On Wed, Nov 28, 2018 at 01:09:00PM -0500, Derek Atkins wrote:
Hi,
Werner Koch <wk(_at_)gnupg(_dot_)org> writes:
On Wed, 28 Nov 2018 06:00, tse(_at_)ribose(_dot_)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(_at_)ihtfp(_dot_)com www.ihtfp.com
Computer and Internet Security Consultant
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp