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

Alan Greenberg alan.greenberg at mcgill.ca
Thu Nov 12 22:07:42 UTC 2015


A completely logical answer, but it is unclear 
what some future IRP might accept as one if it is asserted in the IRP request.

The existence of PICs is a good example. A number 
of people have claimed that the Board had no 
right to invent them since it was clearly a "policy".

Under the new Policy and Implementation measures, 
if it affects a contracted party in a substantive 
way, it is a policy. There for PICs could be 
invalidated just like that, and since they are 
not within the limited list in Spec 1, could not 
be re-instated. I'm sure there are plenty of other examples.

Alan


At 12/11/2015 04:38 PM, Burr, Becky wrote:
>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