DHCPv4 Vendor-specific Message
draft-ietf-dhc-dhcpv4-vendor-message-01

[Ballot comment]
In Section 3:

  Applications using these messages MUST NOT assume that all DHCPv4
  clients, relay agents, and servers support them and MUST use good
  networking practices when transmitting and retransmitting these
  messages.

The second MUST almost raises to the level of DISCUSS.
What are the good practices you are talking about and is the following
sentence describes one of them:

  For some applications, it may be appropriate to use
  Vendor-Identifying Vendor Options [RFC3925] in a standard DHCPv4
  exchange to negotiate whether the end-points support the vendor-
  specific message.

? If not, then it is not clear how this MUST can be satisfied.
In that case you need a reference here.

[Ballot discuss]
I generally don't object to this document going forward, however I believe there are some minor points that needs to be addressed/discussed first:

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 DHCPv4 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 DHCPv4
extensibility rules?

2) In Section 4:

  The option-data field MUST be encoded as a sequence of code/length/
  value fields of identical format to the DHCP options field and is
  identical to the option-data field of Vendor-Identifying Vendor
  Options [RFC3925].

This reference looks Normative to me.

  The option codes are defined by the vendor
  identified in the enterprise-number field and are not managed by
  IANA.  Option codes 0 and 255 have no pre-defined interpretation or

Are you talking about subopt-code here?

  format.  Each of the encapsulated options is formatted as follows:

3) In Section 4:

  Clients, relay agents, and/or servers supporting the Vendor Message
  Option MUST support [RFC3396].

This reference looks Normative to me.

4) Taking over Pasi's DISCUSS:

Section 1 says "New message codes are assigned through IETF Standards
Action". According to the registry and RFC 2939, the policy is
currently "IETF Consensus" -- is this just a typo, or is the intent to
change the policy?

Pasi also wrote: According to the WG chair (Ted Lemon, 2010-02-16), the intent was not to change the current policy, so in Section 1, "Standards Action" should be changed to "IETF Consensus" (or perhaps "IETF Review" in 5226 terms).

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

[Ballot comment]
I do not object to this document going forward, but I support the
Robert Sparks Discuss about better guidance (and perhaps even some
mandatory rules).

Furthermore, upleveling a bit, I think we need to ask why we are doing
this document. Is this a companion document to the other proposals that
I am getting for ND option vendor extensions? When I pushed for the
actual reason to do them, the answer ended up being "because there are
some BBF extensions that we need but would probably not go through the
IETF". Some of such usage is useful stuff that simply has to be specified
and some is questionable (think DHCP authentication).

However, vendor specific options/messages are not the only way to do
these extensions. Here's a couple of other options:

- SDO-specific container for their things (and this cannot then easily
  be used by vendor extensions. i'm not sure I *want* vendor extensions
  to DHCP state machine to begin with, though).

- SDO-specific extension for particular functionality that we just
  approve and hold our nose (and then this cannot be used for any
  extensibility later).

- Generic SDO extension

- Generic extension for vendors and SDOs

Your preferences may vary with regards to the best approach here. I'm
personally happiest with the first two options.

In any case, I would like to understand better the real drivers behind
this work.

[Ballot discuss]
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.

[Ballot comment]
(1) I support Adrian's discuss regarding experimentation.

(2) I support Alexey's discuss regarding section 3 imposing requirements on clients that do not
implement this specification.  If that is the intention, shouldn't this specification update 2131?

[Ballot comment]
(1) I support Adrian's discuss regarding experimentation.

(2) I support Alexey's discuss regarding section 3 imposing requirements on clients that do not
implement this specification.  If that is the intention, shouldn't this specification update 2131?

(3) The introductions states "The protocol provides for 256 possible message codes, of which
a small number have been assigned."  Perhaps I am reading the wrong registry, but aren't the
majority of the 256 codes assigned at this point?

IANA comments:

Upon approval of this document, the IANA will do the following:

ACTION 1:

make an assignment in the "DHCP Message Type 53 Values" registry at
http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml

Value Message Type Reference
----- --------------- ----------------------------------
254 VENDOR-SPECIFIC [RFC-dhc-dhcpv4-vendor-message-01]


ACTION 2:

make an assignment in the "BOOTP Vendor Extensions and DHCP Options"
registry at
http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml

