IETF Last Call Review of draft-ietf-netconf-yp-transport-capabilities-05
review-ietf-netconf-yp-transport-capabilities-05-tsvart-lc-pauly-2025-10-09-00

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

Thanks to the authors for this document. I want to preface my review by
making it clear that I'm not a YANG expert; the majority of this document
is the YANG definition itself.

However, from a transport perspective, I do find aspects of this structuring
potentially confusing. Having definitions that have names as broad as
"transport protocol", "security protocol", etc, raise questions. Are there
concrete and finite definitions of the values that can go in these fields? Or
is this something relatively freeform and expandable? The current two examples
of "transport protocol" are UDP and HTTPS. In an enumeration of transport
protocols in another context, this would be a surprising list. While HTTP is
used as a mechanism for transport in some contexts, one would most often expect
a list like this to be TCP, UDP, QUIC, etc. My assumption is that this is
really an enumeration of the specifically defined YANG notification substrates.
Having the name be notify-transport, notify-substrate, or similar, might be
clearer.

What is the process for expanding the list of possible values? Since you have
"security transports" as an orthogonal concept to the "transport protocols",
how do you capture the ways those protocols compose and interact? For example,
if you're using HTTP/3, which is over QUIC, you cannot select TLS 1.2. I can
imagine that this will get more complex going forward. Perhaps a way out of
this is to focus on an enumeration of known profiles for how the notifications
are handled (DTLS 1.3 + UDP as a set) rather than having combinations be
expressed that may not make sense.

I'll note that the HTTPDIR review [1] of the HTTPS "notification transport"
document also referred to using HTTP as a "substrate" more than a "transport".
That might be a helpful direction for the terminology.

[1]
https://datatracker.ietf.org/doc/review-ietf-netconf-https-notif-15-httpdir-telechat-nottingham-2024-02-02/