<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#330033">
Hi,<br>
<br>
The original positions in the CWG ranged from maintaining the status
quo to a completely free standng IANA model. The supporters of both
of these options have strong reasons and resolve. We were making no
progress on finding agreement.<br>
<br>
A hybrid position was offered after the Singapore meeting,
proposing a shared service held by the 3 operational communities:
names, number and protocols. This offered both legal separation but
joint affiliation with the various operational communities. That
could not be accepted becasue the other communities did not want to
take on the extra repsonsiblity and objected strongly to the Naming
commmunity coming up with a solution that presupposed their
participation. So we ended up coming down to a single member
affiliate. Those who supported the full free standing IANA
proposal, mostly, accepted that having legal separation was a
minimum, but could be acceptable as a first step, with other steps
possible in the future if necessary. <br>
<br>
Since IANA would be subsidiary to ICANN we are therefore also
including in the model, probably in a fundamental bylaw, a process
by which further separation could be achieved if necessary. This is
described in the proposal. Briefly, the IANA Function Review (IFR)
Team (IFRT) could recommend that there was a problem with the then
current arrangement and recommend that further separation
discussions be initiated. The current proposal is still open on
whether at that point:<br>
<br>
- a Cross Community WG, similar to the CWG-IANA or to the ICG (IANA
stewardship transition Coordination Group), would be established to
work on that issue with the option of creating a RFP (request for
proposal) and possibly finding a new IANA function operator. <br>
<br>
- the IFR team itself could then begin the work on a RFP and finding
a new IANA Function Operator.<br>
<br>
The CWG is looking for community opinion on these alternatives, so
if NCSG has a recommendation, it would be a good thing to offer in
our comments.<br>
<br>
In terms of the degree of control that ICANN has of the affiliate,
we are still discussing the degree to which the affiliate will be
subject to ICANN mangement and working for as much independent
action as possible. The contract between ICANN and its affiliate
would define the relationship as well as the requirements on each
side. The Post Transtion IANA (PTI) would have its own largely
independent Board. <br>
<br>
Devils and details still abound.<br>
<br>
avri<br>
(NCSG member on the CWG-IANA)<br>
<br>
<div class="moz-cite-prefix">On 23-Apr-15 11:27, David Post wrote:<br>
</div>
<blockquote cite="mid:55390fcd.6e21340a.3be7.2143@mx.google.com"
type="cite">
Milton/All<br>
<br>
I'm sure this was talked about at length during the development of
the
proposal, but it does seem rather odd to me that "functional and
legal separation" between the IANA naming functions and ICANN
(which
I agree is an important principle) has been implemented in this
proposal
by means of setting up a new corporation that is a wholly-owned
subsidiary of ICANN's (with an ICANN-designated Board - sec
III.A.i.b). Can you say a few words as to why you think that
provides for the necessary independence? The PTI Board will be
answerable to the ICANN Board, because ICANN is the only
"member" of PTI - ?? <br>
<br>
David<br>
<br>
<br>
The At 10:58 AM 4/23/2015, Milton L Mueller wrote:<br>
<blockquote type="cite" class="cite" cite="">Dear NCSG-ers:<br>
<br>
<a moz-do-not-send="true" name="_MailEndCompose"></a>The domain
names part of the IANA
transition is finally being formed. A draft proposal was
released
yesterday and it is open for public comment. <br>
<br>
In my view, this is a big win for accountability. By legally
separating
the IANA functions operator from ICANN, it will be easier to
hold ICANN’s
board and staff accountable for the policy making process, and
easier to
hold the post-transition IANA accountable for its performance of
the IANA
functions. Lines of responsibility will be more direct, and
policy more
clearly separated from implementation. <br>
<br>
The proposal also promotes accountability by creating a periodic
review
process that could allow the names community to “fire” the
existing IANA
if there was great dissatisfaction with its performance. This
enhances
the accountability sought by the numbers and protocols
communities as
well as creating separability for the names community for the
first time.
<br>
<br>
The legal affiliate structure seems to have found the middle
ground in
the debate over ICANN’s role in the IANA functions. Although
IANA will
still be a subsidiary of ICANN, Inc., thus defusing any concerns
about
creating new organizations, it will have a separate board and a
clearer
line of demarcation between the politics of ICANN the policy
maker and
the technical coordination functions provided by the IANA
functions
operator. <br>
<br>
You can read the (very long) proposal here:<br>
<br>
<a moz-do-not-send="true"
href="https://www.icann.org/news/announcement-2015-04-22-en">https
://www.icann.org/news/announcement-2015-04-22-en</a><br>
<br>
You can comment on it here:<br>
<b> <br>
</b>
<a moz-do-not-send="true"
href="https://www.icann.org/public-comments/cwg-stewardship-draft-proposal-2015-04-22-en">https://www.icann.org/public-comments/cwg-stewardship-draft-proposal-2015-04-22-en</a>
<br>
<div align="center"> <br>
</div>
</blockquote>
<br>
*******************************<br>
David G Post - Senior Fellow, Open Technology Institute/New
America
Foundation<br>
blog (Volokh Conspiracy)
<a moz-do-not-send="true"
href="http://www.washingtonpost.com/people/david-post"
eudora="autourl">
http://www.washingtonpost.com/people/david-post<br>
</a>book (Jefferson's Moose)
<a moz-do-not-send="true"
href="http://tinyurl.com/c327w2n%A0%A0%A0%A0%A0"
eudora="autourl">
http://tinyurl.com/c327w2n </a> <br>
music
<a moz-do-not-send="true" href="http://tinyurl.com/davidpostmusic"
eudora="autourl">
http://tinyurl.com/davidpostmusic</a> publications etc.
<a moz-do-not-send="true"
href="http://www.davidpost.com%A0%A0%A0%A0%A0%A0%A0/"
eudora="autourl">
http://www.davidpost.com </a> <br>
******************************* </blockquote>
<br>
<br /><br />
<hr style='border:none; color:#909090; background-color:#B0B0B0; height: 1px; width: 99%;' />
<table style='border-collapse:collapse;border:none;'>
<tr>
<td style='border:none;padding:0px 15px 0px 8px'>
<a href="http://www.avast.com/">
<img border=0 src="http://static.avast.com/emails/avast-mail-stamp.png" alt="Avast logo" />
</a>
</td>
<td>
<p style='color:#3d4d5a; font-family:"Calibri","Verdana","Arial","Helvetica"; font-size:12pt;'>
This email has been checked for viruses by Avast antivirus software.
<br><a href="http://www.avast.com/">www.avast.com</a>
</p>
</td>
</tr>
</table>
<br />
</body>
</html>