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

[Alan Greenberg]

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 at 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 at mcgill.ca]
>Sent: Sunday, December 14, 2014 1:17 AM
>To: Guru Acharya
>Cc: Gomes, Chuck; cwg-stewardship at 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 at mcgill.ca<mailto: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: 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
>
>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, 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:
>cwg-stewardship-bounces at icann.org<mailto: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: 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
>
>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 at sidn.nl<mailto: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
>CWG-Stewardship at icann.org<mailto: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/5715d5ca/attachment-0001.html>