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 tsv-art@ietf.org 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.