Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03

[Brian E Carpenter <[e-mail]>]

Ralph,

On 09/08/2014 08:19, Ralph Droms wrote:
> On Aug 5, 2014, at 4:11 AM 8/5/14, Pascal Thubert (pthubert) <[e-mail]> wrote:
> 
>> I think I see what you are saying, Phil.
>>
>> I can split 1.3 to isolate the deviations to 6437.
>>
>> I also need to move the following text from section 3 in that new section 
>>
>>  This may seem contradictory with the IPv6
>>   Flow Label Specification [RFC6437] which stipulates that once it is
>>   set, the Flow Label is left unchanged; but the RFC also indicates a
>>   violation to the rule can be accepted for compelling reasons, and
>>   that security is a case justifying such a violation.  This
>>   specification suggests that energy-saving is another compelling
>>   reason for a violation to the aforementioned rule.
>>
>> Proposed update for that text:
>>
>>   This specification updates the IPv6
>>   Flow Label Specification [RFC6437], which stipulates that once it is
>>   set, the Flow Label is left unchanged. [RFC6437] also indicates that 
>>   a violation to the rule can be accepted for compelling reasons, 
>>   but limit those compelling reasons to security related issues.  This
>>   specification indicates that energy-saving is another compelling
>>   reason that justifies a violation to the aforementioned rule.
> 
> Well, I personally don't read the text in RFC 6437 as saying "a violation to the rule can be accepted for compelling reasons".  To avoid arguments with difficult individuals like me, you might take a more neutral approach:
> 
> This document updates the following text from RFC 6437, "IPv6 Flow
> Label Specification":
> 
> OLD:
> 
>    Once set to a non-zero value, the Flow Label is expected to be
>    delivered unchanged to the destination node(s).  A forwarding node
>    MUST either leave a non-zero flow label value unchanged or change it
>    only for compelling operational security reasons as described in
>    Section 6.1.
> 
> NEW:
> 
>    Once set to a non-zero value, the Flow Label is expected to be
>    delivered unchanged to the destination node(s).  A forwarding node
>    MUST either leave a non-zero flow label value unchanged or change
>    it only for (1) compelling operational security reasons as
>    described in Section 6.1 or (2) use as specified in RFC-to-be, "The
>    IPv6 Flow Label within a RPL domain".

I *really* don't think RFCs are algorithms to the point where we
need to do this. I see no reason why flow-label-for-rpl can't simply
declare itself an exception to this clause of RFC 6437.

   Brian