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

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

Return-Path: <randy@psg.com>
X-Original-To: int-area@core3.amsl.com
Delivered-To: int-area@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CAB03A6781 for <int-area@core3.amsl.com>; Fri, 20 Aug 2010 21:08:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.48
X-Spam-Level:
X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 GglRQbr-rD3k for <int-area@core3.amsl.com>; Fri, 20 Aug 2010 21:08:14 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id A9CC83A635F for <int-area@ietf.org>; Fri, 20 Aug 2010 21:08:14 -0700 (PDT)
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>
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"
X-Mailman-Approved-At: Sat, 21 Aug 2010 20:01:33 -0700
Cc: IPv6 Operations <v6ops@ops.ietf.org>, int-area@ietf.org, draft-narten-ipv6-3177bis-48boundary@tools.ietf.org
Subject: Re: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/int-area>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Aug 2010 04:08:21 -0000

> 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