DNAME Redirection in the DNS
draft-ietf-dnsext-rfc2672bis-dname-26

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

(Ralph Droms; former steering group member) Yes

(Adrian Farrel; former steering group member) No Objection

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

(David Harrington; former steering group member) No Objection

(Gonzalo Camarillo; former steering group member) No Objection

(Jari Arkko; former steering group member) No Objection

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?

(Pete Resnick; former steering group member) No Objection

[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; former steering group member) No Objection

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; former steering group member) No Objection

(Ron Bonica; former steering group member) (was Discuss) No Objection

(Russ Housley; former steering group member) (was Discuss) No Objection

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

(Sean Turner; former steering group member) No Objection

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

(Stephen Farrell; former steering group member) No Objection

- in 2.4 would s/must be involed/MUST be invoked/ be better?

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

(Wesley Eddy; former steering group member) No Objection