Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis

[Robert Wilton <[e-mail]>]

Hi Vladimir,


On 09/12/2017 11:49, Vladimir Vassilev wrote:
> On 12/08/2017 07:01 PM, Andy Bierman wrote:
>
>> Hi,
>>
>> A library per datastore sounds too complicated.
> I am not proposing that.
I'm slightly lost, because I thought that was exactly what you were 
proposing! ;-)

>
>
> The fundamental point proposed is that the datastore relevant bits are 
> kept in the ietf-datastores module instead of merging everything in a 
> new ietf-yang-library entangled monster module. If needed 
> ietf-datastores can augment ietf-yang-library but ietf-yang-library 
> should be usable on its own without ietf-datastores. The solution is 
> coherent and modular and addresses the problem statement.

The issue with this is that datastore augmentations to YANG library 
would end up changing the meaning of the existing YANG library nodes.  
E.g. an old client that ignores the datastore augmentations is going to 
get a nasty surprise when the server does not behave how it expects.  
E.g. because the configuration node that it thinks should be there isn't 
there because it only supported in <operational>.

This was one of the reasons for changing YANG library.

In terms of the idea of just re-using YANG library but export a separate 
copy for each datastore I think that this has its own problems:
- I don't like the idea of returning meta-data along with configuration 
for a <get-data> on any of the configuration datastores.
- How does a client know whether the YANG library for <running> applies 
to the whole server (as it does today) vs just applies to the <running> 
datastore (as it would for an NMDA server)?
- It requires more handshaking between the client and server to get the 
schema, since a separate request would be required for each datastore 
that is supported.

So, for me, I think that the only way that this solution works, would be 
to define a new <get-server-metadata> RPC, but even then I think that it 
would make sense to combine the data together into a new YANG library 
structure.

At the end of the day, I don't think that a new YANG library is going to 
be were the real cost for supporting NMDA comes from.  I think that the 
real work is supporting <operational> independently from <running> both 
in the client and servers. But I also think that once servers start 
implementing this properly that it will simplify automation, because 
rather than a client having to guess what state a server is in, it can 
actually querey, or be notified of it, without having to write a lot of 
model specific code.

Thanks,
Rob


>> I prefer the proposal that was made at the IETF meeting that had
>> a 'not-implemented-in' leaf-list and a single module list.
> This constraint is already specified in the text of the revised 
> datastores draft. Clients conforming to the draft can expect servers 
> to comply with the MUST requirement even if there is a separate 
> yang-library data tree for each datastore the constraint of 
> configuration stores mapping to 'operational' should be enforced 
> according to the draft. There is no contradiction here.
>
> That said I would be also be OK with ietf-datastores augmenting 
> ietf-yang-library with such a leaf-list ('not-implemented-in' 
> leaf-list) as a more constrained flavor of the same approach instead 
> of going for independent copies of yang-library data. For any of that 
> to happen change in ietf-datastores.yang is needed and change in the 
> original rfc7895 ietf-yang-library is not needed at all.
>
> Vladimir
>
>>
>> Why is it interesting to have a separate module list for regular 
>> modules and imported modules?
>> I prefer to keep the conformance leaf and not change the module list.
>>
>> NMDA needs to be possible to implement with a single schema tree such 
>> that a module
>> is implemented in all datastores, or a subset of all datastores.  
>> Otherwise it probably won't
>> get supported in clients.
>>
>>
>> Andy
>>
>>
>>
>> On Fri, Dec 8, 2017 at 9:21 AM, Kent Watsen <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>>     CC-ing NETCONF, where the draft is being worked on.
>>
>>     Kent
>>
>>
>>     On Fri, 2017-12-08 at 16:34 +0100, Juergen Schoenwaelder wrote:
>>     > On Fri, Dec 08, 2017 at 04:19:28PM +0100, Vladimir Vassilev wrote:
>>     > >
>>     > > Yes. The default value for yang-library-datastore leaf is
>>     ds:operational
>>     > > (the only possible one for the ds:operational datastore). This
>>     is backward
>>     > > compatible. If one needs different model for 'running', etc.
>>     then a new
>>     > > datastore identity has to be defined  and set in place of the
>>     default value.
>>     > > Then this identity can be used to read the yang-library data 
>> with
>>     > > <get-data>.
>>     > >
>>     >
>>     > Sorry, but I have to ask this: How do I obtain the schema for the
>>     > datastore (lets call it <running-library>) that reports the
>>     schema for
>>     > <running>? Is there another <running-library-library> datastore?
>>     Will
>>     > the recursion end? Perhaps it does since <running-library-library>
>>     > might have itself listed as the schema defining datastore. I guess
>>     > Lada will like these kind of meta and meta-meta datastores.
>>
>>     Not really. Metadata needn't be in datastores.
>>
>>     Lada
>>
>>     >
>>     > /js
>>     >
>>     --
>>     Ladislav Lhotka
>>     Head, CZ.NIC Labs
>>     PGP Key ID: 0xB8F92B08A9F76C67
>>
>>     _______________________________________________
>>     netmod mailing list
>>     [e-mail] <mailto:[e-mail]>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5qj6BQUSwqYmkAVeKz5axFV8k3gxYEPSJ5Cp0RSnxrE&s=I7fR1GY5lN2hVMkDuvryrhDeRypike3wPeFRrvQI5l8&e=
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5qj6BQUSwqYmkAVeKz5axFV8k3gxYEPSJ5Cp0RSnxrE&s=I7fR1GY5lN2hVMkDuvryrhDeRypike3wPeFRrvQI5l8&e=>
>>
>>
>>     _______________________________________________
>>     netmod mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/netmod
>>     <https://www.ietf.org/mailman/listinfo/netmod>
>>
>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf