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