On Wed, 2018-02-07 at 11:14 +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder <[email protected]> wrote: > > On Tue, Feb 06, 2018 at 03:25:52PM +0000, Robert Wilton wrote: > > > > > > I think that the term "external" could also be confusing, since I think > > > that > > > sort of implies peer mount like semantics. > > > > The "inline" mount concept seems to subsume peer mounts. From the > > model perspective, is there a difference whether the mounted data is > > local or remote (and what does local/remove mean for a VM)? > > > > > I would suggest the term "dynamic" instead of "inline " but that could > > > easily be confused with dynamic datastores. > > > > Yes, I think this is not a good word either. > > > > > Perhaps rather than "inline" another choice could be "discoverable", i.e. > > > the schema is not known, and is dynamically discoverable inline at the > > > mount > > > point. > > > Equally, rather than "use-schema", perhaps a better choice would be > > > "known", > > > i.e. the schema is already known, and made available as part of YANG > > > library. > > > > Perhaps integrated schema vs. mounted schema. > > I like the term "integrated" better than "use-schema". But both cases > are mounted, so we need another term than "mounted" for "inline". > "segregated" doesn't sound quite right ;-)
I would prefer to use the term "mount" only for the inline case and find something else for the use-schema case. The term "mount" evokes that some *instance* data being added, which is what happens in the "inline" case but not for "use-schema". Lada > > > /martin > > > > > > Whether it would be right to change these at this time, I've no idea ... > > > > Yep. > > > > /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 > [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
