IETF Last Call Review of draft-ietf-netconf-yp-transport-capabilities-06
review-ietf-netconf-yp-transport-capabilities-06-secdir-lc-huitema-2026-08-07-00

I have reviewed draft-ietf-netconf-yp-transport-capabilities-06
as part of the security directorate's ongoing effort to review all
IETF documents being processed by the IESG. Theses comments were written
primarily for the benefit of the security area directors. Document editors and
WG chairs should treat these comments just like any other last call comments.

  The summary of the review is Not Ready.

I find this document confusingbecause it uses generic terms like "server"
or "transport" outside of the general understanding of these terms in IETF RFCs.

Let's start with the introduction: The "ietf-system-capabilities" YANG module
defined in [RFC9196] allows a client to discover a set of capabilities
supported by a server (including, basic system capabilities and YANG-Push
related capabilities) both at implementation time and at runtime. OK. What kind
of server are we speaking about? A web server? An SMTP server? A server
implementing protocols like NETCONF? A VPN server? Capabilities of servers tend
to be very dependent on the type of application that the server is
implementing. The split of functions between client and servers is also very
dependent on the application. For example, a recursive DNS server is both a
server for stub DNS resolvers and a client to authoritative DNS resolvers.

If we mean any server on the Internet, then the review could just as well stop
here. The concept of a unifying model for all Internet nodes that happen to
accept a request and do something for another node is just silly.

If we mean specialized servers used in network management such as NETCONF or
RESTCONF, the draft should say so.

Let's continue with the second paragraph of the introduction, the notion of
transport protocol. At the lowest level, mentioning transport protocols on the
Internet means something like TCP, UDP or QUIC. But then, the examples go on to
include TLS, DTLS. I suspect that the authors' cocnept of what "transport"
means is different from the regular understanding in, say, the IETF Web and
Internet Transport Area. Again, it would be nice if the draft was rewritten to
explain what is mean here by "transport", and if possible pick another name.

The draft goes on to differentiate between TLS 1.2 and TLS 1.3, DTLS 1.2 and
DTLS 1.3, which seems wrong. TLS 1.3 is defined in RFC 9846, which obsoletes
older RFCa including RFC 5246 (TLS 1.2) and RFC 8446 (the original
specification of TLS 1.3). RFC 6347 (DTLS 1.2) is obsoleted by RFC 9147 (DTLS
1.3). The draft should not make normative references to RFCs that are obsolete.
I do not think that the draft should differentiate "identity dtls12" and
"identity dtls13" -- these are just two version of the same protocol, that
certainly do not change the "identity" of the server.

I can understand the need to provide the list of supported
TLS or DTLS versions for management purposes, but this should be achieved by
something like a supported version parameter. The TLS and DTLS negotiations
include the capability of "negotiating down" from [D]TLS 1.3 to [D]TLS 1.2, if
the server and the client are specifically configured to tolerate such
downgrade. Maybe that acceptance or refusal of downgrade should be documented
in the YML text?

I also do not really understand the relation between this "transport capability"
description and the "HTTPS" or "CSVRV" DNS records that clients use to
determine how to contact a server. Maybe that should be explained? Are clients
expected to retrieve the YML description of the server before establishing a
connection? It is pretty hard to review the security properties of this
proposal without understanding its planned usage.