<div dir="ltr">Hello Shatan,<br><div class="gmail_extra"><br></div><div class="gmail_extra">You have listed the important questions that will help directly address the need for a solution. However perhaps a first question to include will be:<br>
<br></div><div class="gmail_extra">What is the current role of NTIA and why does the role need to transition to an entirely NewOrg. (What are we trying to fix). What do we loose if that role is entirely truncated OR if the role is further streamlined and integrated into the process of an already existing organisation?<br>
<br></div><div class="gmail_extra">Regards<br></div><div class="gmail_extra"><div class="gmail_quote">On Sun, Mar 16, 2014 at 5:59 PM, Shatan, Gregory S. <span dir="ltr"><<a href="mailto:GShatan@reedsmith.com" target="_blank">GShatan@reedsmith.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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 "?<br>
<br>
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.<br>
<br>
Greg Shatan<br>
--------------------------<br>
Sent from my BlackBerry Wireless Device<br>
<div class="im HOEnZb"><br>
<br>
----- Original Message -----<br>
From: John Curran [mailto:<a href="mailto:jcurran@istaff.org">jcurran@istaff.org</a>]<br>
</div><div class="im HOEnZb">Sent: Sunday, March 16, 2014 09:24 AM<br>
To: Milton L Mueller <<a href="mailto:mueller@syr.edu">mueller@syr.edu</a>><br>
Cc: 1Net List <<a href="mailto:discuss@1net.org">discuss@1net.org</a>>; <<a href="mailto:governance@lists.igcaucus.org">governance@lists.igcaucus.org</a>> <<a href="mailto:governance@lists.igcaucus.org">governance@lists.igcaucus.org</a>><br>
Subject: Re: [discuss] [governance] U.S. to Give Up Oversight of Web Policymaking Body<br>
<br>
</div><div class="HOEnZb"><div class="h5">On Mar 15, 2014, at 12:25 PM, Milton L Mueller <<a href="mailto:mueller@syr.edu">mueller@syr.edu</a>> wrote:<br>
<br>
> 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.<br>
<br>
The existing co-mingling of overall Internet identifier coordination role, DNS policy<br>
development role, and IANA administration and implementation role (all within ICANN)<br>
does make it difficult at times to keep track of which aspect we are talking about<br>
at any given moment...<br>
<br>
> 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.<br>
<br>
I'd like to explore the various roles just a bit, so I can better understand what is<br>
really proposed in "the IGP plan". To do this, I'd like to consider the tasks performed<br>
for the generic case of IANA protocol parameter registries and then for the specific<br>
case of the DNS root zone registry, as revised per the IGP proposal.<br>
<br>
(I'll spare repeating all of the IETF registry background, but one can refer to for<br>
<<a href="http://1net-mail.1net.org/pipermail/discuss/2014-March/002434.html" target="_blank">http://1net-mail.1net.org/pipermail/discuss/2014-March/002434.html</a>> for reference)<br>
<br>
When the IETF specifies a protocol, there are often associated registries. To a rough<br>
approximation, the IESG is the policy development body (as it works with the community<br>
via working groups and approves the registry creation via the "IANA Considerations'<br>
section of an RFC) and the IAB is the registry authority. Via the mechanisms in RFC<br>
6220 and per an MOU with ICANN (RFC 2860), the IAB has arranged for ICANN to perform<br>
the IANA registry administration and operations tasks. In this role, IANA receives<br>
requests from third parties to make entries in any IETF registry, and if they conform<br>
with the established policy for the registry then the entry is made. This approach<br>
encourages both clarity of registry policy as well as fair and impartial administration<br>
of the registry itself.<br>
<br>
The IAB also noted that some general-propose registries (DNS names and IP addresses)<br>
pose "policy issues", and per the MOU with ICANN recognizes that ICANN may have policy<br>
which affect how those registries (such as the DNS root zone) are administered (and<br>
this is a good thing because the the IANA function contract with NTIA specifically<br>
calls for the IANA to follow ICANN policy when processing DNS root zone requests...)<br>
<br>
With respect to DNS root zone, there is a significant difference being proposed in<br>
the roles under the IGP proposal, in that you have ICANN-sans-IANA performing policy<br>
development _and_ policy administration roles, i.e. from reading, it is hard to tell<br>
if your new "DNSA" is only performing the clerical registry operations task, as opposed<br>
to the actual administration of policy via processing of incoming requests for changes<br>
from the community -<br>
<br>
"The DNSA would require a binding contract with ICANN regarding the conditions<br>
under which it would agree to implement changes in the root zone or other<br>
associated databases to reflect policies emerging from ICANN’s policy development<br>
processes. The contract should ensure that the DNSA has no policy authority but<br>
merely implements valid requests for additions or deletions emerging from ICANN’s<br>
policy process."<br>
<br>
>From the above, is the determination of a "valid request" performed first by ICANN<br>
(and the result send to DNSA for processing), or does DNSA receive the "raw" request<br>
and make the determination of validity in accordance with the established policy?<br>
I believe you intended the former: ICANN-sans-IANA would the body which performs<br>
policy administration and it then sends only clerical direction for registry update<br>
to the DNSA, but could potentially read the proposal either way.<br>
<br>
Thoughts?<br>
/John<br>
<br>
Disclaimer: My views alone.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
discuss mailing list<br>
<a href="mailto:discuss@1net.org">discuss@1net.org</a><br>
<a href="http://1net-mail.1net.org/mailman/listinfo/discuss" target="_blank">http://1net-mail.1net.org/mailman/listinfo/discuss</a><br>
<br>
<br>
<br>
</div></div><div class="im HOEnZb"> * * *<br>
<br>
This E-mail, along with any attachments, is considered<br>
confidential and may well be legally privileged. If you have received it in<br>
error, you are on notice of its status. Please notify us immediately by reply<br>
e-mail and then delete this message from your system. Please do not copy it or<br>
use it for any purposes, or disclose its contents to any other<br>
person. Thank you for your cooperation.<br>
<br>
* * *<br>
<br>
To ensure compliance with Treasury Department regulations, we<br>
inform you that, unless otherwise indicated in writing, any U.S. Federal tax<br>
advice contained in this communication (including any attachments) is not<br>
intended or written to be used, and cannot be used, for the purpose of (1)<br>
avoiding penalties under the Internal Revenue Code or applicable state<br>
and local provisions or (2) promoting, marketing or recommending to another<br>
party any tax-related matters addressed herein.<br>
Disclaimer Version RS.US.20.10.00<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
discuss mailing list<br>
<a href="mailto:discuss@1net.org">discuss@1net.org</a><br>
<a href="http://1net-mail.1net.org/mailman/listinfo/discuss" target="_blank">http://1net-mail.1net.org/mailman/listinfo/discuss</a></div></div></blockquote></div><br><br clear="all"><br>-- <br>------------------------------------------------------------------------<br>
<font color="#888888"><blockquote style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex;font-family:garamond,serif">
<i><span style="color:rgb(0,102,0)">Seun Ojedeji,<br style="color:rgb(0,102,0)"></span><span style="color:rgb(0,102,0)">Federal University Oye-Ekiti<br style="color:rgb(0,102,0)"></span><span style="color:rgb(0,102,0)">web: </span><a href="http://www.fuoye.edu.ng" target="_blank">http://www.fuoye.edu.ng</a><br>
<span style="color:rgb(0,102,0)"></span><span style="color:rgb(0,102,0)">Mobile: <a value="+2348035233535">+2348035233535</a></span><span style="color:rgb(0,102,0)"></span><br></i><i><span style="color:rgb(0,102,0)">alt email:<a href="http://goog_1872880453" target="_blank"> </a><a href="mailto:seun.ojedeji@fuoye.edu.ng" target="_blank">seun.ojedeji@fuoye.edu.ng</a></span></i><br>
</blockquote></font><br>
</div></div>