November 2015 - Accountability-Cross-Community

Re: [CCWG-ACCT] Board comments on the Mission statement
by David Post Nov. 20, 2015

Nov. 20, 2015

Greg: I'd be interested to know how you would respond to Andrew Sullivan's hypothetical: >What about collaborating with anti-abuse people >in taking down names that are the source of >attacks. Is that an imposition of an >obligation on someone whose only connection to >the DNS is the use you describe? Wouldn't that be prohibited under your language as "a regulation on services ... that use the Internet's unique identifiers"? I think what confuses me is the meaning you're giving to "use." You wrote: >I am saying that the type of "use" referred to >here is not the use in the sense of owning a >domain name or typing in a domain name, whether >its being done by registry operators, registrars >or my Aunt Tillie.Â They may initiate a chain >of events that leads to a software process >"using" an IP address or domain name, but >initiating that chain of events is not using a >unique identifier, any more than I use a carburetor when I drive a car. But you DO "use a carburetor" when you drive a car, just as you use your car's tires, transmission, etc. when you drive it. Is that incorrect? To reiterate something I said elsewhere, I'm not at all opposed to crafting the prohibition to concentrate on the services that ICANN cannot regulate, if we can find language that does the job well. David At 01:07 PM 11/20/2015, Greg Shatan wrote: >Bruce, > >I've just posted an email to this thread that >clarifies what is meant by "services" in the following clause: > >ICANN shall not impose regulations on services >(i.e., any software process that accepts >connections for the Internet) that use the >Internet's unique identifiers, or the content >that such services carry or provide. ICANN shall >have the ability to negotiate, enter into and >enforce agreements with contracted parties in service of its mission.Â > >The point is that the focus is on services such >as "web services" running on a web server, or >"mail services" running on a mail server.Â The >focus is not on service providers, whether >registries, registrars, internet service >providers, nail salons or auto mechanics. The >parenthetical language clarifies that and tries >to be as technology-agnostic as possible (I note >that it is consistent with the definition of web >services in my other email, which was drafted in >2004), but improvements are always >welcome.Â The examples provided in my other >email may provide some inspiration for such improvements. > >As such, the novel "revised" "services clause" >provided by David Post is going off in an >entirely different direction, and is really of >no help in explaining to the Board (or anyone >else) what the above clause means.Â Indeed, it >no longer deals just with "services" by any >definition -- it refers to "persons or >entities," which goes even beyond a misdirected >definition of "services." Also, the concept of >"obligations" goes far beyond the concept of >"regulations" in terms of stating the >limitations on ICANN.Â Finally,the idea that >this focuses on "persons or entities whose only >connection to the DNS is that they use a domain >name for Internet communication" is nowhere >found in the clause above or in any of the >discussions I've seen or participated in >regarding this provision.Â So, rather than >being a "revision" of the current services >clause, this alternative is a completely new construction. > >The "idea" that David postulates and then >rapidly assumes that "pretty much everyone >agrees with" also goes far beyond and in >different directions from the above clause, >which reflects hours of careful discussion and >compromise among a number of participants from >different stakeholder groups.Â I am confident >that the statement that "pretty much everyone >agrees with" David's idea is false.Â I, for >one, certainly don't agree with it as a >statement that bears any relationship to the >above clause.Â As such, I think it has no value >in the work of this group other than to yank it >off course, which I think would be highly >counterproductive at this point in the proceedings. > >As to the Board's concerns: > * "Some existing registry agreements may be > out of compliance with ICANN's responsibilities > if this change is adopted": I, for one, had > that concern about the language that appears in > the November 15 formal update.Â I believe that > the current language actually resolves, rather > than causes this problem.Â If the Board > disagrees, I think a far more specific > discussion is needed -- one that clearly > identifies the language (or change/deletion of > language) that causes the Board's concern, and > which provisions in which existing registry > agreements might be out of > compliance.Â Dealing in abstract concerns is > not particularly helpful.Â As far as I know, > it was not the intention of any of the drafters > to nullify or expose to challenge any > provisions of any registry or registrar > agreements.Â Of course, this should be > clarified, and if the Board has identified a > "land mine" in the language that has been > planted in anticipation of a later attempt to > challenge provisions of existing agreements, > that land mind should be extracted and de-fused. > * The use of the word regulate (which occurs > on both the November 15 and November 17 > language, so I assume the Board's concern > covers both versions): Â I have some sympathy > for this, although there are instances of > "regulation" for rules imposed by a private > entity to carry out policy rather than rules > imposed by a government to carry out laws.Â So > far, though, finding a word that does not > substantially change the intended meaning has > been a challenge (such as when "obligation" was > substituted for "regulation" as discussed > above).Â I'm at a loss though to understand > what risk this use would cause to ICANN. > * The definition of services: This is > discussed above and and in my prior email, so I > won't reiterate here.Â While it could be > improved. but it clearly points in the right > direction and away from the wrong one -- and that is critical. > >Greg > >On Thu, Nov 19, 2015 at 4:39 PM, David Post ><<mailto:david.g.post@gmail.com>david.g.post(a)gmail.com> wrote: >Bruce >One question:Â The Board suggests that if >language i adopted that says âICANN shall not >impose regulations on services (i.e., any >software process that accepts connections for >the Internet) that use the Internet's unique >identifiers, or the content that such services >carry or provide ..." there might be some >existing registry agreements that would be "out >of compliance with ICANN's >responsibilities."Â I'd be curious to know what >the Board is concerned with there - what parts >of which registry agreements might be affected >(and made non-compliant) by this language? >With respect to that same "regulations on >services" language, the Board says that it is >"unclear," and asks for "some examples of what >the CCWG believes that ICANN should and should not be able to do." >I agree that the "services" language isn't clear >at the moment.Â Here's my attempt to capture >the point that I think is being made:Â ICANN >should not be allowed to impose -- directly or >indirectly, via its contracts -- obligations on >persons or entities whose only connection to the >DNS is that they use a domain name for Internet communication.Â > >I think it's pretty straightforward.Â I use a >domain name >(<http://davidpost.com>davidpost.com) for >Internet communication.Â The idea -- and I >think pretty much everyone agrees with this? - >is that ICANN can't impose any obligations on me >that affect how I operate the site, what content >I host or don't host, what goods or services I >can or cannot offer, what billing system I use >for those goods and services, what anti-virus >software I install, ... It can't do that >directly (by imposing some contract terms on me >itself) or indirectlyÂ (by getting 3d parties >like the registries or registrars to impose the obligations on me). >Registries and registrars, of course, are not >entities "whose only connection to the DNS is >that they use a domain name for Internet >communication," so this clause shouldn't affect >ICANN's ability to impose obligations on them >(which remains limited by other portions of the Mission Statement). >David > > >David > > > >At 02:12 AM 11/19/2015, Bruce Tonkin wrote: >>Hello All, >>The Board has been considering the CCWG Update >>on Progress Made In and After ICANN54 in Dublin published on 15 Nov 2015. >>The Board information call today considered the >>changes to the mission statement identified in that update. >>Attached is the Board's preliminary comments on >>the mission statement part of the Dublin update >>report.Â Â As we review the remainder of that >>Update, we'll send through additional comments. >>Regards, >>Bruce Tonkin >>ICANN Board Liaison to the CCWG >> >> >>_______________________________________________ >>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 >******************************* >David G Post - Senior Fellow, Open Technology >Institute/New America Foundation >blog (Volokh Conspiracy) ><http://www.washingtonpost.com/people/david-post>http://www.washingtonpost.com/people/david-post > >book (Jefferson's >Moose)Â ><http://tinyurl.com/c327w2n%A0%A0%A0%A0%A0%A0>http://tinyurl.com/c327w2nÂ >Â Â Â Â >music ><http://tinyurl.com/davidpostmusic>http://tinyurl.com/davidpostmusic >publications etc.Â http://www.davidpost.comÂ Â Â Â Â Â Â >******************************* >_______________________________________________ >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 ******************************* 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

Translations of Formal Update (November 15)
by Hillary Jett Nov. 20, 2015

Nov. 20, 2015

Hi all, Please find attached the translations of the CCWG Formal Update issued on November 15th. These documents are currently being posted on the wiki. Thank you, Hillary -- Hillary Jett Communications Coordinator Internet Corporation for Assigned Names and Numbers (ICANN) Mobile: +1 (202) 674-3403 Email: hillary.jett(a)icann.org

1 0

Timeline and next steps (updated)
by León Felipe Sánchez Ambía Nov. 20, 2015

Nov. 20, 2015

An earlier version of this email was sent mistakenly so please disregard the earlier version and have this version as the final version. ================= Dear all, As indicated on call #68, we have designed a detailed roadmap of key dates and milestones toward finalizing theThird Draft Proposal that we invite you to read and mark in your calendars. In order to meet our 30 November deadline, it will be important that we all comply with this calendar of deliverables to ensure feedback and edits are incorporated into the Third Proposal in a prompt and appropriate fashion: 20-Nov-15 Full Proposal content is delivered to CCWG by 23:59 UTC 21-23 Nov-15 CCWG Co-Chairs and Rapporteurs gather feedback from Working Party groups, legal counsel and Advisors 23-Nov-15 CCWG final comments on Full Proposal content due by 23:59 UTC 24-Nov-15 Weekly call #69 24-25-Nov 15 Back and forth and finalizing content with Co-Chairs, Writing team holding the pen 25-Nov-15 Content due to translation / formatting by 23:59 UTC 26-Nov-15 Additional CCWG-ACCT call (call #70) 30-Nov-15 Begin Phase 2 of Consideration by Chartering Organizations 30-Nov-15 Begin professional proofreading/final editing 12 -Dec-15 Translations ready 20-Dec-15 Delivery of final proofreading/editing 21-Dec-15 End of public comment and first close for Chartering Organizations to indicate support for recommendations 24-Dec-15 Staff summary of public comments and Chartering Organization support for recommendation Please note that in consideration of the work load, we recommend holding an additional next week on Thursday 26 November at 14:00-16:00 UTC. For US-based colleagues, the timeslot was selected so that it is early in day for you in consideration of the U.S. holiday. We recognize that we are operating under tight deadlines to produce our Third Draft Proposal and as always, thank you for your cooperation and hard work. Best regards Mathieu, Thomas, León

22 44

Board comments on the Mission statement
by Bruce Tonkin Nov. 19, 2015

Nov. 19, 2015

Hello All, The Board has been considering the CCWG Update on Progress Made In and After ICANN54 in Dublin published on 15 Nov 2015. The Board information call today considered the changes to the mission statement identified in that update. Attached is the Board's preliminary comments on the mission statement part of the Dublin update report. As we review the remainder of that Update, we'll send through additional comments. Regards, Bruce Tonkin ICANN Board Liaison to the CCWG

7 7

FW: [community-finance] Additional information on USG Transition costs published
by James Gannon Nov. 19, 2015

Nov. 19, 2015

For the lists information. From: <community-finance-bounces(a)icann.org<mailto:community-finance-bounces@icann.org>> on behalf of "Xavier J. Calvez" <xavier.calvez(a)icann.org<mailto:xavier.calvez@icann.org>> Date: Thursday 19 November 2015 at 4:29 p.m. To: "community-finance(a)icann.org<mailto:community-finance@icann.org>" <community-finance(a)icann.org<mailto:community-finance@icann.org>>, Policy Staff <policy-staff(a)icann.org<mailto:policy-staff@icann.org>>, Lise Fuhr <lise.fuhr(a)difo.dk<mailto:lise.fuhr@difo.dk>>, Mathieu Weill <mathieu.weill(a)afnic.fr<mailto:mathieu.weill@afnic.fr>>, Jonathan Robinson <jrobinson(a)afilias.info<mailto:jrobinson@afilias.info>>, 'León Felipe Sánchez Ambía' <leonfelipe(a)sanchez.mx<mailto:leonfelipe@sanchez.mx>>, 'Thomas Rickert' <thomas(a)rickert.net<mailto:thomas@rickert.net>> Cc: ICANN News Alert <communications(a)icann.org<mailto:communications@icann.org>>, Grace Abuhamad <grace.abuhamad(a)icann.org<mailto:grace.abuhamad@icann.org>>, BFC <fin-comm(a)icann.org<mailto:fin-comm@icann.org>>, Theresa Swinehart <theresa.swinehart(a)icann.org<mailto:theresa.swinehart@icann.org>>, Alice Jansen <alice.jansen(a)icann.org<mailto:alice.jansen@icann.org>> Subject: [community-finance] Additional information on USG Transition costs published Dear all, Please find below the link to the existing USG Transition expenses page on ICANN.org, that we have updated with additional detailed information on the Professional Services expenses incurred on project until 30 September 2015. Notably, we provide a breakdown of the expenses by type of activity (engagement, lobbying, language services,…), also indicating the names of the vendors. https://www.icann.org/resources/pages/iana-stewardship-project-costs-2015-1… During the Dublin meeting, we presented updates on the USG Transition costs and questions were asked to request further detail on the professional services expenses. This additional information published addresses these requests and increases further as a result our transparency on this project. In addition, further information and disclosure of lobbying activities at ICANN has been provided, to address more fully questions raised during the public forums in Buenos Aires and Dublin. See the link to the announcement below: https://www.icann.org/news/announcement-2015-11-19-en Glen, Lars, Please be sure to forward this email to Stephanie Perrin, who had asked a question on the professional services expenses during the GNSO session on Sunday 19 October (copy me please). Thank you to those community members who, through their questions and requests, take part in improving every day ICANN’s transparency, and accountability as a result. Feel free to forward this email broadly. Best, Xavier Xavier Calvez CFO ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094 Office: +1 (310) 301-5838 Fax: +1 (310) 957-2348 Cell: +1 (805) 312-0052

1 0

Timeline and next steps
by León Felipe Sánchez Ambía Nov. 19, 2015

Nov. 19, 2015

Dear all, As indicated on call #68, we have designed a detailed roadmap of key dates and milestones toward finalizing theThird Draft Proposal that we invite you to read and mark in your calendars. In order to meet our 30 November deadline, it will be important that we all comply with this calendar of deliverables to ensure feedback and edits are incorporated into the Third Proposal in a prompt and appropriate fashion: 20-Nov-15 Full Proposal content is delivered to CCWG by 23:59 UTC 21 – 23 Nov-15 CCWG Co-Chairs and Rapporteurs gather feedback from Working Party groups, legal counsel and Advisors 23-Nov-15 CCWG final comments on Full Proposal due by 23:59 UTC 24-25 Nov 15 Back and forth and finalizing content with Co-Chairs, Writing team holding the pen 25-Nov-15 Content due to translation / formatting by 23:59 UTC 30-Nov-15 Begin Phase 2 of Consideration by Chartering Organizations 30-Nov-15 Begin professional proofreading/final editing 12 -Dec-15 Translations ready 20-Dec-15 Delivery of final proofreading/editing 21-Dec-15 End of public comment and first close for Chartering Organizations to indicate support for recommendations 24-Dec-15 Staff summary of public comments and Chartering Organization support for recommendation We recognize that we are operating under tight deadlines to produce our Third Draft Proposal and as always, thank you for your cooperation and hard work. Best regards Mathieu, Thomas, León

1 0

Notes-Recordings-Transcript links for CCWG ACCT Meeting #68 - 17 November
by Brenda Brewer Nov. 19, 2015

Nov. 19, 2015

Hello all, The notes, recordings and transcripts for CCWG ACCT meeting #68 - 17 November will be available here: https://community.icann.org/x/h7VYAw A copy of the notes and action items may be found below. Thank you. Kind regards, Brenda Action Items * Action (CCWG Members): Chartering Org appointed members to socialise the 'Dublin Update' with respective communities and prepare for release of full proposal on 30 November. * Action (Becky/Chairs): Provide an explicit certified description of the task and all of the considerations for legal counsel to incorporate in this drafting exercise. * Action (Adler/Sidley): Request that legal counsel review the language for the Mission, noting the group's preference and Sebastien's concern for non-native English speakers. * Action (Jordan/WP1): Send a written proposal to the CCWG mailing list describing the issue and the proposed solution(s). Include clarification on whether or not abstention is considered support or not. Notes These high-level notes are designed to help you navigate through content of the call and do not substitute in any way the transcript. 1. Welcome, Roll Call, SOI * Agenda slightly modifed in order, but the items remain the same as circulated earlier this week. * Samantha and Mathieu on audio only. 2. Opening Remarks * Dublin Update published on Sunday (was originally labeled as a Summary, but considering the feedback on the list, the document was modified slightly in purpose) * There are some outstanding items. These will be discussed on today's call. * This document is a communication tool for those outside the CCWG who have had a difficult time following the progress. * Support and endorsement of Chartering Orgs is critical to the success of the CCWG. Action (CCWG Members): Chartering Org appointed members to socialize the 'Dublin Update' with respective communities and prepare for release of full proposal on 30 November. 3. Mission Discussion * On the left is the language circulated immediately after Dublin (based on 2nd Draft Proposal). * Since then, the discussion has evolved to present different alternatives (one from Andrew Sullivan, one from Shatan/Mueller/Bladel and one from Mueller). * Support for Alternative 1 language. * Add "ICANN shall have the ability to negotiate, enter into and enforce agreements with contracted parties [in service of / in so far as these agreements are consistent with /in furtherance of / consistent with/ in performing] its Mission.". This group's preference was "in service of" Action (Becky/Chairs): Provide an explicit certified description of the task and all of the considerations for legal counsel to incorporate in this drafting exercise. Action (Adler/Sidley): Request that legal counsel review the language for the Mission, noting the group's preference and Sebastien's concern for non-native English speakers. 4. PDP interaction with Standard Bylaws Veto * Proposal that PDP changes come through as a package. * Read the full proposal here: <http://mm.icann.org/pipermail/accountability-cross-community/2015-November/…> http://mm.icann.org/pipermail/accountability-cross-community/2015-November/… * No objection to the proposal. 5. Decision-making - thresholds of support * There is no document for this issue, but there has been discussion on list. * If the GAC does not participate in the community mechanism, the thresholds currently in place would require unanimous participation. * GAC position currently: GAC will take a position when we have the position on the paper. Until then, the GAC has consensus input on the second draft report. Action (Jordan/WP1): Send a written proposal to the CCWG mailing list describing the issue and the proposed solution(s). Include clarification on whether or not abstention is considered support or not. 6. ST-18 subgroup update * The first ST-18 subgroup call was yesterday. * Another call scheduled for tomorrow (Wednesday) at 13:00 UTC. * The goal is to come back to the CCWG by next Monday at the latest (so that results are ready for the CCWG call on Tuesday). 7. Timeline Discussion * 21 - 23 Nov-15 Feedback from CCWG * 23-Nov-15 Final comments on Full Proposal content due from CCWG by midnight UTC * 24 - 25 Nov Finalizing content (send to translation/formatting at midnight UTC on 25th) * 30-Nov-15 Beginning of Public Comment Phase 2 (and begin professional proofreading/final editing) * 12 -Dec-15 Anticipated date for delivery of translations * 21-Dec-15 Public comment ends * 24-Dec-15 Staff summary of public comment for review 8. AOB n/a

5 6

Notes-Recordings-Transcript links for ST18 Meeting #2 - 18 November
by Brenda Brewer Nov. 19, 2015

Nov. 19, 2015

Hello all, The notes, recordings and transcripts for the ST18 Meeting #2 - 18 November will be available here: https://community.icann.org/x/Kr1YAw A copy of the notes may be found below. Thank you. Kind regards, Brenda Notes These high-level notes are designed to help you navigate through content of the call and do not substitute in any way the transcript. MW - two documents have been distributed and can be found at <https://community.icann.org/x/crxYAw> https://community.icann.org/x/crxYAw Summary from MW - Requirement to not tell the GAC how to define consensus. - Focus is on how the Board should deal with GAC advice General discussion - DMartinon, PSilva, BSchaefer, JCancio, SDelBianco, PCorwin, PISilva, JCancio, Izumi, Proposal of Board acceptance level at 97% or more support of advice by the GAC. SDelBianco, PISilva, BSchaefer, DMartinon, Wrap up - MWeill - some new options are presented which could limit the number of options. We will circulate options shortly. We need to have an additional call on this topic this week. Next steps: - MW will circulate options for ST18 for comments from this group by 23:59 today. - Reconvene Friday this week at the same time for 90 minutes. conclusion of call.

3 3

Paper for discussion/decision - Community Decision-Making: Thresholds Consideration
by Jordan Carter Nov. 19, 2015

Nov. 19, 2015

Dear all As promised on our call, I have prepared a paper on the decision-making thresholds matter for CCWG consideration. The paper itself is pasted below, and the attached versions in .docx and .pdf also include the decision table with thresholds etc. It is unchanged. Look forward to comments and discussion... best Jordan Community Decision-Making: Thresholds Consideration 18 November 2015 Introduction During its call #68 on 17 November, the CCWG discussed a scenario related to decision thresholds in the Community Mechanism that has been raised by participants on the email list. This discussion has happened a couple of times since it became clear at / after Dublin that the RSSAC and SSAC would not be decisional participants in the Community Mechanism. With these two groups excluded, it is likely the Third Draft Proposal will specify the three SOs, ALAC and GAC as the five “decisional participants” – groups that can express support for or objection to the use of a community power & the engagement process, or choose to express no view at all. The scenario A version of this scenario is as follows (this is entirely hypothetical): *A proposed Annual Operating Plan and Budget is approved by the Board even though substantial community concerns about a particular project (Project X) related to generic top level domains have not been taken into account.* *The ALAC and the GNSO follow the escalation path and convene a Conference call to discuss exercising the Budget veto. Opposition continues to register.* *The GAC joins the group in favour of vetoing the Budget to call a Community Forum. Opposition continues to register.* *The ASO makes it clear it has no interest in the level of funding for Project X, which is the core of the dispute between Board and Community, and will not participate in the decision. This means only four SOs and ACs are left to make decisions.* *The ccNSO is split on whether it is appropriate to make a decision on a gTLD names matter, and proves unable to reach a decision by the end of the time allowed. This is even though many ccTLD managers are opposed to Project X, and only a few support it.* *The use of the community power lapses with only three SOs supporting its use, none objecting, and one not offering a decision (effectively, abstaining), so the Annual Operating Plan and Budget go into effect. The community remains upset and considers other options.* The problem The concern raised by this scenario is as follows: *By reducing the number of decisional participants from seven groups to five groups, a threshold of four SOs and ACs expressing support to exercise a power is too high (if one of them is unable to participate). It is too high because it requires complete unanimity among the rest, a threshold that is inconsistent with the CCWG’s desire to avoid unanimity being required for the use of any of the powers.* Solving the problem The approach I raised for dealing with this issue proposed on the CCWG call on 17 November was as follows: For community powers that require consensus support from four SOs or ACs to exercise the power (powers on Budget, Fundamental bylaws change, Board recall and IANA Names functions separation), an exception should be added as follows: *Where only four SOs and ACs are participating in the decision to exercise the power (through supporting it or objecting to it), the threshold required is only three (3) SOs/ACs in favour, and no more than one objection.* In essence, adding this exception is a possible way to deal with the reduced number of decision-makers (from seven to five), and reduce the likely number of cases where unanimity might be required to use the relevant community powers. This would in turn make sure the powers could be used, and so the incentive effects they are designed to have on Board / Community cooperation would remain strong. This approach develops what was in our Second Draft Proposal, where we suggested only counting affirmative votes to hit support thresholds. Non-participation in that system could also have led to unanimity among participants being a practical requirement. Adopting this solution would be a *change* to our decision-making approach and would be noted as such (compared with Dublin, as this whole Dublin-based approach is new compared with the Second Draft Proposal). The counter-argument & approach A counter-argument to this can be expressed as follows: *Regardless of the reduced number of participants, the threshold should stay the same, because only the strongest and broadest possible community support should allow the exercise of the Community Powers for which a threshold of four SOs/ACs in favour has been proposed.* To give effect to this approach, no changes need to be made to what we decided a week or two ago. Discussion My view as rapporteur is that this question is finely balanced. There are two competing principles: · Making sure community powers can be used without setting a threshold that practically requires unanimity · Making sure community powers are only used with widespread community consensus As a CCWG participant, I haven’t come to a firm conclusion. It seems like the proposed approach steps back a little bit from high degrees of consensus (though they remain quite high); on the other hand, not modifying in line with the proposed approach risks leaving some of the powers practically un-useable, and that is not desirable. Jordan Carter, WP1 Rapporteur, CCWG -- Jordan Carter Chief Executive *InternetNZ* +64-4-495-2118 (office) | +64-21-442-649 (mob) Email: jordan(a)internetnz.net.nz Skype: jordancarter Web: www.internetnz.nz *A better world through a better Internet *

2 1

PDP interaction with bylaws veto - proposed approach
by Jordan Carter Nov. 18, 2015

Nov. 18, 2015

*Dear CCWG colleagues,* *PDP Interaction with Bylaws Veto* In developing accountability improvements for ICANN, the CCWG has been careful to try not to change ICANN's core policy-making processes. The tools it has proposed to improve accountability are generally aimed at ICANN-wide issues, not policy development in the SOs. An example has been raised where policymaking and the bylaws veto power might clash. Here is the scenario: *The outcome of a PDP within an SO could mean that some consequential changes to the ICANN bylaws were needed to implement its recommendations.* *PDP is core policy making and should not be subject to community veto.* *If the PDP *did* require bylaws changes, and those changes *were* subject to the veto, then in effect the community veto would apply to policymaking.* This is a gap in our core proposal which can reasonably easily be closed. *Here is the simplest way to close the gap and ensure policy-making is protected from said veto:* *1: put a requirement (in the bylaws) that any Bylaws changes that are required to implement a PDP are clearly identified in this way, and are not combined with other, non-PDP related bylaws changes.* *2: put a requirement in the Standard Bylaws veto process that for these two steps of the community escalation process:* * -- decision to hold a community forum* * -- decision to exercise the veto power* *the SO which has performed the PDP giving rise to the Bylaws change MUST express its SUPPORT for the exercise of the veto.* This approach has the least possible interference with the scheme of our community powers, does not reopen questions about relative weights between SOs/ACs, does not ban a veto being considered, etc. The community can still trigger a veto process and have the conference call, so issues causing concern will be discussed in a community-wide forum. If this exceptional treatment to a bylaws change means the community really can't live with the outcome of a PDP and associated bylaws changes, they have a number of remedies they could use: - they can work with the Board to ensure that the bylaws change proposal doesn't get the required (2/3?) majority in the Board to be approved (and so would not be implemented) - they can recall the ICANN Board and replace it with a different Board that will follow the community's wishes in not implementing such a bylaws change In other words, this does not leave the possibility of rogue "ICANN transformation by PDP" on the table. Other options I considered were: - a blanket rule that no standard bylaws veto could apply to a PDP bylaws change (rejected because this seemed to change the community power more than minimally) - a rule that no standard bylaws veto could apply to a PDP bylaws change unless it exceeded certain impacts - for instance a net financial impact of $0.5m (rejected because it would be complex to decide the principles to apply to what was in and what was out, and because boundary cases would need adjudication) - a rule that no standard bylaws veto could apply to a PDP bylaws change that only affected the Bylaws that constitute that SO (rejected because policy may properly go beyond the structure of the SO's bylaws) I look forward to your feedback on this proposed way through, and I thank those who have taken the time to discuss the issue with me in coming to this recommendation. cheers Jordan Jordan Carter WP1 Rapporteur, CCWG Chief Executive *InternetNZ* +64-4-495-2118 (office) | +64-21-442-649 (mob) Email: jordan(a)internetnz.net.nz Skype: jordancarter Web: www.internetnz.nz *A better world through a better Internet* -- Jordan Carter Chief Executive, InternetNZ +64-21-442-649 | jordan(a)internetnz.net.nz Sent on the run, apologies for brevity

6 11