[CWG-Stewardship] Strickling Remarks from 4 December re IANA Transition and Accountability

Wed Dec 10 22:32:06 UTC 2014

Thanks for this detailed response, Greg. I think it pretty well lays to rest the “internalist” argument.

--MM

“If we could arrange via the bylaws that the ICANN 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?

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.

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.

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.

Greg

Appreciate your response.

Best,

Maarten

From: cwg-stewardship-bounces at icann.org<mailto:cwg-stewardship-bounces at icann.org> [mailto:cwg-stewardship-bounces at icann.org<mailto:cwg-stewardship-bounces at icann.org>] On Behalf Of Greg Shatan
Sent: maandag 8 december 2014 19:49
To: Seun Ojedeji
Cc: cwg-stewardship at icann.org<mailto:cwg-stewardship at icann.org>
Subject: Re: [CWG-Stewardship] Strickling Remarks from 4 December re IANA Transition and Accountability

My replies are inline.

Greg

Gregory S. Shatan • Abelman Frayne & Schwab

666 Third Avenue • New York, NY 10017-5621

Direct  212-885-9253<tel:212-885-9253> | Main 212-949-9022<tel:212-949-9022>

Fax  212-949-9190<tel:212-949-9190> | Cell 917-816-6428<tel:917-816-6428>

gsshatan at lawabel.com<mailto:gsshatan at lawabel.com>

ICANN-related: gregshatanipc at gmail.com<mailto:gregshatanipc at gmail.com>

www.lawabel.com<http://www.lawabel.com/>

On Mon, Dec 8, 2014 at 5:06 AM, Seun Ojedeji <seun.ojedeji at gmail.com<mailto:seun.ojedeji at gmail.com>> wrote:
On Mon, Dec 8, 2014 at 6:18 AM, Greg Shatan <gregshatanipc at gmail.com<mailto:gregshatanipc at gmail.com>> wrote:
My responses are inline below.
In fact, it's up to us to identify the IANA-specific aspects of accountability and then determine how the IANA Functions Operator should be held accountable for failures to implement policy and for failures of operational excellence. That is our "accountability track."  And this has been true since we started.
If i may ask, if this group is able to put in place mechanisms that ensure the function operator is indeed accountable...why/what then is the need for the MRT and CSC?

The MRT and CSC are integral parts of our accountability mechanisms, along with the contract (and the ability to terminate it) and the independent Appeals Panel.  What do you think our accountability mechanisms are?

Greg i think you did not get my point. My point is that the major accountability requirement that is IANA specific is that which is related to ensuring implementation based on existing policies. So if this group (or the cwg on accountability) is able to fashion out an internal mechanism that guarantees that aspect. Why will we still need MRT?.

This group has always been "able," as a matter of scope, to fashion an internal-to-ICANN accountability mechanism.  Similarly, NASA, as a matter of scope, has always been "able" to fly a rocket to Mars fueled by a jar of peanut butter.  So, what is stopping us and NASA from accomplishing these objectives?  At the very least, the lack of any sort of plan or proposal showing how one would accomplish this.  So it is not a question of scope, it's a question of putting together a plan.  Is this group "able" as a practical matter to put together a plan for an internal-to-ICANN accountability mechanism that meets the requirements and concerns of the NTIA and various stakeholders?  So far, the answer seems to be "no."  I'm open minded -- if someone puts forth a plan with a reasonable level of detail (e.g., strawman or draft proposal level of detail) and everyone probes it for flaws and asks for further details, which then get filled in, and if that plan, after making it through the gantlet of this group, looks viable, that would be a good thing.  (And, of course, that plan might not include an MRT, or it would include a different sort of multistakeholder body.) However, it hasn't happened and I don't see any real movement toward it, and the time for such action is growing short.  Unless there is some realistic movement forward on an "internal-to-ICANN" plan, the continued reference to the "internal-to-ICANN" concept has no shape and thus no value.  Continuing to advocate for "internal-to-ICANN" is very much like a NASA scientist wandering the halls of NASA with a jar of peanut butter, shouting "To Mars!!"  No matter how much that scientist critiques other plans for going to Mars, his "Peanut Butter Plan" will never be credible without more from him.

I may not have any issue if MRT's role does not include RFP and if the Contract Co is just signing of an MOU that is not term based, because at that point, the MRT will just be something similar to the cwg and will become very much less attractive (except that its waste of resources).

