Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03

Owen DeLong <owen@delong.com> Fri, 07 June 2013 22:19 UTC

Return-Path: <owen@delong.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B87DF21F99A6; Fri, 7 Jun 2013 15:19:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level:
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsA7t8J27xFH; Fri, 7 Jun 2013 15:19:06 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id C583821F99A8; Fri, 7 Jun 2013 15:19:06 -0700 (PDT)
Received: from [10.255.251.221] (kiwi.he.net [216.218.252.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r57MCmQT023606 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 7 Jun 2013 15:12:49 -0700
X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r57MCmQT023606
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370643170; bh=vR8orhfRnt+Cccwvod+iiX92F34=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=zxSgoqhoOIC58cFtKsJjuekLK9wAruAF9a2kbE5AwLyNkokzouGvPkl/i3NFOCBrx ueHlioe5Ny2ECj1fdkK5xra7AminlQdF9bcL4ARgndFA71QHa66oruKuEh4GsOOM1T xX6oR3FyX7kBS9q0awS87nQFm1EhU9zpuEbq8eag=
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03
From: Owen DeLong <owen@delong.com>
In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AC9D21B@nkgeml512-mbx.china.huawei.com>
Date: Fri, 07 Jun 2013 15:12:48 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <6E92D779-70BD-488B-B81C-95681AA26F4C@delong.com>
References: <05DB0BDC-9B6D-4852-B878-5320ABC14D67@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> <021E64FECA7E5A4699562F4E6671648103DE44@XCH-PHX-503.sw.nos.boeing.com> <8D23D4052ABE7A4490E77B1A012B6307751C62A3@mbx-01.win.nominum.com> <CAL6Yo0+Bfn0URBTaZmEk_X1NCoBo3QBJNn3FZqG0pLkA+3FgkA@mail.gmail.com> <CEC831E4-719F-40ED-A71D-56433B8CAB37@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC9D21B@nkgeml512-mbx.china.huawei.com>
To: Sheng Jiang <jiangsheng@huawei.com>
X-Mailer: Apple Mail (2.1508)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Fri, 07 Jun 2013 15:12:50 -0700 (PDT)
Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>, "<draft-jiang-v6ops-semantic-prefix@tools.ietf.org>" <draft-jiang-v6ops-semantic-prefix@tools.ietf.org>, "ipv6@ietf.org 6man-wg" <ipv6@ietf.org>, Sheng Jiang <shengjiang@gmail.com>, Ted Lemon <Ted.Lemon@nominum.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Jun 2013 22:19:07 -0000

>>> By the way, ISPs are only one kind of network operators who are interesting
>> in semantic prefix. Enterprise network operators are another group of
>> network operators who can benefit from embedded semantics. And the
>> enterprises do not have subscribers who potentially need extra bits.
>> 
>> Your use of the word "benefit" here is questionable at best. It is an example of
>> language that seems to encourage this use rather than evaluate it in an
>> unbiased manner.
>> 
>> "Enterprise operators are another group of network operators which may
>> succumb to this nasty pitfall of embedded semantics" would be  an equally
>> biased statement in the opposite direction.
>> 
>> I suggest that neutral would require something more along the lines of:
>> 
>> "Enterprise operators are another group of network operators which may
>> choose to embed semantics in their address prefixes."
>> 
>> Now, in terms of arguing the merits, there are significant differences between
>> these two. In the case of an enterprise operator, their choice to embed
>> semantics in the address has a limited scope of harm. It can only negatively
>> impact said enterprise.
>> 
>> In the case of an ISP, this can have significant consequences not only for the
>> ISP, but also for their downstream customers.
> 
> As a neutral analysis, it is fine to say there are benefits and pitfalls. All good things come with costs. I will make sure we document both sides in the draft.
> 

Yes. However, when you talk about classes of users that may use a technology, there are multiple ways to express that potential use.

"Those that may benefit…" is a positive way.
"The world will end if…" is a negative way.
"The following groups may use…" is neutral.

When you are talking about how something can be implemented or the relative merits of doing so, then it is appropriate to discuss the benefits and pitfalls (ideally in as neutral a fashion as possible).

I hope that clarifies what I was attempting to express above.

Owen