Last Call Review of draft-ietf-dnsext-rfc2672bis-dname-
review-ietf-dnsext-rfc2672bis-dname-tsvdir-lc-touch-2011-06-14-00

Hi, all,



I've reviewed this document as part of the transport area directorate's 


ongoing effort to review key IETF documents. These comments were written 


primarily for the transport area directors, but are copied to the 


document's authors for their information and to allow them to address 


any issues raised. The authors should consider this review together with 


any other last-call comments they receive. Please always CC 


tsv-dir at ietf.org if you reply to or forward this review.






The document discusses change to the DNAME DNS record. Such changes are 


discussed in their impact to both the DNS in general, and to SRV records 


in particular. These are the key ways in which this change affects 


transport protocols, and are sufficiently addressed; there do not appear 


to be any other transport issues.






I do have some other concerns which are noted below, and which are 


offered for consideration.






I hope this feedback will be useful to the authors, and will be glad to 


provide further assistance either on- or off-list as useful.




Joe

---------------------------------------------------------------------



The document fails to explain exactly how it changes RFC 2672. At best 


this is noted obliquely in the end of section 2.5 (is this all?). These 


changes should be made clear in the abstract, the intro, and in a 


separate section summarizing the exact ways in which this document 


overrides RFC 2672. The same advice applies for other RFCs this document 


updates (though this does appear to occur in Sec 4).






Further, it is not clear whether this document changes only part of 


RFC2672. It includes some parts of that RFC unmodified (Sec 3.2). If 


this document *obsoletes* that RFC, is this document complete in the 


absence of that RFC? (this should be made clear in the document explicitly).






The abstract explains this is an update and which RFCs are affected, but 


should also briefly state how and why. I.e., the abstract should be 


self-contained.




"Punycode" should be described when introduced, with a reference.



Wherever this document includes advice from RFCs it does not update 


(e.g., Sec 3.3), it should explicitly indicate whether it is copying 


advice verbatim or clarifying it.






Sec 6 should be revised to clarify the relationship between IANA and the 


registries it operates. I.e.:




   The DNAME Resource Record type code 39 (decimal) originally has been
   registered by [RFC2672].  IANA should update the DNS resource record
   registry to point to this document for RR type 39.
should read:
   The DNAME Resource Record type code 39 (decimal) originally and
   currently refers to [RFC2672], the document that initiated its
   assignment. IANA should update the DNS resource record registry to
   refer to this document for RR type 39.

---








-----