> On 23 May 2016, at 15:58, Lou Berger <[email protected]> wrote: > > 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.
OK, so it seems to be related to the use cases for peer mount, which IMO has a lot of other issues to solve. > >>> 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. Well, if the server knows everything upfront, it can also publish the schema in the compact form. A client may not support everything but at least it is able to tell whether it is the case or not. Lada > > 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
