From: Andy Bierman, Friday, August 21, 2015 10:28 AM <snip> > >>> Currently we have a proprietary way of "relocating" YANG modules, and > >>> ODL has its "mount", and I think Andy has some other mechanism. Maybe > >>> the time has come to standardize how mount works, and maybe then also > >>> standardize the list of devices in a controller model.
It seems there are many places where mount is being used effectively. I am all for some standard syntax. > >> +1 > >> > >> We just need to standardize a "docroot within a docroot". > >> This is not relocation of subtrees within the datastore, this is just > >> mounting > >> a datastore somewhere within a parent datastore. > >> > >> In YANG validation terms, you simply adjust the docroot to the nested > >> mount > >> point, > >> and the replicated datastore can be used as if it were stand-alone. > >> This would allow any sort of encapsulation of datastores and not add > >> any > >> data model complexity to devices which do not have virtual servers > >> (most of them). > > Compared to the mount draft, I would like to decouple the schema > > information from the instance population mechanism. I.e., I'd like a > > mechanism that simply defines the schema, not necessarily how the data > > is populated (in the mount draft data was fetched from a remote > > server, but IMO that is just one of several use cases). > Yes, I agree that these could/should be decoupled. Although I note > that the mount draft does also allow for local mounts, although this > does not seem to be intended to be the mainline case. The mount draft was indeed driven by OpenDaylight's use cases. In ODL, mount is used for local YANG representation of remote device information. Based on this I believe a generalized mount syntax should not mandate that the target must be local and cannot be remote. Nor should a generalized mount syntax itself restrict whether the target node contain schema or instance info. There are many ways beyond the syntax if an implementation has no desire for this. Eric _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
