Re: [CFRG] Proposed CFRG process for handling errata

stephen.farrell@cs.tcd.ie Sun, 27 December 2020 21:52 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1EA3A0C59 for <cfrg@ietfa.amsl.com>; Sun, 27 Dec 2020 13:52:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FHGkqBTiJO5 for <cfrg@ietfa.amsl.com>; Sun, 27 Dec 2020 13:52:19 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A22B43A0907 for <cfrg@irtf.org>; Sun, 27 Dec 2020 13:52:19 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 79E37BE5C; Sun, 27 Dec 2020 21:52:17 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHVLx66C6voa; Sun, 27 Dec 2020 21:52:14 +0000 (GMT)
Received: from [10.244.2.235] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 932DCBE58; Sun, 27 Dec 2020 21:52:14 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1609105934; bh=3iiql2BmIF5hc3+TmyU2e7lr8EEQM93FKU1PJcB5lnU=; h=To:Cc:From:Subject:In-Reply-To:References:Date:From; b=xZd2dvvorjP1QIYr9ZGv9JEPtzc+xhcupQKdsTQ1C5dP8WmaRu4ajmndOiwCvx2ay 2LtZxpaH77S/4ffjtkr8ZtCUr1sXH2ECXttnzUh8buNuDKauT6py9LXJM5FH0iE6d+ 8NkP6dMjkSluMFisigsBeWLkcVsTTd3HCv2Ldo0c=
X-Priority: 3
To: msj@nthpermutation.com,housley@vigilsec.com
Cc: cfrg@irtf.org
From: stephen.farrell@cs.tcd.ie
In-Reply-To: <88d7d41d-e750-4d53-9488-8c1bbacf54e8@nthpermutation.com>
References: <40067f90-ec2c-2a36-f6df-8afa97189cd1@isode.com> <47855176-ce02-07b2-3f78-6f373c6f118d@isode.com> <a822af77-d732-73d8-c2e9-475b1fcbb6c2@nthpermutation.com> <EF008FEE-F053-4595-ADEA-CD2E416B2DEB@vigilsec.com> <88d7d41d-e750-4d53-9488-8c1bbacf54e8@nthpermutation.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
Date: Sun, 27 Dec 2020 21:52:13 +0000
Message-ID: <zgwjav.qm0q32.31eoyz-qmf@mercury.scss.tcd.ie>
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/6dAANy06AdOtlW7gH7u4Iuktta0>
Subject: Re: [CFRG] Proposed CFRG process for handling errata
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 27 Dec 2020 21:52:22 -0000

Hi Mike,

On Sunday, 27 December 2020, Michael StJohns wrote:
> 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.
>

I disagree. We have what seems to me to be a setup that's worked these past years with technologists and academic cryptographers collaborating  and I see no reason to risk that success for possible process purity.

Cheers, 
S. 
 
> Mike
> 
> 
> 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 <msj@nthpermutation.com 
> >> <mailto:msj@nthpermutation.com>> 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 www.rfc-editor.org website An 
> >>> erratum on a CFRG document results in email to irsg@irtf.org 
> >>> (+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 
> >>> <https://trac.ietf.org/trac/irtf/wiki/Crypto%20Review%20Panel>, by 
> >>> emailing crypto-panel@irtf.org 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 <cfrg@irtf.org> 
> >>> 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@irtf.org
> >>> https://www.irtf.org/mailman/listinfo/cfrg
> >>
> >>
> >> _______________________________________________
> >> CFRG mailing list
> >> CFRG@irtf.org <mailto:CFRG@irtf.org>
> >> https://www.irtf.org/mailman/listinfo/cfrg
> >
> 
>