Update to the IANA SSH Protocol Parameters Registry Requirements
draft-yee-ssh-iana-requirements-03

Yes

Murray Kucherawy
Paul Wouters
Roman Danyliw
Warren Kumari

No Objection

Andrew Alston
Erik Kline
Jim Guichard
John Scudder
Robert Wilton
Éric Vyncke

Note: This ballot was opened for revision 02 and is now closed.

Murray Kucherawy
Yes
Comment (2023-06-23 for -02) Sent 
I don't think the use of BCP 14 key words is really necessary here.
Paul Wouters
Yes
Comment (2023-07-04 for -02) Sent 
Please consider adding a sentence somewhere listing which IANA SSH Registries were not updated ? Especially since you changed the list to be alphabetical.
Perhaps: The only IANA SSH registries not affected are "Message Numbers" and "Publickey Subsystem Status Codes", as these remain at standard track policy due to their limited resources as one byte registry values.

Please consider using the same listing order as the IANA registry or request IANA alphabetizes their listing too ?


NITS: change "wholly" to "entirely" to help non-English native speaking people.
Roman Danyliw
Yes
Warren Kumari
Yes
Comment (2023-07-05 for -02) Sent 
Thank you for writing this document -- it's clear and easy to read... and, better yet, short :-)

Also much thanks to Scott Rose for the DNSDIR review ( https://datatracker.ietf.org/doc/review-yee-ssh-iana-requirements-01-dnsdir-lc-rose-2022-10-13/ )
Andrew Alston
No Objection
Erik Kline
No Objection
Jim Guichard
No Objection
John Scudder
No Objection
Comment (2023-07-05 for -02) Sent 
Thanks for this. Two minor points --

"IANA MUST only accept registry updates from the designated experts"

Presumably the IESG can also update the registry, indeed that's implicit in "Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the <iesg@ietf.org> mailing list) for resolution."

I don't imagine the text is a practical problem since I don't think the IESG's role is subject to being disclaimed by an RFC in this way. 

And,

   Criteria that SHOULD be applied by the designated experts includes
   determining whether the proposed registration duplicates existing
   functionality
   
Implicit, but not stated, is that duplication of existing functionality is grounds to decline allocating a code point. If that's intended, you might want to make it explicit. If it's *not* intended, that too.
Robert Wilton
No Objection
Comment (2023-06-30 for -02) Sent 
Hi,

Thanks for this document.  Only one comment:

Minor level comments:

(1) p 3, sec 3.  Designated Expert Pool

   Within the review period, the designated experts will either approve
   or deny the registration request, communicating this decision to the
   review list and IANA.  Denials MUST include an explanation and, if
   applicable, suggestions as to how to make the request successful.
   Registration requests that are undetermined for a period longer than
   21 days can be brought to the IESG's attention (using the
   <iesg@ietf.org> mailing list) for resolution.

I think that this would be better to be escalated to the Security ADs (sec-ads@ietf.org) rather than being directed to the whole IESG.

Regards,
Rob
Éric Vyncke
No Objection