April 2016 - Accountability-Cross-Community

Re: [CCWG-ACCT] CCWG ACCT in Helsinki
by Grace Abuhamad June 7, 2016

June 7, 2016

Dear all, Following up on Mathieu’s note, here attached is a document that lays out, for avoidance of doubt, the list of members receiving funding to attend the CCWG-ACCT meeting in Helsinki. Thank you, Grace -- Grace Abuhamad Manager, Public Policy ICANN | Internet Corporation for Assigned Names and Numbers 801 17th Street NW, Suite 400 | Washington, DC 20006 Direct: +1 202 249 7545 | Mobile: +1 310 200 7638 Interested in the IANA Stewardship Transition? LEARN MORE. STAY UPDATED. FOLLOW. ENGAGE. From: <accountability-cross-community-bounces(a)icann.org> on behalf of Mathieu Weill <mathieu.weill(a)afnic.fr> Date: Tuesday, April 12, 2016 at 3:40 PM To: Accountability Cross Community <accountability-cross-community(a)icann.org> Subject: [CCWG-ACCT] CCWG ACCT in Helsinki Dear Colleagues, As discussed during our call on Apr 11, we have received confirmation from Icann that there will be a room available to support our F2F meeting in Helsinki on Sunday 26th June. This meeting will be focused on kicking off WS2 discussions, and scoping the various work items. As I said during the meeting, Icann’s suggestion for our consideration is that Icann provide support for the extra day for those CCWG-Accountability members intending to travel to the meeting B, and for those who were not planning to attend meeting B, that the remote participation is used. We hope that this information is useful to help each of you make the necessary arrangements, so that we can make this F2F successful and demonstrate the value of this event. I seize this opportunity, on behalf of the co chairs, to thank Bernie, Theresa and Xavier who liaised on our behalf with the Board Finance Committee to support our request. Best regards, -- ***************************** Mathieu WEILL AFNIC - directeur général Tél: +33 1 39 30 83 06 mathieu.weill(a)afnic.fr Twitter : @mathieuweill *****************************

5 6

Draft ICANN Bylaws Draft of April 20, 2016: CCWG=Accountability and CWG-Stewardship Certifications
by Gregory, Holly May 13, 2016

May 13, 2016

CCWG Accountability April 20, 2016 Dear CCWG-Accountability Co-Chairs, Members, Participants and Staff, We have reviewed the Proposed Draft ICANN Bylaws, dated April 20, 2016 (“Proposed Draft Bylaws”), a copy of which is attached. We believe that the Proposed Draft Bylaws are consistent with the Cross Community Working Group on Enhancing ICANN Accountability (“CCWG-Accountability”) Supplemental Final Proposal on Work Stream 1 Recommendations (23 February 2016) relating to the IANA Stewardship Transition. Accordingly, we recommend that the Proposed Draft Bylaws be posted to the community for review. Kind regards, Holly J. Gregory and Rosemary E. Fei Sidley Austin LLP and Adler & Colvin CWG-Stewardship April 20, 2016 Dear CWG Co-Chairs, Members, Participants and Staff, We have reviewed the Proposed Draft ICANN Bylaws, dated April 20, 2016 (“Proposed Draft Bylaws”), a copy of which is attached. We believe that the Proposed Draft Bylaws are consistent with the Cross Community Working Group on Naming Related Functions (“CWG-Stewardship”) Final Proposal (11 June 2015) relating to the IANA Stewardship Transition. Accordingly, we recommend that the Proposed Draft Bylaws be posted to the community for review. Kind regards, Holly J. Gregory and Sharon R. Flanagan Sidley Austin LLP HOLLY J. GREGORY Partner and Co-Chair Corporate Governance & Executive Compensation Practice Group Sidley Austin LLP 787 Seventh Avenue New York, NY 10019 +1 212 839 5853 holly.gregory(a)sidley.com<mailto:holly.gregory@sidley.com> www.sidley.com<http://www.sidley.com/> [SIDLEY] **************************************************************************************************** This e-mail is sent by a law firm and may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. ****************************************************************************************************

15 22

The whois/RDS-RT bylaw vs. current activities
by Andrew Sullivan May 2, 2016

May 2, 2016

