Re: [CFRG] Proposed CFRG process for handling errata

Alexey Melnikov <> Wed, 30 December 2020 10:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CBF1B3A040B for <>; Wed, 30 Dec 2020 02:47:24 -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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HTmQ4p5YWWIA for <>; Wed, 30 Dec 2020 02:47:22 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 62E383A03FC for <>; Wed, 30 Dec 2020 02:47:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1609325241;; s=june2016;; bh=PWvk2Sjuo+3bw2UZibPzo+QgwvyDcBk1xFM3vD9ZpWQ=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=fnV/SSiCoKFZWhlljZXtXCM69Sx8EXrqvyfLEaGTFoyYxaFQJyaMzyaCRETkMRDjXyZrp1 QOX+ltvyebqjhM1X1IBhBzkTzh/RZ5P6evoVh+wrz6rzym0VijisJZqXiTKJKT5ETS37vm 027WhItbSGPjFAh6RIAMP7l/MbzNjtw=;
Received: from [] ( []) by (submission channel) via TCP with ESMTPSA id <>; Wed, 30 Dec 2020 10:47:20 +0000
To: Michael StJohns <>,
References: <> <> <>
From: Alexey Melnikov <>
Message-ID: <>
Date: Wed, 30 Dec 2020 10:46:37 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------89540927078589344C36FBEB"
Content-Language: en-GB
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: Wed, 30 Dec 2020 10:47:25 -0000

Hi Michael,

On 26/12/2020 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 endeavo_*r.
Colin already replied with most I had to say, but I will add one thing: 
we (CFRG chairs) are not trying to create extra process just for the 
process sake. We handled errata on ad-hoc basis in the past and we 
dropped the ball several times. We got a complain about lack of 
transparency, so the proposed process is to help address that.
> 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, i_*t 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.

I was always told that IRTF RG can create own process that suites them.

Best Regards,


> 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