Re: [Tools-discuss] Datatracker login for errata

[John C Klensin <[e-mail]>]

--On Tuesday, May 30, 2023 08:49 +1200 Brian E Carpenter
<[e-mail]> wrote:

> On 30-May-23 08:17, John C Klensin wrote:
>> Brian,
>> 
>> In retrospect, maybe the long-ago decision to publish
>> materials the IETF identified as "standards" in the RFC
>> Series was a mistake, leading to a number of awkward names of
>> things and workarounds with "Internet Draft" coming
>> immediately to mind and recalling an old IETF Thursday
>> evening tradition.  Much too late now and, as Rich suggests,
>> perhaps in a better world...
>> 
>> Thinking about your comment, it does occur to me that we could
>> do one thing that would be fairly painless and, I hope,
>> uncontroversial.  That would be to add another paragraph after
>> the first one at https://www.rfc-editor.org/ doing a quick
>> review of the evolution of the Series and pointing out that
>> the name is, at this point, a historical artifact that does
>> not mean what it meant in 1969.  I don't know whether it
>> would be a policy matter but it certainly should not be a
>> large and/or controversial one.
> 
> Yes. The thing I like about the traditional name is that it
> does
> express openness and willingness to listen. We must never lose
> that. "If you want to comment, please consider participation in
> the IETF or IRTF, which are open to all."

That seems exactly right to me.

    john


>> --On Monday, May 29, 2023 16:02 +1200 Brian E Carpenter
>> <[e-mail]> 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. 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
>>>> 
>>>> 
>> 
>>