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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 01 August 2014 20:27 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3BB1B28B3; Fri, 1 Aug 2014 13:27:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.502
X-Spam-Level:
X-Spam-Status: No, score=-16.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7JjwIfE-vrn; Fri, 1 Aug 2014 13:27:42 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2290B1A0137; Fri, 1 Aug 2014 13:27:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3995; q=dns/txt; s=iport; t=1406924862; x=1408134462; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lk8u0FO2bB5hKVS6eu4FnolzVYn48Q5NItL1v2QSvcI=; b=XEhdVBsZ60U0bJR+R/MT8F8Fxai4Zg6301vORpnqr7oCjIhmTxYq58Vh u3DhW0dfxAhzZ57OblN6Yj3JEgJz6c6b4bRx06HbExs0DpSyITGoGeaaV 5usBtbLsjwjsrhiTEw8LfrXA9ija1JckK4zG2SoBL8b9DYKw66VE3IQXv s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhwFALT321OtJV2U/2dsb2JhbABPDA6Cf4Ep02EBgQsWd4QDAQEBAwEdSgUNBQsCAQgOCi4yJQIEDgWIOgjIZxeOZAEBGBszB4MvgRwFhH0ChU+RLJRagwdCbA
X-IronPort-AV: E=Sophos;i="5.01,782,1400025600"; d="scan'208";a="344523903"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-3.cisco.com with ESMTP; 01 Aug 2014 20:27:41 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s71KRfgG028932 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Aug 2014 20:27:41 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.37]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Fri, 1 Aug 2014 15:27:41 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Philip Levis <pal@cs.stanford.edu>
Thread-Topic: WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Index: AQHPrai33Dn9icet106HlaTIaH7gh5u8MoZe
Date: Fri, 01 Aug 2014 20:27:40 +0000
Message-ID: <C17BE08C-E179-472D-A349-B6CB8ADDCDF5@cisco.com>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D04850@xmb-rcd-x01.cisco.com>, <09EC423F-FC09-495D-9B48-0DABFA4C19F6@cs.stanford.edu>
In-Reply-To: <09EC423F-FC09-495D-9B48-0DABFA4C19F6@cs.stanford.edu>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/HHFwTlLbkrFSVPLbr1dh9PSqxTU
X-Mailman-Approved-At: Fri, 01 Aug 2014 13:30:23 -0700
Cc: Brian Haberman <brian@innovationslab.net>, "ipv6@ietf.org" <ipv6@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>, roll <roll@ietf.org>, Ines Robles <mariainesrobles@googlemail.com>, Bob Hinden <bob.hinden@gmail.com>, "Ole Troan (otroan)" <otroan@cisco.com>, Pat Kinney <pat.kinney@KINNEYCONSULTINGLLC.COM>, Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Aug 2014 20:27:44 -0000

Phil,

Though I attended the discussions and have a clear reading of this work I'll certainly defer to Brian on whether there is a violation or not. 

OTOH you need to understand that there is no need for a bis to update a MUST in an RFC. We recognize the imperfection in our work and are always ready to revise and amend after due consideration.

This process takes is another RFC and best judgement from the original group that the new text is indeed valuable and not breaking the original objectives.

We are going through that process.

Pascal

> Le 1 août 2014 à 18:50, "Philip Levis" <pal@cs.stanford.edu> a écrit :
> 
>> On Aug 1, 2014, at 5:44 AM, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
>> 
>> 
>> FYI, it will break nothing since there is no assumption in the Internet that the flow label will be carried unchanged. Consistently, there is no native way to secure the flow label to make sure it was not tempered with (IOW it is not protected by ULP checksums, IPSec AH or ESP transport mode). 
>> 
>> The last call at 6MAN is where I expect problems with the use of the flow label field in this draft to be pointed at. I'm happy to report that there was no trace of bigotry there, all the contrary. 6MAN will confirm whether this draft conforms the spirit of the existing RFCs and so far I gathered, from all but you, that it does
> 
> Pascal, I don't think this is a question of spirit or anything. I mean, I'll repeat, 6437 states
> 
> "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."
> 
> If the point is that experience and use and the spirit of the flow label has changed from this MUST, then we should explicitly state so. I'm not arguing that the above prescription is right; but it's what's written. What worries me is the idea of directly contradicting the text of a prior RFC (the one explicitly on flow labels, no less), without correspondingly obsoleting that RFC. This isn't a SHOULD. It's a MUST!
> 
> I've always thought that using the flow label in this way within an LLN is a good idea. The problem is that you can't do so without violating a MUST in the RFC that specifies how flow labels are used. It sounds like the letter of that document doesn't match the spirit of it -- so let's fix the letter, so it says what was intended! Why is there such recalcitrance to do so? Or provide any quantitative basis for the claims of battery power? You've been proposing this for nearly 4 years now...
> 
> I personally see two reasonable ways forward:
> 
> 1) (As Carsten mentioned) Update 6437 to embrace these new and valuable uses of the flow label.
> 
> 2) Provide evidence that using the flow label in this way would provide significant enough gains that violating a MUST in the RFC specifying the flow label is worth it.
> 
> It seems like you're advocating a third:
> 
> 3) Violate a MUST in the RFC specifying how the flow label is used without any evidence that the actual energy savings are significant.
> 
> As for what I'm trying to achieve, that's pretty simple. I think it's a terrible mistake for a standards body as important as the IETF to rely on the spirit of the standard rather than the letter of the standard, especially when they contradict. If you are one of the hundreds of thousands of network engineers and software developers who work in the Internet, you can't know that a bunch of people in a meeting decided that the spirit of a specification differs from its text. All you have to go on is the text. When the founder of the next YouTube or Instagram or Google or Nicira takes my class and I ask them to write their code to follow an RFC (which I currently do), what should I tell them MUST means?
> 
> Phil