<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#330033">
Hi,<br>
<br>
<br>
<div class="moz-cite-prefix">On 19-Feb-15 18:13, Gomes, Chuck wrote:<br>
</div>
<blockquote
cite="mid:6DCFB66DEEF3CF4D98FA55BCC43F152E4950B3C2@BRN1WNEXMBX01.vcorp.ad.vrsn.com"
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>Thanks Avri. Forgive me if this was
already discussed by I haven’t been able to keep up on this
very well.
</span></p>
</div>
</blockquote>
<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>
<blockquote
cite="mid:6DCFB66DEEF3CF4D98FA55BCC43F152E4950B3C2@BRN1WNEXMBX01.vcorp.ad.vrsn.com"
type="cite">
<div class="WordSection1">
<p class="MsoListParagraph"><span><span>·<span>
</span></span></span><span>Has this approach been vetted
with the protocol and numbers communities?</span></p>
</div>
</blockquote>
<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>
<blockquote
cite="mid:6DCFB66DEEF3CF4D98FA55BCC43F152E4950B3C2@BRN1WNEXMBX01.vcorp.ad.vrsn.com"
type="cite">
<div class="WordSection1">
<p class="MsoListParagraph"><span><span>·<span>
</span></span></span><span>What does it mean that “</span><span>ICANN
establishes SLAs/MoU with Post Transition IANA</span><span>”?
Why would ICANN be involved in this?</span></p>
</div>
</blockquote>
<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>
<blockquote
cite="mid:6DCFB66DEEF3CF4D98FA55BCC43F152E4950B3C2@BRN1WNEXMBX01.vcorp.ad.vrsn.com"
type="cite">
<div class="WordSection1">
<p class="MsoListParagraph"><span><span>·<span>
</span></span></span><span>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?</span></p>
</div>
</blockquote>
<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>
<blockquote
cite="mid:6DCFB66DEEF3CF4D98FA55BCC43F152E4950B3C2@BRN1WNEXMBX01.vcorp.ad.vrsn.com"
type="cite">
<div class="WordSection1">
<p class="MsoListParagraph"><span><span>·<span>
</span></span></span><span>Without in any way criticizing
the proposed approach, isn’t the new IANA board a new
architectural feature</span></p>
</div>
</blockquote>
<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>
<blockquote
cite="mid:6DCFB66DEEF3CF4D98FA55BCC43F152E4950B3C2@BRN1WNEXMBX01.vcorp.ad.vrsn.com"
type="cite">
<div class="WordSection1">
<p class="MsoListParagraph"><span><span>·<span>
</span></span></span><span>Has any thought been put into
the source of funding?</span></p>
</div>
</blockquote>
<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>
<blockquote
cite="mid:6DCFB66DEEF3CF4D98FA55BCC43F152E4950B3C2@BRN1WNEXMBX01.vcorp.ad.vrsn.com"
type="cite">
<div class="WordSection1">
<p class="MsoListParagraph"><span><span>·<span>
</span></span></span><span>Who would have MOUs with the
Post Transition IANA?</span></p>
</div>
</blockquote>
<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>
<blockquote
cite="mid:6DCFB66DEEF3CF4D98FA55BCC43F152E4950B3C2@BRN1WNEXMBX01.vcorp.ad.vrsn.com"
type="cite">
<div class="WordSection1">
<p class="MsoListParagraph"><span><span>·<span>
</span></span></span><span>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?</span></p>
</div>
</blockquote>
<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>
<blockquote
cite="mid:6DCFB66DEEF3CF4D98FA55BCC43F152E4950B3C2@BRN1WNEXMBX01.vcorp.ad.vrsn.com"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><span>I appreciate the thought that has
gone into this.</span></p>
</div>
</blockquote>
<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>
<blockquote
cite="mid:6DCFB66DEEF3CF4D98FA55BCC43F152E4950B3C2@BRN1WNEXMBX01.vcorp.ad.vrsn.com"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span>Chuck</span></p>
<p class="MsoNormal"><span> </span></p>
<div>
<div>
<p class="MsoNormal"><b><span>From:</span></b><span>
<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.</span></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>
<br>
</p>
</div>
</blockquote>
<br>
</body>
</html>