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

Benjamin Kaduk <> Sat, 01 December 2018 00:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 458F7130EF7 for <>; Fri, 30 Nov 2018 16:19:51 -0800 (PST)
X-Quarantine-ID: <VmFTtn7P9Ypz>
X-Virus-Scanned: amavisd-new at
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by[...]
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_CSS=0.1, URIBL_CSS_A=0.1] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VmFTtn7P9Ypz for <>; Fri, 30 Nov 2018 16:19:49 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 67CB3126F72 for <>; Fri, 30 Nov 2018 16:19:49 -0800 (PST)
X-AuditID: 1209190d-58fff70000005ec4-58-5c01d3a37037
Received: from ( []) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id CB.CF.24260.4A3D10C5; Fri, 30 Nov 2018 19:19:48 -0500 (EST)
Received: from (OUTGOING-AUTH-1.MIT.EDU []) by (8.14.7/8.9.2) with ESMTP id wB10Jk5p031449; Fri, 30 Nov 2018 19:19:46 -0500
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) œby (8.14.7/8.12.4) with ESMTP id wB10JgMq032130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 30 Nov 2018 19:19:44 -0500
Date: Fri, 30 Nov 2018 18:19:41 -0600
From: Benjamin Kaduk <>
To: "" <>
Cc: Ronald Tse <>, "Mark D. Baushke" <>, Derek Atkins <>
Message-ID: <>
References: <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupileLIzCtJLcpLzFFi42IR4hRV1l1ymTHG4NNSAYuVk3awW3Tduc5m 0fDvIbtF67YjbA4sHkuW/GTyWP71AYvH9aar7B5X509hC2CJ4rJJSc3JLEst0rdL4MrobZUu +CBe0XBxM0sD4zmhLkZODgkBE4lVNy6ydDFycQgJrGGS6Hh2gwnC2cgo0bHgIBuEc5dJ4uqG GUBlHBwsAqoSs+bqgXSzCahINHRfZgaxRQQ0Jfp2LGcDsZkFciUeL78DZgsL+Ejcb90IVsML tG31uiaomUuYJHr7/7BDJAQlTs58wgLRrCVx499LJpBdzALSEsv/cYCEOQUMJX6d2wJWLiqg LLG37xD7BEaBWUi6ZyHpnoXQvYCReRWjbEpulW5uYmZOcWqybnFyYl5eapGukV5uZoleakrp JkZwMEvy7mD8d9frEKMAB6MSD++EHMYYIdbEsuLK3EOMkhxMSqK8fyWAQnxJ+SmVGYnFGfFF pTmpxYcYJTiYlUR4Sy8C5XhTEiurUovyYVLSHCxK4ry/RR5HCwmkJ5akZqemFqQWwWRlODiU JHgXXgJqFCxKTU+tSMvMKUFIM3FwggznARq+DKSGt7ggMbc4Mx0if4pRl+PFjI4ZzEIsefl5 qVLivDkgRQIgRRmleXBzQElIInt/zStGcaC3hHkFQKp4gAkMbtIroCVMQEtiev5HAy0pSURI STUw7jj85cLMX4nTJXbfm6f28ElAbYjVvc23Zy/uKz7ncDR37hnBxLwTjA6paQphL+8JaZQn RrQfVK3atu7AlkuXBa1O+apJPP6rHBj0pag/qj22X+6N16I70caC6t6CverXtAza/mf25Ias +DGjoGT577utsWwvbnxb3XRv7U5XDwOG3zrXeuV+KrEUZyQaajEXFScCAJY579odAwAA
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: Sat, 01 Dec 2018 00:19:51 -0000

On Wed, Nov 28, 2018 at 01:09:00PM -0500, Derek Atkins wrote:
> Hi,
> 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.

Generally you want the IANA registry to be the single normative place to
consult.  It's fairly common to have a table in an RFC and have the initial
IANA registry populated from that (also normative) table, and perhaps less
common but still plausible to have an update document with a table and
instructions for IANA to resync to that table at time of publication (but
still be able to add/change things later).

> > 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.

Derek is absolutely right, here.

I'll note that for TLS 1.3 we did separate documents, RFCs 8446 and 8447,
since there were a *lot* of registry changes and we did want a permanent
record of them, but that split caused a lot of extra work to ensure things
were synchronized during AUTH48.


> > Salam-Shalom,
> >
> >    Werner
> -derek
> -- 
>        Derek Atkins                 617-623-3745
>        Computer and Internet Security Consultant
> _______________________________________________
> openpgp mailing list