Re: [CFRG] Proposed CFRG process for handling errata

Michael StJohns <> Sun, 27 December 2020 21:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BE5B83A0C4E for <>; Sun, 27 Dec 2020 13:37:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 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, RCVD_IN_DNSWL_BLOCKED=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 gC2vT5-HkMCT for <>; Sun, 27 Dec 2020 13:37:27 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7ECA33A0C4D for <>; Sun, 27 Dec 2020 13:37:27 -0800 (PST)
Received: by with SMTP id c7so7613120qke.1 for <>; Sun, 27 Dec 2020 13:37:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=u7e2E8hDy92swSRsam/QECEqBi+3Nea/62ijWuz0z14=; b=kSJgcGK71C/F/6zTk008m/BllA2R3aaAac+1s1WGScFE7q+FTivJiIZxSPlVYYcSvQ B6/AcQbi1AgECRJjxLJqwR/scldvQhQq8jVQFKLwhYwPmtP4i5WHPW+nqqt4kWYidFGA ivk/tow+rU5mpIAuH2nOqQyw0LA5r4Vq8sLwMp/3BE8vkEJy6CfeCMY1fuEoo1owvj+J iWbklmT5BFQiTQzlNg4jqK+Cu2T8nQV/yUHZ5bR7jpgn9YiNgqYE8iK1oxWY3SqIuH1e rA4DJBP9LVu+forAkLEB7ZaTwcapwOZSlfwiln/cXDg4nAga0hF+Yy6Hwg9hWW1F+jtX FuoA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=u7e2E8hDy92swSRsam/QECEqBi+3Nea/62ijWuz0z14=; b=aIoHhdgDGT+1AtBgob8Cetu5qQ616vG7wOR+B6EU1xClrgBTvFXUjTKzJqNeU9Bno2 BNCAEWvQzoJLR4ZFu1Qqkb+/bqQciqUnc3XdV023dtLKa5weKUQOFP+bKGio01aPv1hS GQon4udaR4Y2BAIwYOnRfAVdymAVo3mng+URsUIxM+M1H9IXNxSAHxkCG0phCJxfQjHm fc/JtwkTWjNC20yPSgBZZ7X+HjftOAZMAuoJjrJxwPvt6+yjJWADHhSX8sEbLQTK533A 9aW002x99OJYlMC+VAJCI0OyTG7hxg7QgAXh1Cg1hyH1vyz/VRkWlK8isddiOLkFMCAw Qfig==
X-Gm-Message-State: AOAM5330/1ollhgCqqoCZ57+q1f3vli/76x5oO1IL1qGA3LW0co22bQT W2MHkSf4xKraQ33iwpz5O96jfuOSo8rpJwG0
X-Google-Smtp-Source: ABdhPJwujZbAqhdKft2wvl6hyEZAjI0btqx/R+yaNdvhkOYo3GHvuWIPWB1U6wCSOri0TOkzCehRjg==
X-Received: by 2002:ae9:e854:: with SMTP id a81mr41829860qkg.77.1609105046069; Sun, 27 Dec 2020 13:37:26 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id c14sm20505747qtp.4.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 27 Dec 2020 13:37:25 -0800 (PST)
To: Russ Housley <>
References: <> <> <> <>
From: Michael StJohns <>
Message-ID: <>
Date: Sun, 27 Dec 2020 16:37:24 -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="------------3BD94D02669D4BD35F64A9EC"
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: Sun, 27 Dec 2020 21:37:30 -0000

Hi Russ -

We ought to stop promoting the fiction that the CFRG isn't doing 
standards and move the CWG part over to the IETF where it belongs.  I 
don't actually have a problem with the errata by itself, but I do when 
you add it to calls for adoption, group consensus, last calls and the 
whole set of things more appropriate for the standards process than what 
the IRTF was intended to be.


On 12/27/2020 2:50 PM, Russ Housley wrote:
> As you say, the CFRG is not like many other RGs.  Crypto algorithm 
> specifications, while informational, ofter become normative references 
> in standards.  For this reason, I think robust handling of errata is 
> desirable.
> Russ
>> On Dec 25, 2020, at 7:59 PM, 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.
>> 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
>> _______________________________________________
>> CFRG mailing list
>> <>