Hi Michael, Thank you for the review and comments. You made very good points, the -05 version will have the text changed accordingly. On Wed, Jun 9, 2021 at 12:42 AM Michael Scharf via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Michael Scharf > Review result: Ready with Nits > > This document has been reviewed as part of the transport area review team'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 and WG to allow them to address any issues raised and also to the IETF > discussion list for information. > > When done at the time of IETF Last Call, the authors should consider this > review as part of the last-call comments they receive. Please always CC > tsv-art@xxxxxxxx if you reply to or forward this review. > > This update to the IPv6 Neighbor Discovery does not directly affect Internet > transport protocols. There are no apparent TSV issues that would prevent > progressing the document. > > Nonetheless, I found some small nits: > > * Section 1: The last sentence "It can cause user-visible packet loss and > performance degradation." may be a bit misleading. If a reliable transport > protocol is used, packet loss is typically _not_ directly visible to the user. > In many cases it may just result in user-visible performance degradation such > as delays (e.g., delays of the TCP connection setup). A better wording would be: > > "It can cause packet loss and performance degradation that can be > user-visible." > > * Section 3: I am not sure if BCP 14 capital latter language is needed in > Section 3. At least, use of BCP 14 terms should be consistent inside Section 3. > I find it confusing that capital letters are used in some requrirements but not > in all. An easy fix would be not to use BCP 14 language in this section. > > * Section 8.7: The list of drawbacks may not be comprehensive. For instance, I > suspect that reducing the probe retransmit interval could increase the risk of > congesting a link that is already under load. If so, this would be another > reason not to use the mechism discussed in Section 8.7. > > > -- > last-call mailing list > last-call@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call -- SY, Jen Linkova aka Furry -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
