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

[Ladislav Lhotka <[e-mail]>]

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

> 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