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

jnc@mercury.lcs.mit.edu (Noel Chiappa) Sun, 03 July 2011 14:07 UTC

Return-Path: <jnc@mercury.lcs.mit.edu>
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 B889221F86EF; Sun, 3 Jul 2011 07:07:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0FZ+yhhWmWq; Sun, 3 Jul 2011 07:07:40 -0700 (PDT)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 4700E21F86EC; Sun, 3 Jul 2011 07:07:40 -0700 (PDT)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 08F5C18C13C; Sun, 3 Jul 2011 10:07:39 -0400 (EDT)
To: ietf@ietf.org
Message-Id: <20110703140739.08F5C18C13C@mercury.lcs.mit.edu>
Date: Sun, 03 Jul 2011 10:07:39 -0400
From: jnc@mercury.lcs.mit.edu
Cc: v6ops@ietf.org, jnc@mercury.lcs.mit.edu
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
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: Sun, 03 Jul 2011 14:07:40 -0000

    > From: Lorenzo Colitti <lorenzo@google.com>

    > Compared to the alternative of publishing 6to4-historic now, it:

    > a) Delays the time of any statement made by the IETF on the question
    > by at least a number of months, while vendors and home gateways are
    > *still shipping* products that implement 6to4 and enable it by
    > default.

draft-ietf-v6ops-6to4-advisory - which already exists, and which nobody is
objecting to - already contains text which tells manufacturers of both
home routers and hosts to disable 6to4 by default, etc, etc. If acting
ASAP is desirable, that ID could be approved just as quickly as
draft-ietf-v6ops-6to4-to-historic-05.txt could be (to be later updated by
the new document mentioned in the recent announcement).

    > b) Even assuming it were to gain consensus in any sort of reasonable
    > timescale, it would provide a less clear statement, and thus be less
    > of an incentive for implementors such as home gateway manufacturers
    > to do the right thing and remove it.

First, killing 6to4 is an additional goal, above and beyond 'stop 6to4
from causing problems'. The only conceivable reason I can think of for
that additional step seems to be the possibility that somehow 6to4 will
cause problems anyway, even if it is normally disabled? This seems
unlikely to me. Is there any reason beyond that to kill 6to4?

Second, what reason is there to believe that a document that says 'remove
6to4' is going to meet with greater/faster compliance from vendors than a
document that says 'disable it'? I would argue that the former takes more
engineering time, and is actually marginally less likely to be timely
responded to.

	Noel