Fwd: Stress Tests for IANA transition proposals
All, Further to our recent discussions of stress tests, scenarios and the like, I am forwarding to the group an email from Steve DelBianco of the Business Constituency with a number of examples of stress tests and links to further discussion. This is particularly relevant to RFP4 (which requests a "Description of how you have tested or evaluated the workability of any new technical or operational methods proposed in this document and how they compare to established arrangements") and RFP3 (to inform our discussion of various alternatives and their strengths and weaknesses). Greg ---------- Forwarded message ---------- From: Steve DelBianco <sdelbianco@netchoice.org> Date: Tue, Nov 25, 2014 at 3:24 PM Subject: Stress Tests for IANA transition proposals To: "gregshatanipc@gmail.com" <gregshatanipc@gmail.com> Cc: Steve Metalitz <met@msk.com>, Tony Holmes <tonyarholmes@btinternet.com>, Phil Corwin <psc@vlaw-dc.com>, Aparna Sridhar <aparnasridhar@google.com>, " skawaguchi@fb.com" <skawaguchi@fb.com>, Jonathan Zuck <JZuck@actonline.org>, Kristina Rosette <krosette@cov.com>, Rick Lane <RLane@21cf.com>, Elisa Cooper <Elisa.Cooper@markmonitor.com> Greg — as you requested on our call today, here are ’stress tests’ from the BC's June comments (link <http://www.bizconst.org/wp-content/uploads/2014/07/BC-reply-comment-on-Enhan...> to comments). The stress tests in a standalone doc are also available at http://bizconst.org/StressTests Some of these stress tests relate to general ICANN accountability concerns. But several are relevant to the IANA role you are looking at for Naming Functions (Numbers 3, 5, 7, 8, 9, and 10, in red below): The BC recommends use of scenarios, or ‘stress tests’ to help design and evaluate ICANN accountability structures and mechanisms. Today, ICANN is an effective organization that generally performs its core functions. Although it can be uncomfortable to imagine a scenario where a future ICANN fails dramatically or is confronted with a serious threat, we should consider challenging scenarios that could arise, such as those described below: 1. Scenario: ICANN unilaterally cancels the Affirmation of Commitments, which it may do with just 120 days notice. And if not outright cancellation, ICANN could refuse to implement recommendations of an Affirmation review. Presently, the discipline imposed by needing to win the IANA contract forces ICANN to adhere to the only external accountability it has today: the Affirmation of Commitments. If the Affirmation is to remain part of the new ICANN accountability framework, it is essential that the leverage formerly conveyed by the IANA contract be replaced with a new mechanism, which may or may not include parties external to ICANN. 2. Scenario: ICANN takes steps to eliminate its legal presence in a nation where Internet users and domain registrants are planning to seek legal remedies for ICANN’s failure to enforce contracts. This scenario is not about ICANN opening new offices around the world as part of its global outreach. Rather, it is about ICANN creating a new legal entity distinct from its present status as a California non-profit corporation, and eventually relocating its legal presence. ICANN’s current corporate presence in California creates legal certainty for businesses; presence in a new jurisdiction might not. 3. Scenario: ICANN becomes financially insolvent, due to lawsuits or gross mismanagement. However unlikely, this scenario should explore the orderly continuation of IANA functions and ICANN contract enforcement in the event ICANN could not maintain the necessary qualified technical resources. 4. Scenario: ICANN expands scope beyond its limited technical mission by using domain registration fees to fund grants for developing nations or other worthy causes. ICANN has the power to determine fees charged to TLD applicants, registry operators, registrars, and registrants, so it presents a big target for any Internet-related cause seeking funding sources. This scenario should examine how a fully independent ICANN could be held to its limited technical mission, and whether its fees and spending are subject to external accountability. 5. Scenario: ICANN attempts to add a new top-level domain in spite of security and stability concerns expressed by technical community leaders. This scenario actually came close to occurring when ICANN management did not respond to recommendations of its own Security and Stability Advisory Committee (SSAC) regarding risks of new TLDs interacting with security certificates and internal domains already in use. SSAC recommendations from prior years were not acted upon until late 2013, after significant pressure from a root server operator, Internet service providers, and system integrators. In the actual event, ICANN responded with a collision mitigation plan. This scenario should assess how proposed new accountability mechanisms could respond to similar technical risks expressed before a TLD delegation, as well as reactive responses to problems reported after a delegation. 6. Scenario: Governments in ICANN’s Government Advisory Committee (GAC) amend their operating procedures to change from consensus decisions to majority voting. Today GAC adopts formal advice according to its Operating Principle 47: “consensus is understood to mean the practice of adopting decisions by general agreement in the absence of any formal objection.”13 But the GAC may at any time change its procedures to use majority voting, where each government has equal voting power, such as in the UN and ITU. (Notably, only 61 governments were present at the GAC meeting in Singapore during March 2014, where several GAC members expressed dissatisfaction with the multistakeholder process and consensus threshold for new gTLD program advice.) While ICANN’s board is not strictly obligated to follow GAC advice, this scenario should assess how ICANN could respond to GAC advice with strong majority support but less than consensus. This scenario might also indicate need to amend ICANN bylaws regarding deference to GAC advice that is not supported by consensus. 1. Scenario: As described in scenario 6, the GAC might issue majority-supported advice instructing ICANN to suspend a TLD that refuses to remove domains with content critical of governments (e.g., .corrupt ). Today, this kind of censorship routinely occurs at the edge of the Internet when governments block domestic access to websites, such as Turkey blocking Twitter. This scenario envisions censorship moving from the edge to the core of the internet – the root table of TLDs used by the entire world. The stress test would ask how a proposed accountability mechanism could respond if a future ICANN board bowed to GAC advice for censorship at the root of the DNS. 2. Scenario: ICANN attempts to re-delegate a gTLD because the registry operator is determined to be in breach of its contract. The registry operator challenges the breach determination and obtains an injunction from a national court. What procedures or appeal mechanisms would be used by the entity charged with maintenance and publication of the root zone? 3. Scenario: A court grants an injunction against delegation of a new gTLD that’s a plural version of another TLD that has already been delegated. (for example, .hotels following after .hotel, or .coms following after .com) The court may have ruled on infringement of rights or on arbitrary and capricious behavior by ICANN, but that’s beside the point. The point of this scenario is to ask how a post-transition ICANN and IANA would be empowered to respond to a court injunction granted by a jurisdiction where ICANN has a legal presence. Would ICANN/IANA be able to defer a delegation until court proceedings were concluded? How would ICANN/IANA be accountable for its decision if it ignored the court injunction? 4. Scenario: A government telecom minister instructs ICANN to re-delegate a country-code top-level domain (ccTLD), despite objections from many current registrants and user communities in the country concerned. Faced with this re-delegation request, what response options and measures could be available to ICANN and the entity charged with maintenance of the root zone? -- *Gregory S. Shatan **ï* *Abelman Frayne & Schwab* *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/>*
Greg, Apart from the scenarios that are pertinent to IANA, identified by Steve DelBianco with red coloring, more scenarios could be outlined in the specific context of transition, and if we do, we may have to outline strategies to deal with each of these scenarios and assess if IANA would get past such scenarios ? One problem with this approach is that some of such imaginary extreme scenarios vividly outline ways by which IANA can be harmed, and might give ideas that might actually lead to such scenarios. Certain degree of caution is required in outlining some scenarios that point to ways of doing harm. I could already see one or two examples that could make someone consider it to be interesting ways of causing trouble. Just a thought. Sivasubramanian M Sivasubramanian M <https://www.facebook.com/sivasubramanian.muthusamy> On Fri, Nov 28, 2014 at 12:14 PM, Greg Shatan <gregshatanipc@gmail.com> wrote:
All,
Further to our recent discussions of stress tests, scenarios and the like, I am forwarding to the group an email from Steve DelBianco of the Business Constituency with a number of examples of stress tests and links to further discussion.
This is particularly relevant to RFP4 (which requests a "Description of how you have tested or evaluated the workability of any new technical or operational methods proposed in this document and how they compare to established arrangements") and RFP3 (to inform our discussion of various alternatives and their strengths and weaknesses).
Greg
---------- Forwarded message ---------- From: Steve DelBianco <sdelbianco@netchoice.org> Date: Tue, Nov 25, 2014 at 3:24 PM Subject: Stress Tests for IANA transition proposals To: "gregshatanipc@gmail.com" <gregshatanipc@gmail.com> Cc: Steve Metalitz <met@msk.com>, Tony Holmes <tonyarholmes@btinternet.com>, Phil Corwin <psc@vlaw-dc.com>, Aparna Sridhar <aparnasridhar@google.com>, "skawaguchi@fb.com" <skawaguchi@fb.com>, Jonathan Zuck < JZuck@actonline.org>, Kristina Rosette <krosette@cov.com>, Rick Lane < RLane@21cf.com>, Elisa Cooper <Elisa.Cooper@markmonitor.com>
Greg — as you requested on our call today, here are ’stress tests’ from the BC's June comments (link <http://www.bizconst.org/wp-content/uploads/2014/07/BC-reply-comment-on-Enhan...> to comments). The stress tests in a standalone doc are also available at http://bizconst.org/StressTests
Some of these stress tests relate to general ICANN accountability concerns. But several are relevant to the IANA role you are looking at for Naming Functions (Numbers 3, 5, 7, 8, 9, and 10, in red below):
The BC recommends use of scenarios, or ‘stress tests’ to help design and evaluate ICANN accountability structures and mechanisms. Today, ICANN is an effective organization that generally performs its core functions. Although it can be uncomfortable to imagine a scenario where a future ICANN fails dramatically or is confronted with a serious threat, we should consider challenging scenarios that could arise, such as those described below:
1.
Scenario: ICANN unilaterally cancels the Affirmation of Commitments, which it may do with just 120 days notice. And if not outright cancellation, ICANN could refuse to implement recommendations of an Affirmation review. Presently, the discipline imposed by needing to win the IANA contract forces ICANN to adhere to the only external accountability it has today: the Affirmation of Commitments. If the Affirmation is to remain part of the new ICANN accountability framework, it is essential that the leverage formerly conveyed by the IANA contract be replaced with a new mechanism, which may or may not include parties external to ICANN. 2.
Scenario: ICANN takes steps to eliminate its legal presence in a nation where Internet users and domain registrants are planning to seek legal remedies for ICANN’s failure to enforce contracts. This scenario is not about ICANN opening new offices around the world as part of its global outreach. Rather, it is about ICANN creating a new legal entity distinct from its present status as a California non-profit corporation, and eventually relocating its legal presence. ICANN’s current corporate presence in California creates legal certainty for businesses; presence in a new jurisdiction might not. 3.
Scenario: ICANN becomes financially insolvent, due to lawsuits or gross mismanagement. However unlikely, this scenario should explore the orderly continuation of IANA functions and ICANN contract enforcement in the event ICANN could not maintain the necessary qualified technical resources. 4.
Scenario: ICANN expands scope beyond its limited technical mission by using domain registration fees to fund grants for developing nations or other worthy causes. ICANN has the power to determine fees charged to TLD applicants, registry operators, registrars, and registrants, so it presents a big target for any Internet-related cause seeking funding sources. This scenario should examine how a fully independent ICANN could be held to its limited technical mission, and whether its fees and spending are subject to external accountability. 5.
Scenario: ICANN attempts to add a new top-level domain in spite of security and stability concerns expressed by technical community leaders. This scenario actually came close to occurring when ICANN management did not respond to recommendations of its own Security and Stability Advisory Committee (SSAC) regarding risks of new TLDs interacting with security certificates and internal domains already in use. SSAC recommendations from prior years were not acted upon until late 2013, after significant pressure from a root server operator, Internet service providers, and system integrators. In the actual event, ICANN responded with a collision mitigation plan. This scenario should assess how proposed new accountability mechanisms could respond to similar technical risks expressed before a TLD delegation, as well as reactive responses to problems reported after a delegation. 6.
Scenario: Governments in ICANN’s Government Advisory Committee (GAC) amend their operating procedures to change from consensus decisions to majority voting. Today GAC adopts formal advice according to its Operating Principle 47: “consensus is understood to mean the practice of adopting decisions by general agreement in the absence of any formal objection.”13 But the GAC may at any time change its procedures to use majority voting, where each government has equal voting power, such as in the UN and ITU. (Notably, only 61 governments were present at the GAC meeting in Singapore during March 2014, where several GAC members expressed dissatisfaction with the multistakeholder process and consensus threshold for new gTLD program advice.) While ICANN’s board is not strictly obligated to follow GAC advice, this scenario should assess how ICANN could respond to GAC advice with strong majority support but less than consensus. This scenario might also indicate need to amend ICANN bylaws regarding deference to GAC advice that is not supported by consensus.
1.
Scenario: As described in scenario 6, the GAC might issue majority-supported advice instructing ICANN to suspend a TLD that refuses to remove domains with content critical of governments (e.g., .corrupt ). Today, this kind of censorship routinely occurs at the edge of the Internet when governments block domestic access to websites, such as Turkey blocking Twitter. This scenario envisions censorship moving from the edge to the core of the internet – the root table of TLDs used by the entire world. The stress test would ask how a proposed accountability mechanism could respond if a future ICANN board bowed to GAC advice for censorship at the root of the DNS. 2.
Scenario: ICANN attempts to re-delegate a gTLD because the registry operator is determined to be in breach of its contract. The registry operator challenges the breach determination and obtains an injunction from a national court. What procedures or appeal mechanisms would be used by the entity charged with maintenance and publication of the root zone? 3.
Scenario: A court grants an injunction against delegation of a new gTLD that’s a plural version of another TLD that has already been delegated. (for example, .hotels following after .hotel, or .coms following after .com) The court may have ruled on infringement of rights or on arbitrary and capricious behavior by ICANN, but that’s beside the point. The point of this scenario is to ask how a post-transition ICANN and IANA would be empowered to respond to a court injunction granted by a jurisdiction where ICANN has a legal presence. Would ICANN/IANA be able to defer a delegation until court proceedings were concluded? How would ICANN/IANA be accountable for its decision if it ignored the court injunction? 4.
Scenario: A government telecom minister instructs ICANN to re-delegate a country-code top-level domain (ccTLD), despite objections from many current registrants and user communities in the country concerned. Faced with this re-delegation request, what response options and measures could be available to ICANN and the entity charged with maintenance of the root zone?
--
*Gregory S. Shatan **ï* *Abelman Frayne & Schwab*
*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/>*
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Siva, I would not characterize these as ‘imaginary extreme scenarios’ . For some of them it is easier for me to see they ‘might give ideas that might actually lead to such scenarios’ than for others. Regardless, they all seem like scenarios that we need to prepare for. Chuck From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Sivasubramanian M Sent: Friday, November 28, 2014 2:39 AM To: Greg Shatan Cc: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] Fwd: Stress Tests for IANA transition proposals Greg, Apart from the scenarios that are pertinent to IANA, identified by Steve DelBianco with red coloring, more scenarios could be outlined in the specific context of transition, and if we do, we may have to outline strategies to deal with each of these scenarios and assess if IANA would get past such scenarios ? One problem with this approach is that some of such imaginary extreme scenarios vividly outline ways by which IANA can be harmed, and might give ideas that might actually lead to such scenarios. Certain degree of caution is required in outlining some scenarios that point to ways of doing harm. I could already see one or two examples that could make someone consider it to be interesting ways of causing trouble. Just a thought. Sivasubramanian M Sivasubramanian M<https://www.facebook.com/sivasubramanian.muthusamy> On Fri, Nov 28, 2014 at 12:14 PM, Greg Shatan <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> wrote: All, Further to our recent discussions of stress tests, scenarios and the like, I am forwarding to the group an email from Steve DelBianco of the Business Constituency with a number of examples of stress tests and links to further discussion. This is particularly relevant to RFP4 (which requests a "Description of how you have tested or evaluated the workability of any new technical or operational methods proposed in this document and how they compare to established arrangements") and RFP3 (to inform our discussion of various alternatives and their strengths and weaknesses). Greg ---------- Forwarded message ---------- From: Steve DelBianco <sdelbianco@netchoice.org<mailto:sdelbianco@netchoice.org>> Date: Tue, Nov 25, 2014 at 3:24 PM Subject: Stress Tests for IANA transition proposals To: "gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>" <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> Cc: Steve Metalitz <met@msk.com<mailto:met@msk.com>>, Tony Holmes <tonyarholmes@btinternet.com<mailto:tonyarholmes@btinternet.com>>, Phil Corwin <psc@vlaw-dc.com<mailto:psc@vlaw-dc.com>>, Aparna Sridhar <aparnasridhar@google.com<mailto:aparnasridhar@google.com>>, "skawaguchi@fb.com<mailto:skawaguchi@fb.com>" <skawaguchi@fb.com<mailto:skawaguchi@fb.com>>, Jonathan Zuck <JZuck@actonline.org<mailto:JZuck@actonline.org>>, Kristina Rosette <krosette@cov.com<mailto:krosette@cov.com>>, Rick Lane <RLane@21cf.com<mailto:RLane@21cf.com>>, Elisa Cooper <Elisa.Cooper@markmonitor.com<mailto:Elisa.Cooper@markmonitor.com>> Greg — as you requested on our call today, here are ’stress tests’ from the BC's June comments (link<http://www.bizconst.org/wp-content/uploads/2014/07/BC-reply-comment-on-Enhan...> to comments). The stress tests in a standalone doc are also available at http://bizconst.org/StressTests Some of these stress tests relate to general ICANN accountability concerns. But several are relevant to the IANA role you are looking at for Naming Functions (Numbers 3, 5, 7, 8, 9, and 10, in red below): The BC recommends use of scenarios, or ‘stress tests’ to help design and evaluate ICANN accountability structures and mechanisms. Today, ICANN is an effective organization that generally performs its core functions. Although it can be uncomfortable to imagine a scenario where a future ICANN fails dramatically or is confronted with a serious threat, we should consider challenging scenarios that could arise, such as those described below: 1. Scenario: ICANN unilaterally cancels the Affirmation of Commitments, which it may do with just 120 days notice. And if not outright cancellation, ICANN could refuse to implement recommendations of an Affirmation review. Presently, the discipline imposed by needing to win the IANA contract forces ICANN to adhere to the only external accountability it has today: the Affirmation of Commitments. If the Affirmation is to remain part of the new ICANN accountability framework, it is essential that the leverage formerly conveyed by the IANA contract be replaced with a new mechanism, which may or may not include parties external to ICANN. 2. Scenario: ICANN takes steps to eliminate its legal presence in a nation where Internet users and domain registrants are planning to seek legal remedies for ICANN’s failure to enforce contracts. This scenario is not about ICANN opening new offices around the world as part of its global outreach. Rather, it is about ICANN creating a new legal entity distinct from its present status as a California non-profit corporation, and eventually relocating its legal presence. ICANN’s current corporate presence in California creates legal certainty for businesses; presence in a new jurisdiction might not. 3. Scenario: ICANN becomes financially insolvent, due to lawsuits or gross mismanagement. However unlikely, this scenario should explore the orderly continuation of IANA functions and ICANN contract enforcement in the event ICANN could not maintain the necessary qualified technical resources. 4. Scenario: ICANN expands scope beyond its limited technical mission by using domain registration fees to fund grants for developing nations or other worthy causes. ICANN has the power to determine fees charged to TLD applicants, registry operators, registrars, and registrants, so it presents a big target for any Internet-related cause seeking funding sources. This scenario should examine how a fully independent ICANN could be held to its limited technical mission, and whether its fees and spending are subject to external accountability. 5. Scenario: ICANN attempts to add a new top-level domain in spite of security and stability concerns expressed by technical community leaders. This scenario actually came close to occurring when ICANN management did not respond to recommendations of its own Security and Stability Advisory Committee (SSAC) regarding risks of new TLDs interacting with security certificates and internal domains already in use. SSAC recommendations from prior years were not acted upon until late 2013, after significant pressure from a root server operator, Internet service providers, and system integrators. In the actual event, ICANN responded with a collision mitigation plan. This scenario should assess how proposed new accountability mechanisms could respond to similar technical risks expressed before a TLD delegation, as well as reactive responses to problems reported after a delegation. 6. Scenario: Governments in ICANN’s Government Advisory Committee (GAC) amend their operating procedures to change from consensus decisions to majority voting. Today GAC adopts formal advice according to its Operating Principle 47: “consensus is understood to mean the practice of adopting decisions by general agreement in the absence of any formal objection.”13 But the GAC may at any time change its procedures to use majority voting, where each government has equal voting power, such as in the UN and ITU. (Notably, only 61 governments were present at the GAC meeting in Singapore during March 2014, where several GAC members expressed dissatisfaction with the multistakeholder process and consensus threshold for new gTLD program advice.) While ICANN’s board is not strictly obligated to follow GAC advice, this scenario should assess how ICANN could respond to GAC advice with strong majority support but less than consensus. This scenario might also indicate need to amend ICANN bylaws regarding deference to GAC advice that is not supported by consensus. 7. Scenario: As described in scenario 6, the GAC might issue majority-supported advice instructing ICANN to suspend a TLD that refuses to remove domains with content critical of governments (e.g., .corrupt ). Today, this kind of censorship routinely occurs at the edge of the Internet when governments block domestic access to websites, such as Turkey blocking Twitter. This scenario envisions censorship moving from the edge to the core of the internet – the root table of TLDs used by the entire world. The stress test would ask how a proposed accountability mechanism could respond if a future ICANN board bowed to GAC advice for censorship at the root of the DNS. 8. Scenario: ICANN attempts to re-delegate a gTLD because the registry operator is determined to be in breach of its contract. The registry operator challenges the breach determination and obtains an injunction from a national court. What procedures or appeal mechanisms would be used by the entity charged with maintenance and publication of the root zone? 9. Scenario: A court grants an injunction against delegation of a new gTLD that’s a plural version of another TLD that has already been delegated. (for example, .hotels following after .hotel, or .coms following after .com) The court may have ruled on infringement of rights or on arbitrary and capricious behavior by ICANN, but that’s beside the point. The point of this scenario is to ask how a post-transition ICANN and IANA would be empowered to respond to a court injunction granted by a jurisdiction where ICANN has a legal presence. Would ICANN/IANA be able to defer a delegation until court proceedings were concluded? How would ICANN/IANA be accountable for its decision if it ignored the court injunction? 10. Scenario: A government telecom minister instructs ICANN to re-delegate a country-code top-level domain (ccTLD), despite objections from many current registrants and user communities in the country concerned. Faced with this re-delegation request, what response options and measures could be available to ICANN and the entity charged with maintenance of the root zone? -- Gregory S. Shatan • Abelman Frayne & Schwab 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/> _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship
Dear Chuck, Agree that we must be prepared. We could prepare solutions for some of the scenarios already outlined, and if there are new scenarios that are prone to capture the imagination, there could be a quieter way of contemplating and preparing for such scenarios. Thank you. Sivasubramanian M <https://www.facebook.com/sivasubramanian.muthusamy> On Fri, Nov 28, 2014 at 4:35 PM, Gomes, Chuck <cgomes@verisign.com> wrote:
Siva,
I would not characterize these as ‘imaginary extreme scenarios’ . For some of them it is easier for me to see they ‘might give ideas that might actually lead to such scenarios’ than for others. Regardless, they all seem like scenarios that we need to prepare for.
Chuck
*From:* cwg-stewardship-bounces@icann.org [mailto: cwg-stewardship-bounces@icann.org] *On Behalf Of *Sivasubramanian M *Sent:* Friday, November 28, 2014 2:39 AM *To:* Greg Shatan *Cc:* cwg-stewardship@icann.org *Subject:* Re: [CWG-Stewardship] Fwd: Stress Tests for IANA transition proposals
Greg,
Apart from the scenarios that are pertinent to IANA, identified by Steve DelBianco with red coloring, more scenarios could be outlined in the specific context of transition, and if we do, we may have to outline strategies to deal with each of these scenarios and assess if IANA would get past such scenarios ?
One problem with this approach is that some of such imaginary extreme scenarios vividly outline ways by which IANA can be harmed, and might give ideas that might actually lead to such scenarios. Certain degree of caution is required in outlining some scenarios that point to ways of doing harm. I could already see one or two examples that could make someone consider it to be interesting ways of causing trouble.
Just a thought.
Sivasubramanian M
Sivasubramanian M <https://www.facebook.com/sivasubramanian.muthusamy>
On Fri, Nov 28, 2014 at 12:14 PM, Greg Shatan <gregshatanipc@gmail.com> wrote:
All,
Further to our recent discussions of stress tests, scenarios and the like, I am forwarding to the group an email from Steve DelBianco of the Business Constituency with a number of examples of stress tests and links to further discussion.
This is particularly relevant to RFP4 (which requests a "Description of how you have tested or evaluated the workability of any new technical or operational methods proposed in this document and how they compare to established arrangements") and RFP3 (to inform our discussion of various alternatives and their strengths and weaknesses).
Greg
---------- Forwarded message ---------- From: *Steve DelBianco* <sdelbianco@netchoice.org> Date: Tue, Nov 25, 2014 at 3:24 PM Subject: Stress Tests for IANA transition proposals To: "gregshatanipc@gmail.com" <gregshatanipc@gmail.com> Cc: Steve Metalitz <met@msk.com>, Tony Holmes <tonyarholmes@btinternet.com>, Phil Corwin <psc@vlaw-dc.com>, Aparna Sridhar <aparnasridhar@google.com>, "skawaguchi@fb.com" <skawaguchi@fb.com>, Jonathan Zuck < JZuck@actonline.org>, Kristina Rosette <krosette@cov.com>, Rick Lane < RLane@21cf.com>, Elisa Cooper <Elisa.Cooper@markmonitor.com>
Greg — as you requested on our call today, here are ’stress tests’ from the BC's June comments (link <http://www.bizconst.org/wp-content/uploads/2014/07/BC-reply-comment-on-Enhan...> to comments). The stress tests in a standalone doc are also available at http://bizconst.org/StressTests
Some of these stress tests relate to general ICANN accountability concerns. But several are relevant to the IANA role you are looking at for Naming Functions (Numbers 3, 5, 7, 8, 9, and 10, in red below):
The BC recommends use of scenarios, or ‘stress tests’ to help design and evaluate ICANN accountability structures and mechanisms. Today, ICANN is an effective organization that generally performs its core functions. Although it can be uncomfortable to imagine a scenario where a future ICANN fails dramatically or is confronted with a serious threat, we should consider challenging scenarios that could arise, such as those described below:
1. Scenario: ICANN unilaterally cancels the *Affirmation of Commitments*, which it may do with just 120 days notice. And if not outright cancellation, ICANN could refuse to implement recommendations of an * Affirmation *review. Presently, the discipline imposed by needing to win the IANA contract forces ICANN to adhere to the only external accountability it has today: the *Affirmation of Commitments*. If the *Affirmation *is to remain part of the new ICANN accountability framework, it is essential that the leverage formerly conveyed by the IANA contract be replaced with a new mechanism, which may or may not include parties external to ICANN.
2. Scenario: ICANN takes steps to eliminate its legal presence in a nation where Internet users and domain registrants are planning to seek legal remedies for ICANN’s failure to enforce contracts. This scenario is not about ICANN opening new offices around the world as part of its global outreach. Rather, it is about ICANN creating a new legal entity distinct from its present status as a California non-profit corporation, and eventually relocating its legal presence. ICANN’s current corporate presence in California creates legal certainty for businesses; presence in a new jurisdiction might not.
3. Scenario: ICANN becomes financially insolvent, due to lawsuits or gross mismanagement. However unlikely, this scenario should explore the orderly continuation of IANA functions and ICANN contract enforcement in the event ICANN could not maintain the necessary qualified technical resources.
4. Scenario: ICANN expands scope beyond its limited technical mission by using domain registration fees to fund grants for developing nations or other worthy causes. ICANN has the power to determine fees charged to TLD applicants, registry operators, registrars, and registrants, so it presents a big target for any Internet-related cause seeking funding sources. This scenario should examine how a fully independent ICANN could be held to its limited technical mission, and whether its fees and spending are subject to external accountability.
5. Scenario: ICANN attempts to add a new top-level domain in spite of security and stability concerns expressed by technical community leaders. This scenario actually came close to occurring when ICANN management did not respond to recommendations of its own Security and Stability Advisory Committee (SSAC) regarding risks of new TLDs interacting with security certificates and internal domains already in use. SSAC recommendations from prior years were not acted upon until late 2013, after significant pressure from a root server operator, Internet service providers, and system integrators. In the actual event, ICANN responded with a collision mitigation plan. This scenario should assess how proposed new accountability mechanisms could respond to similar technical risks expressed before a TLD delegation, as well as reactive responses to problems reported after a delegation.
6. Scenario: Governments in ICANN’s Government Advisory Committee (GAC) amend their operating procedures to change from consensus decisions to majority voting. Today GAC adopts formal advice according to its Operating Principle 47: “*consensus is understood to mean the practice of adopting decisions by general agreement in the absence of any formal objection*.”13 But the GAC may at any time change its procedures to use majority voting, where each government has equal voting power, such as in the UN and ITU. (Notably, only 61 governments were present at the GAC meeting in Singapore during March 2014, where several GAC members expressed dissatisfaction with the multistakeholder process and consensus threshold for new gTLD program advice.) While ICANN’s board is not strictly obligated to follow GAC advice, this scenario should assess how ICANN could respond to GAC advice with strong majority support but less than consensus. This scenario might also indicate need to amend ICANN bylaws regarding deference to GAC advice that is not supported by consensus.
7. Scenario: As described in scenario 6, the GAC might issue majority-supported advice instructing ICANN to suspend a TLD that refuses to remove domains with content critical of governments (e.g., *.*corrupt ). Today, this kind of censorship routinely occurs at the edge of the Internet when governments block domestic access to websites, such as Turkey blocking Twitter. This scenario envisions censorship moving from the edge *to the core of the internet *– the root table of TLDs used by the entire world. The stress test would ask how a proposed accountability mechanism could respond if a future ICANN board bowed to GAC advice for censorship at the root of the DNS.
8. Scenario: ICANN attempts to re-delegate a gTLD because the registry operator is determined to be in breach of its contract. The registry operator challenges the breach determination and obtains an injunction from a national court. What procedures or appeal mechanisms would be used by the entity charged with maintenance and publication of the root zone?
9. Scenario: A court grants an injunction against delegation of a new gTLD that’s a plural version of another TLD that has already been delegated. (for example, .hotels following after .hotel, or .coms following after .com) The court may have ruled on infringement of rights or on arbitrary and capricious behavior by ICANN, but that’s beside the point. The point of this scenario is to ask how a post-transition ICANN and IANA would be empowered to respond to a court injunction granted by a jurisdiction where ICANN has a legal presence. Would ICANN/IANA be able to defer a delegation until court proceedings were concluded? How would ICANN/IANA be accountable for its decision if it ignored the court injunction?
10. Scenario: A government telecom minister instructs ICANN to re-delegate a country-code top-level domain (ccTLD), despite objections from many current registrants and user communities in the country concerned. Faced with this re-delegation request, what response options and measures could be available to ICANN and the entity charged with maintenance of the root zone?
--
*Gregory S. Shatan **ï* *Abelman Frayne & Schwab*
*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/>*
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
That would be good if possible. How do we do that in an open and transparent way? Chuck From: Sivasubramanian M [mailto:isolatedn@gmail.com] Sent: Friday, November 28, 2014 6:17 AM To: Gomes, Chuck Cc: Greg Shatan; cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] Fwd: Stress Tests for IANA transition proposals Dear Chuck, Agree that we must be prepared. We could prepare solutions for some of the scenarios already outlined, and if there are new scenarios that are prone to capture the imagination, there could be a quieter way of contemplating and preparing for such scenarios. Thank you. Sivasubramanian M<https://www.facebook.com/sivasubramanian.muthusamy> On Fri, Nov 28, 2014 at 4:35 PM, Gomes, Chuck <cgomes@verisign.com<mailto:cgomes@verisign.com>> wrote: Siva, I would not characterize these as ‘imaginary extreme scenarios’ . For some of them it is easier for me to see they ‘might give ideas that might actually lead to such scenarios’ than for others. Regardless, they all seem like scenarios that we need to prepare for. Chuck From: cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org>] On Behalf Of Sivasubramanian M Sent: Friday, November 28, 2014 2:39 AM To: Greg Shatan Cc: cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org> Subject: Re: [CWG-Stewardship] Fwd: Stress Tests for IANA transition proposals Greg, Apart from the scenarios that are pertinent to IANA, identified by Steve DelBianco with red coloring, more scenarios could be outlined in the specific context of transition, and if we do, we may have to outline strategies to deal with each of these scenarios and assess if IANA would get past such scenarios ? One problem with this approach is that some of such imaginary extreme scenarios vividly outline ways by which IANA can be harmed, and might give ideas that might actually lead to such scenarios. Certain degree of caution is required in outlining some scenarios that point to ways of doing harm. I could already see one or two examples that could make someone consider it to be interesting ways of causing trouble. Just a thought. Sivasubramanian M Sivasubramanian M<https://www.facebook.com/sivasubramanian.muthusamy> On Fri, Nov 28, 2014 at 12:14 PM, Greg Shatan <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> wrote: All, Further to our recent discussions of stress tests, scenarios and the like, I am forwarding to the group an email from Steve DelBianco of the Business Constituency with a number of examples of stress tests and links to further discussion. This is particularly relevant to RFP4 (which requests a "Description of how you have tested or evaluated the workability of any new technical or operational methods proposed in this document and how they compare to established arrangements") and RFP3 (to inform our discussion of various alternatives and their strengths and weaknesses). Greg ---------- Forwarded message ---------- From: Steve DelBianco <sdelbianco@netchoice.org<mailto:sdelbianco@netchoice.org>> Date: Tue, Nov 25, 2014 at 3:24 PM Subject: Stress Tests for IANA transition proposals To: "gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>" <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> Cc: Steve Metalitz <met@msk.com<mailto:met@msk.com>>, Tony Holmes <tonyarholmes@btinternet.com<mailto:tonyarholmes@btinternet.com>>, Phil Corwin <psc@vlaw-dc.com<mailto:psc@vlaw-dc.com>>, Aparna Sridhar <aparnasridhar@google.com<mailto:aparnasridhar@google.com>>, "skawaguchi@fb.com<mailto:skawaguchi@fb.com>" <skawaguchi@fb.com<mailto:skawaguchi@fb.com>>, Jonathan Zuck <JZuck@actonline.org<mailto:JZuck@actonline.org>>, Kristina Rosette <krosette@cov.com<mailto:krosette@cov.com>>, Rick Lane <RLane@21cf.com<mailto:RLane@21cf.com>>, Elisa Cooper <Elisa.Cooper@markmonitor.com<mailto:Elisa.Cooper@markmonitor.com>> Greg — as you requested on our call today, here are ’stress tests’ from the BC's June comments (link<http://www.bizconst.org/wp-content/uploads/2014/07/BC-reply-comment-on-Enhan...> to comments). The stress tests in a standalone doc are also available at http://bizconst.org/StressTests Some of these stress tests relate to general ICANN accountability concerns. But several are relevant to the IANA role you are looking at for Naming Functions (Numbers 3, 5, 7, 8, 9, and 10, in red below): The BC recommends use of scenarios, or ‘stress tests’ to help design and evaluate ICANN accountability structures and mechanisms. Today, ICANN is an effective organization that generally performs its core functions. Although it can be uncomfortable to imagine a scenario where a future ICANN fails dramatically or is confronted with a serious threat, we should consider challenging scenarios that could arise, such as those described below: 1. Scenario: ICANN unilaterally cancels the Affirmation of Commitments, which it may do with just 120 days notice. And if not outright cancellation, ICANN could refuse to implement recommendations of an Affirmation review. Presently, the discipline imposed by needing to win the IANA contract forces ICANN to adhere to the only external accountability it has today: the Affirmation of Commitments. If the Affirmation is to remain part of the new ICANN accountability framework, it is essential that the leverage formerly conveyed by the IANA contract be replaced with a new mechanism, which may or may not include parties external to ICANN. 2. Scenario: ICANN takes steps to eliminate its legal presence in a nation where Internet users and domain registrants are planning to seek legal remedies for ICANN’s failure to enforce contracts. This scenario is not about ICANN opening new offices around the world as part of its global outreach. Rather, it is about ICANN creating a new legal entity distinct from its present status as a California non-profit corporation, and eventually relocating its legal presence. ICANN’s current corporate presence in California creates legal certainty for businesses; presence in a new jurisdiction might not. 3. Scenario: ICANN becomes financially insolvent, due to lawsuits or gross mismanagement. However unlikely, this scenario should explore the orderly continuation of IANA functions and ICANN contract enforcement in the event ICANN could not maintain the necessary qualified technical resources. 4. Scenario: ICANN expands scope beyond its limited technical mission by using domain registration fees to fund grants for developing nations or other worthy causes. ICANN has the power to determine fees charged to TLD applicants, registry operators, registrars, and registrants, so it presents a big target for any Internet-related cause seeking funding sources. This scenario should examine how a fully independent ICANN could be held to its limited technical mission, and whether its fees and spending are subject to external accountability. 5. Scenario: ICANN attempts to add a new top-level domain in spite of security and stability concerns expressed by technical community leaders. This scenario actually came close to occurring when ICANN management did not respond to recommendations of its own Security and Stability Advisory Committee (SSAC) regarding risks of new TLDs interacting with security certificates and internal domains already in use. SSAC recommendations from prior years were not acted upon until late 2013, after significant pressure from a root server operator, Internet service providers, and system integrators. In the actual event, ICANN responded with a collision mitigation plan. This scenario should assess how proposed new accountability mechanisms could respond to similar technical risks expressed before a TLD delegation, as well as reactive responses to problems reported after a delegation. 6. Scenario: Governments in ICANN’s Government Advisory Committee (GAC) amend their operating procedures to change from consensus decisions to majority voting. Today GAC adopts formal advice according to its Operating Principle 47: “consensus is understood to mean the practice of adopting decisions by general agreement in the absence of any formal objection.”13 But the GAC may at any time change its procedures to use majority voting, where each government has equal voting power, such as in the UN and ITU. (Notably, only 61 governments were present at the GAC meeting in Singapore during March 2014, where several GAC members expressed dissatisfaction with the multistakeholder process and consensus threshold for new gTLD program advice.) While ICANN’s board is not strictly obligated to follow GAC advice, this scenario should assess how ICANN could respond to GAC advice with strong majority support but less than consensus. This scenario might also indicate need to amend ICANN bylaws regarding deference to GAC advice that is not supported by consensus. 7. Scenario: As described in scenario 6, the GAC might issue majority-supported advice instructing ICANN to suspend a TLD that refuses to remove domains with content critical of governments (e.g., .corrupt ). Today, this kind of censorship routinely occurs at the edge of the Internet when governments block domestic access to websites, such as Turkey blocking Twitter. This scenario envisions censorship moving from the edge to the core of the internet – the root table of TLDs used by the entire world. The stress test would ask how a proposed accountability mechanism could respond if a future ICANN board bowed to GAC advice for censorship at the root of the DNS. 8. Scenario: ICANN attempts to re-delegate a gTLD because the registry operator is determined to be in breach of its contract. The registry operator challenges the breach determination and obtains an injunction from a national court. What procedures or appeal mechanisms would be used by the entity charged with maintenance and publication of the root zone? 9. Scenario: A court grants an injunction against delegation of a new gTLD that’s a plural version of another TLD that has already been delegated. (for example, .hotels following after .hotel, or .coms following after .com) The court may have ruled on infringement of rights or on arbitrary and capricious behavior by ICANN, but that’s beside the point. The point of this scenario is to ask how a post-transition ICANN and IANA would be empowered to respond to a court injunction granted by a jurisdiction where ICANN has a legal presence. Would ICANN/IANA be able to defer a delegation until court proceedings were concluded? How would ICANN/IANA be accountable for its decision if it ignored the court injunction? 10. Scenario: A government telecom minister instructs ICANN to re-delegate a country-code top-level domain (ccTLD), despite objections from many current registrants and user communities in the country concerned. Faced with this re-delegation request, what response options and measures could be available to ICANN and the entity charged with maintenance of the root zone? -- Gregory S. Shatan • Abelman Frayne & Schwab 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/> _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship
On 28/11/2014 07:38, Sivasubramanian M wrote:
One problem with this approach is that some of such imaginary extreme scenarios vividly outline ways by which IANA can be harmed, and might give ideas that might actually lead to such scenarios.
The post-transition environment we are attempting to design is intended to be permanent. I don't think it would be sensible to close our eyes to potential risks on the grounds that "they might give people ideas" for how to cause harm. Sooner or later, someone is likely to come up with those same ideas anyway. Even recognising our limited, imperfect nature, we should still at least aim for any permanent outcome we design to be proof against any harmful ideas we can imagine. I therefore regard these stress tests as a valuable contribution to a discussion of success criteria for any post-NTIA structure. Malcolm. -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/ London Internet Exchange Ltd 21-27 St Thomas Street, London SE1 9RY Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA
On 28/11/2014 08:38, Sivasubramanian M wrote:
One problem with this approach is that some of such imaginary extreme scenarios vividly outline ways by which IANA can be harmed, and might give ideas that might actually lead to such scenarios. Certain degree of caution is required in outlining some scenarios that point to ways of doing harm. I could already see one or two examples that could make someone consider it to be interesting ways of causing trouble.
What you are describing, Siva, is a classic case of Security through obscurity. http://en.wikipedia.org/wiki/Security_through_obscurity It doesn't work. If there are flaws, we need to identify them and mitigate them. Kind regards, Olivier
The wiki page article is really interesting. I do not fully agree as technical concepts can not always be projected on to the policy area, though in this case there some of what is said on "Security through obscurity" applies. I will not argue further and would stop here for you all to decide on what scenarios to be discussed and at what level of detail and depth and at what speed. Sivasubramanian M Sivasubramanian M <https://www.facebook.com/sivasubramanian.muthusamy> On Fri, Nov 28, 2014 at 9:05 PM, Olivier MJ Crepin-Leblond <ocl@gih.com> wrote:
On 28/11/2014 08:38, Sivasubramanian M wrote:
One problem with this approach is that some of such imaginary extreme scenarios vividly outline ways by which IANA can be harmed, and might give ideas that might actually lead to such scenarios. Certain degree of caution is required in outlining some scenarios that point to ways of doing harm. I could already see one or two examples that could make someone consider it to be interesting ways of causing trouble.
What you are describing, Siva, is a classic case of Security through obscurity. http://en.wikipedia.org/wiki/Security_through_obscurity It doesn't work.
If there are flaws, we need to identify them and mitigate them. Kind regards,
Olivier
Steve DelBianco's contribution is very valuable and scenarios (or scenari) are useful thought experiments. It is important however to distinguish what is related to the IANA stewardship transition per se and what is related to ICANN's functioning in general, even in the current situation. For instance a GAC evolution towards voting. Steve seems to imply that the allocation of the IANA contract and the role of NTIA in individual request validations constitute a sufficient stopgap or nuclear sanction but I am not sure these scenarios would be easy to handle even in the current architecture. Wotrh studying nonetheless. B. "*Le plus beau métier des hommes, c'est d'unir les hommes*", Antoine de Saint Exupéry ("*There is no greater mission for humans than uniting humans*")BERTRAND DE LA CHAPELLEInternet & Jurisdiction Project | Directoremail bdelachapelle@internetjurisdiction.netemail bdelachapelle@gmail.comtwitter @IJurisdiction <https://twitter.com/IJurisdiction> | @bdelachapelle <https://twitter.com/bdelachapelle>mobile +33 (0)6 11 88 33 32 www.internetjurisdiction.net[image: A GLOBAL MULTI-STAKEHOLDER DIALOGUE PROCESS] On Fri, Nov 28, 2014 at 7:44 AM, Greg Shatan <gregshatanipc@gmail.com> wrote:
All,
Further to our recent discussions of stress tests, scenarios and the like, I am forwarding to the group an email from Steve DelBianco of the Business Constituency with a number of examples of stress tests and links to further discussion.
This is particularly relevant to RFP4 (which requests a "Description of how you have tested or evaluated the workability of any new technical or operational methods proposed in this document and how they compare to established arrangements") and RFP3 (to inform our discussion of various alternatives and their strengths and weaknesses).
Greg
---------- Forwarded message ---------- From: Steve DelBianco <sdelbianco@netchoice.org> Date: Tue, Nov 25, 2014 at 3:24 PM Subject: Stress Tests for IANA transition proposals To: "gregshatanipc@gmail.com" <gregshatanipc@gmail.com> Cc: Steve Metalitz <met@msk.com>, Tony Holmes <tonyarholmes@btinternet.com>, Phil Corwin <psc@vlaw-dc.com>, Aparna Sridhar <aparnasridhar@google.com>, "skawaguchi@fb.com" <skawaguchi@fb.com>, Jonathan Zuck < JZuck@actonline.org>, Kristina Rosette <krosette@cov.com>, Rick Lane < RLane@21cf.com>, Elisa Cooper <Elisa.Cooper@markmonitor.com>
Greg — as you requested on our call today, here are ’stress tests’ from the BC's June comments (link <http://www.bizconst.org/wp-content/uploads/2014/07/BC-reply-comment-on-Enhan...> to comments). The stress tests in a standalone doc are also available at http://bizconst.org/StressTests
Some of these stress tests relate to general ICANN accountability concerns. But several are relevant to the IANA role you are looking at for Naming Functions (Numbers 3, 5, 7, 8, 9, and 10, in red below):
The BC recommends use of scenarios, or ‘stress tests’ to help design and evaluate ICANN accountability structures and mechanisms. Today, ICANN is an effective organization that generally performs its core functions. Although it can be uncomfortable to imagine a scenario where a future ICANN fails dramatically or is confronted with a serious threat, we should consider challenging scenarios that could arise, such as those described below:
1.
Scenario: ICANN unilaterally cancels the Affirmation of Commitments, which it may do with just 120 days notice. And if not outright cancellation, ICANN could refuse to implement recommendations of an Affirmation review. Presently, the discipline imposed by needing to win the IANA contract forces ICANN to adhere to the only external accountability it has today: the Affirmation of Commitments. If the Affirmation is to remain part of the new ICANN accountability framework, it is essential that the leverage formerly conveyed by the IANA contract be replaced with a new mechanism, which may or may not include parties external to ICANN. 2.
Scenario: ICANN takes steps to eliminate its legal presence in a nation where Internet users and domain registrants are planning to seek legal remedies for ICANN’s failure to enforce contracts. This scenario is not about ICANN opening new offices around the world as part of its global outreach. Rather, it is about ICANN creating a new legal entity distinct from its present status as a California non-profit corporation, and eventually relocating its legal presence. ICANN’s current corporate presence in California creates legal certainty for businesses; presence in a new jurisdiction might not. 3.
Scenario: ICANN becomes financially insolvent, due to lawsuits or gross mismanagement. However unlikely, this scenario should explore the orderly continuation of IANA functions and ICANN contract enforcement in the event ICANN could not maintain the necessary qualified technical resources. 4.
Scenario: ICANN expands scope beyond its limited technical mission by using domain registration fees to fund grants for developing nations or other worthy causes. ICANN has the power to determine fees charged to TLD applicants, registry operators, registrars, and registrants, so it presents a big target for any Internet-related cause seeking funding sources. This scenario should examine how a fully independent ICANN could be held to its limited technical mission, and whether its fees and spending are subject to external accountability. 5.
Scenario: ICANN attempts to add a new top-level domain in spite of security and stability concerns expressed by technical community leaders. This scenario actually came close to occurring when ICANN management did not respond to recommendations of its own Security and Stability Advisory Committee (SSAC) regarding risks of new TLDs interacting with security certificates and internal domains already in use. SSAC recommendations from prior years were not acted upon until late 2013, after significant pressure from a root server operator, Internet service providers, and system integrators. In the actual event, ICANN responded with a collision mitigation plan. This scenario should assess how proposed new accountability mechanisms could respond to similar technical risks expressed before a TLD delegation, as well as reactive responses to problems reported after a delegation. 6.
Scenario: Governments in ICANN’s Government Advisory Committee (GAC) amend their operating procedures to change from consensus decisions to majority voting. Today GAC adopts formal advice according to its Operating Principle 47: “consensus is understood to mean the practice of adopting decisions by general agreement in the absence of any formal objection.”13 But the GAC may at any time change its procedures to use majority voting, where each government has equal voting power, such as in the UN and ITU. (Notably, only 61 governments were present at the GAC meeting in Singapore during March 2014, where several GAC members expressed dissatisfaction with the multistakeholder process and consensus threshold for new gTLD program advice.) While ICANN’s board is not strictly obligated to follow GAC advice, this scenario should assess how ICANN could respond to GAC advice with strong majority support but less than consensus. This scenario might also indicate need to amend ICANN bylaws regarding deference to GAC advice that is not supported by consensus.
1.
Scenario: As described in scenario 6, the GAC might issue majority-supported advice instructing ICANN to suspend a TLD that refuses to remove domains with content critical of governments (e.g., .corrupt ). Today, this kind of censorship routinely occurs at the edge of the Internet when governments block domestic access to websites, such as Turkey blocking Twitter. This scenario envisions censorship moving from the edge to the core of the internet – the root table of TLDs used by the entire world. The stress test would ask how a proposed accountability mechanism could respond if a future ICANN board bowed to GAC advice for censorship at the root of the DNS. 2.
Scenario: ICANN attempts to re-delegate a gTLD because the registry operator is determined to be in breach of its contract. The registry operator challenges the breach determination and obtains an injunction from a national court. What procedures or appeal mechanisms would be used by the entity charged with maintenance and publication of the root zone? 3.
Scenario: A court grants an injunction against delegation of a new gTLD that’s a plural version of another TLD that has already been delegated. (for example, .hotels following after .hotel, or .coms following after .com) The court may have ruled on infringement of rights or on arbitrary and capricious behavior by ICANN, but that’s beside the point. The point of this scenario is to ask how a post-transition ICANN and IANA would be empowered to respond to a court injunction granted by a jurisdiction where ICANN has a legal presence. Would ICANN/IANA be able to defer a delegation until court proceedings were concluded? How would ICANN/IANA be accountable for its decision if it ignored the court injunction? 4.
Scenario: A government telecom minister instructs ICANN to re-delegate a country-code top-level domain (ccTLD), despite objections from many current registrants and user communities in the country concerned. Faced with this re-delegation request, what response options and measures could be available to ICANN and the entity charged with maintenance of the root zone?
--
*Gregory S. Shatan **ï* *Abelman Frayne & Schwab*
*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/>*
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Bertrand, all When we discussed the “stress testing” in Frankfurt, we didn’t go into the details, but the way I see it this should primarily aim to evaluate the CWG model towards what we see as realistic tasks and possible complications that the IANA function operator could be facing in their day to day performance of the function as such - and to test if the model answers to those challenges in regards of the ability to timely and adequate reactions, - e.g. the mechanism to activate the independent appeals panels and make sure we have a show stopper before any final execution of any disputed decisions. Testing against scenarios where communities within the ICANN model change their composition or procedures for decisions I agree is more related to ICANN's functioning in general. Best regards Elise Knutssøn Lindeberg Senior Legal Adviser, GAC representative Networks Department Norwegian Post and Telecommunications Authority e-mail: ekl@npt.no<mailto:ekl@npt.no> Mobile: +47 90190947 As of January 1st 2015 NPT will be known as the Norwegian Communications Authority. Fra: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] På vegne av Bertrand de La Chapelle Sendt: 28. november 2014 13:45 Til: Greg Shatan Kopi: cwg-stewardship@icann.org Emne: Re: [CWG-Stewardship] Fwd: Stress Tests for IANA transition proposals Steve DelBianco's contribution is very valuable and scenarios (or scenari) are useful thought experiments. It is important however to distinguish what is related to the IANA stewardship transition per se and what is related to ICANN's functioning in general, even in the current situation. For instance a GAC evolution towards voting. Steve seems to imply that the allocation of the IANA contract and the role of NTIA in individual request validations constitute a sufficient stopgap or nuclear sanction but I am not sure these scenarios would be easy to handle even in the current architecture. Wotrh studying nonetheless. B. "Le plus beau métier des hommes, c'est d'unir les hommes", Antoine de Saint Exupéry ("There is no greater mission for humans than uniting humans") BERTRAND DE LA CHAPELLE Internet & Jurisdiction Project | Director email bdelachapelle@internetjurisdiction.net<mailto:bdelachapelle@internetjurisdiction.net> email bdelachapelle@gmail.com<mailto:bdelachapelle@gmail.com> twitter @IJurisdiction<https://twitter.com/IJurisdiction> | @bdelachapelle<https://twitter.com/bdelachapelle> mobile +33 (0)6 11 88 33 32 www.internetjurisdiction.net<http://www.internetjurisdiction.net> [Bilde er fjernet av sender. A GLOBAL MULTI-STAKEHOLDER DIALOGUE PROCESS] On Fri, Nov 28, 2014 at 7:44 AM, Greg Shatan <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> wrote: All, Further to our recent discussions of stress tests, scenarios and the like, I am forwarding to the group an email from Steve DelBianco of the Business Constituency with a number of examples of stress tests and links to further discussion. This is particularly relevant to RFP4 (which requests a "Description of how you have tested or evaluated the workability of any new technical or operational methods proposed in this document and how they compare to established arrangements") and RFP3 (to inform our discussion of various alternatives and their strengths and weaknesses). Greg ---------- Forwarded message ---------- From: Steve DelBianco <sdelbianco@netchoice.org<mailto:sdelbianco@netchoice.org>> Date: Tue, Nov 25, 2014 at 3:24 PM Subject: Stress Tests for IANA transition proposals To: "gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>" <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> Cc: Steve Metalitz <met@msk.com<mailto:met@msk.com>>, Tony Holmes <tonyarholmes@btinternet.com<mailto:tonyarholmes@btinternet.com>>, Phil Corwin <psc@vlaw-dc.com<mailto:psc@vlaw-dc.com>>, Aparna Sridhar <aparnasridhar@google.com<mailto:aparnasridhar@google.com>>, "skawaguchi@fb.com<mailto:skawaguchi@fb.com>" <skawaguchi@fb.com<mailto:skawaguchi@fb.com>>, Jonathan Zuck <JZuck@actonline.org<mailto:JZuck@actonline.org>>, Kristina Rosette <krosette@cov.com<mailto:krosette@cov.com>>, Rick Lane <RLane@21cf.com<mailto:RLane@21cf.com>>, Elisa Cooper <Elisa.Cooper@markmonitor.com<mailto:Elisa.Cooper@markmonitor.com>> Greg — as you requested on our call today, here are ’stress tests’ from the BC's June comments (link<http://www.bizconst.org/wp-content/uploads/2014/07/BC-reply-comment-on-Enhan...> to comments). The stress tests in a standalone doc are also available at http://bizconst.org/StressTests Some of these stress tests relate to general ICANN accountability concerns. But several are relevant to the IANA role you are looking at for Naming Functions (Numbers 3, 5, 7, 8, 9, and 10, in red below): The BC recommends use of scenarios, or ‘stress tests’ to help design and evaluate ICANN accountability structures and mechanisms. Today, ICANN is an effective organization that generally performs its core functions. Although it can be uncomfortable to imagine a scenario where a future ICANN fails dramatically or is confronted with a serious threat, we should consider challenging scenarios that could arise, such as those described below: 1. Scenario: ICANN unilaterally cancels the Affirmation of Commitments, which it may do with just 120 days notice. And if not outright cancellation, ICANN could refuse to implement recommendations of an Affirmation review. Presently, the discipline imposed by needing to win the IANA contract forces ICANN to adhere to the only external accountability it has today: the Affirmation of Commitments. If the Affirmation is to remain part of the new ICANN accountability framework, it is essential that the leverage formerly conveyed by the IANA contract be replaced with a new mechanism, which may or may not include parties external to ICANN. 2. Scenario: ICANN takes steps to eliminate its legal presence in a nation where Internet users and domain registrants are planning to seek legal remedies for ICANN’s failure to enforce contracts. This scenario is not about ICANN opening new offices around the world as part of its global outreach. Rather, it is about ICANN creating a new legal entity distinct from its present status as a California non-profit corporation, and eventually relocating its legal presence. ICANN’s current corporate presence in California creates legal certainty for businesses; presence in a new jurisdiction might not. 3. Scenario: ICANN becomes financially insolvent, due to lawsuits or gross mismanagement. However unlikely, this scenario should explore the orderly continuation of IANA functions and ICANN contract enforcement in the event ICANN could not maintain the necessary qualified technical resources. 4. Scenario: ICANN expands scope beyond its limited technical mission by using domain registration fees to fund grants for developing nations or other worthy causes. ICANN has the power to determine fees charged to TLD applicants, registry operators, registrars, and registrants, so it presents a big target for any Internet-related cause seeking funding sources. This scenario should examine how a fully independent ICANN could be held to its limited technical mission, and whether its fees and spending are subject to external accountability. 5. Scenario: ICANN attempts to add a new top-level domain in spite of security and stability concerns expressed by technical community leaders. This scenario actually came close to occurring when ICANN management did not respond to recommendations of its own Security and Stability Advisory Committee (SSAC) regarding risks of new TLDs interacting with security certificates and internal domains already in use. SSAC recommendations from prior years were not acted upon until late 2013, after significant pressure from a root server operator, Internet service providers, and system integrators. In the actual event, ICANN responded with a collision mitigation plan. This scenario should assess how proposed new accountability mechanisms could respond to similar technical risks expressed before a TLD delegation, as well as reactive responses to problems reported after a delegation. 6. Scenario: Governments in ICANN’s Government Advisory Committee (GAC) amend their operating procedures to change from consensus decisions to majority voting. Today GAC adopts formal advice according to its Operating Principle 47: “consensus is understood to mean the practice of adopting decisions by general agreement in the absence of any formal objection.”13 But the GAC may at any time change its procedures to use majority voting, where each government has equal voting power, such as in the UN and ITU. (Notably, only 61 governments were present at the GAC meeting in Singapore during March 2014, where several GAC members expressed dissatisfaction with the multistakeholder process and consensus threshold for new gTLD program advice.) While ICANN’s board is not strictly obligated to follow GAC advice, this scenario should assess how ICANN could respond to GAC advice with strong majority support but less than consensus. This scenario might also indicate need to amend ICANN bylaws regarding deference to GAC advice that is not supported by consensus. 7. Scenario: As described in scenario 6, the GAC might issue majority-supported advice instructing ICANN to suspend a TLD that refuses to remove domains with content critical of governments (e.g., .corrupt ). Today, this kind of censorship routinely occurs at the edge of the Internet when governments block domestic access to websites, such as Turkey blocking Twitter. This scenario envisions censorship moving from the edge to the core of the internet – the root table of TLDs used by the entire world. The stress test would ask how a proposed accountability mechanism could respond if a future ICANN board bowed to GAC advice for censorship at the root of the DNS. 8. Scenario: ICANN attempts to re-delegate a gTLD because the registry operator is determined to be in breach of its contract. The registry operator challenges the breach determination and obtains an injunction from a national court. What procedures or appeal mechanisms would be used by the entity charged with maintenance and publication of the root zone? 9. Scenario: A court grants an injunction against delegation of a new gTLD that’s a plural version of another TLD that has already been delegated. (for example, .hotels following after .hotel, or .coms following after .com) The court may have ruled on infringement of rights or on arbitrary and capricious behavior by ICANN, but that’s beside the point. The point of this scenario is to ask how a post-transition ICANN and IANA would be empowered to respond to a court injunction granted by a jurisdiction where ICANN has a legal presence. Would ICANN/IANA be able to defer a delegation until court proceedings were concluded? How would ICANN/IANA be accountable for its decision if it ignored the court injunction? 10. Scenario: A government telecom minister instructs ICANN to re-delegate a country-code top-level domain (ccTLD), despite objections from many current registrants and user communities in the country concerned. Faced with this re-delegation request, what response options and measures could be available to ICANN and the entity charged with maintenance of the root zone? -- Gregory S. Shatan • Abelman Frayne & Schwab 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/> _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship
As noted previously here and elsewhere, we can probably focus on the stress tests in red and consider the stress tests in black to be "out of scope" for our CWG. Greg On Fri, Nov 28, 2014 at 8:24 AM, Lindeberg, Elise <elise.lindeberg@npt.no> wrote:
Bertrand, all
When we discussed the “stress testing” in Frankfurt, we didn’t go into the details, but the way I see it this should primarily aim to evaluate the CWG model towards what we see as realistic tasks and possible complications that the IANA function operator could be facing in their day to day performance of the function as such - and to test if the model answers to those challenges in regards of the ability to timely and adequate reactions, - e.g. the mechanism to activate the independent appeals panels and make sure we have a show stopper before any final execution of any disputed decisions. Testing against scenarios where communities within the ICANN model change their composition or procedures for decisions I agree is more related to ICANN's functioning in general.
Best regards
Elise Knutssøn Lindeberg
Senior Legal Adviser, GAC representative
Networks Department
Norwegian Post and Telecommunications Authority
e-mail: ekl@npt.no
Mobile: +47 90190947
As of January 1st 2015 NPT will be known as the Norwegian Communications Authority.
*Fra:* cwg-stewardship-bounces@icann.org [mailto: cwg-stewardship-bounces@icann.org] *På vegne av* Bertrand de La Chapelle *Sendt:* 28. november 2014 13:45 *Til:* Greg Shatan *Kopi:* cwg-stewardship@icann.org *Emne:* Re: [CWG-Stewardship] Fwd: Stress Tests for IANA transition proposals
Steve DelBianco's contribution is very valuable and scenarios (or scenari) are useful thought experiments.
It is important however to distinguish what is related to the IANA stewardship transition per se and what is related to ICANN's functioning in general, even in the current situation. For instance a GAC evolution towards voting.
Steve seems to imply that the allocation of the IANA contract and the role of NTIA in individual request validations constitute a sufficient stopgap or nuclear sanction but I am not sure these scenarios would be easy to handle even in the current architecture.
Wotrh studying nonetheless.
B.
"*Le plus beau métier des hommes, c'est d'unir les hommes*", Antoine de Saint Exupéry ("*There is no greater mission for humans than uniting humans*")
BERTRAND DE LA CHAPELLE
Internet & Jurisdiction Project | Director
email bdelachapelle@internetjurisdiction.net
email bdelachapelle@gmail.com
twitter @IJurisdiction <https://twitter.com/IJurisdiction> | @bdelachapelle <https://twitter.com/bdelachapelle>
mobile +33 (0)6 11 88 33 32
www.internetjurisdiction.net
[image: Bilde er fjernet av sender. A GLOBAL MULTI-STAKEHOLDER DIALOGUE PROCESS]
On Fri, Nov 28, 2014 at 7:44 AM, Greg Shatan <gregshatanipc@gmail.com> wrote:
All,
Further to our recent discussions of stress tests, scenarios and the like, I am forwarding to the group an email from Steve DelBianco of the Business Constituency with a number of examples of stress tests and links to further discussion.
This is particularly relevant to RFP4 (which requests a "Description of how you have tested or evaluated the workability of any new technical or operational methods proposed in this document and how they compare to established arrangements") and RFP3 (to inform our discussion of various alternatives and their strengths and weaknesses).
Greg
---------- Forwarded message ---------- From: *Steve DelBianco* <sdelbianco@netchoice.org> Date: Tue, Nov 25, 2014 at 3:24 PM Subject: Stress Tests for IANA transition proposals To: "gregshatanipc@gmail.com" <gregshatanipc@gmail.com> Cc: Steve Metalitz <met@msk.com>, Tony Holmes <tonyarholmes@btinternet.com>, Phil Corwin <psc@vlaw-dc.com>, Aparna Sridhar <aparnasridhar@google.com>, "skawaguchi@fb.com" <skawaguchi@fb.com>, Jonathan Zuck < JZuck@actonline.org>, Kristina Rosette <krosette@cov.com>, Rick Lane < RLane@21cf.com>, Elisa Cooper <Elisa.Cooper@markmonitor.com>
Greg — as you requested on our call today, here are ’stress tests’ from the BC's June comments (link <http://www.bizconst.org/wp-content/uploads/2014/07/BC-reply-comment-on-Enhan...> to comments). The stress tests in a standalone doc are also available at http://bizconst.org/StressTests
Some of these stress tests relate to general ICANN accountability concerns. But several are relevant to the IANA role you are looking at for Naming Functions (Numbers 3, 5, 7, 8, 9, and 10, in red below):
The BC recommends use of scenarios, or ‘stress tests’ to help design and evaluate ICANN accountability structures and mechanisms. Today, ICANN is an effective organization that generally performs its core functions. Although it can be uncomfortable to imagine a scenario where a future ICANN fails dramatically or is confronted with a serious threat, we should consider challenging scenarios that could arise, such as those described below:
1. Scenario: ICANN unilaterally cancels the *Affirmation of Commitments*, which it may do with just 120 days notice. And if not outright cancellation, ICANN could refuse to implement recommendations of an * Affirmation *review. Presently, the discipline imposed by needing to win the IANA contract forces ICANN to adhere to the only external accountability it has today: the *Affirmation of Commitments*. If the *Affirmation *is to remain part of the new ICANN accountability framework, it is essential that the leverage formerly conveyed by the IANA contract be replaced with a new mechanism, which may or may not include parties external to ICANN.
2. Scenario: ICANN takes steps to eliminate its legal presence in a nation where Internet users and domain registrants are planning to seek legal remedies for ICANN’s failure to enforce contracts. This scenario is not about ICANN opening new offices around the world as part of its global outreach. Rather, it is about ICANN creating a new legal entity distinct from its present status as a California non-profit corporation, and eventually relocating its legal presence. ICANN’s current corporate presence in California creates legal certainty for businesses; presence in a new jurisdiction might not.
3. Scenario: ICANN becomes financially insolvent, due to lawsuits or gross mismanagement. However unlikely, this scenario should explore the orderly continuation of IANA functions and ICANN contract enforcement in the event ICANN could not maintain the necessary qualified technical resources.
4. Scenario: ICANN expands scope beyond its limited technical mission by using domain registration fees to fund grants for developing nations or other worthy causes. ICANN has the power to determine fees charged to TLD applicants, registry operators, registrars, and registrants, so it presents a big target for any Internet-related cause seeking funding sources. This scenario should examine how a fully independent ICANN could be held to its limited technical mission, and whether its fees and spending are subject to external accountability.
5. Scenario: ICANN attempts to add a new top-level domain in spite of security and stability concerns expressed by technical community leaders. This scenario actually came close to occurring when ICANN management did not respond to recommendations of its own Security and Stability Advisory Committee (SSAC) regarding risks of new TLDs interacting with security certificates and internal domains already in use. SSAC recommendations from prior years were not acted upon until late 2013, after significant pressure from a root server operator, Internet service providers, and system integrators. In the actual event, ICANN responded with a collision mitigation plan. This scenario should assess how proposed new accountability mechanisms could respond to similar technical risks expressed before a TLD delegation, as well as reactive responses to problems reported after a delegation.
6. Scenario: Governments in ICANN’s Government Advisory Committee (GAC) amend their operating procedures to change from consensus decisions to majority voting. Today GAC adopts formal advice according to its Operating Principle 47: “*consensus is understood to mean the practice of adopting decisions by general agreement in the absence of any formal objection*.”13 But the GAC may at any time change its procedures to use majority voting, where each government has equal voting power, such as in the UN and ITU. (Notably, only 61 governments were present at the GAC meeting in Singapore during March 2014, where several GAC members expressed dissatisfaction with the multistakeholder process and consensus threshold for new gTLD program advice.) While ICANN’s board is not strictly obligated to follow GAC advice, this scenario should assess how ICANN could respond to GAC advice with strong majority support but less than consensus. This scenario might also indicate need to amend ICANN bylaws regarding deference to GAC advice that is not supported by consensus.
7. Scenario: As described in scenario 6, the GAC might issue majority-supported advice instructing ICANN to suspend a TLD that refuses to remove domains with content critical of governments (e.g., *.*corrupt ). Today, this kind of censorship routinely occurs at the edge of the Internet when governments block domestic access to websites, such as Turkey blocking Twitter. This scenario envisions censorship moving from the edge *to the core of the internet *– the root table of TLDs used by the entire world. The stress test would ask how a proposed accountability mechanism could respond if a future ICANN board bowed to GAC advice for censorship at the root of the DNS.
8. Scenario: ICANN attempts to re-delegate a gTLD because the registry operator is determined to be in breach of its contract. The registry operator challenges the breach determination and obtains an injunction from a national court. What procedures or appeal mechanisms would be used by the entity charged with maintenance and publication of the root zone?
9. Scenario: A court grants an injunction against delegation of a new gTLD that’s a plural version of another TLD that has already been delegated. (for example, .hotels following after .hotel, or .coms following after .com) The court may have ruled on infringement of rights or on arbitrary and capricious behavior by ICANN, but that’s beside the point. The point of this scenario is to ask how a post-transition ICANN and IANA would be empowered to respond to a court injunction granted by a jurisdiction where ICANN has a legal presence. Would ICANN/IANA be able to defer a delegation until court proceedings were concluded? How would ICANN/IANA be accountable for its decision if it ignored the court injunction?
10. Scenario: A government telecom minister instructs ICANN to re-delegate a country-code top-level domain (ccTLD), despite objections from many current registrants and user communities in the country concerned. Faced with this re-delegation request, what response options and measures could be available to ICANN and the entity charged with maintenance of the root zone?
--
*Gregory S. Shatan **ï* *Abelman Frayne & Schwab*
*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/>*
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
-- *Gregory S. Shatan **ï* *Abelman Frayne & Schwab* *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/>*
participants (7)
-
Bertrand de La Chapelle -
Gomes, Chuck -
Greg Shatan -
Lindeberg, Elise -
Malcolm Hutty -
Olivier MJ Crepin-Leblond -
Sivasubramanian M