Re: [CFRG] Proposed CFRG process for handling errata

Colin Perkins <> Sat, 26 December 2020 13:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E11A33A1085 for <>; Sat, 26 Dec 2020 05:24:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Kp9EmCQ80s0p for <>; Sat, 26 Dec 2020 05:24:44 -0800 (PST)
Received: from ( [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 755763A1080 for <>; Sat, 26 Dec 2020 05:24:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=mythic-beasts-k1; h=To:Date:Subject:From; bh=FcpOSHDEI2kPmtjraY9+/xHw+Zt/UjEKZ0T6Pw7SLFo=; b=b9X1M5otBSwAZJiW9U4mB+UOry 2ShWoO/RUY5u9aYv44aZVANApRgI2UKOv8/NyogGMnsj0PO7kMv/Szf1N201TnL2DgJ8rEAK7WQcG QBAtDNSiWCTJrSq7KAL3UprUw+ggKhKfIx3funIP+ruT4F8jmXtHwhPKZGScZoCd/YqENgbgJt2oP H9KQ1LdGTMIWExcgK4tEumd0L6g82/hcDd88IfTs3326e925rUKfiWY8GI1y93Hp7HSN0+NODHBzF rUaqoxgNApV7Gs2Jjki5rLk0AOOcmojo2GUBudQkCzs5cyVdnt5eoaGc5mt73u5dkfh2zW3XgnTOC g842f68g==;
Received: from [] (port=43925 helo=[]) by with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from <>) id 1kt9Yk-0004sN-Kj; Sat, 26 Dec 2020 13:24:43 +0000
From: Colin Perkins <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A2FE425E-9D49-4A41-93F6-D43DF5A7BA9E"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Date: Sat, 26 Dec 2020 13:24:34 +0000
In-Reply-To: <>
To: Michael StJohns <>
References: <> <> <>
X-Mailer: Apple Mail (2.3445.104.17)
X-BlackCat-Spam-Score: 14
Archived-At: <>
Subject: Re: [CFRG] Proposed CFRG process for handling errata
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 26 Dec 2020 13:24:48 -0000


Corrections and errata are common for published for research papers, whether published as RFCs or by more traditional academic publishers.

As IRTF Chair, and approver of errata for IRTF stream RFCs, I asked the CFRG Chairs to develop a process to help me ensure errata for RFCs produced by CFRG are correctly resolved. Nothing in this proposal conflicts with RFC 2014.


> On 26 Dec 2020, at 00:59, Michael StJohns <> wrote:
> Hi Alexey -
> From a general philosophy, this seems to conflict with the general guidance for RGs - specifically (RFC 2014 "IRTF Research Group Guidelines and Procedures" - section 1.1 ): 
>>  Even more than the IETF, the work of the IRSG is expected to be
>>    marked by informality.  The goal is to encourage and foster valuable
>>    research, not to add burdensome bureaucracy to the endeavor.
> I brought up a while back that the CFRG has taken on more of the characteristics of a WG than an RG and it may be appropriate to recharter the group under the IETF as a WG or even co-charter it as both an RG and WG.  Let me make that point again.
> Also in section 1.1: 
>>  The IRTF does not set standards, and thus has somewhat different and
>>    complementary philosophy and procedures.  In particular, an IRTF
>>    Research Group is expected to be long-lived, producing a sequence of
>>   "products" over time.  The products of a Research Group are research
>>    results that may be disseminated by publication in scholarly journals
>>    and conferences, as white papers for the community, as Informational
>>    RFCs, and so on.  In addition, it is expected that technologies
>>    developed in a Research Group will be brought to the IETF as input to
>>    IETF Working Group(s) for possible standardization.   However,
>>    Research Group input carries no more weight than other community
>>    input, and goes through the same standards setting process as any
>>    other proposal.
> Errata is appropriate for standards - less so for research papers.  
> Or to put it more succinctly - I object to the addition of more process to the RG.  I further suggest that if this isn't apropriate as  IRTF wide process, then it's probably not within the remit of the CFRG to create its own processes - no more than it would for a WG.
> Later, Mike
> ps - feel free to propose amendments to RFC2014, but at AFAICT that document  is the one that describes the current general contract for RGs.
> On 12/24/2020 5:25 AM, Alexey Melnikov wrote:
>> Dear CFRG participants, 
>> Below is the proposed process that CFRG chairs would follow when handling errata submitted on CFRG documents. 
>> Please let chairs know by January 16th if you have comments or concerns. Statements of support for this proposal are also welcome. 
>> ------------ 
>> An erratum is submitted through <> website An erratum on a CFRG document results in email to <> (+authors/editors of the RFC) with subject like "[Technical Errata       Reported] RFCXXXX (YYYY)", where XXXX is the relevant RFC number and YYYY is the corresponding erratum number (assigned automatically by RFC Editor's website). 
>> Note that the current errata system is not designed for reporting of extensions and things that were not known or intended at the time the document was written. It is only designed for reporting problems/bugs in documents. 
>> One of CFRG chairs becomes the response CFRG chair for the erratum. He/she verifies that the erratum designation (Technical versa Editorial) is correct. (Note that the designation can be changed later and it is Ok if initially it is unclear for some errata which one it is.) The CFRG chair can also request deletion of obviously bogus erratum, such as submitted by spammers. 
>> The CFRG chair then can optionally request review from the Crypto Review Panel<> <>, by emailing <> and asking for comments on how to resolve the erratum. A proposed resolution can be suggested, if available. The request should specify a deadline, typically 2 weeks. This deadline can be extended by request from Crypto Review Panel members. Note that feedback from Crypto Review Panel is advisory in nature. 
>> The CFRG chair then emails the CFRG mailing list <> <> asking for comments on how to resolve the erratum. (Possible subject to use: "Proposed resolution for erratum YYYY on RFC XXXX") A proposed resolution can be suggested, if available. The proposed resolution takes into consideration feedback received from the Crypto Review Panel (if requested). The request should specify a recommended deadline for discussions. 
>> The CFRG chair follows the CFRG mailing list discussion of the erratum resolution and posts a summary email after the deadline expires. If there is a clear resolution ("accept", "reject" or "hold for document update") the suggested resolution (and possible changes to the erratum text) are included in the summary email. The IRTF Chair should be notified about the proposed resolution for the erratum. 
>> The IRTF Chair verifies outcome of the process and either acts on the erratum as proposed by the CFRG chair or delegates this decision to another person (who might be the CFRG chair). (The IRTF chair can provide technical feedback on the erratum in his/her personal capacity. The IRTF Chair can also restart discussion of the erratum on the CFRG mailing list.) 
>> ------------ 
>> Best Regards, 
>> Alexey, for the CFRG chairs 
>> _______________________________________________ 
>> CFRG mailing list 
>> <> 
>> <> 
> _______________________________________________
> CFRG mailing list

Colin Perkins