- CWG-Stewardship - lists.icann.org

Re: [CWG-Stewardship] [Cwg-rfp5] Reminder: Outreach Tracking for RFP5
by Alan Greenberg Dec. 6, 2014

Dec. 6, 2014

Thanks Cheryl. Alan At 05/12/2014 10:50 PM, Cheryl Langdon-Orr wrote: >Grace, you may already have this information >from someone else in ALAC or the Leadership >Team, but here is something on behalf of ALAC 'just in case'... > > >The ALAC and At-Large Community (Global with >representation from all 5 ICANN Geographic >Regions) has primarily acted through its >'At-Large Ad-hoc WG on the Transition of US >Government Stewardship of the IANA Function Work >Group'; there is a main wiki page which links to >all activities inclufding the weekly >teleconferences / meetings and in each of those >sub pages Agendas, Minutes/Notes, Meeting >Transcripts and Recordings in EN, FR, ES (at a >mininmum) is found ><https://community.icann.org/display/atlarge/At-Large+Ad-hoc+WG+on+the+Trans…>here >(https://community.icann.org/display/atlarge/At-Large+Ad-hoc+WG+on+the+Trans…) >this completely open to our Community WG was >formed for the purpose of both consultation and >support and feedback for our representation in >the ICG as well as other committees and WG's >related to this matter. The mission is stated >as "...The mission of this ad-hoc working group >is to discuss the transition of US Government >Stewardship of the IANA function in relation to >the discussions taking place in other fora such >as the IANA Stewardship Transition Coordinating >Group (ICG) and the discussions and processes >taking place in RIR, IETF, ISOC & IAB spaces. >Membership of this WG is open to all At-Large members. >â..."â > >Additionally this last weeks At-Large Capacity Building Program - 2014/15 our >Webinar was also on the Topic "IANA Functions >(Standards, Naming & Numbering)". The trainer >was Patrik FÃ¤lstrÃ¶m, Chair SSAC; Noting that >ALAC believes that a solid understanding of the >fundamentals of IANA Functions (based on the >recently released- Aug 15, 2014 SAC067) is >essential to ensure well informed deliberations, >debate and constructive community consultations... > >PLease let me know if we need anything further >from ALAC/At-Large or if something in a different format is required... > >Kindest regards, > > ><http://about.me/cheryl.LangdonOrr>Cheryl Langdon-Orr ... (CLO) ><http://about.me/cheryl.LangdonOrr> >about.me/cheryl.LangdonOrr > > > >On 3 December 2014 at 07:35, Grace Abuhamad ><<mailto:grace.abuhamad@icann.org>grace.abuhamad(a)icann.org> wrote: >Dear all, > >We've received information from ccNSO, GAC, and >RySG. That was included in the draft proposal >and on the Wiki. If you have any additional >information you'd like to share with the group, >please do so and we will include in future proposals. > >Best, >Grace > >From: Grace Abuhamad ><<mailto:grace.abuhamad@icann.org>grace.abuhamad(a)icann.org> >Date: Tuesday, November 25, 2014 11:18 AM >To: <<mailto:cwg-stewardship@icann.org>cwg-stewardship(a)icann.org> >Cc: RFP5 <<mailto:cwg-rfp5@icann.org>cwg-rfp5(a)icann.org> >Subject: Outreach Tracking for RFP5 > >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 > > > >_______________________________________________ >Cwg-rfp5 mailing list ><mailto:Cwg-rfp5@icann.org>Cwg-rfp5(a)icann.org >https://mm.icann.org/mailman/listinfo/cwg-rfp5 >

1 0

Re: [CWG-Stewardship] My concerns with the draft proposal and an alternative option
by Alan Greenberg Dec. 6, 2014

Dec. 6, 2014

