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

[Andy Bierman <[e-mail]>]

Hi,


On Thu, Jun 25, 2026 at 9:59 AM Per Andersson <[e-mail]> wrote:

> Hi,
>
> On Tue, May 5, 2026 at 9:18 AM <[e-mail]> wrote:
> >
> > 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.
>
> As a contributor and having implemented RFC 9196, I interpret
> node-instance-identifier as having access restricted by applicable
> NACM rules for the user viewing the tree.
>
> I am sensitive about leaking data or even existence of paths
> without applying the the correct access control.
>
> The Security Considerations in RFC 9196 state the following:
>
>    All protocol-accessible data nodes in augmented modules are read-only
>    and cannot be modified.  Access control may be configured to avoid
>    exposing any read-only data that is defined by the augmenting module
>    documentation as being security sensitive.
>
> I would argue that showing existence of paths in the
> /system-capabilities tree when the user aren't allowed
> access to these nodes directly is a leak.
>
>
>
This issue was discussed during NACM development, and for the
/restconf/operations list.
It was decided then that leaking the data nodes and operations supported by
the server was not a concern,
since all this info is derivable by reading the YANG library or the NETCONF
<hello> message for YANG 1.0.

--
> Per, contributor
>
> --
> Nmop mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]



Andy