Re: [CCWG-ACCT] Implications of bottom-up "policy" requirement
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@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
******************************* 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 *******************************
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@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
******************************* 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 *******************************
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. / 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, 9:51 AM, "Alan Greenberg" <alan.greenberg@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@icann.org https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailma n_listinfo_accountability-2Dcross-2Dcommunity&d=CwICAg&c=MOptNlVtIETeDAL C_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=He0ZyGdJIDc7wzsd IRdFvJnAm7THjsagVk801BeQ4hE&s=HtbFOYAAV7l0jaMecsuB8Y11DrNFSMO6Xc4C4cNBTJ 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=He0ZyGdJIDc7wzsdIRdFvJnAm7THjsagVk801BeQ4h 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_GRlaq8Mo8TjDmrxdYahOP8WDD kMr4k&m=He0ZyGdJIDc7wzsdIRdFvJnAm7THjsagVk801BeQ4hE&s=KGa9_YOIKx24ypUggxm 2sdw-N8-55AfqtvPzjbBsU_s&e= music https://urldefense.proofpoint.com/v2/url?u=http-3A__tinyurl.com_davidpost music&d=CwICAg&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYa hOP8WDDkMr4k&m=He0ZyGdJIDc7wzsdIRdFvJnAm7THjsagVk801BeQ4hE&s=k3sxcCisSpzv 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_GRlaq8Mo8TjDmrxdYahOP8WDDkM r4k&m=He0ZyGdJIDc7wzsdIRdFvJnAm7THjsagVk801BeQ4hE&s=swRN-B4OyZhrqkSq2N3Zm gJTXXeioI4XPsyNyxfuSZM&e= *******************************
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_ listinfo_accountability-2Dcross-2Dcommunity&d=CwICAg&c=MOptNlVtIETeDALC_lU Lrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=He0ZyGdJIDc7wzsdIRdFvJ nAm7THjsagVk801BeQ4hE&s=HtbFOYAAV7l0jaMecsuB8Y11DrNFSMO6Xc4C4cNBTJ8&e=
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@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@icann.org https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailma n_listinfo_accountability-2Dcross-2Dcommunity&d=CwICAg&c=MOptNlVtIETeDAL C_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=He0ZyGdJIDc7wzsd IRdFvJnAm7THjsagVk801BeQ4hE&s=HtbFOYAAV7l0jaMecsuB8Y11DrNFSMO6Xc4C4cNBTJ 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=He0ZyGdJIDc7wzsdIRdFvJnAm7THjsagVk801BeQ4h 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_GRlaq8Mo8TjDmrxdYahOP8WDD kMr4k&m=He0ZyGdJIDc7wzsdIRdFvJnAm7THjsagVk801BeQ4hE&s=KGa9_YOIKx24ypUggxm 2sdw-N8-55AfqtvPzjbBsU_s&e= music https://urldefense.proofpoint.com/v2/url?u=http-3A__tinyurl.com_davidpost music&d=CwICAg&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYa hOP8WDDkMr4k&m=He0ZyGdJIDc7wzsdIRdFvJnAm7THjsagVk801BeQ4hE&s=k3sxcCisSpzv 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_GRlaq8Mo8TjDmrxdYahOP8WDDkM r4k&m=He0ZyGdJIDc7wzsdIRdFvJnAm7THjsagVk801BeQ4hE&s=swRN-B4OyZhrqkSq2N3Zm gJTXXeioI4XPsyNyxfuSZM&e= *******************************
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_ listinfo_accountability-2Dcross-2Dcommunity&d=CwICAg&c=MOptNlVtIETeDALC_lU Lrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=He0ZyGdJIDc7wzsdIRdFvJ nAm7THjsagVk801BeQ4hE&s=HtbFOYAAV7l0jaMecsuB8Y11DrNFSMO6Xc4C4cNBTJ8&e=
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@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@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@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@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=
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@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@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@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@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=
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 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@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@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@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@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=
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: "ICANNs 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 Internets 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@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@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@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@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 *******************************
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@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@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@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@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 *******************************
participants (4)
-
Alan Greenberg -
Burr, Becky -
David Post -
David Post