<html>
<body>
At 11/12/2014 10:28 AM, Gomes, Chuck wrote:<br>
<blockquote type=cite class=cite cite="">Allan,<br>
<br>
I want to comment on a few of the points you make in the exchange
below.<br>
<br>
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?</blockquote><br>
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).<br><br>
<blockquote type=cite class=cite cite="">
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?</blockquote><br>
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. <br><br>
<blockquote type=cite class=cite cite="">
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.</blockquote><br>
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. <br><br>
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. <br><br>
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.<br><br>
Alan<br><br>
<blockquote type=cite class=cite cite=""> <br>
Chuck<br>
<br>
<br>
<br>
<b>From:</b> cwg-stewardship-bounces@icann.org
[<a href="mailto:cwg-stewardship-bounces@icann.org" eudora="autourl">
mailto:cwg-stewardship-bounces@icann.org</a>] <b>On Behalf Of </b>Alan
Greenberg<br>
<b>Sent:</b> Wednesday, December 10, 2014 9:32 PM<br>
<b>To:</b> Greg Shatan; Maarten Simon<br>
<b>Cc:</b> cwg-stewardship@icann.org<br>
<b>Subject:</b> Re: [CWG-Stewardship] Strickling Remarks from 4 December
re IANA Transition and Accountability<br>
<br>
At 10/12/2014 02:53 PM, Greg Shatan wrote:<br><br>
Maarten:<br><br>
My answers are inline below.<br><br>
Greg<br><br>
On Mon, Dec 8, 2014 at 5:46 PM, Maarten Simon
<<a href="mailto:maarten.simon@sidn.nl">maarten.simon@sidn.nl</a>>
wrote:<br>
Hi Greg,<br>
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):<br>
รขIf we could arrange via the bylaws that the ICANNNN board explicitly
has to follow orders from a MRT-like structure, <br><br>
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?<br><br>
AG:<br>
I will no doubt echo some of what Olivier has said, despite Milton having
explained that he is wrong.<br><br>
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.<br><br>
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. <br><br>
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. <br><br>
It is SO attractive to label ICANN as unchanging and inflexible, but
current evidence does not bear that out.<br><br>
<br><br>
we might not need a contract but have an (internal) MoU/SLA or whatever.
<br><br>
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"?<br><br>
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.<br><br>
AG:<br>
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.<br><br>
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.<br><br>
<br><br>
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. <br><br>
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. <br><br>
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).<br>
<br>
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.รข<br><br>
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." <br><br>
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?<br><br>
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.<br><br>
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.<br><br>
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.<br><br>
AG:<br>
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.<br><br>
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.<br><br>
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.<br><br>
<br><br>
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.<br><br>
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.<br><br>
AG: <br>
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. <br><br>
Alan<br><br>
<br><br>
Greg <br>
Appreciate your response.<br>
Best,<br>
Maarten </blockquote></body>
</html>