I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

This document defines 7 YANG modules for Communication between SSH Client and SSH Server. In these 7 YANG modules, there are three "IETF" modules and four "IANA" modules.
This document is well written and I believe it is ready for publication. However I have a few comments on the latest version v-36:
Major issues:
None

Minor issues
1. The abstract is not consistent with Introduction section, in the abstract, only 3 YANG modules are described but in section 1 or introduction section, 7 YANG modules are explored. Suggest to change abstract to align with section 1.
2. The title of each subsection of section 5.1 doesn’t reflect what is documented within it, I think each subsection focuses on security consideration, suggest the following change to each subsection of section 5.1
s/ Template for the ……/ Consideration for the ……
3. Appendix A.1 said:
“
This section provides an overview of the "iana-ssh-encryption-algs" module in terms of its identities and protocol-accessible nodes.

”
It is clear that iana-ssh-encryption-algs" module doesn’t define
Any protocol-accessible nodes such as container node, list node, leaf node, etc. It only defines identities and typedefs.Suggest the following change as follows:
NEW TEXT:
“This section provides an overview of the "iana-ssh-encryption-algs" module in terms of its identities and typedefs.
”
4. Appendix A.2 said:
“   This section provides an overview of the "iana-ssh-mac-algs" module
   in terms of its identities and protocol-accessible nodes.
“
It is clear that  "iana-ssh-mac-algs " module doesn’t define
Any protocol-accessible nodes such as container node, list node, leaf node, etc. It only defines identities and typedefs. Suggest the following change as follows:
NEW TEXT:
“This section provides an overview of the " iana-ssh-mac-algs" module in terms of its identities and typedefs.
”
5. Appendix A.3 said:
“
   This section provides an overview of the "iana-ssh-public-key-algs"
   module in terms of its identities and protocol-accessible nodes.
“
It is clear that  " iana-ssh-public-key-algs " module doesn’t define
Any protocol-accessible nodes such as container node, list node, leaf node, etc. It only defines identities and typedefs. Suggest the following change as follows:
NEW TEXT:
“This section provides an overview of the " iana-ssh-public-key-algs " module in terms of its identities and typedefs.

6.  Appendix A.4 said:
“
   This section provides an overview of the "iana-ssh-key-exchange-algs"
   module in terms of its identities and protocol-accessible nodes.
”
It is clear that  " iana-ssh-key-exchange-algs " module doesn’t define
Any protocol-accessible nodes such as container node, list node, leaf node, etc. It only defines identities and typedefs. Suggest the following change as follows:
NEW TEXT:
“This section provides an overview of the " iana-ssh-key-exchange-algs " module in terms of its identities and typedefs.

7. Section 6 IANA Section
Section 6.3,Section 6.4, Section 6.5, Section 6.6 describe IANA maintained module, but doesn’t follows Guidance for Writing the IANA Considerations for RFCs Defining IANA-Maintained Modules defined in RFC8047bis.
So the question is for IANA maintained Module, if such module shadows algorithm name sub-registry of SSH protocol parameters registry, should IANA section follow guidance for Defining IANA Maintained Modules defined in RFC8047bis, My understanding is yes. Similar example can be found in the section 3 of RFC7224.

8. Appendix A 
It looks the get identity python code is specific to SSH related encryption algorithm, I am wondering whether there is more generic code for get identity or get enum to automatically help IANA generate IANA maintained modules every time the new value is added? If the answer is, I think such code can be integrated into RFC8407bis as well.

9. There are 31 errors spot by the current YANG validation tool. It looks line wrapping per RFC 8792 is root cause for such errors. I am wondering whether YANG validation tool in the datatracker should be upgraded to ignore line folding per RFC8792 or provide YANG validation check after removing line wrapping from YANG module code.