DHCPv4 Vendor-specific Message
draft-ietf-dhc-dhcpv4-vendor-message-01
Discuss
Yes
No Objection
Abstain
No Record
Summary: Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.
Lars Eggert (was No Objection, Discuss) Abstain
Alvaro Retana No Record
Andrew Alston No Record
Erik Kline No Record
Francesca Palombini No Record
John Scudder No Record
Martin Duke No Record
Murray Kucherawy No Record
Paul Wouters No Record
Robert Wilton No Record
Roman Danyliw No Record
Warren Kumari No Record
Zaheduzzaman Sarker No Record
Éric Vyncke No Record
(Adrian Farrel; former steering group member) 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.
(Alexey Melnikov; former steering group member) 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).
(Cullen Jennings; former steering group member) 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.
(Dan Romascanu; former steering group member) Discuss
Section 4 - the document specify that option-len and subopt-len are expressed in octets
(Robert Sparks; former steering group member) 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.
(Russ Housley; former steering group member) 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.
(Ralph Droms; former steering group member) Yes
(Jari Arkko; former steering group member) No Objection
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.
(Magnus Westerlund; former steering group member) No Objection
(Pasi Eronen; former steering group member) (was Discuss) No Objection
(Ross Callon; former steering group member) No Objection
(Tim Polk; former steering group member) No Objection
(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?
(Ron Bonica; former steering group member) Abstain