[saag] Re: FW: New Version Notification for draft-rsalz-crypto-registries-00.txt

[Simon Josefsson <[e-mail]>]

Hi Rich.  Generally I disagree with the fundamental recommendation:

> This document provides recommendations for how IETF Working Groups
> should create IANA registries that are related to cryptographic
> algorithms. It is based on the lessons learned from the TLS registries
> over the years as described in [RFC8447] and
> [I-D.draft-ietf-tls-rfc8447bis].
> ...
> Each registry SHOULD be "Specification Required," as defined in
> [RFC8126], Section 4.6.

While this may be appropriate for TLS, and may be appropriate for some
other registries, I don't think this is a good universal rule.

Re-reading RFC 8126, I believe it already sets out a good balance
between the different models already, and I encourage people to read the
entire guidance:

https://www.rfc-editor.org/rfc/rfc8126#section-4

SASL mechanisms are registered on a first-come-first-serve basis and
this has worked well historically.
https://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml

Kerberos uses a mix of methods for registration too.
https://www.iana.org/assignments/kerberos-parameters/kerberos-parameters.xhtml

What problem are you trying to solve with this document?
Could we start with a problem statement?

To me, it seems like an attempt to generalize a policy that risk
increasing the downward angle of the slipper slope towards rejecting all
crypto that isn't controlled by NIST.

Quoting section 3:

> A key requirement is that the specification of the semantics must be
> "permanent and readily available" as described in [RFC8126], Section
> 4.6. The defining document should make explicit if Internet-Draft
> documents qualify, as Section 4.6 does not say.

I don't think I-D's are appropriate to use as reference material in the
Specification Required context.  The current IETF I-D boilerplate says:

> Internet-Drafts are draft documents valid for a maximum of six months
> and may be updated, replaced, or obsoleted by other documents at any
> time. It is inappropriate to use Internet-Drafts as reference material
> or to cite them other than as "work in progress."

RFC 8126 suggests that the ideal example of Specification Required is an
RFC but instead of saying 'RFC Required' it says 'Specification
Required' to cover things outside of the RFC path.  I-D's is on the RFC
path.  Thus, I don't think RFC 8126 "Specification Required" was
intended to include I-D's originally.  Quoting section 4.6:

> The intention behind "permanent and readily available" is that a
> document can reasonably be expected to be findable and retrievable
> long after IANA assignment of the requested value.  Publication of an
> RFC is an ideal means of achieving this requirement, but
> Specification Required is intended to also cover the case of a
> document published outside of the RFC path, including informal
> documentation.

Another comment on your text:

> DE Instructions
>
>   Unless the WG chairs indicate otherwise via email, the Designated
>   Experts should decline code point registrations for documents which
>   have already been adopted or are being proposed for adoption by IETF
>   working groups or IRTF research groups.

I suggest changing 'or are being proposed for adoption into 'or are
being proposed by the document authors for adoption into' to avoid
external people fillibustering the registration process of a document by
proposing it for adoption by some random WG's.  Proposing other's work
as WG documents is a pattern that have been followed for several
protocols that people dislike and seamingly wish to delay.

/Simon