- CWG-Stewardship - lists.icann.org

Fwd: [CCWG-Accountability] Regarding Board treatment of the output of the Cross Community Working Group on Enhancing ICANN Accountability
by Greg Shatan Dec. 16, 2014

Dec. 16, 2014

All: I thought that Bruce Tonkin's email a short while ago on the CWG-Accountability list would also be of interest to people on this list. Greg *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/>* ---------- Forwarded message ---------- From: Bruce Tonkin <Bruce.Tonkin(a)melbourneit.com.au> Date: Sun, Dec 14, 2014 at 6:23 PM Subject: [CCWG-Accountability] Regarding Board treatment of the output of the Cross Community Working Group on Enhancing ICANN Accountability To: Accountability Cross Community <accountability-cross-community(a)icann.org > Cc: "Alissa Cooper (alcoop(a)cisco.com)" <alcoop(a)cisco.com> Hello Kavouss, >> In addition to what I informed you before is that , Under WS 1 they already agreed to the terms and conditions as stipulated in the Board Resolution adopted in LA I.E. ALLOWING THE BOARD TO VETO the content of the accountability whereas in case of ICG we have clearly mentioned that the Board should not modify the ICG work and send it as it was received to NTIA .However, should the Board has any comment, they may send it separately to NTIA In case of CWG and WS1 of CCWG, it is not the case. >From my understanding there are two separate but related activities. The IANA Stewardship Transition Coordination Group (ICG) is developing a proposal to send to NTIA for the IANA transition. This proposal could incorporate the output of this Cross Community Working Group on Enhancing ICANN Accountability. The ICANN Board's liaison on the ICG - Kuo Wei Wu - has conveyed to that group that the Board will send the report onto the NTIA without making any changes. The Board will send an accompanying letter which will either endorse the report, or it will express concerns that will already have been shared with the ICG through the various opportunities for public comment and dialogue. This Cross Community Working Group on Enhancing ICANN Accountability is developing recommendations for improvements of ICANN's accountability. These improvements can be made irrespective of whether the NTIA chooses to change its role with respect to the IANA function. The Board of ICANN is committed to making continuous improvements in its accountability mechanisms. The ICANN bylaws are clear on how the Board will approve policy recommendations from the supporting organisations (GNSO, ASO and ccNSO), but there is no explicit material in the bylaws for how the Board will process recommendations directly from a cross-community working group. The Board resolution passed in Los Angeles ( https://www.icann.org/resources/board-material/resolutions-2014-10-16-en#2.d) was intended to set clear expectations for how the recommendations would be treated. The assumption is that the Board will approve the recommendations from this group, and implement those recommendations. If the Board feels that it would not be in the public interest to implement a particular recommendation it has set out a process for working with the Cross Community Working Group on Enhancing ICANN Accountability to resolve the matter. The Board will not make any changes to a recommendation or report from this group. It is up to the CCWG to make or change any of its recommendations. Separately, I expect that the NTIA could make the ICANN Board's approval and implementation of improved accountability mechanisms proposed by this group as a pre-condition to any transition. I hope that helps. Regards, Bruce Tonkin ICANN Board Liaison to the Cross Community Working Group on Enhancing ICANN Accountability _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community(a)icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community

3 3

Next RFP 4 Call - Tuesday 16 December 15:00 - 16:30 UTC
by Robert Guerra Dec. 15, 2014

Dec. 15, 2014

The next RFP 4 call, is Tuesday 16 December 15:00 - 16:30 UTC. Grace will send call in details shortly. In the meantime, please mark your calendars accordingly. To have a more structured and productive session tomorrow, I will be sending a proposed agenda, revised timeline, as well as additional background material later today to the RFP 4 list. regards Robert >

1 0

CWG - Public Comment summary for Friday, Saturday, Sunday December 12, 13, 14th
by Bernard Turcotte Dec. 15, 2014

Dec. 15, 2014

All, No new submissions since Friday. B. >

1 0

Re: [CWG-Stewardship] Strickling Remarks from 4 December re IANA Transition and Accountability
by Alan Greenberg Dec. 15, 2014

Dec. 15, 2014

At 13/12/2014 11:18 AM, Gomes, Chuck wrote: >Thanks a lot Alan for responding. Please see my comments inline below. > >Chuck > >From: Alan Greenberg [mailto:alan.greenberg@mcgill.ca] >Sent: Thursday, December 11, 2014 4:22 PM >To: Gomes, Chuck; Greg Shatan; Maarten Simon >Cc: cwg-stewardship(a)icann.org >Subject: RE: [CWG-Stewardship] Strickling >Remarks from 4 December re IANA Transition and Accountability > >At 11/12/2014 10:28 AM, Gomes, Chuck wrote: > >Allan, > >I want to comment on a few of the points you make in the exchange below. > >1. ". . . the ICANN board has a rather >powerful reason for being flexible and >accomodating". Am I correct that that reason >is the risk of losing the IANA functions? If >so, I would agree but I would also point out >that for that risk to be real it seems to me >that there must be some entity that could >reassign those functions. For now that is >NTIA. What would it be if NTIA goes away? > >The powerful reason I was referring to is I >believe (and I have no guarantee that it is >supported by the majority of the Board, although >I have had some discussions) that a solution >that gives IANA to ICANN (requiring significant >accountability changes that would implicitly >reduce their absolute power) would be far more >palatable the Contract Co model where instead of >internal accountability, we have the threat of >external action (ie breach of the contract going somewhere else at some point). >[Chuck Gomes] Is there a word missing in â. . >. would be far more palatable the Contract Co >model where instead of internal accountability, >we have the threat of external action (ie breach >of the contract going somewhere else at some >point)â. I donât understand what you intended to say. AG: Yes, there was a word missing, two actually. Removing the parentheticals to improve readability: The powerful reason I was referring to is THAT I believe that a solution that gives IANA to ICANN would be far more palatable THAN the Contract Co model where instead of internal accountability, we have the threat of external action. To be clear, it is my belief that if the Board were presented with two options: 1. The CWG Contract Co model; 2. The ALAC model with IANA being given to ICANN and ICANN accepting significant loss of Board autonomy related to IANA; that the Board would pick option 2. I also believe that this would be the preference for NTIA as well. If you want the rationale for that, see the start of my reply to Jordan Carter on https://community.icann.org/x/YoEHAw, about 3/4 down the page. >2. "It is SO attractive to label ICANN as >unchanging and inflexible, but current evidence >does not bear that out." Can you share any >cases where ICANN has been flexible about giving >the Board the final say on a decision? > >No. Today they have ultimate say over pretty >much everything EXCEPT where they accept binding >arbitration to resolve contract disputes. The >Bylaws were written to give the Board such full >power, and there has never been a reason for >them to give any of that power up. This, I believe, is such a reason. >[Chuck Gomes] Agree. > > > >3. "I actually have faith that the >Accountability CCWG can come up with effective >accountability measures that ICANN will be >obliged to accept if it is exchange for keeping >the IANA function" I hope you are correct but >I have serious doubts that that will happen >unless there is a real risk of them losing the >IANA functions and a refer back to 1 above. > >I see VERY little accountability changes to >adapt to the Contract Co. model. Other than the >IAP, ICANN is going from one contracting entity >(NTIA) to another (Contract Co,) both of whom >can make a decision to reassign the IANA >contract in the case of poor performance or >whatever reasons the contact may allow. To fix >the IANA problems a number of years ago, ICANN >took measures to ensure that IANA was >professionally managed and at this stage is >doing a fine job (by all reports). ICANN did not >fix the IANA problems with accountability >measures but with standard good management >practices. I think it would do the same under >contract assignment by Contract Co. >[Chuck Gomes] I would like to think that as well >but shouldnât we have a mechanism in place if we are both wrong? If we are wrong, then either the the Accountability CCWG will through up their hands and give up, which means the proposal is dead, or they come up with something that is unacceptable to the Board (I think their Recs go there, but not really sure), or they come up with something that is judged insufficient by the NTIA and the proposal is dead. The Contract Co. proposal will not have much problem with the Accountability CCWG because so little is needed (see my note to Jordan), but I think the chances are high that it will be rejected by the NTIA either on overall dislike of the model, or some of the many "details" (including cost and funding) will not provide sufficient certainty that it will work and continue to work. Either way has it's potential for failure. I've made my choice on which I believe is more likely to succeed. >The ATRTs have managed to make incremental >changes that have enhanced accountability, but >virtually none that really change how decisions >are made and the involvement of MS in those >decisions. Certainly ATRT2 TAKLKED about some >such real changes, but they basically did not >fly because we got clear messages that the Board >would resist them and we backed off. >[Chuck Gomes] Agree. > > >Accountability will be forced upon ICANN (in my >mind), only if it is in exchange for something >it really wants. And IANA is one such thing. >[Chuck Gomes] Agree. As an add-on thought. The IANA issue is probably not sufficient to immediately fix all accountability issues (ie Track 2 of the CCWG), but if we push through the IANA-centric ones, that will open the door (I think the expression is that the ideas will have been "socialized" and not longer so foreign). Once the Board accepts that it is not all-powerful, I think that the rest will be a lot easier - perhaps not easy, but easier. Alan >Alan > > > >Chuck > > > >From: ><mailto:cwg-stewardship-bounces@icann.org>cwg-stewardship-bounces(a)icann.org >[ mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Alan Greenberg >Sent: Wednesday, December 10, 2014 9:32 PM >To: Greg Shatan; Maarten Simon >Cc: <mailto:cwg-stewardship@icann.org>cwg-stewardship(a)icann.org >Subject: Re: [CWG-Stewardship] Strickling >Remarks from 4 December re IANA Transition and Accountability > >At 10/12/2014 02:53 PM, Greg Shatan wrote: > >Maarten: > >My answers are inline below. > >Greg > >On Mon, Dec 8, 2014 at 5:46 PM, Maarten Simon ><<mailto:maarten.simon@sidn.nl>maarten.simon(a)sidn.nl> wrote: >Hi Greg, >Although I personally have not made up my mind >as yet if the contract co or an internal ICANN >solution is preferable, I have posted a very >rough idea for an internal solution in another >thread that I have not seen your response to. I >repeat it here as I am interested to here from >you if you think it would be legally possible >(apart from the fact that you probably do not support it for other reasons): >ÃÂ¢If we could arrange via the bylaws that >the ICANNNNNN board explicitly has to follow orders from a MRT-like structure, > >GS: This is a pretty big "if." Unlike Contract >Co., which would be built from the ground up to >be a corporation with very limited purpose and >goals and limitations upon its directors and >officer, and thus lends itself to this >"following orders" model, ICANN is an existing >organization with a large board and officer >group and many activities. At best, this type of >organization does not lend itself to such a >model. At worst, it's not even possible. But >let's assume, solely for the sake of argument, >that the ICANN bylaws can be modified in this >fashion. I am assuming that the MRT will be >"internal-to-ICANN" like the current SOs and ACs >(and in contrast to the ICG). Is that >correct? If so, how do you involve the global >multistakeholder community (beyond ICANN) as required by the NTIA? > >AG: >I will no doubt echo some of what Olivier has >said, despite Milton having explained that he is wrong. > >Yes, it is more difficult to retrofit such >measures into the existing ICANN, but then the >ICANN board has a rather powerful reason for being flexible and accomodating. > >It is not clear how "internal" an MRT would be. >It would be organized under the auspices of >ICANN. Whether it "reports" to ICANN is >something else altogether. The relationship >between the IETF and ISOC might be a good model. >ISOC provides funding and perhaps legal >protection but I don't think that we could say >that the IETF is internal to ISOC or controlled by it. > >The ICG and the Stewardship CWG have >representation from outside of ICANN. Yes, >Milton points out that they were created due to >pressure and conditions set by the NTIA. As >above, the desire to retain IAINA is a mighty >big carrot to continue the tradition.ICANN >partially funded NetMundial, and completely >different form of MS event and it did so without US government pressure. > >It is SO attractive to label ICANN as unchanging >and inflexible, but current evidence does not bear that out. > > > >we might not need a contract but have an (internal) MoU/SLA or whatever. > >GS: There really is no such thing as an >internal MoU/SLA. Both of these are agreements >(just like the IANA Functions Contract), and >need to be made between two or more legal >entities capable of contracting. If the >MRT-like structure is internal to ICANN, it >can't have a contract with ICANN -- that would >be ICANN contracting with itself. The >"whatever" would have to be an internal document >of a non-contractual/non-agreement >nature. Conceivably, it could be a policy. If >it is a policy, it would most likely have to go >through an ICANN Policy Development >Process. Would this be done separately by the >ccNSO and the GNSO under their separate PDP >guidelines? Or would we try to put together a >joint PDP Working Group? And how long would >this PDP take to develop an "IANA Functions Policy"? > >The other thing the IANA Functions Contract >establishes is that the right to run the IANA >Functions ultimately resides in Contract >Co. ICANN's right to do it is purely >contractual; essentially, ICANN is a licensee, >and the MRT is a a licensor. Under this >scenario, the current IANA Contract goes away, >and ICANN is left holding the right to perform >the IANA Functions. This means that the IANA >Functions are now an inherent right of >ICANN This is a very different overall set-up, >with different consequences. Losing a right one >has by contract is a very common problem, and is >as old as contracts. Losing an inherent right >and sector of services because a committee says >that you have failed to live up to internal >policies is both very uncommon and very novel, >creating considerable uncertainty even if it is a technical possibility. > >AG: >I have no clue as to the legal issues involved, >but apparently ICANN can sign a MoU with an >internal body. The relationship between ICANN >and the At-Large regional At-large Organizations >(RALOs) are established through MoUs. And >although you presume that the MRT would be >wholly internal to ICANN, that is a premise in your mind, but not mine. > >Yes, without Contract Co, ICANN has the right to >continue performing IANA functions. That >provides a level of stability that the >possibility of moving it (potentially every 5 >years if some people have their way). But if the >MRT can direct how that is done, that may not be >so bad. And It is not inconceivable that the MRT >could direct ICANN to divest itself of IANA in extreme situations. > > > >If the ICANN board would at a certain moment in >time still decide not to follow orders of the >MRT, I would assume it may be sued by affected >parties for violating its own bylaws. > >GS: Litigation should be a last resort, not a >first resort, when it comes to >enforcement. Contract Co. can terminate the >contract (or decide not to sign another one when >it expires). The MRT has no such ability. That >is why you are suggesting litigation -- which is >not an "internal-to-ICANN" solution at all. In >addition to not being "internal-to-ICANN," >litigation (in any jurisdiction) is expensive, >lengthy and consumes great time and resources, >and may not produce a result in any kind of >useful timeframe. In any event, who are the >"affected parties" that would sue? Is it only >one registry, or is it many? What if it's a >stakeholder group, such as "civil society"? If >there are many litigants, they would need to >enter into some sort of joint litigation >agreement, form a coordinating group and deal >with a whole host of other things. And not >every affected party has a litigation war chest >to go up against ICANN -- unlike Contract Co., >which will be indemnified. I don't think there's >any way that ICANN would agree to indemnify, >defend and hold harmless every "affected party" >that might challenge a decision relating to IANA >Functions. So, litigation funding would be a very real issue. > >Finally, I'm not at all sure that the "affected >parties" will have the standing to sue ICANN for >violating its bylaws. This might be a right >that a shareholder would have if ICANN had >shareholders (but nonprofits don't have >shareholders). Third parties may not have a >cause of action here on that front, and would >need to find some other theory that supports a >lawsuit. By contrast, breach of contract >litigation is fairly straightforward (not that >I'm supporting litigation before other forms of escalation are exhausted). > >We further may dictate in the bylaws that ICANN >has to give up the IANA function if decided by >this MRT and of course seal it by dictating that >these specific articles may only be changed with >the explicit consent of the MRT.ÃÂ¢ > >GS: Agaain, I'm not at all sure we can dictate >in the bylaws that ICANN has to "give up the >IANA function if decided by the MRT." (By >contrast, it's quite clear that ICANN can enter >into enforceable obligation if it signs an >agreement with a third party.) But again, let's >assume it for the sake of argument. In your >scenario, it is implicit that the right to >perform the IANA Functions is an inherent right >of ICANN, not a right granted to it by a third >party. So instead of Contract Co. terminating >an agreement, we have the ICANN Board being >instructed to cause ICANN to cease part of its >services. I am much more skeptical that this is >a realistic assumption, especially since it >could run counter to the fiduciary duty of the >Directors to ICANN. (By contrast, I don't see >the MRT instructing Contract Co. to do something >counter to Contract Co.'s interests, given the >limited scope and purpose of Contract Co.) But >let's go on. The concept of ICANN "giving up" >the IANA functions is quite nebulous. Since >it's an inherent right of ICANN's, ICANN would >have to run the RFP to find the next IANA >Functions Operator. Are you assuming that the >MRT will do this as well, rather than ICANN? >That seems like another big assumption. And >what exactly would ICANN be transferring? If it >is an asset of ICANN, it may expect compensation >for it (indeed there could be fiduciary duty >issues if the Board "gives it away." > >Also, once the IANA Functions are transferred >away from ICANN, how will oversight and >accountability continue (since all of the >oversight and accountability is >"internal-to-ICANN") -- this seems like quite a >big issue in terms of "separability," >actually. Will the new IANA be required by the >RFP to amend its bylaws and replicate the MRT >and the CSC and the IAP (and the IRB) to match the current set-up? > >Another big difference (and I think a >disadvantage) is that there is no periodic >expiration of the IANA Contract, with the >implicit or explicit promise of an RFP or at >least a re-examination of the terms of the >agreement. In essence, this now becomes ICANN's >right in perpetuity, unless it fails to properly >perform the IANA Functions in a very significant and ongoing way. > >Finally, while there are ways to limit bylaw >changes that i am aware of under US law (e.g., >supermajority voting combined with board >structuring), I really don't think that this >power can be put into the hands of the MRT >without a host of other governance changes to >ICANN. Of course, without research I can't be >sure, and it may be that some significant >reworking of ICANN's overall Board and >governance structure could elicit this >result. But that would require further research and consideration. > >Overall, this seems a lot more complex and >uncertain than the set-up in the Draft >Proposal. This also does not deal with >operational aspects of replacing NTIA. In >addition to an MRT-like structure, are you also >assuming a CSC-like structure to provide basic >operational oversight of the IANA Functions and >an Appeals Panel for disputes regarding how the >IANA Functions are carried out? If so, there's >no real advantage in terms of the level of >complexity (and probably a disadvantage, at >that). In any event, any proposal has to deal >with more than just separability. > >AG: >Perhaps it is time for us to stop talking about >what we think might not be possible (as the >above paragraphs do several times) and get some facts. > >ICANN regularly accepts the concept that an >external body can tell it exactly what to do - >many of its contracts specify binding >arbitration which leave the ICANN Board with no >wriggle room. ICANN considers this preferable to >litigation, and it accepts the consequences that >it will be bound to honour what an external party dictates. > >I actually have faith that the Accountability >CCWG can come up with effective accountability >measures that ICANN will be obliged to accept if >it is exchange for keeping the IANA function. > > > >I know it is (still) very rough and I directly >agree that separating the IANA function will in >a legal sense probably be a lot more difficult, >I think it would be possible under my legal system at home. > >GS: I am not sure that this is impossible, but >there are a number of very fundamental "ifs" and >assumptions here that seem to make this >speculative and uncertain in the extreme, with >no virtue other than to be >"internal-to-ICANN." I also don't see the >advantages of this set-up, but perhaps I am missing something. > >AG: >Then we agree to disagree. I see stability, >working with a known entity, lower costs >(potentially a LOT lower) and not adding >significant complexity and processes as being a >large benefit. I see not having to deal with >lawsuits over failed RFP bids to take the IANA >contract as a benefit (in many cases, suing >after a failed bid is almost automatic. I value >a higher degree of certainty that the three core >IANA functions will stay together instead of >being fractured as the result of mandatory RFPs. I could go on. > >Alan > > > >Greg >Appreciate your response. >Best, >Maarten

