Hi, John,
On Mon, May 10, 2021 at 7:46 AM John C Klensin <john-ietf@xxxxxxx> wrote:
Spencer,
Trimming further -- your explanation about what has gone on / is
going on in the CELLAR WG was interesting and helpful, but I
have little or nothing to add that is specific to it. On the
other hand, a situation where there is an active WG that
developed the document on which errata were filed seems to me
much different -- and with far more opportunity for real
consensus about decisions-- than the more usual errata
situations. See below.
--On Sunday, May 9, 2021 16:45 -0500 Spencer Dawkins at IETF
<spencerdawkins.ietf@xxxxxxxxx> wrote:
>...
> 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).
But that view suggests that Bob's case of a proposed erratum
correctly identifying a problem but not the right fix should
lead to a Reject conclusion, and that does not seem quite right
either.
I'm sorry if I wasn't clear - the understanding I was describing was my own, in general, and definitely not talking specifically about CELLAR.
Your point above - about an active working group making informed decisions about a document that they had produced - is very much accurate for CELLAR. Reported errors (not from the errata system, but from implementers who likely would have no idea where to go to file an errata report on an RFC) are discussed promptly on the mailing list, and if it seems like there's more than one opinion, in the next monthly meeting (CELLAR has about 10 meetings per year), and pretty quickly, they know what the answer should be. But see below.
> 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.
For a situation where there is an active WG with the best
document as part of its charter, let me suggest something else,
starting with wondering whether the errata system is the right
approach at all. If, as I gather is the case you are talking
about, the WG gets a document published and then immediately
starts discovering bugs in it, isn't The Right Thing for the WG
to put a revision onto its agenda, get a new I-D started, and
put the corrections there? THere makes the status immediately
clear as "WG work in progress" without any handwaving about what
"Verified" actually means. A "Changes from RFC NNNN" section,
which would be desirable anyway, could explain things to the
degree desired. If the WG wanted to put a note on that I-D that
says that everything in it represents WG consensus, that would
be much more clear than the present errata process [1].
So, let's keep solving MY problem, which isn't what to do when CELLAR gets an error report, but about what to do after they agree that they need to do something to fix the specification.
Two things about that.
First, their RFC describes a markup language that they use to describe Matroska media containers, and their soon-to-be-PUB-REQUESTED draft describes pre-IETF versions of an archival video codec. What they really WANT to do is finish Matroska, which is (as best I can tell) their premier deliverable, and work on a new version of that archival video codec. They'd like their published specifications to be correct, but any effort they spend on corrections is taking away from effort that they can spend on their next deliverables. So, if the errata system worked the way we wish it would, that would be fine, but it just doesn't work the way we wish it would (for more reasons than I know).
So, the other thing is - I am not sure whether you are thinking of an UPDATES RFC NNNN WITH ERRATA draft, or an RFC NNNN-bis draft that replaces RFC NNNN, but each of these has its own special agony.
- If one were to take a look at https://datatracker.ietf.org/doc/rfc8540/ballot/, for an UPDATES RFC 4960 WITH ERRATA draft, they will be impressed that an Informational document saying "this is what the working group thinks of its errata" managed to gather (counting again) *9* abstains from ADs who (summarizing) said roughly "no value in publishing this, Should be a wiki page. Where's the RFC 4960-bis draft?" I don't know what the current IESG thinks about docs like this, but what the 2018 IESG thought about them is well-documented(1). Note that "publishing what the working group thinks about errata in a wiki page" is exactly what CELLAR is trying to avoid, and (for extra credit) might not even cross the inbox of an AD.
- If one were to take a look at https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc4960-bis/, the requested -bis draft, they would note that the UPDATES RFC 4960 WITH ERRATA draft was published almost exactly two years ago, and the REPLACES RFC 4960 draft is still sitting comfortably in the working group.
So, we still have some work to do here.
"We" being the IETF, and not just dumping this on the current IESG, unless they have a lot of time and energy on their hands.
I should semi-apologize to you for forgetting that you had written https://datatracker.ietf.org/doc/html/draft-klensin-newtrk-8540style-harmful-00 on this EXACT situation, but I even commented on it at the time (in discussion on IETF mailing list). So I know you see the problem pretty clearly.
(1) To be clear, this is NOT a knock on the 2018 IESG. I'm just pointing to a document I'm familiar with, as the then-responsible AD.
The missing link is something that might be desirable for many
other reasons: It seems to me that, if an RFC is actively under
revision in an IETF WG, an "under revision" note on the RFC
Editor's page for that RFC with a pointer to the WG charter
and/or the relevant I-D would be a big help to readers. It
would also capture the common case in which WGs make many
changes to a document on which errata are not filed.
However successful we are (or are not) at convincing people that
I-Ds are not standards, pointing a reader to a revision in
progress makes it clear that something is going on, may give
insights into the situation with the existing RFC. In the best
of all possible worlds, it might even encourage people who think
they are finding problems in a document to participate in the
relevant WG and discuss their issues.
Finally, if issues are addressed in a WG that is active and
responsible for a document anyway, that reduces the workload on
everyone who would need to be part of a round trip through the
errata system before the issue gets back to that WG anyway.
With the understanding that the situation in particular WGs may
be different, does that sound to you like possibly a better
approximation to The Right Thing for many or most cases?
Modulo how much I wish we'd gotten https://datatracker.ietf.org/doc/html/draft-ietf-newtrk-repurposing-isd-04 out of the NEWTRK working group in 2006 because we could have stopped thinking about this more than a decade ago, yes!
Best,
Spencer
best,
john
[1] While I would hope ADs or Chairs of active WGs with
responsibility for a document against errata were filed would
consult with the WG about the erratum, there is nothing in the
IESG statement that requires that.
