[netconf] Re: Question about NACM username for configured-subscription receivers

[Andy Bierman <[e-mail]>]

On Tue, Aug 18, 2026 at 11:30 AM Kent Watsen <[e-mail]> wrote:

> > I think this is an open issue, and you have captured all the important
> points.
>
> I agree that it's an open-issue, but only to the extent that a
> clarification is required.  An Errata on RFC 8639 is appropriate.
>
>
> > I think our server code uses 'system' (i.e. no NACM user name, and no
> NACM enforcement).
>
> IMO, this is the correct (read: long-term) behavior.  That is, the
> access-control need only apply at the time a subscription (whether dynamic
> or configure) is created, not at the time a notification is being sent, as
> it would affect performance to have such logic in the fast path.
>
> The NACM check is there for client retrieval. but not for notifications

https://datatracker.ietf.org/doc/html/rfc8341#section-3.4.6

   If the user is authorized to receive the notification
   event type, then it is also authorized to receive any data it

contains.

But NACM could have:
  --read-default=deny
  -- explicit rules to permit reading the push-update and
push-change-update events

No check is done (in our server) on the user that configures /subscriptions
to make sure
they have read access to these event types. Does this have to be done?
Reject the edit request if not?

NACM does require that the user is authorized to receive the event-type,
and this check is skipped if the user is 'system'.  Is that a problem?



> > If the NACM user-name was saved (or configured?) in the subscription,
> then the behavior
> > would be more consistent with dynamic subscriptions.
>
> Per above, I don't think saving the username that created the configured
> subscription is necessary.
>
>
Agreed. This is not done for anything else in the config.


>
> Kent // contributor
>
>
Andy