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/