IETF Logo Mail Archive

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

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 20 August 2010 23:17 UTC

Return-Path: <brian.e.carpenter@gmail.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 7A8DB3A691B for <int-area@core3.amsl.com>; Fri, 20 Aug 2010 16:17:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.429
X-Spam-Level:
X-Spam-Status: No, score=-102.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 HaACX8AyCRdI for <int-area@core3.amsl.com>; Fri, 20 Aug 2010 16:17:02 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 93B903A6898 for <int-area@ietf.org>; Fri, 20 Aug 2010 16:17:02 -0700 (PDT)
Received: by qwc9 with SMTP id 9so3795519qwc.31 for <int-area@ietf.org>; Fri, 20 Aug 2010 16:17:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=JY5/X/vYOcY5e13dLl2pfYKiwffqW7sjkPZd+FITdZg=; b=v2eyvJlKlh4LrqbhTZsG8sb5lkvZEIAqAmaC46/VxnsGJLrO8UlFaincUYNvkif+kN b/2HOUg4dInvjubKs9S48Y5V/8gLK6GLpwA2FCZuzjCcnHVBv7xIqAQ2Fna5HTAqvD3k 6AHTvi5yXuiSHbEJDoNxvIBJUWI1uMm0CX5ts=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=iH1BiycYhOR/Ey7F/fw7f6ybYQ5qY2EkSnTNmAj4a7eVj8lnacIXLqLnvaZbS0Vohz anieEQKAx8Pu7e4mX8gnYmVI/HK1m3XPsXNAEtN1T1ROaB29b9x2gcSj1Wp652hMcCLN tC+YbGHTRaMHK1q5l5t6a+5VFJgjUZqW4khWw=
Received: by 10.229.141.75 with SMTP id l11mr355529qcu.154.1282346256683; Fri, 20 Aug 2010 16:17:36 -0700 (PDT)
Received: from [10.1.1.4] ([121.98.142.15]) by mx.google.com with ESMTPS id e6sm3828683qcr.5.2010.08.20.16.17.33 (version=SSLv3 cipher=RC4-MD5); Fri, 20 Aug 2010 16:17:36 -0700 (PDT)
Message-ID: <4C6F0D09.9060107@gmail.com>
Date: Sat, 21 Aug 2010 11:17:29 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Tony Li <tony.li@tony.li>
References: <D74F3837-E115-49FB-A9AB-5E0C53406621@tony.li> <C0AC8FAB6849AB4FADACCC70A949E2F1058062E62F@EUSAACMS0701.eamcs.ericsson.se> <188C11C5-CDBA-4213-83AC-453AE06ADAD5@cisco.com> <4C6EE713.9080805@gmail.com> <4C6EE9D9.2090003@joelhalpern.com> <4C6EEC30.5010409@gmail.com> <C0AC8FAB6849AB4FADACCC70A949E2F1058062E70A@EUSAACMS0701.eamcs.ericsson.se> <D2EC6C44-B0B7-4E20-A7E1-8021E724126F@tony.li>
In-Reply-To: <D2EC6C44-B0B7-4E20-A7E1-8021E724126F@tony.li>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: IPv6 Operations <v6ops@ops.ietf.org>, "int-area@ietf.org" <int-area@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: Fri, 20 Aug 2010 23:17:03 -0000

On 2010-08-21 10:45, Tony Li wrote:
> Hi Eric,
> 
> 
>> 	The second is that they can differentiate themselves by offering
>> address allocation sizes that do not align well with other providers, in
>> an attempt to lock-in customers who will find that they can anticipate
>> administrative head-aches and extra costs if they ever decide they want 
>> to go with a different service provider.  This is probably a bad thing.
> 
> 
> Alternate service providers can then respond by matching the odd address space allocation, or providing their next quantum up.  This hurts addressing efficiency slightly, but is unlikely to be a real deterrent.

Exactly. The market will provide. Of course, I agree with Fred that
we should stick to nibble boundaries.

     Brian

v2.23.0 | Report a Bug | By Email