[Ccpdp-rm] NOTES | ccPDP3 Review Mechanism teleconference | 18 May 2022 (19 UTC)

[Joke Braeken]

Important
Question: will you be on site for ccPDP3-RM and ccPDP4?
To do: Please let Kimberly know, so she can plan for priority in-room seating.


NOTES | ccPDP3 Review Mechanism teleconference | 18 May 2022 (19 UTC)


1.  Welcome & Roll Call

Welcome by Chair Stephen Deerhake
Some apologies received

2.  Administrative Items, if any

Stephen: ccPDP3-RM meeting at ICANN74. Hybrid meeting, with on site and remote participation.
Question: will you be on site for ccPDP3-RM and ccPDP4?
To do: Please let Kimberly know, so she can plan for priority in-room seating.

ccPDP3-RET. No news.

2.a. Action Items

None

3.  Review the possibility of developing a new binding review mechanism

>>> flowchart current situation

Nigel: We say: “cctld manager can go to court”. That never happened, to date. You need a legal theory to go to contract. We do not have contracts. Can a ccTLD manager go to court? Not sure.
Bernie: in California anyone can take anyone to court

>>> non-binding

>>> binding

Same lay-out as non-binding.
Only difference: buttom left-hand tree.
Eberhard: process-flow is an example only? Of how it could look like?
Bernie: yes.

>>> slide deck

Nigel: IRP panel cannot tell icann what to do. Fine words by icann legal. But recalls - in a controversial irp - that the irp panel did exactly that. Irp judgments are declaratory. The judgments go to the icann board for consideration. But icann board can probably not ignore.
Bernie: yes, there have been cases. But see bylaw phrasing. Fiduciary duty.
Bart: BWG. Board Governance Committee
Stephen: this is important. Invites all to pay attention
Bernie: this costs resources, time, money, etc. unclear who would pay.
Nigel: frustrating. Implementation detail: hope we do not go into the same kind of infinite loop.
Bernie: this was decided 5 years ago. This was a decided and accepted point: there would be a standing panel. It is still not in place.  These things take time.
Standard of review is the key.
Costs for binding vs non-binding would be similar.
Sean: Can’t we do IRP plus with the addition of ICANN covering costs on all sides with an ethics wall between finance and legal?  The justification being its not merely a precedent at this stage, but now policy going forward?
Bernie: ICANN legal will not pay your lawyer. Icann legal should not select your lawyer either
Bart: other parts of the community would object too

[cid:image001.png at 01D86B06.65489120]

Stephen: we are stuck
Bart: you want to inform the community. Seize the opportunity at ICANN74. Manage expectations
On your previous call, you agreed to pursue on the non-binding mechanism. That would bring relief to others, without the need to go through expensive court procedures. If you have nothing in place, you force people to go to court.  Even the non-binding will assist the cctlds.
Stephen: agrees. Non-binding is better than nothing.
Bart: one of the reasons why we did the frames. Even with a binding mechanism, even with IRP, at the end of the day, you may end up in court anyway, and then you have double costs.

[cid:image002.png at 01D86B06.65489120]

Stephen: how to interpret the results?
Nick: new binding mechanism is not going anywhere within a reasonable timeframe. Alternatives to court process, give better chances to ccTLDs. Not available to sit on WG to develop a binding mechanism.
Nigel: if we say no, where do we end up?
Bernie: all agree we proceed with non-binding. Secondly, if we believe that a new mechanism would have to be very similar to the IRP, as icann legal has said, the exceptions in the bylaws for cctlds are currently limited to delegations and transfers.  Does not include revocations nor retirements. There is a process in place. And icann needs to develop a standard of review with community, for revocations and retirements. We need to pick the least bad solution: non-binding, and possibly IRP. fundamental bylaw changes are needed in that case. Icann legal will support us.
To answer Nigel’s question: We have the IRP for revocations and retirements. And develop a non-binding mechanism to go forward.
Eberhard: does not make sense. Have 2 things in IRP, and 2 elements not? Big problem with non-binding: RFC says binding. We need to come up something that is a little bit more binding than non-binding. See charter
Nigel: ok to continue with 10 min?
Eberhard: no
Nigel: my opinion to survey changed, following Bernie’s answer
2 to 1 who did not vote yes. No consensus across this group, to go for our own designed binding mechanism. Very informal survey.
Next point: Eberhard is right. “Delegation and redelegation” to mean “anything to do with cctld relations with the root”. Icann legal sees it more limited.
Allan: good discussion. Least worse option is to continue developing of a non-binding mechanism. Let’s pause and try to get a consensus. Not available to sit on WG to develop a binding mechanism.
Linear approach today. We should revisit and try to develop a consensus
Eberhard: consequence cannot be non-binding. We should tell council we cannot fulfill our mandate. Extract from bylaws.
“Notwithstanding any other provision in this Section 4.2, the scope of reconsideration shall exclude the following:
(i) Disputes relating to country code top-level domain ("ccTLD") delegations and re-delegations;
(ii) Disputes relating to Internet numbering resources; and
(iii) Disputes relating to protocol parameters.”
Old language in the bylaws. My most important concern is the RM for revocation. That is covered under bylaws, not under IRP. deep ditch for me
Bart: the bylaw change was in 2016. FOI was adopted in 2014 by board. All knew what was meant. But there is wiggle room. Context: retirement is now included, since it was part of part B of ccPDP3. We separated it. The RM is not ready, when the ccpdp3-RET is adopted by the board. Room for include/exclude.
Eberhard: re-delegation has been supersedes by revocations and transfers. Retirement is technically a revocation. Retirement in IRP, and revocation in our solution.
Bernie: the words are there in the bylaws. And in icann legal bylaws they signal clearly that they are open to wiggle room. Just transfers, not revocations. Half in half out. Not ideal. Revocations and retiremetns in IRP? Our choice.
Eberhard: revocation means only a transfer? Over my dead body
Bernie: we can have bylaw change which will clarify either way.
Eberhard: cannot be our intention.
Nigel: what do you want it to mean? We want to clarify.

4.  Continue the non-binding proposal

Defer to next meeting

5. ICANN74

               Policy Update | Tuesday, 14 June | 11:15-12:30 UTC
               ccPDP3 RM Working session | Tuesday, 14 June | 13:00-14:00 UTC

Bart: prep needed for the next meeting. We are at a crossroad. Use the discussions from today, to update the community, check where they are at. And take the results from that session, for evaluation during our WG meeting. Before we make any decisions, consult with the community first.
Do you agree? Consult with the community on the principle point ?
Stephen: yes. No objections by group either.

6.  AOB

7.  Next meetings

               1 June 19:00 UTC – prep ICANN74

Thank you all. Goodbye.



Joke Braeken
joke.braeken at icann.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/ccpdp-rm/attachments/20220518/5bb12537/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 22298 bytes
Desc: image001.png
URL: <https://mm.icann.org/pipermail/ccpdp-rm/attachments/20220518/5bb12537/image001-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 31565 bytes
Desc: image002.png
URL: <https://mm.icann.org/pipermail/ccpdp-rm/attachments/20220518/5bb12537/image002-0001.png>