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

Thu Jan 14 21:24:01 UTC 2016

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 at 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 at icann.org
>on behalf of Burr, Becky"
><accountability-cross-community-bounces at icann.org on behalf of
>Becky.Burr at 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
>
>><http://www.neustar.biz>
>
>>
>
>>
>
>>
>
>>
>
>>On 1/14/16, 12:03 PM, "Paul Rosenzweig"
>
>><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
>
>>>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 at linx.net]
>
>>>Sent: Thursday, January 14, 2016 2:14 AM
>
>>>To: Burr, Becky <Becky.Burr at neustar.biz>; Accountability Community
>
>>><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
>
>>>   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 at 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 at 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=
>> 
>