[dhcwg] Tsvart Last Call/telechat review of draft-ietf-dhc-rfc3315bis-10

[Allison Mankin <[e-mail]>]

Reviewer: Allison Mankin
Reviewer Result: Ready with Issues

I've reviewed this document as part of TSV-ART's ongoing effort to review
key
IETF documents. These comments were written primarily for the transport area
directors, but are copied to the document's authors for their information
and
to allow them to address any issues raised.  When done at the time of IETF
Last
Call, the authors should consider this review together with any other
last-call
comments they receive. Please always CC [e-mail] if you reply to or
forward this review.

The draft brings together and updates multiple RFCs in order to provide a
cleaned-up version of the DHCPv6 specification.

It is good to see that this Bis document for DHCPv6 has done some new work
on congestion control and towards packet storm controls.  This is noted in
items 12 of Appendix A (the summary of changes) and the sections on Rate
Limiting (14.1) and Reliability (15) are basically in good shape, which is
why the summary is Ready with issues.

The following  transport-related comments should be considered for fixing
before publication

1. In Section 5, which defines that the transport is UDP, add a normative
reference to BCP 145, UDP Usage Guidelines.

2. There are several small issues about retransmissions:

a) there's a transmit parameters table 7.6 and it would be good for this to
reference that these parameters are also controlled by the RND factor
parameter and the backoffs in section 14.1

b) The REC_TIMEOUT parameter in the table in section 7.6 is in seconds, but
it is described as milliseconds in section 18.3

c) does the rate-limit per device per interface  (a MUST in Section 14.1)
explicltly include retransmissions?  This should probably be stated earlier
on in the section.

3. The following addition to the spec in Section 15 seems likely to cause
excess retransmissions:

  A client is not expected to listen for a response during the entire
   RT period and may turn off listening capabilities after a certain
   time due to power consumption saving or other reasons.  Of course, a
   client MUST listen for a Reconfigure if it has negotiated for its use
   with the server.

If this congestion avoidance is working, then the clients may need to
retransmit mostly in cases where the round-trip time isn't very variable.
So I'd be tempted to say "after a certain time" should be after the initial
round-trip timeout, so as not to have too many near-misses.

Not transport related, but should be fixed:

 In Section 6.5, don't cite both RFC 3041 and RFC 4941 (about IPv6 privacy
addresses), because RFC 4941 obsoletes RFC 30410.

---------------

I expect there are some risks in the space of congestion avoidance when the
up-to-32 transparent relays are in place, and I'd want to see (for future
reference, not requesting a change here) some consideration about this
before this spec moves from PS to Full Standard.


​