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

"Metzler, Dan J" <dan-metzler@uiowa.edu> Fri, 03 October 2014 09:33 UTC

Return-Path: <dan-metzler@uiowa.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 B68BD1AD000 for <v6ops@ietfa.amsl.com>; Fri, 3 Oct 2014 02:33:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.386
X-Spam-Level:
X-Spam-Status: No, score=-3.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 RFcGUg7KnWwS for <v6ops@ietfa.amsl.com>; Fri, 3 Oct 2014 02:33:48 -0700 (PDT)
Received: from ITSNT447.iowa.uiowa.edu (itsnt447.iowa.uiowa.edu [128.255.67.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 444C51A0233 for <v6ops@ietf.org>; Fri, 3 Oct 2014 02:33:48 -0700 (PDT)
Received: from ITSNT440.iowa.uiowa.edu ([169.254.2.150]) by ITSNT447.iowa.uiowa.edu ([128.255.67.11]) with mapi id 14.03.0195.001; Fri, 3 Oct 2014 04:33:46 -0500
From: "Metzler, Dan J" <dan-metzler@uiowa.edu>
To: Joe Touch <touch@isi.edu>, Tim Chown <tjc@ecs.soton.ac.uk>
Thread-Topic: [v6ops] IPv6 Extension Headers in the Real World
Thread-Index: AQHP3cgE66Go8UIYvka1CtjXhjqwQpwcKteAgAACD4CAANPigP//ribAgABuhYCAAB74AIAA2aHA
Date: Fri, 03 Oct 2014 09:33:45 +0000
Message-ID: <9062DD5BB047BF4C96BCE0CB9DA96D1B4DE22159@ITSNT440.iowa.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> <542D695A.3070506@isi.edu>
In-Reply-To: <542D695A.3070506@isi.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [128.255.6.15]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/XcBqvte2ZmdHCeCynO6jBYeQ78I
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: Fri, 03 Oct 2014 09:33:50 -0000

I think perhaps I was a bit vague in my previous email, so just to clarify my point.

I would point out that my comments below imply that there is only one document under consideration for both "here's what I saw" and "here's what to do about it".
The problem statement and the solution are still presented in the same document.  "If" a problem statement or "here's what I saw" is presented in a separate document without a solution, purely for the sake of agreeing on the problem in a short period of time, typically I would expect another draft of the document to come along later with both "here's what I saw" and "here's what to do about it", and replace the previous one; not that you would maintain the two in separate documents.

The idea that there might be a document under discussion in two separate WGs at the same time is really a separate discussion, and it's based purely the idea that two WGs are considering the same problem that determines the need for coordination between WGs; not the number of iterations (drafts) of a document.  I would hope that cooperation or coordination between WGs would happen just because it makes sense when you're both considering solutions to the same problem.  That's true regardless of how many drafts are created.

Thanks,

- Dan

> -----Original Message-----
> From: Joe Touch [mailto:touch@isi.edu]
> Sent: Thursday, October 2, 2014 10:04 AM
> To: Tim Chown; Metzler, Dan J
> Cc: Lorenzo Colitti; draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org;
> V6ops Chairs; IPv6 Operations; Fernando Gont
> Subject: Re: [v6ops] IPv6 Extension Headers in the Real World
> 
> 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