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

[Vladimir Vassilev <[e-mail]>]

On 12/13/2017 08:19 AM, Vladimir Vassilev 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,
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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod