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

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 11 May 2018 15:12:31 -0500

Dear Authors,

On Wed, Apr 18, 2018 at 1:50 AM, Gorry Fairhurst <[email-masked]>
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?

---

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 12 May 2018 08:16:05 +0100

On the document status:

This draft is specifically to catalogue all the changes proposed for the 
SCTP base spec. The authors plan to then implement these changes as a 
textual update to RFC 4960 to realise a new completely clean base 
specification. Once this is done the present ID will exist only as a 
record of what has changed. This process was successfully used for other 
SCTP documents and was the rationale for the present ID requesting 
publication as a Information specification.

This was in part explained in section 1 of the writeup - should it also 
be said in the ID?... There was clear consensus when this ID was adopted 
that the plan was to finaly provide an update to RFC 4960.

I expect the authors to comment on your comments, then update their draft.

best wishes,

Gorry
(as document shepherd for draft-ietf-tsvwg-rfc4960-errata)

On 11/05/2018, 21:12, Spencer Dawkins at IETF wrote:
> Dear Authors,
>
> On Wed, Apr 18, 2018 at 1:50 AM, Gorry Fairhurst <[email-masked] 
> <mailto:[email-masked]>> 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/
>     <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
>
> 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.
>
> 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 …
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sun, 13 May 2018 21:47:20 -0500

Hi, Gorry,

> that the plan was to finaly provide an update to RFC 4960.

That's probably not necessary, now that I understand the theory behind this
draft.

> I expect the authors to comment on your comments, then update their draft.

Excellent!

Spencer

best wishes,

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 20 May 2018 18:53:37 +0200

> On 11. May 2018, at 22:12, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Dear Authors,
> 
> On Wed, Apr 18, 2018 at 1:50 AM, Gorry Fairhurst <[email-masked]> 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.
Hi Spencer,

thanks for the review. I'll provide feedback inline.

Please note that I was also notified recently about a paragraph which should
have been removed when moving from RFC 2960 to RFC 4960, but the removal was
missed and the text is still there. I have received this not via any mailing
list but via direct e-mail conversation. The fix is included as
https://github.com/sctplab/rfc4960bis/commit/27c8609a1d57d990fc439ea5f283ab5e82d4fc9c

You can see the current version in the git repository of the document in
http://xml2rfc.ietf.org/cgi-bin/xml2rfc.cgi?input=&url=https%3A%2F%2Fraw.githubusercontent.com%2Fsctplab%2Frfc4960bis%2Fmaster%2Fdraft-ietf-tsvwg-rfc4960-errata.xml&modeAsFormat=html%2Fascii&type=towindow&Submit=Submit

If you want additional changes, please let me know. If you are fine with the current
version in the git repo, I can submit it anytime...

Best regards
Michael
> 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 …
That is actually a good question and it would be a possible way forward.

When being in the process updating RFC 2960 to RFC 4960 we were in the same situation. At that time we wrote
RFC 4460. We thought it is a good idea to not only publish RFC 4960 and let people figure what changed and
why, but document this. That is why we have RFC 4460. We also thought that it is a good idea to just have a
single specification for implementing the base protocol. If we would have made RFC 4460 a PS updating RFC 2960,
and implementer would have to read two RFCs. That is why we decided that it is simpler to publish RFC 4460 as
an informational RFC, and then publish RFC 4960 as a PS updating RFC 2960. As you see from the numbers, working
on RFC 4460 took a while, but once that was there, publishing RFC 4960 was straight forward. Just do the editorial
work described in RFC 4460 and some polishing of text we missed when working in the diff way...

Since this plan worked well, the implementers of SCTP (which were also at that time) are used to it, we though
it is a good way to handle the errata in RFC 4960.
> 
> I note without suggesting a change that if the material in Section 3 was presented in this order
> 
> to allow readers to see the solution description before reading the detailed text changes, that would likely be easier to parse ...
That is definitely doable and I'm willing to do that change. However, this document right now uses the
same structure as RFC 4460 and I would prefer to keep the consistency.
> as saying that the deltas are cumulative, so you should apply the last change to specific text, but this text from Section 1 
> 
> 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.
OK. Changed to

   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.  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, the last delta in the text is the one which
   should be applied.

in https://github.com/sctplab/rfc4960bis/commit/b713055804f0ff26da9bb07bf9ac382ef3f6b434

>    Section 8.2 and Section 8.3 of [RFC4960] in an Inconsistent way.
Because I (or some autocorrection function of my editor) made a mistake.
Fixed in: https://github.com/sctplab/rfc4960bis/commit/12525d23e2ad49f84443e1a4d52a7ed1f90502a9
> 
> 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.
After updating the document to reduce IDNITs warnings regarding too long lines in
https://github.com/sctplab/rfc4960bis/commit/8c2afb32018d7886c7540fb804a32ecdd00626d5
and cleaning up the references in
https://github.com/sctplab/rfc4960bis/commit/84700f46033b5f0a833a13398dfc47766256606e
I added the now true Note to the RFC Editor in
https://github.com/sctplab/rfc4960bis/commit/a8e60e5b230ad24cd79bb807e732ec8a5208de57
>    That is, the next TSN a DATA chunk MUST use after transmitting TSN =
The difference between "2*32" and "2**32" (the second occurrence in the OLD and NEW text)...
Whether this should trigger an eye exam or not is left to the reader.
> 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".
> 
> (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)
You guessed perfectly right and I added the suggested text:
https://github.com/sctplab/rfc4960bis/commit/62674932f28950cf249cdfb2c51534ede667111d
> is actually clear about the order - assuming that you read left to right, it's just clearly wrong :-)
I see. But there is no explicit statement that you have to do it in that order. 

