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

Sun Mar 16 18:53:43 UTC 2014

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
>
>