Re: [Rswg] Making progress on RFC 7991-bis

"\"Mirja Kühlewind (IETF)\"" <ietf@kuehlewind.net> Tue, 02 August 2022 18:36 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: rswg@ietfa.amsl.com
Delivered-To: rswg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC50C15C53A for <rswg@ietfa.amsl.com>; Tue, 2 Aug 2022 11:36:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.659
X-Spam-Level:
X-Spam-Status: No, score=-0.659 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 TDNc-d2CIGgL for <rswg@ietfa.amsl.com>; Tue, 2 Aug 2022 11:36:31 -0700 (PDT)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24B59C15AD22 for <rswg@rfc-editor.org>; Tue, 2 Aug 2022 11:36:31 -0700 (PDT)
Received: from dslb-002-202-026-120.002.202.pools.vodafone-ip.de ([2.202.26.120] helo=smtpclient.apple); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1oIwkj-0002G2-Oi; Tue, 02 Aug 2022 20:36:25 +0200
Content-Type: multipart/alternative; boundary="Apple-Mail-C25631A4-5EFB-472A-979E-42128279D800"
Content-Transfer-Encoding: 7bit
From: "\"Mirja Kühlewind (IETF)\"" <ietf@kuehlewind.net>
Mime-Version: 1.0 (1.0)
Date: Tue, 02 Aug 2022 20:36:24 +0200
Message-Id: <A8C6862A-D8CB-4AEE-9721-16446E11FBD0@kuehlewind.net>
References: <CABcZeBOCO52LKQyfOngrB8cXWRw18kyP5hjY0hUBf5k5xgvCrw@mail.gmail.com>
Cc: rswg@rfc-editor.org
In-Reply-To: <CABcZeBOCO52LKQyfOngrB8cXWRw18kyP5hjY0hUBf5k5xgvCrw@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
X-Mailer: iPhone Mail (19F77)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1659465391;781b4bce;
X-HE-SMSGID: 1oIwkj-0002G2-Oi
Archived-At: <https://mailarchive.ietf.org/arch/msg/rswg/0XNKSLo-YHawfx6JnClr3qY4MYg>
Subject: Re: [Rswg] Making progress on RFC 7991-bis
X-BeenThere: rswg@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "RFC Series Working Group \(RSWG\)" <rswg.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/rswg>, <mailto:rswg-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rswg/>
List-Post: <mailto:rswg@rfc-editor.org>
List-Help: <mailto:rswg-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/rswg>, <mailto:rswg-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2022 18:36:36 -0000

Hi, 

Thanks for the summary and effort to move forward. Please see one comment online and replies to your questions below.

> Am 02.08.2022 um 19:07 schrieb Eric Rescorla <ekr@rtfm.com>:
> 
> 
> Hi folks, Chairs here.
> 
> We've been watching the discussion about RFC 7991-bis and wanted to
> see if we could help guide the discussion towards consensus.
> 
> PROCESS
> Under Section 3 of RFC 9280 the evolution of RFC format is the
> responsibility of this WG as:
> 
>    Policies under the purview of the RSWG and RSAB might include, but
>    are not limited to, document formats, processes for publication and
>    dissemination of RFCs, and overall management of the RFC Series.
> 
> With the publication of RCC 9280, the IAB no longer has a direct role
> in setting the policies for the RFC series, as stated in Section 3.1.1.4:
> 
>    The IAB is requested to convene the RSWG when it is first formed in
>    order to formalize the IAB's transfer of authority over the RFC
>    Editor Model.
> 
> Thus, it would not be appropriate for the IAB to publish an RFC
> that obsoletes RFC 7991, as RFC 7991 expresses policy:
> 
>    The v3 format will be used as part of the new RFC Series format
>    described in [RFC6949].

I disagree here. This sentence is already in rfc7991 and not updated by rfc7991bis. All changes in rfc7991bis are not intended to change policy and I don’t think they do. I see them as bug fixes what exact the purpose of a bis document is.

> 
> Any such document needs to come out of this WG.
> 
> RFC 9280 does not specify a precise line between policy and
> implementation detail, but ultimately it is up to this WG to devise a
> process for evolving the format, subject to approval by RSAB; this might
> include delegating some detailed decisions to the RPC.
> 
> 
> SUBSTANTIVE
> On the substantive matter, we find ourselves in a somewhat difficult
> situation: RFC 7991 defines a format and directs the RPC to use it but
> we are actually using the format defined in
> draft-irse-draft-irse-xml2rfcv3-implemented-01 [0].  This format does
> not have the consensus of the community, it is merely the result of
> decisions made when the tools were written.
> 
> We see broad agreement in the WG that it is necessary to define a new
> format (that could of course be very similar to what we are currently
> using) that has community consensus. The consensus document would go
> through the RFC 9280 process and be published in the Editorial stream.
> 
> This work will of course take some time, but we have already published
> RFCs in the format defined in draft-irse- and nobody has seriously
> suggested that we cease publishing RFCs until a community consensus
> format is published. This makes it necessary to document that
> format. We do not see the WG as currently having consensus on
> the precise manner in which we do so. In particular, the chairs would
> ask people to focus on two questions.
> 
> 1. Do we need to publish the current de facto format as an
>    RFC or should it be in some other form such as an I-D
>    or a Web page?

Yes we need an rfc because otherwise please will keep looking at rfc7991 which is just wrong (and I don’t want to give any estimate how long it will take to publish a new format version).
>    
> 2. Should we just publish the de facto format as-is
>    or should we make limited changes prior to the completion of
>    a more complete format document? If the latter, what process
>    should we use to vet those changes?

Please no changes. Any changes will need to be implemented and tested. That’s not the goal of this exercises. Let’s just document a snapshot of what we have right now. This will be the clearest starting point for new format work.

Mirja


> 
> - Pete and Eric (as chairs)
> 
> 
> [0] At least approximately. We are not making any claims that this
> document is entirely accurate.
> 
> [1] Strictly speaking, we could not publish any RFCs until (2) was
> completed, but I doubt anyone wants that.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> rswg mailing list
> rswg@rfc-editor.org
> https://mailman.rfc-editor.org/mailman/listinfo/rswg