Re: [tsvwg] Publication has been requested for draft-ietf-tsvwg-rfc4960-errata-05

[Spencer Dawkins at IETF <[e-mail]>]

Dear Authors,

On Wed, Apr 18, 2018 at 1:50 AM, Gorry Fairhurst <[e-mail]>
wrote:

> Gorry Fairhurst has requested publication of draft-ietf-tsvwg-rfc4960-errata-05
> as Informational on behalf of the TSVWG working group.
>
> Please verify the document's state at https://datatracker.ietf.org/
> doc/draft-ietf-tsvwg-rfc4960-errata/


Thanks for doing this work (and even more so, for being willing to provide
an updated RFC to implementers, at some point in the future).

I've completed AD evaluation for this draft, and have comments, but almost
all of them are requests for clarifications.

I'd like to work through them with you before requesting Last Call. Please
let me know if you have questions.

Thanks!

Spencer

A high-order bit here ...

I'm not sure why this draft isn't standards-track, and I wonder if there's
a reason it doesn't UPDATE RFC 4960, unless that's a side effect of being
an Informational draft that would update a standards-track RFC.

I'm thinking that this draft has achieved WG consensus, and if it's
published after Last Call, it would have IETF consensus, and it's been
reviewed by implementers. We've certainly published Proposed Standards that
didn't measure up to that level of document quality.

I'm not objecting strongly to publishing as Informational, but I am saying
that I expect other ADs to ask that question during IESG Evaluation, and
I'd like to understand the thinking before someone asks …

I note without suggesting a change that if the material in Section 3 was
presented in this order

3.n.1   Description of the Problem


3.n.3.  Solution Description

3.n.2.  Text Changes to the Document

   ---------
   Old text:
   ---------

   ---------
   New text:
   ---------

to allow readers to see the solution description before reading the
detailed text changes, that would likely be easier to parse ...

I'm reading this text from the Abstract

   Because some text is changed several times the last delta in the
   text is the one which should be applied.  In addition to the delta a
   description of the problem and the details of the solution are also
   provided.

as saying that the deltas are cumulative, so you should apply the last
change to specific text, but this text from Section 1

  Note that when reading this document one must use care to assure that
   a field or item is not updated further on within the document.  Each
   section should be applied in sequence to the original [RFC4960] since
   this document is a historical record of the sequential changes that
   have been found necessary at various inter-op events and through
   discussion on the list.

seems to say that you should apply multiple deltas to the same text
sequentially. IIUC, the text actually does provide cumulative text deltas,
so using the phrasing from the Abstract in both places would be helpful to
the reader.

This is a nit, but why is "Inconsistent" capitalized in this text?

  The handling of the 'Path.Max.Retrans' parameter is described in
   Section 8.2 and Section 8.3 of [RFC4960] in an Inconsistent way.

https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-tsvwg-rfc4960-errata-05.txt
reports a few problems with references. I THINK this is a side effect of
updating (for example) [RFC2434] to be [RFC5226], and then updating
[RFC5226] to be [RFC8126]. If this was my draft, I'd put a note to the RFC
Editor that obsoleted RFCs are used in "OLD TEXT" sections, and should have
the obsoleting RFCs in the "NEW TEXT" sections, so multiple reviewers won't
ask you about the IDNIT reporting multiple times.

I'm probably due for an eye exam, but I'm not seeing any difference between

  ---------
   Old text: (Section 1.6)
   ---------

   Transmission Sequence Numbers wrap around when they reach 2**32 - 1.
   That is, the next TSN a DATA chunk MUST use after transmitting TSN =
   2*32 - 1 is TSN = 0.

and

   ---------
   New text: (Section 1.6)
   ---------

   Transmission Sequence Numbers wrap around when they reach 2**32 - 1.
   That is, the next TSN a DATA chunk MUST use after transmitting TSN =
   2**32 - 1 is TSN = 0.

What am I missing?

In this text,

  Move the sample code related to CRC32c computation and its
   explanation from the end of Appendix C to the end of Appendix B.

I'm pretty sure I can figure out what text/code actually moves from
Appendix C to Appendix B, but I am figuring that out myself. Perhaps it
would be clearer if you said something like "all of Appendix C starting
with this sentence to the end of Appendix B".

   The following non-normative sample code is taken from an open-source
   CRC generator [WILLIAMS93], using the "mirroring" technique and
   yielding a lookup table for SCTP CRC32c with 256 entries, each 32
   bits wide.

(If I guessed wrong, that's likely because the fix says "code and its
explanation", which sounds like "everything following the beginning of the
code", but the explanation comes before the code)

If I'm following closely, the errata described as

  Section 7.2.2 of [RFC4960] is unclear about the order of adjustments
   applied to partial_bytes_acked and cwnd in the congestion avoidance
   phase.

is actually clear about the order - assuming that you read left to right,
it's just clearly wrong :-)

At the risk of asking a technical question ;-)

  The counter SHOULD be reset each time a DATA chunk sent to that peer
   endpoint is acknowledged (by the reception of a SACK). When a
   HEARTBEAT ACK is received from the peer endpoint, the counter SHOULD
   also be reset. The receiver of the HEARTBEAT ACK MAY choose not to
   clear the counter if there is outstanding data on the association.
   This allows for handling the possible difference in reachability
   based on DATA chunks and HEARTBEAT chunks.

why is not clearing the counter if there is outstanding data on the
association a good idea? (this was "shall", but is now "SHOULD")

I have a similar (MUST vs. SHOULD) question about

  Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT
   SHOULD clear the error counter of the destination transport address
   to which the HEARTBEAT was sent, and mark the destination transport
   address as active if it is not so marked.

Why would not clearing the error counter be a good idea?

Section 3.21 has multiple occurrences of something like

  o  partial flag - if this returned flag is set to 1, then this
      Receive contains a partial delivery of the whole message.  When
      ^ this "Receive" is capitalized

      this flag is set, the stream id and Stream Sequence Number MUST
      accompany this receive.  When this flag is set to 0, it indicates
                     ^ this "receive" is not capitalized

      that no more deliveries will be received for this Stream Sequence
      Number.

Is that intentional?