<div dir="ltr"><div>Absolutely agree with all what Steve has said below. Very much inline with the few lines i posted earlier.<br><br></div><div>Thanks Steve.<br><br></div>Cheers!<br></div><div class="gmail_extra"><br><br>

<div class="gmail_quote">On Sun, Mar 16, 2014 at 6:32 PM, Steve Crocker <span dir="ltr">&lt;<a href="mailto:steve@shinkuro.com" target="_blank">steve@shinkuro.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Greg, et al,<br>
<br>
I do not read NTIA&rsquo;s announcement as calling for the creation of a new organization nor the movement or replacement of the current contract with another contract. &nbsp;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&rsquo;s processes and reporting.<br>


<br>
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. &nbsp;By &ldquo;issue&rdquo; I mean a problem that needs to be solved or an aspect of the current arrangement that is not satisfactory in some fashion. &nbsp;And the focus here really needs to be on the functions covered by the current IANA contract. &nbsp;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. &nbsp;There are other venues for discussing those topics.<br>


<br>
By &ldquo;principles&rdquo; I mean qualities that need to be preserved going forward.<br>
<br>
If the community can agree on a set of issues and principles, I think the path forward will be much clearer. &nbsp;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.<br>


<span class="HOEnZb"><font color="#888888"><br>
Steve<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
On Mar 16, 2014, at 12:59 PM, Shatan, Gregory S. &lt;GShatan@ReedSmith.com&gt; wrote:<br>
<br>
&gt; At the most basic level, the NTIA is going to assign the IANA Contract to the new organization created by this process (&quot;NewOrg&quot;), so that NewOrg steps into the shoes of the NTIA.<br>
&gt;<br>
&gt; Then the question becomes should the IANA Contract be &quot;revised&quot; or &quot;renegotiated&quot; as part of the process to add to, subtract from or modify the privileges and obligations of NewOrg and ICANN? &nbsp;By what process and who will be involved? &nbsp;And -- is this question set even on the table? Or is the contract being assigned &quot;as is &quot;?<br>


&gt;<br>
&gt; 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>
&gt;<br>
&gt; Greg Shatan<br>
&gt; --------------------------<br>
&gt; Sent from my BlackBerry Wireless Device<br>
&gt;<br>
&gt;<br>
&gt; ----- Original Message -----<br>
&gt; From: John Curran [mailto:<a href="mailto:jcurran@istaff.org">jcurran@istaff.org</a>]<br>
&gt; Sent: Sunday, March 16, 2014 09:24 AM<br>
&gt; To: Milton L Mueller &lt;<a href="mailto:mueller@syr.edu">mueller@syr.edu</a>&gt;<br>
&gt; Cc: 1Net List &lt;<a href="mailto:discuss@1net.org">discuss@1net.org</a>&gt;; &lt;<a href="mailto:governance@lists.igcaucus.org">governance@lists.igcaucus.org</a>&gt; &lt;<a href="mailto:governance@lists.igcaucus.org">governance@lists.igcaucus.org</a>&gt;<br>


&gt; Subject: Re: [discuss] [governance] U.S. to Give Up Oversight of Web &nbsp; &nbsp;Policymaking Body<br>
&gt;<br>
&gt; On Mar 15, 2014, at 12:25 PM, Milton L Mueller &lt;<a href="mailto:mueller@syr.edu">mueller@syr.edu</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; 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&#39;s policy making process, domicile, etc. Parminder&#39;s comments confuse these two things.<br>


&gt;<br>
&gt; The existing co-mingling of overall Internet identifier coordination role, DNS policy<br>
&gt; development role, and IANA administration and implementation role (all within ICANN)<br>
&gt; does make it difficult at times to keep track of which aspect we are talking about<br>
&gt; at any given moment...<br>
&gt;<br>
&gt;&gt; Let&#39;s do one thing at a time, so that each can be done right. The distinction between ICANN&#39;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&#39;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>


