[CWG-RFP3] Brief comments after Frankfurt

Wed Nov 26 18:35:47 UTC 2014

Becky,

Is this the final report you are referring to?
http://ccnso.icann.org/workinggroups/foi-final-07oct14-en.pdf
Is this report on Revocation also relevant?
http://ccnso.icann.org/workinggroups/foi-revocation-07oct14-en.pdf
And this one on Significantly Interested Parties?
http://ccnso.icann.org/workinggroups/foi-sip-07oct14-en.pdf

Thanks!

Greg

On Wed, Nov 26, 2014 at 11:49 AM, Bertrand de La Chapelle <
bdelachapelle at gmail.com> wrote:

> 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.com
> twitter @IJurisdiction <https://twitter.com/IJurisdiction> |
> @bdelachapelle <https://twitter.com/bdelachapelle>mobile +33 (0)6 11 88
> 33 32www.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=>
>>>
>>>
>>>
>>
>>
>
> _______________________________________________
> Cwg-rfp3 mailing list
> Cwg-rfp3 at icann.org
> https://mm.icann.org/mailman/listinfo/cwg-rfp3
>
>

-- 

*Gregory S. Shatan **ï* *Abelman Frayne & Schwab*

*666 Third Avenue **ï** New York, NY 10017-5621*

*Direct*  212-885-9253 *| **Main* 212-949-9022

*Fax*  212-949-9190 *|* *Cell *917-816-6428

*gsshatan at lawabel.com <gsshatan at lawabel.com>*

*ICANN-related: gregshatanipc at gmail.com <gregshatanipc at gmail.com> *

*www.lawabel.com <http://www.lawabel.com/>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-rfp3/attachments/20141126/3db998e4/attachment-0001.html>