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

[Stuart Cheshire <[e-mail]>]

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

Terminology and references fixed.

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

I changed it to MUST.

> ----
> 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".

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.

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

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

> ------------------
> 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."

Fixed.

> ----
> 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"

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.

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

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.

> -----------------
> 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?

Fixed.

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

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 <[e-mail]>
* Wizard Without Portfolio, Apple Inc.
* www.stuartcheshire.org