Re: [core] YANG to CBOR mapping version 1

[peter van der Stok <[e-mail]>]

Hi Michel,

IMO, an error is an error and should be treated as such. Trying to 
salvage unhealthy situations leads to worse problems.

My approach would be that servers and clients are simple and don't need 
to parse the yang modules during operation; and keep extensive state 
information about each other.

The discussion seems to confirm my growing conviction that the CoMI and 
CoOL approaches are fundamentally different.

Peter

Michel Veillette schreef op 2016-07-13 19:06:
> Hi Peter
> 
> I'm not convinced that Including in the encoding which data nodes are
> the keys completely solve the issue.
> If the client transmit a payload with one key and the server required
> two keys, the payload will be rejected.
> If the client transmit a payload with two keys (marked as such) and
> the server require one key, the payload will be rejected.
> To work, both sides need to known the number of keys used by the other
> side and only 'ietf-cool-library' can resolve that.
> 
> Also, not making which data nodes are keys might help during the 
> migration.
> 
> Regards,
> Michel
> 
> -----Original Message-----
> From: peter van der Stok [mailto:[e-mail]]
> Sent: Wednesday, July 13, 2016 12:55 PM
> To: Michel Veillette <[e-mail]>
> Cc: [e-mail]; Core <[e-mail]>
> Subject: RE: [core] YANG to CBOR mapping version 1
> 
> Hi Michel,
> 
> That looks pretty complex to me; while the keys can be elegantly
> expressed in the CBOR contents.
> 
> Peter
> 
> Michel Veillette schreef op 2016-07-13 16:36:
>> Hi Peter
>> 
>> The scenario you described is part of the generic discovery problem.
>> To perform its tasks, clients typically need to known the list of
>> modules, features, deviations implemented by a server and associated
>> versions.
>> This problem is addressed in
>> http://core-wg.github.io/yang-cbor/draft-veillette-core-cool-library-l
>> atest.html
>> which is the constrained version of
>> https://datatracker.ietf.org/doc/rfc7895/
>> 
>> module: ietf-cool-library
>>    +--ro modules-state
>>       +--ro module-set-id    union
>>       +--ro module* [sid revision]
>>          +--ro sid                 sid
>>          +--ro revision            revision
>>          +--ro feature*            sid
>>          +--ro deviation* [sid revision]
>>          |  +--ro sid         sid
>>          |  +--ro revision    revision
>>          +--ro conformance-type    enumeration
>>          +--ro submodules
>>             +--ro submodule* [sid revision]
>>                +--ro sid         sid
>>                +--ro revision    revision
>> notifications:
>>    +---n yang-library-change
>>       +--ro module-set-id    -> /modules-state/module-set-id
>> 
>> Regards
>> Michel
>> 
>> -----Original Message-----
>> From: peter van der Stok [mailto:[e-mail]]
>> Sent: Wednesday, July 13, 2016 2:34 AM
>> To: Michel Veillette <[e-mail]>
>> Cc: [e-mail]; Core <[e-mail]>
>> Subject: RE: [core] YANG to CBOR mapping version 1
>> 
>> Hi Michel,
>> 
>> When a specification changes it set of of keys, I don't think the SIDs
>> will change.
>> It is for sure that the hashes are not affected by the attribution of
>> a key.
>> 
>> Therefore, what happens when client and server use different keys in
>> otherwise identical list specification?
>> 
>> Peter
>> 
>> Michel Veillette schreef op 2016-07-12 17:07:
>>> Hi Peter
>>> 
>>> The validations performed by the entity which de-serialize the CBOR
>>> payload is based on the YANG schema.
>>> This validation is based on all king of YANG statements such as:
>>> key, unique, range, pattern, length, min-elements, max-elements,
>>> must, when, if-feature
>>> 
>>> The identification of which data nodes are keys is considered
>>> unnecessary meta-data since available in the schema.
>>> Even more heavy weight representations such as xml and json don't
>>> include this meta-data in the encode payload.
>>> 
>>> Regards,
>>> Michel
>>> 
>>> -----Original Message-----
>>> From: peter van der Stok [mailto:[e-mail]]
>>> Sent: Tuesday, July 12, 2016 6:08 AM
>>> To: Michel Veillette <[e-mail]>
>>> Cc: [e-mail]; Core <[e-mail]>
>>> Subject: RE: [core] YANG to CBOR mapping version 1
>>> 
>>> Hi Michel,
>>> 
>>>> 
>>>> However, I am missing how to transport a given list instance with
>>>> its key values in the CBOR encoding. Section 4.4 describes the
>>>> encoding of a complete list not a subset of its instances.
>>>> 
>>>> [MV] A list instance is a collection which is described in section
>>>> 4.2.
>>>> ____________________________________________________________________
>>>> _
>>>> _
>>>> _______________________
>>> 
>>> With the current text I don't see how you distinguish instances with
>>> the same key from instances with different keys.
>>> 
>>> Example:
>>> 
>>> list server {
>>>       key name;
>>> 
>>>       leaf name {
>>>         type string;
>>>       }
>>>       leaf iburst {
>>>         type boolean;
>>>         default false;
>>>     }
>>> 
>>> How to distinguish that in the list below that two instances are
>>> identical (should not occur)
>>>     [
>>>       {
>>>         1755 : "NRC TIC server",          # name (SID 1755)
>>>         1754 : false,                     # iburst (SID 1754)
>>>       },
>>>       {
>>>         1755 : "NRC TIC server",          # name (SID 1755)
>>>         1754 : true,                     # iburst (SID 1754)
>>>       }
>>>     ]
>>> 
>>> And the following two instances are different  (valid array)
>>> 
>>>     [
>>>       {
>>>         1755 : "NRC TAC server",          # name (SID 1755)
>>>         1754 : true,                      # iburst (SID 1754)
>>>       },
>>>       {
>>>         1755 : "NRC TIC server",          # name (SID 1755)
>>>         1754 : true,                     # iburst (SID 1754)
>>>       }
>>>     ]