[Ccpdp-rm] NOTES | ccPDP on Review Mechanism WG | 26 August 2020 (20:00 UTC)

Wed Aug 26 21:06:40 UTC 2020

Hello all,

Please find included below some notes from today’s ccPDP3-RM meeting, held on 26 August 2020 at 20 UTC. The notes are not meant to replace the recordings, but simply help you navigate through the call.

Recordings and all materials will be posted on the group’s workspace: https://community.icann.org/x/rAR1C

Best regards,

Joke Braeken

  1.  Welcome and roll call

Welcome by Chair Stephen Deerhake.

2.                  Administrative announcements, if any

No formal administrative matters.

ccPDP3-ret has started reviewing the comments received during the public comment period. Looks like little changes will be required to the group’s recommendations

Eberhard: ISO issued a new version of the standard. Staff will be asked to distribute the new version

Jaap: it was published yesterday. There are no substantial changes. Only editorial changes. Jaap is not aware of any substantive changes

Peter: looked at the version recently published. Nomenclature changes (code, code elements), but indeed no substantial changes. Nothing that affects the 2nd half of the PDP.

Stephen: the ccPDP-ret WG may want to look at the nomenclature changes?

Peter: indeed. But I prefer to wait for Jaap’s input.

Eberhard: same reading as Peter. But we want to be sure that we use the latest terminology

Jaap: debate about the differences between codes and code elements. Has to do with the central definition.

3.                  Action items

This group will not meet as part of ICANN69

4.                  Identify decision points table

a.                   Revised document

Bernard: re-read the bylaws (section 10, annex C). The reality : ccNSO provides rules to add/delete/change ccTLDs to the zone file.

Our decision point on retirement is: changes to the ISO list.  Delegations and transfers remain.

Contrary to the IRP, trickier process: a negative decision by IANA does not necessarily make it to the Board, because there is no change to the zone file. But: is that a decision that we want to say “ can be appealed”? There is the decision to accept the request for a transfer. Can you appeal that?

If a transfer request was made, and rejected: how can you appeal that?

The current appeals mechanisms only allow for the ccTLD manager to use the PTI complaints mechanism. In the IRP, many discussions (who can add a claim, etc): toughest part.

Key decisions:

  *   Delegation, accepted or not
  *   Transfer, accepted or not

It becomes more about: Who can appeal? Who has standing? What are the triggering factors for what has been decided by IANA? And not necessarily by the Board. That complicates matters.

If we look at this, and those are the key conditions that we want to manage an appeal for, then we start looking at what the trigger is.

What is the decision that caused injury to a party? That would class that party as being able to make an appeal? = key question delegation, redelegation.

Once there is a decision to grant the ccTLD and include it into the root zone, the Board will need to approve it or not.  We need to lay out the framework for deciding who can appeal the decision.

Another point we need to consider: decisions that are appealed in the IRP at ICANN, have a time lag between the time the board announces a TLD and the time it goes into service. This is not necessarily the case when a ccTLD goes online. There are still tech checks, where the community has been consulted. This is nothing compared to the requirements for gTLDs. To consider: something becomes a de facto reality, and an appeal process might be developed that does not make sense.

Question by Bernie: What is the delay between the Board approving a ccTLD for delegation, and it going into the root zone?

Naela: there is little time. All checks have been completed when the package is sent to the Board. In other words: 1 to 2 business days. See SLAs.

Agrees from a contractual point of view, that gTLDs have many requirements. gTLDs come with the work pre-done and come to the IANA services team. ccTLDs are more labour intensive for IANA services staff.

Bernie: I was talking about the requirements from an applicant point of view.

Allan: My mindset is, deliver an appeal mechanism to the ccTLDs which is at least as good as the existing processes within the ICANN community.

  *   What do we do with anyone in the world having the ability to challenge a decision? Claimant needs to demonstrate having suffered harm or injury from the decision. Existing IRP and tweaking it a bit to the particular circumstances we may face.
  *   We can table, but it has to do with what the ccTLD community carved out of the IRP. at some time we need to acknowledge that many things we deal with within the ccNSO, bylaws that govern the ccNSO, are subject to an IRP and are subject to appeal. We need to put that in writing somewhere.

