Extension Mechanisms for DNS (EDNS(0))
draft-ietf-dnsext-rfc2671bis-edns0-10

IANA has reviewed draft-ietf-dnsext-rfc2671bis-edns0-09 and has the following comments:

IANA has questions about some of the IANA actions requested in
this document.

IANA understands that, upon approval of this document, there are six
actions which IANA must complete.

First, in the Domain Name System Parameters Registry located at:

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

The reference for the following subregistries should be changed from
RFC 2671 to
[ RFC-to-be ]. The sub-registries are:
- DNS EDNS(0) Options
- EDNS Version Number
- EDNS Header Flags

Second, in the DNS Label Types subregistry of the Domain Name System Parameters
Registry located at:

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

the Extended label typ with Registry value: "1 1" should have its reference
changed from RFC 2671 to [ RFC-to-be ].

Third, in the DNS RCODEs subregistry of the Domain Name System Parameters
Registry located at:

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

the Bad OPT Version (vallue 16) should have its reference changed from
RFC 2671
to [ RFC-to-be ].

Fourth, RFC 2671 created the "EDNS Extended Label Type Registry".

IANA Question --> is this the values in the sub-registry called "DNS Label
Types" in the Domain Name System Parameters Registry located at:

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

where the first two bits are "0 1" and the lower six bits of the label type
indicate the type of label in use? If so, IANA is to close this part of the DNS
label types to further registrations. However, registrations of normal and
compressed labels are understood to still be available.

IANA also would like to know if this change would meet the needs of the
following request in the document: "[RFC2671] called for the recording of
assignment of extended label types 0bxx111111 as "Reserved for future extended
label types". This request implied a request to open a new registry for
Extended Label Types but due to the possibility of ambiguity new text
registrations were instead made within the general "DNS Label Types" registry
which also registers entries originally defined by [RFC1035]. This document
requests IANA to close registration of further Extended Label Types in the "DNS
Label Types" Registry.

Fifth, in the DNS EDNS0 Options subregistry of the Domain Name System Parameters
Registry located at:

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

option code 65535 is registered as "Reserved for future expansion."

IANA Question --> Should the reference be updated from RFC 2671 to [ RFC-to-be ]?

Sixth, the document requests that, "This document assigns EDNS Extended
RCODE 16
to "BADVERS" in the DNS RCODES registry."

However, in the DNR RCODES subregistry in the Domain Name System Parameters
Registry located at:

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

16 is already registered as BADVERS - Bad OPT Version.

IANA Question --> Should the reference be updated from RFC 2671 to
[ RFC-to-be ]?

IANA understands that these six actions are the only one required to be
completed upon approval of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard


