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

[Burr, Becky]

So if an applicant includes obligations in the application, it is ok for
ICANN to enforce those commitments? What¹s the principle - freedom of
contract? But if GAC, ALAC, or someone else urges ICANN to pick one
applicant over another, anyone can challenge that [what? The urging, the
selection, something else?]?  You¹re disqualified if GAC endorses your
application?  




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/17/16, 2:58 PM, "Mueller, Milton L" <milton at gatech.edu> wrote:

>> -----Original Message-----
>> 
>> 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
>
>Becky, this is a non sequitur.
>
>The issue is not whether there can be or should be community TLDs, but
>whether the wider community that makes policy within ICANN, such as GNSO,
>ALAC or GAC, can impose enforceable commitments on proposed community
>TLDs as a condition of their acceptance. If the original proposer of the
>community TLD wants to bind themselves to do something (e.g., require all
>registrants to wear purple hats) I don't care. If GAC, GNSO, or ALAC
>conspire to get ICANN to reject a community TLD applicant because it
>doesn't require its registrants to wear purple hats, ICANN is straying
>from its mission.
>
>Furthermore, if ICANN has two similar competing applicants for the same
>TLD string, and GAC, ALAC, GNSO or whoever urges ICANN to choose
>applicant A over applicant B because A promises to force all its
>registrants to wear purple hats, then that should be challengeable via
>IRP as exceeding ICANN's mission.
>
>Do we agree on that much?
>
>
>Dr. Milton L Mueller
>Professor, School of Public Policy
>Georgia Institute of Technology
>
>Internet Governance Project
>
>