Extension Mechanisms for DNS (EDNS(0))
draft-ietf-dnsext-rfc2671bis-edns0-10
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2013-04-11
|
10 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2013-03-11
|
10 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2013-03-04
|
10 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2013-03-04
|
10 | (System) | RFC Editor state changed to RFC-EDITOR from IANA |
2013-03-04
|
10 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2013-03-01
|
10 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2013-03-01
|
10 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2013-02-27
|
10 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2013-02-27
|
10 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2013-02-12
|
10 | (System) | RFC Editor state changed to IANA from IANA |
2013-01-31
|
10 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2013-01-31
|
10 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2013-01-29
|
10 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2013-01-28
|
10 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent |
2013-01-25
|
10 | (System) | IANA Action state changed to In Progress |
2013-01-25
|
10 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed |
2013-01-25
|
10 | Amy Vezza | IESG has approved the document |
2013-01-25
|
10 | Amy Vezza | Closed "Approve" ballot |
2013-01-25
|
10 | Amy Vezza | Ballot approval text was generated |
2013-01-25
|
10 | Amy Vezza | Ballot writeup was changed |
2012-12-31
|
10 | Joao Damas | New version available: draft-ietf-dnsext-rfc2671bis-edns0-10.txt |
2012-11-15
|
09 | Cindy Morgan | State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2012-11-15
|
09 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks |
2012-11-15
|
09 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2012-11-14
|
09 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley |
2012-11-14
|
09 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2012-11-13
|
09 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2012-11-13
|
09 | Ralph Droms | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2012-11-12
|
09 | Ron Bonica | [Ballot Position Update] Position for Ronald Bonica has been changed to No Objection from Yes |
2012-10-29
|
09 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2012-10-26
|
09 | Pearl Liang | 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, … 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. |
2012-10-10
|
09 | Barry Leiba | Ballot comment text updated for Barry Leiba |
2012-10-08
|
09 | Ralph Droms | Set telechat returning item indication |
2012-10-03
|
09 | Ralph Droms | Placed on agenda for telechat - 2012-11-15 |
2012-09-30
|
09 | Cindy Morgan | 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 … 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. |
2012-09-30
|
09 | Cindy Morgan | State changed to In Last Call from Last Call Requested |
2012-09-30
|
09 | Ralph Droms | Last call was requested |
2012-09-30
|
09 | Ralph Droms | State changed to Last Call Requested from Waiting for AD Go-Ahead |
2012-09-30
|
09 | Ralph Droms | Last call announcement was changed |
2012-09-30
|
09 | Ralph Droms | Ballot writeup was changed |
2012-09-29
|
09 | Ralph Droms | State changed to Waiting for AD Go-Ahead from Last Call Requested |
2012-09-29
|
09 | Ralph Droms | 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 … 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". |
2012-09-29
|
09 | Ralph Droms | Last call was requested |
2012-09-29
|
09 | Ralph Droms | State changed to Last Call Requested from Waiting for AD Go-Ahead::AD Followup |
2012-09-29
|
09 | Ralph Droms | Last call announcement was changed |
2012-09-29
|
09 | Ralph Droms | Last call announcement was generated |
2012-08-18
|
09 | Pete Resnick | [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 … [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". |
2012-08-18
|
09 | Pete Resnick | [Ballot Position Update] Position for Pete Resnick has been changed to No Objection from Discuss |
2012-08-13
|
09 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2012-08-13
|
09 | Joao Damas | New version available: draft-ietf-dnsext-rfc2671bis-edns0-09.txt |
2012-05-16
|
08 | Cindy Morgan | Ballot approval text was generated |
2012-05-14
|
08 | Ralph Droms | 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 … 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. |
2012-04-24
|
08 | Cindy Morgan | Ballot approval text was generated |
2012-04-24
|
08 | Suresh Krishnan | Request for Last Call review by GENART Completed: Ready. Reviewer: Suresh Krishnan. |
2012-04-24
|
08 | Suresh Krishnan | Request for Last Call review by GENART Completed. Reviewer: Suresh Krishnan. |
2012-04-11
|
08 | Ralph Droms | Removed from agenda for telechat |
2012-04-11
|
08 | Ralph Droms | State changed to Waiting for AD Go-Ahead::Revised ID Needed from IESG Evaluation |
2012-04-11
|
08 | Barry Leiba | [Ballot comment] Please see the comments (and DISCUSS) by Adrian and Pete, with which I agree. Also... --- Introduction, third paragraph: I worry that people … [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. |
2012-04-11
|
08 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2012-04-10
|
08 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy |
2012-04-10
|
08 | Stewart Bryant | [Ballot comment] I support Pete's Discuss and Adrian's comments. Adrian's comment WRT interoperability is important to address. |
2012-04-10
|
08 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2012-04-09
|
08 | Stephen Farrell | [Ballot comment] The changes suggested in Pete's discuss seem correct to me. |
2012-04-09
|
08 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2012-04-09
|
08 | Ron Bonica | [Ballot Position Update] New position, Yes, has been recorded for Ronald Bonica |
2012-04-09
|
08 | Ralph Droms | [Ballot comment] Please consider review comments from Alfred Hönes when revising this document: www.ietf.org/mail-archive/web/dnsext/current/msg12345.html www.ietf.org/mail-archive/web/dnsext/current/msg12346.html |
2012-04-09
|
08 | Ralph Droms | Ballot comment text updated for Ralph Droms |
2012-04-09
|
08 | Sean Turner | [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 … [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 ? |
2012-04-09
|
08 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2012-04-08
|
08 | Adrian Farrel | [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 … [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.) |
2012-04-08
|
08 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2012-04-06
|
08 | Ralph Droms | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2012-04-06
|
08 | Pete Resnick | [Ballot discuss] Section 5 has some problems: Extended Label Types are difficult to use due to support in clients and intermediate gateways as … [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. |
2012-04-06
|
08 | Pete Resnick | [Ballot comment] Section 1: Extended agents MUST be prepared for handling the interactions with unextended clients in the face of new protocol … [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". |
2012-04-06
|
08 | Pete Resnick | [Ballot Position Update] New position, Discuss, has been recorded for Pete Resnick |
2012-04-03
|
08 | Brian Haberman | [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 … [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? |
2012-04-03
|
08 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2012-03-30
|
08 | Amanda Baber | 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 … 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 |
2012-03-30
|
08 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2012-03-22
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Suresh Krishnan |
2012-03-22
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Suresh Krishnan |
2012-03-21
|
08 | Martin Stiemerling | Request for Early review by TSVDIR is assigned to Michael Scharf |
2012-03-21
|
08 | Martin Stiemerling | Request for Early review by TSVDIR is assigned to Michael Scharf |
2012-03-20
|
08 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Dave Cridland |
2012-03-20
|
08 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Dave Cridland |
2012-03-16
|
08 | Cindy Morgan | Last call sent |
2012-03-16
|
08 | Cindy Morgan | 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: … 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. |
2012-03-16
|
08 | Ralph Droms | Placed on agenda for telechat - 2012-04-12 |
2012-03-16
|
08 | Ralph Droms | Last call was requested |
2012-03-16
|
08 | Ralph Droms | State changed to Last Call Requested from AD Evaluation |
2012-03-16
|
08 | Ralph Droms | Last call announcement was generated |
2012-03-16
|
08 | Ralph Droms | Ballot has been issued |
2012-03-16
|
08 | Ralph Droms | Ballot approval text was generated |
2012-03-16
|
08 | Ralph Droms | [Ballot Position Update] New position, Yes, has been recorded for Ralph Droms |
2012-03-16
|
08 | Ralph Droms | Created "Approve" ballot |
2012-03-16
|
08 | Ralph Droms | Ballot writeup was changed |
2012-03-16
|
08 | Ralph Droms | Ballot writeup was changed |
2012-03-16
|
08 | Ralph Droms | Ballot writeup was generated |
2012-03-16
|
08 | Ralph Droms | State changed to AD Evaluation from Publication Requested |
2012-02-16
|
08 | Cindy Morgan | Intended Status has been changed to Standard from Proposed Standard |
2012-02-16
|
08 | Cindy Morgan | (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the … (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. |
2012-02-16
|
08 | Cindy Morgan | Draft added in state Publication Requested |
2012-02-16
|
08 | Cindy Morgan | [Note]: 'Olafur Gudmundsson (ogud at ogud.com) is the document shepherd.' added |
2012-02-07
|
08 | (System) | New version available: draft-ietf-dnsext-rfc2671bis-edns0-08.txt |
2012-01-18
|
07 | (System) | New version available: draft-ietf-dnsext-rfc2671bis-edns0-07.txt |
2012-01-03
|
06 | (System) | New version available: draft-ietf-dnsext-rfc2671bis-edns0-06.txt |
2011-09-08
|
08 | (System) | Document has expired |
2011-05-25
|
08 | Ólafur Guðmundsson | IETF state changed to Waiting for WG Chair Go-Ahead from WG Document |
2011-05-25
|
08 | Ólafur Guðmundsson | WG LC just concluded some changes are needed in document. Will require short review after revised version is posted. |
2011-05-25
|
08 | Ólafur Guðmundsson | Annotation tag Revised I-D Needed - Issue raised by WGLC set. |
2011-03-07
|
05 | (System) | New version available: draft-ietf-dnsext-rfc2671bis-edns0-05.txt |
2010-11-08
|
04 | (System) | New version available: draft-ietf-dnsext-rfc2671bis-edns0-04.txt |
2010-03-25
|
03 | (System) | New version available: draft-ietf-dnsext-rfc2671bis-edns0-03.txt |
2009-07-28
|
02 | (System) | New version available: draft-ietf-dnsext-rfc2671bis-edns0-02.txt |
2008-03-18
|
01 | (System) | New version available: draft-ietf-dnsext-rfc2671bis-edns0-01.txt |
2007-12-27
|
00 | (System) | New version available: draft-ietf-dnsext-rfc2671bis-edns0-00.txt |