Great document I really like it but I think there are a few things
that need to be done to improve it on the administrative side
(technically looks great)..
First of all, it seems to me that there are lots of standards track
stuff that will want to use this, it is well defined, works, widely
implemented, and does not cause harm to existing things - Why would we
do this as informations? I think it should be PS.
Next, I think the IANA section needs some work. It seems that this
specification needs to define a few registries. One for the
application protocol names which needs to be somehow unified with
ports, one for flagship names and another for the sub names. Perhaps
there is a better way to organize these than 3 registries, I don't
care how it gets done but it seems all three of these things do need
to be registered.
For the application protocol names, it seems wise for the registry to
include things for each protocol such as 1) who registered it 2)
optional associated specification such as RFC or URL 3) defined flags
4) associated flagship protocol 5) associated subs 7) full name of
protocol.
The IANA section should ideal provide a template used for new
registrations.
The specification should also provide the initial values to put in the
registry. I would recommend include the 400+ names that are currently
on the external site (thank you for running that BTW) in an appendix
so they can be regressed.
The IANA section should come into force on approval of draft, not on
publication of RFC. This reduces the time of transition.
IANA time is better spend not doing things like checking the protocol
names meant the rules defined here. I think an expert review will do a
better job of that. I think the registry should be Expert review from
the beginning and this specification should provide guidance to the
review that basically any name should be given on FCFS type basis as
long as it meant the rules in this specification and was not making
unreasonable use of the registry. This also resolves the issue of who
and when could change it from FCFS to Expert Review. Would you b
willing to be an expert reviewer for this? If the volume is high, some
registries, such as ports have a bunch of reviewers.
If we want to allow secret registrations, the exact details of that
need to be provided here. I'm very against this as it would be an
administrative nightmare to handle. Instead I would suggest a
different process that achieves much the same effect. During secret
product development, some random individual or even a agent who does
not reveal who they are working for registers the protocol _dapp with
no more information about that than who registered it. Later when the
product is released, the agent or individual could transfer change
control of the registration to apple and update the registration with
all the other information including what dapp was an abbreviation for.
This leads to another area, what to do when the person registered to
update a registration can no longer be contacted at the supplied email
address or easily found. In this case, I believe the expert should be
able to update the registration up to and including removing it if
there is a clear need to do that.
Few other comments.
The rest of my comments are small nits with the document.
Some people may complain that you are using names other than example.*
and use of such names in RFC may cause the internet to melt down.
In section 4.2 seems to be the first mention of PTR records with no
introductory text on how they are used or what they do. Seem like a
sentence or two here might help. The PTR come up again in last para of
section 8 but are not really explained until the next section.
In section 6.5, I think you should soften the advice on using binary
in the TXT records. Sure we need to keep record size in mind but for
many cases, I can imagine an value containing an IP address to be much
easier to work with in ascii than binary. [not to mention v6 address
are sometimes smaller in binary than ascii]. I think the person
defining the tags needs to carefully consider the representation
keeping size limits in mind but ASCII is going to be easier to work
with in many environments - particularly when using existing DNS
servers and tools
In section 12, it was not clear to me why and when you needed this. I
suspect a little more motivation is needed here about what types of
applications need to use these and when.
Section 13.1 Given I would like this to wok with existing DNS servers,
I think a MAY would be better than a SHOULD here. Or if you want to
leave it as a SHOULD, explain when it is OK not to do this.
Cullen in my individual contributor roll
On Nov 4, 2008, at 7:28 , The IESG wrote:
The IESG has received a request from an individual submitter to
consider
the following document:
- 'DNS-Based Service Discovery '
<draft-cheshire-dnsext-dns-sd-05.txt> as an Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to
the
ietf(_at_)ietf(_dot_)org mailing lists by 2008-12-02. Exceptionally,
comments may be sent to iesg(_at_)ietf(_dot_)org instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.
The file can be obtained via
http://www.ietf.org/internet-drafts/draft-cheshire-dnsext-dns-
sd-05.txt
IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=9784&rfc_flag=0
_______________________________________________
IETF-Announce mailing list
IETF-Announce(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf