Subject: Re: [Anima-signaling] Carsten: discuss with anima-signaling ? - tech follow-up

From: Carsten Bormann <[email-masked]>
Date: Thu, 13 Aug 2015 21:29:13 +0200

I have had a look at draft-ietf-anima-grasp-00A.txt and tried to
translate the TLV specs into a possible form of CDDL, see attached.
I didn't try to capture the message types, just the option types.
I used arrays, not maps; see the comments in the cddl file.

If you have installed the CDDL tool*), you can generate example CBOR
instances in diagnostic notation using

	cddl grasp.cddl g

or, if you want 10:

        cddl grasp.cddl g 10

Obviously, the content will be random (and the spec doesn't have
regexpes for fqdns or urls), but it should still give you an idea of a
possible shape of messages based on concise binary object representation.

Here is an impression:

[36062, 11941481, [372], [375, 4041104963]]
[46648, 13137306, [157, 3878789135, 7, 49, "labioglossolaryngeal"],
[376, h'706f6c796779726961'], [374], [153, 175756680, 7, 243, "lightwort"]]
[44443, 14011759, [375, 525587739], [374]]
[30311, 1926360, [374]]
[39195, 5325149, [376, h'6e6f6e636f6e64756374696f6e']]
[51346, 16187405]
[15159, 14105582, [36112, 7, 20, "antarchism"], [372, [3774,
"satisfactive"]], [18299, 7, 237, "evolutionary"]]
[52775, 10477131, [375, 3347559038], [15306, 7, 24, "extravillar"],
[372, h'0924f926', [3774, "postmedia"], h'910acefe', [3773,
"heraldic"]], [13037, 7, 57, "xeromata"]]
[6617, 16599049, [372, [3774, "propessimist"], h'05967f1a'], [376,
h'70657270657475616c6c79'], [376, h'747269656c616964696e'], [376,
h'72696767697368']]
[7440, 2693210, [376, h'7265677572676974616e74'], [374]]

Use the diag2pretty.rb tool that comes with the cddl tool (or use
cbor.me) to translate

[6617, 16599049, [372, [3774, "propessimist"], h'05967f1a'], [376,
h'70657270657475616c6c79'], [376, h'747269656c616964696e'], [376,
h'72696767697368']]

into the binary

86                                   # array(6)
   19 19d9                           # unsigned(6617)
   1a 00fd4809                       # unsigned(16599049)
   83                                # array(3)
      19 0174                        # unsigned(372)
      82                             # array(2)
         19 0ebe                     # unsigned(3774)
         6c                          # text(12)
            70726f70657373696d697374 # "propessimist"
      44                             # bytes(4)
         05967f1a                    # "\x05\x96\x7F\x1A"
   82                                # array(2)
      19 0178                        # unsigned(376)
      4b                             # bytes(11)
         70657270657475616c6c79      # "perpetually"
   82                                # array(2)
      19 0178                        # unsigned(376)
      4a                             # bytes(10)
         747269656c616964696e        # "trielaidin"
   82                                # array(2)
      19 0178                        # unsigned(376)
      47                             # bytes(7)
         72696767697368              # "riggish"

Grüße, Carsten

*)
https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cddl-06#appendix-F

PS.: (ceterum censeo: The word "object-oriented" actually means
something different than what is meant in by its use in section 3.2.)

PPS.: I'll refrain from comments on the rather worrying impression the
draft gives on its security model.  That is for a separate discussion...

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Aug 2015 10:55:23 +1200

Thanks very much, this is immensely helpful. We'll post a WG -00 draft
shortly which is the TLV version, and then we should tackle the CBOR
question straight after that. Assuming we proceed in that direction, you
would presumably become a co-author.

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Aug 2015 14:34:16 +1200

Hi Carsten,

To my amazement I succeeded in installing Ruby and CDDL on my Windows
box. (I had a go at using our departmental Linux server but it is
ignorant of gems, and I had a go at installing Ruby on Cygwin but
that proved to be a nightmare.) So I can play with the CDDL tools
now while I analyse your workk.

You mentioned:

> I'll refrain from comments on the rather worrying impression the
> draft gives on its security model.

You need context on the security bootstrap discussion and the
secure autonomic control plane. I do expect that we will revisit
GRASP seurity when those are settled.

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 22 Aug 2015 16:04:45 +1200

So, I have played with the very nice CDDL-and-friends tool kit,
using an unholy blend of Windows and Cygwin to check that I can
follow the path from CDDL spec to CBOR instance (in diagnostic
notation) to CBOR binary to a hex dump.

If I have this right, the extra cost of using a map like
{time: option-waiting-time} is 6 bytes (including 4 bytes for
the string "time").

I will play a bit with Carsten's CDDL file to add the message
types etc. After that I should be able to make a fairly
accurate estimate of the change in message size that we would
see by changing to a CBOR-defined format. I will be on travel
some of next week so it may take a little longer.