4 4

Re: [CWG-Stewardship] Strickling Remarks from 4 December re IANA Transition and Accountability
by Alan Greenberg Dec. 15, 2014

Dec. 15, 2014

Guru, perhaps that is what you think drives me, but it is not the case. I must admit I am getting a bit tired of having people tell me what my motivations are. I am arguing for what I believe is the best path forward. It does happen to coincide with what I suspect the NTIA will accept, which makes it even better in my mind. And I have no interest in discussing what the Board WANTS. I am sure at some level, many Board members would prefer no substantive change (and the current CWG comes pretty close to that with respect to ICANN needing to change to meet the plan). Your quote regarding "or they come up with something that is unacceptable to the Board" was out of context. What I said (rephrased) was that my recollection was that the Accountability Recommendation would go to the ICANN Board, and that if the Rec. was totally unacceptable it would not be implemented. I have no interest in tilting at windmills, I do not like to waste my time if indeed there is NO chance that it would go forward. ICANN Bylaw changes MUST go through the ICANN Board. That is a fact and all the posturing will not change that. If the ALAC proposal were to go forward, it will NOT result with what the ICANN Board wants. but hopefully something that they can live with. I have no interest in discussing whether one group or another has lost its moral authority, or a wish that the US Gov't should fall on its knees before us. Alan At 13/12/2014 12:46 PM, Guru Acharya wrote: >Alan, > >So much of what you say is driven by what the >NTIA wants and what the ICANN board wants. > >For example: "...I think the chances are high >that it will be rejected by the NTIA either on >overall dislike of the model..." and ... "... >or they come up with something that is unacceptable to the Board ..." > >NTIA has already pushed 4 constraints down our >throats in a top-down manner. ICANN pushed some >additional constraints down our throats using >the Scoping Document. Within all those >constraints, why are you looking for additional ways to please NTIA and ICANN? > >I'm not sure how predicting acceptance by the >top aligns with a bottom up process. > >Its more about what "we", at the bottom of the >community, want regardless of what the top >desires. And the NTIA should fall on its knees >and accept it. The NTIA is not doing anybody a >favour. It has already lost its moral authority to be the steward of the DNS. > >On Sat, Dec 13, 2014 at 10:40 PM, Alan Greenberg ><<mailto:alan.greenberg@mcgill.ca>alan.greenberg(a)mcgill.ca> wrote: >At 13/12/2014 11:18 AM, Gomes, Chuck wrote: >>Thanks a lot Alan for responding. Please see my comments inline below. >> >>Chuck >> >>From: Alan Greenberg [ mailto:alan.greenberg@mcgill.ca] >>Sent: Thursday, December 11, 2014 4:22 PM >>To: Gomes, Chuck; Greg Shatan; Maarten Simon >>Cc: <mailto:cwg-stewardship@icann.org>cwg-stewardship(a)icann.org >>Subject: RE: [CWG-Stewardship] Strickling >>Remarks from 4 December re IANA Transition and Accountability >> >>At 11/12/2014 10:28 AM, Gomes, Chuck wrote: >> >>Allan, >> >>I want to comment on a few of the points you make in the exchange below. >> >>1. ". . . the ICANN board has a rather >>powerful reason for being flexible and >>accomodating" . Am I correct that that reason >>is the risk of losing the IANA functions? If >>so, I would agree but I would also point out >>that for that risk to be real it seems to me >>that there must be some entity that could >>reassign those functions. For now that is >>NTIA. What would it be if NTIA goes away? >> >>The powerful reason I was referring to is I >>believe (and I have no guarantee that it is >>supported by the majority of the Board, >>although I have had some discussions) that a >>solution that gives IANA to ICANN (requiring >>significant accountability changes that would >>implicitly reduce their absolute power) would >>be far more palatable the Contract Co model >>where instead of internal accountability, we >>have the threat of external action (ie breach >>of the contract going somewhere else at some point). >>[Chuck Gomes] Is there a word missing in >>Ã¢Å. . . would be far more palatable the >>Contract Co model where instead of internal >>accountability, we have the threat of external >>action (ie breach of the contract going >>somewhere else at some point)Ã¢ . II donÃ¢t >>t understand what you intended to say. > >AG: Yes, there was a word missing, two actually. >Removing the parentheticals to improve readability: > >The powerful reason I was referring to is THAT I >believe that a solution that gives IANA to ICANN >would be far more palatable THAN the Contract Co >model where instead of internal accountability, >we have the threat of external action. > >To be clear, it is my belief that if the Board >were presented with two options: >1. The CWG Contract Co model; >2. The ALAC model with IANA being given to ICANN >and ICANN accepting significant loss of Board autonomy related to IANA; >that the Board would pick option 2. > >I also believe that this would be the preference >for NTIA as well. If you want the rationale for >that, see the start of my reply to Jordan Carter >on ><https://community.icann.org/x/YoEHAw>https://community.icann.org/x/YoEHAw, >about 3/4 down the page. > > > > >>2. "It is SO attractive to label ICANN as >>unchanging and inflexible, but current evidence >>does not bear that out." Can you share any >>cases where ICANN has been flexible about >>giving the Board the final say on a decision? >> >>No. Today they have ultimate say over pretty >>much everything EXCEPT where they accept >>binding arbitration to resolve contract >>disputes. The Bylaws were written to give the >>Board such full power, and there has never been >>a reason for them to give any of that power up. >>This, I believe, is such a reason. >>[Chuck Gomes] Agree. >> >> >> >>3. "I actually have faith that the >>Accountability CCWG can come up with effective >>accountability measures that ICANN will be >>obliged to accept if it is exchange for keeping >>the IANA function" I hope you are correct but >>I have serious doubts that that will happen >>unless there is a real risk of them losing the >>IANA functions and a refer back to 1 above. >> >>I see VERY little accountability changes to >>adapt to the Contract Co. model. Other than the >>IAP, ICANN is going from one contracting entity >>(NTIA) to another (Contract Co,) both of whom >>can make a decision to reassign the IANA >>contract in the case of poor performance or >>whatever reasons the contact may allow. To fix >>the IANA problems a number of years ago, ICANN >>took measures to ensure that IANA was >>professionally managed and at this stage is >>doing a fine job (by all reports). ICANN did >>not fix the IANA problems with accountability >>measures but with standard good management >>practices. I think it would do the same under >>contract assignment by Contract Co. >>[Chuck Gomes] I would like to think that as >>well but shouldnÃ¢t we e have a mechanism in place if we are both wrong? > >If we are wrong, then either the the >Accountability CCWG will through up their hands >and give up, which means the proposal is dead, >or they come up with something that is >unacceptable to the Board (I think their Recs go >there, but not really sure), or they come up >with something that is judged insufficient by >the NTIA and the proposal is dead. > >The Contract Co. proposal will not have much >problem with the Accountability CCWG because so >little is needed (see my note to Jordan), but I >think the chances are high that it will be >rejected by the NTIA either on overall dislike >of the model, or some of the many "details" >(including cost and funding) will not provide >sufficient certainty that it will work and continue to work. > >Either way has it's potential for failure. I've >made my choice on which I believe is more likely to succeed. > > > >>The ATRTs have managed to make incremental >>changes that have enhanced accountability, but >>virtually none that really change how decisions >>are made and the involvement of MS in those >>decisions. Certainly ATRT2 TAKLKED about some >>such real changes, but they basically did not >>fly because we got clear messages that the >>Board would resist them and we backed off. >>[Chuck Gomes] Agree. >> >> >>Accountability will be forced upon ICANN (in my >>mind), only if it is in exchange for something >>it really wants. And IANA is one such thing. >>[Chuck Gomes] Agree. > >As an add-on thought. The IANA issue is probably >not sufficient to immediately fix all >accountability issues (ie Track 2 of the CCWG), >but if we push through the IANA-centric ones, >that will open the door (I think the expression >is that the ideas will have been "socialized" >and not longer so foreign). Once the Board >accepts that it is not all-powerful, I think >that the rest will be a lot easier - perhaps not easy, but easier. > >Alan > > > >>Alan >> >> >> >>Chuck >> >> >> >>From: >><mailto:cwg-stewardship-bounces@icann.org>cwg-stewardship-bounces(a)icann.org >>[ mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Alan Greenberg >>Sent: Wednesday, December 10, 2014 9:32 PM >>To: Greg Shatan; Maarten Simon >>Cc: <mailto:cwg-stewardship@icann.org>cwg-stewardship(a)icann.org >>Subject: Re: [CWG-Stewardship] Strickling >>Remarks from 4 December re IANA Transition and Accountability >> >>At 10/12/2014 02:53 PM, Greg Shatan wrote: >> >>Maarten: >> >>My answers are inline below. >> >>Greg >> >>On Mon, Dec 8, 2014 at 5:46 PM, Maarten Simon >><<mailto:maarten.simon@sidn.nl>maarten.simon(a)sidn.nl> wrote: >>Hi Greg, >>Although I personally have not made up my mind >>as yet if the contract co or an internal ICANN >>solution is preferable, I have posted a very >>rough idea for an internal solution in another >>thread that I have not seen your response to. I >>repeat it here as I am interested to here from >>you if you think it would be legally possible >>(apart from the fact that you probably do not support it for other reasons): >>ÃÆÃÂ¢If we could arrange via the bylaws t >>that the ICANNNNNN board explicitly has to >>follow orders from a MRT-like structure, >> >>GS: This is a pretty big "if." Unlike >>Contract Co., which would be built from the >>ground up to be a corporation with very limited >>purpose and goals and limitations upon its >>directors and officer, and thus lends itself to >>this "following orders" model, ICANN is an >>existing organization with a large board and >>officer group and many activities. At best, >>this type of organization does not lend itself >>to such a model. At worst, it's not even >>possible. But let's assume, solely for the >>sake of argument, that the ICANN bylaws can be >>modified in this fashion. I am assuming that >>the MRT will be "internal-to-ICANN" like the >>current SOs and ACs (and in contrast to the >>ICG). Is that correct? If so, how do you >>involve the global multistakeholder community >>(beyond ICANN) as required by the NTIA? >> >>AG: >>I will no doubt echo some of what Olivier has >>said, despite Milton having explained that he is wrong. >> >>Yes, it is more difficult to retrofit such >>measures into the existing ICANN, but then the >>ICANN board has a rather powerful reason for being flexible and accomodating. >> >>It is not clear how "internal" an MRT would be. >>It would be organized under the auspices of >>ICANN. Whether it "reports" to ICANN is >>something else altogether. The relationship >>between the IETF and ISOC might be a good >>model. ISOC provides funding and perhaps legal >>protection but I don't think that we could say >>that the IETF is internal to ISOC or controlled by it. >> >>The ICG and the Stewardship CWG have >>representation from outside of ICANN. Yes, >>Milton points out that they were created due to >>pressure and conditions set by the NTIA. As >>above, the desire to retain IAINA is a mighty >>big carrot to continue the tradition.ICANN >>partially funded NetMundial, and completely >>different form of MS event and it did so without US government pressure. >> >>It is SO attractive to label ICANN as >>unchanging and inflexible, but current evidence does not bear that out. >> >> >> >>we might not need a contract but have an (internal) MoU/SLA or whatever. >> >>GS: There really is no such thing as an >>internal MoU/SLA. Both of these are agreements >>(just like the IANA Functions Contract), and >>need to be made between two or more legal >>entities capable of contracting. If the >>MRT-like structure is internal to ICANN, it >>can't have a contract with ICANN -- that would >>be ICANN contracting with itself. The >>"whatever" would have to be an internal >>document of a non-contractual/non-agreement >>nature. Conceivably, it could be a policy. If >>it is a policy, it would most likely have to go >>through an ICANN Policy Development >>Process. Would this be done separately by the >>ccNSO and the GNSO under their separate PDP >>guidelines? Or would we try to put together a >>joint PDP Working Group? And how long would >>this PDP take to develop an "IANA Functions Policy"? >> >>The other thing the IANA Functions Contract >>establishes is that the right to run the IANA >>Functions ultimately resides in Contract >>Co. ICANN's right to do it is purely >>contractual; essentially, ICANN is a licensee, >>and the MRT is a a licensor. Under this >>scenario, the current IANA Contract goes away, >>and ICANN is left holding the right to perform >>the IANA Functions. This means that the IANA >>Functions are now an inherent right of >>ICANN This is a very different overall >>set-up, with different consequences. Losing a >>right one has by contract is a very common >>problem, and is as old as contracts. Losing an >>inherent right and sector of services because a >>committee says that you have failed to live up >>to internal policies is both very uncommon and >>very novel, creating considerable uncertainty >>even if it is a technical possibility. >> >>AG: >>I have no clue as to the legal issues involved, >>but apparently ICANN can sign a MoU with an >>internal body. The relationship between ICANN >>and the At-Large regional At-large >>Organizations (RALOs) are established through >>MoUs. And although you presume that the MRT >>would be wholly internal to ICANN, that is a >>premise in your mind, but not mine. >> >>Yes, without Contract Co, ICANN has the right >>to continue performing IANA functions. That >>provides a level of stability that the >>possibility of moving it (potentially every 5 >>years if some people have their way). But if >>the MRT can direct how that is done, that may >>not be so bad. And It is not inconceivable that >>the MRT could direct ICANN to divest itself of IANA in extreme situations. >> >> >> >>If the ICANN board would at a certain moment in >>time still decide not to follow orders of the >>MRT, I would assume it may be sued by affected >>parties for violating its own bylaws. >> >>GS: Litigation should be a last resort, not a >>first resort, when it comes to >>enforcement. Contract Co. can terminate the >>contract (or decide not to sign another one >>when it expires). The MRT has no such >>ability. That is why you are suggesting >>litigation -- which is not an >>"internal-to-ICANN" solution at all. In >>addition to not being "internal-to-ICANN," >>litigation (in any jurisdiction) is expensive, >>lengthy and consumes great time and resources, >>and may not produce a result in any kind of >>useful timeframe. In any event, who are the >>"affected parties" that would sue? Is it only >>one registry, or is it many? What if it's a >>stakeholder group, such as "civil society"? If >>there are many litigants, they would need to >>enter into some sort of joint litigation >>agreement, form a coordinating group and deal >>with a whole host of other things. And not >>every affected party has a litigation war chest >>to go up against ICANN -- unlike Contract Co., >>which will be indemnified. I don't think >>there's any way that ICANN would agree to >>indemnify, defend and hold harmless every >>"affected party" that might challenge a >>decision relating to IANA Functions. So, >>litigation funding would be a very real issue. >> >>Finally, I'm not at all sure that the "affected >>parties" will have the standing to sue ICANN >>for violating its bylaws. This might be a >>right that a shareholder would have if ICANN >>had shareholders (but nonprofits don't have >>shareholders). Third parties may not have a >>cause of action here on that front, and would >>need to find some other theory that supports a >>lawsuit. By contrast, breach of contract >>litigation is fairly straightforward (not that >>I'm supporting litigation before other forms of escalation are exhausted). >> >>We further may dictate in the bylaws that ICANN >>has to give up the IANA function if decided by >>this MRT and of course seal it by dictating >>that these specific articles may only be >>changed with the explicit consent of the MRT.ÃÆÃÂ¢ >> >>GS: Agaain, I'm not at all sure we can dictate >>in the bylaws that ICANN has to "give up the >>IANA function if decided by the MRT." (By >>contrast, it's quite clear that ICANN can enter >>into enforceable obligation if it signs an >>agreement with a third party.) But again, let's >>assume it for the sake of argument. In your >>scenario, it is implicit that the right to >>perform the IANA Functions is an inherent right >>of ICANN, not a right granted to it by a third >>party. So instead of Contract Co. terminating >>an agreement, we have the ICANN Board being >>instructed to cause ICANN to cease part of its >>services. I am much more skeptical that this >>is a realistic assumption, especially since it >>could run counter to the fiduciary duty of the >>Directors to ICANN. (By contrast, I don't see >>the MRT instructing Contract Co. to do >>something counter to Contract Co.'s interests, >>given the limited scope and purpose of Contract >>Co.) But let's go on. The concept of ICANN >>"giving up" the IANA functions is quite >>nebulous. Since it's an inherent right of >>ICANN's, ICANN would have to run the RFP to >>find the next IANA Functions Operator. Are you >>assuming that the MRT will do this as well, >>rather than ICANN? That seems like another big >>assumption. And what exactly would ICANN be >>transferring? If it is an asset of ICANN, it >>may expect compensation for it (indeed there >>could be fiduciary duty issues if the Board "gives it away." >> >>Also, once the IANA Functions are transferred >>away from ICANN, how will oversight and >>accountability continue (since all of the >>oversight and accountability is >>"internal-to-ICANN") -- this seems like quite a >>big issue in terms of "separability," >>actually. Will the new IANA be required by the >>RFP to amend its bylaws and replicate the MRT >>and the CSC and the IAP (and the IRB) to match the current set-up? >> >>Another big difference (and I think a >>disadvantage) is that there is no periodic >>expiration of the IANA Contract, with the >>implicit or explicit promise of an RFP or at >>least a re-examination of the terms of the >>agreement. In essence, this now becomes >>ICANN's right in perpetuity, unless it fails to >>properly perform the IANA Functions in a very significant and ongoing way. >> >>Finally, while there are ways to limit bylaw >>changes that i am aware of under US law (e.g., >>supermajority voting combined with board >>structuring), I really don't think that this >>power can be put into the hands of the MRT >>without a host of other governance changes to >>ICANN. Of course, without research I can't be >>sure, and it may be that some significant >>reworking of ICANN's overall Board and >>governance structure could elicit this >>result. But that would require further research and consideration. >> >>Overall, this seems a lot more complex and >>uncertain than the set-up in the Draft >>Proposal. This also does not deal with >>operational aspects of replacing NTIA. In >>addition to an MRT-like structure, are you also >>assuming a CSC-like structure to provide basic >>operational oversight of the IANA Functions and >>an Appeals Panel for disputes regarding how the >>IANA Functions are carried out? If so, there's >>no real advantage in terms of the level of >>complexity (and probably a disadvantage, at >>that). In any event, any proposal has to deal >>with more than just separability. >> >>AG: >>Perhaps it is time for us to stop talking about >>what we think might not be possible (as the >>above paragraphs do several times) and get some facts. >> >>ICANN regularly accepts the concept that an >>external body can tell it exactly what to do - >>many of its contracts specify binding >>arbitration which leave the ICANN Board with no >>wriggle room. ICANN considers this preferable >>to litigation, and it accepts the consequences >>that it will be bound to honour what an external party dictates. >> >>I actually have faith that the Accountability >>CCWG can come up with effective accountability >>measures that ICANN will be obliged to accept >>if it is exchange for keeping the IANA function. >> >> >> >>I know it is (still) very rough and I directly >>agree that separating the IANA function will in >>a legal sense probably be a lot more difficult, >>I think it would be possible under my legal system at home. >> >>GS: I am not sure that this is impossible, but >>there are a number of very fundamental "ifs" >>and assumptions here that seem to make this >>speculative and uncertain in the extreme, with >>no virtue other than to be >>"internal-to-ICANN." I also don't see the >>advantages of this set-up, but perhaps I am missing something. >> >>AG: >>Then we agree to disagree. I see stability, >>working with a known entity, lower costs >>(potentially a LOT lower) and not adding >>significant complexity and processes as being a >>large benefit. I see not having to deal with >>lawsuits over failed RFP bids to take the IANA >>contract as a benefit (in many cases, suing >>after a failed bid is almost automatic. I value >>a higher degree of certainty that the three >>core IANA functions will stay together instead >>of being fractured as the result of mandatory RFPs. I could go on. >> >>Alan >> >> >> >>Greg >>Appreciate your response. >>Best, >>Maarten > >_______________________________________________ >CWG-Stewardship mailing list ><mailto:CWG-Stewardship@icann.org>CWG-Stewardship(a)icann.org >https://mm.icann.org/mailman/listinfo/cwg-stewardship >

