<p dir="ltr">Hi,</p>
<p dir="ltr">I tend to agree with Andrew on this. I think the other communities for instance have submitted their proposal while still working on their SLA/SLE. Since there is a time factor here, I don&#39;t think anything would prevent us from including principles of the SLE in the proposal (for presentation in BA and ultimate submission to ICG), while development of SLE continues. We may even reflect the current SLE afterall we all found it to have worked well just that we are looking for something better which is fine and can be achieved later.</p>
<p dir="ltr">That said, I have no idea what may have been the reason for the delay from staff but my guess is that it may have something to do with existing agreements.</p>
<p dir="ltr">Regards</p>
<p dir="ltr">sent from Google nexus 4<br>
kindly excuse brevity and typos.</p>
<div class="gmail_quot&lt;blockquote class=" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, May 20, 2015 at 10:42:25AM +1200, Jordan Carter wrote:<br>
<br>
&gt; So - DT-A is late because of ICANN&#39;s delays.<br>
<br>
If you are serious about agile ways of operation, then that&#39;s one of<br>
the facts that sometimes gets you: not everything is under your<br>
control.  But anyway,<br>
<br>
&gt; And therefore the IANA customers should agree an SLA/SLE framework that is<br>
&gt; far inferior to current performance?<br>
<br>
No, as you&#39;ll note, I pointed out that IANA customers can later agree<br>
to change such a framework precisely because we&#39;re supposed to be able<br>
to do that sort of thing when we&#39;re done.  There are all these<br>
accountability mechanisms that permit it.  If you think that&#39;s not<br>
true, you are implicitly admitting that ICANN is not ready for any<br>
transition because it needs grown up supervision to force it to<br>
evolve.  Is that really what you want to say?<br>
<br>
&gt; Why on earth is that a good idea?<br>
<br>
The _actual_ reason it&#39;s a good idea is because you should never, ever<br>
change the thing you&#39;re measuring and the instrument by which you<br>
measure at the same time.  This is such a fundamental tenet of<br>
empiricism that I can scarcely believe we are debating it.  I do not<br>
dispute that the existing SLAs are vastly exceeded all the time or<br>
that they&#39;re probably too generous given modern operations.  But today<br>
there are well-established levels of service, and there is a long<br>
history of being able to measure &quot;IANA came within [+|-] n% of its<br>
agreed SLA over $period&quot;.  That is a time series that we have.<br>
<br>
That time series is what we ought to be able to compare with after the<br>
transition.  If the graph changes in appreciable ways -- ways you can<br>
see _just by looking_ today -- then there is either a problem, or<br>
proof that the transition is yielding benefits.  If it changes not at<br>
all, that will be an indication that the transition yielded stability.<br>
<br>
That is the reason in my opinion we shouldn&#39;t change this now.  That<br>
is also, in my opinion, the reason we shouldn&#39;t mourn the fact that<br>
DT-A can&#39;t possibly complete in time to make changes here in time for<br>
the BA meeting, on which more below.<br>
<br>
&gt; ICANN&#39;s delays have consequences for this process and they are real ones.<br>
<br>
Yes.  And the fact that CWG-Stewardship has delivered everything so<br>
late, and the fact that the ICANN meeting dates are set long in<br>
advance, and the fact that it took ages to get legal counsel, and the<br>
fact that the DTs were supposed to deliver in a week or two but took a<br>
month even to agree to, and everything else has consequences for this<br>
process.  That&#39;s the harsh fact about having to deliver a real result<br>
in a world constrained by outside actors.<br>
<br>
I have no objection to CWG noting that DT-A might have had a proposal<br>
ready but for egregious delays by ICANN.  I have no objection to<br>
people standing up in public fora, or putting a big note in the<br>
introduction, or so on, and saying that there are parts of ICANN that<br>
seemed to be obstructing the process.  But I think it is just folly to<br>
suppose that anything written after 26 May is actually going to be<br>
properly reviewed and ready for people to be able to read a document<br>
before the BA meeting.  As it is, the CWG plan is to give people very<br>
little time.  It would be irresponsible to allow things to go later.<br>
<br>
Several of my colleagues in the other communities knew that I was at<br>
least to the extent I was able participating in the CWG after<br>
Singapore, and I found myself able to make only a weak defence of the<br>
fact that the CWG put out for public comment a proposal that was _in<br>
its own admission_ full of gaps.  There will not be such a chance for<br>
defence at BA: if this thing isn&#39;t sewn up and complete, it will<br>
simply be laughed at.  That means that anything not absolutely<br>
critical by 26 May (or, IMO, yesterday or maybe last week)<br>
needs to be cut.<br>
<br>
Best regards,<br>
<br>
A<br>
<br>
--<br>
--<br>
Andrew Sullivan<br>
<a href="mailto:ajs@anvilwalrusden.com">ajs@anvilwalrusden.com</a><br>
Awkward access to mail.  Please forgive formatting problems.<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" target="_blank">https://mm.icann.org/mailman/listinfo/cwg-stewardship</a><br>
</div>