[CCWG-ACCT] The Board's take on the Mission Statement
Alan Greenberg
alan.greenberg at mcgill.ca
Thu Dec 17 20:16:54 UTC 2015
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 at melbourneit.com.au>Bruce.Tonkin at melbourneit.com.au>
>Date: Thursday, December 17, 2015 at 4:13 AM
>To: Accountability Community
><<mailto:accountability-cross-community at icann.org>accountability-cross-community at 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 at icann.org>accountability-cross-community-bounces at icann.org
>[mailto:accountability-cross-community-bounces at icann.org]
>On Behalf Of Burr, Becky
>Sent: Thursday, 17 December 2015 3:00 AM
>To: Accountability Community
><<mailto:accountability-cross-community at icann.org>accountability-cross-community at 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 at icann.org
>https://mm.icann.org/mailman/listinfo/accountability-cross-community
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20151217/1f1c4bdf/attachment.html>
More information about the Accountability-Cross-Community
mailing list