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: =?ISO-8859-1?Q?=C1ngel?= <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