<p dir="ltr">sent from Google nexus 4<br>
kindly excuse brevity and typos.<br>
On 21 Apr 2015 23:04, "Client Committee List for CWG" <<a href="mailto:cwg-client@icann.org">cwg-client@icann.org</a>> wrote:<br>
><br>
> Dear All,<br>
><br>
> <br>
><br>
> Following up on today’s call, below is proposed language for III. A and Annex L.<br>
><br>
> <br>
><br>
> III.A.<br>
><br>
> <br>
><br>
> [to replace current first two bullets]<br>
><br>
> <br>
><br>
> • A new separate legal entity, Post-Transition IANA (PTI), would be formed as an affiliate of ICANN. The existing IANA naming functions, administrative staff and related resources, processes, data and know-how would be legally transferred into PTI.<br>
><br>
> <br>
SO: "IANA naming functions," this item was one of what I raised in my comment which Greg forwarded to client( unfortunately I did not get response on), I am unclear why that phrase is still maintained. The understanding i got was that PTI will be the new IANA operator post-transition so again how does the message above put that in context?</p>
<p dir="ltr">><br>
> • ICANN would enter into a contract with PTI, granting PTI the rights and obligations to serve as the IANA Functions Operator for the naming functions. This contract would also include service level agreements for the naming functions.<br>
><br>
> <br>
SO:<br>
Again this validates my comment above; is PTI no longer going to be IANA function operator but IANA *names* function operator? Are we trying to split the functions and divide IANA staff, funding, resources et all?</p>
<p dir="ltr">This seem unclear and can be complicated.</p>
<p dir="ltr">That said, I hope we are not too focused on legal possibilities at the expense of operational realities.</p>
<p dir="ltr">I rest my case.</p>
<p dir="ltr">Regards</p>
<p dir="ltr">><br>
> Annex L:<br>
><br>
> <br>
><br>
> Triggers for the Separation Mechanism<br>
><br>
> An outcome of an IANA Function Review could include a recommendation to initiate a separation of the IANA Functions Operator. This recommendation would be submitted to the ICANN Board for consideration, with ultimate input by the multistakeholder community through the CCWG Accountability mechanisms under consideration.(1) <br>
><br>
> (1) A point for public comment is whether the IANA Function Review recommendation for separation should first be submitted to the Supporting Organizations and Advisory Committees for their approval before escalation to the ICANN Board, or whether the IANA Function Review recommendation for separation should be submitted directly to the ICANN Board by the IANA Function Review Team.<br>
><br>
> <br>
><br>
> <br>
><br>
> SHARON FLANAGAN<br>
> Partner<br>
><br>
> Sidley Austin LLP<br>
> +1.415.772.1271<br>
> <a href="mailto:sflanagan@sidley.com">sflanagan@sidley.com</a><br>
><br>
> <br>
><br>
> From: <a href="mailto:cwg-client-bounces@icann.org">cwg-client-bounces@icann.org</a> [mailto:<a href="mailto:cwg-client-bounces@icann.org">cwg-client-bounces@icann.org</a>] On Behalf Of Client Committee List for CWG<br>
> Sent: Tuesday, April 21, 2015 12:22 PM<br>
> To: Client Committee<br>
> Subject: [client com] FW: Notes CWG Meeting #42 on Tuesday 21 April at 17:00 UTC<br>
><br>
> <br>
><br>
> Client Committee — Here below are the notes from the call we just ended. <br>
><br>
> <br>
><br>
> Timeline attached and also on the Wiki. <br>
><br>
> <br>
><br>
> CWG Meeting #42 on Tuesday 21 April at 17:00 UTC<br>
><br>
> <br>
><br>
> Agenda:<br>
><br>
> 1. Opening Remarks<br>
><br>
> 2. Open items on Draft Proposal 3.4<br>
><br>
> a. To be resolved by Design Teams?<br>
><br>
> b. To be resolved by CWG?<br>
><br>
> c. To be resolved during Public Comment?<br>
><br>
> 3. Public Comment<br>
><br>
> a. Structure <br>
><br>
> b. Associated Communications <br>
><br>
> c. Role of CWG Members<br>
><br>
> 4. Timeline<br>
><br>
> 5. AOB<br>
><br>
> 6. Closing Remarks<br>
><br>
> <br>
><br>
> Notes: <br>
><br>
> <br>
><br>
> 1. Opening Remarks<br>
><br>
> · Last call before the launch of the Public Comment on the 2nd Draft Proposal. <br>
><br>
> · We've converged on one proposal for structure <br>
><br>
> · Today, we'd like to conclude on the last DTs and the outstandings items. <br>
><br>
> · Need dependencies for CCWG-Accountability to be clarified and noted<br>
><br>
> <br>
><br>
> 2. Open items on Draft Proposal 3.4<br>
><br>
> The following three items are "aide-memoire" to help think through open issues and how to address them. <br>
><br>
> a. To be resolved by Design Teams?<br>
><br>
> b. To be resolved by CWG?<br>
><br>
> c. To be resolved during Public Comment?<br>
><br>
> <br>
><br>
> Section III starts on page 17<br>
><br>
> Going through Sidley comments<br>
><br>
> Change review period text to "every 5 years"<br>
><br>
> Page 22, section on IANA Function Review -- help with language from Sidley<br>
><br>
> Page 17, "ICANN to continue as IFO" -- help with language from Sidley<br>
><br>
> For DT-A, placeholder text needed because the DT is not complete: capture that significant work has been done to date, but not all are agreed. --> suggest general statement instead <br>
><br>
> <br>
><br>
> Action (Alan): provide the text for point 4 (after CCWG-Acct meeting)<br>
><br>
> Action (Staff): do a thorough copyedit<br>
><br>
> Action (Sidley): propose language for Section III and Annex L<br>
><br>
> <br>
><br>
> 3. Public Comment<br>
><br>
> <br>
><br>
> a. Structure <br>
><br>
> · As discussed in Istanbul, staff prepared a template for the comments to be submitted. <br>
><br>
> · The template will be presented in Word and PDF formats (the PDF will be fillable)<br>
><br>
> · Use of the template will be strongly encouraged, but not absolutely obligatory (free form comments are also accepted)<br>
><br>
> · The reason for using a template is to get concrete feedback and also to faciliate analysis and incorporation of feedback <br>
><br>
> · The template and the Proposal will be published in all ICANN supported languages<br>
><br>
> <br>
><br>
> b. Associated Communications <br>
><br>
> · There will be a Chairs' Foreword/Summary<br>
><br>
> · There will be an updated version of the Xplane Handout presented in Istanbul<br>
><br>
> · The idea behind the two documents is that they each provide background and narrative on the CWG work process: the foreword/summary does this in a text form, and the XPlane handout provides a visual form. <br>
><br>
> <br>
><br>
> c. Role of CWG Members<br>
><br>
> Please make sure that CWG Members ensure that their communities are aware of the comments, the suggested format, and the timeframe for comments. <br>
><br>
> <br>
><br>
> 4. Timeline<br>
><br>
> Will publish timeline to the list to save for time. <br>
><br>
> (attached here! :) )<br>
><br>
> <br>
><br>
> 5. AOB<br>
><br>
> <br>
><br>
> 6. Closing Remarks<br>
><br>
> <br>
><br>
> <br>
><br>
> ****************************************************************************************************<br>
> This e-mail is sent by a law firm and may contain information that is privileged or confidential.<br>
> If you are not the intended recipient, please delete the e-mail and any attachments and notify us<br>
> immediately.<br>
><br>
> ****************************************************************************************************<br>
><br>
><br>
> _______________________________________________<br>
> Cwg-client mailing list<br>
> <a href="mailto:Cwg-client@icann.org">Cwg-client@icann.org</a><br>
> <a href="https://mm.icann.org/mailman/listinfo/cwg-client">https://mm.icann.org/mailman/listinfo/cwg-client</a><br>
><br>
</p>