[CCWG-ACCT] Implications of bottom-up "policy" requirement
Alan Greenberg
alan.greenberg at mcgill.ca
Fri Nov 13 18:40:00 UTC 2015
No, they should. But we need to be careful that
our existing contracts are not destroyed. What is
deemed to be a "policy" can be very wide and the
majority of our current contracts were not
created by consensus policy (nor can they ever be under the terms of Spec 1/4).
Alan
At 13/11/2015 01:27 PM, Seun Ojedeji wrote:
>".... 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"
><<mailto:alan.greenberg at mcgill.ca>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:
><tel:%2B1.202.533.2932>+1.202.533.2932 Mobile:
><tel:%2B1.202.352.6367>+1.202.352.6367 / <http://neustar.biz>neustar.biz
><http://www.neustar.biz>
>
>
>
>On 11/12/15, 1:23 PM, "Alan Greenberg"
><<mailto:alan.greenberg at mcgill.ca>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:
> <tel:%2B1.202.533.2932>+1.202.533.2932 Mobile:
> <tel:%2B1.202.352.6367>+1.202.352.6367 / <http://neustar.biz>neustar.biz
> >><http://www.neustar.biz>
> >>
> >>
> >>
> >>
> >>On 11/12/15, 9:51 AM, "Alan Greenberg"
> <<mailto:alan.greenberg at mcgill.ca>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
> >> >>><mailto:Accountability-Cross-Community at ica
> nn.org>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>ht
> tps://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>ht
> tps://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>ht
> tps://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>ht
> tps://urldefense.proofpoint.com/v2/url?
> u=<http://http-3A__www.davidpost.com>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
> >> ><mailto:Accountability-Cross-Community at icann
> .org>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>http://www.washingtonpost.com/people/david-post
>
>book (Jefferson's
>Moose) <http://tinyurl.com/c327w2n>http://tinyurl.com/c327w2n
>music
><http://tinyurl.com/davidpostmusic>http://tinyurl.com/davidpostmusic
>publications etc. <http://www.davidpost.com>http://www.davidpost.com
>*******************************
>
>
>_______________________________________________
>Accountability-Cross-Community mailing list
><mailto:Accountability-Cross-Community at icann.org>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/c9c36daa/attachment-0001.html>
More information about the Accountability-Cross-Community
mailing list