Re: [v6ops] 464XLAT Trial Deployment Report

Rémi Després <despres.remi@laposte.net> Thu, 09 February 2012 08:27 UTC

Return-Path: <despres.remi@laposte.net>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7455A21F85C3 for <v6ops@ietfa.amsl.com>; Thu, 9 Feb 2012 00:27:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.249
X-Spam-Level:
X-Spam-Status: No, score=-1.249 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnsQf2QujsmU for <v6ops@ietfa.amsl.com>; Thu, 9 Feb 2012 00:27:45 -0800 (PST)
Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.4]) by ietfa.amsl.com (Postfix) with ESMTP id CC68D21F85C2 for <v6ops@ietf.org>; Thu, 9 Feb 2012 00:27:41 -0800 (PST)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2116.sfr.fr (SMTP Server) with ESMTP id 7D3D270000EA; Thu, 9 Feb 2012 09:27:40 +0100 (CET)
Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2116.sfr.fr (SMTP Server) with ESMTP id 494847000072; Thu, 9 Feb 2012 09:27:40 +0100 (CET)
X-SFR-UUID: 20120209082740300.494847000072@msfrf2116.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="iso-8859-1"
From: Rémi Després <despres.remi@laposte.net>
X-Priority: 3
In-Reply-To: <01bf01cce57a$1a0e0900$4001a8c0@gateway.2wire.net>
Date: Thu, 09 Feb 2012 09:27:39 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <139469BF-BE6E-4939-9550-EFA4FB1F4DA6@laposte.net>
References: <CAD6AjGSRUdx32arseR26RzHNtMri8Vrif3dCQmuk7B52GmoHAw@mail.gmail.com><FBD9BBC7-A537-4ABE-ABEB-76098F1BB415@cisco.com><CAKD1Yr3Cq7kj5RLW_ktEEs12NPA_-yNeSzstPiKeYY7Sv1FqVQ@mail.gmail.com> <C4E5FF0A-9FBA-465C-AB4B-8A1A62BAAD56@apple.com> <01bf01cce57a$1a0e0900$4001a8c0@gateway.2wire.net>
To: "t.petch" <ietfc@btconnect.com>
X-Mailer: Apple Mail (2.1084)
X-sfr-mailing: LEGIT
Cc: v6ops v6ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] 464XLAT Trial Deployment Report
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
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, 09 Feb 2012 08:27:45 -0000

Le 2012-02-07 à 10:23, t.petch a écrit :

> ----- Original Message -----
> From: "james woodyatt" <jhw@apple.com>
> To: "Lorenzo Colitti" <lorenzo@google.com>
> Cc: "v6ops v6ops WG" <v6ops@ietf.org>
> Sent: Monday, February 06, 2012 7:33 PM
>> On Feb 5, 2012, at 23:53 , Lorenzo Colitti wrote:
>>> 
>>> As to which WG it belongs in, I don't know.
>> 
>> I would say that if there is a WG where this belongs, then it would be BEHAVE
> and not V6OPS.  I fail to see why this needs a working group to develop any
> further.  Wouldn't the individual submission track be more appropriate?

+1 

> When I have suggested an individual submission, I get told that it costs the
> IETF more, that is that the necessary evils of publishing are amortised across a
> wider spectrum of people when a WG is involved, so unless an AD is really
> burning with desire to support an individual submission, then a WG is the way to
> go.
> 
> V6OPS or BEHAVE?  I see the latter as more limited, more focussed in scope, so
> would go for V6OPS.
> 
> Is it worth publishing as an RFC?  Yes, the IETF traditionally neglects
> operators, favouring 'manufacturers' so this would help redress the balance.

As individual submission and experimental, yes.
For anything else, Softwire would be the place  (the overlap with stateless solutions studied there is obvious).


RD



> 
> Tom Petch
> 
>> --
>> j h woodyatt <jhw@apple.com>
>> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops