On Wed, Oct 28, 2020 at 02:53:56PM -0400, Joel M. Halpern wrote: > 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". Yes, I was assuming these errata would end up in HFDU. -Ben > 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 > >
