[CWG-Stewardship] Statement from the SLE Design Team

Gomes, Chuck cgomes at verisign.com
Tue Jun 9 16:58:19 UTC 2015


Thanks Martin for the added clarifications.

Chuck

-----Original Message-----
From: Martin Boyle [mailto:Martin.Boyle at nominet.org.uk] 
Sent: Tuesday, June 09, 2015 12:50 PM
To: Gomes, Chuck; Paul M Kane - CWG; cwg-stewardship at icann.org
Cc: dt1 at icann.org
Subject: RE: [CWG-Stewardship] Statement from the SLE Design Team

Chuck,

Just little clarifications below!

Martin
-----Original Message-----
From: Gomes, Chuck [mailto:cgomes at verisign.com] 
Sent: 09 June 2015 17:00
To: Martin Boyle; Paul M Kane - CWG; cwg-stewardship at icann.org
Cc: dt1 at icann.org
Subject: RE: [CWG-Stewardship] Statement from the SLE Design Team

Martin,

Please see my responses below.

Chuck

-----Original Message-----
From: cwg-stewardship-bounces at icann.org [mailto:cwg-stewardship-bounces at icann.org] On Behalf Of Martin Boyle
Sent: Tuesday, June 09, 2015 7:25 AM
To: Paul M Kane - CWG; cwg-stewardship at icann.org
Cc: dt1 at icann.org
Subject: Re: [CWG-Stewardship] Statement from the SLE Design Team

Hi Paul,

Thank you and DT-A for your resolute work,

As I read it the paper is still work in progress, but the way it is written leads towards some rational way of defining SLEs, which I welcome.  It would be good to see resolution in time for inclusion in the ICG proposal for consultation which (we hope) should go out at the start of August, so it would need to be clear of the CWG a week or two before.

Turning to the document, I would have concerns about the way times are calculated - if the IANA functions operator is waiting for a response, the clock should be stopped from the request for information until the information is provided by the registry (or whoever else!).
[Chuck Gomes] I agree with you but think that this is already covered.  Note the first principle in the statement: " Attributable measures. Unless clearly impractical, individual metrics should be reported attributing time taken to the party responsible. For example, time spent by IANA staff processing a change request should be accounted for distinctly from time spent waiting for customer action during a change request."

[MB]	I was reacting to the process which includes both.  I'm fine on the principles, but want to be sure that principles make it into practice.


The last paragraph leaches over into escalation which, as you note, has been worked on in DT-C (and also DT-M).  

"Any future breach of service expectations" is very strong.  This is part of my concern about setting arbitrarily high SLEs:  if there is no leeway, the operator will need to resource to meet worst-case scenarios to provide the service, with knock-on impact on those who are paying for the IANA service - the registries.

DT-C looked at the role of the CSC of at monitoring performance (both overall performance and delivering against targets), seeking explanations for degrading service or failure to meet targets, looking for remedial action to improve the performance and only then moving to escalation if reasonable expectations continue not to be met.

Hence in the last paragraph I would prefer a statement that the CSC would "work with the IANA functions operator to address shortfalls in meeting service expectations or if performance monitoring showed degradation of performance" (rather than the current "contribute to an escalation path for any future breach of service expectations").
[Chuck Gomes] Adding what you suggest seems fine but I wouldn't drop the comment about the escalation path.

[MB]	My point is the confusion of two roles.  CSC is about identifying and pushing for fixing the problems.  If it fails it flags to the GNSO & ccNSO who decide on further action.  The two roles need clear separation and only one is the decision of CSC.



I also have some concerns about the "transactions took longer than a year" statement in the previous section.  These are exceptional circumstances (I'd guess ccTLD redelegation requests) and while it is useful to know the impact on statistics, there is usually good reason for such delay.  Frankly I'd prefer IANA to do a careful job in such cases, rather than jumping a decision because they have a deadline to meet.  As I flag above, it is a case where explanations of the delay are sufficient to flag a reasonable exception.
[Chuck Gomes] I read those statistics just as you say, i.e., as exceptions that were worked carefully.  Do you think that needs to be made clearer?

[MB]	Yes please!



So I'm ok with your approach, but would like to see some response to the concerns I flag above.



Martin



-----Original Message-----
From: cwg-stewardship-bounces at icann.org [mailto:cwg-stewardship-bounces at icann.org] On Behalf Of Paul M Kane - CWG
Sent: 09 June 2015 07:30
To: cwg-stewardship at icann.org
Cc: dt1 at icann.org
Subject: [CWG-Stewardship] Statement from the SLE Design Team

Dear members of the CWG

The SLE Design Team had a productive call with ICANN/IANA last night and the attached statement was agreed.

We would like to move that the attached statement is included in the CWG Proposal which should also include two URLs - one to show our past work and the second URL to show the SLE document under development.

The second proposal for the CWG consideration is confirmation from the CWG that the Design Team and IANA are authorised to continue working together past the submission of the proposal to the ICG.  
It may need to be a specific recommendation from the CWG to the ICG  that the SLE Design Team continues its work.
This proposal need to be agreed with the ICG as we are unsure when the CWG will cease to have any authority to develop the transition proposal.

I will be on the CWG call today from approximately 17-30 UTC - apologies for being late - existing day job commitments.

Kind regards

Paul




_______________________________________________
CWG-Stewardship mailing list
CWG-Stewardship at icann.org
https://mm.icann.org/mailman/listinfo/cwg-stewardship


More information about the CWG-Stewardship mailing list