<div dir="ltr"><div>Alan,<br><br>Why do you say it is up to the NTIA?  Our charter says it&#39;s up to us.  I don&#39;t believe we&#39;re adding a new complexity.  I think we are recognizing that we overlooked an existing complexity that was on our plate.<br><br></div>Greg<br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><p style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif;background-image:initial;background-repeat:initial"><b><span style="font-size:9pt;font-family:Arial,sans-serif;color:rgb(23,54,93)">Gregory S. Shatan </span></b><b><span style="font-size:8pt;font-family:Symbol;color:rgb(23,54,93)">ï</span></b><b><span style="font-size:9pt;font-family:Arial,sans-serif;color:rgb(23,54,93)"> </span></b><b><span style="font-size:8pt;font-family:Arial,sans-serif;color:rgb(192,80,77)">Abelman Frayne &amp; Schwab</span></b><span style="font-size:12pt;font-family:&#39;Times New Roman&#39;,serif"><u></u><u></u></span></p><p style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif;background-image:initial;background-repeat:initial"><b><span style="font-size:8pt;font-family:Arial,sans-serif;color:rgb(23,54,93)">666 Third Avenue </span></b><b><span style="font-size:8pt;font-family:Symbol;color:rgb(23,54,93)">ï</span></b><b><span style="font-size:8pt;font-family:Arial,sans-serif;color:rgb(23,54,93)"> New York, NY 10017-5621</span></b><span style="font-size:12pt;font-family:&#39;Times New Roman&#39;,serif"><u></u><u></u></span></p><p style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif;background-image:initial;background-repeat:initial"><b><span style="font-size:8pt;font-family:Arial,sans-serif;color:navy">Direct</span></b><span style="font-size:8pt;font-family:Arial,sans-serif;color:navy">  </span><span style="font-size:8pt;font-family:Arial,sans-serif;color:rgb(17,85,204)"><a value="+12128859253" style="color:rgb(17,85,204)">212-885-9253</a> <b>| </b></span><b><span style="font-size:8pt;font-family:Arial,sans-serif;color:navy">Main</span></b><span style="font-size:8pt;font-family:Arial,sans-serif;color:navy"> </span><span style="font-size:8pt;font-family:Arial,sans-serif;color:rgb(17,85,204)"><a value="+12129499022" style="color:rgb(17,85,204)">212-949-9022</a></span><span style="font-size:12pt;font-family:&#39;Times New Roman&#39;,serif"><u></u><u></u></span></p><p style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif;background-image:initial;background-repeat:initial"><b><span style="font-size:8pt;font-family:Arial,sans-serif;color:navy">Fax</span></b><span style="font-size:8pt;font-family:Arial,sans-serif;color:navy">  </span><span style="font-size:8pt;font-family:Arial,sans-serif;color:rgb(17,85,204)"><a value="+12129499190" style="color:rgb(17,85,204)">212-949-9190</a> <b>|</b> </span><b><span style="font-size:8pt;font-family:Arial,sans-serif;color:navy">Cell </span></b><span style="font-size:8pt;font-family:Arial,sans-serif;color:rgb(17,85,204)"><a value="+19178166428" style="color:rgb(17,85,204)">917-816-6428</a></span><span style="font-size:12pt;font-family:&#39;Times New Roman&#39;,serif"><u></u><u></u></span></p><p style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif;background-image:initial;background-repeat:initial"><b><i><span style="font-size:8pt;font-family:Arial,sans-serif;color:navy"><a href="mailto:gsshatan@lawabel.com" style="color:rgb(17,85,204)" target="_blank">gsshatan@lawabel.com</a><u></u><u></u></span></i></b></p><p style="margin:0in 0in 0.0001pt;font-family:Calibri,sans-serif;background-image:initial;background-repeat:initial"><b><font>ICANN-related: <a href="mailto:gregshatanipc@gmail.com" target="_blank">gregshatanipc@gmail.com</a> </font></b></p><p style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif;background-image:initial;background-repeat:initial"><b><i><span style="font-size:8pt;font-family:Arial,sans-serif;color:navy"><a href="http://www.lawabel.com/" style="color:rgb(17,85,204)" target="_blank">www.lawabel.com</a></span></i></b></p></div></div></div></div></div>
<br><div class="gmail_quote">On Tue, Dec 9, 2014 at 11:17 PM, Alan Greenberg <span dir="ltr">&lt;<a href="mailto:alan.greenberg@mcgill.ca" target="_blank">alan.greenberg@mcgill.ca</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
We need to specify that for the IANA transition to be effective, there
must be a requirement that the Root zone maintainer accept change
instructions from the assigned IANA functions operator. It is up to NTIA
to arrange its (or perhaps our at some point) contract with the RZM to
make sure that this happens. Why add new complexity to our already
difficult task?<span class="HOEnZb"><font color="#888888"><br><br>
Alan</font></span><div><div class="h5"><br><br>
At 09/12/2014 11:02 PM, Jordan Carter wrote:<br>
<blockquote type="cite">All <br><br>
I agree with Mathieu&#39;s basic concern but would basically put it like
this:<br><br>
ContractCo has no teeth in assigning the IANA functions contract to
anyone unless it can also direct the Root zone maintainer to accept
change instructions from the assigned IANA functions operator.<br><br>
Without the ability to do both those things, then the first power is
imaginary.<br><br>
For example, imagine if Contract Co had a contract with ICANN to perform
the IANA functions, and ICANN as IANA functions operator had a contract
with the RZM. <br><br>
If ContractCo issued the contract for IANA functions to a different
entity, ICANN could still control the root. <br><br>
So it appears to me that we aren&#39;t solving post-NTIA problems if we
aren&#39;t dealing with RZM as well as IANA functions.<br><br>
Interested in other views and perspectives on this.<br><br>
cheers,<br>
Jordan<br><br>
<br>
On 9 December 2014 at 03:48, Milton L Mueller
&lt;<a href="mailto:mueller@syr.edu" target="_blank">mueller@syr.edu</a>&gt; wrote:
<dl>
<dd>I agree with you Greg that this is in scope; you are also correct to
point out that the NTIA language (“related and parallel”) makes it rather
ambiguous regarding our role relative to NTIA’s role in effecting this
change. <br>

