Re: [rsab] [Rswg] Errata report notification (Re: [Editorial Errata Reported] RFC9280 (7795))

[John C Klensin <[e-mail]>]

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, [e-mail]

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
<[e-mail]> 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, [e-mail]
> 
>     For editorial errata reports:
> 
>        To: [e-mail]
>        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 
>> [e-mail]. 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 <[e-mail]> wrote:
>>> 
>>> FYI and for discussion.
>>> 
>>> 
>>> 
>>> -------- Forwarded Message --------
>>> Return-Path: 	<[e-mail]>
>>> 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
>>> <[e-mail]>;  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: 	[e-mail]
>>> Subject: 	[Editorial Errata Reported] RFC9280 (7795)
>>> From: 	RFC Errata System <[e-mail]>
>>> Cc: 	[e-mail], [e-mail]
>>> Content-Type: 	text/plain; charset=UTF-8
>>> Message-Id: 	<[e-mail]>
>>> 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 <[e-mail]>
>>> 
>>> 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
>>> [e-mail]
>>> https://mailman.rfc-editor.org/mailman/listinfo/rsab
>>