It seems you have an essential issue with separability -- you don't want a term and you don't want an RFP.  So, essentially you want to give ICANN the right in perpetuity to be the IANA Functions Operator, subject perhaps to some completely undefined method for some completely undefined group to remove that right due to a completely undefined failure to meet completely undefined criteria.  Well, I can't give the "undefined" any weight whatsoever.

I'm sorry you think that multistakeholder oversight of the IANA Functions is a "waste of resources."  The NTIA and most of the people on this list (myself included) seem to think it is very valuable -- indeed, for the NTIA it is the essence of the transition.  How do you propose to transfer the NTIA's functions to the global multistakeholder community without any sort of multistakeholder group?

This also will not in anyway reduce the possibility of moving IANA if need be.

I don't see how you can say this.  You want to eliminate the only possibilities this CWG has defined to move IANA if need be.  You propose no method or group or criteria by which moving IANA if need be could be achieved.  Until you provide some alternative, you have reduced -- effectively to zero -- the possibility of moving IANA.

You are perhaps quite experienced in the gTLD space than i am, and realistically speaking i think the gTLD are the ones who should seek a permanent solution that makes the role reside within ICANN because everything about the gTLD currently exist within ICANN and it will not make any economic sense to move it out. So i find it strange that even if there is adequate accountability in place within ICANN, you will still insist on going the contracting route.

Adequate accountability within ICANN is a necessity before we move forward with any transition.  However adequate accountability within ICANN is not sufficient -- we need adequate accountability within ICANN directly related to performance of (or failure to properly perform) the IANA Functions.  This type of accountability is within the scope of this CWG (and not the Accountability CCWG), and so far, we have not seen any plan or proposal for such accountability that is adequate and responds to the concerns regarding separability, etc.  I am not insisting on anything with regard to the contracting route.  To the contrary, I remain open-minded.  If we had an "internal to ICANN" plan that looked like it worked for all our purposes and didn't involve a contract, I would love to look at it and subject it to the same scrutiny that the current proposal has been subjected to.  After that, who knows what would happen?

In my view (and the view of many others in this group), the current CWG proposal was (and is) seen as the most efficient, effective, and independent method for achieving this result, and also the best method for replacing NTIA's other pre-transition roles as well.  I believe we arrived at this in spite of ICANN's current general accountability issues, not because of them.

Negative...i don't agree that is the best approach and again i don't know how you already determine the proposal is efficient especially when we don't even have the details yet. There are definitely other options that allows moving of IANA from ICANN (if absolutely required) one of which does not even require any contracting/MOU/agreement (which can be implemented by the technical community)
We don't have all the details, but we have 10 pages of detail, enough to make a preliminary judgment. These other options -- what detail is there for these options?  What framework is there for these options?  Until there is at least a "strawman" level of detail, these other "options" aren't options at all -- they are just empty catchphrases.

Greg, please do not over-estimate multistakeholder settings especially when it has not been put to practice (as it is in this particular case). That 10page details has not touched critical aspect of MRT which is mainly its formation and charter plus the connection between MRT and contract co (it is not enough to call this a self company....the details is what is important)

 Perhaps I have greater faith in the multistakeholder model than you do.  Of course, we will not know how it works in practice until it is in practice -- but that's true of any plan.  We are developing details and we will be subjecting the model to stress tests, so we should know as much anyone with a plan knows about how that plan will work in practice.  Given that our goal is to transition NTIA's roles to the global multistakeholder community, we have to have some level of faith in the multistakeholder model.  Otherwise, we should just tell the NTIA that transitioning their role to the global multistakeholder community can't be done.  I agree that we need to flesh out how the MRT will be formed and what its charter might look like -- what are your suggestions for these aspects that would give you greater comfort?  The connection between MRT and Contract Co. does need to be fleshed out as well -- I envision this as being written into Contract Co.'s bylaws.  And by the way, I never called Contact Co. a "shelf company" -- it will be lightweight and limited but by definition, it can't be a shelf company.  A shelf company (at least as this term is used in the U.S., refers to an inactive (and never activated) corporation -- it has no assets or liabilities, it has entered into no contracts or other obligations of any kind, it typically has a single "incorporator" rather than a full slate of officers and directors, and it has generic short-form documents rather than any kind of specially-drafted articles of incorporation or bylaws.  Contract Co. should be as close as possible to a "shelf corporation".while still being able to perform its duties and meet the needs of the framework (which actually requires a fairly specifically-developed set of by-laws to keep it small and limited).

Without diminishing the importance of details -- the details are only important if the general framework looks promising and appropriate.  I think we have that, and we have a good understanding of the principles that the details must meet to be acceptable to this group and the larger multistakeholder community.  Now it's just a matter of following those principles and filling in the details -- not a small task, but not one to be overestimated either.

