[Curdle] Ben Campbell's Yes on draft-ietf-curdle-ssh-ext-info-12: (with COMMENT)

[Ben Campbell <[e-mail]>]

Ben Campbell has entered the following ballot position for
draft-ietf-curdle-ssh-ext-info-12: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for addressing my DISCUSS point. I've cleared, with the assumption the
discussed change will make it into the final document.

(I leave the non-blocking comments below for reference, although most of them
have been addressed in the email discussion.)

Substantive:

-2.3: "This message is sent immediately after SSH_MSG_NEWKEYS, without delay."
That seems to be contradicted in section 2.4, which talks about two other
potential times.

-2.4, last paragraph (asterisk note): "The message MUST be sent at this point
for the following reasons:" That's a confusing use of MUST. Do you mean that
the message MUST NOT be sent unless the reasons are true? Or that if the
reasons are true, the message MUST be sent? Or is this just a statement of
fact, in which case the 2119 keyword is not appropriate?

-2.5, 2nd paragraph: "or it MAY be sufficient that only one party includes it"
That seems like a statement of fact rather than a grant of permission. If so,
the 2119 MAY is not appropriate.

Editorial:

-2.1, first paragraph: "Applications implementing this mechanism MUST add to
the field
  "kex_algorithms", in their KEXINIT packet sent for the first key
  exchange, one of the following indicator names:"

That's hard to parse.  Suggestion:
"Applications implementing this mechanism MUST add one of the
 following indicator names to the "kex_algorithms" field for the first
 key exchange:"

-2.5, 2nd to last paragraph: "... applications MUST
  tolerate any sequence of bytes; including null bytes at any position;
  in an unknown extension’s extension-value."

Redundant to similar normative statement in 2.3.