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

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Mon, 21 May 2018 17:00 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 7799A12AF83; Mon, 21 May 2018 10:00:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 WwGvbLBb9Mem; Mon, 21 May 2018 09:59:58 -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 CB183129C56; Mon, 21 May 2018 09:59:57 -0700 (PDT)
Received: from Gs-MacBook-Pro.local (at-zeroshell-1.erg.abdn.ac.uk [139.133.217.68]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 0FB361B0015C; Mon, 21 May 2018 17:59:20 +0100 (BST)
Message-ID: <5B02FAE6.2040908@erg.abdn.ac.uk>
Date: Mon, 21 May 2018 17:59:18 +0100
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Reply-To: gorry@erg.abdn.ac.uk
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
CC: Michael Tuexen <tuexen@fh-muenster.de>, draft-ietf-tsvwg-rfc4960-errata@ietf.org, tsvwg-chairs <tsvwg-chairs@ietf.org>, tsvwg@ietf.org
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> <CAKKJt-e-hUwd=DJuS+M_HVmGie1HFo2Z33+1YuDrqSgKL9CZ2Q@mail.gmail.com>
In-Reply-To: <CAKKJt-e-hUwd=DJuS+M_HVmGie1HFo2Z33+1YuDrqSgKL9CZ2Q@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/_WKEkTwmyjwIlLbG3lYSDpRFZ1k>
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 17:00:04 -0000

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