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

Paul M Kane - CWG paul.kane-cwg at icb.co.uk
Thu Sep 10 15:33:00 UTC 2015


Thanks - I have just been told I missed a change "independent" to "relevant" on
Page 23.  So this version  - Final Rev1a (attached) is the document for CWG this
evening.

Best

Paul

Quoting Paul M Kane - CWG <paul.kane-cwg at icb.co.uk>:

> 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-FINALa.pdf
Type: application/pdf
Size: 1227619 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/dt1/attachments/20150910/84e92746/IANAServiceLevelExpectations-AGREED-Rev1-FINALa-0001.pdf>


More information about the dt1 mailing list