Re: [CFRG] Proposed CFRG process for handling errata
Eric Rescorla <ekr@rtfm.com> Sun, 27 December 2020 22:29 UTC
Return-Path: <ekr@rtfm.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 774AD3A0CD2 for <cfrg@ietfa.amsl.com>; Sun, 27 Dec 2020 14:29:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
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, 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=rtfm-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 IEBGvFjrjV3I for <cfrg@ietfa.amsl.com>; Sun, 27 Dec 2020 14:28:58 -0800 (PST)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 6001D3A0CCC for <cfrg@irtf.org>; Sun, 27 Dec 2020 14:28:58 -0800 (PST)
Received: by mail-lf1-x12e.google.com with SMTP id o13so20273363lfr.3 for <cfrg@irtf.org>; Sun, 27 Dec 2020 14:28:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ttSocF6eoo03E0uPjbzv+/pWWtzs248zF40DWPmsUw0=; b=K1RoCHHgSUbtHz/snGIoUSJ9KPZmA6asKYfVrjPBaIBDaD0Y6cCUfs7ehsKv08txp+ uk91JuB6EVb38LoSUDIXDiOmRi1JHStO+hnZiMlREdrr1nWchvB2NYmPhKtad/KDcU5j CN0lyv7T1RYSDodAAQkhZs0n0mCnK7VEwIKAnP39jzCNcSUQzboZqJK/UWU8bGsIWyKc br3tHTz+g7PxAP/krkIJCddLOEE6BDc0Y18lPD/mnT+RncKTEYU+5minvYr2DJqq86cH QdTv2wh3N1j1vi5AqXI0Jve+APzsnQl5hNYOYawWdTJ2jczH9XhiOhsfxe00My13M+ew mKFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ttSocF6eoo03E0uPjbzv+/pWWtzs248zF40DWPmsUw0=; b=pGNdvpxDH06ep2XaBNHO73pQuxNEdJ2BzgCNrQ30fLRLY3u2A4nf5mWxUxmXY0eHiD 9M9rLWG77PmfgGg/Nu935+yPjrih182T+ZPZBJp9YucKI/QqPNBiIiTxKyHUf2HNqXQK QfzNIvYSPbRTlQ3HlVMcic1uHlEwCA/AxJHTrqFC4PF7gQ+wtm3FM9xYjlCvwocoD6YS yH80a5Dyq99IfDRxBZ5Z+mv5nh++hLCLCcQUhXXHMZ2S4+oZ0/yD4O0DNg6Op6yQKfhX sTnfF4vvkQl00Ox9CN0us6dj6cCRD7U1EnXCE+P2h7CUq/6SdDutsIWg2xXlNOk6zmZ2 9BOA==
X-Gm-Message-State: AOAM533ogf6vLD4wSEDN9A9VtW0QSjd92FiV8lQ5xXta+7Z6yOyIm4gP RIZY1vGu+78kys6csU4T1vkmywELu4kGA6aJBKQOXm6esvFgag==
X-Google-Smtp-Source: ABdhPJymoHm+jtBU29I+O87hGQAzNX9mT5HYUf7KuJun8OEgv0jnio9FOQglkeeKNV0084wOUujnBfq9gvnTnqqcnio=
X-Received: by 2002:a2e:918f:: with SMTP id f15mr19827140ljg.82.1609108136753; Sun, 27 Dec 2020 14:28:56 -0800 (PST)
MIME-Version: 1.0
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> <C3EB8DBD-40B4-4800-8452-80BDA100CF62@akamai.com> <392b54bf-afb3-81d7-84f4-857b2342ff9e@nthpermutation.com> <E6F8F1D5-DEEE-4E11-B453-E1CDD239D2D7@akamai.com> <CABcZeBM62XZSWN1P7rw3jbHukGD+WD=t9ptgJDXVh22OsyYXUQ@mail.gmail.com> <uwes80.qm0rf7.31eoyz-qmf@mercury.scss.tcd.ie>
In-Reply-To: <uwes80.qm0rf7.31eoyz-qmf@mercury.scss.tcd.ie>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 27 Dec 2020 14:28:20 -0800
Message-ID: <CABcZeBOVVt9RS8Em1f-g=8NR8QxsrLdCoSsHOtspP4DN90Ow2A@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, Russ Housley <housley@vigilsec.com>, cfrg <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="000000000000e58e4105b779aeba"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/4_xCp9oB7boCrsPzctz_8bTldoo>
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 22:29:01 -0000
On Sun, Dec 27, 2020 at 2:21 PM <stephen.farrell@cs.tcd.ie> wrote: > Hiya, > > On Sunday, 27 December 2020, Eric Rescorla wrote: > > To be honest, I'm torn. > > > > IMO Mike is right that what CFRG is doing is making standards and that > > that's traditionally the domain of the IETF. OTOH, as Rich, Stephen, and > > Uri have pointed out, the current process seems to be working well, so > I'd > > prefer not to disrupt that. I do think we should acknowledge that these > are > > standards (we implement based on them, they're full of normative > language) > > and perhaps it's worth looking into the question of how to publish them > on > > the standards track. Just thinking out loud, what if the IESG could > > cherry-pick to-be-published CFRG documents for ST publication > [potentially > > at the request of CFRG/IRTFC Chair], do a last call, and if there was > > consensus, publish them as Proposed Standard RFCs [perhaps on the IETF > > Stream?]. > > Not sure how much better that'd be vs. the downref registry? > Well, to the extent to which we think that things being labelled as Standards Track matters, then it seems suboptimal to have a bunch of documents which are effectively standards (and in many cases are far more widely deployed than many of our Standards) being Informational. And if it doesn't matter, than one might ask why we bother to publish our protocol specifications as PS. I recognize that in the past a number of cryptographic algorithms were brought in as Informational, but those were largely cases like MD5 where we were just creating a stable reference for something that was externally developed. ISTM that that's not the case for much of the CFRG's current work. -Ekr > S. > > > > > > -Ekr > > > > > > On Sun, Dec 27, 2020 at 1:55 PM Salz, Rich <rsalz= > > 40akamai.com@dmarc.ietf.org> wrote: > > > > > I am glad you said “all good points” > > > > > > I am worried about making any changes because what we have now is > working > > > very well. > > > _______________________________________________ > > > CFRG mailing list > > > 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