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

[Andy Bierman <[e-mail]>]

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.




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



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






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