November 2014 - CWG-Stewardship

Comments on draft Section 3 and Annex
by Matthew Shears Dec. 3, 2014

Dec. 3, 2014

Hi, Some comments on the current draft: * How will non-performance related questions be escalated from the CSC? At the moment their mandate is performance issues and the proposed CSC composition lends itself more to performance than policy escalation. o No matter the liaison role of the SO ACs, I would suggest that policy issues can/should also be raised directly with the PRT. * How will the PRT be composed, how often will it meet, etc.? o Representation on the PRT should reflect but also be broader than ICANN (additional independent experts) otherwise I believe we will not have satisfied the key criteria of "support(ing) and enhanc(ing) the multistakeholder model". The PRT should meet annually to review overall IANA operator performance and any policy or other concerns. It should also be convened on an ad hoc basis to address policy or performance issues as they arise or are escalated. * Should the CSC assume the responsibilities of the current NTIA Contracting Officer? I would have through that this should reside with the PRT. (we may need further elaboration on this particular role at NTIA, etc., and where it would best sit.) * The draft has some contract duties assumed by both the PRT and CSC - is this deliberate? C.5.1., C.5.2 and C.5.3. for example. * Do we believe that the role described in the current contract (sections C.3. and C.5.3.) related to the audit of security provisions can be undertaken by CSC or the PRT? * It still remains unclear how the Contract Co could "take action" per the request of the PRT if the contracting Co. is not staffed, etc. And, does it need to be a corporation? We advice on this asap. otherwise we will have to consider another model. * Is the IANA function to have independent legal counsel (per the proposal)? And will that legal counsel role need to have a more expanded role than delegation and re-delegation issues? * Annex 3 already points to a model for contract options including up to two options to extend. I do not recall there being any consensus or agreement on the structuring of the contract or extension options and this section should be reworded accordingly - for example to state that all contract details such as length, options to extend, etc., are TBD. (I do recall that there was some sense of the room that the amended contract should remain with the current operator after the transition for a limited period of time again TDB.) * In Annex 3 there needs to be a careful reread - see below for examples: o It reads "ICANN to Provide Qualified Program Manager" and should read "Contractor....." o Why does the CSC approve contractor personnel changes? Surely it should the PRT as responsible for contracting issues? o Shouldn't the Final Report and Acceptance and Inspection be for the PRT? There seems to be some lack of clarity in the Annex as to what roles/functions are CSC or PRT? o Again C.6 and C.7 should be PRT, not CSC, issues and are identified as such in the section 3 text. Same issue with C.8 and E. Finally, I share a number of the concerns voiced on the list over the past couple of days. In particular there are many critical details yet unresolved. We may rue not addressing these now. On the issue of accountability, I am pleased to see that the Co-chairs of the two WGs are meeting and believe that we need to quickly align as best possible these two work streams. If, as is likely, the amended contract remains with ICANN for some period of time after the transition the recommendations from work stream 1 (and 2) of the Accountability WG are and remain critically important no matter what happens after the initial contract period. Matthew -- Matthew Shears Director - Global Internet Policy and Human Rights Center for Democracy & Technology (CDT) mshears(a)cdt.org + 44 771 247 2987

4 3

My concerns with the draft proposal and an alternative option
by Alan Greenberg Dec. 3, 2014

Dec. 3, 2014

