[DTL] Deficiencies in Plan for Transition to Successor Contractor

Guru Acharya gurcharya at gmail.com
Tue Mar 17 10:39:03 UTC 2015


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.

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 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.

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.

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.

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.

7) ...



On Tue, Mar 17, 2015 at 1:00 AM, CW Lists <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> 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). 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
> https://mm.icann.org/mailman/listinfo/dt4
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/dt4/attachments/20150317/f44efdfe/attachment.html>


More information about the dt4 mailing list