January 2016 - Accountability-Cross-Community

TR: IANA Budget and CCWG-Accountability proposal - CWG-Stewardship changes
by Mathieu Weill Jan. 26, 2016

Jan. 26, 2016

Dear Colleagues, Please be aware of the recent work that has been done in collaboration between CWG Stewardship / CCWG Accountability regarding the “IANA Budget”. It seems to be comprehensive and address the concern it was intended to deal with. One option is to create a checkpoint during the implementation in order to ensure the requirements (of the CWG) are being met in the actual implementation. The CWG-Stewardship is currently checking on list whether there are any further thoughts or inputs. Best regards, Mathieu De : Jordan Carter [mailto:jordan@internetnz.net.nz] Envoyé : mardi 26 janvier 2016 01:21 À : fuhr(a)etno.eu; Jonathan Robinson; León Felipe Sánchez Ambía; Thomas Rickert; Mathieu Weill; Cheryl Langdon-Orr; Steve DelBianco; Becky Burr; ACCT-Staff Cc : Jonathan Zuck; Gomes, Chuck Objet : IANA Budget and CCWG-Accountability proposal - CWG-Stewardship changes Hi all Please find attached a marked up version of Recommendation 4 on the IANA and ICANN Budget veto power. This document includes tracked changes from Jordan Carter, WP1 Rapporteur in the CCWG. The changes are intended to take into account feedback from the CWG-Stewardship's Chuck Gomes, forwarded to us by the CWG Co-Chairs. Jonathan Zuck and I as leads on budget discussions were asked to talk through the feedback and agree what should happen next. I met with Jonathan and Chuck this morning to talk through the written feedback from Chuck and we're all happy that the proposed changes attached are fit for purpose. The CWG-Stewardship's feedback boiled down to wanting more clarity about the IANA Functions Operator's budget process. I have tried in the tracked changes to clarify what a caretaker budget feels like (as the CWG sought some more detail), and emphasise that the current quite-good consultation processes for all Budget creation will be put in the bylaws (clarifying that this will also apply to the IANA Budget). In respect of further detail about timing of the IANA Functions Budget, I am not comfortable with the CCWG-Accountability defining this. We in the CCWG have done our job in creating a structure for accountability in respect of the IANA Budget. I believe it is up to the CWG-Stewardship, either through its Design Teams approach or in the implementation project, to go any further in defining detail about the planning process (how a Budget is created, the timing of approval, etc). It isn't the CCWG's area of expertise or responsibility. If there are concerns about ensuring that such planning was taken into account, we could explore the concept of a reverse conditionality -- we could state in our report that our requirements are met only when CWG-Stewardship's work here is completed to its satisfaction. This item is on the agenda for CCWG-Accountability on Tuesday between 19h and 22h. Happy to expand or discuss. Happy also for this message to be forwarded to the CWG or to the CCWG by the relevant co-chairs or staff, or anyone else who feels so inclined! best, Jordan -- Jordan Carter Chief Executive InternetNZ +64-4-495-2118 (office) | +64-21-442-649 (mob) Email: <mailto:jordan@internetnz.net.nz> jordan(a)internetnz.net.nz Skype: jordancarter Web: www.internetnz.nz A better world through a better Internet

1 0

Re: [CCWG-ACCT] Recommendation 5 - Mission - 3rd reading conclusions
by Burr, Becky Jan. 25, 2016

Jan. 25, 2016

