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

[Seun Ojedeji]

Ah okay I guess I should have gone through the entire thread. David's
detailed response seem to clarify a lot.

That said, perhaps it will be good to establish a specific staff contact
for different issues just so everyone is in sync as I sense some
communication issues in David's mail.

Thanks

Sent from my Asus Zenfone2
Kindly excuse brevity and typos.
On 14 Oct 2015 02:11, "David Conrad" <david.conrad at icann.org> wrote:

> 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
>
> _______________________________________________
> CWG-Stewardship mailing list
> CWG-Stewardship at icann.org
> https://mm.icann.org/mailman/listinfo/cwg-stewardship
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20151014/de26cf8f/attachment.html>