[CCWG-ACCT] Implications of bottom-up "policy" requirement

Burr, Becky Becky.Burr at neustar.biz
Thu Nov 12 21:38:48 UTC 2015


But why isn’t the answer that it is a part of a non-policy provision of a
commercial contract entered into in furtherance of ICANN’s 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 / neustar.biz
<http://www.neustar.biz>




On 11/12/15, 1:23 PM, "Alan Greenberg" <alan.greenberg at mcgill.ca> wrote:

>Of course contracts are not policies. But
>contracts contain provisions based on policies.
>Stress tests 29 and 30 explicitly makes reference
>to an IRP challenge could asserting that a
>contract provision was not developed by consensus.
>
>If the mission statement addition said that
>Consensus Policy must be developed by a bottom-up
>MS process, that would be fine. But it simply
>says "policies", an undefined and rather vague term.
>
>Alan
>
>At 12/11/2015 03:29 PM, Burr, Becky wrote:
>>With all due respect - contracts are NOT policies.  Contracts reflect
>>policies, and they contain limits on what ICANN can impose unilaterally
>>on
>>contracted parties.  But contracts with registries and registrars contain
>>lots of mutually agreed commercial terms and conditions that are NOT
>>policy.  That is why ICANN must be able to enter into and enforce
>>contracts ³in furtherance of its mission"
>>
>>
>>J. Beckwith Burr
>>Neustar, Inc. / Deputymply says "policies"
>>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 11/12/15, 9:51 AM, "Alan Greenberg" <alan.greenberg at mcgill.ca> wrote:
>>
>> >David, there are several issues here.
>> >
>> >PICs were not developed through a bottom-up process, although they
>> >were subject to comment processes at various times.
>> >
>> >However, PICs are documented in Spec 11 of the registry
>> >agreements.  Spec 1 is the explicit list of what topics can be the
>> >subject of a GNSO PDP, and for whatever reason (you can attribute it
>> >to incompetence or conspiracy), PIC are not in the list.
>> >
>> >My worry is that PICs, or virtually any part of a contract might be
>> >able to be struck down by and IRP because they were not developed in
>> >a bottom-up MS process, but there is no way to use the bottom-up MS
>> >process to replace them.
>> >
>> >Alan
>> >
>> >At 12/11/2015 10:26 AM, David Post wrote:
>> >>Alan - I'm not clear what you mean when you say that
>> >>
>> >>>>AG:- some issues which could reasonably considered "policy", such
>> >>>>as PICs in registry agreements, according to the Registry
>> >>>>agreement Spec 1, are NOT SUBJECT to Consensus Policy"?
>> >>
>> >>Do you mean that the insertion of the PICs in Spec 1 was not
>> >>developed by a consensus process ( I would agree )?  Or that under
>> >>the current language of the proposal, the insertion of the PICs is
>> >>the kind of action that ICANN would be permitted to take without it
>> >>being subject to the consensus process (I don't think I agree )?
>> >>
>> >>David
>> >>
>> >>
>> >>At 07:54 AM 11/12/2015, Alan Greenberg wrote:
>> >>
>> >>>I am increasingly becoming uneasy with the implications of several
>> >>>of our proposed changes/powers. I would be happy to be convinced
>> >>>that I am missing something and there is no need to be concerned.
>> >>>
>> >>>The particular interaction that I am thinking of is:
>> >>>
>> >>>- the new requirement that "policies" be developed through a
>> >>>bottom-up multistakeholder process;
>> >>>
>> >>>- the fact that we never really define "policy" and therefore what
>> >>>is a policy is subject to interpretation;
>> >>>
>> >>>- we have contracts which are made up of a combination of
>> >>>historical language, negotiated terms, Consensus Policy and yes,
>> >>>terms which at some point in time may have been included through
>> >>>more arcane processes;
>> >>>
>> >>>- some issues which could reasonably considered "policy", such as
>> >>>PICs in registry agreements, according to the Registry agreement
>> >>>Spec 1, are NOT SUBJECT to Consensus Policy;
>> >>>
>> >>>- most contractual provisions are also outside of the limited
>> >>>subjects in Spec 1 (Registry) / Spec 4 (Registrar);
>> >>>
>> >>>- The IRP which can judge something to be outside of ICANN's mission;
>> >>>
>> >>>When you put these together, we have the situation that an IRP
>> >>>could judge that some contractual provision is "policy", was not
>> >>>developed through a bottom-up MS process, and therefore violates
>> >>>the Bylaws. Yet such terms are not eligible for a bottom-up MS
>> >>>process, or predate such processes.
>> >>>
>> >>>I find this EXTREMELY problematic.
>> >>>
>> >>>Alan
>> >>>
>> >>>_______________________________________________
>> >>>Accountability-Cross-Community mailing list
>> >>>Accountability-Cross-Community at icann.org
>> 
>>>>>https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mail
>>>>>ma
>> 
>>>>>n_listinfo_accountability-2Dcross-2Dcommunity&d=CwICAg&c=MOptNlVtIETeD
>>>>>AL
>> 
>>>>>C_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=He0ZyGdJIDc7wz
>>>>>sd
>> 
>>>>>IRdFvJnAm7THjsagVk801BeQ4hE&s=HtbFOYAAV7l0jaMecsuB8Y11DrNFSMO6Xc4C4cNB
>>>>>TJ
>> >>>8&e=
>> >>
>> >>*******************************
>> >>David G Post - Senior Fellow, Open Technology Institute/New America
>> >>Foundation
>> >>blog (Volokh Conspiracy)
>> 
>>>>https://urldefense.proofpoint.com/v2/url?u=http-3A__www.washingtonpost.
>>>>co
>> 
>>>>m_people_david-2Dpost&d=CwICAg&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_
>>>>GR
>> 
>>>>laq8Mo8TjDmrxdYahOP8WDDkMr4k&m=He0ZyGdJIDc7wzsdIRdFvJnAm7THjsagVk801BeQ
>>>>4h
>> >>E&s=Du760LWuQaX9-Rtg6INi7M4U1UdOwceKgmo_8WTqEXo&e=
>> >>book (Jefferson's Moose)
>> 
>>>>https://urldefense.proofpoint.com/v2/url?u=http-3A__tinyurl.com_c327w2n
>>>>&d
>> 
>>>>=CwICAg&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8W
>>>>DD
>> 
>>>>kMr4k&m=He0ZyGdJIDc7wzsdIRdFvJnAm7THjsagVk801BeQ4hE&s=KGa9_YOIKx24ypUgg
>>>>xm
>> >>2sdw-N8-55AfqtvPzjbBsU_s&e=
>> >>music
>> 
>>>>https://urldefense.proofpoint.com/v2/url?u=http-3A__tinyurl.com_davidpo
>>>>st
>> 
>>>>music&d=CwICAg&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxd
>>>>Ya
>> 
>>>>hOP8WDDkMr4k&m=He0ZyGdJIDc7wzsdIRdFvJnAm7THjsagVk801BeQ4hE&s=k3sxcCisSp
>>>>zv
>> >>xkzLursRJem4WqQn3W-AAl8g9Du1glw&e=   publications
>> >>etc.
>> 
>>>>https://urldefense.proofpoint.com/v2/url?u=http-3A__www.davidpost.com&d
>>>>=C
>> 
>>>>wICAg&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDD
>>>>kM
>> 
>>>>r4k&m=He0ZyGdJIDc7wzsdIRdFvJnAm7THjsagVk801BeQ4hE&s=swRN-B4OyZhrqkSq2N3
>>>>Zm
>> >>gJTXXeioI4XPsyNyxfuSZM&e=
>> >>*******************************
>> >
>> >_______________________________________________
>> >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=He0ZyGdJIDc7wzsdIRdF
>>>vJ
>> >nAm7THjsagVk801BeQ4hE&s=HtbFOYAAV7l0jaMecsuB8Y11DrNFSMO6Xc4C4cNBTJ8&e=
>



More information about the Accountability-Cross-Community mailing list