[Ccpdp-rm] NOTES | ccPDP3 Review Mechanism WG | 4 November 2020 (4:00 UTC)

Wed Nov 4 05:08:15 UTC 2020

Hello All,

Please find included below some high-level notes from today’s meeting, held on 4 November 2020 at 4 UTC.

Best regards,

Joke Braeken

  1.  Welcome and roll call

Welcome by Stephen Deerhake. Thanks all for participating.

Apologies received:  Jaap Akkerhuis, Patricio Poblete, Eberhard Lisse.  All calls are recorded and recordings will be posted on the public wiki: https://community.icann.org/x/nIfzC

2.                  Administrative announcements, if any

a.                  Call rotation – standard time?

Winter time adjustment? No decision today. Let’s take it to the mailing list.

3.                  Action items

Action items from previous meeting: Bernie had to update the results of the spreadsheet, with the results of the discussion last time.

4.                  Recap of where things stand currently

Discussion regarding ccPDP3-ret at ICANN69: work is ongoing regarding the carve-out of part 1. For those interested in reviewing the slides/recording/transcript for the PDP-RET session at ICANN69:  https://69.schedule.icann.org/meetings/CAh4tpyjSW9HiHSQM

Bernie provides a recap.

Last time we had a table with the various elements that could be appealed. 2 points on delegation, transfer, 1 on revocation, 1 on failure to accept the ccTLD string.

  *   On retirement we had forgotten that we included in the retirement doc that if a reserved code changed status, the IFO could request it to be appealed.
  *   On a new delegation: the applicant could appeal if there was a negative finding from the IFO, or if there was more than one applicant, the losing applicant. No other third party to appeal a new delegation.
  *   Under transfer: the applicants can appeal if it was rejected. No other 3rd party to appeal.

Defining standing: we resolved this. Who can appeal a decision from the IFO?

5.                  Revised:  decision points table/spreadsheet

The appeal process is all about details: timing, process… We need to understand them properly.

We need to make sure that when someone applies for a new ccTLD, that there is a formal notification posted on the IFO website. There needs to be a minimum period during which someone can apply.

Peter: the ccPDP4 is still in the making. Applications for IDN ccTLDs are more complicated (confusing similarity). Anyone affected by a decision, should be able to appeal. How firm can we deal with IDN ccTLDs at the moment? Do we need to update the table based on the results for IDN ccPDP4?

Bernie: this is a placeholder. Logically, it would just be the applicant that could appeal. But we will see later.

Peter: effect of an application might be different from what we have today.

Bart: the IDN PDP is about string selection. Rules for transfer, delegation, revocation, retirement do apply. The review mechanism applies. Having a placeholder is fine. But, is the string selection part of the review mechanism?

a.                  Next steps

Are there deadlines?

General agreement: unwinding a delegation is not a way forward. Timing considerations relative to appeals. We should start thinking about it. The timing may not be monolithic. The timing may be affected by other processes. If we make it a requirement that an agreed party has to go through another process, such as mediation, before going through an appeal mechanism, one needs to consider the time required to do this.  Reminder: keep in mind that we do not know what the mechanics of the appeal mechanism will be. Once we finished, we could work with the lawyers what the options could be for a(n) appeals mechanism(s).  We might not need a full blown mechanism like the ICANN IRP. Lay out the details of what we are thinking, it provides a lot of info. We can then consider the options for the mechanics. International system? Which people to be involved? ICANN noticed that in the IRP, getting good legal people as arbiters was not ideal. Specialised universe. ccTLDs are even more specialised in some ways.

=> 3rd column in the table. The decision that is being contested.

We might need changes here. Originally we were thinking 3rd parties could be involved. But we removed 3rd parties. However, on the delegation of a new ccTLD, if we want to limit it to those that applied … if someone thinks on contesting, there is probably a requirement to have a notice that a delegation request has been made. There may be a window during which anybody else can apply for that ccTLD. It may be wise for the IFO to post a notice. There may be a window for anybody else to apply, so that the IFO can look at both applications at the same time. It may cause some grieve.