Greg, My comments/replies. At 01/12/2014 01:22 PM, Greg Shatan wrote: >Alan: > >Thank you for your email. My specific thoughts >are inline below. I apologize for the length, >but I have tried to be as comprehensive as >possible within a reasonable timeframe. > > >On Sat, Nov 29, 2014 at 12:23 AM, Alan Greenberg ><<mailto:alan.greenberg@mcgill.ca>alan.greenberg(a)mcgill.ca> wrote: >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. > > >GS: I do not share your pessimism. Indeed, I >think that I have offered viable and sufficient >answers in this email, and others have done so in their responses as well. > >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. > > >GS: I think this is more accurately characterized as delegating. > >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. > > >GS: This is fairly simple to resolve. The >winning bidder must be required to indemnify, >defend and hold harmless the PRT. > >Whether it is possible to have such an empty >company do all this remains to be demonstrated. > > >GS: Contract Co. will need to have just enough >substance to accomplish these acts, all of which >are well within the bounds of corporate >authority. I see no reason why Contract Co. >could not do all these things, while remaining a >lightweight, constrained entity. > >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) > > >GS: There's no getting around the fact that >jurisdiction will be perceived as an issue, and >that it will need to be resolved. But that is >true of any solution other than an >"internal-to-ICANN" solution, which would keep >everything in the US (unless, of course, you >propose to move ICANN, which I am confident is >out of our scope. In any event, I don't think >that jurisdiction is as big an issue as some >would like to think it is. But that's just >me. Regardless, I don't think that jurisdiction >can be raised in the abstract. The specific >concerns raised by specific jurisdictions need to be explicitly stated. AG: I also do not believe that it is a "big" issue. But as long as it is not being dealt with explicitly, different people will make different assumptions and that can lead to problems later. >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). > > >GS: Obviously, we all need to work on >"connecting the dots" (i.e., filling in >details). As I've mentioned before, the >articles of incorporation and bylaws can be set >up so that Contract Co. is essentially compelled >to accept the decisions of the PRT with >virtually no discretion. The particular actions >that can and can't be taken by the directors can >be carefully limited and circumscribed. This is >quite commonly done when setting up corporations >for specific purposes. In some cases, it is >necessary that a company be "bankruptcy remote" >(also sometimes referred to as "bankruptcy >proof"). If so, there are a series of >prohibitions, covenants and approvals baked into >the bylaws that prevent the company from putting >itself in the position to be declared >bankrupt. There is also a prohibition against >the directors changing the bylaws to try to >defeat these prohibitions, covenants and >approvals. Similarly, corporations are set up >for specific purposes within the structure of a >private equity fund or hedge fund; these >corporations are also highly constrained in >their actions. This is all well trod ground. I >don't see how such a corporation could be >"captured" or controlled by another entity or a >government. However, without details of exactly >how you expect this corporation to be captured, >it is impossible to see whether this is a >credible threat at all, even before putting in >constraining and limiting controls. Without >details, "capture" -- like "jurisdiction" -- is >just a word being used as a bogeyman or a >rallying cry, stirring emotion but conveying no useful information. AG: You have demonstrated part of what I was saying. You have 20 years of experience in this areas and I have little. I started off the sentence with "Without details". My point was that the proposal must have far more detail in it to allow those of us who do not have vast corporate experience to have any faith in it. > >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. > > >GS: Until this point, I had thought you were >using the term "capture" metaphorically. Now I >fear that you are using it literally. I do not >think that Contract Co. needs to raise a >standing army or build a fleet of >battleships. Indeed, I can't think of an >instance where a corporation has resorted to >physical force to avoid "capture." I do >recognize that there are certain countries in >the world where companies have been >"de-privatized." We should avoid those. More >practically, it should be set forth as a >requirement that any respondent to an RFP must >not be a government or intergovernmental body, >just as NTIA required, and have protections in >place to assure Contract Co./PRT that it cannot later be captured. AG: In my mind, "capture" of PRT is far more likely. > >Contract Co. will not. > > >GS: It will not need to (especially the >battleships part). It will be set up to >eliminate opportunities for capture, and it will >have the protection of the rule of law. >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. > > >GS: I think that it is fairly clear that the >PRT has to be in a state of readiness in order >to deal with "non-periodic" events. On the other >hand, we don't want the PRT to feel the need to >justify its existence or fill monthly meeting >agendas or expand its scope. These can be >controlled by the PRT's organizing documents (perhaps a charter). AG: Clear to you and me, but less so to people who preached that it MUST not be standing and ready. That seems to have dissipated somewhat since I wrote this. >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? > > >GS: In terms of capture or malformation, I think >the answer lies first in the basic precepts of >"multistakeholderism," which I am a strong >believer in, even when I disagree with a >particular result. Broadly speaking, by >constituting the team from a diverse set of >stakeholder groups and organizations, which >formally select the members, you have de facto >checks and balances, as the members and their >organizations have different interests and are >keeping a wary eye on the organization to see if >is going adrift or being pulled out of >alignment. The composition of the group must >also be calibrated to avoid giving too much >power to anyone stakeholder group or set of >naturally aligned stakeholder groups. Finally, >you have to give the organizations the ability >to pull their representative if he/she goes >"rogue" (to borrow one of your suggestions for >the ICANN Board). In order to capture such a >group, you would need to capture enough members >to achieve consensus (i.e., a significant >majority, to say the least), which in turn would >mean capturing a series of diverse, disparate >and sometimes opposed groups and >organizations. I think this might have happened >in Star Wars -- but even in fiction, it took >three movies for Senator Palpatine to become >Emperor Palpatine, as well as acts of war to >suspend the multistakeholder model of the >Galactic Senate. I don't see this happening in >reality, unless the Dark Lords of the Sith are >among us. Seriously, though, I think we have to >have some faith in the multistakeholder model, >not just for the PRT, but for the future of Internet Governance generally. > >As for whether the PRT could be akin to the CWG >-- that does not imply that the PRT would be >under the ICANN umbrella. I think the point was >more one of composition. However, now that you >raise the point, this might be a valid >alternative. I think it is important to >distinguish between "ICANN the corporation" and >"ICANN the community". An ICANN >multistakeholder group is not the same as ICANN >the corporation, which what I think you refer to >when you say ICANN above. So, while ICANN the >corporation may not be "trusted to do it >properly," I have a much higher degree of >confidence that a multistakeholder group will, >whether or not it takes some shelter under the >ICANN umbrella. That does not mean these are >the only alternatives. The PRT could exist >without being aligned with any other >organization, it could be a committee under the >auspices of Contract Co., or it could even >become aligned with another existing organization (e.g., ISOC). >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? > > >GS: I believe I've answered this above. Any >further details on corruption or capture >scenarios would be appreciated (but leave out the battleships, please). AG: I am afraid that until we understand what entity it is that sets the rules for who may join the PRT (or whatever its current name is), and exactly what those rules are, we cannot be assured that it is a good flavour of multistakeholderism. We have seen examples where SOME people believe that the a group has a good multistakeholder balance, and others believe that they are either excluded, or other groups are disproportionately represented. It has happened in ICANN many times and continues to this day. It looks like MS, but on closer inspection, it may be extremely biased. The rules under which the PRT operates can also inappropriately favour one group's opinions over another, with little recourse. > >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)? > > >GS: I have my own opinions about the necessity >of the effort that the ICG took to ensure an >independent secretariat (but maybe they had the >time to turn to such efforts). Nonetheless, it >may provide some useful lessons on doing so, and >such things are always much easier the second time around. AG: I probably agree with you on the ICG. But for the PRT, it may, in my opinion, be FAR more important. I have personal experience (in ICANN) where the secretariat was not sufficiently independent and it had marked impact on the outcomes. > >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). > >GS: Assuming arguendo that PRT is not aligned >with any other body, Contract Co. could purchase >insurance to cover the PRT members, naming them >as additional insureds. By the way, has anyone >checked how we are protected from personal >liability and the possibility of being >sued? Does ICANN carry "multistakeholder >insurance?" I would also be curious to know >whether anyone in this group has been subject to >financial offers or personal threats in order to >capture them. I, for one, have not. A funny >thing, too -- in those instances where capture >occurs (say, soccer referees or baseball teams) >its usually pretty obvious when they go from >free will to puppetry. Now, when you get to >spycraft and other dark arts, it may be more >difficult, but I still think we are straying into the realm of fiction here. AG: Regarding insurance, in most cases within ICANN, internal bodies only make recommendations and it is the Board that takes action. So the potential for being sued as a participant is far less. I tend to agree that to the outsider, it may be obvious that capture has taken place. That does NOT mean that they may have the wherewithal to do anything about it. ANd regardless, by that time it may be too late. We have already said that thr PRTs instructions to Company Co. are sacrosanct. >Surely, the PRT, which is implicitly all >powerful, would need a new oversight mechanism >over it! And who oversees THAT oversight body? > > >GS: Surely not. First, the PRT is not all >powerful, implicitly or otherwise. Its members >must answer to their constituents. Similarly, >the oversight mechanism over the PRT is the >diverse collection of stakeholder groups and >communities, not a body. And no further body is >needed after that. The threat of "infinite oversight" is a myth. AG: The recursive oversight was not meant to be taken seriously. But the fairness of PRT decisions will depend on all of the questions regarding who oversees its creation, composition and how it operates, and how those may change over time. If Company Co. has no choice but to follow its instructions (which was a critical part of Company Co. not being capturable), this it IS all-powerful in this respect. >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. > > >GS: I personally agree that there should be >multistakeholder representation of some sort on >the CSC. But this is still an open issue. AG: And as long as it is open, with some people being adamant that it is just the registries, I worry. > >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. > > >GS: The NTIA currently monitors policy adherence >to an extent, at least with regard to >delegations and redelelegations. The Del/Redel >report must describe how the del/redel follows >existing policy. While we haven't nailed this >down yet, I believe that receiving and reviewing >Del/Redel reports goes to the CSC in the first >instance, and can be escalated to the PRT if >need be. As to whether the CSC will report that >policy is not being followed -- if it doesn't, >it risks destroying its own legitimacy. That's a pretty big risk to take. AG: It is hard to prove that someone didn't notice a problem. It all depends on how much they benefit. But what if the legitimacy IS questioned. As I see it, we are setting up this entire infrastructure with rules that it cannot be changed. How do we then "fix" any of it when it becomes obvious it is broken? The rigidity which makes us feel safe when we believe it is working properly becomes a liability when we desire change. > 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??). > >GS: The GNSO Council has in fact raised policy >concerns regarding various gTLD implementations >and proposals. I believe this is well within >its mandate, and it is worth considering whether >the GNSO Council should have standing to raise >these concerns to the PRT and/or the IAP. AG: It would need standing AND staffing. >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. > > >GS: In that case, it may be more appropriate >for these to be members of, rather than liaisons >to, the CSC. However, I would note that >liaisons do have the power of persuasion, which >you used quite effectively on the GNSO >Council. Finally, I would doubt that the CSC >would be able to act by simple majority, AG: I have no doubt that on occasion my powers of persuassion on the GNSO Council may have changed outcomes. I can give you instances where the lack of formal standing on the Council resulted in significant problems (from an At-Large perspective). >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)? > > >GS: I agree that funding is an aspect that needs >more attention. But the fact that we haven't >yet turned to this in detail does not disqualify >the proposal in any way. Contract Co. is >granting ICANN a valuable right -- the right to >perform a valuable service. If ICANN paid a fee >for that right, it would not be out of the >goodness of its heart. There's no such thing as >a free lunch. I'm confident that we will find a >way to deal with this, given the value that is inherent in the IANA Functions. AG: Again, I need to see a proposal that is not shot down by one player or another. It doesn't have to be the final answer, but we do need a proof of concept. >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? > > >GS: I disagree with this assumption entirely as >I said to Holly earlier. The NTIA is looking to >transition stewardship of the IANA Function to >the global multistakeholder community, not to ICANN. AG: No point in arguing this since we are not privy to the internal discussions. The NTIA focus on "ICANN accountability" sends a pretty strong message to me. >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. > > >GS: My crystal ball is at least as cloudy as >yours, but I predict that a proposal that failed >to transition NTIA's role to the global >multistakeholder community, and instead >transferred it directly into the hands of ICANN, >would be far more likely to be unacceptable to >the US government. This could be the "internal >to ICANN" concept's fatal flaw. AG: Or its strength! ;-) >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). > > >GS: This may be true, but we would be betraying >our mandate and our constituents if we decided >that our aim was to please the Board. In any >event, I have faith (perhaps more than you) that >the Board isn't going to try to stop a >disfavored proposal. That would raise quite a >ruckus, if ICANN the corporation were to turn on >ICANN the community. Remember, this is not just >one SO or AC, which the Board may choose to >ignore at some peril. We are the massed army of >stakeholders (unless, of course, we are riven by >division, which would be far more than >unfortunate -- as Milton notes elsewhere, the >vultures are circling, and if the Board has >indigestion, that is the least of our worries. >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. > >GS: It might be difficult; it might not. As you >note, names is differently situated than the >other two areas. Therefore, a one size fits all >approach was always unlikely. By creating >Contract Co. and the PRT, we are actually closer >to the model of the other two areas, which >should make integration easier, not harder. >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. > > >GS: I think you probably meant to say IANA at >the end of each of those paragraphs, rather than ICANN. AG: Yes, correct. Sorry. > In any event, I understand the concept of > leverage here. I think we exercise that > leverage along the lines that the two CWG's > work is "interrelated and interdependent" and > that Stream 1 accountability has to be resolved > before there is a transition. We can't try to > reform all of ICANN ourselves from the > platforrm and mandate of transitioning NTIA > stewardship. That would be massive mission > creep. There is a careful balance here in > using the IANA Transition to ensure that > Enhanced ICANN Accountability is not just an > empty phrase, but that balance is lost if we > put forth a plan that does not really > transition NTIA's roles and that reaches far > beyond our mandate in order to enact major > reforms. We cannot do the job of the ICG or > the Accountability CWG, but we do depend on them both to do their jobs right. > >Furthermore, I don't think Contract Co. is the >status quo. The NTIA is controlled by the US >Government. Contract Co. is controlled by the >multistakeholder community. What makes you >think we will sit on our collective hands? Also, >I anticipate that the contract will have more >"teeth" in it to enforce accountability >(including termination for breach, which is >absent from the current NTIA agreement except in >extremely narrow circumstances). AG: I would not advocate the internal-to-ICANN route to effect ICANN accountability. That WOULD be extreme mission creep (mission-lope?). But if it were to occur as a side benefit, I think that everyone would benefit. I guess I don't see much difference between termination for breech and termination at end-of-term (except the former is likely to be more likely disputed in court that the latter, and thus less likely to occur. >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. > > >GS: I disagree for the reasons stated >above. We in this CWG may have lost that major >opportunity, but the ICANN community has not >lost that opportunity. It's right next door in >the Accountability CWG. What we have not lost >is the ability to use our leverage judiciously >to support the "interrelated and interdependent >efforts" of the CWG Accountability. And they >way we can lose that is to be overtaken by >internal divisions, failing to meet our >timeline, and squandering our >legitimacy. Frankly, I don't think that is >what's happening here -- there's a reason that >ICANN consensus is "rough" -- some divergence is >expected, but the show must go on. Only where >this true divergence (i.e., no view >predominates) or strong opposition.does the show >not go on. While I agree with Chuck that a >formal consensus call is premature, I think that >in the fullness of time and through our >continuing good faith efforts, we will get there in good shape. >Alternative > >Simply criticizing the current CWG draft >proposal is not particularly useful without alternatives. > > >GS: Alternatives can be helpful. So can >suggestions for improvement. These can come >from adapting certain aspects of alternatives, >as has already happened. It can also happen >when people who look for problems also look for solutions. > >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. > > >GS: I disagree, and I think this >mischaracterizes both the proposal and the work >that led to it. The framework of the CWG draft >proposal is there first to replace the NTIA's >roles. As you will recall, we spent a couple of >hours defining the various roles that NTIA >currently performs in relation to IANA. The CWG >structure was then fit to those roles. Dealing >with non-performance is built into the framework >as well, but it is hardly the sole reason for it. AG: I guess we will disagree here. I see the potential that ICANN will not be able or willing to do the job the ONLY reason for building this new beast. Why else if not for the ability to move the contract outside of ICANN? > >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. >o >GS: I think that you have taken your boat of >the CWG's waters with this >statement. Accountability is part of our >responsibility, but it is accountability >relating to the IANA Functions. Using that >responsibility to try to re-make ICANN from our >group is a massive overreach. We (individually) >can be part of that grander effort by >participating in the CWG on Accountability, and >as a group, by maintaining that Stream 1 must be >resolved before the transition takes place. AG: As I say in my next paragraph, these are not proposals for the IANA CWG to consider or recommend. That is indeed way out of our scope. But I have repeatedly heard that there is and will be NO way to control the ICANN Board (and that leads to the implicit lack of trust in ICANN). There is indeed no way to control the ICANN Board at the moment. A number of decisions related to New gTLDs demonstrate that in spades. The purpose of the preceding paragraphs and the ones that follow are simply to demonstrate that with just a modicum of imagination, there ARE ways that the Board could be reasonably controlled, and that given sufficient motivation the Board might agree to such changes. >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. > > >GS: I think your second and third suggestions >might have a place in the work of our group, and >perhaps the one about GAC advice related to IANA >(but the motivation for that suggestion is still >fuzzy to me). The rest of these fall outside >our mandate. If we were watching an ICANN Board >Committee with our mandate use that mandate to >remake broad swaths of ICANN governance with no >direct relationship to IANA, the multistakeholder howls would be deafening. > >What I found most disappointing when I reached >the end of this email for the first time, was >that there is really no proposal here. AG: You are correct. I did neglect to explicitly put my proposal in here. BUt I have spoken of it a number of times and you yourself alluded to it earlier in your replies. To be explicit, it is the option of the NTIA tranfering responsibility to ICANN instead of to Contract Co. as in the CWG proposal. > As noted above, we noted several roles (we > called them "functions" in Frankfurt, but I > think that leads to confusion with the IANA > Functions) that the NTIA plays and that need to > be replaced in some form (not necessarily on an > exact parallel basis, but they need to be dealt > with and their raisons d'etre need to be > considered and carried through to any > proposal). For convenience, I will repeat our list of NTIA roles below: > >#1 APPROVAL FUUNCTION OF CHANGES TO THE ROOT ZONE > >#2 - PERFORMANCE REVIEW FUNCTION > >Periodic Review > >Transactional Performance review (SLAs) > >Perform (technical) audits and customer surveys > >#3 - CONTRACTING FUNCTION (ability to enter into a contract) > >Determining the substance of the contract > >Award / renewal of contract > >Understand what stakeholder concerns are > >Issuance of RFPs > >Contracting > >Ability to seek public comments > >#4 â ENFORCEMENT OF THE CONTRACT FUNCTION (incl. renewal/rebidding) > >Termination of contract; > >Ability to enforce > >Ability to seek public comments > >Ability to determine whether contract should be >terminated, including hearing of complaints > >Listen to community and act on its behalf > >Regrettably, I think your Alternative skips over >all of this, perhaps due to eagerness to fix >ICANN (which many of us are eager to do in one >way or another). Unfortunately, joining this >CWG meant that we must deal with "nuts and >bolts" issues relating to the NTIA's transition >of its role to the global multistakeholder >community. Your email is devoid of any >resolution for replacing these functions >currently carried out by NTIA. There are a >variety of resolutions that can be imagined in >an "internal to ICANN" proposal -- jobs to be >taken over, processes to be built or adapted, >documents to be written, working groups to be >formed, dispute resolution procedures to be >crafted, These could be configured in a number >of different ways. Unfortunately, you have not >provided us with a framework for any of >this. Certainly, an "internal to ICANN" >proposal would match up to each of these points >in ways that are not quite as obvious as the >current CWG proposal. For instance, in the >absence of a contract, "determining the >substance of the contract" is not directly >applicable. However, the contract is the >vehicle for setting forth ICANN's obligations >regarding IANA. Without a contract, these >obligations need to go somewhere, as does the >ability to enforce them. So the "substance" >still needs to be determined -- it just won't be >in a contract (not likely anyway, but it's your >proposal). Who will make this determination? >How will this be vetted through multistakeholder >processes? What document will contain this >substance? How will it be enforced? I could go >on, but I'm sure you get the point. > >So, I'm not sure what your Alternative is, but >it is not an alternative to the CWG >Proposal. If this were a Venn diagram, the two >circles would be barely overlapping. As I >stated in another thread "I don't think an >"internal to ICANN" proposal was ever put on the >table within the group prior to Frankfurt in any >kind of tangible, concrete fashion." I will add >now that I think that an "internal to ICANN" >proposal still has not been put on the table >within the group in any kind of tangible, >concrete fashion -- which leaves us dancing with >ghosts -- something out of which no progress can be derived, unfortunately. AG: You are correct, I did not address how each of the current NTIA roles (except for issuing the contract which would now be moot) would be carried out. The CWG proposal leaves out many details and I did not feel it was worth my time given that there was little likelihood of the CWG changing direction at this point. A large part of my problems with the CWG proposal is all of the complexity and various bodies that are required to be able to remove ICANN from the equation. That the internal ICANN model does not NEED these is part of its strength. I can comment on a few details just to demonstrate that I have thought this through. The critical part is how would ICANN be held to actually doing the details of the job. That would require Bylaw (or some document linked to the Bylaws, I am not a corporate attorney) changes to lock in the details of the commitment. They could not be changed without MS involvement and examples of such mechanisms were discussed above. If ICANN through its Board either consciously decides, or through inaction to not follow what is now in its Bylaws (ie the "contract"), the MS community could effectively replace a critical part of the Board (or whatever mechanisms the Accountability CCWG Stream 1 would recommend). If such a threat is not sufficient to making the Board comply, it can be carried out (EXACTLY as with Contract Co. threatening or actually pulling the contract). The CWG does not yet have closure on whether all of the NTIA backstop functions need to be done (my personal belief is that they do). In the ICANN model, the decision would also be required. Presuming the answer is that they are needed, we would need to decide which could be done internal to ICANN (but separate from the IANA group) and which would need to be outsourced/delegated to some external body. I could go on, but I honestly don't think that it is worth my time right now. If there is ANY interest expressed in this model, I would be happy to continue. Alan >Greg > > > >_______________________________________________ >CWG-Stewardship mailing list ><mailto:CWG-Stewardship@icann.org>CWG-Stewardship(a)icann.org >https://mm.icann.org/mailman/listinfo/cwg-stewardship

