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

On Wed, Nov 28, 2018 at 01:09:00PM -0500, Derek Atkins wrote:
> Hi,
> 
> Werner Koch <wk@gnupg.org> writes:
> 
> > On Wed, 28 Nov 2018 06:00, tse@ribose.com 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.

-Ben

> > Salam-Shalom,
> >
> >    Werner
> 
> -derek
> -- 
>        Derek Atkins                 617-623-3745
>        derek@ihtfp.com             www.ihtfp.com
>        Computer and Internet Security Consultant
> 
> _______________________________________________
> openpgp mailing list
> openpgp@ietf.org
> https://www.ietf.org/mailman/listinfo/openpgp