[discuss] surveillance governance, was Re: [governance] NTIA statement

Tue Mar 18 18:50:23 UTC 2014

Mike:

That is all extremely well reasoned and stated, and (FWIW) I agree fully.  ‘Nuff said.

Greg Shatan

From: discuss-bounces at 1net.org [mailto:discuss-bounces at 1net.org] On Behalf Of Mike Roberts
Sent: Tuesday, March 18, 2014 1:05 PM
To: Alejandro Pisanty
Cc: discuss at 1net.org
Subject: Re: [discuss] surveillance governance, was Re: [governance] NTIA statement

Too many of the submissions on this thread are building sandcastles.  Admittedly, the geopolitical space surrounding the Internet is a vacuum and has many power brokers or wannabe power brokers circling around. So be it.  Some people have more time on their hands than others.

But as George suggests, let’s leave IANA out of it.

Believe it or not, Jon Postel created the system of thirteen root servers and recruited their international group of volunteer engineer operators before there ever was an ICANN, or WCIT, GAC, or ATRT, or any of the overburden of alleged oversight.  The system is highly redundant, technically robust, globally distributed,  and run by people with no financial interest in what they do.  It is fully automated, resolving billions of queries every day.  More than three quarters of those resolutions are in domains that existed before ICANN and were mercifully not subject to “oversight."

The policy inputs to the root server table entries are few and  remarkably stable.  One of them is the UN’s ISO 3166 country code table and it goes years without a change.  The principal other one is ICANN’s Board, which has constructed, over six years of community input, a 300 page policy guide on how to establish a new commercial top level domain.

Do we need a new and elaborate superstructure of “accountable” people and organizations to sit on top of this well functioning piece of critical infrastructure?  The short answer is no.

But what about the existing NTIA role, you might ask.  In fact, as others have said, it is an empty role that was never envisaged as part of ICANN.  It is not mentioned in the 1998 NTIA White Paper, which contained the policy guidance for creating ICANN.  The IANA contract was cooked up after the fact by nervous nellie lawyers within the government under political pressure.  It’s main purpose over the years has been to serve as a legal cudgel to satisfy domestic political factions. We are all well rid of it.

But what about a rogue ICANN, you might ask.  With regard to new root server table entries, they are approved by the Board after running the [expensive] gauntlet of the TLD policy process described above.  Aggrieved parties have access to multiple layers of reconsideration and to the courts.  ICANN has lost in court over allegations of not following its own policy guidance, and certainly newly aggrieved applicants would be quick to use the judiciary again if necessary.  It is inconceivable that some new system of process and accountability for new commercial name registries would be substantively better than what has taken so many years to put in place.

But what about collusion or malfeasance on the Board, you might ask.  The process of selecting a majority of the voting members of the Board members has received much attention over the years, and is carefully constructed and controlled by a group of volunteers from the community separately from the Board.  It has been reviewed repeatedly.  If there is a robust and more equitable method out there, propose it.

Finally, what about that old bugaboo, “capture” of ICANN and the root.  In the early years, perhaps, emphasize perhaps, that had some reality.  Today, we have a large, informed, engaged, and activist audience for ICANN policy making.  We are in the process of making that audience larger and of finding some way short of crude power politics to enfranchise new stakeholders.  Only the paranoid fringe can find traction for capture now.

But in the cacophonous debate over IG, let’s preserve the peace and competence of IANA.  Some days, we don’t seem to know how good a deal we have.

- Mike

On Mar 18, 2014, at 8:24 AM, Alejandro Pisanty <apisanty at gmail.com<mailto:apisanty at gmail.com>> wrote:

Hi,

that is not the way the Internet's successful multistakeholder governance mechanisms have emerged - no need to ask for a higher, central, global authority for permission. In fact, the pieces of it that exist had to be circumvented in order to get the Internet to expand. The top-down authorization echoes the delusion of One World Government and is the major flaw of the MIPOG idea.

Alejandro Pisanty

On Tue, Mar 18, 2014 at 7:22 AM, Jeremy Malcolm <Jeremy at malcolm.id.au<mailto:Jeremy at malcolm.id.au>> wrote:
On 18 Mar 2014, at 5:58 pm, Kleinwächter, Wolfgang <wolfgang.kleinwaechter at MEDIENKOMM.UNI-HALLE.DE<mailto:wolfgang.kleinwaechter at MEDIENKOMM.UNI-HALLE.DE>> wrote:

> Mechanisms should emerge on the basis of concrete needs and identified gaps. The first thing you have to do is to define the issues which have no existing natural home. Many public policy related Internet issues have a natural home. There are about 50 governmental and non-governmental global organisations dealing with various Internet related issues: From UN bodies like the Human Rights Concil to the I*Organisations. To find out what the missing link is and where we have a gap (or a malfunction) we need first of all  something like a Multistakeholder Internet Governance Clearing House (I have called this MIPOG / Multistakeholder Internet Policy Group). If a stakeholder, including a national government, has a problem, it could go to MIPOG with a request and MIPOG would recommend how to move forward by delegating the request to an existing  mechanism or by launching a (multistakeholder) process in a bottom up, inclusive, open and transparent way to develop policies (as an RFC) which could, if needed, also include the launch of new multistakeholder mechanisms.

That is also essentially what the submission posted through Best Bits calls for:

http://bestbits.net/netmundial-roadmap/

--
Jeremy Malcolm PhD LLB (Hons) B Com
Internet lawyer, ICT policy advocate, geek
host -t NAPTR 5.9.8.5.2.8.2.2.1.0.6.e164.org<http://5.9.8.5.2.8.2.2.1.0.6.e164.org/>|awk -F! '{print $3}'

WARNING: This email has not been encrypted. You are strongly recommended to enable encryption at your end. For instructions, see http://jere.my/l/pgp.

--
- - - - - - - - - - - - - - - - - - - - - - - - - - -
     Dr. Alejandro Pisanty
Facultad de Química UNAM
Av. Universidad 3000, 04510 Mexico DF Mexico
+52-1-5541444475 FROM ABROAD
+525541444475 DESDE MÉXICO SMS +525541444475
Blog: http://pisanty.blogspot.com<http://pisanty.blogspot.com/>
LinkedIn: http://www.linkedin.com/in/pisanty
Unete al grupo UNAM en LinkedIn, http://www.linkedin.com/e/gis/22285/4A106C0C8614
Twitter: http://twitter.com/apisanty
---->> Unete a ISOC Mexico, http://www.isoc.org<http://www.isoc.org/>
.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
_______________________________________________
discuss mailing list
discuss at 1net.org<mailto:discuss at 1net.org>
http://1net-mail.1net.org/mailman/listinfo/discuss

* * *

This E-mail, along with any attachments, is considered confidential and may well be legally privileged. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. Thank you for your cooperation.

* * *

To ensure compliance with Treasury Department regulations, we inform you that, unless otherwise indicated in writing, any U.S. Federal tax advice contained in this communication  (including any attachments) is not intended or written to be used, and cannot be used, for the purpose of (1) avoiding penalties under the Internal Revenue Code or applicable state and local provisions or (2) promoting, marketing or recommending to another party any tax-related matters addressed herein.

Disclaimer Version RS.US.20.10.00
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://1net-mail.1net.org/pipermail/discuss/attachments/20140318/3bd6c8d6/attachment-0001.html>