Re: [core] YANG to CBOR mapping version 1

[Michel Veillette <[e-mail]>]

Hi Peter

Validation mechanisms are defined by YANG  ('key', 'unique', 'range', 'pattern', 'length', 'min-elements', 'max-elements', 
'must', 'when', 'if-feature'), not by CoOL or CoMI. 
Any protocol based on YANG need to be able to support those mechanisms.
Adding meta data in the encoding to identity which data nodes are keys don't eliminate de need for clients and servers to have some knowledge of the schema.

The general rule established for "draft-ietf-core-yang-cbor" is simple.
" In order to minimize the size of the encoded data, the proposed
   mapping avoid any unnecessary meta-information beyond those natively
   supported by CBOR."
https://tools.ietf.org/html/draft-ietf-core-yang-cbor-02#section-3

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

Regards,
Michel


-----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)
>>>       }
>>>     ]