[NMOP] Re: Question on draft-ietf-nmop-yang-message-broker-integration - ietf-system-capabilities

[[e-mail]]

Dear Reshad,

Apologies for late reply. I believe my reply https://mailarchive.ietf.org/arch/msg/netconf/ByHjCK3UEmNaWiKoJsciA_-qAVs/ back then was a bit too short and thanks for giving me a nudge.😊

My understanding is as following, and please correct/challenge me, I might have misunderstood something. I put the RFC 9196 authors in CC. They might want to jump in and comment.

The leaf "node-selector" in [e-mail] is using a type reference to nacm:node-instance-identifier in [e-mail]. According to typedef node-instance-identifier definition, the YANG node permissions are inherited. See below for references.

Therefor I believe RFC 9196 does it correctly. The netconf client user who discovers the capabilities sees only the xpaths which he can subscribe in YANG-Push.

https://datatracker.ietf.org/doc/html/draft-ietf-nmop-yang-message-broker-integration-09#section-4.1 implies that the netconf client user who discovers is also the one which subscribes. Let me know wherever it is worth to detail in the document that discovery and subscription have the same access rights when the same user is used.

Best wishes
Thomas


https://datatracker.ietf.org/doc/html/rfc9196#section-4.2
      list per-node-capabilities {
        description
          "Each list entry specifies capabilities for the selected
           data nodes.  The same capabilities apply to the data nodes
           in the subtree below the selected nodes.

           The system SHALL order the entries according to their
           precedence. The order of the entries MUST NOT change
           unless the underlying capabilities also change.

           Note that the longest patch matching can be achieved
           by ordering more specific matches before less
           specific ones.";
        choice node-selection {
          description
            "A method to select some or all nodes within a
             datastore.";
          leaf node-selector {
            type nacm:node-instance-identifier;
            description
              "Selects the data nodes for which capabilities are
               specified. The special value '/' denotes all data
               nodes in the datastore, consistent with the path
               leaf node on page 41 of [RFC8341].";
            reference
              "RFC 8341: Network Configuration Access Control Model";
          }
        }

https://datatracker.ietf.org/doc/html/rfc8341#section-3.5.2
     typedef node-instance-identifier {
       type yang:xpath1.0;
       description
         "Path expression used to represent a special
          data node, action, or notification instance-identifier
          string.

          A node-instance-identifier value is an
          unrestricted YANG instance-identifier expression.
         All the same rules as an instance-identifier apply,
          except that predicates for keys are optional.  If a key
          predicate is missing, then the node-instance-identifier
          represents all possible server instances for that key.

          This XML Path Language (XPath) expression is evaluated in the
          following context:

             o  The set of namespace declarations are those in scope on
                the leaf element where this type is used.

             o  The set of variable bindings contains one variable,
                'USER', which contains the name of the user of the
                current session.

             o  The function library is the core function library, but
                note that due to the syntax restrictions of an
                instance-identifier, no functions are allowed.

             o  The context node is the root node in the data tree.

          The accessible tree includes actions and notifications tied
          to data nodes.";
     }

From: Reshad Rahman <[e-mail]>
Sent: Wednesday, October 29, 2025 4:23 PM
To: Nmop <[e-mail]>; [e-mail]
Subject: Question on draft-ietf-nmop-yang-message-broker-integration

Be aware: This is an external email.

Hi,

Going through the broker-integration document<https://datatracker.ietf.org/doc/draft-ietf-nmop-yang-message-broker-integration>, it reminded me of this thread<https://mailarchive.ietf.org/arch/msg/netconf/L0Z7UeVrICoKq0NSOdMH8MyMIow/>. Looking at sections 4 and 4.1, specifically steps (1) and (2): user A reads the RFC9196 capabilities and sees that /interfaces/interface/ifstate supports on-change (meaning user A has NACM access to the capabilities data). But that doesn't imply that user A can e.g. dynamically subscribe on-change to /interfaces/interface/ifstate? i.e maybe user A does not have access to /interfaces/interface/ifstate?

Regards,
Reshad.