Re: [Rfced-future] [rfc-i] RSWG & AUTH48 (was Re: [admin-discuss] Public archival of AUTH48 communications)

John C Klensin <john-ietf@jck.com> Fri, 04 March 2022 18:46 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B35053A0D6D for <rfced-future@ietfa.amsl.com>; Fri, 4 Mar 2022 10:46:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 BZG-R3G8IyVe for <rfced-future@ietfa.amsl.com>; Fri, 4 Mar 2022 10:46:44 -0800 (PST)
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 78AE73A0D65 for <rfced-future@iab.org>; Fri, 4 Mar 2022 10:46:44 -0800 (PST)
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 1nQCwa-000GjL-TV; Fri, 04 Mar 2022 13:46:24 -0500
Date: Fri, 04 Mar 2022 13:46:18 -0500
From: John C Klensin <john-ietf@jck.com>
To: Lars Eggert <lars@eggert.org>
cc: Michael Richardson <mcr+ietf@sandelman.ca>, Carsten Bormann <cabo@tzi.org>, Toerless Eckert <tte@cs.fau.de>, rfced-future@iab.org, RFC Interest <rfc-interest@rfc-editor.org>
Message-ID: <D4925436BB27594C0DB4B09D@PSB>
In-Reply-To: <F7300C99-E183-4CB3-AECC-EDCC8028EC03@eggert.org>
References: <CA+9kkMAg_xbTODu=UE288uxTVhL=+r18p5ywC6ZGaUvpyXO8bA@mail.gmail.com> <7C442BD6-F634-4129-9764-1BE29382D629@att.com> <8129A65C40CD88E0B5C94AA8@PSB> <7BC3F808-434B-48CF-B96B-0CF7D8B9F3A7@tzi.org> <EEF0F457622EDF74E090BC66@PSB> <BEB26FE0-CC24-4EC2-B7E5-6556A2425A24@eggert.org> <11721.1646248947@localhost> <af3a9d13-7ec2-4e48-355a-a3870af06361@joelhalpern.com> <a52626d5-13aa-ab1a-cb13-282bd9bcf812@gmail.com> <269b5f09-4840-b038-085c-839e0a1c3c6b@huitema.net> <YiBc6Mjj2++jxE0h@faui48e.informatik.uni-erlangen.de> <D5AC5684-506B-4214-9678-75B5C1FCBED2@tzi.org> <30761.1646334921@localhost> <D1908D64BC74C4F3C9444271@PSB> <F7300C99-E183-4CB3-AECC-EDCC8028EC03@eggert.org>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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/rfced-future/SeHOZQ-fkSklr73ZGfCy3ARre5Q>
Subject: Re: [Rfced-future] [rfc-i] RSWG & AUTH48 (was Re: [admin-discuss] Public archival of AUTH48 communications)
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program <rfced-future.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/rfced-future>, <mailto:rfced-future-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfced-future/>
List-Post: <mailto:rfced-future@iab.org>
List-Help: <mailto:rfced-future-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/rfced-future>, <mailto:rfced-future-request@iab.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Mar 2022 18:46:50 -0000

Lars, thanks...

--On Friday, March 4, 2022 09:48 +0200 Lars Eggert
<lars@eggert.org> wrote:

> Hi,
> 
> neither of the two concerns below motivated the proposal by
> the IESG to make the AUTH48 discussions public. The motivation
> was to further increase transparency of our processes.

And, in case it has not been clear, I appreciate that.  I just
don't think that type of transparency alone and as proposed is
really helpful for those people with concerns about a particular
document because of the S/N problems it implies.    The concerns
I identified were raised in discussions on this thread, not in
what the IESG proposed.  More below.

> On 2022-3-4, at 5:07, John C Klensin <john-ietf@jck.com> wrote:
>> Concern 1: There is a suspicion that something nefarious is
>> going on.
> 
> The IESG doesn't have this suspicion, and I'd be surprised to
> learn that a significant part of the community has this
> suspicion, given that is extremely rare for any individual
> AUTH48 to result in any significant discussion.

