Re: [CCWG-ACCT] Additional Document for discussion
I have made a quick attempt to articulate the standard of behavior against which ICANN might be measured for accountability purposes. It roughly corresponds to the Mission Statement and Core Values in the ICANN bylaws today, but has some additions that and modifications consistent with various suggestions that I’ve heard from the group. If I missed your suggestion, please accept my apologies. This is just to start the discussion. J. Beckwith Burr Neustar, Inc. / Deputy General Counsel and Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington, DC 20006 Office: + 1.202.533.2932 Mobile: +1.202.352.6367 / becky.burr@neustar.biz<mailto:becky.burr@neustar.biz> / www.neustar.biz From: Alice Jansen <alice.jansen@icann.org<mailto:alice.jansen@icann.org>> Date: Monday, February 9, 2015 at 4:38 PM To: Accountability Community <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>> Subject: [CCWG-ACCT] Revised agenda - Meeting #11 Dear all, In anticipation of your meeting #11, please find attached a revised agenda. Thanks Best regards Alice
Becky, In your second slide, it says: „..Implementing Consensus Policies..”. Although I am not sure if this is supposed to mean that ICANN only implements policies for which there is consensus, the condition of having reached consensus before implementing policy is supposed to be a (high) standard of behavior that should be measured for accountability purposes Best, Roelof From: <Burr>, Becky Burr <Becky.Burr@neustar.biz<mailto:Becky.Burr@neustar.biz>> Date: maandag 9 februari 2015 17:03 To: Alice Jansen <alice.jansen@icann.org<mailto:alice.jansen@icann.org>>, "accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>" <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>> Subject: Re: [CCWG-ACCT] Additional Document for discussion I have made a quick attempt to articulate the standard of behavior against which ICANN might be measured for accountability purposes. It roughly corresponds to the Mission Statement and Core Values in the ICANN bylaws today, but has some additions that and modifications consistent with various suggestions that I’ve heard from the group. If I missed your suggestion, please accept my apologies. This is just to start the discussion. J. Beckwith Burr Neustar, Inc. / Deputy General Counsel and Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington, DC 20006 Office: + 1.202.533.2932 Mobile: +1.202.352.6367 / becky.burr@neustar.biz<mailto:becky.burr@neustar.biz> / www.neustar.biz From: Alice Jansen <alice.jansen@icann.org<mailto:alice.jansen@icann.org>> Date: Monday, February 9, 2015 at 4:38 PM To: Accountability Community <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>> Subject: [CCWG-ACCT] Revised agenda - Meeting #11 Dear all, In anticipation of your meeting #11, please find attached a revised agenda. Thanks Best regards Alice
Roelof: It occurs to me that you might not be clear on what "Consensus Policy" means in this context. "Consensus Policy" is a specifically defined term used in the ICANN Bylaws and defined in the gTLD Registry Agreement and Registrar Accreditation Agreement. (To the best of my knowledge, it is not used in the ccTLD context.) It refers to policy developed through the GNSO Policy Development Process, and specifically to policy which is meant to create binding obligations on gTLD registries and registrars. Consensus policy is developed by a Working Group, which must approve its recommendations by consensus of the Working Group (such consensus is "rough" consensus rather than "full" consensus). The potential Consensus Policy must then be approved by a GNSO Council Supermajority vote. If approved, it is a "PDP Recommendation. The PDP Recommendation then goes to the ICANN Board. The Board must then adopt the PDP Recommendation unless it is rejected by a 2/3 vote. The vote is supposed to take place "as soon as feasible, but preferably not later than the second meeting after receipt of a Board Report on the PDP Recommendation, prepared by an ICANN Staff Manager. I hope this helps you understand what is being discussed. Becky or others, please feel free to correct or clarify. In terms of measuring consensus, the Final Report of a PDP Working Group contains a record of the position of each participant with regard to consensus. I don't think there is any particular need for this Working Group to delve into GNSO PDP Working Group Procedures, at least not as a Work Stream 1 issue. I assume this was not what you were suggesting, in any event. There may be accountability issues relating to the Board's actions in approving consensus policy. For instance, I'm not sure if the Board ever approved or rejected certain PDP Recommendations relating to IGO/INGO identifiers that differed from GAC Policy Advice. These were before the Board for a vote on 30 April 2014, and the Board tried to broker a compromise, rather than directly face the issue of a "policy collision" between the GNSO and the GAC. In the interim, the GAC's "Advice" is in effect, not the GNSO's PDP Recommendation (in spite of the of the fact that the GNSO is supposed to be the source for GNSO policy). Hope this helps. Best regards, Greg On Mon, Feb 16, 2015 at 5:00 AM, Roelof Meijer <Roelof.Meijer@sidn.nl> wrote:
Becky,
In your second slide, it says: „..Implementing *Consensus* Policies..”. Although I am not sure if this is supposed to mean that ICANN *only* implements policies for which there is consensus, the condition of having reached consensus before implementing policy is supposed to be a (high) standard of behavior that should be measured for accountability purposes
Best,
Roelof
From: <Burr>, Becky Burr <Becky.Burr@neustar.biz> Date: maandag 9 februari 2015 17:03 To: Alice Jansen <alice.jansen@icann.org>, " accountability-cross-community@icann.org" < accountability-cross-community@icann.org> Subject: Re: [CCWG-ACCT] Additional Document for discussion
I have made a quick attempt to articulate the standard of behavior against which ICANN might be measured for accountability purposes. It roughly corresponds to the Mission Statement and Core Values in the ICANN bylaws today, but has some additions that and modifications consistent with various suggestions that I’ve heard from the group. If I missed your suggestion, please accept my apologies. This is just to start the discussion.
J. Beckwith Burr
*Neustar, Inc. /* Deputy General Counsel and Chief Privacy Officer
1775 Pennsylvania Avenue NW, Washington, DC 20006
Office: + 1.202.533.2932 Mobile: +1.202.352.6367 / becky.burr@neustar.biz / www.neustar.biz
From: Alice Jansen <alice.jansen@icann.org> Date: Monday, February 9, 2015 at 4:38 PM To: Accountability Community <accountability-cross-community@icann.org> Subject: [CCWG-ACCT] Revised agenda - Meeting #11
Dear all, In anticipation of your meeting #11, please find attached a revised agenda. Thanks Best regards Alice
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
-- *Gregory S. Shatan **ï* *Abelman Frayne & Schwab* *Partner* *| IP | Technology | Media | Internet* *666 Third Avenue | New York, NY 10017-5621* *Direct* 212-885-9253 *| **Main* 212-949-9022 *Fax* 212-949-9190 *|* *Cell *917-816-6428 *gsshatan@lawabel.com <gsshatan@lawabel.com>* *ICANN-related: gregshatanipc@gmail.com <gregshatanipc@gmail.com>* *www.lawabel.com <http://www.lawabel.com/>*
Just one addition – although the Bylaws are a little fuzzy on this point, Consensus Policy can only be developed to address issues that are within the “picket fence” - issues related to names and numbers that require/substantially benefit from coordination. Specification 1 in the Registrar Accreditation Agreement and the Registry Agreement lay this out. In other words, the “picket fence” limits ICANN’s ability to impose obligations on registries and registrars that are outside of its “mission." J. Beckwith Burr Neustar, Inc. / Deputy General Counsel and Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington, DC 20006 Office: + 1.202.533.2932 Mobile: +1.202.352.6367 / becky.burr@neustar.biz<mailto:becky.burr@neustar.biz> / www.neustar.biz From: Greg Shatan <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> Date: Monday, February 16, 2015 at 1:51 PM To: Roelof Meijer <Roelof.Meijer@sidn.nl<mailto:Roelof.Meijer@sidn.nl>> Cc: Becky Burr <becky.burr@neustar.biz<mailto:becky.burr@neustar.biz>>, Alice Jansen <alice.jansen@icann.org<mailto:alice.jansen@icann.org>>, Accountability Community <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>> Subject: Re: [CCWG-ACCT] Additional Document for discussion Roelof: It occurs to me that you might not be clear on what "Consensus Policy" means in this context. "Consensus Policy" is a specifically defined term used in the ICANN Bylaws and defined in the gTLD Registry Agreement and Registrar Accreditation Agreement. (To the best of my knowledge, it is not used in the ccTLD context.) It refers to policy developed through the GNSO Policy Development Process, and specifically to policy which is meant to create binding obligations on gTLD registries and registrars. Consensus policy is developed by a Working Group, which must approve its recommendations by consensus of the Working Group (such consensus is "rough" consensus rather than "full" consensus). The potential Consensus Policy must then be approved by a GNSO Council Supermajority vote. If approved, it is a "PDP Recommendation. The PDP Recommendation then goes to the ICANN Board. The Board must then adopt the PDP Recommendation unless it is rejected by a 2/3 vote. The vote is supposed to take place "as soon as feasible, but preferably not later than the second meeting after receipt of a Board Report on the PDP Recommendation, prepared by an ICANN Staff Manager. I hope this helps you understand what is being discussed. Becky or others, please feel free to correct or clarify. In terms of measuring consensus, the Final Report of a PDP Working Group contains a record of the position of each participant with regard to consensus. I don't think there is any particular need for this Working Group to delve into GNSO PDP Working Group Procedures, at least not as a Work Stream 1 issue. I assume this was not what you were suggesting, in any event. There may be accountability issues relating to the Board's actions in approving consensus policy. For instance, I'm not sure if the Board ever approved or rejected certain PDP Recommendations relating to IGO/INGO identifiers that differed from GAC Policy Advice. These were before the Board for a vote on 30 April 2014, and the Board tried to broker a compromise, rather than directly face the issue of a "policy collision" between the GNSO and the GAC. In the interim, the GAC's "Advice" is in effect, not the GNSO's PDP Recommendation (in spite of the of the fact that the GNSO is supposed to be the source for GNSO policy). Hope this helps. Best regards, Greg On Mon, Feb 16, 2015 at 5:00 AM, Roelof Meijer <Roelof.Meijer@sidn.nl<mailto:Roelof.Meijer@sidn.nl>> wrote: Becky, In your second slide, it says: „..Implementing Consensus Policies..”. Although I am not sure if this is supposed to mean that ICANN only implements policies for which there is consensus, the condition of having reached consensus before implementing policy is supposed to be a (high) standard of behavior that should be measured for accountability purposes Best, Roelof From: <Burr>, Becky Burr <Becky.Burr@neustar.biz<mailto:Becky.Burr@neustar.biz>> Date: maandag 9 februari 2015 17:03 To: Alice Jansen <alice.jansen@icann.org<mailto:alice.jansen@icann.org>>, "accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>" <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>> Subject: Re: [CCWG-ACCT] Additional Document for discussion I have made a quick attempt to articulate the standard of behavior against which ICANN might be measured for accountability purposes. It roughly corresponds to the Mission Statement and Core Values in the ICANN bylaws today, but has some additions that and modifications consistent with various suggestions that I’ve heard from the group. If I missed your suggestion, please accept my apologies. This is just to start the discussion. J. Beckwith Burr Neustar, Inc. / Deputy General Counsel and Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington, DC 20006 Office: + 1.202.533.2932<tel:%2B%201.202.533.2932> Mobile: +1.202.352.6367<tel:%2B1.202.352.6367> / becky.burr@neustar.biz<mailto:becky.burr@neustar.biz> / www.neustar.biz<http://www.neustar.biz> From: Alice Jansen <alice.jansen@icann.org<mailto:alice.jansen@icann.org>> Date: Monday, February 9, 2015 at 4:38 PM To: Accountability Community <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>> Subject: [CCWG-ACCT] Revised agenda - Meeting #11 Dear all, In anticipation of your meeting #11, please find attached a revised agenda. Thanks Best regards Alice _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_accountability-2Dcross-2Dcommunity&d=AwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=rDPIYjv2QmqDrpDLHQiM9f65BC91FCOW0Kz7XR4d5es&s=W8eIliVQDJE7JKhqSmXPRvyYjnLFbgM1qUe5RRqV1kM&e=> -- Gregory S. Shatan ï Abelman Frayne & Schwab Partner | IP | Technology | Media | Internet 666 Third Avenue | New York, NY 10017-5621 Direct 212-885-9253 | Main 212-949-9022 Fax 212-949-9190 | Cell 917-816-6428 gsshatan@lawabel.com<mailto:gsshatan@lawabel.com> ICANN-related: gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com> www.lawabel.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lawabel.com_&d=AwMFa...>
Just one addition – although the Bylaws are a little fuzzy on this point, Consensus Policy can only be developed to address issues that are within the “picket fence” - issues related to names and numbers that require/substantially benefit from coordination. Specification 1 in the Registrar Accreditation Agreement and the Registry Agreement lay this out. In other words, the “picket fence” limits ICANN’s ability to impose obligations on registries and registrars that are outside of its “mission."
To complicate further the GNSO can recommend by consensus that ICANN adopt policies that relate to generic top-level domains that don’t directly relate to an existing registry/registrar contract. The policy on new gTLDs is example. The consensus policies within a picket fence require existing registries and registrars to comply with the new policy – e.g. registrar to registrar transfers policies. Regards, Bruce Tonkin
Actually Bruce, I think the new gTLD policy is within the Picket Fence (naming issue that requires or is substantially benefitted by coordination). ICANN does not have a legal right to impose obligations on the contracted parties related to stuff that is outside the PF. But the lines have been muddied from time to time. I would argue that the stability and security review provided for in the RSEP policies is within the PF, but the competition prong of that review is outside the PF. J. Beckwith Burr Neustar, Inc. / Deputy General Counsel and Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington, DC 20006 Office: + 1.202.533.2932 Mobile: +1.202.352.6367 / becky.burr@neustar.biz / www.neustar.biz On 2/17/15, 3:08 AM, "Bruce Tonkin" <Bruce.Tonkin@melbourneit.com.au> wrote:
Just one addition although the Bylaws are a little fuzzy on this point, Consensus Policy can only be developed to address issues that are within the ³picket fence² - issues related to names and numbers that require/substantially benefit from coordination. Specification 1 in the Registrar Accreditation Agreement and the Registry Agreement lay this out. In other words, the ³picket fence² limits ICANN¹s ability to impose obligations on registries and registrars that are outside of its ³mission."
To complicate further the GNSO can recommend by consensus that ICANN adopt policies that relate to generic top-level domains that don¹t directly relate to an existing registry/registrar contract. The policy on new gTLDs is example.
The consensus policies within a picket fence require existing registries and registrars to comply with the new policy e.g. registrar to registrar transfers policies.
Regards,
Bruce Tonkin
Although the competition prong is fairly soft - it just refers the matter to a competition authority . As far as I know ICANN itself doesn't rule on that. Regards, Bruce Tonkin -----Original Message----- From: Burr, Becky [mailto:Becky.Burr@neustar.biz] Sent: Wednesday, 18 February 2015 11:35 AM To: Bruce Tonkin; Greg Shatan; Roelof Meijer Cc: accountability-cross-community@icann.org Subject: Re: [CCWG-ACCT] Additional Document for discussion Actually Bruce, I think the new gTLD policy is within the Picket Fence (naming issue that requires or is substantially benefitted by coordination). ICANN does not have a legal right to impose obligations on the contracted parties related to stuff that is outside the PF. But the lines have been muddied from time to time. I would argue that the stability and security review provided for in the RSEP policies is within the PF, but the competition prong of that review is outside the PF. J. Beckwith Burr Neustar, Inc. / Deputy General Counsel and Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington, DC 20006 Office: + 1.202.533.2932 Mobile: +1.202.352.6367 / becky.burr@neustar.biz / www.neustar.biz On 2/17/15, 3:08 AM, "Bruce Tonkin" <Bruce.Tonkin@melbourneit.com.au> wrote:
Just one addition although the Bylaws are a little fuzzy on this point, Consensus Policy can only be developed to address issues that are within the ³picket fence² - issues related to names and numbers that require/substantially benefit from coordination. Specification 1 in the Registrar Accreditation Agreement and the Registry Agreement lay this out. In other words, the ³picket fence² limits ICANN¹s ability to impose obligations on registries and registrars that are outside of its ³mission."
To complicate further the GNSO can recommend by consensus that ICANN adopt policies that relate to generic top-level domains that don¹t directly relate to an existing registry/registrar contract. The policy on new gTLDs is example.
The consensus policies within a picket fence require existing registries and registrars to comply with the new policy e.g. registrar to registrar transfers policies.
Regards,
Bruce Tonkin
Hi Becky- Is the picket fence established by the bylaws or via the contracts? I ask because for many years prior to the 2013 RAA the registrar agreements lacked this concept... Thanks- J. Sent via iPhone. Blame Siri. On Feb 16, 2015, at 15:45, Burr, Becky <Becky.Burr@neustar.biz<mailto:Becky.Burr@neustar.biz>> wrote: Just one addition – although the Bylaws are a little fuzzy on this point, Consensus Policy can only be developed to address issues that are within the “picket fence” - issues related to names and numbers that require/substantially benefit from coordination. Specification 1 in the Registrar Accreditation Agreement and the Registry Agreement lay this out. In other words, the “picket fence” limits ICANN’s ability to impose obligations on registries and registrars that are outside of its “mission." J. Beckwith Burr Neustar, Inc. / Deputy General Counsel and Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington, DC 20006 Office: + 1.202.533.2932 Mobile: +1.202.352.6367 / becky.burr@neustar.biz<mailto:becky.burr@neustar.biz> / www.neustar.biz<http://www.neustar.biz> From: Greg Shatan <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> Date: Monday, February 16, 2015 at 1:51 PM To: Roelof Meijer <Roelof.Meijer@sidn.nl<mailto:Roelof.Meijer@sidn.nl>> Cc: Becky Burr <becky.burr@neustar.biz<mailto:becky.burr@neustar.biz>>, Alice Jansen <alice.jansen@icann.org<mailto:alice.jansen@icann.org>>, Accountability Community <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>> Subject: Re: [CCWG-ACCT] Additional Document for discussion Roelof: It occurs to me that you might not be clear on what "Consensus Policy" means in this context. "Consensus Policy" is a specifically defined term used in the ICANN Bylaws and defined in the gTLD Registry Agreement and Registrar Accreditation Agreement. (To the best of my knowledge, it is not used in the ccTLD context.) It refers to policy developed through the GNSO Policy Development Process, and specifically to policy which is meant to create binding obligations on gTLD registries and registrars. Consensus policy is developed by a Working Group, which must approve its recommendations by consensus of the Working Group (such consensus is "rough" consensus rather than "full" consensus). The potential Consensus Policy must then be approved by a GNSO Council Supermajority vote. If approved, it is a "PDP Recommendation. The PDP Recommendation then goes to the ICANN Board. The Board must then adopt the PDP Recommendation unless it is rejected by a 2/3 vote. The vote is supposed to take place "as soon as feasible, but preferably not later than the second meeting after receipt of a Board Report on the PDP Recommendation, prepared by an ICANN Staff Manager. I hope this helps you understand what is being discussed. Becky or others, please feel free to correct or clarify. In terms of measuring consensus, the Final Report of a PDP Working Group contains a record of the position of each participant with regard to consensus. I don't think there is any particular need for this Working Group to delve into GNSO PDP Working Group Procedures, at least not as a Work Stream 1 issue. I assume this was not what you were suggesting, in any event. There may be accountability issues relating to the Board's actions in approving consensus policy. For instance, I'm not sure if the Board ever approved or rejected certain PDP Recommendations relating to IGO/INGO identifiers that differed from GAC Policy Advice. These were before the Board for a vote on 30 April 2014, and the Board tried to broker a compromise, rather than directly face the issue of a "policy collision" between the GNSO and the GAC. In the interim, the GAC's "Advice" is in effect, not the GNSO's PDP Recommendation (in spite of the of the fact that the GNSO is supposed to be the source for GNSO policy). Hope this helps. Best regards, Greg On Mon, Feb 16, 2015 at 5:00 AM, Roelof Meijer <Roelof.Meijer@sidn.nl<mailto:Roelof.Meijer@sidn.nl>> wrote: Becky, In your second slide, it says: „..Implementing Consensus Policies..”. Although I am not sure if this is supposed to mean that ICANN only implements policies for which there is consensus, the condition of having reached consensus before implementing policy is supposed to be a (high) standard of behavior that should be measured for accountability purposes Best, Roelof From: <Burr>, Becky Burr <Becky.Burr@neustar.biz<mailto:Becky.Burr@neustar.biz>> Date: maandag 9 februari 2015 17:03 To: Alice Jansen <alice.jansen@icann.org<mailto:alice.jansen@icann.org>>, "accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>" <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>> Subject: Re: [CCWG-ACCT] Additional Document for discussion I have made a quick attempt to articulate the standard of behavior against which ICANN might be measured for accountability purposes. It roughly corresponds to the Mission Statement and Core Values in the ICANN bylaws today, but has some additions that and modifications consistent with various suggestions that I’ve heard from the group. If I missed your suggestion, please accept my apologies. This is just to start the discussion. J. Beckwith Burr Neustar, Inc. / Deputy General Counsel and Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington, DC 20006 Office: + 1.202.533.2932<tel:%2B%201.202.533.2932> Mobile: +1.202.352.6367<tel:%2B1.202.352.6367> / becky.burr@neustar.biz<mailto:becky.burr@neustar.biz> / www.neustar.biz<http://www.neustar.biz> From: Alice Jansen <alice.jansen@icann.org<mailto:alice.jansen@icann.org>> Date: Monday, February 9, 2015 at 4:38 PM To: Accountability Community <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>> Subject: [CCWG-ACCT] Revised agenda - Meeting #11 Dear all, In anticipation of your meeting #11, please find attached a revised agenda. Thanks Best regards Alice _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_accountability-2Dcross-2Dcommunity&d=AwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=rDPIYjv2QmqDrpDLHQiM9f65BC91FCOW0Kz7XR4d5es&s=W8eIliVQDJE7JKhqSmXPRvyYjnLFbgM1qUe5RRqV1kM&e=> -- Gregory S. Shatan ï Abelman Frayne & Schwab Partner | IP | Technology | Media | Internet 666 Third Avenue | New York, NY 10017-5621 Direct 212-885-9253 | Main 212-949-9022 Fax 212-949-9190 | Cell 917-816-6428 gsshatan@lawabel.com<mailto:gsshatan@lawabel.com> ICANN-related: gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com> www.lawabel.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lawabel.com_&d=AwMFa...> _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community
The picket fence was initially established through the registry agreement. The RAA actually had a muddier picket fence, which we tried to clean up in the RAA negotiations. The bylaws talk about “Consensus Policies” but doesn’t currently reflect the Picket Fence. J. Beckwith Burr Neustar, Inc. / Deputy General Counsel and Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington, DC 20006 Office: + 1.202.533.2932 Mobile: +1.202.352.6367 / becky.burr@neustar.biz<mailto:becky.burr@neustar.biz> / www.neustar.biz From: James Bladel <jbladel@godaddy.com<mailto:jbladel@godaddy.com>> Date: Tuesday, February 17, 2015 at 7:14 PM To: Becky Burr <becky.burr@neustar.biz<mailto:becky.burr@neustar.biz>> Cc: Greg Shatan <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>>, Roelof Meijer <Roelof.Meijer@sidn.nl<mailto:Roelof.Meijer@sidn.nl>>, Accountability Community <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>> Subject: Re: [CCWG-ACCT] Additional Document for discussion Hi Becky- Is the picket fence established by the bylaws or via the contracts? I ask because for many years prior to the 2013 RAA the registrar agreements lacked this concept... Thanks- J. Sent via iPhone. Blame Siri. On Feb 16, 2015, at 15:45, Burr, Becky <Becky.Burr@neustar.biz<mailto:Becky.Burr@neustar.biz>> wrote: Just one addition – although the Bylaws are a little fuzzy on this point, Consensus Policy can only be developed to address issues that are within the “picket fence” - issues related to names and numbers that require/substantially benefit from coordination. Specification 1 in the Registrar Accreditation Agreement and the Registry Agreement lay this out. In other words, the “picket fence” limits ICANN’s ability to impose obligations on registries and registrars that are outside of its “mission." J. Beckwith Burr Neustar, Inc. / Deputy General Counsel and Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington, DC 20006 Office: + 1.202.533.2932 Mobile: +1.202.352.6367 / becky.burr@neustar.biz<mailto:becky.burr@neustar.biz> / www.neustar.biz<http://www.neustar.biz> From: Greg Shatan <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> Date: Monday, February 16, 2015 at 1:51 PM To: Roelof Meijer <Roelof.Meijer@sidn.nl<mailto:Roelof.Meijer@sidn.nl>> Cc: Becky Burr <becky.burr@neustar.biz<mailto:becky.burr@neustar.biz>>, Alice Jansen <alice.jansen@icann.org<mailto:alice.jansen@icann.org>>, Accountability Community <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>> Subject: Re: [CCWG-ACCT] Additional Document for discussion Roelof: It occurs to me that you might not be clear on what "Consensus Policy" means in this context. "Consensus Policy" is a specifically defined term used in the ICANN Bylaws and defined in the gTLD Registry Agreement and Registrar Accreditation Agreement. (To the best of my knowledge, it is not used in the ccTLD context.) It refers to policy developed through the GNSO Policy Development Process, and specifically to policy which is meant to create binding obligations on gTLD registries and registrars. Consensus policy is developed by a Working Group, which must approve its recommendations by consensus of the Working Group (such consensus is "rough" consensus rather than "full" consensus). The potential Consensus Policy must then be approved by a GNSO Council Supermajority vote. If approved, it is a "PDP Recommendation. The PDP Recommendation then goes to the ICANN Board. The Board must then adopt the PDP Recommendation unless it is rejected by a 2/3 vote. The vote is supposed to take place "as soon as feasible, but preferably not later than the second meeting after receipt of a Board Report on the PDP Recommendation, prepared by an ICANN Staff Manager. I hope this helps you understand what is being discussed. Becky or others, please feel free to correct or clarify. In terms of measuring consensus, the Final Report of a PDP Working Group contains a record of the position of each participant with regard to consensus. I don't think there is any particular need for this Working Group to delve into GNSO PDP Working Group Procedures, at least not as a Work Stream 1 issue. I assume this was not what you were suggesting, in any event. There may be accountability issues relating to the Board's actions in approving consensus policy. For instance, I'm not sure if the Board ever approved or rejected certain PDP Recommendations relating to IGO/INGO identifiers that differed from GAC Policy Advice. These were before the Board for a vote on 30 April 2014, and the Board tried to broker a compromise, rather than directly face the issue of a "policy collision" between the GNSO and the GAC. In the interim, the GAC's "Advice" is in effect, not the GNSO's PDP Recommendation (in spite of the of the fact that the GNSO is supposed to be the source for GNSO policy). Hope this helps. Best regards, Greg On Mon, Feb 16, 2015 at 5:00 AM, Roelof Meijer <Roelof.Meijer@sidn.nl<mailto:Roelof.Meijer@sidn.nl>> wrote: Becky, In your second slide, it says: „..Implementing Consensus Policies..”. Although I am not sure if this is supposed to mean that ICANN only implements policies for which there is consensus, the condition of having reached consensus before implementing policy is supposed to be a (high) standard of behavior that should be measured for accountability purposes Best, Roelof From: <Burr>, Becky Burr <Becky.Burr@neustar.biz<mailto:Becky.Burr@neustar.biz>> Date: maandag 9 februari 2015 17:03 To: Alice Jansen <alice.jansen@icann.org<mailto:alice.jansen@icann.org>>, "accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>" <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>> Subject: Re: [CCWG-ACCT] Additional Document for discussion I have made a quick attempt to articulate the standard of behavior against which ICANN might be measured for accountability purposes. It roughly corresponds to the Mission Statement and Core Values in the ICANN bylaws today, but has some additions that and modifications consistent with various suggestions that I’ve heard from the group. If I missed your suggestion, please accept my apologies. This is just to start the discussion. J. Beckwith Burr Neustar, Inc. / Deputy General Counsel and Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington, DC 20006 Office: + 1.202.533.2932<tel:%2B%201.202.533.2932> Mobile: +1.202.352.6367<tel:%2B1.202.352.6367> / becky.burr@neustar.biz<mailto:becky.burr@neustar.biz> / www.neustar.biz<http://www.neustar.biz> From: Alice Jansen <alice.jansen@icann.org<mailto:alice.jansen@icann.org>> Date: Monday, February 9, 2015 at 4:38 PM To: Accountability Community <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>> Subject: [CCWG-ACCT] Revised agenda - Meeting #11 Dear all, In anticipation of your meeting #11, please find attached a revised agenda. Thanks Best regards Alice _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_accountability-2Dcross-2Dcommunity&d=AwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=rDPIYjv2QmqDrpDLHQiM9f65BC91FCOW0Kz7XR4d5es&s=W8eIliVQDJE7JKhqSmXPRvyYjnLFbgM1qUe5RRqV1kM&e=> -- Gregory S. Shatan ï Abelman Frayne & Schwab Partner | IP | Technology | Media | Internet 666 Third Avenue | New York, NY 10017-5621 Direct 212-885-9253 | Main 212-949-9022 Fax 212-949-9190 | Cell 917-816-6428 gsshatan@lawabel.com<mailto:gsshatan@lawabel.com> ICANN-related: gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com> www.lawabel.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lawabel.com_&d=AwMFa...> _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_accountability-2Dcross-2Dcommunity&d=AwMF-g&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=QfJoxnDXpV-lLt2n6EohIK-l7ajL-924ifQaLb43PEA&s=g8OQ9-EN8XRyZYxNU5sOlvmGuMYjdx-hNaYqML3Pnto&e=>
Dear All The treatment and processing of gTLD is quite different from that if ccTLD There seems inappropriate to treat these two entirely different issues in the same manner. Kavouss Sent from my iPhone
On 16 Feb 2015, at 19:51, Greg Shatan <gregshatanipc@gmail.com> wrote:
Roelof:
It occurs to me that you might not be clear on what "Consensus Policy" means in this context.
"Consensus Policy" is a specifically defined term used in the ICANN Bylaws and defined in the gTLD Registry Agreement and Registrar Accreditation Agreement. (To the best of my knowledge, it is not used in the ccTLD context.) It refers to policy developed through the GNSO Policy Development Process, and specifically to policy which is meant to create binding obligations on gTLD registries and registrars. Consensus policy is developed by a Working Group, which must approve its recommendations by consensus of the Working Group (such consensus is "rough" consensus rather than "full" consensus). The potential Consensus Policy must then be approved by a GNSO Council Supermajority vote. If approved, it is a "PDP Recommendation. The PDP Recommendation then goes to the ICANN Board. The Board must then adopt the PDP Recommendation unless it is rejected by a 2/3 vote. The vote is supposed to take place "as soon as feasible, but preferably not later than the second meeting after receipt of a Board Report on the PDP Recommendation, prepared by an ICANN Staff Manager.
I hope this helps you understand what is being discussed. Becky or others, please feel free to correct or clarify.
In terms of measuring consensus, the Final Report of a PDP Working Group contains a record of the position of each participant with regard to consensus. I don't think there is any particular need for this Working Group to delve into GNSO PDP Working Group Procedures, at least not as a Work Stream 1 issue. I assume this was not what you were suggesting, in any event.
There may be accountability issues relating to the Board's actions in approving consensus policy. For instance, I'm not sure if the Board ever approved or rejected certain PDP Recommendations relating to IGO/INGO identifiers that differed from GAC Policy Advice. These were before the Board for a vote on 30 April 2014, and the Board tried to broker a compromise, rather than directly face the issue of a "policy collision" between the GNSO and the GAC. In the interim, the GAC's "Advice" is in effect, not the GNSO's PDP Recommendation (in spite of the of the fact that the GNSO is supposed to be the source for GNSO policy).
Hope this helps.
Best regards,
Greg
On Mon, Feb 16, 2015 at 5:00 AM, Roelof Meijer <Roelof.Meijer@sidn.nl> wrote: Becky,
In your second slide, it says: „..Implementing Consensus Policies..”. Although I am not sure if this is supposed to mean that ICANN only implements policies for which there is consensus, the condition of having reached consensus before implementing policy is supposed to be a (high) standard of behavior that should be measured for accountability purposes
Best,
Roelof
From: <Burr>, Becky Burr <Becky.Burr@neustar.biz> Date: maandag 9 februari 2015 17:03 To: Alice Jansen <alice.jansen@icann.org>, "accountability-cross-community@icann.org" <accountability-cross-community@icann.org> Subject: Re: [CCWG-ACCT] Additional Document for discussion
I have made a quick attempt to articulate the standard of behavior against which ICANN might be measured for accountability purposes. It roughly corresponds to the Mission Statement and Core Values in the ICANN bylaws today, but has some additions that and modifications consistent with various suggestions that I’ve heard from the group. If I missed your suggestion, please accept my apologies. This is just to start the discussion.
J. Beckwith Burr Neustar, Inc. / Deputy General Counsel and Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington, DC 20006 Office: + 1.202.533.2932 Mobile: +1.202.352.6367 / becky.burr@neustar.biz / www.neustar.biz
From: Alice Jansen <alice.jansen@icann.org> Date: Monday, February 9, 2015 at 4:38 PM To: Accountability Community <accountability-cross-community@icann.org> Subject: [CCWG-ACCT] Revised agenda - Meeting #11
Dear all, In anticipation of your meeting #11, please find attached a revised agenda. Thanks Best regards Alice
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
-- Gregory S. Shatan ï Abelman Frayne & Schwab Partner | IP | Technology | Media | Internet 666 Third Avenue | New York, NY 10017-5621 Direct 212-885-9253 | Main 212-949-9022 Fax 212-949-9190 | Cell 917-816-6428 gsshatan@lawabel.com ICANN-related: gregshatanipc@gmail.com www.lawabel.com _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Dear Mr Arasteh, I fully agree with your below statement, but would go a little further, in that even in a multi stakeholder environment, stakeholders have their "stakes". Now, as example, you and I disagree on whether states have sovereignty over the corresponding ccTLDS, which we might even be able to reconcile under the 2005 GAC Principles' existing rights grandfather clause, but the concept of Significantly Interested Party ("SIP"), recently introduced by the FoI Principles is helpful. We can all agree that individual governments most certainly are (at least) SIP concerning the corresponding ccTLD. Whatever that eventually means, and in the FoI Principles it only pertains to the selection of a ccTLD manager, either after a revocation or at (new) delegation, but not with regards to the revocation itself. The Namibian government ("GRN") has most certainly a Significant Interest in the management of .NA (from a Public Policy perspective) but, while perhaps interested in other ccTLDs, does not have a Significant Interest in them, as its Public Policy applies only to Namibia. The GRN may have some Significant Interest in .AFRICA, and while it may have an interest in a (hypothetical) .TEHERAN, it may not have a Significant Interest there. Generally speaking, ALAC and/or GNSO constituents may have an interest in one or more ccTLDs but they most definitively are not SIP. I, as most, if not all ccTLD managers, generally keep out of ALAC with the possible exception of AfrICANN (given my technical and outreach expertise I might, or not, be SIP) and out of GNSO, though I share some interests with the Registry Community, in particular technical, which would raise to the level of SIP, unless policies were developed that affected all TLD Managers crossing the two constituencies). This must be reflected in both the Accountability but also Transition proposals. greetings, el -- Sent from Dr Lisse's iPad mini
On Feb 17, 2015, at 09:23, Kavouss Arasteh <kavouss.arasteh@gmail.com> wrote:
Dear All The treatment and processing of gTLD is quite different from that if ccTLD There seems inappropriate to treat these two entirely different issues in the same manner. Kavouss
Sent from my iPhone
On 16 Feb 2015, at 19:51, Greg Shatan <gregshatanipc@gmail.com> wrote:
Roelof:
It occurs to me that you might not be clear on what "Consensus Policy" means in this context.
"Consensus Policy" is a specifically defined term used in the ICANN Bylaws and defined in the gTLD Registry Agreement and Registrar Accreditation Agreement. (To the best of my knowledge, it is not used in the ccTLD context.) It refers to policy developed through the GNSO Policy Development Process, and specifically to policy which is meant to create binding obligations on gTLD registries and registrars. Consensus policy is developed by a Working Group, which must approve its recommendations by consensus of the Working Group (such consensus is "rough" consensus rather than "full" consensus). The potential Consensus Policy must then be approved by a GNSO Council Supermajority vote. If approved, it is a "PDP Recommendation. The PDP Recommendation then goes to the ICANN Board. The Board must then adopt the PDP Recommendation unless it is rejected by a 2/3 vote. The vote is supposed to take place "as soon as feasible, but preferably not later than the second meeting after receipt of a Board Report on the PDP Recommendation, prepared by an ICANN Staff Manager.
I hope this helps you understand what is being discussed. Becky or others, please feel free to correct or clarify.
In terms of measuring consensus, the Final Report of a PDP Working Group contains a record of the position of each participant with regard to consensus. I don't think there is any particular need for this Working Group to delve into GNSO PDP Working Group Procedures, at least not as a Work Stream 1 issue. I assume this was not what you were suggesting, in any event.
There may be accountability issues relating to the Board's actions in approving consensus policy. For instance, I'm not sure if the Board ever approved or rejected certain PDP Recommendations relating to IGO/INGO identifiers that differed from GAC Policy Advice. These were before the Board for a vote on 30 April 2014, and the Board tried to broker a compromise, rather than directly face the issue of a "policy collision" between the GNSO and the GAC. In the interim, the GAC's "Advice" is in effect, not the GNSO's PDP Recommendation (in spite of the of the fact that the GNSO is supposed to be the source for GNSO policy).
Hope this helps.
Best regards,
Greg
[...]
Apologies for the late response, Greg, and it sure helps. I indeed thought we were considering consensus here to be the common understanding of consensus („full” as you call it) and not the ICANN bylaws version („rough”). That clarified, I wonder what we should do in general. The mechanisms template that we are working with, has a field under „Decision making” to be completed that states: "Decision made by consensus or vote ?”. When doing my WP1 homework, I considered consensus there to mean „full consensus”, the general definition so to speak. So, in our work, in general if we talk about consensus, do we use the general definition, or the ICANN bylaws one? I suggest we use the general one as starting point and clearly indicate if for some reason we use the ICANN bylaws one Cheers, Roelof From: Greg Shatan <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> Date: maandag 16 februari 2015 19:51 To: Roelof Meijer <roelof.meijer@sidn.nl<mailto:roelof.meijer@sidn.nl>> Cc: Becky Burr <Becky.Burr@neustar.biz<mailto:Becky.Burr@neustar.biz>>, Alice Jansen <alice.jansen@icann.org<mailto:alice.jansen@icann.org>>, "accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>" <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>> Subject: Re: [CCWG-ACCT] Additional Document for discussion Roelof: It occurs to me that you might not be clear on what "Consensus Policy" means in this context. "Consensus Policy" is a specifically defined term used in the ICANN Bylaws and defined in the gTLD Registry Agreement and Registrar Accreditation Agreement. (To the best of my knowledge, it is not used in the ccTLD context.) It refers to policy developed through the GNSO Policy Development Process, and specifically to policy which is meant to create binding obligations on gTLD registries and registrars. Consensus policy is developed by a Working Group, which must approve its recommendations by consensus of the Working Group (such consensus is "rough" consensus rather than "full" consensus). The potential Consensus Policy must then be approved by a GNSO Council Supermajority vote. If approved, it is a "PDP Recommendation. The PDP Recommendation then goes to the ICANN Board. The Board must then adopt the PDP Recommendation unless it is rejected by a 2/3 vote. The vote is supposed to take place "as soon as feasible, but preferably not later than the second meeting after receipt of a Board Report on the PDP Recommendation, prepared by an ICANN Staff Manager. I hope this helps you understand what is being discussed. Becky or others, please feel free to correct or clarify. In terms of measuring consensus, the Final Report of a PDP Working Group contains a record of the position of each participant with regard to consensus. I don't think there is any particular need for this Working Group to delve into GNSO PDP Working Group Procedures, at least not as a Work Stream 1 issue. I assume this was not what you were suggesting, in any event. There may be accountability issues relating to the Board's actions in approving consensus policy. For instance, I'm not sure if the Board ever approved or rejected certain PDP Recommendations relating to IGO/INGO identifiers that differed from GAC Policy Advice. These were before the Board for a vote on 30 April 2014, and the Board tried to broker a compromise, rather than directly face the issue of a "policy collision" between the GNSO and the GAC. In the interim, the GAC's "Advice" is in effect, not the GNSO's PDP Recommendation (in spite of the of the fact that the GNSO is supposed to be the source for GNSO policy). Hope this helps. Best regards, Greg On Mon, Feb 16, 2015 at 5:00 AM, Roelof Meijer <Roelof.Meijer@sidn.nl<mailto:Roelof.Meijer@sidn.nl>> wrote: Becky, In your second slide, it says: „..Implementing Consensus Policies..”. Although I am not sure if this is supposed to mean that ICANN only implements policies for which there is consensus, the condition of having reached consensus before implementing policy is supposed to be a (high) standard of behavior that should be measured for accountability purposes Best, Roelof From: <Burr>, Becky Burr <Becky.Burr@neustar.biz<mailto:Becky.Burr@neustar.biz>> Date: maandag 9 februari 2015 17:03 To: Alice Jansen <alice.jansen@icann.org<mailto:alice.jansen@icann.org>>, "accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>" <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>> Subject: Re: [CCWG-ACCT] Additional Document for discussion I have made a quick attempt to articulate the standard of behavior against which ICANN might be measured for accountability purposes. It roughly corresponds to the Mission Statement and Core Values in the ICANN bylaws today, but has some additions that and modifications consistent with various suggestions that I’ve heard from the group. If I missed your suggestion, please accept my apologies. This is just to start the discussion. J. Beckwith Burr Neustar, Inc. / Deputy General Counsel and Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington, DC 20006 Office: + 1.202.533.2932<tel:%2B%201.202.533.2932> Mobile: +1.202.352.6367<tel:%2B1.202.352.6367> / becky.burr@neustar.biz<mailto:becky.burr@neustar.biz> / www.neustar.biz<http://www.neustar.biz> From: Alice Jansen <alice.jansen@icann.org<mailto:alice.jansen@icann.org>> Date: Monday, February 9, 2015 at 4:38 PM To: Accountability Community <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>> Subject: [CCWG-ACCT] Revised agenda - Meeting #11 Dear all, In anticipation of your meeting #11, please find attached a revised agenda. Thanks Best regards Alice _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community -- Gregory S. Shatan ï Abelman Frayne & Schwab Partner | IP | Technology | Media | Internet 666 Third Avenue | New York, NY 10017-5621 Direct 212-885-9253 | Main 212-949-9022 Fax 212-949-9190 | Cell 917-816-6428 gsshatan@lawabel.com<mailto:gsshatan@lawabel.com> ICANN-related: gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com> www.lawabel.com<http://www.lawabel.com/>
participants (7)
-
Bruce Tonkin -
Burr, Becky -
Dr Eberhard W Lisse -
Greg Shatan -
James M. Bladel -
Kavouss Arasteh -
Roelof Meijer