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

Joe Touch <touch@isi.edu> Thu, 02 October 2014 15:04 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 ADA3A1A6FB3 for <v6ops@ietfa.amsl.com>; Thu, 2 Oct 2014 08:04:58 -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 pMgagZfm4keF for <v6ops@ietfa.amsl.com>; Thu, 2 Oct 2014 08:04:56 -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 A6D1A1A8549 for <v6ops@ietf.org>; Thu, 2 Oct 2014 08:04:56 -0700 (PDT)
Received: from [192.168.1.10] (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 s92F3r4i005825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 2 Oct 2014 08:03:56 -0700 (PDT)
Message-ID: <542D695A.3070506@isi.edu>
Date: Thu, 02 Oct 2014 08:03:54 -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>, "Metzler, Dan J" <dan-metzler@uiowa.edu>
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>
In-Reply-To: <EMEW3|0e9b5822392d744642b47f8f3cb94f76q91ED603tjc|ecs.soton.ac.uk|E69F8B2A-C8F9-4978-B2F8-0F6C74619BA0@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/YE-gSmxmMEfjBGp-wJgh8j41weo
Cc: "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" <draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org>, IPv6 Operations <v6ops@ietf.org>, V6ops Chairs <v6ops-chairs@tools.ietf.org>, Fernando Gont <fernando@gont.com.ar>
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: Thu, 02 Oct 2014 15:04:58 -0000

You all might consider that "what to do about it" is already being
proposed as a WG doc in OPSEC.

So I disagree with the entire logic of the idea of sequential
publication in this case. It only opens up continued need for
coordination between WGs.

Joe

On 10/2/2014 6:13 AM, Tim Chown wrote:
> On 2 Oct 2014, at 12:51, Metzler, Dan J <dan-metzler@uiowa.edu
> <mailto:dan-metzler@uiowa.edu>> wrote:
> 
>> I would think that if it’s much easier to agree on “here’s what I
>> saw”, then it would work better if the first draft includes the
>> problem statement, and then later drafts flesh out “here’s what to do
>> about it”.  Even in practice, simply agreeing on the nature of the
>> problem, is of limited value without the knowledge of solutions, or
>> even the knowledge that a solution may not exist yet.  Even if there
>> are multiple solutions to a problem, it is always important to state
>> the problem that each solution is designed to solve when presenting
>> any solution.
>>
> 
> Indeed. As an author of the ‘what I saw’ it seems appropriate to
> document an issue that others can discuss and decide what action(s) to
> take.  
> 
> So separation of authorship is one thing.
> 
> Another is that there might be multiple ‘here’s what to do about it’
> documents, as there have been with other operational problem statements.
> There might be Informational or BCP documents in v6ops suggesting
> mitigation methods, and/or there might be protocol changes through 6man.
> 
> Tim