[CWG-RFP3] Brief comments after Frankfurt

Wed Nov 26 10:55:19 UTC 2014

Martin,

The verification-approval function is indeed an important point. Basically,
who or what takes responsibility for the decision.

In the current implementation - with ICANN as the IANA contractor - the
process involves preparation by IANA staff of the report on changes (in
particular for ccTLDs) and its transmission through the ICANN Board to
NTIA.

In the hypothesis of mere disappearance of the NTIA approval function,
without introduction of a specific replacement, would the Board then be
considered as the final approval step? Given the discussions on strong
functional separation, is this what people intend and are comfortable with?

Or would the Head of the IANA Department be considered as the final
approval step? If so, does this provide sufficient guarantees and how would
this person be selected?

Could a group of trustees be envisaged?

Best

Bertrand

"*Le plus beau métier des hommes, c'est d'unir les hommes*", Antoine de
Saint Exupéry
("*There is no greater mission for humans than uniting humans*")BERTRAND DE
LA CHAPELLEInternet & Jurisdiction Project | Directoremail
bdelachapelle at internetjurisdiction.netemail bdelachapelle at gmail.comtwitter
@IJurisdiction <https://twitter.com/IJurisdiction> | @bdelachapelle
<https://twitter.com/bdelachapelle>mobile +33 (0)6 11 88 33 32
www.internetjurisdiction.net[image: A GLOBAL MULTI-STAKEHOLDER DIALOGUE
PROCESS]

On Wed, Nov 26, 2014 at 2:46 AM, Martin Boyle <Martin.Boyle at nominet.org.uk>
wrote:

>  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
> <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.
>
>
>
> _______________________________________________
> Cwg-rfp3 mailing list
> Cwg-rfp3 at icann.org
> https://mm.icann.org/mailman/listinfo/cwg-rfp3
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-rfp3/attachments/20141126/aa9fc338/attachment.html>