<html>
<body>
Greg, My comments/replies.<br><br>
At 01/12/2014 01:22 PM, Greg Shatan wrote:<br>
<blockquote type=cite class=cite cite="">Alan:<br><br>
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.<br><br>
<br>
On Sat, Nov 29, 2014 at 12:23 AM, Alan Greenberg
<<a href="mailto:alan.greenberg@mcgill.ca">alan.greenberg@mcgill.ca</a>
> wrote:
<dl>
<dd>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.
<dd>I am also quite aware that my alternative options are likely to be
vehemently opposed by some.
<dd>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.<br><br>
<dd><font size=5 color="#0000FF">Overview<br><br>
</font>
<dd>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.
<br><br>
</dl><br>
<font color="#0000FF">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.<br>
</font>
<dl>
<dd>This message will necessarily be long - my apologies for
that.<br><br>
<dd><font size=5 color="#0000FF">Contract Co.<br><br>
</font>
<dd>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. <br><br>
</dl><br>
<font color="#0000FF">GS: I think this is more accurately characterized
as delegating.<br>
</font>
<dl>
<dd>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. <br><br>
</dl><br>
<font color="#0000FF">GS: This is fairly simple to resolve. The
winning bidder must be required to indemnify, defend and hold harmless
the PRT. <br>
</font>
<dl>
<dd>Whether it is possible to have such an empty company do all this
remains to be demonstrated.<br><br>
</dl><br>
<font color="#0000FF">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.<br>
</font>
<dl>
<dd>I will deal with problems with this outsourcing under the PRT.
<dd>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)<br><br>
</dl><br>
<font color="#0000FF">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. </font></blockquote><br>
<font color="#008000">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.<br><br></font><blockquote type=cite class=cite cite="">
<dl>
<dd>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). <br><br>
</dl><br>
<font color="#0000FF">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.</font></blockquote><br>
<font color="#008000">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.<br><br>
<br>
</font><blockquote type=cite class=cite cite="">
<dl>
<dd>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. <br><br>
</dl><br>
<font color="#0000FF">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.</font></blockquote><br>
<font color="#008000">AG: In my mind, "capture" of PRT is far
more likely.<br><br>
</font><blockquote type=cite class=cite cite="">
<dl>
<dd>Contract Co. will not.<br><br>
</dl><br>
<font color="#0000FF">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. </font>
<dl>
<dd>There has been no discussion about how this entity, or any part of
the overall proposal, is funded. More on this later.<br><br>
<dd><font size=5 color="#0000FF">Multistakeholder Periodic Review Team
(PRT)<br><br>
</font>
<dd>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.<br><br>
</dl><br>
<font color="#0000FF">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).</font></blockquote><br>
<font color="#008000">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.<br><br></font><blockquote type=cite class=cite cite="">
<dl>
<dd>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?<br><br>
</dl><br>
<font color="#0000FF">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.<br><br>
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).</font>
<dl>
<dd>So how this body, which is the critical keystone [
<a href="http://en.wikipedia.org/wiki/Keystone_(architecture" eudora="autourl">
http://en.wikipedia.org/wiki/Keystone_(architecture</a>)] on which this
entire superstructure depends, constituted, and funded. And how does one
ensure that it is not corrupted, or captured? <br><br>
</dl><br>
<font color="#0000FF">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).</font></blockquote><br>
<font color="#008000">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. <br><br>
The rules under which the PRT operates can also inappropriately favour
one group's opinions over another, with little recourse.<br><br>
</font><blockquote type=cite class=cite cite="">
<dl>
<dd>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)? <br><br>
</dl><br>
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.</blockquote><br>
<font color="#008000">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.<br><br>
</font><blockquote type=cite class=cite cite="">
<dl>
<dd>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).<br><br>
</dl><font color="#0000FF">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. </font></blockquote><br>
<font color="#008000">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.<br><br></font><blockquote type=cite class=cite cite="">
<dl>
<dd>Surely, the PRT, which is implicitly all powerful, would need a new
oversight mechanism over it! And who oversees THAT oversight
body?<br><br>
</dl><br>
<font color="#0000FF">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.</font></blockquote><br>
<font color="#008000">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.<br><br></font><blockquote type=cite class=cite cite="">
<dl>
<dd><font size=5 color="#0000FF">Customer Standing Panel (CSC)<br><br>
</font>
<dd>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. <br><br>
</dl><br>
<font color="#0000FF">GS: I personally agree that there should be
multistakeholder representation of some sort on the CSC. But this
is still an open issue.</font></blockquote><br>
<font color="#008000">AG: And as long as it is open, with some people
being adamant that it is just the registries, I worry.<br><br>
</font><blockquote type=cite class=cite cite=""><font color="#0000FF">
</font>
<dl>
<dd>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. <br><br>
</dl><br>
<font color="#0000FF">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.</font></blockquote><br>
<font color="#008000">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.<br><br>
</font><blockquote type=cite class=cite cite=""><font color="#0000FF">
</font>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??).<br><br>
<font color="#0000FF">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.</font></blockquote><br>
<font color="#008000">AG: It would need standing AND staffing.
<br><br></font><blockquote type=cite class=cite cite="">
<dl>
<dd>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.<br><br>
</dl><br>
<font color="#0000FF">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,</font>
</blockquote><font color="#008000"><br>
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 significa</font>nt
problems (from an At-Large
perspective).<br><br><blockquote type=cite class=cite cite="">
<dl>
<dd><font size=5 color="#0000FF">Cost<br><br>
</font>
<dd>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)?<br><br>
</dl><br>
<font color="#0000FF">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.
</font></blockquote><br>
<font color="#008000">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.<br><br></font><blockquote type=cite class=cite cite="">
<dl>
<dd><font size=5 color="#0000FF">Acceptability<br><br>
</font>
<dd>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?<br><br>
</dl><br>
<font color="#0000FF">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.</font></blockquote><br>
<font color="#008000">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 mes</font>sage to
me.<br><br><blockquote type=cite class=cite cite="">
<dl>
<dd>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.<br><br>
</dl><br>
<font color="#0000FF">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.
</font></blockquote><font color="#008000"><br>
AG: Or its strength!
;-)</font><br><br><blockquote type=cite class=cite cite="">
<dl>
<dd>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).<br><br>
</dl><font color="#0000FF"><br>
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.</font>
<dl>
<dd><font size=5 color="#0000FF">Integratability<br><br>
</font>
<dd>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.
<dd>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.
<dd>Integrating these two approaches may be difficult.
</dl><font color="#0000FF"><br>
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.</font>
<dl>
<dd><font size=5 color="#0000FF">Lost Opportunity<br><br>
</font>
<dd>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.
<dd>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.
<dd>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.
<dd>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.<br><br>
</dl><br>
<font color="#0000FF">GS: I think you probably meant to say IANA at the
end of each of those paragraphs, rather than
ICANN.</font></blockquote><br>
<font color="#008000">AG: Yes, correct. Sorry.<br><br>
</font><blockquote type=cite class=cite cite=""><font color="#0000FF">
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.<br><br>
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).</font></blockquote><br>
<font color="#008000">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.<br><br>
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.<br><br></font><blockquote type=cite class=cite cite="">
<dl>
<dd>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.<br><br>
</dl><br>
<font color="#0000FF">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.</font>
<dl>
<dd><font size=5 color="#0000FF">Alternative<br><br>
</font>
<dd>Simply criticizing the current CWG draft proposal is not particularly
useful without alternatives. <br><br>
</dl><br>
<font color="#0000FF">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.<br>
</font>
<dl>
<dd>My alternative is certain to not please some of the parties in this
discussion, but I believe that it is both possible and viable.
<dd>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. <br><br>
</dl><br>
<font color="#0000FF">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.</font></blockquote><br>
<font color="#008000">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?<br><br>
</font><blockquote type=cite class=cite cite="">
<dl>
<dd>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).
<dd>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.
<dd>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.
</dl>o<br>
<font color="#0000FF">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.</font> </blockquote><br>
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.<br><br><blockquote type=cite class=cite cite="">
<dl>
<dd>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.
<dd>- 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.
<dd>- 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.
<dd>- 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
<dd>- 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.
<dd>- Bylaws regarding GAC advice
related to IANA might need to somewhat altered to compensate for the GAC
not having sitting Board members.
<dd>- Similarly, non-affiliated
ccTLDs would need to be worked into the equation.
<dd>- 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.<br><br>
</dl><br>
<font color="#0000FF">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.<br><br>
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.
</font></blockquote><br>
<font color="#008000">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.<br><br>
</font><blockquote type=cite class=cite cite=""><font color="#0000FF">
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:<br><br>
</font>#1 – APPROVAL FUUNCTION OF CHANGES TO THE ROOT ZONE <br><br>
#2 - PERFORMANCE REVIEW FUNCTION <br><br>
Periodic Review<br><br>
Transactional Performance review (SLAs)<br><br>
Perform (technical) audits and customer surveys<br><br>
#3 - CONTRACTING FUNCTION (ability to enter into a contract)<br><br>
Determining the substance of the contract<br><br>
Award / renewal of contract<br><br>
Understand what stakeholder concerns are<br><br>
Issuance of RFPs<br><br>
Contracting<br><br>
Ability to seek public comments<br><br>
#4 – ENFORCEMENT OF THE CONTRACT FUNCTION (incl.
renewal/rebidding)<br><br>
Termination of contract;<br><br>
Ability to enforce<br><br>
Ability to seek public comments<br><br>
Ability to determine whether contract should be terminated, including
hearing of complaints<br><br>
Listen to community and act on its behalf<br><br>
<font color="#0000FF">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.<br><br>
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 "</font>internal to ICANN" proposal was ever put
on the table within the group prior to Frankfurt in any kind of tangible,
concrete fashion.<font color="#0000FF">" 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.
</font></blockquote><br>
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.<br><br>
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. <br><br>
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. 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. 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). 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). <br><br>
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). In the
ICANN model, the decision would also be required. 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.<br><br>
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.<br><br>
Alan<br><br>
<br>
<blockquote type=cite class=cite cite=""><font color="#0000FF">Greg<br>
</font><br><br>
<dl>
<dd>_______________________________________________
<dd>CWG-Stewardship mailing list
<dd><a href="mailto:CWG-Stewardship@icann.org">
CWG-Stewardship@icann.org</a>
<dd>
<a href="https://mm.icann.org/mailman/listinfo/cwg-stewardship" eudora="autourl">
https://mm.icann.org/mailman/listinfo/cwg-stewardship</a>
</dl></blockquote></body>
</html>