Subject: [core] COOL SID representation

From: peter van der Stok <[email-masked]>
Date: Wed, 30 Mar 2016 14:40:09 +0200

Hi Michel et al,

I find the current representation of the SID rather confusing, both 
within the examples as the CBOR encoding.
The numeric values serving as YANG identifier are represented as 
differences with respect to a hierarchical higher value.
It would be more clear if the operator aspect was shown in the examples: 
e.g. +15 instead of 15.
  It is not clear to me why the operation is with respect to the parent 
schema node.
Could it not just be the former identifier? Efficiency considerations 
may then indicate a reordering of the nodes, but that is not prohibitive 
for the handling of the contents.

 From the above you may understand that I do not like misusing the 
"integer" type in CBOR to annotate Delta's.
It makes the interpretation of the CBOR types application dependent, and 
I don't think that is a good direction to go.
My recommendation is to develop a new CBOR element to denote the deltas.

Greetings, Peter

---

From: Somaraju Abhinav <[email-masked]>
Date: Wed, 30 Mar 2016 14:06:21 +0000

Hi Peter,
please see comments inline.
Regards,
Abhinav
_______________________________________
Hi Michel et al,

[AS] I am not sure I fully understand where you want +15 instead of 15. Could you please point out a line number in a document where this change might help.

[AS] The problem is here is with repeated deltas - if we use former values to calculate deltas then we might get the same delta more than once when encoding an object. CBOR keys can not be used to identify which element within the object we are referring to unless we impose an order on the elements within the object.

[AS] The content-format cool+cbor, clearly tells any application that the keys are delta encoded. I am not sure there is a need to add to an already published RFC considering any application can use this content-format option to indicate that the keys are delta encoded.

Greetings, Peter

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core
________________________________________________________ The contents of this e-mail and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this e-mail is received in error, please immediately notify the sender and delete the e-mail and attached documents. Please note that neither the sender nor the sender's company accept any responsibility for viruses and it is your responsibility to scan or otherwise check this e-mail and any attachments.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 30 Mar 2016 16:15:24 +0200

> [AS] The problem is here is with repeated deltas - if we use former values to calculate deltas then we might get the same delta more than once when encoding an object. CBOR keys can not be used to…

That is not the only problem: maps are not order-preserving in CBOR (a
property CBOR inherits from JSON).  So "former" may not even be a
meaningful concept within the set of keys in a map.

So far, using the parent as the base for the delta is the best we've
come up with.  It also is very simple to implement, as in a given
context the delta for a specific item is always going to be the same.

Grüße, Carsten

---

From: peter van der Stok <[email-masked]>
Date: Thu, 31 Mar 2016 09:42:54 +0200

Hi all,

Personally, I think it is more evident to write a new I-D that describes 
a new CBOR element with a "difference semantics" than changing the 
meaning of the element type.
I like to point out what the YANG to CBOR specification says about 
element 0:
"Leafs of type uint8, uint16, uint32 and uint64 MUST be encoded using
    a CBOR unsigned integer data item (major type 0)."
and nothing about differences.

> Somaraju Abhinav wrote:
>> [AS] The problem is here is with repeated deltas - if we use former 
>> values to calculate deltas then we might get the same delta more than 
>> once when encoding an object. CBOR keys can not be used to identify 
>> which element within the object we are referring to unless we impose 
>> an order on the elements within the object.
> 

Stating that the media-type puts a meaning to the order of the elements 
in the payload seems more logic to me than changing the meaning of the 
type.

And looking at the example in the cool language I-D I get confused about 
the hierarchy.
I do understand the 1529, which is 1529 + 0, where 0 comes from the 
parent.
But I don't understand the 179; Are the parents of 1529 and 179 
different?

"/system-state/clock" (SID 1708) does not look like a child of 
"/interfaces/interface" (SID 1529) .
Probably I am missing something fundamental.

The examples in the text are nice but an explanation how one gets to the 
numbers in the examples following the rules would be helpful.

Peter

  [
    1529,
      {
       4 : "eth0",             # name (SID 1533)
       1 : "Ethernet adaptor", # description (SID 1530)
       5 : 1179,               # type (SID 1534), identity ethernetCsmacd
       2 : true                # enabled (SID 1531)
      },
    179,                       # clock (SID 1708)
      {
        1 : "2015-02-08T14:10:08Z09:00",  # boot-datetime (SID 1709)
        2 : "2015-04-04T09:32:51Z09:00"   # current-datetime (SID 1710)
      }
    13, 60                     # timezone-utc-offset (SID 1721)
  ]

---

From: Michel Veillette <[email-masked]>
Date: Thu, 31 Mar 2016 11:16:25 +0000

Hi Peter

The semantic of deltas are defined in the context of a YANG container, not in the context unsigned integers (uint8, uint16, uint32 and uint64).
For YANG containers, the YANG to CBOR mapping draft also supports:
- JSON names encoded within the CBOR map as CBOR text string data item (major type 3)
- YANG hashes encoded within the CBOR map as CBOR byte string data item (major type 2)

Since we don`t need deltas in other contexts, I don't see the need for a new I-D.

Regards,
Michel

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of peter van der Stok
Sent: March-31-16 3:43 AM
To: Carsten Bormann <[email-masked]>
Cc: Core <[email-masked]>
Subject: Re: [core] COOL SID representation

Hi all,

Personally, I think it is more evident to write a new I-D that describes a new CBOR element with a "difference semantics" than changing the meaning of the element type.
I like to point out what the YANG to CBOR specification says about element 0:
"Leafs of type uint8, uint16, uint32 and uint64 MUST be encoded using
    a CBOR unsigned integer data item (major type 0)."
and nothing about differences.

> meaningful concept within the set of keys in a map.

Stating that the media-type puts a meaning to the order of the elements in the payload seems more logic to me than changing the meaning of the type.

And looking at the example in the cool language I-D I get confused about the hierarchy.
I do understand the 1529, which is 1529 + 0, where 0 comes from the parent.
But I don't understand the 179; Are the parents of 1529 and 179 different?

"/system-state/clock" (SID 1708) does not look like a child of "/interfaces/interface" (SID 1529) .
Probably I am missing something fundamental.

The examples in the text are nice but an explanation how one gets to the numbers in the examples following the rules would be helpful.

Peter

  [
    1529,
      {