[Ballot comment]
I assume that instead of normative reference:
  [3]  IANA, "Private Enterprise Numbers",
        <http://www.iana.org/assignments/enterprise-numbers.html>.
they actually meanL
  [3]  IANA, "Private Enterprise Numbers",
        <http://www.iana.org/assignments/enterprise-numbers>.
that is without the suffix: .html

[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?

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

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?

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.