Re: [Tools-discuss] Datatracker login for errata

John C Klensin <john-ietf@jck.com> Mon, 29 May 2023 20:17 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706CEC151B07 for <tools-discuss@ietfa.amsl.com>; Mon, 29 May 2023 13:17:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.893
X-Spam-Level:
X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYotscu9MiYI for <tools-discuss@ietfa.amsl.com>; Mon, 29 May 2023 13:17:55 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF446C151B04 for <tools-discuss@ietf.org>; Mon, 29 May 2023 13:17:55 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1q3jJR-00014M-Q9; Mon, 29 May 2023 16:17:53 -0400
Date: Mon, 29 May 2023 16:17:41 -0400
From: John C Klensin <john-ietf@jck.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, tools-discuss@ietf.org
Message-ID: <1DFACFE6CE9F8E195F13CED7@PSB>
In-Reply-To: <450426b6-ade4-069d-7201-e64f5e1b2849@gmail.com>
References: <CABcZeBOkf9Z_bAMcUroHd44DOmBa60=qq0u4V8EJPDU2tUoi4A@mail.gmail.com> <20230528172358.B9953DF9249C@ary.qy> <CABcZeBP9A7rYCZsJC9gVrxzMKLpiSBqJUjCX9VN7_mf0fDtv1w@mail.gmail.com> <125bbed2-7f3e-71c1-e26c-7e5f8c55bd2f@gmail.com> <D4C6C897EA2F505AC1DC2018@PSB> <450426b6-ade4-069d-7201-e64f5e1b2849@gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/tools-discuss/qhn8joXerBluXnEsQfMUoUz5D40>
Subject: Re: [Tools-discuss] Datatracker login for errata
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Tools Discussion <tools-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-discuss/>
List-Post: <mailto:tools-discuss@ietf.org>
List-Help: <mailto:tools-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 May 2023 20:17:59 -0000

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.

best,   
   john


--On Monday, May 29, 2023 16:02 +1200 Brian E Carpenter
<brian.e.carpenter@gmail.com> 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
>> <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
>> 
>>