Hi Damien, Thank you for your prompt reply and updated file. We have adopted the XML with only the slight change of sorting the references.
Regarding sourcecode types: >> Either blank or, if it is possible to define a new sourcecode type, >> then "ssh-message" might be a useful addition - I'd certainly use >> it in other drafts I have pending. We went ahead and sent a request to the mailing list ([email protected].) mentioned at https://rpc-wiki.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types for a new “ssh-message” type. For this document, would you like to leave them blank or wait for a new “ssh-message" to be available (these wheels usually turn in just a few days)? As you otherwise indicated your approval of the document in this form, we have updated your status to “Approved” at the AUTH48 status page (see link below). Once we hear back on the sourcecode type question, we will be ready to move this document forward in the publication process. The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9987.txt https://www.rfc-editor.org/authors/rfc9987.pdf https://www.rfc-editor.org/authors/rfc9987.html https://www.rfc-editor.org/authors/rfc9987.xml The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9987-diff.html (comprehensive) https://www.rfc-editor.org/authors/rfc9987-rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9987-auth48diff.html (AUTH48 only) https://www.rfc-editor.org/authors/rfc9987-auth48rfcdiff.html (side by side) The AUTH48 status page is viewable here: https://www.rfc-editor.org/auth48/rfc9987 Thank you. Megan Ferguson RFC Production Center > On May 14, 2026, at 6:49 PM, Damien Miller <[email protected]> wrote: > > Thanks for the review! I've attached an updated XML file to hopefully > resolve the open questions below as well as a typo that I spotted. > > If the updated XML is acceptable to you and there are no other changes > then I approve publication. > > On Thu, 14 May 2026, [email protected] wrote: > >> 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 >> --> > > This is more consistent with the other SSH RFCs, so I welcome the change. > >> >> 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. >> --> > > This is an improvement too. > >> >> 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). >> --> > > Yes, "redundant" is probably redundant here and can be removed. > >> 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. >> >> --> > > Perhaps it would be better to remove the "Note:" here, as I believe > that this is a useful (if not important) clarification. > > >> 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. > > Yes, yours lacks my grammar mistake :) > >> >> 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]). >> >> --> > > Your wording avoids the stuttering of "using" and is another improvement. > >> 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. > > Do you mean adding some text mentioning which values are as yet > unassigned? If so that would be fine. OTOH I think the current state > of not mentioning unassigned values is fairly unambiguous. > >> 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. > > You're fixing a copy/paste mistake I made, so I accept :) > >> >> 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.... > > I prefer this variant. > >> 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. >> --> > > No objection, IIRC the only reference was in a removeInRFC section. > >> 10) <!-- [rfced] Would you like the references to be alphabetized or left >> in their current order? >> --> > > Alphabetized would be an improvement. Their current order indicates no > particular intention. > >> 11) <!--[rfced] Please note that we have expanded abbreviations on first >> use. Please review these expansions for accuracy. --> > > These all look good, thanks. > >> 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. > > Either blank or, if it is possible to define a new sourcecode type, > then "ssh-message" might be a useful addition - I'd certainly use > it in other drafts I have pending. > >> 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. > > Yes, this is intended on the basis that they represent integer values > and not strings of characters. > >> 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" > > In the updated draft attached, I've tried to standardise on "key type > name" when referring to the actual string name that appears on the wire. > >> 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. > > I think these are unambiguous in context and don't need changing. > >> 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. > > I tried to avoid this when drafting and couldn't spot anything on review. > >> Thank you. > > Thanks again for the review! > > Cheers, > Damien<rfc9987.xml> -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
