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

jnc@mercury.lcs.mit.edu (Noel Chiappa) Sun, 03 July 2011 21:29 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 A836E21F85CD; Sun, 3 Jul 2011 14:29:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.722
X-Spam-Level:
X-Spam-Status: No, score=-5.722 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, FRT_FOLLOW1=1.332, FRT_FOLLOW2=0.422, 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 HHxpeS6DEozG; Sun, 3 Jul 2011 14:29:06 -0700 (PDT)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 305BC21F85CC; Sun, 3 Jul 2011 14:29:05 -0700 (PDT)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 34DB218C1C2; Sun, 3 Jul 2011 17:29:05 -0400 (EDT)
To: ietf@ietf.org, v6ops@ietf.org
Message-Id: <20110703212905.34DB218C1C2@mercury.lcs.mit.edu>
Date: Sun, 03 Jul 2011 17:29:05 -0400
From: jnc@mercury.lcs.mit.edu
X-Mailman-Approved-At: Tue, 05 Jul 2011 06:39:23 -0700
Cc: 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 21:29:06 -0000

    > From: Ronald Bonica <rbonica@juniper.net>

    > I think that I get it. There is no IETF consensus regarding the
    > compromise proposed below. ...
    > Right now, the only alternative that I see is to reintroduce
    > draft-ietf-v6ops-6to4-to-historic 

But there is no rough consensus to do that either.

There is simply no IETF-wide agreement on _any_ action with regard to killing
off 6to4.

So the only possible response is the IETF's normal response when there is no
rough consensus on what to do, which is to defer any action.

At least, as has been pointed out, we have draft-ietf-v6ops-6to4-advisory,
which has already been OKs, and which, _if folllowed_, would alleviate most
of the problems.

	Noel