Subject: [dnsext] TSVDIR review of draft-ietf-dnsext-rfc2672bis-dname

From: Joe Touch <[email-masked]>
Date: Sun, 12 Jun 2011 06:51:16 -0700

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 
[email-masked] 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.

---

-----