Re: Last Call: <draft-housley-rfc2050bis-01.txt> (The Internet Numbers Registry System) to Informational RFC

Tom Vest <tvest@eyeconomics.com> Sun, 12 May 2013 20:45 UTC

Return-Path: <tvest@eyeconomics.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 1AF8C21F8529 for <ietf@ietfa.amsl.com>; Sun, 12 May 2013 13:45:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 aSKElkY-TSJc for <ietf@ietfa.amsl.com>; Sun, 12 May 2013 13:45:52 -0700 (PDT)
Received: from smtp94.ord1c.emailsrvr.com (smtp94.ord1c.emailsrvr.com [108.166.43.94]) by ietfa.amsl.com (Postfix) with ESMTP id CBB9121F84B6 for <ietf@ietf.org>; Sun, 12 May 2013 13:45:52 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp4.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 4450114007E; Sun, 12 May 2013 16:45:52 -0400 (EDT)
X-Virus-Scanned: OK
Received: by smtp4.relay.ord1c.emailsrvr.com (Authenticated sender: tvest-AT-eyeconomics.com) with ESMTPA id B8375140083; Sun, 12 May 2013 16:45:51 -0400 (EDT)
Subject: Re: Last Call: <draft-housley-rfc2050bis-01.txt> (The Internet Numbers Registry System) to Informational RFC
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset="us-ascii"
From: Tom Vest <tvest@eyeconomics.com>
In-Reply-To: <6.2.5.6.2.20130511133231.07f7a940@resistor.net>
Date: Sun, 12 May 2013 16:45:51 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <DC59E3A6-00A6-4940-A2E4-32D9E553DFE7@eyeconomics.com>
References: <20130416230618.31243.43068.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130510103049.0ca25050@resistor.net> <D8079A6C-3A65-433E-8D12-5B53E645E48E@virtualized.org> <6.2.5.6.2.20130510231552.0df99d90@resistor.net> <4529DB87-C5E6-4EC0-AA0B-00D261743A2E@eyeconomics.com> <6.2.5.6.2.20130511133231.07f7a940@resistor.net>
To: SM <sm@resistor.net>
X-Mailer: Apple Mail (2.1085)
X-Mailman-Approved-At: Mon, 13 May 2013 07:02:22 -0700
Cc: 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: Sun, 12 May 2013 20:45:57 -0000

On May 11, 2013, at 7:34 PM, SM wrote:

> At 13:08 11-05-2013, Tom Vest wrote:
>> Sorry, but unless you can point to some relevant real-world examples of self-executing, self-sustaining principles, or you're a nihilist and don't really believe that such things as principles exist at all, this is a patently false, bordering on nonsense statement.
> 
> I am not suggesting any self-executing or self-sustaining principles.

Fair enough; I will assume that we agree that "policies" and "principles" are not mutually exclusive and incompatible phenomena, and that the class of durable, self-executing, and self-sustaining principles is an empty set.

>> One is tempted to ask "work for who?" but that would entail giving this statement more credence that it merits. Since TCP/IP is only useful to the end of communication between two or more nodes, the proposed "principle" of finitude would perfectly consistent with this, and almost every other IETF addressing/attachment protocol *not* working at all.
>> 
>> Or did you mean to say that "The principle for the above is to avoid set any constraint unless it is necessary for IETF protocols to 'work' between two virtual machines, under lab conditions"?
> 
> What I meant was to leave policy (PDP, etc.) to the communities interested in IP addressing.  I'll quote part of a message posted on the thread:
> 
>  'To date, the communities interested in IP addressing have established policies
>   that dictate "operational needs" should be the primary constraint (as opposed
>   to say constraining on geo-political boundaries, by ability to pay, etc).'
> 
> The message is at http://www.ietf.org/mail-archive/web/ietf/current/msg79200.html in case what I was quoted is misrepresented.

I certainly did not intend to misrepresent your position. But given the fact that the "part of a message" that you reproduced was offered in response to doubts that you yourself raised about the points covered therein (esp. "operational need"), what is your position, exactly? As David said, "to date" the communities have established policies that are broadly informed by the practical implications of the finitude and uniqueness constraints on address resource management. However, to conclude based on past observations that such will always be true would be tantamount to claiming that management of those constraints is assured by the operation of (unspecified self-executing, self-sustaining) principles. Based on your views as expressed in/around draft-moonesamy-rfc2050-historic-00, it's pretty clear that you don't see any durable, much less "timeless" principles embodied therein -- but that only makes your position on these matters all the more ambiguous. 

Perhaps it would help if you would answer the following clarifying questions:

1. Is it your position that some other force or principle(s) outside of the general mechanisms/practices documented in RFC2050 (and potentially, RFC2050-bis) guarantees that IETF-defined addressing protocols will "just work" as designed, in perpetuity, and thus the informational codification of matters related to the management of finitude and uniqueness constraints is at best unnecessary, at worst counterproductive? If so, what are those unnamed forces/principles, exactly?

2. Is it your position that, if the traditional "communities interested in IP addressing" one day elect to adopt policies that make it impossible for IETF addressing protocols to fulfill even the basic "just work" test, then from the "IETF view"  that should be regarded as a perfectly appropriate and acceptable outcome?

> At 13:14 11-05-2013, Brian E Carpenter wrote:
>> It's up to the IETF to set boundary conditions for the address space
>> that it created (in the case of IPv6) or inherited (in the case of
>> IPv4), in order to protect the long-term viability of the Internet.
> 
> There is some text about Internet address architecture.  It would cover that if the relevant communities are agreeable to it.

Could you please clarify which passages about Internet address architecture you are suggesting are sufficient to make the sections about distribution and uniqueness constraints unnecessary?

Thanks, 

TV


> Regards,
> -sm