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

"Gorry (erg)" <gorry@erg.abdn.ac.uk> Mon, 21 May 2018 15:22 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCEB912E895; Mon, 21 May 2018 08:22:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LG3N3LTRIAm8; Mon, 21 May 2018 08:22:06 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id A75F21274D2; Mon, 21 May 2018 08:22:04 -0700 (PDT)
Received: from [137.50.183.77] (oa-edu-183-77.wireless.abdn.ac.uk [137.50.183.77]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id B24311B00067; Mon, 21 May 2018 16:22:03 +0100 (BST)
Content-Type: multipart/alternative; boundary=Apple-Mail-83B553CB-B491-441C-A5A0-75A0CB9D1F69
Mime-Version: 1.0 (1.0)
From: "Gorry (erg)" <gorry@erg.abdn.ac.uk>
X-Mailer: iPhone Mail (15E216)
In-Reply-To: <CAKKJt-cciJCt9EBr32ua-Ww+xm1x9rY7CypNFy1TpZzS9JZg8w@mail.gmail.com>
Date: Mon, 21 May 2018 16:22:03 +0100
Cc: Michael Tuexen <tuexen@fh-muenster.de>, draft-ietf-tsvwg-rfc4960-errata@ietf.org, tsvwg-chairs <tsvwg-chairs@ietf.org>, tsvwg@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <FD718718-CC0B-4380-B516-13035A6C333E@erg.abdn.ac.uk>
References: <152403424429.31950.1069432147680033860.idtracker@ietfa.amsl.com> <CAKKJt-dxTndxOtUMjjLVfgnwKcJ4xvZ6q09XGv720Ob80f_0ZQ@mail.gmail.com> <28C5B00A-3721-4137-8BEF-E9A013F42856@fh-muenster.de> <CAKKJt-cciJCt9EBr32ua-Ww+xm1x9rY7CypNFy1TpZzS9JZg8w@mail.gmail.com>
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/DBnGNUCtYOLN13IKoibTOh2UB94>
Subject: Re: [tsvwg] Publication has been requested for draft-ietf-tsvwg-rfc4960-errata-05
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 May 2018 15:22:12 -0000

I will do

Gorry 

> On 21 May 2018, at 14:55, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
> 
> Hi, Gorry the Shepherd,
> 
>> On Sun, May 20, 2018 at 11:53 AM Michael Tuexen <tuexen@fh-muenster.de> wrote:
>> 
>> 
>> > On 11. May 2018, at 22:12, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
>> > 
>> > Dear Authors,
>> > 
>> > On Wed, Apr 18, 2018 at 1:50 AM, Gorry Fairhurst <gorry@erg.abdn.ac.uk> 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...
> 
> 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 
>> > 
>> > 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 …
>> 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
>> > 
>> > 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 ...
>> 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.
>> > 
>> > 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.
>> 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
>> 
>> > 
>> > 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.
>> 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
>> > 
>> > 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?
>> 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.
>> > 
>> > 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)
>> You guessed perfectly right and I added the suggested text:
>> https://github.com/sctplab/rfc4960bis/commit/62674932f28950cf249cdfb2c51534ede667111d
>> > 
>> > 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 :-)
>> 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
>> > 
>> > 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")
>> You are correct. It should be a MUST.
>> Changed in: https://github.com/sctplab/rfc4960bis/commit/8ad403dd7e8102d1180b7d0363e3539637f9dafe
>> > 
>> > 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?
>> You are right. The "should" should be changed to a "MUST", not a "SHOULD. Done in:
>> https://github.com/sctplab/rfc4960bis/commit/89446608b675e4d22cb4fe12a12c5a67a1b6faeb
>> > 
>> > 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?
>> 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
>> 
>> 
>>