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

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Mon, 21 May 2018 16:19 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
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 B64A4128959; Mon, 21 May 2018 09:19:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 GcvLZ54czll3; Mon, 21 May 2018 09:19:01 -0700 (PDT)
Received: from mail-yw0-x243.google.com (mail-yw0-x243.google.com [IPv6:2607:f8b0:4002:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E75D12778E; Mon, 21 May 2018 09:19:01 -0700 (PDT)
Received: by mail-yw0-x243.google.com with SMTP id r202-v6so4643664ywg.10; Mon, 21 May 2018 09:19:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IH+JaCKwisgn252YGEpvjxLZP9svVw9yDwQ3IRsU+a8=; b=Ivkvgi21uTIwc3VHfy+lugWKPdRIYLZx2hLQDFF5ArtUXbCrmYEIceCRT3k2Xw+x9/ eiDE1i1WTvuGZKps+Az7+uNpF3Wo0rjKBvgtiqBhi0hFaAtXA3jS5AHQnBNcOy7fHHmc l3TXzamiIe+gQ52a2ACkTwJVcjNTjTKkvqTLNoFcvSzvEvmiNZWtomQkJqHSfXEyaD1H hSt7r0auPdUWcP0W2p1phaLUvzdR0l+YKrWuRG22nu0anZ+EvjVWSyhQnR/c40wx4vtE SlO2ONCRYpPq3qBe3QVtfY++OVwpkGCuT/fgC5br0PzCnbE0tD02qhGUdHYw/D80ueHY lioA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IH+JaCKwisgn252YGEpvjxLZP9svVw9yDwQ3IRsU+a8=; b=rzosmFUWGl4buFt/ABcJAKcuhoafnxYMyVm6qyKHyNGxTjw/nlgJfn8IVVDTJvK3Ru Et1IWH41ovf6Z5gWom3zwDe1BLsa55Xbg9faOF+55ucgHzw1yWlFAFFbVDlnyuhVrxIm kkeT/N+pXx8cLbzx+ptGTSyxpKPi6Gz55VqJUdids88jQbrmM5jp4OoqpPwFmfciOWHy XLflZCwHLDAzRNsZObu2QLXCp0uXRIMyhdGTvnkLJ3FH1NtX/H0bdF7BmRFTbeb7jgXW L5aYniL1YwwyAOboVF9Ew5fjONxttmydwbw2IqRG0O1wJ13Yk+/KBy2NtfgmLKx4IN0B rm7A==
X-Gm-Message-State: ALKqPwdfz7Xz52YFtivT8jwMKkjMui3okJvrSPdJWylc49fl6BYn2gkm pwHj/m7SM0bWzcuvHNAAMxSyxt1N8lYLIaOxdoA=
X-Google-Smtp-Source: AB8JxZr2C3Dr/G681XzJTHZL5MlbUb/JP0mN77X6/tbwWbugQ62GQHxgfFnVJMQVmgvwLv7AbmGjICzTGpFaYw9/61U=
X-Received: by 2002:a0d:ed06:: with SMTP id w6-v6mr9976003ywe.467.1526919539965; Mon, 21 May 2018 09:18:59 -0700 (PDT)
MIME-Version: 1.0
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> <FD718718-CC0B-4380-B516-13035A6C333E@erg.abdn.ac.uk>
In-Reply-To: <FD718718-CC0B-4380-B516-13035A6C333E@erg.abdn.ac.uk>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Mon, 21 May 2018 11:18:46 -0500
Message-ID: <CAKKJt-e-hUwd=DJuS+M_HVmGie1HFo2Z33+1YuDrqSgKL9CZ2Q@mail.gmail.com>
To: G Fairhurst <gorry@erg.abdn.ac.uk>
Cc: Michael Tuexen <tuexen@fh-muenster.de>, draft-ietf-tsvwg-rfc4960-errata@ietf.org, tsvwg-chairs <tsvwg-chairs@ietf.org>, tsvwg@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c7c5c3056cb9a8b1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/O0qRMjv8M5lh5w9qOT398Ds17e0>
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 16:19:05 -0000

Hi, Gorry,

On Mon, May 21, 2018 at 10:22 AM Gorry (erg) <gorry@erg.abdn.ac.uk> wrote:

> 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


> 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
>>
>>
>>
>>