On 12/13/2017 08:40 AM, Martin Bjorklund wrote:
Vladimir Vassilev <[email protected]> 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, 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. 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
This has the same issue as augementing a datastore leaf-list into the
current /modules-state/modules list would have - old clients won't
understand this new node.
IMO it is different. Augmenting the data tree under /modules-state can
potentially compromise the bootstrap resolution of the model context
(depending on whether ignoring the data with unknown namespaces does
change the original model semantics). However I do not see any issue
with the case of the proposed augmentation to yang-library-change
notification. Correctly implemented client needs to read /modules-state
and make sure there are no unsupported modules,features etc. (e.g.
ietf-datastores is supported) before going further (e.g. subscribing to
notifications editing configuration etc.).
/martin
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
