Lada See below
On 5/23/2016 9:43 AM, Ladislav Lhotka wrote: >> On 23 May 2016, at 14:30, Lou Berger <[email protected]> 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. Again there are different use cases. In the fixed-mount case (where a module containing the mount specifies what model is being mounted) a client will always know what to expect. In the LNE and probably even NI cases, a single client may talk to multiple servers, each of which may have different mounted models. I'm less sure about a single server with different models mounted under different NIs, but this is certainly possible in the LNE case. >> 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. I think the complete schema is likely to be known by there server upfront in all cases, but not the client. Lou >>> 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 [email protected] https://www.ietf.org/mailman/listinfo/netmod