Hi, In thinking about the way the bylaws require the regular RTs and how those might interact with other processes, I'm wondering whether we think it would be consistent with the report to say that, if a PDP is going on about any topic that is subject to regular RT, then the PDP can be counted as fulfilling the purposes of the RT? It seems to me that this is consistent with the point of the regular RT requirement (i.e. ensuring that the review happens in a timely way) without entailing that we waste time, money, and energy in multiple, potentially conflicting efforts on the same topic. Have I missed something? Best regards, A -- Andrew Sullivan ajs(a)anvilwalrusden.com

15 21

Bylaws Issue: Section 1.1(c)
by Greg Shatan May 1, 2016

May 1, 2016

All, There is an issue with Section 1.1(c), which (while relatively minor) should be corrected. (There may also be more significant issues, but I'm not going to go there. I'm just dealing with the question of whether the Bylaws carry out the intent of the Proposal.) This section currently reads: ICANN shall not regulate (i.e., impose rules and restrictions on) services that use the Internet’s unique identifiers or the content that such services carry or provide, outside the express scope of Section 1.1(a). For the avoidance of doubt, ICANN does not hold any governmentally authorized regulatory authority, and nothing in the preceding sentence should be construed to suggest that it does have authority to impose such regulations. There was a lot of discussion of this provision during the drafting process, and this particular formulation did not emerge until just before the document went out for public comment. My concern is with the last clause of the last sentence: "*nothing in the preceding sentence should be construed to suggest that it does have authority to impose such regulations.*" The particular problem is the phrase "such regulations." When lawyers use "such" like this, it replaces "the" when referring to a thing that's already been referred to by that term (or that term with adjectives). ("The door to the bedroom is 3 feet wide. ... Such door will remain open at all times.") Here, however, there's been no prior reference to "regulations," so it's completely unclear what this is referring to. *The simplest solution would be to remove this clause and end the sentence with "authority." That removes the issue of "What does "such regulations" refer to?" I support this fix.* If we want to save the last clause, things get more complicated. It could be changed to say "nothing in the preceding sentence should be construed to suggest that it does have such authority." Now it's clear that "such authority" refers to "governmentally authorized regulatory authority." It could also be changed to say "nothing in the preceding sentence should be construed to suggest that it does have authority to impose governmentally authorized regulations." However, I'm not sure that either of these are particularly useful statements or add any clarity to the situation. (The first is modestly more useful than the second.) I look forward to any thoughts. Greg

5 4

FW: CCWG bylaws public comment and other edits/suggestions
by Schaefer, Brett April 29, 2016

April 29, 2016

