Hi, Vladimir Vassilev <vladi...@transpacket.com> 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 <vladi...@transpacket.com> 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. 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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
