Re: [Roll] call for consensus for the RPL RPI / RH3 compression

[Robert Cragie <[e-mail]>]

+1.

It sounds like an interop would be the ideal place to test out the 
various hypotheses on the respective proposals.

Robert

On 19/12/2014 15:14, Brian Haberman wrote:
>
> On 12/19/14 10:01 AM, Pascal Thubert (pthubert) wrote:
>> That's interesting, Brian.
>>
>> 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.
>
> Regards,
> Brian
>
>> Pascal
>>
>>
>>> -----Original Message----- From: Brian Haberman
>>> [mailto:[e-mail]] Sent: vendredi 19 décembre 2014
>>> 14:26 To: Pascal Thubert (pthubert); Routing Over Low power and
>>> Lossy networks Cc: [e-mail];
>>> [e-mail]; [e-mail]; 6lo-
>>> [e-mail] Subject: Re: [Roll] call for consensus for
>>> the RPL RPI / RH3 compression
>>>
>>> Pascal,
>>>
>>> On 12/19/14 6:59 AM, Pascal Thubert (pthubert) wrote:
>>>> The rush Carsten,
>>>>
>>>> is that the document that will be the base for the 6TiSCH interop
>>>> test in Prague is now in last call, and that document refers to
>>>> the NHC draft. The question is what should it refer to, and
>>>> whatever it refers to should be stable and implementable by now.
>>> So, do you view the code for the interop being "set in stone"?  As
>>> Adrian pointed out, the interop could be a way to work out the
>>> tradeoffs of these multiple approaches.  That is, running code
>>> leads to an IETF specification rather than the other way around.
>>>
>>> Regards, Brian
>>>
>>>> Just the first (per your words) is just fine with me.
>>>>
>>>> Cheers,
>>>>
>>>> Pascal
>>>>
>>>>> -----Original Message----- From: Roll
>>>>> [mailto:[e-mail]] On Behalf Of Carsten Bormann
>>>>> Sent: vendredi 19 décembre 2014 09:17 To: Routing Over Low
>>>>> power and Lossy networks Cc: [e-mail];
>>>>> [e-mail]; [e-mail]; 6lo-
>>>>> [e-mail] Subject: Re: [Roll] call for consensus
>>>>> for the RPL RPI / RH3 compression
>>>>>
>>>>> On 17 Dec 2014, at 09:29, Pascal Thubert (pthubert)
>>>>> <[e-mail]> wrote:
>>>>>> Decision in Hawaii was that the NHC draft could not be
>>>>>> accepted as is, since we should compress also the RH3, and
>>>>>> without a clear view of how that would happen, the details of
>>>>>> the NHC compression could not be determined. So the NHC
>>>>>> approach was abandoned
>>>>> That is not at all what I recollect from Hawaii.
>>>>>
>>>>> The current smorgasbord is:
>>>>>
>>>>> — various ways to hijack the flow label (dead) — the 6553-NHC
>>>>> proposal — ideas for a new mesh header
>>>>>
>>>>> I’m not going to beat the dead horse of the flow label hijack.
>>>>>
>>>>> The 6553-NHC proposal mainly needs a decision between the
>>>>> three variants (flip a coin, if need be). If time is of the
>>>>> essence, 6553-NHC is the natural thing to do. We can always do
>>>>> an RFC 6554 NHC compression separately.
>>>>>
>>>>> The MH proposal is forward-looking and probably the right thing
>>>>> for the evolution of 6lo, but probably also not compatible with
>>>>> a tight time schedule.
>>>>>
>>>>> Now, what is the rush? RFC 6553/6554 do exist.
>>>>>
>>>>> So we get to choose between rushing 6553-NHC to completion or
>>>>> using 6553/6554 for now and doing the MH work right (or. more
>>>>> likely than just the first, both). I don’t have an opinion on
>>>>> wether we need to rush 6553-NHC, but if we need to rush
>>>>> anything, this one it is.
>>>>>
>>>>> Grüße, Carsten
>>>>>
>>>>> _______________________________________________ Roll mailing
>>>>> list [e-mail] https://www.ietf.org/mailman/listinfo/roll
>
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll