IETF Last Call Review of draft-ietf-netconf-yp-transport-capabilities-05
review-ietf-netconf-yp-transport-capabilities-05-yangdoctors-lc-lindblad-2025-10-22-00

This is my YANG Doctor last call review of
draft-ietf-netconf-yp-transport-capabilities-05. I think this tiny module is
Ready.

The current model has one small limitation, but that is probably a conscious
choice, and may never become a real world problem. I will mention it anyway
just to make sure all involved are aware.

The transport-capability list has a single key transport-protocol. This means
only a single capability listing for each transport protocol is possible.

         list transport-capability {
           key "transport-protocol";

In this version of the module, the body of the list contains leaf-lists with
the identities of the security protocol and encoding format (and any future
augmentations):

...
           leaf-list security-protocol {
             type union {
               type identityref {
                 base security-protocol;
               }
               type identityref {
                 base tlscmn:tls-version-base;
               }
             }
...
           }
           leaf-list encoding-format {
             type identityref {
               base sn:encoding;
             }

This implies that a server has to support all combinations of listed
security-protocols and encoding formats (and any augmented properties) for each
transport protocol. This is likely the case for most (or all?) implementations.
This model does not make it possible to express for, example, that the server
supports http with tls12 with json and tls13 with json or cbor. If this kind of
swiss-cheese matrix could ever appear in an implementation, the current model
cannot express it.

Best Regards,
/jan