Document: draft-ietf-dhc-dhcpv6-bulk-leasequery-04 Reviewer: Robert Sparks Review Date: Oct 31, 2008 IETF LC End Date: Nov 3, 2008 IESG Telechat date: unknown Summary: This draft may have open issues as described in the review Comments: Apologies in advance if I'm tripping over things that are obvious to folks that are deeply involved in the current dhcpv6 work. I have a few high-level questions/observations: 1) The last paragraph of section 4 requires a dhcpv6 server that's listening on UDP or other types of queries to reject a bulk-leasequery with NotAllowed. This assumes the bulk-leasequery message was constructed the way other UDP based dhcp messages are built (specifically, not framed for TCP as defined in this document) and then sent over UDP. This assumption should be explicitly stated in the text. There should also be some discussion of what happens if an implementation frames the request for TCP and then sends it over UDP. This is a common programming mistake in other protocols that can use both transports. Did the working group discuss the tradeoffs of putting this message-size at the front of the request instead of inside the message-type specific space (allowing unmodified servers to reject the request)? 2) There are places in the draft where its unclear if you intending to just use TCP (which I think is the case) or if you are expecting to influence the behavior of TCP. The last sentence of 7.4 is particularly confusing: "If the server detects that the client end has been closed, the server MUST close its end of the connection after it has finished processing any outstanding requests from the client." (Its also not clear why the server would finish processing the outstanding requests that arrived on this connection). 3) The second paragraph of 7.1 talks about restricting connections to "certain clients" but is not explicit about how those clients are identified. Was this discussed? 4) I'd expect the implementer community in this space to be really sharp on UDP security issues. Are these folks as up to speed on such considerations when using TCP (this appears to be the first use of TCP in this protocol suite)? If not, I wonder if there's a richer set of considerations already captured somewhere that this document can point to? Nits: It might help to leave explicit notes the RFCeditor on how to replace the TBDs in 5.2.1/2 based on the IANA actions.