Subject: Re: [tsvwg] Eric Rescorla's Discuss on draft-ietf-tsvwg-rfc4960-errata-06: (with DISCUSS and COMMENT)

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 23 Oct 2018 18:18:15 -0500

Dear All,

On Thu, Jul 5, 2018 at 10:14 AM Eric Rescorla <[email-masked]> wrote:

> There was some discussion of this on the call, so to clarify my position.
>
> Both because of the internal structure and the IESG statement cited by
> Adam in his DISCUSS, I think this document should not advance, and I think
> it's important to air those issues prior to making a decision. My DISCUSS
> is in the sense seen here (
> https://ietf.org/standards/process/iesg-ballots/) of: "I think we need to
> talk about this.". Once we have done so, if Spencer thinks that this
> document is worth publishing, I will remove my DISCUSS.
>
> -Ekr
>

 I should begin by thanking people for their comments, which (among other
things) resulted in what I believe to be the biggest improvement in the
text, which is flagging the final form of text that was touched more than
once, so that the reader could easily find that, rather than
pattern-matching their way through the document. So, thanks for that.

So, I have some thoughts about this, after reviewing ballot threads, review
threads, and minutes from the telechat where this document was discussed,
but the Tl;dr version is:

Earlier versions of this draft had adopted the "errata in the order they
were submitted" organization that RFC 4460 used, when TSVWG published their
review errata for RFC 2960, and that was reader-hostile. The authors have
updated -08 of this draft to include notes of the form

     This text has been modified by multiple errata.  It is further
     updated in Section 3.43.

and

   This text is in final form, and is not further updated in this
     document.

so that the most reader-hostile aspect of -06 has been addressed to my
satisfaction.

The intended audience for this draft is the SCTP implementer community,
which looks to the RFC series for guidance, and the intended timeframe is
that TSVWG wants the implementer community to be aware of these text
changes now.

The intended audience for this draft includes implementers who are not
active in TSVWG, and unlikely to notice working group wiki pages or expired
drafts. The third alternative we offer in the IESG statement on "Support
Documents in IETF Working Groups" is publication in an informational
appendix to a solution document, but the working group doesn't even have an
individual draft for rfc4960-bis yet.

Eric held a Discuss on this document based on the number of Abstains
balloted, so rather than ask Eric whether he can clear for -08, I want to
ask the IESG whether this draft needs to return on an upcoming telechat, so
that each AD who Abstained can consider the situation.

Thanks in advance for your feedback, of course.

Spencer

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 23 Oct 2018 20:14:43 -0700

On Tue, Oct 23, 2018 at 4:18 PM Spencer Dawkins at IETF <
[email-masked]> wrote:

>> https://ietf.org/standards/process/iesg-ballots/) of: "I think we need
>> to talk about this.". Once we have done so, if Spencer thinks that this
> So, I have some thoughts about this, after reviewing ballot threads,
> review threads, and minutes from the telechat where this document was
> discussed, but the Tl;dr version is:
>

FWIW, I am prepared to withdraw my DISCUSS, but when I do so, I intend to
ballot abstain.

-Ekr

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 23 Oct 2018 23:09:56 -0500

Hi, Eric,

> FWIW, I am prepared to withdraw my DISCUSS, but when I do so, I intend to

Sure. Let's see if anyone else wants this to come back for a telechat.

And thanks. When the working group does a -bis for rfc4960bis in the
distant future, it won't be a late surprise that they should rethink the
approach they used with the previous two revisions :-)

Spencer

---

From: Adam Roach <[email-masked]>
Date: Tue, 23 Oct 2018 23:43:01 -0500

On 10/23/18 6:18 PM, Spencer Dawkins at IETF wrote:
> active in TSVWG, and unlikely to notice working group wiki pages or 
> expired drafts. The third alternative we offer in the IESG statement 
> on "Support Documents in IETF Working Groups" is publication in an 
> informational appendix to a solution document, but the working group 
> doesn't even have an individual draft for rfc4960-bis yet.

I hope this doesn't come across as blithe, but if this document is what 
it appears to be, then creating an RFC 4960 bis should be a trivial 
mechanical exercise, right? And to Eric's point: anything that makes 
this not just a trivial mechanical exercise is complexity that we are 
pushing onto its readers. I recognize that I may be setting up a false 
dichotomy here, but it seems to me that either this document is ready to 
be used, or it's not. What am I missing?

/a

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 24 Oct 2018 00:53:15 -0500

Hi, Adam,

> be used, or it's not. What am I missing?

My understanding - and the WG is copied, and they are not shy, so I have
confidence they'll correct me - is that this document is the errata
handling part of an rfc4960bis, and they want developers to apply these
errata now, without waiting for the working group to agree on new
functionality, which might also be part of an rfc4960bis.

Spencer

---

From: Ben Campbell <[email-masked]>
Date: Wed, 24 Oct 2018 21:49:08 -0500

> On Oct 24, 2018, at 12:53 AM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Hi, Adam,
> 
> On Tue, Oct 23, 2018, 23:43 Adam Roach <[email-masked] <mailto:[email-masked]>> wrote:
> My understanding - and the WG is copied, and they are not shy, so I have confidence they'll correct me - is that this document is the errata handling part of an rfc4960bis, and they want developers to apply these errata now, without waiting for the working group to agree on new functionality, which might also be part of an rfc4960bis.
> 

A possible approach to that would a 4960bis with just errata fixes, and a 4960ter (or is that bis-bis) that adds new functionality.

Ben.

---

From: G Fairhurst <[email-masked]>
Date: Thu, 25 Oct 2018 08:44:15 +0100

On 25/10/2018, 03:49, Ben Campbell wrote:
>
>
>> On Oct 24, 2018, at 12:53 AM, Spencer Dawkins at IETF 
>> <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi, Adam,
>>
>> My understanding - and the WG is copied, and they are not shy, so I 
>> have confidence they'll correct me - is that this document is the 
>> errata handling part of an rfc4960bis, and they want developers to 
>> apply these errata now, without waiting for the working group to 
>> agree on new functionality, which might also be part of an rfc4960bis.
>>
>
> A possible approach to that would a 4960bis with just errata fixes, 
> and a 4960ter (or is that bis-bis) that adds new functionality.
>
> Ben.
>
Nobody in TSVWG has ever requested the Chairs to work on a 4960bis with 
just errata fixes. When asked, the users and implementors both wanted to 
use the process in the past, producing a list of technical changes to 
RFC4960 in an Informational document and a clean rewrite of the 
standards-track document for the new rev of the SCTP spec.

I know Spencer is continuing to follow this up.

Gorry
(TSVWG Co-Chair)

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 25 Oct 2018 09:49:34 +0200

> On 25. Oct 2018, at 04:49, Ben Campbell <[email-masked]> wrote:
> 
> 
> 
Hi Ben,

one reason for the errata document is to define the scope of differences between RFC 4960 and RFC 4960bis.
So I don't think there will be any new functionality added to the base protocol. The goal is to work on
RFC 4960bis with a well defined scope of changes.

Best regards
Michael

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 25 Oct 2018 08:03:18 -0500

FWIW,

> I know Spencer is continuing to follow this up.

Indeed.

On this specific point, I've asked the IESG if anyone else needed to
re-ballot as Discuss knowing that Eric said he would clear, because I do
actually care about what's been said in the discussion to date.

I'd further ask the IESG to let me know by November 1, a week from today,
if that's going to happen.

If it doesn't, I'll ask Eric to clear and I'll move towards approval.

If that does happen, I'll ask that we put this document on an IESG agenda
in Bangkok.

Thanks, all.

Spencer

Gorry