Just for the record, I am a strong supporter of community TLDs and therefore think these kinds of commitments should be enforceable 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> On 1/14/16, 3:59 PM, "Jonathan Zuck" <JZuck@actonline.org> wrote:
This all makes sense but going forward it will require enormous changes to how community proposals and those which overcome GAC objections are handled. As we head into the CCT review (regardless of where consumer trust ends up in the bylaws) it’s not hard to imagine that adherence to PICs will be a part of the consumer trust calculation.
On 1/14/16, 12:59 PM, "accountability-cross-community-bounces@icann.org on behalf of Burr, Becky" <accountability-cross-community-bounces@icann.org on behalf of Becky.Burr@neustar.biz> wrote:
I understand these concerns. Let me try to make my concerns concrete,
particularly in the context community applications for new gTLDs, which
may contain provisions that are a condition of community support but not
strictly within ICANN¹s wheelhouse.
Say, for example, that a community .eco application included provisions,
for example, requiring registrants to disclose certain information about
their environmental practices, and assume for the moment, that the
requirement was the result of input from an advisory group consisting of
global environmental organizations and a condition of the support of those
groups. (I believe that these suppositions are factual but it really
doesn¹t matter.) Suppose, also, that the application includes an
obligation to maintain and support a stakeholder¹s council consisting of
representatives from global environmental organizations. Another example,
suppose .bank requires registrants to demonstrate a certain regulatory
status, and imposed that requirement to gain the support of financial
institutions?
All of those commitments, by virtue of their inclusion in the application,
are enforceable by ICANN. But say that the applicant decides to abandon
the disclosure requirement and disbands the stakeholder council. Are
either of those commitments reasonably necessary to facilitate openness,
interoperability, resilience, security and/or stability of the DNS? Is
ICANN¹s contractual authority to enforce those commitments ³in service² of
ICANN¹s stability and security Mission?
We could say that the community preference for new gTLDs is the result of
bottom-up, multistakeholder policy development and that contractual
enforcement is ³in service² of that policy. But I don¹t know if that
actually resolves the need to be reasonably necessary to facilitate
stability, security, etc.
Thoughts??
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
On 1/14/16, 12:03 PM, "Paul Rosenzweig"
<paul.rosenzweig@redbranchconsulting.com> wrote:
I share Malcolm's view of voluntary commitments. Leaving aside what may
have gone before, allowing the parties to an agreement to contract around
binding limitations on their action would, effectively, nullify the
Mission-limitation principle that is at the core of the accountability
structure we are building. I can live with grandfathering in prior
mistakes
in this regard, if I have to, but it is essential that the line be drawn
for
future actions in stone, not sand.
Cheers
Paul
Paul Rosenzweig
paul.rosenzweig@redbranchconsulting.com
O: +1 (202) 547-0660
M: +1 (202) 329-9650
VOIP: +1 (202) 738-1739
Skype: paul.rosenzweig1066
Link to my PGP Key
-----Original Message-----
From: Malcolm Hutty [mailto:malcolm@linx.net]
Sent: Thursday, January 14, 2016 2:14 AM
To: Burr, Becky <Becky.Burr@neustar.biz>; Accountability Community
<accountability-cross-community@icann.org>
Subject: Re: [CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion
On 06/01/2016 19:03, Burr, Becky wrote:
Is attached in DRAFT FORM. Anything missing or wrong should be
attributed to incompetence rather than conspiracy. I am still working
on questions in 1 section. I will also shortly resend a variety of
previously circulated resource documents.
Becky,
The slide deck you actually presented at meeting 75 contains three
propositions that were not contained in this draft deck you copied to the
list. I believe you described these in your oral presentation as "strawman
propositions for discussion". I am writing to react to those propositions.
"Proposition: The GAC may provide Advice on any matter it sees fit; ICANN
must duly consider such Advice in accordance with the Bylaws, and if it
decides to follow such Advice, must do so in a manner consistent with
ICANN's Bylaws, including its Mission Statement."
I agree with this proposition.
"Proposition: ICANN's agreements with contracted parties may reflect:
(a) bottom-up, consensus-based, multistakeholder policies on issues for
which uniform or coordinated resolution is reasonably necessary to
facilitate the openness, interoperability, resilience, security and/or
stability of the DNS; and (b) other provisions in service of that
Mission."
I also agree with this proposition.
The third propostion you introduce with a question:
"To what extent should contracted parties be free to propose or
voluntarily
accept (and obligated to comply with) contract provisions that exceed the
scope of ICANN's Mission, e.g., to serve a specific community,
pro-actively
address a public policy concern?
If "voluntary" commitments may exceed the scope of ICANN's Mission, how do
you ensure that such commitments are truly voluntary?
Proposition: Individually negotiated commitments will be deemed to be
voluntary. Existing RA and RAA language (including standard PICs) are
"grandfathered" (as defined in Notes). Going forward, a mechanism should
be
available to permit contracted parties to enter into agreements without
waiving the right to challenge (collectively) a contract provision on the
grounds that (a) it exceeds ICANN's Mission and (b) was extracted by ICANN
on an other than voluntary basis."
I do not agree with this proposition, because I think the question you
pose
to which it is offered as an answer is mistaken.
My reasoning is as follows:
Let us set aside the question of how to determine whether a particular
provision of a contract between ICANN and a Registry was arrived at
through
"voluntary" means. Let us also set aside the vexed question of whether the
concept of a "voluntary commitment" is even meaningful in a negotiation
between an entity that has a critical input for its core business and an
entity that is the monopoly supplier of that critical input.
Let us consider instead: why do we care whether terms in Registry
contracts
are "voluntary commitments"?
To put it another way, what is the wrong with ICANN imposing unwanted
terms
on Registries?
It seems to me that the very notion of "voluntary commitment" must be
intended as a meaning of protecting Registries from unreasonable
impositions
by ICANN. However the fear of ICANN making unreasonable impositions on
Registries is not the only or main reason why we want to limit ICANN to
acting within its Mission, so addressing the Mission limitation through
some
definition of what constitutes a "voluntary commitment" misses the point.
Limiting ICANN to its Mission is there to protect the entire community,
not
just Registries. Concerning the so-called "regulatory prohibition", that
prohibition is intended primarily to protect the interests of end-user
registrants, not those of Registries. We should be just as concerned if
ICANN tries to exceed its Mission as a result of a conspiracy between it
and
the Registries as we should if ICANN does so as a result of some other
motivation and then tries to impose requirements on Registries without
their
approval.
Accordingly, I am afraid I cannot agree with either your third proposition
or the assumption on which it rests.
In your question you ask "To what extent should contracted parties be free
to propose or voluntarily accept (and obligated to comply with) contract
provisions that exceed the scope of ICANN's Mission".
The answer to this is that contracted parties are not bound by ICANN's
bylaws, and so they are entirely free to enter into any contractual
relations they wish. However, ICANN is bound by its bylaws, and so is not
free to be the counterparty to a contract the purpose of which exceeds or
is
in contradiction with the Mission or other bylaws requirement.
Incidentally, I would point out that there is nothing unique about the
Mission limitation. If we were to adopt the view that ICANN is free enter
into an agreement with Registries for purposes beyond the Mission merely
because the Registries were eager for it to do so, by the same token ICANN
could then also disregard any other provision of the Bylaws that sought to
constrain how ICANN acts provided that Registries "voluntary" agreed to
that. That cannot be acceptable to anyone, surely.
Kind Regards,
Malcolm.
--
Malcolm Hutty | tel: +44 20 7645 3523
Head of Public Affairs | Read the LINX Public Affairs blog London
Internet Exchange |
https://urldefense.proofpoint.com/v2/url?u=http-3A__publicaffairs.linx.n et
_&d=CwICAg&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP 8W
DDkMr4k&m=S1JiVUQAqGB5VlxgFKlZdI4Kacb3MT5lpljmR0QprN0&s=EG_60KARwEuCkyZe jW
CL5HMy7C5FuGO58n8IlpW3_qE&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
Accountability-Cross-Community@icann.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailma n_
listinfo_accountability-2Dcross-2Dcommunity&d=CwICAg&c=MOptNlVtIETeDALC_ lU
Lrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=S1JiVUQAqGB5VlxgFKlZ dI
4Kacb3MT5lpljmR0QprN0&s=a2j-IrQbQI8nnG8lowtub4eUpDPs20QHQrk9PfOuYak&e=
_______________________________________________
Accountability-Cross-Community mailing list
Accountability-Cross-Community@icann.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman _listinfo_accountability-2Dcross-2Dcommunity&d=CwIGaQ&c=MOptNlVtIETeDALC_ lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=5fp4l6_dpYabbqXJ5jI rneBaxcVshtWf2gPMv57CWQs&s=JDV_2OsfBpBzpvyOseePZwja8Hv4jP7-PUuBgt04DMU&e=