[CWG-RFP3] Brief comments after Frankfurt

[Burr, Becky]

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<mailto:becky.burr at neustar.biz> / www.neustar.biz

From: Bertrand de La Chapelle <bdelachapelle at gmail.com<mailto:bdelachapelle at gmail.com>>
Date: Wednesday, November 26, 2014 at 10:58 AM
To: Martin Boyle <martin.boyle at nominet.org.uk<mailto:martin.boyle at nominet.org.uk>>
Cc: "cwg-rfp3 at icann.org<mailto:cwg-rfp3 at icann.org>" <cwg-rfp3 at icann.org<mailto: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<mailto:bdelachapelle at internetjurisdiction.net>
email bdelachapelle at gmail.com<mailto: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=>

[A GLOBAL MULTI-STAKEHOLDER DIALOGUE PROCESS]


On Wed, Nov 26, 2014 at 4:41 PM, Martin Boyle <Martin.Boyle at nominet.org.uk<mailto: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<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<mailto:Camino.MANJON at ec.europa.eu>; cwg-rfp3 at icann.org<mailto: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]
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<mailto:Camino.MANJON at ec.europa.eu>; cwg-rfp3 at icann.org<mailto: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]<mailto:[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<mailto:Camino.MANJON at ec.europa.eu>; cwg-rfp3 at icann.org<mailto: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<mailto:bdelachapelle at internetjurisdiction.net>

email bdelachapelle at gmail.com<mailto: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<tel:%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=>


[A GLOBAL MULTI-STAKEHOLDER DIALOGUE PROCESS]



On Wed, Nov 26, 2014 at 2:46 AM, Martin Boyle <Martin.Boyle at nominet.org.uk<mailto: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> [mailto: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<mailto:Camino.MANJON at ec.europa.eu>'; 'cwg-rfp3 at icann.org<mailto: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<mailto:Camino.MANJON at ec.europa.eu>'; 'cwg-rfp3 at icann.org<mailto: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<mailto: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/41bd6655/attachment-0001.html>