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

[David Conrad]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4673 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/dt1/attachments/20151014/6d341cdf/smime.p7s>