2 1

Reminder: Comments on WorkPlan due Friday 5 December at 23:59 UTC
by Grace Abuhamad Dec. 5, 2014

Dec. 5, 2014

All, Just a reminder that the Chairs have asked for any comments/suggestions to the work plan to be submitted by Friday 5 December at 23:59 UTC. I've reattached their note and copied it here below for your convenience. Best, Grace IANA Stewardship Transition Cross Community Working Group (CWG) on Naming Related Functions Work plan update from the CWG co-chairs for members and participants Lise Fuhr & Jonathan Robinson The Chairs recognize the great amount of work that has been done drafting the proposal sent out for consultation and we thank the group for the effort. However, given the demanding schedule we still need to work with, we cannot rest on our laurels if we are to meet our next major objective of having a submission ready for the chartering organizations by 19 January 2015. As per our plan we are presenting 3 webinars on the public consultation document this week. Given 2 of these webinars are on Thursday 4 December 2014 and would be book-ends to our working group meeting and that your co-chairs will be presenting the webinars, we felt this was too much. As such we are cancelling the Thursday 4 December meeting of the CWG and hope that those that have questions on the proposal will attend the webinar. Although the 4 December meeting is cancelled, we are posting this new schedule of meetings to allow us to reach our objective, which will include continuing our CWG meetings during the holiday period: * *  Thursday 10 December 2014 – 11:00UTC * *  Thursday 18 December 2014 – 11:00UTC (Time change from 14:00 to 11:00) * *  Tuesday 23 December 2014 – 14:00UTC - hour to be confirmed * *  Tuesday 30 December 2014 – 14:00UTC - hour to be confirmed. * *  Thursday 8 January 2015 – 11:00 - UTC - hour to be confirmed * *  Saturday 10 January – Time TBC (New additional meeting inserted) * *  Thursday 15 January 2015 – 14:00UTC - hour to be confirmed. * * In addition to the above, we now need to focus our efforts on the tasks that still need to be completed in order to meet our next objective. To this end we would propose the following schedule:  Public consultation o Prepare weekly reports on the public consultation for the CWG – Support staff. o Prepare a final report and analysis of the results of the public consultation for the CWG for the 30 December meeting – Support staff. o Review by the CWG of the results of the public consultation and identify action items resulting from – 30 December meeting. o Draft and post the results of the public consultation per the results of the CWG review – 5 January – Staff support.  RFP3 – Contract Co. o Obtain formal legal advice regarding viability of concept and initial requirements – GS and volunteers. o Contract details  Review key terms and make decisions regarding these after details of the MRT are settled.  RFP3 – MRT  RFP3 – CSC  RFP4 o Complete functional analysis and derived requirements – GS and Staff will prepare a report for CWG consideration at its 10 December meeting. o Composition requirements - GS and Staff will prepare a report for CWG consideration at its 10 December meeting. o Structural (internal functional) requirements - TBD o Support requirements (secretariat etc.) - TBD o Bootstrap requirements – TBD o Complete functional analysis and derived requirements – GS and Staff will prepare a report for CWG consideration at its 10 December meeting. o Composition requirements – CWG (10 December 10). o Structural (internal functional) requirements – CWG (10 December). o Support requirements (secretariat etc.) – CWG (10 December). o Bootstrap requirements – CWG (10 December).  RFP3 – Independent Appeals Panel o Wait for results of public consultation.  RFP5  RFP6 o Complete a list of proposed changes from RFP3 (confirmed and optional) that are to be considered in this section –Staff (5 December) o For each proposed change in the previous list identify which of the elements of RFP4 apply and have to be developed to meet the requirements. Present report to CWG – RG, SM (10 December). o Prepare a complete evaluation for one of the simple proposed changes for presentation to the CWG on 10 December – RG, SM. o Present additional elements at each of the following meetings of the CWG on December 18, 23, 30 - RG, SM. o Present a final draft at the 8 January meeting of the CWG. o This work will be completed by the drafting team when the other elements are being assembled. o Is being developed by staff with the help of the various communities. A draft of this is Section C of the public consultation document. This should be completed in the final drafting sessions in the week of 12 January. Furthermore the Principles need to be finalized and this is to be done by 10 December. They will be sent out for comments as soon as possible. We realize that this is a demanding schedule and acknowledge the commitment required of members, participants and staff in working within this schedule, especially as it impacts on the calendar year end holiday season for many. Comments, suggestions and improvements to the proposed schedule are welcome but please provide these as soon as possible and in any event by 23:59 UTC on Friday 5 December 2014. From: Jonathan Robinson <jrobinson(a)afilias.info> Organization: Afilias Reply-To: Jonathan Robinson <jrobinson(a)afilias.info> Date: Wednesday, December 3, 2014 9:11 AM To: "cwg-stewardship(a)icann.org" <cwg-stewardship(a)icann.org> Subject: [CWG-Stewardship] Workplan update from the CWG co-chairs for members and participants All, Please see attached for a work plan update from the CWG co-chairs for members and participants and including detail on proposed meetings and times (some of which have changed). Note: Tomorrow’s meeting of the CWG (4 December 2014, 14:00 UTC) will no longer go ahead as planned. Please check the attachment for full details. Thank-you, Lise Fuhr & Jonathan Robinson