Tag Name Data Length Meaning Reference
--- --------------- ----------- --------------------- -
TBD VENDOR-SPECIFIC N OPTION_VENDOR_MESSAGE
[RFC-dhc-dhcpv4-vendor-message-01]

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

[Ballot discuss]
I have reviewed draft-ietf-dhc-dhcpv4-vendor-message-01, and have one
small question that I'd like to discuss before recommending approval
of the document:

Section 1 says "New message codes are assigned through IETF Standards
Action". According to the registry and RFC 2939, the policy is
currently "IETF Consensus" -- is this just a typo, or is the intent to
change the policy?

[Ballot comment]
s4, top of page 5: 'Option codes 0 and 255 have no pre-defined
  interpretation or format':  This comment (duplicated from RFC 3925)
  is confusing to the uninitiated reader.  If I understand correctly,
  this is intended to contrast with the 'basic' options in DHCPv4 where
  options 0 and 255 are 'special' - i.e. no length code.  I suggest
  adding at the beginning of the sentence: 'Unlike option codes in
  DHCPv4 [RFC2131], option codes 0...'.

[Ballot discuss]
Two concerns were raised in the Gen-ART Review by Elwyn Davies
  that need to be addressed:

  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.

  s7 and s4, next to last para: s4 specifies RFC 3396 as 'MUST support'
  This makes RFC 3396 a normative reference, not informative.  Arguably
  the last para of s4 makes RFC 3925 normative as well.

[Ballot comment]
I support Alexey's Discuss wrt mandating the behavior of non-supporting nodes. You cannot do that and must refer back to the standard processing of unknown messages.

In section 4 you have:
      option-len          5 plus the length of the vendor-option-data.
I think this should s/vendor-option-data/option-data/

Section 1 says:
  DHCPv4 [RFC2131] specifies a mechanism for the assignment of
  addresses and configuration information to nodes.  The protocol
  provides for 256 possible message codes, of which a small number are
  assigned ([DHCPv4Params]).  Each of the assigned message codes have
  specific purposes.  New message codes are assigned through IETF
  Standards Action.
If I am not mistaken, the registry and RFC 2939 say "IETF Consensus". I don't think this changes your work, but you need to fix the document.

[Ballot discuss]
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.

[Ballot comment]
I support Alexey's Discuss wrt mandating the behavior of non-supporting nodes. You cannot do that and must refer back to the standard processing of unknown messages.

In section 4 you have:
      option-len          5 plus the length of the vendor-option-data.
I think this should s/vendor-option-data/option-data/

[Ballot discuss]
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.

[Ballot comment]
I support Alexey's Discuss wrt mandating the behavior of non-supporting nodes. You cannot do that and must refer back to the standard processing of unknown messages.

[Ballot comment]
In Section 3:

  Applications using these messages MUST NOT assume that all DHCPv4
  clients, relay agents, and servers support them and MUST use good
  networking practices when transmitting and retransmitting these
  messages.

The second MUST almost raises to the level of DISCUSS.
What are the good practices you are talking about and is the following
sentence describes one of them:

  For some applications, it may be appropriate to use
  Vendor-Identifying Vendor Options [RFC3925] in a standard DHCPv4
  exchange to negotiate whether the end-points support the vendor-
  specific message.

? If not, then it is not clear how this MUST can be satisfied.
In that case you need a reference here.

[Ballot discuss]
I generally don't object to this document going forward, however I believe there are some minor points that needs to be addressed/discussed first:

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 DHCPv4 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 DHCPv4
extensibility rules?

2) In Section 4:

  The option-data field MUST be encoded as a sequence of code/length/
  value fields of identical format to the DHCP options field and is
  identical to the option-data field of Vendor-Identifying Vendor
  Options [RFC3925].

This reference looks Normative to me.

  The option codes are defined by the vendor
  identified in the enterprise-number field and are not managed by
  IANA.  Option codes 0 and 255 have no pre-defined interpretation or

Are you talking about subopt-code here?

  format.  Each of the encapsulated options is formatted as follows:

3) In Section 4:

  Clients, relay agents, and/or servers supporting the Vendor Message
  Option MUST support [RFC3396].

This reference looks Normative to me.

  (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 DHCPv4 protocol.

    Working Group Summary
Standard DHCPv4 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 DHCPv4 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.