[SLE Team] [CWG-Stewardship] SLE - Document - following the CWG call yesterday.

[Paul M Kane - CWG]

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 at 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




-------------- next part --------------
A non-text attachment was scrubbed...
Name: IANA Service Level Expectations - AGREED-Rev1-FINAL.pdf
Type: application/pdf
Size: 1227690 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/dt1/attachments/20150910/7d262e51/IANAServiceLevelExpectations-AGREED-Rev1-FINAL-0001.pdf>