Subject: [6lo] Summary of RPL artifact compression

From: Robert Cragie <[email-masked]>
Date: Wed, 22 Apr 2015 11:26:28 +0100

I have tried to summarise where I think we are on this topic and have put
in in the Wiki:

http://trac.tools.ietf.org/wg/6lo/trac/wiki/RplArtifactsCompressionApproaches

Comments/modifications/additions welcome. I think you need a tools.ietf.org
login to actually edit the page but I am happy to update it as required.

Robert

---

From: James Woodyatt <[email-masked]>
Date: Wed, 22 Apr 2015 11:20:01 -0700

Everyone—

I've added what I believe to be the arguments against each of the two major
proposals.

NB: I was forced to use my personal email address to create an account on
tools.ietf.org because my employer provided address was rejected by the
authorization enrollment service.

On Wed, Apr 22, 2015 at 3:26 AM, Robert Cragie <[email-masked]>
wrote:

> Comments/modifications/additions welcome. I think you need a
> tools.ietf.org login to actually edit the page but I am happy to update
> it as required.
>
> Robert
>
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo
>
>

-- 
james woodyatt <[email-masked]>
Nest Labs, Communications Engineering

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 22 Apr 2015 20:42:52 +0200

James Woodyatt wrote:
> I've added what I believe to be the arguments against each of the two
> major proposals.

Thanks.

I'm pretty sure we should be very specific in what next-header values we
allow for 6lorh -- my opinion is that we should allow them in front of
IP_HC and FRAG1 only (not even IPv6 uncompressed).  (In any reasonably
efficient way to encode 6lorh that would probably already be an
automatic result of the next-header coding used.)

Grüße, Carsten