Re: [core] YANG list to CBOR mapping

[Michel Veillette <[e-mail]>]

Hi Peter

Have you defined an MergePatch() function similar to RFC 7396 section 2 for your proposed extension?
Do we intent to support two PATCH approaches, RFC 7396 style and draft-ietf-netconf-yang-patch style?
IF so, why list need to be supported by the RFC 7396 style since this approach provide a partial coverage (list without keys and user ordered list is not fully supported) ? Should we address list only in the draft-ietf-netconf-yang-patch style?

Michel Veillette
System Architecture Director
Trilliant Inc.
Tel: [phone] ext. 237


-----Original Message-----
From: peter van der Stok [mailto:[e-mail]] 
Sent: November-23-15 3:58 AM
To: Michel Veillette <[e-mail]>
Subject: RE: [core] YANG list to CBOR mapping

Hi Michel,

the point is to express in the payload the replacement criteria independent of application.
It is a CBOR extension to the patch format of RFC 7396.
The latter allows the replacement of complete arrays, not a subset of the array.

Peter

Michel Veillette schreef op 2015-11-20 21:41:
> Reference: YANG list to CBOR mapping
> https://core-wg.github.io/yang-cbor/#rfc.section.3.1.17
> 
> Hi Peter
> 
> Your proposed solution for lists have some drawbacks and I'll like to 
> understand better its advantages to evaluate the PROS and CONS.
> 
> List of CONS
> - Your proposed solution is not aligned with
> draft-ietf-netmod-yang-json-06
> - Your proposed solution take one extra byte per list entry
> - Your proposed solution use a map as key for a map, which is uncommon 
> (Illegal in JSON but not in CBOR)
> - The encoding of list defined with keys or without keys are done 
> differently
> 
> CoMI-CoOL clients and servers known which data nodes of a list are 
> keys and which ones are associated information.
> I don’t the see value of implementing the keys on the left side of the 
> ':' (key) and the rest of the data nodes on the right side of the ':"
> (value).
> This semantic is already known by both ends, why we need to add it to 
> the encoding?
> 
> === Examples
> 
> Map of map solution with CoMI IDs (88 Bytes)
>   {
>     11111111 : {
>       {22222222 : "book1", 33333333 : "author2"} : {44444444 : 500,
> 55555555: 66} ,
>       {22222222 : "book5", 33333333 : "author3"} : {44444444 : 444,
> 55555555: 11}
>     }
>   }
> 
> Array of map solution with CoMI IDs (86 Bytes)
>   {
>     11111111 : [
>       {
>         22222222 : "book1",
>         33333333 : "author2",
>         44444444 : 500,
>         55555555: 66
>       } ,
>       {
>         22222222 : "book5",
>         33333333 : "author3",
>         44444444 : 444,
>         55555555: 11
>       }
>     ]
>   }
> 
> Map of map solution with CoOL IDs (56 Bytes)
> 
>     {
>       11111111 : {
>         {2 : "book1", 3 : "author2"} : {4 : 500, 5: 66} ,
>         {2 : "book5", 3 : "author3"} : {4 : 444, 5: 11}
>       }
>     }
> 
> Array of map solution with CoOL IDs (54 Bytes)
> 
>     {
>       11111111 : [
>         {
>           2 : "book1",
>           3 : "author2",
>           4 : 500,
>           5: 66
>         } ,
>         {
>           2 : "book5",
>           3 : "author3",
>           4 : 444,
>           5: 11
>         }
>       ]
>     }
> 
> You say "It is the wish to transport only those list elements with a 
> unique key value, either to support a PATCH or a FETCH command".
> I don’t see why this is not the case for both representations.
> 
> Michel Veillette
> System Architecture Director
> Trilliant Inc.
> Tel: [phone] ext. 237
> [e-mail]
> www.trilliantinc.com
> 
> 
> -----Original Message-----
> From: core [mailto:[e-mail]] On Behalf Of peter van der 
> Stok
> Sent: November-19-15 5:06 AM
> To: Core <[e-mail]>
> Cc: [e-mail]
> Subject: [core] YANG list to CBOR mapping
> 
> Hi CoOL authors,
> 
> This e_mail complements my earlier e-mail on YANG to CBOR mapping, and 
> explains the proposed list encoding.
> 
> Both the draft yang-json and the CoOL draft encode a list as an array.
> In the yang-json case as a JSON array, and in the CoOL case as major 
> type 4 of major type 5 objects.
> This encoding prevents the selection of list instances on the basis of 
> the key values from the payload alone. In CoMI the list is encoded as 
> a major type 5 of major type 5 objects. This deviation from the 
> yang-json mapping is motivated by the wish to transport individual 
> list instances and identify the instances in the payload from the key 
> values. This is especially important in case of PATCH operation on 
> list instances.
> Two cases are to be looked at: (1) the list definition specifies one 
> or more key elements, and (2) the list definition does not specify a 
> key element. We will start with a list containing key elements.
> It is the wish to transport only those list elements with a unique key 
> value, either to support a PATCH or a FETCH command. Therefore it is 
> required that the payload allows the selection and identification of 
> these list element on the basis of their key values. Using the 
> diagnostic JSON notation used for CBOR diagnostics, the payload 
> containing a number of elements with key values should look like a 
> JSON object with the structure list-name: {key: value}. Both key and 
> value are composed of JSON objects separated by commas. For example 
> consider the following YANG list specification:
> module foo {
>      namespace http://example.com/book;
>      prefix “fo”;
>      revision  2015-06-07;
> 
>     list B {
>        key “key1 key2”;
>        leaf key1 {type string;}
>        leaf key2 {type string;}
>        leaf coll {type int32;}
>        leaf counter {type int32;}
>     }
> }
> 
> Consider the transport of two instances specified by <“key1” = 
> “book1”, “key2” = “author2”> and by <“key1” = “book5”, “key2” = 
> “author3”> out of a larger set of instances. The representation is 
> different from the yang-json one for the reasons explained above.
> 
> The payload will look like:
> {"B" :{
>      {"key1" : "book1", "key2" : "author2"} :
>      {"coll" : 500, "counter": 66} ,
>      {"key1" : "book5", "key2" : "author3"} :
>      {"coll" : 444, "counter": 11}
>      }
> }
> 
> 
> Which translated to CBOR yields:
> 
> a1                         # map(1)
>     61                      # text(1)
>        42                   # "B"
>     a2                      # map(2)
>        a2                   # map(2)
>           64                # text(4)
>              6b657931       # "key1"
>           65                # text(5)
>              626f6f6b31     # "book1"
>           64                # text(4)
>              6b657932       # "key2"
>           67                # text(7)
>              617574686f7232 # "author2"
>        a2                   # map(2)
>           64                # text(4)
>              636f6c6c       # "coll"
>           19 01f4           # unsigned(500)
>           67                # text(7)
>              636f756e746572 # "counter"
>           18 42             # unsigned(66)
>        a2                   # map(2)
>           64                # text(4)
>              6b657931       # "key1"
>           65                # text(5)
>              626f6f6b35     # "book5"
>           64                # text(4)
>              6b657932       # "key2"
>           67                # text(7)
>              617574686f7233 # "author3"
>        a2                   # map(2)
>           64                # text(4)
>              636f6c6c       # "coll"
>           19 01bc           # unsigned(444)
>           67                # text(7)
>              636f756e746572 # "counter"
>           0b                # unsigned(11)
> 
> The corresponding yang-json draft encoding - that allows transport of 
> a selection of instances- does not specify the key fields and would 
> have looked like:
> 
> {"B" : [
>      {"key1" : "book1",
>        "key2" : "author2”,
>         "coll" : 500,
>         "counter": 66
>       } ,
>      {"key1" : "book5",
>        "key2" : "author3",
>        "coll" : 444,
>        "counter": 11,
>      }
>    ]
> }
> 
> Suppose there are no key elements specified. In that case it is 
> impossible to specify the wanted list elements, and always the whole 
> list must be transported. In the case of a list without key 
> specification is is best to use major type 4 composed of major type 5 
> to transport the list, as is specified in yang-json draft.
> 
> Consider the following YANG list
> 
> Module foo{
>      Namespace http://example.com/book;
>      Prefix “bo”
>      Revision  2015-06-7
> List B {
>     Leaf title {type string;}
>     Leaf author {type string;}
>     Leaf coll {type int32}
>     Leaf counter {type int32}
>     }
> }
> 
> Suppose the list contains two elements. The transport payload of the 
> two elements looks like:
> 
> {"B" :[
>      {"title" : "book1", "author" : "author2", "coll" : 500, "counter":
> 66} ,
>      {"title" : "book5", "author" : "author3",  “coll" : 444,
> "counter":
> 11}
>      ]
> }
> 
> This payload is identical to the yang-json payload.
> Which yields the corresponding CBOR code.
> 
> a1                         # map(1)
>     61                      # text(1)
>        42                   # "B"
>     82                      # array(2)
>        a4                   # map(4)
>           65                # text(5)
>              7469746c65     # "title"
>           65                # text(5)
>              626f6f6b31     # "book1"
>           66                # text(6)
>              617574686f72   # "author"
>           67                # text(7)
>              617574686f7232 # "author2"
>           64                # text(4)
>              636f6c6c       # "coll"
>           19 01f4           # unsigned(500)
>           67                # text(7)
>              636f756e746572 # "counter"
>           18 42             # unsigned(66)
>        a4                   # map(4)
>           65                # text(5)
>              7469746c65     # "title"
>           65                # text(5)
>              626f6f6b35     # "book5"
>           66                # text(6)
>              617574686f72   # "author"
>           67                # text(7)
>              617574686f7233 # "author3"
>           64                # text(4)
>              636f6c6c       # "coll"
>           19 01bc           # unsigned(444)
>           67                # text(7)
>              636f756e746572 # "counter"
>           0b                # unsigned(11)
> 
> 
> --
> Peter van der Stok
> vanderstok consultancy
> mailto: [e-mail]
> 
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core