Subject: [edu-team] Fwd: Re: [Anima] anima/signaling: FYI: CBOR as a generic TLV format

From: Carsten Bormann <[email-masked]>
Date: Mon, 20 Jul 2015 09:43:27 +0200

If there is still space in Yokohama, maybe a CBOR tutorial is in order?

Grüße, Carsten

-------- Original Message --------
Subject: Re: [Anima] anima/signaling: FYI: CBOR as a generic TLV format
Date: Mon, 20 Jul 2015 09:41:31 +0200
From: Carsten Bormann <[email-masked]>
To: Toerless Eckert <[email-masked]>
CC: [email-masked]

Toerless Eckert wrote:
> Carsten/*:
> 
>   If we encode types as strings and IPv4/IPv6 addresses as strings as well,

I'm sorry, I was talking about byte strings, not text strings.

I have two IP addresses right now.  One is:

2001:67c:370:152:fd2d:3b45:57e9:f827

Encoded in CBOR:

50                                  # bytes(16)
   2001067c03700152fd2d3b4557e9f827 # "
\x01\x06|\x03p\x01R\xFD-;EW\xE9\xF8'"

Represented in "diagnostic notation"
(https://tools.ietf.org/html/rfc7049#section-6)

h'2001067c03700152fd2d3b4557e9f827'

The other one is:

31.133.152.125

44          # bytes(4)
   1f85987d # "\x1F\x85\x98}"

h'1f85987d'

(I used http://cbor.me to translate between diagnostic and bytes.)

Similarly, map keys (see the discussion in
https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cddl-06#section-2
for some of the relevant terms here) are best encoded as integers,
unless there is a need for a wide open process of assigning them (then
you'd use text strings, but could still mix in integers for the frequent
ones).

Using CBOR and then using text strings for everything wouldn't use its
full capabilities (you might as well use JSON).  CBOR was designed to
work on constrained nodes (class 1 as per RFC 7228), which typically
have even more stringent size restrictions than the nodes considered in
this WG.

Grüße, Carsten

>   If we can conclude that the devices that would be excluded are anyhow not
>   capable to support the other requirements as raised today against an autonomic
>   node, then i think we are fine with a choice like this.
> 
>   Personally i think this design should fit. "Full" autonomic nodes shouldn't
>   have a problem, i can see them being anything as small as gateways in an IoT
>   scenario, while "constraiend AN nodes" would then be anything arbitrarily smaller,
>   and we could try to design how to expand AN into them separately as a next step,
>   eg: via subsets of what we'd do for full AN nodes and potentially with additional
>   work such as the need to use more efficient encoding - eg: via ASA operating
>   on the AN nodes that act as gateways.
> 
> Cheers
>     Toerless
> 
> On Mon, Jul 20, 2015 at 08:48:33AM +0200, Carsten Bormann wrote:
>> Obviously, many people experienced with CBOR will be in the CoRE meeting
>> at the same time the RTGAREA meeting happens.
>>
>> I'm not sure that we want to go into a "Schema language" rathole, but an
>> ABNF-like data definition language for CBOR is available in the CBOR
>> Data Definition Language (CDDL).
>> https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cddl
>>
>> There are many ways to map information into the extended JSON data model
>> that CBOR uses.  In general, if there is no better way to keep
>> something, use byte strings.  This would apply to IPv4 or IPv6
>> addresses.  Prefixes would be a pair (two-element array) of a prefix
>> length and a byte array for the bits.
>>
>> Certainly, the body of best practices in encoding protocol information
>> in the CBOR data model is still growing.  But apart from us people with
>> gray hair having to learn something new, there is no big obstacle in the
>> way.
>>
>> Grüße, Carsten
>>
>> Toerless Eckert wrote:
>>> In the anima signaling team, we discussed whetherhow to use generic/extensible
>>> encoding like JSOB/CBOR. I mentioned that this is also going to be proposed
>>> by Joe Hildebrand in the "Routing Area Open Meeting" (rtgarea), Tue 15:20 - 17:20
>>> slot, so if you're interested in this subjet, it might be useful to attend
>>> that slot.
>>>
>>> Brians current analysis seems to indicate a good set of open questions against
>>> the approach:
>>>
>>>   -> Schema definition & parsing, for ease of programming. Whats available, best practices
>>>   -> Efficient encoding of important data types, eg: IPv6 addresses ( > 64 bit)
>>>
>>> Cheers
>>>     Toerless
>>>
>>> _______________________________________________
>>> Anima mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/anima
>>>
> 

_______________________________________________
Anima mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/anima

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 20 Jul 2015 21:20:09 +1200

Independently of whether it fits in IETF 94, I think that
"protocol design using object-oriented formats" would be
a great topic, with CBOR as the main topic.

Regards
   Brian

On 20/07/2015 19:43, Carsten Bormann wrote:
> edu-team mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/edu-team
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Jul 2015 01:37:34 +1200

Carsten said yes verbally this morning to a lightning
tutorial on CBOR in Yokohama. (I'm thinking we should aim for
three lightning strikes, maybe 20 min. talk & 10 min. Q/A.)

We need to be sure we have video recording set up for this.

Regards
   Brian