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

"Adrian Farrel" <adrian@olddog.co.uk> Sun, 04 January 2015 11:59 UTC

Return-Path: <adrian@olddog.co.uk>
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 403891A8710; Sun, 4 Jan 2015 03:59:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.381
X-Spam-Level:
X-Spam-Status: No, score=-98.381 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, THIS_AD=0.819, USER_IN_WHITELIST=-100] 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 9GDJjGHgDWHn; Sun, 4 Jan 2015 03:59:57 -0800 (PST)
Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28B1F1A87E3; Sun, 4 Jan 2015 03:59:56 -0800 (PST)
Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t04BxtC1027462; Sun, 4 Jan 2015 11:59:55 GMT
Received: from 950129200 (089144214152.atnat0023.highway.a1.net [89.144.214.152]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t04Bxq4N027451 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 4 Jan 2015 11:59:53 GMT
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Routing Over Low power and Lossy networks'" <roll@ietf.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> <5C9D8B2D-8779-450A-B558-D35323BA18FE@tzi.org> <12622.1420055894@sandelman.ca>
In-Reply-To: <12622.1420055894@sandelman.ca>
Date: Sun, 4 Jan 2015 11:59:52 -0000
Message-ID: <000701d02815$f43df5f0$dcb9e1d0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQDYSrdREYQBBbqMEJ13pvROSVU0ZwFOrF3lAq5NWmYCDPN/2QIHrEpgAnP0kfoCE4LtBAH8RX/fnirl8mA=
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21222.006
X-TM-AS-Result: No--12.096-10.0-31-10
X-imss-scan-details: No--12.096-10.0-31-10
X-TMASE-MatchedRID: X4bcv0S75KlfsB4HYR80ZuYAh37ZsBDC9Pf8r56P8OiqvcIF1TcLYMNG 97DfmZl73ucgpE8r324LCX72pQ57z7mvMSppeWbN3/BiYwVwlIgJDfFL7Mvp7focnZ1sVcITTeW AzLg7201bizXT95VspZznAshKWsZCD71CZKFRa8Ld+fuf9kcapl3KZkFy4YZEQQ1XgvCe7sG0cU TKeVbLpDw2VCzpS/odKAsRrYCoSQzJQQZfFiWFP2iYls8x2M90fkuZtv/FS5rFJnEpmt9OE5HI/ wLXJM6E94TFEi/V+KrNN/jZbR84GVgD5mh+pVM14nbwqqmOd2kIKlg5gvgW3Lv408/GP5HqV3F3 xxDh6Cu4ZfkBlKsszRBsLigpdrdHnyr1pF6DLcRWeFNzK1vl0n0tCKdnhB581kTfEkyaZdz6C0e Ps7A07SQvY0ueKrc1OQXtnknU6N0rqvWELjUtyykqqCDox+4bXnjHx8W4ea8=
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/jScd9D3Iyy56wOoxWDJLLSF5dXE
Cc: 6man-chairs@tools.ietf.org, int-ads@tools.ietf.org, 6tisch@ietf.org, 6lo-chairs@tools.ietf.org, rtg-ads@tools.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: adrian@olddog.co.uk, 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: Sun, 04 Jan 2015 11:59:59 -0000

Michael,

Thanks for continuing to try to wrangle this situation.

> someone wrote;
>     >> 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.
> 
> Carsten Bormann <cabo@tzi.org> wrote:
>     > 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
> 
> so, I think that we have consensus that this can not be left to the plugfest.

I understand that the plugfest has to have a baseline: you can't arrive at the plugfest with lots of implementations of different things!

On the other hand, I don't think that the WG has to agree what the plugfest will do. I think it is fine for some group of people to make that agreement (by all means point at existing I-Ds or even write a brief I-D or wiki page saying "this is what we will test").

If everyone has energy, the plugfest could even test more than one approach.

> A number of people have not replied; some ADs and some WG chairs.
> (I realize that Gabriel Montenegro is new in this position; maybe he can
> bring a fresh viewpoint?)

Is there a specific question you'd like this AD to answer?

> I am going to put up a doodle poll for the week of Jan. 12.
> My goal is not to need it, that we will have a plan for the Jan 9, 6tisch
> call.

I didn't see anything further on this.

> Please: how do we proceed?

Consensus can sometimes be hard-won and slow. It is one of the things that makes people claim the IETF is slow. On the other hand, the alternative to consensus is, erm, no consensus.

In agreeing consensus, however, we may need to declare minority opinions "in the rough" [RFC7282] if there is a body of opinion that one way of doing things is preferred and if the drawbacks of that approach are clearly recognised and accepted.

I see the plugfest as an important way of reaching consensus on this issue. That is, if the plugfest shows that a particular approach is functional and not harmful it provides a strong case for documenting and standardising the mechanism.

Beyond that it may be most helpful to note the objections to the "preferred" approach and to write text that explains the concerns and how they are mitigated (for example, not sending traffic out of admin domains without applying some magic policy).

Adrian