Update to the IANA SSH Protocol Parameters Registry Requirements
draft-yee-ssh-iana-requirements-03
Yes
Roman Danyliw
No Objection
Éric Vyncke
Jim Guichard
(Andrew Alston)
(Erik Kline)
Note: This ballot was opened for revision 02 and is now closed.
Roman Danyliw
Yes
Éric Vyncke
No Objection
Jim Guichard
No Objection
Murray Kucherawy Former IESG member
Yes
Yes
(2023-06-23 for -02)
Sent
I don't think the use of BCP 14 key words is really necessary here.
Paul Wouters Former IESG member
Yes
Yes
(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.
Warren Kumari Former IESG member
Yes
Yes
(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 Former IESG member
No Objection
No Objection
(for -02)
Not sent
Erik Kline Former IESG member
No Objection
No Objection
(for -02)
Not sent
John Scudder Former IESG member
No Objection
No Objection
(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 Former IESG member
No Objection
No Objection
(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