Eberhard: agrees with Allan, regarding the rules and regulations followed by the ccNSO and ccNSO Council, should be subject to a mechanism. But currently they are not. We should build in sufficient time to unring facts.

Stephen: new code point. IANA refuses to delegate it. Single applicant, no discussion, no dispute.

Bernie: part of the work in IRP. same case, for separate things dealing with the same topic. Combined into a single appeal. Minor process for doing that. IOT is currently writing the rules for consolidating cases.

Bernie: we might be talking about 2 delays:

  *   if an appeal is accepted, do you delay the implementation until the case is resolved?

Naela: My concern about what Eberhard and Bernard are saying is that building a delay a common cause for special cause situations feels like “punishment” for every case when the ones that may need to appeal should be a minority of the cases

Bernie: in reality what tends to limit that are 2 things: eligibility, and secondly the cost.

No easy tweak to IRP. if you launch an IRP, it costs a minimum 1 million USD.

Naela: 3 different requestors that wish to operate a ccTLD. In the delegation process, there is an onus on the applicant to demonstrate LIC support, government support etc. big consensus building. The fact that there are more requestors, is a concern. You need to build consensus within the country locally.  No last minute requests or EOI to run a ccTLD should be accepted. Undesirable. If there are competing requests to operate a TLD, IANA will ask both parties to work together

Eberhard: not interfering with the process. No de novo opportunity at the end. But, if a decision has been taken, the entity needs sufficient time before irreversible steps are being taken.

Bernard: there is a question of standing. But before a case is accepted, there is another test. What claim is being made? How is it backed up? Even if they are right, they are not reimbursed. Significant costs.

we simply try to jumpstart the discussion.

Naela: operation asap usually wanted. Iana has been asked for several years to publish on a monthly basis the pending delegations and transfers for all TLDs. the idea was to have an opportunity to not agree. Could be made more publicly visible, more easily accessible.

Bernie: if iana has done a good job resolving the situation in the community, there should be limited grounds for an appeal. But we still need to build it in. More of interest and more difficult to deal with: the transfer issue.  The notices: IANA is looking at delegating etc. there is no guarantee on when it gets done. We need to address what happens when a decision is made. What happens if IANA makes a decision not to give it to the board? Has it been checked at the same level? Is an appeal possible?

ccTLD specific circumstances that do not fit into the standard IRP. Who can appeal? What can they appeal? What do they need to bring to the table? How many people will look at this? Look at all the effective moving parts. Not everything is appealable.

Key decisions which affect parties have to be appealable. Things that led to the decision, can be looked at.

Suggestion to produce a doc that looks at this. What are the key elements?

Stephen: yes. Question of standing, what claims can be made, break it down.

Allan: points of concern. Bernie rightfully said that the IRP is very expensive. If we rely on it, it could deny access to certain parties. Valid point of view. But if the solution is to narrow the scope of what can be appealable, it will be contentious at the end.

Eberhard: no issue, as long as ICANN pays for it.

Bernard: agrees with Allan. Our scope was to do with additions/changes/deletions to the root zone file. 1 thing that is appealable for the deletions:  request to have extension denied. Would this apply to other elements? For this group to decide. Once you have developed a process for hearing requests for appeals, adding things, another PDP to address it: you are not starting from scratch.

5.                  AOB

Allan: applicability IRP to article 9 (Bernie’s correction: article 10) of the bylaws that deals with council and its procedures: fundamental that we understand that. We need to add some clarity on this at a certain point in the process. Maybe we need a discussion with icann legal? Follow up.

Bernie: ICANN IRP does not hear things within SO's, it just deals with Board decisions vs the Bylaws

6.                  Next meetings

9 September 2020 (04:00 UTC)

23 September 2020 (12:00 UTC)

7 October 2020 (20:00 UTC)

No meeting during ICANN69 for the ccPDP3-RM.

The ccPDP3-RET will meet on 15 October (14:00-15:00 UTC)

4 November 2020 (04:00 UTC)

Joke Braeken
ccNSO Policy Advisor
joke.braeken at icann.org<mailto:joke.braeken at icann.org>

Follow @ccNSO on Twitter: https://twitter.com/ccNSO
Follow the ccNSO on Facebook: https://www.facebook.com/ccnso/
http://ccnso.icann.org

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