Regards
   Brian

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 22 Aug 2015 08:24:35 +0200

> notation) to CBOR binary to a hex dump.

Thanks for the flowers.

> {time: option-waiting-time} is 6 bytes (including 4 bytes for

Using text strings for map keys is one way of doing things (this is the
most JSON-like way).

In efforts such as COSE, we are using small integers for map keys that
are very likely to occur; this is closer to how we have done TLVs
traditionally.  Text strings are still useful as an alternative that has
better extensibility.  CBOR has no problem with using both small
integers and text strings as keys within one map. So we use:

   label = int / tstr

and constructions such as

   COSE_Key = {
       key_kty => tstr / int,
       ? key_ops => [+ (tstr / int) ],
       ? key_alg => tstr / int,
       ? key_kid => bstr,
       * label => values
   }

(where the last entry is the wildcard for extensibility).

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Sun, 23 Aug 2015 20:43:33 -0400

> integers and text strings as keys within one map. So we use:

That we can mix-match them, such as can have a traditional IANA registry of
small integer map keys, along with space for new things, is a major win
in my mind.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 24 Aug 2015 13:37:07 +1200

> small integer map keys, along with space for new things, is a major win

There's still a question whether they'd need to be IANA-registered just to
avoid clashes. Thinking outside the box, maybe they should be FCFS and
self-registered, to avoid busy-work for IANA. But using small integers
for the core components of GRASP and text strings for the user-defined
Objective Options does seem attractive.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 24 Aug 2015 17:10:54 +1200

Hi,

I have played around with Carsten's CDDL. Attached is, I believe, a complete
definition of GRASP in CDDL, and the CDDL tool seems happy with it and generates
dummy CBOR output (in diagnostic form). Please everybody review this.
I took a few decisions (some comments are in the file) but it was really fun
and very quick to do. Feedback needed, please.

I decided that Objectives should have names (tstr in CDDL notation) rather
than numbers. I assume that that is OK for the receiver since the CBOR
tag (major type) will be different. But Carsten, can you explain how
this will be hooked into an implementation by a CBOR encoder/decoder?

There's one discrepancy from the current GRASP draft. The draft allows a
discovery message to contain "one or more synchronization options".
I have limited it to one in the CDDL. I don't quite know why we said
"one or more" but it is a significant complication.

Regards
   Brian

P.S. Do not try the following fragment of CDDL at home: thing = [string, 1234]
Or even just: thing = string

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 24 Aug 2015 07:45:06 +0200

Hi Brian,

This looks good on first sight; I'll look closer later.

To your question:

> this will be hooked into an implementation by a CBOR encoder/decoder?

(The term "tag" means something different in CBOR.  Replacing by
"header' while reading the above.)

There are different implementations.  Some just convert the whole input
into a representation of the data model.  For some languages, this can
mostly be the natural representation in the language, for other
languages, a set of appropriate types are defined by the CBOR
implementation.  Alternatively, the decoder converts the input into a
sequence of events such as the start and and end of a map or array or
the occurrence of a text string.

In all these cases, a number typically*) looks different from a text
string.  A map (such as {PEN: pen}) also looks different again.  So a
GRASP implementation on top of the decoder will see whether there is a
generic-obj or a vendor-obj.

On the encoder side, the situation is the same, so a GRASP
implementation gets to choose whether to construct a generic-obj or a
vendor-obj.

By the way, the first element of the array that represents an option can
now be an integer (for the non-objective options), a text string (for
the objective options), or a {PEN: pen} map; in the third case, that is
not the whole identification of the option kind.

A small simplification might be to use

vendor-obj = [[pen, objective-name], objective-flags, loop-count, any]

so in the third case the first element also becomes the whole option
kind identifier and not just gives the PEN (followed by the
objective-name later).

> Or even just: thing = string

The error message could be improved :-), but the reason is that "string"
is not a defined type in the prelude -- we have "text" and "bytes",
which are both "strings", so using that name for either would be a
recipe for mistake.

Grüße, Carsten

*) Some JavaScript implementations use JavaScript "objects" for maps,
which only provide text string map keys.  The CBOR decoder then converts
anything else in the map key position to a string.  Obviously, this
approach is not able to run the full gamut of CBOR types.  You don't
have to, but if you want to cater for this anyway, just don't allow
numeric objective names or braces in objective names.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 24 Aug 2015 10:48:44 -0400

> self-registered, to avoid busy-work for IANA. But using small integers

FCFS is just a specific IANA Considerations policy; just the simplest there is.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 25 Aug 2015 07:53:48 +1200

> FCFS is just a specific IANA Considerations policy; just the simplest there is.

Yes. Self-registered would actually be a new type of policy. It's even been implemented
for IPv6 ULA prefixes at https://www.sixxs.net/tools/grh/ula/.

    Brian