TSVDIR review of draft-ietf-dnsext-rfc2672bis-dname

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

---








-----
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]