[CWG-RFP3] Brief comments after Frankfurt

[Martin Boyle]

I’m not sure who would do the approval, given the liability implications.  This is why there needs to be a robust appeals mechanism based on whether the decision is in line with the agreed policy.

The problem of approval is that the approvals body then seems to have a say over the decision – which in its own right can bring in (in the case of ccTLDs, but the same would apply to many geo-TLDs) a judgement from outside the interested community and would still be open to challenge.

An appeals body could be seen to do the same thing, but in this case it is clearly identified as independent and with expertise in making such calls.

I for one would be very concerned about an approval function that brought in what essentially would look like a kangaroo court into this process and one which would be open to liabilities that it could not respond to.

MB

From: cwg-rfp3-bounces at icann.org [mailto:cwg-rfp3-bounces at icann.org] On Behalf Of Gomes, Chuck
Sent: 25 November 2014 18:56
To: Milton L Mueller; 'Camino.MANJON at ec.europa.eu'; 'cwg-rfp3 at icann.org'
Subject: Re: [CWG-RFP3] Brief comments after Frankfurt

I still need to be convinced that the approval function for a delegation or re-delegation is not needed, but I open to being convinced.  Even if the approval function is fairly straightforward in confirming processes and technical checks were done, it seems to me that it is a good check point before delegation/re-delegation.  I assume that the IANA functions operator would do this but I believe it shouldn’t be left to that operator alone.  I should also add that I think that this could be done in fairly short order, i.e., one or two days max.

I strongly support what Camino says in item 6.

Chuck

From: cwg-rfp3-bounces at icann.org<mailto:cwg-rfp3-bounces at icann.org> [mailto:cwg-rfp3-bounces at icann.org] On Behalf Of Milton L Mueller
Sent: Tuesday, November 25, 2014 11:33 AM
To: 'Camino.MANJON at ec.europa.eu'; 'cwg-rfp3 at icann.org'
Subject: Re: [CWG-RFP3] Brief comments after Frankfurt

Comments in line below:

2) The IANA functions document dated 19 Nov includes 5 functions, being the first the "Approval function of changes to the root zone". It could be made clearer in the CWG proposal how the new architecture addresses this verification-authorisation role. The current flow-chart also does not include Function 5 (backstop fx).
MM: My impression from reading the transcripts was that it was decided there was no need for the approval function. This is a conclusion I would agree with. The appeals mechanism seems to eliminate the need for it.
4) In the appeals panel, it could be clarified that both the IANA Customer Standing Committee and the Periodic Review Team can initiate an arbitration procedure if the operator does not agree to implement recommendations. Is otherwise pulling the plug on the contract the only remedy? How are instructions or recommendations coming from the customers and the multi-stakeholder body enforced? As the flow-chart shows now  it seems that the only impact of the Customer Committee and of the subsequent escalation to the Review Team towards any issue of suboptimal performance of the operator, has to do with changes in the contract.  If the IANA operator is, for instance, interpreting policy and implementing on its own account, how do customers or the review team enforce any decision to stop the operator and how is the operator activity put on hold pending resolution of a conflict?
MM: These are very good questions. I do not know how to answer them, based on the materials coming out of Frankfurt. The proposal should have clear answers to them.
5) As regards the contracting function, we tend to favour the opinion of colleagues who have noted that there needs to be (i) a limited term for the contract; (ii) an open and transparent beauty contest (RFP); and (iii) no presumption or renewal of the contract to provide performance incentives.
MM: I am happy to see this, and I think it would be advisable to get general agreement on these criteria before we start debating whether the renewal period is 3, 5 or 6 years. ;-)
6) As regards what some members and participants have echoed in respect to the two processes (accountability and IANA transition) being interrelated and interdependent, the straw mans included some useful wording in this sense and it may be useful not to dismiss it: "The transition must not take place until (1) the requisite accountability mechanisms have been identified by the CWG on Enhancing ICANN Accountability (“Accountability CCWG”), (2) mechanisms that the community determines are necessary pre-transition have been put in place and (3) agreements and other guarantors are in place to ensure timely implementation of mechanisms that the Accountability CCWG decides may be implemented  post-transition".
MM: On point (1), just to be clearer, you might want to specify “…the requisite accountability mechanisms have been identified by _Track 1_ of the CWG on Enhancing ICANN Accountability….”
Track 1 refers to those parts of the CWG that are supposed to be specified before the transition.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-rfp3/attachments/20141126/af202479/attachment-0001.html>