xNAME RCODE and Status Bits Clarification
draft-ietf-dnsext-xnamercode-00

[Ballot comment]
The Abstract says:

  This document
  clarifies, in the case of such redirected queries, how the RCODE and
  status bits correspond to the initial query cycle (where the CNAME or
  the like was detected) and subsequent or final query cycles.

A standards track document that "clarifies" an existing RFC looks
awfully like an "update".

This seems to be confirmed in Section 3.

As Pete channels Murray, please consider whether this document *does*
update any existing RFCs.

[Ballot comment]
Please address the concerns of Murray Kucherawy's AppsDir review and SM's IETF list comment:

1. Please add an appropriate "Updates" list to this document. Murray mentioned 1035, 2308, and 2672. 1034 and 4035 might also be on the list. I will leave it to the judgement of the authors and WG to figure out what's appropriate.

2. Please give some context for section 2. In particular, Andrew Sullivan's reply to Murray on the IETF list seems to have appropriate explanation that there are implementations that failed to correctly implement the current specs. A mention of that in section 2 would be useful.

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:  (xNAME RCODE and Status Bits Clarification) to Proposed Standard


The IESG has received a request from the DNS Extensions WG (dnsext) to
consider the following document:
- 'xNAME RCODE and Status Bits Clarification'
  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 2012-02-06. 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 Domain Name System (DNS) has long provided means, such as CNAME
  (Canonical Name), where a query can be redirected to a different
  name. A DNS response header has an RCODE (Response Code) field, used
  for indicating errors, and response status bits. This document
  clarifies, in the case of such redirected queries, how the RCODE and
  status bits correspond to the initial query cycle (where the CNAME or
  the like was detected) and subsequent or final query cycles.







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

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


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

PROTO write-up for draft-ietf-dnsext-xnamercode
Template version 2008-09-17

2012-01-20

  (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; yes; yes.

  (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?

It was reviewed by five DNSEXT WG reviewers who said they supported
publication. It has not been reviewed to my knowledge outside DNSEXT,
but it is related specifically to clarification of how the DNS
protocol works.

  (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 specific concerns.  There is no IPR disclosure related to this
document as far as I am aware.

  (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?

It is not clear. The document originally failed to reach the minimum
number of reviewers during WGLC, which suggested that it has not been
widely reviewed.  Its recommendations, however, appear to be in line
with a general agreement on the mailing list about how to clarify this
issue. DNSEXT documents often do not attract as much review as we
might like, but when it was announced that this document would die,
more reviewers came forward in its support; nobody objected.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarize 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?

Nits checked.  There are no other review criteria.

  (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].

References are ok.

  (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?

The IANA Considerations section exists and may be removed at
publication time.  A note to this effect is included.

  (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?

There are no such sections.

  (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
        This memo clarifies how to set the RCODE and how to handle the
        AD and AA bits when processing chains of CNAMEs, DNAMEs, or
        any other similar (as yet uninvented) RRTYPE that performs
        name redirection.  It addresses an ambiguity that has
        persisted in handling of these RRTYPEs since RFC 1034 was
        published. 

    Working Group Summary
        This memo was reviewed by five reviewers of the DNS Extensions
        Working Group. It agrees with other discussions on the DNSEXT
        mailing list about how to handle these cases.

    Document Quality
        The memo agrees with the actual behaviour of many deployed
        DNS resolvers.