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

Carsten Bormann <cabo@tzi.org> Fri, 19 December 2014 21:57 UTC

Return-Path: <cabo@tzi.org>
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 B4F5F1A86F2; Fri, 19 Dec 2014 13:57:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level:
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no
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 nSS5NBbILMbp; Fri, 19 Dec 2014 13:57:08 -0800 (PST)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 044601A1BD2; Fri, 19 Dec 2014 13:57:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id sBJLv0Js000519; Fri, 19 Dec 2014 22:57:00 +0100 (CET)
Received: from [192.168.217.149] (p54890ADC.dip0.t-ipconnect.de [84.137.10.220]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3k43nl5nvgz7xC2; Fri, 19 Dec 2014 22:56:59 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <549440F0.8040407@innovationslab.net>
Date: Fri, 19 Dec 2014 22:56:58 +0100
X-Mao-Original-Outgoing-Id: 440719016.832045-b05aeee497cfb7575977be876d1a58b7
Content-Transfer-Encoding: quoted-printable
Message-Id: <5C9D8B2D-8779-450A-B558-D35323BA18FE@tzi.org>
References: <E045AECD98228444A58C61C200AE1BD848AC2314@xmb-rcd-x01.cisco.com> <184B78CA-953E-45AB-B00C-B3A12CFE4605@tzi.org> <E045AECD98228444A58C61C200AE1BD848AC7D04@xmb-rcd-x01.cisco.com> <54942758.6090705@innovationslab.net> <E045AECD98228444A58C61C200AE1BD848AC86C5@xmb-rcd-x01.cisco.com> <549440F0.8040407@innovationslab.net>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/KKJJ9FuJSZjvzLyMwgIyaSf819g
Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "int-ads@tools.ietf.org" <int-ads@tools.ietf.org>, "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>
Subject: Re: [Roll] call for consensus for the RPL RPI / RH3 compression
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, 19 Dec 2014 21:57:09 -0000

On 19 Dec 2014, at 16:14, Brian Haberman <brian@innovationslab.net> wrote:
> 
> 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.

I agree with Xavi here: This is a good way to gather data for implementation issues (such as the implementation complexity of the “efficient” variant of the NHC approach).  It is not so good for architectural issues (flow label) or housekeeping issues (code point usage of the “greedy” variant; code point re-use in the revised MH proposal).  We should have an agreement on the latter ones before going into a plugfest.

Grüße, Carsten