Re: [OAUTH-WG] [Errata Verified] RFC7800 (6187)

Benjamin Kaduk <kaduk@mit.edu> Sun, 31 May 2020 22:27 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6DAF3A00AD; Sun, 31 May 2020 15:27:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEA7XhOn0MDd; Sun, 31 May 2020 15:27:52 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41B263A0064; Sun, 31 May 2020 15:27:51 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 04VMRg3a016859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 31 May 2020 18:27:44 -0400
Date: Sun, 31 May 2020 15:27:42 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Pete Resnick <resnick@episteme.net>
Cc: Barry Leiba <barryleiba@computer.org>, Michael Jones <mbj@microsoft.com>, IESG <iesg@ietf.org>, John Bradley <ve7jtb@ve7jtb.com>, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>, oauth WG <oauth@ietf.org>, RFC Errata System <rfc-editor@rfc-editor.org>
Message-ID: <20200531222742.GB58497@kduck.mit.edu>
References: <20200531013404.4528BF40721@rfc-editor.org> <AA62FB03-89F3-4931-AB7C-0BE281970A2E@episteme.net> <20200531040924.GM58497@kduck.mit.edu> <DFA83403-04F8-4801-8519-1E2BD2BD7AC7@episteme.net> <CALaySJLCrp1qJ-+iybNZu-YYNvN8N-vwxbvi9M64kWeF2=XEPQ@mail.gmail.com> <B417238F-E380-44F0-9C3C-7184F5931D3B@episteme.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <B417238F-E380-44F0-9C3C-7184F5931D3B@episteme.net>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/6Ypvo_Rm4rLlQM42PqA9iA_Iqfc>
Subject: Re: [OAUTH-WG] [Errata Verified] RFC7800 (6187)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 31 May 2020 22:27:54 -0000

On Sun, May 31, 2020 at 12:58:54PM -0500, Pete Resnick wrote:
> On 31 May 2020, at 12:47, Barry Leiba wrote:
> 
> >> But 
> >> https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/, 
> >> in particular:
> >>
> >> Only errors that could cause implementation or deployment problems or 
> >> significant confusion should be Verified.
> >> Things that are clearly wrong but could not cause an implementation 
> >> or deployment problem should be Hold for Document Update.
> >> Typographical errors which would not cause any confusions to 
> >> implementation or deployments should be Hold for Document Update.
> >>
> >> Did something change these criteria?
> >
> > They're guidelines, not absolute rules, and judgment is expected.
> 
> Sure, but I was replying to Ben's statement that, "The new text is 
> clearly the right thing, and there is no need to debate it if/when the 
> document gets updated.  'Don't hold it; do it now', so to speak". That's 

To be clear, that was an off-the-cuff remark and not a considered opinion.

> not what Verified ever meant before. If the meaning has changed, that's 
> fine, but someone should let the community know and update the IESG 
> Statement. (Personally, I'm all for that, as I've found the current 
> definitions absurd and confusing. All clearly wrong Editorial errata 

They're also not especially internally consistent.  The first point quoted
lists causing "significant confusion" as grounds for Verified, but the
second point doesn't, even though it lists the other two items and one
might expect it to mirror the first point.

Would having a link to go a completely different document than one should
be seeing cause "significant confusion"?  For some people, I think it
would.  I've certainly had such cases, myself, before -- IIRC I put a
Discuss on a document that referenced RFC 7519 when it meant 7159 (in that
case, the "wrong" document was close-enough to topical to be plausible,
albeit incorrect).

-Ben

> should be marked "Verified", IMO.) But that's not about applying 
> judgement; that's changing the definition of the terms used.
> 
> pr
> -- 
> Pete Resnick https://www.episteme.net/
> All connections to the world are tenuous at best