Hi,

I have been selected as the Operational Directorate (opsdir) reviewer for this Internet-Draft. 

The Operational Directorate reviews all operational and management-related Internet-Drafts to ensure alignment with operational best practices and that adequate operational considerations are covered.

A complete set of _"Guidelines for Considering Operations and Management in IETF Specifications"_ can be found at https://datatracker.ietf.org/doc/draft-opsarea-rfc5706bis/.

While these comments are primarily for the Operations and Management Area Directors (Ops ADs), the authors should consider them alongside other feedback received.


- Document: [draft-ietf-sshm-mlkem-hybrid-kex-07]

- Reviewer: [Thomas Graf]

- Review Date: [01.01.2026]

- Intended Status: [Informational] 


This document defines Post-Quantum Traditional (PQ/T) Hybrid key exchange methods using the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) standard and traditional Elliptic-curve Diffie–Hellman (ECDH) key exchange schemes for extending the SSH Transport Layer Protocol.

I have reviewed the document and its references. I am not a cryptography expert and therefore won't be able to judge and comment on the security related statements. My focus is primarily on operations and manageability.

The document is straightforward and very well written. Therefore my comments are rather minor.
 
---

## Summary 

Choose one: 

- Ready: No issues found. This document is ready for publication. 


## General Operational Comments Alignment with RFC 5706bis 

https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-rfc5706bis gives guidance
on operations and manageability of new protocols or extension.

In the following sentence

   This document addresses the problem by extending the SSH Transport
   Layer Protocol [RFC4253] key exchange 

I suggest to reference https://datatracker.ietf.org/doc/html/rfc4253#section-7
specifically and consider in the document to briefly mention the migration path
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-rfc5706bis-01#section-4.3
to ML-KEM.

In the following sentence

   An implementation adhering to [RFC4253] must be able to support
   packets with an uncompressed payload length of 32768 bytes or less
   and a total packet size of 35000 bytes or less (including
   'packet_length', 'padding_length', 'payload', 'random padding', and
   'mac').  

I also suggest to reference https://datatracker.ietf.org/doc/html/rfc4253#section-6.1
specifically. I understood that the section 2.3 defined methods does not impose such
issues while other post-quantum key exchange schemes might impose such problems.

In the Acknowledgements section the authors describe that there are existing
implementations. Please consider writing a "Implementation Status" section as described
in https://datatracker.ietf.org/doc/html/rfc7942#section-2 or/and link the open-source
implementation in the data tracker.

---