[Gen-art] Gen-ART LC Review of draft-cheshire-dnsext-dns-sd-05

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

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 (--).
>

Thanks!

Ben.

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art