DHCPv4 Bulk Leasequery
RFC 6926
Yes
No Objection
Note: This ballot was opened for revision 05 and is now closed.
(Ralph Droms; former steering group member) Yes
(Ron Bonica; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
- Strike "DSLAM" from the box in the diagram in section 1, or simply replace it with "DHCP". DSLAM hasn't been defined yet, and it doesn't add anything to the diagram. - Section 5: Only the DHCPBULKLEASEQUERY request is supported over the Bulk Leasequery connection. No other DHCPv4 requests are supported. The Bulk Leasequery connection is not an alternative DHCPv4 communication option for clients seeking other DHCPv4 services. I don't see how that's enforceable (given our lack of Internet Protocol Police), and I'm not sure what it adds. It might be sufficient to say, "The Bulk Leasequery connection was only designed to handle DHCPBULKLEASEQUERY. It is not intended as an alternative DHCPv4 communication option for clients seeking other DHCPv4 services." The above reads like you really wanted to say 'MUST NOT', but couldn't come up with a legitimate case to forbid it. - Like Peter, I'd also like to understand what a "UTF-8 ASCII VPN identifier" is. So long it is a protocol-opaque user-readable identifier, it's no problem. But we Apps guys like to make sure. :-)
(Peter Saint-Andre; former steering group member) No Objection
Please consider adding references for "NTP" and "UTF-8". What is a "UTF-8 ASCII VPN identifier"??
(Robert Sparks; former steering group member) No Objection
In Section 7.7 the requirement "MUST interleave replies" is not clear. It could be read to mean an implementation has to wait to send additional replies to the first query until it has the information it needs to start answering a second (at the extreme, a strict round-robin of the responses). Is the requirement you are really trying to capture "MUST NOT block sending replies on new queries until all replies for the existing query are complete."? Is there a way for a server to say "the response to your query is too big, please ask again for a subset"? Consider adding a discussion to the document about what a client could do if a server is sending it more data than it is prepared to deal with. RFC5226 defines "IETF Review" as the well-known IANA policy name you are using in section 10. (That RFC notes that this was formerly called "IETF Consensus" in RFC2434.) The document should use that name. RFC5226 is clear on what that policy name means - you invite argument by attempting to restate or clarify the policy in this document. Please consider removing the sentences that start "Basically, this means...".
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) No Objection
I support Stephen's discuss.
(Stephen Farrell; former steering group member) (was Discuss) No Objection
(Stewart Bryant; former steering group member) (was Discuss) No Objection
Thanks for addressing the concern.
(Wesley Eddy; former steering group member) (was Discuss) No Objection