Subject: [Anima-signaling] Carsten: discuss with anima-signaling ?

From: Toerless Eckert <[email-masked]>
Date: Mon, 20 Jul 2015 08:52:56 -0700

[again with correct address]

Hey Carsten

Would you have some time this week, eg: brakfast or lunch to talk with
me and others interested in this from anima-signaling about the mem/cpu ->
protocol (UDP vs. TCP, bitrate) expectations ? We're trying to vet what
expectations we might want to raise against autonomic devices and looking
at eg: CoAP brings in a lot of simplification but at the expense of exposing more
complexity to the application layer, so we're trying to understand when that level
of design is necessary.

Cheers
    Toerless

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 20 Jul 2015 19:42:23 +0200

> Would you have some time this week, eg: brakfast or lunch to talk with

Hi Toerless,

lunch/dinner all taken, but all four breakfast times are still free.
Unfortunately, I'm not staying at the Hilton.

> complexity to the application layer, so we're trying to understand when that level

Now I'm confused -- you want to use CoAP as well as CBOR?
(A decision that 6Tisch made quite rightly, but I didn't know that that
was on the table for you as well.)

Grüße, Carsten

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 20 Jul 2015 10:59:13 -0700

> Unfortunately, I'm not staying at the Hilton.

NP. How about thursday ?

> was on the table for you as well.)

I don't want apps or our JSON/CBOR signaling having to bother about 
segmentation, so i fear that may mean i don't want CoAP, and independent of
this i think our signaling might be a superset of what the'lightweigt http'
layer in CoAP does. But instead, what is of interest is to understand again
in more detail the possible platform limitations that made it preferential
to use CoAP in specific market segments - so we can vet whether a design
that would eg: include TCP eliminates devices we would care about - or
only those type of devices that would fall off an anima focus already because
of other reasons.

Cheers
   Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Jul 2015 07:18:40 +1200

I can probably manage Thursday breakfast. Or if we all eat breakfast
early, maybe we can simply meet at 8:00? (I do want to go to the
plenary at 9:00.)

I am interested in data size, but also very interested in understanding
how to define a protocol aimed at CBOR-on-the-wire and with JSON-like
convenience for programmers.

    Brian

On 21/07/2015 05:59, Toerless Eckert wrote:
> _______________________________________________
> Anima-signaling mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima-signaling
>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 21 Jul 2015 00:38:52 +0200

> early, maybe we can simply meet at 8:00? (I do want to go to the

I don't get breakfast in my hotel before 07:00, so I might be a couple
minutes late for 08:00.  08:10, maybe?

> convenience for programmers.

OK, what are the sources of this convenience:

			JSON	CBOR
JSON data model		x	x
+ binary		-	x
+ extensibility		-	x
+ 64-bit integers	-	x
Wire format is text	x	-
Good libraries		x	x*)
Easy entry of test data	x	x**)

*) Well, this is still improving.
**) You need a simple tool to convert diagnostic to bytes.

Did I miss anything?

Re the text format issue: wireshark is your friend, and non-trivial JSON
streams are also only really readable with a tool (for pretty-printing)
anyway.

Now, there is a lot to say about the "how"...

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Jul 2015 17:06:53 +1200

> minutes late for 08:00.  08:10, maybe?

Sure, we should have enough time for a good discussion.

> **) You need a simple tool to convert diagnostic to bytes.

Well, I have two idiot questions:

Q1. What do I write in my protocol spec, where today I write
something like:

3.7.7.1.  Locator IPv4 address option

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    OPTION_LOCATOR_IPV4ADDR    |           option-len          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          IPv4-Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Q2. What does a programmer write in her Autonomic Service Agent code,
when she wants to invoke a message including a component like
the above? Assume she's writing in Python, for example.

   Brian

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 21 Jul 2015 09:23:22 +0200

OK, I have booked Thu ~08:10 to 09:00.

> 3.7.7.1.  Locator IPv4 address option

locator-ipv4address-option = [OPTION-LOCATOR-IPV4ADDR, IPv4-Address]

or maybe

locator-ipv4address-option = (
  OPTION_LOCATOR_IPV4ADDR => IPv4-Address
)

depending on the context this is being used in (i.e., do we already have
a map this is being plugged into), and then (not in your picture, so I'm
guessing)

OPTION_LOCATOR_IPV4ADDR = 4711
IPv4-Address = bytes .size 4

> the above? Assume she's writing in Python, for example.

My Python is rusty, but in the mostly equivalent Ruby language**) I
would write something like:

ipv4address = ... *)
send_message(..., {OPTION_LOCATOR_IPV4ADDR: ipv4address})

*) [must be in byte string form already, e.g., as it is coming out of
getaddrinfo/pack_sockaddr_in]
**) Actually, this would be shorter in Ruby, but I'm using here what is
probably available in Python, too.

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Jul 2015 18:41:26 +1200

Fortunately there was a cancellation. I have reserved the sign-up
room from 8:00 to 9:00 Thursday morning.

That is the Budapest room, at the extreme end of the Lobby level,
some distance after the terminal rooms.

We will start as soon as Carsten arrives from his hotel;
please finish breakfast before 8:00.

Regards
   Brian

> OK, I have booked Thu ~08:10 to 09:00.

<snip>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Jul 2015 19:01:31 +1200

Some technical follow-ups below (sorry to show my ignorance).

...
> a map this is being plugged into), and then (not in your picture, so I'm

You will have to explain to me exactly when => applies (that is a CDDL
question really). Apart from that, on the wire "OPTION_LOCATOR_IPV4ADDR"
is a 16 bit constant in the current protocol design. Am I right in thinking
that in CBOR, it would end up on the wire as a CBOR key consisting of
whatever UTF-8 string we happen to choose, "ip4addr" for example?

Then I have a subsidiary design question: in a TLV design, I need an IANA
registry for the type codes. Do I need an IANA registry for the equivalent
CBOR keys?

> getaddrinfo/pack_sockaddr_in]

Right. I am very anxious to avoid human-readable addresses, which is the
only kind JSON can handle reasonably.

> probably available in Python, too.

I'm quite happy with Ruby, which I have actually used, but apparently
Python is the flavour of the month.

Thanks
     Brian