Document: draft-cheshire-dnsext-dns-sd-05 Reviewer: Ben Campbell Review Date: 2008-11-13 IETF LC End Date: 2008-12-02 IESG Telechat date: (if known) Summary: This draft is on the right track, but there are open issues that should be considered prior to publication. General Comments: -- Intended Status I am not sure I understand the intent of this draft. It has an intended status of "informational", but it defines protocol of a sort, or at least conventions that would benefit from standardization. I don't think that is necessarily a problem per se, if the intent is something along the lines of "here's a protocol used by certain deployed products, and if you want to interoperate with them you can follow this" If that is the case, it would help to be explicit about it in the first few paragraphs of the intro, and perhaps even the abstract. Or maybe a "Scope of Applicability" section. I further note that there are multiple last call comments that suggest this should be a proposed standard, and that there are proposed standard efforts that would like to use it. [I fully admit to not knowing the history that led to this work being "informational", so there may be very good reasons I don't know about.] -- Relationship to existing work On a shallow review, certain aspects of this draft seem to compete with some of the DDDS/NAPTR work, for example, RFC 4848 and 3958. I am curious what how this draft relates to that, and what benefits the author's believe DNS-SD has over, say, U-NAPTR. (This comment is somewhat dependent on the above comment about intended status--if this is truly informational, then it's probably not a problem if it competes with existing work. But if it became a proposed standard, it would be useful for it to contrast itself to RFC 4848 and/or RFC 3958) -- User Interface recommendations: While there is good information here, I wonder why it belongs in this draft, rather than in a separate paper. While most of the draft describes how to implement DNS-SD, The user interface considerations sections really serve to evangelize subjective viewpoints (most of which I agree with, btw) on UI design. UI design is not something the IETF tends to take on in general. Again, this interacts a bit with my "informational" vs "proposed standard" comments above. While most of the draft could conceivably appropriate for a standards track RFC, the UI considerations section is truly "informational" or possibly BCP material. Also, I assume the UI guidance would apply to other service discovery mechanisms as well. If so, that further supports separating it out. -- Tone Several parts of this draft have a strong marketing tone. An RFC should take more of an objective engineering tone. I will point out some specific (but non-exhaustive) examples in the detailed comments below. Specific Comments: --Section 3, 4th paragraph: "... so simple to implement..." This is a very vague test. How do you define "simple to implement"? I personally know of implementors and operators that struggle getting basic DNS right. -- 5th paragraph: Does this draft purport to meet the requirements in [ATalk]? -- Section 4.2, example 3 paragraphs from end: The"XXX Floor.apple.com" examples should use example.com -- 2nd from end: "... this document recommends..." Since you are using 2119 normative language elsewhere, I suspect this should have been a normative statement. (that is, s/recommends/ RECOMMENDS) -- Last paragraph: "... MAY choose to retry the query using Punycode" Did you really intend that to be a MAY? This seems to imply that it is possible to have records that you cannot successful query without using Punycode--which would seem to support making this at least a SHOULD. -- Section 4.5.3, 2nd paragraph: nit - it might be better to avoid the term "machine" and instead use "name server" or maybe even "zone", since these do not necessarily map to a single piece of hardware. -- Section 5, last paragraph: This effectively says that SRV clients SHOULD do SRV correctly. That seems a little weak--but since this paragraph really only restates requirements from the SRV RFC, you can probably drop in entirely, or if you want it for background purposes, restate it descriptively rather than normatively. -- Section 6.7, paragraph 1 Is this recommendation intended to be normative? Also, in the last sentence, do you want to encourage clients to ignore _lower_ version numbers? Doesn't that hurt backward compatibility? -- Section 8 This entire section seems to assume that devices are creating their own SRV records. You mention elsewhere that this is not a requirement, and that manual administration is a valid approach. It might help to also describe the things in this section from an administrator's viewpoint. -- Paragraph 6 : "Typically the flagship protocol is the oldest and/or best-known protocol of the set" That surprises me--I would have guessed the flagship to be the one that best met the needs of the application--which is unfortunately subjective. On the other hand, if devices create their own "flagship" entries, then this only seems to work if the flagship is the lowest common denominator. This would almost seem to imply a normative statement that the flagship MUST or SHOULD be the lowest common denominator, or you are going to have devices disagreeing on what the flagship should be. -- 2nd to last paragraph: This seems to address my previous comment somewhat--but who decides the flagship for a given class? Should their be a registry? -- Section 12, first paragraph after bullet list: "These domains are purely advisory." Is it safe to assume that, while it is optional to use these domains for the purposes listed, they MUST NOT be used for other purposes? -- Section 13.1: For the record, this is counter to the existing guidance for PTR, which says that no additional section processing is needed. Do you expect DNS servers to be aware that DNS-SD PTR records are different than other PTR records and treat them differently? -- 13.2 Is this advice any different than that for SRV in general? If so, then my same comment from 13.1 applies. If not, then there is no need to restate it normatively here. -- Section 14: You compare DNS-SD against non-DNS methods, but you do not compare it against things like DDDS/NAPTR, etc. That comparison would be helpful. -- Section 16.1, numbered list: It is not clear to me if this section talks about what to provision into DNS records, or what clients should display if they notice conflicts. I _think_ you are talking about the first. Are you assuming automatic generation of the DNS records (e.g. via DDNS)? If so, it is probably worth discussing this from a manual provisioning perspective as well. -- Section 16.1, list of printer names: I would suggest hypothetical names, rather than real products. Also, you suggest that printer makers email the authors to get added to the list--you realize that this can't happen once this becomes an RFC, right? -- Section 16.2 This whole section seems full of stealth marketing. You describe UI mistakes, all of most of which can be attributed to a particular vendor I won't name, then you describe "better ways", most or all of which can be attributed to a certain competing vendor. It would help to restate these from a more objective viewpoint--or at least don't make the identity of the guilty so obvious For example: OLD: (b) display some animation like a searchlight sweeping back and forth for ten seconds, and then (c) at the end of the ten-second search, display a static list showing what was discovered. NEW: (b) display an indication that the host is searching for the resources, and then (c) after a predetermined time period, display a static list showing what was discovered so far. -- Section 18 Single paragraph security considerations sections make me nervous. Have you thought about whether the advertising of services in DNS increases the impact of DNS attacks over and above simple name translation? That is, is it more important to use DNSSEC for DNS-SD than for conventional DNS usages? Is it okay for clients to simply accept services as valid because they discovered then via DNS-SD, or should they apply additional authentication? -- Section 19, paragraph 1: The fact that RFC2782 did not create a application id registry does not close the door on having one. I don't know if this draft is the right place to do it--but if one is needed one should be created. I note at least one other draft (draft-gudmundsson-dns-srv-iana- registry-00) that is attempting to do so--perhaps this section could be used as input to that, or some other effort. -- paragraphs 2 and 3: That's a lot of rules for IANA to enforce. You would probably be better off making the registry "expert review" from day one, and let the reviewers enforce the rules. Also, since I assume this would be a general registry of SRV application identifiers, are these rules general, or specific to DNS-SD? If the second, then an expert review would probably be even more important. Also, shouldn't the application IDs for SRV start with an underscore? -- 5th paragraph: I think the risk of collision is higher than you suggest. Names are not chosen randomly, and it is likely that many implementors would naturally choose the same name for similar services. For example, I could see a bunch of implementers jumping on generic names like "print", "printer", "conference", "storage", etc. I think it would be better to encourage implementors to register names as early as possible. -- 2nd to last paragraph: "... applications to remain secret" I don't think you will find much IETF support for secret IANA registries. But even if I am wrong, if we have a need for secret entries here, we are likely to need them for many other things that IANA manages. If you really want to take up that fight, it might be better to do it in a separate draft. -- Final paragraph: Will this paragraph go away when the RFC is published? How do you plan to get the existing registered names into an IANA registry? -- Section 21: This entire section has a strong "marketing" tone. It's goal is not clear to me. If it is really needed, can it be de-hyped somewhat? A few sentences listing products that use DNS-SD and operating systems for which it is available might be sufficient. --the IDNITS tool reports the following. I think it is confused about the weird spacing issue, but probably correct on the domain name and IP address examples. > Checking boilerplate required by RFC 3978 and 3979, updated by RFC > 4748: > > ---------------------------------------------------------------------- > ------ > > == It looks like you're using RFC 3978 boilerplate. You should > update > this, as the boilerplate described in the IETF Trust License > Policy > document (see http://trustee.ietf.org/license-info) is accepted > from 10 > November 2008, and will be required from 16 December 2008, 01:00 > UTC. > Version 1.34 of xml2rfc can be used to produce documents with > boilerplate > according to the mentioned Trust License Policy document. > > > Checking nits according to > http://www.ietf.org/ietf/1id-guidelines.txt > : > > ---------------------------------------------------------------------- > ------ > > No issues found here. > > Checking nits according to http://www.ietf.org/ID-Checklist.html: > > ---------------------------------------------------------------------- > ------ > > ** There are 9 instances of lines with non-RFC2606-compliant FQDNs > in the > document. > > == There are 3 instances of lines with non-RFC3330-compliant IPv4 > addresses > in the document. If these are example addresses, they should be > changed. > > == There are 1 instance of lines with private range IPv4 addresses > in the > document. If these are generic example addresses, they should be > changed > to use the 192.0.2.x range defined in RFC 3330. > > > Miscellaneous warnings: > > ---------------------------------------------------------------------------- > > == Line 1431 has weird spacing: '...olo.net inte...' > > > Checking references for intended status: Informational > > ---------------------------------------------------------------------------- > > == Missing Reference: 'RFC 3492' is mentioned on line 324, but not > defined > > -- Obsolete informational reference (is this intentional?): RFC 2434 > (Obsoleted by RFC 5226) > > -- Obsolete informational reference (is this intentional?): RFC 2535 > (Obsoleted by RFC 4033, RFC 4034, RFC 4035) > > > Summary: 1 error (**), 5 warnings (==), 2 comments (--)