Subject: Re: Updated IESG Statement "IESG Processing of RFC Errata for the IETF Stream"

From: Brian E Carpenter <[email-masked]>
Date: Sat, 8 May 2021 14:30:02 +1200

Hi,

Does the IESG plan to catch up on old reported errata that have never been processed?

There are three here for example: https://www.rfc-editor.org/errata/rfc6275, as much as 4 years old. There may be a lot more lurking.

Regards
   Brian Carpenter

On 08-May-21 04:38, IESG Secretary wrote:
> IESG Processing of RFC Errata for the IETF Stream
> 
> Online: <https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/>
> 
> This document describes how the IESG processes RFC Errata for the IETF Stream.
> 
> These are strong guidelines, not immutable rules. The Area Directors (ADs) should use 
> common sense and good judgment to decide what the right thing to do is. They apply to new 
> errata and not to errata that have already been processed.
> 
> Errata are meant to fix "bugs" in the specification and should not be used to change what the 
> community meant when it approved the RFC.  Here are some things to consider when 
> submitting an errata report:
> 
> * Errata are items that were errors at the time the document was published -- things that 
>   were missed during the last call, approval, and publication process.  If new information, 
>   new capabilities, or new thinking has come up since publication, or if you disagree with 
>   the content of the RFC, that is not material for an errata report.  Such items are better 
>   brought to relevant working groups, technical area discussions, or the IESG.
> * Errata reports are usually for errors in the text version of a document.  It is possible to 
>   report errors in other outputs (e.g., HTML or PDF) for RFCs published in the v3 format 
>   (i.e., RFC 8650+).
> * Errata are classified as "technical" or "editorial".  Please mark the report appropriately.  
>   Technical errata are expected to be things that would likely cause significant 
>   misunderstandings of the technical specification and might result in faulty 
>   implementations if they are not corrected. Editorial errata are, as the name implies, 
>   editorial - for example, typos, missing commas, etc. Errors in examples will generally be 
>   editorial, though marking them as technical could sometimes be justified.
> * Please clearly explain the issue in the Comments section. This is especially important for 
>   editorial issues, where the Original Text and Corrected Text may look almost identical. 
> 
> When a technical erratum is reported, a report is sent to the authors, chairs, and Area Directors 
> (ADs) of the WG in which the document originated. If the WG has closed or the document was 
> not associated with a WG, then the report will be sent to the ADs for the Area most closely 
> associated with the subject matter.  
> 
> When an editorial erratum is reported, the RFC Editor will do an initial review and handle errata 
> that are clearly editorial in nature. If the erratum cannot be handled by the RFC Editor, the AD 
> will be asked to review.
> 
> While ADs are ultimately responsible for processing the reports, they may delegate the review 
> or perform it personally.  The reviewer will classify the erratum as falling under one of the 
> following states:
> 
> * Verified - The erratum is appropriate under the criteria below and should be available to 
>   implementers or people deploying the RFC.
> * Rejected - The erratum is invalid or proposes a significant change to the RFC that 
>   should be done by publishing a new RFC that replaces or updates the current one. In 
>   the latter case, if the change is to be considered for future updates of the document, it 
>   should be proposed using channels other than the errata process, such as a WG mailing 
>   list.
> * Hold for Document Update - The erratum is not a necessary update to the RFC. 
>   However, any future update of the document might consider it and determine whether it 
>   merits including in an update.
> 
> Guidelines for review are:
> 
> 1. Grammar corrections and typographical errors should be classified as Verified.
> 2. Broken URIs that were likely valid at the time of publication are, strictly speaking, not 
>    subject to errata reports.  That said, the AD must judge the importance of correcting 
>    such a reference and may classify the report as Verified.
> 3. Changes that are stylistic issues or simply make things read better should be classified 
>    as Hold for Document Update.
> 4. Technical items that have a clear resolution in line with the original intent should be 
>    classified as Verified.  If the resolution is not clear or requires further discussion, the 
>    report should be classified as Hold for Document Update.  In both cases, only items that 
>    are clearly wrong should be considered.
> 5. Changes that modify the working of a protocol to something that might be different from 
>    the intended consensus when the document was approved should generally be 
>    Rejected.  Significant clarifications should not be handled as errata reports and need to 
>    be discussed by the relevant technical community.
> 6. Changes that modify the working of a process, such as changing an IANA registration 
>    procedure, to something that might be different from the intended consensus when the 
>    document was approved should be Rejected.
> 7. Errata on obsolete RFCs should be considered according to whether the error persists in 
>    the obsoleting RFC.  If it does, the report should Rejected with a pointer to new errata 
>    against the obsoleting RFC.  If it does not, it should be Rejected with an explanation that 
>    the error is corrected in the obsoleting RFC (cited by number).
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Sat, 8 May 2021 06:35:00 +0000

Brian

Just replying as myself and not in the name of the IESG. I tend to process all incoming errata immediately and on less loaded weeks (no formal telechat), then I try to process a couple of errata (sometimes on very very old documents). 

Sometimes, I feel like I am a Danaïdes' brother __

-éric

-----Original Message-----
From: ietf <[email-masked]> on behalf of Brian E Carpenter <[email-masked]>
Date: Saturday, 8 May 2021 at 04:30
To: IETF discussion list <[email-masked]>
Subject: Re: Updated IESG Statement "IESG Processing of RFC Errata for the IETF Stream"

    Hi,

    Regards
       Brian Carpenter

---

From: Michael Richardson <[email-masked]>
Date: Sat, 08 May 2021 09:54:00 -0400

> There are three here for example:
    > https://www.rfc-editor.org/errata/rfc6275, as much as 4 years
    > old. There may be a lot more lurking.

We need to fix the tooling to delegate to WG chairs to propose actions.
Maybe we want ADs to confirm (like milestones), but I don't think we'll ever
deal with backlog until we can easily keep up with current efforts.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 9 May 2021 07:56:19 +1200

> We need to fix the tooling to delegate to WG chairs to propose actions.

Yes, except when the WG no longer exists.

> deal with backlog until we can easily keep up with current efforts.

I'm sure that's true too.

Dare I suggest monthly nag messages, to the WG chairs if they exist, or to the responsible AD otherwise? Or a least, a page that lists all unprocessed errata and their age in days. At the moment I think we don't even know the size of the backlog.

    Brian

---

From: Bob Hinden <[email-masked]>
Date: Sat, 8 May 2021 15:53:23 -0700

IESG,

I think this is good and appreciate the IESG publishing it.

There is an issue that this does not cover, that something needs to be done about.  It is when an Errata if filed, it identify the problem the Errata is addressing, and new includes text to fix the problem.

However, we have run into errata where the problem identified is correct, but the the fix to the problem is wrong.   It may be completely wrong, or there may be a better way to fix the problem.  In the worst case, it could make the problem worse.

The three states for processing an errata are:

* Verified
* Rejected
* Hold for Document Update

These don’t address this issue.   For example, marking the errata as “Verified” is fine for the problem, but not good for the fix in the errata.    We wouldn’t want implementors to assume the fix is correct.

I think something is needed where the reported problem can be accepted, but the fix can be rejected.    Perhaps some new states, or a change to how the Errata system works.

Bob

> On May 7, 2021, at 7:30 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi,
>

---

From: Stewart Bryant <[email-masked]>
Date: Sun, 9 May 2021 09:29:09 +0100

> Dare I suggest monthly nag messages, to the WG chairs if they exist, or to the responsible AD otherwise? Or a least, a page that lists all unprocessed errata and their age in days. At the moment I…

You can find the number by area and status here:

https://www.rfc-editor.org/errata.php <https://www.rfc-editor.org/errata.php>

Not sure if there is a consolidated view that shows them all, but it is easy to determine the number of unprocessed errata (status = reported) for each area.

Responsibility for moving them forward rests with the AD, and not the WG chairs, though WG have a role to play in their resolution. However in many cases the resolution is obvious and can be done quite quickly by the AD.

Perhaps we should require the IESG Chair to report the errata stats by area at each IETF?

- Stewart

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sun, 9 May 2021 13:54:19 -0500

A bit more than +1 here ...

>     > old. There may be a lot more lurking.

Can I just thank Brian for not picking something from TSV?

Martin and I reeked at that, although we were making progress after a year
or two ... Mirja inspired me to Do Better, but I don't remember us getting
to zero. Based on
https://www.rfc-editor.org/errata_search.php?rec_status=2&area_acronym=tsv&errata_type=2&presentation=table
including one errata reported by Alfred Hoenes in 2010, I'm guessing we
never did.

But this informs my background below.

> deal with backlog until we can easily keep up with current efforts.

This is my +1 for Michael, but I want to provide a bit of background here.

There is a pretty big range of topics in a single area, between areas. In
TSV, I could pretty trivially process technical errata for some working
groups, but for other working groups, I had paid almost no attention to
them for years, before becoming AD (I love NFSv4, but I was only vaguely
aware that NFS was now running over TCP).

I am pretty sure that there are some serving ADs who are responsible for
working groups that they've never followed and had to subscribe to the
mailing lists when they were seated, and had never even looked at those
working group charters (especially not the historical charters). I suspect
that's more true in some areas than others, but that's just a guess.

As long as working groups exist, it's likely that WG chairs have fewer
errata to look at than ADs, and also that they are more likely to be
familiar with the documents and topics from their own working groups.

