[CWG-Stewardship] Strickling Remarks from 4 December re IANA Transition and Accountability
Alan Greenberg
alan.greenberg at mcgill.ca
Sun Dec 14 06:16:48 UTC 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 at mcgill.ca>alan.greenberg at 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 at mcgill.ca]
>>Sent: Thursday, December 11, 2014 4:22 PM
>>To: Gomes, Chuck; Greg Shatan; Maarten Simon
>>Cc: <mailto:cwg-stewardship at icann.org>cwg-stewardship at 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 at icann.org>cwg-stewardship-bounces at icann.org
>>[ mailto:cwg-stewardship-bounces at icann.org] On Behalf Of Alan Greenberg
>>Sent: Wednesday, December 10, 2014 9:32 PM
>>To: Greg Shatan; Maarten Simon
>>Cc: <mailto:cwg-stewardship at icann.org>cwg-stewardship at 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 at sidn.nl>maarten.simon at 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 at icann.org>CWG-Stewardship at icann.org
>https://mm.icann.org/mailman/listinfo/cwg-stewardship
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20141214/58a7670a/attachment-0001.html>
More information about the CWG-Stewardship
mailing list