On 12/08/2017 07:01 PM, Andy Bierman wrote:
Hi,
A library per datastore sounds too complicated.
I am not proposing that.
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.
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 <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