4 6

Re: [CWG-Stewardship] Strickling Remarks from 4 December re IANA Transition and Accountability
by Alan Greenberg Dec. 14, 2014

Dec. 14, 2014

I was quoting what the Co-Chairs of the Stewardship CWG had put in their message. It may certainly change. Alan At 14/12/2014 05:12 PM, Greg Shatan wrote: >The current CWG Proposal also requires the >CCWG's "stream 1" accountability measures be put >in place before the transition is >consummated. So, it is only in isolation that >one can say that the proposal requires very >little in the way of new accountability measures. > >Greg > >On Sunday, December 14, 2014, Alan Greenberg <alan.greenberg(a)mcgill.ca> wrote: >Chuck, I feel awkward trying to say what the >Board or particular Board member want, but I >will try to elaborate. Based on my ATRT2 >experience, I think that there will be a lot of >discomfort with strong new accountability >measures. I am not saying that they would not be >accepted, I think that they will. But the >current CWG proposal will require very little - >see Jonathon and Lise's message on overlaps. Alan >-- >Sent from my mobile. Please excuse brevity and typos. > >On December 14, 2014 11:34:19 AM EST, "Gomes, >Chuck" <cgomes(a)verisign.com> wrote: > >Alan, > > > >I am one that isnât worried about your motives >and I am quite sure that that is the same for >most of us. But I do need some clarity on one of your statements below. > > > >Chuck > > > >From: Alan Greenberg [mailto:alan.greenberg@mcgill.ca] >Sent: Sunday, December 14, 2014 1:17 AM >To: Guru Acharya >Cc: Gomes, Chuck; cwg-stewardship(a)icann.org >Subject: Re: [CWG-Stewardship] Strickling >Remarks from 4 December re IANA Transition and Accountability > > > >Guru, perhaps that is what you think drives me, >but it is not the case. I must admit I am >getting a bit tired of having people tell me what my motivations are. > >I am arguing for what I believe is the best path >forward. It does happen to coincide with what I >suspect the NTIA will accept, which makes it even better in my mind. > >And I have no interest in discussing what the >Board WANTS. I am sure at some level, many Board >members would prefer no substantive change (and >the current CWG comes pretty close to that with >respect to ICANN needing to change to meet the plan). > >[Chuck Gomes] What do you mean when you appear >to say that âthe current CWG comes pretty >close toâ what âmany Board members would prefer no substantive changeâ? > > > >Your quote regarding "or they come up with >something that is unacceptable to the Board" was >out of context. What I said (rephrased) was that >my recollection was that the Accountability >Recommendation would go to the ICANN Board, and >that if the Rec. was totally unacceptable it >would not be implemented. I have no interest in >tilting at windmills, I do not like to waste my >time if indeed there is NO chance that it would >go forward. ICANN Bylaw changes MUST go through >the ICANN Board. That is a fact and all the posturing will not change that. > >If the ALAC proposal were to go forward, it will >NOT result with what the ICANN Board wants. but >hopefully something that they can live with. > >I have no interest in discussing whether one >group or another has lost its moral authority, >or a wish that the US Gov't should fall on its knees before us. > >Alan > > > >At 13/12/2014 12:46 PM, Guru Acharya wrote: > >Alan, > >So much of what you say is driven by what the >NTIA wants and what the ICANN board wants. > >For example: "...I think the chances are high >that it will be rejected by the NTIA either on >overall dislike of the model..." and ... "... >or they come up with something that is unacceptable to the Board ..." > >NTIA has already pushed 4 constraints down our >throats in a top-down manner. ICANN pushed some >additional constraints down our throats using >the Scoping Document. Within all those >constraints, why are you looking for additional ways to please NTIA and ICANN? > >I'm not sure how predicting acceptance by the >top aligns with a bottom up process. > >Its more about what "we", at the bottom of the >community, want regardless of what the top >desires. And the NTIA should fall on its knees >and accept it. The NTIA is not doing anybody a >favour. It has already lost its moral authority to be the steward of the DNS. > >On Sat, Dec 13, 2014 at 10:40 PM, Alan Greenberg ><alan.greenberg(a)mcgill.ca > wrote: > >At 13/12/2014 11:18 AM, Gomes, Chuck wrote: > >Thanks a lot Alan for responding. Please see my comments inline below. > > > >Chuck > > > >From: Alan Greenberg [ mailto:alan.greenberg@mcgill.ca] > >Sent: Thursday, December 11, 2014 4:22 PM > >To: Gomes, Chuck; Greg Shatan; Maarten Simon > >Cc: cwg-stewardship(a)icann.org > >Subject: RE: [CWG-Stewardship] Strickling >Remarks from 4 December re IANA Transition and Accountability > > > >At 11/12/2014 10:28 AM, Gomes, Chuck wrote: > >Allan, > > > >I want to comment on a few of the points you make in the exchange below. > > > >1. ". . . the ICANN board has a rather >powerful reason for being flexible and >accomodating" . Am I correct that that reason >is the risk of losing the IANA functions? If >so, I would agree but I would also point out >that for that risk to be real it seems to me >that there must be some entity that could >reassign those functions. For now that is >NTIA. What would it be if NTIA goes away? > >The powerful reason I was referring to is I >believe (and I have no guarantee that it is >supported by the majority of the Board, although >I have had some discussions) that a solution >that gives IANA to ICANN (requiring significant >accountability changes that would implicitly >reduce their absolute power) would be far more >palatable the Contract Co model where instead of >internal accountability, we have the threat of >external action (ie breach of the contract going somewhere else at some point). > >[Chuck Gomes] Is there a word missing in >ÃÂ¢Ãâ. . . would be fafar more palatable >the Contract Co model where instead of internal >accountability, we have the threat of external >action (ie breach of the contract going >somewhere else at some point)ÃÂ¢ . II >donÃÂÂ¢t t understand what you intended to say. > > > > > > >AG: Yes, there was a word missing, two actually. >Removing the parentheticals to improve readability: > >The powerful reason I was referring to is THAT I >believe that a solution that gives IANA to ICANN >would be far more palatable THAN the Contract Co >model where instead of internal accountability, >we have the threat of external action. > >To be clear, it is my belief that if the Board >were presented with two options: > >1. The CWG Contract Co model; > >2. The ALAC model with IANA being given to ICANN >and ICANN accepting significant loss of Board autonomy related to IANA; > >that the Board would pick option 2. > >I also believe that this would be the preference >for NTIA as well. If you want the rationale for >that, see the start of my reply to Jordan Carter >on ><https://community.icann.org/x/YoEHAw>https://community.icann.org/x/YoEHAw, >about 3/4 down the page. > > > > > >2. "It is SO attractive to label ICANN as >unchanging and inflexible, but current evidence >does not bear that out." Can you share any >cases where ICANN has been flexible about giving >the Board the final say on a decision? > >No. Today they have ultimate say over pretty >much everything EXCEPT where they accept binding >arbitration to resolve contract disputes. The >Bylaws were written to give the Board such full >power, and there has never been a reason for >them to give any of that power up. This, I believe, is such a reason. > >[Chuck Gomes] Agree. > > >3. "I actually have faith that the >Accountability CCWG can come up with effective >accountability measures that ICANN will be >obliged to accept if it is exchange for keeping >the IANA function" I hope you are correct but >I have serious doubts that that will happen >unless there is a real risk of them losing the >IANA functions and a refer back to 1 above. > >I see VERY little accountability changes to >adapt to the Contract Co. model. Other than the >IAP, ICANN is going from one contracting entity >(NTIA) to another (Contract Co,) both of whom >can make a decision to reassign the IANA >contract in the case of poor performance or >whatever reasons the contact may allow. To fix >the IANA problems a number of years ago, ICANN >took measures to ensure that IANA was >professionally managed and at this stage is >doing a fine job (by all reports). ICANN did not >fix the IANA problems with accountability >measures but with standard good management >practices. I think it would do the same under >contract assignment by Contract Co. > >[Chuck Gomes] I would like to think that as well >but shouldnÃÂ¢t we e havhave a mechanism in place if we are both wrong? > > > >If we are wrong, then either the the >Accountability CCWG will through up their hands >and give up, which means the proposal is dead, >or they come up with something that is >unacceptable to the Board (I think their Recs go >there, but not really sure), or they come up >with something that is judged insufficient by >the NTIA and the proposal is dead. > >The Contract Co. proposal will not have much >problem with the Accountability CCWG because so >little is needed (see my note to Jordan), but I >think the chances are high that it will be >rejected by the NTIA either on overall dislike >of the model, or some of the many "details" >(including cost and funding) will not provide >sufficient certainty that it will work and continue to work. > >Either way has it's potential for failure. I've >made my choice on which I believe is more likely to succeed. > > > > >The ATRTs have managed to make incremental >changes that have enhanced accountability, but >virtually none that really change how decisions >are made and the involvement of MS in those >decisions. Certainly ATRT2 TAKLKED about some >such real changes, but they basically did not >fly because we got clear messages that the Board >would resist them and we backed off. > >[Chuck Gomes] Agree. > >Accountability will be forced upon ICANN (in my >mind), only if it is in exchange for something >it really wants. And IANA is one such thing. > >[Chuck Gomes] Agree. > > > >As an add-on thought. The IANA issue is probably >not sufficient to immediately fix all >accountability issues (ie Track 2 of the CCWG), >but if we push through the IANA-centric ones, >that will open the door (I think the expression >is that the ideas will have been "socialized" >and not longer so foreign). Once the Board >accepts that it is not all-powerful, I think >that the rest will be a lot easier - perhaps not easy, but easier. > >Alan > > > > >Alan > > > >Chuck > > > > > > > >From: cwg-stewardship-bounces(a)icann.org [ >mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Alan Greenberg > >Sent: Wednesday, December 10, 2014 9:32 PM > >To: Greg Shatan; Maarten Simon > >Cc: cwg-stewardship(a)icann.org > >Subject: Re: [CWG-Stewardship] Strickling >Remarks from 4 December re IANA Transition and Accountability > > > >At 10/12/2014 02:53 PM, Greg Shatan wrote: > >Maarten: > >My answers are inline below. > >Greg > >On Mon, Dec 8, 2014 at 5:46 PM, Maarten Simon <maarten.simon(a)sidn.nl> wrote: > >Hi Greg, > >Although I personally have not made up my mind >as yet if the contract co or an internal ICANN >solution is preferable, I have posted a very >rough idea for an internal solution in another >thread that I have not seen your response to. I >repeat it here as I am interested to here from >you if you think it would be legally possible >(apart from the fact that you probably do not support it for other reasons): > >ÃÆÃâÃÃÂ¢If we we could arrange via the >bylaws t that the ICANNNNNN board explicitly has >to follow orders from a MRT-like structure, > >GS: This is a pretty big "if." Unlike Contract >Co., which would be built from the ground up to >be a corporation with very limited purpose and >goals and limitations upon its directors and >officer, and thus lends itself to this >"following orders" model, ICANN is an existing >organization with a large board and officer >group and many activities. At best, this type of >organization does not lend itself to such a >model. At worst, it's not even possible. But >let's assume, solely for the sake of argument, >that the ICANN bylaws can be modified in this >fashion. I am assuming that the MRT will be >"internal-to-ICANN" like the current SOs and ACs >(and in contrast to the ICG). Is that >correct? If so, how do you involve the global >multistakeholder community (beyond ICANN) as required by the NTIA? > >AG: > >I will no doubt echo some of what Olivier has >said, despite Milton having explained that he is wrong. > >Yes, it is more difficult to retrofit such >measures into the existing ICANN, but then the >ICANN board has a rather powerful reason for being flexible and accomodating. > >It is not clear how "internal" an MRT would be. >It would be organized under the auspices of >ICANN. Whether it "reports" to ICANN is >something else altogether. The relationship >between the IETF and ISOC might be a good model. >ISOC provides funding and perhaps legal >protection but I don't think that we could say >that the IETF is internal to ISOC or controlled by it. > >The ICG and the Stewardship CWG have >representation from outside of ICANN. Yes, >Milton points out that they were created due to >pressure and conditions set by the NTIA. As >above, the desire to retain IAINA is a mighty >big carrot to continue the tradition.ICANN >partially funded NetMundial, and completely >different form of MS event and it did so without US government pressure. > >It is SO attractive to label ICANN as unchanging >and inflexible, but current evidence does not bear that out. > > >we might not need a contract but have an (internal) MoU/SLA or whatever. > >GS: There really is no such thing as an >internal MoU/SLA. Both of these are agreements >(just like the IANA Functions Contract), and >need to be made between two or more legal >entities capable of contracting. If the >MRT-like structure is internal to ICANN, it >can't have a contract with ICANN -- that would >be ICANN contracting with itself. The >"whatever" would have to be an internal document >of a non-contractual/non-agreement >nature. Conceivably, it could be a policy. If >it is a policy, it would most likely have to go >through an ICANN Policy Development >Process. Would this be done separately by the >ccNSO and the GNSO under their separate PDP >guidelines? Or would we try to put together a >joint PDP Working Group? And how long would >this PDP take to develop an "IANA Functions Policy"? > >The other thing the IANA Functions Contract >establishes is that the right to run the IANA >Functions ultimately resides in Contract >Co. ICANN's right to do it is purely >contractual; essentially, ICANN is a licensee, >and the MRT is a a licensor. Under this >scenario, the current IANA Contract goes away, >and ICANN is left holding the right to perform >the IANA Functions. This means that the IANA >Functions are now an inherent right of >ICANN This is a very different overall set-up, >with different consequences. Losing a right one >has by contract is a very common problem, and is >as old as contracts. Losing an inherent right >and sector of services because a committee says >that you have failed to live up to internal >policies is both very uncommon and very novel, >creating considerable uncertainty even if it is a technical possibility. > >AG: > >I have no clue as to the legal issues involved, >but apparently ICANN can sign a MoU with an >internal body. The relationship between ICANN >and the At-Large regional At-large Organizations >(RALOs) are established through MoUs. And >although you presume that the MRT would be >wholly internal to ICANN, that is a premise in your mind, but not mine. > >Yes, without Contract Co, ICANN has the right to >continue performing IANA functions. That >provides a level of stability that the >possibility of moving it (potentially every 5 >years if some people have their way). But if the >MRT can direct how that is done, that may not be >so bad. And It is not inconceivable that the MRT >could direct ICANN to divest itself of IANA in extreme situations. > > >If the ICANN board would at a certain moment in >time still decide not to follow orders of the >MRT, I would assume it may be sued by affected >parties for violating its own bylaws. > >GS: Litigation should be a last resort, not a >first resort, when it comes to >enforcement. Contract Co. can terminate the >contract (or decide not to sign another one when >it expires). The MRT has no such ability. That >is why you are suggesting litigation -- which is >not an "internal-to-ICANN" solution at all. In >addition to not being "internal-to-ICANN," >litigation (in any jurisdiction) is expensive, >lengthy and consumes great time and resources, >and may not produce a result in any kind of >useful timeframe. In any event, who are the >"affected parties" that would sue? Is it only >one registry, or is it many? What if it's a >stakeholder group, such as "civil society"? If >there are many litigants, they would need to >enter into some sort of joint litigation >agreement, form a coordinating group and deal >with a whole host of other things. And not >every affected party has a litigation war chest >to go up against ICANN -- unlike Contract Co., >which will be indemnified. I don't think there's >any way that ICANN would agree to indemnify, >defend and hold harmless every "affected party" >that might challenge a decision relating to IANA >Functions. So, litigation funding would be a very real issue. > >Finally, I'm not at all sure that the "affected >parties" will have the standing to sue ICANN for >violating its bylaws. This might be a right >that a shareholder would have if ICANN had >shareholders (but nonprofits don't have >shareholders). Third parties may not have a >cause of action here on that front, and would >need to find some other theory that supports a >lawsuit. By contrast, breach of contract >litigation is fairly straightforward (not that >I'm supporting litigation before other forms of escalation are exhausted). > > > >We further may dictate in the bylaws that ICANN >has to give up the IANA function if decided by >this MRT and of course seal it by dictating that >these specific articles may only be changed with >the explicit consent of the MRT.ÃÆÃâÃÃÂ¢ ¬ > >GS: Agaain, I'm not at all sure we can dictate >in the bylaws that ICANN has to "give up the >IANA function if decided by the MRT." (By >contrast, it's quite clear that ICANN can enter >into enforceable obligation if it signs an >agreement with a third party.) But again, let's >assume it for the sake of argument. In your >scenario, it is implicit that the right to >perform the IANA Functions is an inherent right >of ICANN, not a right granted to it by a third >party. So instead of Contract Co. terminating >an agreement, we have the ICANN Board being >instructed to cause ICANN to cease part of its >services. I am much more skeptical that this is >a realistic assumption, especially since it >could run counter to the fiduciary duty of the >Directors to ICANN. (By contrast, I don't see >the MRT instructing Contract Co. to do something >counter to Contract Co.'s interests, given the >limited scope and purpose of Contract Co.) But >let's go on. The concept of ICANN "giving up" >the IANA functions is quite nebulous. Since >it's an inherent right of ICANN's, ICANN would >have to run the RFP to find the next IANA >Functions Operator. Are you assuming that the >MRT will do this as well, rather than ICANN? >That seems like another big assumption. And >what exactly would ICANN be transferring? If it >is an asset of ICANN, it may expect compensation >for it (indeed there could be fiduciary duty >issues if the Board "gives it away." > >Also, once the IANA Functions are transferred >away from ICANN, how will oversight and >accountability continue (since all of the >oversight and accountability is >"internal-to-ICANN") -- this seems like quite a >big issue in terms of "separability," >actually. Will the new IANA be required by the >RFP to amend its bylaws and replicate the MRT >and the CSC and the IAP (and the IRB) to match the current set-up? > >Another big difference (and I think a >disadvantage) is that there is no periodic >expiration of the IANA Contract, with the >implicit or explicit promise of an RFP or at >least a re-examination of the terms of the >agreement. In essence, this now becomes ICANN's >right in perpetuity, unless it fails to properly >perform the IANA Functions in a very significant and ongoing way. > >Finally, while there are ways to limit bylaw >changes that i am aware of under US law (e.g., >supermajority voting combined with board >structuring), I really don't think that this >power can be put into the hands of the MRT >without a host of other governance changes to >ICANN. Of course, without research I can't be >sure, and it may be that some significant >reworking of ICANN's overall Board and >governance structure could elicit this >result. But that would require further research and consideration. > >Overall, this seems a lot more complex and >uncertain than the set-up in the Draft >Proposal. This also does not deal with >operational aspects of replacing NTIA. In >addition to an MRT-like structure, are you also >assuming a CSC-like structure to provide basic >operational oversight of the IANA Functions and >an Appeals Panel for disputes regarding how the >IANA Functions are carried out? If so, there's >no real advantage in terms of the level of >complexity (and probably a disadvantage, at >that). In any event, any proposal has to deal >with more than just separability. > >AG: > >Perhaps it is time for us to stop talking about >what we think might not be possible (as the >above paragraphs do several times) and get some facts. > >ICANN regularly accepts the concept that an >external body can tell it exactly what to do - >many of its contracts specify binding >arbitration which leave the ICANN Board with no >wriggle room. ICANN considers this preferable to >litigation, and it accepts the consequences that >it will be bound to honour what an external party dictates. > >I actually have faith that the Accountability >CCWG can come up with effective accountability >measures that ICANN will be obliged to accept if >it is exchange for keeping the IANA function. > > >I know it is (still) very rough and I directly >agree that separating the IANA function will in >a legal sense probably be a lot more difficult, >I think it would be possible under my legal system at home. > >GS: I am not sure that this is impossible, but >there are a number of very fundamental "ifs" and >assumptions here that seem to make this >speculative and uncertain in the extreme, with >no virtue other than to be >"internal-to-ICANN." I also don't see the >advantages of this set-up, but perhaps I am missing something. > >AG: > >Then we agree to disagree. I see stability, >working with a known entity, lower costs >(potentially a LOT lower) and not adding >significant complexity and processes as being a >large benefit. I see not having to deal with >lawsuits over failed RFP bids to take the IANA >contract as a benefit (in many cases, suing >after a failed bid is almost automatic. I value >a higher degree of certainty that the three core >IANA functions will stay together instead of >being fractured as the result of mandatory RFPs. I could go on. > >Alan > > >Greg > >Appreciate your response. > >Best, > >Maarten > > > >_______________________________________________ > >CWG-Stewardship mailing list > >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

