January 2016 - Accountability-Cross-Community

Re: [CCWG-ACCT] Recommendation 6 - Human Rights - 1st reading conclusions
by Paul Szyndler Jan. 19, 2016

Jan. 19, 2016

All, I have silently, but closely, followed the deliberations on how a recognition of Human Rights should be incorporated in to ICANN’s corporate structures and documents. However, now that we appear to be at a point of choosing between three clear-cut options, I feel the need to comment and raise a few questions. I am taking a step back in the discussions and acknowledge that this perspective may not be popular. To set the scene: auDA has made two submissions to previous Public Comment periods where we unequivocally supported the concept of recognising Human Rights-related principles within ICANN. However, we were equally clear in expressing our concerns that a hurried or partial implementation would be problematic. These comments were drawn from my previous governmental experience, observing both individual governments and inter-governmental organisations grappling with the complex minutiae of how HR statements should be crafted. I agree with Avri that the departure of the NTIA requires some form of “backstop” to ensure Human Rights obligations are met but do not agree that it necessarily requires short-term implementation in order to adequately display a corporate commitment. I believe that a carefully-executed FoI is essential. Wouldn’t a commitment to considered deliberation and implementation through WS2 be adequate? Further, what distinguishes the conversation of human rights from our recent discussion on consumer trust? Both are “new” issues, not previously incorporated in the Bylaws or envisioned in the AoC. >From my reading, when talking about consumer trust, we have all-but agreed that bylaw changes without adequate deliberation are a bad idea. Hence it appears likely to be pushed to WS2, where the FoI will be developed. Why should this not be so for human rights-related amendments? Overall, I am compelled toward the current “Alternative B”. But this is not for fear of legal liability / action. Rather: 1) I value the importance of making sure a challenging issue is resolved properly and thoroughly; and 2) I believe the WG should apply the same approach as it has done to similarly complex topics. I welcome your slings and arrows. Regards, Paul Paul Szyndler | General Manager, International and Government Affairs .au Domain Administration Limited T: +61 2 6292 5034 | F: +61 3 8341 4112 | M: +61 402 250 389 E: <mailto:paul.szyndler@auda.org.au> paul.szyndler(a)auda.org.au | W: www.auda.org.au <http://www.auda.org.au/> Twitter: <http://twitter.com/auda> @auda | Blog: www.auda.org.au/blog/ <http://www.auda.org.au/blog/> auDA – Australia’s Domain Name Administrator Important Notice This email may contain information which is confidential and/or subject to legal privilege, and is intended for the use of the named addressee only. If you are not the intended recipient, you must not use, disclose or copy any part of this email. If you have received this email by mistake, please notify the sender and delete this message immediately. From: accountability-cross-community-bounces(a)icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Greg Shatan Sent: Monday, 18 January 2016 10:36 AM To: Dr Eberhard W Lisse <epilisse(a)gmail.com> Cc: Lisse Eberhard <directors(a)omadhina.net>; CCWG Accountability <accountability-cross-community(a)icann.org> Subject: Re: [CCWG-ACCT] Recommendation 6 - Human Rights - 1st reading conclusions The Third Draft Proposal is actually ambiguous on the issue of implementing the Human Rights Bylaw, and the Proposal is not accurately represented by Alternative A. The Third Draft Proposal includes a transitional Bylaw, which states ""Bylaw xx will be implemented in accordance with the framework of interpretation to be developed as part of “Work Stream 2”." There is no further discussion of this language in the Proposal or Annex. The practical effect of this language is that the Human Rights bylaw cannot be implemented until the framework of interpretation is developed in WS2. The bylaw cannot be implemented any earlier than that, because it would then be impossible to implement the bylaw "in accordance with the framework of interpretation." As such, Alternative C is actually closer to the intent of the Third Draft than Alternative A. Alternative A is essentially incomplete, because it does not take the transitional bylaw into account. Greg On Sun, Jan 17, 2016 at 4:16 PM, Dr Eberhard W Lisse <epilisse(a)gmail.com <mailto:epilisse@gmail.com> > wrote: "Our" agreement? Who is "we"? Never mind that ALAC can have their mind changed for them any time. el -- Sent from Dr Lisse's iPad mini 4 On 17 Jan 2016, at 22:55, Tijani BEN JEMAA <tijani.benjemaa(a)benjemaa.com <mailto:tijani.benjemaa@benjemaa.com> > wrote: Avri, You know that I’m not against including ICANN human rights commitment into its bylaw assuming that it will be limited to the ICANN mission. I don’t understand that we want to include such commitments in the bylaws before we define the interpretation that will insure that they will only be applied according to the limited ICANN mission. Our agreement was to have a high level mention about those commitments in the CCWG proposal for Work Stream 1, and address the whole issue in Work Stream 2 to be included in the bylaws (commitments + interpretation). ----------------------------------------------------------------------------- Tijani BEN JEMAA Directeur Exécutif Fédération Méditerranéenne des associations d'Internet (FMAI) Phone: +216 98 330 114 <tel:%2B216%2098%20330%20114> +216 52 385 114 <tel:%2B216%2052%20385%20114> ----------------------------------------------------------------------------- Le 17 janv. 2016 à 18:58, Avri Doria <avri(a)acm.org <mailto:avri@acm.org> > a écrit : Hi, There would no legal difference in respect of the laws they need to obey. There will be a difference in the set of considerations that could be brought into consideration at the time of IANA contract renewal. The contract renewal is a checkpoint when NTIA can insure that ICANN is meeting all of its obligations including the various freedoms guaranteed by the government's HR obligations, not just the legal ones. rember the consultations that went on last time. And remmeber that ICANN had to fix its application in order to gain approval. With transition we lose this checkpoint and this loss needs something to take its place. In regard to HR issues, corporate responsibility is the best way to maintain that commitment. A simple commitment to respect human rights is the first step toward ICANN accepting its corporate responsibilities on this and other issues. Choice A is the closest we were able to get to making a simple first baby step toward ICANN accepting corporate responsibilities. avri On 17-Jan-16 12:05, Tijani BEN JEMAA wrote: The CCWG-Accountability sought legal advice on whether, upon the termination of the IANA Functions Contract between ICANN and the NTIA, ICANN’s specific Human Rights obligations could be called into question. It was found that, upon termination of the Contract, there would be no significant impact on ICANN’s Human Rights obligations. ----------------------------------------------------------------------------- *Tijani BEN JEMAA* Directeur Exécutif Fédération Méditerranéenne des associations d'Internet (*FMAI*) Phone: +216 98 330 114 <tel:%2B216%2098%20330%20114> +216 52 385 114 <tel:%2B216%2052%20385%20114> ----------------------------------------------------------------------------- Le 17 janv. 2016 à 00:14, Avri Doria <avri(a)acm.org <mailto:avri@acm.org> <mailto:avri@acm.org>> a écrit : Hi, I had understood that much of the opposition expressed by those supporting B had to do with the fear of legal action. Since that fear seems not to be fact based, I was thinking some of that opposition has been answered. There is also the fact that with the departure of NTIA we have no backstop for the human rights obligations of the open internet without declaring a corporate commitment to human rights. This is not one of those nice to have Accountability changes made while there is a chance. This is a direct necessity based on losing the governmental backstop, given their obligation for human rights (whatever we think of their implementation of their governmental responsibilities). avri On 16-Jan-16 15:59, Tijani BEN JEMAA wrote: Some facts: * it wasn’t only the board who expressed concerns: some other comments did * on the call, there were different views expressed: some were for option A, others for option B and most for option C * Option C is a compromise between A and B Other facts: * the issue of Human rights was raised at the beginning of our works, and the position of the CCWG members was « since ICANN is about names and numbers, and has nothing to do with the content, no need to address this issue ». * It was raised again I think in Paris meeting, and the decision was to address it in work stream 2. and under the insistence of some, the CCWG decided to have a very high level mention on the issue in the proposal of Work Stream 1. ----------------------------------------------------------------------------- *Tijani BEN JEMAA* Executive Director Mediterranean Federation of Internet Associations (*FMAI*) Phone: +216 98 330 114 <tel:%2B216%2098%20330%20114> +216 52 385 114 <tel:%2B216%2052%20385%20114> ----------------------------------------------------------------------------- Le 16 janv. 2016 à 20:04, Schaefer, Brett <Brett.Schaefer(a)heritage.org <mailto:Brett.Schaefer@heritage.org> <mailto:Brett.Schaefer@heritage.org> <mailto:Brett.Schaefer@heritage.org>> a écrit : Agree with this. In addition to the Board's comments being the focus for the rec discussions (at least it appears that way to me) it seems like unless a comment is raised during the Adobe it is considered resolved. Not all commenters participate in the Adobe chats, but that should not mean their comments should be dismissed or downplayed. __________ ________________________________ 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 <tel:202-608-6097> heritage.org <http://heritage.org/> <http://heritage.org/> <http://heritage.org/><http://heritage.org/> On Jan 16, 2016, at 3:11 AM, Avri Doria <avri(a)acm.org <mailto:avri@acm.org> <mailto:avri@acm.org> <mailto:avri@acm.org><mailto:avri@acm.org>> wrote: Hi, Was also noticing how little time we spend stepping through all the comments and answering them. Was wondering how we were coming to consensus before having done so. Don't wee need to have a response for all the comments on this draft? Given that we are using the process we are using, perhaps for each recommendation we are approaching consensus on we should check against the comments to see what we may be missing. Each recommendation as it nears completion could be taken by a few volunteers and checked against the comments on that recommendation. These small teams could take responsibility for drafting the responses as well. I do not dispute the importance of coming to agreement with the Board, but we must also deal with the rest of the comments in an proper manner. Especially on areas where finding an agreement point with the Board is challenging, the comments of the community can give us direction and an sasist. avri On 15-Jan-16 18:50, Robin Gross wrote: I agree and am concerned about the degree of automatic deference and preference for board desired outcomes over CCWG - Accountability participants and public comments in the organization of these discussions. For some reason, these discussions seem to each focus on the board objectives and comments and almost no attention to the comments of any other stakeholder. Let’s not forget many members of the public filed comments last month, expecting them to be discussed and incorporated. But it looks like the only concerns placed before us for consideration are the board comments/objectives. Let’s not forget the others! Best, Robin On Jan 15, 2016, at 9:03 AM, Niels ten Oever <lists(a)nielstenoever.net <mailto:lists@nielstenoever.net> <mailto:lists@nielstenoever.net> <mailto:lists@nielstenoever.net><mailto:lists@nielstenoever.net>> wrote: Dear co-chairs (an all), I am quite surprised by your proposal to invite members and board to consider option C since WP4 and CCWG achieved consensus on option A, which was reinforced by the independent lawyers advice. I really don't think this work should be disregarded. The ICANN lawyers did not provide examples, case-law or other documents to outline any risk. So even though I am very willing to discuss, I see no reason to only consider option C and I am very surprised that you as co-chairs argue for that option even though consensus was reached earlier on option A. As I said in my previous email, it is not reasonable to consider option C before we agree that we won't proceed with the option A. All the best, Niels On 01/15/2016 05:26 PM, Alice Jansen wrote: _Sent on behalf of CoChairs _ _ _ Please find below the main conclusions of our deliberations during call #76. The updated document is attached. 1.Agreement to rely on target dates instead of hard deadlines, in line with general approach agreed for WS2 2. Discussed comments (including Icann Board, RrSG…) requesting that the inclusion of human rights language into the bylaws be delayed until the proposed framework of interpretation was completed or even only be considered in Work Stream 2. a.Independent lawyer input has been provided and concludes : While the addition of the proposed human rights bylaw provision should not increase the exposure of ICANN to legal liability, we recognize that special interest groups and individuals might seek to bring non-meritorious claims, but the risk of meritless claims is already a risk that ICANN faces. b. Board clarified that concern included risk that IRP would interpret the Bylaw language and create “case law policy” while the FoI is finalized. c. Consider Lawyer input suggestion as follows : i. “ /expressly limiting the jurisdiction of any internal dispute resolution systems within ICANN (such as the IRP) to preclude claims of human rights violations that are not grounded in a specific violation of an applicable law”./ 3. Members and Board are invited to consider whether option c) could be an acceptable way forward a. Confirm recommendation bylaw language as part of WS1, despite concerns expressed b. Defer bylaw language adoption to WS2, when FoI is finalized c. Adopt adjusted bylaw language as part of WS1 to clarify that it can only be enforced or used in an IRP once the FoI is approved (Such as : “This articles becomes effective 30 days after approval of the FoI…”). Second reading is planned for Tuesday, 19 January. Best regards Mathieu, Thomas, León _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community(a)icann.org <mailto:Accountability-Cross-Community@icann.org> <mailto:Accountability-Cross-Community@icann.org> <mailto:Accountability-Cross-Community@icann.org><mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community <https://mm.icann.org/mailman/listinfo/accountability-cross-community%3Chttp…> <https://mm.icann.org/mailman/listinfo/accountability-cross-community> <https://mm.icann.org/mailman/listinfo/accountability-cross-community%3Chttp… <https://mm.icann.org/mailman/listinfo/accountability-cross-community%3Chttp…> > <https://mm.icann.org/mailman/listinfo/accountability-cross-community%3Chttp… <https://mm.icann.org/mailman/listinfo/accountability-cross-community%3Chttp…> > -- Niels ten Oever Head of Digital Article 19 www.article19.org <http://www.article19.org/> <http://www.article19.org/> <http://www.article19.org/><http://www.article19.org <http://www.article19.org/> <http://www.article19.org/> <http://www.article19.org/>> PGP fingerprint 8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D 68E9 _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community(a)icann.org <mailto:Accountability-Cross-Community@icann.org> <mailto:Accountability-Cross-Community@icann.org> <mailto:Accountability-Cross-Community@icann.org><mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community <https://mm.icann.org/mailman/listinfo/accountability-cross-community%3Chttp…> <https://mm.icann.org/mailman/listinfo/accountability-cross-community> <https://mm.icann.org/mailman/listinfo/accountability-cross-community%3Chttp… <https://mm.icann.org/mailman/listinfo/accountability-cross-community%3Chttp…> > <https://mm.icann.org/mailman/listinfo/accountability-cross-community%3Chttp… <https://mm.icann.org/mailman/listinfo/accountability-cross-community%3Chttp…> > _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community(a)icann.org <mailto:Accountability-Cross-Community@icann.org> <mailto:Accountability-Cross-Community@icann.org> <mailto:Accountability-Cross-Community@icann.org><mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community <https://mm.icann.org/mailman/listinfo/accountability-cross-community%3Chttp…> <https://mm.icann.org/mailman/listinfo/accountability-cross-community> <https://mm.icann.org/mailman/listinfo/accountability-cross-community%3Chttp… <https://mm.icann.org/mailman/listinfo/accountability-cross-community%3Chttp…> > <https://mm.icann.org/mailman/listinfo/accountability-cross-community%3Chttp… <https://mm.icann.org/mailman/listinfo/accountability-cross-community%3Chttp…> > --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus <https://www.avast.com/antivirus%3Chttps:/www.avast.com/antivirus%3E> <https://www.avast.com/antivirus> <https://www.avast.com/antivirus%3Chttps://www.avast.com/antivirus%3E <https://www.avast.com/antivirus%3Chttps:/www.avast.com/antivirus%3E> > <https://www.avast.com/antivirus%3Chttps://www.avast.com/antivirus%3E <https://www.avast.com/antivirus%3Chttps:/www.avast.com/antivirus%3E> > _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community(a)icann.org <mailto:Accountability-Cross-Community@icann.org> <mailto:Accountability-Cross-Community@icann.org> <mailto:Accountability-Cross-Community@icann.org><mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community <https://mm.icann.org/mailman/listinfo/accountability-cross-community%3Chttp…> <https://mm.icann.org/mailman/listinfo/accountability-cross-community> <https://mm.icann.org/mailman/listinfo/accountability-cross-community%3Chttp… <https://mm.icann.org/mailman/listinfo/accountability-cross-community%3Chttp…> > <https://mm.icann.org/mailman/listinfo/accountability-cross-community%3Chttp… <https://mm.icann.org/mailman/listinfo/accountability-cross-community%3Chttp…> > _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community(a)icann.org <mailto:Accountability-Cross-Community@icann.org> <mailto:Accountability-Cross-Community@icann.org> <mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community(a)icann.org <mailto:Accountability-Cross-Community@icann.org> <mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community(a)icann.org <mailto:Accountability-Cross-Community@icann.org> <mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community(a)icann.org <mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community --- This email has been checked for viruses by Avast antivirus software. <https://www.avast.com/antivirus> https://www.avast.com/antivirus _______________________________________________ Accountability-Cross-Community mailing list <mailto:Accountability-Cross-Community@icann.org> Accountability-Cross-Community(a)icann.org <https://mm.icann.org/mailman/listinfo/accountability-cross-community> https://mm.icann.org/mailman/listinfo/accountability-cross-community _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community(a)icann.org <mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community(a)icann.org <mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community

