Re: [Netconf] WG LC for draft-ietf-netconf-rfc6536bis

[Alexander Clemm <[e-mail]>]

One comment below, very bottom, <ALEX>
--- Alex

From: Netconf [mailto:[e-mail]] On Behalf Of Eric Voit (evoit)
Sent: Thursday, May 04, 2017 8:07 AM
To: Andy Bierman <[e-mail]>
Cc: Netconf <[e-mail]>
Subject: Re: [Netconf] WG LC for draft-ietf-netconf-rfc6536bis

Thanks Andy.   I am good with the document.

From: Andy Bierman,  May 4, 2017 11:02 AM



On Thu, May 4, 2017 at 7:53 AM, Eric Voit (evoit) <[e-mail]<mailto:[e-mail]>> wrote:

From: Andy Bierman, May 4, 2017 12:51 AM
On Wed, May 3, 2017 at 6:15 PM, Eric Voit (evoit) <[e-mail]<mailto:[e-mail]>> wrote:
….

#3 Section 3.4.6
Outgoing <notification> Authorization in 3.4.6 say descendent nodes are out of scope.  But as some notifications can contain datastore extracts, it would seem useful allow NACM to act similarly to the processing of a response to a get.  Also is there an intersection of this point with #2 above?

IMO this should not be done (unless you want you code to run way slower)
It also means the client cannot be sure what the server will leak.
I prefer to apply NACM at subscription-time. If the client is not allowed to
read everything in the requested subscription, it is denied.

This doesn't really work for data rules on specific instances that get created
after the subscription starts. But applying NACM data rules to every descendant
node in a YANG push is going to be extremely slow. This gets even worse
for subscriptions with multiple receivers (as NACM has to be enforced for
each receiver). I would prefer to see a solution that forces YANG push
to enforce NACM at update generation time (before the notification
delivery system ever sees it) But this assumes YANG push is aware
of the active subscriptions, so not an ideal solution at all.

<Eric> understand, and agree these are valid approaches.   I am just hoping that the text doesn’t explicitly preclude implementations which might be able to accomplish notification based content filtering.  As the text currently says “out of scope”, my reading is that this not precluded.


IMO it is OK to put this requirement on a YANG push implementation.
The pruning is done by YANG push, not NACM
Then NACM checks the event-type (if so configured)

<ALEX> Is this something that could be added to NACM as a feature/extension to be applied to specific notification types?   Perhaps it does not need to be fully speced out in this document, but still described how this could be accommodated.  As mentioned in my other message, I do think this is an important limitation.  It is made for a reason, but still with possible scenarios that we can already anticipate (with other WG items that are WIP) which will call for that limitation to be overcome, so I think this warrants adding at a minimum a brief section discussing this.
</ALEX>