Re: [weirds] Scope and guiding principles (was Re: I-D Action: draft-hollenbeck-dnrd-ap-query-00.txt)

Eric Brunner-Williams <ebw@abenaki.wabanaki.net> Tue, 08 May 2012 16:45 UTC

Return-Path: <ebw@abenaki.wabanaki.net>
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5777321F84D9 for <weirds@ietfa.amsl.com>; Tue, 8 May 2012 09:45:25 -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=[AWL=0.000, 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 jrjVENqfIadu for <weirds@ietfa.amsl.com>; Tue, 8 May 2012 09:45:24 -0700 (PDT)
Received: from nic-naa.net (nic-naa.net [65.99.1.132]) by ietfa.amsl.com (Postfix) with ESMTP id 75EBC21F846D for <weirds@ietf.org>; Tue, 8 May 2012 09:45:24 -0700 (PDT)
Received: from limpet.local (cpe-67-255-2-48.twcny.res.rr.com [67.255.2.48]) by nic-naa.net (8.14.4/8.14.4) with ESMTP id q48DkIIF079670 for <weirds@ietf.org>; Tue, 8 May 2012 09:46:19 -0400 (EDT) (envelope-from ebw@abenaki.wabanaki.net)
Message-ID: <4FA94D9D.9040208@abenaki.wabanaki.net>
Date: Tue, 08 May 2012 12:45:17 -0400
From: Eric Brunner-Williams <ebw@abenaki.wabanaki.net>
Organization: wampumpeag
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: weirds@ietf.org
References: <CBC96A8A.2C888%francisco.arias@icann.org> <4FA8CEBF.5010605@sidn.nl>
In-Reply-To: <4FA8CEBF.5010605@sidn.nl>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [weirds] Scope and guiding principles (was Re: I-D Action: draft-hollenbeck-dnrd-ap-query-00.txt)
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ebw@abenaki.wabanaki.net
List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" <weirds.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/weirds>, <mailto:weirds-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/weirds>
List-Post: <mailto:weirds@ietf.org>
List-Help: <mailto:weirds-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/weirds>, <mailto:weirds-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 May 2012 16:45:25 -0000

On 5/8/12 3:43 AM, Antoin Verschuren wrote:
> ... I'd say majority or consensus, otherwise we'll not succeed
> to create anything and be discussing for the next 20 years for the
> feasibility of a registry specific feature, or local law specific
> request. ...

i lack your foresight. i've no idea if accommodating a specific
requirement, that is, ensuring that over-specification is avoided,
will result in no specification (that seems to be contradictory) and
twenty years of discussion.

in passing, the .cat rsep to distinguish between registry published
data (on port 43) for natural persons and legal persons (aka "people"
and "businesses") was approved at the current iana contractor's board
meeting of 2012.05.06, see item 2 on the consent agenda.

> ... Let's start with what's out there today.

the current iana contractor has accepted over 2,000 applications for
delegations from the iana root to be made as early as the orlando
meeting, completing no later than the honolulu meeting. the plan of
record of the current iana contractor is to repeat the process it
began this year periodically.

wglc on work product may occur prior to new delegations from the iana
root, but it may not. in any event, the utility of a standard for the
2000-2012 domains-and-addresses allocators and allocatees is bounded.

> And since it is protocol, it must fit RIR's/gTLD's/ccTLD's ...

i'm not quite as optimistic about the proper scope of a standards body
drafted specification of an endpoint identifier allocation query
mechanism.

i can hope it must fit rirs, but it may be prudent to ensure it fits
another ir regime.

i can hope it must fit a gtld contractual regime, but i know it would
be no less useful if it is capable of fitting at last one additional
regime, and is, in general, contractor and regime independent.

i can hope it must fit a useful set of ccTLDs, but these are, in
general, arbitrary sources of requirements.

To restate peter koch's reasonable query: "limiting scope makes sense,
but where's the threshold? at least one? the "majority"? is it the
icann/gtld world what counts?"

exclusion of a requirement must not be capricious, it must be the
consequence of an inability to reconcile that requirement with other
requirements.

my impression, from the domain tasting period, the fastflux working
group, the conficker .c response effort, and incidental conversations
with individuals professionally engaged in rights enforcement, private
and public, is that registration policy -- actual cost in complexity
(time cost) and cash (real dollar cost), are at least as useful as
registry types (supra) at determining utility and necessity of use
cases and therefore requirements.

-e