<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#330033">
Hi,<br>
<br>
Thanks. Happy to do so.<br>
<br>
avri<br>
<br>
<div class="moz-cite-prefix">On 20-Feb-15 11:56, Jonathan Robinson
wrote:<br>
</div>
<blockquote cite="mid:022f01d04d2e$2b0a8b10$811fa130$@afilias.info"
type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered
medium)">
<div class="WordSection1">
<p class="MsoNormal"><span>Avri and CWG members / participants,</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span>Lise and I discussed this and we
propose to have this as a substantive agenda item at the CWG
call on Tuesday.</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span>I suggest that you come prepared to
present the thinking and rationale behind the model and the
CWG members / participants come prepared to question /
discuss.</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span>Thanks,</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span>Jonathan</span></p>
<p class="MsoNormal"><span> </span></p>
<div>
<div>
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span
lang="EN-US"> Avri Doria [<a class="moz-txt-link-freetext" href="mailto:avri@acm.org">mailto:avri@acm.org</a>] <br>
<b>Sent:</b> 20 February 2015 15:32<br>
<b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:cwg-stewardship@icann.org">cwg-stewardship@icann.org</a><br>
<b>Subject:</b> Re: [CWG-Stewardship] Update on the
Integrated model.</span></p>
</div>
</div>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Hi,<br>
<br>
</p>
<div>
<p class="MsoNormal">On 19-Feb-15 18:13, Gomes, Chuck wrote:</p>
</div>
<blockquote>
<div>
<p class="MsoNormal">Thanks Avri. Forgive me if this was
already discussed by I haven’t been able to keep up on
this very well. </p>
</div>
</blockquote>
<p class="MsoNormal"><br>
No it has not been discussed in the CWG yet. I have hopes for
the future and glad for the present opportunity.<br>
<br>
There have been many informal conversations with diverse
people, i.e. anyone we could find free in Singapore and could
buttonhole long enough to explain the model, but nothing
formal.<br>
<br>
<br>
</p>
<div>
<p class="MsoListParagraph">· Has this approach been
vetted with the protocol and numbers communities?</p>
</div>
<p class="MsoNormal"><br>
Vetted, no. <br>
<br>
Discussed informally with some participants from those
operational communities, yes.<br>
<br>
Two points:<br>
<br>
-the first configuration is pretty much an ICANN internal
model and other than being coordinated by the ICG probably
does not need a whole lot of vetting by the other operational
communities.<br>
<br>
- even the other models do not require a whole lot of change
from the other operational models. But lining up the
operational community's solutions is the main task of the ICG
once we have come up with our solution. We were careful to
keep changes required by those communities limited mostly to
the degree of control they had over IANA and the contracting
point of contact.<br>
<br>
Finally, there are many members of those operational
communities on our lists so hopefully they have been taking a
look at it as it was developing. We received anonymous
comments from many people in the docs, no idea who most of
them were. <br>
<br>
I would not expect any sort of formal answer from the other
operational communities before the CWG has even reviewed it.
At this point this is just a proposal by an ad hoc, self
selected drafting team looking for an solution to the apparent
impasse between the Inside and Outside models. Something for
all to question and hopefully discuss in an open manner.<br>
<br>
Finally we are always happy to talk to those communities and
their members, if they have an interest that predates a
possible CWG decision to accept this model. As I say, there
are representatives of those communities on this list and I
would be happy to hear from them. As would our my partners in
this project, though they are more taciturn than I am, and
have given me leave to use the word 'we' (though be assured
they will correct me anytime I step wrong).<br>
<br>
<br>
</p>
<div>
<p class="MsoListParagraph">· What does it mean that
“ICANN establishes SLAs/MoU with Post Transition IANA”? Why
would ICANN be involved in this?</p>
</div>
<p class="MsoNormal"><br>
Because in any of the configurations of the model there is a
degree of separation. The fully owned subsidiary
confirguartion does include full structural separation into
the subsidiary. Often the interface, in cases of an fully
owned entity, is an SLA/MOU. One of the stresses for the
Outside model people in the CWG is that fact the the
relationship between the ICANN operational community and IANA
has no externalized rigor. SLAs/MOUs between a parent company
and a subsidiary are one way to establish such a controlled
relationship. <br>
<br>
So even in the fully owned subsidiary of ICANN, it is possible
for ICANN, the parent company, to establish SLA and MOUs with
its Post Transition IANA (PTI) subsidiary. <br>
<br>
In the Shared Service Arrangement, ICANN would be one of 3
operational community joint owners* establishing SLA/MOUs
with their jointly owned subsidiary.<br>
<br>
<br>
</p>
<div>
<p class="MsoListParagraph">· With regard to the
overall status of the IANA functions operator, I understand
the need for parity between the three organizations, but
when it comes to each of their specific functions, I don’t
see the value of parity. For example, couldn’t parity
become a problem with regard to issues related to the naming
functions from a naming community point of view?</p>
</div>
<p class="MsoNormal"><br>
The CSC, in support of its SLAs with recourse to the IAP is
the main point for naming community issues. The only parity
issues there might be those within the CSC in terms of
Registry priority within that committee and the balance within
ICANN's PTI Board representation.<br>
<br>
The Post Transition IANA (PTI) Board function is limited to
IANA internal operational issues, finances and exception
processing.<br>
<br>
By the time an issue gets passed the IAP, which I personally
hope has binding arbitration capabilities, to the Board of the
PTI as an exception processing issue, it is one that would
probably be broader that just a naming community issue and
warrant the check and balances a board with full parity
brings.<br>
<br>
<br>
</p>
<div>
<p class="MsoListParagraph">· Without in any way
criticizing the proposed approach, isn’t the new IANA board
a new architectural feature</p>
</div>
<p class="MsoNormal"><br>
Criticism is fine, this is an out of the box proposal meant to
solve a nearly intractable problem amongst the Inside model,
the Outside model and Republicans in the US congress. If it
can't deal with criticism it isn't going to get very far.
Criticism is the fuel of improvement. And this model, as all
models, needs improvement only broader discussions, i.e.
criticism, self criticism and further work, can bring.<br>
<br>
Yes the model includes new architectural features, just as
the CSC, MRT and IAP are. In fact it is a variation on the
mainstream theme, though like in the internal models, the
Contract Co has been eliminated, so one less new feature to
deal with.<br>
<br>
But indeed it does need meet the accountability test that
Strickling mentioned for new components. <br>
<br>
Working on a draft on that now. Pretty close too, just waitng
for one of the team to get back from vacation and check it out
before opening it up for wider criticism and discussion.<br>
<br>
<br>
</p>
<div>
<p class="MsoListParagraph">· Has any thought been put
into the source of funding?</p>
</div>
<p class="MsoNormal"><br>
Yes.<br>
<br>
In the wholly own subsidiary, ICANN subsidizes, as it owns it.
Really no diffferent that it does now, just with a more
transparent and specific budget.<br>
<br>
In the Shared Service Arrangements, it is shared between the
owners (IETF/IAB/ISOC, ICANN & RIRs/NRO) in some way they
agree on. I understand that the numbers community already
contributes a significiant sum to ICANN operations, perhaps
some part of it is intended for IANA operations and would be
redirected. As for the protocol community, I expect the
others would continue to carry them given their nature as a
subsidized volunteer group that takes in no income but which
remains critical to the IANA ecosystem and the Internet
itself.<br>
<br>
In the Free Standing configuration, I haven't really thought
about funding, though perhaps others in the team have. I would
assume a model that included startup investment from the
operational communities, and perhaps others, and the
development of a fund raising, or income producing, strategy
by its Board. Just like any other free standing company. I
think anyone who championed that confdiguration would need to
get mode specific on those details. <br>
<br>
<br>
</p>
<div>
<p class="MsoListParagraph">· Who would have MOUs with
the Post Transition IANA?</p>
</div>
<p class="MsoNormal"><br>
They would be between Post Transition IANA (PTI) and each its
customers: IETF/IAB/ISOC, ICANN, & RIRs/NRO<br>
Not sure what you mean by "who holds them?"<br>
<br>
I suppose in the fully subsidized configuration, the parent
compnay ICANN could still hold the SLA/MOUs the for the
protocol and number operational communities, if they wanted to
continue contracting with ICANN instead of PTI. This would
require a slight variation on the subsidiary configuration,
but could be defined. Ie. ICANN would remain repsonsble for
meeting the SLA, and it would use its fully own IANA
subsidiary to do the work.<br>
<br>
<br>
</p>
<div>
<p class="MsoListParagraph">· In the ICANN subsidiary,
shared services and free-standing diagrams, why is ICANN
shown as one of three elements of the Post Transition IANA
Board?</p>
</div>
<p class="MsoNormal"><br>
The Board is made up of the three operational communities,
each of which brings it paticualr multstakeholder mix to the
table. ICANN, our CWG community, is one of the 3 operational
communities and thus should bring its multistakeholder mix to
the PTI Board.<br>
<br>
<br>
</p>
<div>
<p class="MsoNormal">I appreciate the thought that has gone
into this.</p>
</div>
<p class="MsoNormal"><br>
And I yours.<br>
<br>
Thanks<br>
avri<br>
<br>
* The model also allows for separate SLA/MOUS with the the non
participating ccTLDs if necessary - the the PTI Board makes no
accommodation for that at this point - a complexity we did not
tackle. The model is based on the notion that each of the
operational communities internalizes its own multistakeholder
churn, but we recognize that some of the churn cannot always
be internalized.<br>
<br>
<br>
</p>
<div>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Chuck</p>
<p class="MsoNormal"> </p>
<div>
<div>
<p class="MsoNormal"><b>From:</b> <a
moz-do-not-send="true"
href="mailto:cwg-stewardship-bounces@icann.org">cwg-stewardship-bounces@icann.org</a>
[<a moz-do-not-send="true"
href="mailto:cwg-stewardship-bounces@icann.org">mailto:cwg-stewardship-bounces@icann.org</a>]
<b>On Behalf Of </b>Avri Doria<br>
<b>Sent:</b> Wednesday, February 18, 2015 2:09 PM<br>
<b>To:</b> <a moz-do-not-send="true"
href="mailto:cwg-stewardship@icann.org">cwg-stewardship@icann.org</a><br>
<b>Subject:</b> [CWG-Stewardship] Update on the
Integrated model.</p>
</div>
</div>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Hi,<br>
<br>
As mentioned in an earlier email, Matthew Shears, Brenden
Kuerbis and I have been working on a model that attempts to
integrate solutions to some of the various sets of concerns
by those favoring internal models and those preferring
external models while trying to make the model simpler and
more accountable to the IANA ecosystem and the wider
community. During Singapore week we spoke to as many as we
could about this model and have received, and worked
through, a number of comments on the open drive draft
document, which we announced on the list.<br>
<br>
The working draft, which is still a work in progress and
remains open for comment can be found at:<br>
<a moz-do-not-send="true"
href="https://docs.google.com/document/d/1SvKDEIaeHdre3BQXHNe1K3hCA95dsFWqWAz2Kg5YZCU/edit?usp=sharing">https://docs.google.com/document/d/1SvKDEIaeHdre3BQXHNe1K3hCA95dsFWqWAz2Kg5YZCU/edit?usp=sharing</a><br>
<br>
I have attached a pdf version of a snapshot draft of the doc
as of today.<br>
<br>
We would like to be able to present this at the next RFP3
meeting. Or anywhere else that is appropriate.<br>
<br>
We are also working on drafts to document the means by which
this model responds to NTIA requirements, but we will able
to speak those on list and during the meeting.<br>
<br>
In the draft we present three possible configurations for
the model. The authors believe that Shared Service
Arrangement (page 6) is the preferred configuration, as it
offers the most accountability for the least amount of
change or complexity. We would also be interested to see
how these models fare under the stress testing - we have not
done that in any focused way yet, though we have kept those
tests in mind. <br>
<br>
It should be noted that this model would require a minimal
amount of accommodation by the Protocols and Number
communities, but believe that this accommodation while not
disturbing their current model in any significant way would
make IANA more accountable to them as well.<br>
<br>
Thanks<br>
<br>
avri<br>
<br>
</p>
</div>
<p class="MsoNormal"> </p>
</div>
</blockquote>
<br>
</body>
</html>