Subject: Opsdir last call review of draft-ietf-tsvwg-rfc4960-errata-06

From: Jürgen Schönwälder <[email-masked]>
Date: Mon, 11 Jun 2018 03:49:57 -0700

Reviewer: Jürgen Schönwälder
Review result: Has Issues

Let me start this way: I am impressed that tsvwg is able to produce such a
document. I understand that there is a precedence, namely RFC 4460. While
keeping a record of changes is extremely useful, it is not clear whether it is
valuable to go through the effort to publish them as RFCs. (In other WGs,  
issue lists like these are often maintained outside the RFC process.)

Given the number ~50 issues, it is really important to have an RFC 4960bis     
but I do not see such a document anywhere. This concerns me. Do we really help
implementors if they have to extract patches from ~80 pages of text to apply
them        to RFC 4960? Several issues have already been reported as errata.
Why are errata         not found to be sufficient until RFC 4960bis is produced?

If I would have a choice, I would rather have an RFC 4960bis with an appendix
providing any explanations for changes that are not trivial (there are also
quite a few editorial changes).

I have marked this with 'has issues' but I am not really having an issue with
the document per se but more with the fact that I do not see an RFC 4960bis
that integrates all the changes. This I consider actually a serious issues - it
is good to have a standards track specification with all the fixes applied
(instead of an informational collection of fixes that people interested must
apply themselves in a meaningful way).

Editorial:

- s/wrong order of of/wrong order of/

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 11 Jun 2018 17:22:17 +0200

> On 11. Jun 2018, at 12:49, Jürgen Schönwälder <[email-masked]> wrote:
> 
Hi Jürgen,

thanks for your review. See my comments in-line.

Best regards
Michael
> Why are errata         not found to be sufficient until RFC 4960bis is produced?
The implementers wanted to have a document which they can look up the
required changes. Most of them are already implemented in the kernel
implementations.

Most of the time people discussed an issue on the list, agreed on the 
text and than it was added to the WG document. Not sure this is easily
doable with an errata. I mean someone files an errata and than it
can be accepted or rejected. But you can't simply evolve the text for
an resolution. This is at least how this came up in the past. People
filed erratas and then some discussion happened.
I'm also not sure how Erratas are handled. I think an AD is involved that, too?
> quite a few editorial changes).
It would be a substantial appendix...
> apply themselves in a meaningful way).
The plan was to start with the RFC 4960bis document once this document is
an RFC. That work is not too hard and mostly editorial, since the technical
work has been done in this document.

Best regards
Michael
> - s/wrong order of of/wrong order of/
Fixed for the next revision.

---

From: Randall Stewart <[email-masked]>
Date: Mon, 11 Jun 2018 08:25:49 -0700

> work has been done in this document.

And most importantly it scopes the work of 4960 bis to not open things
up to all sort of things..

i.e. if it was not in this document you can't change things in the bis (or
at least you better have a very very very good reason too).

R

--

Randall Stewart

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 11 Jun 2018 16:51:56 -0500

> I'm also not sure how Erratas are handled. I think an AD is involved that, too?

The process is a little different for IETF- vs non-IETF-stream
documents, but basically, yes, an AD acts as Verifier for the
erratum.  They can, however, apply arbitrary changes to the "NEW"
text and NOTE at that time, so it is in some sense encouraged fro
the submission of the errata candidate to spark discussion on the
relevant list(s) and evolution to a consensus text that can be used
to verify the erratum.

> at least you better have a very very very good reason too).

Well, only from a certain point of view.  Once the bis document is
up, it's all fair game for review and changes, from a process point
of view.  If it was going for full Internet Standard as well, then
there would be a process reason to avoid "spurious" changes, though.

-Ben

---

From: "Gorry (erg)" <[email-masked]>
Date: Mon, 11 Jun 2018 11:58:03 +0100

The process used by SCTP is described in the shepherd write up.

Gorry

> On 11 Jun 2018, at 11:49, Jürgen Schönwälder <[email-masked]> wrote:
>

---

From: gorry <[email-masked]>
Date: Tue, 12 Jun 2018 08:18:40 +0100

> there would be a process reason to avoid "spurious" changes, though.

Processes do vary a little for different activities (and areas) in the 
IETF, and "yes" the intention here is to progress the standards status 
of this specification. This seems like a fair discussion - there is more 
context in the Shepherd Write-Up.

I can confirm that the working group was confident that this ID contains 
the set of currently known substantive changes. If this is approved, the 
WG will immediately open a .bis document - it could indeed find more 
issues - and there may well also be editorial changes required to 
complete the process, but the expectation is that all major changes will 
already have been documented here. Since we are working on a implemented 
spec and the implementors have been a part of this process, I am 
confident we will receive the necessary reveiw to complete this.

- Gorry
(Shepherd and co-chair)