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

[Lou Berger <[e-mail]>]

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.

>> 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
>
>
>
>
>