[CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion

Fri Jan 15 21:43:18 UTC 2016

Hmm.  Well.  I feel compelled to defend the right to apply for and operate a “meaningless" TLD.

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>

From: Greg Shatan <gregshatanipc at gmail.com<mailto:gregshatanipc at gmail.com>>
Date: Friday, January 15, 2016 at 3:56 PM
To: David Post <david.g.post at gmail.com<mailto:david.g.post at gmail.com>>
Cc: Becky Burr <becky.burr at neustar.biz<mailto:becky.burr at neustar.biz>>, Accountability Community <accountability-cross-community at icann.org<mailto:accountability-cross-community at icann.org>>
Subject: Re: [CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion

David,

I thinks this is a good point, actually.  There are complexities, fuzzinesses and variables to be sure.  And we may draw the (fuzzy) line in different places.  But even common agreement on what is on the "right" side of the line would be a start.

At some point, we also get to some fairly philosophical policy questions -- what should it mean to operate a TLD? Should it be largely meaningless to have one TLD vs. another?  Or should many TLDs be very meaningful?  Should a TLD registry operator promise that their TLD have a certain meaning (security, our registrants are real banks and not phishing scams, you should feel safe here)?  When should ICANN resolve contention sets based on who made the better promises?  Should all applicants have to keep all their promises when the TLD is "live" -- or are some applicants or some promises different than others?

Meaningless TLDs would be kind of a disaster, since the new gTLD marketplace is predicated on differentiation, and on making a ready connection between the string and the meaning.  We actually did pretty well on the gTLD side with largely meaningless TLDs for a long time (e.g., how many network vs. non-network registrations are there in .net?), while most ccTLDs had at least some degree of meaningfulness.  Imagine a new gTLD program predicated on meaningless strings -- all Londoners should want .blatz, while the horse-loving community is going to love .splooshle.  Not too compelling.  Indeed if meaningless strings were cool, there probably would be no domain names -- we'd just have IP addresses....

Greg

On Thu, Jan 14, 2016 at 1:51 PM, David Post <david.g.post at gmail.com<mailto:david.g.post at gmail.com>> wrote:
Is it possible to analyze these problems by asking first whether ICANN has imposed these requirements (for e.g. a stakeholder council) on the applicant as a condition of entry into the root or, instead, it's a voluntary commitment undertaken by the applicant for its own purposes (e.g. to get the support of global environmental organizations, to get external funding, or what have you).

If it were the former, then I think I do have a problem with ICANN's enforcement of the provision absent some demonstration both that it is reasonably necessary for the stability/security/interoperability of the DNS (which I wouldn't think it is, on the face of it from your hypothetical) and that it is otherwise within the confines of the mission.  On the other hand, to the extent that the applicant made some voluntary undertaking that was not viewed by ICANN as a condition of its entry into the root, I have less of a problem in saying that ICANN can take steps to enforce the contractual promises made to it by third parties.

I know it's a fuzzy line - maybe too fuzzy to be workable.  But I do think that it might be the line that we've been struggling to define throughout this discussion.
David

At 12:59 PM 1/14/2016, Burr, Becky 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<tel:%2B1.202.533.2932>  Mobile: +1.202.352.6367<tel:%2B1.202.352.6367> / neustar.biz<http://neustar.biz>
<http://www.neustar.biz>

On 1/14/16, 12:03 PM, "Paul Rosenzweig"
<paul.rosenzweig at redbranchconsulting.com<mailto:paul.rosenzweig at 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 at redbranchconsulting.com<mailto:paul.rosenzweig at redbranchconsulting.com>
>O: +1 (202) 547-0660<tel:%2B1%20%28202%29%20547-0660>
>M: +1 (202) 329-9650<tel:%2B1%20%28202%29%20329-9650>
>VOIP: +1 (202) 738-1739<tel:%2B1%20%28202%29%20738-1739>
>Skype: paul.rosenzweig1066
>Link to my PGP Key
>
>
>-----Original Message-----
>From: Malcolm Hutty [mailto:malcolm at linx.net<mailto:malcolm at linx.net>]
>Sent: Thursday, January 14, 2016 2:14 AM
>To: Burr, Becky <Becky.Burr at neustar.biz<mailto:Becky.Burr at neustar.biz>>; Accountability Community
><accountability-cross-community at icann.org<mailto:accountability-cross-community at 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<tel:%2B44%2020%207645%203523>
>   Head of Public Affairs | Read the LINX Public Affairs blog  London
>Internet Exchange |
>https://urldefense.proofpoint.com/v2/url?u=http-3A__publicaffairs.linx.net
>_&d=CwICAg&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8W
>DDkMr4k&m=S1JiVUQAqGB5VlxgFKlZdI4Kacb3MT5lpljmR0QprN0&s=EG_60KARwEuCkyZejW
>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 at icann.org<mailto:Accountability-Cross-Community at icann.org>
>https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_
>listinfo_accountability-2Dcross-2Dcommunity&d=CwICAg&c=MOptNlVtIETeDALC_lU
>Lrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=S1JiVUQAqGB5VlxgFKlZdI
>4Kacb3MT5lpljmR0QprN0&s=a2j-IrQbQI8nnG8lowtub4eUpDPs20QHQrk9PfOuYak&e=
>

_______________________________________________
Accountability-Cross-Community mailing list
Accountability-Cross-Community at icann.org<mailto:Accountability-Cross-Community at icann.org>
https://mm.icann.org/mailman/listinfo/accountability-cross-community<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_accountability-2Dcross-2Dcommunity&d=CwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=X78WIcBHzgYjpH4XJRJEQJFTZHGa7lahlvtUFIMtbZQ&s=is6eCPhWlDOLWHO04Lu1jzkdeZJZcUdMbFKPM1H4SFc&e=>

*******************************
David G Post - Senior Fellow, Open Technology Institute/New America Foundation
blog (Volokh Conspiracy) http://www.washingtonpost.com/people/david-post<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.washingtonpost.com_people_david-2Dpost&d=CwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=X78WIcBHzgYjpH4XJRJEQJFTZHGa7lahlvtUFIMtbZQ&s=s-XZ_7FTxSAX_3b0e7i2NMjTksq1FZYVaBl6daxii3M&e=>
book (Jefferson's Moose)  http://tinyurl.com/c327w2n<https://urldefense.proofpoint.com/v2/url?u=http-3A__tinyurl.com_c327w2n&d=CwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=X78WIcBHzgYjpH4XJRJEQJFTZHGa7lahlvtUFIMtbZQ&s=yUIiHI_AXX2f05ciq9Iu1iECfVfQGSRho6NyphGdpLw&e=>
music http://tinyurl.com/davidpostmusic<https://urldefense.proofpoint.com/v2/url?u=http-3A__tinyurl.com_davidpostmusic&d=CwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=X78WIcBHzgYjpH4XJRJEQJFTZHGa7lahlvtUFIMtbZQ&s=H2MJlMVtmrLGjZ5Ediad8L-Ocrtn_O1Exk5U7NMgw3s&e=> publications etc.  http://www.davidpost.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.davidpost.com&d=CwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=X78WIcBHzgYjpH4XJRJEQJFTZHGa7lahlvtUFIMtbZQ&s=1uyD8PvH5k98f_Hst4gBl62K_pOL3Z8QPZb4NFREI9A&e=>
*******************************
_______________________________________________
Accountability-Cross-Community mailing list
Accountability-Cross-Community at icann.org<mailto:Accountability-Cross-Community at icann.org>
https://mm.icann.org/mailman/listinfo/accountability-cross-community<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_accountability-2Dcross-2Dcommunity&d=CwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=X78WIcBHzgYjpH4XJRJEQJFTZHGa7lahlvtUFIMtbZQ&s=is6eCPhWlDOLWHO04Lu1jzkdeZJZcUdMbFKPM1H4SFc&e=>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20160115/772f4bba/attachment-0001.html>