</dd><dd> <br>

</dd><dd>My take on it is that NTIA will actually take responsibility for
modifying or ending the Verisign Cooperative Agreement once we have a
complete proposal, but that our proposal really does need to be based on
a clear understanding of what we want to happen to the RZM functions.
This message should be more detailed but I don’t have time for more
now.  <br><br>

</dd><dd><a name="14a326c41646239e_14a2a63267f337cf__MailEndCompose"></a> 
</dd><dd>From: Greg Shatan
[<a href="mailto:gregshatanipc@gmail.com" target="_blank">
mailto:gregshatanipc@gmail.com</a>] 
</dd><dd>Sent: Monday, December 8, 2014 3:14 AM
</dd><dd>To: Milton L Mueller
</dd><dd>Cc:
<a href="mailto:Mathieu.Weill@afnic.fr" target="_blank">Mathieu.Weill@afnic.fr</a>;
<a href="mailto:cwg-stewardship@icann.org" target="_blank">cwg-stewardship@icann.org</a>
</dd><dd>Subject: Re: [CWG-Stewardship] Contract, Co. and the root zone
publisher<br>

</dd><dd> <br>

</dd><dd>I agree that this is another important reason for Contract Co. -- to
contract with the RZM.<br>

</dd><dd>However, I&#39;m not sure I agree that issues relating to the Cooperative
Agreement are part of a &quot;Step 2&quot; that is not within the scope
of this CWG.<br>

</dd><dd>The Q&amp;A issued along with the NTIA&#39;s initial press release on the
IANA transition said that there a &quot;related and parallel&quot;
transition of the NTIA&#39;s responsibilities relating to the Verisign
cooperative agreement.<br><br>

</dd><dd>
<a href="http://www.ntia.doc.gov/other-publication/2014/iana-functions-and-related-root-zone-management-transition-questions-and-answ" target="_blank">
http://www.ntia.doc.gov/other-publication/2014/iana-functions-and-related-root-zone-management-transition-questions-and-answ</a>
<br>

