<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#330033">
<br>
<div class="moz-cite-prefix">On 21-Feb-15 01:08, Seun Ojedeji wrote:<br>
</div>
<blockquote
cite="mid:CAD_dc6hmkh6fAW-SPz4GPqHN1is5oTDHTPsyCxBK-uy=pP_Keg@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
<p dir="ltr">Hi,</p>
<p dir="ltr">How does this proposal address the few points below:</p>
<p dir="ltr">- ICANN is running IANA properly and should continue
to be the operator<br>
</p>
</blockquote>
<br>
This proposal rest upon the same team being able to continue
handling the operator functions. The 12 person IANA team is what is
doing the job properly and what needs protecting in a stewardship
transition.<br>
<br>
In the fully owned subsidiary configuration, ICANN remains the
operator, or rather the owner or the operator.<br>
In the Shared Service Arrangement ICANN remains one of the owners.
In this operational control is shared with the other operational
communities while ICANN remains a co-owner, has SLA/MOUs and a board
seats.<br>
<br>
It is only in the Free Standing configuration that ICANN would cease
being an owner of a subsidiary though would probably remain owners,
perhaps even members, of the Free Standing company. And would
retain Community Board seats.<br>
<br>
<blockquote
cite="mid:CAD_dc6hmkh6fAW-SPz4GPqHN1is5oTDHTPsyCxBK-uy=pP_Keg@mail.gmail.com"
type="cite">
<p dir="ltr">
- ICANN is purpose built with it's main purpose of centrally
operating IANA for the 3 communities<br>
</p>
</blockquote>
<br>
While this may have been the intention at day 0, the evolution of
ICANN over the years has been anything but purpose built. ICANN has
evolved into a much needed policy group that deals with the
political, financial and other issues that grow out of its narrow
technical mandate. The remaining issue that has not been solved in
the Internal models is the one where the policy organization for
gTLDS, the bulk of ICANN's 100+ MUSD operations is not separated
from IANA.<br>
<br>
<blockquote
cite="mid:CAD_dc6hmkh6fAW-SPz4GPqHN1is5oTDHTPsyCxBK-uy=pP_Keg@mail.gmail.com"
type="cite">
<p dir="ltr">
- The task at hand is to transition IANA stewardship, is the
proposal not doing more than that?<br>
</p>
</blockquote>
<br>
Not really. Especially the model is very much about stewardship and
finding ways to distribute that stewardship in the light of losing
NTIA. In one configuration, ICANN retains complete control, just of
a structurally separated internal component that provides greater
transparency. In the Shared Service Arrangement, IANA shares this
ownership with the other 2 communities, if they are interested in
sharing. If they aren't, I figure they will be fine with leaving it
as a full Owned subsidiary of ICANN.<br>
<br>
<blockquote
cite="mid:CAD_dc6hmkh6fAW-SPz4GPqHN1is5oTDHTPsyCxBK-uy=pP_Keg@mail.gmail.com"
type="cite">
<p dir="ltr">
- Based on the response given by Milton, the practical
implication of this proposal seem to imply absolute separation
between IANA functions so names operation is no longer under
ICANN oversight. If that is correct are we still within scope of
our task by proposing that?<br>
</p>
</blockquote>
<br>
I do not speak for Milton, that is beyond my pay grade. <br>
<br>
While there is structural separation it is not absolute - currently
some try to argue that there is functional separation at ICANN as
required by NTIA in the RFP, though some of us have our doubts on
this actually being the case, especially since IANA isn't even as
separated as is GDD. Not all separation is the same or absolute.<br>
<br>
In two of the configurations, that structural separation is
contained within the existing organizations and remains under ICANN
protection. Even in the Free Standing configuration, ICANN remains
on of the controling voices on the Community Board. ICANN retains
its share of the stewardship role in all of the configurations in
the model. In no part of the model, and in none of it
configurations is the separation complete or absolute. And remember
we allegedly have functional separation today. This model is just
an evolution of current realities with as little disruption as
possible.<br>
<br>
In fact for absolute or complete separation in this model, ICANN
would have to utilize the same so-called nuclear option the other
two operational communities are posting, the ability to take their
business elsewhere. None of the configurations offered provides
absolute separation.<br>
<br>
I see nothing that excludes this from our scope to find the best
stewardship solution we can given the constraint of multistakeholder
general agreement. We face an impasse with strong smart people
insisting they are correct on two very opposed sides of the
discussion. We can continue the tug of war about who is right;
constantly worrying over who has the better argument of the day or
the best allies. Perhaps we can even engage in some brinkmanship -
just like US political leaders. We decided to try to find a
solution that satisfies many of the concerns of both camps without
scaring those who are watching.<br>
<br>
<blockquote
cite="mid:CAD_dc6hmkh6fAW-SPz4GPqHN1is5oTDHTPsyCxBK-uy=pP_Keg@mail.gmail.com"
type="cite">
<p dir="ltr">
- What does the proposal intend to address; separability OR
separation?</p>
</blockquote>
<br>
It is attempting to balance the most critical requirements for a
multistakeholder solution, an Internal solution and also for an
External solution, and one that is solid, stable and safe from
International capture enough to satisfy Republicans in Congress as
well. It is meant to be a reasonable and based on a relatively
standard business relationship that provides the multistakeholder
control through ownership, sla/mous, and membership in the Post
Transition Board. Separability is a principle that all solutions
must satisfy, but it is not a goal. The goal is stewardship for a
multistakeholder, stable, secure and resilient IANA. The secondary
goal was making the solution as simple as possible with as little
reliance on CCWG-Accountabilty fundamental change as possible.<br>
<br>
thanks<br>
<br>
avri<br>
<br>
<br>
<blockquote
cite="mid:CAD_dc6hmkh6fAW-SPz4GPqHN1is5oTDHTPsyCxBK-uy=pP_Keg@mail.gmail.com"
type="cite">
<p dir="ltr">Thanks</p>
<p dir="ltr">Regards<br>
sent from Google nexus 4<br>
kindly excuse brevity and typos.</p>
<div class="gmail_quote">On 21 Feb 2015 00:19, "Avri Doria" <<a
moz-do-not-send="true" href="mailto:avri@acm.org">avri@acm.org</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote">
<div> <br>
<div>On 20-Feb-15 16:50, Milton L Mueller wrote:<br>
</div>
<blockquote type="cite">
<p class="MsoNormal"><span></span></p>
<p class="MsoNormal"><span>My question: </span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span>Does this model provide for
separability?</span></p>
<p class="MsoNormal"><span> </span></p>
</blockquote>
<br>
First it provides structural separation in all
configurations. That is a first level of severability and
hopefully as much as really is ever needed. Additionally,
in this model, ICANN would have the same ability to pick
another provider, or perhaps a redundant provider, just as
the names or protocols can now. This is made possible by
virtue of structural separation and the defintion of
SLA/MOUs across a corporate boundary.<br>
<br>
Further levels of separability can, however, be obtained in
the Shared Service Arrangement configuration or the finally
in the Free Standing configuration. <br>
<br>
Finally<br>
<br>
<br>
</div>
<br>
_______________________________________________<br>
CWG-Stewardship mailing list<br>
<a moz-do-not-send="true"
href="mailto:CWG-Stewardship@icann.org">CWG-Stewardship@icann.org</a><br>
<a moz-do-not-send="true"
href="https://mm.icann.org/mailman/listinfo/cwg-stewardship"
target="_blank">https://mm.icann.org/mailman/listinfo/cwg-stewardship</a><br>
<br>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>