Subject: [apps-discuss] Apps-Review Team Review: draft-cheshire-dnsext-dns-sd-07

From: Joseph Yee <[email-masked]>
Date: Fri, 3 Dec 2010 15:58:25 -0500

I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team).
Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.

Document: draft-cheshire-dnsext-dns-sd-07
Title: DNS-Based Service Discovery
Reviewer: Joseph Yee
Review Date: Dec 2, 2010

Summary: The draft is almost ready for publication as Standard Track but has few issues that should be fixed before publication.  I have a "Question" section after the Nits section.  They are merely questions about this draft in general.  No blocking issues there.

------------------
Major Issues: 
1) Section 4.1, last paragraph, need update on terminologies

The paragraph use terminologies from IDNA2003 (ie. UTF-8 NFC, punycode), and best to update it to IDNA2008 (U-label, A-label, etc).  The paragraph needs to cite RFC5890 instead of RFC3492/3490.  The references, whether it's RFC 3490/3492/5980, are missing in both normative and informative reference section.

Note: Two issues mentioned here.  Update of terminologies is Major.   The lack of reference is Minor (no repeat in Minor section). 

----
2) Concerns on key/value pair in TXT
     Section 6.3, 2nd paragraph
     Section 6.4, 1st paragraph

   section 6.3: If an implementation sees unknown
   keys in a service TXT record, it MUST silently ignore them.

   section 6.4: The "Key" MUST be at least one character. Strings beginning with an
   '=' character (i.e. the key is missing) SHOULD be silently ignored.

    If unknown-key (6.3) MUST be ignored, undefined-key (6.4) is more of a configuration error than unknown-key.  Undefined-key needs to have same level of ignores in unknown-key.  SHOULD gives the dangerous "freedom".  

    Recommendation (Section 6.4, 1st paragraph)
    The "Key" MUST be at least one character. Strings beginning with an
   '=' character (i.e. the key is missing) MUST be silently ignored.

----
3) Section 6.7 (1st paragraph), version tag being 1st key/value pair in TXT records 

     The first paragraph mentioned if using version tag, it "require it to be the first key/value pair in the TXT records" to help client to determine if there's any compatibility concerns.  In regular DNS, when there are multiple TXT records, the order is giving out in "pseudo random" order (some rotate the order in predictable manner).  The first order appearance can't be guarantee in regular DNS even version tag is the first inserted/defined TXT into configuration.

     My recommendation is to update the paragraph to have client to inspect version value after capturing all key/value pairs, and proceed only after checking the compatibility concerns.
     
     Note 1: I interpret the "require it to be the first key/value pair in the TXT record" as equivalent to "MUST be the first pair for client to receive".     

----
4) Mandatory of TXT record (Section 6, general, interoperability)
    There are many SRV records deployed without the associated TXT.  With this draft trying to "merge" 2 sides of the world, this draft needs to address the potential lack of TXT RR in some services.  

    The draft needs to bring up the following:
    - New services need to have TXT record, even it's empty  (this was addressed)
    - Client implementations need to be robust to expect TXT RR may not be there
    - In absence of TXT, client implementations MAY
        - treat the service has empty parameter 
       OR
        - treat the service as not serviceable at the moment
      
NOTE: What's saying at client implementations are suggestion.  I would leave it to authors to determine the scenarios, but I believe the need to expand the text (no pun intended).  The current draft had gone in great details to explain many issues (they are great), I believed this draft is the right place to address it.

------------------
Minor Issues:
1) Section 4.1, 2nd paragraph on page 7
"However, the Unicode
   characters with longer UTF-8 encodings tend to be the more rarely-
   used ones, and tend to be the ones that convey greater meaning per
   character."

recommendation
"However, the Unicode
   characters with longer octet length under UTF-8 encoding tend to be the more rarely-
   used ones, and tend to be the ones that convey greater meaning per
   character."

----
2) Section 4.3, 2nd paragraph, first sentence
original
"Any dots in the <Instance> portion should be escaped by preceding them with a backslash"
recommendation
"Any dots in the <Instance> portion MUST be escaped by preceding them with a backslash"

----
3) Section 7, 3rd paragraph, first sentence
original
"Application Protocol Names may be no more than fifteen characters
   (not counting the mandatory underscore)"
recommendation
"Application Protocol Names RECOMMENDED be no more than fifteen characters
   (not counting the mandatory underscore)"

This is a soft (recommendation) limit rather than hard limit.

-----------------
Nits: 

1)  Status of this Memo, Last paragraph, the sole sentence.
"This Internet-Draft will expire on 8th September 2010."

Wrong date and not necessary. Boilerplate issue?

-----------------
Questions

1. Ever thought of creating an ABNF for the whole service name?

2. What will the IANA Consideration section like after draft-ietf-tsvwg-iana-ports published (what part will get deleted)?  Is DNS-SD draft depend on draft-ietf-tsvwg-iana-ports to publish first? Wouldn't the suggestions of how IANA to manage service name be better suggest in draft-ietf-tsvwg-iana-ports (and discuss there) instead?

-----------------
Best
Joseph

---

From: Stuart Cheshire <[email-masked]>
Date: Wed, 15 Dec 2010 14:30:06 -0800

On 3 Dec 2010, at 12:58 PM, Joseph Yee wrote:

