Re: [openpgp] rfc4880bis and draft-openpgp-iana-registry-updates-01

Derek Atkins <> Wed, 28 November 2018 18:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B1927130E8B for <>; Wed, 28 Nov 2018 10:09:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.789
X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001, URIBL_CSS=0.1, URIBL_CSS_A=0.1] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id M0mUhTN7yoGa for <>; Wed, 28 Nov 2018 10:09:44 -0800 (PST)
Received: from (MAIL2.IHTFP.ORG []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3D44E130E27 for <>; Wed, 28 Nov 2018 10:09:42 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 27910E2046; Wed, 28 Nov 2018 13:09:12 -0500 (EST)
Received: from ([]) by localhost ( []) (amavisd-maia, port 10024) with ESMTP id 21453-05; Wed, 28 Nov 2018 13:09:01 -0500 (EST)
Received: from (IHTFP-DHCP-158.IHTFP.ORG []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "", Issuer "IHTFP Consulting Certification Authority" (not verified)) by (Postfix) with ESMTPS id 7A1CAE2042; Wed, 28 Nov 2018 13:09:01 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1543428541; bh=ISa0p58OSH9yBFdio/fOZeJi34qeWrS5hZGtKYbOMFM=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=H6ABk9+HDIx8AE5qJwyROJaOQsT1ZdiLMwx4jZAtn2JZV+USyG19CXmbU9lH86Rpv lGT5J4n4pUh9n8c2pXz8JuoM4vez7qqKEjOlVDqAgGl93mDOn2SKn+45Xs6EQrpZpY erAjNNAeh+QIkwjv7ongLyOTVi/AARec7IE9I2Zw=
Received: (from warlord@localhost) by (8.15.2/8.15.2/Submit) id wASI90jF013652; Wed, 28 Nov 2018 13:09:00 -0500
From: Derek Atkins <>
To: Ronald Tse <>
Cc: "openpgp\" <>, "Mark D. Baushke" <>, Ronald Tse <>
References: <> <> <> <> <>
Date: Wed, 28 Nov 2018 13:09:00 -0500
In-Reply-To: <> (Werner Koch's message of "Wed, 28 Nov 2018 08:39:44 +0100")
Message-ID: <>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: <>
Subject: Re: [openpgp] rfc4880bis and draft-openpgp-iana-registry-updates-01
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Nov 2018 18:09:46 -0000


Werner Koch <>; writes:

> On Wed, 28 Nov 2018 06:00, said:
>> The question raised by Werner (as I understood it) was more about how
>> to align the IANA considerations given in 4880bis with this document,
>> and whether to merge the said document into 4880bis. For the intended
> Right.  I am not sure what is the right procedure here.  Are the tables
> with the various ids in rfc4880bis normative or are the informational
> and the IANA registry is the normative reference for them.  For
> practical point of view I would like to have the tables in rfc4880bis
> to be normative with the note that the IANA registry defines updates to
> these tables.
> I agree with Ron that the procedures on how to update the IANA registries
> do not belong into rfc4880bis.  We need some advice from IETF procedures
> experienced people (or a pointer to an RFC describing these procedures).

Speaking for myself (but with the knowledge of being a former chair of
the OpenPGP WG), it's perfectly fine to put the one-time IANA process
details into the 4880bis draft.  What is often done is to add an
RFC-Editor note to remove the IANA actions section(s) upon publication.

What happens is that the draft will get approved with all the IANA
actions in it, but when it gets edited into an actual RFC, the one-time
IANA actions can be removed.

There is still the historical record of the one-time actions in the i-d
history, but it de-clutters the RFC.

I recommend we take this approach, because getting TWO I-D through the
process will be twice as much work for everyone involved than getting
only one through the process.  We have enough trouble with just the
one.  So I would recommend we integrate in the one-time actions with a
note to remove it upon publication.

> Salam-Shalom,
>    Werner

       Derek Atkins                 617-623-3745   
       Computer and Internet Security Consultant