To answer your question directly, I don't believe that the current proposal is in any way based on the premise that the current operator lacks -- and will continue to lack -- appropriate general accountability mechanisms.  It is based on the premise that removing the NTIA from the equation requires us to recommend IANA-specific accountability mechanisms, regardless of how improved ICANN's general accountability mechanisms might be (before or after the IANA Transition).  That is what we have been tasked to do, and that is what we have done.

Greg, you mentioned earlier that the ability to move IANA is required (although i don't necessarily agree but it doesn't hurt to have it) so if there are adequate mechanism within ICANN wouldn't all that will be required is for the mechanism to trigger movement of IANA from ICANN? Why then do we require all the MRT/CSC structure? I also don't agree that NTIA said we should replicate contracting processes (you may direct me to what part of NTIA announcement that implied such)
.
There is broad support for separability in the CWG.  It's in our Principles (letter h) and it's in our Draft Proposal.  You are entitled to disagree, but unless you can convince the CWG to change the Principles and the Proposal, any option we recommend must include separability.,

Well the principles is still in draft state (unless you mean it has just been finalised), in anycase, i have no problem with maintaining the current separability and this is something that can still be maintained internally by adding a few lines in the by-law

The Principles may be in draft but they have broad support, and they are heading toward finality.  So it is certainly most appropriate to consider them heavily in examining any proposal.  Right now, the current separability is entirely a creation of the IANA Contract -- I"m glad you have no problem maintaining the type of separability now embodied in the contract.  However, you go on to say that this separability "can still be maintained internally by adding a few lines in the by-law."  I find this assumption completely unsupported and thus completely lacking in credibility and value.  Why do you think this is true?  What would you put in the by-laws (by-laws aren't magic, they require words that work)?  How would this work? What and who would trigger the separation?  What would be the method for actually separating and finding a new Operator?  Without answers to these questions, you are just running through the halls of the CWG with a jar of peanut butter, shouting "To Mars!"  I'm not buying it -- not because I believe it's impossible -- but because I've been shown nothing on a functional level that makes me believe it is possible.

You say "if there are adequate mechanisms within ICANN...."  What are these "adequate mechanisms"?  Where would they come from?  Remember, it's up to our CWG to come up with mechanisms relating to IANA accountability.

.....and this is the issue, we treat IANA accountability as if its rocket science, i think it may have been a mistake to have separated the CWG as its making it all look like the accountability this group is looking for is different from what the CWG-accountability is looking for.

It's not rocket science, and I don't believe we are treating it that way.  It's just hard work.  Whether having two CWGs is a mistake is beside the point.  The accountability this group is looking for IS different from the accountability the CWG-Accountability is looking for.  As I pointed out earlier in this thread:

The key point I am making is that the "IANA specific aspect of the accountability" is within the scope of our CWG, and has been since the beginning of our work.  As it says in our Charter: "Accountability for the administration of the IANA functions (i.e.,implementation and operational accountability), however, is properly within the scope of this working group."  Conversely, the Charter of CCWG-Accountability says "Accountability for the administration of the IANA functions (i.e., implementation and operational accountability) is not within the scope of the CCWG-Accountability as it is being dealt with by the CWG-Stewardship."

The CWG-Accountability is looking at the much broader question of enhancing ICANN's accountability to its stakeholders in all of its policy-making, implementing, operations, etc. -- everything but the accountability we are looking for.

Your "mechanism" is a complete mystery.  If you want this group to consider an "internal to ICANN" mechanism that would move the right to perform the IANA Functions out of ICANN (and meet all the other requirements in this transition), you'll need to propose one.

The NTIA asks us to develop a proposal that transitions its stewardship to multi-stakeholder. It didn't say that the proposal has to be able to take the right to perform IANA function out of ICANN.

I agree that the NTIA did not say that our proposal has to be able to take the right to perform the IANA functions out of ICANN.  However, the NTIA also did not preclude a proposal that takes the right to perform the IANA Functions out of ICANN.  There was broad support within the CWG for a proposal that included the possibility and ability to take the right to perform the IANA Functions out of ICANN, and therefore that is in our proposal.

The way i interpreted it is that ICANN currently has a growing multi-stakeholder environment and this is the opportunity to transition the stewardship to that community so if this require updating ICANN-by law...so be it.

