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

Randy Bush <randy@psg.com> Sun, 03 July 2011 05:06 UTC

Return-Path: <randy@psg.com>
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 5774021F8734; Sat, 2 Jul 2011 22:06:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.574
X-Spam-Level:
X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599]
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 oVrOghwHmuaX; Sat, 2 Jul 2011 22:06:41 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id B10FD21F8733; Sat, 2 Jul 2011 22:06:41 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from <randy@psg.com>) id 1QdEtC-000Foo-0O; Sun, 03 Jul 2011 05:06:38 +0000
Date: Sun, 03 Jul 2011 14:06:36 +0900
Message-ID: <m2mxgw9cmb.wl%randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Ronald Bonica <rbonica@juniper.net>
In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D3F3507F14@EMBX01-WF.jnpr.net>
References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <CAKD1Yr2Smvm0RY5iV2y06wD=RRz-uW4VbaaairnoAkSR7zLdtg@mail.gmail.com> <m2y60g9xiw.wl%randy@psg.com> <13205C286662DE4387D9AF3AC30EF456D3F3507F14@EMBX01-WF.jnpr.net>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Cc: IPv6 Ops WG <v6ops@ietf.org>, IETF Discussion <ietf@ietf.org>
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 05:06:42 -0000

> 1) "as measured on the real internet, not the ietf bar, 6to4 sucks caterpillar snot"
> 2) "perhaps that minority was also vocal in the back room"
> 3) "yes, but that will be a year from now.  in the ietf, delay is one form of death"
> 
> Responses follow:
> 
> 1) While not stated so colorfully, draft-ietf-v6ops-6to4-advisory made
>    this point. It has been approved for publication. 

but then do we not draw the conclusion that therefore publishing
draft-ietf-v6ops-6to4-to-disgusting is the correct approach?

> 2) While there was no back-room activity, an appeal had been filed at
>    the WG level. Since WG consensus was stronger than IETF consensus,
>    it is reasonable to assume that the appeal would be escalated to
>    the IESG level if it was not approved at the WG level.

so these days people who do not get their way use the nuclear option?
we raised kids.  when those tactics resulted in "we are so sorry you do
not like the result, but that's the result" they soon stopped.

> So, any way you look at it, there would be delays.

welcome to the ietf, where process is our most important product.

> 3) The new document may not take a year to publish. Since it is a
>    short draft, it could be produced in a few days. Once it is
>    produced, we could immediately initiate a WG last call and an IETF
>    last call immediately after that. So, we might be talking about a
>    six-week delay.

so process this one in six weeks, please.

> Now, I have a question for you, Lorenzo and Doug. If our goal is to
> take 6-to-4 off of the Internet, does not disabling it by default
> solve most of the problem? AFAIKS, very few users would enable it and
> service providers would not be economically incented to support 6-to-4
> relay routers.

the economic incentive to half-assed service providers is that it gives
an excuse not to deploy ipv6.  the response of these folk will be web
pages instructing their users how to turn 6to4 on.

randy