&gt;<br>
&gt; I&#39;d like to explore the various roles just a bit, so I can better understand what is<br>
&gt; really proposed in &quot;the IGP plan&quot;. &nbsp;To do this, I&#39;d like to consider the tasks performed<br>
&gt; for the generic case of IANA protocol parameter registries and then for the specific<br>
&gt; case of the DNS root zone registry, as revised per the IGP proposal.<br>
&gt;<br>
&gt; (I&#39;ll spare repeating all of the IETF registry background, but one can refer to for<br>
&gt; &lt;<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>&gt; for reference)<br>
&gt;<br>
&gt; When the IETF specifies a protocol, there are often associated registries. &nbsp;To a rough<br>
&gt; approximation, the IESG is the policy development body (as it works with the community<br>
&gt; via working groups and approves the registry creation via the &quot;IANA Considerations&#39;<br>
&gt; section of an RFC) and the IAB is the registry authority. &nbsp;Via the mechanisms in RFC<br>
&gt; 6220 and per an MOU with ICANN (RFC 2860), the IAB has arranged for ICANN to perform<br>
&gt; the IANA registry administration and operations tasks. &nbsp;In this role, IANA receives<br>
&gt; requests from third parties to make entries in any IETF registry, and if they conform<br>
&gt; with the established policy for the registry then the entry is made. &nbsp;This approach<br>
&gt; encourages both clarity of registry policy as well as fair and impartial administration<br>
&gt; of the registry itself.<br>
&gt;<br>
&gt; The IAB also noted that some general-propose registries (DNS names and IP addresses)<br>
&gt; pose &quot;policy issues&quot;, and per the MOU with ICANN recognizes that ICANN may have policy<br>
&gt; which affect how those registries (such as the DNS root zone) are administered (and<br>
&gt; this is a good thing because the the IANA function contract with NTIA specifically<br>
&gt; calls for the IANA to follow ICANN policy when processing DNS root zone requests...)<br>
&gt;<br>
&gt; With respect to DNS root zone, there is a significant difference being proposed in<br>
&gt; the roles under the IGP proposal, in that you have ICANN-sans-IANA performing policy<br>
&gt; development _and_ policy administration roles, i.e. from reading, it is hard to tell<br>
&gt; if your new &quot;DNSA&quot; is only performing the clerical registry operations task, as opposed<br>
&gt; to the actual administration of policy via processing of incoming requests for changes<br>
&gt; from the community -<br>
&gt;<br>
&gt; &nbsp;&quot;The DNSA would require a binding contract with ICANN regarding the conditions<br>
&gt; &nbsp; under which it would agree to implement changes in the root zone or other<br>
&gt; &nbsp; associated databases to reflect policies emerging from ICANN&rsquo;s policy development<br>
&gt; &nbsp; processes. The contract should ensure that the DNSA has no policy authority but<br>
&gt; &nbsp; merely implements valid requests for additions or deletions emerging from ICANN&rsquo;s<br>
&gt; &nbsp; policy process.&quot;<br>
&gt;<br>
&gt; From the above, is the determination of a &quot;valid request&quot; performed first by ICANN<br>
&gt; (and the result send to DNSA for processing), or does DNSA receive the &quot;raw&quot; request<br>
&gt; and make the determination of validity in accordance with the established policy?<br>
&gt; I believe you intended the former: ICANN-sans-IANA would the body which performs<br>
&gt; policy administration and it then sends only clerical direction for registry update<br>
&gt; to the DNSA, but could potentially read the proposal either way.<br>
&gt;<br>
&gt; Thoughts?<br>
&gt; /John<br>
&gt;<br>
&gt; Disclaimer: My views alone.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; discuss mailing list<br>
&gt; <a href="mailto:discuss@1net.org">discuss@1net.org</a><br>
&gt; <a href="http://1net-mail.1net.org/mailman/listinfo/discuss" target="_blank">http://1net-mail.1net.org/mailman/listinfo/discuss</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;* * *<br>
&gt;<br>
&gt; This E-mail, along with any attachments, is considered<br>
&gt; confidential and may well be legally privileged. If you have received it in<br>
&gt; error, you are on notice of its status. Please notify us immediately by reply<br>
&gt; e-mail and then delete this message from your system. Please do not copy it or<br>
&gt; use it for any purposes, or disclose its contents to any other<br>
&gt; person. Thank you for your cooperation.<br>
&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;* * *<br>
&gt;<br>
&gt; To ensure compliance with Treasury Department regulations, we<br>
&gt; inform you that, unless otherwise indicated in writing, any U.S. Federal tax<br>
&gt; advice contained in this communication &nbsp;(including any attachments) is not<br>
&gt; intended or written to be used, and cannot be used, for the purpose of (1)<br>
&gt; avoiding penalties under the Internal Revenue Code or applicable state<br>
&gt; and local provisions or (2) promoting, marketing or recommending to another<br>
&gt; party any tax-related matters addressed herein.<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Disclaimer Version RS.US.20.10.00<br>
&gt; _______________________________________________<br>
&gt; discuss mailing list<br>
&gt; <a href="mailto:discuss@1net.org">discuss@1net.org</a><br>
&gt; <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>
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>
</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:&nbsp; &nbsp; &nbsp; </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>