First, the NTIA did not refer to the "ICANN multistakeholder community," it referred to the "global multistakeholder community."  These are not the same things.  Nonetheless, I don't believe that this necessarily precludes an "internal-to-ICANN" solution, but it does mean that any such solution would have to bring stakeholders not present in ICANN into the oversight and accountability process.  As for updating the ICANN by-laws, this not a magic wand.  Without some idea of what this means (and I've asked a few questions above so that I and others can get some idea), saying "update the ICANN by-laws" is no more valuable than that NASA scientist saying "peanut butter."

Please note that I am not categorically precluding an "internal-to-ICANN" proposal.  But right now, I don't see where that proposal is coming from, much less how it will satisfy even the most basic concerns of various stakeholders.

It is when we propose such and it gets rejected by ICANN board that we can justify that ICANN is not yet mature enough and a contracting route will suffice until there is significant indications of the organisation's maturity

First, we have to have a reasonably tangible and concrete "Internal-to-ICANN" proposal before the CWG, and that proposal has be further developed by and win the support of the CWG.  We don't have even the first step of that , so your scenario above never happens.  If it does happen, it's because the CWG decides that this "internal-to-ICANN" is the best proposal, not because we want to test the ICANN Board's "maturity", before putting forth the current draft proposal.  I am confident we will put forth the proposal that gains the most support from the CWG and the stakeholders, regardless of whether the ICANN Board will like it.  Right now, that seems likely to be a proposal growing out of the current draft proposal, since there is no other tangible proposal on the table.  In any event, whether the ICANN Board would or even has the power to "reject" the proposal is open to question.  As the ICG FAQ states:

15.  How will ICANN Board handle the final proposal submitted by the ICG?

The ICG expects that its proposal, having achieved consensus on the Coordination Group and within the Operational Communities, will be welcomed by the ICANN Board and dutifully transmitted to NTIA

Finally, I never said that the NTIA said we should replicate contracting processes. What makes you say that?

Well you have just implied that in your statement below

No, I have not.  I didn't even mention the NTIA. Please don't put words in my mouth.

  However, unless we have another way to accomplish our objectives, the contract remains the most practical option.

I have "paraphrased" what i believe to be our objective above.
I'm not sure what you are referring to, or what your point is.  Whatever your paraphrase is, our objectives are already well stated in the NTIA's announcement, the ICG RFP and our charter, so hopefully your paraphrase is consistent with those base document.

Regards,

Greg
Regards

Greg
Thanks
Regards!

Greg

Gregory S. Shatan • Abelman Frayne & Schwab

666 Third Avenue • New York, NY 10017-5621

Direct  212-885-9253<tel:212-885-9253> | Main 212-949-9022<tel:212-949-9022>

Fax  212-949-9190<tel:212-949-9190> | Cell 917-816-6428<tel:917-816-6428>

gsshatan at lawabel.com<mailto:gsshatan at lawabel.com>

ICANN-related: gregshatanipc at gmail.com<mailto:gregshatanipc at gmail.com>

www.lawabel.com<http://www.lawabel.com/>

On Sat, Dec 6, 2014 at 2:53 AM, Seun Ojedeji <seun.ojedeji at gmail.com<mailto:seun.ojedeji at gmail.com>> wrote:

Hi Greg,