What about:

Section 7.2.2 of [RFC4960] likely implies the wrong order of adjustments
applied to partial_bytes_acked and cwnd in the congestion avoidance
phase.
which is committed in
https://github.com/sctplab/rfc4960bis/commit/9fa55976e242ff1e5125637336321887a2f57e80
> why is not clearing the counter if there is outstanding data on the association a good idea? (this was "shall", but is now "SHOULD")
You are correct. It should be a MUST.
Changed in: https://github.com/sctplab/rfc4960bis/commit/8ad403dd7e8102d1180b7d0363e3539637f9dafe
> Why would not clearing the error counter be a good idea?
You are right. The "should" should be changed to a "MUST", not a "SHOULD. Done in:
https://github.com/sctplab/rfc4960bis/commit/89446608b675e4d22cb4fe12a12c5a67a1b6faeb
>       that no more deliveries will be received for this Stream Sequence
No. This is even not changed by this documents, but also inconsistent in RFC 4960.
I also improved the consistency of the spelling:
However, I improved the text:
https://github.com/sctplab/rfc4960bis/commit/2e8adee110f3527bc3372c2f0dc6fae72eaf1751

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 21 May 2018 08:55:20 -0500

Hi, Gorry the Shepherd,

On Sun, May 20, 2018 at 11:53 AM Michael Tuexen <[email-masked]>
wrote:

> draft-ietf-tsvwg-rfc4960-errata-05 as Informational on behalf of the TSVWG
> working group.
> >

Michael's responses (whether they resulted in changes or in explanations to
the evaluating AD) work for me. Thanks to Michael for the quick response.

Please invite Michael to submit a new version, when you think that's the
right thing to do.

I would appreciate it if you could add a few words reflecting Michael's
response on Why This Is Informational to the shepherd write-up, perhaps
under (1) or (2)/Working Group Summary, where it will be copied into the
IESG ballot, so that we won't be explaining this 14 more times during IESG
evaluation ;-)

Spencer

> 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.
> >
> saying that I expect other ADs to ask that question during IESG Evaluation,
> and I'd like to understand the thinking before someone asks …
> in
> https://github.com/sctplab/rfc4960bis/commit/b713055804f0ff26da9bb07bf9ac382ef3f6b434
>
> >
> Fixed in:
> https://github.com/sctplab/rfc4960bis/commit/12525d23e2ad49f84443e1a4d52a7ed1f90502a9
> >
> >
> Changed in:
> https://github.com/sctplab/rfc4960bis/commit/8ad403dd7e8102d1180b7d0363e3539637f9dafe
> >

---

From: "Gorry (erg)" <[email-masked]>
Date: Mon, 21 May 2018 16:22:03 +0100

I will do

Gorry 

> On 21 May 2018, at 14:55, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Hi, Gorry the Shepherd,
> 
>> On Sun, May 20, 2018 at 11:53 AM Michael Tuexen <[email-masked]> wrote:
>> 
>> 
> Michael's responses (whether they resulted in changes or in explanations to the evaluating AD) work for me. Thanks to Michael for the quick response.
> 
> Please invite Michael to submit a new version, when you think that's the right thing to do.
> 
> I would appreciate it if you could add a few words reflecting Michael's response on Why This Is Informational to the shepherd write-up, perhaps under (1) or (2)/Working Group Summary, where it will be copied into the IESG ballot, so that we won't be explaining this 14 more times during IESG evaluation ;-)
> 
> Spencer
>  
>> Best regards
>> Michael
>> > 
>> > Thanks!
>> > 
>> > Spencer 
>> >

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 21 May 2018 11:18:46 -0500

Hi, Gorry,

> I will do

Just to confirm, I'll be happy to request Last Call on -06 as submitted.
Let me know when you think we're ready for that.

Thanks!

Spencer

> Michael's responses (whether they resulted in changes or in explanations
> to the evaluating AD) work for me. Thanks to Michael for the quick response.
>
>> an informational RFC, and then publish RFC 4960 as a PS updating RFC
>> 2960. As you see from the numbers, working
>> on RFC 4460 took a while, but once that was there, publishing RFC 4960
>> was straight forward. Just do the editorial

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 21 May 2018 17:59:18 +0100

Hi, Please go ahead with the process Spencer!

I can now confirm I have read the update and made a small change to the 
wrietup to reflect the WG's process of publishing an errata prior to 
working on the PS update,

Gorry

On 21/05/2018, 17:18, Spencer Dawkins at IETF wrote:
> Hi, Gorry,
>
> On Mon, May 21, 2018 at 10:22 AM Gorry (erg)<[email-masked]>  wrote:
>
>> I will do
>>
>> On 21 May 2018, at 14:55, Spencer Dawkins at IETF<
>> [email-masked]>  wrote:
>>
>> Hi, Gorry the Shepherd,
>>
>> On Sun, May 20, 2018 at 11:53 AM Michael Tuexen<[email-masked]>
>> wrote:
>>
>>>
>>>> On 11. May 2018, at 22:12, Spencer Dawkins at IETF<
>>> [email-masked]>  wrote:
>>>> Dear Authors,
>>>>
>>>> On Wed, Apr 18, 2018 at 1:50 AM, Gorry Fairhurst<[email-masked]>
>>> wrote:
>>>>     Transmission Sequence Numbers wrap around when they reach 2**32 - 1