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

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

Jean,

Sorry for the confusion.  For the editorial stream, the RSAB
(possibly even copying this list as Martin more or less
suggested) seems quite reasonable.  If we, as a WG (and, IMO,
one with particularly strong tendencies toward extended
discussions of small details) have approved a document that
contains errors of a technical nature, probably letting us know
is entirely appropriate.

best,
   john


--On Tuesday, February 6, 2024 16:15 -0600 Jean Mahoney
<[e-mail]> wrote:

> John,
> 
> On 2/6/24 3:58 PM, John C Klensin wrote:
>> 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.
> 
> [JM] I should have clarified that the following notification
> lists are for Editorial Stream documents only:
> 
> <snip>
>>> 
>>> 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
> 
> [JM] The errata system can be updated to notify RSWG for both
> report types. RSAB would be the verifier for Editorial Stream
> technical issues (that is, for errata that would change the
> meaning of the text) and the RPC would verify editorial errata
> (e.g., typos). RSAB can consult with RSWG when working through
> any reports.
> 
> Best regards,
> Jean
> 
>>> 
>>> 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
>>>> 
>> 
>>