<html>
<body>
At 17/12/2015 10:11 AM, Burr, Becky wrote:<br>
<blockquote type=cite class=cite cite="">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:<br><br>
<ul>
<li><font face="Calibri">Reading carefully, it appears that the Board
comments with respect to the Mission Statement that rise to the level of
a public interest objection <b>are limited to </b>“the contractual
enforcement issues.” Can you confirm that this?
</ul>
<ul>
<li>Even though this is cast as “the contractual enforcement issues,” I
take it that the board actually objects to the provision that says:
“I</font>CANN 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?
</ul>
<ul>
<li>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:
<dl>
<dl>
<dd>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.<br><br>
<dd>2. The issues identified in Specification 1 to the
Registry Agreement and Specification 4 to the Registrar Accreditation
Agreement (the so-called “Picket Fence</i>”) 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. </blockquote>
</dl>
</dl>
</dl><br>
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.<br><br>
<br>
<blockquote type=cite class=cite cite="">
<dl>
<dl>
<dl>
<dd>3. For the avoidance of uncertainty, the language of
existing registry agreements and registrar accreditation agreements
should be grandfathered. <font color="#797979">[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.]</font></blockquote>
</dl>
</dl>
</dl><br>
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?<br><br>
Alan<br><br>
<br>
<blockquote type=cite class=cite cite="">
<dl>
<dl>
<dl>
<dd>4. The CCWG anticipates that the drafters may need to
modify provisions of the Articles of Incorporation to align with the
revised Bylaws.<br><br>
</dl>
</dl>
<dd>NOTE: Not a trick question Bruce, I<font face="Calibri">’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</font>’<font face="Calibri">s not worry specifically about placement,
but focus on the concept.<br><br>
<dd>Becky<br>
</b></font><br>
</dl><br><br>
J. Beckwith Burr <br>
Neustar, Inc. </b>/ </b>Deputy General Counsel & Chief Privacy
Officer<br>
1775 Pennsylvania Avenue NW, Washington D.C. 20006<br>
Office: </b>+1.202.533.2932 Mobile: </b>+1.202.352.6367 /</b>
<a href="http://www.neustar.biz">neustar.biz</a><br>
</b><br>
From: Bruce Tonkin
<<a href="mailto:Bruce.Tonkin@melbourneit.com.au">
Bruce.Tonkin@melbourneit.com.au</a>><br>
Date: Thursday, December 17, 2015 at 4:13 AM<br>
To: Accountability Community
<<a href="mailto:accountability-cross-community@icann.org">
accountability-cross-community@icann.org</a>><br>
Subject: Re: [CCWG-ACCT] The Board's take on the Mission
Statement<br><br>
Hello Becky,<br>
<br>
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.”<br>
<br>
I accept that this could be considered as part of “implementation of
policies” = but it was trying to be more specific.<br>
<br>
If you are concerned about the language you could reword like:<br>
<br>
“coordinate the development and implementation of polices (including the
allocation and assignment of names in the root zone as a result of those
policies). “<br>
<br>
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.<br>
<br>
<br>
Regards,<br>
Bruce Tonkin<br>
<br>
<br>
<br>
<br>
<a name="_MailEndCompose"></a> <br>
From:</b>
<a href="mailto:accountability-cross-community-bounces@icann.org">
accountability-cross-community-bounces@icann.org</a>
[<a href="mailto:accountability-cross-community-bounces@icann.org" eudora="autourl">
mailto:accountability-cross-community-bounces@icann.org</a>] On Behalf Of
</b>Burr, Becky<br>
Sent:</b> Thursday, 17 December 2015 3:00 AM<br>
To:</b> Accountability Community
<<a href="mailto:accountability-cross-community@icann.org">
accountability-cross-community@icann.org</a>><br>
Subject:</b> [CCWG-ACCT] The Board's take on the Mission Statement<br>
<br>
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.<br>
<br>
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.” <br>
<br>
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.<br>
<br>
<img src="cid:image001.png@01D13907.5FF1EE20" width=1052 height=1054 alt="[]">
<br>
<br>
J. Beckwith Burr<br>
Neustar, Inc.</b>/Deputy General Counsel & Chief Privacy Officer<br>
1775 Pennsylvania Avenue NW, Washington D.C. 20006<br>
Office:</b>+1.202.533.2932 Mobile:</b>+1.202.352.6367
/<a href="http://www.neustar.biz">neustar.biz</a><br>
</b><br>
_______________________________________________<br>
Accountability-Cross-Community mailing list<br>
Accountability-Cross-Community@icann.org<br>
<a href="https://mm.icann.org/mailman/listinfo/accountability-cross-community" eudora="autourl">
https://mm.icann.org/mailman/listinfo/accountability-cross-community</a>
</blockquote></body>
</html>