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

Hi Allison,

thanks for this very good review! This came in after Spencer and I have already put in our position but I have notified Suresh (the responsible AD for this doc) and he will make sure these points get addressed!

Mirja

> Am 24.01.2018 um 23:48 schrieb Allison Mankin <allison.mankin@gmail.com>:
> 
> 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 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.
> 
> _______________________________________________
> Tsv-art mailing list
> Tsv-art@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art