Last Call Review of draft-ietf-dnsext-rfc2672bis-dname-

Request Review of draft-ietf-dnsext-rfc2672bis-dname
Requested rev. no specific revision (document currently at 26)
Type Last Call Review
Team Transport Area Directorate (tsvdir)
Deadline 2011-06-09
Requested 2011-05-27
Authors Scott Rose, Wouter Wijngaards
Draft last updated 2011-06-14
Completed reviews Secdir Last Call review of -?? by Steve Hanna
Secdir Telechat review of -?? by Steve Hanna
Tsvdir Last Call review of -?? by Joseph Touch
Assignment Reviewer Joseph Touch
State Completed
Review review-ietf-dnsext-rfc2672bis-dname-tsvdir-lc-touch-2011-06-14
Review completed: 2011-06-14


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



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 


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