4 3

Do we really need a Contracting Co.?
by Bertrand de La Chapelle Dec. 5, 2014

Dec. 5, 2014

Dear Greg, In your response to Holly you mentioned something that might be worth exploring further regarding the need of a new Contracting Co. : they (BPC: the parameters and numbers people) have existing organizations that are not ICANN that can be used for that oversight function. Names does not have that. Two questions then come to mind: 1) IETF has a MoU with ICANN, but unless I am mistaken (and I can very well be), it is not incorporated. I don't remember if the NRO has a similar arrangement, but I do not think it is incorporated either. Doesn't this open the possibility of arrangements without having to create a Contract Co., with all the recursive accountability and jurisdiction concerns we discussed? 2) The absence of an independent structure for names (potentially including distinction between ccTLDs and gTLDs) is indeed a clear difference between the names group and the two others. The gNSO however is the policy forum for gTLDs and all gTLDs are represented there. Would anything prevent the gNSO Council on its own (ie: without validation from the ICANN Board) to have a MoU with he IANA operator? Some specific role (to be determined) could be given to the Registry constituency in that decision-making process, given their high stake in the functioning of the IANA. On the cc side, it is true that the ccNSO does not encompass all ccTLD operators. Still, the ccNSO and the GAC have jointly developed the "Framework of Interpretation" for ccTLD delegation-redelegation and once finally approved, it will apply to all ccTLDs in the context of the IANA function. So, in the absence of an external exhaustive collective of all ccTLDs, isn't the ccNSO de facto acting as the policy structure for ccs in what regards the IANA functions? Why couldn't it then as well be making a MoU with the IANA operator, without involvement of the ICANN Board? The "contracting" architecture would thus be based on a *simple set of four MoUs*, without the need of a new Contracting Co. Upon signature of these four arrangements, NTIA would just let the current contract expire, without having to formally transition its responsibilities to a new entity. Each of these MoUs would contain common clauses regarding the renewal or rescinding of these arrangements (regular intervals, compulsory RFPs or not, etc... as discussed) and an ad hoc procedure put in place for choosing the contractor. Such a procedure could include the setting up of an ad hoc group (cf. the notion of a PRT) at the regular renewal intervals or upon situation of crisis, with appropriate triggers and decision-making rules. I wonder if this approach would not alleviate the need for creating a new structure and build upon the existing structures within ICANN, without conferring the contracting role to ICANN the organization (which I agree makes little sense). I noted with interest the response by the IETF and its clear message that the current architecture is OK with them. I am a bit worried if the proposals from the names group were to require a complex new architecture that would be very different from the one envisaged on the parameters and numbers sides, making reconciliation of the proposals a bit harder. I hope this helps explore practical options. Please tell me if this is not workable and why a shell company would be a better (or necessary) solution. Maybe there is something I am missing here. Best Bertrand "*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(a)internetjurisdiction.netemail bdelachapelle(a)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]

