Subject: Re: [core] Call for consensus: Should we switch out the option encoding?

From: Likepeng <[email-masked]>
Date: Mon, 3 Dec 2012 02:25:19 +0000

>Do we as a WG have consensus to make this change at this time?

I support this change.

>Whether you answer yes or no, it would be useful to add a line or so of text indicating what motivates your decision.

It is simpler than the previous design.

Thanks,
Kind Regards
Kepeng 

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Carsten Bormann
发送时间: 2012年11月30日 22:10
收件人: [email-masked] WG
主题: [core] Call for consensus: Should we switch out the option encoding?

On Nov 30, 2012, at 14:48, Klaus Hartke <[email-masked]> wrote:

> <new-format-04.txt>

Thanks, Klaus.  
This version doesn't contain all the editorial fixes that were discussed on the list, but these can be done in parallel to making the decision.

Normally, we do minor technical decisions by having a discussion and then simply putting in the new text into the next revision of a WG draft.
However, this is another breaking change, and although the IETF process does allow us to make breaking changes as much as we want, reality doesn't -- we should only make them if the benefits really justify the cost of changing out all tools (including the WireShark that you probably already have installed even if you don't know it), temporarily partitioning the interop testing world into the laggards and the radicals, making previous pcap files less useful for future tests etc.

Other messages have discussed the quantifiable and not so quantifiable advantages (and disadvantages) of the new proposal.
I think I can already state consensus that the new proposal is simpler, which fits the goals of the WG well.

So my question to the WG is now:  Do we as a WG have consensus to make this change at this time?
Whether you answer yes or no, it would be useful to add a line or so of text indicating what motivates your decision.

In order not to lose time, please send in your replies (with this subject) to this mailing list by

	->  2012-12-05, 23:59 UTC.

This will enable us to announce a decision (and, I hope, get coap-13 published) right on Sinterklaas.

Grüße, Carsten

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

---

From: Likepeng <[email-masked]>
Date: Mon, 3 Dec 2012 02:40:25 +0000

>In transports without a length indication, we could use 0xF0 etc. for a payload size indication later, using the same encoding for the second nibble as for the option length.  0xF as a length nibble then just means "indefinite length", i.e. until the end of the PDU.

I think it is better to use an Option to indicate the payload length, instead of using Klaus encoding method for this. BTW, I am in favor of using Klaus encoding for the options, as I indicated in a separate email. 

Reason is that, payload length is an optional feature, and in most of the cases, it is not necessary to be indicated. If we use encoding method, every implementation needs to support this encoding for the payload, not only for the options. If we use an Option for this, it is optional, and it can be optionally implemented where necessary.

Here was my proposal for the payload-length option:
http://tools.ietf.org/id/draft-li-core-coap-payload-length-option-00.txt

Thanks,
Kind Regards
Kepeng
-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Carsten Bormann
发送时间: 2012年11月25日 14:49
收件人: Klaus Hartke
抄送: [email-masked] WG
主题: Re: [core] CoAP jump mechanism

On Nov 25, 2012, at 01:00, Klaus Hartke <[email-masked]> wrote:

> * More fancy artwork.

I liked the old version (32 bits in a row) better.
(The one-byte-per row format is fine for the option.)

Terminologically, I'd stick with a fixed 4-byte header, which is followed by the Token value, if any.

** Technical comments:

What happened to 8-byte Tokens?
Is that an intentional change?

Do use 0xFF for the payload marker.
(In transports without a length indication, we could use 0xF0 etc. for a payload size indication later, using the same encoding for the second nibble as for the option length.  0xF as a length nibble then just means "indefinite length", i.e. until the end of the PDU.)

"Reserved for future use" does not mean anything with respect to packet processing rules.
-> MUST be sent as 0.  MUST be processed as an encoding error unless received as 0.  
(Again with s/0/15/ later).

Grüße, Carsten

---

From: Floris Van den Abeele <[email-masked]>
Date: Mon, 03 Dec 2012 16:29:25 +0100

+1, because it increases uniformity when encoding 'large' values.

For those eager to update & test their implementations, I've setup a 
publicly reachable test server with v13 available @ 
coap://[2001:6a8:1d80:200::4]. It has been tested versus two other v13 
implementations so far.

Regards,
Floris

---

From: Markus Becker <[email-masked]>
Date: Mon, 3 Dec 2012 16:49:53 +0100

I am in favor of the new encoding.

Motivation:
* Simpler and smaller code size.
* I haven't uploaded coap-12 to TinyOS upstream. And since they are switching 
to git, I have another excuse to wait with the upload for coap-13.

Markus

