[CRISP-TEAM] URGENT: Continuity of operations (was: Factors for implementaion which affects the timelines)

[Andrei Robachevsky]

Hi Izumi, all

After talking to my RIPE CRISP colleagues I understand this matter was
discussed on the call and the agreement was to review a possible
amendment to our analysis reflecting this issue.

I propose the following new version of our response in section 8.
Continuity of Operations. I apologize for coming with this suggestion so
close to the deadline for comments.

Please review the text and let us know if we can include it in the
consensus version of our analysis.

A few points:

- The idea is to provide more details and ensure provisions supporting a
contingency plan exist in the SLA (should the operator suddenly cease to
exist) - hence ability to have an ongoing access/backup of essential data.

- The provisions were modeled by the existing ICANN transition plan
produced under the NTIA contract (article C.7.3.). The version I found
is here: https://www.iana.org/reports/2014/transition-plan-201404.pdf,
but there might be a more up to date version.

- Since we are in a situation where the services were successfully
provided by the existing operator for more that 15 years, giving 18
month for producing a transition plan does not make sense. My suggestion
would be to request such plan *prior* to the commencing date of the SLA.

Here we go with the actual text. I also included the next version of our
response, incorporating these changes, redlined:

----BEGIN------

*8. Continuity of Operations*

This principle is addressed by Article 11 “Continuity of operations.”
Since the registry is the cornerstone of the IANA Numbering Services, we
suggest that explicit requirements must be provided regarding the
transfer of registry data and associated data (e.g. audit logs,
correspondence, the state of any as-yet unfulfilled requests).

In particular, the operator should make available to the RIRs on ongoing
basis:

- copies of, or links to, the publicly available text for all processes,
performance standards, request templates and other pages used to support
operations or provide context to reporting.

- a copy of all registry data for Internet Number Resources registries,
including a copies of the IP6.ARPA and IN-ADDR.ARPA zone files.

- a copy of the databases it has used to store requests data, including
ticketing systems and workflow management systems used for Number
Resources registries.

- copies of any published reports and paper records it holds supporting
these request histories.

- any other information necessary for the provision of the IANA
Numbering service

Also, taking into account more than 15 years of experience in providing
the IANA Numbering Services by ICANN it is not unreasonable to request
the Operator to prepare and submit a transition plan to the RIRs
*prior* to the commencing date of the SLA.

-------END------

Andrei



Izumi Okutani wrote on 11/06/15 13:04:
> Hi Andrei, all,
> 
> 
>> The NTIA contract also required that ICANN produces a transition plan.
>> Perhaps this plan could be a good basis for this work.
> 
> I agree this looks like a good starting point.
> 
>> But more importantly we (or the RIRs) should make up their mind if this
>> fallback mechanism is part of the implementation, or not. In the former
>> case the plan should be integrated in the SLA. And for the latter case -
>> this item doesn't seem applicable.
> 
> This would be a good point to confirm.
> I suggest we discuss it at the coming call.
> 
> For those you cannot join, I welcome your input online before and until 24 hours after the call.
> 
> 
> Izumi
> 
> 
> On 2015/06/11 6:45, Andrei Robachevsky wrote:
>> Hi,
>>
>> Izumi Okutani wrote on 10/06/15 17:19:
>> [...]
>>
>>>
>>> Perhaps it would be the best to leave it the RIR staff beyond this point.
>>>
>>
>> I agree.
>>
>> The NTIA contract also required that ICANN produces a transition plan.
>> Perhaps this plan could be a good basis for this work.
>>
>> But more importantly we (or the RIRs) should make up their mind if this
>> fallback mechanism is part of the implementation, or not. In the former
>> case the plan should be integrated in the SLA. And for the latter case -
>> this item doesn't seem applicable.
>>
>>>
>>> Izumi
>>>
>>
>> Andrei
>>
>>>
>>> On 2015/06/10 1:11, Andrei Robachevsky wrote:
>>>> Thank you Izumi,
>>>>
>>>> Izumi Okutani wrote on 09/06/15 16:40:
>>>>> Hi Andrei,
>>>>>
>>>>>
>>>>>> Could you please elaborate what you mean by "fallback mechanism"?
>>>>>
>>>>> Sure, the idea is in case the RIRs have to switch the IANA Function Operator.
>>>>> Basically it is the point Vint Cerf has raised on the ianaxfer list.
>>>>>
>>>>
>>>> Understood.
>>>>
>>>> Looking at this from a formal point of view isn't this what is in
>>>> Article 11 of the SLA "Continuity of operations"? Or do you think this
>>>> work will lead to changes in this article, prescribing specific fallback
>>>> mechanisms?
>>>>
>>>> Andrei
>>>>
>>>>> I can think of be two situation:
>>>>>
>>>>>  1. When RIRs need to switch the IFO as emergency due to serious failure in service level
>>>>>     - Need to switch in a short period of time and there is no gurantee the existing IFO will be able to provide the data needed, within the timeframe needed for the switch
>>>>>     - Steps need to be defined on how to do this as well as identifying the need for data escrow for non-public data
>>>>>
>>>>>  2. When RIRs switch the IFO with advanced notice
>>>>>     - Likely to have time for preparation but need to define steps
>>>>>     - If we are making open RFP, setting the criteria may be another factor in preparing implementation
>>>>>
>>>>>
>>>>> Izumi
>>>>>
>>>>> On 2015/06/09 23:29, Andrei Robachevsky wrote:
>>>>>> Hi Izumi,
>>>>>>
>>>>>> Could you please elaborate what you mean by "fallback mechanism"?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Andrei
>>>>>>
>>>>>> Izumi Okutani wrote on 05/06/15 21:18:
>>>>>>>  d. Fallback mechanism
>>>>>>>    - Identify elements which needs fallback mechanism
>>>>>>>    - Define process
>>>>>>>    - Analyse possible impact
>>>>>>>    - Identify the need of RFP and if needed draft one
>>>>>
>>>
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Review of the SLA-20150612.doc
Type: application/msword
Size: 41984 bytes
Desc: not available
URL: <https://www.nro.net/pipermail/crisp/attachments/20150612/f9e33ce1/ReviewoftheSLA-20150612.doc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Review of the SLA-20150612.pdf
Type: application/pdf
Size: 133483 bytes
Desc: not available
URL: <https://www.nro.net/pipermail/crisp/attachments/20150612/f9e33ce1/ReviewoftheSLA-20150612.pdf>