</dd><dd> <br>

</dd><dd>A &quot;parallel&quot; transition seems inconsistent with a
&quot;Step 2&quot; approach (which would be more of a &quot;serial&quot;
transition).<br>
<br>

</dd><dd>In our CWG&#39;s Charter, in the section entitled &quot;Scope,&quot;
there is the following paragraph (emphasis added):<br>

</dd><dd>In respect of Function 2. (“Perform Administrative Functions
Associated With Root Zone Management”), this process currently involves
distinct roles performed by three different entities through two separate
legal agreements: the Contractor as the IANA Functions Operator, NTIA as
the Administrator, and VeriSign (‘or any successor entity as designated
by the U.S. Department of Commerce”) as the Root Zone Maintainer. The
accountability function currently performed by NTIA regarding the RZM
role, as well as the discussion of the RZM management administrative
interface currently used by NTIA are within the scope of the CWG. The
issue of who performs the Root Zone Maintainer (RZM) role is not in scope
for the CWG and should be dealt with in a subsequent effort as needed.
Additionally, issues related to naming policy e.g. delegation,
redelegation or revocation of ccTLDs, RAA related policy issues etc. are
not within the scope of the CWG. 
</dd><dd> <br>

</dd><dd>If I read this correctly, &quot;the accountability function ...
regarding the RZM role&quot; is within our scope. This means that our
proposal does have to provide for a transition of the NTIA&#39;s role
relating to the RZM function.  It stands to reason that, if the NTIA
is no longer in this role, that the NTIA should no longer be a party to
the Cooperative Agreement, since the Cooperative Agreement is a key part
of the NTIA&#39;s accountability function.  This also seems to call for
a &quot;parallel&quot; transition (like the NTIA Q&amp;A) of the NTIA&#39;s
responsibilities relating to the Verisign cooperative agreement to be
included in our proposal.<br>

</dd><dd>Perhaps someone from the drafting team can shed some light on the
genesis and meaning of this paragraph in our Charter.  The only
reference I can find to this paragraph on the DT wiki is a line from the
Call #3 Meeting Notes and Action Items:<br>

</dd><dd>Language on Root Zone Maintaining process: re-focus on role of NTIA
in Root Zone maintainer process. Action: Avri and Chuck to propose
language to the group. Group aware of Chuck’s role and no objection.<br>

</dd><dd> <br>

</dd><dd>I think we need to get some real clarity on this point very soon, so
that our Proposal does not fail to deal with part of our mandate.<br>

</dd><dd>Greg<br>
<br>

</dd><dd>Gregory S. Shatan ï Abelman Frayne &amp; Schwab<br>

</dd><dd>666 Third Avenue ï New York, NY 10017-5621<br>

</dd><dd>Direct  <a href="tel:212-885-9253" value="+12128859253" target="_blank">212-885-9253</a> | Main <a href="tel:212-949-9022" value="+12129499022" target="_blank">212-949-9022</a><br>

</dd><dd>Fax  <a href="tel:212-949-9190" value="+12129499190" target="_blank">212-949-9190</a> | Cell <a href="tel:917-816-6428" value="+19178166428" target="_blank">917-816-6428</a><br><br>

</dd><dd><a href="mailto:gsshatan@lawabel.com" target="_blank">gsshatan@lawabel.com</a><br>

</dd><dd>ICANN-related:
<a href="mailto:gregshatanipc@gmail.com" target="_blank">gregshatanipc@gmail.com</a>
<br><br>

</dd><dd><a href="http://www.lawabel.com/" target="_blank">www.lawabel.com</a>
<br>

</dd><dd> <br>

</dd><dd>On Sun, Dec 7, 2014 at 11:11 AM, Milton L Mueller
&lt;<a href="mailto:mueller@syr.edu" target="_blank">mueller@syr.edu</a>&gt;
wrote:<br><br>

