Subject: [6tisch] Impact of the lack of RPI compression on draft minimal

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 12 Jan 2015 08:35:15 +0000

Dear ADs and all:

At the interim on Friday (https://bitbucket.org/6tisch/meetings/wiki/150109_webex), we discussed the impact of the lack of RPI compression on the minimal draft, which passed last call at 6TiSCH. Till this is resolved, the chairs need to hold he document.

We asked for advice from our ADs and Brian indicated the following:

"

On 12/19/14 10:01 AM, Pascal Thubert (pthubert) wrote:

> We decided that for completeness of its expression of the RPL

> operation, the draft should provide a pointer on the way the RPL info

> is carried. We need a minimum set of common stuff to interop and the

> way to express the RPL information is one. We can live with any

> default as long as everyone implements it. Now if optionally people

> support additional ways to make comparisons with that reference, that

> would certainly be good, if the question is still open at that time.

> All in all, if you agree, we can progress the draft in IESG review

> leaving that particular reference open to be changed till later in the

> process?

Why would you expect that to be acceptable?  If a piece of the spec is needed for interoperability, it needs to be there during the review.

Why send it to the IESG if there are still questions on how that piece will be done?  If it is left out, how will anyone know if there is consensus on the spec as a whole?

It seems to me that:

1. There have been several proposals put forth

2. Issues have been raised on each one

So, it seems prudent (to me) to look at each of the alternatives and determine which warts everyone concerned is willing to live with.

Running code is a good way to do that.

Making that determination needs to be done before the spec is sent to the IESG
"

The lack of a compression mechanism does not mean, though, that we have an incomplete solution, since we can fallback to shipping with no compression at all.

Michael had the following comment / suggestion:

"
o             Question is: how do we turn compression on if we add compression afterwards. We need to make sure that it is acceptable that nodes running future compression are backward compatible with current approach and in the other way, legacy nodes not accepting new compression would require the overall network to work without compression. we need to make sure this is acceptable.
o             Solution might be to ship now as experimental, collect results from plugtest, finalize the compression work, and ship again in standards track.
"

The consensus at the interim call leaned in favor of that proposal.

So the proposed plan for the minimal support draft would be:

- change the document to indicate no compression of RPL artifacts
- publish as experimental, as base for the interop test in July
- work at 6lo on RPL compression
- depending on progress, suggest optional compression interop test as well
- use the plugtest experience to update to standard track

What do you think?

Pascal