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