[CWG-Stewardship] update on DT X Separation Process

Mon May 18 12:13:09 UTC 2015

+1 on the use of IFRT since the way i understand it, separation process
only kicks in after IFRT has determined and recommended to ICANN board the
in-ability to continue with PTI as the IFO.

That said, i don't get the rationale behind making IFRT to be largely
composed of ccTLD and gTLD registries. My understanding is that IFRT is
supposed to be MS based and so there should be some balance and its also
supposed to be a small as much as possible. I don't think we need more
registry representation within IFRT before it can determine that CSC's
(which is largely registries) report warrant calling for an RFP or
otherwise. We need to ensure that IFRT is truly MS in nature!

Regards

On Mon, May 18, 2015 at 12:39 PM, Gomes, Chuck <cgomes at verisign.com> wrote:

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

-- 
------------------------------------------------------------------------

*Seun Ojedeji,Federal University Oye-Ekitiweb:      http://www.fuoye.edu.ng
<http://www.fuoye.edu.ng> Mobile: +2348035233535**alt email:
<http://goog_1872880453>seun.ojedeji at fuoye.edu.ng
<seun.ojedeji at fuoye.edu.ng>*

The key to understanding is humility - my view !
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150518/32accf17/attachment-0001.html>