Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis

[Vladimir Vassilev <[e-mail]>]

On 12/13/2017 08:40 AM, Martin Bjorklund wrote:

> Vladimir Vassilev <[e-mail]> wrote:
>> On 12/12/2017 08:20 PM, Martin Bjorklund wrote:
>>
>>> Hi,
>>>
>>> Vladimir Vassilev <[e-mail]> 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 <[e-mail]> 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