This is my early YANG Doctor review of draft-ietf-netconf-yp-transport-capabilities-01. I think this small document and tiny YANG Module is a good idea and well written. Overall, I'd say it's ready with issues. I read that there are already multiple vendor implementations of this, but I would still like to bring up a couple YANG design decisions in the proposed module for discussion. #1) Choice of key in list transport-capability The top-level list transport-capability is using the transport protocol as key. +--ro transport-capability* [transport-protocol] +--ro transport-protocol identityref +--ro security-protocol? identityref +--ro encoding-format* identityref Using the transport protocol as key implicitly assumes that one set of properties can describe all uses of this protocol. A server that supports yp over https with either tls13 OR tls20 (future), for example, could not express this. It might also be good for a server to be able to specify a preference value for each protocol and encoding format. Certain combinations may be faster, or better tested, for example. In light of this, a separate synthetic key, possibly indicating preference, might be preferable for this list. #2) Defining identities for The module defines identities for TLS versions, DTLS version, and an SSH version. This might not be ideal, since if e.g. a new TLS version comes around, a new identity would have to be created in some standard module, besides the one(s) already defined in other YANG modules. RFC9645, for example, defines identities for tls12 and tls13 already. They could and probably should be reused here. Here's an proposed example of how they could be reused. module ietf-notification-transport-capabilities { import ietf-tls-common { prefix tlscmn; } // added ... // identities tls12, tls13 removed // maybe dtlsXX are or will be defined in some other std module too? list transport-capability { key "transport-protocol"; leaf transport-protocol { type identityref { base sn:transport; base tlscmn:tls-version-base; // added }