Martin Thank you for your comments and please remember this is a technical process/performance document NOT a policy document. I think your comments can be addressed by "friendly amendments" - and I attach an updated document which should be helpful and not deviate too much from the WG/ICANN/IANA agreed text. Quoting Martin Boyle <Martin.Boyle@nominet.org.uk>:
Hi all,
At our last call I raised a number of concerns that I had with the draft. I am afraid that these remain in place in the draft we are discussing this evening.
My issues are:
1. We have not discussed the process by which the recommendations from the IANA functions operator are checked and approved.
Currently this is a role that is entirely within the IANA functions operator - the IANA team provides a report to the ICANN Board which checks to see whether due process has been followed and that the relevant tests have been documented and explained. This is an internal review now.
Who should carry out what is essentially a check that the IANA team has carried out its work correctly? I'd be inclined to say the PTI Board (as the body *directly* responsible for the IANA functions operation): it has ICANN appointed directors - one of these could ensure that ICANN's interests are properly represented. It could be argued that this should remain with the ICANN Board, but that would give have split responsibilities, which is messy. It also puts the decision into the policy-authority's role, so there will need to be caution about the separation of policy and operation.
This is a Policy issue not in the scope of the SLE WG.
2. There is an introduction of independent verification parties and third party review.
Not introduction, just capturing the current process - but you are right there is some ambiguity ..... to recap.... Today IANA receives the request, checks it, processes it and seeks verification from the requesting registry (who is frequently not contracted with ICANN). For contracted parties ICANN may make a determination based on the terms of the contract with the TLD Registry. So to address your point and remove any ambiguity the term "relevant" may be more appropriate than "independent" so it reads: (e.g. by ICANN Board of Directors or other relevant verification parties)
Given our decision to avoid duplicating the NTIA authorisation role to avoid setting new gatekeepers, I do not welcome the introduction of an independent verification party and there certainly needs to be clear accountability for that entity. While I understand that an ICANN Board decision process could be seen as a third party decision, I would like us to introduce clarity in what we expect - in this case the choice between PTI and ICANN Boards having the role of ticking off the change proposal.
3. Emergency transaction times
This is, I believe, included in the ICANN-NTIA contract. I still do not understand why this does not appear in the tables and I do not want it to be lost when the templates are completed.
(Fortunately) There are not enough emergency situations to be able to ascertain appropriate performance - so the Emergency updates is a place holder for the CSC to be empowered to provide the thresholds as and when sufficient data is available (post transition). If it helps emphasise the importance of subsequent review - it would probably help to remove the prefix title :"Note" to enhance the importance of the Emergency target - but it is just that, a target. In the majority of instances the emergency update is completed well within the 12 hour target time window. To that end, I attache an updated version capturing the above points.... Best Paul