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
