From nobody Thu Jun 5 17:03:51 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 415551A0363 for ; Thu, 5 Jun 2014 17:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVf0CPjQfeCQ for ; Thu, 5 Jun 2014 17:03:46 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id E1EC91A0358 for ; Thu, 5 Jun 2014 17:03:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 223AE1E12A7; Thu, 5 Jun 2014 17:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c9a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9_ln86muZRk; Thu, 5 Jun 2014 17:02:06 -0700 (PDT) Received: from [10.30.0.121] (unknown [83.150.71.93]) by c8a.amsl.com (Postfix) with ESMTPSA id F144F1DF121; Thu, 5 Jun 2014 17:02:04 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: IETF Chair Date: Fri, 6 Jun 2014 03:03:36 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> To: ietf-announce@ietf.org X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/H5he71EVIxwl54ZrLCBRQkwlwuM Cc: internetgovtech@iab.org, IETF discussion list Subject: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: The IESG List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 00:03:48 -0000 As you know, the NTIA announced on March 14th, 2014 that a process has = been started to relinquish the IANA oversight role of the NTIA to the = multistakeholder Internet community. ICANN was given a facilitator role = to set up the process, and there has been a proposal and commentary on = that proposal, including well-received feedback from the IAB. Now we are at a point where the final details are expected to become = clear soon. A big part of the overall plan depends on the processes in = the relevant communities, such as those of the IETF and RIRs. But the = overall process also includes a coordination group, on which the IETF = gets 2 seats and the IAB 2 seats. Other seats will be filled by parts of = the naming and numbering communities. ISOC will also have two seats. The coordination group is likely to be ultimately responsible for = delivering a combined transition proposal to NTIA and for ensuring that = the proposal meets the criteria NTIA previously outlined. Participation = in the coordination group is likely to entail a significant amount of = time and travel, although the exact details of how the group will work = and what its responsibilities will be is not yet available. The IAB will select two people from the IAB voting members and the IAB = IANA strategy program participants. I'm sending this email because the = IESG would like to consult with the community before filling the two = IETF positions. Given that there is an upcoming ICANN meeting in London = (starting on June 22nd) and that there might be opportunities for = discussion during that meeting, timely selection would be useful. We realize that doing this on a compressed timeline and without complete = details is not ideal. NTIA has requested that the transition proposal be = delivered by September 2015, which we view as a relatively short time = period for developing global community consensus on this topic. Thus, we = feel that it is imperative for the coordination group to be constituted = and for it to begin its work as soon as possible, just like how the = relevant communities should progress their parts of the work. We would like to fill the two IETF seats with IETF community members who = have had significant interaction and experience with IANA and its = oversight. Some IESG, IAB, and IAB IANA strategy program members have = experience on this matter, and we are already aware of several such = people who are willing to serve in this role. However, before appointing = people to these seats, we wanted to find out if there are members of the = broader community who would be willing to serve. If you would like to = volunteer, please send a short statement of interest (200 words or less) = to the IESG by 23:59 UTC on June 16, 2014. Jari Arkko on behalf of the IESG From nobody Fri Jun 6 23:49:27 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9791A0272 for ; Fri, 6 Jun 2014 23:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.955 X-Spam-Level: X-Spam-Status: No, score=0.955 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wU_loc5frKEd for ; Fri, 6 Jun 2014 23:49:25 -0700 (PDT) Received: from p130.piuha.net (unknown [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id D35071A0217 for ; Fri, 6 Jun 2014 23:49:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3A1B62CC5F; Sat, 7 Jun 2014 09:49:17 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOgeq__bpwRQ; Sat, 7 Jun 2014 09:49:12 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 8F0A72CC5D; Sat, 7 Jun 2014 09:49:12 +0300 (EEST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: text/plain; charset=us-ascii From: Jari Arkko In-Reply-To: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> Date: Sat, 7 Jun 2014 09:49:11 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> To: ietf-announce@ietf.org X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/8ZKm4Ghy7n3e-uOBCLwszmCyfIs Cc: internetgovtech@iab.org, IETF discussion list Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: The IESG List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 06:49:26 -0000 For your information: additional details about the process and the = coordination group are now available, here:=20 https://www.icann.org/resources/pages/process-next-steps-2014-06-06-en Jari Arkko From nobody Sat Jun 7 08:50:03 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756B11A0245; Sat, 7 Jun 2014 08:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8sl961E5_24w; Sat, 7 Jun 2014 08:49:59 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9338E1A00D7; Sat, 7 Jun 2014 08:49:59 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WtIqs-0001l7-L7; Sat, 07 Jun 2014 11:48:14 -0400 Date: Sat, 07 Jun 2014 11:49:43 -0400 From: John C Klensin To: The IESG Message-ID: In-Reply-To: References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.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 X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/wfaZdJvzVzJX8paLf8Ie6eQGsu8 Cc: internetgovtech@iab.org, IETF discussion list Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 15:50:01 -0000 --On Saturday, June 07, 2014 09:49 +0300 Jari Arkko wrote: > For your information: additional details about the process and > the coordination group are now available, here: > > https://www.icann.org/resources/pages/process-next-steps-2014- > 06-06-en Jari, I find one aspect of this document and the ongoing selection process very troubling. The work and schedule of the Coordinating (nee Steering) Committee seem completely open-ended, both with respect to time commitment and to resource requirements (including the potential requirement for travel to a potentially continual road show of meetings. This new document is worse in that regard than its predecessor because both the schedule of meetings and the mission of the Coordinating Committee have become open-ended. Unlike many of the appointing groups, the IETF is not in a position to underwrite those costs, i.e., to cover costs of time-salary and/or travel to the various meetings so as to spread those costs across the relevant community. The net effect is that the only people who can plausibly represent the IETF are those who: (i) Work for organizational entities with considerable resources and willingness to provide open-ended support their employees in this type of work, (ii) Have significant (even if not "too much") free time and resources on their hands, or (iii) Consider this particular part of the work really, really, important. I suggest that most people who fall into one or more of those categories are not what we would normally consider representative of the IETF community, much less representatives of the diversity of this community (and note that "diversity" is a new criterion). Especially for the first category above, there is also a considerable potential for conflicts of responsibility and interest if organizations with significant stakes in this process have employees or others appointed through both IETF (including IAB) and other constituency models. Perhaps it is the best we can do, but, especially since members of that committee represent themselves once appointed, I think it would be wise for the IETF to publicly note the issues and create some distance from this process. That would be especially important if "we" eventually conclude that we have to reject its final conclusion/ recommendations. I also suggest that, if current IAB or IESG members decide to do this and give it priority, the upcoming Nomcom should give careful consideration to its impact on their current and potential effectiveness in the roles to which prior Nomcom appointed them as well as the overall effectiveness of those bodies. best regards, john p.s. Personal note: despite personal interest in this, involvement as an advisor to IANA since the late 1970s and early 1980s, key roles in ICANN's creation and intermittent involvement since (as liaison to the Board, advisor on multiple issues (especially IDNs and i18n), and occasional consultant, I'd not putting my name forward for this role. The reasons are ultimately connected to the remarks above: I have no funding for an open-ended commitment that could involve significant time and travel and I'm already overextended on work I feel I need to do for the IETF. Especially with the added requirement for "diversity" From nobody Sat Jun 7 12:55:15 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA261A01C8; Sat, 7 Jun 2014 12:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLACkvgGxB40; Sat, 7 Jun 2014 12:55:12 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 4358D1A01BD; Sat, 7 Jun 2014 12:55:12 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 073C2F3C01E; Sat, 7 Jun 2014 15:54:55 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id pL7EK7CvDK5a; Sat, 7 Jun 2014 15:54:31 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-144-77.washdc.fios.verizon.net [96.255.144.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 3E7E1F3C009; Sat, 7 Jun 2014 15:54:32 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary=Apple-Mail-48-809380984 Date: Sat, 7 Jun 2014 15:54:19 -0400 Message-Id: To: internetgovtech@iab.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/W-eqZ4BCC4Kvs9mOt5WxtbOyBHQ Cc: IAB Subject: [Internetgovtech] NTIA IANA Stewardship Transition document posted X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 19:55:13 -0000 --Apple-Mail-48-809380984 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The process document was posted late yesterday by ICANN. It can be found = at: https://www.icann.org/news/announcement-2014-06-06-en Russ --Apple-Mail-48-809380984 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
The process document was posted late yesterday by ICANN. It can be found at: https://www.icann.org/news/announcement-2014-06-06-en

Russ

--Apple-Mail-48-809380984-- From nobody Mon Jun 9 01:15:16 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACA71A000E; Mon, 9 Jun 2014 01:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.259 X-Spam-Level: X-Spam-Status: No, score=0.259 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kTdkV-bhXSg; Mon, 9 Jun 2014 01:15:06 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id F189B1A0016; Mon, 9 Jun 2014 01:15:02 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.158.228]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s598EmTI026249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2014 01:14:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1402301702; x=1402388102; bh=ULSeGCMtjWtOvF/OsCUcrRF1UWWkj1y+ksOfOOfFOFs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=A/nGaA3AvSqf+Hm4yRcwcDxHmd/YkQMIp1fHtvLcDffQwBeqJvShmjPAKHaots56J fwFUnDAyebKjbqy4QfnYXG6ICJGqn1KVpH6U1P1Kg8/VLk32tcVQRT7ng2hZ+WZsSE IADcykEIJXCNojIhRrEQsCRuIhPsFiVNP9qLGAZA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1402301702; x=1402388102; i=@elandsys.com; bh=ULSeGCMtjWtOvF/OsCUcrRF1UWWkj1y+ksOfOOfFOFs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=zdVCbfoswTOdUTKEDgqskGeNZyF0ojoB85a/NYW6XIfNETkNyaKyVphx6dRO29lzA nFvyLPQ9UzpGEPXDW7H2bv4k8Hh2UIhe2WIr+egRq+stnRrZIskV9VqA5OLSfz9YKK TBY3wvZZBEbF87keiOaIUj1GBk/tOdK5rE1Bdu4Y= Message-Id: <6.2.5.6.2.20140608231017.06ddd160@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 09 Jun 2014 00:29:13 -0700 To: iesg@ietf.org From: S Moonesamy In-Reply-To: References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/ZcxlPVezi0q8HF-Dl6uXKu2AfDg Cc: John C Klensin , internetgovtech@iab.org, ietf@ietf.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 08:15:08 -0000 Hello, I think that John Klensin raised some valid points. At 08:49 07-06-2014, John C Klensin wrote: >Perhaps it is the best we can do, but, especially since members >of that committee represent themselves once appointed, I think >it would be wise for the IETF to publicly note the issues and >create some distance from this process. That would be >especially important if "we" eventually conclude that we have to >reject its final conclusion/ recommendations. The "best we can do" will be scrutinized and might highlight IETF internal issues. The pessimistic outlook is that the process will be controversial. Should the IETF be entangled in all that? It would be worthwhile to consider whether the IETF would like to have the ability to say "we disagree" and how it would be able to exercise that option when it is actively involved in the process. Regards, S. Moonesamy From nobody Mon Jun 9 03:01:40 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7581A004D for ; Mon, 9 Jun 2014 03:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpsCADqF_vx0 for ; Mon, 9 Jun 2014 03:01:34 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C5DA1A004B for ; Mon, 9 Jun 2014 03:01:33 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id x48so2703911wes.25 for ; Mon, 09 Jun 2014 03:01:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a2mpiRDPZ53ho6/BBcQlzIA1qvA2Kq0PhN9B6v8VCKs=; b=t0p2Gr+zlNSsnYVO7LfcTfTt2MMO7+jtnPTjntgD2rM4DR6zSa4EDu7G/+Fv97yJr9 T042YGwf6sTDrXopz+z7ndYNY049mP0Fr3g498FyzuM9vhJzC+bT5i2xb40mGRcNucbP eBgTzBP1YraE3roVbQWRN7xz9I+Bdsq03xCilM+asmzjLgeq2+pF45roLF2swSqjh7a9 je5R6TznGUPmcy5jLkm1/+W03phGxEIx3+tVa/LogUgu7yYIN8zW9TMhYYJkgnLWr/n/ XNFcqrQxI1ghIgVXf6P8FZ+6cKxkoYRArDdDxHI187o3/kncsX6ieglrL+rcx0k7Rswd A+CQ== MIME-Version: 1.0 X-Received: by 10.194.186.210 with SMTP id fm18mr29883384wjc.67.1402308092311; Mon, 09 Jun 2014 03:01:32 -0700 (PDT) Received: by 10.217.37.200 with HTTP; Mon, 9 Jun 2014 03:01:32 -0700 (PDT) In-Reply-To: References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> Date: Mon, 9 Jun 2014 12:01:32 +0200 Message-ID: From: =?UTF-8?Q?Roger_J=C3=B8rgensen?= To: John C Klensin Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/MoWC3M6z5dwagkSNjDZgq5BqudE Cc: internetgovtech@iab.org, The IESG , IETF discussion list Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 10:01:35 -0000 On Sat, Jun 7, 2014 at 5:49 PM, John C Klensin wrote: > Coordinating Committee have become open-ended. Unlike many of > the appointing groups, the IETF is not in a position to > underwrite those costs, i.e., to cover costs of time-salary > and/or travel to the various meetings so as to spread those > costs across the relevant community. The net effect is that > the only people who can plausibly represent the IETF are those > who: This part here made me think, can this issue about cost be the first step on the way to a multi-stakeholder for Internet where only the rich can participate? Rich as in having money AND time to travel to endless meetings around the world? ... I hope not. Personally I would like to get more involved but I can not see a way to get more involved, have no way to fund it, or see how I can get time to do more. Except that, it's great work and good to see discussion on the subject (IANA transition) and future for the Internet. > p.s. Personal note: despite personal interest in this, > involvement as an advisor to IANA since the late 1970s and early > 1980s, key roles in ICANN's creation and intermittent > involvement since (as liaison to the Board, advisor on multiple > issues (especially IDNs and i18n), and occasional consultant, > I'd not putting my name forward for this role. The reasons are > ultimately connected to the remarks above: I have no funding for > an open-ended commitment that could involve significant time and > travel and I'm already overextended on work I feel I need to do > for the IETF. > > > > Especially with the added requirement for "diversity" Any discussion without historic view have a possibility to repeat old mistakes... -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no From nobody Mon Jun 9 07:39:30 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0252A1A01C4; Mon, 9 Jun 2014 07:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.052 X-Spam-Level: X-Spam-Status: No, score=-1.052 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-TPNANf4TaW; Mon, 9 Jun 2014 07:39:24 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08AC41A01A9; Mon, 9 Jun 2014 07:39:24 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Wu0hg-0005QQ-Vo; Mon, 09 Jun 2014 10:37:40 -0400 Date: Mon, 09 Jun 2014 10:39:17 -0400 From: John C Klensin To: =?UTF-8?Q?Roger_J=C3=B8rgensen?= Message-ID: <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> In-Reply-To: References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/7at2J9bRC8lMqxqzQIwGUo4f7Mg Cc: internetgovtech@iab.org, The IESG Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 14:39:26 -0000 (IETF list removed from CCs -- this response is not an IETF-specific issue) --On Monday, June 09, 2014 12:01 +0200 Roger J=C3=B8rgensen wrote: > On Sat, Jun 7, 2014 at 5:49 PM, John C Klensin > wrote: >> Coordinating Committee have become open-ended. Unlike many = of >> the appointing groups, the IETF is not in a position to >> underwrite those costs, i.e., to cover costs of time-salary >> and/or travel to the various meetings so as to spread those >> costs across the relevant community. The net effect is that >> the only people who can plausibly represent the IETF are = those >> who: >=20 > This part here made me think, can this issue about cost be the > first step on the way to a multi-stakeholder for Internet > where only the rich can participate? Rich as in having money > AND time to travel to endless meetings around the world? ... I > hope not. I would have said "only the rich and those associated with institutions or employers with significant resources to dedicate to these processes and economic incentives to do so", but I don't think that makes a difference in practice. I think it is, or should be, a major issue. But, whatever it is, it certainly is not the "first step". Consider the following, remembering that some, but certainly not all, of these are side-effects of decisions taken with the best of intentions and that some may be appropriate on balance. (1) ICANN has developed a pattern in which effective participation requires hugs blocks of time, active involvement in multiple committees (most of which produce very long reports that take time to study and that spawn more committees that, in turn, require active effort). Attendance at meetings is effectively mandatory if one wants to be effective. In the interests of involving more diverse populations, many or most of those meetings are held in places that are either expensive for most of the world to reach or to participate in (even though ICANN stresses that attendance at their meetings is "free" because they don't charge a registration fee. Few of the local attendees at those meetings participate effectively long-term unless ICANN subsidizes their participation and the categories of people who get subsidized do not include individual technical experts. The net effect is that it is almost impossible for an individual technical expert, no affiliated with and representing some constituency group, to participate effectively unless either he or she is subsidized by ICANN (not exactly a set of choices that are unbiased by ICANN staff opinions about opinions they want to hear) or can contribute significant individual resources to the work (in your words, "only the rich"). (2) Several normally-sane people have suggested that at least some of the RIRs are dominated by a combination of large incumbent ISPs and entrenched groups of insiders, identifying the latter with apparent "board member for life" positions. I haven't been involved enough with the address process in the last dozen or more years to have an opinion about those claims, but the optics are poor. (3) Returning to ICANN, much of the representation and leverage for individual technical participants is supposed to come through the Nomcom process, but that process has been fairly consistently operated (and starved for resources) that have the presumably-accidental side effect of biasing both applications and selections in favor of those who are well-connected and able to invest considerable personal (or corporate) resources in ICANN participation. (4) Even the IETF is not immune from the problem: Increasing reliance on meetings, requirements (some formal) for meeting attendance for effective participation, and rising total costs of meeting attendance (some of them driven by a desire to show the IETF flag in more places in the world), all contribute to an environment in which predominantly the "rich" (or organizationally-well-supported) can play, especially in "leadership" roles. There are other examples, but I don't think a long catalogue would help illustrate the problem. I wish I knew what to do about it, but we are long past "first step"... and past any plausible claim that what we call a multistakeholder model is really representative of either the broad Internet community or even a broad spectrum of qualified expert opinions. best, john From nobody Mon Jun 9 08:23:12 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF461A01C5 for ; Mon, 9 Jun 2014 08:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKO6QNSMnTAj for ; Mon, 9 Jun 2014 08:23:06 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61AEC1A020B for ; Mon, 9 Jun 2014 08:23:06 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id mc6so3211621lab.30 for ; Mon, 09 Jun 2014 08:23:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Ik1dS5wRbKBlD0m88+NWvBzcErZnLm20baOkSOUJGF0=; b=wp5SIg92U9Wb0fM79FxHhO1BURPVJxbDg3cBztYFTeEbqMgPMq+Qzt1hDAeg13opZy iR6SAq06toCjqZwY5n5X53t5Qa8wTfCPjt1jcdlQHLyE2Qf81qGPde0qr5fTX2eO4ed3 Xek+JDGRJmnn7LPEDOmrfx885zTTHxieOPkQLP7bKH3xAD61Kb8LaB31ifNMjjU2SHy7 PPESqn7VY2TnUKu/S0stYvOIwvUoaSLIMDHJmYqIrOF6/1i4PQEy0IkaHgi1haQ36K+k mSrZ2qddkMXkhDMJa8iUu1u+rQrUqQP06Ym1BnKDP39tqe2T3v1ZfbufA4lK04d4F1x0 Jx8Q== MIME-Version: 1.0 X-Received: by 10.152.4.1 with SMTP id g1mr18299597lag.20.1402327384333; Mon, 09 Jun 2014 08:23:04 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.206.9 with HTTP; Mon, 9 Jun 2014 08:23:04 -0700 (PDT) In-Reply-To: <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> Date: Mon, 9 Jun 2014 11:23:04 -0400 X-Google-Sender-Auth: vIBAPr4oBOogxZNjlIdGPB0-2tw Message-ID: From: Barry Leiba To: John C Klensin Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/s4JmW526Oh4icSjjIC8H2TvoCNM Cc: =?ISO-8859-1?Q?Roger_J=F8rgensen?= , internetgovtech@iab.org, The IESG Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 15:23:07 -0000 > (IETF list removed from CCs -- this response is not an > IETF-specific issue) Indeed. > I would have said "only the rich and those associated with > institutions or employers with significant resources to dedicate > to these processes and economic incentives to do so", but I > don't think that makes a difference in practice. ... > (1) ICANN has developed a pattern in which effective > participation requires hugs blocks of time, active involvement > in multiple committees (most of which produce very long reports > that take time to study and that spawn more committees that, in > turn, require active effort). Attendance at meetings is > effectively mandatory if one wants to be effective. And so, pulling this back to the subject at hand: We can't change that for the purpose of appointing representatives to the Coordination Group. But what we can do is ask our representatives to (1) when the Coordination Group sets up its mode of operation, influence the group to make its operation as accessible as possible to those can't always travel to the meetings, and (2) work toward a plan that changes that aspect of ICANN participation in general. Barry From nobody Mon Jun 9 08:29:06 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729361A01CE for ; Mon, 9 Jun 2014 08:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgmCZVDki7xe for ; Mon, 9 Jun 2014 08:29:03 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59EA21A0068 for ; Mon, 9 Jun 2014 08:29:03 -0700 (PDT) Received: from mx1.yitter.info (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id B5F0A8A031; Mon, 9 Jun 2014 15:29:01 +0000 (UTC) Date: Mon, 9 Jun 2014 11:29:00 -0400 From: Andrew Sullivan To: Barry Leiba Message-ID: <20140609152900.GG27145@mx1.yitter.info> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/GmAASm3-DEhJBkp2SUDxYFmle1A Cc: John C Klensin , Roger =?utf-8?Q?J=C3=B8rgensen?= , internetgovtech@iab.org, The IESG Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 15:29:04 -0000 On Mon, Jun 09, 2014 at 11:23:04AM -0400, Barry Leiba wrote: > those can't always travel to the meetings, and (2) work toward a plan > that changes that aspect of ICANN participation in general. I do not believe that "fixing ICANN" is part of the remit of the group we're talking about. There is a parallel effort about "ICANN accountabilty", and I encourage people who are interested in that to put some effort into it. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Jun 9 08:40:35 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFE51A01C7; Mon, 9 Jun 2014 08:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlKbARPdf_2b; Mon, 9 Jun 2014 08:40:29 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DA021A01B5; Mon, 9 Jun 2014 08:40:29 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Wu1ej-0005Vt-Pt; Mon, 09 Jun 2014 11:38:41 -0400 Date: Mon, 09 Jun 2014 11:40:18 -0400 From: John C Klensin To: Barry Leiba Message-ID: In-Reply-To: References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> 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 X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/PyDM4gouhVkGzjUKB2ZhieDfmYA Cc: =?UTF-8?Q?Roger_J=C3=B8rgensen?= , internetgovtech@iab.org, The IESG Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 15:40:31 -0000 --On Monday, June 09, 2014 11:23 -0400 Barry Leiba wrote: >> (IETF list removed from CCs -- this response is not an >> IETF-specific issue) > > Indeed. > >> I would have said "only the rich and those associated with >> institutions or employers with significant resources to >> dedicate to these processes and economic incentives to do >> so", but I don't think that makes a difference in practice. > ... >> (1) ICANN has developed a pattern in which effective >> participation requires hugs blocks of time, active involvement >> in multiple committees (most of which produce very long >> reports that take time to study and that spawn more >> committees that, in turn, require active effort). Attendance >> at meetings is effectively mandatory if one wants to be >> effective. > > And so, pulling this back to the subject at hand: > We can't change that for the purpose of appointing > representatives to the Coordination Group. While I would not advise it (the ground looks fairly distant from our position on this petard), we could, in principle, object formally to being asked to appoint members of a Coordination Committee unless the resource and similar requirements are clear. We could even decline to make appointments until that was fixed and claim, in public, that the Committee and its decisions were not legitimate multistakeholder efforts until that was done. As I say, I don't recommend any of that... but it all depends on how much we care about these issues. I suggest that the evidence so far is that we care in principle but much less so in practice. > But what we can do > is ask our representatives to (1) when the Coordination Group > sets up its mode of operation, influence the group to make its > operation as accessible as possible to those can't always > travel to the meetings, As a purely pragmatic observation, when the members of a committee (almost any committee) are appointed under particular circumstances, the vast majority of the members will consider those conditions to be just fine (obviously they are a reasonable group and the constraints didn't prevent any of them from volunteering and being appointed). I note that observation applies to the IESG and IAOC as much as to anything that ICANN might do. So, sure. In addition, this group has a very short time horizon, perhaps one that is too short to do its critical-path job well. Debates about different ways in which the group could conduct its business could be seen as obstructing and impeding getting to results (and probably would be). It is not clear that encouraging such debates is in our interest. > and (2) work toward a plan that > changes that aspect of ICANN participation in general. That discussion will almost certainly be excluded on the grounds that it is part of the separate ICANN process revision and review processes, processes that are, IMO, completely captive to the considerations about which Roger and I are expressing concern. best, john From nobody Mon Jun 9 08:41:37 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0F71A01D9 for ; Mon, 9 Jun 2014 08:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KioZQYmE4_B for ; Mon, 9 Jun 2014 08:41:33 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61A9A1A01C7 for ; Mon, 9 Jun 2014 08:41:33 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 1F4B01B81C7 for ; Mon, 9 Jun 2014 08:41:33 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 04DCD190064; Mon, 9 Jun 2014 08:41:33 -0700 (PDT) Received: from [10.0.10.40] (174.62.147.182) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Jun 2014 08:41:32 -0700 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: Date: Mon, 9 Jun 2014 11:41:30 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> To: Barry Leiba X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [174.62.147.182] Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/BRWLfcTFvbNGeTgN8UgXQ6tlpjA Cc: John C Klensin , =?iso-8859-1?Q?Roger_J=F8rgensen?= , internetgovtech@iab.org, The IESG Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 15:41:34 -0000 > We can't change that for the purpose of appointing representatives to > the Coordination Group. We could also ask ICANN to fund the participants if there were someone = we'd want to participate who otherwise would not be able to. Whether = we should ask, and whether they would do it, and whether it would be = appropriate for them to do it are questions to which I do not know the = answers. But if there's a real problem here, it would be worth = considering ways to solve it that don't rely on promises that might not = be able to be kept. From nobody Mon Jun 9 08:46:17 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E082E1A0216 for ; Mon, 9 Jun 2014 08:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hj-6EAPAKidt for ; Mon, 9 Jun 2014 08:45:53 -0700 (PDT) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11AD41A01ED for ; Mon, 9 Jun 2014 08:45:52 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id cc10so146850wib.12 for ; Mon, 09 Jun 2014 08:45:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+UUTOjwc/FKaT+HHWglduiSUz4LsigyB7m+oGT/Ha14=; b=ckcRihcYY7Hhoa3x5HN2EUVd7arKkLgZ8d0V9YOaNABMHhOO6uws9RUUlu1btVkdhZ nTF3gfv9ak+qYVnFbMxaZhB1Od7igrEgn754br28A+JGWk4+a1gDS4LadBZZQQVpiUPS eJIWMCVT+Bs7KgRpWSZ8FrW7RIe2FnoY7U4cXmzvWUxLJVf4IfNnt4L/ZukhcLTYDZ6X zyepJVU9aP+JQY+eRnhcY6Mf0MazbkgKOZhP5nLl3wluJcJ/et5UPmVmk6svk8kfeVqF jlWkB4azPieLncizhEbngkJRUQEuQihEKfiKAZwGphkzmAKOy1g3J8yp7Gwb4gAtyrJo +vYg== X-Gm-Message-State: ALoCoQkYmg7yxLviGuJk8lmnct4wrzjVovKxa9RIggpEBpyh8tIQipm6aPc3FVGqiuBGIqJVqO5b MIME-Version: 1.0 X-Received: by 10.180.103.228 with SMTP id fz4mr30213137wib.4.1402328751381; Mon, 09 Jun 2014 08:45:51 -0700 (PDT) Received: by 10.194.248.233 with HTTP; Mon, 9 Jun 2014 08:45:51 -0700 (PDT) In-Reply-To: <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> Date: Mon, 9 Jun 2014 08:45:51 -0700 Message-ID: From: Warren Kumari To: John C Klensin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/0ET_rnvC1vFhB3Uqp3ik3Fo2qdc Cc: =?UTF-8?Q?Roger_J=C3=B8rgensen?= , internetgovtech@iab.org, The IESG Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 15:46:09 -0000 On Mon, Jun 9, 2014 at 7:39 AM, John C Klensin wrote: > (IETF list removed from CCs -- this response is not an > IETF-specific issue) > > --On Monday, June 09, 2014 12:01 +0200 Roger J=C3=B8rgensen > wrote: > >> On Sat, Jun 7, 2014 at 5:49 PM, John C Klensin >> wrote: >>> Coordinating Committee have become open-ended. Unlike many of >>> the appointing groups, the IETF is not in a position to >>> underwrite those costs, i.e., to cover costs of time-salary >>> and/or travel to the various meetings so as to spread those >>> costs across the relevant community. The net effect is that >>> the only people who can plausibly represent the IETF are those >>> who: >> >> This part here made me think, can this issue about cost be the >> first step on the way to a multi-stakeholder for Internet >> where only the rich can participate? Rich as in having money >> AND time to travel to endless meetings around the world? ... I >> hope not. > > I would have said "only the rich and those associated with > institutions or employers with significant resources to dedicate > to these processes and economic incentives to do so", but I > don't think that makes a difference in practice. > > I think it is, or should be, a major issue. But, whatever it > is, it certainly is not the "first step". Consider the > following, remembering that some, but certainly not all, of > these are side-effects of decisions taken with the best of > intentions and that some may be appropriate on balance. > > (1) ICANN has developed a pattern in which effective > participation requires hugs blocks of time, active involvement > in multiple committees (most of which produce very long reports > that take time to study and that spawn more committees that, in > turn, require active effort). Attendance at meetings is > effectively mandatory if one wants to be effective. Yup. A number of folk tried pushing for much more work being done on (hopefully open) mailing lists, but without much success. > In the > interests of involving more diverse populations, many or most of > those meetings are held in places that are either expensive for > most of the world to reach or to participate in (even though > ICANN stresses that attendance at their meetings is "free" > because they don't charge a registration fee. Few of the local > attendees at those meetings participate effectively long-term > unless ICANN subsidizes their participation and the categories > of people who get subsidized do not include individual technical > experts. The net effect is that it is almost impossible for an > individual technical expert, no affiliated with and representing > some constituency group, to participate effectively unless > either he or she is subsidized by ICANN (not exactly a set of > choices that are unbiased by ICANN staff opinions about opinions > they want to hear) or can contribute significant individual > resources to the work (in your words, "only the rich"). Yup. This effectively limits the ICANN version of multistakeholderism[0] to be those who have some sort of financial incentive to fly all over the world to participate. (Last year this was Beijing, Durban, Buenos-Aires. This year it is Singapore, London, Los Angeles) > > (2) Several normally-sane people have suggested that at least > some of the RIRs are dominated by a combination of large > incumbent ISPs and entrenched groups of insiders, identifying > the latter with apparent "board member for life" positions. I > haven't been involved enough with the address process in the > last dozen or more years to have an opinion about those claims, > but the optics are poor. > > (3) Returning to ICANN, much of the representation and leverage > for individual technical participants is supposed to come > through the Nomcom process, but that process has been fairly > consistently operated (and starved for resources) that have the > presumably-accidental side effect of biasing both applications > and selections in favor of those who are well-connected and able > to invest considerable personal (or corporate) resources in > ICANN participation. > > (4) Even the IETF is not immune from the problem: Increasing > reliance on meetings, requirements (some formal) for meeting > attendance for effective participation, and rising total costs > of meeting attendance (some of them driven by a desire to show > the IETF flag in more places in the world), all contribute to an > environment in which predominantly the "rich" (or > organizationally-well-supported) can play, especially in > "leadership" roles. Yes, but the IETF does at least *try* to go to where the participants are, and tries hard to keep the hotel and similar costs under control - I participate in both IETF and ICANN[1] and my IETF expenses are consistently lower than my ICANN ones. While attendance at some portion of IETF meeting is required for some functions (such as NonCom[3]) it is entirely possible to participate effectively in the IETF without attending any meetings. Yes, it is easier if you show up at the meetings, but still possible if you are not able to travel. > > There are other examples, but I don't think a long catalogue > would help illustrate the problem. I wish I knew what to do > about it, but we are long past "first step"... and past any > plausible claim that what we call a multistakeholder model is > really representative of either the broad Internet community or > even a broad spectrum of qualified expert opinions. Step one is getting the community to acknowledge that there is a problem -- and I'm not sure that there is actually an issue *from the majority of ICANN participants point of view*. I believe that that ICANN "leadership" would like to be more inclusive / have greater representation, but changing the culture (especially in a way that does not benefit those whose culture you are trying to change) is hard. Unfortunately I think that only ways to change this is: 1: for those who are not participating to actually show up for a few meetings and actively push for change. You need to be passionate about this though to be able to justify spending $$$ to attend a meeting. 2: and to provide feedback to the ICANN Accountability work. W [0]: m18m? [1]: I'm incredibly luckily in that my employer is willing to let me traipse all over the world working on what *I* think is best for the Internet. Not many people have this luxury (and we should not reply on this for participation). [3]: Which I think makes sense. You need to know the candidates, and be known and available to get feedback on the candidates. > > best, > john > > > > > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech From nobody Mon Jun 9 08:57:10 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4741A025E for ; Mon, 9 Jun 2014 08:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBGOITIO2ztu for ; Mon, 9 Jun 2014 08:57:00 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A240A1A025B for ; Mon, 9 Jun 2014 08:56:59 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id z12so2469552wgg.25 for ; Mon, 09 Jun 2014 08:56:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=zmc+QLzLhvoGf0hlZBb/esHEoC5PVUYQhHAHHBcekA8=; b=I/LHmNlABF57mSvslqhEoBRTn7MCNmIl4g3Tab/XnSMBdGARHqMCJ4b0VEI0yCQvyO h//Ky8LXbhzfFyizRCr9laqpanpJe1pnIpGLbQ3dXhzt2iPuz366qIHhEx84c/Fx1kbB AFPlKOhAgVp7SSOF6NIkv2zn0e3kgLRSYbjAnXxRby5V++80K//XUpeFUvt11OHRtY/P u9HwK+V0bzqwdGniHdhx7ml17NF+JC2K+4Cgy8x5cz0mXvxqp5l6ro8Vr8bNvkQ2znlf KNyMvhJXB1omIzY4oWMkhMAtnll3+rhN5NRkK48Vnxvx/tLldsdlOHeLiwzku6WtMmwN 9nzQ== X-Received: by 10.14.113.136 with SMTP id a8mr3723724eeh.0.1402329418141; Mon, 09 Jun 2014 08:56:58 -0700 (PDT) Received: from [10.0.0.24] ([98.234.222.98]) by mx.google.com with ESMTPSA id g8sm45827808eep.0.2014.06.09.08.56.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Jun 2014 08:56:54 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_D5E39182-8FF7-4A27-815F-19BE550F58E4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Bob Hinden In-Reply-To: <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> Date: Mon, 9 Jun 2014 08:56:48 -0700 Message-Id: <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/kCHghs4i3uvVe3_GcSu-1Tk_UkY Cc: =?iso-8859-1?Q?Roger_J=F8rgensen?= , Bob Hinden , internetgovtech@iab.org, The IESG , John C Klensin , Barry Leiba Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 15:57:01 -0000 --Apple-Mail=_D5E39182-8FF7-4A27-815F-19BE550F58E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ted, On Jun 9, 2014, at 8:41 AM, Ted Lemon wrote: >> We can't change that for the purpose of appointing representatives to >> the Coordination Group. >=20 > We could also ask ICANN to fund the participants if there were someone = we'd want to participate who otherwise would not be able to. Whether = we should ask, and whether they would do it, and whether it would be = appropriate for them to do it are questions to which I do not know the = answers. But if there's a real problem here, it would be worth = considering ways to solve it that don't rely on promises that might not = be able to be kept. It is my understanding from the process that ISOC is doing, that ICANN = will provide travel support for people who are participants in the = coordination group. We had the same question. It would be good if someone from ICANN would confirm that here. Bob --Apple-Mail=_D5E39182-8FF7-4A27-815F-19BE550F58E4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTldlAAAoJEK7rdBF357uo5RAH/j4M88Ckh2DrQM5mKllnh/9Y Dm52e9yfwM6rc3sFJLu95OdJcXdOILD0yvtJ7m+Je8H5fvOZghIFriw6QMpaL/L+ 7mZ9Jn70gjdjiGHfZ1PyK9RFMhOD18aY+dGI2w8Zx3BUKAUI8Z8j48H5bRSGcDFo usnmfPZkcm0D/F4m8b+oo/jQAIy4Inlf6xPH/9ucR8iJs+57ppwIxWQFvpW6f2jR vD/11lrHuXquqH0L75o9/Aw7dwqZUXDgPPhESjkpgYL+IkaJT6SmtBZ2gD8kzpEG 02C5mLeZy+riXrbanWOND05y3qFW8cVHPgJDQtIkFzteUBkZD6ICsXhEXriIQRQ= =wU+4 -----END PGP SIGNATURE----- --Apple-Mail=_D5E39182-8FF7-4A27-815F-19BE550F58E4-- From nobody Mon Jun 9 09:01:12 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F501A023F for ; Mon, 9 Jun 2014 09:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCvoLtbDi6F9 for ; Mon, 9 Jun 2014 09:01:09 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B35691A0221 for ; Mon, 9 Jun 2014 09:01:09 -0700 (PDT) Received: from mx1.yitter.info (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 99DD98A031; Mon, 9 Jun 2014 16:01:08 +0000 (UTC) Date: Mon, 9 Jun 2014 12:01:01 -0400 From: Andrew Sullivan To: internetgovtech@iab.org, The IESG Message-ID: <20140609160101.GJ27145@mx1.yitter.info> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/FLykzee9i9b7ANMND1ejkkbQjiE Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 16:01:11 -0000 On Mon, Jun 09, 2014 at 08:56:48AM -0700, Bob Hinden wrote: > > It is my understanding from the process that ISOC is doing, that ICANN will provide travel support for people who are participants in the coordination group. We had the same question. > If that's the case, it isn't indicated in the materials ICANN posted the other day as far as I can see. Also, does anyone worry about the potential conflict of having the organization whose contractual relationship is going to change pay for everyone's participation (particularly when that participation is apparently on an individual basis)? A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Jun 9 09:15:55 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 399C51A0266 for ; Mon, 9 Jun 2014 09:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zm5Fdmz8zqfF for ; Mon, 9 Jun 2014 09:15:50 -0700 (PDT) Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C31C41A025F for ; Mon, 9 Jun 2014 09:15:50 -0700 (PDT) Received: by mail-pb0-f43.google.com with SMTP id up15so5038792pbc.16 for ; Mon, 09 Jun 2014 09:15:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=mRupJYvk626E0/b0hGWgAJUEtZPPjjgOwoqjqUsW+Ns=; b=EF8Grdtr38wwSuAIhDCNjIQQ0rMSzZ9Jg0EItOX1wg13l7EorAr3UJ5fRnE7xvcmEw YqzKvj9Ific1/MxXL9DNQrelpJwvXZlVPkTKDKTZ0eE9u+xYlBqGKbfYVSOHVfKDpSx0 +UtIvZ/sOj+6T00Pn9SlgHgnFKB2ieX8StSppzRMyQzsFWbOYuF+GwqMheUq3xZTsHG8 dTBsLbsqmHRZQl+uuYdrRWt0HE8wYdwHUyZBmAnTikR0gaSVhDsFIvL60l5kujv5o9sJ 1NubMCP1zgqHOCEO/ybFZdGpoglRfdCplBL4T0NF9W0ZwqpFmwP7mLxYTDhr+NquoZwP AEQw== X-Gm-Message-State: ALoCoQlMQ+dJujR7SdJa2ip1BfZlm7kyAprtuzHBSDOiPsGB1Ut/GPd+Esj4NQU3Y2s9H3Ij91vw X-Received: by 10.66.249.165 with SMTP id yv5mr5547488pac.79.1402330550295; Mon, 09 Jun 2014 09:15:50 -0700 (PDT) Received: from [10.0.1.3] (c-24-6-168-86.hsd1.ca.comcast.net. [24.6.168.86]) by mx.google.com with ESMTPSA id hb10sm64740421pbd.75.2014.06.09.09.15.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Jun 2014 09:15:49 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_D4635EBE-595F-42D6-A845-DACFE7D5A6DE"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: David Conrad In-Reply-To: <20140609160101.GJ27145@mx1.yitter.info> Date: Mon, 9 Jun 2014 09:15:42 -0700 Message-Id: <63E9BDF5-7DB0-4B72-BAF1-B1818E64DB2B@virtualized.org> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/9ZQnUZ0FeZtW5XyMQRF-UDdS9-c Cc: internetgovtech@iab.org, The IESG Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 16:15:53 -0000 --Apple-Mail=_D4635EBE-595F-42D6-A845-DACFE7D5A6DE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Andrew, On Jun 9, 2014, at 9:01 AM, Andrew Sullivan = wrote: > Also, does anyone worry about the potential conflict of having the > organization whose contractual relationship is going to change pay for > everyone's participation (particularly when that participation is > apparently on an individual basis)? Given ICANN was explicitly asked by the U. S. Dept. of Commerce, NTIA = "to convene global stakeholders to develop a proposal to transition the = current role played by NTIA"[1], no, not really. Regards, -drc [1] = http://www.ntia.doc.gov/press-release/2014/ntia-announces-intent-transitio= n-key-internet-domain-name-functions --Apple-Mail=_D4635EBE-595F-42D6-A845-DACFE7D5A6DE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJTld2uAAoJENV6ebf0/4rXxM4IAL9cpv/nxjwJcLSe14noMGH2 5YROxpFTxsADK+ySa0AcmCGGCH/QlGhcxb713sGamhq4HhNFbRmKdFVx7qhapJhz G6pGYVABdwsGRMOTzsGitqMG4DDxxTJnQNXOgk8FXZzU+WtTMemNQ3q33MVyhKsB kf0Ht5/6j9pAHoVgGBk55gU3Kz0uybi0v9eRj4rq2CmxKfjh64oSlLzJywOt8EIS KTFiOElJzdXbH3pybyd5pWnYAraEv34b0avpzPg/lsl2gYFdX2jrergKmlCMXRI+ FahSZ9hO/l4gZ1EywBt4VrxNgbTGy0bvYHatNsiOs5TLxzzq3w+eWreyEvkl0GA= =y75y -----END PGP SIGNATURE----- --Apple-Mail=_D4635EBE-595F-42D6-A845-DACFE7D5A6DE-- From nobody Mon Jun 9 09:19:59 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653831A0269 for ; Mon, 9 Jun 2014 09:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E_UJa3XG1gmN for ; Mon, 9 Jun 2014 09:19:57 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 730701A01D0 for ; Mon, 9 Jun 2014 09:19:57 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 54C3F1B81C7 for ; Mon, 9 Jun 2014 09:19:57 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 41D29190064; Mon, 9 Jun 2014 09:19:57 -0700 (PDT) Received: from [10.0.10.40] (174.62.147.182) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Jun 2014 09:19:57 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: <20140609160101.GJ27145@mx1.yitter.info> Date: Mon, 9 Jun 2014 12:19:53 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <204A4F6F-908D-49EC-A251-A182EABAB1DF@nominum.com> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [174.62.147.182] Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/ji69ijq5Rym4KFx7oEEhgwoqhqU Cc: internetgovtech@iab.org, The IESG Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 16:19:58 -0000 On Jun 9, 2014, at 12:01 PM, Andrew Sullivan = wrote: > Also, does anyone worry about the potential conflict of having the > organization whose contractual relationship is going to change pay for > everyone's participation (particularly when that participation is > apparently on an individual basis)? Only if the terms allow them to rescind the travel offer if they don't = like what the participant says at the meetings. From nobody Mon Jun 9 09:38:08 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D88D1A01EA for ; Mon, 9 Jun 2014 09:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Si7_dYR4KEnC for ; Mon, 9 Jun 2014 09:38:04 -0700 (PDT) Received: from bmtwo.vm.bytemark.co.uk (mail.firsthand.net [212.110.188.53]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CD0E1A0096 for ; Mon, 9 Jun 2014 09:38:04 -0700 (PDT) X-No-Relay: not in my network DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=firsthand.net; b=SYyGtWHCqqnf7jk+Dv4MVpeal1FUbdnlpprOkHQQG1Mp/KeYR1PZm+/M7qmEhWg7s88m8/JzYNLNscXQrPBiLPJOJ3Sx3d6fgF3SzVBiiK+W/FSIB8RuqmEY0mxUBPfY; h=X-No-Relay:X-No-Relay:X-No-Relay:X-No-Relay:X-No-Relay:Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type; X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from orionlocal.local (host-2-96-80-208.as13285.net [2.96.80.208]) by bmtwo.vm.bytemark.co.uk (Postfix) with ESMTPSA id A0FFAE0102; Mon, 9 Jun 2014 16:37:55 +0100 (BST) Message-ID: <5395E2E5.9010300@firsthand.net> Date: Mon, 09 Jun 2014 17:37:57 +0100 From: Christian de Larrinaga User-Agent: Postbox 3.0.10 (Macintosh/20140526) MIME-Version: 1.0 To: =?UTF-8?B?Um9nZXIgSsO4cmdlbnNlbg==?= References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigE985FBEB1D99C5F75A6E4F48" Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/jibQ-3HEyzlfOwIVJC41Zg4FIGk Cc: John C Klensin , internetgovtech@iab.org, The IESG , IETF discussion list Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: cdel@firsthand.net List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 16:38:06 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE985FBEB1D99C5F75A6E4F48 Content-Type: multipart/alternative; boundary="------------040609000209060709030708" This is a multi-part message in MIME format. --------------040609000209060709030708 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It would be a good thing for I* bodies to reflect on these points that John and Roger are making and provide meaningful support for individual actors to engage effectively and in a balanced way or admit that they are not multi stakeholder. Christian Roger J=C3=B8rgensen wrote: > On Sat, Jun 7, 2014 at 5:49 PM, John C Klensin wrot= e: > >> Coordinating Committee have become open-ended. Unlike many of >> the appointing groups, the IETF is not in a position to >> underwrite those costs, i.e., to cover costs of time-salary >> and/or travel to the various meetings so as to spread those >> costs across the relevant community. The net effect is that >> the only people who can plausibly represent the IETF are those >> who: > > This part here made me think, can this issue about cost be the first > step on the way to a multi-stakeholder for Internet where only > the rich can participate? Rich as in having money AND time to travel > to endless meetings around the world? ... I hope not. > > Personally I would like to get more involved but I can not see a way > to get more involved, have no way to fund it, or see how I can get > time to do more. > > > Except that, it's great work and good to see discussion on the > subject (IANA transition) and future for the Internet. > > > >> p.s. Personal note: despite personal interest in this, >> involvement as an advisor to IANA since the late 1970s and early >> 1980s, key roles in ICANN's creation and intermittent >> involvement since (as liaison to the Board, advisor on multiple >> issues (especially IDNs and i18n), and occasional consultant, >> I'd not putting my name forward for this role. The reasons are >> ultimately connected to the remarks above: I have no funding for >> an open-ended commitment that could involve significant time and >> travel and I'm already overextended on work I feel I need to do >> for the IETF. >> >> >> >> Especially with the added requirement for "diversity" > > Any discussion without historic view have a possibility to repeat old > mistakes... > > > --=20 Christian de Larrinaga FBCS, CITP, MCMA ------------------------- @ FirstHand ------------------------- +44 7989 386778 cdel@firsthand.net ------------------------- --------------040609000209060709030708 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =
It= =20 would be a good thing for I* bodies to reflect on these points that John and Roger are making and provide meaningful support for individual=20 actors to engage effectively and in a balanced way or admit that they=20 are not multi stakeholder.



Christian

Roger=20 J=C3=B8rgensen wrote:
On Sat, Jun 7, 2014 at 5:49 PM, John C Klen=
sin =
<john-ietf@jck.com> wrote:
<snip>

Coordinating Committee hav=
e become open-ended.  Unlike many of
the appointing groups, the IETF is not in a position to
underwrite those costs, i.e., to cover costs of time-salary
and/or travel to the various meetings so as to spread those
costs across the relevant community.   The net effect is that
the only people who can plausibly represent the IETF are those
who:


This part here made me think, can this issue about cost be the first
step on the way to a multi-stakeholder for Internet where only
the rich can participate? Rich as in having money AND time to travel
to endless meetings around the world? ... I hope not.

Personally I would like to get more involved but I can not see a way
to get more involved, have no way to fund it, or see how I can get
time to do more.


Except that, it's great work and good to see discussion  on the
subject (IANA transition) and future for the Internet.


<snip>

p.s. Personal note: despit=
e personal interest in this,
involvement as an advisor to IANA since the late 1970s and early
1980s, key roles in ICANN's creation and intermittent
involvement since (as liaison to the Board, advisor on multiple
issues (especially IDNs and i18n), and occasional consultant,
I'd not putting my name forward for this role.  The reasons are
ultimately connected to the remarks above: I have no funding for
an open-ended commitment that could involve significant time and
travel and I'm already overextended on work I feel I need to do
for the IETF.



Especially with the added requirement for "diversity"


Any discussion without historic view have a possibility to repeat old
mistakes...

--
Christian de=20 Larrinaga
FBCS, CITP, MCMA
-------------------------
@ FirstHand -------------------------
+44 7989 386778
= cdel@firsthand.net
-------------------------
--------------040609000209060709030708-- --------------enigE985FBEB1D99C5F75A6E4F48 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCgAGBQJTleLmAAoJEO8NEF3l27YrEpoH/3/2ufQbCGTsxC9Lv2TbCSaM gMW0tjSjh0PThzyRA/S61irwPGQ6srhYR7n+Zf7RkVzWE8pC4XLXjlna/dvv5cm2 T/BRWADVPTmMAl0kkeIKBepVHhVFBTSDz45KMgz+S070UfeBL4OR1yz+0+SxDmpa Jv8a/d4HJK2cpP7rCZcP5mxggEvBqTUPWK/E8pvyeJW0KEMph4/F+Abu4C8reoIS EvV7HyFVhAxQa3n618EYhZidSpSvCSU3yTPp3/owmJ+pYzo89vKvIeaIk5i8S5zF Jp2J46XUc2XOhvzhLR0yE+hEF3q4dBAKEkiPJJ4kKuafG8cnaJ93D9HUHLkSNHE= =HGKb -----END PGP SIGNATURE----- --------------enigE985FBEB1D99C5F75A6E4F48-- From nobody Mon Jun 9 09:57:06 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 119971A0282 for ; Mon, 9 Jun 2014 09:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aT2b2XAhFgMA for ; Mon, 9 Jun 2014 09:57:02 -0700 (PDT) Received: from waikiki.gih.co.uk (salsa.gih.co.uk [IPv6:2a00:19e8:10:5::b]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4EC1A0274 for ; Mon, 9 Jun 2014 09:57:01 -0700 (PDT) Received: from waikiki.gih.co.uk (localhost6.localdomain6 [IPv6:::1]) by waikiki.gih.co.uk (Postfix) with ESMTP id 638CD18F3B5; Mon, 9 Jun 2014 17:56:58 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gih.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mahalo1; bh=/+cv8IL9i BNhLrXlwV10wc/NJu0=; b=Kjkx7ZiHw4FIcwH7GTpLhJ/CGG/FeSkjRUbVCI6EZ 0Y6JvriQD5cB60cgnI5XMjuglSoaH4W1OIvA6yqE52h/DVMqOW742JZAAUYsSbKK JaHyYgA2f+oBsyGUsap0+pPbPdSfaTOLafzyG9GZ50VHlHTLoNG5EGHto1v5vHB2 dA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gih.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mahalo1; b=H4h 30bx+DUP85c7/q+352V7Xv1+ZimL5zQUKOIPleVrD1ICWA+hGxD1Fxg14p3F68+Y 5KO4Ct0s3aCoz0GLnX9i9APv266emnaBI+NOvvsEJzgZL/xt0/+JWFbtJX1FTedb ahZ/D3s98uTQQnQOZfMXq1x8eOyFncCkvLe+Qr5g= Received: from [IPv6:2a02:120b:2c64:b5e0:2402:35b0:d2d0:d2ec] (unknown [IPv6:2a02:120b:2c64:b5e0:2402:35b0:d2d0:d2ec]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by waikiki.gih.co.uk (Postfix) with ESMTPSA id 66B6518F3AF; Mon, 9 Jun 2014 17:56:57 +0100 (BST) Message-ID: <5395E757.6080809@gih.com> Date: Mon, 09 Jun 2014 18:56:55 +0200 From: Olivier MJ Crepin-Leblond User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Bob Hinden , Ted Lemon References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> In-Reply-To: <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/ds6K-F4u-eFoRyfasngkyr5dvfk Cc: John C Klensin , =?ISO-8859-1?Q?Roger_J=F8rgensen?= , Barry Leiba , internetgovtech@iab.org, The IESG Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 16:57:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bob, On 09/06/2014 17:56, Bob Hinden wrote: > On Jun 9, 2014, at 8:41 AM, Ted Lemon wrote: > >>> >> We can't change that for the purpose of appointing representatives to >>> >> the Coordination Group. >> > >> > We could also ask ICANN to fund the participants if there were someone we'd want to participate who otherwise would not be able to. Whether we should ask, and whether they would do it, and whether it would be appropriate for them to do it are questions to which I do not know the answers. But if there's a real problem here, it would be worth considering ways to solve it that don't rely on promises that might not be able to be kept. > It is my understanding from the process that ISOC is doing, that ICANN will provide travel support for people who are participants in the coordination group. We had the same question. > > It would be good if someone from ICANN would confirm that here. I cannot purport to be "from ICANN" but with the ALAC having 2 seats on that committee, there is an understanding that ICANN Supporting Organisation & Advisory Committee participants will be funded. Having participated at NetMundial thanks to being funded as an Internet community member, along with many other people who were not explicit ICANN community members (I received no perks whatsoever compared to any other Internet community members), I would venture out to extrapolate that funding will be available for all participants should F2F meetings be convened (and indeed, it looks like they will). You will note that the composition of the working group is such that end user representation is quite weak (by its numbers), so I really hope that other organisations such as the IETF as well as ISOC will consider emphasizing the end user input, perhaps by appointing well known champions of the cause. Kind regards, Olivier (speaking in a personal capacity) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTledWAAoJENb2Jfn69hcjA3MH/AnMBUqjFaMQMQiemLJc8dfw FTQ191EekNeXirS0trQAS8ZRUAcHSySOvgFqwhWGj/aQDrw3l9pXLDGX3ms3dws7 A5b7gAXvvEdm93MhhDtK70id2knKh2MJjDkk0q34JyYQHjSIcksHliyWXB6GiJBr kBavkHnzW1XXlMt6JOG/tdX7xLlhkL7vgZwi8ZX3MA6OIuadJSBb5bLxFbLohk7Q wu2gCGu3u0eK4AJVP4+PwELRiG2kiSQ8EcZZzXi3LonZ4auKwtYAtD7WCRU6scIw dYHXU2MKZynufc7l7FUsQqXLO5OG7CPtavdENsIW0jZCIce+s+gHq5PqwfPUyZ0= =0Z2T -----END PGP SIGNATURE----- From nobody Mon Jun 9 10:10:33 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9C81A027B; Mon, 9 Jun 2014 10:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFp-GLyenv6M; Mon, 9 Jun 2014 10:10:26 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A234C1A0278; Mon, 9 Jun 2014 10:10:26 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.142.146]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s59HA0I8007804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2014 10:10:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1402333818; x=1402420218; bh=gX6Js3d0cezuEoekqsiQmUU/161AzajBd8klRguxPv0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=XQU1b1sAxAnh4kHjyr8m9cM/7S7Jey2d0Siajf+/+RnSMqLzHyOG/Dy9CV0Ry18dS bNJ0/zcXX9MLYXShQVNeWd0G9orvgQGNFm9hHBBOmjOwc9iwdjr7reLzLga756XahS 9YzVRVnw/fsdksvX1QsCO8Ykuuih+dKDFSfr/Q50= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1402333818; x=1402420218; i=@elandsys.com; bh=gX6Js3d0cezuEoekqsiQmUU/161AzajBd8klRguxPv0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=TC36DusD5k/s6yCqdmrvDm4l/7ZZTHV5gkplgQeHK78BKpQCZtqPLWz8Pbb/5H2bT zxVg3q/+4tPn7s5xyZzvNf3oDfTriaZQ5Dm1Y2ne/8K7bnOS5qiF5cbOFeiD2De0tJ YWciYJNnw3MCjIttk/6VaCvzAL2d675qEyBskAFE= Message-Id: <6.2.5.6.2.20140609090545.0c7fc780@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 09 Jun 2014 10:04:30 -0700 To: Warren Kumari , John C Klensin , Barry Leiba From: S Moonesamy In-Reply-To: References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/z9eCCUvgpaZMUe_l4D9eh3Eg1E0 Cc: Roger =?iso-8859-1?Q?J=F8rgensen?= , internetgovtech@iab.org, iesg@ietf.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 17:10:28 -0000 Hi Warren, Barry, As a matter of transparency I'll mention that I=20 am one of the TCRs for DNSSEC. I don't have any=20 direct or indirect financial interests in ICANN. At 08:45 09-06-2014, Warren Kumari wrote: >Yes, but the IETF does at least *try* to go to where the participants >are, and tries hard to keep the hotel and similar costs under control >- I participate in both IETF and ICANN[1] and my IETF expenses are >consistently lower than my ICANN ones. While attendance at some >portion of IETF meeting is required for some functions (such as >NonCom[3]) it is entirely possible to participate effectively in the >IETF without attending any meetings. Yes, it is easier if you show up >at the meetings, but still possible if you are not able to travel. I'll skip commenting about this to avoid a=20 discussion which is not related to the topic. >Step one is getting the community to acknowledge that there is a >problem -- and I'm not sure that there is actually an issue *from the >majority of ICANN participants point of view*. I believe that that >ICANN "leadership" would like to be more inclusive / have greater >representation, but changing the culture (especially in a way that >does not benefit those whose culture you are trying to change) is >hard. The issues which John Klensin and Roger J=F8rgensen=20 commented about was about an open-ended=20 commitment and whether anyone who would like to=20 be involved can be involved if the person is not=20 rich. It can come up as not well-thought if I=20 were, for example, to invite Warren to=20 participate and ignore that funding can be a problem. At 08:23 09-06-2014, Barry Leiba wrote: >And so, pulling this back to the subject at hand: >We can't change that for the purpose of appointing representatives to >the Coordination Group. But what we can do is ask our representatives >to (1) when the Coordination Group sets up its mode of operation, >influence the group to make its operation as accessible as possible to >those can't always travel to the meetings, and (2) work toward a plan >that changes that aspect of ICANN participation in general. The issue was about the representatives chosen by=20 the IESG. I don't think that it is about ICANN=20 participation in general as the (IETF)=20 representatives are expected to engage with the=20 IETF Community (that's from my reading of the proposal). Regards, S. Moonesamy=20 From nobody Mon Jun 9 10:25:11 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23BC31A02A3; Mon, 9 Jun 2014 10:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.333 X-Spam-Level: X-Spam-Status: No, score=0.333 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iln1fr19s8IC; Mon, 9 Jun 2014 10:25:04 -0700 (PDT) Received: from nike.wampumpeag.net (nike.wampumpeag.net [67.42.198.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71CF31A02BA; Mon, 9 Jun 2014 10:24:33 -0700 (PDT) Received: from frog.local ([67.42.198.93]) by nike.wampumpeag.net (8.14.9/8.14.9) with ESMTP id s59HOGIn079751; Mon, 9 Jun 2014 10:24:16 -0700 (PDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <5395EDA2.1010409@abenaki.wabanaki.net> Date: Mon, 09 Jun 2014 10:23:46 -0700 From: Eric Brunner-Williams User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: internetgovtech@iab.org, jari.arkko@piuha.net References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/8NX5JuPlhGzjuwF-U_FYg-Tk2uU Cc: iesg@ietf.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 17:25:06 -0000 Colleagues, Agency Capture (the American Administrative Law term for when the "regulator" is run by the "regulated") is probable if the most effective form of participation imposes a cost on the participants which the beneficiaries of agency policies are most capable of sustaining. The open-ended, and travel-required format proposed for the IETF's selectees risks capture, and the set of commercial and governmental actors seeking to become beneficiaries of "IANA Transition" is large. I'm glad John took the time to bring this issue up. Personally, I hope the "IANA Transition as-proposed" will fail, simply because the IANA Function(s) are government property and the mechanisms for the disposal of unwanted government property do not include no-bid contracts, or abandonment of contractual oversight, to the incumbent government contractor. I appreciate that "as proposed" is advanced by the current administration, just as a previous administration proposed the form and function of ICANN, and a still previous administration proposed a "transitions" from ARPA to the NSF and ultimately the DoC, where Agency Capture is present in more agencies than just the NTIA. This likely colors my views, so like John's personal note, I mention it, I have one suggestion, and one "Notice to Mariners", to share. I suggest that the form of participation is declined, that participation be limited to on-the-record commentary conducted by email. Like Warren there were periods in my participation in ICANN affairs when I'd the wicked rare opportunity to travel on my employer's nickle and attempt to, as I saw it, do good. Employer largess is a frail reed to build public policy upon, as is personal largess, and looking to funding from ICANN risks repeating the unfortunate trajectory of the At-Large Advisory Committee -- advice constrained by agreement in the advancement of further funding. As Jari noted in the mail that started this thread, the participants in the proposed coordinating (nee steering) committee are required to "ensur[e] that the proposal meets the criteria NTIA previously outlined". The "Notice to Mariners" is that this criteria may be insufficient, as it originates in an agency "captured", either by the commercial actors it was created to regulate, or by one or more other agencies with distinct agendas, or both, and criteria that narrowly address operational integrity and interoperability cannot be assumed to be identical with commercial and/or agency actors. Eric P.S. I'm not offering to serve either, I've done the laps (MdR, Stockholm, Montevideo, MdR, Rome, LA, New Delhi, Paris, Cairo, Mexico City, Sydney, Seoul, Brussels/Bruxelles, Cartegena, Singapore, Toronto), and worked on i18n/l10n (IDN), been employed by registry operators and registrar operators, and the proposal looks and smells a lot like the original PSO, which the ICANN Board of 2003 found inconvenient to maintain, and "reformed" the "tech" seats on the Board to be fewer, and non-voting. On 6/7/14 8:49 AM, John C Klensin wrote: > > --On Saturday, June 07, 2014 09:49 +0300 Jari Arkko > wrote: > >> For your information: additional details about the process and >> the coordination group are now available, here: >> >> https://www.icann.org/resources/pages/process-next-steps-2014- >> 06-06-en > Jari, > > I find one aspect of this document and the ongoing selection > process very troubling. The work and schedule of the > Coordinating (nee Steering) Committee seem completely > open-ended, both with respect to time commitment and to resource > requirements (including the potential requirement for travel to > a potentially continual road show of meetings. This new > document is worse in that regard than its predecessor because > both the schedule of meetings and the mission of the > Coordinating Committee have become open-ended. Unlike many of > the appointing groups, the IETF is not in a position to > underwrite those costs, i.e., to cover costs of time-salary > and/or travel to the various meetings so as to spread those > costs across the relevant community. The net effect is that > the only people who can plausibly represent the IETF are those > who: > > (i) Work for organizational entities with considerable resources > and willingness to provide open-ended support their employees in > this type of work, > > (ii) Have significant (even if not "too much") free time and > resources on their hands, or > > (iii) Consider this particular part of the work really, really, > important. > > I suggest that most people who fall into one or more of those > categories are not what we would normally consider > representative of the IETF community, much less representatives > of the diversity of this community (and note that "diversity" is > a new criterion). Especially for the first category above, > there is also a considerable potential for conflicts of > responsibility and interest if organizations with significant > stakes in this process have employees or others appointed > through both IETF (including IAB) and other constituency models. > > Perhaps it is the best we can do, but, especially since members > of that committee represent themselves once appointed, I think > it would be wise for the IETF to publicly note the issues and > create some distance from this process. That would be > especially important if "we" eventually conclude that we have to > reject its final conclusion/ recommendations. > > I also suggest that, if current IAB or IESG members decide to do > this and give it priority, the upcoming Nomcom should give > careful consideration to its impact on their current and > potential effectiveness in the roles to which prior Nomcom > appointed them as well as the overall effectiveness of those > bodies. > > best regards, > john > > p.s. Personal note: despite personal interest in this, > involvement as an advisor to IANA since the late 1970s and early > 1980s, key roles in ICANN's creation and intermittent > involvement since (as liaison to the Board, advisor on multiple > issues (especially IDNs and i18n), and occasional consultant, > I'd not putting my name forward for this role. The reasons are > ultimately connected to the remarks above: I have no funding for > an open-ended commitment that could involve significant time and > travel and I'm already overextended on work I feel I need to do > for the IETF. > > > > Especially with the added requirement for "diversity" > > > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech > > From nobody Mon Jun 9 10:33:21 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 620B21A00BD for ; Mon, 9 Jun 2014 10:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idjmH9B_E_zL for ; Mon, 9 Jun 2014 10:33:09 -0700 (PDT) Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 533E91A01AC for ; Mon, 9 Jun 2014 10:33:09 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id y13so5069372pdi.30 for ; Mon, 09 Jun 2014 10:33:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=d6+9+/JD2ewJss/3YU6LTX6/pr8HdFwNzaVOEGTczxA=; b=A0oRyn2oAteSfrdar3+Kp2RtFi1IvqbpuJhm4RUYY9rReINlkmQm+M4IcPGHUratX4 6G8BnIsO1u6ry3FfAQ8VJLIwBytPJLT92wuABF+Z6lcUQ0BWXNgi/V2xU8Qa8xTiWUGH 3gKZvjcqBP/CQRspT35eYuKHsYvpmDs5Xm6GZESSYvci6wxUOwCZPL8MXWSrLaYBss7i btywDrJn877vDTy5BTOfcrgulFvpCqjKCxkMeytJtWs86c0AXrYa+1ppueKlCoy5PMEH ruDIBlpIIV/FmWLHxzQemmEaXpJDkOFFBZTWG9u1tAe0iWEqMM4MbTj3KsgHe5wR+dBp dPbQ== X-Gm-Message-State: ALoCoQnwlFR+sy6kDbTBALJuWA+42nciZFV73NYfDciNBBaiaGxFLRSxycpBd4cNNKMpxrStXBPc X-Received: by 10.69.31.11 with SMTP id ki11mr6032629pbd.88.1402335188824; Mon, 09 Jun 2014 10:33:08 -0700 (PDT) Received: from [10.0.1.3] (c-24-6-168-86.hsd1.ca.comcast.net. [24.6.168.86]) by mx.google.com with ESMTPSA id vn13sm15320367pab.8.2014.06.09.10.33.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Jun 2014 10:33:07 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_04B53522-EA16-4091-88D6-471AB64C1337"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: David Conrad In-Reply-To: Date: Mon, 9 Jun 2014 10:33:01 -0700 Message-Id: <152FE254-0212-40E6-B8E1-410F8BB87E81@virtualized.org> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> To: Warren Lee Kumari X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/OsZ-e2_DiBW0wXqhosPfWCtiQ7I Cc: internetgovtech@iab.org, The IESG Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 17:33:12 -0000 --Apple-Mail=_04B53522-EA16-4091-88D6-471AB64C1337 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Warren and John, Having had a bit of experience on both sides of the ICANN wall, I have = to comment. On Jun 9, 2014, at 8:45 AM, Warren Kumari wrote: > On Mon, Jun 9, 2014 at 7:39 AM, John C Klensin = wrote: >> In the >> interests of involving more diverse populations, many or most of >> those meetings are held in places that are either expensive for >> most of the world to reach or to participate in (even though >> ICANN stresses that attendance at their meetings is "free" >> because they don't charge a registration fee. =20 This is a problem faced by any global activity, including the IETF. = According to ICANN's FY13 budget = (https://www.icann.org/en/system/files/files/proposed-opplan-budget-v1-fy1= 3-01may12-en.pdf), ICANN is funding 135 people to participate in ICANN = meetings in person and, as you note, ICANN does not charge a = registration fee. However, if ICANN did not go to all of those far off = places (and everyplace is far off for someone) or if they charged a = registration fee, they'd be accused of disenfranchising some part of the = community. A difficult to win situation. >> Few of the local >> attendees at those meetings participate effectively long-term >> unless ICANN subsidizes their participation and the categories >> of people who get subsidized do not include individual technical >> experts. =20 Actually, ICANN does subsidize a number of individual technical experts = including individuals participating in ICANN's Security and Stability = Advisory Committee (a dozen for London I believe, including myself) and = Root Server System Advisory Committee, IDN-related experts, etc. >> The net effect is that it is almost impossible for an >> individual technical expert, no affiliated with and representing >> some constituency group, to participate effectively unless >> either he or she is subsidized by ICANN (not exactly a set of >> choices that are unbiased by ICANN staff opinions about opinions >> they want to hear) or can contribute significant individual >> resources to the work (in your words, "only the rich"). >=20 > Yup. This effectively limits the ICANN version of > multistakeholderism[0] to be those who have some sort of financial > incentive to fly all over the world to participate.=20 Not really. ICANN spends over $1M per meeting to support remote participation, = including webcasts, audio conference calls with online support, = real-time transcription, and simultaneous translation into the 7 UN = languages at meetings and yet the number of folks that participate in = those webcasts (who aren't also at the meeting) can be numbered in the = dozens at best. What would you suggest as an alternative? >> (3) Returning to ICANN, much of the representation and leverage >> for individual technical participants is supposed to come >> through the Nomcom process, but that process has been fairly >> consistently operated (and starved for resources) ICANN's Nomcom's budget for FY13 is $834,000. What sort of resources do = you believe ICANN's Nomcom is being starved? >> (4) Even the IETF is not immune from the problem: Increasing >> reliance on meetings, requirements (some formal) for meeting >> attendance for effective participation, and rising total costs >> of meeting attendance (some of them driven by a desire to show >> the IETF flag in more places in the world), all contribute to an >> environment in which predominantly the "rich" (or >> organizationally-well-supported) can play, especially in >> "leadership" roles. >=20 > Yes, but the IETF does at least *try* to go to where the participants > are,=20 Tell that to folks participating in the IETF from Latin America or = Africa. > and tries hard to keep the hotel and similar costs under control As does ICANN. One significant difference: the meeting fee associated = with IETFs now come close to the cost of the economy airfare to get to = some of the meetings.=20 > - I participate in both IETF and ICANN[1] and my IETF expenses are > consistently lower than my ICANN ones. I participate in both as well and I haven't found a significant = difference taking into account ICANN meetings are required to visit all = 5 regions. Putting together a large international conference is an = extremely challenging activity and I believe the meetings teams at both = the IETF and ICANN do a reasonable job in trying to keep attendee = expenses in check.=20 > Unfortunately I think that only ways to change this is: > 1: for those who are not participating to actually show up for a few > meetings and actively push for change. + > 2: and to provide feedback to the ICANN Accountability work. As a member of the last round of accountability and transparency reviews = (https://www.icann.org/resources/pages/2-2012-11-14-en), I will note = that only 15 people applied as "independent experts" and of those = individuals, none listed IETF in their CVs (for a list of all the = applicants and their CVs, see = https://www.icann.org/resources/pages/applications-2012-11-14-en). Given = my experiences on the accountability and transparency review team, I am = a bit cynical when people complain about ICANN's alleged lack of = accountability and transparency. Regards, -drc --Apple-Mail=_04B53522-EA16-4091-88D6-471AB64C1337 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJTle/NAAoJENV6ebf0/4rXlqkH/2iTFQy1z3GOBXAXjVIcNC1l Q00F1lQeH8bbdNLOe6Pm9qe/SnEfW65xAPII6m+5A2DUlQDk54X2M4KohpqllL+J Qq6GspbVQsce7TvewGfezCdYkr3kOTjVr2x+OXO/RkdixQSC6lji8dFCS8/d5f4t oEmW9qtK2mBelg4gzsZGi/XztXek3Z5T0lPP24pX0m+X5l44m0tbHhBVC6I5CYDN xzXfw0Q+qqMhTSGHvbDLm9zQfXhH6n6gcAbTJfOQCfDwGnw2CqOWMhSNfgiXBXx6 c9KS+FX01jstwnq/ALvwt/VLu87DVqgOSh6UYgs3aMUAyqrWFmztrljHcKkaaMM= =DhHZ -----END PGP SIGNATURE----- --Apple-Mail=_04B53522-EA16-4091-88D6-471AB64C1337-- From nobody Mon Jun 9 10:36:57 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 261C11A01AC for ; Mon, 9 Jun 2014 10:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_62=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HW_LnSz2N_j6 for ; Mon, 9 Jun 2014 10:36:51 -0700 (PDT) Received: from waikiki.gih.co.uk (salsa.gih.co.uk [IPv6:2a00:19e8:10:5::b]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38C031A00BD for ; Mon, 9 Jun 2014 10:36:50 -0700 (PDT) Received: from waikiki.gih.co.uk (localhost6.localdomain6 [IPv6:::1]) by waikiki.gih.co.uk (Postfix) with ESMTP id 869BB18F3AF; Mon, 9 Jun 2014 18:36:48 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gih.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mahalo1; bh=mWdDgTE5r KMG7yhltIeJdxTVrsw=; b=LwN0kKcKncZ42ySAp2wNxGV4ArQPlZnteNfINLZyc Jl6rNBwqfHFl4BbpfVlxBX+ugRJfrvUHRJAOaMM2L10OLC6p9ck6zcAXAqY+ln1g 7BjstHRuoAHO+dEdetxCD6vPpnSrp46HPSIf3rIIAPU2hutHeFesAfIcSJp82eBX sk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gih.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mahalo1; b=CGN 3Vvz2lS/4OrBO5q+6TmnruRLjDLuhsp2/ihUyQ5BGE7zGJDkc9HqvRjU8/31gVYJ kKWpyFQHhCOrHPqA3qNRRpdq+c8NWtJhhrCIDa8UdORk2EXDDth7vozbLYZ9qUsq 7QfMZH+q8VYdLgqVBJaBksFEKVhLS65WnumnD3bM= Received: from [IPv6:2a02:120b:2c64:b5e0:2402:35b0:d2d0:d2ec] (unknown [IPv6:2a02:120b:2c64:b5e0:2402:35b0:d2d0:d2ec]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by waikiki.gih.co.uk (Postfix) with ESMTPSA id 86D4518F3AD; Mon, 9 Jun 2014 18:36:47 +0100 (BST) Message-ID: <5395F0AD.9050707@gih.com> Date: Mon, 09 Jun 2014 19:36:45 +0200 From: Olivier MJ Crepin-Leblond User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Warren Kumari , John C Klensin References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/inw01qKAFzrHNAjgT8o5whrp6EQ Cc: =?UTF-8?B?Um9nZXIgSsO4cmdlbnNlbg==?= , internetgovtech@iab.org, The IESG Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 17:36:53 -0000 Dear Warren, On 09/06/2014 17:45, Warren Kumari wrote: > On Mon, Jun 9, 2014 at 7:39 AM, John C Klensin wrot= e: >> (IETF list removed from CCs -- this response is not an >> IETF-specific issue) >> >> --On Monday, June 09, 2014 12:01 +0200 Roger J=C3=B8rgensen >> wrote: >> >>> On Sat, Jun 7, 2014 at 5:49 PM, John C Klensin >>> wrote: >>>> Coordinating Committee have become open-ended. Unlike many of >>>> the appointing groups, the IETF is not in a position to >>>> underwrite those costs, i.e., to cover costs of time-salary >>>> and/or travel to the various meetings so as to spread those >>>> costs across the relevant community. The net effect is that >>>> the only people who can plausibly represent the IETF are those >>>> who: >>> This part here made me think, can this issue about cost be the >>> first step on the way to a multi-stakeholder for Internet >>> where only the rich can participate? Rich as in having money >>> AND time to travel to endless meetings around the world? ... I >>> hope not. >> I would have said "only the rich and those associated with >> institutions or employers with significant resources to dedicate >> to these processes and economic incentives to do so", but I >> don't think that makes a difference in practice. >> >> I think it is, or should be, a major issue. But, whatever it >> is, it certainly is not the "first step". Consider the >> following, remembering that some, but certainly not all, of >> these are side-effects of decisions taken with the best of >> intentions and that some may be appropriate on balance. >> >> (1) ICANN has developed a pattern in which effective >> participation requires hugs blocks of time, active involvement >> in multiple committees (most of which produce very long reports >> that take time to study and that spawn more committees that, in >> turn, require active effort). Attendance at meetings is >> effectively mandatory if one wants to be effective. > Yup. A number of folk tried pushing for much more work being done on > (hopefully open) mailing lists, but without much success. > It really depends which part of ICANN you are looking at. Some parts, like the GNSO or the ALAC have optimised work on mailing lists as well as the use of WIKIs. As a result, only final discussions take place F2F at ICANN meetings. This is only the tip of the iceberg. [...] > Yup. This effectively limits the ICANN version of > multistakeholderism[0] to be those who have some sort of financial > incentive to fly all over the world to participate. (Last year this > was Beijing, Durban, Buenos-Aires. This year it is Singapore, London, > Los Angeles) This is a very real issue. Unbeknown to some of you, the ALAC has secured funding to have its 150+ At-Large Structures, *end-user organisations* come to the London ICANN meeting to work on several topics. This is a one-off event, after the last one in 2009 that brought many new active people in the At-Large sphere, devoting considerable time for free, in order to attempt to defend end user interests from within an organisation that is both difficult to comprehend and has sometimes appeared to be captured by vested interests. We will attempt to draft Statements on the following topics: 1. The Future of Multistakeholderism 2. The Globalization of ICANN 3. Global Internet: The User Perspective 4. ICANN Transparency and Accountability 5. At-Large Community Engagement in ICANN Conclusions will be presented to the ICANN Board. > > >> >> (3) Returning to ICANN, much of the representation and leverage >> for individual technical participants is supposed to come >> through the Nomcom process, but that process has been fairly >> consistently operated (and starved for resources) that have the >> presumably-accidental side effect of biasing both applications >> and selections in favor of those who are well-connected and able >> to invest considerable personal (or corporate) resources in >> ICANN participation. Having served on the NomCom for one year, I can share my thoughts on this too. The function of NomCom members is to (1) search for candidates for leadership positions at ICANN, and that does not only include the Board but also the ccNSO, the GNSO and the ALAC; and (2) make a selection to appoint people from this candidate pool. In the year I was on the ICANN NomCom, although I tried, not one strong technical candidate stood forward to join any of these leadership positions. In fact, I practically got told to get lost when asking people in the IETF sphere if they'd like to participate. One participant told me they'd rather have a root canal done. Yes, holding a volunteer leadership position at ICANN is exhausting time-wise and well as financially if one applies the concept that time is money. But how else do you suggest we solve the problem of volunteer participation? There are too many things to be done and not enough people volunteering to help. In selecting someone for a leadership position you have the four types of candidates to choose from: 1. the hard working, knowledgeable volunteer, of which there are not enough of because they'd rather get paid for their work 2. the hard working, clueless volunteer needs to learn a lot more by working in the trenches for a while more, thus being exhausted by working for free and not getting recognised for it 3. the volunteers looking like they're working hard, but only there for CV building... and guess what, the moment they'll be on the list, they'll stop doing any work whatsoever & will enjoy the free ride. Thankfully those are identified early enough so they never get called back again in the future 4. the trolls who have foobar'ed previous groups and are there to fight the system to show it does not work. What their motivation is, escapes my mind. >> There are other examples, but I don't think a long catalogue >> would help illustrate the problem. I wish I knew what to do >> about it, but we are long past "first step"... and past any >> plausible claim that what we call a multistakeholder model is >> really representative of either the broad Internet community or >> even a broad spectrum of qualified expert opinions. > Step one is getting the community to acknowledge that there is a > problem -- and I'm not sure that there is actually an issue *from the > majority of ICANN participants point of view*. I believe that that > ICANN "leadership" would like to be more inclusive / have greater > representation, but changing the culture (especially in a way that > does not benefit those whose culture you are trying to change) is > hard. I can't speak for any other part of ICANN but can relay to you that the consensus view in the At-Large Community is that there *is* a problem. That said, I also need to recognise that things have improved. ICANN is more and more willing to fun volunteers to *do* things and only volunteer their time and not their money to be involved and get things do= ne. On the one hand, we are seeing a growth into funding volunteers with no vested interests to take part, but on the other hand we are seeing the same people being able to devote their time and energy as soon as it means having to take time of their day to day work & meet face to face. > Unfortunately I think that only ways to change this is: > 1: for those who are not participating to actually show up for a few > meetings and actively push for change. You need to be passionate about > this though to be able to justify spending $$$ to attend a meeting. > 2: and to provide feedback to the ICANN Accountability work. I completely agree with you... ...and again, I can relate my experience about the ICANN Accountability & Transparency Review Team 2 which did its work last year. We produced a report & asked for public input both via a forum and face to face at ICANN meetings. 6 people turned up in the audience of the ICANN meeting, some of whom were in the room because there was good Internet connectivity, it was quiet and they could read their emails in peace. Nobody participated remotely. Very few inputs were received via the online forum. Why? Was it because nobody had time to read the report? So again - I think it's great that we are discussing this topic here, and again, I ask the technical community to get involved more in these issues of Internet Governance especially at ICANN. But I have real concerns that this call for volunteers who have the time, energy and devotion to making ICANN a better organisation, will fall on deaf ears: "I don't have time for this", I hear already... Kind regards, Olivier (expressing my own views. I don't get paid to speak for ICANN) --=20 Olivier MJ Cr=C3=A9pin-Leblond, PhD http://www.gih.com/ocl.html From nobody Mon Jun 9 10:57:27 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E46F1A0294 for ; Mon, 9 Jun 2014 10:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZflXRBxjcby for ; Mon, 9 Jun 2014 10:57:24 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 741621A01C5 for ; Mon, 9 Jun 2014 10:57:24 -0700 (PDT) Received: from 231.74.14.81.rev.sfr.net ([81.14.74.231]:37574 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1Wu3ox-00051R-KG; Mon, 09 Jun 2014 10:57:24 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 09 Jun 2014 19:57:18 +0200 To: internetgovtech@iab.org,The IESG From: JFC Morfin In-Reply-To: <63E9BDF5-7DB0-4B72-BAF1-B1818E64DB2B@virtualized.org> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <63E9BDF5-7DB0-4B72-BAF1-B1818E64DB2B@virtualized.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: jefsey+jefsey.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/FjwWXnT71ZrXjs9m0lFsVe3l690 Subject: [Internetgovtech] Question. [was: Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions] X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 17:57:26 -0000 At 18:15 09/06/2014, David Conrad wrote: >Given ICANN was explicitly asked by the U. S. Dept. of Commerce, >NTIA "to convene global stakeholders to develop a proposal to >transition the current role played by NTIA"[1], no, not really. > >[1] >http://www.ntia.doc.gov/press-release/2014/ntia-announces-intent-transition-key-internet-domain-name-functions Question: The NTIA asked ICANN "a proposal". Will the IETF also coordinate with other project of plans or proposals, or introduce its own one? jfc From nobody Mon Jun 9 11:03:33 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B301A0298 for ; Mon, 9 Jun 2014 11:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20-HGmbLY0CP for ; Mon, 9 Jun 2014 11:03:26 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB9D1A0294 for ; Mon, 9 Jun 2014 11:03:26 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 78AEDF3C009; Mon, 9 Jun 2014 14:03:16 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id eo9cytK5GVG2; Mon, 9 Jun 2014 14:02:55 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-144-77.washdc.fios.verizon.net [96.255.144.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 61EA1F3C01F; Mon, 9 Jun 2014 14:02:55 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <20140609175728.8A2C51A0299@ietfa.amsl.com> Date: Mon, 9 Jun 2014 14:02:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <73021DBA-F693-4E6E-8619-F4A2962D58F4@vigilsec.com> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <63E9BDF5-7DB0-4B72-BAF1-B1818E64DB2B@virtualized.org> <20140609175728.8A2C51A0299@ietfa.amsl.com> To: JFC Morfin X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/F86qWDWwZUYdjjKPCJX8YfFdRD8 Cc: internetgovtech@iab.org, The IESG Subject: Re: [Internetgovtech] Question. [was: Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions] X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 18:03:28 -0000 The NTIA has asked for a single proposal. I expect the IETF and the IAB = to have a very strong voice in the handling of the protocol parameters = in that proposal. Russ On Jun 9, 2014, at 1:57 PM, JFC Morfin wrote: > At 18:15 09/06/2014, David Conrad wrote: >> Given ICANN was explicitly asked by the U. S. Dept. of Commerce, NTIA = "to convene global stakeholders to develop a proposal to transition the = current role played by NTIA"[1], no, not really. >>=20 >> [1] = http://www.ntia.doc.gov/press-release/2014/ntia-announces-intent-transitio= n-key-internet-domain-name-functions >=20 > Question: The NTIA asked ICANN "a proposal". Will the IETF also = coordinate with other project of plans or proposals, or introduce its = own one? > jfc >=20 From nobody Mon Jun 9 11:25:57 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E93651A029B; Mon, 9 Jun 2014 11:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcdJr2QicYYH; Mon, 9 Jun 2014 11:25:50 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C444E1A029A; Mon, 9 Jun 2014 11:25:50 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.142.146]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s59IPZMG008663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2014 11:25:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1402338348; x=1402424748; bh=iNKEm2lPSbKZMVXnrSQRejCDcQnMZ3Wm/HQQ6QaXA7M=; h=Date:To:From:Subject:In-Reply-To:References; b=PFIwo0StSbk5QtQZE66X7JgwbYUkScf6H8jlqMYGQLvjOqybRqxU9W2VIc8Hr+q1Z nYjjWnhuwlVYKiF3aOKiquzx15glwrf2UQi4FnZjpC6S1dqbwiLJ6WiCZA1Ujf1L9+ kMszshk4k66FnjRudk9JUmmARf9MwYFT+Mty2hFk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1402338348; x=1402424748; i=@elandsys.com; bh=iNKEm2lPSbKZMVXnrSQRejCDcQnMZ3Wm/HQQ6QaXA7M=; h=Date:To:From:Subject:In-Reply-To:References; b=PRcXLCWo2K7JIJY6D9RoY53gImtT6h21JQUp0QeksBS6SlmaqfW3h+yWGGDlIE/vr 3MCeT3Ufvy99hJmIJuiF9RceqcfVHkHJLLFZKUmHSvY2TfEECuMnHat6VNWWba/yLt GMdvwY+9WKRh9VnGFkl7Foi7ILLC62QvxcitrPdY= Message-Id: <6.2.5.6.2.20140609102339.0c96d658@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 09 Jun 2014 11:15:25 -0700 To: Andrew Sullivan , internetgovtech@iab.org, iesg@ietf.org From: S Moonesamy In-Reply-To: <20140609160101.GJ27145@mx1.yitter.info> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/4ulLF6qJ6fN1Jrgv1WFgGWOBLTs Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 18:25:52 -0000 Hi Andrew, At 09:01 09-06-2014, Andrew Sullivan wrote: >Also, does anyone worry about the potential conflict of having the >organization whose contractual relationship is going to change pay for >everyone's participation (particularly when that participation is >apparently on an individual basis)? It is a worry as there is a potential conflict. The problem is that there is an assumption that the individual is a (wealthy) philanthropist. That's the only condition that would allow an individual to participate on an individual basis if the requirement is the ability to travel. Some of the entities participating in the process have (indirect) contractual relationships with ICANN. There is, again, a potential conflict. The IANA Transition affects: (i) ICANN (including the RIRs here) (ii) The IETF The IETF has a contractual relationship with ICANN. Should a person who finds the travel prohibitive accept the payment or should he/she choose not to participate? Regards, S. Moonesamy From nobody Mon Jun 9 11:46:49 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5B821A02C4 for ; Mon, 9 Jun 2014 11:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUaYjbqrk5vo for ; Mon, 9 Jun 2014 11:46:40 -0700 (PDT) Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E61B1A02BE for ; Mon, 9 Jun 2014 11:46:40 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id rq2so5263881pbb.33 for ; Mon, 09 Jun 2014 11:46:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=mQ+jhyFhxfT0FcvY/GNlshOl2t8T4SLs3+cgRw/161I=; b=dcavIglAjXdUcY94GAk7rL9qe+vlle49z4/3mVgET6hr5XUhYKrJapEyG0wUYxiq9M piwXZtMPl5V1Ba7XqsTRW8CX7uqwKARIS/U8AMnKAGUgIRKNgenGRAPFLu7ffbMILj5y OWsNWOM2Umum9ECxM/IY2qALbFAoJ2hpVnPJ/O41OUcVwPRNdYn0gtrsIcPZ/5XW48Yn zrLyrqzwAAvN+/UvDgcQ2rgEXti+ncj7sxE2leYw00kd2TsU3DJKPSdDR0xbDiSW6c7P ZH5rcpz0JiVldNBvWOdgWfw46H7jpTBsfTe9P/4doruy21Ged6TTGTKm2F9DQ0i6dv1d 9Sgw== X-Gm-Message-State: ALoCoQmuiefNzl9IrBvdHLi5sK4lvQT2cGUgl7QkUdJ0s6/9iJZrEYJxvHq02kujPayUqOP4Z+z6 X-Received: by 10.68.254.70 with SMTP id ag6mr6412375pbd.33.1402339599965; Mon, 09 Jun 2014 11:46:39 -0700 (PDT) Received: from [10.0.1.3] (c-24-6-168-86.hsd1.ca.comcast.net. [24.6.168.86]) by mx.google.com with ESMTPSA id ei4sm65284986pbb.42.2014.06.09.11.46.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Jun 2014 11:46:39 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_8B921F7E-A670-462C-80BA-01FC12C56898"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: David Conrad In-Reply-To: <6.2.5.6.2.20140609102339.0c96d658@resistor.net> Date: Mon, 9 Jun 2014 11:46:30 -0700 Message-Id: <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> To: S Moonesamy X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/m83s8qr26knxjXjeaRLG223rUzI Cc: internetgovtech@iab.org, The IESG Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 18:46:43 -0000 --Apple-Mail=_8B921F7E-A670-462C-80BA-01FC12C56898 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 9, 2014, at 11:15 AM, S Moonesamy wrote: > It is a worry as there is a potential conflict. =20 There are a myriad of conflict potentials, among the least of which is = that an individual was subsidized to participate. Everyone has an = agenda and ulterior motives. The question is whether or not those = agendas/ulterior motives align with what is in the interests of the = IETF. I believe the key here is for complete and absolute openness and = transparency. No meeting should be held nor anything be done without it = being recorded/documented/transcripts provided/etc. It should be = possible for anyone to understand the arguments and rationales of how = what in included in the final proposal got there, who provided it, what = changes were made and why, etc. Absolutely nothing should be done = behind closed doors or be done in a way that does not allow anyone with = interest to follow along. >=20 > The IANA Transition affects: >=20 > (i) ICANN (including the RIRs here) >=20 > (ii) The IETF >=20 > The IETF has a contractual relationship with ICANN. As do the RIRs (via the ASO MoU). > Should a person who finds the travel prohibitive accept the payment or = should he/she choose not to participate? If they understand and accept the role of representing the IETF and = agree to absolute transparency, I see no problem in them accepting = payment. However, this is sort of putting the cart before the horse as so far, = we've only seen folks declining the opportunity to volunteer :). Regards, -drc --Apple-Mail=_8B921F7E-A670-462C-80BA-01FC12C56898 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJTlgEHAAoJENV6ebf0/4rXkCAIAJQJ99uJDUANovt3aqpytTDT OeJjB1qmxt2Ssp/PhXZoErzjS6IGcPoxDW0FdTJ7jajDGsLpgbG4I++xiE2G1YIy efquUzp9DcG06sZhWA3J22YN+78IdM9y/4OobKIdnJtwL3U21d2IqcuWtKIS0j+x eJqJSnPeP6yVMRmYW6PkMqi0v3ZwYWqLmWTjrxEPfLi6FOfmhN9oixKBKrcjnqij IDrPBFcM0BP7MiyNz1rvYLWQnt6NQIi5A+VaU6A7n2iKq3PGIWjPI5rnaUekh9gu Ul59pKgAWycJlvl5LPYT7qj8fTk/rwdZElN9thtSNn7/uYOq5zmncYYr1ISQRRw= =NZij -----END PGP SIGNATURE----- --Apple-Mail=_8B921F7E-A670-462C-80BA-01FC12C56898-- From nobody Mon Jun 9 12:08:41 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FEF01A029F for ; Mon, 9 Jun 2014 12:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5IJqArGbBR2 for ; Mon, 9 Jun 2014 12:08:39 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 222011A02E9 for ; Mon, 9 Jun 2014 12:08:33 -0700 (PDT) Received: from mx1.yitter.info (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id EB8508A031 for ; Mon, 9 Jun 2014 19:08:31 +0000 (UTC) Date: Mon, 9 Jun 2014 15:08:30 -0400 From: Andrew Sullivan To: internetgovtech@iab.org Message-ID: <20140609190830.GR27145@mx1.yitter.info> References: <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/IedT_CCBNeY2l3MEn6cASxhCVoI Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 19:08:40 -0000 On Mon, Jun 09, 2014 at 11:46:30AM -0700, David Conrad wrote: > it, what changes were made and why, etc. Absolutely nothing should > be done behind closed doors or be done in a way that does not allow > anyone with interest to follow along. Do you extend that to "hallway discussions" among several individuals? A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Jun 9 12:12:18 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60821A02C7 for ; Mon, 9 Jun 2014 12:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91tarLckYqjm for ; Mon, 9 Jun 2014 12:12:15 -0700 (PDT) Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BCDF1A029F for ; Mon, 9 Jun 2014 12:12:15 -0700 (PDT) Received: by mail-pb0-f51.google.com with SMTP id ma3so5298404pbc.24 for ; Mon, 09 Jun 2014 12:12:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=XSpqG3GkI6jylPG3fV8fma8jJdfdiQBD4oM3+uwMuWw=; b=czM8r6/S0Kq5UEQkh+YLxq0kULWJew89POrJCHlHIug6l1kuX2W4VTNH/h24FpnsB4 LJJsgO4y4XD1n9zxLjSl2SWLAAbfQ8P/2Np7YXApRKZr0oaj1b7SylGxupP85VLBr9Ra cfpY1WrDSebDowTkBayXo1HyzGz5cTJcU9zqxo39WR2EawQn9YOnFOevlEHB9qLfKb0y qA8TdGQ/pPBRKtnNT0jEvMxTmIK5C/vbM3vJfS+rVEuYxjkgqNAN+8wuTx4L3sHIGlVY ZyG+3dU76vlo7AfRvAKLMbMKDems1XiWSeBxE/sUOfhle9aYGbulIsiI+Ioi8Wj8DEV1 +8vw== X-Gm-Message-State: ALoCoQm3RtYqw7g5b6YthPXTNqReC2x5SazfQJULUcfcyvZIruadRm92EFOcqtm4nPG1IjFgGLXH X-Received: by 10.68.136.226 with SMTP id qd2mr6522144pbb.72.1402341134988; Mon, 09 Jun 2014 12:12:14 -0700 (PDT) Received: from [10.0.1.3] (c-24-6-168-86.hsd1.ca.comcast.net. [24.6.168.86]) by mx.google.com with ESMTPSA id av2sm65389888pbc.16.2014.06.09.12.12.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Jun 2014 12:12:14 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_3E7DA2A1-320D-41FA-A231-F64BA7EDE398"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: David Conrad In-Reply-To: <20140609190830.GR27145@mx1.yitter.info> Date: Mon, 9 Jun 2014 12:12:07 -0700 Message-Id: References: <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <20140609190830.GR27145@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/t1p8gzmi4cZFpRLm5iM24wPpHtk Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 19:12:17 -0000 --Apple-Mail=_3E7DA2A1-320D-41FA-A231-F64BA7EDE398 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 9, 2014, at 12:08 PM, Andrew Sullivan = wrote: > On Mon, Jun 09, 2014 at 11:46:30AM -0700, David Conrad wrote: >> it, what changes were made and why, etc. Absolutely nothing should >> be done behind closed doors or be done in a way that does not allow >> anyone with interest to follow along. >=20 > Do you extend that to "hallway discussions" among several individuals? = =20 Yes. If there is a hallway meeting that directly impacts the = proceedings, I believe it should be documented.=20 Regards, -drc --Apple-Mail=_3E7DA2A1-320D-41FA-A231-F64BA7EDE398 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJTlgcHAAoJENV6ebf0/4rXWycH/i/H2W3vvybXPqalvVgrV3qi 0cwjlN41Ea8SOg+l4gt963xVGBRJgEa9gy0K0kGnO8yY5UTAAq1U17tpf6KREK32 dv818/KLZkDGePDYAZuXhz5X2kUbd14qeBCQfx0v8yCkrP4KrRUAmyfcwNo0NaA2 Dqea9dZYeTvieBjgEODm/cAMQLZsXnOPXVkNWSHA8aTdO7dDs2FRZ4d7HurUy4Fc 96sRZKnIhunmLRTR/5+HsaPvU3nh9Hbn0nfEPKlk/h0aGmdQFT17xVTdUtu+cHnB pANe5Mto7z9gy/Ek8B2hAbFr/EXJDco7LcA331QdfyInJdsgjZ3D9us64jWsFFc= =4g6R -----END PGP SIGNATURE----- --Apple-Mail=_3E7DA2A1-320D-41FA-A231-F64BA7EDE398-- From nobody Mon Jun 9 12:17:45 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE1371A030A for ; Mon, 9 Jun 2014 12:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IG0qxxCUTsQd for ; Mon, 9 Jun 2014 12:17:42 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E31D1A0310 for ; Mon, 9 Jun 2014 12:17:42 -0700 (PDT) Received: from [192.168.1.45] ([109.128.169.101]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s59JHZir019057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 9 Jun 2014 12:17:40 -0700 Message-ID: <53960817.3050308@dcrocker.net> Date: Mon, 09 Jun 2014 21:16:39 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Andrew Sullivan , internetgovtech@iab.org References: <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <20140609190830.GR27145@mx1.yitter.info> In-Reply-To: <20140609190830.GR27145@mx1.yitter.info> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 09 Jun 2014 12:17:41 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/Ws1_EMliEGha-GyfbjfBhqjgp5g Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 19:17:44 -0000 On 6/9/2014 9:08 PM, Andrew Sullivan wrote: > On Mon, Jun 09, 2014 at 11:46:30AM -0700, David Conrad wrote: > >> it, what changes were made and why, etc. Absolutely nothing should >> be done behind closed doors or be done in a way that does not allow >> anyone with interest to follow along. > > Do you extend that to "hallway discussions" among several individuals? This two-message exchange is pretty classic, for this kind of topic. Let me offer what is intended as a friendly amendment to the offered requirement: For decision-making bodies, discussions tend to divide among exploration, proposal development, and proposal approval. Things can get more elaborate, of course, such as reporting on exploration and reporting on proposals, distinct from approving one among a set. Much of the exploration and development need to have at least the early stages of their work be done by smaller teams that are not necessarily public. Efficiency is the main reason. The alternative is a classic design-by-committee process. However the latter stages of development (let's call it 'refinement'), and the process of approval of proposals or report do need to be fully transparent, including disclosure of influences and rationales. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Jun 9 12:18:10 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071431A033E for ; Mon, 9 Jun 2014 12:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ths5lxfC24mW for ; Mon, 9 Jun 2014 12:18:00 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 773F11A031A for ; Mon, 9 Jun 2014 12:18:00 -0700 (PDT) Received: from c-98-252-11-61.hsd1.de.comcast.net ([98.252.11.61] helo=[192.168.200.186]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1Wu54x-0004lV-Pp; Mon, 09 Jun 2014 19:17:59 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 98.252.11.61 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19iQsNodHL1xV/K8d690qdF Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: John Curran In-Reply-To: <20140609190830.GR27145@mx1.yitter.info> Date: Mon, 9 Jun 2014 15:17:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <20140609190830.GR27145@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/0RZqQTVGzuIM0HSsOXlxaiMlQ5o Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 19:18:05 -0000 On Jun 9, 2014, at 3:08 PM, Andrew Sullivan = wrote: > On Mon, Jun 09, 2014 at 11:46:30AM -0700, David Conrad wrote: >=20 >> it, what changes were made and why, etc. Absolutely nothing should >> be done behind closed doors or be done in a way that does not allow >> anyone with interest to follow along. >=20 > Do you extend that to "hallway discussions" among several individuals? = =20 Slippery slope detected - caution advised (unless you can provide a very = clear,=20 bright line distinguishing hallway discussions of substance versus the = various ad-hoc dinner discussions, private emails among a group of folks, etc.) (I fully support that "It should be possible for anyone to understand = the=20 arguments and rationales of how what in included in the final proposal = got=20 there, who provided it, what changes were made and why, etc.", but do = not derive from that any prohibition on hallway discussions...)=20 FYI, /John Disclaimer: my views alone. From nobody Mon Jun 9 12:40:23 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0C31A0360 for ; Mon, 9 Jun 2014 12:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D59w_saxJ8FA for ; Mon, 9 Jun 2014 12:40:16 -0700 (PDT) Received: from mail-pb0-f50.google.com (mail-pb0-f50.google.com [209.85.160.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0D981A0305 for ; Mon, 9 Jun 2014 12:40:15 -0700 (PDT) Received: by mail-pb0-f50.google.com with SMTP id ma3so5295556pbc.37 for ; Mon, 09 Jun 2014 12:40:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=nfuRGAO6KrZgGo088zU9npqvEw6nfSqzmMczxBQcpGg=; b=HiffWP0qvwVfcTjVv/3MXuUVLpEtnDmap2Py0JJljeF2y9xP/ew1Ihnyyh72qjnUMM 1eA/Z02FREuzUzG/2h5wW7cnc0WY4Dk1XVu4s5jJ4+i8zCQeM5lSecrM+4ZyFmzk22PK y9K/CytLEAD56fm/SLACytaGWYtQYYYcE3G/C7xKtegG+i6AeGtUD0Zj+5sKi2SVGiwh PLA+oX2+x0Da3nsLsn8Z/KNjNlsO+l+UalRPQ76glHEpICdAKBYIXav43Mc+y8yQ9FWW 5RMJnxYA1BEyTZeRyq9j/CfKGzeCkDccpVdAeGhzuNbP/0vA+cgL8qOCgbcrHG73WTq9 VV3A== X-Gm-Message-State: ALoCoQkPHaobkwzt0gZXwXzY9wv/IUf1Td8k/RDalkTRRHgUaAv4aGojq9S24cIM7GUkKBuBiqXc X-Received: by 10.66.102.4 with SMTP id fk4mr352902pab.59.1402342815429; Mon, 09 Jun 2014 12:40:15 -0700 (PDT) Received: from [10.0.1.3] (c-24-6-168-86.hsd1.ca.comcast.net. [24.6.168.86]) by mx.google.com with ESMTPSA id pl10sm65404981pbb.56.2014.06.09.12.40.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Jun 2014 12:40:13 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_691C9424-F34A-4635-A0A4-6F99154E9AD2"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: David Conrad In-Reply-To: <53960817.3050308@dcrocker.net> Date: Mon, 9 Jun 2014 12:40:05 -0700 Message-Id: <59C0992A-037D-40AC-BFD9-419A4B65D4A4@virtualized.org> References: <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <20140609190830.GR27145@mx1.yitter.info> <53960817.3050308@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/tc9WlID_yDN0WQuVz9S53fM_tww Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 19:40:20 -0000 --Apple-Mail=_691C9424-F34A-4635-A0A4-6F99154E9AD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dave, On Jun 9, 2014, at 12:16 PM, Dave Crocker wrote: >>> it, what changes were made and why, etc. Absolutely nothing should >>> be done behind closed doors or be done in a way that does not allow >>> anyone with interest to follow along. >> Do you extend that to "hallway discussions" among several = individuals? =20 >=20 > For decision-making bodies, discussions tend to divide among > exploration, proposal development, and proposal approval. Things can = get > more elaborate, of course, such as reporting on exploration and > reporting on proposals, distinct from approving one among a set. >=20 > Much of the exploration and development need to have at least the > early stages of their work be done by smaller teams that are not > necessarily public. Efficiency is the main reason. The alternative = is > a classic design-by-committee process. >=20 > However the latter stages of development (let's call it > 'refinement'), and the process of approval of proposals or report do > need to be fully transparent, including disclosure of influences and > rationales. Right. The "coordinating committee" (or whatever it is called this week) is = not, as I understand it, supposed to be coming up with the first part. = Their role is to take the input from the various stakeholder communities = and formulate a consensus proposal. That is, the = "exploration/development" bits are being done elsewhere and I have no = issue with that being done behind closed doors (well, actually I do, but = that battle is long lost, even within the IETF). The coordinating = committee's job (again, AIUI), is to take the output of the = "exploration/development" and come up with a single proposal. I believe = this latter part must be done as openly and transparently as possible. (This is one reason I think even the name "coordinating committee" is = bad -- it implies giving direction and results in some folks believing = they need to be one the committee because they're obviously too = important to not be. A better name would've been "rapporteur committee" = or somesuch). Regards, -drc --Apple-Mail=_691C9424-F34A-4635-A0A4-6F99154E9AD2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJTlg2WAAoJENV6ebf0/4rX1AIIAJGLTEE6IHf5dCU61Aj8Ub90 Swa0ndMYe9QerO8vhKm41zJot8X1bZ+2w5PlHiHe3GAmBDqCBtB/Ke0TQoQiUI5y hmTDHe9H6bmZH8bTEfv0qFqwG8RLF4m1M2Va/r5bWXcBTcaBcA1e/ceyAeRAMnE/ 5Rm2Gfu16Jf2Ge1UfZE+sDpOntP+Krh6MnEDlBuOMD0MSEFT8mqH67rxfzUGwyI5 dUp6QIpPXUXvXvNnC5EsYAsiKy4IOSoDEfmsWOCiH+vP9TgzouYDkLBCY2803QMt oyQr/SziIZrpXhUCFHEcrV6kO8Xo/fg7x0X/q+TtQk2T3dN3xv4L1ALSzAZdniY= =T4zW -----END PGP SIGNATURE----- --Apple-Mail=_691C9424-F34A-4635-A0A4-6F99154E9AD2-- From nobody Mon Jun 9 12:43:12 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB6E81A02E6 for ; Mon, 9 Jun 2014 12:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIM5WGompetV for ; Mon, 9 Jun 2014 12:43:08 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B29731A02DE for ; Mon, 9 Jun 2014 12:43:08 -0700 (PDT) Received: from [192.168.1.45] ([109.128.169.101]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s59Jh3tH019560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 9 Jun 2014 12:43:07 -0700 Message-ID: <53960E0F.3080607@dcrocker.net> Date: Mon, 09 Jun 2014 21:42:07 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: David Conrad References: <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <20140609190830.GR27145@mx1.yitter.info> <53960817.3050308@dcrocker.net> <59C0992A-037D-40AC-BFD9-419A4B65D4A4@virtualized.org> In-Reply-To: <59C0992A-037D-40AC-BFD9-419A4B65D4A4@virtualized.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 09 Jun 2014 12:43:08 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/8xRjvwkLN1FTvkoTRCTfqeoiTUw Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 19:43:10 -0000 On 6/9/2014 9:40 PM, David Conrad wrote: > formulate a consensus proposal. formulating a proposal is a development task. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Jun 9 12:58:13 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD051A02D6 for ; Mon, 9 Jun 2014 12:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEnhNcLWJQVN for ; Mon, 9 Jun 2014 12:58:07 -0700 (PDT) Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F1851A0281 for ; Mon, 9 Jun 2014 12:58:06 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id rq2so5348566pbb.33 for ; Mon, 09 Jun 2014 12:58:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=+2qUDIw6BQGZ/GqQQNPVSeorRg37JbptH80XoqI8Qp8=; b=LpmzGEdK2RdpZRoGC37lP0sIuaiA200NCDloK5fx2tk0TTJ8zRtAZIxXWL6h2s6wXO QNRpMoF7kElxoUNd5ExB458/zcDJ3e2INXtzlo6QLQieJOtFmGYKC706Eoy6lpfxWrLU Z2QzdSdkMSWq7+8D2A612T1JdSRZdpflMnWpMuCEDRulN+7Ti5KkSXlKJnXg7nMtMhXi XnU5LWmiAJ2jqbGRaj6SHu8AOqVX9BICOJ2fpaexFgOwTt243cMWZPgXgB2j4m58NIux I1FlvtJZ6jGtEKnmfuh4Ru+h65NvLlTRRQYVshOcUALSXuIP0WtsNVONV/EYQ9tPmxG1 WkaQ== X-Gm-Message-State: ALoCoQmcRZNzKw1JXpSFTTc/dAcUGPiiUjOrpJS5DUn4WuVKHfT1H4kYqCWlMiZFl3qjkqe6D/Yx X-Received: by 10.68.163.197 with SMTP id yk5mr6814306pbb.57.1402343885661; Mon, 09 Jun 2014 12:58:05 -0700 (PDT) Received: from [10.0.1.3] (c-24-6-168-86.hsd1.ca.comcast.net. [24.6.168.86]) by mx.google.com with ESMTPSA id iz2sm65394677pbb.95.2014.06.09.12.58.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Jun 2014 12:58:04 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_7E3DF4AC-1E6F-4597-B326-2350FDFF1CCC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: David Conrad In-Reply-To: <53960E0F.3080607@dcrocker.net> Date: Mon, 9 Jun 2014 12:57:57 -0700 Message-Id: References: <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <20140609190830.GR27145@mx1.yitter.info> <53960817.3050308@dcrocker.net> <59C0992A-037D-40AC-BFD9-419A4B65D4A4@virtualized.org> <53960E0F.3080607@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/Un83VoJXyPybrAEuGDiBlk81m9s Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 19:58:09 -0000 --Apple-Mail=_7E3DF4AC-1E6F-4597-B326-2350FDFF1CCC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Dave, On Jun 9, 2014, at 12:42 PM, Dave Crocker wrote: > On 6/9/2014 9:40 PM, David Conrad wrote: >> formulate a consensus proposal. > formulating a proposal is a development task. Simply: I do not believe it appropriate in the context of the IANA = Transition proposal for the formulation of the consensus proposal across = the various stakeholders to be developed in a non-open and = non-transparent way. Yes, I am aware that this means it is less = efficient, however I do not believe there is any rush here. Feel free to differ. Regards, -drc =20 --Apple-Mail=_7E3DF4AC-1E6F-4597-B326-2350FDFF1CCC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJTlhHFAAoJENV6ebf0/4rXs2sH/ilvwfTACpdm4a2JEdgzfws7 uMYUQ/ULbhfVumU9QOxgrcYJW0C/2PT/wh8CKz39ML90GGiAnDm9nhstKBqfF5+P E4KCJ4rBtEdO+aD1zZlkq0BldHTCxd/QWarIUFqjbCTj7LPAH/HoCR5bFNvJCdYb Dyc88avHCRyMoF170NxEKacyiJhOgeQdqZJOh+bae07epBqciie4zG0HZkmMAKyK e0TD45DgknoI5uS1aRuffXVy8RgR7TtLIApevaJD3b6EN4s9e0xe8MP7pFSQsDDB q8I0Q7LHFnUbPtbYERVD5QwjsGyLScLlHN+A0Me1q6h+W3aQd37+rAdjuyaRyZI= =S6We -----END PGP SIGNATURE----- --Apple-Mail=_7E3DF4AC-1E6F-4597-B326-2350FDFF1CCC-- From nobody Mon Jun 9 13:19:15 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6F11A02EC for ; Mon, 9 Jun 2014 13:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzYOzY7xSUiW for ; Mon, 9 Jun 2014 13:19:11 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F6A91A02E5 for ; Mon, 9 Jun 2014 13:19:10 -0700 (PDT) Received: from mx1.yitter.info (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 7F2A58A031 for ; Mon, 9 Jun 2014 20:19:09 +0000 (UTC) Date: Mon, 9 Jun 2014 16:19:08 -0400 From: Andrew Sullivan To: internetgovtech@iab.org Message-ID: <20140609201907.GS27145@mx1.yitter.info> References: <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <20140609190830.GR27145@mx1.yitter.info> <53960817.3050308@dcrocker.net> <59C0992A-037D-40AC-BFD9-419A4B65D4A4@virtualized.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <59C0992A-037D-40AC-BFD9-419A4B65D4A4@virtualized.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/s18k4J_iCQMNjqBVDZjp7mF8MjU Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 20:19:12 -0000 Hi, On Mon, Jun 09, 2014 at 12:40:05PM -0700, David Conrad wrote: > > The "coordinating committee" (or whatever it is called this week) is > not, as I understand it, supposed to be coming up with the first > part. Their role is to take the input from the various stakeholder > communities and formulate a consensus proposal. Well, maybe. https://www.icann.org/resources/pages/process-next-steps-2014-06-06-en says The Coordination Group will be responsible for preparing a transition proposal respective of the differing needs of the various affected parties of the IANA functions. It should be responsible for assembling the components from the respective communities into a single proposal meeting the criteria set out by NTIA. So, it's "responsible for preparing" but also it's supposed to do it by "assembling". Yet it seems pretty clear that ICANN is refusing to be prescriptive: The overview of comments regarding the roles and responsibilities of the Coordination Group is intended to serve as input for the Coordination Group and its work moving forward, consistent with the scope [PDF, 456 KB]. That is, this document does not prescribe the roles and responsibilities for the Coordination Group. The Coordination Group may use the input at its discretion as it works toward defining its modes of operation and working methods. My own view, which was completely in alignment with what the IAB stated in its earlier comments, was that the Coordination Group should have been a straight "rapporteur", as David suggested. Unfortunately, that's not what we have. Instead, we have a group that can in effect decide to do whatever it wants. The protection from that, however, remains our various communities' vigilance. For that reason, I really strongly support the suggestion that the overall effect needs to be open and transparent; but I'm not actually convinced that extends to every hallway conversation and so on. I don't care how a good idea comes up. What I care about is why I should accept an idea and what objections there are to that idea. So, the debate about a proposal has to happen in public, but in my view that doesn't mean that every interaction needs to be regulated. I don't care who came up with something. I'm interested in the very strongest arguments for and against a plan. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Jun 9 13:36:19 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30DE1A0319 for ; Mon, 9 Jun 2014 13:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgie7hUIxVps for ; Mon, 9 Jun 2014 13:36:16 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF9B81A0318 for ; Mon, 9 Jun 2014 13:36:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1827; q=dns/txt; s=iport; t=1402346176; x=1403555776; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=7gKBt/QzmaoO3tXa9Pot3Ktabal47iCOGTx9PyUDUgU=; b=HsUxbDBM6YGs9SMdQQ7R7JPFwYDsq0dvrpHChKqkPui+bQ95EKzbd1ZY mV9Vg2/qvvIZWkRcl7mLudpco/GgEbOA6IDoyMjeWizx2GXUO2j6+kNMk NPDK8RudfY2jUj3xVLlQiE8sGfg3YY9QpiVA6tw5cvvFDevilsQQzL1Gd k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am8KAEUallOtJssW/2dsb2JhbABZhySndQEBAQEBAQUBmRABgSh1hAMBAQEDASNVBgsLDgwCBRYEBwICCQMCAQIBRQYBDAgBAYg2CKwfnxkXgSqEM4kWgnWBTAEDmiGTRYF8gUI7 X-IronPort-AV: E=Sophos;i="4.98,1003,1392163200"; d="scan'208";a="75750399" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 09 Jun 2014 20:36:13 +0000 Received: from ELEAR-M-C3ZS.CISCO.COM ([10.61.201.68]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s59KaDFb030401; Mon, 9 Jun 2014 20:36:13 GMT Message-ID: <53961ABD.3000807@cisco.com> Date: Mon, 09 Jun 2014 22:36:13 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Andrew Sullivan , internetgovtech@iab.org References: <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <20140609190830.GR27145@mx1.yitter.info> <53960817.3050308@dcrocker.net> <59C0992A-037D-40AC-BFD9-419A4B65D4A4@virtualized.org> <20140609201907.GS27145@mx1.yitter.info> In-Reply-To: <20140609201907.GS27145@mx1.yitter.info> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/wj8pEEfXI-Hg5SAbkO5-HR5N5Yo Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 20:36:18 -0000 Hi, On 6/9/14, 10:19 PM, Andrew Sullivan wrote: > My own view, which was completely in alignment with what the IAB > stated in its earlier comments, was that the Coordination Group should > have been a straight "rapporteur", as David suggested. Indeed. > Unfortunately, > that's not what we have. Instead, we have a group that can in effect > decide to do whatever it wants. To be fair, ICANN tried to scope the group and nobody liked what they came up with. And so they removed the scope, sticking precisely to NTIA's parameters. They prescribed little more than the size and composition of the group. > > The protection from that, however, remains our various communities' > vigilance. For that reason, I really strongly support the suggestion > that the overall effect needs to be open and transparent; but I'm not > actually convinced that extends to every hallway conversation and so > on. I don't care how a good idea comes up. What I care about is why > I should accept an idea and what objections there are to that idea. > So, the debate about a proposal has to happen in public, but in my > view that doesn't mean that every interaction needs to be regulated. > I don't care who came up with something. I'm interested in the very > strongest arguments for and against a plan. > Of course, we may have no recourse, whether we accept the idea or not, depending on the rules of the coordination group. What some people may be concerned about is a private quid pro quo. That's quite difficult to guard against, and this is why a representative approach with governance is a useful tool. That is- the communities are speaking, not the individuals. That is an option left to this coordination group, since they are establishing their operating methods. Eliot From nobody Mon Jun 9 13:39:18 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 718E91A02E6 for ; Mon, 9 Jun 2014 13:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRYXkAsrKFx2 for ; Mon, 9 Jun 2014 13:39:15 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 575051A02F2 for ; Mon, 9 Jun 2014 13:39:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=436; q=dns/txt; s=iport; t=1402346354; x=1403555954; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=t6erqbj0okxjj8I88dlsS56KLElFyO/9B7OprnOvkI0=; b=mS9kCm0upf0rE0fDhYVH/pOqj3KGNN7ca+orPq/u5AUAGbboyxiki6VS mW9yctvhfFaB/ET+eHryH9EGysYKmwNto8cW62cxv1fqUWpkMdb7fXMH7 YvrnEkzoCNQErn48jlSfv5EQsRf8TiWNQNWS2FqUrh0y+pU9upMCVzhK3 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am8KAIIallOtJssW/2dsb2JhbABZhySndQEBAQEBAQUBmRABgSh1hAMBAQEEI08GEQsOCgICBRYEBwICCQMCAQIBRQYBDAgBAYg+rCCfGReBKoQziRaCdYFMAQOaIZNFgXyBQjs X-IronPort-AV: E=Sophos;i="4.98,1003,1392163200"; d="scan'208";a="79859102" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 09 Jun 2014 20:39:11 +0000 Received: from ELEAR-M-C3ZS.CISCO.COM ([10.61.201.68]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s59KdBmd001082; Mon, 9 Jun 2014 20:39:11 GMT Message-ID: <53961B6F.4070708@cisco.com> Date: Mon, 09 Jun 2014 22:39:11 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Andrew Sullivan , internetgovtech@iab.org, The IESG References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> In-Reply-To: <20140609160101.GJ27145@mx1.yitter.info> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/E18y0a34QxBWoqgPLXEkGXm-11Q Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 20:39:15 -0000 On 6/9/14, 6:01 PM, Andrew Sullivan wrote: > Also, does anyone worry about the potential conflict of having the > organization whose contractual relationship is going to change pay for > everyone's participation (particularly when that participation is > apparently on an individual basis)? > Somewhat, yes. Let's put this another way: should we be asking ISOC to pay for travel of candidates who ask for support? Eliot From nobody Mon Jun 9 13:47:36 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D7F1A032E for ; Mon, 9 Jun 2014 13:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7PRVDxCFI3t for ; Mon, 9 Jun 2014 13:47:34 -0700 (PDT) Received: from nike.wampumpeag.net (nike.wampumpeag.net [67.42.198.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B3341A0319 for ; Mon, 9 Jun 2014 13:47:34 -0700 (PDT) Received: from frog.local ([67.42.198.93]) by nike.wampumpeag.net (8.14.9/8.14.9) with ESMTP id s59KlXSv080341 for ; Mon, 9 Jun 2014 13:47:33 -0700 (PDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <53961D65.4000006@abenaki.wabanaki.net> Date: Mon, 09 Jun 2014 13:47:33 -0700 From: Eric Brunner-Williams User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: internetgovtech@iab.org References: <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <20140609190830.GR27145@mx1.yitter.info> <53960817.3050308@dcrocker.net> <59C0992A-037D-40AC-BFD9-419A4B65D4A4@virtualized.org> <53960E0F.3080607@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/tBlPPAB5S9NoR4dDdFW0uMSbbTc Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 20:47:35 -0000 On 6/9/14 12:57 PM, David Conrad wrote: > Simply: I do not believe it appropriate in the context of the IANA Transition proposal for the formulation of the consensus proposal across the various stakeholders to be developed in a non-open and non-transparent way. Yes, I am aware that this means it is less efficient, however I do not believe there is any rush here. > > Feel free to differ. I agree. Eric From nobody Mon Jun 9 13:53:53 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 470811A02C6 for ; Mon, 9 Jun 2014 13:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwO5_-ylNilg for ; Mon, 9 Jun 2014 13:53:51 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17F661A0330 for ; Mon, 9 Jun 2014 13:53:50 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id n3so2307281wiv.2 for ; Mon, 09 Jun 2014 13:53:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=b2u3/378YQpKyoHP4I2S8pwkzYXq//j7eYD36l13Qds=; b=HDJGzeBqDn/ZbDRWSbXfjLcQeM4d2ItauDNTF9JPANFV8DIbN8DUP//WgnoBhYaG38 wtb1G5597HX+wCOakkBqPlKgUKuoyP/tr+RVb0R5VOeIRPXP1F663WuOYLDJSnGiVzJK MrtLgzo3alQYeV7cKYtJiz1vfXaQ6qwUGD4tx51Jve0rSpxOt9/uBvgNUh5cD523HfDm wDpu1PAjY6Ln+yATq7DWfv/37fk3/uEbGisMXDP9hcpcWZVRtcvz9VgaJJTo9FuiWs9Y Mmob/6eBKzNj/tEdXnbxy8s5d3H1/2Opfp8cEqDBdjY3mKAZU1J3aoUo0hwUUcBzmhMP hNkg== MIME-Version: 1.0 X-Received: by 10.194.83.39 with SMTP id n7mr11837374wjy.58.1402347229537; Mon, 09 Jun 2014 13:53:49 -0700 (PDT) Received: by 10.217.37.200 with HTTP; Mon, 9 Jun 2014 13:53:49 -0700 (PDT) In-Reply-To: <53961B6F.4070708@cisco.com> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <53961B6F.4070708@cisco.com> Date: Mon, 9 Jun 2014 22:53:49 +0200 Message-ID: From: =?UTF-8?Q?Roger_J=C3=B8rgensen?= To: Eliot Lear Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/4xMJkxCfJ4-UZKaxvUkZ8x_Zxm0 Cc: internetgovtech@iab.org, The IESG , Andrew Sullivan Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 20:53:52 -0000 On Mon, Jun 9, 2014 at 10:39 PM, Eliot Lear wrote: > > On 6/9/14, 6:01 PM, Andrew Sullivan wrote: >> Also, does anyone worry about the potential conflict of having the >> organization whose contractual relationship is going to change pay for >> everyone's participation (particularly when that participation is >> apparently on an individual basis)? >> > > Somewhat, yes. Let's put this another way: should we be asking ISOC to > pay for travel of candidates who ask for support? Not a bad idea, but ... given that ISOC already have 2 seats, if they pick up the expenses for IETF and maybe IAB, that can be understood as they have 6 seats. Is that what we want? I think it's actual better to let ICANN pick up the expenses and we chose people we trust and know can handle it represent us there. Or an split between ISOC and ICANN... -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no From nobody Mon Jun 9 14:02:06 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D8B1A01EB; Mon, 9 Jun 2014 14:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.251 X-Spam-Level: X-Spam-Status: No, score=-5.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K293rtxs0qLv; Mon, 9 Jun 2014 14:02:01 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 884B31A01DD; Mon, 9 Jun 2014 14:02:01 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Wu6fq-0006GY-KS; Mon, 09 Jun 2014 17:00:10 -0400 Date: Mon, 09 Jun 2014 17:01:48 -0400 From: John C Klensin To: Ted Lemon , Barry Leiba , Andrew Sullivan Message-ID: <1E8054717F7369872099FDD6@JcK-HP8200.jck.com> In-Reply-To: <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> 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 X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/LwhD-VI23D7VG7zO0z-4t3ho2XE Cc: internetgovtech@iab.org, iesg@ietf.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 21:02:03 -0000 --On Monday, June 09, 2014 11:41 -0400 Ted Lemon wrote: >... > We could also ask ICANN to fund the participants if there were > someone we'd want to participate who otherwise would not be > able to. Whether we should ask, and whether they would do > it, and whether it would be appropriate for them to do it are > questions to which I do not know the answers. But if there's > a real problem here, it would be worth considering ways to > solve it that don't rely on promises that might not be able to > be kept. Ted, I see the tradeoffs here as very complex. I hope the answer isn't "the rich, or richly-supported, are better than the rest of us" but it might, sadly, be the best we can do. In addition to the issues identified by Bob and Andrew (see below), as soon as we volunteer to pay people to go to meetings (or to support their attendance), we immediately draw volunteers who either have a strong interest in international travel and what Marshall Rose describes as "fine lunches and dinners" or who want free transport to meetings they might struggle to go to otherwise (and, in the words of a senior ICANN staff member who apparently no longer sees it as a problem, "who have too much time on their hands"), both independent of real interest in and qualification for the work. Neither may be the best pool of people from whom to select; neither pool is likely to be a good source of candidates who would dedicate themselves to reduction of the costs (including both time and travel requirements). I wish I were more confident in the ability of the IAB and IESG to read candidate letters and filter those people out, but doing really well at it requires mind-reading and that isn't part of the selection criteria for members of those bodies. Note too that "someone we'd want to participate" isn't a criterion that is being optimized if the process relies on those who self-nominate and who do so against a background of uncertainty about the level of effort required and whether or not support will be available. This is not a new problem -- the ad hoc group that was turned into a nominating committee for IGF MAG positions from the "technical community" faced exactly the same issues and, with considerable prompting from ISOC Staff and a great deal of time pressure, basically threw up its hands and went with those who had the resources. It wasn't new then either. As I have tried to say in other ways, I'm not at all convinced that the right answer is refusing to play. I think that, whether we intended it or not, we are much too involved at this point to take our marbles and go home, at least without losing all rights to comment on the results. On the other hand, I think it is very important that the extended IETF community discuss these issues in enough depth that there is a reasonable understanding of what we are getting ourselves into. --On Monday, June 09, 2014 12:01 -0400 Andrew Sullivan wrote: > On Mon, Jun 09, 2014 at 08:56:48AM -0700, Bob Hinden wrote: >> >> It is my understanding from the process that ISOC is doing, >> that ICANN will provide travel support for people who are >> participants in the coordination group. We had the same >> question. > If that's the case, it isn't indicated in the materials ICANN > posted the other day as far as I can see. I just went back and reviewed those materials and can find no hint of any travel or other support for anyone associated with the Coordination Group process other than the members of the " small independent Secretariat". I wouldn't care to speculate whether the representatives of ICANN-created bodies (e.g., ALAC, RSSAC, SSAC, and/or GAC), or any of all of the nine appointees from name-sales-related bodies, will be funded for travel, but there is no indication that others are anything but on their own. Note Olivier's comment about presumed travel support for the ALAC representatives and see below. > Also, does anyone worry about the potential conflict of having > the organization whose contractual relationship is going to > change pay for everyone's participation (particularly when > that participation is apparently on an individual basis)? In general, I do. A lot. But, for this particular, case, I see no problem with ICANN providing that support as long as three conditions are met: (i) The decisions as to which individuals are selected or, when selected, supported, not under ICANN (or ICANN staff) control. (ii) ICANN (including staff) do not get to decide to support representatives from some bodies and not others. Either appointees from every group are offered travel support or no one is. Either appointees from every group are offered honoraria or other support for time invested or no one is. Note that, as with Board member compensation, no one is obligated to accept offered funding, but the offer must be there. (iii) Whatever the decisions are going to be, balance, openness, and transparency require that they be clear and public considerably before the nomination/selection process for any of the 27 seats reaches its first benchmark (typically the close of a call for candidates). If the support/ resource rules are not clear by that time, people may self-select out of applying because of uncertainty about resources, thereby biasing things toward those who can assume responsibility for an essentially unlimited resource commitment. Without those three principles, there could easily be an appearance that ICANN is trying to assure representation of particular points of view... not much less so than under the original plan of selection by the ICANN and GAC Chairs. Note that, if a side deal has been made to support ALAC representative participation without a general and public announcement of support for all selected Coordination Group member (as appears to be the case) the second and third principles have already been violated. best, john From nobody Mon Jun 9 14:57:40 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBFB1A0347 for ; Mon, 9 Jun 2014 14:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vVdl3TLnjgf for ; Mon, 9 Jun 2014 14:57:37 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 013871A032D for ; Mon, 9 Jun 2014 14:57:37 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Mon, 9 Jun 2014 14:57:36 -0700 From: Theresa Swinehart To: Bob Hinden , Ted Lemon Date: Mon, 9 Jun 2014 14:57:36 -0700 Thread-Topic: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions Thread-Index: Ac+ELdKzXTrKODvJQvKFP1cPgVjb3Q== Message-ID: References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> In-Reply-To: <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3485182786_19123079" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/pe29vpyDN3c2xG_ojqHUX77UL9k Cc: John C Klensin , =?iso-8859-1?Q?Roger_J=F8rgensen?= , Barry Leiba , "internetgovtech@iab.org" , The IESG Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 21:57:38 -0000 --B_3485182786_19123079 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit All, Apologies for the delay in responding, and appreciate the exchanges. To provide clarification, the Coordination Group members will not be remunerated for their time. However, travel, meal and lodging costs for Coordination Group members to participate in Coordination Group meetings will be covered by ICANN, upon request and in accordance with ICANN's community travel support guidelines. The announcement page will be updated to reflect this information and provide additional details. Kind regards, Theresa On 6/9/14 11:56 AM, "Bob Hinden" wrote: >Ted, > >On Jun 9, 2014, at 8:41 AM, Ted Lemon wrote: > >>> We can't change that for the purpose of appointing representatives to >>> the Coordination Group. >> >> We could also ask ICANN to fund the participants if there were someone >>we'd want to participate who otherwise would not be able to. Whether >>we should ask, and whether they would do it, and whether it would be >>appropriate for them to do it are questions to which I do not know the >>answers. But if there's a real problem here, it would be worth >>considering ways to solve it that don't rely on promises that might not >>be able to be kept. > >It is my understanding from the process that ISOC is doing, that ICANN >will provide travel support for people who are participants in the >coordination group. We had the same question. > >It would be good if someone from ICANN would confirm that here. > >Bob > > --B_3485182786_19123079 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIT5AYJKoZIhvcNAQcCoIIT1TCCE9ECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EbAwggcrMIIGE6ADAgECAhAIdtjUtK7QT3NoaZzvBRL0MA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMzA5MDYwMDAw MDBaFw0xNjA5MDYxMjAwMDBaMIHSMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0aW9u IGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczESMBAGA1UECxMJRXhlY3V0aXZlMRow GAYDVQQDExFUaGVyZXNhIFN3aW5laGFydDEqMCgGCSqGSIb3DQEJARMbdGhlcmVzYS5zd2lu ZWhhcnRAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2WpifUYI zzBKS3JzHOQFYu3T64+MQCpwxeEZwKTOZuzWWjKOERedHRdzkA2P0DlrP/Ue7ASWXsirOA4M u+9y6bBTFEPfQTFiLyN+jyf2c9BgQ10y9g7/1Ju/DJHoqBe145gmjy+nKwmsZktqFMq6S/Fq Gtn/PfuAa2b/AAA0RSUPI9Mc7KMz45jAyUwaFVWrAGjtmbqqQ1AvorNF3B/Fsj0Deov+IKu6 sKcUeXuU1L/q3xD1vH4pbP8P6ozrC32aalOF3ZgXBncn9pjvWhWn2lXzniwEJtOrUxonHYhp pSpYI1Q8Xu650TN0TZcWvOBkAytylmtXHl/xv30A3L4uZQIDAQABo4IDajCCA2YwHwYDVR0j BBgwFoAUFQASKxOYspkH7R7for5XDStnAs0wHQYDVR0OBBYEFN1D/9FvYoTYopLyTDCkR2Zl TZeGMCYGA1UdEQQfMB2BG3RoZXJlc2Euc3dpbmVoYXJ0QGljYW5uLm9yZzAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMH0GA1UdHwR2MHQwOKA2oDSG Mmh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMDig NqA0hjJodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNy bDCCAcUGA1UdIASCAbwwggG4MIIBtAYKYIZIAYb9bAQBAjCCAaQwOgYIKwYBBQUHAgEWLmh0 dHA6Ly93d3cuZGlnaWNlcnQuY29tL3NzbC1jcHMtcmVwb3NpdG9yeS5odG0wggFkBggrBgEF BQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBzACAAQwBlAHIAdABp AGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMAZQBwAHQAYQBu AGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQAFMAIABh AG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUAZQBt AGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABh AG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAg AGIAeQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wdwYIKwYBBQUHAQEEazBpMCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQQYIKwYBBQUHMAKGNWh0dHA6Ly9jYWNlcnRz LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3J0MAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQEFBQADggEBAM53htQ+sIXBmw4KMrJDKKKJteaZMF7HRN7fy6n6nN0oiWaV bbyNk9NwwL14/iz6Q2GMP1gZc1FMGBTywlKUZYVHAGJNogFu10m33Nemmj4PVZJmjVwK0/Rr kXnz31oSJGVTmF12kraaos5U0R2irbSGRDUkUXu82tu6eJImTE3whzpaN1Cln7Ysp1ViHCtF Aj6r9zRUXtKcEqxRkGPMFfa5td3bTuESA5CytvIPfYRCtJUkO2Y7itq75jv4rVViZ5mJhjJj qYpTN7e/JA9k0AJHovALdeBEz2pYBCLLKsPCn2prFjBUjSFPD/ijbKdbHtTguD/WOPBoQQsl 02MGJxAwggbCMIIFqqADAgECAhAKBN8hdF1NK4zqM3IFAFDpMA0GCSqGSIb3DQEBBQUAMGUx CzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdp Y2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjEx MTAwMDAwMDBaFw0yMTExMTAwMDAwMDBaMGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0 IEFzc3VyZWQgSUQgQ0EtMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOiCLZn5 ysJClaWAc0Bw0p5WVFypxNJBBo/JM/xNRZFcgZ/tLJz4FlnfnrUkFcKYubR3SdyJxArar8te a+2tsHEx6886QAxGTZPsi3o2CAOrDDT+GEmC/sfHMUiAfB6iD5IOUMnGh+s2P9gww/+m9/ui zW9zI/6sVgWQ8DIhFonGcIj5BZd9o8dD3QLoOz3tsUGj7T++25VIxO4es/K8DCuZ0MZdEkKB 4YNugnM/JksUkK5ZZgrEjb7SzgaurYRvSISbT0C58Uzyr5j79s5AXVz2qPEvr+yJIvJrGGWx wXOt1/HYzx4KdFxCuGh+t9V3CidWfA9ipD8yFGCV/QcEogkCAwEAAaOCA28wggNrMA4GA1Ud DwEB/wQEAwIBhjA7BgNVHSUENDAyBggrBgEFBQcDAQYIKwYBBQUHAwIGCCsGAQUFBwMDBggr BgEFBQcDBAYIKwYBBQUHAwgwggHGBgNVHSAEggG9MIIBuTCCAbUGC2CGSAGG/WwBAwAEMIIB pDA6BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0 b3J5Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQA aABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMA IABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQA IABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIA dAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUA ZAAgAGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAPBgNVHRMBAf8E BTADAQH/MH0GCCsGAQUFBwEBBHEwbzAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNl cnQuY29tMEcGCCsGAQUFBzAChjtodHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DQUNlcnRzL0Rp Z2lDZXJ0QXNzdXJlZElEUm9vdENBLmNydDCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2Ny bDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0 cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNV HQ4EFgQUFQASKxOYspkH7R7for5XDStnAs0wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6ch nfNtyA8wDQYJKoZIhvcNAQEFBQADggEBAIRhTkEeuHYEKrW274/yVYW5XVb+Cpjm5L1lin1A KdP8sV1F/Tq4KlszSyRczbm05HOtYV12rXQzimbVI69MH3JuRdl1QLuiO8+NSS/AQbDiKaNR OENQmRSsMwY1Yol9d6lSB+VsIFe2gbpvvLPClO12AoDZfM6FqBzsx0NKS7FXz3LO3/UlPMsi T/2fUtE3ywi7OD7g1T5veQmtW3wxs3c1w+Rj+WgKmAfnRjh3hNI+l7wKoKisJU9EbpHh0lqv a+8wHI2jREKzEIsj+tfmNXQ3rM/rq1gfyYgj/zbUB+o0akfqnZVsnilPU+3jK5UgTirPlmB6 +CyA8JVSzimWgWIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEB BQUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3 dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAe Fw0wNjExMTAwMDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQK EwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8K DIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8 R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQ jpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8B Rob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEw DgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1R i6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEB BQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk 0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe 3WLxvlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7z fx9jEB76jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/DCC AfgCAQEwdjBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQL ExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2VydCBBc3N1cmVkIElEIENBLTEC EAh22NS0rtBPc2hpnO8FEvQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTeoQNnUIr4 2jK/XKDZ+CPajk8XmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNDA2MDkyMjE5NDZaMA0GCSqGSIb3DQEBAQUABIIBANI5fWjE8vWxB4a4fdjMJaFkpzIr wYgaxAta3Ekp9/fCCXlKca5Yo5Ru8ljQeay3av1woo6vwnvdjoTfqe6gIT2Bi9rHMrReCaiy 4QgnTA/G68ifZRbYWkRJHAFNTSeXDJOVl4rH4kkx0HuOvWEfly30NSikw82VaVkThz0F1VvC t0fxl5qV9PJDK841/ldKV6lrj7sQPADI+dJsX95mWR3QDFh25U5EErQigcZLeCES1NUHIUaL QNz16jq1NYEh75W45vxyABXA2aRvO4dmugycnsBFyc+Oma3TaStJtTYzrXNaLz3Ju9WuMZqi oMlBJKkzNU1CnThOg1OIVpIuov4= --B_3485182786_19123079-- From nobody Mon Jun 9 16:17:03 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03AB11A0246; Mon, 9 Jun 2014 16:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzboSWf5_XYM; Mon, 9 Jun 2014 16:16:52 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E109C1A004E; Mon, 9 Jun 2014 16:16:51 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.142.146]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s59NGb0F029206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2014 16:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1402355811; x=1402442211; bh=QrJYTuxqwxjVZ7G5t9ksu99Pnn3BVInhH7jhQjyM4nw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=MxvtB5OHg5VAHp608FfNp3LzqeR/GMsloixUOgI8lIbJSkkVvT2INGXngHrzPrPrw Amwb2KpSojXK3KnOJj5JAwZ2Ah0gltUfk2qsf3NqcqeKgbfbNmcsXOt3ZJ/7moFbkb RabBUVZoa8RllKm6ILG4IsfakE9x4h/4/BZPNpKI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1402355811; x=1402442211; i=@elandsys.com; bh=QrJYTuxqwxjVZ7G5t9ksu99Pnn3BVInhH7jhQjyM4nw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=tL/OaCtISQX4vFpFkEPftQnnR1s+XrcDDH0HXpzaOZCzPaGFgfX7cgJ1RKZDJgm5x UURViNjOyHuSaj0hZYoor5TNaOR8E6rSYhtdKkarB3tVk9O3zeaLOyn67Rbnh8uAUH LUCuksZNSls5oA6WYS/Sk48B8eAtJXZj7lSyCI9U= Message-Id: <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 09 Jun 2014 14:17:54 -0700 To: David Conrad From: S Moonesamy In-Reply-To: <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/MLYxz5FFMx-2d8i1IL3luGY_RrU Cc: internetgovtech@iab.org, iesg@ietf.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 23:16:58 -0000 Hi David, At 11:46 09-06-2014, David Conrad wrote: >There are a myriad of conflict potentials, among the least of which >is that an individual was subsidized to participate. Everyone has >an agenda and ulterior motives. The question is whether or not >those agendas/ulterior motives align with what is in the interests of the IETF. My short answer to the above would be "yes". >As do the RIRs (via the ASO MoU). Yes. >If they understand and accept the role of representing the IETF and >agree to absolute transparency, I see no problem in them accepting payment. I am still trying to resolve that question. >However, this is sort of putting the cart before the horse as so >far, we've only seen folks declining the opportunity to volunteer :). It may seem like an opportunity if the motivation is travel experience. I'll pick up a comment from one of your messages: "Tell that to folks participating in the IETF from Latin America or Africa." That's the comment which the representative will get. Let's assume that I put my name forward. If I give the honest response the (rest of the) IETF won't like it. If I give the politically correct response the other party won't believe it. There is the time commitment. Depending on how one views volunteer work it can entail digesting voluminous reports and other material to understand the issues. There are good reasons for people to decline the opportunity. :-) Regards, S. Moonesamy From nobody Mon Jun 9 18:37:18 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9065E1A0341 for ; Mon, 9 Jun 2014 18:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94w1gsVahjeY for ; Mon, 9 Jun 2014 18:37:12 -0700 (PDT) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEE441A033D for ; Mon, 9 Jun 2014 18:37:11 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id ey11so109225pad.10 for ; Mon, 09 Jun 2014 18:37:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=wj0US2iUmCQNczF9hEPTAeZJ9aosjno6ZZmLL6pxysw=; b=EMsZi1N3HJ6a7boaKx1TpGIM08LSk0m+VoIw8IiNqYajMBavWJIixRvUgcWx2pXiiP SgSchTryswtKJ3U6iAWYtghDQRjO7vLg6SsXjMrtAzcYPhHeU0ewYyiyLOB7FiSyBjVg VF7C8UW2E7Sd2+t1gNs46RCHD8/BYXW7A8nQOD3zRlYF79M2UhFT5hAJ0Qd5bvtaGkC+ Q6ADRqrQug4J1YzXFBbVmNBcUtxlKM01jd2fOQQZ7gcYCflvPMeFdi0LLSK14s1WhqZx C2W93HCbJD/qZtZw1Q8Z05+OaT/uNLFNivu5tWeTi/JhUQeDpI+07T4FXg/GcfVizGl0 z/6g== X-Gm-Message-State: ALoCoQlRimK+bXmb11PJu27k0xRKemtO08o+r1FB2EvD7Fa0bRefJEvCNiWgMzxGzokNJounXnGJ X-Received: by 10.66.142.199 with SMTP id ry7mr2152198pab.10.1402364231172; Mon, 09 Jun 2014 18:37:11 -0700 (PDT) Received: from [10.0.1.3] (c-24-6-168-86.hsd1.ca.comcast.net. [24.6.168.86]) by mx.google.com with ESMTPSA id fe3sm66263994pbd.66.2014.06.09.18.37.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Jun 2014 18:37:10 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_6E1C3199-2004-47AB-B5A2-61BC2CB34314"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: David Conrad In-Reply-To: <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> Date: Mon, 9 Jun 2014 18:37:06 -0700 Message-Id: References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/8LKMLoefCZ18HXVCg20M_KCz-rA Cc: internetgovtech@iab.org, iesg@ietf.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 01:37:15 -0000 --Apple-Mail=_6E1C3199-2004-47AB-B5A2-61BC2CB34314 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii S Moonesamy, On Jun 9, 2014, at 2:17 PM, S Moonesamy wrote: >> However, this is sort of putting the cart before the horse as so far, = we've only seen folks declining the opportunity to volunteer :). >=20 > It may seem like an opportunity if the motivation is travel = experience. =20 Hmm. =20 ICANN's next 5 meetings: London (same venue as the IETF, o joy o = rapture), Los Angeles, [Africa], [Latin America/Caribbean], [Europe]. IETF's next 5 meetings: Toronto, Honolulu, Dallas, Prague, Yokohama. Seems there will be plenty of opportunities for travel experience... In any event, it is an opportunity to actively contribute towards an = effort that will resolve a "difference of opinion" between what some = people within the IETF (and others) think and what some people = associated with governments all over the world (and others) think about = answer to the question "=46rom where does the authority behind the IANA = functions come?". Having personally been at the sharp end of that = particular question in the past, I believe it will be a quite good if = there is resolution. > There are good reasons for people to decline the opportunity. :-) Sure. However, as with anything, if you believe strongly in something, = you may also find good reasons to accept. Or folks can let the = commercialized DNS and government folks decide. What could go wrong? :) Regards, -drc --Apple-Mail=_6E1C3199-2004-47AB-B5A2-61BC2CB34314 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJTlmFCAAoJENV6ebf0/4rXg5oH/2HDe7u4LZKN7jYhvdYkqV1i oeX103cH2+4hS4d3BlIrfMlK9HB/gWGJDzxB3ua+6DOU7O+t2QO+VwqUAYIoyrN+ fImmEmcsElaNiJciWNDeI42wUYJKPt0VWpTJ+xi3wTnDxWf/Eolck1B1qTrXJ/t+ yev32/SDei2aBxMXPokbPWCP+YgP9xExwEDOzKBgWtx+5JWXP6Q0g9AS8lYIeoIb E2v3hq83PPEAEqqbFCHmvMsbmWdtusaRgWAL53dizGu8rrYfx3Np+dK7i3aAXl/v OmRI25jdKjZ3VK1E39ygPDfQ18PEdqsJ9+CR+SLsNIAZ26KoObYTNOWYrp0g+0o= =r7wD -----END PGP SIGNATURE----- --Apple-Mail=_6E1C3199-2004-47AB-B5A2-61BC2CB34314-- From nobody Mon Jun 9 22:16:46 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D990C1A03CB for ; Mon, 9 Jun 2014 22:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RldcS_rdJoOe for ; Mon, 9 Jun 2014 22:16:36 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2EC21A03D4 for ; Mon, 9 Jun 2014 22:16:29 -0700 (PDT) Received: from [192.168.1.32] (frobbit.cust.teleservice.net [85.30.128.225]) by mail.frobbit.se (Postfix) with ESMTPSA id A64EB20823; Tue, 10 Jun 2014 07:16:27 +0200 (CEST) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Content-Type: multipart/signed; boundary="Apple-Mail=_C1E85A5D-FC77-4B20-981C-7EDE01A13F7A"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <4335C1C8-350C-4C1D-AF79-6E8E26353801@frobbit.se> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Date: Tue, 10 Jun 2014 07:16:26 +0200 References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <53961B6F.4070708@cisco.com> To: internetgovtech@iab.org, The IESG In-Reply-To: X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/EQGNQGaOoV1Mk-emMyo4NuuGmgY Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 05:16:38 -0000 --Apple-Mail=_C1E85A5D-FC77-4B20-981C-7EDE01A13F7A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 9 jun 2014, at 22:53, Roger J=F8rgensen wrote: > I think it's actual better to let ICANN pick up the expenses and we > chose people we trust and know can handle it represent us there. Or an > split between ISOC and ICANN... I now know ICANN will pick up expenses, but not more. Patrik --Apple-Mail=_C1E85A5D-FC77-4B20-981C-7EDE01A13F7A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD4DBQFTlpSqrMabGguI180RAuppAJd4hGn6DGztJB/ZiOI3sVnFU0xwAJ9NrGTs tQwPsFs6+lgNZLk+ixuTRA== =PUyK -----END PGP SIGNATURE----- --Apple-Mail=_C1E85A5D-FC77-4B20-981C-7EDE01A13F7A-- From nobody Mon Jun 9 22:17:43 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F731A03E4 for ; Mon, 9 Jun 2014 22:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wr4_J245atwI for ; Mon, 9 Jun 2014 22:17:37 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 403DE1A03D4 for ; Mon, 9 Jun 2014 22:17:37 -0700 (PDT) Received: from [IPv6:2a02:80:3ffc::6940:6b0a:abd5:c1c1] (unknown [IPv6:2a02:80:3ffc:0:6940:6b0a:abd5:c1c1]) by mail.frobbit.se (Postfix) with ESMTPSA id AFFF420823; Tue, 10 Jun 2014 07:17:35 +0200 (CEST) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Content-Type: multipart/signed; boundary="Apple-Mail=_2600D912-CEF1-42FB-823E-C728ADBA39E2"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <93A8EB1F-D633-4B5F-8BD9-4F4D9B653D96@frobbit.se> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Date: Tue, 10 Jun 2014 07:17:34 +0200 References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <53961B6F.4070708@cisco.com> <4335C1C8-350C-4C1D-AF79-6E8E26353801@frobbit.se> To: internetgovtech@iab.org, The IESG In-Reply-To: <4335C1C8-350C-4C1D-AF79-6E8E26353801@frobbit.se> X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/X8nHysXMX1j1vazDqwNOMj9QMVM Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 05:17:39 -0000 --Apple-Mail=_2600D912-CEF1-42FB-823E-C728ADBA39E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 10 jun 2014, at 07:16, Patrik F=E4ltstr=F6m wrote: > On 9 jun 2014, at 22:53, Roger J=F8rgensen wrote: >=20 >> I think it's actual better to let ICANN pick up the expenses and we >> chose people we trust and know can handle it represent us there. Or = an >> split between ISOC and ICANN... >=20 > I now know ICANN will pick up expenses, but not more. I.e. forgot the quote: > Apologies for the delay in responding, and appreciate the exchanges. = To > provide clarification, the Coordination Group members will not be > remunerated for their time. However, travel, meal and lodging costs = for > Coordination Group members to participate in Coordination Group = meetings > will be covered by ICANN, upon request and in accordance with ICANN's > community travel support guidelines. The announcement page will be = updated > to reflect this information and provide additional details. Patrik --Apple-Mail=_2600D912-CEF1-42FB-823E-C728ADBA39E2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTlpTurMabGguI180RAsGLAJ413A67KBoURXhoYq0s+eiwirtVbACeIgOU t7zwvr31alaXbJ/qZlPGuRk= =/3KE -----END PGP SIGNATURE----- --Apple-Mail=_2600D912-CEF1-42FB-823E-C728ADBA39E2-- From nobody Mon Jun 9 22:41:07 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18DE1A03E4 for ; Mon, 9 Jun 2014 22:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.152 X-Spam-Level: X-Spam-Status: No, score=-12.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w16c7IZ2YhT9 for ; Mon, 9 Jun 2014 22:41:00 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 012D41A03DC for ; Mon, 9 Jun 2014 22:40:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2132; q=dns/txt; s=iport; t=1402378857; x=1403588457; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=g3Yidm18X0aTOPhhRvipAOFh6hwmlEjYxYmEI+FRIqU=; b=FbnUiWfv9rpgB1BYZca2oRac8no7ozUFQ1X9G+LgvGww8S1372U3rpU+ WDL6UxoL5//zpmm1p+xu1brUCtG75DFrcfN/oKIuPb8VEMgHtKxDOOqa2 GTuSq4/w9SDyCnmg2K5eKPkMHWXZ70QDAI49vFloaLA2jlZYBM8a8FMX5 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am8KAE6ZllOtJssW/2dsb2JhbABZhySneAEBAQEBAQUBmRABgSN1hAMBAQEEI1UBEAsYAgIFFgQHAgIJAwIBAgFFBgEMAQcBAYg+qyOfNxeBKoQzg2OESWMHgnWBTAEDjWOMPpNFgXyBQjs X-IronPort-AV: E=Sophos;i="4.98,1007,1392163200"; d="scan'208";a="80993416" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 10 Jun 2014 05:40:55 +0000 Received: from ELEAR-M-C3ZS.CISCO.COM ([10.61.171.147]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s5A5esSO012872; Tue, 10 Jun 2014 05:40:54 GMT Message-ID: <53969A66.4080903@cisco.com> Date: Tue, 10 Jun 2014 07:40:54 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: John C Klensin , Ted Lemon , Barry Leiba , Andrew Sullivan References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <1E8054717F7369872099FDD6@JcK-HP8200.jck.com> In-Reply-To: <1E8054717F7369872099FDD6@JcK-HP8200.jck.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/Ioeh60O3d8B9iJEfTAIeTLnWhpc Cc: internetgovtech@iab.org, iesg@ietf.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 05:41:02 -0000 Hi John, Just on this one point: On 6/9/14, 11:01 PM, John C Klensin wrote: > Ted, I see the tradeoffs here as very complex. I hope the > answer isn't "the rich, or richly-supported, are better than the > rest of us" but it might, sadly, be the best we can do. In > addition to the issues identified by Bob and Andrew (see below), > as soon as we volunteer to pay people to go to meetings (or to > support their attendance), we immediately draw volunteers who > either have a strong interest in international travel and what > Marshall Rose describes as "fine lunches and dinners" or who > want free transport to meetings they might struggle to go to > otherwise (and, in the words of a senior ICANN staff member who > apparently no longer sees it as a problem, "who have too much > time on their hands"), both independent of real interest in and > qualification for the work. Neither may be the best pool of > people from whom to select; neither pool is likely to be a good > source of candidates who would dedicate themselves to reduction > of the costs (including both time and travel requirements). > > I wish I were more confident in the ability of the IAB and IESG > to read candidate letters and filter those people out, but doing > really well at it requires mind-reading and that isn't part of > the selection criteria for members of those bodies. No it doesn't. A qualified candidate is going to have a demonstrated record in a number of areas. For me that includes first and foremost a full knowledge of the IANA functions and their complexities, familiarity with both IETF and ICANN processes, ability to build consensus, experience establishing organizational structures, and some amount of architectural knowledge. These positions are important, and the implication of your note is that neither the IAB nor the IESG would take seriously their responsibilities to select qualified candidates. Moreover, since the IAB has already selected various funded positions for ICANN, we have some experience that the flood gates don't break just for a meal and a flight. Eliot From nobody Mon Jun 9 22:50:51 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7368B1A03F7 for ; Mon, 9 Jun 2014 22:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eT_0U8dcH43B for ; Mon, 9 Jun 2014 22:50:46 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40F421A03E4 for ; Mon, 9 Jun 2014 22:50:46 -0700 (PDT) Received: from [192.168.1.32] (frobbit.cust.teleservice.net [85.30.128.225]) by mail.frobbit.se (Postfix) with ESMTPSA id BC61E233CA; Tue, 10 Jun 2014 07:50:43 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_84A23F7B-C8AC-4BB8-9AE1-E53D4F15D77F"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <53969A66.4080903@cisco.com> Date: Tue, 10 Jun 2014 07:50:41 +0200 Message-Id: <0DFF94DE-7DD2-4813-8B47-781B2A3E8815@frobbit.se> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <1E8054717F7369872099FDD6@JcK-HP8200.jck.com> <53969A66.4080903@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/YZJP54Nbf9jOuX6-zBcs9BeBIcQ Cc: Andrew Sullivan , internetgovtech@iab.org, Ted Lemon , John Klensin , Barry Leiba , The IESG Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 05:50:47 -0000 --Apple-Mail=_84A23F7B-C8AC-4BB8-9AE1-E53D4F15D77F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Let me add a few suggestions that unfortunately do not make things = easier. I think you must to some degree in parallell do the following (in no = specific order): - Appoint people, the timeline for appointment is very aggressive - Stay by your view that the steering committee is only coordinating, = work is to be done elsewhere - Ensure people being appointed understand IAB view on bing coordinator = and not more - Continue to be "on your toes" regarding pointing out the group should = only be coordinating, that the over time shrinking time is not not = optimal (the contrary), and other things that might come up - Regarding "elsewhere", create bonds horizontally between IAB and other = "affected groups", and do not rely on all communication going through = (coming from) ICANN, do ISOC have staff working on these things in very = close coordination with IETF? - Be prepared to appoint people to elsewhere, where the work is done -- = I have no clear indication coordinated work happens outside of ICANN at = the moment, but who knows Patrik --Apple-Mail=_84A23F7B-C8AC-4BB8-9AE1-E53D4F15D77F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTlpyxrMabGguI180RAv/kAJ9lZooYNX0pb1c9t7L/VH8en+FxvgCeIAPI AJoy6unuhfWeQoTxuOMKpCA= =IL5U -----END PGP SIGNATURE----- --Apple-Mail=_84A23F7B-C8AC-4BB8-9AE1-E53D4F15D77F-- From nobody Tue Jun 10 00:25:19 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 270F71A023C; Tue, 10 Jun 2014 00:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 008PbCAYnyc8; Tue, 10 Jun 2014 00:25:12 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03F6F1A00B8; Tue, 10 Jun 2014 00:25:12 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WuGOx-0007BH-Ee; Tue, 10 Jun 2014 03:23:23 -0400 Date: Tue, 10 Jun 2014 03:25:02 -0400 From: John C Klensin To: David Conrad , Warren Lee Kumari Message-ID: <6D77774657909C285BA0E53B@JcK-HP8200.jck.com> In-Reply-To: <152FE254-0212-40E6-B8E1-410F8BB87E81@virtualized.org> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <152FE254-0212-40E6-B8E1-410F8BB87E81@virtualized.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 X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/KXSQs-OBWjmbE_2kMzlgkIGTm8I Cc: internetgovtech@iab.org, The IESG Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 07:25:14 -0000 --On Monday, June 09, 2014 10:33 -0700 David Conrad wrote: >... >>> Few of the local >>> attendees at those meetings participate effectively long-term >>> unless ICANN subsidizes their participation and the >>> categories of people who get subsidized do not include >>> individual technical experts. > > Actually, ICANN does subsidize a number of individual > technical experts including individuals participating in > ICANN's Security and Stability Advisory Committee (a dozen for > London I believe, including myself) and Root Server System > Advisory Committee, IDN-related experts, etc. And that is exactly where the type of conflict I'm concerned about arises. First, the selection and appointment process for individuals participating in those committee is not exactly open and transparent. Almost certainly there have been no widespread call for candidates, clear qualification and selection criteria, etc., for most of those slots. In at least one or two cases I'm aware of, there were clear selection criteria that were not adhered to in the selections made by staff. And the response to questions about the selection and selections processes was the notorious "the procedures were followed". Even after people are appointed, their continuation on those committees, etc., depends on retaining the good will of ICANN staff, so anyone who wants to continue feeding at the trough has power incentives to take positions supportive of ICANN's best interests even when they may not be the Internet's best interests. Should conflicts arise, some people will take principled positions (and risk getting fired or not reappointed) rather than modifying their positions to be consistent with staff-perceived ICANN interests, others won't. Given that situation, at least where the RSSAC and SSAC are concerned, ICANN (and the broader community) have gotten much better people, committees, and advice than we probably deserve, but the appearance of potential for improper influences is definitely still present. >>> (3) Returning to ICANN, much of the representation and >>> leverage for individual technical participants is supposed >>> to come through the Nomcom process, but that process has >>> been fairly consistently operated (and starved for resources) > > ICANN's Nomcom's budget for FY13 is $834,000. What sort of > resources do you believe ICANN's Nomcom is being starved? David, I'm not sure this is the right place to discuss this, but I'm the proud recipient of a note from the current Nomcom Chair that effectively says "that was mismanaged because we didn't have sufficient resources and couldn't get them". I'd consider the situation that prompted that remark to be an aberration were it not for the fact that I've heard similar remarks from several prior Nomcoms and am aware of other Nomcom situations that would have gone badly had strong-willed Nomcom chairs not succeeded in getting additional resources that were initially denied or restricted by ICANN's staff and systems. In at least this year's case, the combination of the problem that was claimed to be due to insufficient resources with insider information available to some potential candidates but not others served to prevent some potential candidates from applying and, consequently, to bias the candidate pool in the direction of those potential candidates connected to the usual well-resourced constituencies and interests. [...] best regards, john From nobody Tue Jun 10 00:45:28 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AAFA1A0495 for ; Tue, 10 Jun 2014 00:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiMr1AXU7WW0 for ; Tue, 10 Jun 2014 00:45:17 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F258C1A0463 for ; Tue, 10 Jun 2014 00:45:16 -0700 (PDT) Received: from vpn-client-208.netnod.se (vpn-client-208.netnod.se [192.71.80.208]) by mail.frobbit.se (Postfix) with ESMTPSA id 329BC20823; Tue, 10 Jun 2014 09:45:14 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_10B6D106-B080-4D56-9D15-A6E8889AD532"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <6D77774657909C285BA0E53B@JcK-HP8200.jck.com> Date: Tue, 10 Jun 2014 09:45:24 +0200 Message-Id: References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <152FE254-0212-40E6-B8E1-410F8BB87E81@virtualized.org> <6D77774657909C285BA0E53B@JcK-HP8200.jck.com> To: John Klensin X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/sI5MnMc77t_XfXa_jTrU8rrRsgY Cc: internetgovtech@iab.org, Warren Lee Kumari , David Conrad , The IESG Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 07:45:21 -0000 --Apple-Mail=_10B6D106-B080-4D56-9D15-A6E8889AD532 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 10 Jun 2014, at 09:25, John C Klensin wrote: > Given that situation, at least where the RSSAC and SSAC are > concerned, ICANN (and the broader community) have gotten much > better people, committees, and advice than we probably deserve, > but the appearance of potential for improper influences is > definitely still present. I feel I should take on a special hat and explain a few things so that = everyone understand how things in SSAC work. First, thanks for these words John. Secondly, in SSAC we do have a fixed number of "slots" available for = each ICANN meeting. That number was just increased from 10 to 15 for = FY'15. On the other hand, the ability for me as chair to "move slots" = from one meeting to another was removed (i.e. to have 30 a year). = Because of this, maximum number of individuals that can get travel = expenses paid is 15 for SSAC. That do btw matches approximately each one = of the groups in ICANN do get. I have as chair argued in favour of this increase in budget because I = have seen an increase in quality of our reports if the members of SSAC = actually do go to the ICANN meetings instead of the meetings their = normal funding channel would pay for (NANOG, RIPE, IETF etc). So yes, I = do see SSAC members have to increase the number of days on the road. In = some cases of course to the level where the pain is quite high ("get a = life!"). But funding has helped I claim, more than trouble it has = created. I do though of course share your worries. Within SSAC we select the funding the following way: - SSAC Chair and vice Chair (currently myself and Jim Galvin) do get = funding. - The remaining 13 slots are allocated randomly to whoever wants the = funding, and if more than 13 people do request funding (has not happened = yet) out of the 40 SSAC members, where 25-30 actually do come to ICANN = meetings, we intend to use the IETF random selection process for the = randomisation. On top of that: - SSAC Liaison to the ICANN Board do get funding from the ICANN Board = Travel support. - SSAC Liaison to NomCom do get funding from the NomCom funding. - Other SSAC members might get funding by other means indirectly from = ICANN due to membership of other funded groups. I am happy to discuss with you John and/or anyone else how to make this = process more stable and effective while still ensuring we stay away from = ending up in the trouble you describe. Patrik F=E4ltstr=F6m SSAC Chair --Apple-Mail=_10B6D106-B080-4D56-9D15-A6E8889AD532 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlOWt5QACgkQrMabGguI183JzACfUkSOVICDXyJoTfF6kifD1pqf G7gAniW1kXpkOn3Nte5IduJtkvm5swWt =f1Bu -----END PGP SIGNATURE----- --Apple-Mail=_10B6D106-B080-4D56-9D15-A6E8889AD532-- From nobody Tue Jun 10 02:52:53 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C181A0354 for ; Tue, 10 Jun 2014 02:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.955 X-Spam-Level: X-Spam-Status: No, score=0.955 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmDEKjrfJuJf for ; Tue, 10 Jun 2014 02:52:49 -0700 (PDT) Received: from p130.piuha.net (unknown [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1071A0166 for ; Tue, 10 Jun 2014 02:52:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 6803B2CCE4; Tue, 10 Jun 2014 12:52:47 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtEi_SdUGn62; Tue, 10 Jun 2014 12:52:38 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id A9A602CCF9; Tue, 10 Jun 2014 12:52:38 +0300 (EEST) Content-Type: multipart/signed; boundary="Apple-Mail=_F02F5B51-9B18-47DB-80D3-D3E23224ECE4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Jari Arkko In-Reply-To: <20140609201907.GS27145@mx1.yitter.info> Date: Tue, 10 Jun 2014 12:52:40 +0300 Message-Id: <3D43E112-7BC2-499D-B46D-92001CC61FE7@piuha.net> References: <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <20140609190830.GR27145@mx1.yitter.info> <53960817.3050308@dcrocker.net> <59C0992A-037D-40AC-BFD9-419A4B65D4A4@virtualized.org> <20140609201907.GS27145@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/BUlfHBpNLnhHvES2wFbhAOZzK74 Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 09:52:51 -0000 --Apple-Mail=_F02F5B51-9B18-47DB-80D3-D3E23224ECE4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > > My own view, which was completely in alignment with what the IAB > stated in its earlier comments, was that the Coordination Group should > have been a straight "rapporteur", as David suggested. Unfortunately, > that's not what we have. Instead, we have a group that can in effect > decide to do whatever it wants. > > The protection from that, however, remains our various communities' > vigilance. For that reason, I really strongly support the suggestion > that the overall effect needs to be open and transparent; but I'm not > actually convinced that extends to every hallway conversation and so > on. I don't care how a good idea comes up. What I care about is why > I should accept an idea and what objections there are to that idea. > So, the debate about a proposal has to happen in public, but in my > view that doesn't mean that every interaction needs to be regulated. > I don't care who came up with something. I'm interested in the very > strongest arguments for and against a plan. FWIW, I am in agreement with what Andrew says above. Jari --Apple-Mail=_F02F5B51-9B18-47DB-80D3-D3E23224ECE4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTltVoAAoJEM80gCTQU46qUs4QAJq/BCB8QjBFzGRsOa0TVhIY UOnxqtmNH10okoKxWtgaYSayX/A0AYxFYLHi0S/hZeWCIUaKD5BcHyzLiJy77Ytt ovOweW1+91/i2BIWN8+modtWeSSR9/Wkn1dyQ6mz819EC1/ledaBCaGeCTyzG83O QSMma+Njk19favWemh98JhL/7n9dn3vGhsoaamOrugJ1KjG2Eqh0LcwjGoL5rXEQ oXZuezvteNqObh9VjZi5OkopQNnLhip0GZeiBZYJ7swWOQhXLbrC1/Q3N5hUwQZ/ lgjIyW9JELbxAEg4aoOiAiQs/kgGvGrAYZeIhnHgf5OpyisqzVxk4cSd5mgLMzSG foJczsYNUqg7LwIImGtVLk9ShoMvJqQdZezFUixvOrE1w13oHhkYRxk7XJV7B3Hi JajJixvm8BurpulAhjUAXFscc5WUUctLfFFrJta9tkjc5uL1uwFywd4lGXeh3kQ+ aWS0gQ8wNwJA+s/lyQpBR9dpzbjMr8Sy5ju4NuNb8wq/NAIUDo4mpl0gKAn3kW2+ f/+S01weIvsLow9hUCiYuKe3yaqe0aHbdMvy78lKE+VYPniqsrxixJaxXPw+hWHq I06B150vuIhs+uo2oumyDxwQ0RheoRQLomErqPs/d7VNyHXoxn9LFMZFRcSp6oDh EHtkfcpAGryDeJ62rSwn =WuIu -----END PGP SIGNATURE----- --Apple-Mail=_F02F5B51-9B18-47DB-80D3-D3E23224ECE4-- From nobody Tue Jun 10 05:46:05 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61FF01A0095 for ; Tue, 10 Jun 2014 05:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.231 X-Spam-Level: ** X-Spam-Status: No, score=2.231 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_19=0.6, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFkmEThMf7Js for ; Tue, 10 Jun 2014 05:46:00 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87D6C1A00B2 for ; Tue, 10 Jun 2014 05:46:00 -0700 (PDT) Received: from 231.74.14.81.rev.sfr.net ([81.14.74.231]:57442 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1WuLR8-00072p-Ix; Tue, 10 Jun 2014 05:45:59 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 10 Jun 2014 14:45:55 +0200 To: Russ Housley From: Jefsey In-Reply-To: <73021DBA-F693-4E6E-8619-F4A2962D58F4@vigilsec.com> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <63E9BDF5-7DB0-4B72-BAF1-B1818E64DB2B@virtualized.org> <20140609175728.8A2C51A0299@ietfa.amsl.com> <73021DBA-F693-4E6E-8619-F4A2962D58F4@vigilsec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: jefsey+jefsey.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/sPT_orvuPg14zjamM-SBGLtqy8I Cc: internetgovtech@iab.org, The IESG Subject: Re: [Internetgovtech] Question. [was: Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions] X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 12:46:01 -0000 At 20:02 09/06/2014, Russ Housley wrote: >The NTIA has asked for a single proposal. I expect the IETF and the >IAB to have a very strong voice in the handling of the protocol >parameters in that proposal. Dar Russ, I am interested in my own interuse of my Internet. I am interested in the US use, as I am for any other stakeholder. My question is: will the IETF and IAB coordinate with other plan studies by people, users, nations, international organization, whatever else ... in order to most orderly address the consequences of a shift in the US 37 years supervision from Executive to Legislative branches (back to the FCC?). The problem is that until now IAB had coordinated the external liaisons for the IETF. Now, the I*leadeship has amalgamated in an OpenStand group which is still unformalized in term of interface, supposed to deal with, and obey global communities' economic interests. I understand that ICANN is the only RFC 6852 "global community" acknowledged by the NTIA. Google, Microsoft, Apple, Amazon, Facebook, Twitters, etc. are the leaders of other communities. Will the IAB and IETF deal with them to best accomodate their technical requirements and economic interests in the context of the the IANA transfer? The IANA's move certainly rises a lot of question at the IUser (inter-user) level and an opportunity to see its emergence as a global community that we could qualify as symetric InterUse internet global interest. I will document its fundamental architectontical, economical, political, technical requirements in the coming months based upon achitectural field experimentation at various local to global levels; now the technical and situational evolution helps considering some people centered (cf. WSIS/Sao Paulo) projects. My question actually replaces my appeal to ISOC IRT RFC 6852 - now ISOC appears superseded by the NTIA. It essentially remains the same: is there a cockpit? Can this cockpit still be an open minded and friendly one, so it would be advantageous to cooperate at a contingency plan, or are we definitly only by our own? If there is a cockpit, we certainly are interested in theorytically coordinating with it globally. If there is none, we will develop by practical propagation from propject to project (slower but possibly more robust). Anyway I plan to use I_D to permit couple a cooperation at any time. Best! jfc From nobody Tue Jun 10 06:01:43 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C671A00FE for ; Tue, 10 Jun 2014 06:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.255 X-Spam-Level: * X-Spam-Status: No, score=1.255 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REO84f1UjgmQ for ; Tue, 10 Jun 2014 06:01:41 -0700 (PDT) Received: from p130.piuha.net (unknown [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 86CB41A0043 for ; Tue, 10 Jun 2014 06:01:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D12AB2CD0E; Tue, 10 Jun 2014 16:01:40 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjX6oK0oYZ95; Tue, 10 Jun 2014 16:01:32 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 331662CC5D; Tue, 10 Jun 2014 16:01:32 +0300 (EEST) Content-Type: multipart/signed; boundary="Apple-Mail=_F14E1C9F-8B8B-4094-A8A5-A833CD66FAE2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Jari Arkko In-Reply-To: <0DFF94DE-7DD2-4813-8B47-781B2A3E8815@frobbit.se> Date: Tue, 10 Jun 2014 16:01:33 +0300 Message-Id: References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <1E8054717F7369872099FDD6@JcK-HP8200.jck.com> <53969A66.4080903@cisco.com> <0DFF94DE-7DD2-4813-8B47-781B2A3E8815@frobbit.se> To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/abzRN5eN4Z1ITRfASw4eBeUDEtQ Cc: internetgovtech@iab.org, The IESG Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 13:01:42 -0000 --Apple-Mail=_F14E1C9F-8B8B-4094-A8A5-A833CD66FAE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > I think you must to some degree in parallell do the following (in no = specific order): >=20 > - Appoint people, the timeline for appointment is very aggressive > - Stay by your view that the steering committee is only coordinating, = work is to be done elsewhere > - Ensure people being appointed understand IAB view on bing = coordinator and not more > - Continue to be "on your toes" regarding pointing out the group = should only be coordinating, that the over time shrinking time is not = not optimal (the contrary), and other things that might come up > - Regarding "elsewhere", create bonds horizontally between IAB and = other "affected groups", and do not rely on all communication going = through (coming from) ICANN, do ISOC have staff working on these things = in very close coordination with IETF? > - Be prepared to appoint people to elsewhere, where the work is done = -- I have no clear indication coordinated work happens outside of ICANN = at the moment, but who knows Agreed. Jari --Apple-Mail=_F14E1C9F-8B8B-4094-A8A5-A833CD66FAE2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTlwGuAAoJEM80gCTQU46qjpoP/2os5rDU/3yPn4KhwVKUO4eX f5AHr1Ie9TzRdULZEmynQlXSDEZee4QTLXWn4Biq8m51LjZvdMhsWWri6DgdgOc8 SsxaTFbLvw3GQtUybInk0CeuxTLkiq0eXqd+WIfEKCtSQS1zrc1oKZfpBgbPSh77 fEzJJPhdeVUEEpl7sOdGZ7FzYPX1mRcrJZ+nAjAeAU7pB0YktdSNLBfyHBLHnkpt CsYE/knxK8Q83SalR8MBpgX8NsOpXzCxZJIV14Hg2SFdN9JmKdSvH40VuWjqivVY ut7fl48grzHmQ3bJhdea+CVumUdFC2z9e29wSLRdgh8zOr4Up+TQZTthAxyUGB7I eHFlEADj2Mqt+guuTFTkA3ZV6ef+qgLikWhhHJrpyu+gxQlGv2mo0/rKcNYu3i0A 8j61ofGwjJ14ylA0NAJm5vQkNoMcMLeizg2a2pdbfBh/wh3KToP9xXJIZUVnWVea TVQq7hFVMQ9Zi+bnDcJS5VF+z1dcx671HSbFJKp5Yp3p5jGXlLLHg9oFylJoLdyI QltN/UMKRYLiuizZZ9YA7ROxEmEK/+mT6ec8onqWglouNQ3+0Ld3XuXy9AMR4RRQ wvLqAjKnBFI4vBZp0iycgvYVOv4sAS2PWXABGNuA0LVlm/T4JhPsqPG3lsajoTf4 s0IcHp6v69VwzCfqfN5k =Qx0R -----END PGP SIGNATURE----- --Apple-Mail=_F14E1C9F-8B8B-4094-A8A5-A833CD66FAE2-- From nobody Tue Jun 10 07:14:02 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A421A0177 for ; Tue, 10 Jun 2014 07:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uReAZ3ywa0Lk for ; Tue, 10 Jun 2014 07:13:56 -0700 (PDT) Received: from atl4mhob11.myregisteredsite.com (atl4mhob11.myregisteredsite.com [209.17.115.49]) by ietfa.amsl.com (Postfix) with ESMTP id 248FB1A0162 for ; Tue, 10 Jun 2014 07:13:55 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.203]) by atl4mhob11.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s5AEDral009911 for ; Tue, 10 Jun 2014 10:13:53 -0400 Received: (qmail 17050 invoked by uid 0); 10 Jun 2014 14:13:53 -0000 X-TCPREMOTEIP: 212.185.96.28 X-Authenticated-UID: avri@ella.com Received: from unknown (HELO ?127.0.0.1?) (avri@ella.com@212.185.96.28) by 0 with ESMTPA; 10 Jun 2014 14:13:52 -0000 Message-ID: <53971298.7000603@acm.org> Date: Tue, 10 Jun 2014 16:13:44 +0200 From: Avri Doria User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: internetgovtech@iab.org References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> In-Reply-To: <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 140609-1, 06/09/2014), Outbound message X-Antivirus-Status: Not-Tested Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/IkgdJxwR0JoIu5sR1m2wuuopmMw Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 14:13:58 -0000 Hi, Picking some bones inline. On 09-Jun-14 16:39, John C Klensin wrote: >> This part here made me think, can this issue about cost be the >> first step on the way to a multi-stakeholder for Internet >> where only the rich can participate? Rich as in having money >> AND time to travel to endless meetings around the world? ... I >> hope not. It is a challenge but lots of us do it without money of our own or working for rich organizations. > > I would have said "only the rich and those associated with > institutions or employers with significant resources to dedicate > to these processes and economic incentives to do so", but I > don't think that makes a difference in practice. > I agree it doesn't make a difference in practice. Just willingness to put in lots of time. > I think it is, or should be, a major issue. But, whatever it > is, it certainly is not the "first step". Consider the > following, remembering that some, but certainly not all, of > these are side-effects of decisions taken with the best of > intentions and that some may be appropriate on balance. > > (1) ICANN has developed a pattern in which effective > participation requires hugs blocks of time, active involvement > in multiple committees (most of which produce very long reports > that take time to study and that spawn more committees that, in > turn, require active effort). Attendance at meetings is > effectively mandatory if one wants to be effective. In the > interests of involving more diverse populations, many or most of > those meetings are held in places that are either expensive for > most of the world to reach or to participate in (even though > ICANN stresses that attendance at their meetings is "free" > because they don't charge a registration fee. Few of the local > attendees at those meetings participate effectively long-term > unless ICANN subsidizes their participation and the categories > of people who get subsidized do not include individual technical > experts. The net effect is that it is almost impossible for an > individual technical expert, no affiliated with and representing > some constituency group, to participate effectively unless > either he or she is subsidized by ICANN (not exactly a set of > choices that are unbiased by ICANN staff opinions about opinions > they want to hear) or can contribute significant individual > resources to the work (in your words, "only the rich"). Certainly ICANN requires time. Way too much time at times. "Huge blocks of time" is not an overstatement. But one can participate effectively without attending all meetings. Most work is done on conference calls. Weekly conference calls, long conference calls, mind numbing conferences. But there are 800 lines that are paid for, and if you live where there is no 800 access, they call you. VoIP, or skype as the case may be, works too. No cost to talk incessantly. Most anyone (s)elected to one of the many special Committees/Teams/WGs, Supporting Organization Council, Advisory Committees, Constituecies and leadership of Regional At-Large organizations (RALOs) (except maybe GAC) get support to attend the meetings. I am not rich by any western standard (me and my first world problems!) but have been able to attend all of the meetings for my nearly 10 years of ICANN participation by getting elected or appointed to committees where i worked my tail off. I am also not a favorite of ICANN upper management having often criticized senior management in a very pointed and public manner. Yet they do not exclude. Personally I think that ICANN should support the participation of those (s)elected by their constituencies to participate in the coordinating body, that is what it means to facilitate the process in my mind, and they are richer than the gods. They may already be planning to do so. ICANN does provide for some remote participation facilities at meetings and it is possible to attend that way, lots of people do. It is not as effective as being on site, but it works - getting better all the time. But someone would still have to attend face to face sometimes. In short ICANN is easier for a pauper to participate in than any other organization I have ever seen. They even give people per diem. And if you are lucky enough to get elected to the board they pay you and treat you like royalty. > > (2) Several normally-sane people have suggested that at least > some of the RIRs are dominated by a combination of large > incumbent ISPs and entrenched groups of insiders, identifying > the latter with apparent "board member for life" positions. I > haven't been involved enough with the address process in the > last dozen or more years to have an opinion about those claims, > but the optics are poor. Incumbents are always blamed for nefariousness. Sometimes it is true, but my experience with RIR folk (in ICANN, the IGF and many other Internet governance institutions) shows that while they may tend to group think, mostly they pull their own strings. And yeah some people do seem to have permanent seats on things. > > (3) Returning to ICANN, much of the representation and leverage > for individual technical participants is supposed to come > through the Nomcom process, but that process has been fairly > consistently operated (and starved for resources) that have the > presumably-accidental side effect of biasing both applications > and selections in favor of those who are well-connected and able > to invest considerable personal (or corporate) resources in > ICANN participation. > Ah Nomcom, won't argue with you there. But the volunteers do try. Again, I think the problem is mostly the hive mind syndrome. They are good and dedicated people, for the most part, who try to pick the best, from their narrow points of view. Then again I would say that, they picked the likes of me 3 times for the GNSO (Generic Name Supporting Organization) but turned me down 3 times for the Board. What does that tell you other than the likes of me can't break the glass ceiling of the board but are welcome to do work. > (4) Even the IETF is not immune from the problem: Increasing > reliance on meetings, requirements (some formal) for meeting > attendance for effective participation, and rising total costs > of meeting attendance (some of them driven by a desire to show > the IETF flag in more places in the world), all contribute to an > environment in which predominantly the "rich" (or > organizationally-well-supported) can play, especially in > "leadership" roles. I cannot afford to attend IETF meeting unless i beg for support from someone with the right riches. Participation in the IETF is certainly limited by money and organization as you suggest. True most of the decision are made on the lists, but I do not believe one can participate in the organization effectively without attending meetings. A technical project or two, maybe, but not the organization. And even in technical groups, much of the nitty gritty consensus work is done at the meetings. And remote participation at IETF is even worse than at ICANN. > > There are other examples, but I don't think a long catalogue > would help illustrate the problem. I wish I knew what to do > about it, but we are long past "first step"... and past any > plausible claim that what we call a multistakeholder model is > really representative of either the broad Internet community or > even a broad spectrum of qualified expert opinions. I think the first step is pick the right people to repesent the IETF and IAB. The second step is get ICANN to pay for their participation. And if that doesn't work, start fundraising. cheers, avri From nobody Tue Jun 10 08:00:36 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBEF51B27C6 for ; Tue, 10 Jun 2014 08:00:27 -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=-1.9, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOTrAJi2bQeR for ; Tue, 10 Jun 2014 08:00:21 -0700 (PDT) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAA091B27E6 for ; Tue, 10 Jun 2014 08:00:21 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id jt11so6315404pbb.36 for ; Tue, 10 Jun 2014 08:00:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=g4bYT6hW5KWSO72nSpszeTpY30u4I/doFvdSAmFyFK0=; b=JWk2vRmlyz6M9yx6zIauzhx/S+bEisW3jjoJnOTOTNB6AtK1GDFJtGTKPNSEChT5A4 ALCKYJt9l+EMyrwnfexfm28aBYjEPG8RI9u4dI6QceBFQs472uW6K363/HTGfqYSxCJM EZ0zT8A+sGb/yRyYE9vqa5X9D4yfl7Bmfo7uMK3YnoNAcBuNXPVINFBOUU1Z6qsFPqff 04A7M7869RgKrGJLMG1fMztBCetJqIsiCSDm/HANZ6yLTMQAikO7aZcQqJ9iZip+8xmF wZZegODkEMpQUnN9Xaqi4ZCJFdsF9ZjA2CgvMVwGp/4QG46Q1KnvKBBnc7Qor5MEOTmk qkrQ== X-Gm-Message-State: ALoCoQmYSaBg6RKWfedm2yMtV4PnOkvC8cnaIL3vJdK3pWEiDLvpgdO/Qg73EKkAjoqHnpUCpLsd X-Received: by 10.66.227.4 with SMTP id rw4mr5466933pac.18.1402412421219; Tue, 10 Jun 2014 08:00:21 -0700 (PDT) Received: from [10.0.1.3] (c-24-6-168-86.hsd1.ca.comcast.net. [24.6.168.86]) by mx.google.com with ESMTPSA id ln2sm14291698pab.35.2014.06.10.08.00.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Jun 2014 08:00:20 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_B79E69AA-F34A-475B-B992-1EF3599E4806"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: David Conrad In-Reply-To: <6D77774657909C285BA0E53B@JcK-HP8200.jck.com> Date: Tue, 10 Jun 2014 08:00:16 -0700 Message-Id: References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <152FE254-0212-40E6-B8E1-410F8BB87E81@virtualized.org> <6D77774657909C285BA0E53B@JcK-HP8200.jck.com> To: John C Klensin X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/pcTWNt7ogjROfFHnINSA5nePCoY Cc: internetgovtech@iab.org, The IESG Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 15:00:28 -0000 --Apple-Mail=_B79E69AA-F34A-475B-B992-1EF3599E4806 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii John, On Jun 10, 2014, at 12:25 AM, John C Klensin wrote: > First, the selection and appointment process for > individuals participating in those committee is not exactly open > and transparent. =20 There is a bit of documentation on selection/appointment for committees, = e.g.: SSAC: see section 2 of = https://www.icann.org/en/system/files/files/operational-procedures-18jan13= -en.pdf RSSAC: Executive Committee: run a root server, Caucus: see = https://www.icann.org/resources/pages/rssac-caucus-2014-05-06-en and = https://www.icann.org/en/groups/rssac/rssac-caucus-06may14-en.pdf. With that said, I would agree that both committees do lack in the = openness/transparency department (the reasons for this aren't = particularly relevant). =20 Out of curiosity, what's the process for an individual joining an IETF = Directorate? > In at least one or two cases I'm > aware of, there were clear selection criteria that were not > adhered to in the selections made by staff. [...] Given your well known reticent nature, I guess it's not surprising you = didn't take your concerns public if you believe staff have performed = inappropriately :). More seriously, I get that you don't like/trust ICANN staff however it = is difficult for me to comment on vague accusations and innuendo without = either evidence or understanding the other side of the story. As such, = I won't. Moreover, it's largely irrelevant. The question here isn't whether or = not ICANN (for some value of that variable) will try to influence = outcomes: of course they will, just as the commercial entities that fund = their representatives will, governmental folks, ISOC, etc. The question = is whether or not the representatives will live up to the trust their = respective communities have placed on them, regardless of how they are = funded. Trotting out "but ICANN staff are evil and will use purse = strings to make people do bad things" is asserting that the individuals = the IETF chooses can't be trusted. That's a leap I'm not going to make.=20= >> ICANN's Nomcom's budget for FY13 is $834,000. What sort of >> resources do you believe ICANN's Nomcom is being starved? > I'm the proud recipient of a note from the current Nomcom Chair > that effectively says "that was mismanaged because we didn't > have sufficient resources and couldn't get them". To be honest, to me, given 3/4 of a million dollars to identify a = handful of candidates, this suggests a problem unrelated to resources. = How much does the IETF pay for their Nomcom? Regards, -drc --Apple-Mail=_B79E69AA-F34A-475B-B992-1EF3599E4806 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJTlx2BAAoJENV6ebf0/4rXjuoH/iO96h7Yk5RP2LIXMaaJHpDf ybK06jXo9biKhrmlbtjIdAeSyyjX8i19WndD0IPcXRJuWFZeNwqGHqkiDv/+4vyM 1YrMegkRQp9FC0lQyNHd8wFd5dqL0foY21/M+58I3ZI7XSaPvuyPm1gVM8sqh0rg 4/fWPEGeAJwjUYj1l95WLx1180R92q0UO+J739HQLZlog6txc/r3Yv3fSheVf3t2 XV2C6lEFtwIuGSYUVpxqzuoMJyzWbblHkGXx7yyizXs+sf4HjKB6kcmWN0aY08Nc A/qVhIDqeJir4jvEJYW37RXsA56+sQb4FKtJwNaygSZkb06WevMq34eBAcfwGvQ= =n0p2 -----END PGP SIGNATURE----- --Apple-Mail=_B79E69AA-F34A-475B-B992-1EF3599E4806-- From nobody Tue Jun 10 09:48:44 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F04D51A01FB for ; Tue, 10 Jun 2014 09:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8YwgJJRKEc1 for ; Tue, 10 Jun 2014 09:48:40 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB65F1A019B for ; Tue, 10 Jun 2014 09:48:40 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.235.111]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s5AGmKav019519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2014 09:48:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1402418917; x=1402505317; bh=CJL7vZuxQ2j5XOSUh2PnTReJZcXxrM1MYVFZNhvagSI=; h=Date:To:From:Subject:In-Reply-To:References; b=ZnekE426CxDN54ckw+b07jxPxgjmrsKJIgFuUbCe+xSwHPMFT6ihr5RnPUGR9r2gU TLNjUlXFFgCLP/JZo1K7wC14DD2XircY47UP5+5xeNEOPfOLM4rLTEaXko/ioOOMli XSXKslkjl0Oz3wtHhqjA/6EpnyNIzZRZOq1MkYt4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1402418917; x=1402505317; i=@elandsys.com; bh=CJL7vZuxQ2j5XOSUh2PnTReJZcXxrM1MYVFZNhvagSI=; h=Date:To:From:Subject:In-Reply-To:References; b=SOi6ePWzdpunNWs4azkUrBvLkr+tG4As8LOf7FXTAzbsS7jwq/OoEjv698ogQYYnv nOg1cmV1GuWXWEbcpjU1UligwnTcbpdZsIIJKWFDJgyUuNawN+XrCoYp5OzT+Y9v3/ n9IgUjfb4ZWvXucJs2YHw1Vu3YuLSGIVYHk+Q0pQ= Message-Id: <6.2.5.6.2.20140610075434.0ba98160@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 10 Jun 2014 08:30:56 -0700 To: Avri Doria , internetgovtech@iab.org From: S Moonesamy In-Reply-To: <53971298.7000603@acm.org> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <53971298.7000603@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/GKM4PwM_kDvY206bM5HJCPI0ub8 Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 16:48:42 -0000 Hi Avri, At 07:13 10-06-2014, Avri Doria wrote: >Certainly ICANN requires time. Way too much time at times. "Huge blocks >of time" is not an overstatement. Yes. >But one can participate effectively without attending all meetings. >Most work is done on conference calls. Weekly conference calls, long >conference calls, mind numbing conferences. But there are 800 lines that >are paid for, and if you live where there is no 800 access, they call >you. VoIP, or skype as the case may be, works too. No cost to talk >incessantly. I have been on some of the conference calls. It would have been more productive to have most of these discussions on a mailing list [1] as: (i) It means committing less time for participation. (ii) It is better to talk about issues which cannot be resolved by other (communication) means. >I am not rich by any western standard (me and my first world problems!) >but have been able to attend all of the meetings for my nearly 10 years >of ICANN participation by getting elected or appointed to committees >where i worked my tail off. I am also not a favorite of ICANN upper >management having often criticized senior management in a very pointed >and public manner. Yet they do not exclude. Ok. >I cannot afford to attend IETF meeting unless i beg for support from >someone with the right riches. Participation in the IETF is certainly >limited by money and organization as you suggest. True most of the >decision are made on the lists, but I do not believe one can participate >in the organization effectively without attending meetings. A technical >project or two, maybe, but not the organization. >And even in technical groups, much of the nitty gritty consensus work is >done at the meetings. And remote participation at IETF is even worse >than at ICANN. The way for me to justify support to attend an IETF meeting is to do a presentation. This means asking a WG Chair to approve a time slot which I would decline if I was in his or her shoes. The argument that it is not possible to participate effectively in the IETF without attending meetings is because only a few people try hard to get the work done through the mailing lists. I agree that remote participation in the IETF is even worse than at ICANN. Regards, S. Moonesamy 1. This does not mean unmanaged discussions From nobody Tue Jun 10 12:20:39 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1CD31A0081 for ; Tue, 10 Jun 2014 12:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQkCFX89b3Rj for ; Tue, 10 Jun 2014 12:20:15 -0700 (PDT) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAC7A1A0279 for ; Tue, 10 Jun 2014 12:20:14 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id j7so9652732qaq.17 for ; Tue, 10 Jun 2014 12:20:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=dI7Hy3jInrZKV5BbodgGj2mq/R3HUQRKLTmfCL/5TCk=; b=B3fQdRLUAX74EpNppuP2tiaSPeEbLXp/2F6TzywV64mFW++sfEt1vz8/qYKX1nPlJD 1mOy/Xjs9LAQrB2uPESZ1ebV7TH/A/31GqBDb8SHdZ6naYZiIwrgK7p/ent3rU1W126o LHTuqeG7th9bc7G/FyfncwG0p97OTWozfJ8ltX51Y9pOANJy6OAot9slvegotubq+pE4 4YGFot4uGLYlAS10ThG713ivqnQgccBZdJ9ooEroyn+Izh2Fb1swyhaMFO+Oh9Of/DXD oX8phUWcPrrC+4gdi9Zpa81v9aCWvyy3Ly8sb6dRQz0B8KgU8TlntR9mLE5OP9/ccoHT hBuA== X-Received: by 10.229.97.71 with SMTP id k7mr44924453qcn.4.1402428013910; Tue, 10 Jun 2014 12:20:13 -0700 (PDT) Received: from [10.0.0.5] (c-24-63-89-87.hsd1.ma.comcast.net. [24.63.89.87]) by mx.google.com with ESMTPSA id g8sm37115050qam.38.2014.06.10.12.20.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Jun 2014 12:20:12 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_D4DB46A3-C336-4A77-BD3F-B48C22522860" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Suzanne Woolf In-Reply-To: <0DFF94DE-7DD2-4813-8B47-781B2A3E8815@frobbit.se> Date: Tue, 10 Jun 2014 15:20:11 -0400 Message-Id: <05F25AA9-5A80-4889-BDEA-15C669A8A6FF@gmail.com> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <1E8054717F7369872099FDD6@JcK-HP8200.jck.com> <53969A66.4080903@cisco.com> <0DFF94DE-7DD2-4813-8B47-781B2A3E8815@frobbit.se> To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/lE-164jGK7aOM4fKXUeX6iZ84yU Cc: Eliot Lear , Andrew Sullivan , internetgovtech@iab.org, Ted Lemon , John Klensin , Barry Leiba , The IESG Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 19:20:16 -0000 --Apple-Mail=_D4DB46A3-C336-4A77-BD3F-B48C22522860 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, A few observations=85. (No hats. If I volunteer for this activity, which seems unlikely, it = will probably be in another capacity.) On Jun 10, 2014, at 1:50 AM, Patrik F=E4ltstr=F6m = wrote: > Let me add a few suggestions that unfortunately do not make things = easier. >=20 > I think you must to some degree in parallell do the following (in no = specific order): >=20 > - Appoint people, the timeline for appointment is very aggressive > - Stay by your view that the steering committee is only coordinating, = work is to be done elsewhere > - Ensure people being appointed understand IAB view on bing = coordinator and not more > - Continue to be "on your toes" regarding pointing out the group = should only be coordinating, that the over time shrinking time is not = not optimal (the contrary), and other things that might come up These points are all about vigilance and care for participants in the = process, and the level of vigilance it will take to support sound = process here (per not only Patrik's remarks, but John's, Andrew's, = Eliot's, etc.) is not trivial. A couple of observations about that seem = worth reinforcing. First-- I think that non-participation in this effort is not really an = option for the IETF and the IAB, no matter how we feel about ICANN's = ability to facilitate distributed work, etc. As a practical reality, the = IETF is in some ways the most prominent "customer" of IANA, and the = possibility of the end of the IANA functions contract is the biggest = thing to happen in this space since ICANN was founded. Staying on the = sidelines doesn't even preserve the ability to dissent later (to the = contrary in fact). The kind of political challenge involved happens all = the time, certainly in any process that's even within shouting distance = of anything labeled "internet governance". There's nothing new in = participating in a process, working earnestly towards a successful = outcome, and still considering the contingency that it might fail. = However, taking on all of the perceived ills of ICANN and its = administration in this process is also not an option.=20 There's a specific task at hand. It can't really be done without the = participation of the IETF, and it's in the best interests of the IETF = that it be done and that it include the IETF's interests as input. Leadership is going to be important in keeping the group focused and = moving forward (not just moving)-- doing all it has to do and no more. = It does seem to me that participants appointed by the IETF and the IAB = are likely to be among the most realistic about what a post-NTIA IANA = should look like and the most experienced in forging the kind of = consensus that will be needed. The IETF has already started that process = internally (draft-iab-iana-framework) and the revised proposal from = ICANN for the membership and charter of the Coordination Group = incorporates multiple suggestions from the IAB's and ISOC's comments on = an earlier draft. There's a lot of room for IETF and IAB participants to = influence both process and outcomes. Presumably IETF and IAB appointees to the coordination group will have = backup from other knowledgeable colleagues. They're going to need it. > - Regarding "elsewhere", create bonds horizontally between IAB and = other "affected groups", and do not rely on all communication going = through (coming from) ICANN, do ISOC have staff working on these things = in very close coordination with IETF? > - Be prepared to appoint people to elsewhere, where the work is done = -- I have no clear indication coordinated work happens outside of ICANN = at the moment, but who knows Discussion of the process, conflicts of interest, standards for = transparency and so on are incredibly important to support defensible, = high-quality outcomes, but let's not lose sight of the need for = outcomes: the deliverable for this group is a proposal, to be given to = the US Department of Commerce, for proper stewardship of "the IANA = functions" in the event that the US government allows its current = contract with ICANN for those functions to end without renewal in late = 2015.=20 Patrik is right that the specifics are not the remit of the coordination = group. The "real work" is to be done by the stakeholder groups. For the = IETF and IAB, this seems relatively straightforward, because there's a = high degree of clarity about what is involved in doing the protocol = parameters work and in proper oversight of it. However, the group is = also responsible for coordinating multiple components of an overall = proposal, which would entail identifying any gaps and making sure any = overlaps are resolved in synthesizing a full proposal that complies with = the NTIA guidelines. Controversy is inevitable, for reasons that have little to do with the = IETF and IAB. Per RFC 2860, the IETF is not particularly interested in = policy control over domain names, but that's what most of the people who = care about IANA and the NTIA contract are concerned about. Most of that = conversation belongs in other venues ("ICANN Accountability," ICANN's = SOs and ACs, etc.) but keeping it corralled is consistently a challenge. One way to consider the task at hand: the role of the IETF and the IAB = here, along with the TLD operators, root server operators, and the RIRs, = is to make sure that the practical realities of what IANA does and what = changes a transition plan has to cover are not lost among the policy = activities and implications. Not that the policy aspects should (or even = can) be locked out of the room, but neither should (or can) the = "technical details" for those who will be directly affected if the = contemplated changes don't properly assure the reliable execution of the = work of IANA. The IETF and the IAB need to speak clearly and openly for their = requirements and priorities, and insist that a proposal for the = operation of the IANA functions post-NTIA take those fully into account. = It's just that simple. One place to do that is in the IANA framework = discussion within the IETF. Another is in the IANA stewardship = transition proposal process. I respectfully suggest we focus here on what steps the IETF and the IAB = can take not only to appoint qualified people to the coordination group, = but to support their efforts and the IETF's internal process for = providing its input to the proposal. best, Suzanne= --Apple-Mail=_D4DB46A3-C336-4A77-BD3F-B48C22522860 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 paf@frobbit.se>= wrote:
Let me add a few suggestions that unfortunately do not = make things easier.

I think you must to some degree in parallell = do the following (in no specific order):

- Appoint people, the = timeline for appointment is very aggressive
- Stay by your view that = the steering committee is only coordinating, work is to be done = elsewhere
- Ensure people being appointed understand IAB view on bing = coordinator and not more
- Continue to be "on your toes" regarding = pointing out the group should only be coordinating, that the over time = shrinking time is not not optimal (the contrary), and other things that = might come up

These points are all = about vigilance and care for participants in the process, and the level = of vigilance it will take to support sound process here (per not only = Patrik's remarks, but John's, Andrew's, Eliot's, etc.) is not trivial. A = couple of observations about that seem worth = reinforcing.

First-- I think that = non-participation in this effort is not really an option for the IETF = and the IAB, no matter how we feel about ICANN's ability to facilitate = distributed work, etc. As a practical reality, the IETF is in some ways = the most prominent "customer" of IANA, and the possibility of the end of = the IANA functions contract is the biggest thing to happen in this space = since ICANN was founded. Staying on the sidelines doesn't even preserve = the ability to dissent later (to the contrary in fact). The kind of = political challenge involved happens all the time, certainly in any = process that's even within shouting distance of anything labeled = "internet governance". There's nothing new in participating in a = process, working earnestly towards a successful outcome, and still = considering the contingency that it might fail. However, taking on all = of the perceived ills of ICANN and its administration in this process is = also not an option. 

There's a specific = task at hand. It can't really be done without the participation of the = IETF, and it's in the best interests of the IETF that it be done and = that it include the IETF's interests as = input.

Leadership is going to be important in = keeping the group focused and moving forward (not just moving)-- doing = all it has to do and no more.  It does seem to me that participants = appointed by the IETF and the IAB are likely to be among the most = realistic about what a post-NTIA IANA should look like and the most = experienced in forging the kind of consensus that will be needed. The = IETF has already started that process internally = (draft-iab-iana-framework) and the revised proposal from ICANN for the = membership and charter of the Coordination Group incorporates multiple = suggestions from the IAB's and ISOC's comments on an earlier draft. = There's a lot of room for IETF and IAB participants to influence both = process and outcomes.

Presumably IETF and IAB = appointees to the coordination group will have backup from other = knowledgeable colleagues. They're going to need = it.

- Regarding = "elsewhere", create bonds horizontally between IAB and other "affected = groups", and do not rely on all communication going through (coming = from) ICANN, do ISOC have staff working on these things in very close = coordination with IETF?
- Be prepared to appoint people to elsewhere, = where the work is done -- I have no clear indication coordinated work = happens outside of ICANN at the moment, but who = knows

Discussion of the process, = conflicts of interest, standards for transparency and so on are = incredibly important to support defensible, high-quality outcomes, but = let's not lose sight of the need for outcomes: the deliverable for this = group is a proposal, to be given to the US Department of Commerce, for = proper stewardship of "the IANA functions" in the event that the US = government allows its current contract with ICANN for those functions to = end without renewal in late 2015. 

Patrik = is right that the specifics are not the remit of the coordination group. = The "real work" is to be done by the stakeholder groups. For the IETF = and IAB, this seems relatively straightforward, because there's a high = degree of clarity about what is involved in doing the protocol = parameters work and in proper oversight of it. However, the group is = also responsible for coordinating multiple components of an overall = proposal, which would entail identifying any gaps and making sure any = overlaps are resolved in synthesizing a full proposal that complies with = the NTIA guidelines.

Controversy is = inevitable, for reasons that have little to do with the IETF and IAB. = Per RFC 2860, the IETF is not particularly interested in policy control = over domain names, but that's what most of the people who care about = IANA and the NTIA contract are concerned about. Most of that = conversation belongs in other venues ("ICANN Accountability," ICANN's = SOs and ACs, etc.) but keeping it corralled is consistently a = challenge.

One way to consider the task at = hand: the role of the IETF and the IAB here, along with the TLD = operators, root server operators, and the RIRs, is to make sure that the = practical realities of what IANA does and what changes a transition plan = has to cover are not lost among the policy activities and implications. = Not that the policy aspects should (or even can) be locked out of the = room, but neither should (or can) the "technical details" for those who = will be directly affected if the contemplated changes don't properly = assure the reliable execution of the work of = IANA.

The IETF and the IAB need to speak = clearly and openly for their requirements and priorities, and insist = that a proposal for the operation of the IANA functions post-NTIA take = those fully into account. It's just that simple. One place to do that is = in the IANA framework discussion within the IETF. Another is in the IANA = stewardship transition proposal process.

I = respectfully suggest we focus here on what steps the IETF and the IAB = can take not only to appoint qualified people to the coordination group, = but to support their efforts and the IETF's internal process for = providing its input to the = proposal.


best,
Suzanne<= /div>
= --Apple-Mail=_D4DB46A3-C336-4A77-BD3F-B48C22522860-- From nobody Tue Jun 10 13:34:06 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505F21A02D0 for ; Tue, 10 Jun 2014 13:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id janzAxbXUj33 for ; Tue, 10 Jun 2014 13:33:40 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9E851A02D3 for ; Tue, 10 Jun 2014 13:33:40 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id rd3so1079107pab.30 for ; Tue, 10 Jun 2014 13:33:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=nA38t5b3pgeuP2kr8CGUA9FadpWS5SrKqOAUm4kOTqM=; b=oe+UC7T9tYqqJ2PnU7MoI2PTNCk7ZNZWc6VbnWhUFjTlpehS0TbNxIarSr+DvMbFq7 wg2/pjgo+9Bojs8fpbdSyKVIx90Xq6cnUFPhJLrv8bvPQByGzEmeHXwLrNYeyIWIgttY RYpc4cpAXx7UELgspSCvtV6ghaT9+MlSdXMg6qWx3RPKJT8qVIBMRfUV04yfStbNTZSk fhBVx6U22azpq+CBu4nYRDOFLW+T5rB/EAUen4VsuJmwN2Qg43e1vStWHqiQPRwT3v19 ivxWjplTgGuU5ji5uyA+8ZkT5nxBUfJ2NGHKc+R/j2CHnWNYlssMAkQCM4Y7gMk8khIo ggMA== X-Received: by 10.68.163.197 with SMTP id yk5mr14251800pbb.57.1402432419487; Tue, 10 Jun 2014 13:33:39 -0700 (PDT) Received: from [192.168.178.23] (163.193.69.111.dynamic.snap.net.nz. [111.69.193.163]) by mx.google.com with ESMTPSA id ei4sm71070836pbb.42.2014.06.10.13.33.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Jun 2014 13:33:38 -0700 (PDT) Message-ID: <53976BA5.1040002@gmail.com> Date: Wed, 11 Jun 2014 08:33:41 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: David Conrad References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <152FE254-0212-40E6-B8E1-410F8BB87E81@virtualized.org> <6D77774657909C285BA0E53B@JcK-HP8200.jck.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/cEXZw0UaVLX4bW0MKcaFQVEQYK0 Cc: John C Klensin , internetgovtech@iab.org, The IESG Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 20:33:41 -0000 On 11/06/2014 03:00, David Conrad wrote: ... > Out of curiosity, what's the process for an individual joining an IETF Directorate? iirc, invitation by the responsible AD(s). But also, of course, IETF Directorates are strictly advisory and the responsibility stays firmly with the AD(s). And there's no travel budget. Brian From nobody Tue Jun 10 13:52:49 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA791A02D8 for ; Tue, 10 Jun 2014 13:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.565 X-Spam-Level: X-Spam-Status: No, score=-1.565 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtqZqoFxmfsC for ; Tue, 10 Jun 2014 13:52:35 -0700 (PDT) Received: from nike.wampumpeag.net (nike.wampumpeag.net [67.42.198.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BF301A02D3 for ; Tue, 10 Jun 2014 13:52:35 -0700 (PDT) Received: from frog.local ([67.42.198.93]) by nike.wampumpeag.net (8.14.9/8.14.9) with ESMTP id s5AKpp8r001575 for ; Tue, 10 Jun 2014 13:52:10 -0700 (PDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <53976FDB.7060307@abenaki.wabanaki.net> Date: Tue, 10 Jun 2014 13:51:39 -0700 From: Eric Brunner-Williams User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: internetgovtech@iab.org References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060604040905010601000801" Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/ZhqFubMllfpcOYmp-s7GV_40B5M Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 20:52:37 -0000 This is a multi-part message in MIME format. --------------060604040905010601000801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 6/9/14 6:37 PM, David Conrad wrote: > In any event, it is an opportunity to actively contribute towards an effort that will resolve a "difference of opinion" between what some people within the IETF (and others) think and what some people associated with governments all over the world (and others) think about answer to the question "From where does the authority behind the IANA functions come?". Having personally been at the sharp end of that particular question in the past, I believe it will be a quite good if there is resolution. In 2000 Michael Froomkin wrote "WRONG TURN IN CYBERSPACE: USING ICANN TO ROUTE AROUND THE APA AND THE CONSTITUTION" which appeared in the Duke Law Journal. This was followed in 2002 by an exchange of articles Joe Sims and Cynthia Bauerly writing in support of the claim that ICANN is not an agency of government, refuting Michael Froomkin's article, and replies by Michael, in a special issue of the Lewis and Clark Law Review -- Volume 6, Number 1. Just over a decade has past and no court has ruled on the question -- Is ICANN exercising delegated rule making authority, or does its authority arise from some other source? Hence "From where does the authority behind the IANA functions come?" I suggest that among the limited set of persons to be offered to "ensur[e] that the proposal meets the criteria NTIA previously outlined" is at least one who does not overlook the necessity, and utility, of answering a fundamental question. It is unlikely that any other designated sources of {steering|coordinating|...} group members will select, let alone solicit offers to contribute, to anyone who entertains David's question as a serious, unanswered question, and getting a useful answer to what appears to be a simple question of responsibilities for protocol parameters while leaving the question of the source of authority unanswered risks having an answer that does not age well. So I suggest Michael Froomkin be considered. In the spirit of full disclosure, Michael Froomkin was a member of ICANN's NomCom in 2004/2005, and he solicited my application to an ICANN NomCom appointed seat. Eric --------------060604040905010601000801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 6/9/14 6:37 PM, David Conrad wrote:
In any event, it is an opportunity to actively contribute towards an effort that will resolve a "difference of opinion" between what some people within the IETF (and others) think and what some people associated with governments all over the world (and others) think about answer to the question "From where does the authority behind the IANA functions come?".  Having personally been at the sharp end of that particular question in the past, I believe it will be a quite good if there is resolution.

In 2000 Michael Froomkin wrote "WRONG TURN IN CYBERSPACE: USING ICANN TO ROUTE AROUND THE APA AND THE CONSTITUTION" which appeared in the Duke Law Journal. This was followed in 2002 by an exchange of articles Joe Sims and Cynthia Bauerly writing in support of the claim that ICANN is not an agency of government, refuting Michael Froomkin's article, and replies by Michael, in a special issue of the Lewis and Clark Law Review -- Volume 6, Number 1.

Just over a decade has past and no court has ruled on the question -- Is ICANN exercising delegated rule making authority, or does its authority arise from some other source? Hence "From where does the authority behind the IANA functions come?"

I suggest that among the limited set of persons to be offered to "ensur[e] that the proposal meets the criteria NTIA previously outlined" is at least one who does not overlook the necessity, and utility, of answering a fundamental question.

It is unlikely that any other designated sources of {steering|coordinating|...} group members will select, let alone solicit offers to contribute, to anyone who entertains David's question as a serious, unanswered question, and getting a useful answer to what appears to be a simple question of responsibilities for protocol parameters while leaving the question of the source of authority unanswered risks having an answer that does not age well.

So I suggest Michael Froomkin be considered.

In the spirit of full disclosure, Michael Froomkin was a member of ICANN's NomCom in 2004/2005, and he solicited my application to an ICANN NomCom appointed seat.

Eric
--------------060604040905010601000801-- From nobody Tue Jun 10 17:41:12 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 067D01A0261 for ; Tue, 10 Jun 2014 17:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmR3pjv8sOGH for ; Tue, 10 Jun 2014 17:41:08 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4DBD1A021B for ; Tue, 10 Jun 2014 17:41:08 -0700 (PDT) Received: from pool-108-56-179-253.washdc.fios.verizon.net ([108.56.179.253] helo=[192.168.1.10]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1WuWbD-000Hkb-UM; Wed, 11 Jun 2014 00:41:08 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 108.56.179.253 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18qnPfBjv2nVMiivNRxlDCG Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: John Curran In-Reply-To: <53971298.7000603@acm.org> Date: Tue, 10 Jun 2014 20:41:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <53971298.7000603@acm.org> To: Avri Doria X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/TKqvQDL7IgSUOS7vFv-hibS9kPA Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 00:41:11 -0000 On Jun 10, 2014, at 10:13 AM, Avri Doria wrote: > ... > The second step is get ICANN to pay for their participation. The next steps document appears to be updated with relevant information =20= = - " ... Travel Support Coordination Group members will not be remunerated. However, travel, = meal and lodging costs for Coordination Group members to participate in = Coordination Group meetings will be covered by ICANN, upon request and = in accordance with ICANN's community travel support guidelines. Supported travelers must book their air travel with ICANN's authorized = travel agent, where the cost will be billed directly to ICANN. Hotel = rooms and tax for a specified meeting will be arranged and paid for = directly by ICANN in accordance with the authorized arrival and = departure dates for each supported traveler. ICANN will only book and = pay for a non-refundable, lowest logical price airfare, and economy = airfare. Reimbursement will be permitted for meeting attendance and = other reasonable incidental expenses incurred. For questions, or to make the necessary travel arrangements, please = contact constituency-travel@icann.org. " FYI, /John From nobody Tue Jun 10 17:50:19 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0B81A0252 for ; Tue, 10 Jun 2014 17:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPrOs0lVQmao for ; Tue, 10 Jun 2014 17:50:13 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2EB51A0261 for ; Tue, 10 Jun 2014 17:50:12 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id lj1so392939pab.15 for ; Tue, 10 Jun 2014 17:50:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=K/Y1hIKnFiLyPKDaMnEhZLK4ICio0Sr0PSDaK3RUh2Q=; b=q2q1CM3R+f/q92zerzEsgLi9KPrtqPbIS0fBbK7/1IF6UmxPCLxJj/6j6svh6PAZ1g 9PDgU7VQSpUkn2EM2pQI9q2zaEe8KB4DCIiFse0R2UU81tliTXAgOC4E3OcO+5G22jSb C9WkqDAFyWDwrgWkkzGvU8KYrucXZ2hxdDc/pQhhe37QTymtouBK/hqCbsZnHPDOIeBG PJmV4ualJzntgDsfsoazw0o8V2d5jqJQdVRStXivnv/i3TVNNthCKZ7pCtbTqyT7naGq +AsKXkN9yN1zU0zwVXnZ0wB8x5dFe+zLEiW/i+kC6u9350vzBf9EfaHhmqS0WuIXFX57 W47g== X-Received: by 10.69.31.97 with SMTP id kl1mr760750pbd.162.1402447812549; Tue, 10 Jun 2014 17:50:12 -0700 (PDT) Received: from [192.168.178.23] (163.193.69.111.dynamic.snap.net.nz. [111.69.193.163]) by mx.google.com with ESMTPSA id eh4sm71634016pbc.79.2014.06.10.17.50.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Jun 2014 17:50:11 -0700 (PDT) Message-ID: <5397A7C7.9050907@gmail.com> Date: Wed, 11 Jun 2014 12:50:15 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Eric Brunner-Williams References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> In-Reply-To: <53976FDB.7060307@abenaki.wabanaki.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/0KbPlivm4q9QhlvZfBxhtIO3g6A Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 00:50:14 -0000 On 11/06/2014 08:51, Eric Brunner-Williams wrote: ... > no court has ruled on the question And frankly, who cares? Here in the technical community, we should be focussing on ensuring that IANA's authority comes from where it has always come from: the technical community as a whole. The laws and courts of any one country are beside the point. The technical community's members in the coordination group need to be people who will watch out for the technical health of the Internet, one aspect of which is protecting IANA from any kind of interference from national jurisdictions. Brian From nobody Tue Jun 10 18:29:47 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D101A0296 for ; Tue, 10 Jun 2014 18:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRMXhLkVEyHx for ; Tue, 10 Jun 2014 18:29:43 -0700 (PDT) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36FF81A0277 for ; Tue, 10 Jun 2014 18:29:43 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id bj1so1296052pad.7 for ; Tue, 10 Jun 2014 18:29:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=w+M5mtg/okoqJw397MS0uVF1iu8+zuZ1ZGA8MlGXYGE=; b=bfy7tT1K52rgYKLpO5+ABR+kbSZu+l8EZA3l1c8OOgNGTsVwJ71E4UD3svvV1KICxX DeQeGEEF5ZtsTnjTumFkNuARNWxGiUVRIbXit8rlQiOfoaUJbvHsyO/jqn+pQqOlii4l HqPonn8OKTyxc8K3mdUDk8zMVFYaNB3E/Hp4EEI5Rm5Qh/2WgkTfbU1wzMaizWX9/abW 6fFqJwOXiFX2vZ9FYzWaQAqiwE+S+NMR/2BLURIYOazS2d6SlKudFRqToK+/Sm3mKjMv gqlLApcZoGsJE5wfl398Gd41XHZ4DNPxICXpOVJedo/Ysip50aKZu0v97ghCI+MaYQRM YJzg== X-Gm-Message-State: ALoCoQluOXyYAcRpfLlPFfgev/QgBPGVgJMytbxzzhSP2dB9dSsGGgmpMW5eefsN4WKft2y/e3w5 X-Received: by 10.66.232.68 with SMTP id tm4mr9366129pac.114.1402450182882; Tue, 10 Jun 2014 18:29:42 -0700 (PDT) Received: from [10.0.1.3] (c-24-6-168-86.hsd1.ca.comcast.net. [24.6.168.86]) by mx.google.com with ESMTPSA id ek2sm71806703pbd.30.2014.06.10.18.29.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Jun 2014 18:29:41 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_AFF9285A-A9AF-4221-B3B2-92D7FB4C2608"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: David Conrad In-Reply-To: <5397A7C7.9050907@gmail.com> Date: Tue, 10 Jun 2014 18:29:35 -0700 Message-Id: <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/BbMGqUpIEPaRNxOwMHIQdJAAqE0 Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 01:29:45 -0000 --Apple-Mail=_AFF9285A-A9AF-4221-B3B2-92D7FB4C2608 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Brian, On Jun 10, 2014, at 5:50 PM, Brian E Carpenter = wrote: >> no court has ruled on the question > And frankly, who cares? [...] > The technical community's members in the coordination group > need to be people who will watch out for the technical health of > the Internet, one aspect of which is protecting IANA from any kind > of interference from national jurisdictions. Didn't you just answer your own question? Regards, -drc --Apple-Mail=_AFF9285A-A9AF-4221-B3B2-92D7FB4C2608 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJTl7EAAAoJENV6ebf0/4rXuFQH/3+2ObAfPgYsnMzl7/0vzk6y xqyFszANf8a0tg2zeFbf6dM85wcqZc2pI6Jfmi0TuqKnbuBEa45KhyxfidFhptG9 v8kU48xDdUhRaw4Qv/oDksTU5MZdiBl+awDoOqTUkVjUOZ0bfPDgnJJjgKWF1XfU lgjr5yIkGIlOxkdQHvUC+U/bakr9jNcX7UW+Gu/Uo6G6DlPUdSJw5fpPtYhVNy25 5jtyo46W6rw8hqVgKeaU26l6Ffl+8bT45NdqNanPPxIZ+eNg5s7vfTcK9d/VmZsn 3LVnrGKzHYsx80zx7Y/cmSl1TWyBItaV/oD+sdop1p633rkgmaqvCyeYDcg0rlM= =qOSV -----END PGP SIGNATURE----- --Apple-Mail=_AFF9285A-A9AF-4221-B3B2-92D7FB4C2608-- From nobody Tue Jun 10 18:42:40 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEEF41A02E3 for ; Tue, 10 Jun 2014 18:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TpoC5WH0760 for ; Tue, 10 Jun 2014 18:42:35 -0700 (PDT) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 659C01A0261 for ; Tue, 10 Jun 2014 18:42:35 -0700 (PDT) Received: by mail-pb0-f50.google.com with SMTP id rp16so1411471pbb.23 for ; Tue, 10 Jun 2014 18:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=cJf3j/18EuQshPC5Kw8N4dNLon/NB/VzyEhQCwPEMhc=; b=xXKzGVbfZ8HEm+D707git4dmHe+pqHW7Y5cmwaSf2jsQhCLhL28gfBYjLw4Pw2+wcQ Jg9T6iyUqAQ2/Y01V2iJAIZ3aO7VfBeZP1+Jx3CG/SU/tD7xhqSsUhACjjn/pDv37g7A NfF7BBjneWULmIFbFeX5hjzAQ0Tr+DRveZRx/+jsk/KDvMxPoGs6aYbgjoyyhinzHNiY +iRxpWF3Td8EbwL+G5GBFV6sQpR4bAz8lK1MUYo7stpAvA1sK+I30+2AM38wUSPhnQpK zRtBHgcBggMJt4I7ev3MrJfoQsnVQBdBwwFEXi4BgKGw2w1MOYfWq7pb4rKelhzQH6lT 8t4g== X-Received: by 10.66.244.176 with SMTP id xh16mr9545443pac.20.1402450954016; Tue, 10 Jun 2014 18:42:34 -0700 (PDT) Received: from [192.168.178.23] (163.193.69.111.dynamic.snap.net.nz. [111.69.193.163]) by mx.google.com with ESMTPSA id h5sm71771671pbw.81.2014.06.10.18.42.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Jun 2014 18:42:33 -0700 (PDT) Message-ID: <5397B40C.60509@gmail.com> Date: Wed, 11 Jun 2014 13:42:36 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: David Conrad References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> In-Reply-To: <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/pjVFfztpL0yFwTy8hpr-WTAUswE Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 01:42:36 -0000 On 11/06/2014 13:29, David Conrad wrote: > Brian, > > On Jun 10, 2014, at 5:50 PM, Brian E Carpenter wrote: >>> no court has ruled on the question >> And frankly, who cares? > [...] >> The technical community's members in the coordination group >> need to be people who will watch out for the technical health of >> the Internet, one aspect of which is protecting IANA from any kind >> of interference from national jurisdictions. > > Didn't you just answer your own question? I guess, but I read Eric's comment as implying that it was a bad thing that no court had ruled. Brian From nobody Tue Jun 10 19:17:04 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE171A035B for ; Tue, 10 Jun 2014 19:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgX76hrvbZ2A for ; Tue, 10 Jun 2014 19:17:02 -0700 (PDT) Received: from nike.wampumpeag.net (nike.wampumpeag.net [67.42.198.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34EF81A032D for ; Tue, 10 Jun 2014 19:17:02 -0700 (PDT) Received: from frog.local ([67.42.198.93]) by nike.wampumpeag.net (8.14.9/8.14.9) with ESMTP id s5B2GItL002489 for ; Tue, 10 Jun 2014 19:16:36 -0700 (PDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <5397BBE6.40604@abenaki.wabanaki.net> Date: Tue, 10 Jun 2014 19:16:06 -0700 From: Eric Brunner-Williams User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: internetgovtech@iab.org References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> In-Reply-To: <5397B40C.60509@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/W5bw6GHW8ehuPLgmYXK_6ZfjVPQ Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 02:17:03 -0000 On 6/10/14 6:42 PM, Brian E Carpenter wrote: > On 11/06/2014 13:29, David Conrad wrote: >> Brian, >> >> On Jun 10, 2014, at 5:50 PM, Brian E Carpenter wrote: >>>> no court has ruled on the question >>> And frankly, who cares? >> [...] >>> The technical community's members in the coordination group >>> need to be people who will watch out for the technical health of >>> the Internet, one aspect of which is protecting IANA from any kind >>> of interference from national jurisdictions. >> Didn't you just answer your own question? > I guess, but I read Eric's comment as implying that it was a bad > thing that no court had ruled. Brian, Because no court has ruled on the question, there are left with two competing theories -- does the exercise of the IANA Function arise from the delegation of rule making authority to a 501(c)(3) domiciled in California by the Department of Commerce, or does its authority arise from some other source? It is possible that the representation of Joe Sims et al, that no existing body of American law applies to what he represented as a "sui generis" body, for another dozen years without challenge, but it could work out otherwise. Eric From nobody Tue Jun 10 19:49:45 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF871A063A for ; Tue, 10 Jun 2014 19:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLIwHVO5unqW for ; Tue, 10 Jun 2014 19:49:32 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB91C1A0552 for ; Tue, 10 Jun 2014 19:49:32 -0700 (PDT) Received: from pool-108-56-179-253.washdc.fios.verizon.net ([108.56.179.253] helo=[192.168.1.10]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1WuYbT-0004Ia-U3; Wed, 11 Jun 2014 02:49:31 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 108.56.179.253 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+vfkP0i7x38etpGvf/3DH4 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: John Curran In-Reply-To: <5397BBE6.40604@abenaki.wabanaki.net> Date: Tue, 10 Jun 2014 22:49:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2963BB17-E425-46A9-A6CF-EE95C63B4626@istaff.org> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> To: Eric Brunner-Williams X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/0Wva1DrqXr28X314ux9cvFldHVo Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 02:49:37 -0000 On Jun 10, 2014, at 10:16 PM, Eric Brunner-Williams = wrote: > Because no court has ruled on the question, there are left with two = competing theories -- does the exercise of the IANA Function arise from = the delegation of rule making authority to a 501(c)(3) domiciled in = California by the Department of Commerce, or does its authority arise = from some other source? It would appear that anyone can use IETF protocols with any parameters=20= that they like (e.g. configure smtp over a different port than default, configure a private DNS root, use any general purpose IP addresses on interfaces) and the protocols will function just fine as long as one is communicating with other systems which are coordinated in these choices=20= of parameter values... I note that the IETF has arranged for their to be appropriate "IANA" = registries for the protocols that require such, and these registries are generally = used by=20 default by most of those using IETF protocols. Given that such usage is = voluntary=20 (albeit with strong "network effects" encouraging the use of single = 'definitive' registries for each protocol value), I don't know if the concept of = "governmental" authority is even applicable. Presumably, the IAB/IETF finds it useful = to arrange for an IANA registry to be administered when it approves a protocol; why = would=20 the IAB/IETF's authorization not be viewed as the source of authority = for an=20 IANA registry? /John Disclaimer: My views alone. From nobody Tue Jun 10 20:02:58 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A241E1A032E for ; Tue, 10 Jun 2014 20:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMJDqg-le7az for ; Tue, 10 Jun 2014 20:02:53 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 055BE1A019B for ; Tue, 10 Jun 2014 20:02:52 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id x12so5660556wgg.10 for ; Tue, 10 Jun 2014 20:02:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zgERXRvRZlBOh6BXqj3xGzUv6xkBQcJg2ZKE3TuapLY=; b=GgAu5gylChlUMz2ToNAdrUYnVrrFB3gNsODbRhFmo2vhHqfV2X64zLlwOLJu3Vzwf/ j/lddSRiW4kc4j8509BJ1zOxfnRdIEMVzIzXkZAH/wm3eR368MjEujNcOKH10fWZxnyp g8Htz9Zy20c84P+Nla2y+IwPlX/qyL13bREQrsQkFWtxQAp8KkmsQkDhbnIP7Kq3wmdr 4V7khffNFeDSEgbxDnj2cYG/mZJrwpcTeK95A+RZM9zMLpd47+8q1LehNO1FwjX8d8dZ oT8PhIT4AfGWZueNVOOslX47TuJZGrqLcW7pNEkc7Hdog0GNFnZ3NkAz88RTTDlqIkdm iRcQ== MIME-Version: 1.0 X-Received: by 10.180.81.102 with SMTP id z6mr42670502wix.54.1402455771262; Tue, 10 Jun 2014 20:02:51 -0700 (PDT) Received: by 10.194.61.78 with HTTP; Tue, 10 Jun 2014 20:02:51 -0700 (PDT) In-Reply-To: <5397BBE6.40604@abenaki.wabanaki.net> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> Date: Wed, 11 Jun 2014 11:02:51 +0800 Message-ID: From: Pindar Wong To: Eric Brunner-Williams Content-Type: multipart/alternative; boundary=f46d04428fb40f34ea04fb86ae5d Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/inH80ALrMuXvTIjpEsX6nQnLrs8 Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 03:02:55 -0000 --f46d04428fb40f34ea04fb86ae5d Content-Type: text/plain; charset=UTF-8 On Wed, Jun 11, 2014 at 10:16 AM, Eric Brunner-Williams < ebw@abenaki.wabanaki.net> wrote: > On 6/10/14 6:42 PM, Brian E Carpenter wrote: > >> On 11/06/2014 13:29, David Conrad wrote: >> >>> Brian, >>> >>> On Jun 10, 2014, at 5:50 PM, Brian E Carpenter < >>> brian.e.carpenter@gmail.com> wrote: >>> >>>> no court has ruled on the question >>>>> >>>> And frankly, who cares? >>>> >>> [...] >>> >>>> The technical community's members in the coordination group >>>> need to be people who will watch out for the technical health of >>>> the Internet, one aspect of which is protecting IANA from any kind >>>> of interference from national jurisdictions. >>>> >>> Didn't you just answer your own question? >>> >> I guess, but I read Eric's comment as implying that it was a bad >> thing that no court had ruled. >> > > Brian, > > Because no court has ruled on the question, there are left with two > competing theories -- does the exercise of the IANA Function arise from the > delegation of rule making authority to a 501(c)(3) domiciled in California > by the Department of Commerce, or does its authority arise from some other > source? > Perhaps consensus of the networks and consent of the networked? p. > > It is possible that the representation of Joe Sims et al, that no existing > body of American law applies to what he represented as a "sui generis" > body, for another dozen years without challenge, but it could work out > otherwise. > > Eric > > > > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech > --f46d04428fb40f34ea04fb86ae5d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Jun 11, 2014 at 10:16 AM, Eric Brunner-Williams <= ebw@abenaki.wabanaki.net> wrote:
On 6/10/14 6:42 PM, Brian E = Carpenter wrote:
On 11/06/2014 13:29, David Conrad wrote:
Brian,

On Jun 10, 2014, at 5:50 PM, Brian E Carpenter <brian.e.carpenter@gmail.com>= ; wrote:
no court has ruled on the question
And frankly, who cares?
[...]
The technical community's members in the coordination group
need to be people who will watch out for the technical health of
the Internet, one aspect of which is protecting IANA from any kind
of interference from national jurisdictions.
Didn't you just answer your own question?
I guess, but I read Eric's comment as implying that it was a bad
thing that no court had ruled.

Brian,

Because no court has ruled on the question, there are left with two competi= ng theories -- does the exercise of the IANA Function arise from the delega= tion of rule making authority to a 501(c)(3) domiciled in California by the= Department of Commerce, or does its authority arise from some other source= ?

Perhaps consensus of the networks and cons= ent of the networked?

p.
=C2=A0

It is possible that the representation of Joe Sims et al, that no existing = body of American law applies to what he represented as a "sui generis&= quot; body, =C2=A0for another dozen years without challenge, but it could w= ork out otherwise.

Eric



_______________________________________________
Internetgovtech mailing list
Internetgovtec= h@iab.org
https://www.iab.org/mailman/listinfo/internetgovtech

--f46d04428fb40f34ea04fb86ae5d-- From nobody Wed Jun 11 06:00:12 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6C31A009C for ; Wed, 11 Jun 2014 06:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsZvC2IAhaac for ; Wed, 11 Jun 2014 06:00:10 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B2791A0085 for ; Wed, 11 Jun 2014 06:00:10 -0700 (PDT) Received: from 231.74.14.81.rev.sfr.net ([81.14.74.231]:22946 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1Wui85-00016D-AZ; Wed, 11 Jun 2014 05:59:49 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 11 Jun 2014 14:59:45 +0200 To: Pindar Wong , Eric Brunner-Williams From: Jefsey In-Reply-To: References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: jefsey+jefsey.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/Qyyjw4gd23XVRAiSWbNWqRAx8Kc Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 13:00:11 -0000 At 05:02 11/06/2014, Pindar Wong wrote: >Perhaps consensus of the networks and consent of the networked? This consent is in a given stable context. Will it remain in another context? jfc From nobody Wed Jun 11 06:18:30 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D514F1A008B for ; Wed, 11 Jun 2014 06:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.632 X-Spam-Level: * X-Spam-Status: No, score=1.632 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8qKfScn3DcS for ; Wed, 11 Jun 2014 06:18:24 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A76D1A0084 for ; Wed, 11 Jun 2014 06:18:24 -0700 (PDT) Received: from 231.74.14.81.rev.sfr.net ([81.14.74.231]:23323 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1WuiQ1-0003Aw-E5; Wed, 11 Jun 2014 06:18:22 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 11 Jun 2014 15:18:16 +0200 To: John C Klensin ,Ted Lemon , Barry Leiba , Andrew Sullivan From: Jefsey References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <1E8054717F7369872099FDD6@JcK-HP8200.jck.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1037184784==.ALT" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: jefsey+jefsey.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/O6HCS_umxQAhyhZdpJ72JDba_FU Cc: internetgovtech@iab.org, iesg@ietf.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 13:18:26 -0000 --=====================_1037184784==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed >At 23:01 09/06/2014, John C Klensin wrote: >This is not a new problem >John, I think you pointed out the real issue. This SHOULD be a ***new*** problem for the Internet side. I will explain. This is as concise as I can make it for such a complex issue. The Internet issue The Internet project is described in IEN 48 as being local turning global. There is no provision for other layers whether a more central (people) or intermediary (corporate, urban, national, trades) one. The reason for that is that it is an "internetting" project and so the atomic unit is the local network in the catenet. "The term "local" is used [there] in a loose sense, here, since it means "peculiar to the particular network" rather than "a network of limited geographic extent." As a result, "global" will means wider than the US geographical meaning of "worldwide"; i.e. the French meaning of global as the "whole > sum of its parts" attached to something. The difficulty we are facing today, is that we have found for decades a certain compromise between the Internet culture and the national level and we now have to accommodate (1) all the others and (2) their entanglement (something we are not used to doing since nations are sovereign). This is the true issue: a communications governance systemic change and not only a reshuffling were "old problems" would only be adapted to an evolution. This is an Internet context total change. The national side The US national level is the most important among nations due to its specifics, being the largest and the first impacted. It was initially (pre-1978) based upon law (1934 Telecommunications Act) and FCC regulation. The debated started in 1976 and by 1978, the Congress had come to the working idea of competition as a better mean to push for innovation and possibly reduce the overall costs for the nation and boost industry, the issue being not to increase costs for the residential user due to investments in new technologies and less coordination between incumbents and new entrants. At the time, the discussed layer was bandwidth, but the packet switch was present (Telenet contribution in 1977) and temporary VAN status/license introduced for a few by the FCC (Telenet, Tymnet, Uninet). Deregulation, new Telecommunications Act, etc. have added to that. However, the momentum was there. The world side The two main issues at hand today are the logical and mental addressing systems (IP addresses and DNS). This started in 1977 as soon as the US IRCs and some PTTs adopted the Tymnet technology to start deploying the international packet switch services network because Tymnet was a licensed VAN and used semantic addresses. 1. Addressing Until the emergence of TCP/IP in the international public area (1984) through the Telenet domestic interconnect with Tymnet among others, to enlarge the Internet support via external networks (externets), international addressing was an ITU structured issue (X.121). Part of today's problem is the lack of an IPv6 capacity to support an X.121 scheme, as names supported X.121 from 1981 and efforts were paid for the DNS to support ENUM. 2. Naming The naming issue was licensed to Tymnet. Because the Tymnet technology became used for every new international service, its license has extended, through the US IRCs naming coordination, to the whole global systems and PTTs. It happens that I was facilitating that international aspect from 1978, and so I know what happened, but more importantly I know how and why. Semantic addressing (naming) is people's brain oriented. Its "how and why" belong to the brainware strata - i.e. the way people jointly use the hardware and software network system. The human brain having not been updated for some time, it is likely that its behavioral characteristics have not changed much. From observation, everything stayed internationally stable until recently. This was due to the users' trust in an objective common interest with FCC and then NTIA supervision that they first experienced with the Tymnet sponsored multistakeholder secretariat. This trust has survived the 2000 new TLD proposition, understood as trade experimentation, and ITLDs as ccTLD extensions in their script/language being in line with Jon Postel's RFC 920. This trust crumbled with the gTLD business sales and national aftermath and TM related issues. The reality check There are actually two opposing evaluations: either the NTIA is right or the IAB, IESG, ISOC, IEEE, W3C, RIRs, and ICANN are. 1. Either the target is "to produce high quality, relevant technical and engineering documents that influence the way people design, use, and manage the Internet in such a way as to make the Internet work better" (RFC 3639) in the line with the "universal service" concept under 1.1. either the US limited FCC + NTIA ICANN replacement global regulation, discussed on a delimited MS basis. This corresponds to a USG mastered VGN (virtual global network) under the current USG legislation and jurisdiction that most of the world continues to adhere to. 1.2. either the coordinated replication of other sovereign VGNs, by other governments as we see the Chinese Internet, the growing Russian Internet, or the Hollande/Merkel NSA proof attempt. 1.3. or the general entanglement of personal, social, trade, local, regional, national, specialized, and edge provider VGNs. 2. Or the target is an OpenStand approach where "the economics of global markets, fueled by technological advancements, drive the global deployment of standards regardless of their formal status" 2.1. fragmented on a merchants' dominant coopetitive MS basis. 2.2. united through the general acknowledgement of a subsidiary meshing of personal, social, trade, local, regional, national, specialized, and edge provider VGNs governed and standardized on an open MS basis. As an IUser, i.e. wanting to build, maintain, and interuse a stable, reliable, optimized, and symmetric relation at the best price and with all the parts, components, and interlocutors of my digitality's personal, local, external, global, and relational space. - I do not feel secure with 1.1. - I do not want 2.1. - I can survive 1.3. - I prefer 2.2. - Otherwise, I will call for protection from 1.2. How to solve this? There may be several ways to solve this since no one can expect that one of these five options will become globally consensual, and that each of them should consider its own contingency plan. IMHO, the best way to reach a multiconsensus is to consider that each of these hypotheses could work with the others in order to avoid frontal operational conflicts (e.g. over TM names, routing misunderstanding, etc.). This can be obtained in cross contributions along RFC 6852 if it is admitted that in the long run the economics of a global community is the use satisfaction of its members and that complex symmetric interuse will generalize. jfc --=====================_1037184784==.ALT Content-Type: text/html; charset="us-ascii"
At 23:01 09/06/2014, John C Klensin wrote:
This is not a new problem
John,

I think you pointed out the real issue. This SHOULD be a ***new*** problem for the Internet side.

I will explain. This is as concise as I can make it for such a complex issue.


The Internet issue

The Internet project is described in IEN 48 as being local turning global. There is no provision for other layers whether a more central (people) or intermediary (corporate, urban, national, trades) one. The reason for that is that it is an "internetting" project and so the atomic unit is the local network in the catenet. "The term "local" is used [there] in a loose sense, here, since it means "peculiar to the particular network" rather than "a network of limited geographic extent." As a result, "global" will means wider than the US geographical meaning of "worldwide"; i.e. the French meaning of global as the "whole > sum of its parts" attached to something.

The difficulty we are facing today, is that we have found for decades a certain compromise between the Internet culture and the national level and we now have to accommodate (1) all the others and (2) their entanglement (something we are not used to doing since nations are sovereign). This is the true issue: a communications governance systemic change and not only a reshuffling were "old problems" would only be adapted to an evolution. This is an Internet context total change.


The national side

The US national level is the most important among nations due to its specifics, being the largest and the first impacted. It was initially (pre-1978) based upon law (1934 Telecommunications Act) and FCC regulation. The debated started in 1976 and by 1978, the Congress had come to the working idea of competition as a better mean to push for innovation and possibly reduce the overall costs for the nation and boost industry, the issue being not to increase costs for the residential user due to investments in new technologies and less coordination between incumbents and new entrants. At the time, the discussed layer was bandwidth, but the packet switch was present (Telenet contribution in 1977) and temporary VAN status/license introduced for a few by the FCC (Telenet, Tymnet, Uninet). Deregulation, new Telecommunications Act, etc. have added to that. However, the momentum was there.


The world side

The two main issues at hand today are the logical and mental addressing systems (IP addresses and DNS). This started in 1977 as soon as the US IRCs and some PTTs adopted the Tymnet technology to start deploying the international packet switch services network because Tymnet was a licensed VAN and used semantic addresses.

1. Addressing

Until the emergence of TCP/IP in the international public area (1984) through the Telenet domestic interconnect with Tymnet among others, to enlarge the Internet support via external networks (externets), international addressing was an ITU structured issue (X.121). Part of today’s problem is the lack of an IPv6 capacity to support an X.121 scheme, as names supported X.121 from 1981 and efforts were paid for the DNS to support ENUM.

2. Naming

The naming issue was licensed to Tymnet. Because the Tymnet technology became used for every new international service, its license has extended, through the US IRCs naming coordination, to the whole global systems and PTTs. It happens that I was facilitating that international aspect from 1978, and so I know what happened, but more importantly I know how and why. Semantic addressing (naming) is people's brain oriented.  Its "how and why" belong to the brainware strata - i.e. the way people jointly use the hardware and software network system. The human brain having not been updated for some time, it is likely that its behavioral characteristics have not changed much.

From observation, everything stayed internationally stable until recently. This was due to the users' trust in an objective common interest with FCC and then NTIA supervision that they first experienced with the Tymnet sponsored multistakeholder secretariat. This trust has survived the 2000 new TLD proposition, understood as trade experimentation, and ITLDs as ccTLD extensions in their script/language being in line with Jon Postel’s RFC 920.

This trust crumbled with the gTLD business sales and national aftermath and TM related issues. 


The reality check

There are actually two opposing evaluations: either the NTIA is right or the IAB, IESG, ISOC, IEEE, W3C, RIRs, and ICANN are.

1. Either the target is "to produce high quality, relevant technical and engineering documents that influence the way people design, use, and manage the Internet in such a way as to make the Internet work better" (RFC 3639) in the line with the "universal service" concept under

1.1. either the US limited FCC + NTIA ICANN replacement global regulation, discussed on a delimited MS basis. This corresponds to a USG mastered VGN (virtual global network) under the current USG legislation and jurisdiction that most of the world continues to adhere to.
1.2. either the coordinated replication of other sovereign VGNs, by other governments as we see the Chinese Internet, the growing Russian Internet, or the Hollande/Merkel NSA proof attempt.
1.3. or the general entanglement of personal, social, trade, local, regional, national, specialized, and edge provider VGNs.

2. Or the target is an OpenStand approach where "the economics of global markets, fueled by technological advancements, drive the global deployment of standards regardless of their formal status"
2.1. fragmented on a merchants’ dominant coopetitive MS basis.
2.2. united through the general acknowledgement of a subsidiary meshing of personal, social, trade, local, regional, national, specialized, and edge provider VGNs governed and standardized on an open MS basis.

As an IUser, i.e. wanting to build, maintain, and interuse a stable, reliable, optimized, and symmetric relation at the best price and with all the parts, components, and interlocutors of my digitality's personal, local, external, global, and relational space.

- I do not feel secure with 1.1.
- I do not want 2.1.
- I can survive 1.3.
- I prefer 2.2.
- Otherwise, I will call for protection from 1.2.

How to solve this?
 
There may be several ways to solve this since no one can expect that one of these five options will become globally consensual, and that each of them should consider its own contingency plan. IMHO, the best way to reach a multiconsensus is to consider that each of these hypotheses could work with the others in order to avoid frontal operational conflicts (e.g. over TM names, routing misunderstanding, etc.). This can be obtained in cross contributions along RFC 6852 if it is admitted that in the long run the economics of a global community is the use satisfaction of its members and that complex symmetric interuse will generalize.

jfc --=====================_1037184784==.ALT-- From nobody Wed Jun 11 07:12:50 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD0B1A039B for ; Wed, 11 Jun 2014 07:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtAPOWUOzBHt for ; Wed, 11 Jun 2014 07:12:47 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A39271A0104 for ; Wed, 11 Jun 2014 07:12:46 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id z12so5474283wgg.25 for ; Wed, 11 Jun 2014 07:12:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=53FqFb0x5mSTK8miL4i9ne9PGvRoRiJw/nWrb82BOe0=; b=oeRdaubmSmC6cLWDlNdvUwoO43ATuqGkwZ7B6gu62fze7uYof0kIGB0oZMgzkhD5Zm maFBAacCH9xD77FdQ+kEjrfp0SImH6HuRmIF22qSVVUcbySP9ihd8DPGLIRp4juq4/Yp bXd44qt1wsPL4Wrh7ETfWjBGJgwS8XB1OeyCpMcnInOO8+uub0f3fwf/dxz/RjIRn+M1 XtJaKyoIXMTmjZH4VZRKGOUh+89LV1g9YL0O3S7XLuADHVpEvK0XswI8HnEaWJtj0weT 29TYtAjE9WZmQLIMTERTlBhLO39zscSB1RraDX5SjFoVM8aCnNmCbUZAljmuCuaD89bg zBiQ== MIME-Version: 1.0 X-Received: by 10.194.62.176 with SMTP id z16mr33425675wjr.76.1402495965008; Wed, 11 Jun 2014 07:12:45 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.79.136 with HTTP; Wed, 11 Jun 2014 07:12:44 -0700 (PDT) In-Reply-To: <20140609190830.GR27145@mx1.yitter.info> References: <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <20140609190830.GR27145@mx1.yitter.info> Date: Wed, 11 Jun 2014 10:12:44 -0400 X-Google-Sender-Auth: hPO4VzguSG1mF4IYhw-_Loy9Nx8 Message-ID: From: Phillip Hallam-Baker To: Andrew Sullivan Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/lYI_P3WcudSuRv8dHshbWtT-P94 Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 14:12:48 -0000 On Mon, Jun 9, 2014 at 3:08 PM, Andrew Sullivan wrote: > On Mon, Jun 09, 2014 at 11:46:30AM -0700, David Conrad wrote: > >> it, what changes were made and why, etc. Absolutely nothing should >> be done behind closed doors or be done in a way that does not allow >> anyone with interest to follow along. > > Do you extend that to "hallway discussions" among several individuals? Quite, how is it ever possible to do everything in public? I will float some wild idea here on the IETF lists because long experience is that the risks of doing so is nil. But I don't do that with government types. And they don't ask me to tell them what to do, they ask me to explain the technical consequences of political decisions. Now as people keep trying to tell me, my prospects of an official IETF role would be a lot better if I didn't have that irritating habit of telling the awful truth to people who just don't want to hear it. Well the difference with the government types is that many actually do want to hear the awful truth, just never in public. Where I think this particular process is bojorked is that we are still working from a model where we concentrate all the power in one place and then try to create controls to stop its abuse. That seems to me to be completely contrary to common sense. From nobody Wed Jun 11 08:10:18 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 050171A01AA for ; Wed, 11 Jun 2014 08:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.289 X-Spam-Level: * X-Spam-Status: No, score=1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mH9GYtttN-I for ; Wed, 11 Jun 2014 08:09:38 -0700 (PDT) Received: from nike.wampumpeag.net (unknown [67.42.198.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0086E1A05D1 for ; Wed, 11 Jun 2014 08:09:31 -0700 (PDT) Received: from frog.local ([67.42.198.93]) by nike.wampumpeag.net (8.14.9/8.14.9) with ESMTP id s5BF7Nf8004587; Wed, 11 Jun 2014 08:07:41 -0700 (PDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <5398709F.8060007@abenaki.wabanaki.net> Date: Wed, 11 Jun 2014 08:07:11 -0700 From: Eric Brunner-Williams User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Pindar Wong References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/WHPNtv0lQ5Ij3aqfSUEgfzO5C1M Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 15:10:10 -0000 On 6/10/14 8:02 PM, Pindar Wong wrote: > ... > > Perhaps consensus of the networks and consent of the networked? Pindar, Abstractly this revisits the problem faced in 2002 when attempting to form a "membership" for ICANN -- who "consent[s]"? If one stops at "the networks" and their "consensus", then depending upon one's {domain|address} centricism, it is the GNSO or the ASO, which is proximal to current practice. Your (rather nicely framed) one liner seems equivalent to Joe Sims' position that ICANN is "sui generis", and no existing law is applicable to answer the question of source of authority. Eric P.S. For those who don't recall there was a Membership Implementation Task Force (MTIF) which attempted to create broader participation in ICANN. An eventual indirect consequence of that failed effort was the formation of an "at large" vehicle for participation by those not able to participate through one of the Supporting Organizations (which included a "Protocol Supporting Organization" at that point in time, so IETF, ITU, W3C, ETSI contributors/members/corporations/...), and in particular, on the domain side of policy responsibility, not via a registry, registrar, trademark, access network, or business constituency membership, which eventually became an Advisory Committee in one of the many 2005/6 ByLaws changes, IIRC. From nobody Wed Jun 11 09:08:29 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 646641B27CF for ; Wed, 11 Jun 2014 09:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZpmkLAjFAAz for ; Wed, 11 Jun 2014 09:08:20 -0700 (PDT) Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 309FF1A01AB for ; Wed, 11 Jun 2014 09:08:20 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id un15so2181045pbc.20 for ; Wed, 11 Jun 2014 09:08:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=JwO70QAB30+MZlJJY8/Jv+KYwahYwEnGqJtuBowmE+k=; b=B65vJ2MisfKMYxh50x7gKwSfBOS1hT2c/fR7oZnIo3qpOVPWRc0Lf6toZPFR9lhwA7 YNeNLxVd9WvTvw4K2AqoEfTLKdTG1GQ4vbILoOIM6ePtI9KBYzJcjl7ZaaQLaiRKqk7D gl3VlrzASXaR5mcNISaJ+F3movYofkRiKWfthy8QOP+iTCxbKtpzj5WlW7uYHLRZvGEA KPmRNhIdXoT4OCnc1NOGZsx4/kmEcW1oqTTbB811jEKH6bV9sC6r0rrMqnxqFLJMY1JV U0lx8pYve4b9OdKeiKtydIAfUci9oCASNB3duN/zxGM5kKjb2zNSrw+Hrq8z6jBmnrg7 DSpw== X-Gm-Message-State: ALoCoQn2BUmVE6rx5xl3PWg23YzmE/bTylpFnXLbkL7KpWyL9yCmBkjvb4xZMbBPhlfJjpeBenHe X-Received: by 10.68.231.229 with SMTP id tj5mr6304212pbc.101.1402502899654; Wed, 11 Jun 2014 09:08:19 -0700 (PDT) Received: from [172.20.10.2] (mobile-166-137-187-242.mycingular.net. [166.137.187.242]) by mx.google.com with ESMTPSA id ir10sm75723087pbc.59.2014.06.11.09.08.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Jun 2014 09:08:18 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_BA8C6F3A-53A3-4B51-928A-30563AD4DB62"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: David Conrad In-Reply-To: <2963BB17-E425-46A9-A6CF-EE95C63B4626@istaff.org> Date: Wed, 11 Jun 2014 09:08:10 -0700 Message-Id: <79BC0637-22AE-46ED-A70C-C57446FC6511@virtualized.org> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <2963BB17-E425-46A9-A6CF-EE95C63B4626@istaff.org> To: John Curran X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/Jw3AaXEgIcZD_9xoF0hrLve3MxA Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 16:08:26 -0000 --Apple-Mail=_BA8C6F3A-53A3-4B51-928A-30563AD4DB62 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii John, On Jun 10, 2014, at 7:49 PM, John Curran wrote: > Given that such usage is voluntary=20 > (albeit with strong "network effects" encouraging the use of single = 'definitive' > registries for each protocol value), I don't know if the concept of = "governmental" > authority is even applicable. =20 And yet, IIRC you personally and on behalf of ARIN (not to mention = ARIN's counsel) have claimed on various and numerous occasions that = ARIN, one of the entities that administers a portion of those registries = delegated by the IETF, derives its authority from various U. S. = Government contracts going back to the mid-80s. Something, if you'll = remember, we disagreed on (and I won't go into the unfortunate results = of that particular disagreement). > Presumably, the IAB/IETF finds it useful to arrange > for an IANA registry to be administered when it approves a protocol; = why would=20 > the IAB/IETF's authorization not be viewed as the source of authority = for an=20 > IANA registry? Because it suits individual and organizational agendas (see comments = above) and the lack of a definitive ruling one way or the other leaves = the door open to various unpleasantries. As far as I can tell, the point of this exercise is to clear up the = ambiguity such that there is no longer any question that the = multi-stakeholder community is ultimately responsible for the = administration of the IANA Functions (or, dare I say, _the IANA_). I'm = honestly confused why anyone would argue against this. Regards, -drc --Apple-Mail=_BA8C6F3A-53A3-4B51-928A-30563AD4DB62 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJTmH7qAAoJENV6ebf0/4rXF60IAPlT/sl8mAOuDsHMGGRwXKEN i+/aAkrudQoGuqS1Hbc+l4PNCZzeswwgOKvt6PhmqP7BiFwcLtf82wORjJLcwaIE 7It5G8A775vrdyM7J7b/zR9KzxXH+RagDQEmolToaJNAceyqmUlpRHzrqU3cHJZV ULdyW5RnReHK3An4bs3b65g8d/eqp2sf6CZf7O3SVwLewE4cAQM2tDenYk2wnHKX I0G7hrICA0yeb9x/0Ub7+ZNwV5xXpTtPGkMRX3s+LT/+2jXGLKT2vgUjbpwtvOTU 1CRSvy4Bz1OlM0hjz07bVunhFUP73xG49EKuGOYJseQotmcPOP/iI3nVrLzTryE= =eOAX -----END PGP SIGNATURE----- --Apple-Mail=_BA8C6F3A-53A3-4B51-928A-30563AD4DB62-- From nobody Wed Jun 11 09:46:52 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1434B1A016C for ; Wed, 11 Jun 2014 09:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBsb-O1s92V4 for ; Wed, 11 Jun 2014 09:46:48 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE47D1A0024 for ; Wed, 11 Jun 2014 09:46:48 -0700 (PDT) Received: from pool-108-56-179-253.washdc.fios.verizon.net ([108.56.179.253] helo=[192.168.1.10]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1Wulfj-0001dL-Vf; Wed, 11 Jun 2014 16:46:48 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 108.56.179.253 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19EO9FFLlAb1eEVjT5xyBGU Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: text/plain; charset=us-ascii From: John Curran X-Priority: 1 In-Reply-To: <79BC0637-22AE-46ED-A70C-C57446FC6511@virtualized.org> Date: Wed, 11 Jun 2014 12:46:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1810133C-040B-4F9B-B16E-665442E56F8A@istaff.org> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <2963BB17-E425-46A9-A6CF-EE95C63B4626@istaff.org> <79BC0637-22AE-46ED-A70C-C57446FC6511@virtualized.org> To: David Conrad X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/xCSGSVRmtgE898tYaaU7RdzqwNI Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 16:46:51 -0000 On Jun 11, 2014, at 12:08 PM, David Conrad wrote: >=20 > And yet, IIRC you personally and on behalf of ARIN (not to mention = ARIN's counsel) have > claimed on various and numerous occasions that ARIN, one of the = entities that administers > a portion of those registries delegated by the IETF, derives its = authority from various > U. S. Government contracts going back to the mid-80s.=20 Note that it is quite possible to have multiple entities invest = authority into an=20 organization (particularly when multiple organizations have a role in = the creation) and ICANN certainty is the beneficiary of such a situation with respect = to USG/NTIA=20 and IAB/IETF when it comes to being viewed as an appropriate administer = of the DNS=20 registry. The same can be said of the RIR system with respect to = Internet numbering=20 resources. > As far as I can tell, the point of this exercise is to clear up the = ambiguity such that there is no longer any question that the = multi-stakeholder community is ultimately responsible for the = administration of the IANA Functions (or, dare I say, _the IANA_). I'm = honestly confused why anyone would argue against this. Complete agreement - this is an excellent time to resolve such overlap; = one might=20 argue it is an opportunity both without precedent and very unlikely to = recur.=20 For example, one could imagine an "IANA Stewardship Transition Plan" = which made plain the fact that the IANA registries are in fact "IETF IANA" = registries, with=20 policy authority for the general-purpose registries (names, addresses) = have already been durably delegated to organizations which are representative of the = served=20 communities; organizations that agree to follow open and transparent = processes,=20 and agree to have that confirmed periodically by well-defined = independent third- party multi-stakeholder review process. Such a plan, fully elaborated by the community (once accepted by the = USG) would=20 fully and completely resolve the authority confusion, while = simultaneously ending any unique USG role in oversight. =20 It could leverage some existing but strengthened accountability review = processes,=20 and would leave the IAB/IETF at a safe and healthy distance from such = organizations, except in the rare case of an actual organizational failure so = significant that an=20 independent review resulted in a finding that one of these organizations = was no longer representative of the served community; only then raising the = specter of=20 either an aggressive program to cure such a fault, or face potential = policy=20 authority redelegation to another organization more representative of = the served=20 community. FYI, /John Disclaimer: My views alone. This email message is provided "as-is", with = no=20 warranty expressed or implied. Please use your own judgement when = building=20 global Internet governance systems. From nobody Wed Jun 11 10:32:44 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209951A0207 for ; Wed, 11 Jun 2014 10:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, LOTS_OF_MONEY=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCXIYEm66Bc5 for ; Wed, 11 Jun 2014 10:32:40 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 993591A0194 for ; Wed, 11 Jun 2014 10:32:40 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u57so67865wes.17 for ; Wed, 11 Jun 2014 10:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=OqQwkGWb4l02fn8jymnSitvQ8A21TcTrITLolIgyHaE=; b=pXkpIiLkEpJ5uZ0Dlbf5jEOf6cF5YtDhieFoNnwyAi7nvfcdfoOMrm6qSQI8JE9mgI QcXkh6DtG6EbXphRdFsdgMgBtmQ1HWX4imES1aOz0CWV7EiYMl5kYFaZvBj4MESmTEfb Q0xn5VX6fZ+jKPctQREQu0YuiR4ruIKdP4S472o4XX8Yh3bkeQykleRFL5ucyHROFR4i 0W7HVkCrbugJalChaLSEsfwfsCl8Qq33O6eY43iKn1NVb8sUrWZ6G+uLVdQKtt1+3+bJ HwCCDYSV6i7qPyKeJ9FyrHKS7Id5Iaa/RvWHCcxIo0Lo19cjALh/9ntPypd9fINl+aYD ohBQ== MIME-Version: 1.0 X-Received: by 10.180.76.6 with SMTP id g6mr49021386wiw.34.1402507958816; Wed, 11 Jun 2014 10:32:38 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.79.136 with HTTP; Wed, 11 Jun 2014 10:32:38 -0700 (PDT) In-Reply-To: <1810133C-040B-4F9B-B16E-665442E56F8A@istaff.org> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <2963BB17-E425-46A9-A6CF-EE95C63B4626@istaff.org> <79BC0637-22AE-46ED-A70C-C57446FC6511@virtualized.org> <1810133C-040B-4F9B-B16E-665442E56F8A@istaff.org> Date: Wed, 11 Jun 2014 13:32:38 -0400 X-Google-Sender-Auth: _1BnhHftZImjOpylcbw0sMY_Rbk Message-ID: From: Phillip Hallam-Baker To: John Curran Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/OhdoT9JKiclQnIXBy3SI7St4Zcs Cc: internetgovtech@iab.org, David Conrad Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 17:32:42 -0000 On Wed, Jun 11, 2014 at 12:46 PM, John Curran wrote: > On Jun 11, 2014, at 12:08 PM, David Conrad wrote: >> >> And yet, IIRC you personally and on behalf of ARIN (not to mention ARIN's counsel) have >> claimed on various and numerous occasions that ARIN, one of the entities that administers >> a portion of those registries delegated by the IETF, derives its authority from various >> U. S. Government contracts going back to the mid-80s. > > Note that it is quite possible to have multiple entities invest authority into an > organization (particularly when multiple organizations have a role in the creation) > and ICANN certainty is the beneficiary of such a situation with respect to USG/NTIA > and IAB/IETF when it comes to being viewed as an appropriate administer of the DNS > registry. The same can be said of the RIR system with respect to Internet numbering > resources. How an organization is created and how it derives its ongoing legitimacy are two very different things. One of the main problems with the US government role is the presence of chest thumpers on the US government side. These are the people whose only role in life is to start wars that will kill thousands of people and thump their mighty chests proclaiming how manly they are and chanting USA! And the US chest thumpers are in fear of the Chinese and Russian chest thumpers who have the same sort of world view but a slightly different style of thumping. > For example, one could imagine an "IANA Stewardship Transition Plan" which made > plain the fact that the IANA registries are in fact "IETF IANA" registries, with > policy authority for the general-purpose registries (names, addresses) have already > been durably delegated to organizations which are representative of the served > communities; organizations that agree to follow open and transparent processes, > and agree to have that confirmed periodically by well-defined independent third- > party multi-stakeholder review process. The problem here is that we can't necessarily trust the organizations to self govern if the accountability structures are removed. There is no technical reason why a TLD should cost any more than any other type of domain but they cost a quarter million dollars just to apply. I am not that worried about there being a problem with IP addresses. If the RIRs misbehave the Internet community can create as many RIRs as it likes. But it would take a major breach of trust before they would want to do it. From nobody Wed Jun 11 11:45:29 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEDBC1B2807 for ; Wed, 11 Jun 2014 11:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jz2HM9RinZ56 for ; Wed, 11 Jun 2014 11:45:14 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C24991B27DF for ; Wed, 11 Jun 2014 11:45:14 -0700 (PDT) Received: from xarin.arin.net ([192.149.252.135] helo=[192.168.36.163]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1WunWL-000Lz4-Ab; Wed, 11 Jun 2014 18:45:13 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 192.149.252.135 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+inQY2r2oZhUO9Ihq6Upsx Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: John Curran In-Reply-To: Date: Wed, 11 Jun 2014 14:44:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <2963BB17-E425-46A9-A6CF-EE95C63B4626@istaff.org> <79BC0637-22AE-46ED-A70C-C57446FC6511@virtualized.org> <1810133C-040B- 4F9B-B16E-665442E56F8A@istaff.org> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/z8Maq77_ODBBwzA1hwsz36fE1AE Cc: internetgovtech@iab.org, David Conrad Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 18:45:22 -0000 On Jun 11, 2014, at 1:32 PM, Phillip Hallam-Baker = wrote: > On Wed, Jun 11, 2014 at 12:46 PM, John Curran = wrote: >=20 >> For example, one could imagine an "IANA Stewardship Transition Plan" = which made >> plain the fact that the IANA registries are in fact "IETF IANA" = registries, with >> policy authority for the general-purpose registries (names, = addresses) have already >> been durably delegated to organizations which are representative of = the served >> communities; organizations that agree to follow open and transparent = processes, >> and agree to have that confirmed periodically by well-defined = independent third- >> party multi-stakeholder review process. >=20 > The problem here is that we can't necessarily trust the organizations > to self govern if the accountability structures are removed. Agreed. > There is no technical reason why a TLD should cost any more than any > other type of domain but they cost a quarter million dollars just to > apply. >=20 > I am not that worried about there being a problem with IP addresses. > If the RIRs misbehave the Internet community can create as many RIRs > as it likes. But it would take a major breach of trust before they > would want to do it. I believe that there is quite a bit of room for improvement in the = present accountability structures for the organizations which have been = delegated=20 policy authority for general-purpose registries (i.e. both the RIRs and=20= ICANN); furthermore, I think the possibility of actually seeing = long-term improvements is probably higher under an approach where the IETF lays = out=20 clear expectations (i.e. for the accountability and transparency aspects=20= of the delegated authorities for IANA registries) then via the = trajectory=20 of the present USG-sponsored structures. FYI, /John Disclaimer: My views alone. From nobody Wed Jun 11 11:48:03 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C761B2802 for ; Wed, 11 Jun 2014 11:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.83 X-Spam-Level: X-Spam-Status: No, score=0.83 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNQsRh_Jn5tH for ; Wed, 11 Jun 2014 11:48:00 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFCED1A0259 for ; Wed, 11 Jun 2014 11:48:00 -0700 (PDT) Received: from 231.74.14.81.rev.sfr.net ([81.14.74.231]:30897 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1WunZ0-0007pv-VU; Wed, 11 Jun 2014 11:47:59 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 11 Jun 2014 20:47:43 +0200 To: Phillip Hallam-Baker , John Curran From: Jefsey In-Reply-To: References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <2963BB17-E425-46A9-A6CF-EE95C63B4626@istaff.org> <79BC0637-22AE-46ED-A70C-C57446FC6511@virtualized.org> <1810133C-040B-4F9B-B16E-665442E56F8A@istaff.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: jefsey+jefsey.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/7vtnvoxd2OLhifmIu6XrjBfl8z4 Cc: internetgovtech@iab.org, David Conrad Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 18:48:01 -0000 At 19:32 11/06/2014, Phillip Hallam-Baker wrote: >I am not that worried about there being a problem with IP addresses. >If the RIRs misbehave the Internet community can create as many RIRs >as it likes. But it would take a major breach of trust before they >would want to do it. Phillip, the breach of trust is to be assumed if you want to devise a self-healing system. Our chance is that a broad part of the trust is already gone in a very broad part of the world. This may help a constructuve thinking. Considering solutions based upon the former trust in the former trustee does not make sense. Any consideration based upon any other model than a fractal deterministic chaotic networking is necessarily doomed to fail at a certain point. I am sorry ICANN is not chaotic enough :-). jfc From nobody Wed Jun 11 17:00:59 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6839C1B28D9 for ; Wed, 11 Jun 2014 17:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lo22TI8k2Zc2 for ; Wed, 11 Jun 2014 17:00:55 -0700 (PDT) Received: from nike.wampumpeag.net (nike.wampumpeag.net [67.42.198.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4BDF1B28ED for ; Wed, 11 Jun 2014 17:00:55 -0700 (PDT) Received: from frog.local ([67.42.198.93]) by nike.wampumpeag.net (8.14.9/8.14.9) with ESMTP id s5BIPiZR032461; Wed, 11 Jun 2014 11:27:21 -0700 (PDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <53989EFA.5000806@abenaki.wabanaki.net> Date: Wed, 11 Jun 2014 11:24:58 -0700 From: Eric Brunner-Williams User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: John Curran References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <2963BB17-E425-46A9-A6CF-EE95C63B4626@istaff.org> In-Reply-To: <2963BB17-E425-46A9-A6CF-EE95C63B4626@istaff.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/s31owIYwzexstIz_YAnoX3nIrgk Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 00:00:57 -0000 John, Your note perplexes me. To constrain "use", your first argument, would require a private property interest to exist, or a public prohibition, and in either case, is unrelated to existence of one or more archives of data referenced in the publication of specifications, meeting the general notion of "open" and/or "interoperable" and "standards". Use, constrained or not, is distinct from the creation, curation, and assignment of what is used. To offer market share as sufficient to conclude that governmental authority is not applicable, your second argument, without protection from public prohibition, appears to overlook the liabilities that exist where market power also exists. Finally, to offer choice of registry for "IANA Considerations" as a complete statement of the technical community's interest in the proposal put forward by the current administration relating to the IANA Function is a much narrower reading of the issues than I can entertain. I've tried to avoid the ground DRC's already covered. Eric On 6/10/14 7:49 PM, John Curran wrote: > On Jun 10, 2014, at 10:16 PM, Eric Brunner-Williams wrote: > >> Because no court has ruled on the question, there are left with two competing theories -- does the exercise of the IANA Function arise from the delegation of rule making authority to a 501(c)(3) domiciled in California by the Department of Commerce, or does its authority arise from some other source? > It would appear that anyone can use IETF protocols with any parameters > that they like (e.g. configure smtp over a different port than default, > configure a private DNS root, use any general purpose IP addresses on > interfaces) and the protocols will function just fine as long as one is > communicating with other systems which are coordinated in these choices > of parameter values... > > I note that the IETF has arranged for their to be appropriate "IANA" registries > for the protocols that require such, and these registries are generally used by > default by most of those using IETF protocols. Given that such usage is voluntary > (albeit with strong "network effects" encouraging the use of single 'definitive' > registries for each protocol value), I don't know if the concept of "governmental" > authority is even applicable. Presumably, the IAB/IETF finds it useful to arrange > for an IANA registry to be administered when it approves a protocol; why would > the IAB/IETF's authorization not be viewed as the source of authority for an > IANA registry? > > /John > > Disclaimer: My views alone. > > > > > > > > From nobody Wed Jun 11 18:09:59 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8E21B291B for ; Wed, 11 Jun 2014 18:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOLZb7Lxc1o8 for ; Wed, 11 Jun 2014 18:09:03 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E4141B2928 for ; Wed, 11 Jun 2014 18:09:03 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id q59so522858wes.27 for ; Wed, 11 Jun 2014 18:09:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=A29mqF8k2l0Q652IyGpBif4HG3iPha71ctoN5kkjsvk=; b=jykjbkIZpnqFKLXsCPFXZnmsUwF5MRGlf2rlbXqpaxJr+40gWPiWQPpvEE/8KkF2wZ PHRywjLUjrHETU7BK+BxQdOgeaN3kb2b/GdxNK2UnKymFwp+UMSDiH7VBLTlyXrrIcYV aruuHQhizSTXRH+9g5IxiiXEEb1G6cBZK4DUkPUtTFEuu3jXy7RufuqJQOlmOiK6jM7B d2KpOVIaYgwiuebPXcmfhfvDfWxMxag69SaNQo+72ZxUl6wXtljgtlcZIonncRA+8gdg 0bJIliDYjtBu8ay5LNMr/P7Z+Zmi+abXMjp+g7pLNPJuMpqs4LW5iMuSe0aStYzJGZb7 5K0Q== MIME-Version: 1.0 X-Received: by 10.180.75.75 with SMTP id a11mr1609391wiw.3.1402535341556; Wed, 11 Jun 2014 18:09:01 -0700 (PDT) Received: by 10.194.92.3 with HTTP; Wed, 11 Jun 2014 18:09:01 -0700 (PDT) In-Reply-To: <20140611130013.007F71A00AA@ietfa.amsl.com> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <20140611130013.007F71A00AA@ietfa.amsl.com> Date: Thu, 12 Jun 2014 09:09:01 +0800 Message-ID: From: Pindar Wong To: Jefsey Content-Type: multipart/alternative; boundary=f46d04388e95d18e4c04fb9934d4 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/jWU0-bK_nW5rppitOQ3LeFzzcPs Cc: Eric Brunner-Williams , internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 01:09:49 -0000 --f46d04388e95d18e4c04fb9934d4 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 11, 2014 at 8:59 PM, Jefsey wrote: > At 05:02 11/06/2014, Pindar Wong wrote: > >> Perhaps consensus of the networks and consent of the networked? >> > > This consent is in a given stable context. Will it remain in another > context? > I guess the perception of stability depends on one's perspective as the context itself evolves over time i.e. At a high enough level, things looks gracefully stable ... look close enough and it's frothy quantum foam. Consent, and implied legitimacy through use, can also quickly change. See yesterday's posting by John Curran who said it well. p. jfc > > _______________________________________________ > Internetgovtech mailing list > Internetgovtech@iab.org > https://www.iab.org/mailman/listinfo/internetgovtech > --f46d04388e95d18e4c04fb9934d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Jun 11, 2014 at 8:59 PM, Jefsey <jefsey@jefsey.com> = wrote:
At 05:02 11/06/2014= , Pindar Wong wrote:
Perhaps consensus of the networks and consent of the networked?

This consent is in a given stable context. Will it remain in another contex= t?

I guess the perception of stab= ility depends on one's perspective as the context itself evolves over t= ime i.e. At a high enough level, things looks gracefully stable ... look cl= ose enough and it's frothy quantum foam.=C2=A0 Consent, and implied leg= itimacy through use,=C2=A0 can also quickly change. See yesterday's pos= ting by John Curran who said it well.

p.



jfc

_______________________________________________
Internetgovtech mailing list
Internetgovtec= h@iab.org
https://www.iab.org/mailman/listinfo/internetgovtech

--f46d04388e95d18e4c04fb9934d4-- From nobody Wed Jun 11 18:38:22 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313A61B2942 for ; Wed, 11 Jun 2014 18:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKqYTMhp6V7P for ; Wed, 11 Jun 2014 18:38:19 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E5631B2944 for ; Wed, 11 Jun 2014 18:38:18 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id n15so2110757wiw.17 for ; Wed, 11 Jun 2014 18:38:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qJu/jwnFP0t+26ZTbxrBsPZKrkIeMkXFMoiNmACPteQ=; b=ES4EORIIK+eS1fntMBu5Fsq+AMlxU0P5DLt1aYbnHXPTEXSlRcHQPM+/trcisDvB0j PFGtFMWBJ807qKuEQn6eQJyo9QK1Ki7xNJHz6+bBXwYFREl9O5wZ8PxbV7AffofZxiOX Wyy8HSGKo87NFRzAEfnaF/KSadcE2JZ1QSxD2VJ/cHSiJri8In82ZAhdvN6T3OtROr13 TbShUgCt3g0DsUGq4p1hgFDgd2QIc2OrtzNax41lt//cgo5hUkvPbIzYPdCPx8VALM6y PanfcE76HS7PqsjLCFrre1H7cJIdOIGKGYOxx9KFxuQ3CQOFk/NgakgZJX1idoFqvVYf b6wA== MIME-Version: 1.0 X-Received: by 10.180.73.201 with SMTP id n9mr1590687wiv.45.1402537097672; Wed, 11 Jun 2014 18:38:17 -0700 (PDT) Received: by 10.194.92.3 with HTTP; Wed, 11 Jun 2014 18:38:17 -0700 (PDT) In-Reply-To: <5398709F.8060007@abenaki.wabanaki.net> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <5398709F.8060007@abenaki.wabanaki.net> Date: Thu, 12 Jun 2014 09:38:17 +0800 Message-ID: From: Pindar Wong To: Eric Brunner-Williams Content-Type: multipart/alternative; boundary=f46d0435c02a7dc0f204fb999d83 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/BzmWdTg-pOdbGnCQkltsmkalkfM Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 01:38:21 -0000 --f46d0435c02a7dc0f204fb999d83 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 11, 2014 at 11:07 PM, Eric Brunner-Williams < ebw@abenaki.wabanaki.net> wrote: > On 6/10/14 8:02 PM, Pindar Wong wrote: > >> ... >> >> >> Perhaps consensus of the networks and consent of the networked? >> > > Pindar, > > Abstractly this revisits the problem faced in 2002 when attempting to form > a "membership" for ICANN -- who "consent[s]"? If one stops at "the > networks" and their "consensus", then depending upon one's {domain|address} > centricism, it is the GNSO or the ASO, which is proximal to current > practice. > That wasn't my intention but I believe you're right Eric. > > Your (rather nicely framed) one liner seems equivalent to Joe Sims' > position that ICANN is "sui generis", and no existing law is applicable to > answer the question of source of authority. Sorry I'm not a lawyer ... much to my mother's disappointment ;) To my eye, I believe that ICANN is indeed 'sui generis' in so far as it is unique to its characteristics, its evolving context and its participants. Hence my skepticism that ICANN might serve as appropriate model in a different context. To my mind, the question of source of legitimacy is through voluntary use and engagement and, where necessary ... expressed through contract, enforced by law. As far as the law of the jungle, perhaps 'possession is 9/10th of the law' ? p. > > Eric > > P.S. For those who don't recall there was a Membership Implementation Task > Force (MTIF) which attempted to create broader participation in ICANN. An > eventual indirect consequence of that failed effort was the formation of an > "at large" vehicle for participation by those not able to participate > through one of the Supporting Organizations (which included a "Protocol > Supporting Organization" at that point in time, so IETF, ITU, W3C, ETSI > contributors/members/corporations/...), and in particular, on the domain > side of policy responsibility, not via a registry, registrar, trademark, > access network, or business constituency membership, which eventually > became an Advisory Committee in one of the many 2005/6 ByLaws changes, IIRC. > --f46d0435c02a7dc0f204fb999d83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Jun 11, 2014 at 11:07 PM, Eric Brunner-Williams <= ebw@abenaki.wabanaki.net> wrote:
On 6/10/14 8:02 PM, Pindar Wong wrote:
...


Perhaps consensus of the networks and consent of the networked?

Pindar,

Abstractly this revisits the problem faced in 2002 when attempting to form = a "membership" for ICANN -- who "consent[s]"? =C2=A0If = one stops at "the networks" and their "consensus", then= depending upon one's {domain|address} centricism, it is the GNSO or th= e ASO, which is proximal to current practice.

That wasn't my intention but I believe= you're right Eric.=C2=A0
=C2=A0

Your (rather nicely framed) one liner seems equivalent to Joe Sims' pos= ition that ICANN is "sui generis", and no existing law is applica= ble to answer the question of source of authority.

Sorry I'm not a lawyer ... much to my mother's disappoin= tment ;)

To my eye, I believe that ICANN is indeed 'sui generis&= #39; in so far as it is unique to its characteristics, its evolving context= and its participants. Hence my skepticism that ICANN might serve as approp= riate model in a different context.=C2=A0 To my mind, the question of sourc= e of legitimacy is through voluntary use and engagement and, where necessar= y=C2=A0 ... expressed through contract,=C2=A0 enforced by law.=C2=A0
=C2=A0
As far as the law of the jungle, perhaps 'possess= ion is 9/10th of the law' ?

p.




Eric

P.S. For those who don't recall there was a Membership Implementation T= ask Force (MTIF) which attempted to create broader participation in ICANN. = An eventual indirect consequence of that failed effort was the formation of= an "at large" vehicle for participation by those not able to par= ticipate through one of the Supporting Organizations (which included a &quo= t;Protocol Supporting Organization" at that point in time, so IETF, IT= U, W3C, ETSI contributors/members/corporations/...), and in particul= ar, on the domain side of policy responsibility, not via a registry, regist= rar, trademark, access network, or business constituency membership, which = eventually became an Advisory Committee in one of the many 2005/6 ByLaws ch= anges, IIRC.

--f46d0435c02a7dc0f204fb999d83-- From nobody Wed Jun 11 19:49:20 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 942BA1A0359 for ; Wed, 11 Jun 2014 19:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSRlSdMr0JYh for ; Wed, 11 Jun 2014 19:49:09 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1409A1A0351 for ; Wed, 11 Jun 2014 19:49:08 -0700 (PDT) Received: from pool-108-56-179-253.washdc.fios.verizon.net ([108.56.179.253] helo=[192.168.1.10]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1Wuv4Y-000LUb-Lz; Thu, 12 Jun 2014 02:49:08 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 108.56.179.253 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18SCvV4HZhNW9RLb8Iei391 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: John Curran In-Reply-To: <53989EFA.5000806@abenaki.wabanaki.net> Date: Wed, 11 Jun 2014 22:48:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <2963BB17-E425-46A9-A6CF-EE95C63B4626@istaff.org> <53989EFA.5000806@abenaki.wabanaki.net> To: Eric Brunner-Williams X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/PZNXgdAgqstB_Tbdpew2iRQoffA Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 02:49:14 -0000 On Jun 11, 2014, at 2:24 PM, Eric Brunner-Williams = wrote: > Your note perplexes me. To constrain "use", your first argument, would = require a private property interest to exist, or a public prohibition, = and in either case, is unrelated to existence of one or more archives of = data referenced in the publication of specifications, meeting the = general notion of "open" and/or "interoperable" and "standards". Use, = constrained or not, is distinct from the creation, curation, and = assignment of what is used. Apologies for the confusion; I should have answered your question more = directly - Question: "...does its authority arise from some other source?" Answer: = Yes, the=20 IETF/IAB/ICANN MOU, RFC 2860. > To offer market share as sufficient to conclude that governmental = authority is not applicable, your second argument, without protection = from public prohibition, appears to overlook the liabilities that exist = where market power also exists. I did not conclude that governmental authority is not applicable, I = indicated that I did not know if it is applicable. The exercise of governmental authority or = intervention in=20 advance of any misuse of market power (particularly in a normal = situation of an industry=20 with appropriate accountability mechanisms to the served community) does = seem unnecessary=20 to me. There should certainly the typical legal recourse available for = misuse of such power, but that does not imply that the present system must be anchored = by "governmental authority." > Finally, to offer choice of registry for "IANA Considerations" as a = complete statement of the technical community's interest in the proposal = put forward by the current administration relating to the IANA Function = is a much narrower reading of the issues than I can entertain. The technical community should probably propose an actual framework = which indicates that=20 IANA registry administration shall be performed in an accountable and = transparent manner,=20 is stable, etc. Perhaps the full list of issues that you entertain as = relevant for the IANA registries should included in draft-iab-iana-framework? Thanks! /John Disclaimer: My views alone. From nobody Wed Jun 11 20:48:51 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A931D1B29AF for ; Wed, 11 Jun 2014 20:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.565 X-Spam-Level: X-Spam-Status: No, score=-1.565 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mNKmoFzscIF for ; Wed, 11 Jun 2014 20:48:34 -0700 (PDT) Received: from nike.wampumpeag.net (nike.wampumpeag.net [67.42.198.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC75B1B29AE for ; Wed, 11 Jun 2014 20:48:33 -0700 (PDT) Received: from frog.local ([67.42.198.93]) by nike.wampumpeag.net (8.14.9/8.14.9) with ESMTP id s5C2orp6036930; Wed, 11 Jun 2014 19:51:12 -0700 (PDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <53991572.3090705@abenaki.wabanaki.net> Date: Wed, 11 Jun 2014 19:50:26 -0700 From: Eric Brunner-Williams User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Pindar Wong References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <5398709F.8060007@abenaki.wabanaki.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020406070200080609090307" Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/hLqY-S27jtXQnVt6CTIQpcQ0zqM Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 03:48:36 -0000 This is a multi-part message in MIME format. --------------020406070200080609090307 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Pindar, I'm not a lawyer either, but my wife, who is, and is a government lawyer, keeps muttering "jurisdiction." First, ICANN is not the only 501(c)(3) that has been delegated regulatory authority by the legislative and executive branches over certain functions generally reserved to agencies of the Executive Branch (of the United States Government, this form of delegated regulatory authority is found at all levels of government, its called "privatization"). But make no mistake that this delegation of authority to a private actor in no way means a divestiture of the long-term authority over the property interest, it is a delegation, not a divestiture. The United States Government's real and/or intellectual property interest is substantial; full divestiture will most likely take an Act of Congress -- an Executive Order is unlikely to suffice in this political climate. Eric On 6/11/14 6:38 PM, Pindar Wong wrote: > > > > On Wed, Jun 11, 2014 at 11:07 PM, Eric Brunner-Williams > > wrote: > > On 6/10/14 8:02 PM, Pindar Wong wrote: > > ... > > > Perhaps consensus of the networks and consent of the networked? > > > Pindar, > > Abstractly this revisits the problem faced in 2002 when attempting > to form a "membership" for ICANN -- who "consent[s]"? If one > stops at "the networks" and their "consensus", then depending upon > one's {domain|address} centricism, it is the GNSO or the ASO, > which is proximal to current practice. > > > That wasn't my intention but I believe you're right Eric. > > > Your (rather nicely framed) one liner seems equivalent to Joe > Sims' position that ICANN is "sui generis", and no existing law is > applicable to answer the question of source of authority. > > > Sorry I'm not a lawyer ... much to my mother's disappointment ;) > > To my eye, I believe that ICANN is indeed 'sui generis' in so far as > it is unique to its characteristics, its evolving context and its > participants. Hence my skepticism that ICANN might serve as > appropriate model in a different context. To my mind, the question of > source of legitimacy is through voluntary use and engagement and, > where necessary ... expressed through contract, enforced by law. > > As far as the law of the jungle, perhaps 'possession is 9/10th of the > law' ? > > p. > > > > > Eric > > P.S. For those who don't recall there was a Membership > Implementation Task Force (MTIF) which attempted to create broader > participation in ICANN. An eventual indirect consequence of that > failed effort was the formation of an "at large" vehicle for > participation by those not able to participate through one of the > Supporting Organizations (which included a "Protocol Supporting > Organization" at that point in time, so IETF, ITU, W3C, ETSI > contributors/members/corporations/...), and in particular, on the > domain side of policy responsibility, not via a registry, > registrar, trademark, access network, or business constituency > membership, which eventually became an Advisory Committee in one > of the many 2005/6 ByLaws changes, IIRC. > > --------------020406070200080609090307 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Pindar,

I'm not a lawyer either, but my wife, who is, and is a government lawyer, keeps muttering "jurisdiction."

First, ICANN is not the only 501(c)(3) that has been delegated regulatory authority by the legislative and executive branches over certain functions generally reserved to agencies of the Executive Branch (of the United States Government, this form of delegated regulatory authority is found at all levels of government, its called "privatization"). But make no mistake that this delegation of authority to a private actor in no way means a divestiture of the long-term authority over the property interest, it is a delegation, not a divestiture.

The United States Government's real and/or intellectual property interest is substantial; full divestiture will most likely take an Act of Congress -- an Executive Order is unlikely to suffice in this political climate.

Eric

On 6/11/14 6:38 PM, Pindar Wong wrote:



On Wed, Jun 11, 2014 at 11:07 PM, Eric Brunner-Williams <ebw@abenaki.wabanaki.net> wrote:
On 6/10/14 8:02 PM, Pindar Wong wrote:
...


Perhaps consensus of the networks and consent of the networked?

Pindar,

Abstractly this revisits the problem faced in 2002 when attempting to form a "membership" for ICANN -- who "consent[s]"?  If one stops at "the networks" and their "consensus", then depending upon one's {domain|address} centricism, it is the GNSO or the ASO, which is proximal to current practice.

That wasn't my intention but I believe you're right Eric. 
 

Your (rather nicely framed) one liner seems equivalent to Joe Sims' position that ICANN is "sui generis", and no existing law is applicable to answer the question of source of authority.

Sorry I'm not a lawyer ... much to my mother's disappointment ;)

To my eye, I believe that ICANN is indeed 'sui generis' in so far as it is unique to its characteristics, its evolving context and its participants. Hence my skepticism that ICANN might serve as appropriate model in a different context.  To my mind, the question of source of legitimacy is through voluntary use and engagement and, where necessary  ... expressed through contract,  enforced by law. 
 
As far as the law of the jungle, perhaps 'possession is 9/10th of the law' ?

p.




Eric

P.S. For those who don't recall there was a Membership Implementation Task Force (MTIF) which attempted to create broader participation in ICANN. An eventual indirect consequence of that failed effort was the formation of an "at large" vehicle for participation by those not able to participate through one of the Supporting Organizations (which included a "Protocol Supporting Organization" at that point in time, so IETF, ITU, W3C, ETSI contributors/members/corporations/...), and in particular, on the domain side of policy responsibility, not via a registry, registrar, trademark, access network, or business constituency membership, which eventually became an Advisory Committee in one of the many 2005/6 ByLaws changes, IIRC.


--------------020406070200080609090307-- From nobody Wed Jun 11 23:59:04 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB201A0641 for ; Wed, 11 Jun 2014 23:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLxBdD2c6f7N for ; Wed, 11 Jun 2014 23:58:58 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id BBDC61A08EC for ; Wed, 11 Jun 2014 23:58:58 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.141.215]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s5C6tx1N013296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jun 2014 23:56:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1402556171; x=1402642571; bh=WYtgk1g/C8LqfWcUHr7kLQrOlS6pl+rvaHp9CTs++qQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=rXXVWJ6MDSME6zovhxpjTowzf3rYfE3pcX3mMVHga8LHTdu/bIsxsewGIKgBOjUKz w3wjU6b4yxESJ9qv9FKOk467AwexeLWrBmJXZS6D3rlRQLTBDWgUfJy7D2S8Zt+AMw m2SA4iyKD3rhuFMMWtJaJ0+xQ9pxkLzne/Tl1V98= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1402556171; x=1402642571; i=@elandsys.com; bh=WYtgk1g/C8LqfWcUHr7kLQrOlS6pl+rvaHp9CTs++qQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=qj3jVCgktz95WTATiFaxZWW9mi4yWfzVhiBATBiKp6zr9ZOKEpCqopxvTnTmRPVe5 ZBigOg22GQBKEXNOubltNYkXtnEbawkwRl8EgO10bise1DfDR+jKsBj8gEPQcMXvjb DzRrsTvKOe6mU32mIEW3WmAgM/FG31yM3wnFUN5s= Message-Id: <6.2.5.6.2.20140611225603.0b8f99c8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 11 Jun 2014 23:39:58 -0700 To: Eric Brunner-Williams , Pindar Wong From: S Moonesamy In-Reply-To: <53991572.3090705@abenaki.wabanaki.net> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <5398709F.8060007@abenaki.wabanaki.net> <53991572.3090705@abenaki.wabanaki.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/vjY0CApA625NB0Su5briBH3GAZM Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 06:59:01 -0000 Hi Eric, At 19:50 11-06-2014, Eric Brunner-Williams wrote: >The United States Government's real and/or intellectual property >interest is substantial; full divestiture will most likely take an >Act of Congress -- an Executive Order is unlikely to suffice in this >political climate. I am commenting about the IETF Protocol Parameter Registries. According to the IETF, and a previous IAB, the copyright on that is to be held by the IETF Trust. Regards, S. Moonesamy From nobody Thu Jun 12 00:06:35 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8A31A0259 for ; Thu, 12 Jun 2014 00:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcHw9ThRXq-n for ; Thu, 12 Jun 2014 00:06:10 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB82C1A01DC for ; Thu, 12 Jun 2014 00:06:10 -0700 (PDT) Received: from [192.168.1.45] ([109.128.169.101]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s5C762I0018617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 12 Jun 2014 00:06:08 -0700 Message-ID: <53995121.4000507@dcrocker.net> Date: Thu, 12 Jun 2014 09:05:05 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Pindar Wong References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <20140611130013.007F71A00AA@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 12 Jun 2014 00:06:09 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/u5WoF359fuX4evlrYna3UkUhCWA Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 07:06:18 -0000 On 6/12/2014 3:09 AM, Pindar Wong wrote: > I guess the perception of stability depends on one's perspective as the > context itself evolves over time i.e. At a high enough level, things > looks gracefully stable ... look close enough and it's frothy quantum foam. Hi Pindar. Your comment echoes a cliche about organization management. It involves the image of a duck paddling across a quiet pond, as seen by the eagle and the fish. The view of the eagle is of the duck gracefully moving across the pond; quite a serene image. The fish only sees the duck feet thrashing about, below, which makes everything seem a mess. I suppose there is also the usual reference to eating sausage, versus watching it being made. While these ought to give us pause from overreacting about how an organization is managed, there's always a danger that knowing about the potential of overreacting might cause us to underreact... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Jun 12 01:57:10 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0EEC1A854B for ; Thu, 12 Jun 2014 01:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.231 X-Spam-Level: ** X-Spam-Status: No, score=2.231 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_19=0.6, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2sG5Oa2JFvs for ; Thu, 12 Jun 2014 01:57:07 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8568A1A0199 for ; Thu, 12 Jun 2014 01:57:07 -0700 (PDT) Received: from 231.74.14.81.rev.sfr.net ([81.14.74.231]:9499 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1Wv0oj-0004qn-44; Thu, 12 Jun 2014 01:57:05 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 12 Jun 2014 10:57:00 +0200 To: John Curran ,David Conrad From: Jefsey In-Reply-To: <1810133C-040B-4F9B-B16E-665442E56F8A@istaff.org> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <2963BB17-E425-46A9-A6CF-EE95C63B4626@istaff.org> <79BC0637-22AE-46ED-A70C-C57446FC6511@virtualized.org> <1810133C-040B-4F9B-B16E-665442E56F8A@istaff.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: jefsey+jefsey.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/Z6TbYhEbPEqwL0chtEJiuC7FgjI Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 08:57:08 -0000 At 18:46 11/06/2014, John Curran wrote: >For example, one could imagine an "IANA Stewardship Transition Plan" >which made >plain the fact that the IANA registries are in fact "IETF IANA" >registries, with >policy authority for the general-purpose registries (names, >addresses) have already >been durably delegated to organizations which are representative of >the served >communities; organizations that agree to follow open and transparent >processes, >and agree to have that confirmed periodically by well-defined >independent third- >party multi-stakeholder review process. John, I am sorry but, again, the only thing you can take for granted is a total lack of trust. (1) people have stopped trusting the US and any other government/hacker/human dependant system. (2) in the IoT machines do not trust because trust is not quantifiable. I can only trust names I created, selected, validated, got certified. I can only trust objective elements in terms of address. I do not pay for my GPS geographic coordinates. I know this kills the name and address sales industry and has therefore strong opposition in I*dominance, but we have to accept the true NTIA's removal significance: the US VGN (virtual global network). Market monopoly has come to an end. The uncomplete RFC 6852 is enacted. The internet is fragmanted among "global communities" (that are "benefiting humanity")of which the different economic interests decide. Not the NTIA, not ICANN, not RIRs, not the IETF, not even the Governments. This has been decided by the IAB: in removing themselves as the ultimate referent of what is a "better internet" and stating that voluntarily accepted standards are the norm. We all are to adapt. The NTIA is trying. I agree that RFC 6852 in uncomplete because it does not say, nor even exemplify, how to adapt. However its diagonisis is true. Since Russ only intends to interoperate with the NTIA/ICANN process and not with any other collective empowerment concordance process, things are settled: IAB and IETF do not wish to be (cannot democratically be either) "representative of the served communities". The same as they did not want to tell us how to proceed. We are by our own. NTIACANN has a proposition, IUsers (symetric interuse networking users) need another one. Please read carefully RFC 6852: you have to differentiate between the standard proposition by authoritative sources "that agree to follow open and transparent processes, etc..." and the "5. Voluntary adoption. Standards are voluntarily adopted and success is determined by the market." "You can lead a donkey to water but you can't make it drink" We (IUsers) ask for too much change you do not understand. We will therefore try to help in implementing and documenting it. It will be slower, uncertain, more difficult, more complicate ... You have your certitudes and dollars, we have our ignorances and needs .... We thought you were interested in our network codevelopment, we understand that we only are interesting as consumers. jfc From nobody Thu Jun 12 03:55:46 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0E51B297C for ; Thu, 12 Jun 2014 03:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ES9w0kq7pujw for ; Thu, 12 Jun 2014 03:55:43 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9862E1A0340 for ; Thu, 12 Jun 2014 03:55:43 -0700 (PDT) Received: from pool-108-56-179-253.washdc.fios.verizon.net ([108.56.179.253] helo=[192.168.1.10]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1Wv2fV-000A4h-VX; Thu, 12 Jun 2014 10:55:42 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 108.56.179.253 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+7sC9Nyy5cq7R7gVhP7dCm Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: John Curran In-Reply-To: <53991572.3090705@abenaki.wabanaki.net> Date: Thu, 12 Jun 2014 06:55:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4888A5A6-CD76-4B68-8AD0-20CD1DFC0BFB@istaff.org> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <5398709F.8060007@abenaki.wabanaki.net> <53991572.3090705@abenaki.wabanaki.ne t> To: Eric Brunner-Williams X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/TXmx2B6MfmK-MA9QUOKWvFKD6Bw Cc: internetgovtech@iab.org, Pindar Wong Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 10:55:44 -0000 On Jun 11, 2014, at 10:50 PM, Eric Brunner-Williams = wrote: > Pindar, >=20 > I'm not a lawyer either, but my wife, who is, and is a government = lawyer, keeps muttering "jurisdiction." Good to know - she could be an excellent resource in this activity. > First, ICANN is not the only 501(c)(3) that has been delegated = regulatory authority by the legislative and executive branches over = certain functions generally reserved to agencies of the Executive Branch = ... Interesting assertion - specifically, that "ICANN ... has been delegated = regulatory authority". > The United States Government's real and/or intellectual property = interest is substantial; full divestiture will most likely take an Act = of Congress -- an Executive Order is unlikely to suffice in this = political climate. Indeterminate, but her paper on this topic should make for informative = reading. Thanks! /John Disclaimers: My views alone. From nobody Thu Jun 12 04:42:42 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28451B2858 for ; Thu, 12 Jun 2014 04:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOrr7vPAZygD for ; Thu, 12 Jun 2014 04:42:38 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F29C1B2854 for ; Thu, 12 Jun 2014 04:42:38 -0700 (PDT) Received: from pool-108-56-179-253.washdc.fios.verizon.net ([108.56.179.253] helo=[192.168.1.10]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1Wv3Ou-0003vi-Us; Thu, 12 Jun 2014 11:42:37 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 108.56.179.253 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/AKkE2B6RrtrBqkjar1yWt Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: John Curran In-Reply-To: <20140612085707.B7DB68B73A4@mail-04-pao.dyndns.com> Date: Thu, 12 Jun 2014 07:42:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <05921299-0B65-458B-AD75-AE22B84ED4DE@istaff.org> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <2963BB17-E425-46A9-A6CF-EE95C63B4626@istaff.org> <79BC0637-22AE-46ED-A70C-C57446FC6511@virtualized.org> <1810133C-040B- 4F9B-B16E-665442E56F8A@istaff.org> <20140612085707.B7DB68B73A4@mail-04-pao.dyndns.com> To: Jefsey X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/rARiH-rHwnZok0IOlVZMOrC1cMc Cc: internetgovtech@iab.org, David Conrad Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 11:42:40 -0000 On Jun 12, 2014, at 4:57 AM, Jefsey wrote: > I am sorry but, again, the only thing you can take for granted is a = total lack of trust. A most appropriate attitude given that we are discussing accountability=20= mechanisms (which are, by their nature, designed to provide feedback and=20= course correction in circumstances of low mutual trust) > ... Not the NTIA, not ICANN, not RIRs, not the IETF, not even the = Governments. This has been decided by the IAB: in removing themselves as = the ultimate referent of what is a "better internet" and stating that = voluntarily accepted standards are the norm. We all are to adapt. The = NTIA is trying. Interesting assertion above; I'm not certain that the IAB sees it that = way,=20 but even if so, that actually serves to emphasize the importance of my = point regarding the IETF role regarding general-purpose IANA registries. > Since Russ only intends to interoperate with the NTIA/ICANN process = and not with any other collective empowerment concordance process, = things are settled: IAB and IETF do not wish to be (cannot = democratically be either) "representative of the served communities".=20 I do not know what Russ intends (nor what that matters in this = discussion) but=20 will observe that there is a huge difference between the IETF claiming = to be=20 "representative of the served communities" versus the IETF noting that = its DNS=20 and IP protocols require coordinated unique identifiers and arranging = for there=20 to be a IANA registry for such (for those who wish to voluntarily follow = that=20 registry.) > Please read carefully RFC 6852: you have to differentiate between the = standard proposition by authoritative sources "that agree to follow open = and transparent processes, etc..." and the "5. Voluntary adoption. = Standards are voluntarily adopted and success is determined by the = market." Correct. The fact that the IETF generally seeks to have an IANA = registry for all=20 of its protocol parameters (both technical and general-purpose spaces) = doesn't=20 require anyone make use of that registry. However, there is great = wisdom in the IETF also recognizing (as it already _has_ in RFC 2860) that the = general-purpose=20 portion registries of DNS and IP addresses space need to have policy set = by a=20 larger, more representative community, and thus have already made policy = authority=20 delegations to ICANN and the RIRs for these spaces respectively. The = fact that such authority has been delegated to deal with "policy matters" does not = exempt=20 these entities from compliance with the technical specifications of the = IETF with=20 respect to the particular parameter space, including technical = reservations in=20 that space. > "You can lead a donkey to water but you can't make it drink" Correct. The donkey can drink from the IANA water hole (with all of the = other donkeys who choose to), or not; it can establish its own water hole with = other=20 interested donkeys collaboratively (or not); or it can die of thirst... = there=20 are apparently lots of choices available, Jefsey, if one is a donkey. To return to IANA registries, we are discussion in particular whether = the IETF=20 considers itself to have any responsibility for arranging via IANA for a = default=20 source of coordination for the general-purpose registry spaces defined = in IETF=20 protocol specifications. I guess one can imagine a world where the IETF = defines=20 a version of the IP or DNS protocols with general-purpose identifiers to = be=20 collaboratively assigned, and then decides _not_ to actually direct the = IANA=20 to provide a default source of coordination for this purpose, but that = would=20 definitely be unprecedented. =20 It seems more prudent to delegate that duty to organizations with = instructions=20 that they must conform to all relevant IETF technical specifications for = the=20 registry, that they respect the technically reserved assignments from = such=20 spaces, that they operate in an open and transparent manner, that they = assert and strive to truly represent the user community for that registry, that = they have periodic independent reviews to confirm their adherence to the = above, and=20 finally that they realize as much humanly possible that the IETF really = doesn't ever want to have to deal with a independent finding that such = organizations are=20 chronically not representative of the communities that they claim to = represent. (as such a finding would require either strong and timely corrective = action by the lagging organization or raise the possibility of re-delegation.) FYI, /John Disclaimer: My views alone. If you consider DNS and IP not be IETF = protocols, and therefore their parameters fields not to be IETF protocol parameters = (albeit mostly general-purpose rather than technical in nature), you can = probably save time and skip reading this and future postings by me... From nobody Thu Jun 12 05:07:55 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDA11B2865 for ; Thu, 12 Jun 2014 05:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGeEgSIR8NMf for ; Thu, 12 Jun 2014 05:07:45 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B00D81B2824 for ; Thu, 12 Jun 2014 05:07:44 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id n3so2845100wiv.2 for ; Thu, 12 Jun 2014 05:07:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=1YzU3V20oQHqW7ef/Ht8msalaRZrpo8zpeRu6+6GG0U=; b=qS6h1xvwEgeA8PDUU8KFvnsDSFT8zO2iDLseAsRR+R/hC8ZzMu2sdJfYACXaD8A7Vw U0kL5dAG+g2t8uIMfCTrMHBR5KmFM3SZbvR283RNfDkPxmxQ+9TB/6Q9mxpnCYK2okJK q+WonnF7VDVESSPNc9/dBSC+dlRKS6clU+iktGyw/ORJNWwFymbqzeGCtqvaYwN0P90p GYzXqECQD5xGGbfEqFzVYuKhx/tnOZLo7vc3Kf8QFlVegqtyE7MEIZJ6mTCTh33XpMBx dUm1odYUhi0MfRPpaIz1I+ctrBFfOo7tcS3bUBlplfzXoo7+qD2WosMJJnbZGb4yJ/U8 oS/w== MIME-Version: 1.0 X-Received: by 10.180.7.227 with SMTP id m3mr5705216wia.59.1402574863084; Thu, 12 Jun 2014 05:07:43 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.79.136 with HTTP; Thu, 12 Jun 2014 05:07:42 -0700 (PDT) In-Reply-To: <53991572.3090705@abenaki.wabanaki.net> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <5398709F.8060007@abenaki.wabanaki.net> <53991572.3090705@abenaki.wabanaki.net> Date: Thu, 12 Jun 2014 08:07:42 -0400 X-Google-Sender-Auth: OE7h4rvDE6fBpl1z37vtQNNHpAE Message-ID: From: Phillip Hallam-Baker To: Eric Brunner-Williams Content-Type: multipart/alternative; boundary=f46d044402087c38cf04fba268d9 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/cMPXhnJ42GIHpIp3i2s_iCbvip4 Cc: internetgovtech@iab.org, Pindar Wong Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 12:07:47 -0000 --f46d044402087c38cf04fba268d9 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 11, 2014 at 10:50 PM, Eric Brunner-Williams < ebw@abenaki.wabanaki.net> wrote: > Pindar, > > I'm not a lawyer either, but my wife, who is, and is a government lawyer, > keeps muttering "jurisdiction." > > First, ICANN is not the only 501(c)(3) that has been delegated regulatory > authority by the legislative and executive branches over certain functions > generally reserved to agencies of the Executive Branch (of the United > States Government, this form of delegated regulatory authority is found at > all levels of government, its called "privatization"). But make no mistake > that this delegation of authority to a private actor in no way means a > divestiture of the long-term authority over the property interest, it is a > delegation, not a divestiture. > > The United States Government's real and/or intellectual property interest > is substantial; full divestiture will most likely take an Act of Congress > -- an Executive Order is unlikely to suffice in this political climate. > Who is going to prosecute? Unless Congress wants to actually impeach the President over this, this is just hot air. The last President committed torture and no prosecutions followed. Who would have standing to sue? Under what imaginable circumstances could the US government recapture control if it tried? It is really not clear to me that IANA acts only under US government authority. Particularly when the management of non-US networks is concerned. Arguably the scope of the US government authority is and has always been limited to IANA and ICANN functions that affect US government networks. --f46d044402087c38cf04fba268d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Jun 11, 2014 at 10:50 PM, Eric Brunner-Williams <= ebw@abenaki.wabanaki.net> wrote:
=20 =20 =20
Pindar,

I'm not a lawyer either, but my wife, who is, and is a government lawyer, keeps muttering "jurisdiction."

First, ICANN is not the only 501(c)(3) that has been delegated regulatory authority by the legislative and executive branches over certain functions generally reserved to agencies of the Executive Branch (of the United States Government, this form of delegated regulatory authority is found at all levels of government, its called "privatization"). But make no mistak= e that this delegation of authority to a private actor in no way means a divestiture of the long-term authority over the property interest, it is a delegation, not a divestiture.

The United States Government's real and/or intellectual property interest is substantial; full divestiture will most likely take an Act of Congress -- an Executive Order is unlikely to suffice in this political climate.

W= ho is going to prosecute? Unless Congress wants to actually impeach the Pre= sident over this, this is just hot air.

The last P= resident committed torture and no prosecutions followed.=C2=A0

Who would have standing to sue? Under what imaginable c= ircumstances could the US government recapture control if it tried?

It is really not clear to me that IANA acts only under US= government authority. Particularly when the management of non-US networks = is concerned. Arguably the scope of the US government authority is and has = always been limited to IANA and ICANN functions that affect US government n= etworks.



--f46d044402087c38cf04fba268d9-- From nobody Thu Jun 12 05:15:28 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA28D1B2865 for ; Thu, 12 Jun 2014 05:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hcIr_RStZPJ for ; Thu, 12 Jun 2014 05:15:25 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A01731B2863 for ; Thu, 12 Jun 2014 05:15:25 -0700 (PDT) Received: from pool-108-56-179-253.washdc.fios.verizon.net ([108.56.179.253] helo=[192.168.1.10]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1Wv3ub-000NfZ-PY; Thu, 12 Jun 2014 12:15:21 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 108.56.179.253 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/UFh3sVJfjTVcYD7D0cOm/ Content-Type: multipart/alternative; boundary="Apple-Mail=_401B46AE-1B8D-4125-8ADB-D635279FF76F" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: John Curran In-Reply-To: Date: Thu, 12 Jun 2014 08:15:18 -0400 Message-Id: <4B4AC233-36A5-483E-9C30-DFFA8DF85247@istaff.org> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <5398709F.8060007@abenaki.wabanaki.net> <53991572.3090705@abenaki.wabanaki.ne t> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/P--UufVaePg40okz0FIcTZgmRaA Cc: Eric Brunner-Williams , internetgovtech@iab.org, Pindar Wong Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 12:15:27 -0000 --Apple-Mail=_401B46AE-1B8D-4125-8ADB-D635279FF76F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 12, 2014, at 8:07 AM, Phillip Hallam-Baker = wrote: > On Wed, Jun 11, 2014 at 10:50 PM, Eric Brunner-Williams = wrote: > Pindar, >=20 > I'm not a lawyer either, but my wife, who is, and is a government = lawyer, keeps muttering "jurisdiction." >=20 > First, ICANN is not the only 501(c)(3) that has been delegated = regulatory authority by the legislative and executive branches over = certain functions generally reserved to agencies of the Executive Branch = (of the United States Government, this form of delegated regulatory = authority is found at all levels of government, its called = "privatization"). But make no mistake that this delegation of authority = to a private actor in no way means a divestiture of the long-term = authority over the property interest, it is a delegation, not a = divestiture. >=20 > The United States Government's real and/or intellectual property = interest is substantial; full divestiture will most likely take an Act = of Congress -- an Executive Order is unlikely to suffice in this = political climate. >=20 > Who is going to prosecute? Unless Congress wants to actually impeach = the President over this, this is just hot air. >=20 > The last President committed torture and no prosecutions followed.=20 >=20 > Who would have standing to sue? Under what imaginable circumstances = could the US government recapture control if it tried? >=20 > It is really not clear to me that IANA acts only under US government = authority. Particularly when the management of non-US networks is = concerned. Arguably the scope of the US government authority is and has = always been limited to IANA and ICANN functions that affect US = government networks. Eric's distinction is also moot if the community comes up with a IANA = stewardship transition=20 plan and the USG collectively (i.e. the administration and congressional = committee with the oversight) agree that it is the prudent path forward as result of the = GAO study of same. FYI, /John Disclaimer: My views alone. --Apple-Mail=_401B46AE-1B8D-4125-8ADB-D635279FF76F Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii On Jun 12, 2014, at 8:07 AM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:

On Wed, Jun 11, 2014 at 10:50 PM, Eric Brunner-Williams <ebw@abenaki.wabanaki.net> wrote:
Pindar,

I'm not a lawyer either, but my wife, who is, and is a government lawyer, keeps muttering "jurisdiction."

First, ICANN is not the only 501(c)(3) that has been delegated regulatory authority by the legislative and executive branches over certain functions generally reserved to agencies of the Executive Branch (of the United States Government, this form of delegated regulatory authority is found at all levels of government, its called "privatization"). But make no mistake that this delegation of authority to a private actor in no way means a divestiture of the long-term authority over the property interest, it is a delegation, not a divestiture.

The United States Government's real and/or intellectual property interest is substantial; full divestiture will most likely take an Act of Congress -- an Executive Order is unlikely to suffice in this political climate.

Who is going to prosecute? Unless Congress wants to actually impeach the President over this, this is just hot air.

The last President committed torture and no prosecutions followed. 

Who would have standing to sue? Under what imaginable circumstances could the US government recapture control if it tried?

It is really not clear to me that IANA acts only under US government authority. Particularly when the management of non-US networks is concerned. Arguably the scope of the US government authority is and has always been limited to IANA and ICANN functions that affect US government networks.

Eric's distinction is also moot if the community comes up with a IANA stewardship transition 
plan and the USG collectively (i.e. the administration and congressional committee with the
oversight) agree that it is the prudent path forward as result of the GAO study of same.

FYI,
/John

Disclaimer: My views alone.




--Apple-Mail=_401B46AE-1B8D-4125-8ADB-D635279FF76F-- From nobody Thu Jun 12 10:19:53 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD821B2AAE for ; Thu, 12 Jun 2014 10:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.331 X-Spam-Level: X-Spam-Status: No, score=0.331 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwHwARBnCJLM for ; Thu, 12 Jun 2014 10:19:44 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1A6C1B2AA3 for ; Thu, 12 Jun 2014 10:19:40 -0700 (PDT) Received: from 231.74.14.81.rev.sfr.net ([81.14.74.231]:31237 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1Wv8f2-0002sd-Tn; Thu, 12 Jun 2014 10:19:39 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 12 Jun 2014 19:19:12 +0200 To: John Curran From: Jefsey In-Reply-To: <05921299-0B65-458B-AD75-AE22B84ED4DE@istaff.org> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <2963BB17-E425-46A9-A6CF-EE95C63B4626@istaff.org> <79BC0637-22AE-46ED-A70C-C57446FC6511@virtualized.org> <1810133C-040B-4F9B-B16E-665442E56F8A@istaff.org> <20140612085707.B7DB68B73A4@mail-04-pao.dyndns.com> <05921299-0B65-458B-AD75-AE22B84ED4DE@istaff.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: jefsey+jefsey.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/KUEiAMiHIAfHnANUjGN13y_5F70 Cc: internetgovtech@iab.org, David Conrad Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 17:19:45 -0000 At 13:42 12/06/2014, John Curran wrote: > > Please read carefully RFC 6852: you have to differentiate between > the standard proposition by authoritative sources "that agree to > follow open and transparent processes, etc..." and the "5. > Voluntary adoption. Standards are voluntarily adopted and success > is determined by the market." > >However, there is great wisdom in the >IETF also recognizing (as it already _has_ in RFC 2860) that the >general-purpose >portion registries of DNS and IP addresses space need to have policy set by a >larger, more representative community, and thus have already made >policy authority >delegations to ICANN and the RIRs for these spaces respectively. I would be interested if you could quote the language for this, in an RFC - the intent of which "is exclusively to define the technical work to be carried out by the Internet Assigned Numbers Authority on behalf of the Internet Engineering Task Force and the Internet Research Task Force." - which states "4.3. Two particular assigned spaces present policy issues in addition to the technical considerations specified by the IETF: the assignment of domain names, and the assignment of IP address blocks. These policy issues are outside the scope of this MOU." >The fact that >such authority has been delegated to deal with "policy matters" does >not exempt >these entities from compliance with the technical specifications of >the IETF with >respect to the particular parameter space, including technical >reservations in >that space. > > > "You can lead a donkey to water but you can't make it drink" > >Correct. The donkey can drink from the IANA water hole (with all of the other >donkeys who choose to), or not; it can establish its own water hole >with other >interested donkeys collaboratively (or not); or it can die of thirst... there >are apparently lots of choices available, Jefsey, if one is a donkey. > >To return to IANA registries, we are discussion in particular >whether the IETF >considers itself to have any responsibility for arranging via IANA >for a default >source of coordination for the general-purpose registry spaces >defined in IETF >protocol specifications. I guess one can imagine a world where the >IETF defines >a version of the IP or DNS protocols with general-purpose identifiers to be >collaboratively assigned, and then decides _not_ to actually direct the IANA >to provide a default source of coordination for this purpose, but that would >definitely be unprecedented. You do not need to imagine it. This IS the real world. Even if it is not the way you currently read it. The job of IETF is to design the donkey. The role of the IAB is to provide ultimate guidance on the water it can drink. Not to hold a politically commercial monopoly on any water. IAB in RFC 6852 has removed itself from this role. Russ seems (may be I did not understood him) to have only kept it for the NTIACANN: because the NTIA has requested a single proposition to the sole ICANN. This raises the problem of the IETF Trust copyrights and of its sole property on derivative works. Are TCP/IP and RFCs eventually USG copyrighted. Will the USG sue those who would use them with non-IANA parameters, specially in the RFC 2860 section 4.3. area? This is exactly the BNP current case, TPP, TAFTA issues, this is the whole "ingle authoritative root" saga: is the international life an inter-sovereign Excutive polylog at State level, or is it become an US law and order unique jurisidiction, in our case, managed by ICANN/RIR privatized agencies. This has a certain importance since the Internet operates at the citizens' digitality level (people centered information society). Is the NTIA transition a move toward global digital stability, or a "digital war on people" declaration? If Internet access is an human right, I do not want to pay ICANN for a name and you for an IP. This is as simple as that: common goods are not goods for US sales. Even transparent and accountable sales. This is why it is also quite complex and dangerous for all. Cheers. jfc From nobody Thu Jun 12 10:49:07 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E83D1A01C0 for ; Thu, 12 Jun 2014 10:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNXmUVcYpmnC for ; Thu, 12 Jun 2014 10:49:04 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A82A1A01B7 for ; Thu, 12 Jun 2014 10:49:03 -0700 (PDT) Received: from pool-108-56-179-253.washdc.fios.verizon.net ([108.56.179.253] helo=[192.168.1.10]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1Wv97X-000JCT-4Y; Thu, 12 Jun 2014 17:49:03 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 108.56.179.253 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/sSC/Kc83yAxqrzRVPeDU6 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: John Curran In-Reply-To: <20140612171952.3C7C71B2AB0@ietfa.amsl.com> Date: Thu, 12 Jun 2014 13:49:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6B3C7C0E-073B-4071-AEC1-C09E788FE239@istaff.org> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <2963BB17-E425-46A9-A6CF-EE95C63B4626@istaff.org> <79BC0637-22AE-46ED-A70C-C57446FC6511@virtualized.org> <1810133C-040B- 4F9B-B16E-665442E56F8A@istaff.org> <20140612085707.B7DB68B73A4@mail-04-pao.dyndns.com> <05921299-0B65-458B-AD75-AE22B84ED4DE@istaff.org> <20140612171952.3C7C71B2AB0@ietfa.amsl.com> To: Jefsey X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/WS2siEItRQx_tXN4BVvZWS45Vgw Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 17:49:05 -0000 On Jun 12, 2014, at 1:19 PM, Jefsey wrote: > I would be interested if you could quote the language for this, in an = RFC > - the intent of which "is exclusively to define the technical work to = be carried out by the Internet Assigned Numbers Authority on behalf of = the Internet Engineering Task Force and the Internet Research Task = Force." > - which states "4.3. Two particular assigned spaces present policy = issues in addition to the technical considerations specified by the = IETF: the assignment of domain names, and the assignment of IP address = blocks. These policy issues are outside the scope of this MOU." Luckily, you've already quoted the appropriate text, but apparently did = not read it. Section 4.1 says that the IANA will assign and register = Internet=20 protocol parameters per technical considerations specified by the IETF;=20= section 4.3 notes that two particular assigned spaces present "policy = issues" in addition to the technical considerations, and places those "policy = issues" outside the scope of the MOU. It goes on further to note that ICANN = needs to take care not to make conflicts with technical reservations within those = same=20 assigned spaces. i.e. The RFC 2860 MOU places the "policy issues" out of scope for the = two=20 problematic general-purpose registries (DNS and IP addresses space), = which is what I said -=20 "However, there is great wisdom in the IETF also recognizing (as it = already=20 _has_ in RFC 2860) that the general-purpose portion registries of DNS = and=20 IP addresses space need to have policy set by a larger, more = representative=20 community, " If you are curious about the second portion of my statement ("and thus = have=20 already made policy authority delegations to ICANN and the RIRs for = these=20 spaces respectively"), you can find clear reference with respect the = Internet=20 Numbers Registry in RFC 7020 and RFC 7249. =20 Thanks! /John Disclaimer: My views alone. From nobody Thu Jun 12 22:40:35 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302DA1B28DA for ; Thu, 12 Jun 2014 22:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuxNqYD_9o8w for ; Thu, 12 Jun 2014 22:40:30 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8645A1B28E0 for ; Thu, 12 Jun 2014 22:40:30 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id t60so2278678wes.28 for ; Thu, 12 Jun 2014 22:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+KcghA85FLzU6/7zN+F2UYCYGOpsvcD68XUi0ZUmryQ=; b=MBpbGjQUZ7arIalig9qBHFrN3Nn7G8EewQiJgDflV0NJ18tN5aUVnt0FCVpSt2CE0B n652FspVoMnarSns3+SNhdswAVPoxCNMdDanJkdj35tw/PIAeRgiviXniR2Cd0HJlcjY R5+U0w/tVOy8shDQpgmwRVqoMuOh0bN70rD1JP861h3aySuG39E3GbbiIwWdRm5U5Gyj 4j0P0fCDo2vlk0VP2MkCRnDMnXYDesBHbPulhFyk/z9+8bMXiQehz1o/LoFrUSGi3F94 hcxEruRNsdh4pWd1AaSfRG/C7VjrJIOYLpEBekYm6PqzvdVIuKyuvuiJQNyz4HzON8BE Pd0g== MIME-Version: 1.0 X-Received: by 10.194.186.178 with SMTP id fl18mr626754wjc.83.1402638027802; Thu, 12 Jun 2014 22:40:27 -0700 (PDT) Received: by 10.194.92.3 with HTTP; Thu, 12 Jun 2014 22:40:27 -0700 (PDT) In-Reply-To: <53995121.4000507@dcrocker.net> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <20140611130013.007F71A00AA@ietfa.amsl.com> <53995121.4000507@dcrocker.net> Date: Fri, 13 Jun 2014 13:40:27 +0800 Message-ID: From: Pindar Wong To: dcrocker@bbiw.net Content-Type: multipart/alternative; boundary=047d7bb04dd2654f2d04fbb11d4f Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/SucfLVP8mHqouyG0E4vTdDYG818 Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 05:40:33 -0000 --047d7bb04dd2654f2d04fbb11d4f Content-Type: text/plain; charset=UTF-8 On Thu, Jun 12, 2014 at 3:05 PM, Dave Crocker wrote: > [snip] > > While these ought to give us pause from overreacting about how an > organization is managed, there's always a danger that knowing about the > potential of overreacting might cause us to underreact... > I fully agree with you on that score Dave. p. > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > --047d7bb04dd2654f2d04fbb11d4f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Jun 12, 2014 at 3:05 PM, Dave Crocker <= ;dhc@dcrocker.net= > wrote:
[snip]
=C2=A0
While these ought to give us pause from overreacting about how an
organization is managed, there's always a danger that knowing about the=
potential of overreacting might cause us to underreact...

I fully agree with you on that score Dave.
p.


=C2=A0

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

--047d7bb04dd2654f2d04fbb11d4f-- From nobody Thu Jun 12 22:59:57 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAE181A0361 for ; Thu, 12 Jun 2014 22:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F_b9CfEGFUnI for ; Thu, 12 Jun 2014 22:59:53 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E020A1B28CA for ; Thu, 12 Jun 2014 22:59:52 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id u56so2272744wes.36 for ; Thu, 12 Jun 2014 22:59:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+C8BLpggBcZyk283R/SrepFaHOvNZjYW5ZUHMZswDH4=; b=EDkzaY2RRUETkU8sws8gudYxIwtAUwgmeiEWTPyqGYWZKnOUt1d8TZHIPAujr7KTpq +mk/eJj0zcPyGZr1WWrRYYX7P3b2lD91XYLZ1aSkkn7j+QX8zSMJR9ezb3oOmfZi80+D jm3UUmLl3gC6yySbF/cIwuImgiAq4+kHdAnBlxlGDsMC6tbkatMHU+j/T4G+2CkhbdhL AMoxlNpNgQeutFRVkt84JBKmJ5h7GTHY+w+Zqirs4xqAdJHmkTxbsTIw27/eLV3m6HRw Na66ksyN/6BINCIwdGTqLNCSLI6e8CPD2zRLMYqzptPgtbdU7aIHpPhXZRgtIdMtC+VL rCMw== MIME-Version: 1.0 X-Received: by 10.194.186.178 with SMTP id fl18mr746156wjc.83.1402639188290; Thu, 12 Jun 2014 22:59:48 -0700 (PDT) Received: by 10.194.92.3 with HTTP; Thu, 12 Jun 2014 22:59:48 -0700 (PDT) In-Reply-To: <4888A5A6-CD76-4B68-8AD0-20CD1DFC0BFB@istaff.org> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <5398709F.8060007@abenaki.wabanaki.net> <53991572.3090705@abenaki.wabanaki.net> <4888A5A6-CD76-4B68-8AD0-20CD1DFC0BFB@istaff.org> Date: Fri, 13 Jun 2014 13:59:48 +0800 Message-ID: From: Pindar Wong To: John Curran Content-Type: multipart/alternative; boundary=047d7bb04dd290f2ac04fbb16264 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/dIE0sPUFL6gBYpU4JQ8sOPcWA5k Cc: Eric Brunner-Williams , internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 05:59:55 -0000 --047d7bb04dd290f2ac04fbb16264 Content-Type: text/plain; charset=UTF-8 On Thu, Jun 12, 2014 at 6:55 PM, John Curran wrote: > On Jun 11, 2014, at 10:50 PM, Eric Brunner-Williams < > ebw@abenaki.wabanaki.net> wrote: > > > Pindar, > > > > I'm not a lawyer either, but my wife, who is, and is a government > lawyer, keeps muttering "jurisdiction." > > Good to know - she could be an excellent resource in this activity. > Agreed. And it's not just 'jurisdiction', but also issues of 'standing'. Mutter mutter mutter* p. *Note: Some of the work by Joanna Kulesza might be of interest for those who like these kinds of puzzles > First, ICANN is not the only 501(c)(3) that has been delegated regulatory > authority by the legislative and executive branches over certain functions > generally reserved to agencies of the Executive Branch ... > > Interesting assertion - specifically, that "ICANN ... has been delegated > regulatory authority". > > > The United States Government's real and/or intellectual property > interest is substantial; full divestiture will most likely take an Act of > Congress -- an Executive Order is unlikely to suffice in this political > climate. > > Indeterminate, but her paper on this topic should make for informative > reading. > > Thanks! > /John > > Disclaimers: My views alone. > > > --047d7bb04dd290f2ac04fbb16264 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Jun 12, 2014 at 6:55 PM, John Curran <= jcurran@istaff.org<= /a>> wrote:
On Jun 11, 2014, at = 10:50 PM, Eric Brunner-Williams <ebw@abenaki.wabanaki.net> wrote:

> Pindar,
>
> I'm not a lawyer either, but my wife, who is, and is a government = lawyer, keeps muttering "jurisdiction."

Good to know - she could be an excellent resource in this activity.

Agreed.

And it's n= ot just 'jurisdiction',=C2=A0 but also issues of 'standing'= .

Mutter mutter mutter*

p.

*Note: Som= e of the work by Joanna Kulesza might be of interest for those who like the= se kinds of puzzles

> First, ICANN is not the only 501(c)(3) that has been delegated regulat= ory authority by the legislative and executive branches over certain functi= ons generally reserved to agencies of the Executive Branch ...

Interesting assertion - specifically, that "ICANN ... has been delegat= ed regulatory authority".

> The United States Government's real and/or intellectual property i= nterest is substantial; full divestiture will most likely take an Act of Co= ngress -- an Executive Order is unlikely to suffice in this political clima= te.

Indeterminate, but her paper on this topic should make for informativ= e reading.

Thanks!
/John

Disclaimers: My views alone.



--047d7bb04dd290f2ac04fbb16264-- From nobody Thu Jun 12 23:11:20 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360461A036C for ; Thu, 12 Jun 2014 23:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-dQlM1PngFF for ; Thu, 12 Jun 2014 23:11:10 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B12E41A0361 for ; Thu, 12 Jun 2014 23:11:09 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id cc10so1757650wib.1 for ; Thu, 12 Jun 2014 23:11:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vOlxIWZoNt9ovrfzDA8iNS/kECQ9heNXFwBpavQSevk=; b=qhAcGz1Do6nL5iOe5tihlNU8QPMKPywponm6GtHCrVKomk/CJ0E4lLNnZ0g0vVuCH/ ALOEtscksoReNXKj2vgvGipuec6vQRk6GBQxH00737u5M3TIWlB0da8C9uSvVfBRm0aA ZEOErFH4mRaOfm8mjsF49svqd+Yq/7wqZ0HQuXtIqQQ3rKdBfjtQRPybqhnuFA5jCYLU N90bL+sfdXhdvnaY++OQnDz39xAGAy/E09+Gl47ALTc5hHESU3SL+w4vz9RJUC5Iq+w/ rLdvlGG5n1663zRLtHF5WCcNJWMENTw2wtXoGciXCR7dPGKk8fkV0xzM6k7ojdT4TxgZ qZNw== MIME-Version: 1.0 X-Received: by 10.180.149.240 with SMTP id ud16mr1583514wib.3.1402639868036; Thu, 12 Jun 2014 23:11:08 -0700 (PDT) Received: by 10.194.92.3 with HTTP; Thu, 12 Jun 2014 23:11:07 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20140611225603.0b8f99c8@resistor.net> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <5398709F.8060007@abenaki.wabanaki.net> <53991572.3090705@abenaki.wabanaki.net> <6.2.5.6.2.20140611225603.0b8f99c8@resistor.net> Date: Fri, 13 Jun 2014 14:11:07 +0800 Message-ID: From: Pindar Wong To: S Moonesamy Content-Type: multipart/alternative; boundary=001a11c260e2150b0404fbb18bb6 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/gwH7IroS27WY2Oitwn-MlUYbjGY Cc: Eric Brunner-Williams , internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 06:11:17 -0000 --001a11c260e2150b0404fbb18bb6 Content-Type: text/plain; charset=UTF-8 On Thu, Jun 12, 2014 at 2:39 PM, S Moonesamy wrote: > Hi Eric, > > At 19:50 11-06-2014, Eric Brunner-Williams wrote: > >> The United States Government's real and/or intellectual property interest >> is substantial; full divestiture will most likely take an Act of Congress >> -- an Executive Order is unlikely to suffice in this political climate. >> > > I am commenting about the IETF Protocol Parameter Registries. According > to the IETF, and a previous IAB, the copyright on that is to be held by the > IETF Trust. > Please keep in mind that, as far as I'm aware, copyright laws (and others related to 'intellectual property') have a concept of 'territoriality' which doesn't exactly help, especially when the objective is to actually legally share digital works globally. Also keep in view the 'sui generis database' rights I may have mentioned earlier. p. > > Regards, > S. Moonesamy > --001a11c260e2150b0404fbb18bb6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Jun 12, 2014 at 2:39 PM, S Moonesamy <= sm+ietf@elandsys.= com> wrote:
Hi Eric,

At 19:50 11-06-2014, Eric Brunner-Williams wrote:
The United States Government's real and/or intellectual property intere= st is substantial; full divestiture will most likely take an Act of Congres= s -- an Executive Order is unlikely to suffice in this political climate.

I am commenting about the IETF Protocol Parameter Registries. =C2=A0Accordi= ng to the IETF, and a previous IAB, the copyright on that is to be held by = the IETF Trust.

Please keep in mind tha= t, as far as I'm aware, copyright=C2=A0 laws (and others related to = 9;intellectual property') have a concept of 'territoriality' wh= ich doesn't exactly help, especially when the objective is to actually = legally share digital works globally.=C2=A0 Also keep in view the 'sui = generis database' rights I may have mentioned earlier.

p.

=C2=A0

Regards,
S. Moonesamy =C2=A0

--001a11c260e2150b0404fbb18bb6-- From nobody Fri Jun 13 05:04:10 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659CD1B2817 for ; Fri, 13 Jun 2014 05:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnrFoS-jTGtv for ; Fri, 13 Jun 2014 05:04:07 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59F5A1A04CA for ; Fri, 13 Jun 2014 05:04:07 -0700 (PDT) Received: from 231.74.14.81.rev.sfr.net ([81.14.74.231]:42546 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1WvQDG-0006a8-Pk; Fri, 13 Jun 2014 05:04:07 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 13 Jun 2014 11:47:32 +0200 To: John Curran From: Jefsey In-Reply-To: <6B3C7C0E-073B-4071-AEC1-C09E788FE239@istaff.org> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <2963BB17-E425-46A9-A6CF-EE95C63B4626@istaff.org> <79BC0637-22AE-46ED-A70C-C57446FC6511@virtualized.org> <1810133C-040B-4F9B-B16E-665442E56F8A@istaff.org> <20140612085707.B7DB68B73A4@mail-04-pao.dyndns.com> <05921299-0B65-458B-AD75-AE22B84ED4DE@istaff.org> <20140612171952.3C7C71B2AB0@ietfa.amsl.com> <6B3C7C0E-073B-4071-AEC1-C09E788FE239@istaff.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: jefsey+jefsey.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/0EjS-tAIajNJCp9YvuM1ZlXvQ7E Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 12:04:08 -0000 At 19:49 12/06/2014, John Curran wrote: >On Jun 12, 2014, at 1:19 PM, Jefsey wrote: > > > I would be interested if you could quote the language for this, in an RFC > > - the intent of which "is exclusively to define the technical > work to be carried out by the Internet Assigned Numbers Authority > on behalf of the Internet Engineering Task Force and the Internet > Research Task Force." > > - which states "4.3. Two particular assigned spaces present > policy issues in addition to the technical considerations specified > by the IETF: the assignment of domain names, and the assignment of > IP address blocks. These policy issues are outside the scope of this MOU." > >Luckily, you've already quoted the appropriate text, but apparently did not >read it. Section 4.1 says that the IANA will assign and register Internet >protocol parameters per technical considerations specified by the IETF; >section 4.3 notes that two particular assigned spaces present "policy issues" >in addition to the technical considerations, and places those "policy issues" >outside the scope of the MOU. In adding even further that, in case of disagreement between the IANA and IETF, the IAB is the referent (what RFC 6852 disassemble but not reassemble). >It goes on further to note that ICANN needs to take care not to make >conflicts with technical reservations within those same assigned spaces. That is a pure inventive artistic vision. "You do not have to create technical conflicts within the MOU framework" would means "you have the global legitimacy to rule the world". Sorry but I feel that the WCIT has shown that the world's majority disagree. This majority has since enlarged if I read the European Statements and reactions to TPP and AFTA. >i.e. The RFC 2860 MOU places the "policy issues" out of scope for the two >problematic general-purpose registries (DNS and IP addresses space), which >is what I said - > >"However, there is great wisdom in the IETF also recognizing (as it already >_has_ in RFC 2860) that the general-purpose portion registries of DNS and >IP addresses space need to have policy set by a larger, more representative >community, " > >If you are curious about the second portion of my statement ("and thus have >already made policy authority delegations to ICANN and the RIRs for these >spaces respectively"), you can find clear reference with respect the Internet >Numbers Registry in RFC 7020 and RFC 7249. John, these self RFC quotations are of no use in this case. You have to accept that there are two strata that have to be made to work together on the same hardware: - software: i.e. the IETF/SDOs designed systems, which to some extent make a local (within the systems) law. - brainware: i.e. the people multitude's use of these and many other systems IETF/SDOs MAY advise and have to design software for. There the people's laws and common laws specifty the software. You do not have to take side if you want a stable coordinated system. If you take side you will necessarily enter in conflicts. For several years since Adam, brainware has ultimately won and obtained innovative software adapted to the hardware reality's capacities. You can rigidly claim that your for information RFCs are to be considered as unique, life you will only answer you: why did you not then made them universal? For three centuries, money and industrial revolution have progressively replaced philia by competition as a societal motivation, with an interesting and typical Beaumarchais' move to create IP rights to subsidize La Fayette. Several have positively opposed that change (in academic and political circles and Stallman in our area) and reintroduced adapted forms of philia (FLOSS, what some calls the internet democracy). The US are born during the XVIIIth change and have an hybrid culture: today they are at a fork and have to choose. Money/competition or people/philia. Or seomething else? The NTIANA move is a typical sample of this choice. MSism is a sustainable coopetitive attempt to replace a philia based democracy in a global complex market. You obvioiusly are at the center of this issue as being ARIN. The danger for your own evaluation is to confuse this technical occasional centricity of yours with the centricity of a world which is indefinitly polycentric by nature, and by IETF construction (look at LISP, at DNS Classes). As you word it yourself you are an example of solution in a multiversal system. The worry is the lack of "after-sale" support by IAB: they seems to only be interested in helping their IANA example solution, not in helping the customizing diversity of people's universes (in this case, the VGNs). The danger is that we wind up with conflicting rather than compatible universes. This is fragmentation by rigidity. jfc From nobody Fri Jun 13 05:04:11 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E7A1B279B for ; Fri, 13 Jun 2014 05:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.224 X-Spam-Level: *** X-Spam-Status: No, score=3.224 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_03_06=1.592, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUxePgrNKASZ for ; Fri, 13 Jun 2014 05:04:07 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38CD11A024D for ; Fri, 13 Jun 2014 05:04:07 -0700 (PDT) Received: from 231.74.14.81.rev.sfr.net ([81.14.74.231]:42546 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1WvQDF-0006a8-Ab; Fri, 13 Jun 2014 05:04:05 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 13 Jun 2014 10:28:51 +0200 To: John Curran , Phillip Hallam-Baker From: Jefsey In-Reply-To: <4B4AC233-36A5-483E-9C30-DFFA8DF85247@istaff.org> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <5398709F.8060007@abenaki.wabanaki.net> <53991572.3090705@abenaki.wabanaki.ne t> <4B4AC233-36A5-483E-9C30-DFFA8DF85247@istaff.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_124279023==.ALT" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: jefsey+jefsey.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/HLJDP8nn9rjAb0FQgiAD8dJrJTY Cc: Eric Brunner-Williams , internetgovtech@iab.org, Pindar Wong Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 12:04:08 -0000 --=====================_124279023==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 14:15 12/06/2014, John Curran wrote: >On Jun 12, 2014, at 8:07 AM, Phillip Hallam-Baker ><phill@hallambaker.com> wrote: > >>On Wed, Jun 11, 2014 at 10:50 PM, Eric Brunner-Williams >><ebw@abenaki.wabanaki.net> wrote: >>Who is going to prosecute? Unless Congress wants to actually >>impeach the President over this, this is just hot air. >> >>The last President committed torture and no prosecutions followed. >> >>Who would have standing to sue? Under what imaginable circumstances >>could the US government recapture control if it tried? >> >>It is really not clear to me that IANA acts only under US >>government authority. Particularly when the management of non-US >>networks is concerned. Arguably the scope of the US government >>authority is and has always been limited to IANA and ICANN >>functions that affect US government networks. > >Eric's distinction is also moot if the community comes up with a >IANA stewardship transition >plan and the USG collectively (i.e. the administration and >congressional committee with the >oversight) agree that it is the prudent path forward as result of >the GAO study of same. I am sorry, folks, but could you translate all of this in a non-US centric point of view? What is the "community": is it an oligarchy? a corporation? a Government? a people? a multitude? jfc --=====================_124279023==.ALT Content-Type: text/html; charset="us-ascii" At 14:15 12/06/2014, John Curran wrote:
On Jun 12, 2014, at 8:07 AM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:

On Wed, Jun 11, 2014 at 10:50 PM, Eric Brunner-Williams <ebw@abenaki.wabanaki.net > wrote:
Who is going to prosecute? Unless Congress wants to actually impeach the President over this, this is just hot air.

The last President committed torture and no prosecutions followed.

Who would have standing to sue? Under what imaginable circumstances could the US government recapture control if it tried?

It is really not clear to me that IANA acts only under US government authority. Particularly when the management of non-US networks is concerned. Arguably the scope of the US government authority is and has always been limited to IANA and ICANN functions that affect US government networks.

Eric's distinction is also moot if the community comes up with a IANA stewardship transition
plan and the USG collectively (i.e. the administration and congressional committee with the
oversight) agree that it is the prudent path forward as result of the GAO study of same.

I am sorry, folks, but could you translate all of this in a non-US centric point of view? What is the "community": is it an oligarchy? a corporation? a Government? a people? a multitude?
jfc --=====================_124279023==.ALT-- From nobody Fri Jun 13 06:33:49 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F541B2902 for ; Fri, 13 Jun 2014 06:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.276 X-Spam-Level: X-Spam-Status: No, score=-1.276 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UHus1Qw2Ckt for ; Fri, 13 Jun 2014 06:33:45 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 510141B2880 for ; Fri, 13 Jun 2014 06:33:45 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id y10so2765819wgg.20 for ; Fri, 13 Jun 2014 06:33:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=H+bH5QWf+/wW1M9I3Bl3jSbBshQcdHIrvpMOb02xVvs=; b=U4n87j1TAvgITocaQYaaL4U1nsvwUP/K7ZcKkjFqiaxVvXCia+njjO5Ov3UqFgRPJf tnafAFy5JIVnlFGNSskcaHnTT1tpwnB1kMswD5wZ8f+q/jV8QOp8hSQLIsH2S5iCV0Af lN4QA+yPowQhItx5jrPynhsBeD6e+Q61ocGSQuA/lTm7bI/kedDBi5eDlbWNVoT98e/x vGU4G0BPNE/pF0UUfJqW7fe6JZbIxhG0oSwkDNHMLFvlPUK2bTlNXZh3SJFm432v6/G1 aDCm8LLTO/5Q6W9kfStBEN9E8vtZpdPa3hRlDg08QN8ns61MR4aoHD2nOEMkgEQgSIIc 2+nA== MIME-Version: 1.0 X-Received: by 10.180.207.9 with SMTP id ls9mr4916274wic.32.1402666423736; Fri, 13 Jun 2014 06:33:43 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.79.136 with HTTP; Fri, 13 Jun 2014 06:33:43 -0700 (PDT) In-Reply-To: <0LhgAT-1WQkDR1bo9-00nSOw@mx.perfora.net> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <5398709F.8060007@abenaki.wabanaki.net> <4B4AC233-36A5-483E-9C30-DFFA8DF85247@istaff.org> <0LhgAT-1WQkDR1bo9-00nSOw@mx.perfora.net> Date: Fri, 13 Jun 2014 09:33:43 -0400 X-Google-Sender-Auth: 6aVKK2nd8rjpv3aTf7i_m5aw4Sw Message-ID: From: Phillip Hallam-Baker To: Jefsey Content-Type: multipart/alternative; boundary=001a11c3cdc0ece05904fbb7b906 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/YAvdfqodv-Qp0X97W9MUPjau67E Cc: Pindar Wong , John Curran , Eric Brunner-Williams , internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 13:33:46 -0000 --001a11c3cdc0ece05904fbb7b906 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 13, 2014 at 4:28 AM, Jefsey wrote: > > I am sorry, folks, but could you translate all of this in a non-US centric > point of view? What is the "community": is it an oligarchy? a corporation? > a Government? a people? a multitude? > jfc > This is a case where US centrism is necessary since the choices on offer are 1) Zero governments involved 2) Only the US government involved 3) All governments involved And within 2 there is the military faction that wants the control to be exercised for ends decided by the generals and there is the state department faction that regards them as posing a greater risk than the threats they purport to defend against. Contrary to media reports, the Arab spring was not the result of Facebook and Twitter. The primary cause is actually climate change, the harvests have failed several years in a row, food prices are up. The main technology cause was actually the cell phone camera and its ability to turn any event into a 'Rodney King' moment. But the Obama administration has certainly used the Internet to influence the outcome in the Arab spring. A few years earlier, Congress voted $100 million a year in information engagement operations against Iran. That technology was put to use in the Arab Spring. But talking about the US government as if it is of one mind is ridiculous. The NSA does not have the same agenda as the rest of the Pentagon and certainly not the same as State. In 1953 the CIA discovered that it could use the technology used to decipher Enigma to engineer coups in pretty much any country where they found a foothold. In the mid 1970s they lost that capability due to the rise of microcomputers and electronic ciphers. And now a large part of that establishment thinks that the Internet is the replacement, the spearpoint of a softpower strategy. Those at any rate are the motivations behind the players. The US has diverse motives but it will not under any circumstances allow Russia or China to gain control of the Internet. So there is no circumstance under which (3) will happen. And that is all 'multistakeholder' means. So the choice is between (1) or (2). Brazil insists that it be (1) because they remember that they were one of the targets of the coups organized by the NSA/CIA and they have certain scores to settle. But at the end of the day they realize that Putin and Putinism is the immediate threat. --001a11c3cdc0ece05904fbb7b906 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jun 13, 2014 at 4:28 AM, Jefsey <jefsey@jefsey.com> wrot= e:

I am sorry, folks, but could you translate all of this in a non-US centric point of view? What is the "community": is it an oligarchy? a corporation? a Government? a people? a multitude?
jfc

This is a case where US centrism is necessary since the choic= es on offer are

1) Zero governments involved
2) Only the US= government involved
3) All governments inv= olved

= And within 2 there is the military faction that wants the control to be exe= rcised for ends decided by the generals and there is the state department f= action that regards them as posing a greater risk than the threats they pur= port to defend against.

Contrary to= media reports, the Arab spring was not the result of Facebook and Twitter.= The primary cause is actually climate change, the harvests have failed sev= eral years in a row, food prices are up. The main technology cause was actu= ally the cell phone camera and its ability to turn any event into a 'Ro= dney King' moment.=C2=A0

But the Oba= ma administration has certainly used the Internet to influence the outcome = in the Arab spring. A few years earlier, Congress voted $100 million a year= in information engagement operations against Iran. That technology was put= to use in the Arab Spring.=C2=A0


<= div class=3D"gmail_extra">But talking about the US government as if it is o= f one mind is ridiculous. The NSA does not have the same agenda as the rest= of the Pentagon and certainly not the same as State.

In 1953 the= CIA discovered that it could use the technology used to decipher Enigma to= engineer coups in pretty much any country where they found a foothold. In = the mid 1970s they lost that capability due to the rise of microcomputers a= nd electronic ciphers. And now a large part of that establishment thinks th= at the Internet is the replacement, the spearpoint of a softpower strategy.=


<= div class=3D"gmail_extra">Those at any rate are the motivations behind the = players. The US has diverse motives but it will not under any circumstances= allow Russia or China to gain control of the Internet. So there is no circ= umstance under which (3) will happen. And that is all 'multistakeholder= ' means.

So the choi= ce is between (1) or (2). Brazil insists that it be (1) because they rememb= er that they were one of the targets of the coups organized by the NSA/CIA = and they have certain scores to settle. But at the end of the day they real= ize that Putin and Putinism is the immediate threat.
--001a11c3cdc0ece05904fbb7b906-- From nobody Fri Jun 13 08:13:26 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 932571B2955 for ; Fri, 13 Jun 2014 08:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hH821Ka2RBi for ; Fri, 13 Jun 2014 08:13:13 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 823DB1B2950 for ; Fri, 13 Jun 2014 08:13:07 -0700 (PDT) Received: from c-98-252-11-61.hsd1.de.comcast.net ([98.252.11.61] helo=[192.168.200.186]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1WvTAA-000AIQ-MG; Fri, 13 Jun 2014 15:13:06 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 98.252.11.61 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18j47NQgKnhYuq5F9cR2V5e Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: John Curran In-Reply-To: <20140613120407.5CEEA44B5EE@mail-14-pao.dyndns.com> Date: Fri, 13 Jun 2014 11:13:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6350D89F-DF33-433F-BE26-6BD58AC3515C@istaff.org> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <2963BB17-E425-46A9-A6CF-EE95C63B4626@istaff.org> <79BC0637-22AE-46ED-A70C-C57446FC6511@virtualized.org> <1810133C-040B- 4F9B-B16E-665442E56F8A@istaff.org> <20140612085707.B7DB68B73A4@mail-04-pao.dyndns.com> <05921299-0B65-458B-AD75-AE22B84ED4DE@istaff.org> <20140612171952.3C7C71B2AB0@ietfa.amsl.com> <6B3C7C0E-073B-4071-AEC1-C09E788FE239@istaff.org> <20140613120407.5CEEA44B5EE@mail-14-pao.dyndns.com> To: Jefsey X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/Mbn6rktq8BEsGmCXPRpRU3VnPQw Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 15:13:17 -0000 On Jun 13, 2014, at 5:47 AM, Jefsey wrote: >> It goes on further to note that ICANN needs to take care not to make = conflicts with technical reservations within those same assigned spaces. >=20 > That is a pure inventive artistic vision. "You do not have to create = technical conflicts within the MOU framework" would means "you have the = global legitimacy to rule the world". I fail to see how "not conflicting IETF technical assignments in the = IANA=20 registries" equates to "global legitimacy to rule the world". The IANA registries are simply an administrative coordination function = that allows for interoperability by coordinating particular values among the = various participants, just as the protocols themselves provide for coordination = of=20 communication messages. Use of all it is voluntary, but certainly makes=20= global communication much easier. > Sorry but I feel that the WCIT has shown that the world's majority = disagree. I was at WCIT in Dubai; there is no statement in the contested ITR's = which=20 supports your position (that IETF has the ability to establish technical=20= requirements for the registries defined by its protocols.) It is possible that a number of governments believe in a "need for = development=20 of public policy by governments" with respect to the future Internet = (the famed "Resolution 3"), even if such a statement were common consensus (which = it is not),=20 that would not change the ability of the IETF to set technical = requirements on the=20 registries defined by IETF specifications or to make technical = reservations in=20 those registries. (It would take governments mandating use of the IANA = registries=20 to provide any "ruling power" out of their specification and/or = administration; needless to say, governments are unlikely to under such without making = sure that the control accrues to them.) > You have to accept that there are two strata that have to be made to = work together on the same hardware: >=20 > - software: i.e. the IETF/SDOs designed systems, which to some extent = make a local (within the systems) law. > - brainware: i.e. the people multitude's use of these and many other = systems IETF/SDOs MAY advise and have to design software for. There the = people's laws and common laws specifty the software. >=20 > You do not have to take side if you want a stable coordinated system. = If you take side you will necessarily enter in conflicts. For several = years since Adam, brainware has ultimately won and obtained innovative = software adapted to the hardware reality's capacities. You can rigidly = claim that your for information RFCs are to be considered as unique, = life you will only answer you: why did you not then made them universal? >=20 > For three centuries, money and industrial revolution have = progressively replaced philia by competition as a societal motivation, = with an interesting and typical Beaumarchais' move to create IP rights = to subsidize La Fayette. Several have positively opposed that change (in = academic and political circles and Stallman in our area) and = reintroduced adapted forms of philia (FLOSS, what some calls the = internet democracy). >=20 > The US are born during the XVIIIth change and have an hybrid culture: = today they are at a fork and have to choose. Money/competition or = people/philia. Or seomething else? The NTIANA move is a typical sample = of this choice. MSism is a sustainable coopetitive attempt to replace a = philia based democracy in a global complex market. Apologies - the above syntactically parsed but semantically nothing = resulted with respect to stewardship or administration of the IANA registries. > You obvioiusly are at the center of this issue as being ARIN. Actually, ARIN's position on the IANA stewardship transition planning = topic=20 is simple: it is predominantly about oversight mechanisms - as such it = would=20 be best if the members of our community would engage in the discussion = and=20 express their views on what would be best. My participation on this list in my personal capacity as someone with = passing=20 familiarity with the IETF and IANA registry system; as I noted before, I = feel strongly that IETF has a key role in establishing the framework in which = the IANA registries operate, and that such a technical framework does not = exclude=20 the general-purpose portions of the DNS and IP protocol parameter = registries. > The danger for your own evaluation is to confuse this technical = occasional centricity of yours with the centricity of a world which is = indefinitly polycentric by nature, and by IETF construction (look at = LISP, at DNS Classes). As you word it yourself you are an example of = solution in a multiversal system. The worry is the lack of "after-sale" = support by IAB: they seems to only be interested in helping their IANA = example solution, not in helping the customizing diversity of people's = universes (in this case, the VGNs). Ah, VGNs... Yes, it does appear that the IETF seeks to have an IANA = registry for its protocols; as noted earlier, the protocols work just fine with = any=20 set of coordinated values, so perhaps you yourself should consider = providing=20 support for the multiple universes you seem to believe exist? > The danger is that we wind up with conflicting rather than compatible = universes. > This is fragmentation by rigidity. Your vision is vast; indeed, many folks would be thrilled if we can = establish a successful and accountable IANA coordination model for simply one = universe... /John Disclaimer: My views alone. =20 From nobody Fri Jun 13 08:18:42 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17AF01B293A for ; Fri, 13 Jun 2014 08:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNQiHtblVorC for ; Fri, 13 Jun 2014 08:18:38 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A09091B2812 for ; Fri, 13 Jun 2014 08:18:38 -0700 (PDT) Received: from c-98-252-11-61.hsd1.de.comcast.net ([98.252.11.61] helo=[192.168.200.186]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1WvTFV-000E55-VD; Fri, 13 Jun 2014 15:18:37 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 98.252.11.61 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/8yWPN4G7HQmuVGnhtxAkM Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: John Curran In-Reply-To: <6350D89F-DF33-433F-BE26-6BD58AC3515C@istaff.org> Date: Fri, 13 Jun 2014 11:18:38 -0400 Content-Transfer-Encoding: 7bit Message-Id: <7298A707-822D-451C-BDB3-B189CE469DBA@istaff.org> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <2963BB17-E425-46A9-A6CF-EE95C63B4626@istaff.org> <79BC0637-22AE-46ED-A70C-C57446FC6511@virtualized.org> <"1810133C-040B - 4F9B-B16E-665442E56F8A"@istaff.org> <20140612085707.B7DB68B73A4@mail-04-pao.dyndns.com> <05921299-0B65-458B-AD75-AE22B84ED4DE@istaff.org> <20140612171952.3C7C71B2AB0@ietfa.amsl.com> <6B3C7C0E-073B-4071-AEC1-C09E788FE239@istaff.org> <20140613120407.5CEEA44B5EE@mail-14-pao.dyndns.com> <6350D89F-DF33-433F-BE26-6BD58AC3515C@istaff.org> To: Jefsey X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/3X5axrhNnJlG4v7FptbUIgXKBuM Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 15:18:41 -0000 On Jun 13, 2014, at 11:13 AM, John Curran wrote: > I was at WCIT in Dubai; there is no statement in the contested ITR's which > supports your position (that IETF has the ability to establish technical > requirements for the registries defined by its protocols.) Argh... should read - I was at WCIT in Dubai; there is no statement in the contested ITR's which supports your position, specifically that somehow IETF's ability to establish technical requirements for IANA registries equates to a "global legitimacy to rule the world". Mea culpa, /John From nobody Fri Jun 13 09:43:48 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220DB1A05CB for ; Fri, 13 Jun 2014 09:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5J11Ds22EjzD for ; Fri, 13 Jun 2014 09:43:43 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 366381A01A8 for ; Fri, 13 Jun 2014 09:43:43 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id x12so3021677wgg.22 for ; Fri, 13 Jun 2014 09:43:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ZIOTrQe8QhM5+Cj7+kkwtTsiBmIjy2SAUqBehy/r2R8=; b=FUOpEuIm8JmurYWmCL+civ0NrI139lfBQ7dy6lY57Pe55R0tNmVoYkCPL9ovGUllwF Z3H0gZiQZFuFqS58GoaiIu2YXTvCcZu/mb1eEiQO1ctvMe/VYGKOMvpMlHfTI+nPXKIR ID33zzyxSI6j06v1Dj6J3L7iieZbqAvr4pzHgaBMAopatJu6dPjw1Hq0SF+OqTUuSaa+ rNRHeD1+xBqxA+wWwfahNxKIxY5e+G83py7ugM7fb3gBcjhENnvxVPnjQHZtD8ZbbPX1 t+k8lVqa2PpLrmIuXd184WChhnPIsAhf94hy2fssdpHzP9aC42vwd/TUnhwRGnipoNxR iRmg== MIME-Version: 1.0 X-Received: by 10.180.105.72 with SMTP id gk8mr6362003wib.32.1402677821366; Fri, 13 Jun 2014 09:43:41 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.79.136 with HTTP; Fri, 13 Jun 2014 09:43:41 -0700 (PDT) In-Reply-To: <6350D89F-DF33-433F-BE26-6BD58AC3515C@istaff.org> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <2963BB17-E425-46A9-A6CF-EE95C63B4626@istaff.org> <79BC0637-22AE-46ED-A70C-C57446FC6511@virtualized.org> <20140612085707.B7DB68B73A4@mail-04-pao.dyndns.com> <05921299-0B65-458B-AD75-AE22B84ED4DE@istaff.org> <20140612171952.3C7C71B2AB0@ietfa.amsl.com> <6B3C7C0E-073B-4071-AEC1-C09E788FE239@istaff.org> <20140613120407.5CEEA44B5EE@mail-14-pao.dyndns.com> <6350D89F-DF33-433F-BE26-6BD58AC3515C@istaff.org> Date: Fri, 13 Jun 2014 12:43:41 -0400 X-Google-Sender-Auth: tFsvvtdPACKXns2iugGQTkIXkEc Message-ID: From: Phillip Hallam-Baker To: John Curran Content-Type: multipart/alternative; boundary=f46d0442685a46e87704fbba6197 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/YIjtDCFcaS-hx_jMpwhtk9bPzJY Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 16:43:45 -0000 --f46d0442685a46e87704fbba6197 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 13, 2014 at 11:13 AM, John Curran wrote: > On Jun 13, 2014, at 5:47 AM, Jefsey wrote: > > >> It goes on further to note that ICANN needs to take care not to make > conflicts with technical reservations within those same assigned spaces. > > > > That is a pure inventive artistic vision. "You do not have to create > technical conflicts within the MOU framework" would means "you have the > global legitimacy to rule the world". > > I fail to see how "not conflicting IETF technical assignments in the IANA > registries" equates to "global legitimacy to rule the world". > > The IANA registries are simply an administrative coordination function that > allows for interoperability by coordinating particular values among the > various > participants, just as the protocols themselves provide for coordination of > communication messages. Use of all it is voluntary, but certainly makes > global communication much easier. As a clarifying matter could we separate out discussion of IANA-IP and IANA-IETF? The fact that the two functions are both nominally vested in IANA is a real source of confusion and probably the one thing that the IETF should ask to change. The functions, processes and constituencies that IANA-IP responds to are completely disjoint from those of IANA-IETF. The only thing that combines the two are that they were both done by Jon Postel and IP addresses were not divested to ICANN along with domains. Unless the allocation processes are completely fubar, IANA-IP should for all intents and purposes cease to exist. IPv4 is all gone as far as IANA is concerned. And IPv6 is sufficiently plentiful that the only effective power IANA-IP currently holds is the ability to create a new RIR. I don't think IANA-IP could remove accreditation from a RIR by starving them of IPv6 assignment space. The five RIRs all have a /12 assigned which is 2^52 possible networks. [SIDR could change the game-theory analysis in theory but not in practice because SIDR is only evaluated by backbone providers and if the RIRs or ICANN or anyone play stupid games or try to act corruptly the SIDR layer will be ignored.] So acknowledging that the power is negligible, I suggest folding IANA-IP into ICANN but with the proviso that IANA only has control over the blocks that have been specifically allocated to it. This effectively leaves 7/8ths of the address space in the hands of the IETF. I would ideally like to change the name of IANA simply to avoid the IETF registries continuing to be a control target. But that could be expensive and difficult. On the other hand, we still use .arpa. --f46d0442685a46e87704fbba6197 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Jun 13, 2014 at 11:13 AM, John Curran <= ;jcurran@istaff.org= > wrote:
On Jun 13, 2014, at 5:47 AM,= Jefsey <jefsey@jefsey.com> = wrote:

>> It goes on further to note that ICANN needs to take care not to ma= ke conflicts with technical reservations within those same assigned spaces.=
>
> That is a pure inventive artistic vision. "= You do not have to create technical conflicts within the MOU framework"= ; would means "you have the global legitimacy to rule the world".=

I fail to see how "not conflicting IETF technical assignments in= the IANA
registries" equates to "global legitimacy to rule the world"= .

The IANA registries are simply an administrative coordination function that=
allows for interoperability by coordinating particular values among the var= ious
participants, just as the protocols themselves provide for coordination of<= br> communication messages. =C2=A0Use of all it is voluntary, but certainly mak= es
global communication much easier.

As a clar= ifying matter could we separate out discussion of IANA-IP and IANA-IETF?

The fact that the two functions are both nominally v= ested in IANA is a real source of confusion and probably the one thing that= the IETF should ask to change.

The functions, processes and constituencies that IANA-I= P responds to are completely disjoint from those of IANA-IETF. The only thi= ng that combines the two are that they were both done by Jon Postel and IP = addresses were not divested to ICANN along with domains.


Unless the allocation processes are comp= letely fubar, IANA-IP should for all intents and purposes cease to exist. I= Pv4 is all gone as far as IANA is concerned. And IPv6 is sufficiently plent= iful that the only effective power IANA-IP currently holds is the ability t= o create a new RIR.

I don't think IANA-IP could remove accreditation fr= om a RIR by starving them of IPv6 assignment space. The five RIRs all have = a /12 assigned which is 2^52 possible networks.

[SIDR could change the game-theory analysis in theory but not in practice b= ecause SIDR is only evaluated by backbone providers and if the RIRs or ICAN= N or anyone play stupid games or try to act corruptly the SIDR layer will b= e ignored.]=C2=A0


So acknowledging that the power is negli= gible, I suggest folding IANA-IP into ICANN but with the proviso that IANA = only has control over the blocks that have been specifically allocated to i= t. This effectively leaves 7/8ths of the address space in the hands of the = IETF.

I would ideally like to change the name of IANA simply = to avoid the IETF registries continuing to be a control target. But that co= uld be expensive and difficult. On the other hand, we still use .arpa.
--f46d0442685a46e87704fbba6197-- From nobody Fri Jun 13 09:55:06 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDAE81B29A5 for ; Fri, 13 Jun 2014 09:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDRVv7X-r5MT for ; Fri, 13 Jun 2014 09:55:03 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B75301B29A1 for ; Fri, 13 Jun 2014 09:55:03 -0700 (PDT) Received: from mx1.yitter.info (nat-07-mht.dyndns.com [216.146.45.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 71C7D8A031 for ; Fri, 13 Jun 2014 16:55:02 +0000 (UTC) Date: Fri, 13 Jun 2014 12:55:01 -0400 From: Andrew Sullivan To: internetgovtech@iab.org Message-ID: <20140613165501.GP35100@mx1.yitter.info> References: <5397BBE6.40604@abenaki.wabanaki.net> <2963BB17-E425-46A9-A6CF-EE95C63B4626@istaff.org> <79BC0637-22AE-46ED-A70C-C57446FC6511@virtualized.org> <20140612085707.B7DB68B73A4@mail-04-pao.dyndns.com> <05921299-0B65-458B-AD75-AE22B84ED4DE@istaff.org> <20140612171952.3C7C71B2AB0@ietfa.amsl.com> <6B3C7C0E-073B-4071-AEC1-C09E788FE239@istaff.org> <20140613120407.5CEEA44B5EE@mail-14-pao.dyndns.com> <6350D89F-DF33-433F-BE26-6BD58AC3515C@istaff.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/CHuiVhojO631hVB6tqlJXy2ikw4 Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 16:55:05 -0000 On Fri, Jun 13, 2014 at 12:43:41PM -0400, Phillip Hallam-Baker wrote: > > As a clarifying matter could we separate out discussion of IANA-IP and > IANA-IETF? > > The fact that the two functions are both nominally vested in IANA is a real > source of confusion and probably the one thing that the IETF should ask to > change. > > The functions, processes and constituencies that IANA-IP responds to are > completely disjoint from those of IANA-IETF. The only thing that combines > the two are that they were both done by Jon Postel and IP addresses were > not divested to ICANN along with domains. I used to think this too, but I don't any more. It seems to me that special-use registries of both IP addresses and DNS names militate for protocol parameters and these other allocations to live in the same organization, so that the (admittedly rare) cases where there are relationships between them can be caught. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Jun 13 10:07:02 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1621B29A4 for ; Fri, 13 Jun 2014 10:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEYrBgDH-0Yh for ; Fri, 13 Jun 2014 10:06:58 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 311AB1B2994 for ; Fri, 13 Jun 2014 10:06:58 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id z12so2959767wgg.1 for ; Fri, 13 Jun 2014 10:06:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=JritvTq6tMiLZpEq8nd5c8VzeKmbT70trFciGxJ8NMo=; b=Im3QhqnkzMSobg3m7o/8aSWpUFzRJEaeFNhzBWU7LfhAfYzfQ6Q5M7igSQMvAEoAgq X2YvWazhP7cjxqsLh3swc4kF52ohk5wnCbK4yuEkmhtX270iHsYqq5ZKOozzTkKxMlTG fWgKl62ukpf7kn8b4BBon3NFumEP0DFMKF/6bWfTXasWIX/AQxEX9zROs9rqWBq59wEb l1ddCqNPu8SpMmpZtPJCfqhrRwLNkQlzuoceoHEy/zXE0zqszVNW6bLSMa03+7q6HFyG vmfEtm5dyyjJHW3EuaQjDtwDdrO/KxOfcXLKw9TpIepHNwPsgl7mBFkOrnPwAYrEK8pi 1f/A== MIME-Version: 1.0 X-Received: by 10.194.24.36 with SMTP id r4mr6250077wjf.39.1402679216649; Fri, 13 Jun 2014 10:06:56 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.79.136 with HTTP; Fri, 13 Jun 2014 10:06:56 -0700 (PDT) In-Reply-To: <20140613165501.GP35100@mx1.yitter.info> References: <5397BBE6.40604@abenaki.wabanaki.net> <2963BB17-E425-46A9-A6CF-EE95C63B4626@istaff.org> <79BC0637-22AE-46ED-A70C-C57446FC6511@virtualized.org> <20140612085707.B7DB68B73A4@mail-04-pao.dyndns.com> <05921299-0B65-458B-AD75-AE22B84ED4DE@istaff.org> <20140612171952.3C7C71B2AB0@ietfa.amsl.com> <6B3C7C0E-073B-4071-AEC1-C09E788FE239@istaff.org> <20140613120407.5CEEA44B5EE@mail-14-pao.dyndns.com> <6350D89F-DF33-433F-BE26-6BD58AC3515C@istaff.org> <20140613165501.GP35100@mx1.yitter.info> Date: Fri, 13 Jun 2014 13:06:56 -0400 X-Google-Sender-Auth: 99sZEhaNdtyaKamKsE_wolXrOBM Message-ID: From: Phillip Hallam-Baker To: Andrew Sullivan Content-Type: multipart/alternative; boundary=047d7b5d2dea713fe704fbbab468 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/sWd9NO0uZ7kPme5jfUiCOgIRkM4 Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 17:07:00 -0000 --047d7b5d2dea713fe704fbbab468 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 13, 2014 at 12:55 PM, Andrew Sullivan wrote: > On Fri, Jun 13, 2014 at 12:43:41PM -0400, Phillip Hallam-Baker wrote: > > > > As a clarifying matter could we separate out discussion of IANA-IP and > > IANA-IETF? > > > > The fact that the two functions are both nominally vested in IANA is a > real > > source of confusion and probably the one thing that the IETF should ask > to > > change. > > > > The functions, processes and constituencies that IANA-IP responds to are > > completely disjoint from those of IANA-IETF. The only thing that combines > > the two are that they were both done by Jon Postel and IP addresses were > > not divested to ICANN along with domains. > > I used to think this too, but I don't any more. It seems to me that > special-use registries of both IP addresses and DNS names militate for > protocol parameters and these other allocations to live in the same > organization, so that the (admittedly rare) cases where there are > relationships between them can be caught. > > The technical side is not really relevant here, its the appearances that matter. The Generals who froth about the Internet being a 'failed state' that needs to be brought under their control don't understand those distinctions. Nor do their Russian counterparts who are pining for a return to the good old days of the Soviet Union before they were 'stabbed in the back' by Gorbachev and Yeltsin. I have not met the Chinese generals so I don't know what they are about but it seems to be mostly fear of a return to an 'open door policy' situation where they become vassals of the US or a new cultural revolution situation. The way I would handle it technically is for IANA-IETF to delegate responsibility for a significant chunk of IPv6 space to IANA-IP. That need not be the whole of 2/8 or even 2/9. Just get rid of the parts that make them a target. --047d7b5d2dea713fe704fbbab468 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Jun 13, 2014 at 12:55 PM, Andrew Sullivan <ajs@anvilw= alrusden.com> wrote:
On Fri, Jun 13, 2014 at 12:4= 3:41PM -0400, Phillip Hallam-Baker wrote:
>
> As a clarifying matter could we separate out discussion of IANA-IP and=
> IANA-IETF?
>
> The fact that the two functions are both nominally vested in IANA is a= real
> source of confusion and probably the one thing that the IETF should as= k to
> change.
>
> The functions, processes and constituencies that IANA-IP responds to a= re
> completely disjoint from those of IANA-IETF. The only thing that combi= nes
> the two are that they were both done by Jon Postel and IP addresses we= re
> not divested to ICANN along with domains.

I used to think this too, but I don't any more. =C2=A0It seems to= me that
special-use registries of both IP addresses and DNS names militate for
protocol parameters and these other allocations to live in the same
organization, so that the (admittedly rare) cases where there are
relationships between them can be caught.


The tec= hnical side is not really relevant here, its the appearances that matter.

The Generals who froth about the Internet being a &= #39;failed state' that needs to be brought under their control don'= t understand those distinctions. Nor do their Russian counterparts who are = pining for a return to the good old days of the Soviet Union before they we= re 'stabbed in the back' by Gorbachev and Yeltsin.=C2=A0

I have not met the Chinese generals so I don't know= what they are about but it seems to be mostly fear of a return to an '= open door policy' situation where they become vassals of the US or a ne= w cultural revolution situation.=C2=A0

=C2=A0
The way I would handle it technically = is for IANA-IETF to delegate responsibility for a significant chunk of IPv6= space to IANA-IP. That need not be the whole of 2/8 or even 2/9.

Just get rid of the parts that make them a target.
--047d7b5d2dea713fe704fbbab468-- From nobody Fri Jun 13 10:27:19 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBF51B2992 for ; Fri, 13 Jun 2014 10:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.83 X-Spam-Level: X-Spam-Status: No, score=0.83 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XmhJT2M_oZk for ; Fri, 13 Jun 2014 10:27:16 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 108361B27BC for ; Fri, 13 Jun 2014 10:27:15 -0700 (PDT) Received: from 231.74.14.81.rev.sfr.net ([81.14.74.231]:51356 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1WvVFy-0000nQ-Mo; Fri, 13 Jun 2014 10:27:15 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 13 Jun 2014 19:10:19 +0200 To: John Curran From: Jefsey In-Reply-To: <6350D89F-DF33-433F-BE26-6BD58AC3515C@istaff.org> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <2963BB17-E425-46A9-A6CF-EE95C63B4626@istaff.org> <79BC0637-22AE-46ED-A70C-C57446FC6511@virtualized.org> <1810133C-040B-4F9B-B16E-665442E56F8A@istaff.org> <20140612085707.B7DB68B73A4@mail-04-pao.dyndns.com> <05921299-0B65-458B-AD75-AE22B84ED4DE@istaff.org> <20140612171952.3C7C71B2AB0@ietfa.amsl.com> <6B3C7C0E-073B-4071-AEC1-C09E788FE239@istaff.org> <20140613120407.5CEEA44B5EE@mail-14-pao.dyndns.com> <6350D89F-DF33-433F-BE26-6BD58AC3515C@istaff.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: jefsey+jefsey.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/H-0BtNBCH0_wdKMDOumV-q85PSw Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 17:27:17 -0000 John, difficult to discuss with you as you obviously have formed an educated middle vision of things which quickly become too versatile to simple logic. I am not at all against it, but it does not seem that mail is adequate to support the debate. As it may lead to apparently say contradicting things in the same sentence. At 17:13 13/06/2014, John Curran wrote: > > The danger for your own evaluation is to confuse this technical > occasional centricity of yours with the centricity of a world > which is indefinitly polycentric by nature, and by IETF > construction (look at LISP, at DNS Classes). As you word it > yourself you are an example of solution in a multiversal system. > The worry is the lack of "after-sale" support by IAB: they seems to > only be interested in helping their IANA example solution, not in > helping the customizing diversity of people's universes (in this > case, the VGNs). > >Ah, VGNs... Yes, it does appear that the IETF seeks to have an IANA registry >for its protocols; as noted earlier, the protocols work just fine with any >set of coordinated values, so perhaps you yourself should consider providing >support for the multiple universes you seem to believe exist? This is a clear suggestion where I can make a response you might litterally accept. 1. this is what I do 2. this is what IAB does not help while it should. A car manufacturer does not only support a perfect demonstration car. It supports all of them. > > The danger is that we wind up with conflicting rather than > compatible universes. > > This is fragmentation by rigidity. > >Your vision is vast; indeed, many folks would be thrilled if we can establish >a successful and accountable IANA coordination model for simply one >universe... This is not a complex thing if you accept to say "a united multiverse" rather than "one universe". This is what communication is about. The IANA as a protocol. We did not need it for the WhoIs and we have it, we need it for the IANA as a whole and we do not have it. The problem is that we waste time for years and years in considering a centralized IANA repository. Probably because we have a IANA protocol available but we want to keep it a single authoritative root. The IANA is to be multi-use, multi-technologies, multi-lingual, multi-national, etc. etc. as in the French meaning of "global" as opposed to the American meaning of "global", that Vint Cerf however tried to integrate in the "loose" meaning of "local" in IEN 48. Again, and again, the BUG (Being Uniliaterally Global) is at the root :-) jfc >/John > >Disclaimer: My views alone. From nobody Fri Jun 13 10:27:20 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2401B2905 for ; Fri, 13 Jun 2014 10:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXT1QtOO-1SO for ; Fri, 13 Jun 2014 10:27:17 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 045511B295D for ; Fri, 13 Jun 2014 10:27:17 -0700 (PDT) Received: from 231.74.14.81.rev.sfr.net ([81.14.74.231]:51356 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1WvVG0-0000nQ-D4; Fri, 13 Jun 2014 10:27:16 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 13 Jun 2014 19:22:22 +0200 To: Phillip Hallam-Baker , John Curran From: Jefsey In-Reply-To: References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <2963BB17-E425-46A9-A6CF-EE95C63B4626@istaff.org> <79BC0637-22AE-46ED-A70C-C57446FC6511@virtualized.org> <20140612085707.B7DB68B73A4@mail-04-pao.dyndns.com> <05921299-0B65-458B-AD75-AE22B84ED4DE@istaff.org> <20140612171952.3C7C71B2AB0@ietfa.amsl.com> <6B3C7C0E-073B-4071-AEC1-C09E788FE239@istaff.org> <20140613120407.5CEEA44B5EE@mail-14-pao.dyndns.com> <6350D89F-DF33-433F-BE26-6BD58AC3515C@istaff.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: jefsey+jefsey.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/V6Fie4nHLzdzhxLRvZKlCmDjtBY Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 17:27:18 -0000 At 18:43 13/06/2014, Phillip Hallam-Baker wrote: >So acknowledging that the power is negligible, I suggest folding >IANA-IP into ICANN but with the proviso that IANA only has control >over the blocks that have been specifically allocated to it. This >effectively leaves 7/8ths of the address space in the hands of the IETF. I appreciate the pertinence of your political/historic evaluation. And of this remark. However, I am not sure that leaving the address space in the IETF hands makes sense either. It would be like saying that GPS coordinates should be in the hands of NASA. IPv6 numbering plan should result from a universal mathematical function. jfc From nobody Fri Jun 13 10:43:46 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45F61A0535 for ; Fri, 13 Jun 2014 10:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ktt_gKRmKXL for ; Fri, 13 Jun 2014 10:43:42 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C2501B27BD for ; Fri, 13 Jun 2014 10:43:42 -0700 (PDT) Received: from c-98-252-11-61.hsd1.de.comcast.net ([98.252.11.61] helo=[192.168.200.186]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1WvVVt-000OUk-Rv; Fri, 13 Jun 2014 17:43:41 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 98.252.11.61 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+ly2NDfn/kGEn0Es5m8T00 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: John Curran In-Reply-To: Date: Fri, 13 Jun 2014 13:43:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <146D5D34-5765-460A-8BF1-A73CCF8D4481@istaff.org> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <2963BB17-E425-46A9-A6CF-EE95C63B4626@istaff.org> <79BC0637-22AE-46ED-A70C-C57446FC6511@virtualized.org> <20140612085707 .B7DB68B73A4@mail-04-pao.dyndns.com> <05921299-0B65-458B-AD75-AE22B84ED4DE@istaff.org> <20140612171952.3C7C71B2AB0@ietfa.amsl.com> <6B3C7C0E-073B-4071-AEC1-C09E788FE239@istaff.org> <20140613120407.5CEEA44B5EE@mail-14-pao.dyndns.com> <6350D89F-DF33-433F-BE26-6BD58AC3515C@istaff.org> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/FxKAG0v7_XrvZu7wKCFoXEmh-d8 Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 17:43:45 -0000 On Jun 13, 2014, at 12:43 PM, Phillip Hallam-Baker = wrote: > As a clarifying matter could we separate out discussion of IANA-IP and = IANA-IETF? Umm.. There is only one 32-bit address space, and it has both the IETF = making=20 specialized reservations and the RIRs making general-purpose assignments = from that space. The entire space is published via various protocols that = require there be coordination (whois, reverse DNS, RPKI) > Unless the allocation processes are completely fubar, IANA-IP should = for all intents and purposes cease to exist. IPv4 is all gone as far as = IANA is concerned. And IPv6 is sufficiently plentiful that the only = effective power IANA-IP currently holds is the ability to create a new = RIR. Actually, there are new IETF technical reservations being made in IPv4 = from time to time,=20 including some assignments last year -=20 = > I don't think IANA-IP could remove accreditation from a RIR by = starving them of IPv6 assignment space. The five RIRs all have a /12 = assigned which is 2^52 possible networks. One of the questions we face is what to do if any of the RIRs or ICANN = were to be=20 captured by interests which clearly do not represent the served = community. In the most extreme case, there could be a need at some point to duplicate all = of the existing=20 registry data and then designate a replacement organization (the reality = is probably=20 that there only needs to be the potential to do such; it's visible = existence alone serves as a strong deterrent against capture.) > So acknowledging that the power is negligible, I suggest folding = IANA-IP into ICANN but with the proviso that IANA only has control over = the blocks that have been specifically allocated to it. This effectively = leaves 7/8ths of the address space in the hands of the IETF. That is effectively the current situation. > I would ideally like to change the name of IANA simply to avoid the = IETF registries continuing to be a control target. But that could be = expensive and difficult. On the other hand, we still use .arpa. The name is not the reason for involvement of the IETF - the IETF = mission of "making the=20 Internet work better" requires that it do more than develop protocols, = it has occasionally worry about the registries required by those protocols, the framework in = which the registries operate, and the importance of delegating policy authority for more = general purpose spaces to bodies which represent the community of those using the protocol. FYI, /John Disclaimer: My views alone. From nobody Fri Jun 13 10:44:13 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF471B2957 for ; Fri, 13 Jun 2014 10:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2qoauYLSr8h for ; Fri, 13 Jun 2014 10:44:11 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B3B31B293F for ; Fri, 13 Jun 2014 10:44:11 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id r20so1300952wiv.16 for ; Fri, 13 Jun 2014 10:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=hE885c453liA9QbwaBRiZEXWk2fR350AM2Uo+OY3P7A=; b=axeKEWdxLLYT9XjEYIZHnlL20PWB8L5h+eHeDCAf5kTFyrLh/pJ4ti6Mw3+akbrPV1 rSS95flunYXqVCBOFZT0+1/q17wTKBKJk05gRcrWMXt4g00MOC7FADxhBPVR2vg4BBBr JjC/7F081RnJJE4kpVc9Zyaege9OMy9bB1XhdYeUvFUJ/OZXd88SeCV2KtiV4cfmAtVN el6aHF4rqx1vOPxmqCgrfMisFyjuDzOAeJMkZRlcLOcAQemVc1iVe+uw3iaw1O9mDa5p 78WiKcGH0aUPagkTmbq9Q4120Nh8qZp1rCrpn9xdnjWiXSCU8vtc3Dyt14hIAFGOihW5 638g== MIME-Version: 1.0 X-Received: by 10.194.62.176 with SMTP id z16mr6574167wjr.76.1402681448798; Fri, 13 Jun 2014 10:44:08 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.79.136 with HTTP; Fri, 13 Jun 2014 10:44:08 -0700 (PDT) In-Reply-To: <20140613172720.041791B29B4@ietfa.amsl.com> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <2963BB17-E425-46A9-A6CF-EE95C63B4626@istaff.org> <79BC0637-22AE-46ED-A70C-C57446FC6511@virtualized.org> <20140612085707.B7DB68B73A4@mail-04-pao.dyndns.com> <05921299-0B65-458B-AD75-AE22B84ED4DE@istaff.org> <20140612171952.3C7C71B2AB0@ietfa.amsl.com> <6B3C7C0E-073B-4071-AEC1-C09E788FE239@istaff.org> <20140613120407.5CEEA44B5EE@mail-14-pao.dyndns.com> <6350D89F-DF33-433F-BE26-6BD58AC3515C@istaff.org> <20140613172720.041791B29B4@ietfa.amsl.com> Date: Fri, 13 Jun 2014 13:44:08 -0400 X-Google-Sender-Auth: sI9QV4HcLh1M_Kj4lw3FNZnLEGU Message-ID: From: Phillip Hallam-Baker To: Jefsey Content-Type: multipart/alternative; boundary=047d7ba979c27d24d604fbbb3992 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/HOyQjZJHOzMvIT0SVVfk9ya2_J8 Cc: John Curran , internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 17:44:12 -0000 --047d7ba979c27d24d604fbbb3992 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 13, 2014 at 1:22 PM, Jefsey wrote: > At 18:43 13/06/2014, Phillip Hallam-Baker wrote: > >> So acknowledging that the power is negligible, I suggest folding IANA-IP >> into ICANN but with the proviso that IANA only has control over the blocks >> that have been specifically allocated to it. This effectively leaves 7/8ths >> of the address space in the hands of the IETF. >> > > I appreciate the pertinence of your political/historic evaluation. And of > this remark. > However, I am not sure that leaving the address space in the IETF hands > makes sense either. > It would be like saying that GPS coordinates should be in the hands of > NASA. > IPv6 numbering plan should result from a universal mathematical function. > That is the one thing that the IPv6 number space is too small for. If we had 128 routable bits then we could use SHA-2-256-128 to obtain one way hashes of public keys and use 'em for routing. But we didn't and it is too late now. And even if we had it would be horribly inefficient to route such a sparse address space. There are some assignments made by the IETF for purely technical reasons. In fact I just did a SECDIR review of that type of assignment recently. But those are all in space that is reserved by IETF for those purposes and not available for general allocation. The only circumstance in which IETF might get involved in IP assignment again would be precisely the case in which a universal mathematical function approach was applied. But the IETF would have to develop that technology first. At the moment that space is not routable at all. --047d7ba979c27d24d604fbbb3992 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jun 13, 2014 at 1:22 PM, Jefsey <jefsey@jefsey.com> wrot= e:
At 18:43 13/06/2014, Phillip Hallam-Baker wrote:
So acknowledging that the power is negligible, I suggest folding IANA-IP in= to ICANN but with the proviso that IANA only has control over the blocks th= at have been specifically allocated to it. This effectively leaves 7/8ths o= f the address space in the hands of the IETF.

I appreciate the pertinence of your political/historic evaluation. And of t= his remark.
However, I am not sure that leaving the address space in the IETF hands mak= es sense either.
It would be like saying that GPS coordinates should be in the hands of NASA= .
IPv6 numbering plan should result from a universal mathematical function.

That is the one thing that the IPv= 6 number space is too small for.

If we had 128 rou= table bits then we could use SHA-2-256-128 to obtain one way hashes of publ= ic keys and use 'em for routing.

But we didn't and it is too late now. And even if w= e had it would be horribly inefficient to route such a sparse address space= .


There are some assignments made b= y the IETF for purely technical reasons. In fact I just did a SECDIR review= of that type of assignment recently. But those are all in space that is re= served by IETF for those purposes and not available for general allocation.= =C2=A0

The only circumstance in which IETF might get involved = in IP assignment again would be precisely the case in which a universal mat= hematical function approach was applied. But the IETF would have to develop= that technology first. At the moment that space is not routable at all.
--047d7ba979c27d24d604fbbb3992-- From nobody Fri Jun 13 11:02:19 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F54E1B2993 for ; Fri, 13 Jun 2014 11:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbHpxAimGiec for ; Fri, 13 Jun 2014 11:02:16 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FD011B293F for ; Fri, 13 Jun 2014 11:02:16 -0700 (PDT) Received: from 231.74.14.81.rev.sfr.net ([81.14.74.231]:52067 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1WvVnr-00039c-37; Fri, 13 Jun 2014 11:02:15 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 13 Jun 2014 20:01:51 +0200 To: Andrew Sullivan ,internetgovtech@iab.org From: JFC Morfin In-Reply-To: <20140613165501.GP35100@mx1.yitter.info> References: <5397BBE6.40604@abenaki.wabanaki.net> <2963BB17-E425-46A9-A6CF-EE95C63B4626@istaff.org> <79BC0637-22AE-46ED-A70C-C57446FC6511@virtualized.org> <20140612085707.B7DB68B73A4@mail-04-pao.dyndns.com> <05921299-0B65-458B-AD75-AE22B84ED4DE@istaff.org> <20140612171952.3C7C71B2AB0@ietfa.amsl.com> <6B3C7C0E-073B-4071-AEC1-C09E788FE239@istaff.org> <20140613120407.5CEEA44B5EE@mail-14-pao.dyndns.com> <6350D89F-DF33-433F-BE26-6BD58AC3515C@istaff.org> <20140613165501.GP35100@mx1.yitter.info> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: jefsey+jefsey.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/CLtvTxY85Acu3jx4W8s53EWNids Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 18:02:17 -0000 At 18:55 13/06/2014, Andrew Sullivan wrote: >I used to think this too, but I don't any more. It seems to me that >special-use registries of both IP addresses and DNS names militate for >protocol parameters and these other allocations to live in the same >organization, so that the (admittedly rare) cases where there are >relationships between them can be caught. A. Have you any? That would not be actually conceptual bugs of the two systems? Or more probably of the way they are used? B. There is nothing against any "special-use registries" as part of the definition of a universal system (Phillip mentionned 1/8th of the IPv6 addresses to the RIR and .arpa: don't they correspond to your "special-use" cases? jfc From nobody Fri Jun 13 11:11:25 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6647F1B29BB for ; Fri, 13 Jun 2014 11:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mo2JALA2-4xM for ; Fri, 13 Jun 2014 11:11:13 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86A811A01E7 for ; Fri, 13 Jun 2014 11:11:12 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id n12so3105590wgh.7 for ; Fri, 13 Jun 2014 11:11:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=LEITYfQ23NyFTP4JJ36rFYuoYenDxVsLlDHRMFuFJdQ=; b=ZLIUNhj2/xNANAE85FT0ltxxgsbZvG7IynxUhQNuCpXlvz7gJIY7lO5FSox0IjCzCo uTgdwx7mILYRdPdFbR46LXQvz/pVj7kh2L03c+FWE6QH/ueC7OQ/payNuXp7tYa4yNS1 iy2rovOoWq2ajDrYCMhxAztoiA795FDTO+J2oTaQiKX0+346BLQQBlsiXwgSx+84/vES 1LGFbNu0Ks/aD0ynirPMivc9JiRez4XuU9SadReIZrwUaz4Pfb3GfT/t4NE9gwEjbLE/ XiYndLvaAczgi1b31YqAK1Cf+5BUWg9Wtv6uSIT8qeUof3phmACmW9ee94uKqgdunxNe 9/4Q== MIME-Version: 1.0 X-Received: by 10.180.13.139 with SMTP id h11mr6932397wic.34.1402683071113; Fri, 13 Jun 2014 11:11:11 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.79.136 with HTTP; Fri, 13 Jun 2014 11:11:11 -0700 (PDT) In-Reply-To: <146D5D34-5765-460A-8BF1-A73CCF8D4481@istaff.org> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <2963BB17-E425-46A9-A6CF-EE95C63B4626@istaff.org> <79BC0637-22AE-46ED-A70C-C57446FC6511@virtualized.org> <20140612085707.B7DB68B73A4@mail-04-pao.dyndns.com> <05921299-0B65-458B-AD75-AE22B84ED4DE@istaff.org> <20140612171952.3C7C71B2AB0@ietfa.amsl.com> <6B3C7C0E-073B-4071-AEC1-C09E788FE239@istaff.org> <20140613120407.5CEEA44B5EE@mail-14-pao.dyndns.com> <6350D89F-DF33-433F-BE26-6BD58AC3515C@istaff.org> <146D5D34-5765-460A-8BF1-A73CCF8D4481@istaff.org> Date: Fri, 13 Jun 2014 14:11:11 -0400 X-Google-Sender-Auth: exkkWQL7POKQDZ70qk_LnzFOdMc Message-ID: From: Phillip Hallam-Baker To: John Curran Content-Type: multipart/alternative; boundary=001a11c244482fbad504fbbb9a8e Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/5nwrNhklngOI9U0dX918yaC6lYU Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 18:11:19 -0000 --001a11c244482fbad504fbbb9a8e Content-Type: text/plain; charset=UTF-8 On Fri, Jun 13, 2014 at 1:43 PM, John Curran wrote: > On Jun 13, 2014, at 12:43 PM, Phillip Hallam-Baker > wrote: > > > As a clarifying matter could we separate out discussion of IANA-IP and > IANA-IETF? > > Umm.. There is only one 32-bit address space, and it has both the IETF > making > specialized reservations and the RIRs making general-purpose assignments > from > that space. The entire space is published via various protocols that > require there > be coordination (whois, reverse DNS, RPKI) > The RIRs cannot allocate from the space IETF might allocate from, they are already reserved to IETF. > > Unless the allocation processes are completely fubar, IANA-IP should for > all intents and purposes cease to exist. IPv4 is all gone as far as IANA is > concerned. And IPv6 is sufficiently plentiful that the only effective power > IANA-IP currently holds is the ability to create a new RIR. > > Actually, there are new IETF technical reservations being made in IPv4 > from time to time, > including some assignments last year - > < > http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml > > > Yes, I did the SECDIR review on one of them. Which probably means I will get the next one as well. IPv4 is all gone as far as IANA-IP is concerned, it an't going to delegate any more to the RIRs. Making IP address space allocations from the IETF-reserved areas is a function I would consider part of IANA-IETF. The only part I would split off is the part that is allocating to the RIRs. > > I don't think IANA-IP could remove accreditation from a RIR by starving > them of IPv6 assignment space. The five RIRs all have a /12 assigned which > is 2^52 possible networks. > > One of the questions we face is what to do if any of the RIRs or ICANN > were to be > captured by interests which clearly do not represent the served community. You mean if one of the CEOs raises rates and buys themselves a huge yacht. Not actually beyond possibility given the political norms in some of these places. The World Cup is currently having a bribery scandal very similar to the SLC olympics. I would say it is a virtual certainly something of the sort will occur at some time. There are five RIRs and thus five opportunities. The question would be the extent to which the RIRs respected expectations of exclusivity and whether default by one led to a domino effect. My grandfather ran a building society which is the UK equivalent of the savings and loans. After he retired there was a craze for demutualization of the building societies and today the one he ran is one of the few left. Only a few of the others exist in any form. Most were bought by the large banks or amalgamated to form banks like the Bradford and Bingley that were the primary cause of the UK banking collapse.The B&B had a 150 year history as a mutual before is demutualized in 2000. It lasted only seven years as a bank. But the management did extremely well from running it into the ground they paid themselves millions for doing so. And of course anyone who pointed out the likely outcome of such schemes was a dirty hippie. The account holders loved getting paid free money for losing their mutual ownership. The shareholders initially got a bump in their share price after the IPO. In the > most extreme case, there could be a need at some point to duplicate all of > the existing > registry data and then designate a replacement organization (the reality > is probably > that there only needs to be the potential to do such; it's visible > existence alone serves > as a strong deterrent against capture.) > True, but I don't think that is something that necessarily needs to be vested in ICANN or IANA. Since the records are public, any party could archive them. The question then goes to whether the archives are to be believed to be accurate. Which is why I keep proposing we have a Harber-Stornetta style notary service for the Internet... > > So acknowledging that the power is negligible, I suggest folding IANA-IP > into ICANN but with the proviso that IANA only has control over the blocks > that have been specifically allocated to it. This effectively leaves 7/8ths > of the address space in the hands of the IETF. > > That is effectively the current situation. > Correct. I am not suggesting any change in what happens. I am only suggesting that instead of the IANA being gold plated and having everyone think that it is solid gold and worth stealing we paint it a different colour that attracts less attention. > > I would ideally like to change the name of IANA simply to avoid the IETF > registries continuing to be a control target. But that could be expensive > and difficult. On the other hand, we still use .arpa. > > The name is not the reason for involvement of the IETF - the IETF mission > of "making the > Internet work better" requires that it do more than develop protocols, it > has occasionally > worry about the registries required by those protocols, the framework in > which the registries > operate, and the importance of delegating policy authority for more > general purpose spaces > to bodies which represent the community of those using the protocol. > > FYI, > /John > > Disclaimer: My views alone. > > > --001a11c244482fbad504fbbb9a8e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Jun 13, 2014 at 1:43 PM, John Curran <= jcurran@istaff.org<= /a>> wrote:
On Jun 13, 2014, at 12:43 PM, Phillip Hallam= -Baker <phill@hallambaker.com> wrote:

> As a clarifying matter could we separate out discussion of IANA-IP and= IANA-IETF?

Umm.. =C2=A0There is only one 32-bit address space, and it has both the IET= F making
specialized reservations and the RIRs making general-purpose assignments fr= om
that space. =C2=A0The entire space is published via various protocols that = require there
be coordination (whois, reverse DNS, RPKI)

<= div>The RIRs cannot allocate from the space IETF might allocate from, they = are already reserved to IETF.

> Unless the allocation processes are completely fubar, IANA-IP should f= or all intents and purposes cease to exist. IPv4 is all gone as far as IANA= is concerned. And IPv6 is sufficiently plentiful that the only effective p= ower IANA-IP currently holds is the ability to create a new RIR.

Actually, there are new IETF technical reservations being made in IPv4 from= time to time,
including some assignments last year -
=C2=A0<http://www.iana.or= g/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml>

Yes, I did the SECDIR review on one of the= m. Which probably means I will get the next one as well.

IPv4 is all gone as far as IANA-IP is concerned, it an't going t= o delegate any more to the RIRs.


Making IP address space allocations from= the IETF-reserved areas is a function I would consider part of IANA-IETF. = The only part I would split off is the part that is allocating to the RIRs.=

=C2=A0
> I don't think IANA-IP could remove accreditation from a RIR by sta= rving them of IPv6 assignment space. The five RIRs all have a /12 assigned = which is 2^52 possible networks.

One of the questions we face is what to do if any of the RIRs or ICANN were= to be
captured by interests which clearly do not represent the served community. =

You mean if one of the CEOs raises rates a= nd buys themselves a huge yacht. Not actually beyond possibility given the = political norms in some of these places. The World Cup is currently having = a bribery scandal very similar to the SLC olympics.=C2=A0

I would say it is a virtual certainly something of the = sort will occur at some time. There are five RIRs and thus five opportuniti= es. The question would be the extent to which the RIRs respected expectatio= ns of exclusivity and whether default by one led to a domino effect.

My grandfather ran a building society which is the UK e= quivalent of the savings and loans. After he retired there was a craze for = demutualization of the building societies and today the one he ran is one o= f the few left. Only a few of the others exist in any form. Most were bough= t by the large banks or amalgamated to form banks like the Bradford and Bin= gley that were the primary cause of the UK banking collapse.The B&B had= a 150 year history as a mutual before is demutualized in 2000. It lasted o= nly seven years as a bank. But the management did extremely well from runni= ng it into the ground they paid themselves millions for doing so.

And of course anyone who pointed out the likely outcome= of such schemes was a dirty hippie. The account holders loved getting paid= free money for losing their mutual ownership. The shareholders initially g= ot a bump in their share price after the IPO.=C2=A0


=C2=A0In the most extreme case, there could be a need at some point to duplicate all of = the existing
registry data and then designate a replacement organization (the reality is= probably
that there only needs to be the potential to do such; it's visible exis= tence alone serves
as a strong deterrent against capture.)

True, but I don't think that is something that necessarily needs to be= vested in ICANN or IANA. Since the records are public, any party could arc= hive them. The question then goes to whether the archives are to be believe= d to be accurate.

Which is why I keep proposing we have a Harber-Stornett= a style notary service for the Internet...



=C2=A0
> So acknowledging that the power is negligible, I suggest folding IANA-= IP into ICANN but with the proviso that IANA only has control over the bloc= ks that have been specifically allocated to it. This effectively leaves 7/8= ths of the address space in the hands of the IETF.

That is effectively the current situation.

<= div>Correct. I am not suggesting any change in what happens. I am only sugg= esting that instead of the IANA being gold plated and having everyone think= that it is solid gold and worth stealing we paint it a different colour th= at attracts less attention.


=C2=A0
> I would ideally like to change the name of IANA simply to avoid the IE= TF registries continuing to be a control target. But that could be expensiv= e and difficult. On the other hand, we still use .arpa.

The name is not the reason for involvement of the IETF - the IETF mission o= f "making the
Internet work better" requires that it do more than develop protocols,= it has occasionally
worry about the registries required by those protocols, the framework in wh= ich the registries
operate, and the importance of delegating policy authority for more general= purpose spaces
to bodies which represent the community of those using the protocol.

FYI,
/John

Disclaimer: My views alone.



--001a11c244482fbad504fbbb9a8e-- From nobody Fri Jun 13 11:30:01 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA391B29D1 for ; Fri, 13 Jun 2014 11:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwzoAURZ0rFS for ; Fri, 13 Jun 2014 11:30:00 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8BF91B29CF for ; Fri, 13 Jun 2014 11:29:59 -0700 (PDT) Received: from mx1.yitter.info (nat-07-mht.dyndns.com [216.146.45.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id A47D38A031 for ; Fri, 13 Jun 2014 18:29:58 +0000 (UTC) Date: Fri, 13 Jun 2014 14:29:57 -0400 From: Andrew Sullivan To: internetgovtech@iab.org Message-ID: <20140613182957.GW35100@mx1.yitter.info> References: <79BC0637-22AE-46ED-A70C-C57446FC6511@virtualized.org> <20140612085707.B7DB68B73A4@mail-04-pao.dyndns.com> <05921299-0B65-458B-AD75-AE22B84ED4DE@istaff.org> <20140612171952.3C7C71B2AB0@ietfa.amsl.com> <6B3C7C0E-073B-4071-AEC1-C09E788FE239@istaff.org> <20140613120407.5CEEA44B5EE@mail-14-pao.dyndns.com> <6350D89F-DF33-433F-BE26-6BD58AC3515C@istaff.org> <20140613165501.GP35100@mx1.yitter.info> <20140613180220.5E1941B2994@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140613180220.5E1941B2994@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/0xaEyBHJy-FC9mi9OkU2Ioy349Y Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 18:30:01 -0000 On Fri, Jun 13, 2014 at 08:01:51PM +0200, JFC Morfin wrote: > > A. Have you any? That would not be actually conceptual bugs of the > two systems? Or more probably of the way they are used? For instance, having IANA be aware that a separate port (protocol parameter registry) is being allocated for a thing that uses a special name (local., just for example) is, I claim, useful. In point of fact, IP addresses and DNS names are just more protocol parameters, although very particular ones that turn out to need large registries. So it's useful for pragmatic reasons to break out the operation of those kinds of registries from everything else. They're not a different kind of thing. They just have different kinds of effects in the world. > B. There is nothing against any "special-use registries" as part of > the definition of a universal system (Phillip mentionned 1/8th of > the IPv6 addresses to the RIR and .arpa: don't they correspond to > your "special-use" cases? If we had the ability to state in advance what parts needed to be special use, it wouldn't be a big deal. But of course, at least in the name space, that isn't true. See John Curran's remarks upthread about working on the operation of this Internet in this universe. (If it makes you feel better to say "multiverse", go nuts. It doesn't change the truth conditions for the proposition.) A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Jun 13 11:35:11 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0C31B2945 for ; Fri, 13 Jun 2014 11:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoSiJkwAI-rV for ; Fri, 13 Jun 2014 11:35:08 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EBA61A05F5 for ; Fri, 13 Jun 2014 11:35:08 -0700 (PDT) Received: from c-98-252-11-61.hsd1.de.comcast.net ([98.252.11.61] helo=[192.168.200.186]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1WvWJf-0004f9-H8; Fri, 13 Jun 2014 18:35:07 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 98.252.11.61 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/HfST4PtLbOieFhi4knYVK Content-Type: multipart/alternative; boundary="Apple-Mail=_1768F607-E132-4D27-91CD-193C5BF83B94" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: John Curran In-Reply-To: Date: Fri, 13 Jun 2014 14:35:07 -0400 Message-Id: References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <2963BB17-E425-46A9-A6CF-EE95C63B4626@istaff.org> <79BC0637-22AE-46ED-A70C-C57446FC6511@virtualized.org> <20140612085707 .B7DB68B73A4@mail-04-pao.dyndns.com> <05921299-0B65-458B-AD75-AE22B84ED4DE@istaff.org> <20140612171952.3C7C71B2AB0@ietfa.amsl.com> <6B3C7C0E-073B-4071-AEC1-C09E788FE239@istaff.org> <20140613120407.5CEEA44B5EE@mail-14-pao.dyndns.com> <6350D89F-DF33-433F-BE26-6BD58AC3515C@istaff.org> <146D5D34-5765-460A-8BF1-A73CCF8D4481@istaff.org> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/XoOmLGX2L5Yswf-y5bZgVVSo4-M Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 18:35:10 -0000 --Apple-Mail=_1768F607-E132-4D27-91CD-193C5BF83B94 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 13, 2014, at 2:11 PM, Phillip Hallam-Baker = wrote: > On Fri, Jun 13, 2014 at 1:43 PM, John Curran = wrote: > On Jun 13, 2014, at 12:43 PM, Phillip Hallam-Baker = wrote: >=20 > > As a clarifying matter could we separate out discussion of IANA-IP = and IANA-IETF? >=20 > Umm.. There is only one 32-bit address space, and it has both the = IETF making > specialized reservations and the RIRs making general-purpose = assignments from > that space. The entire space is published via various protocols that = require there > be coordination (whois, reverse DNS, RPKI) >=20 > The RIRs cannot allocate from the space IETF might allocate from, they = are already reserved to IETF. Not in practice... we've already had occasions of IPv4 space moving from = RIRs to IANA entirely for the purpose of satisfying an IETF technical = reservation. > IPv4 is all gone as far as IANA-IP is concerned, it an't going to = delegate any more to the RIRs. Yes, but movement of assignments is possible in the other direction. It = is also not inconceivable that the IETF might someday direct changes with respect to = some of the more esoteric regions of IPv4 address space (multicast, class E) In any case, the present state of one of the general purpose spaces = (IPv4) should not materially impact the framework of the system used for IPv4, IPv6, = and ASNs (both 2 and 4 byte). > Making IP address space allocations from the IETF-reserved areas is a = function I would consider part of IANA-IETF. The only part I would split = off is the part that is allocating to the RIRs. > =20 > > I don't think IANA-IP could remove accreditation from a RIR by = starving them of IPv6 assignment space. The five RIRs all have a /12 = assigned which is 2^52 possible networks. >=20 > One of the questions we face is what to do if any of the RIRs or ICANN = were to be > captured by interests which clearly do not represent the served = community. >=20 > You mean if one of the CEOs raises rates and buys themselves a huge = yacht. Hey, ARIN has a community suggestion process, let me know if you need a = pointer to it... ;-) =20 (At ARIN, we've actually lowered member fees 4 or 5 times over the = years, and strive=20 to be very lean... no budget for yachts or black helicopters allowed = :-) > Not actually beyond possibility given the political norms in some of = these places. The World Cup is currently having a bribery scandal very = similar to the SLC olympics.=20 >=20 > I would say it is a virtual certainly something of the sort will occur = at some time. There are five RIRs and thus five opportunities. The = question would be the extent to which the RIRs respected expectations of = exclusivity and whether default by one led to a domino effect. >=20 > My grandfather ran a building society which is the UK equivalent of = the savings and loans. After he retired there was a craze for = demutualization of the building societies and today the one he ran is = one of the few left. Only a few of the others exist in any form. Most = were bought by the large banks or amalgamated to form banks like the = Bradford and Bingley that were the primary cause of the UK banking = collapse.The B&B had a 150 year history as a mutual before is = demutualized in 2000. It lasted only seven years as a bank. But the = management did extremely well from running it into the ground they paid = themselves millions for doing so. >=20 > And of course anyone who pointed out the likely outcome of such = schemes was a dirty hippie. The account holders loved getting paid free = money for losing their mutual ownership. The shareholders initially got = a bump in their share price after the IPO.=20 I am a strong believer that there should be something external to the = RIRs and ICANN to serve as a deterrent from such occurring. While I have enormous = respect for the folks involved in running these organizations, it is not possible to = know what the coming decades will hold. > In the > most extreme case, there could be a need at some point to duplicate = all of the existing > registry data and then designate a replacement organization (the = reality is probably > that there only needs to be the potential to do such; it's visible = existence alone serves > as a strong deterrent against capture.) >=20 > True, but I don't think that is something that necessarily needs to be = vested in ICANN or IANA. Since the records are public, any party could = archive them. The question then goes to whether the archives are to be = believed to be accurate. >=20 > Which is why I keep proposing we have a Harber-Stornetta style notary = service for the Internet... Long road from theory to practice... =20 > > So acknowledging that the power is negligible, I suggest folding = IANA-IP into ICANN but with the proviso that IANA only has control over = the blocks that have been specifically allocated to it. This effectively = leaves 7/8ths of the address space in the hands of the IETF. >=20 > That is effectively the current situation. >=20 > Correct. I am not suggesting any change in what happens. I am only = suggesting that instead of the IANA being gold plated and having = everyone think that it is solid gold and worth stealing we paint it a = different colour that attracts less attention. The reality is that the IETF has a vested interest in a healthy registry = system. I do appreciate the appeal of turning the other way, closing one's eyes and ears, and = going "no no no, not our job", but do think it is preferential to proactively engage and define = the relationship in a way that says that policy authority for the general-purpose space _has been = delegated_ and unless a list of certain clear conditions occur (e.g. finding that the org is no = longer representing the served=20 community by an independent third-party review process, such as ICANN's = ATRT review), then it is not the IETF's issue. This is the type of thing that you could = put in a contract (e.g. 2860)=20 such that no party would bother the IETF, knowing it has _zero role_ = except and unless the existing general-purpose registry organizations have provably failed. FYI, /John Disclaimer: My views alone.=20 --Apple-Mail=_1768F607-E132-4D27-91CD-193C5BF83B94 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jun = 13, 2014, at 2:11 PM, Phillip Hallam-Baker <phill@hallambaker.com> = wrote:

On Fri, Jun 13, 2014 at 1:43 PM, John = Curran <jcurran@istaff.org> wrote:
On Jun 13, 2014, at 12:43 PM, Phillip = Hallam-Baker <phill@hallambaker.com> = wrote:

> As a clarifying matter could we separate out = discussion of IANA-IP and IANA-IETF?

Umm..  There is only = one 32-bit address space, and it has both the IETF making
specialized = reservations and the RIRs making general-purpose assignments = from
that space.  The entire space is published via various = protocols that require there
be coordination (whois, reverse DNS, = RPKI)

The RIRs cannot allocate from = the space IETF might allocate from, they are already reserved to = IETF.

Not in = practice... we've already had occasions of IPv4 space moving from = RIRs
to IANA entirely for the purpose of satisfying an IETF = technical reservation.

IPv4 is all gone = as far as IANA-IP is concerned, it an't going to delegate any more to = the RIRs.

Yes, but = movement of assignments is possible in the other direction.  It is = also not
inconceivable that the IETF might someday direct = changes with respect to some
of the more esoteric regions of = IPv4 address space (multicast, class E)

In any = case, the present state of one of the general purpose spaces (IPv4) = should
not materially impact the framework of the system used = for IPv4, IPv6, and ASNs
(both 2 and 4 = byte).

Making IP address space allocations from the = IETF-reserved areas is a function I would consider part of IANA-IETF. = The only part I would split off is the part that is allocating to the = RIRs.
 
> I don't think IANA-IP could remove = accreditation from a RIR by starving them of IPv6 assignment space. The = five RIRs all have a /12 assigned which is 2^52 possible = networks.

One of the questions we face is what to do if any of = the RIRs or ICANN were to be
captured by interests which clearly do = not represent the served community.

You = mean if one of the CEOs raises rates and buys themselves a huge yacht. =

Hey, ARIN has a = community suggestion process, let me know if you need a = pointer
to it...  ;-) =   

(At ARIN, we've actually lowered = member fees 4 or 5 times over the years, and = strive 
 to be very lean...    no budget = for yachts or black helicopters allowed = :-)

Not actually beyond possibility given the = political norms in some of these places. The World Cup is currently = having a bribery scandal very similar to the SLC = olympics. 

I would say it is a virtual = certainly something of the sort will occur at some time. There are five = RIRs and thus five opportunities. The question would be the extent to = which the RIRs respected expectations of exclusivity and whether default = by one led to a domino effect.

My grandfather = ran a building society which is the UK equivalent of the savings and = loans. After he retired there was a craze for demutualization of the = building societies and today the one he ran is one of the few left. Only = a few of the others exist in any form. Most were bought by the large = banks or amalgamated to form banks like the Bradford and Bingley that = were the primary cause of the UK banking collapse.The B&B had a 150 = year history as a mutual before is demutualized in 2000. It lasted only = seven years as a bank. But the management did extremely well from = running it into the ground they paid themselves millions for doing = so.

And of course anyone who pointed out the = likely outcome of such schemes was a dirty hippie. The account holders = loved getting paid free money for losing their mutual ownership. The = shareholders initially got a bump in their share price after the = IPO. 

I am = a strong believer that there should be something external to the RIRs = and ICANN
to serve as a deterrent from such occurring.   = While I have enormous respect for the
folks involved in = running these organizations, it is not possible to know what the = coming
decades will hold.

 In the
most = extreme case, there could be a need at some point to duplicate all of = the existing
registry data and then designate a replacement = organization (the reality is probably
that there only needs to be the = potential to do such; it's visible existence alone serves
as a strong = deterrent against capture.)

True, = but I don't think that is something that necessarily needs to be vested = in ICANN or IANA. Since the records are public, any party could archive = them. The question then goes to whether the archives are to be believed = to be accurate.

Which is why I keep proposing = we have a Harber-Stornetta style notary service for the = Internet...

Long = road from theory to practice...
 
> So acknowledging that = the power is negligible, I suggest folding IANA-IP into ICANN but with = the proviso that IANA only has control over the blocks that have been = specifically allocated to it. This effectively leaves 7/8ths of the = address space in the hands of the IETF.

That is effectively the = current situation.

Correct. I am not = suggesting any change in what happens. I am only suggesting that instead = of the IANA being gold plated and having everyone think that it is solid = gold and worth stealing we paint it a different colour that attracts = less = attention.

The = reality is that the IETF has a vested interest in a healthy registry = system.  I do appreciate
the appeal of turning the other = way, closing one's eyes and ears, and going "no no no, not = our
job", but do think it is preferential to proactively = engage and define the relationship in a way that
says that = policy authority for the general-purpose space _has been delegated_ and = unless a list
of certain clear conditions occur (e.g. finding = that the org is no  longer representing the = served 
community by an independent third-party review = process, such as ICANN's ATRT review), then
it is not the = IETF's issue.  This is the type of thing that you could put in a = contract (e.g. 2860) 
such that no party would bother the = IETF, knowing it has _zero role_ except and unless = the
existing general-purpose registry organizations have = provably failed.

FYI,
/John

Disclaimer: My views alone. 

= --Apple-Mail=_1768F607-E132-4D27-91CD-193C5BF83B94-- From nobody Fri Jun 13 12:07:33 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 439D11B27EF for ; Fri, 13 Jun 2014 12:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2Z1VljyjMk4 for ; Fri, 13 Jun 2014 12:07:28 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E1141B2947 for ; Fri, 13 Jun 2014 12:07:27 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id t60so3207606wes.18 for ; Fri, 13 Jun 2014 12:07:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=NoOmUKXM/q48ibWMflXtCs2diSRdwizSkzBzKXyEFiA=; b=IJFXK5Q5o3mOIcNugt/ZHeFyo5a032XLqK8mgUYWse8VDWqcVZlD8Bj1uC6JVdOxv4 gfYlFAQuxSr1bW/vThOScRrx0KLUMXXa5HcR2MQ45Rx6x8EsyeAD/NHjpeflB93VtfXF lkoAPR8wcdF8L4T7rAz/atjY77v6T+MNrKnDQZPD36OBanG6p3OI3Ng4TeLhTMkMZ6Y3 jJptKckaAH3GBmYE6QiRUOj5YQlnz39W8jPSIHjnOGgleYMDMv1brdCh3RQDIrumqU6t YBY9hj1ddjss/aTHdya1HTPsaatD8aZ/hiMMJe9Eh+SxHyIB8QOSfYCnANTiHyRPqlbz O5Cg== MIME-Version: 1.0 X-Received: by 10.180.207.9 with SMTP id ls9mr7289816wic.32.1402686445386; Fri, 13 Jun 2014 12:07:25 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.79.136 with HTTP; Fri, 13 Jun 2014 12:07:25 -0700 (PDT) In-Reply-To: References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <2963BB17-E425-46A9-A6CF-EE95C63B4626@istaff.org> <79BC0637-22AE-46ED-A70C-C57446FC6511@virtualized.org> <20140612085707.B7DB68B73A4@mail-04-pao.dyndns.com> <05921299-0B65-458B-AD75-AE22B84ED4DE@istaff.org> <20140612171952.3C7C71B2AB0@ietfa.amsl.com> <6B3C7C0E-073B-4071-AEC1-C09E788FE239@istaff.org> <20140613120407.5CEEA44B5EE@mail-14-pao.dyndns.com> <6350D89F-DF33-433F-BE26-6BD58AC3515C@istaff.org> <146D5D34-5765-460A-8BF1-A73CCF8D4481@istaff.org> Date: Fri, 13 Jun 2014 15:07:25 -0400 X-Google-Sender-Auth: 0kDe-BLXQU3x2jIisyvfJWCFmBE Message-ID: From: Phillip Hallam-Baker To: John Curran Content-Type: multipart/alternative; boundary=001a11c3cdc04f064a04fbbc6379 Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/UEMuLcyvS4h9yqzhRjGIx-xayM8 Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 19:07:31 -0000 --001a11c3cdc04f064a04fbbc6379 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 13, 2014 at 2:35 PM, John Curran wrote: > On Jun 13, 2014, at 2:11 PM, Phillip Hallam-Baker > wrote: > > On Fri, Jun 13, 2014 at 1:43 PM, John Curran wrote: > >> On Jun 13, 2014, at 12:43 PM, Phillip Hallam-Baker >> wrote: >> >> > As a clarifying matter could we separate out discussion of IANA-IP and >> IANA-IETF? >> >> Umm.. There is only one 32-bit address space, and it has both the IETF >> making >> specialized reservations and the RIRs making general-purpose assignments >> from >> that space. The entire space is published via various protocols that >> require there >> be coordination (whois, reverse DNS, RPKI) >> > > The RIRs cannot allocate from the space IETF might allocate from, they are > already reserved to IETF. > > > Not in practice... we've already had occasions of IPv4 space moving from > RIRs > to IANA entirely for the purpose of satisfying an IETF technical > reservation. > That would not be necessary if the need was anticipated. > IPv4 is all gone as far as IANA-IP is concerned, it an't going to delegate > any more to the RIRs. > > > Yes, but movement of assignments is possible in the other direction. It > is also not > inconceivable that the IETF might someday direct changes with respect to > some > of the more esoteric regions of IPv4 address space (multicast, class E) > Which would still be possible without IANA-IETF being IANA-IP. All it would require is that IANA-IETF requests the assignment and it is granted by at least one RIR. The same thing could happen with TLDs. ICANN was all set to issue .corp at one point. They didn't because it was pointed out that it is effectively assigned already. > In any case, the present state of one of the general purpose spaces (IPv4) > should > not materially impact the framework of the system used for IPv4, IPv6, and > ASNs > (both 2 and 4 byte). > I don't thibnk we need to worry about IANA-IPv4, that is all done. The only IPv4 assignments to come will be from reserved and unroutable spaces. And if IETF needs more IPv4 space for whatever reason it is no better off than anyone else. > I am a strong believer that there should be something external to the RIRs > and ICANN > to serve as a deterrent from such occurring. While I have enormous > respect for the > folks involved in running these organizations, it is not possible to know > what the coming > decades will hold. > Exactly. Nobody wanted to suggest possible problems with ICANN because we all trusted Jon Postel. But we didn't get Jon. I remember going round with my grandfather to look at houses that the society was being asked to raise a mortgage on. Now this was the CEO/Chairman mind you of a fairly large bank with a dozen branches personally checking that there was a house behind every loan. One of the reasons B&B went bust is that they lent money on houses that never existed or didn't belong to the person they gave the money to. > True, but I don't think that is something that necessarily needs to be > vested in ICANN or IANA. Since the records are public, any party could > archive them. The question then goes to whether the archives are to be > believed to be accurate. > > Which is why I keep proposing we have a Harber-Stornetta style notary > service for the Internet... > > > Long road from theory to practice... > It will take a decade probably. > > So acknowledging that the power is negligible, I suggest folding IANA-IP >> into ICANN but with the proviso that IANA only has control over the blocks >> that have been specifically allocated to it. This effectively leaves 7/8ths >> of the address space in the hands of the IETF. >> >> That is effectively the current situation. >> > > Correct. I am not suggesting any change in what happens. I am only > suggesting that instead of the IANA being gold plated and having everyone > think that it is solid gold and worth stealing we paint it a different > colour that attracts less attention. > > > The reality is that the IETF has a vested interest in a healthy registry > system. I do appreciate > the appeal of turning the other way, closing one's eyes and ears, and > going "no no no, not our > job", but do think it is preferential to proactively engage and define the > relationship in a way that > says that policy authority for the general-purpose space _has been > delegated_ and unless a list > of certain clear conditions occur (e.g. finding that the org is no longer > representing the served > community by an independent third-party review process, such as ICANN's > ATRT review), then > it is not the IETF's issue. This is the type of thing that you could put > in a contract (e.g. 2860) > such that no party would bother the IETF, knowing it has _zero role_ > except and unless the > existing general-purpose registry organizations have provably failed. > > Well another approach would be to dramatically strip back the scope for which IANA assignments are required and what it needs to do for them. For example, right now we have hundreds of separate registries for application layer strings. But even though it is possible in theory for FOO to mean X in the context of HTTP and something else in the context of SMTP, we all recognize that would be silly and avoid overlaps. So in practice we could manage with only one first come first served registry for strings since the assignment space is practically unlimited. That is obviously not true at the lower levels and where fixed length numeric tags are used but it is almost so. --001a11c3cdc04f064a04fbbc6379 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Jun 13, 2014 at 2:35 PM, John Curran <= jcurran@istaff.org<= /a>> wrote:

On Fri, Jun 13, 2014 at 1:43 PM, John Curran=C2= =A0<jcurran@istaff.org>=C2=A0wrote:
On Jun 13, 2014, at 12:43 PM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:=

> As a clarifying matter could we separate out discussion of IAN= A-IP and IANA-IETF?

Umm.. =C2=A0There is only one 32-bit address space, and it has both the= IETF making
specialized reservations and the RIRs making general-purpos= e assignments from
that space. =C2=A0The entire space is published via v= arious protocols that require there
be coordination (whois, reverse DNS, RPKI)

<= div>The RIRs cannot allocate from the space IETF might allocate from, they = are already reserved to IETF.

Not in practice... we've already had occasions of IPv4 = space moving from RIRs
to IANA entirely for the purpose of satisf= ying an IETF technical reservation.

That would not be necessary if the need was anticipated.=C2=A0


=C2=A0
IPv4 is all gone= as far as IANA-IP is concerned, it an't going to delegate any more to = the RIRs.

Yes, but= movement of assignments is possible in the other direction. =C2=A0It is al= so not
inconceivable that the IETF might someday direct changes with respect = to some
of the more esoteric regions of IPv4 address space (multi= cast, class E)

Which would stil= l be possible without IANA-IETF being IANA-IP. All it would require is that= IANA-IETF requests the assignment and it is granted by at least one RIR.

The same thing could happen with TLDs. ICANN was all se= t to issue .corp at one point. They didn't because it was pointed out t= hat it is effectively assigned already.

=C2=A0
In = any case, the present state of one of the general purpose spaces (IPv4) sho= uld
not materially impact the framework of the system used for IPv4, IPv6,= and ASNs
(both 2 and 4 byte).

<= /div>
I don't thibnk we need to worry about IANA-IPv4, that is all = done. The only IPv4 assignments to come will be from reserved and unroutabl= e spaces. And if IETF needs more IPv4 space for whatever reason it is no be= tter off than anyone else.

=C2=A0
I am a strong believer that there shoul= d be something external to the RIRs and ICANN
to serve as a deterrent from such occurring. =C2=A0 While I have enorm= ous respect for the
folks involved in running these organizations= , it is not possible to know what the coming
decades will hold.

Exactly. Nobody wanted to sugg= est possible problems with ICANN because we all trusted Jon Postel. But we = didn't get Jon.

I remember going round with my= grandfather to look at houses that the society was being asked to raise a = mortgage on. Now this was the CEO/Chairman mind you of a fairly large bank = with a dozen branches personally checking that there was a house behind eve= ry loan.

One of the reasons B&B went bust is that they lent = money on houses that never existed or didn't belong to the person they = gave the money to.=C2=A0


T= rue, but I don't think that is something that necessarily needs to be v= ested in ICANN or IANA. Since the records are public, any party could archi= ve them. The question then goes to whether the archives are to be believed = to be accurate.

Which is why I keep proposing we have a Harber-Stornett= a style notary service for the Internet...

Long road from theory to practice...

It will take a decade probably.

=C2=A0
>= So acknowledging that the power is negligible, I suggest folding IANA-IP i= nto ICANN but with the proviso that IANA only has control over the blocks t= hat have been specifically allocated to it. This effectively leaves 7/8ths = of the address space in the hands of the IETF.

That is effectively the current situation.

Correct. I am not suggesting any change in what happens. I am only = suggesting that instead of the IANA being gold plated and having everyone t= hink that it is solid gold and worth stealing we paint it a different colou= r that attracts less attention.

The reality is tha= t the IETF has a vested interest in a healthy registry system. =C2=A0I do a= ppreciate
the appeal of turning the other way, closing one's = eyes and ears, and going "no no no, not our
job", but do think it is preferential to proactively engage and d= efine the relationship in a way that
says that policy authority f= or the general-purpose space _has been delegated_ and unless a list
of certain clear conditions occur (e.g. finding that the org is no =C2= =A0longer representing the served=C2=A0
community by an independe= nt third-party review process, such as ICANN's ATRT review), then
=
it is not the IETF's issue. =C2=A0This is the type of thing that y= ou could put in a contract (e.g. 2860)=C2=A0
such that no party would bother the IETF, knowing it has _zero role_ e= xcept and unless the
existing general-purpose registry organizati= ons have provably failed.


Well another approach would b= e to dramatically strip back the scope for which IANA assignments are requi= red and what it needs to do for them.

For example, right now we have hundreds of separate reg= istries for application layer strings. But even though it is possible in th= eory for FOO to mean X in the context of HTTP and something else in the con= text of SMTP, we all recognize that would be silly and avoid overlaps.

So in practice we could manage with only one first come= first served registry for strings since the assignment space is practicall= y unlimited.

That is obviously not true at the low= er levels and where fixed length numeric tags are used but it is almost so.=
--001a11c3cdc04f064a04fbbc6379-- From nobody Fri Jun 13 13:37:23 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34E351B280A for ; Fri, 13 Jun 2014 13:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aW5kFjLqPJGD for ; Fri, 13 Jun 2014 13:37:15 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 614F61A029A for ; Fri, 13 Jun 2014 13:37:15 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id bj1so708879pad.9 for ; Fri, 13 Jun 2014 13:37:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hw2Tt0uM4s3eQUdR6r/mVtWcEHOY0zc8b3ql+6QpKsw=; b=tGUQ7Ryzu4PIiA+rXdFNStDRSvQrA8uCXz52SbZMmNhTjr7xh6kI+HLlZaO9tQGWpr tZ1GDoPBATSpPKeMPCUdOn1KW2kvpEc+byYzuVYUNLEoGucgnmORhA79C7oKYQXSWq7M jhslLF5cXzeXXrJFiBBYR8RByWv/LpoAIRYyTvXhJ/rYW/MDBN6RUpjPl/iBhw5yRjZ6 2xETUYWPGBFSxtspTMRa6IrTYqrUmYpYeJnlVufetrJu/IjDWlQwR1mB80L88eX4GZYP aNYz6W+NOYpiQYqpj6AwazG1CmGsICm1LamVyrO5SKo3Joq8l0w4Ob1jaohZZ3ApOYL7 UyOw== X-Received: by 10.66.132.70 with SMTP id os6mr6051037pab.110.1402691834073; Fri, 13 Jun 2014 13:37:14 -0700 (PDT) Received: from [192.168.178.23] (115.199.69.111.dynamic.snap.net.nz. [111.69.199.115]) by mx.google.com with ESMTPSA id ix7sm5181901pbd.36.2014.06.13.13.37.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Jun 2014 13:37:13 -0700 (PDT) Message-ID: <539B6104.4030407@gmail.com> Date: Sat, 14 Jun 2014 08:37:24 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Phillip Hallam-Baker References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <2963BB17-E425-46A9-A6CF-EE95C63B4626@istaff.org> <79BC0637-22AE-46ED-A70C-C57446FC6511@virtualized.org> <20140612085707.B7DB68B73A4@mail-04-pao.dyndns.com> <05921299-0B65-458B-AD75-AE22B84ED4DE@istaff.org> <20140612171952.3C7C71B2AB0@ietfa.amsl.com> <6B3C7C0E-073B-4071-AEC1-C09E788FE239@istaff.org> <20140613120407.5CEEA44B5EE@mail-14-pao.dyndns.com> <6350D89F-DF33-433F-BE26-6BD58AC3515C@istaff.org> <146D5D34-5765-460A-8BF1-A73CCF8D4481@istaff.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/MA07j2OVHyHVa4UkZesrKmqUsYQ Cc: John Curran , internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 20:37:20 -0000 Phill, On 14/06/2014 07:07, Phillip Hallam-Baker wrote: ... >>>> As a clarifying matter could we separate out discussion of IANA-IP and >>>> IANA-IETF? John and Andrew have done all the hard work of pointing out the reasons why this would be a step backwards; and I don't see why anything needs clarification. What we separated out in 2000 was *policy issues* for assignment of IP address blocks. That is quite distinct from the mechanics of maintaining a large sheet of squared paper with address allocations written on it, and we have 15 years experience that it's completely clear. Brian From nobody Fri Jun 13 13:55:54 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05211B2930 for ; Fri, 13 Jun 2014 13:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwwEj4rmP4-F for ; Fri, 13 Jun 2014 13:55:50 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E62E21A025A for ; Fri, 13 Jun 2014 13:55:49 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WvYTv-000G8V-7A; Fri, 13 Jun 2014 16:53:51 -0400 Date: Fri, 13 Jun 2014 16:55:43 -0400 From: John C Klensin To: Phillip Hallam-Baker Message-ID: <84A9C7C16688E8BF106ED74D@JcK-HP8200.jck.com> In-Reply-To: References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <2963BB17-E425-46A9-A6CF-EE95C63B4626@istaff.org> <79BC0637-22AE-46ED-A70C-C57446FC6511@virtualized.org> <20140612085707.B7DB68B73A4@mail-04-pao.dyndns.com> <05921299-0B65-458B-AD75-AE22B84ED4DE@istaff.org> <20140612171952.3C7C71B2AB0@ietfa.amsl.com> <6B3C7C0E-073B-4071-AEC1-C09E788FE239@istaff.org> <20140613120407.5CEEA44B5EE@mail-14-pao.dyndns.com> <6350D89F-DF33-433F-BE26-6BD58AC3515C@istaff.org> <146D5D34-5765-460A-8BF1-A73CCF8D4481@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 X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/F4Izh7hrKDlggly5eVt_rJsEJuk Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 20:55:51 -0000 --On Friday, June 13, 2014 15:07 -0400 Phillip Hallam-Baker wrote: > For example, right now we have hundreds of separate registries > for application layer strings. But even though it is possible > in theory for FOO to mean X in the context of HTTP and > something else in the context of SMTP, we all recognize that > would be silly and avoid overlaps. Does the same principle apply to the implications of the string "URL" when used in the IETF, in WHATWG or HTML5, the semantic web, or in several other contexts including possibly a distinction between "in an HTML file" and "on the wire in various HTTP contexts and elsewhere"? If so, "we all recognize.. and avoid overlaps" might be a bit of a stretch. > So in practice we could manage with only one first come first > served registry for strings since the assignment space is > practically unlimited. Sigh. Exactly the same argument could be made about domain names: the space is at least very large laterally and, given that the DNS is hierarchical, the total space is essentially unlimited. But many people have insisted that names have value, that some names are more valuable than others, and then have constructed business based on those two assertions. Looking at the issues more broadly than the Internet, the existence of trademarks and other mechanisms are, IMO, evidence that, in a practically unlimited assignment space, FCFS is insufficient to avoid conflicts and, ultimately, the need for a process that decides who wins and who loses. john From nobody Sat Jun 14 02:57:36 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A751B2C0D for ; Sat, 14 Jun 2014 02:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6JVEe4xb6tf for ; Sat, 14 Jun 2014 02:57:34 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4161B2C06 for ; Sat, 14 Jun 2014 02:57:33 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.141.167]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s5E9vGQO018495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Jun 2014 02:57:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1402739849; x=1402826249; bh=sFPWDJCPwebu+9qjyfdISefn1ejtlXTjuWwEFSVM498=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=LEUYM9nF49dQqaOA2XfF1iVtrAvC9eUxe3fNpgo0efvVRV6aICwWw34TStSWN0/mb zTg0MBVI375MXIe/Iz91d5Z58/R7M0gNM0attzhTkdjzCy2lcqxWpsX8kaV4I2KqZi mjVAYBS6dM8srWkK0Ee/yQhVLNTaRBMAXlXD9EkI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1402739849; x=1402826249; i=@elandsys.com; bh=sFPWDJCPwebu+9qjyfdISefn1ejtlXTjuWwEFSVM498=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=dep5Rlbxd1Wm5gvfBNqA7xncNYeAX/Lf8cj0KZJD/exVi2gFYARhdPCAdc/pRbQrt w9NdtWsaW0e21Ak99cO3/hvZAOt4PTeUpvBJWq3t0u7Wc3y88rNs+VcSwqpI0PG9MM QCUAo0P1DZmFCqE8g8LoWnR0lvT1oUQsjFtQ1We4= Message-Id: <6.2.5.6.2.20140613130028.0d55c378@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 13 Jun 2014 15:28:05 -0700 To: Phillip Hallam-Baker From: S Moonesamy In-Reply-To: References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <3EAE63E7BADB8EBCA546F041@JcK-HP8200.jck.com> <55AAA4B3-94BE-473F-9146-7AD63270BA9C@nominum.com> <08F218C8-68B7-4499-A027-B4E788A3B30E@gmail.com> <20140609160101.GJ27145@mx1.yitter.info> <6.2.5.6.2.20140609102339.0c96d658@resistor.net> <77C8D2D2-334C-419A-AF1E-75AC2458C16F@virtualized.org> <6.2.5.6.2.20140609115341.0af8bf88@elandnews.com> <53976FDB.7060307@abenaki.wabanaki.net> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <2963BB17-E425-46A9-A6CF-EE95C63B4626@istaff.org> <79BC0637-22AE-46ED-A70C-C57446FC6511@virtualized.org> <20140612085707.B7DB68B73A4@mail-04-pao.dyndns.com> <05921299-0B65-458B-AD75-AE22B84ED4DE@istaff.org> <20140612171952.3C7C71B2AB0@ietfa.amsl.com> <6B3C7C0E-073B-4071-AEC1-C09E788FE239@istaff.org> <20140613120407.5CEEA44B5EE@mail-14-pao.dyndns.com> <6350D89F-DF33-433F-BE26-6BD58AC3515C@istaff.org> <146D5D34-5765-460A-8BF1-A73CCF8D4481@istaff.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/w4MIOL6iligbhlTnQJxV7n3xfZg Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 09:57:34 -0000 Hi Phillip, At 12:07 13-06-2014, Phillip Hallam-Baker wrote: >Well another approach would be to dramatically strip back the scope >for which IANA assignments are required and what it needs to do for them. The percentage of identifiers assigned to the IETF is very low. It is easy for anyone to verify that as the information is publicly available. >For example, right now we have hundreds of separate registries for >application layer strings. But even though it is possible in theory >for FOO to mean X in the context of HTTP and something else in the >context of SMTP, we all recognize that would be silly and avoid overlaps. I would consider the above as a separate question. As a matter of individual opinion [1] I'd say that the reviews for some of the registry guidelines could have been better. A glimpse at the (IETF) mailing list archives would show whether people are that interested in the matter. I don't think that people writing software worry about overlap. Regards, S. Moonesamy 1. It is based on hindsight. From nobody Tue Jun 17 03:17:47 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136B91A0340 for ; Tue, 17 Jun 2014 03:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ufosIvGenqx for ; Tue, 17 Jun 2014 03:17:42 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC601A0341 for ; Tue, 17 Jun 2014 03:17:40 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id A08E232E557; Tue, 17 Jun 2014 19:17:39 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 2d13_3750_2ba66321_f0dd_4fe4_8fbe_76adc493e0d0; Tue, 17 Jun 2014 19:17:38 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id B2CB1BF4E2; Tue, 17 Jun 2014 19:17:38 +0900 (JST) Message-ID: <53A015A4.5010701@it.aoyama.ac.jp> Date: Tue, 17 Jun 2014 19:17:08 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John C Klensin , Phillip Hallam-Baker References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <5397A7C7.9050907@gmail.com> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <2963BB17-E425-46A9-A6CF-EE95C63B4626@istaff.org> <79BC0637-22AE-46ED-A70C-C57446FC6511@virtualized.org> <20140612085707.B7DB68B73A4@mail-04-pao.dyndns.com> <05921299-0B65-458B-AD75-AE22B84ED4DE@istaff.org> <20140612171952.3C7C71B2AB0@ietfa.amsl.com> <6B3C7C0E-073B-4071-AEC1-C09E788FE239@istaff.org> <2 0140613120407.5CEEA44B5EE@mail-14-pao.dyndns.com> <6350D89F-DF33-433F-BE26-6BD58AC3515C@istaff.org> <146D5D34-5765-460A-8BF1-A73CCF8D4481@istaff.org> <84A9C7C16688E8BF106ED74D@JcK-HP8200.jck.com> In-Reply-To: <84A9C7C16688E8BF106ED74D@JcK-HP8200.jck.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/Zux0wcoXIsulAqv4cpVPx8pOTLw Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 10:17:45 -0000 On 2014/06/14 05:55, John C Klensin wrote: > --On Friday, June 13, 2014 15:07 -0400 Phillip Hallam-Baker > wrote: > >> For example, right now we have hundreds of separate registries >> for application layer strings. But even though it is possible >> in theory for FOO to mean X in the context of HTTP and >> something else in the context of SMTP, we all recognize that >> would be silly and avoid overlaps. > > Does the same principle apply to the implications of the string > "URL" when used in the IETF, in WHATWG or HTML5, the semantic > web, or in several other contexts including possibly a > distinction between "in an HTML file" and "on the wire in > various HTTP contexts and elsewhere"? If so, "we all > recognize.. and avoid overlaps" might be a bit of a stretch. Well, or the distinction between a HTTP GET request (returning an actual representation) and an HTTP HEAD request (returning just the length,... of such a representation). In linguistic terms, it's the same object but with different verbs applied. The string "URL" is just three letters in some specs. There's confusion among spec writers and spec readers when the same three letters are used with slightly different meanings, but the running code isn't affected too much, except in edge cases. Regards, Martin. From nobody Tue Jun 17 03:39:26 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA541A0340 for ; Tue, 17 Jun 2014 03:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.852 X-Spam-Level: X-Spam-Status: No, score=-9.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LscpvktxL6gn for ; Tue, 17 Jun 2014 03:39:18 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85FC31A0342 for ; Tue, 17 Jun 2014 03:39:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=346; q=dns/txt; s=iport; t=1403001557; x=1404211157; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=7HHcFXpN4uW1mEPs+oVAf1zuCopS02Pc43cLlRDgs08=; b=VKtuHiz7riB+3f5pqnHpLExNtW2u55f3oOE5LVLZ+ftn45YLl+37gkM3 XmzpuAmroccx70xrkMUBlLYiyy/7b/UVFozlijHjZv1uzdt3/QuArzots CD1yQDZmtuDGLaVhcfxFB4nb6yRh/Z9cy311AQMI2Rgxeq7L9VvbcamD+ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioGAJsZoFOtJssW/2dsb2JhbABaDocXpxEBAQEBAQEFAZkdCQGBInWEBAEBBCNVARALGgIFFgQHAgIJAwIBAgFFBgEMAQcBAYg+rSyeKxeBKoQ5iRMHgneBTAEDmkOTWIF+gQBEOw X-IronPort-AV: E=Sophos;i="5.01,493,1400025600"; d="scan'208";a="88512154" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 17 Jun 2014 10:39:15 +0000 Received: from ELEAR-M-C3ZS.CISCO.COM ([10.61.174.132]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s5HAdFrL026497; Tue, 17 Jun 2014 10:39:15 GMT Message-ID: <53A01AD3.4080509@cisco.com> Date: Tue, 17 Jun 2014 12:39:15 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , John C Klensin , Phillip Hallam-Baker References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <2963BB17-E425-46A9-A6CF-EE95C63B4626@istaff.org> <79BC0637-22AE-46ED-A70C-C57446FC6511@virtualized.org> <20140612085707.B7DB68B73A4@mail-04-pao.dyndns.com> <05921299-0B65-458B-AD75-AE22B84ED4DE@istaff.org> <20140612171952.3C7C71B2AB0@ietfa.amsl.com> <6B3C7C0E-073B-4071-AEC1-C09E788FE239@istaff.org> <2 0140613120407.5CEEA44B5EE@mail-14-pao.dyndns.com> <6350D89F-DF33-433F-BE26-6BD58AC3515C@istaff.org> <146D5D34-5765-460A-8BF1-A73CCF8D4481@istaff.org> <84A9C7C16688E8BF106ED74D@JcK-HP8200.jck.com> <53A015A4.5010701@it.aoyama.ac.jp> In-Reply-To: <53A015A4.5010701@it.aoyama.ac.jp> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/mcoDlLXX9f4_GCMHLt8W52HbdJw Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 10:39:22 -0000 Code points only have value in the context in which they are defined. It is absolutely possible to define a shared registry, so long as the rules of the registry are amenable to each of the specific uses. The IP address is an example of such a shared registry. But I would hazard a guess that's the exception more than the rule. Eliot From nobody Tue Jun 17 12:07:53 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 468AF1A0159 for ; Tue, 17 Jun 2014 12:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FSL_HELO_BARE_IP_2=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F57QjL9R3L-4 for ; Tue, 17 Jun 2014 12:07:51 -0700 (PDT) Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com [67.18.15.8]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 648261A00C0 for ; Tue, 17 Jun 2014 12:07:51 -0700 (PDT) Received: by gateway09.websitewelcome.com (Postfix, from userid 507) id 88B6AA78395A0; Tue, 17 Jun 2014 14:07:50 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway09.websitewelcome.com (Postfix) with ESMTP id ADF6BA78392BA for ; Tue, 17 Jun 2014 14:07:49 -0500 (CDT) Received: from [96.231.225.192] (port=51172 helo=192.168.1.4) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WwyjU-0003k7-L5; Tue, 17 Jun 2014 14:07:48 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Sean Turner In-Reply-To: <53A01AD3.4080509@cisco.com> Date: Tue, 17 Jun 2014 15:07:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <75E7A41B-9056-44B4-983C-D8FE7011E477@ieca.com> References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <51E80250-B953-44D3-A65E-F64069321F03@virtualized.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <2963BB17-E425-46A9-A6CF-EE95C63B4626@istaff.org> <79BC0637-22AE-46ED-A70C-C57446FC6511@virtualized.org> <20140612085707.B7DB68B73A4@mail-04-pao.dyndns.com> <05921299-0B65-458B-AD75-AE22B84ED4DE@istaff.org> <20140612171952.3C7C71B2AB0@ietfa.amsl.com> <6B3C7C0E-073B-4071-AEC1-C09E788FE239@istaff.org> <2 0140613120407.5CEEA44B5EE@mail-14-pao.dyndns.com> <6350D89F-DF33-433F-BE26-6BD58AC3515C@istaff.org> <146D5D34-5765-460A-8BF1-A73CCF8D4481@istaff.org> <84A9C7C16688E8BF106ED74D@JcK-HP8200.jck.com> <53A015A4.5010701@it.aoyama.ac.jp> <53A01AD3.4080509@ cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.1878.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.225.192 X-Exim-ID: 1WwyjU-0003k7-L5 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.4) [96.231.225.192]:51172 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/YiCf70wp4UGXY4u1sg-EM11-8h4 Cc: John C Klensin , =?windows-1252?Q?=22Martin_J=2E_D=FCrst=22?= , Phillip Hallam-Baker , internetgovtech@iab.org Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 19:07:52 -0000 On Jun 17, 2014, at 06:39, Eliot Lear wrote: > Code points only have value in the context in which they are defined.=20= > It is absolutely possible to define a shared registry, so long as the > rules of the registry are amenable to each of the specific uses. The = IP > address is an example of such a shared registry. But I would hazard a > guess that's the exception more than the rule. >=20 > Eliot Well there=92s been cases where code points assigned for one context got = adopted in another and then the new context wanted to add values to the = registry but the original context wasn=92t thrilled about it. = Personally, I=92d avoid shared registries if at all possible, because = most registries are cheap. spt= From nobody Tue Jun 17 21:39:57 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F671A0172 for ; Tue, 17 Jun 2014 21:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.579 X-Spam-Level: X-Spam-Status: No, score=0.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-TiHkUlLFK5 for ; Tue, 17 Jun 2014 21:39:54 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id C942B1A00AD for ; Tue, 17 Jun 2014 21:39:53 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id E567732E561 for ; Wed, 18 Jun 2014 13:39:51 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 28a1_8968_f53730b9_e360_4f31_b94b_9741958ac90b; Wed, 18 Jun 2014 13:39:51 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 4BD97BF4BA for ; Wed, 18 Jun 2014 13:39:51 +0900 (JST) Message-ID: <53A11806.4060007@it.aoyama.ac.jp> Date: Wed, 18 Jun 2014 13:39:34 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 CC: internetgovtech@iab.org References: <90B42437-9C59-41ED-83C1-94DA1E58237D@ietf.org> <5397B40C.60509@gmail.com> <5397BBE6.40604@abenaki.wabanaki.net> <2963BB17-E425-46A9-A6CF-EE95C63B4626@istaff.org> <79BC0637-22AE-46ED-A70C-C57446FC6511@virtualized.org> <20140612085707.B7DB68B73A4@mail-04-pao.dyndns.com> <05921299-0B65-458B-AD75-AE22B84ED4DE@istaff.org> <20140612171952.3C7C71B2AB0@ietfa.amsl.com> <6B3C7C0E-073B-4071-AEC1-C09E788FE239@istaff.org> <2 0140613120407.5CEEA44B5EE@mail-14-pao.dyndns.com> <6350D89F-DF33-433F-BE26-6BD58AC3 515C@istaff.org> <146D5D34-5765-460A-8BF1-A73CCF8D4481@istaff.org> <84A9C7C16688E8BF106ED74D@JcK-HP8200.jck.com> <53A015A4.5010701@it.aoyama.ac.jp> <53A01AD3.4080509@ cisco.com> <75E7A41B-9056-44B4-983C-D8FE7011E477@ieca. com> In-Reply-To: <75E7A41B-9056-44B4-983C-D8FE7011E477@ieca.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/E7i6sdcHA5yDqQyFnobvmFAGdZA Subject: Re: [Internetgovtech] Coordination Group Members for the Transition of NTIA's Stewardship of the IANA Functions X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 04:39:55 -0000 On 2014/06/18 04:07, Sean Turner wrote: > On Jun 17, 2014, at 06:39, Eliot Lear wrote: > >> Code points only have value in the context in which they are defined. >> It is absolutely possible to define a shared registry, so long as the >> rules of the registry are amenable to each of the specific uses. The = IP >> address is an example of such a shared registry. But I would hazard a >> guess that's the exception more than the rule. >> >> Eliot > > Well there=E2=80=99s been cases where code points assigned for one cont= ext got adopted in another and then the new context wanted to add values = to the registry but the original context wasn=E2=80=99t thrilled about it= . Personally, I=E2=80=99d avoid shared registries if at all possible, be= cause most registries are cheap. There have also been examples that worked out quite well. My standard=20 example would be Message headers, shared by HTTP, mail, and netnews. See http://tools.ietf.org/html/rfc3864,=20 http://www.iana.org/assignments/message-headers/message-headers.xhtml#per= m-headers,=20 http://www.iana.org/assignments/message-headers/message-headers.xhtml#pro= v-headers. Regards, Martin. From nobody Sat Jun 21 11:06:29 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5ED91A03C3; Sat, 21 Jun 2014 11:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Oq2w-vLSNbI; Sat, 21 Jun 2014 11:06:24 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6A641A03AB; Sat, 21 Jun 2014 11:06:23 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s5LI6LN5028107; Sat, 21 Jun 2014 19:06:21 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s5LI6KeI028099 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 21 Jun 2014 19:06:20 +0100 From: "Adrian Farrel" To: , Date: Sat, 21 Jun 2014 19:06:20 +0100 Message-ID: <0ba001cf8d7b$81c1f6a0$8545e3e0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+Ne3+nXJOcUIiRT4WbtQKz3xCqFw== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20772.001 X-TM-AS-Result: No--4.772-10.0-31-10 X-imss-scan-details: No--4.772-10.0-31-10 X-TMASE-MatchedRID: uPdbYrSxZsbAz7IGs/2dj1YIkrFDFO7mEtdrY/Wb3fM7nO9p37Uqk7Yz /RR6JZDspVdMiW33wf/NRKl8tXQsm9UX4QqLU49f04Rmz/agfdzxyOUBQvAZnlVMJlS9HCuzmvF PPubhMtlsSWbHX76Tc5C1FYwsuHudxGtpMtFxybLTzWmGCXkX+RQK/sD1nu4x63iNMMu8u6ujxY yRBa/qJX3mXSdV7KK4OubYLCVnBVFYF3qW3Je6+47xASrNIrdALsQoIsBdX/fHBvR4AHjgehRyq X5kt3ioph9VJDgt7M9vFWy0tXYd+Ea+nxL6lktN9Gy4O62y53UovwM4Byhjduh6vUQky8b7LLR5 nF3ltXgVUhluC41uNBWJz0qF3xvHjd00uZU7WfJ+3BndfXUhXQ== Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/z-zLsUib4tBl72goD-0z5eek1Lc Cc: iesg@ietf.org Subject: [Internetgovtech] Status of selection of IANA NTIA transition representatives by the IESG X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2014 18:06:26 -0000 The IESG (minus any ADs who have put their names in as candidates) continues to consider the appointment of two IETF representatives to the ICANN consultative process on the transition of IANA from NTIA stewardship and thanks all of the people who have put their names forward. Alissa Cooper has been selected as one of the two representatives, and the IESG is still considering all of the other candidates to select a second person. We want to stress that our failure to select a second representative does not reflect badly on the quality of the candidates, but rather results from the care that the IESG is taking over the decision. There is an initial ICANN meeting on this topic in London next week and the IESG will not have made its selection of the second representative in time for the meeting. Therefore, the IESG is delegating Alissa Cooper as the representative of the IETF's interests at that meeting. Jari Arkko will also be in attendance in his role as the IETF Chair and can, of course, speak to IETF concerns as they arise. The IESG plans to resume consideration after the London meeting and make its selection of the second IETF representative before the July 2nd deadline. Thanks, Adrian Farrel for the IESG From nobody Sun Jun 22 11:22:33 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B161B27C5 for ; Sun, 22 Jun 2014 11:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wF8zVm6_AJGq for ; Sun, 22 Jun 2014 11:22:30 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4593C1A02BB for ; Sun, 22 Jun 2014 11:22:30 -0700 (PDT) Received: from 231.74.14.81.rev.sfr.net ([81.14.74.231]:7405 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1WymPL-0007s6-Ti; Sun, 22 Jun 2014 11:22:28 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 22 Jun 2014 20:22:00 +0200 To: adrian@olddog.co.uk,, From: Jefsey In-Reply-To: <0ba001cf8d7b$81c1f6a0$8545e3e0$@olddog.co.uk> References: <0ba001cf8d7b$81c1f6a0$8545e3e0$@olddog.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: jefsey+jefsey.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/8bbXMYjBkqLrGQOmC5GStLp73ko Cc: iesg@ietf.org Subject: Re: [Internetgovtech] Status of selection of IANA NTIA transition representatives by the IESG X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2014 18:22:31 -0000 Dear Adrian, this is an embarassing situation as no one knows who are the candidates, their positions, and the criteria of their selection. Nor, by the way, what the IESG agenda may be concerning the IETF position regarding the ICANN process. IMHO the most appropriate solution for a technical body should be to consider the best and the worst cases and make sure that the technology can cope with both of them, most probably with a delegate being specialized in each extreme case? Otherwise, along RFC 6852, this is encouraging users and operators considering contingency situations where solutions could be asked for, proposed and implemented, "regardless of their formal status". This is exactly the situation where I put myself as a Libre non-profit ISP having to protect the best symetric (inbound/outbound) access to my members. I do not worry too much due to the actual flexibility of the technology but I am definitly sure that the solutions I will implement in case of difficulty will not be those advocated by the ICANNTIA project, as they would be the source of that difficulty. Since many of other operators and users will proceed the same in their own unknown way, some by local regulations or national law, without prior MSist coordination, the result may turn out to be technically operational but politically confuse, and difficult or even impossible to globally concert again. This would then be the end of the IETF as a global body or even worse if the situation degenerated. This kind of situation is scientifically known as "SOC", self-organizing criticality. This is the way nature and history usually work, by way of catastrophes. I think this is a point worth considering, more over than most of the people who will actually take these decisions are not (like me, but this is its own decision) on the IETF list. jfc PS. for your information most of the positions I will take in an a difficult situation will be documented in the French language for my French fellow users. I suppose that other ISPs will proceed in the same manner. Not to consider an ICANNTIA failure and train us in advance may lead to contradict RFC 3935 which states that "The IETF uses the English language for its work is because of its utility for working in a global context." At 20:06 21/06/2014, Adrian Farrel wrote: >The IESG (minus any ADs who have put their names in as candidates) >continues to >consider the appointment of two IETF representatives to the ICANN consultative >process on the transition of IANA from NTIA stewardship and thanks all of the >people who have put their names forward. > >Alissa Cooper has been selected as one of the two representatives, >and the IESG >is still considering all of the other candidates to select a second person. We >want to stress that our failure to select a second representative does not >reflect badly on the quality of the candidates, but rather results >from the care >that the IESG is taking over the decision. > >There is an initial ICANN meeting on this topic in London next week >and the IESG >will not have made its selection of the second representative in time for the >meeting. Therefore, the IESG is delegating Alissa Cooper as the representative >of the IETF's interests at that meeting. Jari Arkko will also be in attendance >in his role as the IETF Chair and can, of course, speak to IETF >concerns as they >arise. > >The IESG plans to resume consideration after the London meeting and make its >selection of the second IETF representative before the July 2nd deadline. > >Thanks, >Adrian Farrel for the IESG > >_______________________________________________ >Internetgovtech mailing list >Internetgovtech@iab.org >https://www.iab.org/mailman/listinfo/internetgovtech From nobody Sun Jun 22 12:17:55 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA29B1A0308; Sun, 22 Jun 2014 12:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.551 X-Spam-Level: X-Spam-Status: No, score=-0.551 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVmt-HBVU1z7; Sun, 22 Jun 2014 12:17:43 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1F8B1A00CD; Sun, 22 Jun 2014 12:17:43 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WynEI-000BXn-NE; Sun, 22 Jun 2014 15:15:06 -0400 Date: Sun, 22 Jun 2014 15:17:31 -0400 From: John C Klensin To: Jefsey , adrian@olddog.co.uk, internetgovtech@iab.org, ietf@ietf.org Message-ID: <0FDAFBF46666EB91ED76F7A7@JcK-HP8200.jck.com> In-Reply-To: <20140622182235.41BC41B27C5@ietfa.amsl.com> References: <0ba001cf8d7b$81c1f6a0$8545e3e0$@olddog.co.uk> <20140622182235.41BC41B27C5@ietfa.amsl.com> 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 X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/TJYGoQkzM-CQIfs_HZsdz36_p4E Cc: iesg@ietf.org Subject: Re: [Internetgovtech] Status of selection of IANA NTIA transition representatives by the IESG X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2014 19:17:46 -0000 --On Sunday, June 22, 2014 20:22 +0200 Jefsey wrote: > Dear Adrian, > > this is an embarassing situation as no one knows who are the > candidates, their positions, and the criteria of their > selection. Nor, by the way, what the IESG agenda may be > concerning the IETF position regarding the ICANN process. IMHO > the most appropriate solution for a technical body should be > to consider the best and the worst cases and make sure that > the technology can cope with both of them, most probably with > a delegate being specialized in each extreme case? Jefsey, I find many things with which I disagree and about which to be concerned in the various pieces of this process. But I don't think Adrian's note identifies a situation about which the IESG or IETF should be embarrassed in any way. I believe that the overall schedule would be very difficult even if ICANN had presented a starting-point plan to the community for tuning and ratification, but they didn't and, as far as I can tell, no one wants that. That leaves the community with an even more difficult schedule and, while I can understand some impatience with delays, I think there are ultimately only two possibilities: (1) This whole initiative isn't going anywhere and, if there is eventually an IANA transition away from the current NTIA oversight model, it will not result from this process and, in particular, from the Coordination Group's efforts. If that is the case, it doesn't make any difference what the IESG does and no one should be concerned about whether or not they do it (except, possibly, about the time they spend discussing it that could be spent in other ways). (2) The initiative is important. In that case, I would much rather have the IESG think carefully about what they want, who they want to do it, and any details they want to work out about relationships, discussing that with each other and, if needed, with possible candidates, rather than do anything hasty in order to get a second person appointed quickly ... especially since I note that several other constituencies haven't announced selections either. And I think we should be pleased, and not embarrassed at all, that they are taking that level of care. > Otherwise, along RFC 6852, this is encouraging users and > operators considering contingency situations where solutions > could be asked for, proposed and implemented, "regardless of > their formal status". I don't see any way in which that would follow, even if I were more confident I understood what you were talking about. > This is exactly the situation where I > put myself as a Libre non-profit ISP having to protect the > best symetric (inbound/outbound) access to my members. It is not clear to me why you think --as I assume from the above that you do-- protecting "best symmetric ... access to your members" has anything to do with IANA, how it is overseen, or any other aspect of this process. Even if it did, it would not be clear to me why you should be seeking representation in the process via the IESG or otherwise feeling that you have standing to complain about what the IESG is or is not doing. > I do not worry too much due to the actual flexibility of the > technology but I am definitly sure that the solutions I will > implement in case of difficulty will not be those advocated by > the ICANNTIA project, as they would be the source of that > difficulty. Since many of other operators and users will > proceed the same in their own unknown way, some by local > regulations or national law, without prior MSist coordination, > the result may turn out to be technically operational but > politically confuse, and difficult or even impossible to > globally concert again. This would then be the end of the IETF > as a global body or even worse if the situation degenerated. >... And now I'm sure I don't understand what you are talking about. Nothing in the NTIA-ICANN-IANA relationship has ever had an influence on IETF protocol decisions (other than as comments from the community). If something causes difficulties in the design or implementation of what you decide to do, it will either be administrative or policy decisions involving your providers or French, EU, or possibly RIPE, but not NTIA or IANA in any direct way. IETF protocol decisions may make it easier or harder to do whatever you intend to do (and, in particular, may influence what you can easily obtain as Common, Off-the-Shelf, hardware or software, but NTIA and IANA don't have much influence over those decisions either... and it has hard to blame the IETF for not facilitating whatever non-conforming things you want to do. And, again, I don't see how you classify or name some aspect of what is going on changes anything. You may have disagreements with decisions the IETF makes and/or the patterns of IETF protocol work. You may want to go off in other directions and may even consider some of those directions to be more true to the spirit of the Internet model than what you see the IETF doing. Whether you would be, by some measure, right or wrong, it still seems to me to have no interaction at all with this NTIA-IANA transition proposal. john From nobody Sun Jun 22 14:20:40 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C311A02BA; Sun, 22 Jun 2014 14:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.001 X-Spam-Level: X-Spam-Status: No, score=-100.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J45D9liqLxes; Sun, 22 Jun 2014 14:20:31 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D30F11A0295; Sun, 22 Jun 2014 14:20:29 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s5MLKRJ0000310; Sun, 22 Jun 2014 22:20:27 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s5MLKQwh032760 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 22 Jun 2014 22:20:27 +0100 From: "Adrian Farrel" To: "'Jefsey'" , , References: <0ba001cf8d7b$81c1f6a0$8545e3e0$@olddog.co.uk> <201406221822.s5MIMUW0010375@mta1.iomartmail.com> In-Reply-To: <201406221822.s5MIMUW0010375@mta1.iomartmail.com> Date: Sun, 22 Jun 2014 22:20:25 +0100 Message-ID: <00b401cf8e5f$c8ea7680$5abf6380$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG6iqpsDMWT8ffEtzBNvKw7amLnugJ5UM1fm5PaJOA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.0.0.1014-20774.002 X-TM-AS-Result: No--11.992-10.0-31-10 X-imss-scan-details: No--11.992-10.0-31-10 X-TMASE-MatchedRID: C/snMIRQLS192uPSQ/uy2GrRghnYv51qC3HuWcgyQCZ9Q5/gynnG1uAm ImeMynMEGuN6OYqG1L8Z5+/CBY4PWdaSgJLPelTmVZ54ioe2EwsL8TGleseLPBsizOQuDf4xr+g 7JvNQo+9ozlC4ypuEFVyQkoWMY0gvy+mf3q0dxCZHcypzEXqVgVxIyn/X4Smnq4c1/8j5pHqkwF TCCpbFRzSiGtn3dqFDg0ba6jw+n/ig0d6GNBKQUO8rvrpD1cllBhfhOps3jagtfh4sRUyg+gEGq FryhDT/1dzFSrJgGNVqT2omj58OwE1fsoLovwOe5VdEYJwEhsDSv+oK79xjnQ8x3RwK3jjFBf7f 3ILP2qoEDX0Lfnqcqo7SOhp1bxAa0RCs70uuPqHcWo5Vvs8MQpWr6iSXWtgP7ynGrUv2DpQzBHK sDHLon5kzCXQMauGmQ1KdtEmw6Jk84uNt4Z+7XZ4CIKY/Hg3AlfGwpNSPVn6+qryzYw2E8M8943 oc3p3sq7rFUcuGp/EgBwKKRHe+rzjjxtyzlw2j8emFrFRJEvJMSta06qk2FK8aAqJcMWstHlfuy zRdC+k= Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/ahRnkIHX9JzL9zVzLb0mTnRSdCQ Cc: iesg@ietf.org Subject: Re: [Internetgovtech] Status of selection of IANA NTIA transition representatives by the IESG X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2014 21:20:34 -0000 Hello JFC, I speak only for myself in my answer. The IETF community was invited to volunteer for these positions. I view the positions as akin to the liaison manage roles usually appointed to by the IAB, and it does not seem to me that the IESG is doing anything unusual in the way it is choosing these representatives. There are email lists on which the subject matter can be discussed in order to get a good view of the concerns and possibly of consensus within the IETF. The representatives being appointed by the IESG are intended to represent the IETF. Adrian > Dear Adrian, > > this is an embarassing situation as no one knows who are the > candidates, their positions, and the criteria of their selection. > Nor, by the way, what the IESG agenda may be concerning the IETF > position regarding the ICANN process. IMHO the most appropriate > solution for a technical body should be to consider the best and the > worst cases and make sure that the technology can cope with both of > them, most probably with a delegate being specialized in each extreme case? > > Otherwise, along RFC 6852, this is encouraging users and operators > considering contingency situations where solutions could be asked > for, proposed and implemented, "regardless of their formal status". > This is exactly the situation where I put myself as a Libre > non-profit ISP having to protect the best symetric (inbound/outbound) > access to my members. > > I do not worry too much due to the actual flexibility of the > technology but I am definitly sure that the solutions I will > implement in case of difficulty will not be those advocated by the > ICANNTIA project, as they would be the source of that difficulty. > Since many of other operators and users will proceed the same in > their own unknown way, some by local regulations or national law, > without prior MSist coordination, the result may turn out to be > technically operational but politically confuse, and difficult or > even impossible to globally concert again. This would then be the end > of the IETF as a global body or even worse if the situation degenerated. > > This kind of situation is scientifically known as "SOC", > self-organizing criticality. This is the way nature and history > usually work, by way of catastrophes. I think this is a point worth > considering, more over than most of the people who will actually take > these decisions are not (like me, but this is its own decision) on > the IETF list. > > jfc > > PS. for your information most of the positions I will take in an a > difficult situation will be documented in the French language for my > French fellow users. I suppose that other ISPs will proceed in the > same manner. Not to consider an ICANNTIA failure and train us in > advance may lead to contradict RFC 3935 which states that "The IETF > uses the English language for its work is because of its utility for > working in a global context." From nobody Mon Jun 23 08:45:36 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDC91B2B46 for ; Mon, 23 Jun 2014 08:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.632 X-Spam-Level: * X-Spam-Status: No, score=1.632 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gzoBRLdTKpC for ; Mon, 23 Jun 2014 08:45:30 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCC7A1B2B4B for ; Mon, 23 Jun 2014 08:45:28 -0700 (PDT) Received: from 231.74.14.81.rev.sfr.net ([81.14.74.231]:21523 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1Wz6Qv-0006PQ-8l; Mon, 23 Jun 2014 08:45:27 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 23 Jun 2014 17:44:54 +0200 To: ,, From: Jefsey In-Reply-To: <00b401cf8e5f$c8ea7680$5abf6380$@olddog.co.uk> References: <0ba001cf8d7b$81c1f6a0$8545e3e0$@olddog.co.uk> <201406221822.s5MIMUW0010375@mta1.iomartmail.com> <00b401cf8e5f$c8ea7680$5abf6380$@olddog.co.uk> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1001550536==.ALT" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: jefsey+jefsey.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/K_g5QYJM4NNmWEAFIpwsBI-iSno Cc: iesg@ietf.org Subject: Re: [Internetgovtech] Status of selection of IANA NTIA transition representatives by the IESG X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 15:45:32 -0000 --=====================_1001550536==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed John, Adrian, I am afraid we misunderstand. In a nutshell, I consider that the July 1978 IEN 48 internetting project: - first motivation phase is ending. The proof of the catenet concept under TCP/IP is completed. President Giscard d'Estain has closed the Cyclades project that ARPA has paid for and completed, and the alternative RCP project has led to Transpac and X.25 and has also closed. The French and US government executive direct/indirect influences on hardware and software, bandwidth and code are over. NTIA ends it. - second motivation phase is eventually engaged. It is to provide what Tymnet had engaged in June 1978 while new govermental influences (Europe, Russia, China) are emerging in a different form (no more budgets to pay for the code but laws to influence the code). Brainware/collective use is taking preeminance while economy and strategies are shifting from information and communications focus to intellition, i.e. what makes sense out of received/collected communicated information (publicity, press, PRISM, big data, content). In this process fair competition replacing regulation not possible due to cross-subsidization from brainware (edge providers) and inbound/outbound dissymetry, laws and public investement must restore a fair situation. This will have most probably an important impact on the fringe to fringe and edge systems architecture. The question I raise is who is going to make sure that the kind of ubiquity that intellition systems brainware calls for is going to be technically documented? - either in recalling the current technologies limits, possibilities, costs, options to other and new stakeholders who will sponsor a new tech community? - or in coordinating a collective documentation, experimentation, validation and deployment in the multi-global-community context acknowledged but not organized by RFC 6852? As a result there are two possibilities for the IETF: - either to help documenting what is existing and what it can do but never did yet (transition). - or to work on the architectural extensions the new geo-political-use will call for (evolution). In front of this there are two possibilities for the NTIA/ICANN process: - either they listen to the IETF and OpenStand allies and cooperate. - or they do not. This will impact the position of Governments, as I see in the current ".wine", ".vin" issue, and in turn my capacity of access to the hardware, software and brainware current reality (i.e; what I cannot change by mu own). 1. I need to know my options and decide my road-map. This is why I wish to know (I am not interested in discussing it: I am banned) the IETF project, and it to be efficiently defended (for stability reasons). This is why I need the IETF to delegate two people specialized, one for the political cooperation scenario and the other for the political change scenaroi. Question 1. What is the architectonical project of the IETF? To remain at the software protocol strtatum, or to extend in the virtual hardware, layer six and the low brainware layers? Question 2. How is this coordinated within the OpenStand partners? Question 3. The NTIA transfers authority. The liaisons are not to be experts but leaders with a target and powers. What is the target, what are the powers? 2. I need to survive and develop with what is available to me now. I am in the same situation as many others, with the difference that (1) I have been in charge of the early years of what is to be deployed, this was before the industry's status-quo strategy took over (2) I planned and tested ahead how the internet technology could support it. I have two options: - either I use the solutions that the IETF will quickly and credibly document for my type of use and accomodate the positive or negative outcome of the NTIA/ICANN transition. - or I adapt the existing solutions by myself, alone or in coordinating with allies, something everyone may have to do in hurry, to best accomodate the positive or negative aspects of the NTIA/ICANN transition. My feeling is that the best interest of Virtual Glocal Networks is that solution proposers coordinate. I have nothing more to say. I will attentively listen to you. And we will proceed by our own for the best of our members. jfc At 23:20 22/06/2014, Adrian Farrel wrote: >Hello JFC, > >I speak only for myself in my answer. > >The IETF community was invited to volunteer for these positions. I view the >positions as akin to the liaison manage roles usually appointed to by the IAB, >and it does not seem to me that the IESG is doing anything unusual >in the way it >is choosing these representatives. > >There are email lists on which the subject matter can be discussed in order to >get a good view of the concerns and possibly of consensus within the IETF. The >representatives being appointed by the IESG are intended to >represent the IETF. > >Adrian > > > > Dear Adrian, > > > > this is an embarassing situation as no one knows who are the > > candidates, their positions, and the criteria of their selection. > > Nor, by the way, what the IESG agenda may be concerning the IETF > > position regarding the ICANN process. IMHO the most appropriate > > solution for a technical body should be to consider the best and the > > worst cases and make sure that the technology can cope with both of > > them, most probably with a delegate being specialized in each extreme case? > > > > Otherwise, along RFC 6852, this is encouraging users and operators > > considering contingency situations where solutions could be asked > > for, proposed and implemented, "regardless of their formal status". > > This is exactly the situation where I put myself as a Libre > > non-profit ISP having to protect the best symetric (inbound/outbound) > > access to my members. > > > > I do not worry too much due to the actual flexibility of the > > technology but I am definitly sure that the solutions I will > > implement in case of difficulty will not be those advocated by the > > ICANNTIA project, as they would be the source of that difficulty. > > Since many of other operators and users will proceed the same in > > their own unknown way, some by local regulations or national law, > > without prior MSist coordination, the result may turn out to be > > technically operational but politically confuse, and difficult or > > even impossible to globally concert again. This would then be the end > > of the IETF as a global body or even worse if the situation degenerated. > > > > This kind of situation is scientifically known as "SOC", > > self-organizing criticality. This is the way nature and history > > usually work, by way of catastrophes. I think this is a point worth > > considering, more over than most of the people who will actually take > > these decisions are not (like me, but this is its own decision) on > > the IETF list. > > > > jfc > > > > PS. for your information most of the positions I will take in an a > > difficult situation will be documented in the French language for my > > French fellow users. I suppose that other ISPs will proceed in the > > same manner. Not to consider an ICANNTIA failure and train us in > > advance may lead to contradict RFC 3935 which states that "The IETF > > uses the English language for its work is because of its utility for > > working in a global context." --=====================_1001550536==.ALT Content-Type: text/html; charset="us-ascii" John, Adrian,

I am afraid we misunderstand. In a nutshell, I consider that the July 1978 IEN 48 internetting project:

- first motivation phase is ending. The proof of the catenet concept under TCP/IP is completed. President Giscard d'Estain has closed the Cyclades project that ARPA has paid for and completed, and the alternative RCP project has led to Transpac and X.25 and has also closed. The French and US government executive direct/indirect influences on hardware and software, bandwidth and code are over. NTIA ends it.
- second motivation phase is eventually engaged. It is to provide what Tymnet had engaged in June 1978 while new govermental influences (Europe, Russia, China) are emerging in a different form (no more budgets to pay for the code but laws to influence the code). Brainware/collective use is taking preeminance while economy and strategies are shifting from information and communications focus to intellition, i.e. what makes sense out of received/collected communicated information (publicity, press, PRISM, big data, content).

In this process fair competition replacing regulation not possible due to cross-subsidization from brainware (edge providers) and inbound/outbound dissymetry, laws and public investement must restore a fair situation. This will have most probably an important impact on the fringe to fringe and edge systems architecture.

The question I raise is who is going to make sure that the kind of ubiquity that intellition systems brainware calls for is going to be technically documented?
- either in recalling the current technologies limits, possibilities, costs, options to other and new stakeholders who will sponsor a new tech community?
- or in coordinating a collective documentation, experimentation, validation and deployment in the multi-global-community context acknowledged but not organized by RFC 6852?

As a result there are two possibilities for the IETF:
- either to help documenting what is existing and what it can do but never did yet (transition).
- or to work on the architectural extensions the new geo-political-use will call for (evolution).

In front of this there are two possibilities for the NTIA/ICANN process:
- either they listen to the IETF and OpenStand allies and cooperate.
- or they do not.

This will impact the position of Governments, as I see in the current ".wine", ".vin" issue, and in turn my capacity of access to the hardware, software and brainware current reality (i.e; what I cannot change by mu own).


1. I need to know my options and decide my road-map. This is why I wish to know (I am not interested  in discussing it: I am banned) the IETF project, and it to be efficiently  defended (for stability reasons). This is why I need the IETF to delegate two people specialized, one for the political cooperation scenario and the other for the political change scenaroi.

Question 1. What is the architectonical project of the IETF? To remain at the software protocol strtatum, or to extend in the virtual hardware, layer six and the low brainware layers?
Question 2. How is this coordinated within the OpenStand partners?
Question 3. The NTIA transfers authority. The liaisons are not to be experts but leaders with a target and powers. What is the target, what are the powers?


2. I need to survive and develop with what is available to me now. I am in the same situation as many others, with the difference that (1) I have been in charge of the early years of what is to be deployed, this was before the industry's status-quo strategy took over (2) I planned and tested ahead how the internet technology could support it.

I have two options:

- either I use the solutions that the IETF will quickly and credibly document for my type of use and accomodate the positive or negative outcome of the NTIA/ICANN transition.
- or I adapt the existing solutions by myself, alone or in coordinating with allies, something everyone may have to do in hurry, to best accomodate the positive or negative aspects of the NTIA/ICANN transition. My feeling is that the best interest of Virtual Glocal Networks is that solution proposers coordinate.

I have nothing more to say. I will attentively listen to you. And we will proceed by our own for the best of our members.

jfc


At 23:20 22/06/2014, Adrian Farrel wrote:
Hello JFC,

I speak only for myself in my answer.

The IETF community was invited to volunteer for these positions. I view the
positions as akin to the liaison manage roles usually appointed to by the IAB,
and it does not seem to me that the IESG is doing anything unusual in the way it
is choosing these representatives.

There are email lists on which the subject matter can be discussed in order to
get a good view of the concerns and possibly of consensus within the IETF. The
representatives being appointed by the IESG are intended to represent the IETF.

Adrian


> Dear Adrian,
>
> this is an embarassing situation as no one knows who are the
> candidates, their positions, and the criteria of their selection.
> Nor, by the way, what the IESG agenda may be concerning the IETF
> position regarding the ICANN process. IMHO the most appropriate
> solution for a technical body should be to consider the best and the
> worst cases and make sure that the technology can cope with both of
> them, most probably with a delegate being specialized in each extreme case?
>
> Otherwise, along RFC 6852, this is encouraging users and operators
> considering contingency situations where solutions could be asked
> for, proposed and implemented,  "regardless of their formal status".
> This is exactly the situation where I put myself as a Libre
> non-profit ISP having to protect the best symetric (inbound/outbound)
> access to my members.
>
> I do not worry too much due to the actual flexibility of the
> technology but I am definitly sure that the solutions I will
> implement in case of difficulty will not be those advocated by the
> ICANNTIA project, as they would be the source of that difficulty.
> Since many of other operators and users will proceed the same in
> their own unknown way, some by local regulations or national law,
> without prior MSist coordination, the result may turn out to be
> technically operational but politically confuse, and difficult or
> even impossible to globally concert again. This would then be the end
> of the IETF as a global body or even worse if the situation degenerated.
>
> This kind of situation is scientifically known as "SOC",
> self-organizing criticality. This is the way nature and history
> usually work, by way of catastrophes. I think this is a point worth
> considering, more over than most of the people who will actually take
> these decisions are not (like me, but this is its own decision) on
> the IETF list.
>
> jfc
>
> PS. for your information most of the positions I will take in an a
> difficult situation will be documented in the French language for my
> French fellow users. I suppose that other ISPs will proceed in the
> same manner. Not to consider an ICANNTIA failure and train us in
> advance may lead to contradict RFC 3935 which states that "The IETF
> uses the English language for its work is because of its utility for
> working in a global context."
--=====================_1001550536==.ALT--