So, yes, PLEASE consider doing with errata what has been done with
milestones. That would make a huge difference for at least some errata from
current working groups, and if the ADs end up dealing with the deep end of
the swamp without an active working group (or even an active mailing list),
well, that's just part of the job. Today, they own all of the swamp.

This is much more likely to work well than nag messages (ADs have some of
the most fabulous mail filters I've ever seen, just in order to survive,
and once you figure out you won't be recalled if there's a 10-year-old
reported errata in your area, there's no going back!).

Best,

Spencer

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sun, 9 May 2021 14:06:02 -0500

Hi, Stewart,

> Perhaps we should require the IESG Chair to report the errata stats by

We might disagree on how responsive ADs have been, or should be, to public
shaming in general, but I remember that the errata states were presented at
plenary when I joined the IESG, and Martin and I managed to be pretty
shameless, when it came to errata 😂

Slide in
https://www.ietf.org/proceedings/87/slides/slides-87-iesg-opsplenary-0.pdf.

Best,

Spencer

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 9 May 2021 21:11:35 +0200

>  https://www.rfc-editor.org/errata_search.php?rec_status=2&area_acronym=tsv&errata_type=2&presentation=table

Wow, thanks.

I immediately glanced at

https://www.rfc-editor.org/errata_search.php?rec_status=2&area_acronym=art&errata_type=2&presentation=table

228 of them.  Two even reported by me that I had completely forgotten about :*)

So how do I find unhandled errata reports for all RFCs that I’m a co-author on?

Grüße, Carsten

:*) https://www.rfc-editor.org/errata_search.php?rec_status=2&errata_type=2&presentation=table&submitter_name=Carsten%20Bormann

---

From: tom petch <[email-masked]>
Date: Sun, 9 May 2021 21:18:31 +0100

> I think something is needed where the reported problem can be accepted, but the fix can be rejected.    Perhaps some new states, or a change to how the Errata system works.

I have seen this several times and the solution I see is that the AD has 
space to comment on the reasons for the rejection and that is what they 
do, yes to the problem, no to the solution, and in several cases the 
author of the erratum has another go, perhaps with a WG discussion, and 
in the end there is usually an accepted erratum.

Better still is to have the discussion on the WG list beforehand and I 
see plenty of that.  In fact, I would say that an erratum without a 
prior discussion usually comes from someone whom I have not seen 
participating in the IETF before, is unfamiliar with the process and do 
not realise that functional changes are made via an I-D.

Tom Petch
Tom Petch

---

From: John C Klensin <[email-masked]>
Date: Sun, 09 May 2021 16:19:47 -0400

--On Saturday, May 8, 2021 15:53 -0700 Bob Hinden
<[email-masked]> wrote:

> There is an issue that this does not cover, that something
> needs to be done about.  It is when an Errata if filed, it
> identify the problem the Errata is addressing, and new
> includes text to fix the problem.
> 
> However, we have run into errata where the problem identified
> is correct, but the the fix to the problem is wrong.   It may
> be completely wrong, or there may be a better way to fix the
> problem.  In the worst case, it could make the problem worse.
> 
> These don't address this issue.   For example, marking the
> errata as "Verified" is fine for the problem, but not good
> for the fix in the errata.    We wouldn't want implementors
> to assume the fix is correct.
> 
> I think something is needed where the reported problem can be
> accepted, but the fix can be rejected.    Perhaps some new
> states, or a change to how the Errata system works.

Bob,

While I agree with your statement of the problem, I'm not sure
about the fix :-).  And I'm afraid you just opened a can of
worms.

Let's take the two cases I think are difficult and putting aside
documents that are not on the standards track or that did not
come from a WG for the moment:

Example 1:  Text says "...Mickey is a duck".  Errata report says
'"not" is missing; Mickey is not a duck' and claims it is an
editorial matter.

Now, I would hope the RFC Editor would say "the suggestion
changes the meaning of the sentence and is consequently not
editorial" but I would hope there would be an additional set of
eyes on that decision, or any decision that something more
serious than, e.g., an obvious misspelling, is editorial.  To
reduce AD  workload, I think those eyes can safely be those of
the author(s).

Example 2: There is a real technical issue.  The assertion about
Mickey's species might turn out to be an example but I'm more
concerned about proposed errata that involve more complex
issues.  If the consensus among ADs, Authors, and present or
former WG Chairs is "whoops, the WG didn't think about that and
thinking about that now gives us a headache", then the erratum
clearly gets "save for document revision" and we move on.  But
suppose it is "Verified".  What does that mean and, coming back
to your point in particular, can an implementer rely on it?  It
does not represent IETF Consensus: there is been no IETF Last
Call and it is really the position of a handful of people.

My guess is that, at least for technical issues, "hold for
document update"  means "we are not going to think about that
now" and that "verified" means "we agree that there is probably
a problem, the proposed fix may or may not be correct, and you
will need to wait for a new RFC with IETF Consensus to get a
conclusion implementers can rely on".  The IESG should be able
to make statements about the level of their confidence in the
fix as long as it was clear that their comments must not be
confused with IETF consensus either.  That would, of course,
solve the problem you identify but has much broader
implications.  If there is agreement about "verified" not
representing IETF consensus -- even for the problem statement,
much less the fix-- I'd hope the relevant RFC Editor pages could
be updated to clearly show definitions like those and that IESG
statements could point to them.

These distinctions are particularly important if the IETF is
going to publish versions of RFCs with errata incorporated.

The only other option I can see involves putting every single
erratum with potentially substantive technical implications
through IETF Last Call before it is marked "verified".  Even if
that was not required for "rejected" or "save for document
update", to say that would not reduce AD (or community) workload
significantly would be an understatement.  

best,
   john

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sun, 9 May 2021 16:45:58 -0500

Massively chopping this thread of (I'm not being snarky) wisdom, down to
the part I think I can contribute to ...

> going to publish versions of RFCs with errata incorporated.

Because I honestly don't know who might be reading this e-mail thread, and
what they might know, let me say this out loud.

I have no inside knowledge of what the *IETF* might plan to publish, but
for what the RFC Editor publishes, this ship has sailed.

Tl;dr

I had the privilege (HAH!!!) of explaining the Theory and Practice of RFC
Errata to members of the CELLAR working group that I co-chair with Michael
Richardson, during our last virtual meeting. This group has published one
RFC, and https://datatracker.ietf.org/doc/html/rfc8794 is 2700 lines long
and pretty dense, so they're receiving errata report (mostly through
Github, from people who don't even participate in CELLAR, much less grok
the difference between the RFC view in the datatracker and the RFC view on
rfc-editor.org).

They were horrified to discover that RFCs are immutable, and were imagining
that they were going to have to roll another RFC every time someone
reported a bug.

I showed them (as an example) that if they searched for RFC3261 on the RFC
Editor website, and clicked on the cute "HTML with a green check mark"
icon, they got a page that started with this:

This is a purely informative rendering of an RFC that includes verified
errata. This rendering may not be used as a reference.

The following 'Verified' errata have been incorporated in this document: EID
316 <https://www.rfc-editor.org/rfc/inline-errata/rfc3261.html#eid316>, EID
1051 <https://www.rfc-editor.org/rfc/inline-errata/rfc3261.html#btn_1051>, EID
1073 <https://www.rfc-editor.org/rfc/inline-errata/rfc3261.html#eid1073>, EID
1470 <https://www.rfc-editor.org/rfc/inline-errata/rfc3261.html#btn_1470>, EID
2051 <https://www.rfc-editor.org/rfc/inline-errata/rfc3261.html#btn_2051>, EID
3183 <https://www.rfc-editor.org/rfc/inline-errata/rfc3261.html#btn_3183>, EID
4567 <https://www.rfc-editor.org/rfc/inline-errata/rfc3261.html#btn_4567>

And if you click on the links, it shows you where each errata goes, and if
you click on "Expand", it shows you the Verified errata, and if the errata
had OLD/NEW text, the new text is shown inline.

So, what you get is something like this:

   The handling parameter, handling-param, describes how the UAS should Expand
react if it receives a message body whose content type or disposition
type it does not understand. The parameter has defined values of
"optional" and "required". If the handling parameter is missing, or if
the Content-Disposition header field is missing, the value "required"
SHOULD be assumed. The handling parameter is described in RFC 3204 [19].

*EID 4567 <https://www.rfc-editor.org/errata/eid4567> (Verified) is as follows:*
*Section:* 20.11
*Original Text:*

The handling parameter, handling-param, describes how the UAS should
react if it receives a message body whose content type or disposition
type it does not understand. The parameter has defined values of
"optional" and "required". If the handling parameter is missing, the
value "required" SHOULD be assumed. The handling parameter is
described in RFC 3204 [19].
*Corrected Text:*

The handling parameter, handling-param, describes how the UAS should
react if it receives a message body whose content type or disposition
type it does not understand. The parameter has defined values of
"optional" and "required". If the handling parameter is missing, or if
the Content-Disposition header field is missing, the value "required"
SHOULD be assumed. The handling parameter is described in RFC 3204 [19].

*Notes:*
None

