Re: [CFRG] Proposed CFRG process for handling errata
Michael StJohns <msj@nthpermutation.com> Sun, 27 December 2020 21:37 UTC
Return-Path: <msj@nthpermutation.com>
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 67B373A0CDC for <cfrg@ietfa.amsl.com>; Sun, 27 Dec 2020 13:37:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com
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 ND_-4S2QJ-1G for <cfrg@ietfa.amsl.com>; Sun, 27 Dec 2020 13:37:37 -0800 (PST)
Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B0313A0CB7 for <cfrg@irtf.org>; Sun, 27 Dec 2020 13:37:37 -0800 (PST)
Received: by mail-qt1-x82d.google.com with SMTP id y15so5901612qtv.5 for <cfrg@irtf.org>; Sun, 27 Dec 2020 13:37:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=y1FMFYKFEnaBTeSOJfsEnP0FKMRGD+JU+ccnv95UuwI=; b=kYr7IIWr6Qx2JkoSmx+0msYJqCeQbZbHdRfty0xhmrGeFzlTvp8DMT3RajZTuonzem r/bzKgfEza9jTA2GNYjOKzMmDm0iKI05jFCovbG6oxxCxJcBTIPbjK0i8F48ojNADqDA dJewa2kzlq+sGW4F+iheICkucNmk0BoqGAytN4Z+7Ms2REYwfq+RHgxxNwnodem5KCRP jyvhuy/wy+JhPtUtilznDB8H1WMojGD+4wVca/8fzP/sRxZYs1t8vkwLy9zaPk38RHbs z9yjTPWP1rLs6lo8wjCIVvvfjft9k83QEfw2IYF2mEHn/MZQHNHG+U63pSeSi7kcErYM 1c/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=y1FMFYKFEnaBTeSOJfsEnP0FKMRGD+JU+ccnv95UuwI=; b=IAqJ8rSCEbavl0o1slSL9wZtaAf4JEY/iZ2HaNAlFmFI4dLBqxFOmJX9fhDWQvQJGK Yb1BdQmK1D8t0vZrOy3WxIPwBvzPuHMTMRKpNUb9CFIYtqmH6IqWJJ/DrcQTbo5rLAwd D/Zvc9of1DrafQRPSFiz+y/gSlCgEZV/nCWsxUaqiROz/YxCJhpEGPGVc8At2VSrE0nG XaMcmm+X0NsnUfSNLz6Ug/V6X5RQD0gYprzr2+v3RieFZGjElWF8qA/nwNfgWuKR7Kq/ O4PX7ACJepRxDevsObQmU9ANM83si3zdEtq2atZ6BGskHRzZ1uUmlnpvEYyuyvrbwcL1 ySzg==
X-Gm-Message-State: AOAM533iM3Sa+vCDRcxJAfpTvtXBWAKZ+2M4faSR2ghvqLR/j7ur8rPm nogezxGOGvnP8n+BNOk+TmgtXvJZDJt6xrTh
X-Google-Smtp-Source: ABdhPJyCQUH77Tan2P9gxa16jTpJ4Z0veDmWYGNlRhdUqxpLo6hXWQ/4fGN/zCY1P5EKKmiVCo1rew==
X-Received: by 2002:aed:23d6:: with SMTP id k22mr42023585qtc.226.1609105056305; Sun, 27 Dec 2020 13:37:36 -0800 (PST)
Received: from [192.168.1.23] (pool-108-28-189-254.washdc.fios.verizon.net. [108.28.189.254]) by smtp.gmail.com with ESMTPSA id s19sm18419610qta.35.2020.12.27.13.37.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 27 Dec 2020 13:37:35 -0800 (PST)
To: Russ Housley <housley@vigilsec.com>
Cc: IRTF CFRG <cfrg@irtf.org>
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>
From: Michael StJohns <msj@nthpermutation.com>
Message-ID: <88d7d41d-e750-4d53-9488-8c1bbacf54e8@nthpermutation.com>
Date: Sun, 27 Dec 2020 16:37:33 -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: <EF008FEE-F053-4595-ADEA-CD2E416B2DEB@vigilsec.com>
Content-Type: multipart/alternative; boundary="------------7E8E85E4A517DAC76A58D096"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/PneMQiAFqsm0p0sN11fgzPcHqIs>
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:37:47 -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. 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 >
- [CFRG] Proposed CFRG process for handling errata Alexey Melnikov
- Re: [CFRG] Proposed CFRG process for handling err… Russ Housley
- Re: [CFRG] Proposed CFRG process for handling err… James Muir
- Re: [CFRG] Proposed CFRG process for handling err… Michael StJohns
- Re: [CFRG] Proposed CFRG process for handling err… Colin Perkins
- Re: [CFRG] Proposed CFRG process for handling err… Russ Housley
- Re: [CFRG] Proposed CFRG process for handling err… Salz, Rich
- Re: [CFRG] Proposed CFRG process for handling err… Michael StJohns
- Re: [CFRG] Proposed CFRG process for handling err… Michael StJohns
- Re: [CFRG] Proposed CFRG process for handling err… Michael StJohns
- Re: [CFRG] Proposed CFRG process for handling err… stephen.farrell
- Re: [CFRG] Proposed CFRG process for handling err… Salz, Rich
- Re: [CFRG] Proposed CFRG process for handling err… Blumenthal, Uri - 0553 - MITLL
- Re: [CFRG] Proposed CFRG process for handling err… Eric Rescorla
- Re: [CFRG] Proposed CFRG process for handling err… stephen.farrell
- Re: [CFRG] Proposed CFRG process for handling err… Eric Rescorla
- Re: [CFRG] Proposed CFRG process for handling err… Alexey Melnikov
- Re: [CFRG] Proposed CFRG process for handling err… Alexey Melnikov