Re: [openpgp] who creates old-rfc registries?
Ángel <angel@16bits.net> Mon, 01 March 2021 02:08 UTC
Return-Path: <angel@16bits.net>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98A153A129F for <openpgp@ietfa.amsl.com>; Sun, 28 Feb 2021 18:08:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 XQT89gC3VBRP for <openpgp@ietfa.amsl.com>; Sun, 28 Feb 2021 18:08:07 -0800 (PST)
Received: from mail.direccionemail.com (mail.direccionemail.com [199.195.249.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2A603A129E for <openpgp@ietf.org>; Sun, 28 Feb 2021 18:08:06 -0800 (PST)
Message-ID: <ac0cb30914c159db92786a24943e55233620ede0.camel@16bits.net>
From: Ángel <angel@16bits.net>
To: openpgp@ietf.org
Date: Mon, 01 Mar 2021 03:08:04 +0100
In-Reply-To: <87v9aecg7i.fsf@fifthhorseman.net>
References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> <4f3d66b74b46b5b8bf27b5e1589bf80e.squirrel@mail2.ihtfp.org> <87a6rug0x5.fsf@wheatstone.g10code.de> <8473b015f635c0f88f9bceed8acda0f8.squirrel@mail2.ihtfp.org> <239af1473534565304e2ecfeca630219417ebc0e.camel@16bits.net> <87v9aecg7i.fsf@fifthhorseman.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/Z6kuNJ-yx5ru5WS07ei8vSRizhg>
Subject: Re: [openpgp] who creates old-rfc registries?
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Mar 2021 02:08:09 -0000
> > Procedural question: is it the right thing for a RFC to state that it "creates a > > new registry" for those registries which were actually created by an older RFC > > it is obsoleting? > > If you're talking about the Notation Flags registry, it doesn't > currently exist at IANA: > > https://www.iana.org/assignments/pgp-parameters/pgp-parameters.xhtml > > So yes, while the initial values that populate it came from the older, > obsoleted RFC, this RFC *is* the one that is creating the registry. No. I'm talking about every section but the "Signature Notation Data Subpacket Notation Flags" :-) The other sections of §10 were already created by 4880. It's probably explained somewhere, although I don't find the exact answer. I see however that https://www.rfc-editor.org/rfc/rfc8126.html#section-8 mentions IANA registration info should be updated to the new RFC, so I guess the answer is that instead of "This specification creates a registry" they should all be "This specification becomes the reference for registry…" or something along that line. I have opened https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/23 to track this. Best regards
- [openpgp] I-D Action: draft-ietf-openpgp-crypto-r… internet-drafts
- Re: [openpgp] I-D Action: draft-ietf-openpgp-cryp… Paul Wouters
- Re: [openpgp] I-D Action: draft-ietf-openpgp-cryp… Derek Atkins
- Re: [openpgp] I-D Action: draft-ietf-openpgp-cryp… Robert J. Hansen
- Re: [openpgp] I-D Action: draft-ietf-openpgp-cryp… Werner Koch
- Re: [openpgp] I-D Action: draft-ietf-openpgp-cryp… Derek Atkins
- Re: [openpgp] I-D Action: draft-ietf-openpgp-cryp… Ángel
- Re: [openpgp] I-D Action: draft-ietf-openpgp-cryp… Ángel
- [openpgp] Incorporated RFC 6637: SHA2-384 recomme… Neal H. Walfield
- Re: [openpgp] I-D Action: draft-ietf-openpgp-cryp… Neal H. Walfield
- Re: [openpgp] I-D Action: draft-ietf-openpgp-cryp… Neal H. Walfield
- [openpgp] textual cleanup (no substantive changes) Neal H. Walfield
- [openpgp] Deprecate non-integrity-protected encry… Neal H. Walfield
- Re: [openpgp] I-D Action: draft-ietf-openpgp-cryp… Neal H. Walfield
- Re: [openpgp] Deprecate non-integrity-protected e… Neal H. Walfield
- Re: [openpgp] I-D Action: draft-ietf-openpgp-cryp… Daniel Kahn Gillmor
- Re: [openpgp] I-D Action: draft-ietf-openpgp-cryp… Daniel Kahn Gillmor
- Re: [openpgp] I-D Action: draft-ietf-openpgp-cryp… Daniel Kahn Gillmor
- [openpgp] Sec. Considerations MUST about S2K [was… Daniel Kahn Gillmor
- [openpgp] v5 fingerprints in ECDH brian m. carlson
- [openpgp] Curve448 in ECDH brian m. carlson
- Re: [openpgp] Sec. Considerations MUST about S2K … Peter Gutmann
- Re: [openpgp] Curve448 in ECDH Paul Wouters
- Re: [openpgp] v5 fingerprints in ECDH Paul Wouters
- Re: [openpgp] Curve448 in ECDH brian m. carlson
- Re: [openpgp] I-D Action: draft-ietf-openpgp-cryp… Paul Wouters
- Re: [openpgp] I-D Action: draft-ietf-openpgp-cryp… Paul Wouters
- Re: [openpgp] Curve448 in ECDH Paul Wouters
- Re: [openpgp] Curve448 in ECDH brian m. carlson
- Re: [openpgp] Sec. Considerations MUST about S2K … Ángel
- Re: [openpgp] ECC Curve OIDs section Ángel
- Re: [openpgp] who creates old-rfc registries? Ángel
- Re: [openpgp] I-D Action: draft-ietf-openpgp-cryp… Ángel
- Re: [openpgp] I-D Action: draft-ietf-openpgp-cryp… Neal H. Walfield
- Re: [openpgp] Sec. Considerations MUST about S2K … Ángel
- Re: [openpgp] Sec. Considerations MUST about S2K … Ángel
- Re: [openpgp] I-D Action: draft-ietf-openpgp-cryp… Paul Wouters