[DTL] Deficiencies in Plan for Transition to Successor Contractor

Tue Mar 17 11:00:07 UTC 2015

Thanks Guru

On 3/17/2015 10:39 AM, Guru Acharya wrote:
> Hi CW,
>
> Appreciate your comments. I tend to agree with most of what you have 
> written.
>
> 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.
Agree.
>
> 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.
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.
> I have read your comments and replied to them in that context. Please 
> correct me if I do so incorrectly.
>
> 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.
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).
>
> 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.
We should discuss with DT on IPR.
>
> 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.
>
> 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.
(Not sure what the flaws might be) but agree that it is key that the 
software can be fully ported to the successor.
>
> 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.
>
> 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.
Agree.

Thanks!

>
> 7) ...
>
>
>
> On Tue, Mar 17, 2015 at 1:00 AM, CW Lists 
> <lists at christopherwilkinson.eu <mailto:lists at christopherwilkinson.eu>> 
> wrote:
>
>     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
>     <mailto: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:
>>
>>      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 <http://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.
>>
>>
>>
>>     <transition-plan-201404.pdf>_______________________________________________
>>     dt4 mailing list
>>     dt4 at icann.org <mailto:dt4 at icann.org>
>>     https://mm.icann.org/mailman/listinfo/dt4
>
>
>
>
>
> _______________________________________________
> 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/20150317/89e04dae/attachment-0001.html>