I hope I am missing something.
I have trouble thinking of a case where a security vulnerability in our
work could be reasoanbly captured in an erratta that is anything other
than "held for future update".
The errata system is not an issue tracker for RFCs. Accepted errata are
not supposed to be changes to the WG agreement, even if the WG got it
wrong. They are supposed to be cases where the words on the page do not
say what the WG meant. this can be a missing (or added "not", or
verbiage so opaque that anyone not in the room can't figure out what it
means (although most of the time the RPC catches those before RFC
publication.)
it is not for the cases where the WG agreed on a protocol that has a
security hole, bug, or potential misbehavior.
Heck, in the case of 8200 I have to agree with the AD that an errata was
not the way to fix ambiguous wording that the WG agreed on, even when
folks later came up with an interpretation that had not been considered
by the WG. Errata simply are not for things that change existing WG
agreements.
Yours,
Joel
On 10/28/2020 2:42 PM, Benjamin Kaduk wrote:
On Tue, Oct 27, 2020 at 11:27:13AM -0700, Michael Thomas wrote:
On 10/27/20 11:00 AM, Eliot Lear wrote:
I think what you are pointing out is that maybe it would help if these
things were properly tracked against anything that would update or
obsolete existing work. We might even be able to automate the
response along the lines of:
* A working group is currently working on an update. Please feel
free to join in the fun at...
* A working group is currently working on a replacement (e.g.,
obsolete). Please feel free to join in the fun at ...
* No current update is in progress. In addition to filing an
erratum, we invite you to provide an update through our errata
process, and perhaps through our standards process. You can
contact <insert AD here> for more information.
My impression is that errata has a pretty high barrier to entry if it's
potentially controversial. There doesn't seem to be any easy mechanism
to do a one off update that requires wg buy in to get enough eyeballs on
the problem to make certain that the fix is correct. it's like you need
something similar to a critical security update to your OS, say, which
needs to be well vetted by the devs, but doesn't want to wait for the
next point release.
There are several WGs where we've had extended discussions over the text to
put in a potential errata report, before the report gets submitted.
If errata is that mechanism for something controversial, it's news to
me. Mostly what i've seen with errata are minor fixes which the wg chair
and/or authors can sign off easily.
I don't think that errata are the definitive mechanism for potentially
controversial things or things that require intrusive changes to resolve,
but they can be an appropriate tool. A drive-by errata report without
additional discussion is probably not going to be the most effective way to
make progress on such issues, but it can definitely be useful to have the
issue documented in an errata report, even as a revision to the RFC is
underway to fix the issue.
-Ben
