Re: [IETF] IETF, ICANN and Whois (Was Re: Last Call: <draft-housley-rfc2050bis-01.txt> (The Internet Numbers Registry System) to Informational RFC)

John Curran <jcurran@istaff.org> Fri, 21 June 2013 22:05 UTC

Return-Path: <jcurran@istaff.org>
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 F113821F9962 for <ietf@ietfa.amsl.com>; Fri, 21 Jun 2013 15:05:35 -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 274Y0o6p-L3O for <ietf@ietfa.amsl.com>; Fri, 21 Jun 2013 15:05:30 -0700 (PDT)
Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id E027021F9ADA for <ietf@ietf.org>; Fri, 21 Jun 2013 15:05:29 -0700 (PDT)
Received: from pool-71-191-247-90.washdc.fios.verizon.net ([71.191.247.90] helo=diamond.istaff.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <jcurran@istaff.org>) id 1Uq9SL-000Ij6-Oo; Fri, 21 Jun 2013 22:05:21 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 71.191.247.90
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX19Zzf+v2d8rStFgvLa5MLQW
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
Subject: Re: [IETF] IETF, ICANN and Whois (Was Re: Last Call: <draft-housley-rfc2050bis-01.txt> (The Internet Numbers Registry System) to Informational RFC)
From: John Curran <jcurran@istaff.org>
In-Reply-To: <E9D4C327CAB3DE4FF73FDC2F@JcK-HP8200.jck.com>
Date: Fri, 21 Jun 2013 18:05:22 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <2E2038CA-2543-4DFE-B292-E66E50EB6575@istaff.org>
References: <F14A1FD640A19C37C743AFC2@JcK-HP8200.jck.com> <CAL9jLaZncSO_nnpe0wPgfsEY9zGnCj=N0tE_8MyXZ1gL6re+cA@mail.gmail.com> <4357630D-9FF4-4A6E-91E9-4731B02FD4FA@piuha.net> <D6B2DDFE-1C83-4FD0-9646-576F2F437239@frobbit.se> <51C21498.3020008@gmail.com> <C8EEFB02-5637-4247-98F6-3B414E045E0E@kumari.net> <BB52D64B1827B309BF7D9629@JcK-HP8200.jck.com> <C13DA83D-FC43-4243-897F-3E6B17B3434D@istaff.org> <E9D4C327CAB3DE4FF73FDC2F@JcK-HP8200.jck.com>
To: John C Klensin <john-ietf@jck.com>
X-Mailer: Apple Mail (2.1508)
Cc: Patrik Fältström <paf@frobbit.se>, ietf <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: Fri, 21 Jun 2013 22:05:36 -0000

On Jun 21, 2013, at 2:56 PM, John C Klensin <john-ietf@jck.com> wrote:

> While I agree with the above (and am still trying to avoid
> carrying this conversation very far on the IETF list), I think
> another part of the puzzle is that there are also situations in
> which technical considerations imply real constraints on policy
> alternatives.  Some obvious examples include physical constants
> like the speed of light, others, only slightly less obvious,
> include things like the design of the DNS as a simply hierarchy
> that cannot support symmetric aliases (i.e., anything that would
> support an actual "came from" function or a list of all of the
> names that point to a given note).  The policy folks ignore
> those constraints, or treat them as subject to policy-making
> decisions at the risk of being ridiculous and/or causing
> considerable harm to the Internet.  While they are less obvious
> in this community, I suggest it works the other way too -- there
> are policy and economic decisions and realities that are as much
> constraints on the technical solution space as those technical
> constrains are on the policy ones, with just about the same
> risks of ridiculousness or damage if they are ignored.

Agreed.  I believe that there is a better understanding of this
situation now than in the earlier days (including among governments
who are beginning to seriously engage with ICANN's GAC.)

> That is, again, why it is so unfortunate that the original model
> of the IAB/PSO as one of ICANN's three "everyone has to work
> together" pillars was abandoned... and more unfortunate that it
> was replaced on the ICANN side by approximately nothing other
> than some committees and other bodies that could easily be
> ignored and on the IETF side by depending on individuals with
> feet in both camps to speak up.


It's difficult to lay blame anyone from walking away from the PSO approach;
in ICANN's early years it always seemed to be a vestigial structure serving
little purpose. The lack of apparent value was amplified when ICANN changed 
its proposed structure (from being oversight and coordination between true
independent supporting organizations) into a heavily DNS-focused direction 
by opting to absorb the DNSO internally in the initial Singapore meeting.
If ICANN were operating solely in a coordination and oversight role, with 
policy, process, and protocol development done in supporting organizations, 
then it would have been a lot easier to make the liaison and coordination 
function successful, both between pillars (DNSO, ASO, PSO) and to/from 
governmental types.  For some reason, doing that in the margin of a 97%
DNS-focused omnibus policy/oversight/coordination/operation organization 
doesn't provide the necessary level of attention.

FYI,
/John

Disclaimers: My views alone.  Apologies for length; I lacked the time to
write a shorter reply.