All, I sent this earlier to the lawyers and Chairs. Looking at my inbox, I see that others are sending comments to the list, so I decided to as well. Best, Brett ________________________________ Brett Schaefer Jay Kingham Senior Research Fellow in International Regulatory Affairs Margaret Thatcher Center for Freedom Davis Institute for National Security and Foreign Policy The Heritage Foundation 214 Massachusetts Avenue, NE Washington, DC 20002 202-608-6097 heritage.org<http://heritage.org/> From: Schaefer, Brett Sent: Friday, April 29, 2016 1:55 PM To: Gregory, Holly (holly.gregory(a)sidley.com) Rosemary E. Fei (rfei(a)adlercolvin.com) Cc: Mathieu Weill (mathieu.weill(a)afnic.fr) 'Thomas Rickert' (thomas(a)rickert.net) León Felipe Sánchez Ambía (leonfelipe(a)sanchez.mx) Subject: CCWG bylaws public comment and otehr edits/suggestions Holly and Rosemary, Here are my comments on the draft bylaws (using the redline version circulated by Holly on Wed 4/20/16) in terms of consistency with the CCWG proposal: · 1.1(d)ii(A)(1) – The RA and RAA exceptions include not just those in force as of the date, but also those under negotiation. This is not specifically mentioned in the CCWG draft. Moreover, it seems to be overly broad and inconsistent with the overall intent of the CCWG proposal that future agreements should be within the scope and mission of ICANN. Indeed, all of the other exception listed in this section only cover those in force, effective as of, or existing on the specified date. The phrase “, or undergoing negotiation as of,” should be eliminated. · 1.1(d)ii(B-D) – These agreements should not be exempted, they should be within the scope and mission of ICANN and subject to IRP challenge, as is a central principle of the CCWG report. · 1.1(d)ii(F) – The ability to renew seems very sweeping. Would this permit a “renewal” of a substantially changed agreement, even if it involves provisions outside the scope and mission of ICANN since this is the purpose of this section, if the existing terms allowed for adjustments in their terms? This renewal provision should be tightened to prevent such efforts. · 1.2(b)(viii) – The phrase “except as provided herein” is not in the CCWG draft and it is not clear what it refers to. This is concerning because it would seem to undermine the clear constraints stated prior to the phrase: “this Core Value does not create and shall not be interpreted to create any additional obligation for ICANN and shall not obligate ICANN to respond to or consider any complaint, request or demand seeking the enforcement of human rights by ICANN.” The phrase “except as provided herein” should be deleted. · 6.1(b) – The current text states that “any change in the number and/or identity of Decisional Participants for any reason (including the resignation of any Decisional Participant or the addition of new Decisional Participants as a result of the creations of additional Supporting Organizations or Advisory Committees).” Should the possibility of SSAC or RSSAC deciding that they wish to become Decisional Participants in the EC also be specifically addressed? This is not captured in either example. · 22.8 – The current text states: “If three or more Decisional Participants deliver to the Secretary a joint written certification from the respective chairs of each such Decisional Participant that the constituents of such Decisional Participants have, by consensus, determined that there is a credible allegation that ICANN has committed fraud or that there has been a gross mismanagement of ICANN’s resources, ICANN shall retain a third-party, independent firm to investigate such alleged fraudulent activity or gross mismanagement.” Why does this specify that the Decisional Participants have to decide by consensus? This is not in the CCWG report and is inconsistent with the CCWG proposal that states that EC Decisional Participants determine their own procedures. The phrase “,by consensus,” should be struck. · 22.8 – Board power to redact should not be so broad and was not specified in the CCWG proposal. The current text states: “Such report shall be posted on the Website, which may be in a redacted form as determined by the Board, including to preserve attorney-client privilege, work product doctrine or other legal privilege or where such information is confidential, in which case ICANN will provide the Decisional Participants that submitted the certification a written rationale for such redactions.” Suggest striking “, including”. · Annex D Section 1.4(b) – After “if” at the conclusion add the following phrase “after accounting for any adjustments to the below as required by the GAC Carve-out pursuant to Section 3.6(e) of the Bylaws if the Approval Action Board Notice included a GAC Consensus Statement”. This construction mirrors that for the Rejection Action and reflects the GAC carve-out as explained in the CCWG report. · Annex D Section 2.2 (c)(i)(A) – These specific rationales were not specified in the CCWG proposal and I don’t recall discussion of them. Suggest a reversion to a requirement for unspecified rationale. Edits: · 1.1(d)ii – Why is the date 1 October 2016 in brackets? The Board has committed to implementing the bylaws regardless of the transition, so the 1 October 2016 date should be firm (perhaps phrased as “on or prior to 1 October 2016” as is the case in 16.3(a)) or replaced with “upon the adoption of these bylaws”. · 4.3(a)(iii)(A)(4) – First mention of DIDP, should be spelled out. The next DIDP reference is on p. 132 and spells out document information disclosure policy. · 7.2(f)(iii) – Should conditionally be unconditionally? · 7.8(a)(i-vi) – The terms specified for seats 1-3 and for seats 9 and 12 are the same, as are 4-6 and 10 and 13, and 7-8 and 11, 14, and 15. This seems to be an artifact from the timing of the previous bylaws and should be consolidated. · 7.8(b) and 22.3 – The 1 October 2016 date seems superfluous. · 7.11(a)(B) – The deletion of “A” in the parentheses and replacement with “x” seems to be an error. · 16.1 – There does not seem to be a Section 1.1(d)(v) as referenced. · Article 16.2, 17 and 18 titles and section headers frequently lack a space between the number and text. · 18.2(a) Why is the date 1 October 2018 in brackets? · 18.6(c), 18.12(d), 19.1(c), 19.4(c), Annex D 4.2((b)(ii)(B-D) – Replace (x) and (y) with (A) and (B) to comply with the editorial style in the rest of the bylaws? · 18.6(c)(i) – space needed between “Annex D)shall” · 18.8 – Colon, not semi-colon in title · 19.5(f) – repetition: “SCWG’s SCWG Recommendations” · 19.1(c) and 19.4(c) – Is it clear what happens if the Board rejects a SCWG Creation Recommendation and the EC rejects that Board rejection? It appears that the process dies there. Should the Board be able to block the process indefinitely? Or is this where EC Board removal comes into play? Am I reading this incorrectly? Consider: · 4.2 -- The CCWG draft does not provide for interim relief or stay in the case of a request for reconsideration. However, the possibility for harm with no adequate remedy exists for such cases just as it does for the IRP, which does provide such an option. Adding similar protections, at the determination of the Ombudsman, to the reconsideration process in instances where the request is not summarily dismissed would seem to be consistent with the intent of the CCWG report although it is not expressly stated. Should the CCWG public comment suggest granting the Ombudsman authority to confer interim relief during the reconsideration process? I have broader concerns, but I restricted these comments to the matter of consistency with the CCWG proposal. On the edits, I stopped adding them after Article 19 as I was running up against a scheduled meeting and just focused on the substance. Apologies if I missed any later. Best wishes, Brett ________________________________ Brett Schaefer Jay Kingham Senior Research Fellow in International Regulatory Affairs Margaret Thatcher Center for Freedom Davis Institute for National Security and Foreign Policy x6097

