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