IETF Last Call Review of draft-ietf-netconf-yp-transport-capabilities-07
review-ietf-netconf-yp-transport-capabilities-07-tsvart-lc-black-2026-09-04-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.

The authors do not appear to have revised the draft to respond to Tommy Pauly's
review of the -05 version, so I'm incorporating that review by reference:
(https://datatracker.ietf.org/doc/review-ietf-netconf-yp-transport-capabilities-05-tsvart-lc-pauly-2025-10-09/).

Like Tommy, I want to preface my review by making it clear that I'm not a YANG expert.
However, I do understand enough about YANG to attempt to answer some of Tommy's questions:

Q1: "Are there concrete and finite definitions of the values that can go in these fields?"
    and the obvious follow-up: "If so, where are the definitions and the registry for them?"
Q2: What is the process for expanding the list of possible values?

Let the adventure begin :-) ...

(1) In this transport-capabilities draft under:

        augment "/sysc:system-capabilities"
                + "/notc:subscription-capabilities" {

    we find:

        key "transport-protocol";
        description
           "Indicates supported YANG notifications transport protocol
           for Subscribed Notifications [RFC8639] and YANG-Push
           [RFC8641]. Defines the supported transports, security
           protocols and supported notification encodings.";
        leaf transport-protocol {
          type identityref {
            base sn:transport;
          }

(2) So, we have an identityref in the sn namespace - that namespace is
        is defined by an import element that points over to RFC 8639:

  import ietf-subscribed-notifications {
    prefix sn;
    reference
      "RFC 8639: Subscription to YANG Notifications";
  }

(3) Over in RFC 8639, "transport" is in the subscriptions container,
	as indicated by this portion of the tree diagram:

     +--rw subscriptions
        +--rw subscription* [id]
           +--rw id
           |       subscription-id
           ...
           +--rw transport?                                 transport
           |       {configured}?
	   ...

	and sure enough, here's the YANG definition for "transport"
        under grouping subscription-policy:

     leaf transport {
      if-feature "configured";
      type transport;
      description
        "For a configured subscription, this leaf specifies the
         transport used to deliver messages destined for all
         receivers of that subscription.";
    }

	that "transport" definition uses this typedef:

  typedef transport {
    type identityref {
      base transport;
    }
    description
      "Specifies the transport used to send notification messages
       to a receiver.";
  }

(4) That's nice, but what are the allowed identityrefs for "transport"?
        RFC 8639 doesn't say, and neither does this draft.

        But ... looking at this draft's examples, there appear to be two
        identityrefs that are allowed:

  xmlns:hnt="urn:ietf:params:xml:ns:yang:ietf-https-notif-transport"
  ...
  xmlns:unt="urn:ietf:params:xml:ns:yang:ietf-udp-notif-transport">
  ...
            <transport-protocol>hnt:https</transport-protocol>
            ...
            <transport-protocol>unt:udp-notif</transport-protocol>

(5) Returning to the YANG, for UDP, we need to find udp-notif in
        the ietf-udp-notif-transport module.

	That module is defined over in draft-ietf-netconf-udp-notif-26,
        where we find:

  identity udp-notif {
    base sn:transport;
    base sn:configurable-encoding;
    description
      "UDP-Notif is used as transport for notification messages
      and state change notifications.";
  }

	which matches unt:udp-notif in the example excerpted at step (4),
	completing this journey (whew!).

The journey appears to lead to the following answers to the initial questions:

Q1: Are there concrete and finite definitions of the values that can go in these fields?
    If so, where are the definitions and the registry for them?
A1: Yes, there are concrete and finite definitions. They are found by locating the YANG
    *-Notif modules that define a *-notif identity that is based on sn:transport.
    Two of the internet drafts referenced by this draft define such modules.

Q2: What is the process for expanding the list of possible values?
A2: For a transport protocol foo, define a foo-notif module that contains
        a foo-notif identity that is based on sn:transport.

The journey took a good 30 minutes of this reviewer's time.  The authors should
add an explanatory paragraph or two to section 1 and/or section 2 of the draft to
provide explanation sufficient to reduce this 30 minute journey to a 30 second
read for a reader who has some YANG familiarity, but is not a YANG expert.

In addition, the authors should reread Tommy's review and respond to all of his
questions and concerns.  That review has been incorporated by reference into this
review, hence its contents should be considered as IETF Last Call comments on -07.

I concur with Tommy's observation that "transport protocol" is overly broad, and
suggest "notification transport protocol" as a replacement.  Likewise "security
protocol" would be better replaced by "notification security protocol"

Tommy also asked ...

Q3: Since you have "security transports" as an orthogonal concept to the
"transport protocols", how do you capture the ways those protocols compose
and interact?

An initial investigation of this question turned up what appears to be an
omission in this draft. That omission stems from the statement in
draft-ietf-netconf-https-notif-16 that the HTTPS notification transport is
only supported over HTTP/1.1 and HTTP/2.  For HTTP/3, that https-notif draft
explains:

   Since there is no support for configuring the minimum required parameters
   to enable notifications over HTTP/3 [RFC9114], support for it is considered
   out of scope of this document at this time.

This transport-capabilities draft defines security protocol identities only for
DTLS 1.2 and DTLS 1.3, both of which do not work with either HTTP/1.1 or HTTP/2.

The authors need to start by defining security protocol identities for TLS 1.2
and TLS 1.3 for use with the HTTPS notification transport, which will enable 
Q3 to be addressed.