Peter: I do see the 'DoS’ potential, but that appears to me to look like a significant deviation from RFC 1591
.  Looks like an admin issue. Closing the window after some time has a significant impact on RFC1591.

Bernie: two-edged sword. We then have to consider the impact. There is as much a DoS possibility, if someone understands the only applicant is about to get something, and then they put in an application when the original applicant is about to get the TLD.

Allan: agrees with Bernie. Wonders if we choose how to characterise the publication of the potential of a delegation. Given that the processes are lengthy, there may be a way for the IFO to make a notice early in the process: we have an application we are looking at. Needs to be early enough in the process. Then maybe there is no DoS.

Bernie: for transfer there is no question of notice. For retirement, all timings are built in the retirement process. Revocation: not sure we worked out the timing or process very well? Needs to be looked at. We worked out the conditions for what would cause the revocation. The detailed process might be a point to be looked into, so that timing is clear.

On the decision to be contested, there is only the losing party in the delegation.

Stephen: how detailed do we want to go into the IDN issue?

Bernie: not an issue from the timing perspective. There is one clear applicant for the string. That appeals, if we decide to go there, is complicated. Why? Confusing similarity. Analogous to string evaluation panels for gTLDs. In the appeals mechanism on IRP, they start to consider, whether to appeal the decision, or getting into the panel that decides?

Bart: would it be helpful if we did a similar issue as what we did with the retirement? The group notes that there is an issue regarding IDNs and brings it to Council’s attention. So that this group is not too hung up in what is happening in ccPDP4. Issues to be considered by ccPDP4 instead.

Bernie: Let’s first see what our phase 1 work brings us. Once we are done, there might be a note to council that there are some issues.

Bart: run parallel list of issues to be identified? Parallel list of stress-testing.

=> 5th column. Second part of the timing: the timing after the decision.

Not unwind a delegation that has gone into the root: fundamental premise. So we need timing considerations: announce that the decision has been made to grant the delegation. Once that has been done, a clock starts ticking. A party that can appeal, can actually make that appeal. 30 day period as a placeholder. Keep in mind: if someone does appeal, it means you do not delegate the ccTLD into the root for the time being. We need to be clear on that. Appeal takes time. In case of an appeal for a refused transfer, it does not change anything. You are not blocking a delegation. On retirement: are you appealing a decision to remove an exceptionally reserved because of a change in status, be careful. Our minimum is 5 years, so we do not have a problem. If there is an appeal on retirement for extension, you may not want to drag it out too long. Revocation: you can appeal it. Given we do not have the conditions under which the mechanics of a revocation apply, what are we going to hold off on?

Bart: was the type of redress discussed, that you get from an appeals mechanism? Turning back the decision made

Bernie: not considered that yet.

Bart: example. Delegation. If you turn back the decision to delegate, you could imagine a new ccTLD at one point to be entered into the root. Decision: has it been delegated to the right party? The redress mechanism could be a transfer.

Bernie: have that as a stress test. It would not be a transfer as such. A Transfer is between 2 willing parties. In your example, it is not. That is why we need timing: issue to be resolved first, before entering it into the root.

Bart: you appeal the decision. But what does it imply?

Bernie: the only thing an IRP panel can do, is say “ICANN has made a decision, or failed to make a decision, as required by the bylaws”.  This is not a court where damages can be awarded.

Bernie to start building a parallel list for stress tests

6.                  Issues list (continue discussion)

Covered under item 5

7.                  Next meetings

Suggestion to move the timing up with 1 or 2 hours. Proposal to put a doodle poll out to see what the membership prefers.

18 November 2020 (time tbd)

2 December 2020 (time tbd)

16 December 2020 (time tbd)

7.                  AOB

none

8.                  Closure

Thank you all for participating.

Joke Braeken
ccNSO Policy Advisor
joke.braeken at icann.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ccpdp-rm/attachments/20201104/0ff4d200/attachment-0001.html>