Kind of cherry picking here. > On Aug 7, 2019, at 12:09, Fernando Gont <fgont@xxxxxxxxxxxxxxx> wrote: > > 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). just my two cents: I remember when I thought processing errata was going to be oh so easy. Man was I dead wrong. As noted somewhere in this thread somebody read all of the RFCs (at the time) and submitted errata. It was a _LOT_ of errata. After trying to process them, there ended being even more because many of the errata were were multipart - like 15 parts. One part could be verified, but others HFDU (hold for document update) or rejected. To address this Tim Polk and I had to break most apart, which in turn made our “numbers” ballon*; but really the RFC editor did the separation for us. Along the way, Tim and I had discussions with submitters about whether the errata fell into bucket 1, 2, 4, 5, 6, 7, or 8 from https://www.ietf.org/blog/iesg-processing-rfc-errata-ietf-stream/. All of this was made a littler hard when the errata were against “legacy" RFCs because tracking down the authors for input was downright painful (Google was my friend here) and sometimes impossible. When we could not find the authors or the WG chairs (sometimes of long closed WGs) were unresponsive, Tim and I would have to roll up our sleeves and do a deep dive. This involved talking with members of the community, talking it out together, and running the proposed solution by community member(s). We also ran things by the WGs, but frankly what we saw then is what I see now - there’s just not a lot of interest in processing errata. I will note, AD-sponsored RFCs were even more painful, because, at least to me, it seemed like many of those authors got their RFC and were done with it/us. It took many months to whittle the numbers down to 1. We never did manage to get to zero. Let’s say HFDU was really our friend here. To get through this process Tim and I developed the following email which we shared with the chairs and the authors and wg chairs: The errata process is beginning to be used by more and more people. To ensure we (the ADs) properly process them, we need help from document authors and WG chairs. We'd like your help with the following errata [insert #s]. We need your help with the following: #1) Ensure the reported errata is against the correct RFC. If not, inform us. If it is, continue with steps 2 through 5. #2) Determine whether the reported errata type is correct. There are two types editorial and technical. Editorial errata are well editorial (i.e., commas, spelling, typos, etc. or subjective/stylistic edits) that would make the document clearer and easier to read, but do not really affect the utility of the specification. Technical errata are errors or inconsistencies that could introduce implementation or deployment problems. Any errata that changes bits on the wire or processing algorithms is generally technical! #3) Use the criteria from http://www.ietf.org/iesg/statement/errata-processing.html to determine the correct next state: Approved, Hold For Document Update, or Rejected. Note that most editorial errata should be held or rejected. #4) If approved, determine whether the errata needs to be edited. Sometimes the submitter has identified a real problem but the proposed edit does not entirely correct the problem. If the proposed edit requires tweaking, please propose a correction! #5) Inform us whether you agree with the reported errata type, the next state, and whether any edits should be applied to the errata itself. As noted in the IESG statement, these are guidelines and not immutable rules. When in doubt, please rely on your common sense and good judgment! We greatly appreciate your support. Hope this helps, spt * I remember Sandy giving reports about errata during IETF week’s Sunday IESG sessions and cringing at the SEC “tower” in the bar chart.
