[Tools-discuss] "Discuss this RFC" (was Re: Datatracker login for errata

[Jean Mahoney <[e-mail]>]

Hi all,

On 5/28/23 11:02 PM, Brian E Carpenter wrote:
> Top posting, because basically I agree (the argument about captcha
> vs login required is only the tip of an iceberg). It's indeed a bit
> odd that a site hosting "requests for comments" doesn't have a
> "comment here" button. 
[JM] The info page for each RFC has a link labeled "Discuss this RFC" 
with a link to the working group or research group mailing list or 
stream manager alias (in the case of Independent stream docs). For example:

https://www.rfc-editor.org/info/rfc793 (IESG (Legacy))
https://www.rfc-editor.org/info/rfc3261 (sipcore)
https://www.rfc-editor.org/info/rfc9180 (cfrg)
https://www.rfc-editor.org/info/rfc9370 (ipsec)
https://www.rfc-editor.org/info/rfc9385 (ISE)
https://www.rfc-editor.org/info/rfc9318 (IAB)

The info page also provides a link to the RFC's datatracker page ("View 
history of RFC NNNN").

Best regards,
Jean

> We probably do need a policy discussion on this.
>
> Regards
>    Brian
>
> On 29-May-23 14:04, John C Klensin wrote:
>>
>>
>> --On Monday, May 29, 2023 07:57 +1200 Brian E Carpenter
>> <[e-mail]> wrote:
>>
>>> On 29-May-23 06:38, Eric Rescorla wrote:
>>>>
>>>>
>>>> On Sun, May 28, 2023 at 10:24 AM John Levine
>>>> <[e-mail] <mailto:[e-mail]>> wrote:
>>>>
>>>>      It appears that Eric Rescorla  <[e-mail]
>>>>      <mailto:[e-mail]>> 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 - [e-mail] -
>>> https://www.ietf.org/mailman/listinfo/tools-discuss
>>
>>
> ___________________________________________________________
> Tools-discuss mailing list - [e-mail] - 
> https://www.ietf.org/mailman/listinfo/tools-discuss