As I have mentioned during the F2F meeting in Frankfurt and on the most recent teleconference, I have significant problems with the proposal currently on the table. I am taking this opportunity to present my concerns in somewhat more detail, and I will also present what I believe to be a viable alternative. The ideas presented are my own, but I do know that they are largely shared by my At-Large colleagues and by some others in the community. I am also quite aware that my alternative options are likely to be vehemently opposed by some. I should also add that there are aspects of the current draft CWG proposal that I strongly support. The Independent Appeals Panel is perhaps the most important one. Overview Many of my concerns are due to the large number of "details" that are, as yet, unspecified. Perhaps some of my concerns will be negated once there are sufficient answers, but I have the nagging feeling that for many, there will be no viable answer. This message will necessarily be long - my apologies for that. Contract Co. Many of the issues surround the "entity" (as it was referred to in Frankfurt). The draft somewhat glibly says that it will only sign the contract. But it seems to be outsourcing much of its responsibility to the Multistakeholder Periodic Review Team (PRT), and that seems problematic. Perhaps the intent is not that all of these things go to the PRT, but there does not seem to be anywhere else for the functions to go. Among the tasks that it has outsourced are consultation regarding the contents of future RFPs, RFP issuance, RFP evaluation, contract negotiation and contract enforcement. What it cannot outsource is addressing legal issues such as being sued by a bidder who failed for win the contract and other such possibilities. Whether it is possible to have such an empty company do all this remains to be demonstrated. I will deal with problems with this outsourcing under the PRT. The jurisdiction under which the company is registered has been the subject of some discussion. Clearly there are those who feel that under no conditions can it be the US. At the same time, there are some indications (such as terms in the Kelly bill) that imply that the US Government may not be willing to accept anything other than the US. Note that I understand that the Kelly bill itself may wither and die, but to quote Milton Meuller, "We should also pay attention to it because the bill provides a very good benchmark for preparing for the kind of questions that the NTIA is likely to be asked after they get a complete proposal from the ICG and begin to implement it. The Kelly bill can be considered a list of the concerns that US-based interests are going to be using to assess the final proposal. The GAO Report is equally important in this regard. Ignore them at your peril." (E-mail to the CWG-Stewardship list on 23 Nov 2014) Without details of exactly how this corporation will exist, it is impossible to assure oneself that it cannot be captured or controlled by some entity or government(s). Running IANA will be a treasured target by some countries and we do not know what lengths they would go to capture the contract. NTIA had the strength of the US (and its battleships and such) behind it. Contract Co. will not. There has been no discussion about how this entity, or any part of the overall proposal, is funded. More on this later. Multistakeholder Periodic Review Team (PRT) The PRT is effectively the operational arm of Contract Co. It is the entity that makes decision for Contract Co., presumably including those related to the RFP, contract negotiations, contract enforcement and much more. But by its very name, it is Periodic. It does not exist at all times and there are some in the community that have said it should be re-constituted afresh every time it is needed (perhaps like the Phoenix born from the ashes of its predecessor). I fail to understand to how it can take action on problems if it is not an ongoing entity. The description says that it is a "body" with representatives selected by the relevant bodies. Accepting that "relevant" is to be decided later, it is unclear under whose auspices this body is convened, and how we can ensure that it remains free from capture or malformation. It was suggested in Frankfurt that this body could be akin to (or even identical to) the IANA-CWG, but given that the entire concept of this elaborate infrastructure is to allow ICANN to be completely excluded from the IANA management process, presumably because it has ceased to carry out this function as well as all parties claim it is now doing, what makes us think that ICANN would take responsibility for this, or more to the point, could be trusted to do it properly? So how this body, which is the critical keystone [http://en.wikipedia.org/wiki/Keystone_(architecture)] on which this entire superstructure depends, constituted, and funded. And how does one ensure that it is not corrupted, or captured? Or sued. A body as large as it will have to be will require infrastructure such as a secretariat - how do we ensure that IT is not subverted (just look at all the effort that has gone into ensuring an independent ICG secretariat)? And without a corporate backing of the PRT, its members would be personally liable in the case of a lawsuit. Who would want to serve on such a group? Moreover, in an environment where the PRT is taking very significant decisions, both financial offers and personal threats would be an effective method of capture (and presumably this is all volunteer work, or at most a modest stipend). Surely, the PRT, which is implicitly all powerful, would need a new oversight mechanism over it! And who oversees THAT oversight body? Customer Standing Panel (CSC) It is unclear exactly what this body monitors. If it is JUST service levels committed to by IANA, the composition may be ok. But if it is also responsible for ensuring that IANA is following policy, then the composition MUST reflect the multi-stakeholder body or bodies that created such policy. You cannot presume that the customers, who may have been vehemently opposed to any specific policy, will report that such a policy is not being policy. If the CSC is NOT monitoring adherence to policy, then who is? It does not seem to be covered in the proposal. During e-mail discussions, someone said it was the job of the (for the gTLD space) GNSO. But it does not have the staff or Bylaw mandate to do so, nor would it have any standing to complain to whoever it is that would attempt enforcement (the PRT??). There is reference to Liaison from ACs and SOs on the CSC. In the ICANN context, a Liaison has no power other than that of persuasion. They have no power to act if they are in disagreement with the majority of the full members. Cost Cost has been mentioned briefly above, but it is a significant issue. Aside from the costs of the infrastructure we are discussing here, there is the cost of IANA. Currently this is funded by ICANN. If ICANN were to be taken out of the picture (and the possibility of doing that is the ONLY reason for building all of this), where does the funding come from? From ICANN, out of the goodness of its heart, despite no longer having ANY control over how much money is demanded or how it is spent? By the gTLD registries, who have said they would likely fund THEIR part of the costs, but not the entire thing. By the ccTLDs who have clearly said we should not depend on them (with a few exceptions)? Acceptability The last time I heard Larry Strickling talk about the stewardship transition, he said it would only take place if sufficient controls were put in place to address ICANN messing up (i.e., in the extreme, a rogue Board). That PRESUMES that it is ICANN at the centre of the IANA stewardship - why else would we care about ICANN accountability if ICANN were not involved. From that, my take is they envision the IANA responsibility being transferred to ICANN. The Kelly bill clearly presumes this as well - why else would it be attempting to put so many constraints on ICANN? It is not at all clear that a proposal such as one that the CWG has put in this draft would be acceptable to the US government. It will certainly not be a favoured proposal from the point of view of the ICANN Board (who may not have a direct say in this but cannot be totally ignored either). Integratability The ICG will be tasked with integrating the CWG proposal with that of the RIRs and the IETF. Although this is clearly their job and not ours, I have always believed that one needs to look ahead to ensure that there are no impassable roadblocks ahead. We do not definitively know what those proposals will be, but indications are emerging. Both bodies seem to be happy with how ICANN is managing IANA, but both feel that in the event of any untoward action, they could move the responsibility associated with their areas somewhere else. Since in both cases, it is the same body that sets the policy that would judge it, no great complexity is involved. In ICANN's case, since the bodies that set policy in the names space are (to a large extent) an integral part of ICANN, they cannot take action against their "parent" (so to speak). Thus this cumbersome alternative. Integrating these two approaches may be difficult. Lost Opportunity Part of the IANA Stewardship Transition is to put in place suitable ICANN accountability and governance changes so as to ensure the continuity of the IANA function. If all of the questions posed here, and the ones raised by others are addressed, we would end up moving from a situation where an entity (the NTIA of the US government) awards the IANA contract. The contract is currently held by ICANN but in theory at some future date, it could be awarded to some other organization, removing ICANN from any operational connection to ICANN. The new situation would be where Contract Co. awards the IANA contract. The contract will initially be held by ICANN but in theory at some future date, it could be awarded to some other organization, removing ICANN from any operational connection to ICANN. Notice the parallel wording. ICANN really has no motivation to change to effect this change. And in all likelihood any change associated with this transition will be minimal. If we go down the path of the current draft CWG proposal, I believe that a major opportunity will have been lost to reform ICANN. Alternative Simply criticizing the current CWG draft proposal is not particularly useful without alternatives. My alternative is certain to not please some of the parties in this discussion, but I believe that it is both possible and viable. All of the complexity of the CWG draft proposal is there to cover the eventuality that ICANN suddenly or gracefully stops performing the IANA function to the satisfaction of the community. That was indeed the situation a number of years ago, and ICANN took effective action to rectify the problems (that is, the NTI did not have to yank the contract to fix the problems). At the moment all parties seem to agree that there are no significant outstanding major problems, certainly none that could justify a change in the status quo. But there is a recurrent fear of "what if". What if ICANN had the IANA responsibility in perpetuity and stopped caring. Or had a Board that deliberately and without community support took action or inaction to harm how the IANA functions are carried out (the "rogue Board scenario). These worst case alternatives are indeed possible. And since under the current ICANN Bylaws, the Board is effectively sovereign, little could be done short of changing the Board over a period of 3+ years. I suggest that there are ways to alter ICANN's Bylaws to allow the effective control of an out-of-control Board. These mechanisms will not be particularly appreciated by the ICANN Board, but I believe that such measures (or something similar) would be adopted if that is what is required to be granted IANA. There are a number of components that I will describe. They are not necessarily a complete or even the correct set. Putting in place a complete set of cohesive recommendations is what the Accountability CCWG is being convened for. But the existence of the following as a starting point, I believe, demonstrates that there IS a way to proceed forward. - ACs and SOs must be given the ability to recall their sitting Board member. There will be no need to await the end of the current 3-year term. - Certain classes of decision regarding IANA can only be made with (for an example) a supermajority (2/3) of the Board's maximum Bylaw-mandated membership approving the decision. Without the bulk of the AC/SO Board members, there will not be a critical mass of Board members to take such a decision. - Certain classes of decision regarding IANA may only be made after notification period and public comment. This would allow the ACs and SOs sufficient time to act to recall their Board members - It is possible that the composition of the Board might need to be slightly altered to ensure that a recall of most but not all AC/SO Board members would be effective in halting action. Or a higher threshold than supermajority might be needed. - Bylaws regarding GAC advice related to IANA might need to somewhat altered to compensate for the GAC not having sitting Board members. - Similarly, non-affiliated ccTLDs would need to be worked into the equation. - If allowed under California law, the Bylaws could be require that under certain circumstances, a Board decision could be appealed to an external body (similar to the proposal's Independent Appeal for IANA decisions) and that the decision would be binding and enforceable in courts.

14 46

Concern with Contract Co.
by Avri Doria Dec. 1, 2014

Dec. 1, 2014

Hi, I think this has exactly a 180 degree wrong approach > . Contract Co. -- This is a not for profit company whose only function > is to be signatory to the contract with the IANA Functions Operator. > As such this entity would have no staff. I think that this should have nothing but staff, a minimal staff of one or two I.e it should have a neutral Administrator that does what the PRT tells her to do in terms of the contract adminstration, and perhaps a backup/aise. It could also be the Root Zone Management Process Administrator as that is a clerical staff function. avri

16 41

Fwd: [Ianaplan] I-D Action: draft-ietf-ianaplan-icg-response-06.txt
by Olivier MJ Crepin-Leblond Nov. 29, 2014

Nov. 29, 2014

FYI -- if any of you have spare cycles to read the draft of the IETF proposal. Kind regards, Olivier -------- Forwarded Message -------- Subject: [Ianaplan] I-D Action: draft-ietf-ianaplan-icg-response-06.txt Date: Wed, 26 Nov 2014 07:50:29 -0800 From: internet-drafts(a)ietf.org To: i-d-announce(a)ietf.org CC: ianaplan(a)ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Planning for the IANA/NTIA Transition Working Group of the IETF. Title : Draft Response to the Internet Coordination Group Request for Proposals on the IANA protocol parameters registries Authors : Eliot Lear Russ Housley Filename : draft-ietf-ianaplan-icg-response-06.txt Pages : 30 Date : 2014-11-26 Abstract: This document contains the IETF response to a request for proposals from the IANA Stewardship Transition Coordination Group regarding the protocol parameters registries. It is meant to be included in an aggregate proposal that also includes contributions covering domain names and numbering resources that will be submitted from their respective operational communities. The IETF community is invited to comment and propose changes to this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ianaplan-icg-response/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ianaplan-icg-response-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ianaplan-icg-response-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Ianaplan mailing list Ianaplan(a)ietf.org https://www.ietf.org/mailman/listinfo/ianaplan

2 1

Re: [CWG-Stewardship] Concern with Contract Co.
by Alan Greenberg Nov. 29, 2014

Nov. 29, 2014

In Frankfurt we used the term "entity" as if it was something other than some for of company or corporation. We have now replaced it with "corporation". Others assure me that a corporation is possible with no Board or members or owners or shareholders or officers or bank account, but I have yet to fully understand how this works. I will be addressing some of this in my comments, hopefully later tonight. Alan At 28/11/2014 06:32 PM, Greg Shatan wrote: >Olivier, > >I'm not sure exactly what you mean by the >"configuration" of Contract Co. We certainly >have discussed the "form" the entity would take, >i.e., a nonprofit corporation. Place of >incorporation has not been significantly >discussed in recent days, though we had a number >of email exchanges and some discussion of >jurisdiction earlier in a variety of contexts. > >Greg > >On Fri, Nov 28, 2014 at 6:19 PM, Olivier MJ >Crepin-Leblond <<mailto:ocl@gih.com>ocl(a)gih.com> wrote: > >On 28/11/2014 16:36, Milton L Mueller wrote: >> >> >> >> >> >>From: >><mailto:cwg-stewardship-bounces@icann.org>cwg-stewardship-bounces(a)icann.org >>[mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Bertrand de La Chapelle >> >>Is the idea of a contract Co. a done deal? >>Establishing any organization with whatever >>limited staff is usually a recipe for its growth in time. >> >> >> >>MM: The idea that there should be a contracting >>entity separate from ICANN is, I believe, a >>done deal. It reflects some of the principles >>we agreed on (such as separability) and the >>general agreement that, as the draft proposal says, >> >>âThe current arrangements provided by the >>NTIA for the oversight and accountability of >>the IANA Functions are generally satisfactory >>and the objective of the CWG is to replicate >>these as faithfully as possibleâ > >This is not at all how I understood it. The >discussion on whether the "contracting entity" >should be a contract co. or something else has >never been touched - certainly no alternatives have been seriously considered. > >> >> >>MM: On the other hand, whether the specific >>configuration of the Contract Co. is optimal >>for achieving those purposes could still be >>open. I would say is still open to >>_modification_; any modification that >>accomplishes the agreed objectives but avoids >>any problems that might arise would be welcomed by the CWG I imagine. > >The configuration of the Contract Co. has not >been discussed either. We know what functions >should be undertaken and what broad >characteristics would be needed. No discussion >of jurisdiction nor configuration of the entity >has been done except on RFP4 call today where we started to touch on it. > >Kind regards, > >Olivier > >_______________________________________________ >CWG-Stewardship mailing list ><mailto:CWG-Stewardship@icann.org>CWG-Stewardship(a)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 > ><mailto:gsshatan@lawabel.com>gsshatan(a)lawabel.com > >ICANN-related: <mailto:gregshatanipc@gmail.com>gregshatanipc(a)gmail.com > >www.lawabel.com >_______________________________________________ >CWG-Stewardship mailing list >CWG-Stewardship(a)icann.org >https://mm.icann.org/mailman/listinfo/cwg-stewardship

3 4

Chairs' Statement with progress update and route ahead
by Jonathan Robinson Nov. 29, 2014

Nov. 29, 2014

All, Please see attached a Chairs' Statement with progress update and route ahead. Thank-you. Lise Fuhr & Jonathan Robinson

3 2

Outreach Tracking for RFP5
by Grace Abuhamad Nov. 28, 2014

Nov. 28, 2014

Dear all, On behalf of the RFP5 subgroup, we'd like to start collecting information about the consultations within communities that have taken place to date. This is in order to validate the NTIA requirements and principles. Please reply with an outline of your community consultations to date and/or a description of your outreach efforts to date. We will compile this information and provide it to the RFP5 subgroup for review. Best, Grace

3 2

Fwd: Stress Tests for IANA transition proposals
by Greg Shatan Nov. 28, 2014

Nov. 28, 2014

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(a)netchoice.org> Date: Tue, Nov 25, 2014 at 3:24 PM Subject: Stress Tests for IANA transition proposals To: "gregshatanipc(a)gmail.com" <gregshatanipc(a)gmail.com> Cc: Steve Metalitz <met(a)msk.com>, Tony Holmes <tonyarholmes(a)btinternet.com>, Phil Corwin <psc(a)vlaw-dc.com>, Aparna Sridhar <aparnasridhar(a)google.com>, " skawaguchi(a)fb.com" <skawaguchi(a)fb.com>, Jonathan Zuck <JZuck(a)actonline.org>, Kristina Rosette <krosette(a)cov.com>, Rick Lane <RLane(a)21cf.com>, Elisa Cooper <Elisa.Cooper(a)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-Enha…> 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(a)lawabel.com <gsshatan(a)lawabel.com>* *ICANN-related: gregshatanipc(a)gmail.com <gregshatanipc(a)gmail.com> * *www.lawabel.com <http://www.lawabel.com/>*

7 10

Notes & Action items from today's meeting
by Marika Konings Nov. 27, 2014

Nov. 27, 2014

Dear All, Please find below the notes and action items from today's meeting. As a reminder: * Everyone is requested to contribute to questions that would need to be called out as part of the public comment forum. Deadline for all input on the questions & draft proposal - no later than Saturday 29 November at 12.00 UTC. Co-chairs will have the authority to take that input and formulate the questions and issues that CWG wants input on. (for your convenience, you'll find the latest version of the draft proposal attached) Best regards, Marika Notes 27/11: Welcome & roll call * Roll call will be taken from Adobe Connect Review of F2F meeting * Good representation and participation both from members as well as participants (over 40 participants) * Substantial progress made, including framework for responding to RFP3 * Chairs statement published after the meeting to communicate outcome of meeting more broadly Update from RFP4 * First call earlier this week on RFP4 - awaiting outcome of RFP3 * Considering how to move forward on items 1 and 2 which may be less dependent on RFP3 * Next call scheduled for Friday 28 November at 13.00 UTC. * What is expected from RFP4 as part of the publication of the draft proposal on 1 December? Review Draft Proposal Section 3 Comments * ALAC to provide written comments - concerns regarding jurisdication of contracting entity (problematic to find one); capture of whole process; costs - how is this entity going to be funded, especially if ICANN shouldn't be part of the picture; integration problems with other proposals; who convenes PRT, prevent capture; likelihood of acceptance by NTIA. Basically some of the components have questions that do not have obvious answers - several of these together may question the overall proposal. * Consider calling out some of these questions out as part of the public comment forum. For example, jurisdiction of contracting authority; formation of PRT; stress test idea - are there any items in the structures that leave it open for capture; * Not useful to raise acceptability to the NTIA unless it relates to the criteria set by the NTIA. * Focus on acceptance by naming community - ICG will worry about how it fits together with other proposals. * How will contracting entity take action if it has no staff? Actions could be delegated to PRT or administrator / secretariat function for contracting entity? Principle is that PRT provides oversight and direction to Contracting Entity. * Paper is a starting point - there are issues that will need to be addressed, but having a document will allow for soliciting input. * Focus should be on finding solutions for issues identified, not just calling issues out. Work from within the group, not from the outside. Need to be part of the dialogue. * Contracting entity questions: jurisdiction, staffing to carry out its responsibilities, who will be paying for it, is it a viable plan? PRT would be responsible for taking actions. Regarding funding, various models could be explored. * Contracting entity - formal legal authority. Created with very limited mandate. In articles and bylaws it would have prohibition against changing bylaws unless certain steps are taken that involve the PRT/multistakeholder community. * Consider opening different email threads on questions identified * Need some independent legal contracting expertise to provide input - should be started now. How can indepenent legal advice be obtained and funded? * Accountability - chairs will meet with co-chairs of the accountability CWG to discuss linkage and commence co-ordination between two groups. * Approval function - may no longer be necessary. Has the proposal thought the issue through, also per the discussions on the mailing list. May be another issue to be called out as part of the public comment forum. * Proposed modifications to the document as well as questions that need to be called out as part of the public comment forum - objective of today's conversation. * Need to agree on sign-off moment for chairs to publish document * Flag open issues / questions - either in document or as part of public comment forum. * Transition implications could be an other area to solicit input on. * Is it possible to flesh out composition of PDT and relationship to customer standing committee as part of draft proposal? See also comments from Avri on the mailing list. Could be convened on short notice if issue arises, but probably formally convenes once a year? Would need to define number of seats, not necessarily which individuals would occcupy those seats, but will need to be multistakeholder. Term 'periodic' may be misleading as PRT is expected to be reactive between formal review moments. * CSC focused on direct customers, possibly with a couple of additional experts /liaisons (non-registry per se, but experts in technical / operational issues that may occur in the execution of the IANA functions). Scope and deliniation between CSC and PRT should be further defined. * Guide public comments on preferred way these should come back to facilitate review by CWG. * Need to define who has standing to appeal to independents appeals panel. * Monitoring of how policy is implemented - how is that done? * Agreement to keep on moving on the current timetable, although consideration will need to be given with regards to the linkage with the accountability work. Action item: contribute to questions that would need to be called out as part of the public comment forum. Deadline for all input on the questions & document - no later than Saturday 12.00 UTC. Co-chairs will have the authority to take that input and formulate the questions and issues that CWG wants input on. Webinars * Co-chairs leading / presenting, supported by RFP Leads * Will be scheduled for: * 3 December from 7:00 - 8:30 UTC * 4 December from 12:30 - 14:00 UTC * 4 December from 16:00 - 17:30 UTC * All CWG members and participants encouraged to participate and promote webinars

1 0

Customer Service Panel mandate may be too limited
by Avri Doria Nov. 27, 2014

Nov. 27, 2014

Hi, in reading the draft I have an issue with the mandate of the CSC, but it may be just a clarification question. > . Customer Standing Committee (CSC) - The CSC would receive IANA > Operator reports, evaluate these for the PRT and the community at > large and escalate any significant issues to the PRT. The CSC, which > would report to the PRT, would be primarily made up of a small number > of representatives of registry operators, as well as liaisons from > other SO/AC's and potentially other stakeholder groups (exact > composition to be determined). I see this as a system alarm feature. They review that status of the function in a steady state model and raise alarms when there are problems that need to be dealt with. While I think that customer issues, such as SLAa, are cricially important I think we may need other alarms such as: - stability and security alarms - root server issue alarms - implementation inconsistent with established policy alarms. I think that fact that this group has a multistakeholder composition is important in perhaps resolving this. What I think may be more importnat is to make sure that these multistakeholder liaisons and reps are experts with the expereince to be able to spot these issues and raise the alarm flag on issues beyond SLA based customer issues. While the draft does not explicitly preclude raising these sorts of issues, the predominantly customer focus may limit the perceived mandate. Since the PRT is both intermittent and not necessarily in a position to notice these issues, they would need to be raised by someone. They could be raised by the larger community, but that channel will be unpredictable and probably have a low signal to noise ratio. I thus think these sorts of considerations should be included in the CSC ([concerns] standing committee?) avri

1 0