Paul,
My issue was (see the attached diagram) that the CRISP (numbers community) have their new SLA being tested from January and I would like the naming community to be treated equally with our numbering community colleagues ... hence January 1st.
Simply, you have misinterpreted that diagram. As should be clear in that diagram given the orange blocks _start_ in January, the implementation of the CRISP SLA is scheduled to _start_ on January 1 with completion scheduled in September. In fact, the CWG is not being treated equally, they are getting development priority because we are required to do parallel testing of the code in a particular way that necessitates a 6 month cushion.
It seems to be taking longer to update the RZMS than it did to write it in the first place.
I do not believe hyperbole is helpful here. For the record, due to a variety of factors, most of which were non-technical, it took 2 years to develop RZMS. The changes that are being implemented are being done in a production system in an extremely sensitive environment and we're looking at around 3-4 months of development/testing.
IANA is not a particularly active service and will a 3 month window generate sufficient data?
As stated, we expect to deploy the new code at the beginning of 2Q2016. This would appear to leave (some portion of) April, May, June, July, August, and (some portion of) September for the collection of data. Currently, I'm told IANA is receiving about 100-200 root zone change requests per month. This should supply at least 400 to 800 requests. Of course, it depends on whether some requests are actually made, e.g., the SLA that requires ICANN to measure "Credential recovery time to dispatch confirmation email of forgotten username or password" (another one of those metrics that will be measured in nanoseconds since it measures something that does not require human interaction or code branches), so whether there are enough nanosecond samples depends on how many folks try to recover their passwords. Regards, -drc