Update in advance of call: The ASO language still seems to be something of a moving target. I believe the following 3 versions are in play: Version 1: Coordinates the allocation and assignment at the top-most level of Internet Protocol ("IP") and Autonomous System ("AS") numbers. Further, it ratifies, at the global level, policies related to these IP and AS numbers and developed according to the ICANN Address Supporting Organization (ASO) Memorandum of Understanding between ICANN and the Number Resource Organization dated 21 October, 2004, as may be amended from time to time in accordance with its terms. Version 2: Coordinates the allocation and assignment at the top-most level of Internet Protocol (“IP”) and Autonomous System (“AS”) numbers. Further, it implements, at the global level, policies related to these IP and AS numbers and developed pursuant to the Memorandum of Understanding between ICANN and the Number Resource Organization dated 21 October, 2004, as may be amended from time to time in accordance with its terms. Version 3: Coordinates the allocation and assignment at the top-most level of Internet Protocol (“IP”) and Autonomous System (“AS”) numbers. Further, it ratifies and implements, at the global level, policies related to these IP and AS numbers and developed pursuant to the ICANN Address Supporting Organization (ASO) Memorandum of Understanding between ICANN and the Number Resource Organization dated 21 October, 2004, as may be amended from time to time in accordance with its terms. J. Beckwith Burr Neustar, Inc. / Deputy General Counsel & Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington D.C. 20006 Office: +1.202.533.2932 Mobile: +1.202.352.6367 / neustar.biz<http://www.neustar.biz> From: Alice Jansen <alice.jansen(a)icann.org<mailto:alice.jansen@icann.org>> Date: Monday, January 25, 2016 at 5:05 AM To: Accountability Community <accountability-cross-community(a)icann.org<mailto:accountability-cross-community@icann.org>> Subject: [CCWG-ACCT] Recommendation 5 - Mission - 3rd reading conclusions Sent on behalf of CoChairs Please find below the conclusions (3rd reading) of our mission deliberations during call #78. The updated document is attached. Conclusions: 1. On Consumer Trust: agreement to keep Third Draft Proposal language. Reference to Consumer Trust should not be added to Core Values. It will be included at part of AOC reviews. 2. Discuss ALAC concern regarding removal of the words “where feasible and appropriate” in Core Value 4 that states : Depending on market mechanisms to promote and sustain a healthy competitive environment in the DNS market 3. Awaiting Board input on root servers 4. On numbers language, wordsmithing is needed based on input from lawyers - see http://mm.icann.org/pipermail/accountability-cross-community/2016-January/0…<https://urldefense.proofpoint.com/v2/url?u=http-3A__mm.icann.org_pipermail_…> and proposed language from ASO: "Coordinates the allocation and assignment at the top-most level of Internet Protocol (“IP”) and Autonomous System (“AS”) numbers. Further, it ratifies, at the global level, policies related to these IP and AS numbers and developed according to the ASO-MoU." 5. On RSSAC language: [RSSAC PROPOSED TEXT: Facilitates coordinatesion of the operation and evolution of the DNS root name server system.] [BOARD PROPOSED TEXT: Coordinates the operation and evolution of the DNS root name server system. In this role, ICANN’s Mission is to [to be provided by RSSAC]. ICANN retains an operational role as well as considers inputs from the communities dependent on the root server system.] 6. Discuss the issue around the scope of ICANN’s agreements with contracted parties (page 10). 3rd draft provisions are : a. ICANN shall not impose regulations on services that use the Internet’s unique identifiers, or the content that such services carry or provide. b. ICANN shall have the ability to negotiate, enter into and enforce agreements with contracted parties in furtherance service of its Mission. c. Take into consideration legal advice : “For clients facing similar dilemmas, a common approach is to draft general principles into governing documents and provide a mechanism for interpreting them in specific situations. We recommend that the CCWG agree upon and articulate mission principles at a general level appropriate for inclusion in the Bylaws, understanding that refinement and interpretation will be needed thereafter”. 7. Grandfathering. Discuss questions raised by lawyers : a. What is the effective cut-off date for the grandfathering? This could be a specified date in the future, or could be an event, such as the date of adoption of the relevant Fundamental Bylaw. b. Should RAs that are in the process of being put in place but have not yet been finalized and signed as of the effective date, be included or excluded? If that should depend on how far along in the process they are, what should be the standard for deciding that point? c. Should renewals of existing RAs, unchanged, that contain PICs covered by the grandfathering clause, be included? If so, should there be a limit on the number of renewals that will be covered? Should grandfathering cover PICs that are not modified, even though other provisions of the agreement are changed? d. What if an existing RA/RAA includes a grandfathered PIC, and the agreement is modified, by mutual agreement or otherwise -- is it still grandfathered? e. Should all grandfathering have a sunset date, i.e., a point far enough in the future on which all grandfathering protection will expire? 8. Discuss request to provide impact assessment as requested by several group members. Fourth reading is planned for Tuesday, 26 January. Best regards Mathieu, Thomas, León

5 7

Standard PICs - relevant for "grandfathering" discussion tomorrow
by Burr, Becky Jan. 25, 2016

Jan. 25, 2016

