Yes. The one thing I would add is that validation of the mounted data can occur in its original path (the authoritative owner (in the distributed case)). It should not be required to do this validation with the chrooted path, although that path can be used by other data nodes that refer to / have dependencies on the mounted data.
Regarding naming, do you have an alternative suggestion? Cheers --- Alex -----Original Message----- From: Martin Bjorklund [mailto:[email protected]] Sent: Wednesday, August 26, 2015 11:27 PM To: Alexander Clemm (alex) <[email protected]> Cc: [email protected]; [email protected] Subject: Re: [netmod] Y34 - root node "Alexander Clemm (alex)" <[email protected]> wrote: > - As Martin mentioned, clearly by allowing to mount you are decoupling > schema information and instance population. Regarding the issue of > validation, this can be addressed by several ways. I think that the mount point effectively works as a 'chroot' for all mounted data models in the mount point. This means that if ietf-interfaces and ietf-routing are mounted under /devices/device/data, all XPath expressions and leafref paths and instance-identifiers in these models are evaluated in a chrooted environment where their '/' is set to /device/device[name='...']/data. This is how we implement validation for such modules in our NCS (manager product). In an implementation that actually does not store the data locally, but fetches it from a remote device (like the original mount proposal), it is fine to push also validation to the remote node. [maybe mount is not a good name for this generalized thing; this term might make you believe that the data has to be provided by some other server.] /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
