[CRISP-TEAM] URGENT: Continuity of operations

[Izumi Okutani]

Hi Andrei and all,



Thanks for the drafting the suggestion to add them in the CRISP Team's review of the SLA, based on the 21st CRISP Call.



CRISP Team,

Since we are short of business hours to review it before the submission deadline on 14th June to the NRO, I suggest below as the next step.

1. Incorporate this suggestion on the CRISP Team's SLA review and submit to the NRO

   We note:
   - We haven't had sufficient time to hear inputs from everyone on adding these yet.
   - If we receive additional inputs, we will share with the NRO EC by Wed 17th June 23:59 UTC 
    (*I will be flying to BA so would like to request for volunteer*)

2. Open this for comments from the CRISP Team and the ianaxfer list until: Tuesday 16th 23:59 UTC 
   (Give 48h business hours)
 
   We explain:
   - If we receive no concerns until the above timelines, we consider it consensus
   - This is not adding a new point; rather, requesting for more clarity in the SLA in section 8 " Continuity of Operations "
   - We felt this is an important addition to be covered in ensuring continuity of the operation
   - While we have already submitted comments to the NRO EC, we have clarified that;
     We haven't had time to sufficiently hear inputs and will get back to them if we hear further comments


In the meantime, while the comments are open until Tuesday 16th 23:59 UTC, 
I welcome comments from the CRISP Team as much as possible before: the UTC23:59 14th June deadline.

This will allow us to incorporate as much feedback as possible in our submission to the NRO.


Izumi



On 2015/06/12 20:13, Andrei Robachevsky wrote:
> 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
>>>>>>
>>>>
>>