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

[Andy Bierman <[e-mail]>]

On Thu, May 4, 2017 at 7:53 AM, Eric Voit (evoit) <[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]> 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]>
> 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
>
>
>
>
>
>
>
>
>