1 0

Re: [CWG-Stewardship] Strickling Remarks from 4 December re IANA Transition and Accountability
by Alan Greenberg Dec. 14, 2014

Dec. 14, 2014

"Should we be reticent about proposing new accountability measures because it will make the Board uncomfortable? I think not." I think not as well. Otherwise I would be a fool to be supporting the ALAC position. If ICANN is to survive, I think the "trust" issue needs to be confronted. And to me, that means not only publishing an infinite number of stats and after-the-fact-rationales, but effectively means less Board autonomy. By hook or crook. We need to live the multistakeholder model, not just preach it. Alan At 14/12/2014 01:49 PM, Gomes, Chuck wrote: >Alan, > >I think we can say that there will definitely be >âa lot of discomfort with strong new >accountability measuresâ on the part of many >of the Board members and even more so on the >part of the General Counselâs office. Change >is usually uncomfortable but sometimes it is >needed and helpful. Should we be reticent about >proposing new accountability measures because it >will make the Board uncomfortable? I think not. > >Chuck > >From: Alan Greenberg [mailto:alan.greenberg@mcgill.ca] >Sent: Sunday, December 14, 2014 12:03 PM >To: Gomes, Chuck; Guru Acharya >Cc: cwg-stewardship(a)icann.org >Subject: RE: [CWG-Stewardship] Strickling >Remarks from 4 December re IANA Transition and Accountability > >Chuck, I feel awkward trying to say what the >Board or particular Board member want, but I >will try to elaborate. Based on my ATRT2 >experience, I think that there will be a lot of >discomfort with strong new accountability >measures. I am not saying that they would not be >accepted, I think that they will. But the >current CWG proposal will require very little - >see Jonathon and Lise's message on overlaps. Alan >-- >Sent from my mobile. Please excuse brevity and typos. >On December 14, 2014 11:34:19 AM EST, "Gomes, >Chuck" <<mailto:cgomes@verisign.com>cgomes(a)verisign.com> wrote: >Alan, > > >I am one that isnât worried about your motives >and I am quite sure that that is the same for >most of us. But I do need some clarity on one of your statements below. > > >Chuck > > >From: Alan Greenberg [mailto:alan.greenberg@mcgill.ca] >Sent: Sunday, December 14, 2014 1:17 AM >To: Guru Acharya >Cc: Gomes, Chuck; <mailto:cwg-stewardship@icann.org>cwg-stewardship(a)icann.org >Subject: Re: [CWG-Stewardship] Strickling >Remarks from 4 December re IANA Transition and Accountability > > >Guru, perhaps that is what you think drives me, >but it is not the case. I must admit I am >getting a bit tired of having people tell me what my motivations are. > >I am arguing for what I believe is the best path >forward. It does happen to coincide with what I >suspect the NTIA will accept, which makes it even better in my mind. > >And I have no interest in discussing what the >Board WANTS. I am sure at some level, many Board >members would prefer no substantive change (and >the current CWG comes pretty close to that with >respect to ICANN needing to change to meet the plan). >[Chuck Gomes] What do you mean when you appear >to say that âthe current CWG comes pretty >close toâ what âmany Board members would prefer no substantive changeâ? > > >Your quote regarding "or they come up with >something that is unacceptable to the Board" was >out of context. What I said (rephrased) was that >my recollection was that the Accountability >Recommendation would go to the ICANN Board, and >that if the Rec. was totally unacceptable it >would not be implemented. I have no interest in >tilting at windmills, I do not like to waste my >time if indeed there is NO chance that it would >go forward. ICANN Bylaw changes MUST go through >the ICANN Board. That is a fact and all the posturing will not change that. > >If the ALAC proposal were to go forward, it will >NOT result with what the ICANN Board wants. but >hopefully something that they can live with. > >I have no interest in discussing whether one >group or another has lost its moral authority, >or a wish that the US Gov't should fall on its knees before us. > >Alan > > > >At 13/12/2014 12:46 PM, Guru Acharya wrote: >Alan, > >So much of what you say is driven by what the >NTIA wants and what the ICANN board wants. > >For example: "...I think the chances are high >that it will be rejected by the NTIA either on >overall dislike of the model..." and ... "... >or they come up with something that is unacceptable to the Board ..." > >NTIA has already pushed 4 constraints down our >throats in a top-down manner. ICANN pushed some >additional constraints down our throats using >the Scoping Document. Within all those >constraints, why are you looking for additional ways to please NTIA and ICANN? > >I'm not sure how predicting acceptance by the >top aligns with a bottom up process. > >Its more about what "we", at the bottom of the >community, want regardless of what the top >desires. And the NTIA should fall on its knees >and accept it. The NTIA is not doing anybody a >favour. It has already lost its moral authority to be the steward of the DNS. > >On Sat, Dec 13, 2014 at 10:40 PM, Alan Greenberg ><<mailto:alan.greenberg@mcgill.ca>alan.greenberg(a)mcgill.ca > wrote: >At 13/12/2014 11:18 AM, Gomes, Chuck wrote: >Thanks a lot Alan for responding. Please see my comments inline below. > >Chuck > >From: Alan Greenberg [ ><mailto:alan.greenberg@mcgill.ca>mailto:alan.greenberg@mcgill.ca] >Sent: Thursday, December 11, 2014 4:22 PM >To: Gomes, Chuck; Greg Shatan; Maarten Simon >Cc: <mailto:cwg-stewardship@icann.org>cwg-stewardship(a)icann.org >Subject: RE: [CWG-Stewardship] Strickling >Remarks from 4 December re IANA Transition and Accountability > >At 11/12/2014 10:28 AM, Gomes, Chuck wrote: >Allan, > >I want to comment on a few of the points you make in the exchange below. > >1. ". . . the ICANN board has a rather >powerful reason for being flexible and >accomodating" . Am I correct that that reason >is the risk of losing the IANA functions? If >so, I would agree but I would also point out >that for that risk to be real it seems to me >that there must be some entity that could >reassign those functions. For now that is >NTIA. What would it be if NTIA goes away? >The powerful reason I was referring to is I >believe (and I have no guarantee that it is >supported by the majority of the Board, although >I have had some discussions) that a solution >that gives IANA to ICANN (requiring significant >accountability changes that would implicitly >reduce their absolute power) would be far more >palatable the Contract Co model where instead of >internal accountability, we have the threat of >external action (ie breach of the contract going somewhere else at some point). >[Chuck Gomes] Is there a word missing in >ÃÂ¢Ãâ. . . would be far more palatable e >the Contract Co model where instead of internal >accountability, we have the threat of external >action (ie breach of the contract going >somewhere else at some point)ÃÂ¢â¬ . II >donÃÂ¢t t understand what you intendended to say. > > >AG: Yes, there was a word missing, two actually. >Removing the parentheticals to improve readability: >The powerful reason I was referring to is THAT I >believe that a solution that gives IANA to ICANN >would be far more palatable THAN the Contract Co >model where instead of internal accountability, >we have the threat of external action. >To be clear, it is my belief that if the Board >were presented with two options: >1. The CWG Contract Co model; >2. The ALAC model with IANA being given to ICANN >and ICANN accepting significant loss of Board autonomy related to IANA; >that the Board would pick option 2. >I also believe that this would be the preference >for NTIA as well. If you want the rationale for >that, see the start of my reply to Jordan Carter >on ><https://community.icann.org/x/YoEHAw>https://community.icann.org/x/YoEHAw, >about 3/4 down the page. > > > > >2. "It is SO attractive to label ICANN as >unchanging and inflexible, but current evidence >does not bear that out." Can you share any >cases where ICANN has been flexible about giving >the Board the final say on a decision? >No. Today they have ultimate say over pretty >much everything EXCEPT where they accept binding >arbitration to resolve contract disputes. The >Bylaws were written to give the Board such full >power, and there has never been a reason for >them to give any of that power up. This, I believe, is such a reason. >[Chuck Gomes] Agree. > >3. "I actually have faith that the >Accountability CCWG can come up with effective >accountability measures that ICANN will be >obliged to accept if it is exchange for keeping >the IANA function" I hope you are correct but >I have serious doubts that that will happen >unless there is a real risk of them losing the >IANA functions and a refer back to 1 above. >I see VERY little accountability changes to >adapt to the Contract Co. model. Other than the >IAP, ICANN is going from one contracting entity >(NTIA) to another (Contract Co,) both of whom >can make a decision to reassign the IANA >contract in the case of poor performance or >whatever reasons the contact may allow. To fix >the IANA problems a number of years ago, ICANN >took measures to ensure that IANA was >professionally managed and at this stage is >doing a fine job (by all reports). ICANN did not >fix the IANA problems with accountability >measures but with standard good management >practices. I think it would do the same under >contract assignment by Contract Co. >[Chuck Gomes] I would like to think that as well >but shouldnÃÂ¢t we e have a mechanism in place if we areare both wrong? > > >If we are wrong, then either the the >Accountability CCWG will through up their hands >and give up, which means the proposal is dead, >or they come up with something that is >unacceptable to the Board (I think their Recs go >there, but not really sure), or they come up >with something that is judged insufficient by >the NTIA and the proposal is dead. >The Contract Co. proposal will not have much >problem with the Accountability CCWG because so >little is needed (see my note to Jordan), but I >think the chances are high that it will be >rejected by the NTIA either on overall dislike >of the model, or some of the many "details" >(including cost and funding) will not provide >sufficient certainty that it will work and continue to work. >Either way has it's potential for failure. I've >made my choice on which I believe is more likely to succeed. > > > >The ATRTs have managed to make incremental >changes that have enhanced accountability, but >virtually none that really change how decisions >are made and the involvement of MS in those >decisions. Certainly ATRT2 TAKLKED about some >such real changes, but they basically did not >fly because we got clear messages that the Board >would resist them and we backed off. >[Chuck Gomes] Agree. >Accountability will be forced upon ICANN (in my >mind), only if it is in exchange for something >it really wants. And IANA is one such thing. >[Chuck Gomes] Agree. > > >As an add-on thought. The IANA issue is probably >not sufficient to immediately fix all >accountability issues (ie Track 2 of the CCWG), >but if we push through the IANA-centric ones, >that will open the door (I think the expression >is that the ideas will have been "socialized" >and not longer so foreign). Once the Board >accepts that it is not all-powerful, I think >that the rest will be a lot easier - perhaps not easy, but easier. >Alan > > > >Alan > >Chuck > > > >From: ><mailto:cwg-stewardship-bounces@icann.org>cwg-stewardship-bounces(a)icann.org >[ mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Alan Greenberg >Sent: Wednesday, December 10, 2014 9:32 PM >To: Greg Shatan; Maarten Simon >Cc: <mailto:cwg-stewardship@icann.org>cwg-stewardship(a)icann.org >Subject: Re: [CWG-Stewardship] Strickling >Remarks from 4 December re IANA Transition and Accountability > >At 10/12/2014 02:53 PM, Greg Shatan wrote: >Maarten: >My answers are inline below. >Greg >On Mon, Dec 8, 2014 at 5:46 PM, Maarten Simon ><<mailto:maarten.simon@sidn.nl>maarten.simon(a)sidn.nl> wrote: >Hi Greg, >Although I personally have not made up my mind >as yet if the contract co or an internal ICANN >solution is preferable, I have posted a very >rough idea for an internal solution in another >thread that I have not seen your response to. I >repeat it here as I am interested to here from >you if you think it would be legally possible >(apart from the fact that you probably do not support it for other reasons): >ÃÆÃâÃÃÂ¢If If we could arrange via >the bylaws t that the ICANNNNNN board explicitly >has to follow orders from a MRT-like structure, >GS: This is a pretty big "if." Unlike Contract >Co., which would be built from the ground up to >be a corporation with very limited purpose and >goals and limitations upon its directors and >officer, and thus lends itself to this >"following orders" model, ICANN is an existing >organization with a large board and officer >group and many activities. At best, this type of >organization does not lend itself to such a >model. At worst, it's not even possible. But >let's assume, solely for the sake of argument, >that the ICANN bylaws can be modified in this >fashion. I am assuming that the MRT will be >"internal-to-ICANN" like the current SOs and ACs >(and in contrast to the ICG). Is that >correct? If so, how do you involve the global >multistakeholder community (beyond ICANN) as required by the NTIA? >AG: >I will no doubt echo some of what Olivier has >said, despite Milton having explained that he is wrong. >Yes, it is more difficult to retrofit such >measures into the existing ICANN, but then the >ICANN board has a rather powerful reason for being flexible and accomodating. >It is not clear how "internal" an MRT would be. >It would be organized under the auspices of >ICANN. Whether it "reports" to ICANN is >something else altogether. The relationship >between the IETF and ISOC might be a good model. >ISOC provides funding and perhaps legal >protection but I don't think that we could say >that the IETF is internal to ISOC or controlled by it. >The ICG and the Stewardship CWG have >representation from outside of ICANN. Yes, >Milton points out that they were created due to >pressure and conditions set by the NTIA. As >above, the desire to retain IAINA is a mighty >big carrot to continue the tradition.ICANN >partially funded NetMundial, and completely >different form of MS event and it did so without US government pressure. >It is SO attractive to label ICANN as unchanging >and inflexible, but current evidence does not bear that out. > >we might not need a contract but have an (internal) MoU/SLA or whatever. >GS: There really is no such thing as an >internal MoU/SLA. Both of these are agreements >(just like the IANA Functions Contract), and >need to be made between two or more legal >entities capable of contracting. If the >MRT-like structure is internal to ICANN, it >can't have a contract with ICANN -- that would >be ICANN contracting with itself. The >"whatever" would have to be an internal document >of a non-contractual/non-agreement >nature. Conceivably, it could be a policy. If >it is a policy, it would most likely have to go >through an ICANN Policy Development >Process. Would this be done separately by the >ccNSO and the GNSO under their separate PDP >guidelines? Or would we try to put together a >joint PDP Working Group? And how long would >this PDP take to develop an "IANA Functions Policy"? >The other thing the IANA Functions Contract >establishes is that the right to run the IANA >Functions ultimately resides in Contract >Co. ICANN's right to do it is purely >contractual; essentially, ICANN is a licensee, >and the MRT is a a licensor. Under this >scenario, the current IANA Contract goes away, >and ICANN is left holding the right to perform >the IANA Functions. This means that the IANA >Functions are now an inherent right of >ICANN This is a very different overall set-up, >with different consequences. Losing a right one >has by contract is a very common problem, and is >as old as contracts. Losing an inherent right >and sector of services because a committee says >that you have failed to live up to internal >policies is both very uncommon and very novel, >creating considerable uncertainty even if it is a technical possibility. >AG: >I have no clue as to the legal issues involved, >but apparently ICANN can sign a MoU with an >internal body. The relationship between ICANN >and the At-Large regional At-large Organizations >(RALOs) are established through MoUs. And >although you presume that the MRT would be >wholly internal to ICANN, that is a premise in your mind, but not mine. >Yes, without Contract Co, ICANN has the right to >continue performing IANA functions. That >provides a level of stability that the >possibility of moving it (potentially every 5 >years if some people have their way). But if the >MRT can direct how that is done, that may not be >so bad. And It is not inconceivable that the MRT >could direct ICANN to divest itself of IANA in extreme situations. > >If the ICANN board would at a certain moment in >time still decide not to follow orders of the >MRT, I would assume it may be sued by affected >parties for violating its own bylaws. >GS: Litigation should be a last resort, not a >first resort, when it comes to >enforcement. Contract Co. can terminate the >contract (or decide not to sign another one when >it expires). The MRT has no such ability. That >is why you are suggesting litigation -- which is >not an "internal-to-ICANN" solution at all. In >addition to not being "internal-to-ICANN," >litigation (in any jurisdiction) is expensive, >lengthy and consumes great time and resources, >and may not produce a result in any kind of >useful timeframe. In any event, who are the >"affected parties" that would sue? Is it only >one registry, or is it many? What if it's a >stakeholder group, such as "civil society"? If >there are many litigants, they would need to >enter into some sort of joint litigation >agreement, form a coordinating group and deal >with a whole host of other things. And not >every affected party has a litigation war chest >to go up against ICANN -- unlike Contract Co., >which will be indemnified. I don't think there's >any way that ICANN would agree to indemnify, >defend and hold harmless every "affected party" >that might challenge a decision relating to IANA >Functions. So, litigation funding would be a very real issue. >Finally, I'm not at all sure that the "affected >parties" will have the standing to sue ICANN for >violating its bylaws. This might be a right >that a shareholder would have if ICANN had >shareholders (but nonprofits don't have >shareholders). Third parties may not have a >cause of action here on that front, and would >need to find some other theory that supports a >lawsuit. By contrast, breach of contract >litigation is fairly straightforward (not that >I'm supporting litigation before other forms of escalation are exhausted). > >We further may dictate in the bylaws that ICANN >has to give up the IANA function if decided by >this MRT and of course seal it by dictating that >these specific articles may only be changed with >the explicit consent of the MRT.ÃÆÃâÃÃÂ¢ >p> GS: Agaain, I'm not at all sure we can >dictate in the bylaws that ICANN has to "give up >the IANA function if decided by the MRT." (By >contrast, it's quite clear that ICANN can enter >into enforceable obligation if it signs an >agreement with a third party.) But again, let's >assume it for the sake of argument. In your >scenario, it is implicit that the right to >perform the IANA Functions is an inherent right >of ICANN, not a right granted to it by a third >party. So instead of Contract Co. terminating >an agreement, we have the ICANN Board being >instructed to cause ICANN to cease part of its >services. I am much more skeptical that this is >a realistic assumption, especially since it >could run counter to the fiduciary duty of the >Directors to ICANN. (By contrast, I don't see >the MRT instructing Contract Co. to do something >counter to Contract Co.'s interests, given the >limited scope and purpose of Contract Co.) But >let's go on. The concept of ICANN "giving up" >the IANA functions is quite nebulous. Since >it's an inherent right of ICANN's, ICANN would >have to run the RFP to find the next IANA >Functions Operator. Are you assuming that the >MRT will do this as well, rather than ICANN? >That seems like another big assumption. And >what exactly would ICANN be transferring? If it >is an asset of ICANN, it may expect compensation >for it (indeed there could be fiduciary duty >issues if the Board "gives it away." >Also, once the IANA Functions are transferred >away from ICANN, how will oversight and >accountability continue (since all of the >oversight and accountability is >"internal-to-ICANN") -- this seems like quite a >big issue in terms of "separability," >actually. Will the new IANA be required by the >RFP to amend its bylaws and replicate the MRT >and the CSC and the IAP (and the IRB) to match the current set-up? >Another big difference (and I think a >disadvantage) is that there is no periodic >expiration of the IANA Contract, with the >implicit or explicit promise of an RFP or at >least a re-examination of the terms of the >agreement. In essence, this now becomes ICANN's >right in perpetuity, unless it fails to properly >perform the IANA Functions in a very significant and ongoing way. >Finally, while there are ways to limit bylaw >changes that i am aware of under US law (e.g., >supermajority voting combined with board >structuring), I really don't think that this >power can be put into the hands of the MRT >without a host of other governance changes to >ICANN. Of course, without research I can't be >sure, and it may be that some significant >reworking of ICANN's overall Board and >governance structure could elicit this >result. But that would require further research and consideration. >Overall, this seems a lot more complex and >uncertain than the set-up in the Draft >Proposal. This also does not deal with >operational aspects of replacing NTIA. In >addition to an MRT-like structure, are you also >assuming a CSC-like structure to provide basic >operational oversight of the IANA Functions and >an Appeals Panel for disputes regarding how the >IANA Functions are carried out? If so, there's >no real advantage in terms of the level of >complexity (and probably a disadvantage, at >that). In any event, any proposal has to deal >with more than just separability. >AG: >Perhaps it is time for us to stop talking about >what we think might not be possible (as the >above paragraphs do several times) and get some facts. >ICANN regularly accepts the concept that an >external body can tell it exactly what to do - >many of its contracts specify binding >arbitration which leave the ICANN Board with no >wriggle room. ICANN considers this preferable to >litigation, and it accepts the consequences that >it will be bound to honour what an external party dictates. >I actually have faith that the Accountability >CCWG can come up with effective accountability >measures that ICANN will be obliged to accept if >it is exchange for keeping the IANA function. > >I know it is (still) very rough and I directly >agree that separating the IANA function will in >a legal sense probably be a lot more difficult, >I think it would be possible under my legal system at home. >GS: I am not sure that this is impossible, but >there are a number of very fundamental "ifs" and >assumptions here that seem to make this >speculative and uncertain in the extreme, with >no virtue other than to be >"internal-to-ICANN." I also don't see the >advantages of this set-up, but perhaps I am missing something. >AG: >Then we agree to disagree. I see stability, >working with a known entity, lower costs >(potentially a LOT lower) and not adding >significant complexity and processes as being a >large benefit. I see not having to deal with >lawsuits over failed RFP bids to take the IANA >contract as a benefit (in many cases, suing >after a failed bid is almost automatic. I value >a higher degree of certainty that the three core >IANA functions will stay together instead of >being fractured as the result of mandatory RFPs. I could go on. >Alan > >Greg >Appreciate your response. >Best, >Maarten > > >_______________________________________________ >CWG-Stewardship mailing list ><mailto:CWG-Stewardship@icann.org>CWG-Stewardship(a)icann.org >https://mm.icann.org/mailman/listinfo/cwg-stewardship

1 0

Re: [CWG-Stewardship] [Internal-cg] CCWG Accountability
by WUKnoben Dec. 14, 2014

Dec. 14, 2014

I agree that close coordination is needed at least between the CWG-Stewardship and the CCWG-Accountability. In addition with respect to the timeline coordination is needed with the ICG. The respective charters of CWG-Stewardship and CCWG-Accountability make reference that << Accountability for the administration of the IANA functions (i.e., implementation and operational accountability), however, is properly within the scope of the CWG-Stewardship >> What makes me a bit nervous is the timeline for workstream 1 (WS1) of CCWG-Accountability focusing on mechanisms enhancing ICANN accountability that must be in place or committed to within the time frame of the IANA Stewardship Transition. At the time being submission of WS1 is scheduled for June 2014. However the Stewardship transition proposals (from CWG-Stewardship) are expected by Jan 2014. I’m not fully clear what the potential impact on the overall timeline may be. But this should be discussed – and coordinated – between the various groups’ leaderships. Best regards Wolf-Ulrich From: Kavouss Arasteh Sent: Saturday, December 13, 2014 12:49 AM To: Drazek, Keith Cc: accountability-ccg-members(a)icann.org ; gac-iana-cgroup(a)icann.org ; ICG Subject: Re: [Internal-cg] CCWG Accountability Alissa, Thank you very much for your message. I will participate in CCWG ,for the time being and until the GAC chair make different rarrangements, as A PARTICIPANT. When I intervene, I make it clear that I am speaking on that capacity, should I need to intervene as ICG,as I made once, indicating that the deadline for Workstream 1 should meet and match with time lines that ICG established. What I can inform you now as ICG Liaison is that the course of action being taken does not correspond to the expectation of the overall accountabilty and there is insufficient coordination between CWG and CCWG workstream 1. Infact what ICG awaiting on accountability for its current activities ON NAMES should be fed from CWG and not CCWG. tHE Scope of activities of CCWG on accountabilty is currently norrowed down to collection of information from the past expereince and not addressing the fundamental issue of accountability ,if and only if, NTIA transfers the stewardship of IANA functions to Global Multistakeholder which would certainly bedifferent from the existing structure and mechanism of ICANN . We should all remember that currently ICANN is accountable to NTIA.To which entity ICANN would be accountable after transition, it is not yet clear. Certainly ,ICANN would not be accountable to ICANN .tHERE MUST BE A WORKABLE MECHANISM to which ICANN would be accountable .This is a fact and reality. By the way, I was not voluteer to be Liason at CCWG, i WAS VOLUNTEERED FOR cwg, YOU ASKED ME TO WITHDRAW FROM CWG and I respected your request tks Kavouss 2014-12-12 21:26 GMT+01:00 Drazek, Keith <kdrazek(a)verisign.com>: I would also add that Kavouss, like anyone, can participate actively in the Enhancing ICANN Accountability CCWG as an individual participant. I will be doing the same thing. I am not the official "appointed member" from the Registries Stakeholder Group (GNSO) but I will still be very active on behalf of Verisign, my employer. Similarly, Kavouss can participate actively on behalf of the Government of Iran or in his individual capacity. There is no restriction to anyone's active participation. Hope that helps! Sent from my iPhone On Dec 12, 2014, at 2:45 PM, "Alissa Cooper" <alissa(a)cooperw.in> wrote: Hi Kavouss, As I mentioned to you off-list, I think it’s fine if you want to participate in the CCWG-Accountability as both a GAC representative and ICG liaison, as long as (i) you confirm that the GAC wants you to serve as its representative, which is a decision that needs to be made among you and the other GAC members, without involvement from the ICG, and (ii) you make it clear to all CCWG participants that all of your contributions are on behalf of the GAC unless you explicitly state that you are providing information from the ICG. The ICG has no role in decisions of the GAC about the GAC’s representation in the CCWG. As the ICG discussed in Los Angeles, (see pages 50-60 of our meeting transcript: http://la51.icann.org/en/schedule/fri-icg/transcript-icg-17oct14-en.pdf ) the ICG wanted to make sure that we had people who could send information back and forth between our group and the CCWG. As summarized in the transcript, "Anything you think is important, let us know. Anything that we think is important, we'll let you know." The structure of the CCWG had not been formulated at the time when you agreed to liaise, but I think we had good agreement within the ICG nonetheless that the liaison role there on our behalf would be to share information back and forth, and not to specifically represent the ICG or vote on our behalf. If you would prefer, we can see if we can find a different ICG liaison or rely solely on Keith Drazek for now if you think serving as the liaison will interfere with your ability to participate in the CCWG. Best, Alissa On Dec 12, 2014, at 3:32 AM, Kavouss Arasteh <kavouss.arasteh(a)gmail.com> wrote: Dear All, I wish to inform you that on the unfounded bureaucratic ground ,people wishes to avoid or prevent receiving any comments from me on the most crucial and most fundamental issue of ICANN ACCOUNTABILITY CCWG . However, I continue to comments and do in no way accept that because I am not the member of that group ( not included in the Thomas Schneider letter to the chair of that group my sincere volunteer to fully and actively participate as GAC member from Asia Pacific which is the most largest ICANN geographical region with more than 75 countries or geographical dependent territories , my volunteer was rejected by the chair and the crew ). This is not fair nor acceptable I have asked to be the member of that Group from July 2014 in multiple communications to the former GAC Chsair and the Secretary. We need to encourage those who wish to contribute and not put an obstacle in using purely bureaucratic element that participants or Lisison can not actively contribute Regards Kavouss _______________________________________________ Internal-cg mailing list Internal-cg(a)icann.org https://mm.icann.org/mailman/listinfo/internal-cg -------------------------------------------------------------------------------- _______________________________________________ Internal-cg mailing list Internal-cg(a)icann.org https://mm.icann.org/mailman/listinfo/internal-cg

2 1

Re: [CWG-Stewardship] Strickling Remarks from 4 December re IANA Transition and Accountability
by Alan Greenberg Dec. 13, 2014

Dec. 13, 2014

At 11/12/2014 10:28 AM, Gomes, Chuck wrote: >Allan, > >I want to comment on a few of the points you make in the exchange below. > >1. ". . . the ICANN board has a rather >powerful reason for being flexible and >accomodating". Am I correct that that reason >is the risk of losing the IANA functions? If >so, I would agree but I would also point out >that for that risk to be real it seems to me >that there must be some entity that could >reassign those functions. For now that is >NTIA. What would it be if NTIA goes away? The powerful reason I was referring to is I believe (and I have no guarantee that it is supported by the majority of the Board, although I have had some discussions) that a solution that gives IANA to ICANN (requiring significant accountability changes that would implicitly reduce their absolute power) would be far more palatable the Contract Co model where instead of internal accountability, we have the threat of external action (ie breach of the contract going somewhere else at some point). >2. "It is SO attractive to label ICANN as >unchanging and inflexible, but current evidence >does not bear that out." Can you share any >cases where ICANN has been flexible about giving >the Board the final say on a decision? No. Today they have ultimate say over pretty much everything EXCEPT where they accept binding arbitration to resolve contract disputes. The Bylaws were written to give the Board such full power, and there has never been a reason for them to give any of that power up. This, I believe, is such a reason. >3. "I actually have faith that the >Accountability CCWG can come up with effective >accountability measures that ICANN will be >obliged to accept if it is exchange for keeping >the IANA function" I hope you are correct but >I have serious doubts that that will happen >unless there is a real risk of them losing the >IANA functions and a refer back to 1 above. I see VERY little accountability changes to adapt to the Contract Co. model. Other than the IAP, ICANN is going from one contracting entity (NTIA) to another (Contract Co,) both of whom can make a decision to reassign the IANA contract in the case of poor performance or whatever reasons the contact may allow. To fix the IANA problems a number of years ago, ICANN took measures to ensure that IANA was professionally managed and at this stage is doing a fine job (by all reports). ICANN did not fix the IANA problems with accountability measures but with standard good management practices. I think it would do the same under contract assignment by Contract Co. The ATRTs have managed to make incremental changes that have enhanced accountability, but virtually none that really change how decisions are made and the involvement of MS in those decisions. Certainly ATRT2 TAKLKED about some such real changes, but they basically did not fly because we got clear messages that the Board would resist them and we backed off. Accountability will be forced upon ICANN (in my mind), only if it is in exchange for something it really wants. And IANA is one such thing. Alan > >Chuck > > > >From: cwg-stewardship-bounces(a)icann.org >[mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Alan Greenberg >Sent: Wednesday, December 10, 2014 9:32 PM >To: Greg Shatan; Maarten Simon >Cc: cwg-stewardship(a)icann.org >Subject: Re: [CWG-Stewardship] Strickling >Remarks from 4 December re IANA Transition and Accountability > >At 10/12/2014 02:53 PM, Greg Shatan wrote: > >Maarten: > >My answers are inline below. > >Greg > >On Mon, Dec 8, 2014 at 5:46 PM, Maarten Simon ><<mailto:maarten.simon@sidn.nl>maarten.simon(a)sidn.nl> wrote: >Hi Greg, >Although I personally have not made up my mind >as yet if the contract co or an internal ICANN >solution is preferable, I have posted a very >rough idea for an internal solution in another >thread that I have not seen your response to. I >repeat it here as I am interested to here from >you if you think it would be legally possible >(apart from the fact that you probably do not support it for other reasons): >Ã¢If we could arrange via the bylaws that the >ICANNNN board explicitly has to follow orders from a MRT-like structure, > >GS: This is a pretty big "if." Unlike Contract >Co., which would be built from the ground up to >be a corporation with very limited purpose and >goals and limitations upon its directors and >officer, and thus lends itself to this >"following orders" model, ICANN is an existing >organization with a large board and officer >group and many activities. At best, this type of >organization does not lend itself to such a >model. At worst, it's not even possible. But >let's assume, solely for the sake of argument, >that the ICANN bylaws can be modified in this >fashion. I am assuming that the MRT will be >"internal-to-ICANN" like the current SOs and ACs >(and in contrast to the ICG). Is that >correct? If so, how do you involve the global >multistakeholder community (beyond ICANN) as required by the NTIA? > >AG: >I will no doubt echo some of what Olivier has >said, despite Milton having explained that he is wrong. > >Yes, it is more difficult to retrofit such >measures into the existing ICANN, but then the >ICANN board has a rather powerful reason for being flexible and accomodating. > >It is not clear how "internal" an MRT would be. >It would be organized under the auspices of >ICANN. Whether it "reports" to ICANN is >something else altogether. The relationship >between the IETF and ISOC might be a good model. >ISOC provides funding and perhaps legal >protection but I don't think that we could say >that the IETF is internal to ISOC or controlled by it. > >The ICG and the Stewardship CWG have >representation from outside of ICANN. Yes, >Milton points out that they were created due to >pressure and conditions set by the NTIA. As >above, the desire to retain IAINA is a mighty >big carrot to continue the tradition.ICANN >partially funded NetMundial, and completely >different form of MS event and it did so without US government pressure. > >It is SO attractive to label ICANN as unchanging >and inflexible, but current evidence does not bear that out. > > > >we might not need a contract but have an (internal) MoU/SLA or whatever. > >GS: There really is no such thing as an >internal MoU/SLA. Both of these are agreements >(just like the IANA Functions Contract), and >need to be made between two or more legal >entities capable of contracting. If the >MRT-like structure is internal to ICANN, it >can't have a contract with ICANN -- that would >be ICANN contracting with itself. The >"whatever" would have to be an internal document >of a non-contractual/non-agreement >nature. Conceivably, it could be a policy. If >it is a policy, it would most likely have to go >through an ICANN Policy Development >Process. Would this be done separately by the >ccNSO and the GNSO under their separate PDP >guidelines? Or would we try to put together a >joint PDP Working Group? And how long would >this PDP take to develop an "IANA Functions Policy"? > >The other thing the IANA Functions Contract >establishes is that the right to run the IANA >Functions ultimately resides in Contract >Co. ICANN's right to do it is purely >contractual; essentially, ICANN is a licensee, >and the MRT is a a licensor. Under this >scenario, the current IANA Contract goes away, >and ICANN is left holding the right to perform >the IANA Functions. This means that the IANA >Functions are now an inherent right of >ICANN This is a very different overall set-up, >with different consequences. Losing a right one >has by contract is a very common problem, and is >as old as contracts. Losing an inherent right >and sector of services because a committee says >that you have failed to live up to internal >policies is both very uncommon and very novel, >creating considerable uncertainty even if it is a technical possibility. > >AG: >I have no clue as to the legal issues involved, >but apparently ICANN can sign a MoU with an >internal body. The relationship between ICANN >and the At-Large regional At-large Organizations >(RALOs) are established through MoUs. And >although you presume that the MRT would be >wholly internal to ICANN, that is a premise in your mind, but not mine. > >Yes, without Contract Co, ICANN has the right to >continue performing IANA functions. That >provides a level of stability that the >possibility of moving it (potentially every 5 >years if some people have their way). But if the >MRT can direct how that is done, that may not be >so bad. And It is not inconceivable that the MRT >could direct ICANN to divest itself of IANA in extreme situations. > > > >If the ICANN board would at a certain moment in >time still decide not to follow orders of the >MRT, I would assume it may be sued by affected >parties for violating its own bylaws. > >GS: Litigation should be a last resort, not a >first resort, when it comes to >enforcement. Contract Co. can terminate the >contract (or decide not to sign another one when >it expires). The MRT has no such ability. That >is why you are suggesting litigation -- which is >not an "internal-to-ICANN" solution at all. In >addition to not being "internal-to-ICANN," >litigation (in any jurisdiction) is expensive, >lengthy and consumes great time and resources, >and may not produce a result in any kind of >useful timeframe. In any event, who are the >"affected parties" that would sue? Is it only >one registry, or is it many? What if it's a >stakeholder group, such as "civil society"? If >there are many litigants, they would need to >enter into some sort of joint litigation >agreement, form a coordinating group and deal >with a whole host of other things. And not >every affected party has a litigation war chest >to go up against ICANN -- unlike Contract Co., >which will be indemnified. I don't think there's >any way that ICANN would agree to indemnify, >defend and hold harmless every "affected party" >that might challenge a decision relating to IANA >Functions. So, litigation funding would be a very real issue. > >Finally, I'm not at all sure that the "affected >parties" will have the standing to sue ICANN for >violating its bylaws. This might be a right >that a shareholder would have if ICANN had >shareholders (but nonprofits don't have >shareholders). Third parties may not have a >cause of action here on that front, and would >need to find some other theory that supports a >lawsuit. By contrast, breach of contract >litigation is fairly straightforward (not that >I'm supporting litigation before other forms of escalation are exhausted). > >We further may dictate in the bylaws that ICANN >has to give up the IANA function if decided by >this MRT and of course seal it by dictating that >these specific articles may only be changed with >the explicit consent of the MRT.Ã¢ > >GS: Again, I'm not at all sure we can dictate in >the bylaws that ICANN has to "give up the IANA >function if decided by the MRT." (By contrast, >it's quite clear that ICANN can enter into >enforceable obligation if it signs an agreement >with a third party.) But again, let's assume it >for the sake of argument. In your scenario, it >is implicit that the right to perform the IANA >Functions is an inherent right of ICANN, not a >right granted to it by a third party. So >instead of Contract Co. terminating an >agreement, we have the ICANN Board being >instructed to cause ICANN to cease part of its >services. I am much more skeptical that this is >a realistic assumption, especially since it >could run counter to the fiduciary duty of the >Directors to ICANN. (By contrast, I don't see >the MRT instructing Contract Co. to do something >counter to Contract Co.'s interests, given the >limited scope and purpose of Contract Co.) But >let's go on. The concept of ICANN "giving up" >the IANA functions is quite nebulous. Since >it's an inherent right of ICANN's, ICANN would >have to run the RFP to find the next IANA >Functions Operator. Are you assuming that the >MRT will do this as well, rather than ICANN? >That seems like another big assumption. And >what exactly would ICANN be transferring? If it >is an asset of ICANN, it may expect compensation >for it (indeed there could be fiduciary duty >issues if the Board "gives it away." > >Also, once the IANA Functions are transferred >away from ICANN, how will oversight and >accountability continue (since all of the >oversight and accountability is >"internal-to-ICANN") -- this seems like quite a >big issue in terms of "separability," >actually. Will the new IANA be required by the >RFP to amend its bylaws and replicate the MRT >and the CSC and the IAP (and the IRB) to match the current set-up? > >Another big difference (and I think a >disadvantage) is that there is no periodic >expiration of the IANA Contract, with the >implicit or explicit promise of an RFP or at >least a re-examination of the terms of the >agreement. In essence, this now becomes ICANN's >right in perpetuity, unless it fails to properly >perform the IANA Functions in a very significant and ongoing way. > >Finally, while there are ways to limit bylaw >changes that i am aware of under US law (e.g., >supermajority voting combined with board >structuring), I really don't think that this >power can be put into the hands of the MRT >without a host of other governance changes to >ICANN. Of course, without research I can't be >sure, and it may be that some significant >reworking of ICANN's overall Board and >governance structure could elicit this >result. But that would require further research and consideration. > >Overall, this seems a lot more complex and >uncertain than the set-up in the Draft >Proposal. This also does not deal with >operational aspects of replacing NTIA. In >addition to an MRT-like structure, are you also >assuming a CSC-like structure to provide basic >operational oversight of the IANA Functions and >an Appeals Panel for disputes regarding how the >IANA Functions are carried out? If so, there's >no real advantage in terms of the level of >complexity (and probably a disadvantage, at >that). In any event, any proposal has to deal >with more than just separability. > >AG: >Perhaps it is time for us to stop talking about >what we think might not be possible (as the >above paragraphs do several times) and get some facts. > >ICANN regularly accepts the concept that an >external body can tell it exactly what to do - >many of its contracts specify binding >arbitration which leave the ICANN Board with no >wriggle room. ICANN considers this preferable to >litigation, and it accepts the consequences that >it will be bound to honour what an external party dictates. > >I actually have faith that the Accountability >CCWG can come up with effective accountability >measures that ICANN will be obliged to accept if >it is exchange for keeping the IANA function. > > > >I know it is (still) very rough and I directly >agree that separating the IANA function will in >a legal sense probably be a lot more difficult, >I think it would be possible under my legal system at home. > >GS: I am not sure that this is impossible, but >there are a number of very fundamental "ifs" and >assumptions here that seem to make this >speculative and uncertain in the extreme, with >no virtue other than to be >"internal-to-ICANN." I also don't see the >advantages of this set-up, but perhaps I am missing something. > >AG: >Then we agree to disagree. I see stability, >working with a known entity, lower costs >(potentially a LOT lower) and not adding >significant complexity and processes as being a >large benefit. I see not having to deal with >lawsuits over failed RFP bids to take the IANA >contract as a benefit (in many cases, suing >after a failed bid is almost automatic. I value >a higher degree of certainty that the three core >IANA functions will stay together instead of >being fractured as the result of mandatory RFPs. I could go on. > >Alan > > > >Greg >Appreciate your response. >Best, >Maarten

2 1

Strickling Remarks from 4 December re IANA Transition and Accountability
by Greg Shatan Dec. 12, 2014

Dec. 12, 2014

All: I thought that Larry Strickling's remarks at a seminar yesterday would be of interest to the group. Here is the portion of his speech that appears germane to our work and that of the CWG-Accountability: I will finish up by addressing the challenges and opportunities facing us in 2015 with respect to Internet policy. Our core mission at NTIA is to ensure that the Internet remains an engine for economic growth, innovation and free expression. Internationally, the United States has been a vocal advocate of the bottom-up, consensus-based approach to Internet governance known as the multistakeholder model. The multistakeholder model has enabled the Internet to develop into an engine for innovation, free speech and economic growth. Under this model, all stakeholders, whether they be from industry, civil society, or government, come together in an inclusive, transparent, accountable forum to make decisions and solve problems. As the Internet agency, NTIA’s job is to strengthen and promote that model. In 2014, we have seen a growing acceptance of the multistakeholder model around the world, but particularly in developing countries. Earlier this year, Brazil hosted the successful NetMundial conference, which brought together a wide range of stakeholders including technical experts, civil society groups, industry representatives and government officials, all on an equal footing with each other. At this meeting not only did participants agree that Internet governance should be built on democratic multistakeholder processes,” the entire meeting was a demonstration of the open, participative, and consensus-driven governance that has allowed the Internet to develop as an unparalleled engine of economic growth and innovation. A month later, a High-Level Panel, headed by the president of Estonia, Toomas Ilves released a report once again affirming the power of multistakeholder policy development. The panel said it “recognizes, fully supports, and adopts the Internet governance principles produced in the NetMundial Statement.” Most recently, at the International Telecommunication Union’s 2014 Plenipotentiary conference in Busan, Korea, last month, we saw the fruits of all our work to preserve multistakeholder Internet governance. The United States achieved all of its objectives in Busan, including keeping the ITU’s work focused on its current mandate and not expanding its role into Internet and cybersecurity issues. The U.S. delegation, led by Ambassador Danny Sepulveda, successfully built consensus across nations to protect the robust, innovative, multi-stakeholder Internet we enjoy today. This validation of the multistakeholder model comes at a critical time. Last March, NTIA announced its intention to complete the privatization of the Internet Domain Name System (DNS), currently managed by the Internet Corporation for Assigned Names and Numbers (ICANN). This process began in 1998, when ICANN took over important technical functions related to the domain name system, known as the IANA functions, under a contract with NTIA. In our March announcement, NTIA asked ICANN to convene a multistakeholder process to develop a proposal to transition the U.S. stewardship role over the IANA functions to the international community. We did this to ensure that the multistakeholder model for DNS coordination continues. When we announced this transition, we outlined some specific conditions that must be addressed before this transition takes place. First, the proposal must support and enhance the multistakeholder model of Internet governance, in that it should be developed by the multistakeholder community and have broad community support. More specifically, we will not accept a transition proposal that replaces the NTIA role with a government-led or intergovernmental organization solution. Second, the proposal must maintain the security, stability, and resiliency of the domain name system. Third, it must meet the needs and expectations of the global customers and partners of the IANA services. And finally, it must maintain the openness of the Internet. Now that we are eight months past our IANA announcement, it is important to take stock of where this transition stands. We are pleased that the community has responded enthusiastically to our call to develop a transition plan that will ensure the stability, security and openness of the Internet. Acting as a facilitator, ICANN announced this summer the formation of a group representing more than a dozen Internet stakeholder communities that will help develop a transition proposal. As set forth in its charter, the IANA Stewardship Transition Coordination Group is “conduct[ing] itself transparently, consult[ing] with a broad range of stakeholders, and ensur[ing] that its proposals support the security and stability of the IANA functions.” The community is in the process of developing proposals for the specific IANA functions. Earlier this week, a working group focused on domain names released a 100-page proposal for community review and comment. We expect proposals for other of the functions to surface over the next month or so. The community hopes to submit its transition proposal to NTIA by the end of next July, which would allow us to review the proposal before the current contract expires at the end of September 2015. I want to emphasize that we did not set a deadline for this transition. If for some reason the community needs more time, we have the option to extend the current contract for up to four years. ICANN has also launched a process to examine how to ensure it remains accountable to the global Internet community. Specifically, this process will examine how ICANN can strengthen its accountability mechanisms to address the absence of its historical contractual relationship with NTIA. NTIA believes that this accountability process needs to include the stress testing of solutions to safeguard against future contingencies such as attempts to influence or takeover ICANN functions that are not currently possible with the IANA functions contract in place. The two work streams on the IANA transition and enhanced accountability are directly linked and NTIA has repeatedly said that both issues must be addressed before any transition takes place. I am confident that engaging the global Internet community to work out these important issues will strengthen the multistakeholder process and will result in ICANN’s becoming even more directly accountable to the customers of the IANA functions and to the broader Internet community. Getting the transition right will be a major project for NTIA in 2015. The full remarks are at: http://www.ntia.doc.gov/speechtestimony/2014/remarks-assistant-secretary-st… An article about these remarks by Kieren McCarty in the Register is at: http://www.theregister.co.uk/2014/12/05/us_government_tells_icann_no_accoun… <http://www.theregister.co.uk/2014/12/05/us_government_tells_icann_no_accoun…> Greg *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 26