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

[Robert Wilton <[e-mail]>]

Hi,


On 08/12/2017 18:01, Andy Bierman wrote:
> Hi,
>
> A library per datastore sounds too complicated.
> I prefer the proposal that was made at the IETF meeting that had
> a 'not-implemented-in' leaf-list and a single module list.
The use case that this particular design doesn't work particularly well 
for is if you have a dynamic datastore that just contains a few modules 
that are not supported via the conventional datastores.

I think that there are future uses cases where the set of modules used 
for a dynamic datastore could be really quite different and separate 
from conventional configuration.  E.g. if dynamic subscribers were 
managed through a dynamic configuration datastore rather than RADIUS.

>
> Why is it interesting to have a separate module list for regular 
> modules and imported modules?
Several reasons:
1) It means that the list of implemented modules have a single key and 
hence any references to an implemented module are cleaner/simpler.
2) The model structure naturally more strictly enforces that only a 
single revision/version of a module is implemented.  (E.g. it prevents a 
server stating that two revisions of a module are both implemented).
3) I genuinely think that the list of implemented modules is more 
interesting to the client than the imported, but not implemented modules.

For a server, I would design it to "implement" one revision of every 
module that it uses (including those that don't contain any data nodes, 
RPCs, actions, notifications, or deviations), and then the "import-only" 
list becomes the list of modules that the server implements to satisfy 
"import-by-revision" and these are stated in the implemented schema anyway.


> 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.
All solutions accommodate this requirement.

For me, some of the interesting design questions have revolved around:
- is it better to reduce duplication in the list of modules reported at 
the cost of increased model complexity?
- does the solution extend to schema mount?
- how well does the solution cope with with configuration datastores 
that support very different sets of modules?

To a lesser extent we have also been considering how well the solution 
extends to packaging and semantic versioning, but I think that it is 
quite tricky to know who these are going to pan out. E.g. I think that 
the restriction that a given schema will only implement a single 
revision of a module will end up still holding, but I'm not sure that 
everyone has that same view point.

Thanks,
Rob


>
>
> 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>
>
>
>
>
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf