On Wed, Aug 07, 2019 at 03:06:28PM +0300, Fernando Gont wrote: > On 7/8/19 14:49, Stephen Farrell wrote: > > > > Hiya, > > > > On 07/08/2019 12:31, Kathleen Moriarty wrote: > >> Some ADs simply don't think errata is useful. I handled some, but worked > >> with ADs who didn't care about them. > > > > I guess I was one of those:-) I wouldn't say I considered > > errata as not being useful, but I do consider most errata > > are not useful and many are hugely time-consuming (it can > > take an hour to acquire enough context to decide if moving > > that comma is ok or not;-), > > That may apply to editorial errata, but not to *techical* errata. > > That doesn't mean that the errata might be of use, but it would seem to > me that it would be due dilligence to at least process the *technical* > errata. You keep emphasizing *technical* errata as if there is a crisp line between technical and editorial. But part of the work of processing an errata report is to determine whether or not it is, in fact, technical. I've lost count of the number of reports I've seen where the submitter thought they were technical but the WG/authors disagreed. > > Basically, I took silence as indicative of unimportance as > > I didn't have time to process 'em all. And the world didn't > > end, but yes the queue built up some more. > > > > So another way to improve this might be to put new errata > > into a "probably nobody cares right now" queue until it is > > apparent that someone other than the poster of the erratum > > cares that the change is good and ought be visible. > > Isn't part of IETF's mission to maintain its protocols? If nobody cares > about submitted errata, that would make one one wonder about the extent > to which that pat of the mission can be accomplished. "maintenance" and "RFCs are immutable" seem somewhat at odds with each other. > > > > At that > > point an erratum could be moved into the "for processing" > > queue. A WG later developing a bis draft could consider > > those "nobody cared" errata just as much as ever, but in > > the meantime they'd not bother the rest of the world (which, > > again, would not end:-). > > What I would expect is that, as with reported software vulnerabilities, > technical errata are processed, asap. It is not that the reporter is > telling you "review your spec, there is a bug, and i won't tell you > why", but normally the problematic text is quoted, and a solution proposed. I'm on the security team for a couple of pieces of open-source software. Serious vulnerabilities are processed ASAP, yes. But not all vulnerabilities are serious, and not all reports are vulnerabilities. Once we have looked far enough to know that something is not a vulnerability or not serious, it sometimes makes sense to remove the "security issue" prioritization and handle it as part of the normal development workflow. > Get the author of the spec to process it, and/or else the wg chairs, > and/or the relevant wg, or, why not, a set of people from the Acks > section. Complete AD processing my happen as a last resort... It remains unclear to me (and this is not directed at you) what would make authors/WG more motivated to look at something if I forward a mail to them versus just receiving it directly from the errata submission tool. (The latter being what already happens today.) I already have more documents blocking on me doing something than I can keep track of in my head (the datatracker helps, a fair amount); attempting to add errata to that is not something that I personally, at least, can manage. -Ben
