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

Gorry Fairhurst <> Mon, 21 May 2018 17:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7799A12AF83; Mon, 21 May 2018 10:00:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WwGvbLBb9Mem; Mon, 21 May 2018 09:59:58 -0700 (PDT)
Received: from ( [IPv6:2001:630:241:204::f0f0]) by (Postfix) with ESMTP id CB183129C56; Mon, 21 May 2018 09:59:57 -0700 (PDT)
Received: from Gs-MacBook-Pro.local ( []) by (Postfix) with ESMTPA id 0FB361B0015C; Mon, 21 May 2018 17:59:20 +0100 (BST)
Message-ID: <>
Date: Mon, 21 May 2018 17:59:18 +0100
From: Gorry Fairhurst <>
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 <>
CC: Michael Tuexen <>,, tsvwg-chairs <>,
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [tsvwg] Publication has been requested for draft-ietf-tsvwg-rfc4960-errata-05
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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,


On 21/05/2018, 17:18, Spencer Dawkins at IETF wrote:
> Hi, Gorry,
> On Mon, May 21, 2018 at 10:22 AM Gorry (erg)<>  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<
>>>  wrote:
>> Hi, Gorry the Shepherd,
>> On Sun, May 20, 2018 at 11:53 AM Michael Tuexen<>
>> wrote:
>>>> On 11. May 2018, at 22:12, Spencer Dawkins at IETF<
>>>>  wrote:
>>>> Dear Authors,
>>>> On Wed, Apr 18, 2018 at 1:50 AM, Gorry Fairhurst<>
>>> 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
>>>> 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
>>> You can see the current version in the git repository of the document in
>>> 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
>>>> 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:
>>> 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
>>> and cleaning up the references in
>>> I added the now true Note to the RFC Editor in
>>>> 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