Re: Errata Processing Stats/Queue?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Aug 06, 2019 at 08:06:09PM +0300, Fernando Gont wrote:
> On 6/8/19 18:52, Benjamin Kaduk wrote:
> > On Tue, Aug 06, 2019 at 11:48:00AM -0400, Michael Richardson wrote:
> >>
> >> Stewart Bryant <stewart.bryant@xxxxxxxxx> wrote:
> >>     > The usual process is for the IETF Chair tell the ADs to address them
> >>     > and get the numbers down, and for the rest of us to have a discussion
> >>     > with the the Nomcom if neither of those happen.
> >>
> >> I think that we need to do something to allow the work to be more visible to
> >> WG chairs, leaving the ADs to deal with errata where there are no WG, and
> >> then redirect it to an appropriate WG or XYZAREA-WG.
> >> Some of this could be done by directorates too.
> >>
> >> ADs are too valuable, and yet usually don't have the subject matter,
> >> and at this point, authors don't have any ability to act.
> > 
> > Most of the time, if the authors reply back that an errata is (in)valid, I
> > am willing to act on it.  More input from a WG list is better, of course,
> > but if I'm left to my own devices, I tend to only act on errata related to
> > technologies that I consider myself to already be an expert at.
> 
> What about the rest? Particularly for security, one may wonder what the
> unprocessed (technical) errata are about, and what the impact may be.

I'm not sure I understand the question.  From memory, a qualitative sense
is that (leaving outside the substantial fraction of purely editorial
ones), many reports are a difference of opinion between the reporter and
the authors/WG, or pointing out things that we wouldn't do again based on
what is well-known now, but were intended at the time (and thus do not
really meet the qualifications for errata).  There are, of course, the
handful of cases that point out actual security-relevant or
interoperability-affecting flaws, and while I/we do try to process those
more reliably, it's still not particularly reliable.  That said, as John's
note alludes, from the perspective of a potential implementor wanting to do
the right thing, there's not a huge difference between having an errata in
the "reported" state vs. "hold for document update" (which is what many of
these would end up as, due to the nature of the proposed change) -- a new
document would likely be more effective.

-Ben




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux