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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
