Re: [netmod] js review of draft-ietf-netmod-schema-mount-09

[Juergen Schoenwaelder <[e-mail]>]

On Fri, Apr 06, 2018 at 03:27:10PM +0200, Martin Bjorklund wrote:
> 
> Ok.  I tweaked it to:
> 
>   This document defines a mechanism to add the schema trees defined
>   by a set of YANG modules onto a mount point defined in the schema
>   tree in some YANG module.
>

Works for me.

> > OK. It seems that for a client capable to support a 'shared schema',
> > the 'inline' schema really is just a special case without parent
> > references. (I wonder whether anything should be said to YANG library
> > version numbers, whether they are always scoped by the mount point
> > or have meaning across mount points; if two YANG library instances
> > in mounted schemas have the same version number, does this imply
> > that these YANG library instances are identical or is this just a
> > version number clash? But then this probably goes across the spirit
> > of not talking about YANG library too much.)
> 
> When you say "version number" do you mean the YANG library checksum?
> I don't think the YL document guarantees that there can never be
> clashes.

Yes, the checksum (which I think is actually a version identifier).
Anyway, the question is whether a client can draw any conclusions from
seeing YANG library instances with the same checksum and whether a
client must simpy treat this as a clash. If multiple mounted schemas
have the same YANG library, then reading one of them would be
sufficient. The question is whether the checksum is a tool for
deciding whether a YANG library is similar to an already known one or
whether a client must not make this assumption, i.e., a checksum is
always scoped to the YANG library instance and you have to read them
all.

> > This helps. Can I also mount NACM into a mount point? If yes, what if
> > both are present?
> 
> Yes you can mount NACM.  To keep things simple, I think the inner NACM
> should not affect the access control done in the parent.  Consider the
> use cases for this.  In a NI situation, it doesn't make much sense to
> mount NACM.  In an LNE (or in a "peer mount") situation, it may make
> sense to mount NACM if the LNE (or device) supports it.  In this case,
> if I try to access any mounted data in the parent, access is
> controlled by the parent.  If I have access, the parent may send a
> request over to the mounted device to read/write the data.  That
> device will use its local copy of NACM to control access, or some
> other mechanism.

In this scenarios, if the parent NACM grants access but the inner NACM
does not grant access, I assume I will not have access, right? So how
does this line up with "the inner NACM should not affect the access
control done in the parent"? Frankly, this is all a bit hypothetical
since we have no standards for doing peer mounts - and clearly not for
writable peer mounts. So probably the truth is that it is undefined
whether the inner NACM applies or not. Hm.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>