DNAME Redirection in the DNS
RFC 6672

Note: This ballot was opened for revision 25 and is now closed.

(Ralph Droms) Yes

(Jari Arkko) No Objection

Comment (2011-10-20 for -)
No email
send info
I asked Ari Keränen to help me with the review of this document. Here's what he said:

It wasn't clear how this draft updates (or, actually, why this draft 
obsoletes) RFC 2672. The intro seems to imply that this (only) adds 
"discussion [...] on problems that may be encountered when using DNAME", 
but this alone sounds a bit strange reason for obsoleting, instead of 
simply updating, an RFC. Perhaps a short high-level section on what is 
changed would help?

1.  Introduction

    Examples include punycode alternates for domain spaces.

Consider adding reference to punycode (RFC3492).

4.  DNAME Discussions in Other Documents

    In [RFC3363], the paragraph
      "The issues for DNAME in the reverse mapping tree appears to be
      tree be deprecated."
    is to be replaced with the word "DELETED".

Considering that you can't really change a published RFC, this text 
seems a bit odd. I'd rather say that one "MUST NOT" do that; and/or 
"instead of X [...] MUST Y".

5.2.  Dynamic Update and DNAME

    If a dynamic update message attempts to add a DNAME with a given
    owner name but a CNAME is associated with that name, then the server
    MUST ignore the DNAME.

Would some error response/notification be appropriate in this case?

(Ron Bonica) (was Discuss) No Objection

(Gonzalo Camarillo) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2011-10-17 for -)
No email
send info
I would have liked to see a section that summarised "Changes from
RFC 2672". (cf. Sean)


It wouldn't hurt to name the registry in Section 7

(Stephen Farrell) No Objection

Comment (2011-10-11 for -)
No email
send info
- in 2.4 would s/must be involed/MUST be invoked/ be better?

- in, last sentence would s/The validator must verify/The
valiator MUST verify/ be better?

(David Harrington) No Objection

(Russ Housley) (was Discuss) No Objection

Comment (2011-10-20)
No email
send info
The Abstract says: "This is a revision of the original specification
  in RFC 2672, also aligning RFC 3363 and RFC 4294 with this revision."
  The title page header indicates that this document obsoletes RFC 2672,
  and updates RFC 3363 and RFC 4294.  Please explicitly state this

(Pete Resnick) No Objection

Comment (2011-10-09 for -)
No email
send info
[Probably tilting at a windmill, but...]
I don't think 2119 language is correctly used when talking about whether a server "SHOULD" load a zone. See section 2.4 and the last paragraph of section 3.3 and compare section 6 of 2119. Not a hill I'm prepared to die on, but I would really like to see this text change.

(Peter Saint-Andre) No Objection

Comment (2011-10-19 for -)
No email
send info
In Section 1, might the sentence about "punycode alternates for domain spaces" benefit by citing RFC 3492? The same is true for Section 5.1.

Section 2.1 has "class-sensitive" -- is "case-sensitive" meant here?

Section 2.1 has "must be sent in uncompressed form" -- is MUST meant here?

Section 2.4 notes that "A server SHOULD refuse to load a zone that violates these rules." Are there particular circumstances under which it is acceptable to violate this SHOULD?

The "Requirements Language" boilerplate text after the Abstract does not include "NOT RECOMMENDED", but Section 4 includes that term; please add it to the boilerplate (this will be accepted by the RFC Editor).

(Robert Sparks) No Objection

(Sean Turner) No Objection

Comment (2011-10-13 for -)
No email
send info
#1) Many times when a document obsoletes another there's a section in the new document that summarizes what's changed.  Such a section would be nice to have in s1.