Re: draft-ietf-v6ops-6to4-to-historic (yet again)

james woodyatt <jhw@apple.com> Tue, 26 July 2011 22:11 UTC

Return-Path: <jhw@apple.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930A521F8782 for <ietf@ietfa.amsl.com>; Tue, 26 Jul 2011 15:11:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 XX9fCVgUQqfI for <ietf@ietfa.amsl.com>; Tue, 26 Jul 2011 15:11:22 -0700 (PDT)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 1AACA21F877F for <ietf@ietf.org>; Tue, 26 Jul 2011 15:11:22 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; CHARSET="US-ASCII"
Received: from relay13.apple.com ([17.128.113.29]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LOY004O1O98B0C0@mail-out.apple.com> for ietf@ietf.org; Tue, 26 Jul 2011 15:11:19 -0700 (PDT)
X-AuditID: 1180711d-b7c5fae000001427-1e-4e2f3b3e3e9f
Received: from kencur (kencur.apple.com [17.151.62.38]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id 0D.FA.05159.E3B3F2E4; Tue, 26 Jul 2011 15:10:06 -0700 (PDT)
Received: from [17.153.16.23] (unknown [17.153.16.23]) by kencur.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LOY001P6OATUD50@kencur.apple.com> for ietf@ietf.org; Tue, 26 Jul 2011 15:11:18 -0700 (PDT)
Subject: Re: draft-ietf-v6ops-6to4-to-historic (yet again)
From: james woodyatt <jhw@apple.com>
In-reply-to: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net>
Date: Tue, 26 Jul 2011 18:11:16 -0400
Message-id: <46B9B2CA-3A7A-40F4-9164-5608C48DCF18@apple.com>
References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net>
To: Ronald Bonica <rbonica@juniper.net>
X-Mailer: Apple Mail (2.1244.3)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUiON1OTdfOWt/PYNpFfYtnG+ezODB6LFny kymAMYrLJiU1J7MstUjfLoEr49DUjewFD/kqvq+cyNrA2MLTxcjJISFgInFs7z8mCFtM4sK9 9WxdjFwcQgLtTBLrG+YzgyR4BQQlfky+x9LFyMHBLCAvcfC8LEiYWUBL4vujVhaI+slMEr0z rrODJIQFrCXezr8ONpRNQEXi2+W7YDangI/EuwWNbCBzWARUJc7sdYCYoyxx9OsNdohVNhJT 3hwBKxcS8JZ4N20x2AkiAuoSj1dNY4O4U15icctnxgmMArOQXDcL4bpZSK5bwMi8ilGwKDUn sdLQWC+xoCAnVS85P3cTIyjsGgpldzDu/8l/iFGAg1GJh5dpsq6fEGtiWXFl7iFGCQ5mJRHe Hf/1/IR4UxIrq1KL8uOLSnNSiw8xSnOwKInzZv1Q9RMSSE8sSc1OTS1ILYLJMnFwSjUwFp84 /dM68k2/jvXsLdnvXOwqf83Rfm79ruHk1N2dSZEeGjm1boL/0oUFLnJtrCtt/Dh71cppsotz ciNVrITc1rdFnF5TfWP76ccS225fusPPeWTas+i7zUWe0wqeWDNMeGy3N2OD80+RmnyOf9m7 OKeVbVnHzLT735LEy5tyjwXM/71z3t/JB5VYijMSDbWYi4oTAQgT7DQ3AgAA
Cc: "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jul 2011 22:11:22 -0000

On Jul 25, 2011, at 10:30 AM, Ronald Bonica wrote:
> 
> Please post your views on this course of action by August 8, 2011.

I remain convinced that this document is unnecessary and publishing it would be silly, at best, and at worst, the simultaneous publication of 6to4-to-historic alongside 6to4-advisory, which implicitly contradict one another-- the latter says that 6to4 has an indefinite future and here's how to keep everything operational in its presence on the Internet; the former says 6to4 has no future, and it should not be used by anyone for any purpose-- may turn out to be an embarrassment for IETF.  IESG should feel very nervous about claiming there is consensus to publish this draft.  It does not appear to me like there is a rough consensus for it.

That said, I won't complain too loudly if this draft is published.  It would give me cover to ask my employers for 6to4 capability to be removed from forthcoming products that I mainly work to support.  I don't like taking features away from users when there isn't a suitable upgrade path for them, but the truth is that fielding problems from the field resulting from 6to4 failure can be pretty tiresome, and I would welcome the cover from IETF to be able to say, "Oh, you're still using 6to4?  You should turn that off.  It's deprecated by IETF now, and accordingly, we no longer support it.  Get native IPv6 service."

In other words, whether IESG means to convey this message or not, publishing 6to4-to-historic alongside the existing 6to4-advisory-- without any clear phase-out plan-- will pretty clearly imply to people like me that the official phase-out plan is to remove 6to4 from the Internet, starting as soon as vendors and operators are independently able to do so.  "Start the engines of destruction."


--
james woodyatt <jhw@apple.com>
member of technical staff, core os networking