1 0

inconsistency in bylaws spotted
by Niels ten Oever April 28, 2016

April 28, 2016

Dear all, I hope this email finds you well. Upon re-reading the bylaw text I came across the following issue which does not seem to be in accordance with what we agreed in WS1. The CCWG report says where it comes to Human Rights: [ccwg report] “Within its Core Values, ICANN will commit to respect internationally recognized Human Rights as required by applicable law. This provision does not create any additional obligation for ICANN to respond to or consider any complaint, request, or demand seeking the enforcement of Human Rights by ICANN. This Bylaw provision will not enter into force until (1) a Framework of Interpretation for Human Rights (FOI-HR) is developed by the CCWG-Accountability as a consensus recommendation in Work Stream 2 (including Chartering Organizations’ approval) and (2) the FOI-HR is approved by the ICANN Board using the same process and criteria it has committed to use to consider the Work Stream 1 recommendations.” [/ccwg report] But when I look at the bylaw text it says: [proposed bylaw] The Core Value set forth in Section 1.2(b)(viii) shall have no force or effect unless and until a framework of interpretation for human rights (“FOI-HR”) is approved by (i) the CCWG-Accountability as a consensus recommendation in Work Stream 2, (ii) each of the CCWG-Accountability’s chartering organizations and (iii) the Board (in the case of the Board, using the same process and criteria used by the Board to consider the Work Stream 1 Recommendations). [/proposed bylaw] Now it is explicitly required that all Chartering Organizations approve the Framework of Interpretation, whereas during WS1 it was agreed that for WS2 we would use exactly the same process of approval as for WS1. What makes this even more divergent is that this clause is only added for Human Rights in the proposed bylaws and not for any other bylaw. Whereas there was no exceptional procedure for human rights discussed for WS2. What I propose is to refer to the charter of the CCWG on Accountability for the decision making of all processes in WS2 (including the decision making on the FoI on Human Rights) and not create separate or new requirements or processes. All the best, Niels -- Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D 68E9

22 52

[blog] IANA Stewardship Transition Planning Update (Volume 1)
by Hillary Jett April 27, 2016

April 27, 2016

