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

[Ballot comment]
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?

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot discuss]
The Gen-ART Review by Ben Campbell on 7-Jun-2011 includes:

    This draft does not seem to be quite ready for publication, in
    that it professes to obsolete RFC 2672, but does not cover all
    the material from that RFC or explain the absence of the missing
    material.

    -- Section 4.2 of RFC 2672, "Processing by Resolvers", is not
      replicated in this draft or it is in a very different form.

    -- Section 5 of RFC 2672, "examples of use" is not replicated in
      this draft. Similar examples are mentioned in the introduction,
      but the detail is removed.

  Two revisions of this document have been posted since this review,
  but the issue has not been addressed.  I think it is best resolved
  by the addition of a section that covers the changes since RFC 2672.

[Ballot comment]
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).

[Ballot discuss]
The document header and abstract contradict each other. The header says that this document obsoletes RFC 2672 and updates RFCs 3363 and 4294. The abstract says "This is a revision to the original specification in RFC 2672 as well as updating RFC 3363 and RFC 4294 to align with this revision.

[Ballot comment]
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

[Ballot comment]
#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.

[Ballot comment]
- 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?

[Ballot comment]
[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.

IANA understands that, upon approval, there is a single IANA action that
needs to be completed.

In the Registry Name: Resource Record (RR) TYPEs registry in the Domain
Name System (DNS) Parameters registry located at:

http://www.iana.org/assignments/dns-parameters

the reference for the entry that currently reads:

DNAME 39 DNAME [RFC2672]

will be updated with a reference to [ RFC-to-be ].

IANA understands that this is the only action required upon approval of
the document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Update to DNAME Redirection in the DNS) to Proposed Standard


The IESG has received a request from the DNS Extensions WG (dnsext) to
consider the following document:
- 'Update to DNAME Redirection in the DNS'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-06-09. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The DNAME record provides redirection for a sub-tree of the domain
  name tree in the DNS system.  That is, all names that end with a
  particular suffix are redirected to another part of the DNS.  This is
  a revision of the original specification in RFC 2672, also aligning
  RFC 3363 and RFC 4294 with this revision.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dnsext-rfc2672bis-dname/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dnsext-rfc2672bis-dname/


No IPR declarations have been submitted directly on this I-D.

This is the completed Document Shepherd Write-Up as required by RFC
4858 for the draft draft-ietf-dnsext-rfc2672bis-dname-22. This
template was completed 2011-05-04.

The template version is dated September 17, 2008.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Andrew Sullivan is the Document Shepherd. He has reviewed the
document and believes it is ready.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has been part of the DNSEXT work for a number of years.
It is on version 22; the -00 was published in 2006.

It has been through several lengthy discussions on the WG mailing
list. Recent calls for any additional comments did not result in any
new work.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There was at least one WG participant who maintained privately that he
could not support the document publicly, because he believes it
introduces a subtle incompatibility; but that he was not willing to
object publicly. The shepherd sought elaboration of this critique,
but (1) it wasn't forthcoming and (2) nobody else made it.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Yes. Note that the complaint about NOT RECOMMENDED & 2119 isn't quite true:
the phrase is only in the document in order to update a different
document that already uses that phrase.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

The references are so split, and everything is correct.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

Yes. There is a request to update an existing registry. It is identified.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

N/A

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:
Technical Summary

The DNS DNAME RRTYPE redirects subtrees of the domain name
space. This memo updates the original specification found in
RFC 2672. It also aligns RFC 3363 and RFC 4294 with the
revision.

Working Group Summary

The DNS Extensions Working Group has spent a considerable
amount of time on this document. It is the product of
extended review. The chairs believe the WG consensus to be
strong.

Document Quality

The document is partly the result of experience with the
original DNAME specification, and highlights a number of
issues that have proven troublesome in practice. In the
opinion of the WG, the draft clarifies these issues without
introducing wire changes to the protocol.