[discuss] [governance] U.S. to Give Up Oversight ofWeb Policymaking Body
WUKnoben
wolf-ulrich.knoben at t-online.de
Mon Mar 17 10:06:19 UTC 2014
It should be avoided to start again from the scratch with an experiment like
1net started: many threads and poor structure which deterred people to
contribute.
I guess the NTIA did not make the announcement without having had a kind of
high level "informal talks" with ICANN in advance. This shimmered a little
through when Fadi on the call last Saturday said that he was surprised "by
the timing of the announcement". Those people should be in a position to
provide in Singapore basic exegesis on the background, and I'm curious to
hear more about. As Steve outlines the deduction of principles and issues
should be the first focus of the community.
Best regards
Wolf-Ulrich Knoben
-----Ursprüngliche Nachricht-----
From: Shatan, Gregory S.
Sent: Monday, March 17, 2014 4:50 AM
To: 'Steve Crocker'
Cc: discuss at 1net.org ; governance at lists.igcaucus.org
Subject: Re: [discuss] [governance] U.S. to Give Up Oversight ofWeb
Policymaking Body
Steve,
You are correct. The "assignment" of the IANA contract may be a useful
paradigm to isolate what responsibilities and obligations NTIA is
transitioning, but the NTIA statement does not call for the NTIA to be
replaced by an organization (new or existing) performing the NTIA's role
(though it could be) or for the NTIA's role to be performed or enforced
pursuant to a contract (though it could be). The drawing board is actually
fairly open when it comes to mechanisms and solutions, and the focus should
be on issues (what needs to be fixed) and principles (what needs to be
maintained) at this stage.
As for whether this list can focus on the functions covered by the current
IANA contract, I tend to doubt that will happen. While I haven't been a fan
of the previous attempts or suggestions to split this list, perhaps the
time has come to either (a) split the list into two lists, one to discuss
this transition, and another for everything else, or (b) at the least, tag
all emails on this subject with, e.g., [IANA Transition] to distinguish them
from all the other topics under discussion here.
Greg Shatan
-----Original Message-----
From: Steve Crocker [mailto:steve at shinkuro.com]
Sent: Sunday, March 16, 2014 1:33 PM
To: Shatan, Gregory S.
Cc: discuss at 1net.org; governance at lists.igcaucus.org
Subject: Re: [discuss] [governance] U.S. to Give Up Oversight of Web
Policymaking Body
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
More information about the discuss
mailing list