Original link: https://www.icann.org/news/blog/iana-stewardship-transition-planning-update… IANA Stewardship Transition Planning Update (Volume 1) This update marks the beginning of an initiative mentioned by Akram Atallah in his 12 April 2016 blog, aimed at keeping interested stakeholders up to date on the latest developments and progress relating to implementation planning for the IANA Stewardship Transition, the proposal for which is currently under review by NTIA. These updates will detail what work has been identified based on the proposals of the IANA Stewardship Transition Coordination Group (ICG) and the Cross Community Working Group on Enhancing ICANN Accountability (CCWG-Accountability), and provide insight into what is happening on a week-to-week basis. Our goal is to provide consistent, structured updates that give any interested party access to latest information, documents and announcements. We will also post direct links to the mailing lists where conversations are taking place on each of the planning elements. ICANN has identified work that must be completed for the transition to occur successfully. The planned work has been mapped across 14 projects and grouped into 3 tracks. You can find more information on the ICANN website here. - Trang Nguyen, Senior Director of Strategic Programs Root Zone Management The Root Zone Management implementation planning track contains projects relating to changes to the Root Zone Management System (RZMS) to remove NTIA's authorization role, parallel testing of the production and parallel test RZMS systems; and the development, and execution of an agreement with Verisign as the root zone maintainer. Root Zone Management System (RZMS) Parallel Testing Status update: In accordance with the plan submitted to NTIA, ICANN and Verisign completed system code changes and began a 90-day “parallel testing” period on Wednesday, 6 April 2016. This is a key planning step to ensure the continued security and stability of the Root Zone Management System (RZMS) operation after the successful completion of the IANA Stewardship Transition, currently projected for September 30, 2016. It has been almost 3 weeks since the start of parallel testing and everything is going smoothly. Click here to view Verisign’s daily Parallel Operations Root Zone Management System Comparisons reports of all the root zone files generated. In the event that no unexplained differences in root zone files are identified between the production RZMS and the parallel test RZMS, the testing period will end successfully on 5 July 2016. Documents/announcements posted: % ICANN and Verisign Announce Start of 90-day Root Zone Management System “Parallel Testing” Period 2 Verisign Daily Parallel Operations Root Zone Management System Comparisons Mailing list(s): None. Root Zone Maintainer Agreement (RZMA) Status update: ICANN and Verisign continue to engage in discussion to prepare for a RZMA. The current plan for completion of a draft RZMA is the end of this month. Documents/announcements posted: None. Mailing list(s): None. Stewardship Transition The Stewardship Transition planning track contains projects to prepare relationship documentation with the operational communities, creation of a Post-Transition IANA (PTI) entity, establishment of a Customer Standing Committee (CSC) and a Root Zone Evolution Review Committee (RZERC), operationalizing the IANA customer service escalation mechanisms and Service Level Agreements (SLAs). Service Level Agreement (SLA) for the IANA Numbering Services Status update: On Wednesday, 20 April 2016, the Number Resource Organization (NRO) published an announcement regarding version 5.1 of the SLA document. The SLA will be submitted to the ICANN Board for consideration and adoption when the NRO andICANN establish a mutually agreed upon date. Documents/announcements posted: % Updated 5.1 and Signature Version of the SLA for the IANA Numbering Services 2 Service Level Agreement for IANA Numbering Services (v5.1) Mailing list(s): + https://www.nro.net/pipermail/ianaxfer/ Post-Transition IANA (PTI) Status update: ICANN continues to work on the plan for PTI implementation that the Implementation Oversight Task Force (IOTF) requested, as well as the ICANN-PTI contract. What is the IOTF? The IOTF was formed following ICANN55 in Marrakech. The IOTF offers a channel for ICANN to request insights or clarifications to ensure that ICANN and the community remain aligned on ICANN’s implementation planning efforts of the ICG Proposal. The group was formed to include the co-Chairs and Design Team leads of the Cross Community Working Group to Develop an IANA Stewardship Transition Proposal on Naming Related Functions (CWG-Stewardship), and has since grown to also include representatives from the ICG, Numbering Resources community and Protocol Parameters community. Documents/announcements posted this week: None. Mailing list: + http://mm.icann.org/pipermail/iotf/ Root Zone Evolution Review Committee (RZERC) Status update: ICANN continues to work with the IOTF to finalize the terms of the RZERC Charter. A revised charter was circulated to the IOTF on 25 April 2016. Documents/announcements: 2 Root Zone Evolution Review Committee (RZERC) Charter (v3) Mailing list: + http://mm.icann.org/pipermail/iotf/ IANA Customer Service Escalation Mechanism Status update: ICANN received clarification from the IOTF regarding the IANA Customer Service Complaint Resolution Process for Naming Related Functions and IANA Problem Resolution Process (for IANA naming services only) referenced in Annex I and J of the CWG-Stewardship proposal. As next step, ICANN will update relevant process documentations for these processes. Documents/announcements: None. Mailing list: + http://mm.icann.org/pipermail/iotf/ Accountability Enhancements The Accountability Enhancements track contains plans to implement enhancements to ICANN’s Independent Review and Reconsideration Request processes, to update ICANN’s governance documents, and to operationalize new community powers defined by the Cross Community Working Group on Enhancing ICANNAccountability (CCWG-Accountability). ICANN's Bylaws Status update: ICANN has posted proposed draft new Bylaws for a 30-day public comment from 21 April - 21 May 2016 to allow any interested party to review and provide feedback. 2 Public Comment Page + Submit Comment to Forum + Comments Forum The proposed draft of the new ICANN Bylaws was developed collaboratively by the ICANN legal team and the independent counsel hired to advise the CCWG-Accountability and the CWG-Stewardship. In developing the draft new ICANN Bylaws, the attorneys consulted a Bylaws Coordination Group populated with both community and Board members, as well as with the CWG-Stewardship and the CCWG-Accountability. Adoption of the new Bylaws by the ICANN Board is anticipated for on or around 27 May 2016. Once new ICANN Bylaws have been adopted, ICANN will notify NTIA. Once adopted, the Bylaws are expected to go into effect if NTIA approves of the IANA Stewardship Transition Proposal and the IANA Functions Contract expires. Documents/announcements: 2 Draft New ICANN Bylaws 2 Comparison of Draft New ICANN Bylaws to Current Bylaws Mailing list(s): + http://mm.icann.org/pipermail/bylaws-coord/ + http://mm.icann.org/pipermail/accountability-cross-community/ + http://mm.icann.org/pipermail/cwg-stewardship/ + http://mm.ianacg.org/pipermail/internal-cg_ianacg.org/

