On 7/8/19 17:58, Benjamin Kaduk wrote: > 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. I'd expect that *all* errata gets processed. The reason I emphasize the technical one is because that's supposed to be way more important and relevant. I never meant that processing errata is easy, quick, enjoyable, or doesn't have false positives -- the same may also having for vulnerability reports (continuing with the analogy). What I do believe is that the system is important, processing the errata is important, and a procedure should be devised such as errata are handled in a timelier manner. All, or at the very least the ones flagged as technical (even if they result to be false positives). > >>> 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. Not sure I follow. I'm all for updating or revising RFCs where needed. In fact, most of the work I've done myself is exactly that. In fact, I'm all for processing the errata under the assumption that they may have flaws that require attention, sometimes in the form of a verified errata, while others in the form of a bis document. >>> 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. I'd expect that when somebody reports a vulnerability, you handle the report, and if it turns out that it actually isn't, you respond to the submitter. -- that's handling the report (whether you actually patch asap or not). Errata in the "reported" state were simply not processed. Nobody knows (neither the submitter, nor the community as a whole) if they make sense or not. >> 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. Agreed. THe question is how to respond when they don't respond. At the end of the day, the document they authored stopped being *their* document once the relevant wg adopted it. So, it would be nice if they responded (I'd expect them to), but if they don't, it's an IETF document that needs to be takn care of, anyway. > (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. Could directorates help? Could something like a "AD secretary" help? An Errata team for each area? Anything else? FWIW, my point and intent is certainly not to overload ADs, but to find a way in which somehow the work gets done. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@xxxxxxxxxxxxxxx PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
