Re: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05

Randy Bush <randy@psg.com> Sat, 21 August 2010 04:11 UTC

Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72E113A68FC for <ietfarch-v6ops-archive@core3.amsl.com>; Fri, 20 Aug 2010 21:11:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.482
X-Spam-Level:
X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15xGKjmpJsjb for <ietfarch-v6ops-archive@core3.amsl.com>; Fri, 20 Aug 2010 21:11:22 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 748073A635F for <v6ops-archive@lists.ietf.org>; Fri, 20 Aug 2010 21:11:22 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1OmfNy-0006ej-Hn for v6ops-data0@psg.com; Sat, 21 Aug 2010 04:08:50 +0000
Received: from [2001:418:1::40] (helo=ran.psg.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from <randy@psg.com>) id 1OmfNw-0006e9-G4 for v6ops@ops.ietf.org; Sat, 21 Aug 2010 04:08:48 +0000
Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <randy@psg.com>) id 1OmfNp-000KgJ-2p; Sat, 21 Aug 2010 04:08:41 +0000
Date: Sat, 21 Aug 2010 13:08:39 +0900
Message-ID: <m2tymomwu0.wl%randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Fred Baker <fred@cisco.com>
Cc: draft-narten-ipv6-3177bis-48boundary@tools.ietf.org, IPv6 Operations <v6ops@ops.ietf.org>, int-area@ietf.org
Subject: Re: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05
In-Reply-To: <DB6D65E1-34A5-42A9-B692-7C826AD754C8@cisco.com>
References: <D74F3837-E115-49FB-A9AB-5E0C53406621@tony.li> <DB6D65E1-34A5-42A9-B692-7C826AD754C8@cisco.com>
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"
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

> One of the important points of RFC 3177 is in the opening statements:
> 
>    The technical principles that apply to address allocation seek to
>    balance healthy conservation practices and wisdom with a certain ease
>    of access...
> 
>    The IETF makes no comment on business issues or relationships.
>    However, in general, we observe that technical delegation policy can
>    have strong business impacts.  A strong requirement of the address
>    delegation plan is that it not be predicated on or unduly bias
>    business relationships or models.

observing it is just fine.  mucking with it is something we got the
<bleep> out of the ietf and back into the hands of operators in a decade
ago.  we do not need to re-learn tose lessons.

the ietf has no actual brief for recommendating allocation sizes that
are not based on, likely ephemeral and often fallacious, beliefs about
isps' business practices, operational needs, this week's st00pid
hardwhere, and religios zealotry about freeing the consumer.

i strongly support the draft with the careful constraints it has.

randy