DHCPv6 Vendor-specific Message
draft-ietf-dhc-dhcpv6-vendor-message-01
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-10-14
|
01 | (System) | Notify list changed from dhc-chairs@ietf.org, draft-ietf-dhc-dhcpv6-vendor-message@ietf.org to (None) |
2010-10-24
|
01 | (System) | Document has expired |
2010-10-23
|
01 | Ralph Droms | State changed to Dead::AD Followup from IESG Evaluation::AD Followup by Ralph Droms |
2010-02-20
|
01 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Tobias Gondrom. |
2010-02-19
|
01 | (System) | Removed from agenda for telechat - 2010-02-18 |
2010-02-18
|
01 | Cindy Morgan | State Changes to IESG Evaluation::AD Followup from Waiting for AD Go-Ahead by Cindy Morgan |
2010-02-18
|
01 | Cullen Jennings | [Ballot discuss] I view this document as effectively making it so no review is needed of new DHCP options. I don't think theWG charter allows … [Ballot discuss] I view this document as effectively making it so no review is needed of new DHCP options. I don't think theWG charter allows this. I also view this as very bad thing given the goals of the IETF and would likely move to abstain. If the WG wanted to move to something that allowed a large code space with a easier review process, I would have no objects to that. |
2010-02-18
|
01 | Cullen Jennings | [Ballot Position Update] New position, Discuss, has been recorded by Cullen Jennings |
2010-02-18
|
01 | Ron Bonica | [Ballot Position Update] New position, Abstain, has been recorded by Ron Bonica |
2010-02-18
|
01 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2010-02-18
|
01 | Jari Arkko | [Ballot comment] See my comment in the DHCPv4 companion document. |
2010-02-18
|
01 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko |
2010-02-18
|
01 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
2010-02-17
|
01 | Robert Sparks | [Ballot discuss] (This is a copy of the same comment made for the dhcpv4-vendor-message document) Should this document contain (or point to) more guidance that … [Ballot discuss] (This is a copy of the same comment made for the dhcpv4-vendor-message document) Should this document contain (or point to) more guidance that would encourage the use and development of interoperable DHCP options? It is currently missing any pressure to discourage the replication of already standardized behavior and encourage bringing common functionality through the standards process. |
2010-02-17
|
01 | Robert Sparks | [Ballot Position Update] New position, Discuss, has been recorded by Robert Sparks |
2010-02-17
|
01 | Dan Romascanu | [Ballot comment] 1. I support Adrian's DISCUSS that mentioning experimental purposes is not appropriate. 2. I support Russ's DISCUSS that 'MUST use good networking practices' … [Ballot comment] 1. I support Adrian's DISCUSS that mentioning experimental purposes is not appropriate. 2. I support Russ's DISCUSS that 'MUST use good networking practices' includes a too vague construct ('good networking practices') for a mandatory to implement statement. 3. The IANA considerations section should note that the the document makes use of the IANA enterprise id numbers registry. While this is mentioned previously in the document (in Section 4) it is not noted in the IANA considerations section. While no specific action item is requested of IANA it is a consideration. |
2010-02-17
|
01 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2010-02-17
|
01 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2010-02-16
|
01 | Tim Polk | [Ballot comment] I support Adrian and Alexey's discuss positions. |
2010-02-16
|
01 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk |
2010-02-16
|
01 | Amanda Baber | IANA comments: Upon approval of this document, the IANA will make the following assignment in the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry, located … IANA comments: Upon approval of this document, the IANA will make the following assignment in the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry, located at http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml in the subregistry "DHCP Message types" Value Description Reference ----- --------------- ---------------------------------- 254 VENDOR-SPECIFIC [RFC-dhc-dhcpv4-vendor-message-01] |
2010-02-16
|
01 | Lars Eggert | [Ballot Position Update] New position, Abstain, has been recorded by Lars Eggert |
2010-02-16
|
01 | Pasi Eronen | [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen |
2010-02-14
|
01 | Russ Housley | [Ballot discuss] s3, para 3: This paragraph contains weasel words about 'good networking practices' that 'MUST be used'. This is untestable as it … [Ballot discuss] s3, para 3: This paragraph contains weasel words about 'good networking practices' that 'MUST be used'. This is untestable as it stands. Is this anything more than dealing with non-replies, not flooding the network with repeats, and not hanging up if the partner never does answer? Also, servers or clients that do not (yet) implement this capability do not have a defined behaviour when receiving this new type of message. There is a assumption that they will be silently dropped without causing any problems. |
2010-02-14
|
01 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley |
2010-02-13
|
01 | Adrian Farrel | [Ballot comment] I also support Alexey's Discuss on this document. This work should not attempt to define procedures for non-supporting nodes, but must reference the … [Ballot comment] I also support Alexey's Discuss on this document. This work should not attempt to define procedures for non-supporting nodes, but must reference the base spec. |
2010-02-13
|
01 | Adrian Farrel | [Ballot discuss] My Discuss is identical to the issue I raised for draft-ietf-dhc-dhcpv4-vendor-message. I think adding a vendor-specific message to DHCP is a fine thing … [Ballot discuss] My Discuss is identical to the issue I raised for draft-ietf-dhc-dhcpv4-vendor-message. I think adding a vendor-specific message to DHCP is a fine thing to do. However, I have a relatively minor issue with the current text. I don't think it is correct to suggest that a purpose of this is experimentation. Experiments are not supposed to escape into the wider Net and an experimental message would be treated differently from a vendor-specific message. While it is true that a vendor may choose to experiment under their enterprise number, the fact that it is an experiment is actually hidden from the world, and we don't consider listing all of the other uses to which this message might be put. I would be happy to see the reference to experimentation removed from the Abstract and the Introduction. |
2010-02-13
|
01 | Adrian Farrel | [Ballot Position Update] New position, Discuss, has been recorded by Adrian Farrel |
2010-02-13
|
01 | Alexey Melnikov | [Ballot discuss] This is similar to one of the DISCUSS issues on draft-ietf-dhc-dhcpv4-vendor-message-01.txt. (Note that other issues I raised against draft-ietf-dhc-dhcpv4-vendor-message-01.txt are addressed in this … [Ballot discuss] This is similar to one of the DISCUSS issues on draft-ietf-dhc-dhcpv4-vendor-message-01.txt. (Note that other issues I raised against draft-ietf-dhc-dhcpv4-vendor-message-01.txt are addressed in this document). 1) In Section 3 Clients and servers MAY chose to support this message; those that do not, MUST discard the message. Relay agents SHOULD relay these messages as they would other DHCPv6 messages unless the relay agent understands the specific message and knows that the message was directed at it. This sounds as if this document is trying to put requirements on implementations that are not compliant with this document. Is this section just describes something which follows from DHCPv6 extensibility rules? If yes, then rewording this paragraph to say "According to [ref] ..." would address my issue. |
2010-02-13
|
01 | Alexey Melnikov | [Ballot Position Update] New position, Discuss, has been recorded by Alexey Melnikov |
2010-02-05
|
01 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Tobias Gondrom |
2010-02-05
|
01 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Tobias Gondrom |
2010-02-04
|
01 | Ralph Droms | Placed on agenda for telechat - 2010-02-18 by Ralph Droms |
2010-02-03
|
01 | Amy Vezza | Last call sent |
2010-02-03
|
01 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2010-02-03
|
01 | Ralph Droms | [Ballot Position Update] New position, Yes, has been recorded for Ralph Droms |
2010-02-03
|
01 | Ralph Droms | Ballot has been issued by Ralph Droms |
2010-02-03
|
01 | Ralph Droms | Created "Approve" ballot |
2010-02-03
|
01 | Ralph Droms | Last Call was requested by Ralph Droms |
2010-02-03
|
01 | Ralph Droms | State Changes to Last Call Requested from AD Evaluation by Ralph Droms |
2010-02-03
|
01 | Ralph Droms | Last Call was requested by Ralph Droms |
2010-02-03
|
01 | (System) | Ballot writeup text was added |
2010-02-03
|
01 | (System) | Last call text was added |
2010-02-03
|
01 | (System) | Ballot approval text was added |
2010-02-03
|
01 | Ralph Droms | State Changes to AD Evaluation from Publication Requested by Ralph Droms |
2010-02-03
|
01 | Ralph Droms | [Note]: 'Ted Lemon (mellon@nominum.com) is the document shepherd.' added by Ralph Droms |
2010-01-28
|
01 | Cindy Morgan | [Note]: 'Ted Lemon (mellon@nominum.com) is the document shepherd.' added by Cindy Morgan |
2010-01-28
|
01 | 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 shepherd for this document. I have personally reviewed the document, and I think it is ready to forward to the IESG 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? The document has been carefully reviewed by several experienced DHCP implementors. I have no concerns that the document has not had adequate review. (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? The document is a pretty simple extension, so I don't have any such concerns. (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. The primary concern that was raised about this document is that it creates an escape mechanism whereby a vendor can add functionality to DHCP without review by the DHC working group. However, this is already possible; vendors have in the past simply allocated message codes from the reserved space and used them without consulting the working group. By providing a clear mechanism for creating experimental messages, we hope that vendors will stop allocating reserved codes when working on experimental DHCP extensions. (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? Most of the more active members of the working group have reviewed the document and support its advancement. It's been explained in working group meetings, so I think anyone who is interested has a pretty clear understanding of what it does. (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, in fact I was the only person who objected to the document, and the reasoning I've given above under (1.d) is what convinced me to agree it needed to be done. (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. The document was last submitted prior to the latest update to the IETF Trust Provisions as of 28 Dec 2009, so it contains boilerplate from a previous version. My intention is to ask the author to correct this after IESG review, on the assumption that other document changes will also be required. (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]. This document only makes reference to RFCs and to the IANA. (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 seem correct to me. (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? The document doesn't contain any 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 document provides a standard mechanism for defining experimental messages in the DHCPv6 protocol. Working Group Summary Standard DHCPv6 message codes are allocated by the IANA and require working group approval. The current IANA procedure for message type code allocation requires that a document pass a working group last call before a code can be allocated. Current practice among implementors of new or experimental DHCP messages is to simply bypass the IANA process and allocate a code. Because this document provides a clear alternative, the working group hopes that no new DHCPv6 message type codes will be pirated by experimenters. One concern that was raised was that by providing an unreviewed mechanism for allocating new DHCP message types, implementors would have less of an incentive for consulting the working group when developing new DHCP messages. However, our experience has been that the people least likely to consult the working group are the same people who would feel free to simply make up a number and not tell anyone until a collision arises. Hence, this mechanism is seen even by those who raised this objection as the lesser of two evils. Document Quality The document has already been used for an implementation of an experimental authentication protocol at Cisco; the protocol in question is under consideration for standardization by the DHC working group. Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are .' The document shepherd is Ted Lemon . I believe the responsible A-D is Ralph Droms. |
2010-01-28
|
01 | Cindy Morgan | Draft Added by Cindy Morgan in state Publication Requested |
2009-08-04
|
01 | (System) | New version available: draft-ietf-dhc-dhcpv6-vendor-message-01.txt |
2009-01-22
|
00 | (System) | New version available: draft-ietf-dhc-dhcpv6-vendor-message-00.txt |