[..]
> So my question to the WG is now:  Do we as a WG have consensus to make this
> change at this time? Whether you answer yes or no, it would be useful to
> add a line or so of text indicating what motivates your decision.
> 
------------------------------------------------
| Dipl.-Ing. Markus Becker
| Communication Networks
| TZI - Center for Computing Technologies
| University Bremen
| Germany
------------------------------------------------
| web: http://www.comnets.uni-bremen.de/~mab/
| mailto: [email-masked]
| telephone: +49 421 218 62379
| building: NW1 room: N2260
------------------------------------------------

---

From: Jeroen Hoebeke <[email-masked]>
Date: Mon, 3 Dec 2012 17:22:46 +0100

+1 for the new encoding.

Motivation:
- simplicity in design: uniform solution for option delta and option length encoding makes the protocol cleaner and easier to understand
- although a breaking change, the implementation is not hard at all (as experienced last week during the plugtest)

---

From: "Rahman, Akbar" <[email-masked]>
Date: Mon, 3 Dec 2012 11:43:02 -0500

+1 for support of the change to Klaus' new encoding proposal.  

Motivation:
>From a technical standpoint we are in favor even though it will result in some rework of our current implementation.  Klaus' proposal is simpler than the current mechanism which seems unnecessarily complex and prone to error.  

/Akbar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: Friday, November 30, 2012 9:10 AM
To: [email-masked] WG
Subject: [core] Call for consensus: Should we switch out the option encoding?

Thanks, Klaus.  

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 3 Dec 2012 17:51:37 +0100

On Dec 3, 2012, at 16:29, Floris Van den Abeele <[email-masked]> wrote:

> I've setup a publicly reachable test server with v13 available @ coap://[2001:6a8:1d80:200::4]. It has been tested versus two other v13 implementations so far.

Good idea!

Given today's spate of positive responses, http://coap.me (the client) and coap://coap.me (the server) are now on "Klaus encoding", too.

(And they, as we already tested at the plugtest, do interoperate with your implementation:
http://coap.me/crawl/coap://[2001:6a8:1d80:200::4]
.)

Grüße, Carsten

---

From: Szymon Sasin <[email-masked]>
Date: Tue, 04 Dec 2012 13:11:48 +0200

+1

It's simpler and less error prone.

Szymon Sasin
Sensinode

---

From: Zach Shelby <[email-masked]>
Date: Tue, 4 Dec 2012 17:09:01 +0200

> This will enable us to announce a decision (and, I hope, get coap-13 published) right on Sinterklaas.

I support this change as both a document author and an individual participant. This simplifies both reading and implementing the specification, optimizes the most constrained implementations, and reduces the chances for interoperability problems in the future. 

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com @SensinodeIoT
Mobile: +358 40 7796297
Twitter: @zach_shelby
LinkedIn: http://fi.linkedin.com/in/zachshelby
6LoWPAN Book: http://6lowpan.net

---

From: "Pete St. Pierre" <[email-masked]>
Date: Tue, 4 Dec 2012 08:17:18 -0800

+1

As a very early implementer (-05 days), I very much prefer the mechanism being proposed.
...Pete
--
Pete St. Pierre
[email-masked]

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Tue, 4 Dec 2012 19:21:33 +0000

+1 for Klaus-encoding.

And some new data from updating Erbium, here for WinAVR 20100110 4.3.3:

   text    data     bss     dec     hex filename
   7046     140       6    7192    1c18 er-coap-12.o

   text    data     bss     dec     hex filename
   6700     140       6    6846    1abe er-coap-klaus.o

Here the new encoding saves 346 bytes of ROM and round about 25 SLoC.
And I like the beauty of a uniform scheme.

Ciao
Matthias

---

From: Maciej Wasilak <[email-masked]>
Date: Tue, 4 Dec 2012 21:10:44 +0100

+1 (also early implementer) - both code and unit tests are much simpler
with new version.

Best Regards
Maciej

2012/12/4 Kovatsch Matthias <[email-masked]>

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Tue, 4 Dec 2012 20:19:57 +0000

Okay, a small bug disallowing to encode longer lengths allowed for an incredible optimization.
But after fixing this, it is still 262 saved bytes of ROM (just to have correct numbers on the list):

   text    data     bss     dec     hex filename
   6784     140       6    6930    1b12 er-coap-klaus.o

Ciao
Matthias

> From: Kovatsch Matthias
> Sent: Dienstag, 4. Dezember 2012 20:22
> To: [email-masked]
> Subject: RE: [core] Call for consensus: Should we switch out the option
> encoding?
> 
> +1 for Klaus-encoding.
>

---

From: Andrew McGregor <[email-masked]>
Date: Thu, 6 Dec 2012 13:07:07 +1300

The consensus call window has now passed.

We have clear support for making the change, and no disagreement.

Therefore, the chairs request the draft authors to integrate Klaus's proposal and make the necessary changes to the text.

Thanks,

Andrew