<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Thanks Guru<br>
<br>
<div class="moz-cite-prefix">On 3/17/2015 10:39 AM, Guru Acharya
wrote:<br>
</div>
<blockquote
cite="mid:CAEEwkf7fjFw1_+bN=bkb3YHz_=tZchj66kMyk0qPL+oek2a-fA@mail.gmail.com"
type="cite">
<div dir="ltr">Hi CW,
<div><br>
</div>
<div>Appreciate your comments. I tend to agree with most of what
you have written.</div>
<div><br>
</div>
<div>However, I think we are approaching the problem
differently. While you appear to be persuading us to make
ICANN the permanent home of IANA, I feel that this decision is
out of scope for the DT. What we can best do is figure out a
succession plan that appropriately addresses all concerns that
may arise if the CWG chooses to implement separability in its
final proposal.</div>
</div>
</blockquote>
Agree.<br>
<blockquote
cite="mid:CAEEwkf7fjFw1_+bN=bkb3YHz_=tZchj66kMyk0qPL+oek2a-fA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>So, I suggest that all of us channel our pessimism of
separability in a constructive manner by suggesting how the
foreseeable problems in succession can be overcome. </div>
</div>
</blockquote>
I really don't think that separability is an issue here as I have
mentioned elsewhere. (And we should not be evolving this work with
a particular bias towards one model or another.) This transition
plan is needed no matter what one may think of the various models
under consideration.<br>
<blockquote
cite="mid:CAEEwkf7fjFw1_+bN=bkb3YHz_=tZchj66kMyk0qPL+oek2a-fA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>I have read your comments and replied to them in that
context. Please correct me if I do so incorrectly.</div>
<div><br>
</div>
<div>1) The need for training should be minimised by devising a
RFP process that selects the most qualified contractor.
Accordingly, the succession plan that we suggest should also
recommend the minimal technical qualifications for potential
bidders that should be considered during the RFP process in
order to ensure continued stability and security.</div>
</div>
</blockquote>
We might want to raise this with the CWG and/or discuss further as
not fully sure this is within our remit (then again I am not sure
where those minimum criteria are being discussed).<br>
<blockquote
cite="mid:CAEEwkf7fjFw1_+bN=bkb3YHz_=tZchj66kMyk0qPL+oek2a-fA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>2) There is a need to overcome the possibility that ICANN
may frustrate the succession plan using transfer of IPR and
website as leverage. I suggest that we look into the
understanding reached by CRISP and IETF regarding IPR related
issued in which they jointly agree that the IETF Trust may
hold IANA related IPRs. The CWG could also jointly agree with
this proposal. This would preclude the possibility of ICANN
frustrating the transfer of IPR.</div>
</div>
</blockquote>
We should discuss with DT on IPR.<br>
<blockquote
cite="mid:CAEEwkf7fjFw1_+bN=bkb3YHz_=tZchj66kMyk0qPL+oek2a-fA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>3) I agree that ICANN may reject the DIDP request for the
Root Zone Key succession plan citing various non-disclosure
categories. To deal with this, we could request the chairs to
send an email to IANA and the ICANN board highlighting the
importance of the document for the CWG. At best, the DIDP
response should only redact those portions of the document
that are extremely confidential and not the entire document.
If we fail to get hold of the document, we could best try to
address the issues by involving someone with the required
experience in the DT process.</div>
<div><br>
</div>
<div>4) I agree that there may be serious flaws in the existing
software and machinery, which may be the very reason for
ending the current contract and selecting a new IANA operator.
To deal with this, I suggest that the old operator should also
be required to transfer the source code of the software to the
new operator - so that the software may be
rectified/modified/improved by the new operator. We could also
require the incumbent operator to place a copy of the source
code with a escrow to preclude the possibility of the old
operator frustrating the succession or holding the entire
internet community to ransom.<br>
</div>
</div>
</blockquote>
(Not sure what the flaws might be) but agree that it is key that the
software can be fully ported to the successor.<br>
<blockquote
cite="mid:CAEEwkf7fjFw1_+bN=bkb3YHz_=tZchj66kMyk0qPL+oek2a-fA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>5) While I personally agree that IANA should not be split,
it would be shortsighted to not recognise that each of the
three independent operational communities may develop
divergent requirements over a substantial period of time given
the pace at which technology and standards are evolving. It is
important to note that the other proposals from CRISP and IETF
also recognise the possibility of IANA splitting. I suggest we
look into the implications of the possibility of IANA breaking
up into two or three parts and then at the minimum mention the
issues that may arise and that may need to be considered.</div>
</div>
</blockquote>
<blockquote
cite="mid:CAEEwkf7fjFw1_+bN=bkb3YHz_=tZchj66kMyk0qPL+oek2a-fA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>6) I agree that deleting data by the old operator may have
implications. While I am not able to contemplate these
implications right now, we should definitely explore these
issues. In that case, the IANA Functions Contract needs to
have a clause that requires the old operator to provide
security for retention of that data.</div>
</div>
</blockquote>
Agree.<br>
<br>
Thanks!<br>
<br>
<blockquote
cite="mid:CAEEwkf7fjFw1_+bN=bkb3YHz_=tZchj66kMyk0qPL+oek2a-fA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>7) ...</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Mar 17, 2015 at 1:00 AM, CW
Lists <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:lists@christopherwilkinson.eu"
target="_blank">lists@christopherwilkinson.eu</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">Dear Guru:
<div><br>
</div>
<div>I have a few comments on the points that you have
mentioned, below.</div>
<div>Please see attached .pdf</div>
<div><br>
</div>
<div>Regards</div>
<div><br>
</div>
<div>Christopher</div>
<div><br>
</div>
</div>
<br>
<div style="word-wrap:break-word">
<div><br>
</div>
<div><br>
</div>
<div>
<div>
<div>On 15 Mar 2015, at 09:48, Guru Acharya <<a
moz-do-not-send="true"
href="mailto:gurcharya@gmail.com" target="_blank">gurcharya@gmail.com</a>>
wrote:</div>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div dir="ltr">
<div>Hi CW, JG, MS and JA,</div>
<div><br>
</div>
<div>This is with reference to the attached
document prepared by ICANN under C.7.3 for
transition of IANA to a successor
contractor.<br>
</div>
<div><br>
</div>
<div>I wanted to quickly remark that there are
serious deficiencies in the document. At the
face of it, the following issues come to my
mind:</div>
<div>
<ol>
<li><b>Training & Overlapping Time
Period: </b>The transition document
does not mandate an overlapping time
period wherein the old operator would be
required to assist and train the
employees of the new operator in taking
over the IANA functions. The overlapping
time period should only end once the
requisite security and stability has
been reached by the new operator. Such a
process may also require the old
operator to develop training material.</li>
<li><b>Website & IPR</b>: The
transition plan only requires the old
operator to share the data that is
publicly available on the website. It
does not require the operator to
transfer the website itself (<a
moz-do-not-send="true"
href="http://iana.org/"
target="_blank">iana.org</a>). It is
also silent about the assignment of
associated IPR. For example, IANA is a
registered trademark of ICANN.
Similarly, ICANN has a copyright on all
documents produced by the IANA staff.<br>
</li>
<li><b>Root Zone Key</b>: The transition
of responsibilities for root zone key is
in a separate document that is currently
not available with us. As an action
item, we should request the IANA staff
for this document or file a DIDP request
for it.</li>
<li><b>Software and Machinery</b>: The
transition document only requires the
old operator to provide a description of
the functional requirements of the
software and APIs. It excludes transfer
of the existing software and the
existing essential machinery that is
used by the old operator. This may have
serious stability and
security implications. The transition
plan should require the transfer of all
essential softwares and machinery from
the old operator to the new operator,
especially for the overlapping time
period.</li>
<li><b>Specific Exclusion</b>: It is not
clear why certain types of documents
have been excluded from transition and
marked as "deliverables not requiring
transition". The rationale for this
exclusion needs to be tested against the
stress scenarios.</li>
<li><b>Breakup of IANA</b>: The transition
plan does not address the possibility
that IANA may be broken into three
smaller IANAs in the future. The
associated issues need to be addressed.</li>
<li><b>Old data</b>: The transition plan
should require the old operator to
permanently delete all data. If the old
operator retains any data that it no
longer requires, then it should continue
to provide the requisite security for
maintaining the data.</li>
<li><b>Holistic View</b>: A systematic
transition plan will typically address
associated HR issues, legal issues,
procurement issues, IT issues, cultural
issues, finance issues and finally also
develop a proper Gantt chart with
estimated timelines.</li>
</ol>
</div>
<div><br>
</div>
</div>
<div>
<div class="gmail_extra"><br>
</div>
</div>
</div>
</div>
<span><transition-plan-201404.pdf></span>_______________________________________________<br>
dt4 mailing list<br>
<a moz-do-not-send="true"
href="mailto:dt4@icann.org" target="_blank">dt4@icann.org</a><br>
<a moz-do-not-send="true"
href="https://mm.icann.org/mailman/listinfo/dt4"
target="_blank">https://mm.icann.org/mailman/listinfo/dt4</a><br>
</blockquote>
</div>
<br>
</div>
</div>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
dt4 mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dt4@icann.org">dt4@icann.org</a>
<a class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/dt4">https://mm.icann.org/mailman/listinfo/dt4</a>
</pre>
</blockquote>
<br>
</body>
</html>