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

Jean Mahoney <jmahoney@amsl.com> Thu, 03 March 2022 16:30 UTC

Return-Path: <jmahoney@amsl.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 BC86B3A0E11 for <rfced-future@ietfa.amsl.com>; Thu, 3 Mar 2022 08:30:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, 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 5XYqQ8gICqx2 for <rfced-future@ietfa.amsl.com>; Thu, 3 Mar 2022 08:29:56 -0800 (PST)
Received: from c8a.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CDA73A0E01 for <rfced-future@iab.org>; Thu, 3 Mar 2022 08:29:56 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 4CA8C427C640; Thu, 3 Mar 2022 08:29:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Av6FGXZhtFCL; Thu, 3 Mar 2022 08:29:56 -0800 (PST)
Received: from [192.168.1.203] (unknown [47.186.48.51]) by c8a.amsl.com (Postfix) with ESMTPSA id 8E93A425C356; Thu, 3 Mar 2022 08:29:55 -0800 (PST)
Message-ID: <b1b5aab9-cf10-53ae-c5d6-4d85088bd996@amsl.com>
Date: Thu, 03 Mar 2022 10:29:54 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.1
Content-Language: en-US
To: Toerless Eckert <tte@cs.fau.de>, Christian Huitema <huitema@huitema.net>
Cc: rfced-future@iab.org, RFC Interest <rfc-interest@rfc-editor.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>
From: Jean Mahoney <jmahoney@amsl.com>
In-Reply-To: <YiBc6Mjj2++jxE0h@faui48e.informatik.uni-erlangen.de>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfced-future/XwUp8qfKgs8FvLUlgSui-iKg2jA>
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 16:30:01 -0000

Hi all,

Please note that the RPC requests review and approval from a stream 
manager of any change made during AUTH48 that is beyond editorial. This 
policy may be found on the rfc-editor.org website [1] [2] and also in 
each email message that starts AUTH48:

    We will ask a stream manager to review and approve any changes that seem
    beyond editorial in nature, e.g., addition of new text, deletion of text,
    and technical changes.  Information about stream managers can be found in
    the FAQ.  Editorial changes do not require approval from a stream manager.

Best regards,

Jean Mahoney
RPC Project Manager

[1] https://www.rfc-editor.org/pubprocess/auth48/
[2] https://www.rfc-editor.org/faq/#streammanagers

On 3/3/22 12:15 AM, Toerless Eckert wrote:
> I am not aware of backroom dealings for non-editorial changes
> during AUTH48. Examples would be useful to start having a more
> educated opinion.
>
> I do not think we should or could expect for parties currently
> not involved in the AUTH48 process to start acting in the future as
> additional accountable watchdogs just because we make AUTH48 communications
> public. In the absense of knowing any specific examples, i can
> only imagine that such an interest watchdog party might happen
> if the IETF approved last draft was a very tough compromise and
> a non-author party has severe concerns about abuse of AUTH48.
>
> But in any such case i imagine that it should already be possible
> to escalate such a situation after publication of the RFC and
> demand for it to be taken down ("this RFC does not match functionally
> the last draft and this AUTH48 change should have been IESG/WG discussed...")
> If such a process is not well defined, then i think its better to do that
> than to expect additional process for AUTH48. E.g.: 1 month of
> "conditional publishing" of RFC in which time any such concerns
> can be raised (non-editorial change from last draft during AUTH48).
>
> That said, i am all for a real-time publically accessible
> stream of AUTH48 communications. I just don't think we should
> expect it to be used by our processes for anything but a)
> openness and curiosity and b) reference reading for when the AUTH48
> process does result in notification of IETF/WG for a required
> change beyond AUTH48 purview.
>
> Cheers
>      Toerless
>
> On Wed, Mar 02, 2022 at 04:14:48PM -0800, Christian Huitema wrote:
>> On 3/2/2022 12:31 PM, Brian E Carpenter wrote:
>>
>>> Joel's concern is reasonable but I think the boundary between policy and
>>> operations will always be hard to fix precisely.
>>>
>>> That said, I slightly disagree with Lars. It's *exactly* because the
>>> policy requirements might differ between streams that the RSWG/RSAB
>>> structure is the right place to discuss this. To be specific, the
>>> lack of public debate about non-editorial changes at AUTH48 is of
>>> real concern in the IETF standards process, but might be considered
>>> a non-issue for the Independent Stream. And the desired settings might
>>> be different for the other three streams (including the new Editorial
>>> stream). That - public debate during AUTH48 - would be a policy issue.
>>> The details of which mailing lists and/or version management systems
>>> are used is operational.
>> The request to make AUTH48  discussions public is rooted in the standard
>> making requirements. RFCs coming out of the IETF streams are standard
>> documents. The process must be fully transparent, if only to avoid
>> appearances of last minute backroom dealing. The responsibility for ensuring
>> the requiring transparency is squarely on the IESG and the IETF chair, not
>> on the RSWG/RSAB or the RPC.
>>
>> -- Christian Huitema
>>
>>
>> _______________________________________________
>> rfc-interest mailing list
>> rfc-interest@rfc-editor.org
>> https://www.rfc-editor.org/mailman/listinfo/rfc-interest