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

[[e-mail]]

Dear RFC 9196 authors,

Reshad and I have a different understanding on wherever through NACM YANG node permissions are inherited or not. Or in other words if a Netconf/Restconf client has certain permissions to access a certain YANG node defined by NACM, depending on those permission only subscribe able YANG nodes would be shown.

I understood that Reshad interprets below text that all YANG nodes regardless would be shown.

Can you clarify this for us?

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.";
     }



Thomas Graf
____________________________________________________________________________
Distinguished Network Engineer
Network Analytics Architect
Telefon [phone]
Mobile  [phone]
[e-mail]<mailto:[e-mail]>
____________________________________________________________________________
Swisscom (Schweiz) AG
IT, Network & Infrastructure
Datacenter Functions
Binzring 17
8045 Zürich
www.swisscom.com<http://www.swisscom.com/>
Postadresse:
Binzring 17
8045 Zürich


From: Reshad Rahman <[e-mail]>
Sent: Tuesday, March 10, 2026 10:40 PM
To: [e-mail]; [e-mail]; Graf Thomas, SCS-INI-NET-VNC-E2E <[e-mail]>
Cc: [e-mail]; ludwig=[e-mail]; balazs.lengyel=[e-mail]
Subject: Re: Question on draft-ietf-nmop-yang-message-broker-integration - ietf-system-capabilities

Be aware: This is an external email.

Hi Thomas,

Even bigger apologies from me, that RTT doesn't match the SLO :-( Unfortunately, your email somehow ended up in the wrong folder, and only when I was going through the archive for threads on this document I noticed that you replied...

I don't interpret RFC9196 and RFC8341's node-instance-identifier the same way as you do. I also don't see how RFC9196's implementation-time use case works if the data in per-node-capabilities is user-specific. But I can very well be mistaken.

Regards,
Reshad.

On Friday, November 28, 2025 at 11:55:16 PM PST, <[e-mail]<mailto:[e-mail]>> wrote:



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]<mailto:[e-mail]> is using a type reference to nacm:node-instance-identifier in [e-mail]<mailto:[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]<mailto:[e-mail]>>
Sent: Wednesday, October 29, 2025 4:23 PM
To: Nmop <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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.