The IESG has received a request from the DNS Extensions WG (dnsext) to
consider the following document:
- 'Extension Mechanisms for DNS (EDNS(0))'
  as Internet 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-10-29. 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's wire protocol includes a number of fixed
  fields whose range has been or soon will be exhausted and does not
  allow requestors to advertise their capabilities to responders.  This
  document describes backward compatible mechanisms for allowing the
  protocol to grow.

  This document updates the EDNS(0) specification (and obsoletes RFC
  2671) based on feedback from deployment experience in several
  implementations.  It also closes the IANA registry for extended
  labels created as part of RFC 2671 and obsoletes RFC 2673 ("Binary
  Labels in the Domain Name System") which depends on the existence of
  extended labels.

This IETF Last Call is a second Last call for this document, to address
process issues with the first Last Call.  The document has been updated
since the first Last Call to address comments received during the Last
Call and during IESG review.


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

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


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

Requested second IETF Last Call to address process issues with
the first Last Call; specifically, the first Last Call announced the
document as in consideration for "Full Standard" rather than
"Internet Standard".

[Ballot comment]
Thanks for addressing my other issues. A few still outstanding.

Section 6.1.2:

- You changed "Must" to "MUST" in the table. I don't think you should have, Sean's comment (well, question really) notwithstanding. That said, figure out what the right thing is and do it. Both this and Sean's are just comments, not directives that you have to change this. Is this a protocol instruction that implementations need to be told about in order to work interoperably (in which case MUST is right), or is this just a definition of the field (in which case Must is right)? You decide.

- Just below the table

  Each option MUST be treated as a bit field.

So you changed "binary" to "a bit field". I still don't know what that means. Please explain.

Section 6.2.3:

  Bigger values SHOULD be considered by implementers to be used where
  fragmentation is not a concern.

The protocol instruction isn't to *consider* a bigger value; it's to *use* it. Change to:

  Bigger values SHOULD be used by implementers where fragmentation is
  not a concern.

To paraphrase Yoda, "Use, or do not use. There is no consider."

Section 10:

  IETF Standards Action is required for assignments of new EDNS0 flags.
  Flags SHOULD be used only when necessary for DNS resolution to
  function.  For many uses, a EDNS Option Code may be preferred.

2119 terms in IANA considerations give me the willies. Who are you instructing to only use the flags here? IANA? Again, those last two sentences probably belong somewhere else, and either way, drop the "SHOULD", perhaps making it "are only to".

Document was pulled from IESG telechat agenda to address process issues with advancement to Internet Standard.  dnsext WG chairs and document authors will collaborate on a revision to the document.  AD will then run a 4-week IETF last call.

[Ballot comment]
Please see the comments (and DISCUSS) by Adrian and Pete, with which I agree.  Also...

---
Introduction, third paragraph:
I worry that people aren't used to seeing normative text in introductions, and especially won't be prepared to respond to 2119 language in the introduction.  I suggest moving or repeating that in a later section, where it's more expected, or else deciding that it's not normative (and removing the 2119 keyword).

---
Further on the IANA Considerations mess:

* Separating different IANA actions into their own subsections or into separate bullets in a bulleted list makes it much easier for reviewers (and IANA) to figure out what's being requested.  The first few items (through "IANA is advised to udpates [sic] references") appear to be part of one IANA action, while the rest appear to be separate actions, though I'm not always sure.

* It would really be helpful to note what you're changing, in addition to where you're ending up.  For example, "IETF Standards Action is required for assignments of new EDNS0 flags."... is that a statement of how things are, or a change to an existing situation?

* I'm not sure what "several entries" 2671 created; you seem to only list two here.  Are there more?  "Several" usually implies more than two or three.  If there are more, and you're asking IANA to look for them, it's best to say that.

[Ballot comment]
Support Pete's discuss and feel that addressing Adrian's comments would greatly help with readability.

s6.1.1: I think the following:

  No more than one OPT RR MUST be included within any DNS message.

is trying to say that only one OPT RR is allowed in any DNS message.  Maybe:

  If a responder includes an OPT RR, then it MUST only include one instance the OPT RR.

s6.1.2: In the first table: r/Must/MUST ?

[Ballot comment]
Thanks for this work. I have no objection to its publication as an
RFC. I have a few minor comments that I would appreciate you glancing
over before the document is advanced.

---

The Abstract is mildly confusing by saying this document updates RFC
2671 when, in fact, it obsoletes it.

---

It would be nice if the term "EDNS0" was explicitly tied to "the DNS
extension mechanisms defined in this document". This could be in the
Abstract and the Introduction.

It would also be good to state what "EDNS" means and how it differs
from "EDNS0".

---

I looked for, but could not find a description of the interworking
behavior of an RFC 2671 compliant node and a node that has implemented
the "refinements" defined in this document. Such a description would,
at least, make the reviewer more comfortable.

---

In Section 5

  Therefore, this document moves them from experimental to historical,
  making them deprecated.

I fully expect other ADs will get more excited by this text than I am.
I am not clear that you are moving RFC 2673 to Historical. You probably
want...

  Therefore, this document obsoletes Extended Lables and deprecates all
  label types begining 0b01.

Additinnally, in this section it would be nice to move some things into
the past tense. For example,in...

  A specific Extended Label Type is selected by
  the 6 least significant bits

... s/is/was/

---

I am slightly confused as to what a conformant implementation is
supposed to do when a legacy implementation sends it an Extnded Label.
Should it react as it would do for any unknown label type, or should it
notce te use of a deprecated Extended Label and do something special?

Section 5 does tell me that Extended Labels must not be passed (which is
helpful), but it doesn't feel like the whole story.

---

I am surethat IANA will work through Seciton 10 with you. I found it a
bit muddled and I think it repeats some things. There is also a
difference between closing the registry, and deprecating the extended
label marker of the label type (which the txt earlier in the document
said was intended).

---

It would be good if you could fold A.1 and A.2 together so that the
appendix simply shows the changes since RFC 2671. (But, BTW, thanks for
providing this information which makes review much easier.)

[Ballot discuss]
Section 5 has some problems:

  Extended Label Types are difficult to use due to support in clients
  and intermediate gateways as described in [RFC3364] which moves them
  to experimental status and [RFC3363], which describes the pros and
  cons.

It was 3363 that moved A6 and Bit label to experiments, not 3364, and either way, the above paragraph does not indicate which documents were moved to experimental (nor does the next one). I suggest rewriting:

  Extended Label Types are difficult to use due to lack of support in
  clients and intermediate gateways as described in [RFC3363], which
  moved [RFC2673] to Experimental status, and [RFC3364], which
  describes the pros and cons.

As for the next bit:

  Therefore, this document moves them from experimental to historical,
  making them deprecated.

The IESG is right in the middle of a conversation about the logistics of marking things Historic, and in this case it's completely unnecessary. This document is obsoleting [2673], which is perfectly sufficient. I suggest:

  Therefore, this document obsoletes [RFC2673] and deprecates the use
  of Extended Label Types.

Finally:

  Implementations MUST NOT generate or pass Extended Labels in their
  communications.  Additionally, no further registrations of Extended
  Label Types are permitted.

The reason no further registrations are permitted is because you've asked IANA not to accept them any more. Say that instead:

  Implementations MUST NOT generate or pass Extended Labels in their
  communications.  Additionally, IANA has been requested to close
  registration of further Extended Label Types in the "DNS Label
  Types" Registry so that no further registrations will be permitted.

[Ballot comment]
Section 1:

  Extended agents
  MUST be prepared for handling the interactions with unextended
  clients in the face of new protocol elements, and fall back
  gracefully to unextended DNS.

You haven't yet defined the 2119 terms yet, and I hate putting protocol instructions with 2119 directives into the intro. Can't this be "need to" and leave it to section 8 to handle the "MUSTs"?

Section 6.1.2:

  Each option MUST be treated as binary.

I'm not sure what that means. Please explain.

Section 6.2.3:

  Bigger values SHOULD be considered where fragmentation is not a
  concern.

The protocol instruction isn't to *consider* a bigger value; it's to *use* it. Change "considered" to "used". To paraphrase Yoda, "Use, or do not use. There is no consider."

Section 6.2.6:

  MiddleBoxes which have additional functionality, such as answering
  queries or acting as intelligent forwarders, SHOULD understand the
  OPT record.  These boxes MUST consider the incoming request and any
  outgoing requests as separate transactions if the characteristics of
  the messages are different.

I'm not convinced the "SHOULD" and "MUST" are actionable. You want the middle box to "understand" something and to "consider" something else? Instead of "understand", do you mean "answer or forward"? Instead of "consider", do you mean "treat"?

Section 10:

  [RFC2671] expands the RCODE space from 4 bits to 12 bits.  This
  allows more than the 16 distinct RCODE values allowed in [RFC1035].
  IETF Standards Action is required to add a new RCODE.  Adding new
  RCODEs should be avoided due to the difficulty in upgrading the
  installed base.

That last sentence doesn't see like an IANA consideration, but rather belongs somewhere else in the document.

  IETF Standards Action is required for assignments of new EDNS0 flags.
  Flags SHOULD be used only when necessary for DNS resolution to
  function.  For many uses, a EDNS Option Code may be preferred.

2119 terms in IANA considerations give me the willies. Who are you instructing to only use the flags here? IANA? Again, those last two sentences probably belong somewhere else, and either way, drop the "SHOULD", perhaps making it "are only to".

[Ballot comment]
I only have two editorial comments.

1. The EDNS acronym is not defined before it is used.  I don't see it defined in RFC 2671 either, so it might be good to actually define it somewhere.

2. I see EDNS, EDNS0, and EDNS(0) used in this document, apparently inter-changeably.  Are there any differences between those three?

Upon approval, IANA will complete the following actions:

ACTION 1:

All references to RFC2671 will be replaced with references to this document.


ACTION 2:

IANA will add a note (and a reference to this document) to the EDNS
Extended Label Type Registry indicating that it has been closed.


ACTION 3:

In the DNS EDNS0 Options registry, value 65535 will be designated
"Reserved for future expansion" with this document as a reference.


ACTION 4:

The DNS RCODEs registry will be expanded to 12 bits, and its
registration procedures will be changed to Standards Action.


ACTION 5:

IANA will close registration of further Extended Label Types in the "DNS
Label Types" Registry.


ACTION 6:

The registration procedures for these registries will be updated as follows:

EDNS0 flags: Standards Action
EDNS Version Number: Standards Action
EDNS Option Codes: Expert Review

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:  (Extension Mechanisms for DNS (EDNS0)) to Full Standard





The IESG has received a request from the DNS Extensions WG (dnsext) to

consider the following document:

- 'Extension Mechanisms for DNS (EDNS0)'

  as a Full 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-03-30. 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's wire protocol includes a number of fixed

  fields whose range has been or soon will be exhausted and does not

  allow requestors to advertise their capabilities to responders.  This

  document describes backward compatible mechanisms for allowing the

  protocol to grow.



  This document updates the EDNS0 specification (RFC 2671) based on

  feedback from deployment experience in several implementations.  It

  also closes the IANA registry for extended labels created as part of

  RFC 2671 and obsoletes RFC 2673 ("Binary Labels in the Domain Name

  System") which depends on the existence of extended labels.









The file can be obtained via

http://datatracker.ietf.org/doc/draft-ietf-dnsext-rfc2671bis-edns0/



Implementation Report can be accessed at

http://www.ietf.org/iesg/implementation.html



IESG discussion can be tracked via

http://datatracker.ietf.org/doc/draft-ietf-dnsext-rfc2671bis-edns0/ballot/





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

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

Olafur Gudmundsson ogud at ogud.com is the document shepherd
I have personally reviewed this and prior versions, this
document is ready for publication.

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

This document has had extensive review and comments over its
lifetime as well as during the lifetime of its precursor
RFC2671.
There are no concerns with the reviews.

  (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 IPR disclosure, this is a real important document.
The precursor document was written in pre-RFC2119 style that
made it sometimes hard to nail down exact intent of text, this
document attempts to adress the issues with RFC2671 and
various deployment issues we have run into over the years.
All Normative refernecs are "Full Standard", being obsolted or
"Proposed Standard".

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

Quite solid there are some people that want stronger languague
in certain places and others that want weaker. The WG understands
the document and is overall happy with 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

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

Yes the references are split.
If this document is published as Internet Standard one
normative reference is a downref RFC3225 that is only included
here due to the fact that a registry requested by RFC2671 was
not created by IANA but backfilled much later and this
document fills out the current values of the registry.

  (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 IANA considerations section is present and actionable by
IANA.

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

Does not apply

  (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
        Relevant content can frequently be found in the abstract
        and/or introduction of the document. If not, this may be
        an indication that there are deficiencies in the abstract
        or introduction.
----
    The Domain Name System's wire protocol includes a number of fixed
    fields whose range has been or soon will be exhausted and does not
    allow requestors to advertise their capabilities to responders.  This
    document describes backward compatible mechanisms for allowing the
    protocol to grow.

    This document updates the EDNS0 specification (RFC 2671) based on
    feedback from deployment experience in several implementations.  It
    also closes the IANA registry for extended labels created as part of
    RFC 2671 and obsoletes RFC 2673 ("Binary Labels in the Domain Name
    System") which depends on the existence of extended labels.

    The main contribution of RFC2671 was to allow larger DNS messages
    over UDP, beween cooperating parties, this is crucial for DNSSEC
    and other modern DNS uses.
----

      Working Group Summary
        Was there anything in WG process that is worth noting? For
        example, was there controversy about particular points or
        were there decisions where the consensus was particularly
        rough?

-----
      Working group is solidly behind this document.
----

      Document Quality
        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to
        implement the specification? Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues? If
        there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?

There are many implemenations of this specification, the working group
wish is that this be published as Internet Standard. This document is the
cummulation of fair ammount of work and experience. During the WG process
most of the changes in the document were stylistic and presentation
ones rather than technical.