- CWG-Stewardship - lists.icann.org

Re: [CWG-Stewardship] FW: Marc's presentation and report with some background
by Paul M Kane - CWG Feb. 22, 2016

Feb. 22, 2016

Thanks David Great news the RZMS modifications will be completed at the end of February so data collection can start. Sorry for delay - there is a gremlin somewhere on the CWG mailing list.... I receive direct emails to my but not those distributed via the CWG mailing list at the moment... Best Paul Quoting Grace Abuhamad <grace.abuhamad(a)icann.org>: > Hi Paul Forwarding this to you in case you did not receive through > mailing list. Please respond to the mailing list so that the rest of the > group and the original sender are included. There have been no replies to > date. I will do my best to forward you any replies to the thread > considering your issue with receiving email from the mailing list. > > Grace > > On 2/11/16, 11:48 AM, "cwg-stewardship-bounces(a)icann.org on behalf of > David Conrad" <cwg-stewardship-bounces(a)icann.org on behalf of > david.conrad(a)icann.org> wrote: > > >Hi, > > > >On the 76th CWG call on February 4th > >(https://community.icann.org/x/nJBlAw) Marc Blanchet of Viagenie gave a > >presentation on the work ICANN contracted them to perform that attempted > >to derive approximations of the SLEs using the current RZMS and RT logs > >and databases. Attached is the PowerPoint deck that Marc used for his > >presentation as well as the final report detailing his analyses. I am > >circulating these reports for your review. > > > > > >Based on the questions raised during the CWG call, it seems there might > >have been some confusion around why that work was undertaken and how it > >relates to the implementation of the SLEs. I am providing some background > >here to help remove any confusion. My apologies in advance for the length > >of this message, however I believe it important for there to be clarity > >on this issue. > > > >1. Before the SLEs were developed, ICANN staff informed the DT-A that the > >current RZMS and RT systems collect performance metrics as directed by > >NTIA and our own internal requirements. The DT-A felt these metrics were > >insufficient to ensure IANA performance met community requirements and > >that new metrics would be necessary. ICANN staff informed the DT-A that > >changes to performance metrics would require code changes to the RZMS. > > > > > >2. After the SLEs were developed, ICANN staff informed the CWG that due > >to the number of simultaneous demands placed upon ICANN to safely > >and securely modify systems and processes to meet transition > >requirements, ICANN staff estimated the code changes to RZMS would be > >completed by the end of March 2016. Some in the CWG suggested ICANN add > >additional staff to the RZMS development team in an attempt to deploy the > >code sooner. ICANN informed the CWG that doing so would more likely > >result in development taking longer since any new developers would need > >to become familiar with the existing code base and this familiarization > >would necessarily involve interruptions to the existing development team, > >delaying their efforts. > > > > > >3. During ICANN 54, ICANN staff were informed of a new requirement that > >SLE data must be collected for a period of 6 months before SLAs could be > >set. ICANN staff was further informed that the March 2016 timeframe was > >unacceptable since a 6-month data collection requirement would lead to > >insufficient time being available to incorporate the SLE-derived SLAs > >into the ICANN-PTI contract. A request was made to ICANN to make > >available RZMS and RT raw data so that SLEs could be extracted from data > >collected by the current RZMS/RT systems. Due to the confidential nature > >of the root zone change request data, which includes email discussions > >between ICANN staff and the requesters in which potentially business > >proprietary details of registry operation are disclosed, ICANN staff > >informed the CWG chairs and DT-A that releasing the raw RZMS/RT data > >would be a violation of existing IANA policy and thus, would not be > >possible, particularly to any organization that competes in the domain > >name space. ICANN staff also again explained that the RZMS/RT systems do > >not currently collect data the way the SLEs were defined and the primary > >task for ICANN was to modify RZMS in order to collect the new SLEs. > > > > > >4. As a compromise to try to address the new 6-month data collection > >requirement, ICANN staff contracted with Viagenie as an independent and > >neutral third-party to explore whether the data collected by the current > >RZMS/RT system could be used to "seed" some portion of the SLEs, thereby > >reducing the data collection time requirement. > > > > > >5. Viagenie completed their work and presented a summary on the Feb 4th > >CWG call, confirming that: (a) The current RZMS/RT systems do not collect > >data in accordance with the newly defined SLEs; (b) The heuristics > >developed provided approximations for most metrics, but some > >approximations were less conclusive; and (c) The RZMS/RT tool is a > >complex system that frequently relies on email interactions for > >progressing request state. > > > > > >6. In parallel to the work ICANN contracted Viagenie to perform, ICANN > >has continued to pursue modifying the RZMS system to collect data in the > >way that the SLEs were defined. ICANN now expects that the RZMS > >modifications will be completed at the end of February, a month ahead of > >schedule. Data collection for the new SLEs can thus begin in March. > >Assuming everything goes well, this would allow for sufficient time for > >SLE data collection without delay of the transition in order to meet the > >6-month SLE data collection requirement. > > > > > >The main approach to implementing the SLEs had always been to make code > >changes to the RZMS so that it can capture processing time data that the > >DT-A defined for all future change request processing. ICANN is on-track > >to have this work completed by the end of this month, February. > > > > > >If the CWG would like any additional clarification around the work > >performed by Viagenie, the RZMS development work, or other aspects of the > >technical implementation of the transition, please let ICANN staff know > >and we will be happy to provide clarification. > > > > > >Regards, > >-drc > >ICANN CTO > > > > > >

6 6

FW: [Iana-ipr] Notes from 15 Feb 2016
by Jonathan Robinson Feb. 17, 2016

Feb. 17, 2016

All, Please see below for the notes from the most recent IANA IPR call. The draft principle terms are available here: <https://docs.google.com/document/d/1oR3nmHl1fK7BEWOBK65KyvnmhTJZX70j9q4Ne9i…> Thanks, Jonathan -----Original Message----- From: Alan Barrett [mailto:alan.barrett@afrinic.net] Sent: 16 February 2016 14:53 To: iana-ipr(a)nro.net Subject: [Iana-ipr] Notes from 15 Feb 2016 Notes from IANA IPR call, 15 Feb 2016, 21:00 UTC Present: - Alan Barrett (NRO) - Paul Wilson (NRO) - Nurani Nimpuno (CRISP) - Greg Shatan (CWG) - Jonathan Robinson (CWG) - Jari Arkko (IETF) - Andrew Sullivan (IAB) - German Valdez (Secretariat) Apologies: - Izumi Okutani (CRISP) - Lise Fuhr (CWG) 1. Mailing list read-only subscription by observers German confirmed that the iana-ipr(a)nro.net mailing list is open for subscription from the public, but is moderated in such a way that posts are allowed only from the small group of members. 2. Draft document read-only access by observers Greg confirmed that read-only access to the “Principle Terms” draft document in Google Docs was possible using this link: <https://docs.google.com/document/d/1oR3nmHl1fK7BEWOBK65KyvnmhTJZX70j9q4Ne9i…> This link may be published. Members of this small group have all received a different link via email, which allows editing and commenting. 3. Tentative acceptance of non-controversial edits Jonathan confirmed that he and Lise had reviewed the document. All agreed that non-controversial edits may be tentatively “accepted” in the draft document in Google Docs. Acceptance of edits is not binding on any party. 4. Discussion of items that have been flagged in the document 4.1. Sublicensing rights It was agreed that the document should explicitly give ICANN the right to sublicense rights to PTI. 4.2. Registrar, registrant and admin contact for IANA domain names There was discussion on ICANN’s expressed desire for "operational control over the IANA.ORG domain”, and how to provide that. ICANN position, as stated in August 2015, is published at <https://www.icann.org/news/announcement-2015-08-15-en>. It was agreed that the registrant of the IANA domain names must be the same as the owner of the IPR (to be the IETF Trust). It also seemed clear that ICANN should be both the administrative contact and the technical contact for the IANA domain names. Andrew suggested that some registrars provide services in which multiple approvals would be required for any operational change. He suggested that using such a registrar could provide ICANN with the assurance that they would have sufficient operational control. Jonathan suggested that we could allow multiple registrars the opportunity to bid on such a service. ACTION: Andrew to edit the document to outline the requirements for multiple approvals for any action by the registrar. 4.3. Size of IIGC The draft (seciton 2b) says "the RIRs, the IETF and the names community will each select [five (5)] representatives (the “IANA IPR Reps”) to serve on an IANA IPR Governance Council (“IIGC”).” There was general agreement that this should be changed to three (3) representatives from each of the three operational communities. 4.4. Exclusive license There was a long discussion on the implications of an exclusive license to ICANN. The IETF and the RIRs need to refer to the name IANA, and they might occasionally use the logo. Greg said that descriptive or nominative use of the name was allowed without a licence, but use of the logo might need a licence. Alan was concerned that granting an exclusive licence to ICANN would prevent the granting of a licence for another party to use the logo. Greg explained that exclusivity was restricted to a field of use, so granting an exclusive licence to ICANN for provideint the IANA services would not prevent granting a licence to another party to sue the logo for some legitimate reason. Greg also clarified that granting an exclusive licence to ICANN would prevent the IETF Trust from claiming to provide the AINA services, but would not interfere with the IETF Trust’s ability to use the marks in a descriptive way. ACTION: Greg to edit the document to clarify that the exclusive licence would be for a specified field of use. Andrew noted that there is an IANA registry that is not managed by ICANN (the ENUM registry managed by the RIPE NCC), and there is a non-IANA registry that is managed by the ICANN IANA department (the timezone database). Licencing would need to accommodate these and similar cases. ACTION: Andrew to edit the document to mention the cases of IANA registries not managed by ICANN, and non-IANA registries managed by the ICANN IANA department. 4.5. Ability for IETF Trust to use the marks This issue had been discussed under the previous agenda item. 4.6. Quality of service Greg clarified that the text in section 3b requiring “consistent quality at least equal to the quality of services offered by ICANN immediately prior to the transition” was a standard formulation. There does not seem to be a need to add more detailed quality rules to the document. 4.7. Request to engage a new IANA service provider The draft (section 3g) say "the Trust may request that the relevant operational community or communities begin the process to engage a new IANA service provider.” Jari had expressed a concern that a decision to engage a new IANA service provider shoudl come fomr the operational communities, not from the IETF Trust. Andrew said that there was a tension between the Trust’s need to perform quality control, and the need for the Trust to follwo the community’s wishes. Greg said that the term “request” had been chosen deliberately in an attempt to balance these two goals. Greg also said that this phrase should not be read in isolation, but in the context of the entire section 3g, which lists several escalation steps. There was general agreement that the affected operational communities should make the decision about engaging a new IANA service provider, and that this part of the “Principle Terms” draft should be brought to the communities’ attention during discussion. 4.8. Other issues No other issies were discussed. 5. Next steps The draft "Principle Terms” document should be discussed in the operational communities. This link to the document may be used: <https://docs.google.com/document/d/1oR3nmHl1fK7BEWOBK65KyvnmhTJZX70j9q4Ne9i…> The next meeting will be in two weeks, on Monday 29 February at a time to be determined. This will be shortly before the ICSANN 55 meeting in Marrakesh. — _______________________________________________ Iana-ipr mailing list Iana-ipr(a)nro.net https://www.nro.net/mailman/listinfo/iana-ipr

2 3

Update RE: CWG IANA Budget Call 9 Feb 16 - Suggestion to ensure financial stability of PTI.
by Lise Fuhr Feb. 16, 2016

Feb. 16, 2016

Dear All, Yesterday we had a call regarding the CCWG implementation of our budget requirements. The call had two purposes: 1. To address some concerns raised by CWG member Paul Kane 2. To make sure that Sidley has an overview of the actual changes in relation to the draft we commented on in December 2015. 1. Paul's concern is that the PTI budget is not sufficiently ring fenced in relation to ICANN if anything goes wrong (e.g. bankruptcy) and that this creates a possible instability in the future. To solve this issue Paul suggested a three year escrow or a reserve fund. At the call there seemed to be general support for the idea of extra financial security to PTI. Since this is not a part of the requirements to the CCWG nor an explicit part of the proposal the chairs will like to underline that we can't amend the proposal nor include this in the CCWG requirements. We believe that this can be a part of the implementation and we will discuss the way forward on the next CWG call. 2. Since Sidley couldn't join the call yesterday we didn't manage to give them an overview of the actual changes to the budget requirements. Furthermore we didn't have time to discuss the changes at the call so there is no recording and hence a need to inform Sidley about these changes in writing. The chairs suggests that this information is given to Sidley from the DTO/the chair of DTO as soon as possible. Best regards, Lise -----Original Message----- From: Gomes, Chuck [mailto:cgomes@verisign.com] Sent: 10 February 2016 04:34 To: Paul M Kane - CWG Cc: Paul M Kane (Paul.Kane(a)communitydns.net) allan.macgillivray(a)cira.ca; Bart Boswinkel (bart.boswinkel(a)icann.org) Maarten Simon; Jordan Carter; 'Jonathan Zuck' (jzuck(a)actonline.org) 'Jonathan Robinson' (jonathan.robinson(a)ipracon.com) Lise Fuhr; Grace Abuhamad (grace.abuhamad(a)icann.org) Subject: RE: CWG IANA Budget Call 9 Feb 16 - Suggestion to ensure financial stability of PTI. Thank you very much Paul. I am not a lawyer either so I will let Lise and Jonathan decide how to refine the language. Whether or not 3 years reserve is the right amount or not, I don't personally know but we can discuss that on the CWG list as Lise and Jonathan see fit. Chuck -----Original Message----- From: Paul M Kane - CWG [mailto:paul.kane-cwg@icb.co.uk] Sent: Tuesday, February 09, 2016 10:13 PM To: Gomes, Chuck Cc: Paul M Kane (Paul.Kane(a)communitydns.net<mailto:Paul.Kane@communitydns.net>); allan.macgillivray(a)cira.ca<mailto:allan.macgillivray@cira.ca>; Bart Boswinkel (bart.boswinkel(a)icann.org<mailto:bart.boswinkel@icann.org>); Maarten Simon; Jordan Carter; 'Jonathan Zuck' (jzuck(a)actonline.org<mailto:jzuck@actonline.org>); 'Jonathan Robinson' (jonathan.robinson(a)ipracon.com<mailto:jonathan.robinson@ipracon.com>); Lisa Fuhr (fuhr(a)etno.eu<mailto:fuhr@etno.eu>); Grace Abuhamad (grace.abuhamad(a)icann.org<mailto:grace.abuhamad@icann.org>) Subject: Re: CWG IANA Budget Call 9 Feb 16 - Suggestion to ensure financial stability of PTI. Chuck Thanks for the call yesterday ..... As requested, below is my first cut at a potential Bylaw (I am not a lawyer!!) - change as you wish Best Paul To respect the operational and financial autonomy of the IANA/PTI service to the community, the Board of ICANN shall provide an arms-length mechanism for the management board of PTI to be able to undertake the independent financial administration and accountability of PTI by ensuring a dedicated rolling three year reserve for future expenses and contingencies reasonably related to the legitimate activities of PTI.

2 3

Marc's presentation and report with some background
by David Conrad Feb. 16, 2016

Feb. 16, 2016

Hi, On the 76th CWG call on February 4th (https://community.icann.org/x/nJBlAw) Marc Blanchet of Viagenie gave a presentation on the work ICANN contracted them to perform that attempted to derive approximations of the SLEs using the current RZMS and RT logs and databases. Attached is the PowerPoint deck that Marc used for his presentation as well as the final report detailing his analyses. I am circulating these reports for your review. Based on the questions raised during the CWG call, it seems there might have been some confusion around why that work was undertaken and how it relates to the implementation of the SLEs. I am providing some background here to help remove any confusion. My apologies in advance for the length of this message, however I believe it important for there to be clarity on this issue. 1. Before the SLEs were developed, ICANN staff informed the DT-A that the current RZMS and RT systems collect performance metrics as directed by NTIA and our own internal requirements. The DT-A felt these metrics were insufficient to ensure IANA performance met community requirements and that new metrics would be necessary. ICANN staff informed the DT-A that changes to performance metrics would require code changes to the RZMS. 2. After the SLEs were developed, ICANN staff informed the CWG that due to the number of simultaneous demands placed upon ICANN to safely and securely modify systems and processes to meet transition requirements, ICANN staff estimated the code changes to RZMS would be completed by the end of March 2016. Some in the CWG suggested ICANN add additional staff to the RZMS development team in an attempt to deploy the code sooner. ICANN informed the CWG that doing so would more likely result in development taking longer since any new developers would need to become familiar with the existing code base and this familiarization would necessarily involve interruptions to the existing development team, delaying their efforts. 3. During ICANN 54, ICANN staff were informed of a new requirement that SLE data must be collected for a period of 6 months before SLAs could be set. ICANN staff was further informed that the March 2016 timeframe was unacceptable since a 6-month data collection requirement would lead to insufficient time being available to incorporate the SLE-derived SLAs into the ICANN-PTI contract. A request was made to ICANN to make available RZMS and RT raw data so that SLEs could be extracted from data collected by the current RZMS/RT systems. Due to the confidential nature of the root zone change request data, which includes email discussions between ICANN staff and the requesters in which potentially business proprietary details of registry operation are disclosed, ICANN staff informed the CWG chairs and DT-A that releasing the raw RZMS/RT data would be a violation of existing IANA policy and thus, would not be possible, particularly to any organization that competes in the domain name space. ICANN staff also again explained that the RZMS/RT systems do not currently collect data the way the SLEs were defined and the primary task for ICANN was to modify RZMS in order to collect the new SLEs. 4. As a compromise to try to address the new 6-month data collection requirement, ICANN staff contracted with Viagenie as an independent and neutral third-party to explore whether the data collected by the current RZMS/RT system could be used to "seed" some portion of the SLEs, thereby reducing the data collection time requirement. 5. Viagenie completed their work and presented a summary on the Feb 4th CWG call, confirming that: (a) The current RZMS/RT systems do not collect data in accordance with the newly defined SLEs; (b) The heuristics developed provided approximations for most metrics, but some approximations were less conclusive; and (c) The RZMS/RT tool is a complex system that frequently relies on email interactions for progressing request state. 6. In parallel to the work ICANN contracted Viagenie to perform, ICANN has continued to pursue modifying the RZMS system to collect data in the way that the SLEs were defined. ICANN now expects that the RZMS modifications will be completed at the end of February, a month ahead of schedule. Data collection for the new SLEs can thus begin in March. Assuming everything goes well, this would allow for sufficient time for SLE data collection without delay of the transition in order to meet the 6-month SLE data collection requirement. The main approach to implementing the SLEs had always been to make code changes to the RZMS so that it can capture processing time data that the DT-A defined for all future change request processing. ICANN is on-track to have this work completed by the end of this month, February. If the CWG would like any additional clarification around the work performed by Viagenie, the RZMS development work, or other aspects of the technical implementation of the transition, please let ICANN staff know and we will be happy to provide clarification. Regards, -drc ICANN CTO

2 1

FW: CCWG-Accountability timeline
by Jonathan Robinson Feb. 12, 2016

Feb. 12, 2016

All, Please see below. This does provide a little more leeway to finalise our communication to the CCWG but, in essence, it remains ASAP given that the the Chartering organisations will be waiting on our comment. Jonathan From: Mathieu Weill [mailto:mathieu.weill@afnic.fr] Sent: 12 February 2016 15:32 Subject: CCWG-Accountability timeline Dear Chartering Organizations, As you know, the Cross Community Working Group on Enhancing ICANN Accountability (CCWG-Accountability) has been working since December 2014, to develop a set of proposed enhancements to ICANN's accountability. The work is nearing completion and we want to inform you of the current timeline for finalization of our report so that you can be prepared to review and act upon the final report when its completed and formally sent to your organization for consideration and approval. * 12 Feb - Report sent by 22:00 UTC to the CCWG Leadership Team and CCWG Legal Counsel for review with all materials posted on the Wiki ( <https://community.icann.org/x/iw2AAw> https://community.icann.org/x/iw2AAw) for everyone to view. * 15 Feb - Report updated (if needed) to incorporate edits from CCWG Leadership Team and Legal. * 16 Feb - Report sent to CCWG for 48-hour review (and posted on the Wiki at <https://community.icann.org/x/iw2AAw> https://community.icann.org/x/iw2AAw) * 17 Feb - Minority statements due for incorporation into Final Report. * 18 Feb - Final Report sent to Chartering Organizations for consideration and approval. Once the Final Report is in the hands of your organizations, these are the expected dates for the final steps, as we discussed on the <https://www.icann.org/resources/pages/transition-facilitation-2015-09-23-en > Transition Program Facilitation call this past Tuesday: * 25 Feb - CWG-Stewardship sign-off letter delivered to Chartering Organizations, then to ICG. * By 9 Mar at the latest - Sign-off on Final Report by Chartering Organizations at ICANN55 in Marrakech (in time for the Board to consider). * 10 Mar - Public Board Meeting and hand over from ICANN Board to NTIA. We look forward to the result of the discussions within your community and endorsement of the final document. Please feel free to encourage your community members to begin reviewing the materials at their earliest convenience. If you have any questions about our timeline or suggestions for our process, please let us know how we can assist. Sincerely, Thomas, Mathieu, and Leon CCWG-Accountability Co-Chairs

1 0

CWG Stewardship Dependency on CCWG Accountability - Process & Timing
by Jonathan Robinson Feb. 12, 2016

Feb. 12, 2016

All, An update on process and timing regarding our work on the CWG Stewardship Dependency on CCWG Accountability. * CWG Accountability plans to publish their draft Supplementary Proposal to the CCWG on 16 February 2016. * Following that, the CCWG plan is to distribute the Supplementary Proposal to the Chartering Organisations on 18 February. * The CCWG and the Chartering Organisations will reasonably expect us - the CWG Stewardship - to confirm ASAP that the conditionality we defined has been met. * When CCWG published their previous version - the third Draft Proposal - we (with the assistance of Sidley Austin) sent a detailed response (attached for reference). * This detailed response now needs updating to reflect the changes that have since been made in the Supplementary Proposal and the Client Committee will ask Sidley to undertake that work. * Accordingly, we expect to have an up-to-date response (to the CCWG Supplementary Proposal) prepared by Sidley for final review by this group as close to the 18 February publication of the CCWG Supplementary Proposal as possible. * Please be on the lookout for this response (currently anticipated to be Fri 19 February) and be prepared to offer any feedback immediately and no later than 23h59 UTC on Mon 22 February. * Lise and I will then ensure that the final response is communicated to the CCWG, the Chartering Organisations and, of course, the ICG on or around 23 February. Any concerns, questions or issues arising, please let us know ASAP. Thank-you, Jonathan & Lise CWG Stewardship Co-Chairs

1 0

FW: CWG-Stewardship Notification to GNSO Council concerning conditionality requirements
by Jonathan Robinson Feb. 12, 2016

Feb. 12, 2016

All, Please see attached from the GNSO. Jonathan & Lise From: Marika Konings [mailto:marika.konings@icann.org] Sent: 09 February 2016 19:40 To: Jonathan Robinson <jrobinson(a)afilias.info>; Lise Fuhr <Fuhr(a)etno.eu> Cc: James M. Bladel <jbladel(a)godaddy.com>; Austin, Donna <Donna.Austin(a)neustar.biz>; Heather Forrest <Heather.Forrest(a)acu.edu.au>; Grace Abuhamad <grace.abuhamad(a)icann.org>; gnso-secs(a)icann.org Subject: CWG-Stewardship Notification to GNSO Council concerning conditionality requirements Dear Jonathan, Lise, Please find attached for your attention a letter from the GNSO Council leadership concerning the CWG-Stewardship notification to the GNSO Council concerning the conditionality requirements in the CCWG-Accountability Supplemental Proposal. Best regards, Marika

2 2

FW: CCWG - Recommendation 7 - Final
by Grace Abuhamad Feb. 12, 2016

Feb. 12, 2016

Dear all — Passing this along to note that the CWG-Stewardship edit was accepted and incorporated into the text. From: <acct-staff-bounces(a)icann.org> on behalf of Bernard Turcotte <turcotte.bernard(a)gmail.com> Date: Wednesday, February 10, 2016 at 7:37 PM To: Accountability Cross Community <accountability-cross-community(a)icann.org>, ACCT-Staff <acct-staff(a)icann.org> Subject: [Acct-Staff] CCWG - Recommendation 7 - Final All, As of the close of the comment period for Recommendation 7 only 1 comment had been received (from the CWG review of the CCWG recommendation 7): > Suggested edit: Sharon Flanagan (Sidley): Para 8 of Annex 7 -- insert "of > direct customers" after "ICANN Bylaws will provide that PTI service > complaints" Becky Burr who was present at this meeting approved the edit considering it a clarification. As such the change has been made and you will find both a red line and clean version attached to this email. Given this was the only change to the legal review version and that it was proposed by a Sidley lawyer there is no need for further legal review. Therefore this recommendation is considered final. Thank you. Bernard Turcotte ICANN Staff Support for CCWG On Mon, Feb 8, 2016 at 8:53 PM, Bernard Turcotte <turcotte.bernard(a)gmail.com> wrote: > > Per the request of the co-chairs we are publishing the final draft version of > Annex 7 for comments by the CCWG. > > This version is the version produced by legal counsel as distributed this > weekend with additional edits approved by the co-chairs and BBurr. These > include the comments from C. Gomes of the CWG and the possibility of a review > of DIDP requests if against Bylaws (similar to expert panels) as per BBurr > request. > > You will find attached 2 documents, one with track changes (staff and legal) > and the other a clean version. > > The comment period for the CCWG will run from 02:00 UTC Tuesday 9 February and > will close at 02:00 UTC Thursday11 February - providing the 48 hour comment > period. > > Please make your comments via email to the full CCWG list and use the > following subject line to identify your email as being a comment on this: > >> CCWG - Recommendation >> 7 >> - Final draft for CCWG comments >> > or simply reply to this email. > > Comments will be compiled in semi-real time by staff > . > > > > Thank You. > > > Bernard Turcotte > ICANN Staff Support for CCWG >

1 0

Notes, Recordings, Transcript - CWG IANA IRP Informational Meeting- 10 February 2016
by Brenda Brewer Feb. 10, 2016

Feb. 10, 2016

Dear all, The notes, recordings and transcripts for the CWG IANA IRP Informational Meeting that took place on 10 February @ 22:00 UTC will be available here: https://community.icann.org/x/fgiAAw A copy of the notes may be found below. Kind regards, Brenda Notes IRP Informational Meeting -10 February 2016 @ 22:00 UTC Purpose of the call: discuss the IRP section of the requirements / certification of CCWG-Accoutability work, considering that the CCWG report is in finalization stages. Text from requirements letter (21 December): Section 7, Conclusion: - As we noted in our comment letter to the Second Draft Proposal, the Third Draft Proposal does not explicitly address the CWG-Stewardship requirement that an independent review process be available for claims relating to actions or inactions of PTI. This requirement could be addressed in a number of ways. For example, a provision could be added to the ICANN Bylaws that would require ICANN to enforce its rights under the ICANN-PTI Contract/Statement of Work (SOW), with a failure by ICANN to address a material breach by PTI under the contract being grounds for an IRP process by the Empowered Community (after engagement and escalation). Another approach would be to expand and modify, as appropriate, the IRP process currently contemplated by the Third Draft Proposal to cover claims relating to actions or inactions of PTI, with the ICANN Bylaws and PTI governance documents expressly confirming that the IRP process is binding on PTI (which provisions would be Fundamental Bylaws that could not be amend. Presentation by Becky Burr, lead author in CCWG-Accountability Questions / Answers: * If service complaints are not resolved through mediation, direct customers can bring an IRP. Should we limit the term? No, since we are looking to the direct customers of PTI. Suggested edit: Sharon Flanagan (Sidley): Para 8 of Annex 7 -- insert "of direct customers" after "ICANN Bylaws will provide that PTI service complaints" * Standard: "material harm" -- CWG proposal was silent on this. Is this ok with CWG? No comments rom CWG. * How does the IRP fit - either within or outside - the proposed escalation process outlined in the CWG propopsal? The IRP does not replace the existing escalation processes, and both processes could happen. * Escalation processes in the CWG proposal come before the IRP. * Is there a different between appealing to PTI or ICANN? In practice, no, since ICANN will have responsibility for performance of PTI. * Does the IRP need to be embedded in the PTI Bylaws? The ICANN-PTI Contract can have a provision for PTI to abide by the IRP. Whether this provision is also in the Bylaws is a question for implememtation. Are the CWG folks satisfied that the requirements are met? Is Sidley satisfied with the rationale provided, so that they can review their requirements letter? CWG aims to sign-off by 18 Feb.

1 0

CWG Co-Chairs Update
by Jonathan Robinson Feb. 10, 2016

Feb. 10, 2016

All, An update on three meetings which took place yesterday, all of which were recorded. Also, a comment on the IRP. Transition Facilitation - We are into a very tight time window of opportunity to finalise the IANA Transition proposal - CCWG Accountability expects to publish its Supplementary Proposal to the Chartering Organisations on 18 February 2016 - The Chartering Organisations will want to know whether or not the CWG Stewardship conditions have been met - The ICG is poised to transmit its proposal to the ICANN board and will also wish to know whether or not the CWG Stewardship conditions have been met - Therefore the CWG Stewardship needs to be in a position to certify that our conditions have been met as soon as possible and ideally, at the same time as the Supplementary Proposal is published - We have been doing background work (see below) and are able to continue to do so, focussing particular attention on the IANA Budget & and the Independent Review components of the CWG / CCWG work IANA Budget (as a component of CWG Stewardship / CCWG Accountability proposals) - A call was run yesterday to discuss any lasting concerns with the work on the IANA Budget - Notes and information from that call have been circulated to the CWG Stewardship mailing list - The key question for the CWG is what, if any, outcomes from that do we wish to support? If so, how do we accommodate those? - In dealing with this key question, we need to be mindful of the scope and timescales of the CCWG work as well as the constraints we face in adapting our proposal at this stage - We will co-ordinate with Sidley on this issue IANA Transition Budget - A meeting was held between the ICANN Board, senior staff and the CCWG Accountability / CWG Stewardship Co-chairs - All parties recognise the seriousness of budget overruns given the magnitude that has occurred in this case (relating to the overall IANA Stewardship Transition project) - The focus was on effective cost-control for the remainder of the financial year (to June 2016) and beyond - This is work in progress IRP - A meeting to review the status quo will be held later today (22h00 UTC) We will work with you over the next week with the aim of completing our certification of the CWG dependencies so that the chartering organisations can then go on to review the CCWG Accountability Supplementary Proposal confident in the knowledge that the CWG Stewardship is satisfied. Thank-you, Jonathan Robinson & Lise Fuhr CWG Co-Chairs

1 0