Re: Last Call: draft-cheshire-dnsext-dns-sd (DNS-Based Service Discovery) to Informational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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@xxxxxxxx mailing lists by 2008-12-02. Exceptionally,
comments may be sent to iesg@xxxxxxxx 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf-announce

_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]