Re: [CFRG] Proposed CFRG process for handling errata

Michael StJohns <> Sat, 26 December 2020 00:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B09093A0E7C for <>; Fri, 25 Dec 2020 16:59:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 nN5jwAnAvUzt for <>; Fri, 25 Dec 2020 16:59:37 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A3E453A09E8 for <>; Fri, 25 Dec 2020 16:59:37 -0800 (PST)
Received: by with SMTP id 19so4811813qkm.8 for <>; Fri, 25 Dec 2020 16:59:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=ge3B6NIDCFSfsm4oz4eHuiITaIPF9jtjpKpnpbJ3+7c=; b=0F7E0FuRBt1gi+j+1C++pl1CTfFqXwAegmWzH5eE7xDLUBAeDJaTD/Fe6fm1wxvOXj BDQGTFp7XRoUP1cYBQRv1vb0M9NkZMRlT3N/hxHcNAFAQ5XRxRlxHwBabDxkvAbVgzzF n1bA/5GTCWvEJgsTV9KZMaOO8wL5jGDDCuu2XMSKwTjJzOR7IZrWtcEgRgpYbEeZNydf 6PLeLRfVRsAXJ6k5Yg4LFOyDJ5Jm+vjJ/50d3Qh9Nq6KC4QYTYIgBoqD/kVN67F/DlrZ nwpDlonEuCKsuYmMTCcYf3S4jC2TFzds4NB4ziGgv0PHJkdhJfgCisO4jLje35BY5J75 NgfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=ge3B6NIDCFSfsm4oz4eHuiITaIPF9jtjpKpnpbJ3+7c=; b=IOAlKAPbXDLYrCr30us8gLxX+KDZUPuLTEKypaGIFEEVTVEO81FbkGHWY5lqyRlAcW YnYuTiqfu3AuUwOJUwgtXy3DGKhzOnonxErAaY2FU6rGP9RLgewjnrH2GMvaP1hUs1CB 52DZef3+/MHe4t5Cg2o3BOG0GsXzY51Qr9AWAGW7M9ZDZp1NPUp73usJpg4C23hdR73K prmEu41lFKZXvNXGe9OThOGqzwW5nn7Gf734WmlWtWcZz8KPiQYjuoByelW+hT5ADhaC 3gu581U4+HQfjJcyKTkEb5MjyNVxF5sezu5YuRLSg/5AcLL7ckqPXSsJQCD1/K0Rgqsn ZcWQ==
X-Gm-Message-State: AOAM533Bb1Zo5dUBmjL7IblhJZ7oEwtbBPpQbNYotmh+qNS6+e9fyGB/ DoO3AeMr7sb7yb59gV/KwTF7mzXeYcExvVEV
X-Google-Smtp-Source: ABdhPJzewJEr9ySNRJPSbW2YZd4UqYreJPAAsPdhVjglbdWhF9/mmFf4E+jyZN+T51m/shV2XTCRng==
X-Received: by 2002:a05:620a:2227:: with SMTP id n7mr34733135qkh.153.1608944370771; Fri, 25 Dec 2020 16:59:30 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id h1sm18703553qtr.1.2020. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 25 Dec 2020 16:59:30 -0800 (PST)
References: <> <>
From: Michael StJohns <>
Message-ID: <>
Date: Fri, 25 Dec 2020 19:59:28 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------3735282CA9075ACF36438217"
Content-Language: en-US
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 00:59:40 -0000

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.

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.

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