On Wed, Aug 7, 2019 at 7:32 AM Kathleen Moriarty <kathleen.moriarty.ietf@xxxxxxxxx> wrote: > > > > On Tue, Aug 6, 2019 at 4:51 PM Michael Richardson <mcr+ietf@xxxxxxxxxxxx> wrote: >> >> >> Fernando Gont <fgont@xxxxxxxxxxxxxxx> wrote: >> >> And yes, it does help if WGs are responsive to errata as well. >> >> > FWIW, I do think when an appropriate WG is available, they should work >> > on emptying the errata queue. >> >> > Like bugs, if nobody cares in patching, why would folks care to report? >> >> 1) If WG-chairs could change the state themselves that would help. >> 2) If WG sessions had a number of errata as part of the status slide, >> then that would probably help close the loop. > > > I agree with this. Errata needs to be delegated further to improve processing. If all of the ones that existed where there is an open WG could be handled by the chairs, they would be more familiar with each errata, who the experts were that could approve them, and may have the history having been chairs for a long period of time. Counterpoint -- the relevant AD(s) can simply poke the chairs and / or working group and ask them what should happen with the Errata. As an example: https://mailarchive.ietf.org/arch/msg/dnsop/PFPRwLBE02SniDqaV6VaZ-Z4Uiw this got some good discussion and feedback. As another example: https://mailarchive.ietf.org/arch/msg/opsec/jHa-VrrZzVkdgcPqL86lObiT-u8 This one was sent to the relevant WG (OpSec), and the chairs responded. The actual "work" was opening the RFC, hitting "Command-F", typing in a word or two, and marking the Errata as "Hold for Document Update"[0]. Errata really are important (IMO!), and need to be treated judiciously - from "RFC Editor Proposal for Handling RFC Errata" ( https://www.rfc-editor.org/materials/draft-rfc-editor-errata-process-02.txt ) "We note that allowing technical errata is a slippery slope: there may be a temptation to use errata to "fix" protocol design errors, rather than publishing new RFCs that update the erroneous documents. In general, an erratum is intended to report an error in a document, rather than an error in the design of the protocol or other entity defined in the document, but this distinction may be too imprecise to avoid hard choices. For the IETF stream, these choices should be made by the IESG, and are discussed in their proposed guidelines on errata processing [IESG-Err-Proc]." It can be *really* tempting to fix something obviously wrong as (or outdated!) in a protocol design by simply filling an Errata - I witnessed this in Montreal where a working group could have saved a significant amount of work, and also made a protocol / the world better by simply changing a "SHOULD do X" to "SHOULD NOT do X". The chairs and (majority of the) WG were ready to do this through an errata, but it would be a mistake -- the consensus when the document was written was clearly "SHOULD do X" (there is even an explanation in the next sentence), and as tempting as it is, using the Errata process to "fix" this would violate our consensus process and weaken the RFC series. As the AD I have less skin in this particular game / no dog in the fight[1], and so I'm (hopefully!) better able to avoid the temptation. I agree that processing Errata can be annoying, and can require much research, archeology, trying to figure out history, etc -- I keep snippets so I can track what I've been spending my time on and there are 101 instances of 'Errata' in my snippets - if each instance took 10 minutes (seems like a reasonable average, including context switch) that's ~16 hours. Errata notices get sent to (I believe) the WG, the authors and the AD -- I'm quite certain that no AD would object to the working groups (and authors) looking at the Errata notices as they arrive, discussing it, writing up a summary / proposed resolution and sending it to the AD to do the annoying administrivia bits of clicking the buttons. W [0]: "The erratum is not a necessary update to the RFC. However, any future update of the document might consider this erratum, and determine whether it is correct and merits including in the update." (https://www.ietf.org/blog/iesg-processing-rfc-errata-ietf-stream/) [1]: Sorry for the idioms - https://en.wikipedia.org/wiki/Skin_in_the_game_(phrase) , https://www.usingenglish.com/reference/idioms/no+dog+in+this+fight.html > > Some ADs simply don't think errata is useful. I handled some, but worked with ADs who didn't care about them. As a result, Security has the second highest score, leaving Ben and Roman with a bit too much to deal with at this point. > > If there's no WG that remains or never was one, it would be nice if those could be delegated too. The usual process is for editors of the draft to review the errata and respond on list as to their thoughts. Then the AD is able to press the buttons. Maybe someone else could monitor the list conversations and update the text in the errata filing accordingly with a link to said email confirmations and press the buttons? > > Best regards, > Kathleen >> >> >> >> But trying to perform statistical analysis on the numbers is likely to >> >> appear to tell us things that just aren't so. >> >> > Not much of an analysis, but more of a simple way to spot where there >> > might be room for improvement. >> >> Agreed. >> >> >> >> >> >> -- >> Michael Richardson <mcr+IETF@xxxxxxxxxxxx>, Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> > > > -- > > Best regards, > Kathleen -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