14 51

CWG - Public Comment summary for Thursday December 4th
by Bernard Turcotte Dec. 5, 2014

Dec. 5, 2014

No submissions were made on Thursday December 4th. B.

1 0

authorization function for ccTLDs
by Milton L Mueller Dec. 4, 2014

Dec. 4, 2014

I have some questions regarding this: "The CWG is considering replacing the authorization role, at least with regard to ccTLDs, with a written opinion from counsel (independent of ICANN) that each delegation and re-delegation request meets the policy requirements cited in the publicly posted reports." Where would this counsel come from? Whose counsel is it if it is independent of ICANN and ICANN is supplying the IANA service? Since most of the policy requirements related to ccTLD delegation/redelegation are not laws, but things like RFC 1591, on what basis is the counsel's opinion made? Precedent? Milton L. Mueller Laura J. and L. Douglas Meredith Professor Syracuse University School of Information Studies http://faculty.ischool.syr.edu/mueller/mueller/Home.html

11 15

Reminder: Call Cancelled Today
by Grace Abuhamad Dec. 4, 2014

Dec. 4, 2014

Dear all, Just a reminder that the CWG call originally scheduled for today was cancelled. Best, Grace From: Jonathan Robinson <jrobinson(a)afilias.info> Organization: Afilias Reply-To: Jonathan Robinson <jrobinson(a)afilias.info> Date: Wednesday, December 3, 2014 6:11 AM To: "cwg-stewardship(a)icann.org" <cwg-stewardship(a)icann.org> Subject: [CWG-Stewardship] Workplan update from the CWG co-chairs for members and participants All, Please see attached for a work plan update from the CWG co-chairs for members and participants and including detail on proposed meetings and times (some of which have changed). Note: Tomorrow¹s meeting of the CWG (4 December 2014, 14:00 UTC) will no longer go ahead as planned. Please check the attachment for full details. Thank-you, Lise Fuhr & Jonathan Robinson