I am definitely not also in any form of agreement with an extension of the timeline especially as it may not be the same story after USA elections. I am also not sure I have seen much people calling for extension on this list... We both know what has been paramount subject of discussion in the last few weeks and timeline is the least of them.
I am saying since it is definite ( it's a requirement) that some level of accountability will/MUST happen before transition, will it not already handle some of our fears that actually lead to the creation of the current transition proposal. My understanding is that the current transition proposal was mainly inspired on the premise of the current operator lacking appropriate accountability mechanism... No? As you seem to be implying otherwise by your mail.

Cheers!

sent from Google nexus 4
kindly excuse brevity and typos.
On 6 Dec 2014 08:36, "Greg Shatan" <gregshatanipc at gmail.com<mailto:gregshatanipc at gmail.com>> wrote:
Seun:

I don't see how Strickling's remarks provide an "opportunity" for anything.  I presume you are referring to the "spin" that some are putting on this speech as a "hint" that the timeline should be extended.  I think that is a baseless assertion.  The NTIA has indicated since March that they have the option to extend the agreement, so not only is this not "new news" it's no news.  It's also not news that both the IANA transition and accountability "issues must be addressed before any transition takes place."  Not only is this not news to the CWG  or the community, it is in our proposal.  So, I think the direct answer to your question is "No," and wishing won't make it so.
The remarks also clearly recognize that there are two work streams -- IANA transition and enhanced ICANN accountability. Not to belabor the obvious but we are the "IANA transition" work stream.  Of course, there are elements of accountability in our scope as well -- as Strickling refers to it, a process that will "result in ICANN’s becoming even more directly accountable to the customers of the IANA functions."  It is that type of accountability that we have to worry about, and which I believe our proposal (while still a work in progress) addresses.  I don't believe that there is anything in our proposal that can be categorized as "overreaching."  Indeed, I think we have been quite mindful of staying within our scope.
I'm not sure what you are driving at -- do you want us to take on the task of enhancing ICANN's accountability beyond the IANA function?  This would be massively "overreaching." Or do you want us not to deal with accountability at all, leaving it to the CCWG-Accountability to handle all elements of accountability, with the result that ICANN would then somehow be "safe" for an "internal to ICANN" IANA transition?  I think this would be "underreaching." It also assumes that the only thing standing between us and an "internal to ICANN" IANA transition is enhanced ICANN accountability; I do not think this is the case.  I think there is a need for IANA-specific accountability regardless of the overall state of ICANN accountability, and I think our proposal meets that need.

In any event, we can neither grab the entire accountability mandate or leave it all to the CCWG-Accountability.  Rather, we need to deal with the elements of accountability that fall within our bailiwick -- as we have done all along -- and which are an integral part of satisfying the requirement for transition, as it has been all along.
Greg

Gregory S. Shatan • Abelman Frayne & Schwab

666 Third Avenue • New York, NY 10017-5621

Direct  212-885-9253<tel:212-885-9253> | Main 212-949-9022<tel:212-949-9022>

Fax  212-949-9190<tel:212-949-9190> | Cell 917-816-6428<tel:917-816-6428>

gsshatan at lawabel.com<mailto:gsshatan at lawabel.com>

ICANN-related: gregshatanipc at gmail.com<mailto:gregshatanipc at gmail.com>

www.lawabel.com<http://www.lawabel.com/>

On Sat, Dec 6, 2014 at 1:31 AM, Seun Ojedeji <seun.ojedeji at gmail.com<mailto:seun.ojedeji at gmail.com>> wrote:

Thanks for the share Greg, wouldn't this then give us the opportunity to rethink the accountability measures we propose to put in place in lieu of ICANN's accountability; Since ICANN accountability is a requirement for transition then there may be no need for the current overreaching transition structure we are proposing.

Cheers!

sent from Google nexus 4
kindly excuse brevity and typos.
On 6 Dec 2014 00:43, "Greg Shatan" <gregshatanipc at gmail.com<mailto:gregshatanipc at gmail.com>> wrote:
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-strickling-plifcba-telecommunications-policy-regula

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_accountability_no_iana/<http://www.theregister.co.uk/2014/12/05/us_government_tells_icann_no_accountability_no_iana/>

Greg

Gregory S. Shatan • Abelman Frayne & Schwab

666 Third Avenue • New York, NY 10017-5621

Direct  212-885-9253<tel:212-885-9253> | Main 212-949-9022<tel:212-949-9022>

Fax  212-949-9190<tel:212-949-9190> | Cell 917-816-6428<tel:917-816-6428>

gsshatan at lawabel.com<mailto:gsshatan at lawabel.com>

ICANN-related: gregshatanipc at gmail.com<mailto:gregshatanipc at gmail.com>

www.lawabel.com<http://www.lawabel.com/>

_______________________________________________
CWG-Stewardship mailing list
CWG-Stewardship at icann.org<mailto:CWG-Stewardship at icann.org>
https://mm.icann.org/mailman/listinfo/cwg-stewardship

--
------------------------------------------------------------------------
Seun Ojedeji,
Federal University Oye-Ekiti
web:      http://www.fuoye.edu.ng
Mobile: +2348035233535<tel:%2B2348035233535>
alt email: <http://goog_1872880453> seun.ojedeji at fuoye.edu.ng<mailto:seun.ojedeji at fuoye.edu.ng>
The key to understanding is humility - my view !

--
------------------------------------------------------------------------
Seun Ojedeji,
Federal University Oye-Ekiti
web:      http://www.fuoye.edu.ng
Mobile: +2348035233535<tel:%2B2348035233535>
alt email: <http://goog_1872880453> seun.ojedeji at fuoye.edu.ng<mailto:seun.ojedeji at fuoye.edu.ng>
The key to understanding is humility - my view !

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20141210/6cb9c592/attachment-0001.html>