[CWG-Stewardship] update on DT X Separation Process

Gomes, Chuck cgomes at verisign.com
Mon May 18 12:03:09 UTC 2015


Definitely not Martin.  I do not support a permanent entity; it should only be convened as needed and it should be clearly defined in advance so that it doesn't take too much time to convene.  If a separation review is needed, it would be covered under the provision for a Special Review in contrast to the periodic reviews.

Chuck

-----Original Message-----
From: Martin Boyle [mailto:Martin.Boyle at nominet.org.uk] 
Sent: Monday, May 18, 2015 7:48 AM
To: Gomes, Chuck; avri at acm.org; cwg-stewardship at icann.org
Subject: RE: [CWG-Stewardship] update on DT X Separation Process

Chuck,

Are you suggesting that we have a standing review team for the IANA functions?  I thought we'd agreed that it would be convened for the review (regular or special), rather than becoming a permanent entity (but then I might have missed something).

Martin



-----Original Message-----
From: Gomes, Chuck [mailto:cgomes at verisign.com]
Sent: 18 May 2015 12:40
To: Martin Boyle; avri at acm.org; cwg-stewardship at icann.org
Subject: RE: [CWG-Stewardship] update on DT X Separation Process

I sincerely appreciate all of the thought and discussion that has been happening on this over the last several days.  Personally I am thinking that the best way to do a separation review would be to use the IFRT rather than creating a new review team with all the complexities and time that would introduce.  I think though that the IFRT would need to include a larger (although not majority) presence of ccTLD and gTLD registries so that there is strong involvement of those who would be directly impacted by a separation while at the same time ensuring broad community participation.

Chuck

-----Original Message-----
From: cwg-stewardship-bounces at icann.org [mailto:cwg-stewardship-bounces at icann.org] On Behalf Of Martin Boyle
Sent: Monday, May 18, 2015 6:29 AM
To: avri at acm.org; cwg-stewardship at icann.org
Subject: Re: [CWG-Stewardship] update on DT X Separation Process

Thanks Avri, this is a good summary.  My comments are in line below: 


> 1. i do not believe that the same group that recommends a so-called nuclear process is the one to execute that process.  It is a checks and balances sort of thing.  You do not give yourself a task of this magnitude.

Nuclear option or not (I take it as a significant change - and one that will have an impact on ICANN), the most important element is on the checks and balances.  So I agree with Avri on the need for a different group for the process.


> 2. I see taking a further step in the separation process as needing the same sort of full community review and support that transition requires.  This is being defined as an extraordinary event , not a regualr event in the current formulaton.

I'm less sure of a separate community-review step:  if we have not managed to get this into the IFR step, then we need to.  In my mind, the IFR recommendation itself should already have gone out to consultation and the decision to move should have been endorsed by the ccNSO and the RySG.  The next step is then endorsing that decision, to agree and adopt the IFR recommendation.  The decision to separate should be a community decision with a customer buy in, but that should be the final part of the IFR process.

This should then be followed by a process for developing the RfP (not a trivial task) and one which needs to be based on customer requirements - I agree with Milton's assertions that the re-bid is of a service level contract (although I'm not convinced that there are enough independent experts out there with any realistic idea of how to run the IANA functions operator to make any correlation to changing an ISP a fair one).  So the RfP needs to be based on clear requirements on SLAs/SLEs and on independence of the operator, its technical skills, ability and resources.  We also 


> 3. I believe that those who review and accept this transition proposal 
> should be able to have the assurance that the ground is not going to 
> easily slip under them.  If we make it too easy to go to RFP or spin 
> out of the PTI, they could be forgiven for insecurity about our 
> proposal

In the case of a (clear and supported) decision being made on the IFR recommendations, the RfP step does need to be engaged fairly quickly.  If there are doubts about the well-found nature of the recommendation (for example, it failed to take account of key factors or was based on criteria that were not part of the agreed contract), those should come out in the adoption process via community comments.


> That is why I beleive it is not Over-bureaucratization of this process but rather giving a serious issue the proper full community  due consideration.

I think the key thing is on endorsement (or rejection) by the community of the IFR recommendation.  I'm not sure that that needs the additional step you propose - once the recommendation is seen to have significant support (particularly at the customer level), it becomes important to reduce the period of uncertainty.


Martin


On 15-May-15 11:26, Milton L Mueller wrote:
> Avri:
> I support your concepts of the possible outcomes but I don't understand why a "separation review" is conceived as a new and independent process from the IFR. I've said this before but there has been no answer. If an IFR indicates that the community is so dissatisfied that separation is a live possibility, it seems that action needs to be taken expeditiously instead of launching another review process. Isn't it possible that this should be more like a choice of a service vendor than something like the ICG/IANA stewardship transition? We are not changing stewardship or high-level institutions, we are changing a functions operator. Over-bureaucratization of this process actually works against accountability by making the costs of a switch so high as to be prohibitive.
>
> May I please have a response to this?
>
> --MM
>
>> -----Original Message-----
>>
>> To relate this to the SR, each would present a different set of 
>> opportunities for SR action, that is why the 5 possibilities in the 
>> SR text are really just examples, an incomplete set in the whole 
>> universe of examples, that the SR mechanism could recmmend.
>>
>> As I mentioned in the call this is my personal reason for thinking 
>> that an SR event, needs to be quite similar to the current Transition event.
>> It would be a big deal that the whole community would need to be 
>> involved in.
>
>


---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com

_______________________________________________
CWG-Stewardship mailing list
CWG-Stewardship at icann.org
https://mm.icann.org/mailman/listinfo/cwg-stewardship
_______________________________________________
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