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

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 08 August 2014 20:36 UTC

Return-Path: <brian.e.carpenter@gmail.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 5C0751A0109; Fri, 8 Aug 2014 13:36:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 T_5zgP63Jthn; Fri, 8 Aug 2014 13:36:49 -0700 (PDT)
Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A53E41A00D8; Fri, 8 Aug 2014 13:36:49 -0700 (PDT)
Received: by mail-pa0-f44.google.com with SMTP id eu11so7889438pac.31 for <multiple recipients>; Fri, 08 Aug 2014 13:36:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jCX5VXOLf5w1EYCN3Mnngzz3q94BWCN1WAGlc48IhS0=; b=bxiqODlEtd+zxkz8jT68rR43wYDrNkoShv/9RRF7l+PTHjdFQgBl+MIU6KCtrXIRyD Vq6iPgRiGJm+naEjjgxRL3I5gFNL10UIrwwJ/uyBdWiYiO6wDpugbpUXFB8QKCfz0b7b 2h6Wrlf61qbhhH9dD8wl20Uadrhd1qsS2vpm6iSvtZkt2Lbt+SyxK8vFsP3Xa8HAyhUu FTq7kdqZaqPhyVGALQ5Rkh0tTacfWqDoQ57smyM1Bkto7wwpI+0g7WamvWrjPbtD/jsw nnar/fynuN5IOcoiMu0XjQTLK9QXrVfjzecm8Ye/HeR/nQQkpeacsjN1JPmeQVIoKFGl sBAA==
X-Received: by 10.70.89.43 with SMTP id bl11mr3647102pdb.163.1407530209289; Fri, 08 Aug 2014 13:36:49 -0700 (PDT)
Received: from [192.168.178.23] (146.197.69.111.dynamic.snap.net.nz. [111.69.197.146]) by mx.google.com with ESMTPSA id om8sm5709726pdb.58.2014.08.08.13.36.46 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Aug 2014 13:36:48 -0700 (PDT)
Message-ID: <53E534E8.4050304@gmail.com>
Date: Sat, 09 Aug 2014 08:36:56 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Ralph Droms <rdroms.ietf@gmail.com>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com>
In-Reply-To: <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/XewflubZvAJlAwLH21ZFQGV4HH4
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, "ipv6@ietf.org" <ipv6@ietf.org>, Routing Over Low power and Lossy networks <roll@ietf.org>
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, 08 Aug 2014 20:36:51 -0000

Ralph,

On 09/08/2014 08:19, Ralph Droms wrote:
> On Aug 5, 2014, at 4:11 AM 8/5/14, Pascal Thubert (pthubert) <pthubert@cisco.com> 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