On 11/12/2017 20:55, Andy Bierman wrote:
On Mon, Dec 11, 2017 at 2:57 AM, Robert Wilton <[email protected]
<mailto:[email protected]>> wrote:
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.
IMO you are replacing universally meaningful keys (module-name,
revision-date) with an arbitrary name,
It is not cleaner and not simpler for a client.
No, for alternatives A and B, the list key is the module name itself,
nor an arbitrary name.
Alternative C uses an arbitrary name.
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).
How is that the case if the schema list includes its own module list?
You mean there is a "unique" statement in the outer list that insures
that a module/revision
shows up at most once in all instances of the inner module list?
For alt A, each schema represents a single list (so no duplicated
implemented modules are possible).
For alt B, yes, the rule is that there must be no duplicates in the
module-sets that are combined into a single schema.
3) I genuinely think that the list of implemented modules is more
interesting to the client than the imported, but not implemented
modules.
The conformance leaf was good enough.
Duplicating the module list and removing the conformance leaf is
aggressively non-backward compatible.
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.
Seems to me all new solutions allow a server to violate the MUST in
the NMDA draft that
there is a superset of all modules. A client has to look for every
module in a server-specific
set of named schema sets, and then reconcile all these sets.
I still prefer the single module list with a conformance leaf and a
leaf-list indicating
the supported (or unsupported) datastores.
So, this is a trade off between a more expressive model vs a more
constrained model.
It is worth noting that the existing YANG library (RFC 7895) allows
servers to produce illegal module lists because they could implement
multiple revisions of the same module.
Thanks,
Rob
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
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] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netconf
<https://www.ietf.org/mailman/listinfo/netconf>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
