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

Fri Nov 13 17:13:33 UTC 2015

Good question. Let me look at the original version again. Alan

At 13/11/2015 10:48 AM, David Post wrote:
>At 09:45 AM 11/13/2015, Alan Greenberg wrote:
>>I would like to propose a solution to this problem.
>>
>>The current proposal is that policies (without 
>>being specific) be developed by a bottom-up MS process.
>>
>>I suggest that we replace "policy' by 
>>"Consensus Policy". This is a term already used 
>>in the Bylaws and is applicable to both the Registry and Registrar contracts.
>>
>>If, as my original scenario envisions, that 
>>such a policy is struck down, then it may be 
>>re-crafted (or not!) using the established By-Law mandated processes.
>
>Alan
>
>Can you clarify what you mean when you propose 
>replacing "policy" with "Consensus 
>Policy"?  Just substituting the words "Consensus 
>Policy" for "policy" in the proposal language looks like this:
>
>
>"ICANN's Mission is to coordinate the 
>development and implementation of Consensus 
>Policies: . For which uniform or coordinated 
>resolution is reasonably necessary to facilitate 
>the openness, interoperability, resilience, 
>security and/or stability: . That are developed 
>through a bottom-up, consensus-based 
>multistakeholder process and designed to ensure 
>the stable and secure operation of the Internet's unique names system."
>
>Is that what you're proposing?
>
>David
>
>
>>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=
>>> >
>
>*******************************
>David G Post - Senior Fellow, Open Technology Institute/New America Foundation
>blog (Volokh Conspiracy) http://www.washingtonpost.com/people/david-post
>book (Jefferson's Moose)  http://tinyurl.com/c327w2n
>music http://tinyurl.com/davidpostmusic 
>publications etc.  http://www.davidpost.com
>*******************************