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

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

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?

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

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 ?

The changes suggested in Pete's discuss seem correct to me.

I support Pete's Discuss and Adrian's comments.

Adrian's comment WRT interoperability is important to address.