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

Carsten Bormann <cabo@tzi.org> Thu, 03 March 2022 08:06 UTC

Return-Path: <cabo@tzi.org>
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 ED0D23A12DE for <rfced-future@ietfa.amsl.com>; Thu, 3 Mar 2022 00:06:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-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 sxhAUD8UOl_n for <rfced-future@ietfa.amsl.com>; Thu, 3 Mar 2022 00:06:30 -0800 (PST)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B6E13A12D8 for <rfced-future@iab.org>; Thu, 3 Mar 2022 00:06:30 -0800 (PST)
Received: from smtpclient.apple (p5089ad4f.dip0.t-ipconnect.de [80.137.173.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4K8Nq705SqzDCkF; Thu, 3 Mar 2022 09:06:26 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <YiBz6FNcjxrwiHVS@faui48e.informatik.uni-erlangen.de>
Date: Thu, 03 Mar 2022 09:06:26 +0100
Cc: rfced-future@iab.org, RFC Interest <rfc-interest@rfc-editor.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DCED11B7-B942-4183-830A-08FE69132B4F@tzi.org>
References: <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> <YiBjw7P7CW5Lf2oH@faui48e.informatik.uni-erlangen.de> <A9CDA47A-9CA0-4CF4-ABDC-4F0821F2349D@tzi.org> <YiBz6FNcjxrwiHVS@faui48e.informatik.uni-erlangen.de>
To: Toerless Eckert <tte@cs.fau.de>
X-Mailer: Apple Mail (2.3693.60.0.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfced-future/DgoxWuFM6cptrMTi-etuTCBv-s0>
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: Thu, 03 Mar 2022 08:06:35 -0000

On 3. Mar 2022, at 08:53, Toerless Eckert <tte@cs.fau.de> wrote:
> 
> On Thu, Mar 03, 2022 at 07:51:46AM +0100, Carsten Bormann wrote:
>>> Let me rephrase: How would you describe the responsibitiles and
>>> accountabilities to improve the process ?
>>> 
>>> "Make it public and let them come" ?
>> 
>> Yes.
>> Those who truly care about an RFC-to-be are likely to come if we don’t make access too onerous.
> 
> Not necessarily those who might have the best input though.
> 
> Aka: this can IMHO only be a secondary add-on option and
> must not replace some primary responsibility of authors/AD/shepherd/rfc-editor
> to alert the right expert/groups from whom to explicitly seek
> input if/when such a situation arises during AUTH48.

Processes are much easier to design if you know everyone will always do their tasks perfectly and on time.
(In Software Engineering, we call this process confabulation.)

Yes, public AUTH48 is a small additional safety net, and a very thin one.

>>> ("All the planning charts and demolition orders have been on display at your local planning department…")
>> 
>> Yes, but the first thing to alert you is the status change on the I-D.
>> You have subscribed to the status changes, no?
> 
> I am not aware of any status changes during auth48 to be publically available.
> But lets assume we would add that.

During AUTH48 — yes, you have to follow the list.

> Which publically available status change notification system are you
> referring to ?

1 Go to https://datatracker.ietf.org/wg/core/documents/ (for a WG of your choice)
2 Scroll to the end
3 Click “Subscribe to changes” (or “Change subscription”)
4 Fill in the form (“All changes”).  Submit.
5 Profit from the magically improved situational awareness you now have achieved.

(You can also get an atom feed.)

> All events on planet earth, the just slightly less
> poluted i-d-announce mailing list or something more specific i can
> easily subscribe to. I am not aware of the latter.

See above.

I don’t know how to subscribe to AD-sponsored documents, though.

Grüße, Carsten