Re: [core] YANG to CBOR mapping version 1

[Michel Veillette <[e-mail]>]

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