Re: [netmod] compact versus iterative representation of the overall schema

[Ladislav Lhotka <[e-mail]>]

> On 23 May 2016, at 15:58, Lou Berger <[e-mail]> wrote:
> 
> Lada
> 
> See below
> 
> On 5/23/2016 9:43 AM, Ladislav Lhotka wrote:
>>> On 23 May 2016, at 14:30, Lou Berger <[e-mail]> 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