<dl>
<dd>Mathieu
</dd><dd>You are correct to suggest that the status of Verisign as RZM is
still a bit of a loose end in the transition process. However, the
scenario you propose isn&#39;t a problem with this plan; if it could happen
under a new regime, too if we are not careful. There would be nothing
preventing Verisign from refusing to implement IANA change requests from
ICANN, for example.<br>

</dd><dd>So this is not an argument against any particular plan, it is simply
identifying a problem that the NTIA has to take care of after the
transition.<br>

</dd><dd>Currently, Verisign is bound to modify the root zone changes approved
by the NTIA through a Cooperative Agreement with the Commerce Department.
Ultimately, that agreement has to go away to complete the IANA
transition. If Verisign continues to be the Root Zone File implementer,
the cooperative agreement has to go away otherwise the NTIA will still be
in control of the root. However, for practical reasons the NTIA has
chosen to make that &quot;step 2&quot; after they get an agreeable IANA
transition plan. My guess is that once we have an acceptable plan, then
the NTIA-Verisign cooperative agreement will be modified and the new IANA
contractor will work out an agreement with whoever the RZF implementer
turns out to be.<br>

</dd><dd>This is another reason why we MUST have a Contract Co.!!!! How are
you going to have authority over RZF change implementation without a
legally binding, readily enforceable contract?<br>

</dd><dd>One thing that may put your mind at ease: Verisign does not want to
be in control of root zone file modifications. That would make it liable
for antitrust challenges or make it subject to liability for other things
that might happen related to RZF changes. It is a private, commercial
company, and putting a private company in charge of a critical resource
used by its competitors is not a position a company residing in a
jurisdiction with strong antitrust laws wants to be in. The current
arrangement makes Verisign the operator but someone else has the
responsibility for the changes.<br><br>

