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

Alan Greenberg alan.greenberg at mcgill.ca
Thu Nov 12 21:23:06 UTC 2015


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_mailma
> >>>n_listinfo_accountability-2Dcross-2Dcommunity&d=CwICAg&c=MOptNlVtIETeDAL
> >>>C_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=He0ZyGdJIDc7wzsd
> >>>IRdFvJnAm7THjsagVk801BeQ4hE&s=HtbFOYAAV7l0jaMecsuB8Y11DrNFSMO6Xc4C4cNBTJ
> >>>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=He0ZyGdJIDc7wzsdIRdFvJnAm7THjsagVk801BeQ4h
> >>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_GRlaq8Mo8TjDmrxdYahOP8WDD
> >>kMr4k&m=He0ZyGdJIDc7wzsdIRdFvJnAm7THjsagVk801BeQ4hE&s=KGa9_YOIKx24ypUggxm
> >>2sdw-N8-55AfqtvPzjbBsU_s&e=
> >>music
> >>https://urldefense.proofpoint.com/v2/url?u=http-3A__tinyurl.com_davidpost
> >>music&d=CwICAg&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYa
> >>hOP8WDDkMr4k&m=He0ZyGdJIDc7wzsdIRdFvJnAm7THjsagVk801BeQ4hE&s=k3sxcCisSpzv
> >>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_GRlaq8Mo8TjDmrxdYahOP8WDDkM
> >>r4k&m=He0ZyGdJIDc7wzsdIRdFvJnAm7THjsagVk801BeQ4hE&s=swRN-B4OyZhrqkSq2N3Zm
> >>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_mailman_
> >listinfo_accountability-2Dcross-2Dcommunity&d=CwICAg&c=MOptNlVtIETeDALC_lU
> >Lrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=He0ZyGdJIDc7wzsdIRdFvJ
> >nAm7THjsagVk801BeQ4hE&s=HtbFOYAAV7l0jaMecsuB8Y11DrNFSMO6Xc4C4cNBTJ8&e=



More information about the Accountability-Cross-Community mailing list