Hi Damien,
While reviewing this document during AUTH48, please resolve (as necessary) the
following questions, which are also in the source file.
1) <!-- [rfced] Please note that the title of the document has been
updated as follows:
Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC
Style Guide"). Please review.
Original:
SSH Agent Protocol
Current:
Secure Shell (SSH) Agent Protocol
-->
2) <!--[rfced] Please review both how we added in an expansion for the
abbreviation EdDSA and the possible citation add in the following
text. Note also that we have updated one instance of "EDDSA" to
"EdDSA". Please let us know any objections.
Original:
[RFC8709] defines Ed25519 and Ed448 with key type names "ssh-ed25519"
and "ssh-ed448" respectively.
Current:
[RFC8709] defines Edwards-curve Digital Signature Algorithm (EdDSA)
keys (see [RFC8032]) Ed25519 and Ed448 with key type names
"ssh-ed25519" and "ssh-ed448", respectively.
-->
3) <!--[rfced] Do we need both "redundant" and "repetition" here?
Original:
...(this redundant repetition of the public key is to maintain
compatibility with widely deployed implementations).
Perhaps:
...(this repetition of the public key is to maintain
compatibility with widely deployed implementations).
-->
4) <!--[rfced] Please review if any text marked "Note:" should be put in
the <aside> element (defined as "a container for content that is
semantically less important or tangential to the content that
surrounds it" at
https://authors.ietf.org/en/rfcxml-vocabulary#aside.
Original:
Note: this operation affects the agent only, it SHOULD NOT cause the
keys be deleted from the token itself.
-->
5) <!--[rfced] Please confirm that the following update maintains your
intended meaning:
Original:
An agent MUST reply with SSH_AGENT_SUCCESS keys were deleted or
SSH_AGENT_FAILURE if none were found.
Current:
An agent MUST reply with SSH_AGENT_SUCCESS if the keys were deleted or
SSH_AGENT_FAILURE if none were found.
-->
6) <!--[rfced] Please clarify how these two "using" clauses relate to the
sentence:
Original:
The agent protocol may be forwarded over an SSH connection, using the
[RFC4254] connection protocol, allowing agent forwarding to be
requested for any session channel, using a model that is similar to
the connection protocol's support for X11 Forwarding (Section 6.3 of
[RFC4254]).
Perhaps:
Using the connection protocol described in [RFC4254], the agent
protocol may be forwarded over an SSH connection. This allows agent
forwarding to be requested for any session channel using a model that
is similar to the connection protocol's support for X11 Forwarding
(Section 6.3 of [RFC4254]).
-->
7) <!--[rfced] We had the following questions related to the IANA
registries:
a) We see no mention in the tables in this document of unassigned
values as appears at the corresponding IANA registries.
Please let us know if this document should be updated to match the
registries in this regard.
b) Please note that we have updated the column title in the Connection
Protocol Channel Types section (Table 7) to read as "Channel Type"
instead of "Request Type" to match the registry at
https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parameters-11.
Please let us know any objections.
-->
8) <!--[rfced] How would we separate this slashed phrase?
Original:
Implementation of token/smartcard-hosted keys...
Perhaps A:
Implementation of keys hosted by a token or smartcard....
Perhaps B:
Implementation of token keys or smartcard-hosted keys...
-->
9) <!-- [rfced] Note that the reference [I-D.ietf-secsh-agent] has been
removed as it had no corresponding citation in the document.
Please let us know any objections.
-->
10) <!-- [rfced] Would you like the references to be alphabetized or left
in their current order?
-->
11) <!--[rfced] Please note that we have expanded abbreviations on first
use. Please review these expansions for accuracy. -->
12) <!-- [rfced] We had the following questions/comments regarding
responses from the document intake email:
a) Regarding <sourcecode>:
"This document has none of the former, but plenty of the latter. The
stuff in <sourcecode> blocks are message definitions. Did I use the
wrong element type?"
None of the <sourcecode> pieces have a type set. The only type with
"message" in the name at the list (see below) is "http-message".
Please let us know if you would like to set a <sourcecode> type for
each instance of the sourcecode element. If the current list of
preferred values for "type"
(https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types)
does not contain an applicable type, then feel free to let us know.
Also, it is acceptable to leave the "type" attribute not set. Please
let us know if that is your choice.
b) Regarding using quotes for protocol message field names and literal strings:
"Literal strings that appear in protocol messages should be in double quotes
both in protocol message definitions and in descriptive text.
Protocol message field names should be in double quotes when they
appear in descriptive text, but not in the protocol message
definition."
It seemed the byte names (e.g., SSH_AGENTC_ADD_ID_CONSTRAINED) were
never in quotes. We have left these as they were.
Please review our updates and let us know if any further changes are
necessary (as these same terms seem to be used in the general sense,
this was not always clear to us).
-->
13) <!--[rfced] We had the following questions/comments related to
terminology use throughout the document:
a) Should the use of "type" and "key type" be made uniform here?
type "ssh-dss" vs. key type "ssh-rsa"
b) We see both "Windows Named Pipe" and "On Windows, access to a named
pipe". Please review and let us know if updates should be made for
uniformity.
-->
14) <!-- [rfced] Please review the "Inclusive Language" portion of the
online Style Guide
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this
nature typically result in more precise language, which is
helpful for readers.
Note that our script did not flag any words in particular, but this
should still be reviewed as a best practice.
-->
Thank you.
Megan Ferguson
RFC Production Center
*****IMPORTANT*****
Updated 2026/05/14
RFC Author(s):
--------------
Instructions for Completing AUTH48
Your document has now entered AUTH48. Once it has been reviewed and
approved by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies
available as listed in the FAQ (https://www.rfc-editor.org/faq/).
You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Planning your review
---------------------
Please review the following aspects of your document:
* RFC Editor questions
Please review and resolve any questions raised by the RFC Editor
that have been included in the XML file as comments marked as
follows:
<!-- [rfced] ... -->
These questions will also be sent in a subsequent email.
* Changes submitted by coauthors
Please ensure that you review any changes submitted by your
coauthors. We assume that if you do not speak up that you
agree to changes submitted by your coauthors.
* Content
Please review the full content of the document, as this cannot
change once the RFC is published. Please pay particular attention to:
- IANA considerations updates (if applicable)
- contact information
- references
* Copyright notices and legends
Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions
(TLP – https://trustee.ietf.org/license-info).
* Semantic markup
Please review the markup in the XML file to ensure that elements of
content are correctly tagged. For example, ensure that <sourcecode>
and <artwork> are set correctly. See details at
<https://authors.ietf.org/rfcxml-vocabulary>.
* Formatted output
Please review the PDF, HTML, and TXT files to ensure that the
formatted output, as generated from the markup in the XML file, is
reasonable. Please note that the TXT will have formatting
limitations compared to the PDF and HTML.
Submitting changes
------------------
To submit changes, please reply to this email using ‘REPLY ALL’ as all
the parties CCed on this message need to see your changes. The parties
include:
* your coauthors
* [email protected] (the RPC team)
* other document participants, depending on the stream (e.g.,
IETF Stream participants are your working group chairs, the
responsible ADs, and the document shepherd).
* [email protected], which is a new archival mailing list
to preserve AUTH48 conversations; it is not an active discussion
list:
* More info:
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/
* Note: If only absolutely necessary, you may temporarily opt out
of the archiving of messages (e.g., to discuss a sensitive matter).
If needed, please add a note at the top of the message that you
have dropped the address. When the discussion is concluded,
[email protected] will be re-added to the CC list and
its addition will be noted at the top of the message.
You may submit your changes in one of two ways:
An update to the provided XML file
— OR —
An explicit list of changes in this format
Section # (or indicate Global)
OLD:
old text
NEW:
new text
You do not need to reply with both an updated XML file and an explicit
list of changes, as either form is sufficient.
We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text,
and technical changes. Information about stream managers can be found in
the FAQ. Editorial changes do not require approval from a stream manager.
Approving for publication
--------------------------
To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication. Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.
Files
-----
The files are available here:
https://www.rfc-editor.org/authors/rfc9987.xml
https://www.rfc-editor.org/authors/rfc9987.html
https://www.rfc-editor.org/authors/rfc9987.pdf
https://www.rfc-editor.org/authors/rfc9987.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9987-diff.html
https://www.rfc-editor.org/authors/rfc9987-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9987-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9987
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC9987 (draft-ietf-sshm-ssh-agent-16)
Title : SSH Agent Protocol
Author(s) : D. Miller
WG Chair(s) : Stephen Farrell, Job Snijders
Area Director(s) : Deb Cooley, Christopher Inacio
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
