At 17/12/2015 10:11 AM, Burr, Becky wrote:

This is helpful Bruce. I think the language re: allocation and assignment of names in the root as a result of policies works. Also, I am relieved that the language re the permissible scope of ICANN policies is not a fundamental divide – at least from your perspective. Thank you. A couple of key points and questions:

* Reading carefully, it appears that the Board comments with respect to the Mission Statement that rise to the level of a public interest objection are limited to “the contractual enforcement issues.” Can you confirm that this? * Even though this is cast as “the contractual enforcement issues,” I take it that the board actually objects to the provision that says: “ICANN shall not impose regulations on services that use the Internet’s unique identifiers, or the content that such services carry or provide.” [I make that assumption because I don’t know why the board would object to the following statement: "ICANN shall have the ability to negotiate, enter into and enforce agreements with contracted parties in service of its Mission.”] Can you confirm this? * Could you attempt to be concrete about why the Board objects to the regulatory prohibition notwithstanding the following explanatory text, which you previously indicated is not objectionable: 1. The prohibition on the regulation of “content” is not intended to prevent ICANN policies from taking into account the use of domain names as identifiers in various natural languages.

2. The issues identified in Specification 1 to the Registry Agreement and Specification 4 to the Registrar Accreditation Agreement (the so-called “Picket Fence”) are intended and understood to be within the scope of ICANN’s Mission. A side-by-side comparison of the formulation of the Picket Fence in the respective agreements is attached for reference.

Picket Fence issues are clearly within scope for ICANN, but they are not the ONLY thing in scope. The Picket Fence identified a subset of issues that contracted parties agree can be altered by PDP. There are other terms in contracts that CANNOT be altered by a PDP, but they can still be in scope.

3. For the avoidance of uncertainty, the language of existing registry agreements and registrar accreditation agreements should be grandfathered. [ADDITIONAL SUPPLEMENTARY LANGUAGE AGREED TO BUT NOT IN 3RD DRAFT PROPOSAL: This means that the parties who entered into existing contracts intended (and intend) to be bound by those agreements. It means that neither a contracting party nor anyone else should be able to bring a case that any provisions of such agreements on their face are ultra vires. It does not, however, modify any contracting party’s right to challenge the other party¹s interpretation of that language. It does not modify the right of any person or entity materially affected (as defined in the Bylaws) by an action or inaction in violation ICANN¹s Bylaws to seek redress through an IRP. Nor does it modify the scope of ICANN’s Mission.]

We still need a legal opinion (or confirmation) that the wording will allow contract renewal. And I have still not seen how those New gTLD Applications for which contracts are not yet signed at the time the Bylaws come into effect will be suitable "grandfathered" as well. Or is it the intent that those who happen to have their signing delayed will operate under a completely different regime? Alan

4. The CCWG anticipates that the drafters may need to modify provisions of the Articles of Incorporation to align with the revised Bylaws.

NOTE: Not a trick question Bruce, I’m really trying to identify a way forward. Although some of us were comfortable relying on a clear and limited Mission Statement, many – certainly most participants who expressed an opinion on this issue - felt that a clear prohibition on certain types of regulation was mandatory, particularly in light of the “legislative history” of this language (it appeared in both the first and second draft report, so its removal would be construed against the concept). To move the ball forward, we need to have a conversation that goes beyond the mere assertion that “ICANN is not a regulator.” Is there a formulation of the regulatory prohibition that the Board could accept, or is there additional explanatory text that would make the Board comfortable that the Bylaws drafters had sufficient direction to proceed. I am pressing because I have the sense that while we may not that far apart, we could really reach an impasse on this matter. Let’s not worry specifically about placement, but focus on the concept.

Becky

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 / <http://www.neustar.biz>neustar.biz

From: Bruce Tonkin <<mailto:Bruce.Tonkin@melbourneit.com.au>Bruce.Tonkin@melbourneit.com.au> Date: Thursday, December 17, 2015 at 4:13 AM To: Accountability Community <<mailto:accountability-cross-community@icann.org>accountability-cross-community@icann.org> Subject: Re: [CCWG-ACCT] The Board's take on the Mission Statement

Hello Becky,

The addition of “allocation and assignment of names” was intended to capture the role of putting names in the root zone including new gTLDs and IDN-ccTLDs.”

I accept that this could be considered as part of “implementation of policies” = but it was trying to be more specific.

If you are concerned about the language you could reword like:

“coordinate the development and implementation of polices (including the allocation and assignment of names in the root zone as a result of those policies). “

Speaking personally I have no issue with also including the last two paragraphs in your note below which is really a limitation on what policies can be created and how they should be created. This text is really lifted from the registry and registrar agreements so ICANN has already committed to that. It is not something that we as a board directly discussed.

Regards, Bruce Tonkin

From: <mailto:accountability-cross-community-bounces@icann.org>accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Burr, Becky Sent: Thursday, 17 December 2015 3:00 AM To: Accountability Community <<mailto:accountability-cross-community@icann.org>accountability-cross-community@icann.org> Subject: [CCWG-ACCT] The Board's take on the Mission Statement

I have run a comparison between the Mission Statement with respect to names, which has been on the table since January of this year, and the Board’s proposed substitute. In doing so, I have set aside totally the difficult wording issues relating to regulatory prohibition and contracting authority. I am also setting aside, for the moment, Alan G’s concern regarding the bottom–up policy development language (which I believe is addressed through the contracting language). By any measure, the changes are significant. Because the fundamental role of the IRP is to ensure that ICANN stays within its Mission, the changes in the Mission statement directly impact the effectiveness of the “crown jewels” of this accountability exercise.

I have asked Bruce to explain what is encompassed by "the allocation and assignment of names in the root zone” that is not covered by “coordination of the development and implantation of policies.”

I encourage each of you to study the side-by-side comparison attached to determine for yourself whether the Board’s approach is consistent with the goals of clarifying ICANN’s limited Mission.

[]

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 /<http://www.neustar.biz>neustar.biz

_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community