[Ssh] Éric Vyncke's Discuss on draft-ietf-sshm-ssh-agent-12: (with DISCUSS and COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-sshm-ssh-agent-12: Discuss

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


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



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


# Éric Vyncke, INT AD, comments for draft-ietf-sshm-ssh-agent-12
CC @evyncke

Thank you for the work put into this document.

Please find below one blocking DISCUSS points (easy to address), some
non-blocking COMMENT points/nits (replies would be appreciated even if only for
my own education).

Special thanks to Job Snijders for the shepherd's detailed write-up including
the WG consensus and some justification of the intended status.

Other thanks to Duane Wessels, the Internet directorate reviewer (at my
request), and I have read Damien's reply to Duane's detailed review:
https://datatracker.ietf.org/doc/review-ietf-sshm-ssh-agent-12-intdir-telechat-wessels-2025-11-20/

I hope that this review helps to improve the document,

Regards,

-éric

## DISCUSS (blocking)

As noted in
https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/,
a DISCUSS ballot is a request to have a discussion on the points below; I
really think that the document would be improved with a change here, but can be
convinced otherwise.

### Section 7.1 and others

SSH_AGENTC_ADD_IDENTITY is not specified in section 6.1 but in section 3.2.

`Reserved for organizational use` is not a use specified in RFC 8126.


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


## COMMENTS (non-blocking)

### Abstract

s/This document describes/This document *specifies*/ as it is proposed standard
;-)

The 'This note...' should not be in the abstract but in a `<note>`.

### Section 1

Strongly suggest to add references to all RFC 425x that specify the SSH
protocol.

### Section 3.2

Where are the components listed in `"contents" consists of the public and
private components of the key and vary by key type, they are listed below for
standard and commonly used key types`? A forward reference 'as specified in the
following sub-sections' would be welcome.

### Section 3.2.6

Why not a "MUST" in `the agent SHOULD also return SSH_AGENT_FAILURE` ?

### Section 3.2.7

`it is necessary to know its structure beforehand and it is not possible to
safely recover` this seems like a big issue to me as it mostly ossify the SSH
agent. Probably too late to change this as implementations are deployed, but
using the usual TLV would have been better.

This should also be described in an operational considerations section.

### Section 5.3

What are the consequences (even if semi obvious) of bypassing the "SHOULD" in
`An SSH client SHOULD be prepared`? See also
https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/

### Section 6

Unsure whether this section is required or even useful as the IANA section
repeats the same data. Consider removing it.

### Section 7.1

Please use the registry URI
https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml rather
than RFC 4250.

### Section 7.8

This sub-section should really appear *before* section 7.1.

### Section 8

A lot of "SHOULD" in this section without the companion clauses requested by 
https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/