[secdir] Re: [netconf] draft-ietf-netconf-yp-transport-capabilities-06 ietf last call Secdir review

[[e-mail]]

Dear Christian,

Thanks for the review.

We addressed these comments in -07.

Please find the diff in: https://author-tools.ietf.org/diff?doc_1=draft-ietf-netconf-yp-transport-capabilities-06&url_2=https://raw.githubusercontent.com/network-analytics/draft-netana-netconf-yang-push-transport-capabilities/refs/heads/main/draft-ietf-netconf-yp-transport-capabilities-07.txt

And the document: https://github.com/network-analytics/draft-netana-netconf-yang-push-transport-capabilities/blob/main/draft-ietf-netconf-yp-transport-capabilities-07.txt

Please see inline.

On 8 Aug 2026, at 02:58, Christian Huitema via Datatracker <[e-mail]> wrote:

Document: draft-ietf-netconf-yp-transport-capabilities
Title: YANG Notification Transport Capabilities
Reviewer: Christian Huitema
Review result: Not Ready

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.
Yes, we meant NETCONF/RESTCONF server.

We changed the wording throughout the document to refer to the NETCONF/RESTCONF client/server explicitly.
Additionally, note we have client/server definitions in the terminology section where we refer to RFC8342 for their definitions.

These changes can be found in the abstract, introduction and section 2.

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.
Good point. I changed the wording to "notification delivery protocol”. I also added the term “transport protocol” in the terminology section to specify that we refer to the protocol used to deliver notifications between a publisher and a receiver.
As this term comes from RFC8639, we refrain from changing it in the YANG module.

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.
Such modelling was agreed by the WG and YANG doctors. The use of identities directly rather than the protocol and its version is because it would allow future users/developers to directly augment such YANG identities.
RFC9645 already uses this structure and we followed for consistency.

Regarding referencing obsoleted RFCs as normative is because we define those identities. Shall we move these obsoleted references to informative?

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?
The current document is not recommending any version of TLS or DTLS. The scope of the document is rather providing the NETCONF/RESTCONF server the capability to advertise what it supports for the notification delivery protocols, it does not define which protocols should be configured.

Recommendations about which version to use are defined in their respective transport protocols (e.g. https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif#name-secured-layer-for-udp-notif)


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.
The intended usage of this model is between an orchestrator and a network device. Such network is configured beforehand by an operator and is typically dedicated to exchange configuration information.
We added the following paragraph, helping the reader about the expected usage:

   This model is intended to be used between an orchestrator and a
   network device that provides YANG notifications.  A management
   network between the orchestrator and the network device is assumed to
   be available for exchanging YANG management information.  The
   management connectivity and endpoint of the network device are
   expected to be provisioned as part of the management network
   configuration.  The orchestrator can use the established management
   connection to discover the notification transport capabilities of the
   network device before establishing the notification subscription.

I hope this text makes the document clearer.

Regards,
Alex



_______________________________________________
netconf mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]