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.
> 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].
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?
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.