7 7

(no subject)
by Gregory, Holly Jan. 19, 2016

Jan. 19, 2016

Dear CCWG Co-Chairs, Members and Participants and ICANN Staff, Attached please find our memo responding to the certified question of January 11, 2016 regarding litigation risks related to the proposed human rights bylaws provisions. Kind regards, Holly and Rosemary HOLLY J. GREGORY Partner and Co-Chair Global Corporate Governance & Executive Compensation Practice Sidley Austin LLP +1 212 839 5853 holly.gregory(a)sidley.com<mailto:holly.gregory@sidley.com> **************************************************************************************************** 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. ****************************************************************************************************

9 11

Re: [CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion
by Alan Greenberg Jan. 19, 2016

Jan. 19, 2016

I strongly support Greg's position. This is exactly the type of thing that the ALAC was concerned about when we raised a general caution on the mission changes being contemplated and the concern that one of ICANN's prime responsibilities, being a good custodian of the gTLD space, could be subverted. Alan At 18/01/2016 10:32 PM, Greg Shatan wrote: >Malcolm, > >On Mon, Jan 18, 2016 at 5:48 AM, Malcolm Hutty ><<mailto:malcolm@linx.net>malcolm(a)linx.net> wrote: > >On 18/01/2016 01:54, Burr, Becky wrote: > > > > So if an applicant includes obligations in the application, it is ok for > > ICANN to enforce those commitments? > >Not for purposes inconsistent with ICANN's Mission, no. > > >âIf (in your view) ICANN caânnot enforce >obligations that an applicant includes in its >application, who can enforce those >obligations? If no one can enforce these >obligations, then how can they even be called >obligations? What keeps applicants from pulling >a "bait-and-switch," stating a series of >"obligations" in their application, only to drop >them after the application is approved. > >Frankly, I think it is entirely within ICANN's >mission to enforce obligations set out in >applications. ICANN is the entity running the >application process, and the credibility of the >enterprise rests in part on holding >applicants/registry operators to their >promises. An interpretation that says that >ICANN can only enforce some of the applicant's >commitments is inherently and fatally flawed. > >It shouldn't be surprising that ICANN cannot escape the limits of its >Bylaws simply by placing something inconsistent with them into a >contract. > > >âHowever, this is not what Becky >postulated. She postulated obligations >âplaced in the agreement by the registry >operator, not obligations placed in the >agreement by ICANN. Once these obligations are >placed in a contract between two parties, the >obligations made by one party are enforceable by >the other, and vice versa. This concept is at the very heart of contracting. > >If a Registry placed something in its application that would, >if agreed, cause ICANN to act inconsistently with law that was >applicable to ICANN, you wouldn't expect the contract to override >applicable law. Nor should it override the governance of ICANN. > > >âThis answer only muddies the waters. We seem >to have shifted somehow from potential >obligations placed on the applicant to potential >obligations placed on ICANN in the application >that would then become part of the RA. I'm not >sure where that shift came from. > >I'm not sure what "real world" examples of this >there would be -- where a registry puts new >obligations on ICANN. I think this is so rare >as to be essentially not worth considering. As >such, the idea that a registry operator could >place something in an application that would >"override the governance of ICANN" seems to be >meaningless (though it sure sounds bad). > >Of course, if an application did require ICANN >to break the law, I would expect that >application to be rejected or modified, rather >than having that obligation placed into an >agreement. Indeed, if it were to ever get that >far, a contractual provision that violated the >law would be void as against public policy (at least under US law). > > > WhatÂ¹s the principle - freedom of > > contract? > >No. > >The Registry's freedom of contract is not limited, subject to applicable >law. But ICANN's is freedom of contract is additionally limited by the >Bylaws. > > >âWe are talking about a single contract here >-- between a registry operator and ICANN. So if >the registry's freedom of contract is not >limited, perforce ICANN's ability to enforce >that same contract is not limited >either.â To say that a registry can agree to >perform certain actions in a contract with >ICANN, but that ICANN can't enforce the contract >to ensure that the registry performs those >action is essentially saying that the contract >is not a contract and the obligations are not >obligations. In that event, these are merely >gratuitous statements without the force of >contract, and thus essentially worthless. Such a result makes no sense > >Greg. >â > >-- > Malcolm Hutty | tel: <tel:%2B44%2020%207645%203523>+44 20 7645 3523 > Head of Public Affairs | Read the LINX Public Affairs blog > London Internet Exchange | > <http://publicaffairs.linx.net/>http://publicaffairs.linx.net/ > > London Internet Exchange Ltd > Monument Place, 24 Monument Street, London EC3R 8AJ > > Company Registered in England No. 3137929 > Trinity Court, Trinity Street, Peterborough PE1 1DA > > >_______________________________________________ >Accountability-Cross-Community mailing list ><mailto:Accountability-Cross-Community@icann.org>Accountability-Cross-Community(a)icann.org >https://mm.icann.org/mailman/listinfo/accountability-cross-community > > >_______________________________________________ >Accountability-Cross-Community mailing list >Accountability-Cross-Community(a)icann.org >https://mm.icann.org/mailman/listinfo/accountability-cross-community

1 0

Proposed carve-out language for community IRP
by Burr, Becky Jan. 18, 2016

Jan. 18, 2016

With thanks to David McAuley, the language below is proposed to address concerns about IRP challenges to the results of a PDP. This paragraph would appear in Rec. 4 perhaps as a parenthetical statement at the end of the lead-in language in paragraph 69, just prior to bullets, and again as a parenthetical in paragraph 117 of the Draft Proposal and Paragraph 54 of Annex 02: Notwithstanding the foregoing and notwithstanding any required threshold for launching a community IRP, no community IRP that challenges the result(s) of a supporting organization’s policy development process (PDP) may be launched without the support of the supporting organization that developed such PDP or, in the case of joint PDPs, without the support of the supporting organizations that developed such PDP. 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>

1 0

DOCUMENT - Rec 10 - SO/AC Accountability (first reading)
by Alice Jansen Jan. 18, 2016

Jan. 18, 2016

Sent on behalf of CCWG-ACCT Co-Chairs In preparation for your Recommendation 8 – SO/AC Accountability (first reading) discussion scheduled for your call #79 - Thursday, 21 January 2016 (12:00 – 15:00 UTC) - please find attached the material to review. Please use this email thread to circulate any comments you may have in advance of the call. Thank you Mathieu, Thomas, León

1 0

DOCUMENT - Rec 8 - Reconsideration (first reading)
by Alice Jansen Jan. 18, 2016

Jan. 18, 2016

Sent on behalf of CCWG-ACCT Co-Chairs In preparation for your Recommendation 8 – Reconsideration (first reading) discussion scheduled for your call #79 - Thursday, 21 January 2016 (12:00 – 15:00 UTC) - please find attached the material to review. Please use this email thread to circulate any comments you may have in advance of the call. Thank you Mathieu, Thomas, León

1 0

Blog: Volume 12: IANA Stewardship Discussions
by Grace Abuhamad Jan. 18, 2016

Jan. 18, 2016

Original link: https://www.icann.org/news/blog/volume-12-an-update-on-iana-stewardship-disc ussions Volume 12: An Update on IANA Stewardship Discussions <https://www.icann.org/news/blog/volume-12-an-update-on-iana-stewardship-di scussions#> <https://www.icann.org/news/blog/volume-12-an-update-on-iana-stewardship-dis cussions#> <https://www.icann.org/news/blog/volume-12-an-update-on-iana-stewardship-dis cussions#> <https://www.icann.org/news/blog/volume-12-an-update-on-iana-stewardship-dis cussions#> <https://www.icann.org/news/blog/volume-12-an-update-on-iana-stewardship-dis cussions#> <https://www.icann.org/news/blog/volume-12-an-update-on-iana-stewardship-dis cussions#> 22 months after the big announcement by NTIA, the transition is within reach It has been a full 22 months since NTIA first announced <https://www.ntia.doc.gov/press-release/2014/ntia-announces-intent-transitio n-key-internet-domain-name-functions> its intention to transition its stewardship of theIANA functions. In that time, the three operational communities (names, numbers, and protocol parameters) have spent thousands of hours meeting, writing and reviewing documents, and reading emails. The combined IANA Stewardship Transition Proposal is ready to be submitted to the ICANNBoard and NTIA, pending the completion of the final report on the Work Stream 1 Recommendations of the CCWG-Accountability. Note: The last status update on this series of IANA Stewardship Transition updates was published 2 November 2015 <https://www.icann.org/news/blog/volume-11-an-update-on-iana-stewardship-dis cussions> . This update, therefore, includes major events since that last update. IANA Stewardship Transition Proposal On 30 November 2015, the IANA Stewardship Transition Coordination Group (ICG <http://www.ianacg.org/> ) published itsSummary Report on Comments Received during the Public Comment Period on the Combined Transition Proposal <https://www.ianacg.org/icg-files/documents/Public-Comment-Summary-final.pdf > . The public comment period <https://www.ianacg.org/calls-for-input/combined-proposal-public-comment-per iod/> for the Proposal to Transition the Stewardship of the Internet Assigned Numbers Authority (IANA) Functions from the U.S. Commerce Department¹s National Telecommunications and Information Administration (NTIA) to the Global Multistakeholder Community <https://www.ianacg.org/icg-files/documents/IANA-stewardship-transition-prop osal-EN.pdf> ended on 8 September 2015. The ICG is now awaiting confirmation from the Cross Community Working Group to Develop an IANAStewardship Transition Proposal on Naming Related Functions (CWG-Stewardship <https://community.icann.org/display/gnsocwgdtstwrdshp/CWG+to+Develop+an+IAN A+Stewardship+Transition+Proposal+on+Naming+Related+Functions> ) that the Work Stream proposal by the Cross Community Working Group on Enhancing ICANN Accountability (CCWG-Accountability <https://community.icann.org/display/acctcrosscomm/CCWG+on+Enhancing+ICANN+A ccountability> ) meets their needs. IANA Intellectual Property Rights (IPR) The CWG-Stewardship is working to finalize its position on IANA IPR. The goal is to find a mutually acceptable way forward on the IPR issue for all three IANA operational communities to allow the IANAStewardship Transition to take place on schedule, in September 2016. In December 2015, the CWG-Stewardship¹s Design Team on IPR (DT-IPR <https://community.icann.org/display/gnsocwgdtstwrdshp/DT-IPR++IANA+Intellec tual+Property+Rights> ) published its latest version of draft principles and requirements <https://community.icann.org/download/attachments/56145364/DT-IPR%20Draft%20 of%20December%2014%202015.pdf?version=1&modificationDate=1450225433000&api=v 2> to which the two operational communities provided feedback in early January. Following the CWG-Stewardship's confirmation on a position, representatives from each operational community will work together to refine an outcome. Implementation work ICANN is facilitating monthly community discussions and providing implementation preparation updates on Transition Facilitation Calls <https://www.icann.org/resources/pages/transition-facilitation-2015-09-23-en > held between ICANN staff and the leadership teams of the CCWG-Accountability, CWG-Stewardship, CRISP Team, IANAPLAN WG, GNSO, ccNSO, IETF, IAB, and the RIRs. The latest call was held on 13 January 2016. To keep up to date with implementation activities, see ICANN¹s IANA Stewardship Implementation page <https://www.icann.org/stewardship-implementation> . CCWG-Accountability Work Stream 1 Recommendations The CCWG-Accountability is currently in the process of finalizing its recommendations for Work Stream 1, following the 8 January 2016 release of the staff report <https://www.icann.org/en/system/files/files/report-comments-draft-ccwg-acco untability-proposal-08jan16-en.pdf> and summary <https://www.icann.org/en/system/files/files/summary-comments-draft-ccwg-acc ountability-proposal-08jan16-en.xlsx> on the public comments received on the 3rd Draft Proposal on Work Stream 1 Recommendations <https://www.icann.org/en/system/files/files/ccwg-draft-2-proposal-work-stre am-1-recs-03aug15-en.pdf> . Between 12 and 21 January, the CCWG-Accountability is conducting a series of readings <https://community.icann.org/display/acctcrosscomm/Final+Report> via teleconference of its revised 12 recommendations. The upcoming teleconferences that will complete the series of readings are: 19 January 2016 <https://community.icann.org/pages/viewpage.action?pageId=56990858> , 12:00-15:00 UTC 21 January 2016 <https://community.icann.org/pages/viewpage.action?pageId=56990860> , 12:00-15:00 UTC Details of the group¹s working methods and time plan for this phase of the proposal finalization are available in this Work Plan <https://community.icann.org/download/attachments/56989168/CCWG%20January%20 Work%20Plan%20-%205%20Jan.pdf?version=1&modificationDate=1452094855000&api=v 2> . The two recommendations that generated the most feedback in the public comment period, and therefore have required the most significant amounts of discussion amongst the CCWG-Accountability to finalize are: Recommendation #5: Changing aspects of ICANN's Mission, Commitments and Core Values Recommendation #11: Board obligations with regards to Governmental Advisory Committee Advice (Stress Test 18) Consideration of the recommendations By Chartering Organizations The CCWG-Accountability has requested that all Chartering Organizations of the CCWG-Accountability indicate whether they support the recommendations in the proposal by 21 January 2015 at the latest. The Chartering Organizations are the GNSO, ALAC, ccNSO, GAC, ASO, and SSAC. The GNSO, ccNSOand GAC are currently working on responses to the CCWG-Accountability. Timeline for finalization of proposal and submission to the ICANN Board The CCWG-Accountability had, at the time of the publication of the 3rd Draft Proposal, planned to complete its final report and send it to the ICANN Board by the end of January 2016. This timeline is likely to be adjusted following feedback from all Chartering Organizations. When feedback is received from all six Chartering Organizations, the CCWG-Accountability will be in a better position to judge how much additional work may be needed to finalize the report and will adjust its timeline for the Work Stream 1 Final Proposal. Feedback From the CCWG-Accountability¹s legal counsel Following a teleconference on 8 January 2016 <https://community.icann.org/pages/viewpage.action?pageId=56989655> between the CCWG-Accountability co-Chairs and the group¹s legal counsel, it was agreed that legal counsel would provide its input on the 12 recommendations in two steps: After the first reading, legal counsel will share high level feedback and/or concerns that could then be discussed as part of the second reading on the recommendation. After the second reading, legal counsel will provide detailed edits where appropriate. If the input would result in a substantial change to a recommendation, there will be a discussion on the CCWG-Accountability mailing list to consider how to proceed with the input. If there is no substantial change involved, the recommendation will be amended to incorporate the legal counsel¹s input. Drafting of ICANN Bylaws On the teleconference on 8 January 2016 <https://community.icann.org/pages/viewpage.action?pageId=56989655> between the CCWG-Accountability co-Chairs and the group¹s legal counsel, counsel noted that final drafting of the Bylaws, based on the recommendations in the CCWG-Accountability¹s final report, would need to be primarily the responsibility of legal counsel. This would then include representatives of the CCWG-Accountability providing an oversight role to ensure the Bylaws meet their requirements, rather than have all members of the CCWG-Accountability participating in line edits of the drafted Bylaws. The CWG-Stewardship is currently reviewing a draft of the ICANN Bylaws <http://mm.icann.org/pipermail/cwg-client/attachments/20151107/f66cef8b/2103 78438_15-0001.pdf> that are to change as a result of the CWG-Stewardship¹s requirements. The draft was submitted <http://mm.icann.org/pipermail/cwg-client/2015-November/000348.html> by the group¹s legal counsel on 7 November 2015. ICANN 55 The CCWG-Accountability will meet in Marrakech during ICANN55 <https://meetings.icann.org/en/marrakech55> , but at this point, the main focus of the CCWG¹s work in Marrakech is planning Work Stream 2 activities. Work Stream 2 focuses on accountability topics that extend beyond the IANA Stewardship Transition. Key documents Jan 2016 CCWG-Accountability Final Report <https://community.icann.org/display/acctcrosscomm/Final+Report> (Work in progress) 14 Dec 2015 CWG-Stewardship IANA Intellectual Property Rights - Draft Principles and Requirements <https://community.icann.org/download/attachments/56145364/DT-IPR%20Draft%20 of%20December%2014%202015.pdf?version=1&modificationDate=1450225433000&api=v 2> 30 Nov 2015ICG - Summary Report on Comments Recieved During the Public Comment Period on the Combined Transition Proposal <https://www.ianacg.org/icg-files/documents/Public-Comment-Summary-final.pdf > You can play a role in IANA¹s future Anyone can participate in discussions about the future of IANA's stewardship and ICANN accountability. For information on joining CCWG-Accountability, contact acct-staff(a)icann.org. Compiled on behalf of ICANN by Samantha Dickinson 15 January 2015

1 0

Recommendation 6 - Human Rights - 1st reading conclusions
by Alice Jansen Jan. 17, 2016

Jan. 17, 2016

Sent on behalf of CoChairs Please find below the main conclusions of our deliberations during call #76. The updated document is attached. 1.Agreement to rely on target dates instead of hard deadlines, in line with general approach agreed for WS2 2. Discussed comments (including Icann Board, RrSG…) requesting that the inclusion of human rights language into the bylaws be delayed until the proposed framework of interpretation was completed or even only be considered in Work Stream 2. a.Independent lawyer input has been provided and concludes : While the addition of the proposed human rights bylaw provision should not increase the exposure of ICANN to legal liability, we recognize that special interest groups and individuals might seek to bring non-meritorious claims, but the risk of meritless claims is already a risk that ICANN faces. b. Board clarified that concern included risk that IRP would interpret the Bylaw language and create “case law policy” while the FoI is finalized. c. Consider Lawyer input suggestion as follows : i. “ expressly limiting the jurisdiction of any internal dispute resolution systems within ICANN (such as the IRP) to preclude claims of human rights violations that are not grounded in a specific violation of an applicable law”. 3. Members and Board are invited to consider whether option c) could be an acceptable way forward a. Confirm recommendation bylaw language as part of WS1, despite concerns expressed b. Defer bylaw language adoption to WS2, when FoI is finalized c. Adopt adjusted bylaw language as part of WS1 to clarify that it can only be enforced or used in an IRP once the FoI is approved (Such as : “This articles becomes effective 30 days after approval of the FoI…”). Second reading is planned for Tuesday, 19 January. Best regards Mathieu, Thomas, León

14 21

Re: [CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion
by David Post Jan. 16, 2016

Jan. 16, 2016

At 06:07 PM 1/15/2016, Greg Shatan wrote: >This is not "regulatory authority" at all.Â It >the enforcement of a bilateral agreement between >ICANN and the registry operator.Â I think this >is a conflation of contractual enforcement and >regulation, which are two different things. SNIP Let me add one brief comment here before I run out the door, and then try to give a more detailed comment to this very interesting thread when I can compose a longer note. The problem we're wrestling with is that some "contractual enforcement" is, in fact, an exercise of something that closely resembles "regulatory authority," and we're trying to define where that line is. At one extreme, let's say ICANN enters into a contract with its office supply company - Staples - and it gets Staples to promise various things - a 25% discount, that it won't employ non-union labor, that it will deliver on Sundays, etc etc. Nobody (I wouldn't think) would have a problem with ICANN enforcing those contract terms, even without any "community consensus" on the matter, and without any need to show that doing so is within ICANN's narrow mission. That's the "contractual enforcement" side. At the other end of the spectrum, if ICANN says to a gTLD applicant that as a condition of entry into the root, it must charge its customers such-and-such, or use only union labor, or have a particular kind of "license," then it's engaged in something that looks a LOT like "regulation," because it has monopoly control over a valuable resource and its "contract terms" are, in effect, rules (or "regulations") that you must comply with (or leave the space entirely). And for those, ICANN should, in my opinion, be tightly bound to abide by the restrictions in the mission. David >If a PIC is vague that there is no reasonable >understanding of its meaning, that would be a >problem.Â I suppose it's possible such PICs >exist, but they have to be a small minority of >the overall PIC universe; examples of such PICs >would be appreciated.Â Putting such "edge >cases" aside, it's completely appropriate for >ICANN to expect registries to comply with PICs >and for ICANN to enforce compliance with those >PICs just as they would any provision of the >contract.Â Typically, there is a very high bar >to voiding provisions of contracts, and even >then there is preference to "blue pencil" them >(i.e., the court rewrites them to be >enforceable) rather than voiding them completely. > >On Fri, Jan 15, 2016 at 5:53 PM, Burr, Becky ><<mailto:Becky.Burr@neustar.biz>Becky.Burr(a)neustar.biz> wrote: >I think this is a very useful discussion getting to the heart of the >matter, so I would really like to encourage others to participate. > >Question - you say > >In other words, the idea that ICANN can "enforce" PICs without itself >determining the standards that PICs seek to enforce simply doesn't stand >up to scrutiny. As soon as ICANN is called on to enforce a PIC against a >registry, it must necessarily assert that a particular kind of action is >required by the PIC, and distinguish it from the action actually >undertaken that the registry asserts to be sufficient. This is the core >of regulatory activity. I have no problem whatsoever with ICANN engaging >in this kind of regulatory behaviour for matters within its limited >Mission, but if we invite ICANN to take this on for an unlimited range >of objectives claimed to be in the public interest, we are essentially >investing ICANN with a global policing power. > >Ok, but can ICANN enforce the part of the contract that says you canÂ¹t >register in the domain unless you are licensed by an appropriate >authority?Â I understand that having rules for allocating new TLDs is >reasonably necessary to ensure the stability and security of the DNS, but >I donÂ¹t understand how enforcing that the registry licensing requirement >is (in and of itself) UNLESS you say that the delegation (community >preference) was made on the basis of that commitment, and enforcing the >commitments underlying the delegation decision is an inherent requirement >of the policy itself. IÂ¹m grasping for a principle here. > > > > >J. Beckwith Burr >Neustar, Inc. / Deputy >General Counsel & Chief Privacy Officer >1775 Pennsylvania Avenue NW, Washington D.C. 20006 >Office: ><tel:%2B1.202.533.2932>+1.202.533.2932Â Mobile: ><tel:%2B1.202.352.6367>+1.202.352.6367 / <http://neustar.biz>neustar.biz ><http://www.neustar.biz> > > > > >On 1/15/16, 11:22 AM, "Malcolm Hutty" ><<mailto:malcolm@linx.net>malcolm(a)linx.net> wrote: > > > > >Becky, > > > >I agree that the existence of community applications has been an > >important part of the new gTLD process. I don't think the small > >limitation on the Mission we have agreed in the Third Draft Report would > >or should prevent ICANN creating new community TLDs in the future. > > > >You give the example of .bank. I don't see anything in the Mission that > >inhibits ICANN in any way from saying that .bank has been created for > >the exclusive use of recognised banks, and that the only banks it > >recognises for this purpose are those with an appropriate banking > >license under applicable law. > > > >This is quite different from regulating the behaviour of banks. If ICANN > >went on to say that any bank must report cash transactions over $10,000 > >to the US treasury, and any bank refused to do this it would take their > >domains away, then that would be an example of ICANN regulating the > >behaviour of banks, not of it identifying a particular user community. > >Though opponents of a limited Mission can try to blur this distinction > >with cleverly-constructed corner cases, I think this distinction is > >quite clear enough to be workable and to be objectively employed by an > >independent reviewer. > > > >Turning to your example of environmental activists, I think it clear > >that if ICANN sets rules requiring disclosure of certain environmental > >practices then that is a clear example of behavioural regulation, that I > >don't think ICANN should be getting into. By contrast, if that registry > >promised to have a stakeholder council and then disbanded it, I think > >this would be a case of changing the organisational structure of the > >registry, no different from disbanding a customer complaints division > >(and no less objectionable). > > > >In short, I think community TLDs should be allowed for identifiable > >communities; I don't think this carries any necessary implication that > >ICANN should get into the business of seeking to regulate the behaviour > >of the members of those communities (except as justified by reasons that > >actually are part of ICANN's Mission, of course). > > > >To those who disagree, I would like to point out the inevitable > >consequences of going down this route. > > > >Some say that the registry should be "made to uphold" these commitments, > >while still thinking that this doesn't require ICANN to begin creating > >such behavioural rules itself. I think this profoundly mistaken. > > > >Suppose that a registry, such as for .eco, makes a commitment to enforce > >certain behaviour by its users, such as the publication of relevant > >environmental reports. As long as nobody is objecting, the fact that > >ICANN has contracted with the registry to do this doesn't really have > >any effect. The only time it matters is when someone complains. > > > >The only way ICANN gets involved is when someone comes to ICANN and says > >".eco promised to make their users disclose environmental reports and > >they're not doing so. Please enforce this requirement on the .eco > >registry". > > > >What is ICANN supposed to do with this complaint? Proponents of PICS > >seem to think there is some magical wand that ICANN waives to bring .eco > >into compliance with its contract. This is nonsense. What actually > >happens is that ICANN contacts the registry and says "We've had a > >complaint you're not requiring publication of relevant reports, is this > >true? Please provide evidence that you are doing as you previously > >promised.". Most likely, the registry replies that they are in > >compliance with their commitment. The evidence offered, however, may > >well be open to differing interpretations: for example, .eco may have > >placed an extremely narrow definition on what constitutes a "relevant > >environmental report". > > > >What is ICANN supposed to do next? On the one hand, it has a > >complainant, who can show that the registry is not doing certain things, > >and argues that those things are required by the PIC. On the other, it > >has a registry, which can show it is doing other things, and argues that > >those things are sufficient to discharge the promise it had previously > >made in the PIC. > > > >It seems to me that there are really two options for how to proceed: > > > >i) ICANN could be so deferential to the registry interpretation as to > >accept its position pretty much automatically: so long as the registry > >didn't simply admit non-compliance, and its claim to compliance wasn't > >manifestly ridiculous, ICANN could simply stop there. But what is the > >value in requiring ICANN to "enforce" PICs to such a limited standard? > >If that's all we're going to do, why not save ourselves a lot of bother > >(not to mention raising expectations from some stakeholders only to > >inevitably disappoint)? > > > >ii) Alternatively, ICANN could investigate the case and come to its own > >view as to whether what the registry has done is sufficient to discharge > >its contractual obligation. However it can ONLY do that by first forming > >a view as to what the PIC requires. So in the putative case, ICANN could > >only enforce a requirement to make reasonable environmental disclosures > >if it itself determines what it considers constitutes a reasonable > >environmental disclosure. Likewise it can only enforce a commitment to > >prevent harassment by setting standards for what constitutes harassment, > >it can only enforce a commitment take down copyright infringing material > >by deciding whether particular publications infringe copyright, and it > >can only enforce a commitment to prevent access to certain web sites by > >minors by deciding both what age constitutes a minor, and what are > >acceptable means for identifying them and for excluding them from access. > > > >In other words, the idea that ICANN can "enforce" PICs without itself > >determining the standards that PICs seek to enforce simply doesn't stand > >up to scrutiny. As soon as ICANN is called on to enforce a PIC against a > >registry, it must necessarily assert that a particular kind of action is > >required by the PIC, and distinguish it from the action actually > >undertaken that the registry asserts to be sufficient. This is the core > >of regulatory activity. I have no problem whatsoever with ICANN engaging > >in this kind of regulatory behaviour for matters within its limited > >Mission, but if we invite ICANN to take this on for an unlimited range > >of objectives claimed to be in the public interest, we are essentially > >investing ICANN with a global policing power. > > > >Some may be happy to see ICANN go down that route. I would not: I think > >it has neither the capacity nor the legitimacy. But I am also worried by > >those who have managed to convince themselves that it is possible to > >enforce PICs for an unlimited range of purposes without itself becoming > >embroiled in setting the rules for those purposes. Those people are, I > >believe, simply kidding themselves. > > > >Malcolm. > > > >-- > >Â Â Â Â Â Â Malcolm Hutty | tel: > <tel:%2B44%2020%207645%203523>+44 20 7645 3523 > >Â Â Head of Public Affairs | Read the LINX Public Affairs blog > > London Internet Exchange | > ><https://urldefense.proofpoint.com/v2/url?u=htt > p-3A__publicaffairs.linx.net>https://urldefense.proofpoint.com/v2/url?u=http-3A__publicaffairs.linx.net > >_&d=CwIF-g&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8W > >DDkMr4k&m=F3FlEVYbysKtCNonZguZbv90urP8qDBk_08KcwSbnzQ&s=ksR3GCVlhY-LMF3l9w > >mgX_POXp3jz25-xZ5f0KkUo-E&e= > > > >Â Â Â Â Â Â Â Â Â London Internet Exchange Ltd > >Â Â Â Â Monument Place, 24 Monument Street, London EC3R 8AJ > > > >Â Â Â Â Â Company Registered in England No. 3137929 > >Â Â Â Â Trinity Court, Trinity Street, Peterborough PE1 1DA > > > > > >_______________________________________________ >Accountability-Cross-Community mailing list ><mailto:Accountability-Cross-Community@icann.org>Accountability-Cross-Community(a)icann.org >https://mm.icann.org/mailman/listinfo/accountability-cross-community > > >_______________________________________________ >Accountability-Cross-Community mailing list >Accountability-Cross-Community(a)icann.org >https://mm.icann.org/mailman/listinfo/accountability-cross-community ******************************* David G Post - Senior Fellow, Open Technology Institute/New America Foundation blog (Volokh Conspiracy) http://www.washingtonpost.com/people/david-post book (Jefferson's Moose) http://tinyurl.com/c327w2n music http://tinyurl.com/davidpostmusic publications etc. http://www.davidpost.com *******************************

