Re: [saag] SSH & Ntruprime

["Salz, Rich" <[e-mail]>]

A half-dozen emails came in while I was writing this and providing examples for it, so some of this will be repetitive, sorry.


  *   Fortunately, we have a natural experiment here, because RFC 8446 explicitly allows the registration of TLS code points based on I-Ds, so in five years I guess we can see how that worked.

8446 was published in August 2018, so we’re closing in on the first five years of registry action.

Allowing registry entries to point to a stable document source, rather than requiring an RFC, was an unequivocably good thing. (I’m one of the three TLS registry designated experts.) Look at the ALPN IDs[1] and notice the several entries that are not RFCs. Assume that most of those people would not go through the RFC process; would the Internet be better off if those registries did not exist? Same question for the Broadband form entry in exporter labels[2].  Same question for the ISO identity-based encryption signature schemes. Our job is to make the Internet work better, and those registry entries help that.

As for whether an Internet-Draft is acceptable, the IETF community decided some time ago that drafts do not get deleted, so they meet the requirements. This is also a good thing for several reasons. For example, several of the examples I quoted above would not come to the IETF if they had to write an RFC. Even if they do come, things change – SPDY becoming QUIC for example – so should we not register SPDY? Also, not every individual or organization has the wherewithal to have long-lasting links to documentation, and in many cases the IETF would probably prefer those things be kept as an IETF resource.


[1] https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids
[2] https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#exporter-labels
[3] https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-signaturescheme