1 0

Re: [CWG-Stewardship] CWG - Public Comment summary for Wednesday December 4th
by Bernard Turcotte Dec. 4, 2014

Dec. 4, 2014

All, No new submissions yesterday. B.

1 0

Questions about implementation
by Avri Doria Dec. 4, 2014

Dec. 4, 2014

Hi, While we continue to discuss and wait for the chartering group and ICG decisions, we need to look at implementation. As I understand the situation, we not only need to have a notion, a workable notion, it needs to be one that can be in place and shown as solid before the current contract periods ends. I.e there needs to be an address for this to transition to. I am not sure which part of out plan this is done in. The hardest part to set up in my mind is Contract Co. - this neeeds legal advise on how we develop this holding entity. The MRT and CSC should be relatively easy, but first we have to agree on their compositions and we see that it takes a few months to get a cross community setup established. We do need to boootstrap this thing if we want it to serve as the transition mechanism. Also one recommendation I have heard, based on McCarthy's accusations that we are just trying to put ourselves in charge ourselves, that we pledge not to take a role in the intial implementation of the MRT and CSC that we create - makes it easier to argue that we are just not trying to create power for ourselves. Does this make sense to others? avri

1 0

Re: [CWG-Stewardship] CWG - Public Comment summary for Wednesday December 3rd
by kurt＠kjpritz.com Dec. 4, 2014

Dec. 4, 2014

1 0