> On 23 May 2016, at 14:30, Lou Berger <lber...@labn.net> wrote: > > Hi Lada, > I looks like no one really jumped on this one -- so better late than > never ... > > When looking at the question below, we should consider the uses cases. > I'm particularity interested (as a contributor) in the use case of > nested mounts (NIs mounted within LNEs), as well as the case if models > that will only permit mounting of specific other models vs generically > mounting any model. > > On 4/6/2016 10:07 AM, Ladislav Lhotka wrote: >> Hi, >> >> with a schema mount mechanism in place, there are two different options >> for constructing the overall schema (their combinations are possible, >> too): >> >> 1. Define schema mount as an extension of YANG library so that it >> defines YANG modules, revisions, features and deviations as before but >> also the way how they are combined into a hierarchical structure of >> schemas. > > I think this only makes sense if this is scoped in some way. For > example, with LNEs, the parent/host server may not have visibility into > the mounted models, (see draft-rtgyangdt-rtgwg-lne-model). And even if
As I understand it, schema-mount is about accessing the LNE models from the parent/host management interface. I believe the real question is whether we want to allow the schema to dynamically change at run time and possibly throw in new modules that the client never heard of. #2 can do it while #1 can't. I am not sure though whether the LNE model really requires something like this. > does, you have to consider the cases of mounted models contained within > mounted models. This is possible either way, provided that the complete schema is known upfront. > >> >> 2. Apart from YANG Library data, the server just specifies the mount >> points. A client of an NM protocol is expected to fetch a new instance >> of YANG library and/or subordinate mount points as state data from a >> well-known location under each mount point. > > I think this depends on the use case. For LNEs, I think this is right. > For some of the other possible use cases being discussed only a specific > model can be mounted. I guess I need some example scenarios demonstrating that #1 cannot be used for LNE. Lada > >> I think that #1 should be available (alone or along with #2) because >> there are cases when YANG is used as a data modelling language outside >> the context of a NM protocol – Eliot Lear's MUD presentation is one >> example. > > I think we (the rtg yang arch dt) had envisioned something closer to > 2. And as you say, an approach that also includes a properly scoped 1 > is possible. > > Lou > >> Lada >> > > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