> I have been selected as the Applications Area Review Team reviewer  
> for this draft
>
> Major Issues:
> The paragraph use terminologies from IDNA2003 (ie. UTF-8 NFC,  
> punycode), and best to update it to IDNA2008 (U-label, A-label,  
> etc).  The paragraph needs to cite RFC5890 instead of  
> RFC3492/3490.  The references, whether it's RFC 3490/3492/5980, are  
> missing in both normative and informative reference section.
>
> Note: Two issues mentioned here.  Update of terminologies is  
> Major.   The lack of reference is Minor (no repeat in Minor section).

Terminology and references fixed.

>     If unknown-key (6.3) MUST be ignored, undefined-key (6.4) is  
> more of a configuration error than unknown-key.  Undefined-key  
> needs to have same level of ignores in unknown-key.  SHOULD gives  
> the dangerous "freedom".
>

I changed it to MUST.

>      The first paragraph mentioned if using version tag, it  
> "require it to be the first key/value pair in the TXT records" to  
> help client to determine if there's any compatibility concerns.  In  
> regular DNS, when there are multiple TXT records, the order is  
> giving out in "pseudo random" order (some rotate the order in  
> predictable manner).  The first order appearance can't be guarantee  
> in regular DNS even version tag is the first inserted/defined TXT  
> into configuration.
>
>      My recommendation is to update the paragraph to have client to  
> inspect version value after capturing all key/value pairs, and  
> proceed only after checking the compatibility concerns.
>
>      Note 1: I interpret the "require it to be the first key/value  
> pair in the TXT record" as equivalent to "MUST be the first pair  
> for client to receive".

The order that *different* TXT records are returned is undefined by  
DNS, but the order of constituent strings within a *single* DNS TXT  
record is well defined.

>     There are many SRV records deployed without the associated  
> TXT.  With this draft trying to "merge" 2 sides of the world, this  
> draft needs to address the potential lack of TXT RR in some services.
>
> NOTE: What's saying at client implementations are suggestion.  I  
> would leave it to authors to determine the scenarios, but I believe  
> the need to expand the text (no pun intended).  The current draft  
> had gone in great details to explain many issues (they are great),  
> I believed this draft is the right place to address it.

I have added:

    Note that this requirement for a mandatory TXT record applies
    exclusively to DNS-SD service advertising, i.e. services advertised
    using the PTR+SRV+TXT convention specified in this document.
    It is not a requirement of SRV records in general. The DNS SRV  
record
    datatype [RFC 2782] may still be used in other contexts without any
    requirement for accompanying PTR and TXT records.

I have also added:

    An empty TXT record containing zero strings is disallowed by RFC
    1035. DNS-SD implementations MUST NOT emit empty TXT records.
    DNS-SD clients MUST treat the following as equivalent:

     o A TXT record containing a single zero byte.
       (i.e. a single empty string.)

     o An empty (zero-length) TXT record
       (This is not strictly legal, but should one be received it should
       be interpreted as the same as a single empty string.)

     o No TXT record.
       (i.e. an NXDOMAIN or no-error-no-answer response.)

Fixed.

> "Any dots in the <Instance> portion MUST be escaped by preceding  

IETF standards specify on-the-wire protocol requirements. This  
section points out an issue implementers should be aware of, but I'm  
wary of actually dictating internal implementation decisions  
regarding how to address that issue.

Is this new text satisfactory?

    If client software takes the <Instance>, <Service> and <Domain>
    portions of a Service Instance Name and internally concatenates them
    together into a single string, then because the <Instance>  
portion is
    allowed to contain any characters, including dots, appropriate
    precautions MUST be taken to ensure that boundaries are properly
    preserved. Client software can do this in a variety of ways, such as
    character escaping.

    This document RECOMMENDS that if concatenating the three portions of
    a Service Instance Name, any dots in the <Instance> portion should
    be escaped following the customary DNS convention for text files:
    by preceding literal dots with a backslash (so "." becomes "\.").
    Likewise, any backslashes in the <Instance> portion should also be
    escaped by preceding them with a backslash (so "\" becomes "\\").
    Having done this, the three components of the name may be safely
    concatenated. The backslash-escaping allows literal dots in the name
    (escaped) to be distinguished from label-separator dots (not
    escaped), and the resulting concatenated string may be safely passed
    to standard DNS APIs like res_query(), which will interpret the
    backslash-escaped string as intended.

> This is a soft (recommendation) limit rather than hard limit.

No, it's a hard limit. Implementations set buffer sizes and protocol  
fields based on this limit. There is no benefit to be had in allowing  
some Application Protocol Names to be bigger than this. This is also  
documented in draft-ietf-tsvwg-iana-ports.

Fixed.

I am not a fan of ABNF. I feel it is frequently used where not  
necessary just because it makes a document look more "technical",  
even though for many people is *less* comprehensible than plain  
English. And if the document contains both, then which is normative?

> 2. What will the IANA Consideration section like after draft-ietf- 
> tsvwg-iana-ports published (what part will get deleted)?  Is DNS-SD  
> draft depend on draft-ietf-tsvwg-iana-ports to publish first?  
> Wouldn't the suggestions of how IANA to manage service name be  
> better suggest in draft-ietf-tsvwg-iana-ports (and discuss there)  
> instead?

That will depend on the final form draft-ietf-tsvwg-iana-ports takes.  
I am willing to hold this document until draft-ietf-tsvwg-iana-ports  
is published, as long as that does not take too long. Remember that  
this document first started in 2001 (draft-cheshire-dnsext- 
nias-00.txt), seven years before draft-ietf-tsvwg-iana-ports-00.

Stuart Cheshire <[email-masked]>
* Wizard Without Portfolio, Apple Inc.
* www.stuartcheshire.org