Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)
draft-ietf-dhc-vendor-03
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2004-07-12
|
03 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2004-07-12
|
03 | Amy Vezza | IESG state changed to Approved-announcement sent |
2004-07-12
|
03 | Amy Vezza | IESG has approved the document |
2004-07-12
|
03 | Amy Vezza | Closed "Approve" ballot |
2004-07-09
|
03 | (System) | Removed from agenda for telechat - 2004-07-08 |
2004-07-08
|
03 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation by Amy Vezza |
2004-07-08
|
03 | Bert Wijnen | [Ballot Position Update] Position for Bert Wijnen has been changed to No Objection from Undefined by Bert Wijnen |
2004-07-08
|
03 | Bert Wijnen | [Ballot comment] I assume that instead of normative reference: [3] IANA, "Private Enterprise Numbers", . they actually meanL [3] … [Ballot comment] I assume that instead of normative reference: [3] IANA, "Private Enterprise Numbers", . they actually meanL [3] IANA, "Private Enterprise Numbers", . that is without the suffix: .html |
2004-07-08
|
03 | Bert Wijnen | [Ballot Position Update] New position, Undefined, has been recorded for Bert Wijnen by Bert Wijnen |
2004-07-08
|
03 | Scott Hollenbeck | [Ballot Position Update] Position for Scott Hollenbeck has been changed to No Objection from Undefined by Scott Hollenbeck |
2004-07-08
|
03 | Scott Hollenbeck | [Ballot comment] It would be helpful if the numbering system base for the option values were specified. Are they supposed to be octal, decimal, or … [Ballot comment] It would be helpful if the numbering system base for the option values were specified. Are they supposed to be octal, decimal, or hexadecimal? |
2004-07-08
|
03 | Scott Hollenbeck | [Ballot Position Update] New position, Undefined, has been recorded for Scott Hollenbeck by Scott Hollenbeck |
2004-07-08
|
03 | Alex Zinin | [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin |
2004-07-08
|
03 | Allison Mankin | [Ballot Position Update] Position for Allison Mankin has been changed to No Objection from Undefined by Allison Mankin |
2004-07-08
|
03 | Allison Mankin | [Ballot comment] This needs to have a normative reference to RFC 2939. I don't require this to be written, but one could write a … [Ballot comment] This needs to have a normative reference to RFC 2939. I don't require this to be written, but one could write a stronger security consideration, something like that there's more need for the development of the mechanisms other than 3118 with this improved vendor extension mechanism. |
2004-07-08
|
03 | Allison Mankin | [Ballot Position Update] New position, Undefined, has been recorded for Allison Mankin by Allison Mankin |
2004-07-08
|
03 | Bill Fenner | [Ballot Position Update] New position, Yes, has been recorded for Bill Fenner by Bill Fenner |
2004-07-06
|
03 | Steven Bellovin | [Ballot Position Update] New position, No Objection, has been recorded for Steve Bellovin by Steve Bellovin |
2004-07-06
|
03 | Ted Hardie | [Ballot Position Update] New position, No Objection, has been recorded for Ted Hardie by Ted Hardie |
2004-07-04
|
03 | Margaret Cullen | [Ballot Position Update] New position, Yes, has been recorded for Margaret Wasserman |
2004-07-04
|
03 | Margaret Cullen | Ballot has been issued by Margaret Wasserman |
2004-07-04
|
03 | Margaret Cullen | Created "Approve" ballot |
2004-06-30
|
03 | Margaret Cullen | State Changes to IESG Evaluation from In Last Call by Margaret Wasserman |
2004-06-30
|
03 | Margaret Cullen | Placed on agenda for telechat - 2004-07-08 by Margaret Wasserman |
2004-06-24
|
03 | Amy Vezza | Last call sent |
2004-06-24
|
03 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2004-06-24
|
03 | Margaret Cullen | State Changes to Last Call Requested from AD Evaluation::Revised ID Needed by Margaret Wasserman |
2004-06-24
|
03 | Margaret Cullen | Last Call was requested by Margaret Wasserman |
2004-06-24
|
03 | (System) | Ballot writeup text was added |
2004-06-24
|
03 | (System) | Last call text was added |
2004-06-24
|
03 | (System) | Ballot approval text was added |
2004-06-24
|
03 | Margaret Cullen | State Changes to AD Evaluation::Revised ID Needed from Publication Requested by Margaret Wasserman |
2004-06-24
|
03 | Margaret Cullen | The following AD Review comments were sent to the author: Hi Josh, I just finished my review of draft-ietf-dhc-vendor-02.txt. In general, I think that these … The following AD Review comments were sent to the author: Hi Josh, I just finished my review of draft-ietf-dhc-vendor-02.txt. In general, I think that these options are a good idea and that this is a good document. However, I do have a few questions (included below) that I think should be resolved before sending this document to IETF Last Call. I think that these questions are editorial in nature, so I am just sending them to you. If it turns out that there are any substantive issues here, we can take that discussion to the DHCP WG. I've tried to include enough document text that you can understand the context. My comments are marked with ">>". Thoughts? Margaret --- This document defines two new options, modeled on the IPv6 options for vendor class and vendor-specific information defined in RFC 3315 [6], which contain Enterprise Numbers to remove ambiguity about the interpretation of their contents. If desired, these new options can be used in addition to the current vendor class and vendor information options, whose definition is unaffected by this document. >> It would probably be good to include a reference for "Enterprise Number" >> and some indication of where one would go to get one... Maybe >> "IANA-assigned Enterprise Number [ref]". The format of the V-I Vendor Class option is: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-code | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | enterprise-number1 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data-len1 | | +-+-+-+-+-+-+-+-+ | / vendor-class-data1 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- | enterprise-number2 | ^ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | data-len2 | | optional +-+-+-+-+-+-+-+-+ | | / vendor-class-data2 / | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ... ~ V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- option-code OPTION_V-I_VENDOR_CLASS (to be assigned by IANA) option-len 5 + length of vendor class data field >> Shouldn't this be the length of the entire option? And where does the >> 5 come from? Are you intending some distinction between the use of >> "vendor class data field" here and "vendor-class-data field" below? enterprise-numberN The vendor's 32-bit Enterprise Number as registered with IANA [3] data-lenN Length of vendor-class-data field vendor-class-dataN Details of the hardware configuration of the host on which the client is running, or of [...] The format of the V-I Vendor-specific Information option is: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-code | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | enterprise-number1 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data-len1 | | +-+-+-+-+-+-+-+-+ option-data1 | / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- | enterprise-number2 | ^ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | data-len2 | | optional +-+-+-+-+-+-+-+-+ option-data2 | | / / | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ... ~ V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- option-code OPTION_V-I_VENDOR_OPTS (to be assigned by IANA) option-len 5 + length of option-data field >> Same questions as above... Where does the 5 come from? And shouldn't >> this be the length of the entire option, not just 5 + one option-data >> field? |
2004-06-23
|
03 | (System) | New version available: draft-ietf-dhc-vendor-03.txt |
2004-06-03
|
03 | Margaret Cullen | 1) Have the chairs personally reviewed this version of the ID and do they believe this ID is sufficiently baked to forward to the … 1) Have the chairs personally reviewed this version of the ID and do they believe this ID is sufficiently baked to forward to the IESG for publication? Yes. 2) Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? Yes and no. 3) Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? No. The technology in this draft is retrofitted to DHCPv4 from DHCPv6. 4) Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or whether there really is a need for it, etc., but at the same time these issues have been discussed in the WG and the WG has indicated it wishes to advance the document anyway. No. 5) 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? Basically strong concurrence of a few individuals, with no objections from the Silent Majority. 6) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize what are they upset about. No. 7) Have the chairs verified that the document adheres to _all_ of the ID nits? (see http://www.ietf.org/ID-nits.html). Yes. 8) For Standards Track and BCP documents, the IESG approval announcement includes a writeup section with the following sections: - Technical Summary The DHCP options for Vendor Class and Vendor-Specific Information can be limiting or ambiguous when a DHCP client represents multiple vendors. This document defines two new options, modeled on the IPv6 options for vendor class and vendor-specific information, which contain Enterprise Numbers to remove ambiguity. - Working Group Summary The WG agrees that these options are a useful extension to DHCPv4. The corresponding options in DHCPv6 were based on deployment experience with the vendor type (option 60) and vendor-specific information (option 43) options. - Protocol Quality The protocol in this standard is not currently implemented. We expect implementation in new DHCP clients, especially in dedicated devices like DOCSIS modems and RFID readers, which may require class and option information based on both the type of device and the vendor of the device. We don't have any specific information about implementation plans. As these options are retrofitted from the DHCPv6 spec, there was no special review of the options. |
2004-06-03
|
03 | Margaret Cullen | Draft Added by Margaret Wasserman |
2004-05-18
|
02 | (System) | New version available: draft-ietf-dhc-vendor-02.txt |
2004-02-05
|
01 | (System) | New version available: draft-ietf-dhc-vendor-01.txt |
2003-09-30
|
00 | (System) | New version available: draft-ietf-dhc-vendor-00.txt |