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