Juergen, I think you are correct. Also alias-mount and peer-mount (not just schema-mount) specify mountpoints in the schema. They are not about mounting arbitrary data in arbitrary places, but defining a model with mountpoints declared. --- Alex
-----Original Message----- From: netmod [mailto:[email protected]] On Behalf Of Juergen Schoenwaelder Sent: Wednesday, February 24, 2016 8:10 AM To: Martin Bjorklund <[email protected]> Cc: [email protected] Subject: Re: [netmod] explicit mount On Tue, Feb 23, 2016 at 04:08:06PM +0100, Martin Bjorklund wrote: > Hi, > > In yesterday's meeting, Lou (I think?) mentioned a use case for mount > that is not documented in draft-rtgyangdt-rtgwg-device-model; the need > for being able to specify modules to mount directly in the schema. > Something like this: > > container root { > ymnt:mount-point "lne" { > ymnt:mount-module "ietf-interfaces"; > } > } > > It would be useful if the use case for this could be described in more > details. Is it a requirement to be able to specify this in the > schema, or could it be done (as Chris mentioned) in the RFC text? > > The reason I ask is that it is probably not as simple as the example > above. First, you probably need to specify a revision of the module > to be mounted. Or a min-revision. Then probably a set of features > that must be enabled. And so on. It turns out that there is already > a proposal for specifying such a "conformance profile" - YANG Packages > (see draft-bierman-netmod-yang-package). Maybe it would be better to > re-use packages? We are talking schema mount, right? So why would features matter? Yes, there might be interesting versioning issues but how are they different from an augmentation putting data under root? I naively considered such a 'static schema defined mount' the simplest case, then the 'augmented schema defined mount' naturally following from the way augmentations work: augment /some:root { ymnt:mount-point "lne" { ymnt:mount-module "ietf-interfaces"; } } The 'dynamic runtime defined mounts' may be most flexible but then they require me to read runtime data in order to adapt to the schema structure, which has its own set of complexities. Yes, the versioning issues go away since I have to adapt to each implementation dynamically but there is surely a cost involved with that as well. Am I missing something? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
