An update on the work of the SLE group
Apologies for the silence, at a personal level it has been a traumatic three weeks and I am only now (slowly) re-surfacing. Firstly, I would like to thank Kim Davies from IANA, Bernie Turcotte from ICANN and Adam Smith from my staff for the constructive manner in which progress is being made on the SLE document. Adam stepped in with the agreement of DT-A members to keep the momentum during my period of absence as we are all keen to conclude the SLE document. Rest assured that members of DT-A all share a similar vision and are working well together, recognize that the SLE is a keystone document and on the 8th June members of DT-A and IANA/ICANN will have another telephone conference to identify where additional work is needed. Secondly, I'd like to confirm that DTA is _not_ suggesting *any* process "improvements" or "changes". We are capturing the current process, documenting it as best we can and determining the performance matrix for the process. Our focus has been on those Registries that interact with IANA electronically via the RZM service. We hope to be able to provide an SLE document for those Registries that do not use the RZM preferring to send letters or faxes or phone calls to request/authorise changes, and more time will be needed to address this minority IANA user community. We are trying to avoid discriminatory practice but obviously inefficient interactions with IANA does add delay to the process which is not IANA's fault. Third, it is vital that IANA services are delivered to all Registries whether gTLDs or ccTLDs, contracted or non-contracted, on a equal, impartial and efficient basis. To avoid IANA being the subject of claims of expediting the changes of one registry operator in preference to another, DT-A and IANA share the view there should be a distinction between metrics that should be collected to support general analysis, versus those which are the critical metrics that are considered important to set specific thresholds for judging breaches in ICANNs ability to provide an appropriate non-discriminatory level of service. Fourth, there may be those in the community that want a vague SLE that does not follow professional standards for efficient operation. IANA specifically don't want that and have committed to provide attributable metrics for the party responsible for that particular process. DT-A support IANA in this and in post-transition world, without the (perceived) liability protection of the US Government "validating" change requests - there may be parties who seek redress from ICANN/IANA (alleging) non-performance when the problem is outside of IANA's control. Consequently, the SLE seeks to define the process and specific measures against which specific thresholds should be set, with an expectation that the IANA Functions Operator will normally perform within the threshold. Where there is an inability to meet the threshold, it will be identified, resulting in follow-up with the Customer Standing Committee to identify the cause, and whether the issues is within IANA's control. Regular unexplained inability to meet the thresholds may result in remedial action and it is anticipated the thresholds will be modified over time as part of periodic reviews of the service level expectation. For those registries wanting DT-A to define the process for end-to-end automation - an API for interacting with IANA - that is outside the scope of this Design Team and may be addressed post transition. Our goal is to work with IANA to capture a workable SLE that reassures all parties there is no room for discriminatory practice and the broader community can be confident that IANA will continue to deliver exemplary service post transition. I am optimistic there will be a draft released following our next call and DT-A will continue to work with IANA after the 8th June to refine the SLE and incorporate as much of IANA's sub-processes as possible. I hope to be on today's call but I will not have Internet access between the end of the call and our call with IANA on Monday so please do not expect email replies in the intervening period. Best Paul
participants (1)
-
Paul M Kane - CWG