Skip to main content

Last Call Review of draft-ietf-6man-grand-04
review-ietf-6man-grand-04-tsvart-lc-scharf-2021-06-08-00

Request Review of draft-ietf-6man-grand
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2021-06-18
Requested 2021-06-04
Authors Jen Linkova
I-D last updated 2021-06-08
Completed reviews Tsvart Last Call review of -04 by Michael Scharf (diff)
Iotdir Last Call review of -04 by Carles Gomez (diff)
Secdir Last Call review of -04 by Scott G. Kelly (diff)
Genart Last Call review of -04 by Dan Romascanu (diff)
Assignment Reviewer Michael Scharf
State Completed
Request Last Call review on draft-ietf-6man-grand by Transport Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/tsv-art/ZUJ3MUQc_EKdYH1hsNFcea1s6dM
Reviewed revision 04 (document currently at 07)
Result Ready w/nits
Completed 2021-06-08
review-ietf-6man-grand-04-tsvart-lc-scharf-2021-06-08-00
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.