Early Review of draft-ietf-netconf-yp-transport-capabilities-01
review-ietf-netconf-yp-transport-capabilities-01-yangdoctors-early-lindblad-2025-04-21-00

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
             }