Re: [v6ops] IPv6 Extension Headers in the Real World

Joe Touch <touch@isi.edu> Mon, 06 October 2014 15:28 UTC

Return-Path: <touch@isi.edu>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5FC1A6FDD for <v6ops@ietfa.amsl.com>; Mon, 6 Oct 2014 08:28:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.686
X-Spam-Level:
X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 bC736j41lFqM for <v6ops@ietfa.amsl.com>; Mon, 6 Oct 2014 08:28:27 -0700 (PDT)
Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C68C41A02DD for <v6ops@ietf.org>; Mon, 6 Oct 2014 08:28:27 -0700 (PDT)
Received: from [192.168.1.8] (pool-71-103-148-36.lsanca.dsl-w.verizon.net [71.103.148.36]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s96FRRdo020969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 6 Oct 2014 08:27:30 -0700 (PDT)
Message-ID: <5432B4E1.1050908@isi.edu>
Date: Mon, 06 Oct 2014 08:27:29 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Tim Chown <tjc@ecs.soton.ac.uk>
References: <542A36AC.9030203@gont.com.ar> <542C81B7.10601@isi.edu> <99A3738D-954C-4A75-8055-E30D0D73DD80@ecs.soton.ac.uk> <EMEW3|fe883999a173b6d6b6b574badb6ebb53q90Niq03tjc|ecs.soton.ac.uk|99A3738D-954C-4A75-8055-E30D0D73DD80@ecs.soton.ac.uk> <542C8595.6080809@isi.edu> <CAKD1Yr2JB6V61D+JcUR2qj6-AGEAQr+Jn0eOUPSLEOKXZ1cEqw@mail.gmail.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DE1C0C7@ITSNT440.iowa.uiowa.edu> <E69F8B2A-C8F9-4978-B2F8-0F6C74619BA0@ecs.soton.ac.uk> <EMEW3|0e9b5822392d744642b47f8f3cb94f76q91ED603tjc|ecs.soton.ac.uk|E69F8B2A-C8F9-4978-B2F8-0F6C74619BA0@ecs.soton.ac.uk> <542D695A.3070506@isi.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DE22159@ITSNT440.iowa.uiowa.edu> <542EAFEF.30607@gont.com.ar> <542EF0BA.2070604@isi.edu> <08B266AA-2C78-4C21-BF76-F4B64C9B56CC@ecs.soton.ac.uk> <EMEW3|fba318d9629281f51901ef8c456d7f83q94E2e03tjc|ecs.soton.ac.uk|08B266AA-2C78-4C21-BF76-F4B64C9B56CC@ecs.soton.ac.uk>
In-Reply-To: <EMEW3|fba318d9629281f51901ef8c456d7f83q94E2e03tjc|ecs.soton.ac.uk|08B266AA-2C78-4C21-BF76-F4B64C9B56CC@ecs.soton.ac.uk>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/QdEFK0HfnRRYvrmYEFpMbzVZLN0
Cc: IPv6 Operations <v6ops@ietf.org>, Fernando Gont <fernando@gont.com.ar>, "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" <draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org>, V6ops Chairs <v6ops-chairs@tools.ietf.org>
Subject: Re: [v6ops] IPv6 Extension Headers in the Real World
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Oct 2014 15:28:29 -0000


On 10/5/2014 6:01 AM, Tim Chown wrote:
> On 3 Oct 2014, at 19:53, Joe Touch <touch@isi.edu> wrote:
...
>> Ultimately, we need an Internet whose behavior is coherent, not based on
>> potentially interfering communities perceived as being orthogonal.
> 
> Perhaps better to say communities with different perspectives. But your choice language makes a point.
> 
> RFC7045 is good in my view, but is not yet where we are at. 

Which raises an additional point. The ink on that is barely dry. What
changed that warrants looking at this again so soon? BOTH docs ought to
address that (this doc mentions that RFC only in passing in the intro,

...
> But the point remains, documenting the observations/problem
> independently allows discussion in those other communities - vendors,
> operators and protocol designers - without trying to pre-empt that in a
> single document. I’m not saying there’s a right or a wrong way, but I
> think it’s better to be able to take stock from a clean problem
> statement/set of observations, than try to do everything in one go.

That ship sailed with RFC7045.

Right now, we're not talking about a hypothetical sequence of docs.
We're talking about operational recommendations that have already been
offered as a WG doc in OPSEC a few weeks ago this AND now this doc in V6OPS.

> It’s a shame the IETF91 BoF cutoff just went by - a non WG-forming
> BoF might have been a good way to tease these issues out.

The only people who really need to be at that meeting right now are the
ADs and chairs of OPSEC and V6OPS.

Although I appreciate that everyone thinks that "this can be
coordinated", we're seeing ample evidence to the contrary. It's useful
to note here that NEITHER DOC REFERENCES THE OTHER, despite being
written by the same author (which begs the question of "end run").

If this is left to the WGs, then the WGs need to decide if they can
manage each of these documents in the isolation the context that already
has been allowed to exist and is already promoted by the author - or if
that can *only* happen in a single doc.

Joe