Re: [netmod] schema mount and YANG library

[Lou Berger <[e-mail]>]

On 1/17/2018 1:59 AM, Ladislav Lhotka wrote:
...
>>>>>> I think
>>>>>> it is incumbent upon those revisiting past/closed WG decisions (in
>>>>>> this case, inline schema being represented by YL) to argue why the
>>>>>> decision needs to be revisited.
>>>>> I'm repeating my self: b/c the current solution doesn't work well with
>>>>> the NMDA.
>>>> I simply don't understand how YL-bis works at the root node but
>>>> doesn't work equally at an inline mount point.  Can you elaborate?
>>> With NMDA, a server may have one schema for the config datastore and
>>> another one for operational (one is a superset of the other).  A
>>> mounted YL can only be present in operational.  Thus, there's no way a
>>> client can learn the schema for config.
>> If the LNE mounted the full YL-bis at the mount point then you would
>> have the list of datastores, and the schema associated with each
>> datastore.  Of course, this would only be available in operational, but
>> that is the same as a regular server support YL-bis.
> YL-bis is different in that it is in fact metadata even though we call it state
> data.
I couldn't agree more.  YL and SM are server metadata and are 
independent of any DS.  They could be accessed via any (as others have 
suggested), but we are currently choosing to access if via operational 
state.  With NMDA, I think personally think server meta data should have 
it's own DS.  This discussion has convinced me that the current proposed 
alternative, of accessing as operational data is flawed and even access 
via *any* DS is preferable.

> In any case, no matter what datastores the server has, YL-bis is the
> single well-known location from which the schema of all datastores can be
> retrieved.
That's a nice idea, but as was discussed in december, the direction 
being taken doesn't include SM so this statement isn't *currently* true.

>
> We could refer to <operational> as the place from which the mounted schemas of
> NMDA-standard config datastores can be retrieved (except for special cases, one
> is discussed below). But if there is another config datastore (e.g. dynamic)
> with an inline mount point instance, it is unclear where to look for the mounted
> schema.
Why?  Is it unclear where to look for YL-bis in this case?  Why is SM 
any different than YL?

>   With my proposal, the mount point instance will be annotated with
> @schema-ref that points to a schema in the top-level YL.
right and as we thrashed out the last time we had discussed this with 
the whole WG, having inline schema available at the top level was not 
the preferred solution.

>
>> I thought that the problem with the current solution and NMDA, was that
>> there is no way to find out what the LNE schema is if the LNE isn't
>> booted, and hence isn't providing <operational>.  But I'm not sure what
>> issues that actually causes.  E.g. does it cause issues with
>> pre-configuration of the LNE?
> The issue that this causes is that the schema for the pre-configured LNE isn't
> known and validity of <intended> is unclear.
Please elaborate on what you see here as a problem.  Those working on 
LNE's (including myself) don't see an issue here.

Lou
>
> Lada
>