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

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


Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

netmod mailing list

Reply via email to