1 0

Bylaws section 1.1(d)
by Alissa Cooper April 27, 2016

April 27, 2016

Per Greg’s question in the chat during the most recent CCWG call, could someone cite the text in the CCWG proposal that bylaws sections 1.1(d)(ii)(B)-(E) are implementing? I see that paragraph 147 bullet #3 is implemented by 1.1(d)(ii)(A). Thanks, Alissa

1 0

Notes-Recordings-Transcript link for CCWG Accountability Meeting #92 - 27 April 2016
by MSSI Secretariat April 27, 2016

April 27, 2016

Hello all, The notes, recordings and transcripts for CCWG Accountability Meeting #92 - 27 April 2016 will be available here: https://community.icann.org/x/mCeAAw A copy of the notes may be found below. Thank you. With kind regards, Brenda Brewer MSSI Projects & Operations Assistant ICANN - Internet Corporation for Assigned Names and Numbers Notes These high-level notes are designed to help you navigate through content of the call and do not substitute in any way the transcript. 1. Welcome, roll call, SOI (LS) * TRickert has updated his SOI. 2. Timeline for CCWG Comment on Draft Bylaws - Apr 27th : CCWG ACCT Meeting #92 - May 3rd : CCWG ACCT Meeting #93 - May 10th : Submission * No objections to proposed timeline. 3. Introductory remarks from Holly and Rosemary 4. Q&A (TR) * Email question on Human Rights from Niels has been responded to by Rosemary Fei and this will be included in the CCWG response to the public consultation on the draft Bylaws. * TTropina - Only lawyers can suggest clarifications? * HGregory - Anyone can propose clarifications but the CCWG needs to decide which to accept. * TR - no wordsmithing please. * GShatan - The difference between HG proposal and mine is that HG suggested language perpetuates the ambiguity. FOI approval is business as usual per CCWG procedures. * RFei - Ambiguity comes in in the parenthetical - the INCLUDING CO APPROVAL - this causes the confusion - this should simply be removed and approval is then according to standard process. * TR - there seems to be general support for RF proposal but participants would like to see the language. * LSachez - WHOIS review has been deferred several times - the Bylaws speak to the timing of reviews (5 years from start of previous one). Given the previous WHOIS review was in 2010 the approval of the new Bylaws would automatically put us in default. How would lawyers recommend we deal with this issue - possibly via a footnote? * RFei - The CCWG never intended to create a situation where when the Bylaws came into effect this would create such a situation. All we need is confirmation of this and lawyers can fix this. * TR - Reminder the only thing we are doing here is ensuring consistency between our final report and the draft Bylaws. Adding things that are beyond our report is not our responsibility. * AGreenberg - True, but the previous Bylaws gave the Board room to fix such things which when the new Bylaws come into effect will no longer be possible for the Board. Yes such a change is beyond what was in the CCWG recommendations. * HGregory - Such things will happen in this type of large document. Now that we are aware of this we, including ICANN legal, should be able to propose language to the CCWG. * GShatan - Transitional bylaw would make sense as a place to fix this - but do not want top open the door to wholesale delaying of reviews. * TR - I do not know if there are any other topics which require such action and if this is not the case then it may not be our responsibility to handle this. Let us ask the legal teams to consider this. * HGregory - whatever we come up with should be part of the CCWG response to public comment on the draft Bylaws. * TR - any further comments or questions? none. We can move to the next agenda item. 5. ICANN Legal discussion on section 1.1 d of the draft Bylaws (MW) Document shared: Explanation of grandfathered agreements.pdf<https://community.icann.org/download/attachments/58730392/Explanation%20of%…> * MW - this is about the GRANDFATHERING provisions in the Mission and Core Values. The conclusion of our previous call was that we would hold a plenary discussion of this. Our lawyers have provided formal input to us on this topic explaining their support for the language. * SEisner - We provided an explanation document on the various grandfathering clauses. The contracting of the IANA function had to be added to ensure ICANN could continue to perform its historic mission wrt IANA. This does not add anything to ICANN's mission, but simply confirms that these responsibilities and contracts cannot be challenged as not being in ICANN's mission. * JJeffrey - This is a good start. We all need to know what those documents, PTI Byalws, ICANN-PTI contract etc. but these will be the subject of public consultation etc. * ASullivan - What JJ has said is part of what I am concerned about. there are provisions in the grandfathering clauses that refer to documents that have not yet been written and refer to parties which do not exist (PTI). What is more troubling is that including external documents in the mission could technically modify the mission without a formal process for approving such changes. This seems to create a truck-sized hole. More concerned about 2 provisions - the PTI agreement and the 5 year plan. But overall the notion of including things which are not yet in existence in the mission. * RFei - I understand why this is a concern - what is important is that those documents need to be in existence when the Bylaws come into effect as the draft Bylaws currently state. The discomfort should be about what those documents will actually say. * ACooper - this conversation clearly shows the issue is timing. It is quite likely that there will not be sufficient time to have a proper and thorough review of the PTI documents. This provision is not necessary to implement the results of the CWG and the CCWG and creates a giant loophole which would create the opportunity to amend the mission indirectly. Do not think we can approve these Bylaws with this clause. The ICG proposal says the most important thing is that the IANA functions continue to be performed properly vs having ICANN perform these functions. * JCarter - I am more relaxed on this given the community will review those proposals which are not yet defined. * GShatan - As a lawyer who does this type of work regularly - convergent drafting - all documents WILL exist at the time they come into force. RA and RAA grandfathering should not be up for discussion here. So this type of situation is not exceptional. * SEisner - PTI contract development - We are working with the community to ensure that the community can be properly consulted. It is important to note that there is not a lot that ICANN can put in the PTI documents given it is about performing the IANA function. The intent is not about preserving ICANN performing the IANA functions - if the operational communities think ICANN should be performing those IANA functions then ICANN should be able to do so without being challenged that it is not in mission. On the PTI Sidley will be involved. * Holly J. Gregory (Sidley) from chat: We also assume that as counsel to CWG we will have an opportunity to weigh in on the PTI Articles and Bylaws and "certify" consistency with the CCWG and CWG Proposals * ASullivan - I was listening the discussion on phone and did not follow the chat. There may be a deeper and fundamental issue - the entire grandfathering section sets up a condition that there is no way to question agreements covered by it. I do not understand why this needs to be a piece of fundamental Bylaws and a carve out - including contracts in the mission of ICANN seems to go against the notion of simplicity and clarity for the mission. * MW - good to have this discussion. recap of points presented. The two points of view are protecting the right of ICANN to perform the IANA functions for the communities vs having external contracts in the mission. This is a surprising situation with no clear way forward - given ACooper has stated in the chat that additional process safeguards would not fix this. * ASullivan - what new text would help (from chat)? There is no need for section D. If there is a need for sub-section D we have a bigger problem. Many issues make it too dangerous. Just remove it. * ACooper - On the contracts that are not yet written - we went through this process to define a clear narrow mission - IF the PTI agreements would not expand the mission as originally intended then there is no need for this clause. The situation for existing documents / agreements is different (RA, RAA). * MW - sections 11D has several sub-sections, the RA and RAA have been discussed and is not at issue here. B are existing and not at issue. C and D (RZ Maintainer and PTI) are at issue. Uncertain that we can make more progress today. Lawyers have to find a way to ensure that the scope of the ICANN mission as per the CCWG recommendations is preserved. The way the CCWG has scoped the mission cannot be modified by including these yet undefined documents. This discussion should continue on the list. * RFei - Concerns about this protection changing the scope of the mission - my understanding is that these agreements would be negotiated to be consistent with the mission. the purpose is to protect agreements that have been agreed by the community. * ASullivan - the IETF considers its relationship with ICANN to be that with a service provider. As such there could be a consensus problem. * MW - we will need to summarize these discussions and refer to the CCWG recommendations for the mission. The PTI contract and the RZM agreement will not go through the same approval process as the CCWG recommendations have - the requirement is simply that they go through public comment - which is quite different. There should be no loopholes in the mission. We should ask our lawyers to confer on this and suggest how to address this. I am coming out of this discussion with two different views I would like to avoid having people from the operational communities putting in public comments against these provisions as this would be unfortunate. * ASullivan - Nobody wants this transition to fail. The challenge is simply how to write this so it works well for everybody. There is a concern that some may be favoring incumbent (ICANN). * MW - We need to follow the requirements of the recommendations of the CCWG. This needs to be discussed on the list and lawyers need to consider this. We should get back to this at our next meeting. 6. AOB -LS * clarification of deadlines. * No other points.