So, they're SUPER excited about making use of this mechanism, and we can
talk about whether people really read Public Service Announcements *("This
is a purely informative rendering of an RFC that includes verified errata.
This rendering may not be used as a reference.") *- but can we blame them
for *wanting *to do that?

So, ISTM that what our current errata system was set up to do (and I can't
emphasize enough that I wasn't there when it was set up), was to Reject
stuff that wasn't REALLY an errata or obviously not the right correction to
make, Verify obvious corrections, and Hold Everything Else For Document
Updates, so that a working group has a chance to talk about what The Right
Thing To Do is, given that they missed something Technical when they looked
at this for the first time, as opposed to having an AD decide *now* what
The Right Thing To Do will be at some point in the future, and constraining
the working group when they *do* have enough brain cells to update the
document. (If that's not the case, my apologies to the people who set it up
in the first place).

If we wanted to make life easier for people using IETF specifications (as
opposed to going to the Github repos and "making" their own specifications
from Master/Main branches, we might think about

   - How much we want to "warn people away" from using the really helpful
   errata inlining mechanism that is already available from the RFC Editor,
   and
   - How much stuff that's not Verified would be useful to present to the
   people who use our documents - especially stuff that's Rejected because it
   doesn't reflect the thinking of (my own favorite) the NFSv4 working group
   more than a decade ago, but is really close to what they are thinking today.

As always, thanks for listening. And Do The Right Thing.

Best,

Spencer, who used the tools format of RFCs in HTML almost exclusively for
at least a decade, and then switched to the datatracker HTML format,
neither of which were the canonical txt-then, XML-now formats that we wish
people would use.

---

From: [email-masked]
Date: Mon, 10 May 2021 08:31:41 +0200

> I think something is needed where the reported problem can be accepted, but the fix can be rejected.    Perhaps some new states, or a change to how the Errata system works.

I fully agree with that.
I have also seen cases where errata is wrong or even has been used as a way to try to change a specifictation.

The current errata system allows anyone to attach whatever they like without review to a published document.
I don't know how to fix this, but it might include changes to process, tools and presentation.
A clearer distinction between a reported document bug and a verified errata could be a start.

Best regards,
Ole

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 10 May 2021 08:58:43 +0200

> A clearer distinction between a reported document bug and a verified errata could be a start.

Yes.  

(1) We need to stop calling errata reports that are not (yet) verified, “errata”.

The errata are the problems that we *agree* exist.
(Each single such problem is an erratum, BTW.)

Section 4.8.6.5 of RFC 7322 MUST die, die, die.

(My own errata report about the incorrect terminology of that section was almost rejected…  https://www.rfc-editor.org/errata/eid6347 (*))

(2) When an errata report is indeed verified, it should be OPTIONAL whether the suggested solution is also verified.  I’m not unhappy about the idea of last-calling an actual solution instead, after it has been discussed and shaped by authors and the WG (or the WG’s old mailing list, or a dispatch WG if that doesn’t exist).

Grüße, Carsten

(*)  [Err4409] [Err4963] [Err4964] were attempts to change the (admittedly not so bright, after all) WG consensus after the fact.  They are still cited as “errata” in RFC 8949 in Appendix G, where we discuss how we handled the errata reports on its predecessor RFC 7049.  Reason did not prevail over Section 4.8.6.5.

---

From: Lloyd W <[email-masked]>
Date: Mon, 10 May 2021 18:35:17 +1000

if we're changing how this works...

the singular of errata is erratum

one erratum, many errata
one criterion, many criteria
one datum, many data

one didactic pedant, many ...

sigh

Lloyd Wood
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Mon, 10 May 2021 10:18:42 -0400

> So how do I find unhandled errata reports for all RFCs that I’m a co-author on?

Ultimately, that's the workflow that we need to enable.
It's not just the finding, it's getting the response into a clear place so
that the AD can easily digest and approve without spending multiple hours
per.

---

From: Alvaro Retana <[email-masked]>
Date: Mon, 10 May 2021 15:22:03 -0400

On May 8, 2021 at 6:53:46 PM, Bob Hinden wrote:

Bob:

Hi!

...
> I think something is needed where the reported problem can be accepted, but
> the fix can be rejected. Perhaps some new states, or a change to how the
> Errata system works.

You're right, *without proper explanation*, there is no explicit state
that indicates a valid problem and an invalid solution.  Hold for
Document Update is the closest as further discussion is obviously
needed.

However, even with a proper explanation, it may still be confusing
whether the proposed solution is valid or not.  One of the issues is
that there is a single notes field that is used by both the submitter
and the verifier.  Also, these notes appear *after* the
problem/solution have been described, making it harder to find
relevant comments.

Changing how the errata system works requires a wider discussion of
course -- beyond what the current statement is intended for.

Thanks!

Alvaro.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 May 2021 09:13:53 +1200

>>  https://www.rfc-editor.org/errata_search.php?rec_status=2&area_acronym=tsv&errata_type=2&presentation=table

Yes, thanks. So we can quickly see that there are 556 unhandled errata, and the oldest ones were reported in 2010. That seems to be about 8% of the total errata ever reported. Is this a problem worth fixing?

On the entertainment side, there's one very plausible erratum on RFC1321 (MD5) reported last year, and one on RFC 1180, the "TCP/IP tutorial" from 
1991, reported in 2017.

And in case anybody's wondering, I did *not* report the erratum #5209 on RFC1001. But it might well be valid.

    Brian

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 11 May 2021 10:53:54 +0100

> On 10 May 2021, at 20:22, Alvaro Retana <[email-masked]> wrote:
> 

The AD can edit the text and provide a solution that works.

If there is a problem but no solution that would be quite worrying.

- Stewart

---

From: Bob Hinden <[email-masked]>
Date: Tue, 11 May 2021 09:36:44 -0700

Alvaro,

> On May 10, 2021, at 12:22 PM, Alvaro Retana <[email-masked]> wrote:
> 

I agree, I wanted to start that discussion.    However, it might be good if the IESG statement mentioned this issue.

I note this is a real issue based on several Errata filed on IPv6 RFCs produced by 6MAN.   It was dealt with by rejecting the errata and filing a new one with a solution that the w.g. agree to.   Hardly an ideal situation and would have been avoided if problem reporting was separated from fixes.

Bob

---

From: John C Klensin <[email-masked]>
Date: Tue, 11 May 2021 15:24:46 -0400

> The AD can edit the text and provide a solution that works.

And which has IETF consensus?   Again, disclaimers aside (see
Spencer's note), the more we formalize this -- or, to some
extent, view lists of errata and fixes as more than guidance to
the next WG to come along to work on the document -- the more we
create a confusing situation about what implementers are
actually expected to believe.  So, if there is significant
controversy about whether the actual correct solution is, I'd
rather see the notes be explicit about that, rather than
describing "a solution that works" rather than an agreed-upon
best solution.

> If there is a problem but no solution that would be quite

Isn't that at least part of what "hold for document update" is
for.  I.e., we've identified the problem but determining which
solution is good enough to get (or even presume) IETF consensus
is going to take more study and group involvement.

I don't know how many of them there have been in recent years
but, as someone generating a report about something I claim is
an error, I think it is important that I be about to say "this
particular section or provision is clearly wrong because...
But I either don't have a clue about how it should be fixed or
can propose three alternatives that seem reasonable".  That
would be consistent with many comments we've seen on this (and
other) IETF lists over the years in which someone who flags a
problem doesn't really care how it is resolved as long as the
decision is clear and well-documented.

I'd hope that, unless it was possible to reject the claimed
error, any of those cases would go swiftly and efficiently into
"Hold for document revision" rather than, e.g., an AD trying to
figure out the right answer on their own.

   john

best,
    john

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 11 May 2021 22:51:47 +0100

Sent from my iPad

> On 11 May 2021, at 20:24, John C Klensin <[email-masked]> wrote:
> 
> 
> 
> And which has IETF consensus?  

In  the majority of cases the resolution of an erratum  is a simple obvious fix. 

Stewart

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 12 May 2021 01:15:03 +0200

> In  the majority of cases the resolution of an erratum  is a simple obvious fix. 

Simple, obvious, and wrong? [1]

SCNR, but it sure makes sense to discuss such a fix in a wider audience.

Grüße, Carsten

[1]: https://quoteinvestigator.com/2016/07/17/solution/

---

From: John C Klensin <[email-masked]>
Date: Tue, 11 May 2021 19:38:48 -0400

>> On 11 May 2021, at 20:24, John C Klensin <[email-masked]>
ഀ਀㸀㸀 ഀ਀㸀㸀 ⴀⴀ伀渀 吀甀攀猀搀愀礀Ⰰ 䴀愀礀 ㄀㄀Ⰰ ㈀　㈀㄀ ㄀　㨀㔀㌀ ⬀　㄀　　 匀琀攀眀愀爀琀 䈀爀礀愀渀琀ഀ਀㸀㸀 㰀猀琀攀眀愀爀琀⸀戀爀礀愀渀琀䀀最洀愀椀氀⸀挀漀洀㸀 眀爀漀琀攀㨀ഀ਀㸀㸀 ഀ਀㸀㸀㸀 ⸀⸀⸀ഀ਀㸀㸀㸀 吀栀攀 䄀䐀 挀愀渀 攀搀椀琀 琀栀攀 琀攀砀琀 愀渀搀 瀀爀漀瘀椀搀攀 愀 猀漀氀甀琀�
�漀渀 琀栀愀琀 眀漀爀欀猀⸀ഀ਀㸀㸀 ഀ਀㸀㸀 䄀渀搀 眀栀椀挀栀 栀愀猀 䤀䔀吀䘀 挀漀渀猀攀渀猀甀猀㼀  ഀ਀㸀 ഀ਀㸀 䤀渀  琀栀攀 洀愀樀漀爀椀琀礀 漀昀 挀愀猀攀猀 琀栀攀 爀攀猀漀氀甀琀椀漀渀 漀昀 愀渀 攀爀爀愀琀甀洀  椀猀 愀ഀ਀㸀 猀椀洀瀀氀攀 漀戀瘀椀漀甀猀 昀椀砀⸀ ഀ਀ഀ਀䤀 愀最爀攀攀 愀戀漀甀琀 琀�
��攀 洀愀樀漀爀椀琀礀 愀渀搀 眀漀甀氀搀 愀最爀攀攀 攀瘀攀渀 洀漀爀攀 椀昀 礀漀甀 栀愀搀 猀愀椀搀 猀漀洀攀琀栀椀渀最 琀栀愀琀 眀漀甀氀搀 栀愀瘀攀 椀渀挀氀甀搀攀搀 琀栀攀 瀀爀漀戀氀攀洀 戀攀椀渀最 漀戀瘀椀漀甀猀 漀渀挀攀 椀琀 眀愀猀 椀搀攀渀琀椀昀椀攀搀 戀礀 琀栀攀 爀攀瀀漀爀琀攀搀 攀爀爀愀琀甀洀⸀ ഀ਀ഀ਀
䠀漀眀攀瘀攀爀Ⰰ 愀猀 甀猀甀愀氀 ⠀愀渀搀 愀昀琀攀爀 猀漀洀攀 搀椀昀昀椀挀甀氀琀 攀砀瀀攀爀椀攀渀挀攀猀⤀Ⰰ 䤀✀洀 挀漀渀挀攀爀渀攀搀 愀戀漀甀琀 琀栀攀 漀渀攀猀 琀栀愀琀 椀渀瘀漀氀瘀攀 渀漀渀ⴀ漀戀瘀椀漀甀猀 瀀爀漀戀氀攀洀猀 愀渀搀⼀漀爀 渀漀渀ⴀ漀戀瘀椀漀甀猀 昀椀砀攀猀Ⰰ 攀猀瀀攀挀椀愀氀氀礀 琀栀攀 漀渀攀猀�
�琀栀愀琀 猀琀攀洀 昀爀漀洀 攀椀琀栀攀爀 漀瘀攀爀猀椀最栀琀猀 椀渀 琀栀攀 搀爀愀昀琀椀渀最 愀渀搀 愀瀀瀀爀漀瘀愀氀 漀昀 琀栀攀 漀爀椀最椀渀愀氀 搀漀挀甀洀攀渀琀猀 漀爀 搀椀猀愀最爀攀攀洀攀渀琀猀 愀戀漀甀琀 眀栀愀琀 琀栀攀 眀漀爀搀猀 琀栀愀琀 愀爀攀 愀氀爀攀愀搀礀 琀栀攀爀攀 洀攀愀渀⸀ഀ਀ഀ਀䤀昀 眀攀 愀爀�
�� 挀漀渀挀攀爀渀攀搀 漀渀氀礀 愀戀漀甀琀 琀栀攀 洀愀樀漀爀椀琀礀 漀昀 挀愀猀攀猀Ⰰ 䤀 挀愀渀 瀀爀漀瀀漀猀攀 愀 洀甀挀栀 洀漀爀攀 猀椀洀瀀氀攀 愀渀搀 氀攀猀猀 琀椀洀攀ⴀ挀漀渀猀甀洀椀渀最 瀀爀漀挀攀搀甀爀攀 琀栀愀渀 琀栀攀 漀渀氀礀 挀漀瘀攀爀攀搀 椀渀 琀栀攀 䤀䔀匀䜀 猀琀愀琀攀洀攀渀琀Ⰰ 挀漀渀猀椀猀琀椀渀
最 漀昀 昀漀甀爀 猀琀攀瀀猀㨀ഀ਀ഀ਀⠀　⤀ 䤀昀 琀栀攀 搀漀挀甀洀攀渀琀 眀愀猀 瀀爀漀搀甀挀攀搀 戀礀 愀 猀琀椀氀氀ⴀ愀挀琀椀瘀攀 圀䜀Ⰰ 琀栀攀 刀䘀䌀 䔀搀椀琀漀爀 昀漀爀眀愀爀搀猀 琀栀攀 爀攀瀀漀爀琀 琀漀 琀栀攀洀 愀渀搀 琀栀攀礀 搀攀挀椀搀攀 眀栀愀琀 琀漀 搀漀 愀戀漀甀琀 椀琀Ⰰ 瀀攀爀栀愀瀀猀 愀猀欀�
�渀最 琀漀 洀漀搀椀昀礀 琀栀攀椀爀 挀栀愀爀琀攀爀 愀渀搀 焀甀攀甀椀渀最 甀瀀 愀 爀攀瘀椀猀椀漀渀 漀爀Ⰰ 漀瀀琀椀漀渀愀氀氀礀Ⰰ 搀攀挀椀搀椀渀最 椀琀 椀猀 愀渀 漀戀瘀椀漀甀猀 攀搀椀琀漀爀椀愀氀 瀀爀漀戀氀攀洀 琀栀愀琀 琀栀攀礀 搀漀渀✀琀 渀攀攀搀 琀漀 搀漀 愀渀礀琀栀椀渀最 愀戀漀甀琀Ⰰ 愀渀搀 瘀攀爀椀昀礀�
��琀栀攀 爀攀瀀漀爀琀⸀  伀爀 琀栀攀礀 挀漀渀挀氀甀搀攀 琀栀愀琀 琀栀攀 爀攀瀀漀爀琀 椀猀 椀渀挀漀爀爀攀挀琀 愀渀搀 爀攀樀攀挀琀 椀琀⸀ 伀爀 琀栀攀礀 挀漀渀挀氀甀搀攀 琀栀愀琀 琀栀攀礀 渀攀攀搀 琀漀 眀漀爀欀 漀渀 琀栀攀 搀漀挀甀洀攀渀琀Ⰰ 椀渀 眀栀椀挀栀 挀愀猀攀 琀栀攀 爀攀瀀漀爀琀 椀猀 洀愀爀欀攀搀 
∀栀漀氀搀 昀漀爀 搀漀挀甀洀攀渀琀 甀瀀搀愀琀攀∀⸀   䐀漀渀攀 椀渀 愀渀礀 挀愀猀攀 ⠀眀椀琀栀漀甀琀 琀栀攀 䤀䔀匀䜀 漀爀Ⰰ 漀琀栀攀爀 琀栀愀渀 昀漀爀眀愀爀搀椀渀最 琀栀攀 爀攀瀀漀爀琀 愀渀搀 甀瀀搀愀琀椀渀最 搀愀琀愀戀愀猀攀猀Ⰰ 琀栀攀 刀䘀䌀 䔀搀椀琀漀爀 最攀琀琀椀渀最 椀渀瘀漀氀瘀攀搀⤀⸀ഀ਀ഀ਀⠀㄀⤀�
�吀栀攀 刀䘀䌀 䔀搀椀琀漀爀Ⰰ 椀渀 挀漀渀猀甀氀琀愀琀椀漀渀 眀椀琀栀 琀栀攀 愀甀琀栀漀爀⠀猀⤀ 洀愀欀攀猀 愀 搀攀琀攀爀洀椀渀愀琀椀漀渀 愀猀 琀漀 眀栀攀琀栀攀爀 椀琀 椀猀 愀渀 攀搀椀琀漀爀椀愀氀 椀猀猀甀攀 眀椀琀栀 愀渀 漀戀瘀椀漀甀猀 昀椀砀⸀  䤀昀 ∀礀攀猀∀Ⰰ 琀栀攀 爀攀瀀漀爀琀 椀猀 瘀攀爀椀昀椀攀搀�
��椀猀 琀栀攀 瀀爀漀挀攀猀猀 攀渀搀猀⸀  伀琀栀攀爀眀椀猀攀 最漀 琀漀 猀琀攀瀀 ㈀⸀ഀ਀ഀ਀⠀㈀⤀ 吀栀攀 搀漀挀甀洀攀渀琀 椀猀 昀漀爀眀愀爀搀攀搀 琀漀 琀栀攀 䤀䔀匀䜀 眀栀攀爀攀 愀 搀攀琀攀爀洀椀渀愀琀椀漀渀 椀猀 洀愀搀攀 愀戀漀甀琀 眀栀椀挀栀 䄀䐀 猀栀漀甀氀搀 戀攀 爀攀猀瀀漀渀猀椀戀氀攀 昀漀爀 椀琀⸀ 
  䤀昀 琀栀攀 䄀䐀Ⰰ 椀渀 挀漀渀樀甀渀挀琀椀漀渀 眀椀琀栀 愀甀琀栀漀爀⠀猀⤀Ⰰ 瀀爀攀猀攀渀琀 漀爀 昀漀爀洀攀爀 圀䜀 挀栀愀椀爀猀Ⰰ 愀渀搀 愀渀礀漀渀攀 攀氀猀攀 琀栀攀礀 昀攀攀氀 洀漀琀椀瘀愀琀攀搀 琀漀 挀漀渀猀甀氀琀Ⰰ 搀攀挀椀搀攀猀 琀栀愀琀 戀漀琀栀 琀栀攀 瀀爀漀戀氀攀洀 愀渀搀 琀栀攀 猀漀氀甀琀椀漀�
� 愀爀攀 漀戀瘀椀漀甀猀 漀爀 琀栀愀琀 琀栀攀 瀀爀漀戀氀攀洀 猀琀愀琀攀洀攀渀琀 椀猀 椀渀挀漀爀爀攀挀琀Ⰰ 琀栀攀礀 瘀攀爀椀昀礀 漀爀 爀攀樀攀挀琀 琀栀攀 攀爀爀愀琀甀洀 爀攀猀瀀攀挀琀椀瘀攀氀礀⸀  伀琀栀攀爀眀椀猀攀Ⰰ 最漀 琀漀 匀琀攀瀀 ㌀⸀ഀ਀ഀ਀⠀㌀⤀ 䴀愀爀欀 琀栀攀 爀攀瀀漀爀琀 愀猀 ∀栀漀氀搀 昀漀爀�
��搀漀挀甀洀攀渀琀 爀攀瘀椀猀椀漀渀∀⸀ഀ਀ഀ਀吀栀愀琀 爀攀搀甀挀攀猀 眀漀爀欀氀漀愀搀 漀渀 琀栀攀 䤀䔀匀䜀 攀瘀攀爀 洀漀爀攀 琀栀愀渀 琀栀攀 挀甀爀爀攀渀琀 猀琀愀琀攀洀攀渀琀⸀ 䤀琀猀 椀洀瀀氀椀挀愀琀椀漀渀 椀猀 琀栀愀琀Ⰰ 椀昀 愀 爀攀瀀漀爀琀 爀攀焀甀椀爀攀猀 愀渀礀 搀攀攀瀀 琀栀椀渀欀椀渀最 漀爀 爀攀愀氀
氀礀 猀攀爀椀漀甀猀 攀砀愀洀椀渀愀琀椀漀渀 漀爀 搀椀猀挀甀猀猀椀漀渀 开愀琀 愀氀氀开 琀栀攀 愀瀀瀀爀漀瀀爀椀愀琀攀 搀椀猀瀀漀猀椀琀椀漀渀 椀猀 ∀爀攀瀀漀爀琀攀搀Ⰰ 栀漀氀搀 昀漀爀 搀漀挀甀洀攀渀琀 爀攀瘀椀猀椀漀渀∀⸀ഀ਀ഀ਀戀攀猀琀Ⰰഀ਀   樀漀栀渀ഀ਀ഀ਀瀀⸀猀⸀ 一漀琀攀 琀栀愀琀 ⠀㈀⤀ 挀愀渀 戀攀 昀甀�
�琀栀攀爀 猀琀爀攀愀洀氀椀渀攀搀 昀漀爀 搀漀挀甀洀攀渀琀猀 昀漀爀 眀栀椀挀栀 琀栀攀爀攀 椀猀 愀 猀甀爀瘀椀瘀椀渀最 洀愀椀氀椀渀最 氀椀猀琀 昀爀漀洀 琀栀攀 圀䜀 漀爀 琀愀欀椀渀最 漀瘀攀爀 椀琀猀 搀椀猀挀甀猀猀椀漀渀猀㨀  刀攀瀀漀爀琀 最漀攀猀 琀漀 漀渀攀 漀昀 琀栀攀 䄀䐀猀 椀渀 琀栀攀 洀漀猀琀 渀攀愀爀�
��礀 爀攀氀攀瘀愀渀琀 䄀爀攀愀⸀  吀栀攀礀 昀椀最甀爀攀 漀甀琀 栀漀眀 椀琀 椀猀 琀漀 戀攀 栀愀渀搀氀攀搀 ⠀漀戀瘀椀漀甀猀 椀昀 漀渀攀 漀昀 琀栀攀洀 眀愀猀 爀攀猀瀀漀渀猀椀戀氀攀 昀漀爀 椀琀⤀⸀  吀栀愀琀 䄀䐀Ⰰ 眀椀琀栀漀甀琀 挀漀渀猀甀氀琀椀渀最 愀渀礀漀渀攀Ⰰ 洀愀欀攀猀 愀 搀攀挀椀猀椀漀渀 愀戀漀甀琀
 漀戀瘀椀漀甀猀渀攀猀猀⸀   䤀昀 漀戀瘀椀漀甀猀Ⰰ 愀 渀漀琀攀 椀猀 猀攀渀琀 琀漀 琀栀攀 洀愀椀氀椀渀最 氀椀猀琀 椀搀攀渀琀椀昀礀椀渀最 琀栀攀 瀀爀漀瀀漀猀攀搀 猀漀氀甀琀椀漀渀 愀渀搀 猀瀀攀挀椀昀礀椀渀最 愀 琀椀洀攀漀甀琀⸀  匀椀氀攀渀挀攀 椀渀搀椀挀愀琀攀猀 挀漀渀猀攀渀琀 琀漀 攀椀琀栀攀爀 瘀攀爀椀昀礀�
�渀最 漀爀 爀攀樀攀挀琀椀渀最 琀栀攀 爀攀瀀漀爀琀 愀猀 琀栀攀 䄀䐀 瀀爀漀瀀漀猀攀猀⸀  䄀渀礀 猀攀爀椀漀甀猀 猀椀最渀猀 漀昀 挀漀渀琀爀漀瘀攀爀猀礀 愀渀搀 琀栀攀 搀漀挀甀洀攀渀琀 最攀琀猀 洀愀爀欀攀搀 ∀栀漀氀搀⸀⸀⸀∀ 愀渀搀 攀瘀攀爀礀漀渀攀 洀漀瘀攀猀 漀渀⸀ഀ਀ഀ਀瀀⸀瀀⸀猀⸀ 吀栀攀爀攀 愀爀攀 漀戀瘀�
��漀甀猀 漀瀀瀀漀爀琀甀渀椀琀椀攀猀 昀漀爀 䐀漀匀 愀琀琀愀挀欀猀 漀渀 攀椀琀栀攀爀 琀栀攀 愀戀漀瘀攀 愀瀀瀀爀漀愀挀栀 漀爀 琀栀攀 漀渀攀 椀渀 琀栀攀 䤀䔀匀䜀 猀琀愀琀攀洀攀渀琀Ⰰ 戀甀琀 琀栀愀琀 椀猀 眀栀礀 眀攀 栀愀瘀攀 瀀爀漀挀攀搀甀爀攀猀 昀漀爀 搀攀愀氀椀渀最 眀椀琀栀 瀀攀漀瀀氀攀 眀栀漀 愀爀攀 搀椀
猀爀甀瀀琀椀瘀攀⸀ഀ਀ഀ਀ഀ਀

---

From: Ole Jacobsen <[email-masked]>
Date: Tue, 11 May 2021 16:46:31 -0700

It would appear you've changed personality and character set, John.

:-)

> On May 11, 2021, at 16:38, John C Klensin <[email-masked]> wrote:
> 
> 
> 
> �攀 洀愀樀漀爀椀琀礀 愀渀搀 眀漀甀氀搀 愀最爀攀攀 攀瘀攀渀 洀漀爀攀 椀昀 礀漀甀 栀愀搀 猀愀椀搀 猀漀洀攀琀栀椀渀最 琀栀愀琀 眀漀甀氀搀 栀愀瘀攀 椀渀挀氀甀搀攀搀 琀栀攀 瀀爀漀戀氀攀洀 戀攀椀渀最 漀戀瘀椀漀甀猀 漀渀挀攀 椀琀 眀愀猀 椀搀攀渀琀椀昀椀攀搀 戀礀 琀栀攀 爀攀瀀漀爀琀攀搀 攀爀爀愀琀甀洀⸀ ഀ਀ഀ਀
> � 挀漀渀挀攀爀渀攀搀 漀渀氀礀 愀戀漀甀琀 琀栀攀 洀愀樀漀爀椀琀礀 漀昀 挀愀猀攀猀Ⰰ 䤀 挀愀渀 瀀爀漀瀀漀猀攀 愀 洀甀挀栀 洀漀爀攀 猀椀洀瀀氀攀 愀渀搀 氀攀猀猀 琀椀洀攀ⴀ挀漀渀猀甀洀椀渀最 瀀爀漀挀攀搀甀爀攀 琀栀愀渀 琀栀攀 漀渀氀礀 挀漀瘀攀爀攀搀 椀渀 琀栀攀 䤀䔀匀䜀 猀琀愀琀攀洀攀渀琀Ⰰ 挀漀渀猀椀猀琀椀渀
> �琀栀攀 爀攀瀀漀爀琀⸀  伀爀 琀栀攀礀 挀漀渀挀氀甀搀攀 琀栀愀琀 琀栀攀 爀攀瀀漀爀琀 椀猀 椀渀挀漀爀爀攀挀琀 愀渀搀 爀攀樀攀挀琀 椀琀⸀ 伀爀 琀栀攀礀 挀漀渀挀氀甀搀攀 琀栀愀琀 琀栀攀礀 渀攀攀搀 琀漀 眀漀爀欀 漀渀 琀栀攀 搀漀挀甀洀攀渀琀Ⰰ 椀渀 眀栀椀挀栀 挀愀猀攀 琀栀攀 爀攀瀀漀爀琀 椀猀 洀愀爀欀攀搀 
> �椀猀 琀栀攀 瀀爀漀挀攀猀猀 攀渀搀猀⸀  伀琀栀攀爀眀椀猀攀 最漀 琀漀 猀琀攀瀀 ㈀⸀ഀ਀ഀ਀⠀㈀⤀ 吀栀攀 搀漀挀甀洀攀渀琀 椀猀 昀漀爀眀愀爀搀攀搀 琀漀 琀栀攀 䤀䔀匀䜀 眀栀攀爀攀 愀 搀攀琀攀爀洀椀渀愀琀椀漀渀 椀猀 洀愀搀攀 愀戀漀甀琀 眀栀椀挀栀 䄀䐀 猀栀漀甀氀搀 戀攀 爀攀猀瀀漀渀猀椀戀氀攀 昀漀爀 椀琀⸀ 
> �搀漀挀甀洀攀渀琀 爀攀瘀椀猀椀漀渀∀⸀ഀ਀ഀ਀吀栀愀琀 爀攀搀甀挀攀猀 眀漀爀欀氀漀愀搀 漀渀 琀栀攀 䤀䔀匀䜀 攀瘀攀爀 洀漀爀攀 琀栀愀渀 琀栀攀 挀甀爀爀攀渀琀 猀琀愀琀攀洀攀渀琀⸀ 䤀琀猀 椀洀瀀氀椀挀愀琀椀漀渀 椀猀 琀栀愀琀Ⰰ 椀昀 愀 爀攀瀀漀爀琀 爀攀焀甀椀爀攀猀 愀渀礀 搀攀攀瀀 琀栀椀渀欀椀渀最 漀爀 爀攀愀氀
> �礀 爀攀氀攀瘀愀渀琀 䄀爀攀愀⸀  吀栀攀礀 昀椀最甀爀攀 漀甀琀 栀漀眀 椀琀 椀猀 琀漀 戀攀 栀愀渀搀氀攀搀 ⠀漀戀瘀椀漀甀猀 椀昀 漀渀攀 漀昀 琀栀攀洀 眀愀猀 爀攀猀瀀漀渀猀椀戀氀攀 昀漀爀 椀琀⤀⸀  吀栀愀琀 䄀䐀Ⰰ 眀椀琀栀漀甀琀 挀漀渀猀甀氀琀椀渀最 愀渀礀漀渀攀Ⰰ 洀愀欀攀猀 愀 搀攀挀椀猀椀漀渀 愀戀漀甀琀
> �漀甀猀 漀瀀瀀漀爀琀甀渀椀琀椀攀猀 昀漀爀 䐀漀匀 愀琀琀愀挀欀猀 漀渀 攀椀琀栀攀爀 琀栀攀 愀戀漀瘀攀 愀瀀瀀爀漀愀挀栀 漀爀 琀栀攀 漀渀攀 椀渀 琀栀攀 䤀䔀匀䜀 猀琀愀琀攀洀攀渀琀Ⰰ 戀甀琀 琀栀愀琀 椀猀 眀栀礀 眀攀 栀愀瘀攀 瀀爀漀挀攀搀甀爀攀猀 昀漀爀 搀攀愀氀椀渀最 眀椀琀栀 瀀攀漀瀀氀攀 眀栀漀 愀爀攀 搀椀
> 猀爀甀瀀琀椀瘀攀⸀ഀ਀ഀ਀ഀ਀
> 

Ole J. Jacobsen
Editor and Publisher
The Internet Protocol Journal
Office: +1 415-550-9433
Cell:   +1 415-370-4628
Web: protocoljournal.org
E-mail: [email-masked]
E-mail: [email-masked]
Skype: organdemo

---

From: John C Klensin <[email-masked]>
Date: Tue, 11 May 2021 20:28:40 -0400

Drat.  Caught by that again -- first time in a long time it has
shown up with an inline response.

Will try to reconstruct and resend.

thanks,
   john

>>>> On 11 May 2021, at 20:24, John C Klensin <[email-masked]>
ഀ਀㸀㸀㸀 ഀ਀㸀㸀㸀 ⴀⴀ伀渀 吀甀攀猀搀愀礀Ⰰ 䴀愀礀 ㄀㄀Ⰰ ㈀　㈀㄀ ㄀　㨀㔀㌀ ⬀　㄀　　 匀琀攀眀愀爀琀 䈀爀礀愀渀琀ഀ਀㸀㸀㸀 㰀猀琀攀眀愀爀琀⸀戀爀礀愀渀琀䀀最洀愀椀氀⸀挀漀洀㸀 眀爀漀琀攀㨀ഀ਀㸀㸀㸀 ഀ਀㸀㸀㸀㸀 ⸀⸀⸀ഀ਀㸀㸀㸀㸀 吀栀攀 䄀䐀 挀愀渀 攀搀椀琀 琀栀攀 琀攀砀琀 愀渀搀 瀀爀漀瘀椀搀攀 愀�
�਀㸀㸀㸀㸀 猀漀氀甀琀�
�漀渀 琀栀愀琀 眀漀爀欀猀⸀ഀ਀㸀㸀㸀 ഀ਀㸀㸀㸀 䄀渀搀 眀栀椀挀栀 栀愀猀 䤀䔀吀䘀 挀漀渀猀攀渀猀甀猀㼀  ഀ਀㸀㸀 ഀ਀㸀㸀 䤀渀  琀栀攀 洀愀樀漀爀椀琀礀 漀昀 挀愀猀攀猀 琀栀攀 爀攀猀漀氀甀琀椀漀渀 漀昀 愀渀 攀爀爀愀琀甀洀  椀猀 愀ഀ਀㸀㸀 猀椀洀瀀氀攀 漀戀瘀椀漀甀猀 昀椀砀⸀ ഀ਀㸀 ഀ਀㸀 䤀 愀最爀�
�攀 愀戀漀甀琀 琀�
�攀 洀愀樀漀爀椀琀礀 愀渀搀 眀漀甀氀搀 愀最爀攀攀ഀ਀㸀 攀瘀攀渀 洀漀爀攀 椀昀 礀漀甀 栀愀搀 猀愀椀搀 猀漀洀攀琀栀椀渀最 琀栀愀琀 眀漀甀氀搀 栀愀瘀攀 椀渀挀氀甀搀攀搀ഀ਀㸀 琀栀攀 瀀爀漀戀氀攀洀 戀攀椀渀最 漀戀瘀椀漀甀猀 漀渀挀攀 椀琀 眀愀猀 椀搀攀渀琀椀昀椀攀搀 戀礀 琀栀攀ഀ਀㸀 爀攀瀀漀爀琀攀搀 攀爀爀�
�琀甀洀⸀ ഀ਀㸀 ഀ਀㸀 
䠀漀眀攀瘀攀爀Ⰰ 愀猀 甀猀甀愀氀 ⠀愀渀搀 愀昀琀攀爀 猀漀洀攀 搀椀昀昀椀挀甀氀琀ഀ਀㸀 攀砀瀀攀爀椀攀渀挀攀猀⤀Ⰰ 䤀✀洀 挀漀渀挀攀爀渀攀搀 愀戀漀甀琀 琀栀攀 漀渀攀猀 琀栀愀琀 椀渀瘀漀氀瘀攀ഀ਀㸀 渀漀渀ⴀ漀戀瘀椀漀甀猀 瀀爀漀戀氀攀洀猀 愀渀搀⼀漀爀 渀漀渀ⴀ漀戀瘀椀漀甀猀 昀椀砀攀猀Ⰰ 攀猀瀀攀挀椀愀氀氀礀 琀栀�
�ഀ਀㸀 漀渀攀猀�
�琀栀愀琀 猀琀攀洀 昀爀漀洀 攀椀琀栀攀爀 漀瘀攀爀猀椀最栀琀猀 椀渀 琀栀攀ഀ਀㸀 搀爀愀昀琀椀渀最 愀渀搀 愀瀀瀀爀漀瘀愀氀 漀昀 琀栀攀 漀爀椀最椀渀愀氀 搀漀挀甀洀攀渀琀猀 漀爀ഀ਀㸀 搀椀猀愀最爀攀攀洀攀渀琀猀 愀戀漀甀琀 眀栀愀琀 琀栀攀 眀漀爀搀猀 琀栀愀琀 愀爀攀 愀氀爀攀愀搀礀 琀栀攀爀攀 洀攀愀渀⸀ഀ਀㸀 ഀ�
�㸀 䤀昀 眀攀 愀爀�
� 挀漀渀挀攀爀渀攀搀 漀渀氀礀 愀戀漀甀琀 琀栀攀 洀愀樀漀爀椀琀礀ഀ਀㸀 漀昀 挀愀猀攀猀Ⰰ 䤀 挀愀渀 瀀爀漀瀀漀猀攀 愀 洀甀挀栀 洀漀爀攀 猀椀洀瀀氀攀 愀渀搀 氀攀猀猀ഀ਀㸀 琀椀洀攀ⴀ挀漀渀猀甀洀椀渀最 瀀爀漀挀攀搀甀爀攀 琀栀愀渀 琀栀攀 漀渀氀礀 挀漀瘀攀爀攀搀 椀渀 琀栀攀 䤀䔀匀䜀ഀ਀㸀 猀琀愀琀攀洀攀渀琀Ⰰ�
�挀漀渀猀椀猀琀椀渀
最 漀昀 昀漀甀爀 猀琀攀瀀猀㨀ഀ਀㸀 ഀ਀㸀 ⠀　⤀ 䤀昀 琀栀攀 搀漀挀甀洀攀渀琀 眀愀猀 瀀爀漀搀甀挀攀搀 戀礀 愀 猀琀椀氀氀ⴀ愀挀琀椀瘀攀 圀䜀Ⰰ 琀栀攀 刀䘀䌀ഀ਀㸀 䔀搀椀琀漀爀 昀漀爀眀愀爀搀猀 琀栀攀 爀攀瀀漀爀琀 琀漀 琀栀攀洀 愀渀搀 琀栀攀礀 搀攀挀椀搀攀 眀栀愀琀 琀漀 搀漀ഀ਀㸀 愀戀漀甀琀 椀琀Ⰰ 瀀�
�爀栀愀瀀猀 愀猀欀�
�渀最 琀漀 洀漀搀椀昀礀 琀栀攀椀爀ഀ਀㸀 挀栀愀爀琀攀爀 愀渀搀 焀甀攀甀椀渀最 甀瀀 愀 爀攀瘀椀猀椀漀渀 漀爀Ⰰ 漀瀀琀椀漀渀愀氀氀礀Ⰰ 搀攀挀椀搀椀渀最 椀琀ഀ਀㸀 椀猀 愀渀 漀戀瘀椀漀甀猀 攀搀椀琀漀爀椀愀氀 瀀爀漀戀氀攀洀 琀栀愀琀 琀栀攀礀 搀漀渀✀琀 渀攀攀搀 琀漀 搀漀ഀ਀㸀 愀渀礀琀栀椀渀最 愀戀漀甀琀Ⰰ �
�渀搀 瘀攀爀椀昀礀�
�琀栀攀 爀攀瀀漀爀琀⸀  伀爀ഀ਀㸀 琀栀攀礀 挀漀渀挀氀甀搀攀 琀栀愀琀 琀栀攀 爀攀瀀漀爀琀 椀猀 椀渀挀漀爀爀攀挀琀 愀渀搀 爀攀樀攀挀琀 椀琀⸀ 伀爀ഀ਀㸀 琀栀攀礀 挀漀渀挀氀甀搀攀 琀栀愀琀 琀栀攀礀 渀攀攀搀 琀漀 眀漀爀欀 漀渀 琀栀攀 搀漀挀甀洀攀渀琀Ⰰ 椀渀 眀栀椀挀栀ഀ਀㸀 挀愀猀攀 琀栀攀 爀攀瀀漀爀琀 �
�猀 洀愀爀欀攀搀 
∀栀漀氀搀 昀漀爀 搀漀挀甀洀攀渀琀ഀ਀㸀 甀瀀搀愀琀攀∀⸀   䐀漀渀攀 椀渀 愀渀礀 挀愀猀攀 ⠀眀椀琀栀漀甀琀 琀栀攀 䤀䔀匀䜀 漀爀Ⰰ 漀琀栀攀爀 琀栀愀渀ഀ਀㸀 昀漀爀眀愀爀搀椀渀最 琀栀攀 爀攀瀀漀爀琀 愀渀搀 甀瀀搀愀琀椀渀最 搀愀琀愀戀愀猀攀猀Ⰰ 琀栀攀 刀䘀䌀 䔀搀椀琀漀爀ഀ਀㸀 最攀琀琀椀渀最 椀渀瘀漀氀瘀攀搀�
�⸀ഀ਀㸀 ഀ਀㸀 ⠀㄀⤀�
�吀栀攀 刀䘀䌀 䔀搀椀琀漀爀Ⰰ 椀渀 挀漀渀猀甀氀琀愀琀椀漀渀 眀椀琀栀 琀栀攀ഀ਀㸀 愀甀琀栀漀爀⠀猀⤀ 洀愀欀攀猀 愀 搀攀琀攀爀洀椀渀愀琀椀漀渀 愀猀 琀漀 眀栀攀琀栀攀爀 椀琀 椀猀 愀渀ഀ਀㸀 攀搀椀琀漀爀椀愀氀 椀猀猀甀攀 眀椀琀栀 愀渀 漀戀瘀椀漀甀猀 昀椀砀⸀  䤀昀 ∀礀攀猀∀Ⰰ 琀栀攀 爀攀瀀漀爀琀 椀猀ഀ਀�
� 瘀攀爀椀昀椀攀搀�
�椀猀 琀栀攀 瀀爀漀挀攀猀猀 攀渀搀猀⸀  伀琀栀攀爀眀椀猀攀 最漀ഀ਀㸀 琀漀 猀琀攀瀀 ㈀⸀ഀ਀㸀 ഀ਀㸀 ⠀㈀⤀ 吀栀攀 搀漀挀甀洀攀渀琀 椀猀 昀漀爀眀愀爀搀攀搀 琀漀 琀栀攀 䤀䔀匀䜀 眀栀攀爀攀 愀ഀ਀㸀 搀攀琀攀爀洀椀渀愀琀椀漀渀 椀猀 洀愀搀攀 愀戀漀甀琀 眀栀椀挀栀 䄀䐀 猀栀漀甀氀搀 戀攀 爀攀猀瀀漀渀猀椀戀�
�攀 昀漀爀ഀ਀㸀 椀琀⸀ 
  䤀昀 琀栀攀 䄀䐀Ⰰ 椀渀 挀漀渀樀甀渀挀琀椀漀渀 眀椀琀栀 愀甀琀栀漀爀⠀猀⤀Ⰰഀ਀㸀 瀀爀攀猀攀渀琀 漀爀 昀漀爀洀攀爀 圀䜀 挀栀愀椀爀猀Ⰰ 愀渀搀 愀渀礀漀渀攀 攀氀猀攀 琀栀攀礀 昀攀攀氀ഀ਀㸀 洀漀琀椀瘀愀琀攀搀 琀漀 挀漀渀猀甀氀琀Ⰰ 搀攀挀椀搀攀猀 琀栀愀琀 戀漀琀栀 琀栀攀 瀀爀漀戀氀攀洀 愀渀搀 琀栀攀ഀ਀�
� 猀漀氀甀琀椀漀�
� 愀爀攀 漀戀瘀椀漀甀猀 漀爀 琀栀愀琀 琀栀攀 瀀爀漀戀氀攀洀ഀ਀㸀 猀琀愀琀攀洀攀渀琀 椀猀 椀渀挀漀爀爀攀挀琀Ⰰ 琀栀攀礀 瘀攀爀椀昀礀 漀爀 爀攀樀攀挀琀 琀栀攀 攀爀爀愀琀甀洀ഀ਀㸀 爀攀猀瀀攀挀琀椀瘀攀氀礀⸀  伀琀栀攀爀眀椀猀攀Ⰰ 最漀 琀漀 匀琀攀瀀 ㌀⸀ഀ਀㸀 ഀ਀㸀 ⠀㌀⤀ 䴀愀爀欀 琀栀攀 爀攀瀀漀爀琀 愀�
� ∀栀漀氀搀 昀漀爀�
�搀漀挀甀洀攀渀琀ഀ਀㸀 爀攀瘀椀猀椀漀渀∀⸀ഀ਀㸀 ഀ਀㸀 吀栀愀琀 爀攀搀甀挀攀猀 眀漀爀欀氀漀愀搀 漀渀 琀栀攀 䤀䔀匀䜀 攀瘀攀爀 洀漀爀攀 琀栀愀渀 琀栀攀 挀甀爀爀攀渀琀ഀ਀㸀 猀琀愀琀攀洀攀渀琀⸀ 䤀琀猀 椀洀瀀氀椀挀愀琀椀漀渀 椀猀 琀栀愀琀Ⰰ 椀昀 愀 爀攀瀀漀爀琀 爀攀焀甀椀爀攀猀 愀渀礀ഀ਀㸀 搀攀攀瀀 琀栀�
�渀欀椀渀最 漀爀 爀攀愀氀
氀礀 猀攀爀椀漀甀猀 攀砀愀洀椀渀愀琀椀漀渀 漀爀ഀ਀㸀 搀椀猀挀甀猀猀椀漀渀 开愀琀 愀氀氀开 琀栀攀 愀瀀瀀爀漀瀀爀椀愀琀攀 搀椀猀瀀漀猀椀琀椀漀渀 椀猀 ∀爀攀瀀漀爀琀攀搀Ⰰഀ਀㸀 栀漀氀搀 昀漀爀 搀漀挀甀洀攀渀琀 爀攀瘀椀猀椀漀渀∀⸀ഀ਀㸀 ഀ਀㸀 戀攀猀琀Ⰰഀ਀㸀    樀漀栀渀ഀ਀㸀 ഀ਀㸀 瀀⸀猀⸀ 一漀琀攀 琀栀�
�琀 ⠀㈀⤀ 挀愀渀 戀攀 昀甀�
�琀栀攀爀 猀琀爀攀愀洀氀椀渀攀搀ഀ਀㸀 昀漀爀 搀漀挀甀洀攀渀琀猀 昀漀爀 眀栀椀挀栀 琀栀攀爀攀 椀猀 愀 猀甀爀瘀椀瘀椀渀最 洀愀椀氀椀渀最 氀椀猀琀 昀爀漀洀ഀ਀㸀 琀栀攀 圀䜀 漀爀 琀愀欀椀渀最 漀瘀攀爀 椀琀猀 搀椀猀挀甀猀猀椀漀渀猀㨀  刀攀瀀漀爀琀 最漀攀猀 琀漀 漀渀攀 漀昀ഀ਀㸀 琀栀攀 䄀䐀猀 椀渀 琀栀攀�
�洀漀猀琀 渀攀愀爀�
�礀 爀攀氀攀瘀愀渀琀 䄀爀攀愀⸀ഀ਀㸀 吀栀攀礀 昀椀最甀爀攀 漀甀琀 栀漀眀 椀琀 椀猀 琀漀 戀攀 栀愀渀搀氀攀搀 ⠀漀戀瘀椀漀甀猀 椀昀 漀渀攀 漀昀ഀ਀㸀 琀栀攀洀 眀愀猀 爀攀猀瀀漀渀猀椀戀氀攀 昀漀爀 椀琀⤀⸀  吀栀愀琀 䄀䐀Ⰰ 眀椀琀栀漀甀琀 挀漀渀猀甀氀琀椀渀最ഀ਀㸀 愀渀礀漀渀攀Ⰰ 洀愀欀攀猀 愀 搀攀挀椀猀�
�漀渀 愀戀漀甀琀
 漀戀瘀椀漀甀猀渀攀猀猀⸀   䤀昀ഀ਀㸀 漀戀瘀椀漀甀猀Ⰰ 愀 渀漀琀攀 椀猀 猀攀渀琀 琀漀 琀栀攀 洀愀椀氀椀渀最 氀椀猀琀 椀搀攀渀琀椀昀礀椀渀最 琀栀攀ഀ਀㸀 瀀爀漀瀀漀猀攀搀 猀漀氀甀琀椀漀渀 愀渀搀 猀瀀攀挀椀昀礀椀渀最 愀 琀椀洀攀漀甀琀⸀  匀椀氀攀渀挀攀 椀渀搀椀挀愀琀攀猀ഀ਀㸀 挀漀渀猀攀渀琀 琀漀 攀椀琀栀�
�爀 瘀攀爀椀昀礀�
�渀最 漀爀 爀攀樀攀挀琀椀渀最 琀栀攀ഀ਀㸀 爀攀瀀漀爀琀 愀猀 琀栀攀 䄀䐀 瀀爀漀瀀漀猀攀猀⸀  䄀渀礀 猀攀爀椀漀甀猀 猀椀最渀猀 漀昀 挀漀渀琀爀漀瘀攀爀猀礀ഀ਀㸀 愀渀搀 琀栀攀 搀漀挀甀洀攀渀琀 最攀琀猀 洀愀爀欀攀搀 ∀栀漀氀搀⸀⸀⸀∀ 愀渀搀 攀瘀攀爀礀漀渀攀 洀漀瘀攀猀 漀渀⸀ഀ਀㸀 ഀ਀㸀 瀀⸀瀀⸀猀⸀ 吀栀�
�爀攀 愀爀攀 漀戀瘀�
�漀甀猀 漀瀀瀀漀爀琀甀渀椀琀椀攀猀 昀漀爀ഀ਀㸀 䐀漀匀 愀琀琀愀挀欀猀 漀渀 攀椀琀栀攀爀 琀栀攀 愀戀漀瘀攀 愀瀀瀀爀漀愀挀栀 漀爀 琀栀攀 漀渀攀 椀渀 琀栀攀ഀ਀㸀 䤀䔀匀䜀 猀琀愀琀攀洀攀渀琀Ⰰ 戀甀琀 琀栀愀琀 椀猀 眀栀礀 眀攀 栀愀瘀攀 瀀爀漀挀攀搀甀爀攀猀 昀漀爀 搀攀愀氀椀渀最ഀ਀㸀 眀椀琀栀 瀀攀漀瀀氀攀 �
�栀漀 愀爀攀 搀椀
> 猀爀甀瀀琀椀瘀攀⸀ഀ਀㸀 ഀ਀㸀 ഀ਀㸀 

Ole J. Jacob൳ഀ਀㸀

---

From: John C Klensin <[email-masked]>
Date: Tue, 11 May 2021 21:17:21 -0400

(trying again.  Again, my apologies -- explanation on request)

> In  the majority of cases the resolution of an erratum  is a

Indeed.  And in even a larger majority of cases, it is obvious
that a reported erratum either correctly identified the problem
or resulted from significant confusion on the part of the
reporter (which might be a separate problem).

I'm concerned about the other cases, but your comment suggests
a way to streamline processing even more than the current IESG
Statement suggests. Consider the following steps after
submission:

(1) If the reported error is in a document produced by a WG
that is still active, the report goes to them. If they decide
they want to deal with it, they can either verify or reject or
just identify it as "Held for Document Update" (and,
potentially, decide to go to work on it). If they cannot reach
consensus (either on reviewing or on what action to take, the
status should clearly be "Held for Document Update". Other than
some quick administrative actions, neither the RFC Editor nor
any IESG member need to be involved. In any event, modulo the
usual appeal provisions, their decision is final.

(2) The RFC Editor, in consultation with the author(s), make a
determination of whether the matter is a simple editorial issue
and, if so, whether the proposed fix is correct. If the answer
to both questions is "yes", then the report is verified.
Otherwise, go to the next step.

(3) Some relevant AD (obviously the one who worked on the
document earlier if there is such a person) consults with
authors, present or former WG chairs, and, at their discretion,
other ADs and anyone else who seems relevant. They make a
determination as to whether the problem is correctly identified
and the proposed fix is correct, simple, and obvious. If those
who are consulted can reach consensus, the report is either
verified, rejected, or classified as "held for...". If they
cannot agree, the matter is sufficiently controversial that
"Held for Document Update" is the correct status
classification. It would be a good idea to announce that
decision to the community in case someone sees issues the
review team missed or otherwise objects but I'd see that as a
monthly or per-IETF-meeting summary, not noise on the IETF list
(or even a relevant ex-WG list) per reported error. 

So, if things are simple and obvious, they get dealt with very
quickly and efficiently. Or, if they are not, they get
classified as "Held for Document Update", which makes it
painfully clear to the reader that there is no IETF consensus
on the problem and solution. It also puts the decision as to
what to do about the report when there is no conensus back into
our normal process rather than using errata reports for
non-obvious problems or solutions as a means of changing
documents with little or no community input.

There is obvious potential for DoS attacks in both the above
and in the IETF Statement as it now stands, but our current
procedures for dealing with people who are disruptive ought to
be perfectly adequate to handle them.

best,
   john

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 12 May 2021 07:10:37 -0500

Top posting, just to say that we can talk about the details, but John's
proposal seems very helpful at putting the responsibility for errata
handling on an existing working group, that is at least theoretically
already chartered to work on a document update, rather than on an AD, who
is not.

Where there is no existing working group, we are no worse off than we are,
today.

So, I like this enough to encourage people to think about this proposal.

And if (for example) a TSV AD can look at an errata for an RFC that the
concluded MPTCP working group produced and say "the existing working group
that should handle this is TCPM", we'd be better off, except in cases where
a serious (and I presume technical) errata is submitted for an RFC that no
existing working group is chartered to work on.

Maybe that's not a huge problem. If it is, we can figure out what The Right
Thing To Do is for those cases, and do that.

Best,

Spencer

---

From: tom petch <[email-masked]>
Date: Wed, 12 May 2021 16:46:12 +0100

> (or even a relevant ex-WG list) per reported error.

John,

Mostly, I agree but would suggest two wrinkles.

One is that when the WG who produced the RFC is not longer active, there 
may be a successor WG which is competent to reach consensus on the 
erratum, e.g. ipsecme, lamps, and I think that whether or not such a 
group exists is a judgement call for an AD from the area, so I would 
insert such a step - pass to Area AD to see if another WG can step in - 
before going to the RFC Editor (whom I would not see as necessariy 
having skills in that field).

Second, you say that 'Hold for Document Update' makes it painfully clear 
that there is no IETF consensus on the problem.  I disagree.  The Editor 
page says that this status says that it is not a necessaary update, may 
be considered for a future update which to me has always implied that 
this may not be an error at all, rather out of scope at present, a 
request for a functional change, such as to make a product compliant to 
the RFC:-).  SO there may be a clear consensus, not right at this time.

Tom Petch

> .

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 12 May 2021 17:51:52 +0100

> On 12 May 2021, at 16:46, tom petch <[email-masked]> wrote:
> 
> Second, you say that 'Hold for Document Update' makes it painfully clear that there is no IETF consensus on the problem. I disagree.  The Editor page says that this status says that it is not a necessaary update, may be considered for a future update which to me has always implied that this may not be an error at all, rather out of scope at present, a request for a functional change, such as to make a product compliant to the RFC:-).  SO there may be a clear consensus, not right at this time.

Yes there are many reasons for HFDU. One is that the issue is a technical change that is out of scope for an erratum, but does need to be addressed when an updating or replacing RFC is published. It is assumed that the change is not urgent when HFDU is used,There is another that is closer to your point in that the erratum problem is valid, but would take significant work to address, and the base document itself is obsolete so no harm is done in leaving the issue on file.

So long as we have technical experts as ADs and not career specialist managers, the system we have with the significant degree of discretion that we impart to the ADs and associated errata classifications works acceptably well in my view.

If a fix to an erratum is incorrect it can always be replaced, a second erratum created or an updating RFC published. We should continue to use the  pragmatic and reasonably flexible process that exists and seems to work, rather than try to design a fixed “perfect” approach.

- Stewart