Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

Martin Millnert <martin@millnert.se> Sat, 23 April 2011 23:14 UTC

Return-Path: <martin@millnert.se>
X-Original-To: v6ops@ietfc.amsl.com
Delivered-To: v6ops@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A7D34E0613 for <v6ops@ietfc.amsl.com>; Sat, 23 Apr 2011 16:14:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8A-KVXJ7JTw for <v6ops@ietfc.amsl.com>; Sat, 23 Apr 2011 16:14:55 -0700 (PDT)
Received: from ncis.csbnet.se (ncis.csbnet.se [IPv6:2a02:9a0:4:104:5054:ff:feb8:99a4]) by ietfc.amsl.com (Postfix) with ESMTP id F0A2CE0611 for <v6ops@ietf.org>; Sat, 23 Apr 2011 16:14:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id 29CB777F0; Sun, 24 Apr 2011 01:30:05 +0200 (CEST)
Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVaq6mnjeKgT; Sun, 24 Apr 2011 01:30:05 +0200 (CEST)
Received: from [192.168.8.9] (unknown [76.14.60.12]) by ncis.csbnet.se (Postfix) with ESMTPSA id ED68E771E; Sun, 24 Apr 2011 01:30:03 +0200 (CEST)
From: Martin Millnert <martin@millnert.se>
To: james woodyatt <jhw@apple.com>
In-Reply-To: <04463D0E-CE36-4A40-8273-72EB61D3DE6C@apple.com>
References: <alpine.LRH.2.02.1104211405450.14690@netcore.fi> <AEAA108B-BDD3-4810-8464-A483D572EADF@cisco.com> <alpine.LRH.2.02.1104212051370.22232@netcore.fi> <20110423.180828.74727913.sthaug@nethelp.no> <04463D0E-CE36-4A40-8273-72EB61D3DE6C@apple.com>
Content-Type: text/plain; charset="UTF-8"
Date: Sat, 23 Apr 2011 19:14:46 -0400
Message-ID: <1303600486.3205.10.camel@shakira.millnert.se>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3
Content-Transfer-Encoding: 7bit
Cc: IPv6 Ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC
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: Sat, 23 Apr 2011 23:14:55 -0000

Some short-circuiting below.

On Sat, 2011-04-23 at 15:48 -0700, james woodyatt wrote:
> On Apr 23, 2011, at 9:08 AM, sthaug@nethelp.no wrote:
> 
> > In any case, I think it's quite clear that we need to get a document
> > out which says in no uncertain terms that 6to4 should not be enabled
> > by default.
> 
> I thought 6to4-advisory already said that.  If it doesn't perhaps Brain could be persuaded to amend it.  It's good advice for all the reasons described in that document.
> 

On Thu, 2011-04-14 at 19:30 +1200, Brian E Carpenter wrote:
> On 2011-04-14 08:48, Martin Millnert wrote:
> 
> <snip>
> 
> > 3. Disabling automatic 6to4-enabling on hosts would be good, too,
> > like you say (virtually everyone seems to agree about this?).
> > 
<snip>
> >   Brian, 4.1 in draft-ietf-v6ops-6to4-advisory-00: "This is bad
> >   practice - it should always be a conscious decision by a user to
> >   enable 6to4."
> > Would you have a comment on increasing the usage of 2119-wording in
> > the draft?  Is a change of the above "should" to "MUST"
> > inappropriate, the draft being a advisory text, and all?
> 
> Well, it will get published a lot quicker if it is kept as an
> Informational draft without formal language.
> 
> I think you should raise this comment against
> draft-ietf-v6ops-6to4-to-historic-00.txt, which says:
> 
> "2. Implementations capable of acting as 6to4 routers SHOULD NOT
>     enable 6to4 without explicit user configuration.
> ...
> 3.  If implemented in future products 6to4 SHOULD be disabled by
>     default"
> 
>      Brian

Regards,
Martin