Re: [Tools-discuss] Datatracker login for errata

--On Monday, May 29, 2023 07:57 +1200 Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:

> On 29-May-23 06:38, Eric Rescorla wrote:
>> 
>> 
>> On Sun, May 28, 2023 at 10:24 AM John Levine
>> <johnl@taugh.com <mailto:johnl@taugh.com>> wrote:
>> 
>>     It appears that Eric Rescorla  <ekr@rtfm.com
>>     <mailto:ekr@rtfm.com>> said:
>>      > -=-=-=-=-=-
>>      > 
>>      > I see that you now need to solve a captcha to submit
>>      > errata, as well as type in your name and email. This
>>      > seems like unnecessary friction.
>> 
>>     We're still getting a lot of junk errata.
>> 
>> 
>> If we're still getting them, that doesn't seem like a great
>> endorsement for the captcha.
>> 
>> 
>>      > Perhaps we could have a datatracker login version that
>>      > bypassed the captcha and filled this stuff in.
>> 
>>     Actually, I wouldn't mind if you could only submit errata
>>     with a DT login. I don't recall seeing many real errata
>>     from names I didn't recognize.
>> 
>> 
>> I don't feel strongly about DT only; I'm merely arguing that
>> a DT option would be a good idea.
> 
> Yes. I think it would be very parochial to refuse errata from
> outsiders. A bad look for an open standards organisation.

Brian,

I'm actually not sure.   Many of the errata I've seen have been
spurious or basically change requests for the specification.
Others have been corrections of trivial editorial or
typographical errors.  Certainly the latter, and at least some
of the former, may be indicative of what you described in a
later note as "dull lives" and that I would describe as "too
much time on their hands".  I have no idea what percentage of
the total errata submissions fall into those categories; perhaps
even a subjective impression (no elaborate data collection or
analysis needed) from the RPC about the number of errata reports
that are substantive, useful (i.e., not a protocol change
request or equivalent), and that are resolved in a positive way
(with neither "hold for document update" nor "rejected" counting
as positive).

Equally important our errata processing procedure for IETF
Stream documents (at least) seems to me to be very costly in
terms of the number of people and groups who need to get
involved.  That, in combination with the above, makes the errata
system a good candidate as a vector for DoS attacks, whether we
have seen that yet or not.  If making someone create an account,
supply an address that can be authenticated, or something
similar reduces that risk, improves the S/N ratio, or both, I
think that is good process management what than parochial
behavior.

I also note that we have no formal mechanism for people to ask
questions about interpretation of a specification (especially
standards track ones).  There are good reasons for that, most
having to do with how we would establish community consensus
about the answer, but, given that insiders can approach other
insiders in the real or virtual halls, that seems far more
parochial than some minor impediments in the errata process.
And, of course, to the extent that errata reports are used as a
substitute for clarification questions, that is another problem
with the current model.

FWIW, once upon a time, the RFC errata process consisted of an
answer to any input that said approximately "if this is
important enough, become part of the process and get started on
a revision; if it is less so, we will leave notes for the
author(s) of the document and keep informal notes that would
inform any future revision".    It would be really easy to
automate that process and be sure that everything was logged.
I'm not entirely clear that the current process --especially
given concerns about whether RFCs that are essentially changed
by errata still represent community consensus -- are actually an
improvement.

best,
  john

p.s. this discussion seems to be moving in a direction (even
before the note above) that should be handled as an RFC Series
policy matter rather than a tools question.

> 
>     Brian
> ___________________________________________________________
> Tools-discuss mailing list - Tools-discuss@ietf.org -
> https://www.ietf.org/mailman/listinfo/tools-discuss