1 0

Recommendation 3 - Fundamental Bylaws - 1st reading conclusions
by Alice Jansen Jan. 15, 2016

Jan. 15, 2016

Sent on behalf of CoChairs Please find below the main conclusions of our deliberations during call #77. The updated document is attached. 1. Clarify that IFR provisions apply only to IANA’s domain name management function (since it is part of CWG-Stewardship requirements) 2. Clarify process for change of Articles of Association, which is to be similar to the Fundamental Bylaw change process (paragraph 19-21 – page 5) a. Noting our lawyer’s memo on the topic (Nov 23rd) : […] In the case of ICANN, if the Empowered Community is not provided a right to approve amendments to the Articles, there is a risk that Fundamental Bylaw provisions could be undermined by amendment of the Articles by the ICANN Board, given the hierarchical relationship described above. Thus, we recommend including an approval right with respect to amendments to ICANN’s Articles in favor of the Empowered Community in the same way the Empowered Community has approval rights with respect to Fundamental Bylaws. […] b. Add specific recommendation that the current Articles of Incorporation be modified to remove the notion of members and reflect the need for an affirmative vote of at least three quarters of the Directors, as well as ratification by the Empowered Community. Second reading is planned for Thursday, 21 January. Best regards Mathieu, Thomas, León

3 2