Lou Berger píše v Po 28. 08. 2017 v 08:54 -0400: > > On 8/28/2017 7:35 AM, Martin Bjorklund wrote: > > Lou Berger <[email protected]> wrote: > > > Martin, > > > See below. > > > > > > On 08/28/2017 06:28 AM, Martin Bjorklund wrote: > > > > Lou Berger <[email protected]> wrote: > > > > > Martin, > > > > > See below > > > > > > > > > > > > > > > On August 23, 2017 2:28:37 AM Martin Bjorklund <[email protected]> > > > > > wrote: > > > > > > > > > > > Lou Berger <[email protected]> wrote: > > > > > > > Hi Martin, > > > > > > > > > > > > > > See below. > > > > > > > > > > > > > > > > > > > > > On 8/22/2017 6:20 AM, Martin Bjorklund wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > Lada presented an open issue in schema mount in Prague. (See > > > > > > > > slide 6 > > > > > > > > in > > > > > > > > > > > > > > > > > > > > > > https://datatracker.ietf.org/meeting/99/materials/slides-99-netmod-sessb-schema-mount) > > > > > > > > The original problem comes from the NI use case > > > > > > > > (https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model). In > > > > > > > > this > > > > > > > > use case, interfaces are assigned to NIs by: > > > > > > > > > > > > > > > > augment /if:interfaces/if:interface: > > > > > > > > +--rw bind-ni-name? -> > > > > > > > > /network-instances/network-instance/name > > > > > > > > > > > > > > > > Modules that are mounted within the NI might have references to > > > > > > > > interfaces. The idea is that a specific NI can only reference > > > > > > > > the > > > > > > > > interfaces that has been assigned to it. > > > > > > > > > > > > > > > > In schema mount, we have the "parent-reference" XPath > > > > > > > > expression that > > > > > > > > in this case will be "/if:interfaces/if:interface". The > > > > > > > > problem is > > > > > > > > that this XPath expression will evaluate to a node set that > > > > > > > > contains > > > > > > > > *all* interfaces in the system. We would like this to contain > > > > > > > > just > > > > > > > > the interfaces assigned to the NI. > > > > > > > > > > > > > > > > It turns out that this can be done with a simple change to the > > > > > > > > "parent-reference" node. If we state that this XPath > > > > > > > > expression is > > > > > > > > evaluated in an XPath context where the context node is the > > > > > > > > node in > > > > > > > > the data tree where the mount point is defined (instead of > > > > > > > > "/"), we > > > > > > > > can use as parent-reference: > > > > > > > > > > > > > > > > /if:interfaces/if:interface[ni:bind-network-instance-name = > > > > > > > > ../ni:name] > > > > > > > > > > > > > > > > Putting this together we'd have: > > > > > > > > > > > > > > > > augment "/if:interfaces/if:interface" { > > > > > > > > leaf bind-ni-name { > > > > > > > > type leafref { > > > > > > > > path "/network-instances/network-instance/name"; > > > > > > > > } > > > > > > > > } > > > > > > > > } > > > > > > > > > > > > > > > > container network-instances { > > > > > > > > list network-instance { > > > > > > > > key name; > > > > > > > > leaf name { ... } > > > > > > > > ... > > > > > > > > container root { > > > > > > > > // this would be the XPath context root for > > > > > > > > parent-reference > > > > > > > > yangmnt:mount-point ni-root; > > > > > > > > } > > > > > > > > } > > > > > > > > } > > > > > > > > > > > > > > note that the current NI definition is: > > > > > > > > > > > > Yes I saw that. > > > > > > > > > > > > > module: ietf-network-instance > > > > > > > +--rw network-instances > > > > > > > +--rw network-instance* [name] > > > > > > > +--rw name string > > > > > > > +--rw enabled? boolean > > > > > > > +--rw description? string > > > > > > > +--rw (ni-type)? > > > > > > > +--rw (root-type)? > > > > > > > +--:(vrf-root) > > > > > > > | +--mp vrf-root? > > > > > > > +--:(vsi-root) > > > > > > > | +--mp vsi-root? > > > > > > > +--:(vv-root) > > > > > > > +--mp vv-root? > > > > > > > > > > > > Note that the extension yangmnt:mount-point can only be present in a > > > > > > container or list, not in a choice/case. > > > > > > > > > > Okay, I missed that restriction in your draft. What's the reason for > > > > > not allowing mounts under choices/cases? Isn't the resulting path to > > > > > data nodes indistinguishable when the parent is a list or container? > > > > > > > > Suppose a server lists a couple of modules for "vrf-root" and some > > > > other for "vsi-root" in the /schema-mounts/mount-point list. How can > > > > a client tell if a certain NI instance is has the "vrf" modules or > > > > "vsi" modules? > > > > > > umm, my understanding is that only one of the cases under a choice can > > > be present in the data (tree) at a time so the client *can* only see one > > > mount point {vrf-root, vsi-root or vv-root} node and all the mounted > > > schemas will be under that '-root' node. What have I missed? > > > > The mount point itself is not a node. > > okay, I think we're getting to the crux of this issue! I certainly > didn't see this (that a schema-mount root node is *not* represented in > the data, but only in the schema) stated in > draft-ietf-netmod-schema-mount. In fact, I read the text as saying just > the opposite:
I don't think so, it just says that an (existing) node in the parent schema gets the mount-point label. The mount-point extension itself generates no extra node. If we used schema node identifiers denoting the mount points instead of the extension (as I proposed earlier), there would be no additions to the schema proper, so this confusion couldn't arise. > > The basic idea of schema mount is to label a data node in the parent > schema as the mount point, and then define a complete data model to > be attached to the mount point so that the labeled data node > effectively becomes the root node of the mounted data model. > > Why don't you think an MP should be represented in the data (tree)? > > In our example usage > (https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model-03#appendix-B) we > include the mount point as a node in the data. You're saying that this > doesn't line up with your expectation, right? > > Can you please take a look at it and see if we have any other disconnects? This is really scary. How can we expect poor data modellers to understand the concept if we have such fundamental disconnects, after so many hours of discussing it? Lada > > > So the client will just see > > some mounted top-level nodes. If you require that all mount points > > have disjoint sets of modules, then this could work. But I assume > > that this is not the case. > > <rest trimmed> > > Lou > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