1 0

Re: [CCWG-ACCT] Proposed Agenda CCWG ACCT Meeting - 27 April @ 04:00 UTC
by Grace Abuhamad April 26, 2016

April 26, 2016

Dear all, In advance of the call tomorrow, please be sure to read through the attached document. This document provides an explanation of grandfathered agreements and corresponds to item #5 on the agenda below. This document was sent to the Bylaws Coordination Group and then circulated by Mathieu Weill to the CCWG-ACCT last week (link). Since we have confirmed the necessary attendees for the call, item #5 is confirmed (no longer tentative as it was listed when the agenda was sent out). Thank you, Grace -- Grace Abuhamad Manager, Public Policy ICANN | Internet Corporation for Assigned Names and Numbers 801 17th Street NW, Suite 400 | Washington, DC 20006 Direct: +1 202 249 7545 | Mobile: +1 310 200 7638 Interested in the IANA Stewardship Transition? LEARN MORE. STAY UPDATED. FOLLOW. ENGAGE. From: <accountability-cross-community-bounces(a)icann.org> on behalf of Grace Abuhamad <mssi-secretariat(a)icann.org> Date: Monday, April 25, 2016 at 1:52 PM To: Accountability Cross Community <accountability-cross-community(a)icann.org> Subject: [CCWG-ACCT] Proposed Agenda CCWG ACCT Meeting - 27 April @ 04:00 UTC Dear All, In preparation for your call, CCWG Accountability Meeting #92 – Wednesday, 27 April at 04:00 – 06:00 UTC (time converter), see below proposed agenda: Proposed Agenda: 1. Welcome, roll call, SOI 2. Timeline for CCWG Comment on Draft Bylaws - Apr 27th : CCWG ACCT Meeting #92 - May 3rd : CCWG ACCT Meeting #93 - May 10th : Submission 3. Introductory remarks from Holly and Rosemary 4. Q&A 5. [Tentative] ICANN Legal discussion on 1.1 6. AOB Adobe Connect: https://icann.adobeconnect.com/accountability/ Thank you! With kind regards, Brenda Brewer MSSI Projects & Operations Assistant ICANN- Internet Corporation for Assigned Names and Numbers

1 0