[discuss] [governance] U.S. to Give Up Oversight of Web Policymaking Body

Mon Mar 17 12:33:26 UTC 2014

It would be useful for people to understand what access is possible in 
various countries.  The PATRIOT Act is neither unique nor the most 
draconian/expansive act of western democracies.

If we wish to discuss accountability lets play with facts rather than 
slogans...

Joe
On 3/16/2014 3:04 PM, Dominique Lacroix wrote:
> Good step, Avri. Separate the powers, first, of course.
>
>> There is also the issue of ICANN being subject to US law.
> More important may be the contracts between ICANN and dealers: all
> subjected to US laws, and to Patriot Act, inter alia.
> That's the link with surveillance and lack of trust ;-(
>
> NTIA was a very good stewart. It's replacement must not be wished
> because of bad behaviour, but because of principles and values.
> So putting that replacement discussion just now may hide the very core
> of the problem: trust.
> Don't you think so?
>
> @+, cheers, Dominique
>
>
>
> Le 16/03/14 19:53, Avri Doria a écrit :
>> Hi,
>>
>> One of those principles for me would be:
>>
>> - Strict functional separation of the policy making and administration
>>
>> I think that many, myself included, do not see how being part of ICANN
>> and strict functionally separation are possible within ICANN's current
>> configuration.
>>
>> This may also be a big part of the expectations of global stakeholders.
>>
>> There is also the issue of ICANN being subject to US law.  This
>> remains a problem if ICANN plans to keep the administrative function
>> after transition.
>>
>> avri
>>
>> On 16-Mar-14 13:32, Steve Crocker wrote:
>>> Greg, et al,
>>>
>>> I do not read NTIA’s announcement as calling for the creation of a
>>> new organization nor the movement or replacement of the current
>>> contract with another contract.  Instead, I believe NTIA is asking
>>> for the community to think through how to replace the role the NTIA
>>> has performed, which is only a review of the root zone update actions
>>> and ICANN’s processes and reporting.
>>>
>>> I think it would be very helpful to everyone to focus first on coming
>>> up with a list of *issues* and *principles* before suggesting
>>> specific mechanisms or solutions.  By “issue” I mean a problem that
>>> needs to be solved or an aspect of the current arrangement that is
>>> not satisfactory in some fashion.  And the focus here really needs to
>>> be on the functions covered by the current IANA contract.  Issues
>>> related to gTLD contractual matters, overall organization of ICANN,
>>> non-ICANN matters such as network surveillance by various
>>> governments, etc. are quite far outside the scope.  There are other
>>> venues for discussing those topics.
>>>
>>> By “principles” I mean qualities that need to be preserved going
>>> forward.
>>>
>>> If the community can agree on a set of issues and principles, I think
>>> the path forward will be much clearer.  If the issues and principles
>>> are in place, choosing a specific mechanism becomes, to use the
>>> tongue-in-cheek phrasing from the technical community, just an
>>> implementation detail.
>>>
>>> Steve
>>>
>>>
>>>
>>>
>>> On Mar 16, 2014, at 12:59 PM, Shatan, Gregory S.
>>> <GShatan at ReedSmith.com> wrote:
>>>
>>>> At the most basic level, the NTIA is going to assign the IANA
>>>> Contract to the new organization created by this process
>>>> ("NewOrg"), so that NewOrg steps into the shoes of the NTIA.
>>>>
>>>> Then the question becomes should the IANA Contract be "revised" or
>>>> "renegotiated" as part of the process to add to, subtract from or
>>>> modify the privileges and obligations of NewOrg and ICANN?  By what
>>>> process and who will be involved?  And -- is this question set even
>>>> on the table? Or is the contract being assigned "as is "?
>>>>
>>>> Also, what will NewOrg look like? What form, what domicile, what
>>>> governance? This is probably the question set more directly asked
>>>> as a result of the NTIA announcement.
>>>>
>>>> Greg Shatan -------------------------- Sent from my BlackBerry
>>>> Wireless Device
>>>>
>>>>
>>>> ----- Original Message ----- From: John Curran
>>>> [mailto:jcurran at istaff.org] Sent: Sunday, March 16, 2014 09:24 AM
>>>> To: Milton L Mueller <mueller at syr.edu> Cc: 1Net List
>>>> <discuss at 1net.org>; <governance at lists.igcaucus.org>
>>>> <governance at lists.igcaucus.org> Subject: Re: [discuss] [governance]
>>>> U.S. to Give Up Oversight of Web    Policymaking Body
>>>>
>>>> On Mar 15, 2014, at 12:25 PM, Milton L Mueller <mueller at syr.edu>
>>>> wrote:
>>>>
>>>>> Furthermore, I would refer people back to the IGP plan, and the
>>>>> call to separate the globalization/reform of the IANA functions
>>>>> from the broader and more difficult reforms that must be made in
>>>>> ICANN's policy making process, domicile, etc. Parminder's
>>>>> comments confuse these two things.
>>>> The existing co-mingling of overall Internet identifier
>>>> coordination role, DNS policy development role, and IANA
>>>> administration and implementation role (all within ICANN) does make
>>>> it difficult at times to keep track of which aspect we are talking
>>>> about at any given moment...
>>>>
>>>>> Let's do one thing at a time, so that each can be done right. The
>>>>> distinction between ICANN's policy process, its corporate
>>>>> domicile, its contracts with registries, etc., with the
>>>>> globalization of the IANA functions has been reiterated many
>>>>> times on this list. We don't have to change everything about
>>>>> ICANN in one stage. Once the IANA functions are dealt with, a lot
>>>>> of options open up regarding the policy process.
>>>> I'd like to explore the various roles just a bit, so I can better
>>>> understand what is really proposed in "the IGP plan".  To do this,
>>>> I'd like to consider the tasks performed for the generic case of
>>>> IANA protocol parameter registries and then for the specific case
>>>> of the DNS root zone registry, as revised per the IGP proposal.
>>>>
>>>> (I'll spare repeating all of the IETF registry background, but one
>>>> can refer to for
>>>> <http://1net-mail.1net.org/pipermail/discuss/2014-March/002434.html>
>>>> for reference)
>>>>
>>>> When the IETF specifies a protocol, there are often associated
>>>> registries.  To a rough approximation, the IESG is the policy
>>>> development body (as it works with the community via working groups
>>>> and approves the registry creation via the "IANA Considerations'
>>>> section of an RFC) and the IAB is the registry authority.  Via the
>>>> mechanisms in RFC 6220 and per an MOU with ICANN (RFC 2860), the
>>>> IAB has arranged for ICANN to perform the IANA registry
>>>> administration and operations tasks.  In this role, IANA receives
>>>> requests from third parties to make entries in any IETF registry,
>>>> and if they conform with the established policy for the registry
>>>> then the entry is made.  This approach encourages both clarity of
>>>> registry policy as well as fair and impartial administration of the
>>>> registry itself.
>>>>
>>>> The IAB also noted that some general-propose registries (DNS names
>>>> and IP addresses) pose "policy issues", and per the MOU with ICANN
>>>> recognizes that ICANN may have policy which affect how those
>>>> registries (such as the DNS root zone) are administered (and this
>>>> is a good thing because the the IANA function contract with NTIA
>>>> specifically calls for the IANA to follow ICANN policy when
>>>> processing DNS root zone requests...)
>>>>
>>>> With respect to DNS root zone, there is a significant difference
>>>> being proposed in the roles under the IGP proposal, in that you
>>>> have ICANN-sans-IANA performing policy development _and_ policy
>>>> administration roles, i.e. from reading, it is hard to tell if your
>>>> new "DNSA" is only performing the clerical registry operations
>>>> task, as opposed to the actual administration of policy via
>>>> processing of incoming requests for changes from the community -
>>>>
>>>> "The DNSA would require a binding contract with ICANN regarding the
>>>> conditions under which it would agree to implement changes in the
>>>> root zone or other associated databases to reflect policies
>>>> emerging from ICANN’s policy development processes. The contract
>>>> should ensure that the DNSA has no policy authority but merely
>>>> implements valid requests for additions or deletions emerging from
>>>> ICANN’s policy process."
>>>>
>>>>  From the above, is the determination of a "valid request" performed
>>>> first by ICANN (and the result send to DNSA for processing), or
>>>> does DNSA receive the "raw" request and make the determination of
>>>> validity in accordance with the established policy? I believe you
>>>> intended the former: ICANN-sans-IANA would the body which performs
>>>> policy administration and it then sends only clerical direction for
>>>> registry update to the DNSA, but could potentially read the
>>>> proposal either way.
>>>>
>>>> Thoughts? /John
>>>>
>>>> Disclaimer: My views alone.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________ discuss mailing
>>>> list 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 _______________________________________________
>>>> discuss mailing list discuss at 1net.org
>>>> http://1net-mail.1net.org/mailman/listinfo/discuss
>>>
>>> _______________________________________________ discuss mailing list
>>> discuss at 1net.org http://1net-mail.1net.org/mailman/listinfo/discuss
>>>
>>>
>> _______________________________________________
>> discuss mailing list
>> discuss at 1net.org
>> http://1net-mail.1net.org/mailman/listinfo/discuss
>>
>
> _______________________________________________
> discuss mailing list
> discuss at 1net.org
> http://1net-mail.1net.org/mailman/listinfo/discuss