Again, referring to the list discussion and not to the IESG
announcement/ proposal, I have definitely seen that concern
raised.  Do I think a significant part of the community has that
suspicion?  Personally, I have doubts that a significant part of
the community cares about these issues at all? I would not be
surprised if a significant part of the community had even heard
of AUTH48, much less had a clue about what it was about, before
this discussion broke out (those who are not on these two lists
devoted to the RFC Editor Function probably still don't).

That said -- and it is definitely a separate question -- over
the years I have seen multiple cases in which decisions have
been made during AUTH48 about WG documents that arguably should
have been thrown back to the WGs (even if only for ratification)
and where that was not done.  In those cases, there have almost
always been reasonable and honest differences of opinion about
whether the WG would have anything useful to say if asked and
whether the added delay would be worth the trouble.  Practical
improvements in the transparency of such decisions would
definitely be welcome (see below).

Going further afield, something similar could be said about
bouncing documents back to a WG (not just document
authors/submitters) rather than making decisions during IESG
review and decision-making after Last Calls are completed.

>> 	Plausible solution: Make the correspondence public
>> 	either in real time or on request later. (Not a perfect
>> 	solution, see "observation" below.)
> 
> The motivation for making AUTH48 discussions public is solely
> that AUTH48 is AFAICT the only remaining step in the
> standardization process where private discussions are still
> being held (albeit only on editorial questions), and the IESG
> wanted to further increase transparency here.

Entirely worthwhile, but see below.

>> Concern 2: The AUTH48 reviewers lack breadth or are
>> sufficiently invested in one vision of the document to not be
>> able to reliably make good critical decisions consistent with
>> consensus of the Stream/ Approving body.   Using the IETF
>> Stream as an example, with no malice at all, inconsistency
>> between the views of the community and those of the authors
>> and IESG could be another part of this concern.
 
> This is not a concern for the IESG. We have seen no evidence
> that the AUTH48 step is somehow systemically broken. (It does
> often take longer than 48 hours - but that has been the case
> for decades.)

I did not say "systematically broken" or anything like it.  Over
the years, I've seen several cases in which questions about
clarity or ambiguity have come up during AUTH48 where the
possible solutions could have substantive technical
implications.  The decisions that have been made at that stage
have almost always been made based on beliefs about what the WG
intended or what the WG would say if asked.  AFAICT, those
decisions have almost always been made correctly made -- I don't
believe that I have ever (at least in the last couple of
decades) heard of participants in a WG complaining that a
document, as published, was not what they intended. However, I
still think it is reasonable to be anxious about that way of
making such decisions (although, frankly, not very anxious).

>> 	Plausible solution:  Figure out a better way to allow
>> 	broader review immediately pre-publication.
> 
> This is explicitly a non-goal. The conversation in AUTH48 is
> intended to remain between the authors/editors and the RPC,
> with ADs in the loop. It is not intended to morph into some
> sort of post-approval community last call.

As more people have been added to the distribution of AUTH48
interactions, it seems to me that we are already past
authors/editors, the RPC, and responsible ADs (rather than the
whole IESG) in the conversation/loop.  Shepherds have been added
and sometimes people who have made comments during Last Call or
IESG review have been added.   Even the procedural notes to
which Jean Mahoney pointed us yesterday require "steam manager"
review of certain types of changes.  This might be another issue
with definitions in the model document but my understanding is
the "stream manager" does not differ from document to document,
so that presumably points to the IESG or someone the IESG
appoints  to that role on a relatively long-term basis (not
per-document).

So, part of my comment, the IESG's goals aside, is that we are
already on the slippery slope past authors/editors and an AD.

If I have any disagreement with what the IESG proposes in the
name of simple transparency (as you suggest above), it is more
about goals than about mechanisms.  I think that the goal of
establishing more formal/symbolic transparency (and I don't
intend either of those terms pejoratively) is always good and
especially good when AUTH48 is, as you point out, the only part
of the standardization process where private discussions still
occur [1].  That is consistent with what I have observed of the
list discussion: I've seen proposals about how to better tune
what should be done.  However, all of them have been targeted to
other goals or criteria.  I'm also seen questions about impact
on other Streams and about timing, but I don't think anyone has
said either "bad idea in any form" or "that is a bad goal" to
the IETF proposal

So, please take my comments and attempt to summarize other
issues/goals (with which, in case it wasn't clear, I don't
necessarily agree), not as "your goals are bad" or "don't do
this".  They are about whether you have (accidentally?) exposed
some other problems that should be addressed and goals that
should be in your queue for discussion at some point.  In
particular, we know that AUTH48 sometimes addresses issues that
are not strictly editorial.  If that were not the case, there
would be no need for the RPC procedural statements or AD
involvement.  I don't think it is either feasible or desirable
to try to change that, but it involves a question the IESG
should ask, almost certainly in conjunction with the RSWG.  And,
IMO more important, if even marginally non-editorial decisions
are being made after the IESG signs off on a document, do we
have enough safeguards in place to ensure that those decisions
are made consistent with what they community thought it was
agreeing to during Last Call or that were covered in a final,
post-approval, draft posted by the authors/editor (and that
everyone feels confident about that)?  The answer may well be
"yes" (or nearly so), but I think your setting goals for greater
transparency suggests that, sooner or later, those questions
should be asked.

thanks,
  john


[1] I don't quite believe that, but it is part of separate
discussion we might have at another time.