DHCPv6 Vendor-specific Message
draft-ietf-dhc-dhcpv6-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 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
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.
(Alexey Melnikov; former steering group member) 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.
(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.
(Robert Sparks; former steering group member) 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.
(Russ Housley; former steering group member) 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.
(Ralph Droms; former steering group member) Yes
(Dan Romascanu; former steering group member) No Objection
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.
(Jari Arkko; former steering group member) No Objection
See my comment in the DHCPv4 companion document.
(Magnus Westerlund; former steering group member) No Objection
(Pasi Eronen; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
(Tim Polk; former steering group member) No Objection
I support Adrian and Alexey's discuss positions.
(Ron Bonica; former steering group member) Abstain