On 12/13/2017 08:19 AM, Vladimir Vassilev wrote:
On 12/12/2017 08:20 PM, Martin Bjorklund wrote:
Hi,
Vladimir Vassilev <[email protected]> wrote:
On 12/08/2017 04:06 PM, Juergen Schoenwaelder wrote:
On Fri, Dec 08, 2017 at 04:03:06PM +0100, Martin Bjorklund wrote:
Vladimir Vassilev <[email protected]> wrote:
On 11/15/2017 06:29 PM, Robert Wilton wrote:
I don't think that this is really a good idea. You would end up
returning server metadata in addition to the configuration.
Obviously RFC 7895 defines only config false; data and I was not
proposing a change to that. But I agree something has to be added to
complete the solution. Special purpose datastore identities can be
defined that return instance of yang-library data when read with
<get-data>. (Datastores with yang-library config false; only data
not
represented in 'operational')
Adding this special yang-library-datastore to the proposed
ietf-datastores container e.g.
module: ietf-datastores
+--ro datastores
| +--ro datastore* [name]
| +--ro name identityref
| +--ro yang-library-datastore identityref
I don't understand this proposal. How would a client learn the
library for <running>? For <operational>?
My interpretation is that the client reads the datastores list from
<operational> and the list entries give you the identity of a separate
datastore that gives you the content of the yang library for that
datastore. (For each datastore, you have a separate datastore to
report its yang library.)
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>.
Ah, ok. This is a clever solution, but quite complicated. It
requires several round trips for a client to learn all library
instances. Also, w/o any changes, it is not clear which module-set-id
is sent in the capability,
The module-set-id sent in capabilities has to be the one for operational
since the client needs to get started by reading /datastores-state.
and a client must query all module-set-ids
in all (meta)datastores in order to just check if it has the latest
version or not.
Adding a /datastores-state/datastore/module-set-id leaf in operational
can resolve this problem.
At the current point I think all issues raised are addressed with the
following model (notice the added anydata option which can replace the
use of yang-library-datastore and if implemented as an alternative can
make retrieval as a single tree):
module: ietf-datastores
+--ro datastores-state
+--ro datastore* [name]
+--ro module-set-id string
+--ro (model)?
+--:(same-as-operational)
+--:(constrained-to-operational)
| +--ro not-implemented* [name revision]
| +--ro name -> /yanglib:module-state/module/name
| +--ro revision -> /yanglib:module-state/module/revision
+--:(unconstrained-datastore-instance)
| +--ro yang-library-datastore identityref
+--:(unconstrained-anydata)
+--ro yang-library? <anydata>
augment /yanglib:yang-library-change:
+---- datastore? identityref
Vladimir
It is also not clear how the existing notification
"yang-library-change" would work when there are multiple instances
involved.
How about this?
module: ietf-datastores
...
augment /yanglib:yang-library-change:
+---- datastore? identityref
Vladimir
So I don't think that this solution will actually work w/o
an update to 7895 - but not updating 7895 was the whole reason for
doing this.
/martin
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
