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

Fri Nov 13 18:27:01 UTC 2015

".... and, when they alter existing contracts must be developed through a
bottom-up, consensus-based multistakeholder process."

Does the above imply that other policies that does not alter existing
contracts should/may not go through MS process? I hope that's not what is
intended

Regards

Sent from my Asus Zenfone2
Kindly excuse brevity and typos.
On 13 Nov 2015 19:12, "Alan Greenberg" <alan.greenberg at mcgill.ca> wrote:

> On review, the change is not quite that simple, partly because in the
> current version, the first bullet does not make sense.
>
> removing the extraneous punctuation for just the first bullet we have: "In
> this role, with respect to domain names, ICANN’s Mission is to coordinate
> the development and implementation of policies for which uniform or
> coordinated resolution is reasonably necessary to facilitate the openness,
> interoperability, resilience, security and/or stability of the DNS"
>
> I do not think that "uniform and coordinated resolution of policies" makes
> sense. I think it was meant to say that the policies allow uniform and
> coordinated resolution of names, not the policies them selves.
>
> Perhaps the following works.
>
> In this role, with respect to domain names, ICANN’s Mission is to
> coordinate the development and implementation of policies which allow the
> necessary uniform or coordinated resolution to facilitate the openness,
> interoperability, resilience, security and/or stability of the DNS. Such
> policies must be designed to ensure the stable and secure operation of the
> Internet’s unique names systems and, when they alter existing contracts
> must be developed through a bottom-up, consensus-based multistakeholder
> process.
>
> Alan
>
>
>
>
>
>
>
>
>
>
>
>
> At 13/11/2015 12:13 PM, Alan Greenberg wrote:
>
>> 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-2Dcomm
>>>>> unity&d=CwICAg&c=MOptNlVtIETeD
>>>>> >>>>>AL
>>>>> >>
>>>>> >>>>>C_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdY
>>>>> ahOP8WDDkMr4k&m=He0ZyGdJIDc7wz
>>>>> >>>>>sd
>>>>> >>
>>>>> >>>>>IRdFvJnAm7THjsagVk801BeQ4hE&s=HtbFOYAAV7
>>>>> l0jaMecsuB8Y11DrNFSMO6Xc4C4cNB
>>>>> >>>>>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=MOptNlVt
>>>>> IETeDALC_lULrw&r=62cJFOifzm6X_
>>>>> >>>>GR
>>>>> >>
>>>>> >>>>laq8Mo8TjDmrxdYahOP8WDDkMr4k&m=He0ZyGdJID
>>>>> c7wzsdIRdFvJnAm7THjsagVk801BeQ
>>>>> >>>>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=62cJFO
>>>>> ifzm6X_GRlaq8Mo8TjDmrxdYahOP8W
>>>>> >>>>DD
>>>>> >>
>>>>> >>>>kMr4k&m=He0ZyGdJIDc7wzsdIRdFvJnAm7THjsagV
>>>>> k801BeQ4hE&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=He0ZyGdJIDc7wzsdIRdFvJnAm7
>>>>> THjsagVk801BeQ4hE&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=62cJFOif
>>>>> zm6X_GRlaq8Mo8TjDmrxdYahOP8WDD
>>>>> >>>>kM
>>>>> >>
>>>>> >>>>r4k&m=He0ZyGdJIDc7wzsdIRdFvJnAm7THjsagVk8
>>>>> 01BeQ4hE&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-2Dcommunit
>>>>> y&d=CwICAg&c=MOptNlVtIETeDALC_
>>>>> >>>lU
>>>>> >>
>>>>> >>>Lrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8W
>>>>> DDkMr4k&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
>>> *******************************
>>>
>>
> _______________________________________________
> Accountability-Cross-Community mailing list
> Accountability-Cross-Community at icann.org
> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20151113/d8e37fda/attachment-0001.html>