[CWG-Stewardship] My concerns with the draft proposal and an alternative option

[Greg Shatan]

Alan,

My further replies are below.

Greg

*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

*gsshatan at lawabel.com <gsshatan at lawabel.com>*

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

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

On Thu, Dec 4, 2014 at 12:24 AM, Alan Greenberg <alan.greenberg at mcgill.ca>
wrote:

>  Greg, My comments/replies.
>
> At 01/12/2014 01:22 PM, Greg Shatan wrote:
>
> Alan:
>
> Thank you for your email.  My specific thoughts are inline below. I
> apologize for the length, but I have tried to be as comprehensive as
> possible within a reasonable timeframe.
>
>
> On Sat, Nov 29, 2014 at 12:23 AM, Alan Greenberg <alan.greenberg at mcgill.ca
> > wrote: As I have mentioned during the F2F meeting in Frankfurt and on
> the most recent teleconference, I have significant problems with the
> proposal currently on the table. I am taking this opportunity to present my
> concerns in somewhat more detail, and I will also present what I believe to
> be a viable alternative. The ideas presented are my own, but I do know that
> they are largely shared by my At-Large colleagues and by some others in the
> community. I am also quite aware that my alternative options are likely
> to be vehemently opposed by some. I should also add that there are
> aspects of the current draft CWG proposal that I strongly support. The
> Independent Appeals Panel is perhaps the most important one.
>
> Overview
>
>  Many of my concerns are due to the large number of "details" that are,
> as yet, unspecified. Perhaps some of my concerns will be negated once there
> are sufficient answers, but I have the nagging feeling that for many, there
> will be no viable answer.
>
>
> GS: I do not share your pessimism.  Indeed, I think that I have offered
> viable and sufficient answers in this email, and others have done so in
> their responses as well.
>   This message will necessarily be long - my apologies for that.
>
> Contract Co.
>
>  Many of the issues surround the "entity" (as it was referred to in
> Frankfurt). The draft somewhat glibly says that it will only sign the
> contract. But it seems to be outsourcing much of its responsibility to the
> Multistakeholder Periodic Review Team (PRT), and that seems problematic.
>
>
> GS: I think this is more accurately characterized as delegating.
>   Perhaps the intent is not that all of these things go to the PRT, but
> there does not seem to be anywhere else for the functions to go. Among the
> tasks that it has outsourced are consultation regarding the contents of
> future RFPs, RFP issuance, RFP evaluation, contract negotiation and
> contract enforcement. What it cannot outsource is addressing legal issues
> such as being sued by a bidder who failed for win the contract and other
> such possibilities.
>
>
> GS:  This is fairly simple to resolve. The winning bidder must be required
> to indemnify, defend and hold harmless the PRT.
>   Whether it is possible to have such an empty company do all this
> remains to be demonstrated.
>
>
> GS:  Contract Co. will need to have just enough substance to accomplish
> these acts, all of which are well within the bounds of corporate
> authority.  I see no reason why Contract Co. could not do all these things,
> while remaining a lightweight, constrained entity.
>   I will deal with problems with this outsourcing under the PRT. The
> jurisdiction under which the company is registered has been the subject of
> some discussion. Clearly there are those who feel that under no conditions
> can it be the US. At the same time, there are some indications (such as
> terms in the Kelly bill) that imply that the US Government may not be
> willing to accept anything other than the US. Note that I understand that
> the Kelly bill itself may wither and die, but to quote Milton Meuller, "We
> should also pay attention to it because the bill provides a very good
> benchmark for preparing for the kind of questions that the NTIA is likely
> to be asked after they get a complete proposal from the ICG and begin to
> implement it. The Kelly bill can be considered a list of the concerns that
> US-based interests are going to be using to assess the final proposal. The
> GAO Report is equally important in this regard. Ignore them at your peril."
> (E-mail to the CWG-Stewardship list on 23 Nov 2014)
>
>
> GS: There's no getting around the fact that jurisdiction will be perceived
> as an issue, and that it will need to be resolved.  But that is true of any
> solution other than an "internal-to-ICANN" solution, which would keep
> everything in the US (unless, of course, you propose to move ICANN, which I
> am confident is out of our scope.  In any event, I don't think that
> jurisdiction is as big an issue as some would like to think it is.  But
> that's just me.  Regardless, I don't think that jurisdiction can be raised
> in the abstract.  The specific concerns raised by specific jurisdictions
> need to be explicitly stated.
>
>
> AG: I also do not believe that it is a "big" issue. But as long as it is
> not being dealt with explicitly, different people will make different
> assumptions and that can lead to problems later.
>

GS:  I don't disagree.  I think this is one of the key open issues we need
to deal with very soon.  One of the reasons we didn't get to it earlier is
a concern that once we got onto jurisdiction, we might never get off of
it.  There seems to be an almost endless fascination with "jurisdiction,"
and all the things that people think it implies (some correctly, some I
think rather far-fetched).

>
>  Without details of exactly how this corporation will exist, it is
> impossible to assure oneself that it cannot be captured or controlled by
> some entity or government(s).
>
>
> GS: Obviously, we all need to work on "connecting the dots" (i.e., filling
> in details).  As I've mentioned before, the articles of incorporation and
> bylaws can be set up so that Contract Co. is essentially compelled to
> accept the decisions of the PRT with virtually no discretion.  The
> particular actions that can and can't be taken by the directors can be
> carefully limited and circumscribed.  This is quite commonly done when
> setting up corporations for specific purposes.  In some cases, it is
> necessary that a company be "bankruptcy remote" (also sometimes referred to
> as "bankruptcy proof").  If so, there are a series of prohibitions,
> covenants and approvals baked into the bylaws that prevent the company from
> putting itself in the position to be declared bankrupt.  There is also a
> prohibition against the directors changing the bylaws to try to defeat
> these prohibitions, covenants and approvals.  Similarly, corporations are
> set up for specific purposes within the structure of a private equity fund
> or hedge fund; these corporations are also highly constrained in their
> actions.  This is all well trod ground.  I don't see how such a corporation
> could be "captured" or controlled by another entity or a government.
> However, without details of exactly how you expect this corporation to be
> captured, it is impossible to see whether this is a credible threat at all,
> even before putting in constraining and limiting controls.  Without
> details, "capture" -- like "jurisdiction" -- is just a word being used as a
> bogeyman or a rallying cry, stirring emotion but conveying no useful
> information.
>
>
> AG: You have demonstrated part of what I was saying. You have 20 years of
> experience in this areas and I have little. I started off the sentence with
> "Without details". My point was that the proposal must have far more detail
> in it to allow those of us who do not have vast corporate experience to
> have any faith in it.
>

GS:  I agree, up to a point.  I think any planning process is by necessity
iterative, and with each iteration problems are solved and details are
added. I expect that we will be adding a great deal more detail in coming
days.  In the meantime, while I expect some skepticism, I think that having
"no faith" is a little harsh.

>
>   Running IANA will be a treasured target by some countries and we do not
> know what lengths they would go to capture the contract. NTIA had the
> strength of the US (and its battleships and such) behind it.
>
>
> GS:  Until this point, I had thought you were using the term "capture"
> metaphorically.  Now I fear that you are using it literally.  I do not
> think that Contract Co. needs to raise a standing army or build a fleet of
> battleships.  Indeed, I can't think of an instance where a corporation has
> resorted to physical force to avoid "capture."  I do recognize that there
> are certain countries in the world where companies have been
> "de-privatized."  We should avoid those.  More practically, it should be
> set forth as a requirement that any respondent to an RFP must not be a
> government or intergovernmental body, just as NTIA required, and have
> protections in place to assure Contract Co./PRT that it cannot later be
> captured.
>
>
> AG: In my mind, "capture" of PRT is far more likely.
>

GS:  Why do you think that is? The PRT (now MRT) will be a broadly
multistakeholder body, and one that will be set up as representative.  Do
you have examples of a multistakeholder body being "captured"?  I think a
lot of this goes back to how you define "capture." In another email, you
indicated that a multistakeholder body that left anyone out could be deemed
to be "captured" by the remainder.  I think that expands the definition of
capture beyond any reasonable bounds.  Is a multistakeholder WG that
arrives at (ICANN-style rough) consensus "captured" by those that support
consensus?  If we follow this to its logical conclusion, capture of every
organization is inevitable.  Thankfully, I don't think this is a valid
definition of "capture."  In any event, I would think the MRT is highly
unlikely to be prone to "capture" (in any reasonable sense) as it will be a
broadly multistakeholder body in which no one stakeholder group should
predominate, and in which the representatives are each accountable to their
stakeholder group.  If a representative is not acting in accordance with
the instructions of the stakeholder group, they should be able to yank
him/her.  Clearly, composition of the MRT is not without its complexities,
and the balancing of seats and interests needs to be though as part of our
process..

>
>   Contract Co. will not.
>
>
> GS:  It will not need to (especially the battleships part).  It will be
> set up to eliminate opportunities for capture, and it will have the
> protection of the rule of law.  There has been no discussion about how
> this entity, or any part of the overall proposal, is funded. More on this
> later.
>
> Multistakeholder Periodic Review Team (PRT)
>
>  The PRT is effectively the operational arm of Contract Co. It is the
> entity that makes decision for Contract Co., presumably including those
> related to the RFP, contract negotiations, contract enforcement and much
> more. But by its very name, it is Periodic. It does not exist at all times
> and there are some in the community that have said it should be
> re-constituted afresh every time it is needed (perhaps like the Phoenix
> born from the ashes of its predecessor). I fail to understand to how it can
> take action on problems if it is not an ongoing entity.
>
>
> GS:  I think that it is fairly clear that the PRT has to be in a state of
> readiness in order to deal with "non-periodic" events. On the other hand,
> we don't want the PRT to feel the need to justify its existence or fill
> monthly meeting agendas or expand its scope.  These can be controlled by
> the PRT's organizing documents (perhaps a charter).
>
>
> AG: Clear to you and me, but less so to people who preached that it MUST
> not be standing and ready. That seems to have dissipated somewhat since I
> wrote this.
>
>  The description says that it is a "body" with representatives selected
> by the relevant bodies. Accepting that "relevant" is to be decided later,
> it is unclear under whose auspices this body is convened, and how we can
> ensure that it remains free from capture or malformation. It was suggested
> in Frankfurt that this body could be akin to (or even identical to) the
> IANA-CWG, but given that the entire concept of this elaborate
> infrastructure is to allow ICANN to be completely excluded from the IANA
> management process, presumably because it has ceased to carry out this
> function as well as all parties claim it is now doing, what makes us think
> that ICANN would take responsibility for this, or more to the point, could
> be trusted to do it properly?
>
>
> GS: In terms of capture or malformation, I think the answer lies first in
> the basic precepts of "multistakeholderism," which I am a strong believer
> in, even when I disagree with a particular result.  Broadly speaking, by
> constituting the team from a diverse set of stakeholder groups and
> organizations, which formally select the members, you have de facto checks
> and balances, as the members and their organizations have different
> interests and are keeping a wary eye on the organization to see if is going
> adrift or being pulled out of alignment.  The composition of the group must
> also be calibrated to avoid giving too much power to anyone stakeholder
> group or set of naturally aligned stakeholder groups.  Finally, you have to
> give the organizations the ability to pull their representative if he/she
> goes "rogue" (to borrow one of your suggestions for the ICANN Board).  In
> order to capture such a group, you would need to capture enough members to
> achieve consensus (i.e., a significant majority, to say the least), which
> in turn would mean capturing a series of diverse, disparate and sometimes
> opposed groups and organizations.  I think this might have happened in Star
> Wars -- but even in fiction, it took three movies for Senator Palpatine to
> become Emperor Palpatine, as well as acts of war to suspend the
> multistakeholder model of the Galactic Senate.  I don't see this happening
> in reality, unless the Dark Lords of the Sith are among us.  Seriously,
> though, I think we have to have some faith in the multistakeholder model,
> not just for the PRT, but for the future of Internet Governance generally.
>
> As for whether the PRT could be akin to the CWG -- that does not imply
> that the PRT would be under the ICANN umbrella.  I think the point was more
> one of composition.  However, now that you raise the point, this might be a
> valid alternative.  I think it is important to distinguish between "ICANN
> the corporation" and "ICANN the community".  An ICANN multistakeholder
> group is not the same as ICANN the corporation, which what I think you
> refer to when you say ICANN above. So, while ICANN the corporation may not
> be "trusted to do it properly," I have a much higher degree of confidence
> that a multistakeholder group will, whether or not it takes some shelter
> under the ICANN umbrella.  That does not mean these are the only
> alternatives.  The PRT could exist without being aligned with any other
> organization, it could be a committee under the auspices of Contract Co.,
> or it could even become aligned with another existing organization (e.g.,
> ISOC). So how this body, which is the critical keystone [
> http://en.wikipedia.org/wiki/Keystone_(architecture)] on which this
> entire superstructure depends, constituted, and funded. And how does one
> ensure that it is not corrupted, or captured?
>
>
> GS: I believe I've answered this above.  Any further details on corruption
> or capture scenarios would be appreciated (but leave out the battleships,
> please).
>
>
> AG: I am afraid that until we understand what entity it is that sets the
> rules for who may join the PRT (or whatever its current name is), and
> exactly what those rules are, we cannot be assured that it is a good
> flavour of multistakeholderism. We have seen examples where SOME people
> believe that the a group has a good multistakeholder balance, and others
> believe that they are either excluded, or other groups are
> disproportionately represented. It has happened in ICANN many times and
> continues to this day. It looks like MS, but on closer inspection, it may
> be extremely biased.
>
> The rules under which the PRT operates can also inappropriately favour one
> group's opinions over another, with little recourse.
>

GS: In the first instance, it is this CWG that will be setting the rules
for who may join the MRT.  I would greatly appreciate your suggestions on
what should be in these rules, and what the composition of the group should
be so that it has a a good multistakeholder balance.  Prior examples of
bias that you mention would be quite helpful (I'm not saying they don't or
didn't exist, just that we need to be concrete about what the prior issues
were.  If we were building a boat, it wouldn't be particularly helpful to
say "I've seen boats made of that stuff sink," without offering some
concrete advice.  Now, if you said, "Every boat made of that stuff sinks,"
that might be a different story.  But, if there is no good way to put
together a multistakeholder group, we have bigger problems.

>
>   Or sued. A body as large as it will have to be will require
> infrastructure such as a secretariat - how do we ensure that IT is not
> subverted (just look at all the effort that has gone into ensuring an
> independent ICG secretariat)?
>
>
> GS: I have my own opinions about the necessity of the effort that the ICG
> took to ensure an independent secretariat (but maybe they had the time to
> turn to such efforts).  Nonetheless, it may provide some useful lessons on
> doing so, and such things are always much easier the second time around.
>
>
> AG: I probably agree with you on the ICG. But for the PRT, it may, in my
> opinion, be FAR more important. I have personal experience (in ICANN) where
> the secretariat was not sufficiently independent and it had marked impact
> on the outcomes.
>

GS:  Again, it would help to be more concrete about the issues you've seen
in the past.  We need to be able to learn some lessons from these past
problems.  We may also be able to learn something from the ICG's efforts as
well.   Of course, this assumes that the MRT needs a secretariat (but it's
probably a fairly safe assumption that ti will need some support.)

>
>   And without a corporate backing of the PRT, its members would be
> personally liable in the case of a lawsuit. Who would want to serve on such
> a group? Moreover, in an environment where the PRT is taking very
> significant decisions, both financial offers and personal threats would be
> an effective method of capture (and presumably this is all volunteer work,
> or at most a modest stipend).
>
> GS: Assuming arguendo that PRT is not aligned with any other body,
> Contract Co. could purchase insurance to cover the PRT members, naming them
> as additional insureds.  By the way, has anyone checked how we are
> protected from personal liability and the possibility of being sued?  Does
> ICANN carry "multistakeholder insurance?"  I would also be curious to know
> whether anyone in this group has been subject to financial offers or
> personal threats in order to capture them. I, for one, have not.  A funny
> thing, too -- in those instances where capture occurs (say, soccer referees
> or baseball teams) its usually pretty obvious when they go from free will
> to puppetry.  Now, when you get to spycraft and other dark arts, it may be
> more difficult, but I still think we are straying into the realm of fiction
> here.
>
>
> AG: Regarding insurance, in most cases within ICANN, internal bodies only
> make recommendations and it is the Board that takes action. So the
> potential for being sued as a participant is far less. I tend to agree that
> to the outsider, it may be obvious that capture has taken place. That does
> NOT mean that they may have the wherewithal to do anything about it. ANd
> regardless, by that time it may be too late. We have already said that thr
> PRTs instructions to Company Co. are sacrosanct.
>

GS: The "key contract provisions" in Section 3 of the proposal contemplate
that ICANN will indemnify, defend and hold harmless Contract Co., the MRT
and the CSC.  In a typical indem, this extends to individuals affiliated
with the indemnified organization, such as the members of the PRT and CSC.

>
>  Surely, the PRT, which is implicitly all powerful, would need a new
> oversight mechanism over it! And who oversees THAT oversight body?
>
>
> GS:  Surely not. First, the PRT is not all powerful, implicitly or
> otherwise.  Its members must answer to their constituents.  Similarly, the
> oversight mechanism over the PRT is the diverse collection of stakeholder
> groups and communities, not a body.  And no further body is needed after
> that.  The threat of "infinite oversight" is a myth.
>
>
> AG: The recursive oversight was not meant to be taken seriously. But the
> fairness of PRT decisions will depend on all of the questions regarding who
> oversees its creation, composition and how it operates, and how those may
> change over time. If Company Co. has no choice but to follow its
> instructions (which was a critical part of Company Co. not being
> capturable), this it IS all-powerful in this respect.
>

GS: I've responded above to your questions regarding the MRT's creation and
composition.  There's no denying that it will take some work to fill in the
blanks. I expect that we will be doing this work very shortly.

>
>  Customer Standing Panel (CSC)
>
>  It is unclear exactly what this body monitors. If it is JUST service
> levels committed to by IANA, the composition may be ok. But if it is also
> responsible for ensuring that IANA is following policy, then the
> composition MUST reflect the multi-stakeholder body or bodies that created
> such policy.
>
>
> GS:  I personally agree that there should be multistakeholder
> representation of some sort on the CSC.  But this is still an open issue.
>
>
> AG: And as long as it is open, with some people being adamant that it is
> just the registries, I worry.
>
>    You cannot presume that the customers, who may have been vehemently
> opposed to any specific policy, will report that such a policy is not being
> policy. If the CSC is NOT monitoring adherence to policy, then who is? It
> does not seem to be covered in the proposal.
>
>
> GS: The NTIA currently monitors policy adherence to an extent, at least
> with regard to delegations and redelelegations.  The Del/Redel report must
> describe how the del/redel follows existing policy.  While we haven't
> nailed this down yet, I believe that receiving and reviewing Del/Redel
> reports goes to the CSC in the first instance, and can be escalated to the
> PRT if need be.  As to whether the CSC will report that policy is not being
> followed -- if it doesn't, it risks destroying its own legitimacy.  That's
> a pretty big risk to take.
>
>
> AG: It is hard to prove that someone didn't notice a problem. It all
> depends on how much they benefit. But what if the legitimacy IS questioned.
> As I see it, we are setting up this entire infrastructure with rules that
> it cannot be changed. How do we then "fix" any of it when it becomes
> obvious it is broken? The rigidity which makes us feel safe when we believe
> it is working properly becomes a liability when we desire change.
>

GS:  I don't think we've ever said that the rules of this entire
infrastructure cannot be changed -- that it will be cast in stone.  That
would be bizarre.  First, the ICG may well make some changes.  Then, as
details are filled in after we do our work (e.g., the detailed drafting of
the definitive IANA contract, for example), tweaks may need to be made.
There needs to be some ability to refine the model after it is put in
place.  I think this is a "policy and implementation" issue -- it is the
principles and policy that need to be constant, and to guide future
implementation. If a particular implementation is broken, there should be a
way to fix it.  Let's put that down on the checklist as well....

>
>   During e-mail discussions, someone said it was the job of the (for the
> gTLD space) GNSO. But it does not have the staff or Bylaw mandate to do so,
> nor would it have any standing to complain to whoever it is that would
> attempt enforcement (the PRT??).
>
> GS:  The GNSO Council has in fact raised policy concerns regarding various
> gTLD implementations and proposals.  I believe this is well within its
> mandate, and it is worth considering whether the GNSO Council should have
> standing to raise these concerns to the PRT and/or the IAP.
>
>
> AG: It would need standing AND staffing.
>

GS: The question of GNSO staffing is interesting, and we could make some
recommendations in that regard, but I think that is a much bigger issue and
one that is not really in our remit.  Something to feed into the GNSO
Review, perhaps?

>
>  There is reference to Liaison from ACs and SOs on the CSC. In the ICANN
> context, a Liaison has no power other than that of persuasion. They have no
> power to act if they are in disagreement with the majority of the full
> members.
>
>
> GS:  In that case, it may be more appropriate for these to be members of,
> rather than liaisons to, the CSC.  However, I would note that liaisons do
> have the power of persuasion, which you used quite effectively on the GNSO
> Council.  Finally, I would doubt that the CSC would be able to act by
> simple majority,
>
>
> AG: I have no doubt that on occasion my powers of persuassion on the GNSO
> Council may have changed outcomes. I can give you instances where the lack
> of formal standing on the Council resulted in significant problems (from
> an At-Large perspective).
>
> GS:  That would be helpful, and I think the question of liaisons vs.
representatives is very much on the table.

>  Cost
>
>  Cost has been mentioned briefly above, but it is a significant issue.
> Aside from the costs of the infrastructure we are discussing here, there is
> the cost of IANA. Currently this is funded by ICANN. If ICANN were to be
> taken out of the picture (and the possibility of doing that is the ONLY
> reason for building all of this), where does the funding come from? From
> ICANN, out of the goodness of its heart, despite no longer having ANY
> control over how much money is demanded or how it is spent? By the gTLD
> registries, who have said they would likely fund THEIR part of the costs,
> but not the entire thing. By the ccTLDs who have clearly said we should not
> depend on them (with a few exceptions)?
>
>
> GS: I agree that funding is an aspect that needs more attention.  But the
> fact that we haven't yet turned to this in detail does not disqualify the
> proposal in any way.  Contract Co. is granting ICANN a valuable right --
> the right to perform a valuable service.  If ICANN paid a fee for that
> right, it would not be out of the goodness of its heart.  There's no such
> thing as a free lunch.  I'm confident that we will find a way to deal with
> this, given the value that is inherent in the IANA Functions.
>
>
> AG: Again, I need to see a proposal that is not shot down by one player or
> another. It doesn't have to be the final answer, but we do need a proof of
> concept.
>

GS: This is another issue I expect we will reach in very short order.  And
the fact that one player or another takes a shot at a particular proposal
does not necessarily mean that it is "shot down."  Compromises will need to
be made.

>
>  Acceptability
>
>  The last time I heard Larry Strickling talk about the stewardship
> transition, he said it would only take place if sufficient controls were
> put in place to address ICANN messing up (i.e., in the extreme, a rogue
> Board). That PRESUMES that it is ICANN at the centre of the IANA
> stewardship - why else would we care about ICANN accountability if ICANN
> were not involved. From that, my take is they envision the IANA
> responsibility being transferred to ICANN. The Kelly bill clearly presumes
> this as well - why else would it be attempting to put so many constraints
> on ICANN?
>
>
> GS:  I disagree with this assumption entirely as I said to Holly earlier.
> The NTIA is looking to transition stewardship of the IANA Function to the
> global multistakeholder community, not to ICANN.
>
>
> AG: No point in arguing this since we are not privy to the internal
> discussions. The NTIA focus on "ICANN accountability" sends a pretty strong
> message to me.
>

GS: Are their particular remarks that lead you to believe that an "internal
to ICANN approach" would be favored?  I recognize and share the concern
about ICANN accountability, but I don't this presumes that ICANN is
engaging solely in "self-accountability."  I think the presumptions are (a)
that ICANN will be at the center of performing the IANA functions, not the
stewardship, and (b) that ICANN need general accountability improvements to
replace the NTIA's power to use the IANA contract to pull ICANN's leash
(even on matters wholly unrelated to IANA performance).

>
>
>  It is not at all clear that a proposal such as one that the CWG has put
> in this draft would be acceptable to the US government.
>
>
> GS:  My crystal ball is at least as cloudy as yours, but I predict that a
> proposal that failed to transition NTIA's role to the global
> multistakeholder community, and instead transferred it directly into the
> hands of ICANN, would be far more likely to be unacceptable to the US
> government.  This could be the "internal to ICANN" concept's fatal flaw.
>
>
> AG: Or its strength!  ;-)
>


>
>
>  It will certainly not be a favoured proposal from the point of view of
> the ICANN Board (who may not have a direct say in this but cannot be
> totally ignored either).
>
>
> GS:  This may be true, but we would be betraying our mandate and our
> constituents if we decided that our aim was to please the Board.  In any
> event, I have faith (perhaps more than you) that the Board isn't going to
> try to stop a disfavored proposal. That would raise quite a ruckus, if
> ICANN the corporation were to turn on ICANN the community.  Remember, this
> is not just one SO or AC, which the Board may choose to ignore at some
> peril.  We are the massed army of stakeholders (unless, of course, we are
> riven by division, which would be far more than unfortunate -- as Milton
> notes elsewhere, the vultures are circling, and if the Board has
> indigestion, that is the least of our worries. Integratability
>
>  The ICG will be tasked with integrating the CWG proposal with that of
> the RIRs and the IETF. Although this is clearly their job and not ours, I
> have always believed that one needs to look ahead to ensure that there are
> no impassable roadblocks ahead. We do not definitively know what those
> proposals will be, but indications are emerging. Both bodies seem to be
> happy with how ICANN is managing IANA, but both feel that in the event of
> any untoward action, they could move the responsibility associated with
> their areas somewhere else. Since in both cases, it is the same body that
> sets the policy that would judge it, no great complexity is involved. In
> ICANN's case, since the bodies that set policy in the names space are (to a
> large extent) an integral part of ICANN, they cannot take action against
> their "parent" (so to speak). Thus this cumbersome alternative. Integrating
> these two approaches may be difficult.
> GS:  It might be difficult; it might not. As you note, names is
> differently situated than the other two areas.  Therefore, a one size fits
> all approach was always unlikely.  By creating Contract Co. and the PRT, we
> are actually closer to the model of the other two areas, which should make
> integration easier, not harder. Lost Opportunity
>
>  Part of the IANA Stewardship Transition is to put in place suitable
> ICANN accountability and governance changes so as to ensure the continuity
> of the IANA function. If all of the questions posed here, and the ones
> raised by others are addressed, we would end up moving from a situation
> where an entity (the NTIA of the US government) awards the IANA contract.
> The contract is currently held by ICANN but in theory at some future date,
> it could be awarded to some other organization, removing ICANN from any
> operational connection to ICANN. The new situation would be where
> Contract Co. awards the IANA contract. The contract will initially be held
> by ICANN but in theory at some future date, it could be awarded to some
> other organization, removing ICANN from any operational connection to
> ICANN. Notice the parallel wording. ICANN really has no motivation to
> change to effect this change. And in all likelihood any change associated
> with this transition will be minimal.
>
>
> GS: I think you probably meant to say IANA at the end of each of those
> paragraphs, rather than ICANN.
>
>
> AG: Yes, correct. Sorry.
>
>    In any event, I understand the concept of leverage here.  I think we
> exercise that leverage along the lines that the two CWG's work is
> "interrelated and interdependent" and that Stream 1 accountability has to
> be resolved before there is a transition.  We can't try to reform all of
> ICANN ourselves from the platforrm and mandate of transitioning NTIA
> stewardship. That would be massive mission creep.  There is a careful
> balance here in using the IANA Transition to ensure that Enhanced ICANN
> Accountability is not just an empty phrase, but that balance is lost if we
> put forth a plan that does not really transition NTIA's roles and that
> reaches far beyond our mandate in order to enact major reforms.  We cannot
> do the job of the ICG or the Accountability CWG, but we do depend on them
> both to do their jobs right.
>
> Furthermore, I don't think Contract Co. is the status quo.  The NTIA is
> controlled by the US Government.  Contract Co. is controlled by the
> multistakeholder community.  What makes you think we will sit on our
> collective hands? Also, I anticipate that the contract will have more
> "teeth" in it to enforce accountability (including termination for breach,
> which is absent from the current NTIA agreement except in extremely narrow
> circumstances).
>
>
> AG: I would not advocate the internal-to-ICANN route to effect ICANN
> accountability. That WOULD be extreme mission creep (mission-lope?). But if
> it were to occur as a side benefit, I think that everyone would benefit.
>
> I guess I don't see much difference between termination for breech and
> termination at end-of-term (except the former is likely to be more likely
> disputed in court that the latter, and thus less likely to occur.
>

GS:  I may speak from some greater experience here.  I think that the
threat of termination for breach is very real and thus a very real
accountability mechanism.  Termination for breach rarely occurs
immediately; there is almost always an "opportunity to cure the breach," as
well as an escalation process.  In my experience, the majority of times a
"breach notice" goes out, it results in a cure rather than a termination.
The right to terminate for breach should be viewed in this light, not
merely with regard to the aftermath of an actual termination occurring.

>
>  If we go down the path of the current draft CWG proposal, I believe that
> a major opportunity will have been lost to reform ICANN.
>
>
> GS:  I disagree for the reasons stated above.  We in this CWG may have
> lost that major opportunity, but the ICANN community has not lost that
> opportunity.  It's right next door in the Accountability CWG.  What we have
> not lost is the ability to use our leverage judiciously to support the
> "interrelated and interdependent efforts" of the CWG Accountability.  And
> they way we can lose that is to be overtaken by internal divisions, failing
> to meet our timeline, and squandering our legitimacy.  Frankly, I don't
> think that is what's happening here -- there's a reason that ICANN
> consensus is "rough" -- some divergence is expected, but the show must go
> on.  Only where this true divergence (i.e., no view predominates) or strong
> opposition.does the show not go on.  While I agree with Chuck that a formal
> consensus call is premature, I think that in the fullness of time and
> through our continuing good faith efforts, we will get there in good shape.
> Alternative
>
>  Simply criticizing the current CWG draft proposal is not particularly
> useful without alternatives.
>
>
> GS:  Alternatives can be helpful.  So can suggestions for improvement.
> These can come from adapting certain aspects of alternatives, as has
> already happened.  It can also happen when people who look for problems
> also look for solutions.
>   My alternative is certain to not please some of the parties in this
> discussion, but I believe that it is both possible and viable. All of the
> complexity of the CWG draft proposal is there to cover the eventuality that
> ICANN suddenly or gracefully stops performing the IANA function to the
> satisfaction of the community.
>
>
> GS: I disagree, and I think this mischaracterizes both the proposal and
> the work that led to it. The framework of the CWG draft proposal is there
> first to replace the NTIA's roles.  As you will recall, we spent a couple
> of hours defining the various roles that NTIA currently performs in
> relation to IANA.  The CWG structure was then fit to those roles.  Dealing
> with non-performance is built into the framework as well, but it is hardly
> the sole reason for it.
>
>
> AG: I guess we will disagree here. I see the potential that ICANN will not
> be able or willing to do the job the ONLY reason for building this new
> beast. Why else if not for the ability to move the contract outside of
> ICANN?
>

GS:  This structure was built to assume all of the roles of the NTIA that
we identified in Frankfurt and through our other work.  A structure with
the sole purpose of one day being called upon to move the IANA contract out
of ICANN would not have satisfied the RFP or the NTIA.

>
>   That was indeed the situation a number of years ago, and ICANN took
> effective action to rectify the problems (that is, the NTI did not have to
> yank the contract to fix the problems). At the moment all parties seem to
> agree that there are no significant outstanding major problems, certainly
> none that could justify a change in the status quo. But there is a
> recurrent fear of "what if". What if ICANN had the IANA responsibility in
> perpetuity and stopped caring. Or had a Board that deliberately and without
> community support took action or inaction to harm how the IANA functions
> are carried out (the "rogue Board scenario). These worst case
> alternatives are indeed possible. And since under the current ICANN Bylaws,
> the Board is effectively sovereign, little could be done short of changing
> the Board over a period of 3+ years. I suggest that there are ways to
> alter ICANN's Bylaws to allow the effective control of an out-of-control
> Board. These mechanisms will not be particularly appreciated by the ICANN
> Board, but I believe that such measures (or something similar) would be
> adopted if that is what is required to be granted IANA. o
> GS:  I think that you have taken your boat of the CWG's waters with this
> statement.  Accountability is part of our responsibility, but it is
> accountability relating to the IANA Functions.  Using that responsibility
> to try to re-make ICANN from our group is a massive overreach.  We
> (individually) can be part of that grander effort by participating in the
> CWG on Accountability, and as a group, by maintaining that Stream 1 must be
> resolved before the transition takes place.
>
>
> AG: As I say in my next paragraph, these are not proposals for the IANA
> CWG to consider or recommend. That is indeed way out of our scope. But I
> have repeatedly heard that there is and will be NO way to control the ICANN
> Board (and that leads to the implicit lack of trust in ICANN). There is
> indeed no way to control the ICANN Board at the moment. A number of
> decisions related to New gTLDs demonstrate that in spades. The purpose of
> the preceding paragraphs and the ones that follow are simply to demonstrate
> that with just a modicum of imagination, there ARE ways that the Board
> could be reasonably controlled, and that given sufficient motivation the
> Board might agree to such changes.
>
>  There are a number of components that I will describe. They are not
> necessarily a complete or even the correct set. Putting in place a complete
> set of cohesive recommendations is what the Accountability CCWG is being
> convened for. But the existence of the following as a starting point, I
> believe, demonstrates that there IS a way to proceed forward. -       ACs
> and SOs must be given the ability to recall their sitting Board member.
> There will be no need to await the end of the current 3-year term. -
> Certain classes of decision regarding IANA can only be made with (for an
> example) a supermajority (2/3) of the Board's maximum Bylaw-mandated
> membership approving the decision. Without the bulk of the AC/SO Board
> members, there will not be a critical mass of Board members to take such a
> decision. -       Certain classes of decision regarding IANA may only be
> made after notification period and public comment. This would allow the ACs
> and SOs sufficient time to act to recall their Board members -       It
> is possible that the composition of the Board might need to be slightly
> altered to ensure that a recall of most but not all AC/SO Board members
> would be effective in halting action. Or a higher threshold than
> supermajority might be needed. -       Bylaws regarding GAC advice
> related to IANA might need to somewhat altered to compensate for the GAC
> not having sitting Board members. -       Similarly, non-affiliated
> ccTLDs would need to be worked into the equation. -       If allowed
> under California law, the Bylaws could be require that under certain
> circumstances, a Board decision could be appealed to an external body
> (similar to the proposal's Independent Appeal for IANA decisions) and that
> the decision would be binding and enforceable in courts.
>
>
> GS:  I think your second and third suggestions might have a place in the
> work of our group, and perhaps the one about GAC advice related to IANA
> (but the motivation for that suggestion is still fuzzy to me).  The rest of
> these fall outside our mandate.  If we were watching an ICANN Board
> Committee with our mandate use that mandate to remake broad swaths of ICANN
> governance with no direct relationship to IANA, the multistakeholder howls
> would be deafening.
>
> What I found most disappointing when I reached the end of this email for
> the first time, was that there is really no proposal here.
>
>
> AG: You are correct. I did neglect to explicitly put my proposal in here.
> BUt I have spoken of it a number of times and you yourself alluded to it
> earlier in your replies. To be explicit, it is the option of the NTIA
> tranfering responsibility to ICANN instead of to Contract Co. as in the CWG
> proposal.
>

GSS:  I understand the "high level concept."  But there's no meat on the
bones.  If this were the "elevator pitch" for your idea, you would need a
very short elevator, or there would be a very long silence.

>
>   As noted above, we noted several roles (we called them "functions" in
> Frankfurt, but I think that leads to confusion with the IANA Functions)
> that the NTIA plays and that need to be replaced in some form (not
> necessarily on an exact parallel basis, but they need to be dealt with and
> their raisons d'etre need to be considered and carried through to any
> proposal).  For convenience, I will repeat our list of NTIA roles below:
>
> #1 – APPROVAL FUUNCTION OF CHANGES TO THE ROOT ZONE
>
> #2 - PERFORMANCE REVIEW FUNCTION
>
> Periodic Review
>
> Transactional Performance review (SLAs)
>
> Perform (technical) audits and customer surveys
>
> #3 - CONTRACTING FUNCTION (ability to enter into a contract)
>
> Determining the substance of the contract
>
> Award / renewal of contract
>
> Understand what stakeholder concerns are
>
> Issuance of RFPs
>
> Contracting
>
> Ability to seek public comments
>
> #4 – ENFORCEMENT OF THE CONTRACT FUNCTION (incl. renewal/rebidding)
>
> Termination of contract;
>
> Ability to enforce
>
> Ability to seek public comments
>
> Ability to determine whether contract should be terminated, including
> hearing of complaints
>
> Listen to community and act on its behalf
>
> Regrettably, I think your Alternative skips over all of this, perhaps due
> to eagerness to fix ICANN (which many of us are eager to do in one way or
> another).  Unfortunately, joining this CWG meant that we must deal with
> "nuts and bolts" issues relating to the NTIA's transition of its role to
> the global multistakeholder community.  Your email is devoid of any
> resolution for replacing these functions currently carried out by NTIA.
> There are a variety of resolutions that can be imagined in an "internal to
> ICANN" proposal -- jobs to be taken over, processes to be built or adapted,
> documents to be written, working groups to be formed, dispute resolution
> procedures to be crafted,  These could be configured in a number of
> different ways.  Unfortunately, you have not provided us with a framework
> for any of this.  Certainly, an "internal to ICANN" proposal would match up
> to each of these points in ways that are not quite as obvious as the
> current CWG proposal.  For instance, in the absence of a contract,
> "determining the substance of the contract" is not directly applicable.
> However, the contract is the vehicle for setting forth ICANN's obligations
> regarding IANA.  Without a contract, these obligations need to go
> somewhere, as does the ability to enforce them.  So the "substance" still
> needs to be determined -- it just won't be in a contract (not likely
> anyway, but it's your proposal).  Who will make this determination? How
> will this be vetted through multistakeholder processes?  What document will
> contain this substance?  How will it be enforced?  I could go on, but I'm
> sure you get the point.
>
> So, I'm not sure what your Alternative is, but it is not an alternative to
> the CWG Proposal.  If this were a Venn diagram, the two circles would be
> barely overlapping.  As I stated in another thread "I don't think an "internal
> to ICANN" proposal was ever put on the table within the group prior to
> Frankfurt in any kind of tangible, concrete fashion."  I will add now
> that I think that an "internal to ICANN" proposal still has not been put on
> the table within the group in any kind of tangible, concrete fashion --
> which leaves us dancing with ghosts -- something out of which no progress
> can be derived, unfortunately.
>
>
> AG: You are correct, I did not address how each of the current NTIA roles
> (except for issuing the contract which would now be moot) would be carried
> out. The CWG proposal leaves out many details and I did not feel it was
> worth my time given that there was little likelihood of the CWG changing
> direction at this point.
>

GS: I think the CWG proposal is detailed enough at this stage to talk about
it on its merits, to level specific criticisms, and to provide specific
responses and recommendations in response to those criticisms.  I don't
think it "leaves out" details.  I think we are at the point in the process
where those details have not yet been added in, but that does not mean they
have been "left out."  Any planning process necessarily gets more detailed
as it goes along.  Our proposal could not have burst full-blown from the
forehead of Zeus.  Yes, there is a relative lack of detail, compared to a
final, all-identified-issues-resolved, fully implementable solution.  But I
don't think you (or anyone else) can use that as an excuse for not putting
forth at least a "strawman" proposal that shows how an "internal to ICANN"
approuch would work.  That can't possibly be helpful to the process, the
proposal or to those that agree with you.

>
> A large part of my problems with the CWG proposal is all of the complexity
> and various bodies that are required to be able to remove ICANN from the
> equation. That the internal ICANN model does not NEED these is part of its
> strength.
>

GS: It's a fair criticism, up to a point.  However, only one one body would
really be required to remove ICANN from the equation -- but amalgamating
Contract Co./MRT/CSC caused howls of concern for other reasons -- capture,
creating a shadow ICANN, etc.  Those are the reasons we broke up the power
centers -- really has nothing to do with the direct issue of pulling the
contract.

>
>
> I can comment on a few details just to demonstrate that I have thought
> this through. The critical part is how would ICANN be held to actually
> doing the details of the job.
>

GS:  Am I correct to assume that "the job" you refer to is performing the
IANA Functions?  If that is the case, I agree that is "a" critical part,
but not "the" critical part.  The contract defines what the details of the
job are and how performance is reported.  That would need to be replaced
somehow.  An external body (now NTIA) receives and reviews numerous
reports.  That would need to be replaced somehow.


> That would require Bylaw (or some document linked to the Bylaws, I am not
> a corporate attorney) changes to lock in the details of the commitment.
>

GS: Bylaws generally cover *how* an organization is governed.  The policy
and decisions are generally reflected in resolutions passed by the Board.
Be that as it may, the mechanics can come later (see how that happens?)
What's more important is to flesh out what the commitment is that you are
looking to lock in.


> They could not be changed without MS involvement and examples of such
> mechanisms were discussed above. If ICANN through its Board either
> consciously decides, or through inaction to not follow what is now in its
> Bylaws (ie the "contract"), the MS community could effectively replace a
> critical part of the Board (or whatever mechanisms the Accountability CCWG
> Stream 1 would recommend).
>

GS:  How would you feel if such a mechanism were in place solely for
failure to follow the details of the IANA Functions, but not for any other
action or inaction of the ICANN Board?  Would that be satisfactory to you?
I somehow feel it would not.  Yet, we cannot radically remake ICANN's
overall governance structure and procedures under the guise of making sure
that accountability for performance of the IANA functions needs to be
strengthened.


> If such a threat is not sufficient to making the Board comply, it can be
> carried out (EXACTLY as with Contract Co. threatening or actually pulling
> the contract).
>

GS:  This is probably where we cannot put the mechanics aside and just say
"this will happen."  It is one thing for ICANN (or any other corporation or
other legal entity) to be obligated to a third party by virtue of a
contract, and for that third party to have power to cause the corporation
to do things, or to take back a right that the third party granted to the
corporation -- that happens all the time.  It's another thing to put
together a process whereby a cross-community oversight committee within the
ICANN structure can essentially force a divestiture of a business unit for
failure of that business unit to meet performance criteria (or for any
other reason for that matter).  That is probably a big stumbling block for
an "internal to ICANN" approach.

>
> The CWG does not yet have closure on whether all of the NTIA backstop
> functions need to be done (my personal belief is that they do).
>

GS: This does need to be further discussed. The related question of whether
it is our CWG's work to replace that backstop function or the work of the
Accountability CWG also hangs in the air.


> In the ICANN model, the decision would also be required.
>

GS:  Really, a lot of the same decisions have to be faced whatever road one
goes down.  The solutions may differ quite a lot.  The principles
underlying the solutions probably would not vary much at all (that sounds
like "implementation vs. policy" to me...).



> Presuming the answer is that they are needed, we would need to decide
> which could be done internal to ICANN (but separate from the IANA group)
> and which would need to be outsourced/delegated to some external body.
>

GS:  Sounds like things are getting complicated now in the "internal to
ICANN" model, including the possibility that some of it may have to be
external.... But without a strawman of some sort, we'll never know.

>
> I could go on, but I honestly don't think that it is worth my time right
> now. If there is ANY interest expressed in this model, I would be happy to
> continue.
>

GS:  Actually, in my humble and slightly disruptive opinion, I don't think
there is anything that is more worthy your time right now than this.  If
"internal to ICANN" remains an idea or a rallying cry, rather than being
put forth in a concrete and tangible form, it can't really go anywhere.  It
can't even be "used for parts" as the strawmen were when the CWG proposal
was built.

Where does that leave those that believe that an "internal to ICANN"
approach is the better mousetrap?  Well, I guess that gives you "I told you
so" rights and "coulda, woulda, shoulda" rights and "who knows what coulda
happened" rights and "it wasn't MY idea" rights as this progresses.  But
those are not valuable rights, and they reflect a resignation that I
believe is premature and not constructive.

And where does that leave the CWG?  Without the benefit of thoughtful
consideration of an "internal to ICANN" proposal, and arguably open to some
criticism that such a proposal was not more fully reviewed.  I think such
criticism would be unfounded, at least of the group as a whole.  Each of
the original strawmen either came from ideas set forth by proponents of
that strawman or were written out by proponents of that strawman -- that's
how those got fleshed out and put into the conversation.  And the current
proposal was germinated in Frankfurt in a process in which we all
participated, which combined many aspects of the strawmen, along with
attention to the functions that we determined needed to be replaced.  If an
"internal to ICANN" proposal is going to be considered within this group,
the most likely reason for that is a proposal that comes from its
proponents, that tries to solve the criticisms that have been leveled at
this point, and that is detailed enough that specific criticism and
solutions can be discussed.  So, it leaves the group poorer for the lack of
such a proposal and may leave us with some lingering uncertainty about
whether such a proposal might have worked, but that's not particularly
useful.

On the other hand, if there's a decent strawman for such a proposal, it can
be poked and prodded and examined and tested (and maybe even improved).
And if we just can't get it to work in a way that gets broad traction,
well, at least we tried and the "internal to ICANN" issue is essentially
put to bed (and all of those "non-bragging rights" above never come into
play).  And what if we can get it to work in a way that gets broad
traction?  Well, wouldn't you like to find out?

Greg



>
>
> Alan
>
>
> Greg
>
>
>   _______________________________________________ CWG-Stewardship mailing
> list 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/20141205/55089f6a/attachment-0001.html>