[DTL] Deficiencies in Plan for Transition to Successor Contractor

[CW Lists]

Dear Guru:

I have a few comments on the points that you have mentioned, below.
Please see attached .pdf

Regards

Christopher




On 15 Mar 2015, at 09:48, Guru Acharya <gurcharya at gmail.com> wrote:

> 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:
> 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.
> 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.
> 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.
> 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.
> 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.
> 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.
> 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.
> 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.
> 
> 
> <transition-plan-201404.pdf>_______________________________________________
> dt4 mailing list
> dt4 at icann.org
> https://mm.icann.org/mailman/listinfo/dt4

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/dt4/attachments/20150316/3d5c8431/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CW_DT4-responses1.pdf
Type: application/pdf
Size: 85878 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/dt4/attachments/20150316/3d5c8431/CW_DT4-responses1-0001.pdf>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/dt4/attachments/20150316/3d5c8431/attachment-0003.html>