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 protected]
https://www.ietf.org/mailman/listinfo/gen-art