</dd><dd>&gt; -----Original Message-----
</dd><dd>&gt; From:
<a href="mailto:cwg-stewardship-bounces@icann.org" target="_blank">
cwg-stewardship-bounces@icann.org</a>
[mailto:<a href="mailto:cwg-stewardship-" target="_blank">cwg-stewardship-</a>
</dd><dd>&gt; <a href="mailto:bounces@icann.org" target="_blank">bounces@icann.org</a>] On
Behalf Of Mathieu Weill
</dd><dd>&gt; Sent: Sunday, December 7, 2014 7:41 AM
</dd><dd>&gt; To:
<a href="mailto:cwg-stewardship@icann.org" target="_blank">cwg-stewardship@icann.org</a>
</dd><dd>&gt; Subject: [CWG-Stewardship] Contract, Co. and the root zone
publisher
</dd><dd>&gt;
</dd><dd>&gt; Dear Colleagues,
</dd><dd>&gt;
</dd><dd>&gt; Having now read carefully the proposal document, I have a
significant
</dd><dd>&gt; concern to share with all Members and Participants. I feel like
we are missing
</dd><dd>&gt; an important part of the puzzle.
</dd><dd>&gt;
</dd><dd>&gt; I apologize for raising this concern so late, and I hope this
concern will be
</dd><dd>&gt; easily dismissed if I have missed something.
</dd><dd>&gt;
</dd><dd>&gt; Here is the scenario that raised my concern.
</dd><dd>&gt;
</dd><dd>&gt; The CWG suggests to create Contract, Co. as the contracting
party for the
</dd><dd>&gt; IANA contract in the future. Consider the scenario where
Contract, Co., upon
</dd><dd>&gt; instruction from the MRT after a fierce debate, contracts with
someone else
</dd><dd>&gt; than Icann, following an RFP.
</dd><dd>&gt;
</dd><dd>&gt; Consider now that, due to external considerations, the root zone
publisher
</dd><dd>&gt; (currently, Verisign) indicates that it does not intend
accepting requests from
</dd><dd>&gt; the new IANA operator. We would be facing a deadlock,
threatening the
</dd><dd>&gt; ability to maintain the root zone in a secure and stable
manner.
</dd><dd>&gt;
</dd><dd>&gt; Am I missing something here ? Unless I am, I believe we would
need to
</dd><dd>&gt; expand our investigations to be able to address this scenario,
by :
</dd><dd>&gt; - analyzing the root zone publisher function, especially by what
mechanisms
</dd><dd>&gt; it is bound to publish IANA-approved changes to to the root
zone.
</dd><dd>&gt; - investigating options in our transition proposal, through
which to ensure
</dd><dd>&gt; that the root zone publisher remains committed to publish
changes in the
</dd><dd>&gt; root when, and only when, they are approved by the IANA
Operator.
</dd><dd>&gt;
</dd><dd>&gt; Many thanks in advance for your replies regarding both the
validity of this
</dd><dd>&gt; scenario as well as potential ways to address that risk.
</dd><dd>&gt;
</dd><dd>&gt; --
</dd><dd>&gt; *****************************
</dd><dd>&gt; Mathieu WEILL
</dd><dd>&gt; AFNIC - directeur général
</dd><dd>&gt; Tél: 01 39 30 83 06
</dd><dd>&gt;
<a href="mailto:mathieu.weill@afnic.fr" target="_blank">mathieu.weill@afnic.fr</a>
</dd><dd>&gt; *****************************
</dd><dd>&gt; ATTENTION : L&#39;Afnic a déménagé le 31 mars 2014 !
</dd><dd>&gt; Notre nouvelle adresse est :
</dd><dd>&gt; Afnic - Immeuble Le Stephenson - 1, rue Stephenson - 78180
Montigny-le-
</dd><dd>&gt; Bretonneux
</dd><dd>&gt;
</dd><dd>&gt; _______________________________________________
</dd><dd>&gt; CWG-Stewardship mailing list
</dd><dd>&gt;
<a href="mailto:CWG-Stewardship@icann.org" target="_blank">CWG-Stewardship@icann.org</a>
</dd><dd>&gt;
<a href="https://mm.icann.org/mailman/listinfo/cwg-stewardship" target="_blank">
https://mm.icann.org/mailman/listinfo/cwg-stewardship</a>
</dd><dd>_______________________________________________
</dd><dd>CWG-Stewardship mailing list
</dd><dd><a href="mailto:CWG-Stewardship@icann.org" target="_blank">
CWG-Stewardship@icann.org</a>
</dd><dd>
<a href="https://mm.icann.org/mailman/listinfo/cwg-stewardship" target="_blank">
https://mm.icann.org/mailman/listinfo/cwg-stewardship</a><br><br>

</dd></dl></dd></dl>
<dd> <br>

</dd><dd>_______________________________________________
</dd><dd>CWG-Stewardship mailing list
</dd><dd><a href="mailto:CWG-Stewardship@icann.org" target="_blank">
CWG-Stewardship@icann.org</a>
</dd><dd>
<a href="https://mm.icann.org/mailman/listinfo/cwg-stewardship" target="_blank">
https://mm.icann.org/mailman/listinfo/cwg-stewardship</a><br><br>
</dd><br><br>
<br>
-- <br>
Jordan Carter<br><br>
Chief Executive <br>
InternetNZ<br><br>
04 495 2118 (office) | <a href="tel:%2B64%2021%20442%20649" value="+6421442649" target="_blank">+64 21 442 649</a> (mob)<br>
<a href="mailto:jordan@internetnz.net.nz" target="_blank">jordan@internetnz.net.nz</a>
<br>
Skype: jordancarter<br><br>
To promote the Internet&#39;s benefits and uses, and protect its
potential.<br><br>
_______________________________________________<br>
CWG-Stewardship mailing list<br>
<a href="mailto:CWG-Stewardship@icann.org" target="_blank">CWG-Stewardship@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/cwg-stewardship" target="_blank">
https://mm.icann.org/mailman/listinfo/cwg-stewardship</a></blockquote>
</div></div></div>

<br>_______________________________________________<br>
CWG-Stewardship mailing list<br>
<a href="mailto:CWG-Stewardship@icann.org">CWG-Stewardship@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/cwg-stewardship" target="_blank">https://mm.icann.org/mailman/listinfo/cwg-stewardship</a><br>
<br></blockquote></div><br></div>