<html>
<body>
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).<br><br>
Alan<br><br>
At 13/11/2015 01:27 PM, Seun Ojedeji wrote:<br><br>
<blockquote type=cite class=cite cite="">".... and, when they alter
existing contracts must be developed through a bottom-up, consensus-based
multistakeholder process."<br><br>
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<br><br>
Regards<br><br>
Sent from my Asus Zenfone2<br>
Kindly excuse brevity and typos.<br>
On 13 Nov 2015 19:12, "Alan Greenberg"
<<a href="mailto:alan.greenberg@mcgill.ca">alan.greenberg@mcgill.ca</a>
> wrote:
<dl>
<dd>On review, the change is not quite that simple, partly because in the
current version, the first bullet does not make sense.<br>
<dd>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"<br>
<dd>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.<br>
<dd>Perhaps the following works.<br>
<dd>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.<br>
<dd>Alan<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<dd>At 13/11/2015 12:13 PM, Alan Greenberg wrote:
<dl>
<dd>Good question. Let me look at the original version again. Alan<br>
<dd>At 13/11/2015 10:48 AM, David Post wrote:
<dl>
<dd>At 09:45 AM 11/13/2015, Alan Greenberg wrote:
<dl>
<dd>I would like to propose a solution to this problem.<br>
<dd>The current proposal is that policies (without being specific) be
developed by a bottom-up MS process.<br>
<dd>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.<br>
<dd>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.<br>
<br><br>
</dl>
<dd>Alan<br>
<dd>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:<br>
<br>
<dd>"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."<br><br>
<dd>Is that what you're proposing?<br>
<dd>David<br>
<br><br>
<dl>
<dd>At 12/11/2015 04:38 PM, Burr, Becky wrote:
<dl>
<dd>But why isn¡¯t the answer that it is a part of a non-policy
provision of a
<dd>commercial contract entered into in furtherance of ICANN¡¯s
mission?<br>
<br><br>
<dd>J. Beckwith Burr
<dd>Neustar, Inc. / Deputy
<dd>General Counsel & Chief Privacy Officer
<dd>1775 Pennsylvania Avenue NW, Washington D.C. 20006
<dd>Office: <a href="tel:%2B1.202.533.2932">+1.202.533.2932</a>
Mobile: <a href="tel:%2B1.202.352.6367">+1.202.352.6367</a> /
<a href="http://neustar.biz">neustar.biz</a>
<dd><<a href="http://www.neustar.biz/" eudora="autourl">
http://www.neustar.biz</a>><br>
<br>
<br>
<br>
<dd>On 11/12/15, 1:23 PM, "Alan Greenberg"
<<a href="mailto:alan.greenberg@mcgill.ca">alan.greenberg@mcgill.ca</a>
> wrote:<br>
<dd>>Of course contracts are not policies. But
<dd>>contracts contain provisions based on policies.
<dd>>Stress tests 29 and 30 explicitly makes reference
<dd>>to an IRP challenge could asserting that a
<dd>>contract provision was not developed by consensus.
<dd>>
<dd>>If the mission statement addition said that
<dd>>Consensus Policy must be developed by a bottom-up
<dd>>MS process, that would be fine. But it simply
<dd>>says "policies", an undefined and rather vague term.
<dd>>
<dd>>Alan
<dd>>
<dd>>At 12/11/2015 03:29 PM, Burr, Becky wrote:
<dd>>>With all due respect - contracts are NOT policies.
Contracts reflect
<dd>>>policies, and they contain limits on what ICANN can impose
unilaterally
<dd>>>on
<dd>>>contracted parties. But contracts with registries and
registrars contain
<dd>>>lots of mutually agreed commercial terms and conditions that
are NOT
<dd>>>policy. That is why ICANN must be able to enter into
and enforce
<dd>>>contracts ©øin furtherance of its mission"
<dd>>>
<dd>>>
<dd>>>J. Beckwith Burr
<dd>>>Neustar, Inc. / Deputymply says "policies"
<dd>>>General Counsel & Chief Privacy Officer
<dd>>>1775 Pennsylvania Avenue NW, Washington D.C. 20006
<dd>>>Office:
<a href="tel:%2B1.202.533.2932">+1.202.533.2932</a> Mobile:
<a href="tel:%2B1.202.352.6367">+1.202.352.6367</a> /
<a href="http://neustar.biz">neustar.biz</a>
<dd>>><<a href="http://www.neustar.biz/" eudora="autourl">
http://www.neustar.biz</a>>
<dd>>>
<dd>>>
<dd>>>
<dd>>>
<dd>>>On 11/12/15, 9:51 AM, "Alan Greenberg"
<<a href="mailto:alan.greenberg@mcgill.ca">alan.greenberg@mcgill.ca</a>
> wrote:
<dd>>>
<dd>>> >David, there are several issues here.
<dd>>> >
<dd>>> >PICs were not developed through a bottom-up process,
although they
<dd>>> >were subject to comment processes at various times.
<dd>>> >
<dd>>> >However, PICs are documented in Spec 11 of the registry
<dd>>> >agreements. Spec 1 is the explicit list of what
topics can be the
<dd>>> >subject of a GNSO PDP, and for whatever reason (you can
attribute it
<dd>>> >to incompetence or conspiracy), PIC are not in the
list.
<dd>>> >
<dd>>> >My worry is that PICs, or virtually any part of a
contract might be
<dd>>> >able to be struck down by and IRP because they were not
developed in
<dd>>> >a bottom-up MS process, but there is no way to use the
bottom-up MS
<dd>>> >process to replace them.
<dd>>> >
<dd>>> >Alan
<dd>>> >
<dd>>> >At 12/11/2015 10:26 AM, David Post wrote:
<dd>>> >>Alan - I'm not clear what you mean when you say
that
<dd>>> >>
<dd>>> >>>>AG:- some issues which could reasonably
considered "policy", such
<dd>>> >>>>as PICs in registry agreements, according to
the Registry
<dd>>> >>>>agreement Spec 1, are NOT SUBJECT to
Consensus Policy"?
<dd>>> >>
<dd>>> >>Do you mean that the insertion of the PICs in Spec 1
was not
<dd>>> >>developed by a consensus process ( I would agree
)? Or that under
<dd>>> >>the current language of the proposal, the insertion
of the PICs is
<dd>>> >>the kind of action that ICANN would be permitted to
take without it
<dd>>> >>being subject to the consensus process (I don't
think I agree )?
<dd>>> >>
<dd>>> >>David
<dd>>> >>
<dd>>> >>
<dd>>> >>At 07:54 AM 11/12/2015, Alan Greenberg wrote:
<dd>>> >>
<dd>>> >>>I am increasingly becoming uneasy with the
implications of several
<dd>>> >>>of our proposed changes/powers. I would be happy
to be convinced
<dd>>> >>>that I am missing something and there is no need
to be concerned.
<dd>>> >>>
<dd>>> >>>The particular interaction that I am thinking of
is:
<dd>>> >>>
<dd>>> >>>- the new requirement that "policies"
be developed through a
<dd>>> >>>bottom-up multistakeholder process;
<dd>>> >>>
<dd>>> >>>- the fact that we never really define
"policy" and therefore what
<dd>>> >>>is a policy is subject to interpretation;
<dd>>> >>>
<dd>>> >>>- we have contracts which are made up of a
combination of
<dd>>> >>>historical language, negotiated terms, Consensus
Policy and yes,
<dd>>> >>>terms which at some point in time may have been
included through
<dd>>> >>>more arcane processes;
<dd>>> >>>
<dd>>> >>>- some issues which could reasonably considered
"policy", such as
<dd>>> >>>PICs in registry agreements, according to the
Registry agreement
<dd>>> >>>Spec 1, are NOT SUBJECT to Consensus Policy;
<dd>>> >>>
<dd>>> >>>- most contractual provisions are also outside
of the limited
<dd>>> >>>subjects in Spec 1 (Registry) / Spec 4
(Registrar);
<dd>>> >>>
<dd>>> >>>- The IRP which can judge something to be
outside of ICANN's mission;
<dd>>> >>>
<dd>>> >>>When you put these together, we have the
situation that an IRP
<dd>>> >>>could judge that some contractual provision is
"policy", was not
<dd>>> >>>developed through a bottom-up MS process, and
therefore violates
<dd>>> >>>the Bylaws. Yet such terms are not eligible for
a bottom-up MS
<dd>>> >>>process, or predate such processes.
<dd>>> >>>
<dd>>> >>>I find this EXTREMELY problematic.
<dd>>> >>>
<dd>>> >>>Alan
<dd>>> >>>
<dd>>> >>>_______________________________________________
<dd>>> >>>Accountability-Cross-Community mailing list
<dd>>>
>>><a href="mailto:Accountability-Cross-Community@icann.org">
Accountability-Cross-Community@icann.org</a>
<dd>>>
<dd>
>>>>><a href="https://urldefense.proofpoint.com/v2/url" eudora="autourl">
https://urldefense.proofpoint.com/v2/url</a>
?u=https-3A__mm.icann.org_mail
<dd>>>>>>ma
<dd>>>
<dd>>>>>>n_listinfo_accountability-2Dcross-2Dcomm
unity&d=CwICAg&c=MOptNlVtIETeD
<dd>>>>>>AL
<dd>>>
<dd>>>>>>C_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdY
ahOP8WDDkMr4k&m=He0ZyGdJIDc7wz
<dd>>>>>>sd
<dd>>>
<dd>>>>>>IRdFvJnAm7THjsagVk801BeQ4hE&s=HtbFOYAAV7
l0jaMecsuB8Y11DrNFSMO6Xc4C4cNB
<dd>>>>>>TJ
<dd>>> >>>8&e=
<dd>>> >>
<dd>>> >>*******************************
<dd>>> >>David G Post - Senior Fellow, Open Technology
Institute/New America
<dd>>> >>Foundation
<dd>>> >>blog (Volokh Conspiracy)
<dd>>>
<dd>>>>><a href="https://urldefense.proofpoint.com/v2/url">
https://urldefense.proofpoint.com/v2/url</a>?
u=http-3A__www.washingtonpost.
<dd>>>>>co
<dd>>>
<dd>>>>>m_people_david-2Dpost&d=CwICAg&c=MOptNlVt
IETeDALC_lULrw&r=62cJFOifzm6X_
<dd>>>>>GR
<dd>>>
<dd>>>>>laq8Mo8TjDmrxdYahOP8WDDkMr4k&m=He0ZyGdJID
c7wzsdIRdFvJnAm7THjsagVk801BeQ
<dd>>>>>4h
<dd>>>
>>E&s=Du760LWuQaX9-Rtg6INi7M4U1UdOwceKgmo_8WTqEXo&e=
<dd>>> >>book (Jefferson's Moose)
<dd>>>
<dd>>>>><a href="https://urldefense.proofpoint.com/v2/url">
https://urldefense.proofpoint.com/v2/url</a>?
u=http-3A__tinyurl.com_c327w2n
<dd>>>>>&d
<dd>>>
<dd>>>>>=CwICAg&c=MOptNlVtIETeDALC_lULrw&r=62cJFO
ifzm6X_GRlaq8Mo8TjDmrxdYahOP8W
<dd>>>>>DD
<dd>>>
<dd>>>>>kMr4k&m=He0ZyGdJIDc7wzsdIRdFvJnAm7THjsagV
k801BeQ4hE&s=KGa9_YOIKx24ypUgg
<dd>>>>>xm
<dd>>> >>2sdw-N8-55AfqtvPzjbBsU_s&e=
<dd>>> >>music
<dd>>>
<dd>>>>><a href="https://urldefense.proofpoint.com/v2/url">
https://urldefense.proofpoint.com/v2/url</a>?
u=http-3A__tinyurl.com_davidpo
<dd>>>>>st
<dd>>>
<dd>>>>>music&d=CwICAg&c=MOptNlVtIETeDALC_lULrw&r
=62cJFOifzm6X_GRlaq8Mo8TjDmrxd
<dd>>>>>Ya
<dd>>>
<dd>>>>>hOP8WDDkMr4k&m=He0ZyGdJIDc7wzsdIRdFvJnAm7
THjsagVk801BeQ4hE&s=k3sxcCisSp
<dd>>>>>zv
<dd>>> >>xkzLursRJem4WqQn3W-AAl8g9Du1glw&e=
publications
<dd>>> >>etc.
<dd>>>
<dd>>>>><a href="https://urldefense.proofpoint.com/v2/url">
https://urldefense.proofpoint.com/v2/url</a>?
u=<a href="http://http-3A__www.davidpost.com">
http-3A__www.davidpost.com</a>&d
<dd>>>>>=C
<dd>>>
<dd>>>>>wICAg&c=MOptNlVtIETeDALC_lULrw&r=62cJFOif
zm6X_GRlaq8Mo8TjDmrxdYahOP8WDD
<dd>>>>>kM
<dd>>>
<dd>>>>>r4k&m=He0ZyGdJIDc7wzsdIRdFvJnAm7THjsagVk8
01BeQ4hE&s=swRN-B4OyZhrqkSq2N3
<dd>>>>>Zm
<dd>>> >>gJTXXeioI4XPsyNyxfuSZM&e=
<dd>>> >>*******************************
<dd>>> >
<dd>>> >_______________________________________________
<dd>>> >Accountability-Cross-Community mailing list
<dd>>>
><a href="mailto:Accountability-Cross-Community@icann.org">
Accountability-Cross-Community@icann.org</a>
<dd>>>
<dd>
>>><a href="https://urldefense.proofpoint.com/v2/url?u" eudora="autourl">
https://urldefense.proofpoint.com/v2/url?u</a>
=https-3A__mm.icann.org_mailma
<dd>>>>n_
<dd>>>
<dd>>>>listinfo_accountability-2Dcross-2Dcommunit
y&d=CwICAg&c=MOptNlVtIETeDALC_
<dd>>>>lU
<dd>>>
<dd>>>>Lrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8W
DDkMr4k&m=He0ZyGdJIDc7wzsdIRdF
<dd>>>>vJ
<dd>>>
>nAm7THjsagVk801BeQ4hE&s=HtbFOYAAV7l0jaMecsuB8Y11DrNFSMO6Xc4C4cNBTJ8&e=
<dd>><br>
<br><br>
</dl>
</dl>
<dd>*******************************
<dd>David G Post - Senior Fellow, Open Technology Institute/New America
Foundation
<dd>blog (Volokh Conspiracy)
<a href="http://www.washingtonpost.com/people/david-post">
http://www.washingtonpost.com/people/david-post</a>
<dd>book (Jefferson's Moose)
<a href="http://tinyurl.com/c327w2n">http://tinyurl.com/c327w2n</a>
<dd>music
<a href="http://tinyurl.com/davidpostmusic">
http://tinyurl.com/davidpostmusic</a> publications etc.
<a href="http://www.davidpost.com">http://www.davidpost.com</a>
<dd>*******************************<br>
<br><br>
</dl>
</dl>
<dd>_______________________________________________
<dd>Accountability-Cross-Community mailing list
<dd><a href="mailto:Accountability-Cross-Community@icann.org">
Accountability-Cross-Community@icann.org</a>
<dd>
<a href="https://mm.icann.org/mailman/listinfo/accountability-cross-community" eudora="autourl">
https://mm.icann.org/mailman/listinfo/accountability-cross-community</a>
</dl></blockquote></body>
</html>