Re: [Rswg] Errata report notification (Re: [rsab] [Editorial Errata Reported] RFC9280 (7795))
John C Klensin <john-ietf@jck.com> Tue, 06 February 2024 21:58 UTC
Return-Path: <john-ietf@jck.com>
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 CEB04C14F6AA; Tue, 6 Feb 2024 13:58:35 -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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ucCnBdojUjrp; Tue, 6 Feb 2024 13:58:31 -0800 (PST)
Received: from bsa2.jck.com (bsa2.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 32B99C14F686; Tue, 6 Feb 2024 13:58:30 -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 1rXTSU-0004Yh-NU; Tue, 06 Feb 2024 16:58:26 -0500
Date: Tue, 06 Feb 2024 16:58:21 -0500
From: John C Klensin <john-ietf@jck.com>
To: Jean Mahoney <jmahoney@amsl.com>, "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>, RFC Editor <rfc-editor@rfc-editor.org>, Eliot Lear <lear@lear.ch>
cc: RSWG <rswg@rfc-editor.org>, rsab@rfc-editor.org
Message-ID: <3D33CB656142C9F33DA5BDD2@PSB>
In-Reply-To: <ce4d2324-6623-4881-8f74-bc4fcf8428bd@amsl.com>
References: <20240203084054.24DBB11821EE@rfcpa.amsl.com> <3f525194-e353-4c21-b4d6-8839c7f5e780@lear.ch> <719000BB-BE9F-42E8-8779-34D3FDB085BB@kuehlewind.net> <ce4d2324-6623-4881-8f74-bc4fcf8428bd@amsl.com>
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/rswg/tT86lnJmnvhVYKW_cNqltHz7abU>
Subject: Re: [Rswg] Errata report notification (Re: [rsab] [Editorial Errata Reported] RFC9280 (7795))
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, 06 Feb 2024 21:58:35 -0000
Jean, I don't think this is quite right and, unless there have been change recently, it may not be consistent with what I have observed over the years, even the last couple of years. My impression is that: (1) According to RFC 9280, the RSAB consists of "stream representatives". Especially for the IETF Stream (and even more especially for standards track and BCP documents), if the stream representative were appointed for expertise in editorial policy generally or RFC Series issues, they may not have the expertise needed to make technical judgments on claimed errors or even have more expertise than the RPC has about who would be the right person or group to whom to refer the alleged error. So I don't see strong justification for the RSAB to be involved at all except for documents that, perhaps because of age, the RPC cannot figure out how to route or even to which stream the error should be reported. (2) If the RPC can identify a stream, and for the IETF Stream (and maybe the IRTF or others) an area or active WG or equivalent, it would seem far more efficient --and less of a risk of missing something important-- if the report went to the relevant AD and WG and perhaps to whomever has lead technical (or technical coordination) responsibility for documents in that stream. At least as I read it, 9280 is quite clear that the stream representative to the RSAB is not required to be also hold that technical coordination role for the stream. My impression has been that what I suggest below actually has been the policy, at least until quite recently. So, I would think that for technical errata, the distribution should be To: authors, relevant stream technical contacts CC: reporter, rfc-editor@rfc-editor.org Where "relevant stream technical contacts" should be (where a relevant IETF WG is active): WG Chair(s), responsible AD and with the clear understanding that either of those can (and should if the situation is not completely obvious) include the WG in any discussion. (where there is an obvious WG, but it has closed): AD, former Chair(s) (potentially involving the WG mailing list if they think it appropriate) (where there is an obvious Area, but no easily identified WG Chair): ADs for Area (where even the Area is not obvious and for other streams): IESG or Steam leadership unless they have designated someone else or some other process. That said, I'd recommend against writing that down except, possibly, as general guidance. Instead, I think the RPC should be tasked with exercising good judgment about who to consult about particular errata (beyond the reporter and whatever authors might be available), drawing from records about who participated in AUTH48 (or predecessor processes) on the relevant documents and in what roles as appropriate. If they want to informally consult Stream or other people before sending out the errata correspondence at all, great, but, unless we like increased bureaucracy and overloading people who are probably already overloaded, that should not be a requirement either. And I suggest, with general guidance --formal or informal-- similar to the above and, assuming that it is obvious to everyone that the goal with an erratum that is identified as technical is to competently determine whether the error actually exists and the proposed remedy is correct, if we cannot trust the RPC to get such contacts right, we have far worse problems than errata handling. This also raises another issue that _might_ be a RSWG-level policy matter or might be left entirely to the Steams. The "editorial versus technical" distinction is fine for the RPC to make and, especially if they are as conservative about the former category in the future as I have experienced in the past, as far as they should go. But I think that, at the next stage in the process (and especially for IETF standards track and BCP documents), it would be helpful to explicitly divide the technical ones into, e.g., minor/trivial and substantive. For the latter, we (and the errata process) should keep in mind that documents that are approved and published by community consensus --and represented externally has having community consensus-- should not be altered or updated (including errata approval especially if we are going to make versions of documents with approved errata incorporated) by the decisions of a handful of people, working outside public view, about what they think the community intended. If that implies that "minor/trivial" gets considered further through the errata process and everything else goes immediately into "hold for document update", so be it. thanks, john --On Monday, February 5, 2024 13:56 -0600 Jean Mahoney <jmahoney@amsl.com> wrote: > Hi all, > > The errata system is currently set up to send errata report > notifications to the following: > > For technical errata reports: > > To: authors, RSAB > CC: reporter, rfc-editor@rfc-editor.org > > For editorial errata reports: > > To: rfc-editor@rfc-editor.org > CC: reporter, authors > > Note that the RPC verifies reports that are of editorial > nature (e.g., basic typos, punctuation mistakes, etc.). If we > cannot verify the report (i.e., the suggested correction > changes the meaning of the text), we will set the report type > to "technical" and forward it to the verifier of technical > reports. For instance, I would consider the change described > in this report to be beyond editorial. > > We can add RSWG to the CC: list for both types of reports. > RSAB is considered the verifying party for technical reports. > Please let us know if any other changes to notifications are > required. > > Best regards, > Jean > > > On 2/5/24 5:42 AM, Mirja Kuehlewind (IETF) wrote: >> Thanks Eliot for forwarding. >> >> If I see this correctly, this errata report was only send to >> rfc-editor@rfc-editor.org. This seems to be the right address >> to handle the errata, however, as we do also send IETF/IRTF >> errata to the respective working/research group, I think it >> would be good to send all errata reports for the editorial >> stream also to RSWG (and probably also RSAB). >> >> Mirja >> >> >> >>> On 3. Feb 2024, at 09:43, Eliot Lear <lear@lear.ch> wrote: >>> >>> FYI and for discussion. >>> >>> >>> >>> -------- Forwarded Message -------- >>> Return-Path: <wwwrun@rfcpa.amsl.com> >>> Authentication-Results: upstairs.ofcourseimright.com; >>> dmarc=none (p=none dis=none) header.from=rfc-editor.org >>> Received: from rfcpa.amsl.com (rfcpa.amsl.com >>> [50.223.129.200]) by upstairs.ofcourseimright.com >>> (8.15.2/8.15.2/Debian-22ubuntu3) with ESMTPS id >>> 4138et9h1897964 (version=TLSv1.3 >>> cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for >>> <lear@lear.ch>; Sat, 3 Feb 2024 09:40:57 +0100 >>> Received: by rfcpa.amsl.com (Postfix, from userid 499) id >>> 24DBB11821EE; Sat, 3 Feb 2024 00:40:54 -0800 (PST) >>> To: rfc-editor@rfc-editor.org >>> Subject: [Editorial Errata Reported] RFC9280 (7795) >>> From: RFC Errata System <rfc-editor@rfc-editor.org> >>> Cc: lear@lear.ch, stpeter@stpeter.im >>> Content-Type: text/plain; charset=UTF-8 >>> Message-Id: <20240203084054.24DBB11821EE@rfcpa.amsl.com> >>> Date: Sat, 3 Feb 2024 00:40:54 -0800 (PST) >>> >>> >>> >>> The following errata report has been submitted for RFC9280, >>> "RFC Editor Model (Version 3)". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> https://www.rfc-editor.org/errata/eid7795 >>> >>> -------------------------------------- >>> Type: Editorial >>> Reported by: Eliot Lear <lear@lear.ch> >>> >>> Section: 8 >>> >>> Original Text >>> ------------- >>> Updates, amendments, and refinements to this document can be >>> produced using the process documented herein but shall be >>> published and operative only after (a) obtaining the >>> agreement of the IAB and the IESG and (b) ensuring that the >>> IETF LLC has no objections regarding its ability to >>> implement any proposed changes. >>> >>> Corrected Text >>> -------------- >>> Updates, amendments, and refinements to this document can be >>> produced using the process documented herein but, unless >>> otherwise specified in this document, shall be published and >>> operative only after (a) obtaining the agreement of the IAB >>> and the IESG and (b) ensuring that the IETF LLC has no >>> objections regarding its ability to implement any proposed >>> changes. >>> >>> >>> Notes >>> ----- >>> Section 7 explicitly states: >>> >>> "Proposals that affect these properties are possible within >>> the processes defined in this document." >>> >>> And it goes on from there to discuss RSWG/RSAB review. >>> >>> Therefore, it should not be necessary for the IAB, IESG, and >>> LLC to approve changes in Section 7. That is just a >>> for-instance. There may be other examples. >>> >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". (If it is >>> spam, it will be removed shortly by the RFC Production >>> Center.) Please use "Reply All" to discuss whether it should >>> be verified or rejected. When a decision is reached, the >>> verifying party will log in to change the status and edit >>> the report, if necessary. >>> >>> -------------------------------------- >>> RFC9280 (draft-iab-rfcefdp-rfced-model-13) >>> -------------------------------------- >>> Title : RFC Editor Model (Version 3) >>> Publication Date : June 2022 >>> Author(s) : P. Saint-Andre, Ed. >>> Category : INFORMATIONAL >>> Source : IAB >>> Area : N/A >>> Stream : IAB >>> Verifying Party : IAB >>> >> >>> -- >>> RSAB mailing list >>> RSAB@rfc-editor.org >>> https://mailman.rfc-editor.org/mailman/listinfo/rsab >>
- [Rswg] Fwd: [Editorial Errata Reported] RFC9280 (… Eliot Lear
- Re: [Rswg] [rsab] [Editorial Errata Reported] RFC… Mirja Kuehlewind (IETF)
- Re: [Rswg] [rsab] [Editorial Errata Reported] RFC… Eliot Lear
- [Rswg] Errata report notification (Re: [rsab] [Ed… Jean Mahoney
- Re: [Rswg] [rsab] [Editorial Errata Reported] RFC… Mirja Kuehlewind (IETF)
- Re: [Rswg] [rsab] [Editorial Errata Reported] RFC… Mirja Kuehlewind (IETF)
- Re: [Rswg] Errata report notification (Re: [rsab]… John C Klensin
- Re: [Rswg] Errata report notification (Re: [rsab]… Jean Mahoney
- Re: [Rswg] Errata report notification (Re: [rsab]… Martin Thomson
- Re: [Rswg] Errata report notification (Re: [rsab]… John C Klensin
- Re: [Rswg] [rsab] [Editorial Errata Reported] RFC… Eliot Lear
- Re: [Rswg] Errata report notification (Re: [rsab]… John C Klensin
- Re: [Rswg] Errata report notification (Re: [rsab]… Mirja Kuehlewind (IETF)
- Re: [Rswg] Errata report notification (Re: [rsab]… Jean Mahoney
- Re: [Rswg] Errata report notification (Re: [rsab]… Mirja Kuehlewind (IETF)