Re: [core] YANG to CBOR mapping version 1

[Michel Veillette <[e-mail]>]

Hi Peter

"Meta data" is defined as "data that provides information about other data"
The identification of  which data nodes are listed in the 'key' YANG statement is information about the data transferred, not the data itself.

So yes, extra meta-date is required if we want to identify the list of key(s) in the encoded payload.

Updating the list of keys is not something typical and if done, I assume  that the interactions between clients and servers change significantly. I still believe that the discovery process is the most appropriate and generic way to address these types of problems.

Regards,


-----Original Message-----
From: peter van der Stok [mailto:[e-mail]] 
Sent: Thursday, July 14, 2016 11:40 AM
To: Michel Veillette <[e-mail]>
Cc: [e-mail]; Core <[e-mail]>
Subject: RE: [core] YANG to CBOR mapping version 1

Hi Michel,


> In this case, you propose to add more meta data than 
> "draft-ietf-netmod-yang-json"
> which don't share the same limitations on the payload size.
> https://tools.ietf.org/html/draft-ietf-netmod-yang-json-10#section-5.4

I don't think extra meta-data is needed (depending on your definition of
meta-data)

> 
> Regards,
> Michel

Greetings,

Peter

> 
> 
> -----Original Message-----
> 
> From: peter van der Stok [mailto:[e-mail]]
> Sent: Thursday, July 14, 2016 3:57 AM
> To: Michel Veillette <[e-mail]>
> Cc: [e-mail]; Core <[e-mail]>
> Subject: RE: [core] YANG to CBOR mapping version 1
> 
> 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)
>>>>       }
>>>>     ]