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

["Eric Voit (evoit)" <[e-mail]>]

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:
Hi Andy,
Hi Martin,

This is an excellent document.  I  have a few questions:

#1 Section 3.1.3
If a data node identified in a request has no read access allowed (i.e., data node rule violation), isn’t it better to treat the response like the node didn’t exist, i.e. a “data-missing” error code?   You highlight this as an issue in 3.7.2, but I don’t see a reason why “data missing” isn’t preferable to “access denied” (other than ease of debug.)


data-missing seems tied to the delete operation error
(client tried to delete a node that does not exist).
access-denied can apply to the object -- the data may or may not exist.
I think many of the NETCONF error-tags overlap and we just have to make
a subjective choice.

<Eric> ok

It would be disruptive to change this because 6536-compliant implementations send access-denied



#2  Section 3.1.3
On the sentence: “If the user is not authorized to read all the specified data nodes and the notification node, then the notification is dropped for that subscription.”    There is a difference between events (where the whole event should be discarded), and YANG object selections (where it is preferable to just discard those node for which a receiver has no access).   What are your thoughts based on the type of notification of allowing the simple dropping any nodes where read access is not available if the notification includes some extract of a yang datastore?

The initial intent was to keep NACM simple and make it easier to have high performance implementations.
NACM only allows the event-type to be tested, not any data within it. IMO the new notification work will
be significantly more expensive to implement high performance notification delivery.

NACM does not really work the way YANG push wants it to work.
The  path /my-event/interfaces/interface/name is not the same node
as /interfaces/interface/name. Some handwaving text may say treat these
nodes the same, but they are not related at all (from a NACM POV)

<Eric> Understand.  For this high performance reason in the YANG Push work we do allow for subscriptions to be re-established if underlying object permissions change.

Do you see this NACM text providing a blocker for someone who desires such notification content filtering?  Some early yang-push use cases I am seeing are in the security and config change validation spaces.  As these have low transaction volumes, it may be viable to support such event based permissions mapping in implementation.


no -- see below


#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)


Eric

Andy




Thanks,
Eric

Andy


From: Mahesh Jethanandani, May 3, 2017 5:18 PM
Folks,

There has been literally no feedback on this document, either to say they have read the document and support it, or to express concerns about the document. Silence, unfortunately is not a good guide for us. To move the document forward, we need to hear from folks, including those who were in IETF 98.

Thanks.

On Apr 18, 2017, at 5:34 PM, Mahesh Jethanandani <[e-mail]<mailto:[e-mail]>> wrote:

NETCONF WG,

In IETF 98, the authors indicated that the above draft was ready for Last Call, and the consensus in the room indicated as much.

This is a start of a 2 week WG Last Call for draft-ietf-netconf-rfc6536bis. After two weeks, the document will be assigned a shepherd, and the document will be prepared for IESG.

The latest version of the draft can be found at:
https://tools.ietf.org/html/draft-ietf-netconf-rfc6536bis-01

Please review and send any comments to the WG mailing list or by responding to this e-mail. Comments can be statements such as, I read/reviewed the document and believe it is ready for publication, or I have concerns about the document. For the latter, please indicate what your concerns are.

Any reports on implementation status or plans to implement are also very useful.

Authors, please indicate if you are aware of any IPRs related to the draft.

Thanks.

Mahesh and Mehmet



Mahesh & Mehmet