[CWG-Stewardship] [SLE Team] SLE update - ICANN seeks to delay SLE Accountability reporting......

[Gomes, Chuck]

I want to thank David for the very thorough response that I think provides some essential clarity on this discussion. 

We have been debating whether the SLEs should be implemented before or after the transition.  The following statement from David seems to clarify that in my mind: ". . . we did NOT commit to a timeframe in which the development would be done (other than before the transition)." (David - please correct me if I misinterpreted this.)

It seems to me that the gap in understanding relates to the January target date versus a March/April date.  I also was not a party to any of the discussions on this, but it appears to me that a March/April date may be fine because I think we are now looking at a September 2016 transition date.  Am I missing something here?

On a minor point, I am not sure that RZM refers to Root Zone Maintainer.  RZM is sometimes used to refer to Root Zone Manager or Root Zone Management.

Chuck

-----Original Message-----
From: cwg-stewardship-bounces at icann.org [mailto:cwg-stewardship-bounces at icann.org] On Behalf Of David Conrad
Sent: Tuesday, October 13, 2015 9:10 PM
To: Paul M Kane - CWG; cwg-stewardship at icann.org
Cc: dt1 at icann.org
Subject: Re: [CWG-Stewardship] [SLE Team] SLE update - ICANN seeks to delay SLE Accountability reporting......

Paul,

On 10/13/15, 11:31 AM, "dt1-bounces at icann.org on behalf of Paul M Kane - CWG" <dt1-bounces at icann.org on behalf of paul.kane-cwg at icb.co.uk> wrote:
> The test phase is scheduled to start 1st January 2016.

I am unaware of any commitment by my development team to a "1st January 2016" start date for SLE data collection. If you believe ICANN staff have made such a commitment, I'd very much appreciate a pointer to the recording, transcript, email, or other documentary evidence.  My recollection was that ICANN staff went on record to repeatedly state that we can NOT make any commitment about when we would deliver the code until we had a chance to actually scope the development necessary.

We have done a preliminary scoping of the work involved in revising the existing Root Zone Management System.  Based on that scoping, we feel confident deploying the revised code by the beginning of 2Q2016. This provides for up to 6 months of data collection for the establishment of the actual contractual SLAs.  If you do not believe this sufficient time, perhaps you could explain why you believe additional time will be necessary?

> I attended a meeting in Brussels on Wednesday and met with Elise 
> Gerish, IANA Manager who told me that ICANN does not have the 
> resources to identify their current RZM processes in terms of time taken for the SLE.

Not being party to that particular meeting, I suspect confusion here.
ICANN does, of course, have the resources to identify Root Zone Management System processes for the purposes of establishing the SLEs. As stated during many conversations with the SLE Working Group and/or sub-team,  the granularity to which the SLE Working Group has required metrics to be collected goes beyond the detail that is logged today.  As such we have to insert new code into the existing RZMS code base and make sure we don¹t break anything when we do so.

We cannot, of course, comment on current Root Zone Maintainer (RZM), that is, Verisign processes -- I'll presume this to be a typo.

> Consequently, they are proposing to delay the testing of the naming 
> community's reporting requirements until after March/April 2016.

As I stated repeatedly on the SLE Working Group calls, there are a number of changes that are required to the RZMS software in order to support operation without NTIA in a way that can be verified to not impact the security and stability of changes to the root zone. Implementation of the various code points within the RZMS software to support the SLEs is one component of those changes. There are also changes to support the removal of NTIA from their authorization role as well as changes to the interfaces between the front end and the back end of the RZMS software to facilitate the parallel testing necessary to ensure we are not breaking anything.
This is not a "delay" since we did NOT commit to a timeframe in which the development would be done (other than before the transition).

> This
> was news to me and I assume/hope it would be unreasonable to deduce 
> that ICANN are delaying to potentially seize control of the IANA RZM 
> (from NTIA's oversight) without having to adhere to the operational 
> SLE standards agreed with the community.

It would indeed be unreasonable to make such a deduction, particularly given the repeated assertions from members of the SLE Working Group "no SLEs, no transition."  In fact I might even call such a deduction offensive given the efforts ICANN staff have expended on this particular topic.

> A while back, I spoke with the contractor who wrote the IANA RZM 
> system and he said most of the data is already captured, it is just 
> that ICANN wanted the data extraction tools disabled.

Could you clarify to whom you have spoken?  This is both simply incorrect and suggests malfeasance on the part of ICANN staff and I would like to understand from that individual directly why they believe this, particularly given the contractor who was part of the team that initially did the work with us (nearly a decade ago) was a she, not a he.

> Having an effective
> transaction log of each process step is a fundamental part of 
> Information Security Management (ISO/IEC 27001)- and is basic good 
> practice - and it should not be a complicated task to generate the SLE 
> reports from the transaction logs.

As mentioned previously, the granularity to which the SLE Working Group has required metrics to be collected goes beyond the detail that is logged within our transactions logs. For example, the SLEs require the RZMS code to keep track of "Time for authorization contacts to be asked to approve change request after completing previous process phase".  Since there is literally nothing that occurs between the point in time at which the previous process phase has completed and sending the approval request, we're going to have to insert code and new logging statements to allow us to meet the SLE Working Group requirements even though the time measured for this SLE will likely be in the nanoseconds since it does not involve any human interaction nor branching logic. There are a number of these types of metrics that the SLE Working Group decided were necessary and as a result, there is a number of code modifications that need to be made and tested before we can put the code into production.

> It is essential that at the time of transition we have a 
> tried/tested/proven SLE standard in place so ICANN is accountable to 
> our naming community.

Indeed, but that is not what the SLE Working Group has demanded.  The SLE Working Group demanded a new set of metrics from those that NTIA had defined and which had been tried/tested/proven.  In keeping with that demand, ICANN staff has now undertaken to modify the RZMS code.  The inclusion of new code into the RZMS software requires us to do extensive testing. It would be quite unfortunate if due to a rush to deploy code that measures ICANN's performance, we break root management.

> Can I encourage every member of the CWG (and ICG) to invite ICANN to 
> engage the necessary resources to enable the SLE accountability 
> reporting mechanisms from the 1st January 2016 on their test (post 
> NTIA) RZM platform

To quote Fredrick Brooks:

"The bearing of a child takes nine months, no matter how many women are assigned."
-- Fredrick Brooks, Mythical Man-Month, pg. 17

Pragmatically speaking, the issue is that in order to implement the SLEs, a fairly in-depth knowledge of the underlying RZMS code base is required.
If we were to attempt to throw new additional resources at implementing the SLEs within the timeframe you assert (approximately 9 work _weeks_ from today), it would require time to find those resources and bring them up to speed on the code base.  Bringing those resources up to speed would, of course, impact the productivity of those who already know the code base, resulting in delays.  Further, since people new to the code base would likely make mistakes, additional testing and debugging would necessitate even more delays.

> ...... as they are doing for the other IANA customers (numbers and 
>protocols)?

I'm sorry, what?  As far as I understand, the SLAs for the numbers community are still being discussed with people at the RIRs and I'm unaware of any discussions relating to the routine updating of the SLAs with the IETF (which last I heard for this go around, didn't involve any code development and certainly not code that is critical to the management of the root zone of the DNS). Why would you assert we are doing something for either of those communities by 1 January 2016?

Regards,
-drc