<p dir="ltr">Ah okay I guess I should have gone through the entire thread. David's detailed response seem to clarify a lot.</p>
<p dir="ltr">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.</p>
<p dir="ltr">Thanks</p>
<p dir="ltr">Sent from my Asus Zenfone2<br>
Kindly excuse brevity and typos.</p>
<div class="gmail_quote">On 14 Oct 2015 02:11, "David Conrad" <<a href="mailto:david.conrad@icann.org">david.conrad@icann.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Paul,<br>
<br>
On 10/13/15, 11:31 AM, "<a href="mailto:dt1-bounces@icann.org">dt1-bounces@icann.org</a> on behalf of Paul M Kane -<br>
CWG" <<a href="mailto:dt1-bounces@icann.org">dt1-bounces@icann.org</a> on behalf of <a href="mailto:paul.kane-cwg@icb.co.uk">paul.kane-cwg@icb.co.uk</a>> wrote:<br>
> The test phase is scheduled to start 1st January 2016.<br>
<br>
I am unaware of any commitment by my development team to a "1st January<br>
2016" start date for SLE data collection. If you believe ICANN staff have<br>
made such a commitment, I'd very much appreciate a pointer to the<br>
recording, transcript, email, or other documentary evidence. My<br>
recollection was that ICANN staff went on record to repeatedly state that<br>
we can NOT make any commitment about when we would deliver the code until<br>
we had a chance to actually scope the development necessary.<br>
<br>
We have done a preliminary scoping of the work involved in revising the<br>
existing Root Zone Management System. Based on that scoping, we feel<br>
confident deploying the revised code by the beginning of 2Q2016. This<br>
provides for up to 6 months of data collection for the establishment of<br>
the actual contractual SLAs. If you do not believe this sufficient time,<br>
perhaps you could explain why you believe additional time will be<br>
necessary?<br>
<br>
> I attended a meeting in Brussels on Wednesday and met with Elise Gerish,<br>
> IANA Manager who told me that ICANN does not have the resources to<br>
> identify their current RZM processes in terms of time taken for the SLE.<br>
<br>
Not being party to that particular meeting, I suspect confusion here.<br>
ICANN does, of course, have the resources to identify Root Zone Management<br>
System processes for the purposes of establishing the SLEs. As stated<br>
during many conversations with the SLE Working Group and/or sub-team, the<br>
granularity to which the SLE Working Group has required metrics to be<br>
collected goes beyond the detail that is logged today. As such we have to<br>
insert new code into the existing RZMS code base and make sure we don¹t<br>
break anything when we do so.<br>
<br>
We cannot, of course, comment on current Root Zone Maintainer (RZM), that<br>
is, Verisign processes -- I'll presume this to be a typo.<br>
<br>
> Consequently, they are proposing to delay the testing of the naming<br>
> community's reporting requirements until after March/April 2016.<br>
<br>
As I stated repeatedly on the SLE Working Group calls, there are a number<br>
of changes that are required to the RZMS software in order to support<br>
operation without NTIA in a way that can be verified to not impact the<br>
security and stability of changes to the root zone. Implementation of the<br>
various code points within the RZMS software to support the SLEs is one<br>
component of those changes. There are also changes to support the removal<br>
of NTIA from their authorization role as well as changes to the interfaces<br>
between the front end and the back end of the RZMS software to facilitate<br>
the parallel testing necessary to ensure we are not breaking anything.<br>
This is not a "delay" since we did NOT commit to a timeframe in which the<br>
development would be done (other than before the transition).<br>
<br>
> This<br>
> was news to me and I assume/hope it would be unreasonable to deduce that<br>
> ICANN are delaying to potentially seize control of the IANA RZM (from<br>
> NTIA's oversight) without having to adhere to the operational SLE<br>
> standards agreed with the community.<br>
<br>
It would indeed be unreasonable to make such a deduction, particularly<br>
given the repeated assertions from members of the SLE Working Group "no<br>
SLEs, no transition." In fact I might even call such a deduction<br>
offensive given the efforts ICANN staff have expended on this particular<br>
topic.<br>
<br>
> A while back, I spoke with the contractor who wrote the IANA RZM system<br>
> and he said most of the data is already captured, it is just that ICANN<br>
> wanted the data extraction tools disabled.<br>
<br>
Could you clarify to whom you have spoken? This is both simply incorrect<br>
and suggests malfeasance on the part of ICANN staff and I would like to<br>
understand from that individual directly why they believe this,<br>
particularly given the contractor who was part of the team that initially<br>
did the work with us (nearly a decade ago) was a she, not a he.<br>
<br>
> Having an effective<br>
> transaction log of each process step is a fundamental part of<br>
> Information Security Management (ISO/IEC 27001)- and is basic good<br>
> practice - and it should not be a complicated task to generate the SLE<br>
> reports from the transaction logs.<br>
<br>
As mentioned previously, the granularity to which the SLE Working Group<br>
has required metrics to be collected goes beyond the detail that is logged<br>
within our transactions logs. For example, the SLEs require the RZMS code<br>
to keep track of "Time for authorization contacts to be asked to approve<br>
change request after completing previous process phase". Since there is<br>
literally nothing that occurs between the point in time at which the<br>
previous process phase has completed and sending the approval request,<br>
we're going to have to insert code and new logging statements to allow us<br>
to meet the SLE Working Group requirements even though the time measured<br>
for this SLE will likely be in the nanoseconds since it does not involve<br>
any human interaction nor branching logic. There are a number of these<br>
types of metrics that the SLE Working Group decided were necessary and as<br>
a result, there is a number of code modifications that need to be made and<br>
tested before we can put the code into production.<br>
<br>
> It is essential that at the time of transition we have a<br>
> tried/tested/proven SLE standard in place so ICANN is accountable to our<br>
> naming community.<br>
<br>
Indeed, but that is not what the SLE Working Group has demanded. The SLE<br>
Working Group demanded a new set of metrics from those that NTIA had<br>
defined and which had been tried/tested/proven. In keeping with that<br>
demand, ICANN staff has now undertaken to modify the RZMS code. The<br>
inclusion of new code into the RZMS software requires us to do extensive<br>
testing. It would be quite unfortunate if due to a rush to deploy code<br>
that measures ICANN's performance, we break root management.<br>
<br>
> Can I encourage every member of the CWG (and ICG) to invite ICANN to<br>
> engage the necessary resources to enable the SLE accountability<br>
> reporting mechanisms from the 1st January 2016 on their test (post NTIA)<br>
> RZM platform<br>
<br>
To quote Fredrick Brooks:<br>
<br>
"The bearing of a child takes nine months, no matter how many women are<br>
assigned."<br>
-- Fredrick Brooks, Mythical Man-Month, pg. 17<br>
<br>
Pragmatically speaking, the issue is that in order to implement the SLEs,<br>
a fairly in-depth knowledge of the underlying RZMS code base is required.<br>
If we were to attempt to throw new additional resources at implementing<br>
the SLEs within the timeframe you assert (approximately 9 work _weeks_<br>
from today), it would require time to find those resources and bring them<br>
up to speed on the code base. Bringing those resources up to speed would,<br>
of course, impact the productivity of those who already know the code<br>
base, resulting in delays. Further, since people new to the code base<br>
would likely make mistakes, additional testing and debugging would<br>
necessitate even more delays.<br>
<br>
> ...... as they are doing for the other IANA customers (numbers and<br>
>protocols)?<br>
<br>
I'm sorry, what? As far as I understand, the SLAs for the numbers<br>
community are still being discussed with people at the RIRs and I'm<br>
unaware of any discussions relating to the routine updating of the SLAs<br>
with the IETF (which last I heard for this go around, didn't involve any<br>
code development and certainly not code that is critical to the management<br>
of the root zone of the DNS). Why would you assert we are doing something<br>
for either of those communities by 1 January 2016?<br>
<br>
Regards,<br>
-drc<br>
<br>_______________________________________________<br>
CWG-Stewardship mailing list<br>
<a href="mailto:CWG-Stewardship@icann.org">CWG-Stewardship@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/cwg-stewardship" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/listinfo/cwg-stewardship</a><br>
<br></blockquote></div>