Prefix Exclude Option for DHCPv6-based Prefix Delegation
RFC 6603
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2020-01-21
|
04 | (System) | Received changes through RFC Editor sync (added Verified Errata tag) |
|
2015-12-31
|
04 | Jean Mahoney | Closed request for Last Call review by GENART with state 'No Response' |
|
2015-10-14
|
04 | (System) | Notify list changed from dhc-chairs@ietf.org, draft-ietf-dhc-pd-exclude@ietf.org to (None) |
|
2012-05-16
|
04 | (System) | RFC published |
|
2012-02-29
|
04 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
|
2012-02-29
|
04 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
|
2012-02-28
|
04 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
|
2012-02-22
|
04 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent. |
|
2012-02-22
|
04 | (System) | IANA Action state changed to In Progress |
|
2012-02-21
|
04 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2012-02-21
|
04 | Amy Vezza | IESG has approved the document |
|
2012-02-21
|
04 | Amy Vezza | Closed "Approve" ballot |
|
2012-02-21
|
04 | Amy Vezza | Approval announcement text regenerated |
|
2012-02-21
|
04 | Amy Vezza | Ballot writeup text changed |
|
2012-02-16
|
04 | Cindy Morgan | Removed from agenda for telechat |
|
2012-02-16
|
04 | Cindy Morgan | State changed to Approved-announcement to be sent from IESG Evaluation. |
|
2012-02-16
|
04 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded |
|
2012-02-16
|
04 | Jari Arkko | [Ballot comment] Thanks for writing this draft, it is very important addition to DHCPv6. |
|
2012-02-16
|
04 | Jari Arkko | [Ballot comment] Thanks for writing this draft, it is very important addition to DHCPv6. Isn't this code wrong: uint16_t d = (c/8)+1; // … [Ballot comment] Thanks for writing this draft, it is very important addition to DHCPv6. Isn't this code wrong: uint16_t d = (c/8)+1; // the IPv6_subnet_ID_length in octets as you'd get d = 2 for c = 8, for instance. You'd want something like: uint8_t d = i/8 + (i%8>0); Or am I missing something obvious? |
|
2012-02-16
|
04 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded |
|
2012-02-15
|
04 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Magnus Nystrom. |
|
2012-02-15
|
04 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded |
|
2012-02-15
|
04 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded |
|
2012-02-14
|
04 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded |
|
2012-02-14
|
04 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded |
|
2012-02-14
|
04 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded |
|
2012-02-14
|
04 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded |
|
2012-02-14
|
04 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded |
|
2012-02-13
|
04 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded |
|
2012-02-13
|
04 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded |
|
2012-02-13
|
04 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded |
|
2012-02-09
|
04 | Ralph Droms | State changed to IESG Evaluation from Waiting for AD Go-Ahead. |
|
2012-02-09
|
04 | Ralph Droms | Placed on agenda for telechat - 2012-02-16 |
|
2012-02-09
|
04 | Ralph Droms | [Ballot Position Update] New position, Yes, has been recorded for Ralph Droms |
|
2012-02-09
|
04 | Ralph Droms | Ballot has been issued |
|
2012-02-09
|
04 | Ralph Droms | Created "Approve" ballot |
|
2012-02-07
|
04 | Amanda Baber | IANA understands that, upon approval of this document, there is a single IANA action which needs to be completed. In the DHCP Option Codes in … IANA understands that, upon approval of this document, there is a single IANA action which needs to be completed. In the DHCP Option Codes in the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) registry located at: www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml a new option code is to be registered as follows: Value: [ tbd ] Description: OPTION_PD_EXCLUDE Reference: [ RFC-to-be ] |
|
2012-02-07
|
04 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
|
2012-01-27
|
04 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Magnus Nystrom |
|
2012-01-27
|
04 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Magnus Nystrom |
|
2012-01-26
|
04 | Jean Mahoney | Request for Last Call review by GENART is assigned to Pete McCann |
|
2012-01-26
|
04 | Jean Mahoney | Request for Last Call review by GENART is assigned to Pete McCann |
|
2012-01-24
|
04 | Amy Vezza | Last call sent |
|
2012-01-24
|
04 | Amy Vezza | State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: … State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: <dhcwg@ietf.org> Reply-To: ietf@ietf.org Subject: Last Call: <draft-ietf-dhc-pd-exclude-04.txt> (Prefix Exclude Option for DHCPv6-based Prefix Delegation) to Proposed Standard The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'Prefix Exclude Option for DHCPv6-based Prefix Delegation' <draft-ietf-dhc-pd-exclude-04.txt> 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-07. 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 This specification defines an optional mechanism to allow exclusion of one specific prefix from a delegated prefix set when using DHCPv6- based prefix delegation. The new mechanism updates RFC 3633. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dhc-pd-exclude/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dhc-pd-exclude/ If approved, this document will update RFC 3633. No IPR declarations have been submitted directly on this I-D. |
|
2012-01-24
|
04 | Ralph Droms | Last Call was requested |
|
2012-01-24
|
04 | Ralph Droms | State changed to Last Call Requested from Last Call Requested. |
|
2012-01-24
|
04 | Ralph Droms | Last Call text changed |
|
2012-01-24
|
04 | Ralph Droms | Last Call was requested |
|
2012-01-24
|
04 | Ralph Droms | State changed to Last Call Requested from AD Evaluation. |
|
2012-01-24
|
04 | Ralph Droms | Last Call text changed |
|
2012-01-24
|
04 | (System) | Ballot writeup text was added |
|
2012-01-24
|
04 | (System) | Last call text was added |
|
2012-01-24
|
04 | (System) | Ballot approval text was added |
|
2012-01-24
|
04 | Ralph Droms | Ballot writeup text changed |
|
2012-01-24
|
04 | Ralph Droms | Ballot writeup text changed |
|
2012-01-23
|
04 | Ralph Droms | State changed to AD Evaluation from Publication Requested. |
|
2011-12-20
|
04 | 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? I (Ted Lemon) am the document shepherd. I have reviewed the document, and believe it 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 The document has had thorough review from several members of the working group, and is quite mature. The described solution has been also adopted, and referenced, by 3GPP in Release-10 version of 23.401” Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 10)”, latest (10.5.0) being here: http://www.3gpp.org/ftp/Specs/archive/23_series/ 23.401/23401-a50.zip (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? I am quite happy with the degree of review that this document has had, although of course more review is always welcomed. (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. I think this document is definitely needed, and is important work. I was initially uncomfortable with the way the algorithm for computing the IPv6 subnet ID field was done. However, I walked through the algorithm with pencil and paper, and after doing so had a clear understanding of how it works, so I think actually it's a pretty good way to specify it. There was debate in the working group as to whether to make the representation compact, as is done in the current document, or to simplify the algorithm at the expense of using extra space. The consensus of the working group was to be space-efficient, and I think this will produce an acceptable outcome. I don't think it's possible to implement this without a clear understanding of the algorithm: a half- assed attempt at implementation would immediately and obviously fail to interoperate. No IPR disclosures have been made, and I am not aware of any that are pending. Teemu also says there are no IPR claims. (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 is substantial consensus in the working group to publish the document. There was some debate early on as to whether it was necessary, but ultimately no substantive objections were raised, and the consensus to advance the document was broad after the working group review was complete. (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.) Nothing of this sort has been expressed in any venue that I'm aware of. (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? The document passes idnits. (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 have been split. There are no downward references. (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 considersations section seems clear to me, although I would have liked it if the language were a bit more imperative. (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? No such language exists in the text. As stated earlier, I walked through the C pseudocode on paper to make sure it works, and it does. (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 specification defines an optional mechanism to allow exclusion of one specific prefix from a delegated prefix set when using DHCPv6- based prefix delegation. The new mechanism updates RFC 3633. Working Group Summary This document received a thorough review by the WG. Many comments were made, and several revisions done. The process was amicable and seems to have satisfied all participants. 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? The protocol is required by the latest 3GPP GPRS specification, but the authors are not aware of any specific implementations yet. We would expect to see these implementations appearing in cellular data devices that do IPv6 tethering, which is a relatively new sort of application. |
|
2011-12-20
|
04 | Cindy Morgan | Draft added in state Publication Requested |
|
2011-12-20
|
04 | Cindy Morgan | [Note]: 'Ted Lemon (ted.lemon@nominum.com) is the document shepherd.' added |
|
2011-12-19
|
04 | (System) | New version available: draft-ietf-dhc-pd-exclude-04.txt |
|
2011-08-05
|
03 | (System) | New version available: draft-ietf-dhc-pd-exclude-03.txt |
|
2011-06-20
|
02 | (System) | New version available: draft-ietf-dhc-pd-exclude-02.txt |
|
2011-01-11
|
01 | (System) | New version available: draft-ietf-dhc-pd-exclude-01.txt |
|
2010-10-08
|
00 | (System) | New version available: draft-ietf-dhc-pd-exclude-00.txt |