[CWG-Stewardship] My concerns with the draft proposal and an alternative option
Alan Greenberg
alan.greenberg at mcgill.ca
Mon Dec 1 22:00:54 UTC 2014
Greg,
Thank you for actually going through my message
and addressing the points I raised. It is
refreshing compared to the hand-waving that
others have done. You have indeed addressed some
of my concerns. Others I believe still need
further work and for others, I think there is
still a lack of understanding the point I was
making. I will respond to you in some detail, but
unfortunately I will not have the time to do that
today (or perhaps even tomorrow).
Alan
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
><<mailto:alan.greenberg at mcgill.ca>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.
>
>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.
>
>
>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.
>
>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).
>
>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).
>
>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.
>
>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.
>
>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.
>
>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.
>
>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.
>
>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.
>
>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,
>
>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.
>
>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 .
>
>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.
>
>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. 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).
>
>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.
>
>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.
>
>
>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.
>
>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. 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.
>
>Greg
>
>
>
>_______________________________________________
>CWG-Stewardship mailing list
><mailto:CWG-Stewardship at icann.org>CWG-Stewardship at icann.org
>https://mm.icann.org/mailman/listinfo/cwg-stewardship
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20141201/4a32cf4e/attachment-0001.html>
More information about the CWG-Stewardship
mailing list