In advance of the call tomorrow, and in particular our grandfathering discussion, I’ve pasted below the “standard” Public Interest Commitments (PICs) from the Registry Agreement. It would be useful to review these in advance of the call. Two simple questions: (1) can existing agreements containing these provisions can be renewed as is under the grandfathering provision and (2) can existing applicants who have not yet entered into registry agreements sign contracts containing these provisions under the grandfathering clause? SPECIFICATION 11 PUBLIC INTEREST COMMITMENTS 1. Registry Operator will use only ICANN accredited registrars that are party to the Registrar Accreditation Agreement approved by the ICANN Board of Directors on 27 June 2013 in registering domain names. A list of such registrars shall be maintained by ICANN on ICANN’s website. 2. Registry Operator will operate the registry for the TLD in compliance with all commitments, statements of intent and business plans stated in the following sections of Registry Operator’s application to ICANN for the TLD, which commitments, statements of intent and business plans are hereby incorporated by reference into this Agreement. Registry Operator’s obligations pursuant to this paragraph shall be enforceable by ICANN and through the Public Interest Commitment Dispute Resolution Process established by ICANN (posted at http://www.icann.org/en/resources/registries/picdrp) which may be revised in immaterial respects by ICANN from time to time (the “PICDRP”). Registry Operator shall comply with the PICDRP. Registry Operator agrees to implement and adhere to any remedies ICANN imposes (which may include any reasonable remedy, including for the avoidance of doubt, the termination of the Registry Agreement pursuant to Section 4.3(e) of the Agreement) following a determination by any PICDRP panel and to be bound by any such determination. [Registry Operator to insert specific application sections here, if applicable] 3. Registry Operator agrees to perform the following specific public interest commitments, which commitments shall be enforceable by ICANN and through the PICDRP. Registry Operator shall comply with the PICDRP. Registry Operator agrees to implement and adhere to any remedies ICANN imposes (which may include any reasonable remedy, including for the avoidance of doubt, the termination of the Registry Agreement pursuant to Section 4.3(e) of the Agreement) following a determination by any PICDRP panel and to be bound by any such determination. a. Registry Operator will include a provision in its Registry-Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting Registered Name Holders from distributing malware, abusively operating botnets, phishing, piracy, trademark or copyright infringement, fraudulent or deceptive practices, counterfeiting or otherwise engaging in activity contrary to applicable law, and providing (consistent with applicable law and any related procedures) consequences for such activities including suspension of the domain name. b. Registry Operator will periodically conduct a technical analysis to assess whether domains in the TLD are being used to perpetrate security threats, such as pharming, phishing, malware, and botnets. Registry Operator will maintain statistical reports on the number of security threats identified and the actions taken as a result of the periodic security checks. Registry Operator will maintain these reports for the term of the Agreement unless a shorter period is required by law or approved by ICANN, and will provide them to ICANN upon request. c. Registry Operator will operate the TLD in a transparent manner consistent with general principles of openness and non-discrimination by establishing, publishing and adhering to clear registration policies. d. Registry Operator of a “Generic String” TLD may not impose eligibility criteria for registering names in the TLD that limit registrations exclusively to a single person or entity and/or that person’s or entity’s “Affiliates” (as defined in Section 2.9(c) of the Registry Agreement). “Generic String” means a string consisting of a word or term that denominates or describes a general class of goods, services, groups, organizations or things, as opposed to distinguishing a specific brand of goods, services, groups, organizations or things from those of others. J. Beckwith Burr Neustar, Inc. / Deputy General Counsel & Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington D.C. 20006 Office: +1.202.533.2932 Mobile: +1.202.352.6367 / neustar.biz<http://www.neustar.biz>

5 6

Recommendation 11 - GAC Advice - 1st reading conclusions
by Alice Jansen Jan. 25, 2016

Jan. 25, 2016

Sent on behalf of CoChairs Please find below conclusions of our deliberations during call #79. The updated document is attached. 1. Clarify whether current drafting imposed mandatory voting from the Board and represents an unintended change to the current practice (see IPC detailed comment page 8 on http://forum.icann.org/lists/comments-draft-ccwg-accountability-proposal-30… ) To address this concern, add this clarification for legal counsel to consider when drafting bylaws language. This recommendation is intended to limit the conditions under which the ICANN board and GAC must try to find a mutually acceptable solution. This recommendation shall not create any new obligations for ICANN board to consider and/or vote on GAC advice, relative to the bylaws in effect prior to the IANA transition. This recommendation shall not create any obligation that ICANN is bound to implement any advice that is not rejected by the board. 2. Confirm or discuss need for such a recommendation to change how GAC Advice is being treated by the Icann Board, in light of comments received. 3. Confirm or discuss recommendation that at least 2/3rds of the Board was required to reject GAC consensus advice to the Board. 4. Discuss request that GAC advice must be approved by general agreement in the absence of formal objection and that the definition of objection/consensus cannot be changed. Others specifically supported this provision. 5. Add the requirement that a rationale must be provided for formal advice provided by an Advisory Committee to the ICANN Board. The Board should determine whether the rationale is adequate. 6. To address the concern of GAC advice inconsistent with bylaws, add this clarification for legal counsel to consider when drafting bylaws language: ICANN cannot take action - based on advice or otherwise – that is inconsistent with Bylaws: While the GAC is not restricted as to the advice it can offer to ICANN, it is clear that ICANN may not take action that is inconsistent with its Bylaws. Any aggrieved party or the empowered community will have standing to bring an IRP to challenge whether any board action or inaction that is inconsistent with its bylaws, even if the board acted on GAC advice. Lawyers’ Memo We were asked to review the current Bylaws provision addressing GAC advice and determine whether the ambiguities we identified in our review of the proposed revisions to this provision are new or stem from ambiguities under the current Bylaws text. We have determined that there are ambiguities under the current Bylaws text, which provides as follows: ICANN Bylaws Article XI, Section 2.1.j. The advice of the Governmental Advisory Committee on public policy matters shall be duly taken into account, both in the formulation and adoption of policies. In the event that the ICANN Board determines to take an action that is not consistent with the Governmental Advisory Committee advice, it shall so inform the Committee and state the reasons why it decided not to follow that advice. The Governmental Advisory Committee and the ICANN Board will then try, in good faith and in a timely and efficient manner, to find a mutually acceptable solution. The phrase “duly taken into account” is ambiguous, but reading it together with the next sentence, which requires that the Board follow a specific procedure before taking actions inconsistent with GAC advice, we believe the best interpretation of this phrase is to mean “do not act inconsistently with.” Based on this interpretation, we recommend the following clarification (underlined) to the first sentence of this Bylaws provision: “The advice of the Governmental Advisory Committee on public policy matters shall be duly taken into account, both in the formulation and adoption of policies, and ICANN shall not act inconsistently with that advice except as otherwise provided in this paragraph.” We also note that there is no meaningful legal distinction between voting and determining to take an action, as some commenters have suggested. The only way the Board can legally determine or decide anything under California law is by voting. The proposed addition to the current Bylaws text is underlined below: ICANN Bylaws Article XI, Section 2.1.j. The advice of the Governmental Advisory Committee on public policy matters shall be duly taken into account, both in the formulation and adoption of policies. In the event that the ICANN Board determines to take an action that is not consistent with the Governmental Advisory Committee advice, it shall so inform the Committee and state the reasons why it decided not to follow that advice. Any Governmental Advisory Committee advice approved by a full Governmental Advisory Committee consensus, understood to mean the practice of adopting decisions by general agreement in the absence of any formal objection, may only be rejected by a vote of 2/3 of the Board, and the Governmental Advisory Committee and the ICANN Board will then try, in good faith and in a timely and efficient manner, to find a mutually acceptable solution. Based on our interpretation of the current Bylaws text, described above, we believe this proposed provision results in the following process: 1. If GAC provides advice (whether by a full GAC consensus or a lesser approval threshold), the ICANN Board must “duly take[] into account” that advice -- i.e., ICANN must not act inconsistently with that advice, unless #2 and/or #3 below apply. 2. If GAC provides advice (whether by a full GAC consensus or a lesser approval threshold), and the ICANN Board decides to take an action inconsistent with that advice, the ICANN Board must first give GAC notice and provide a rationale. · In addition, f the GAC advice was by a full GAC consensus, the ICANN Board may decide to take an action inconsistent with that advice only by a vote of 2/3 of the ICANN Board. If that 2/3 threshold is reached, GAC and ICANN must then try in good faith to find a mutually acceptable solution. If the 2/3 threshold is not reached, ICANN is required to act consistently with the consensus GAC advice. We recommend that consideration be given to further clarifying this process, and we agree with commenters who have concluded that the proposed provision does not impose an affirmative obligation upon ICANN’s Board to vote on GAC consensus advice every time that advice is provided. We note that additional Bylaws language is being proposed to clarify that, in any case, the Board needs to act in compliance with the ICANN Bylaws. Thus, if the Board were to determine that following GAC advice would result in non-compliance with the Bylaws, the Board should be able to reject the advice (with a majority or two-thirds vote, depending on whether the GAC advice was consensus advice) and explain its position to GAC. NB: Focus on chartering organization feedback: - GNSO : Strong opposition to rec as written in Third Draft Proposal. No support (most SG/Cs) to raise threshold for a Board vote to reject GAC advice. Serious concern over lack of specificity in relation of requirements for GAC advice (such as provision of rationale) and possibility that this recommendation, if adopted, could unduly change nature of Board-GAC relationship and/or position of GAC vis-à-vis other SO/ACs. Several SG/Cs believe any recommendation should retain current flexibility in Bylaws where Board is not required to undertake a formal vote in order to reject GAC advice. - ccNSO : no specific comment - ASO: In general we find the current text acceptable. Additionally we would like to make the following remarks: We would support a text that clarifies today’s practices and does not substantially change the GAC's role and how its advice is treated by the Board or substantially strengthen obligations for the Board to consider the GAC advice. We would not support a text that cannot be acceptable by the NTIA. - GAC : There is no consensus within the GAC so far to support or object to the text contained in Recommendation 11 of the 3rd Draft Proposal. - ALAC : support the recommendation - SSAC : no specific comment Second reading is planned for Thursday, 28 January. Best regards Mathieu, Thomas, León

1 0

CCWG - Recommendation 3 - Final draft for CCWG comments
by Bernard Turcotte Jan. 25, 2016

Jan. 25, 2016

Per the request of the co-chairs we are publishing the final draft version of Annex 3 for comments by the CCWG. This version is the version produced by legal counsel with the additional edit of correcting 8 powers to 7 powers. 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 18:00 UTC Monday 25 January and will close at 18:00 UTC Wednesday 27 January - 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 3 - Final draft for CCWG comments* or simply reply to this email. Comments will be compiled in semi-real time by staff in a google sheet at: https://docs.google.com/spreadsheets/d/1YNvRyLsJ4EYXv83-Munrva6mgWW-bsGDmph… Thank You. Bernard Turcotte ICANN Staff Support for CCWG

1 0

Re: [CCWG-ACCT] CCWG - Rec 12 - Final draft for CCWG comments
by Bernard Turcotte Jan. 25, 2016

Jan. 25, 2016

All, As of the close of the comment period no comments had been received. Therefore this recommendation is currently considered final pending completion of the other recommendations. Given there were no changes from the legal review version this will not be re-submitted for a final legal review (lawyers will review the complete package when it is completed). Clean version attached for you convenience. Thank you. Bernard Turcotte ICANN Staff Support for CCWG On Thu, Jan 21, 2016 at 11:30 AM, Bernard Turcotte < turcotte.bernard(a)gmail.com> wrote: > > All, > > Per the request of the co-chairs we are publishing the final draft > version of Annex 12 for comments by the CCWG. > > This is based on the version circulated yesterday which was sent to the > lawyers for review. > > You will find attached 2 documents, one with track changes and the other > clean. > > The comment period for the CCWG will run from 18:00 UTC Thursday 21 > January and will close at 18:00 UTC Saturday 23 January - 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 - Rec 12 - Final draft for CCWG comments* > > or simply reply to this email. > > Comments will be compiled in semi-real time by staff in a google sheet at: > > > https://docs.google.com/spreadsheets/d/1fnInYAmWIQiHmsCqxE6jSL7DNY4H85aBrlP… > > > Please note that the CCWG legal team is currently working with ICANN legal > on a proposal for Recommendation 6 (email from Holly.Gregory(a)sidley.com > titled Report on Lawyers Call re Human Rights dated 20 January) . If this > work is successful it will require amending Recommendation 6 and making an > amendment to Recommendation 12 to reflect the change in Recommendation 6 > (as noted in the email). If this is the case Recommendation 12 will be > posted again for comments by the CCWG. > > Once the comment period is completed the co-chairs and Rapporteurs will > review the comments and a final version will be produced for a final legal > check. > > Thank You. > > > Bernard Turcotte > ICANN Staff Support for CCWG > >

1 0

Terminology - “Sole Designator”, “Empowered Community” and “community”
by Bruce Tonkin Jan. 25, 2016

Jan. 25, 2016

Hello All, >> Just a reminder that in addition to the high level concerns and detailed edits we have noted to date, it will be important in the final review to use consistent terminology for the concepts and entities discussed and ensure that the glossary is up to date. This will be especially important as to how “Sole Designator”, “Empowered Community” and “community” are used. Following on from Holly’s note above, here is how I see the different terms applying: Community – the aggregate of all those that attend ICANN meetings either physically (attending face-to-face meetings) or virtually (members of mailing lists, contributors to online forums etc). This also includes all the members of the constituency bodies – the RIRs, the SOs, the stakeholder groups, constituencies, the advisory committees etc Empowered Community – this is a construct in the bylaws similar to the construct for SOs and ACs. The bylaws give this construct particular community powers, roles and responsibilities just as they give roles and responsibilities to individual SOs and ACs. The IRP is the primary mechanism where disputes are resolved with respect to the organisation’s compliance with those bylaws. The IRP is not a court in a single legal jurisdiction, but is a global mechanism for resolving disputes. I would expect that the panel would have global diversity amongst its members in addition to their skills. The ICANN Board will abide by the decision of the IRP. Sole Designator -= this is a stand-alone legal entity that exists outside of ICANN. It appoints and removes Board directors on the instruction of the relevant SO, AC, nominating committee or Empowered Community as described in the bylaws. As well as appointing directors, it serves as the ultimate enforcement mechanism should the Board not follow the decision of an IRP panel through its power to remove Board directors. The ability to appoint or remove directors is enforceable in a California court. This is only mechanism that it tied specifically to the law in California. Regards, Bruce Tonkin

2 1

Recommendation 5 - Mission - 3rd reading conclusions
by Alice Jansen Jan. 25, 2016

Jan. 25, 2016

Sent on behalf of CoChairs Please find below the conclusions (3rd reading) of our mission deliberations during call #78. The updated document is attached. Conclusions: 1. On Consumer Trust: agreement to keep Third Draft Proposal language. Reference to Consumer Trust should not be added to Core Values. It will be included at part of AOC reviews. 2. Discuss ALAC concern regarding removal of the words “where feasible and appropriate” in Core Value 4 that states : Depending on market mechanisms to promote and sustain a healthy competitive environment in the DNS market 3. Awaiting Board input on root servers 4. On numbers language, wordsmithing is needed based on input from lawyers - see http://mm.icann.org/pipermail/accountability-cross-community/2016-January/0… and proposed language from ASO: "Coordinates the allocation and assignment at the top-most level of Internet Protocol (“IP”) and Autonomous System (“AS”) numbers. Further, it ratifies, at the global level, policies related to these IP and AS numbers and developed according to the ASO-MoU." 5. On RSSAC language: [RSSAC PROPOSED TEXT: Facilitates coordinatesion of the operation and evolution of the DNS root name server system.] [BOARD PROPOSED TEXT: Coordinates the operation and evolution of the DNS root name server system. In this role, ICANN’s Mission is to [to be provided by RSSAC]. ICANN retains an operational role as well as considers inputs from the communities dependent on the root server system.] 6. Discuss the issue around the scope of ICANN’s agreements with contracted parties (page 10). 3rd draft provisions are : a. ICANN shall not impose regulations on services that use the Internet’s unique identifiers, or the content that such services carry or provide. b. ICANN shall have the ability to negotiate, enter into and enforce agreements with contracted parties in furtherance service of its Mission. c. Take into consideration legal advice : “For clients facing similar dilemmas, a common approach is to draft general principles into governing documents and provide a mechanism for interpreting them in specific situations. We recommend that the CCWG agree upon and articulate mission principles at a general level appropriate for inclusion in the Bylaws, understanding that refinement and interpretation will be needed thereafter”. 7. Grandfathering. Discuss questions raised by lawyers : a. What is the effective cut-off date for the grandfathering? This could be a specified date in the future, or could be an event, such as the date of adoption of the relevant Fundamental Bylaw. b. Should RAs that are in the process of being put in place but have not yet been finalized and signed as of the effective date, be included or excluded? If that should depend on how far along in the process they are, what should be the standard for deciding that point? c. Should renewals of existing RAs, unchanged, that contain PICs covered by the grandfathering clause, be included? If so, should there be a limit on the number of renewals that will be covered? Should grandfathering cover PICs that are not modified, even though other provisions of the agreement are changed? d. What if an existing RA/RAA includes a grandfathered PIC, and the agreement is modified, by mutual agreement or otherwise -- is it still grandfathered? e. Should all grandfathering have a sunset date, i.e., a point far enough in the future on which all grandfathering protection will expire? 8. Discuss request to provide impact assessment as requested by several group members. Fourth reading is planned for Tuesday, 26 January. Best regards Mathieu, Thomas, León

1 0

Re: [CCWG-ACCT] Counsels' feedback on Annex 9 (AOC Reviews)
by Alan Greenberg Jan. 24, 2016

Jan. 24, 2016

Greg, you use the expression "seating a full review team" and say that "unused" seats could be used for other AC/SOs (as does the current proposal, to some extent). However, I hope that everyone understands these terms. The "full review team" according to our new definition is 21 people from AC/SOs plus the Board and advisors/experts. To date, we have have had or are in the process of doing 5AoC reviews. They have had between 11 and 13 AC/SO members. Some AC/SOs have occupied less than 1 seat per review (and one has occupied only 1 seats overall the reviews). "Seating the full review team" would involve nearly doubling the size of each review, and I have yet to hear of an explanation that even tries to justify that. For those who want to see the actual numbers (based on a very quick review of the review documents), a tally of the reviews is attached. Alan At 24/01/2016 10:46 AM, Greg Shatan wrote: >Counsel provided the following feedback on Annex 9: > >Annex 9 (AOC Reviews): We recommend that >consideration be given to further clarifying the >Review Team provision in Paragraph 54 (1) to >specify the type of âdiversityâ desired >(geographic or otherwise) for Review Team >members and (2) to state whether, in determining >the composition of the members of the Review >Teams they select, the group of chairs can >solicit additional nominees or appoint less than >21 members to avoid potential overrepresentation >of particular ACs or SOs if some nominate less than 3 members. > >Diversity is desirable and should be encouraged, >in various ways. However, on the se second >point above, I think the suggestions go further >and in different directions than I believe >appropriate. Diversity is a goal, not a >requirement. Soliciting members from >underrepresented demographics is not troubling; >indeed, participation should be encouraged >across the board. However, the idea of not >seating a full review team because of lack of >enthusiasm from particular demographics is >troubling, for a few reasons. First, the teams >are purposely fairly small and smaller teams >would make it harder to get the work >done. Second, some topics may naturally inspire >more interest from some demographics than >others. Third, some topics may actually be >appropriate for an imbalanced representation. > >I also think the application of "diversity" to >the distribution of SOs and ACs ona review team >is misplaced. Indeed it runs counter to the >concept that unfilled seats of one SO/AC (to the >extent there are even formal 'seats') can be >reallocated to another SO/AC with more >applicants for the review team. This should be >clarified,as an acceptable and appropriate >action, rather than made to seem undesirable in the name of "diversity." > >Greg >_______________________________________________ >Accountability-Cross-Community mailing list >Accountability-Cross-Community(a)icann.org >https://mm.icann.org/mailman/listinfo/accountability-cross-community

1 0

Counsels' feedback on Annex 9 (AOC Reviews)
by Greg Shatan Jan. 24, 2016

Jan. 24, 2016

Counsel provided the following feedback on Annex 9: *Annex 9 (AOC Reviews)*: *We recommend that consideration be given to further clarifying the Review Team provision in Paragraph 54** (1) to specify the type of “diversity” desired (geographic or otherwise) for Review Team members and (2) to state whether, in determining the composition of the members of the Review Teams they select, the group of chairs can solicit additional nominees or appoint less than 21 members to avoid potential overrepresentation of particular ACs or SOs if some nominate less than 3 members.* Diversity is desirable and should be encouraged, in various ways. However, on the se second point above, I think the suggestions go further and in different directions than I believe appropriate. Diversity is a goal, not a requirement. Soliciting members from underrepresented demographics is not troubling; indeed, participation should be encouraged across the board. However, the idea of not seating a full review team because of lack of enthusiasm from particular demographics is troubling, for a few reasons. First, the teams are purposely fairly small and smaller teams would make it harder to get the work done. Second, some topics may naturally inspire more interest from some demographics than others. Third, some topics may actually be appropriate for an imbalanced representation. I also think the application of "diversity" to the distribution of SOs and ACs ona review team is misplaced. Indeed it runs counter to the concept that unfilled seats of one SO/AC (to the extent there are even formal 'seats') can be reallocated to another SO/AC with more applicants for the review team. This should be clarified,as an acceptable and appropriate action, rather than made to seem undesirable in the name of "diversity." Greg

1 0