[CWG-RFP3] Brief comments after Frankfurt

Bertrand de La Chapelle bdelachapelle at gmail.com
Wed Nov 26 16:49:12 UTC 2014


I agree.

B.

"*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 5:23 PM, Burr, Becky <Becky.Burr at neustar.biz> wrote:

>   Bertrand,
>
>  In regard to ccTLDs, the final report of the Framework of Interpretation
> Working Group is very helpful
>
>  Becky
>
>
>  J. Beckwith Burr
>
> *Neustar, Inc. /* Deputy General Counsel and Chief Privacy Officer
>
> 1775 Pennsylvania Avenue NW, Washington, DC 20006
>
> Office: + 1.202.533.2932  Mobile:  +1.202.352.6367  /
> becky.burr at neustar.biz / www.neustar.biz
>
>   From: Bertrand de La Chapelle <bdelachapelle at gmail.com>
> Date: Wednesday, November 26, 2014 at 10:58 AM
> To: Martin Boyle <martin.boyle at nominet.org.uk>
> Cc: "cwg-rfp3 at icann.org" <cwg-rfp3 at icann.org>
>
> Subject: Re: [CWG-RFP3] Brief comments after Frankfurt
>
>   Martin, Chuck,
>
>  You rightly seem to make a distinction in your exchange between the
> delegation of new gTLDs and redelegation of ccTLDs. The first one is simply
> a matter of accuracy once the decision to approve the TLD has been made
> within ICANN. I don't think it goes to the Board in the current workflow.
> And the .xxx case showed that the function NTIA performed was not a second
> evaluation. So Chuck is probably right in suggesting no formal validation
> step.
>
>  Regarding ccTLD redelegation, the Framework of Interpretation provides
> in a certain way the policy. But there are criteria to be checked. I agree
> with Martin that this probably requires some formal decision. Is giving
> this decision to the Head of the IANA department, without a Board step, the
> direction we are heading towards? Is that enough?
>
>  As for Martin's comment regarding appeal mechanism, who would be the
> interested parties? In particular, what if there has been a gross
> mis-appreciation of the local conditions (for instance redelegation without
> due process at the national level and insufficient accounting of the
> interests of the local community as per RFC 1591). Who would the appeal be
> open to?
>
>  It has always been my concern that improper redelegation requests can be
> made by governments and there is not sufficient global accountability in
> that regard. ccTLDs are national structures but many do allow out of
> country registrants (some are even functioning more like gTLDs actually)
> and any disfunction of a ccTLD after an inappropriate redelegation can
> impact actors outside of the national territory, which is a matter of
> global public interest. In that regard, the exercise of sovereignty must
> account for potential transboundary impact.
>
>  B.
>
>      "*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 CHAPELLE  Internet & Jurisdiction Project | Director  email
> bdelachapelle at internetjurisdiction.net  email bdelachapelle at gmail.com
> twitter @IJurisdiction
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_IJurisdiction&d=AwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=__6hw5NXC14ET_uwbCGrT4JBLv7342oru6V3KJHWxD8&s=9txrdLhBm8yi-XK5Jiyu3-6IWRTMdqIns7YWTKqQLVw&e=>
>  | @bdelachapelle
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_bdelachapelle&d=AwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=__6hw5NXC14ET_uwbCGrT4JBLv7342oru6V3KJHWxD8&s=8AVIAoxWGTEGzcE9URRI70JI6FigA6r596OazZ0GkEs&e=>
> mobile +33 (0)6 11 88 33 32  www.internetjurisdiction.net
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.internetjurisdiction.net&d=AwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=__6hw5NXC14ET_uwbCGrT4JBLv7342oru6V3KJHWxD8&s=7IqM9c9xtPMf5DUEdAQP8uSV737g5nqHeVeKWSbvM8M&e=>   [image:
> A GLOBAL MULTI-STAKEHOLDER DIALOGUE PROCESS]
>
> On Wed, Nov 26, 2014 at 4:41 PM, Martin Boyle <Martin.Boyle at nominet.org.uk
> > wrote:
>
>>  I was just noting the status quo – at least for ccTLD delegation and
>> redelegation decisions.  I would be happy to see this go (although I don’t
>> think it is a problem at the moment, it could, as you point out, become
>> one), but for a decision with potential liability for the IANA functions
>> operator, it is a decision that needs to be made at a high level, in
>> particular for difficult decisions like delegation/redelegation.
>>
>>
>>
>> For a new gTLD, I can’t see why that should need to be referred up – just
>> a check on accuracy with the operator.  The process is in ICANN for
>> verification that it conforms to the Applicant Guide Book and that due
>> process has been followed?  A second assessment would seem to me redundant
>> at best, time consuming and open to abuse at worst, no?
>>
>>
>>
>> I struggle to see where a separate approvals process would fit and what
>> value it would bring in either gTLD or ccTLD cases.
>>
>>
>>
>> Cheers
>>
>>
>>
>> Martin
>>
>>
>>
>>
>>
>>
>>
>> *From:* Gomes, Chuck [mailto:cgomes at verisign.com]
>> *Sent:* 26 November 2014 14:39
>> *To:* Martin Boyle; Bertrand de La Chapelle
>> *Cc:* Milton L Mueller; Camino.MANJON at ec.europa.eu; cwg-rfp3 at icann.org
>>
>> *Subject:* RE: [CWG-RFP3] Brief comments after Frankfurt
>>
>>
>>
>> I am not sure that having the ICANN Board in the approval process for
>> delegation of gTLDs will be acceptable to new gTLD registry operators.
>> That could easily add a month or two to the process and maybe more.
>>
>>
>>
>> Chuck
>>
>>
>>
>> *From:* Martin Boyle [mailto:Martin.Boyle at nominet.org.uk
>> <Martin.Boyle at nominet.org.uk>]
>> *Sent:* Wednesday, November 26, 2014 8:51 AM
>> *To:* Bertrand de La Chapelle
>> *Cc:* Gomes, Chuck; Milton L Mueller; Camino.MANJON at ec.europa.eu;
>> cwg-rfp3 at icann.org
>> *Subject:* RE: [CWG-RFP3] Brief comments after Frankfurt
>>
>>
>>
>> Bertrand,
>>
>>
>>
>> Isn’t the approval function one of:
>>
>>
>>
>> 1.       A decision in the IANA contractor (I’d say at a high level,
>> bearing in mind potential liability risks:  I’d not have any particular
>> problem of this being in the ICANN Board, as it is at the moment.  This is
>> (or should be) essentially limited to checking that due process has been
>> followed.  Wisdom would say that the IANA functions operator has notified
>> the main parties.
>>
>> 2.       Before carrying out the redelegation, it should be possible
>> (and that is on our flowchart from last week) for the main parties to
>> appeal the decision.  This would be the replacement of the NTIA
>> verification step.
>>
>>
>>
>> More generally, it would seem to me to be important for the operator to
>> go to the registry with the final information on the change and for the
>> registry to agree that the change is indeed correct.  In otherwise for more
>> routine changes it is the registry that authorises its change.
>>
>>
>>
>> The authorisation role appears to me to be a gate-keeper role and
>> liability stops there:  this does not seem to me to be tenable.
>>
>>
>>
>> Hope this helps
>>
>>
>>
>> Martin
>>
>>
>>
>> *From:* Bertrand de La Chapelle [mailto:bdelachapelle at gmail.com]
>> *Sent:* 26 November 2014 10:55
>> *To:* Martin Boyle
>> *Cc:* Gomes, Chuck; Milton L Mueller; Camino.MANJON at ec.europa.eu;
>> cwg-rfp3 at icann.org
>> *Subject:* Re: [CWG-RFP3] Brief comments after Frankfurt
>>
>>
>>
>> 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 CHAPELLE
>>
>> Internet & Jurisdiction Project | Director
>>
>> email bdelachapelle at internetjurisdiction.net
>>
>> email bdelachapelle at gmail.com
>>
>> twitter @IJurisdiction
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_IJurisdiction&d=AwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=__6hw5NXC14ET_uwbCGrT4JBLv7342oru6V3KJHWxD8&s=9txrdLhBm8yi-XK5Jiyu3-6IWRTMdqIns7YWTKqQLVw&e=>
>>  | @bdelachapelle
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_bdelachapelle&d=AwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=__6hw5NXC14ET_uwbCGrT4JBLv7342oru6V3KJHWxD8&s=8AVIAoxWGTEGzcE9URRI70JI6FigA6r596OazZ0GkEs&e=>
>>
>> mobile +33 (0)6 11 88 33 32 <%2B33%20%280%296%2011%2088%2033%2032>
>>
>> www.internetjurisdiction.net
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.internetjurisdiction.net&d=AwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=__6hw5NXC14ET_uwbCGrT4JBLv7342oru6V3KJHWxD8&s=7IqM9c9xtPMf5DUEdAQP8uSV737g5nqHeVeKWSbvM8M&e=>
>>
>> [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
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_cwg-2Drfp3&d=AwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=__6hw5NXC14ET_uwbCGrT4JBLv7342oru6V3KJHWxD8&s=6_EZKjw-hBg1JnxCeS9cvheH2kzlilp9mQhP0Nu9lSg&e=>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-rfp3/attachments/20141126/12fca188/attachment-0001.html>


More information about the Cwg-rfp3 mailing list