Re: [Curdle] Time to Review IANA SSH Registries Policies?

[Tero Kivinen <[e-mail]>]

Jeffrey T. Hutzelman writes:
> I'm not specifically opposed to this, but many of ssh's registries are for
> string identifiers (e.g. algorithm names) where there is a straightforward
> mechanism for individual implementors to define unique, interoperable
> identifiers without going through the registry (specifically, identifiers of
> the form name@domain are permitted, as assigned by the owner of that domain).
> 
> Certain values, such as message numbers, are small, and thus scarce. The
> current policy for these is Standards Action, which IMHO is appropriate giving
> the size of the available namespace as well as the core protocol functions
> they serve. For the most part, it is intended that new values for these codes
> would be allocated only as part of a revision of the base protocol suite,
> rather than in an extension.

I agree on what was said above. I do not think changing those string
registries to Expert review would really help anything, as the corrent
way way of allocate [e-mail] is
much easier than even to go to the Expert and ask for the review... On
the other hand if that algorithm gets implemented by multiple
implementations then writing and RFC about it is not high bar.

Most of the Expert review allocations end up having RFCs anyways
(speaking as an IANA expert for IPsec), or at least have some stable
reference in some other SDOs.

Currently only Message Numbers, and Publickey Subsystem Status codes
have Standards Action registration procedure, and I think at least
Message Numbers should be kept with that high bar.

> That said, there are some other attributes (particularly, disconnect reasons,
> channel open failure reasons, and extended channel data types) for which
> significant namespace is managed under the IETF Review policy, with a small
> portion set aside for private use. It does seem like it would be reasonable to
> update these to use Expert Review instead.

Yep. Those registries do not have string format, so lowering the bar
there from IETF Review to Expert review could be helpful. Perhaps even
the last numeric registry Pseudo-Terminal Encoded Terminal Modes too.

On the other hand only following registries have had any allocations
after the initial work finished around 2006.

  - Message Numbers (integer)
  - Pseudo-Terminal Encoded Terminal Modes (integer)
  - Connection Protocol Subsystem Names (string)
  - Key Exchange Method Names (string)
  - Encryption Algorithm Names (string)
  - MAC Algorithm Names (string)
  - Public Key Algorithm Names (string)

And my understanding is that those string registries used @domain name
format for some time before someone actually decided to create RFC to
register those things, so this did not cause any issues on the
interoperability.

Usually the problems have been when people have used those @domain
name formats, and there is no documentation how they work, thus others
have had to reverse engineer or guess how they work, and didn't get
things right. Requiring RFC solves that issue, as then you must have
a documentation what that thing means...

> The ultimate question, then, is whether it is worth the (admittedly
> small) effort.

I would almost think it would not even be worth the effort. At least
we should show that it has caused some issues in the past before we
invest too much time on this.
-- 
[e-mail]