Re: [Last-Call] Tsvart last call review of draft-ietf-6man-grand-04

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@ietf.org> 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@ietf.org 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@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call

-- 
SY, Jen Linkova aka Furry