On Wed, May 20, 2015 at 10:42:25AM +1200, Jordan Carter wrote:
So - DT-A is late because of ICANN's delays.
If you are serious about agile ways of operation, then that's one of the facts that sometimes gets you: not everything is under your control. But anyway,
And therefore the IANA customers should agree an SLA/SLE framework that is far inferior to current performance?
No, as you'll note, I pointed out that IANA customers can later agree to change such a framework precisely because we're supposed to be able to do that sort of thing when we're done. There are all these accountability mechanisms that permit it. If you think that's not true, you are implicitly admitting that ICANN is not ready for any transition because it needs grown up supervision to force it to evolve. Is that really what you want to say?
Why on earth is that a good idea?
The _actual_ reason it's a good idea is because you should never, ever change the thing you're measuring and the instrument by which you measure at the same time. This is such a fundamental tenet of empiricism that I can scarcely believe we are debating it. I do not dispute that the existing SLAs are vastly exceeded all the time or that they're probably too generous given modern operations. But today there are well-established levels of service, and there is a long history of being able to measure "IANA came within [+|-] n% of its agreed SLA over $period". That is a time series that we have. That time series is what we ought to be able to compare with after the transition. If the graph changes in appreciable ways -- ways you can see _just by looking_ today -- then there is either a problem, or proof that the transition is yielding benefits. If it changes not at all, that will be an indication that the transition yielded stability. That is the reason in my opinion we shouldn't change this now. That is also, in my opinion, the reason we shouldn't mourn the fact that DT-A can't possibly complete in time to make changes here in time for the BA meeting, on which more below.
ICANN's delays have consequences for this process and they are real ones.
Yes. And the fact that CWG-Stewardship has delivered everything so late, and the fact that the ICANN meeting dates are set long in advance, and the fact that it took ages to get legal counsel, and the fact that the DTs were supposed to deliver in a week or two but took a month even to agree to, and everything else has consequences for this process. That's the harsh fact about having to deliver a real result in a world constrained by outside actors. I have no objection to CWG noting that DT-A might have had a proposal ready but for egregious delays by ICANN. I have no objection to people standing up in public fora, or putting a big note in the introduction, or so on, and saying that there are parts of ICANN that seemed to be obstructing the process. But I think it is just folly to suppose that anything written after 26 May is actually going to be properly reviewed and ready for people to be able to read a document before the BA meeting. As it is, the CWG plan is to give people very little time. It would be irresponsible to allow things to go later. Several of my colleagues in the other communities knew that I was at least to the extent I was able participating in the CWG after Singapore, and I found myself able to make only a weak defence of the fact that the CWG put out for public comment a proposal that was _in its own admission_ full of gaps. There will not be such a chance for defence at BA: if this thing isn't sewn up and complete, it will simply be laughed at. That means that anything not absolutely critical by 26 May (or, IMO, yesterday or maybe last week) needs to be cut. Best regards, A -- -- Andrew Sullivan ajs@anvilwalrusden.com Awkward access to mail. Please forgive formatting problems.