Hi Mark,
You’re right. IANA has a page of all “Pretty Good Privacy” registries, but even
the name of that is outdated and should reflect “OpenPGP” instead.
The intention of "draft-openpgp-iana-registry-updates” was to perform a
one-time change for the whole set of OpenPGP registries, to get them up-to-date
and to bring them inline with desired policies and practices. In order to do so
(for IANA to take action in modifying the registry metadata), this document
needs to be published as an RFC.
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 audience of 4880bis, it
seems preferable to keep one-time changes in
"draft-openpgp-iana-registry-updates” (such as registry policy updates,
renaming, etc), and let 4880bis be a document targeted for the audience of
implementers.
Indeed 4880 will have a successor, that is not a “standing document” that is
permanently active. It is insofar “living", however, considering the years it
took for 4880 to be revised — 4880bis will probably be active for a long time
before RFCnnnnbis appears :-)
And fully agree with allowing simple short RFCs to add to the PGP umbrella.
Ron
_____________________________________
Ronald Tse
Ribose Inc.
On Nov 28, 2018, at 2:22 AM, Mark D. Baushke
<mdb(_at_)juniper(_dot_)net<mailto:mdb(_at_)juniper(_dot_)net>> wrote:
fwiw: IANA has a document:
https://www.iana.org/assignments/pgp-parameters/pgp-parameters.xhtml
which is used to identify items for Pretty Good Privacy which includes
the RFC 4880 defined numbers as well as a few assigned numbers that do
not have an RFC 4880 reference.
Not that even an IETF Draft *might* end up adding to the pgp-parameters
file if the number used is used in enough implementtions along the way.
Yes, it is best to use the IETF CONSENSUS method for new identifiers a
la RFC2434, but an informational RFC may be used to define de facto
standards that have arisen and may otherwise cause interoperability
problems if not defined.
Creating an RFC to add a new identifer to that IANA pgp-parameters.xhtml
file is not hard and makes sense to do.
There will be a published RFC4880 successor eventually. However, it will
not be a living document. It will be given a particular RFC number nnnn
and then there will probably eventually be an RFCnnnnbis document... etc.
In addition, there is no real problem with coming up with new things to
add to the pgp umbrella as very simple short RFCs.
Enjoy!
-- Mark
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp