DHCPv4 Bulk Leasequery
draft-ietf-dhc-dhcpv4-bulk-leasequery-07

- 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. :-)

Please consider adding references for "NTP" and "UTF-8".

What is a "UTF-8 ASCII VPN identifier"??

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

I support Stephen's discuss.

Thanks for addressing the concern.