Subject: [Gen-art] Gen-art IETF LC review of draft-ietf-dhc-dhcpv6-bulk-leasequery-0

From: Robert Sparks <[email-masked]>
Date: Fri, 31 Oct 2008 13:31:53 -0500

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

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.

_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art