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

[Joseph Yee <[e-mail]>]

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