[DTL] Deficiencies in Plan for Transition to Successor Contractor

[Guru Acharya]

Hi CW, JG, MS and JA,

This is with reference to the attached document prepared by ICANN under
C.7.3 for transition of IANA to a successor contractor.

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:

   1. *Training & Overlapping Time Period: *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.
   2. *Website & IPR*: 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 (iana.org). 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.
   3. *Root Zone Key*: 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.
   4. *Software and Machinery*: 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.
   5. *Specific Exclusion*: 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.
   6. *Breakup of IANA*: 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.
   7. *Old data*: 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.
   8. *Holistic View*: 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/dt4/attachments/20150315/eb4a2f8f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: transition-plan-201404.pdf
Type: application/pdf
Size: 326351 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/dt4/attachments/20150315/eb4a2f8f/transition-plan-201404-0001.pdf>