[Tsv-art] Tsvart telechat review of draft-ietf-dhc-rfc3315bis-10

[Allison Mankin <[e-mail]>]

Reviewer: Allison Mankin
Review result: Ready with Issues

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.