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.
- Re: IETF, ICANN and Whois (Was Re: Last Call: <dr… John C Klensin
- Re: IETF, ICANN and Whois (Was Re: Last Call: <dr… Christopher Morrow
- Re: [Back to] Last Call: <draft-housley-rfc2050bi… David Conrad
- Re: IETF, ICANN and Whois (Was Re: Last Call: <dr… Jari Arkko
- Re: IETF, ICANN and Whois (Was Re: Last Call: <dr… John C Klensin
- Re: IETF, ICANN and Whois (Was Re: Last Call: <dr… Jari Arkko
- Re: IETF, ICANN and Whois (Was Re: Last Call: <dr… Christopher Morrow
- Re: [Back to] Last Call: <draft-housley-rfc2050bi… Christopher Morrow
- Re: IETF, ICANN and Whois (Was Re: Last Call: <dr… Randy Bush
- Re: IETF, ICANN and Whois (Was Re: Last Call: <dr… Patrik Fältström
- Re: IETF, ICANN and Whois (Was Re: Last Call: <dr… SM
- Re: IETF, ICANN and Whois (Was Re: Last Call: <dr… Patrik Fältström
- Re: IETF, ICANN and Whois (Was Re: Last Call: <dr… Paul Hoffman
- Lessons from PROVREG WG was Re: IETF, ICANN and W… Edward Lewis
- Re: Lessons from PROVREG WG was Re: IETF, ICANN a… joel jaeggli
- Re: Lessons from PROVREG WG was Re: IETF, ICANN a… Thomas Narten
- Re: Lessons from PROVREG WG was Re: IETF, ICANN a… Patrik Fältström
- RE: Lessons from PROVREG WG was Re: IETF, ICANN a… Hollenbeck, Scott
- Re: Lessons from PROVREG WG was Re: IETF, ICANN a… Edward Lewis
- Re: IETF, ICANN and non-standards John Levine
- Re: IETF, ICANN and Whois (Was Re: Last Call: <dr… Brian E Carpenter
- Re: IETF, ICANN and non-standards Ted Lemon
- Re: [IETF] Re: IETF, ICANN and non-standards Warren Kumari
- Re: [IETF] Re: IETF, ICANN and non-standards Joe Abley
- Re: [IETF] Re: IETF, ICANN and Whois (Was Re: Las… Warren Kumari
- Re: IETF, ICANN and non-standards John R. Levine
- Re: IETF, ICANN and non-standards John C Klensin
- Re: [IETF] Re: IETF, ICANN and Whois (Was Re: Las… John C Klensin
- Re: [IETF] IETF, ICANN and Whois (Was Re: Last Ca… John Curran
- Re: [IETF] IETF, ICANN and Whois (Was Re: Last Ca… David Farmer
- Re: [IETF] IETF, ICANN and Whois (Was Re: Last Ca… John C Klensin
- Re: [IETF] IETF, ICANN and Whois (Was Re: Last Ca… John Curran
- Re: IETF, ICANN and Whois (Was Re: Last Call: <dr… Fred Baker (fred)