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

John C Klensin <john-ietf@jck.com> Fri, 21 June 2013 18:57 UTC

Return-Path: <john-ietf@jck.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 49E4421F9F06 for <ietf@ietfa.amsl.com>; Fri, 21 Jun 2013 11:57:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.501
X-Spam-Level:
X-Spam-Status: No, score=-102.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 L6WyUq04tzZy for <ietf@ietfa.amsl.com>; Fri, 21 Jun 2013 11:57:09 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 61D2321F9E61 for <ietf@ietf.org>; Fri, 21 Jun 2013 11:57:09 -0700 (PDT)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1Uq6W9-0007wv-1Q; Fri, 21 Jun 2013 14:57:05 -0400
Date: Fri, 21 Jun 2013 14:56:59 -0400
From: John C Klensin <john-ietf@jck.com>
To: John Curran <jcurran@istaff.org>
Subject: Re: [IETF] IETF, ICANN and Whois (Was Re: Last Call: <draft-housley-rfc2050bis-01.txt> (The Internet Numbers Registry System) to Informational RFC)
Message-ID: <E9D4C327CAB3DE4FF73FDC2F@JcK-HP8200.jck.com>
In-Reply-To: <C13DA83D-FC43-4243-897F-3E6B17B3434D@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>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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 18:57:15 -0000

--On Friday, June 21, 2013 11:46 -0400 John Curran
<jcurran@istaff.org> wrote:

>...
>> Let's not complicate things further by making the assumption
>> that anything that reasonably looks like "technical stuff"
>> belongs in the IETF and not in ICANN.  It is likely to just
>> make having the right conversations even harder.
> 
> I believe that policy issues that are under active discussion
> in ICANN can also be discussed in the IETF, but there is
> recognition  that ICANN is likely the more appropriate place
> to lead the process of consensus development and approval.
> 
> I believe that protocol development that is under active
> discussion at the IETF can also discussed at ICANN, but there
> is recognition  that the IETF is likely the appropriate place
> to lead the process  of consensus development and approval.
>...

John,

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.

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.

   john