[Ccpdp-rm] NOTES | ccPDP3-RM | 3 June 2020 (20 UTC)

[Joke Braeken]

hello all.

Please find included below some high-level notes from today’s ccPDP3-RM meeting, held on 3 June at 20 UTC.

Best regards,

Joke Braeken



  1.  Welcome and roll call


Welcome by Chair Stephen Deerhake (.as)


2.                  Administrative announcements, if any


None by the Chair. None by the support staff


a.                  Action Items, if any:  update method for identifying decisions subject to review?


3.                  Reconsideration process:  overview – ICANN Legal


Presentation by Liz Le. See slide deck shared via zoom. Slides on wiki too https://community.icann.org/x/gIXsBw

-Scope and purpose of the reconsideration process

-Standard of review

-The reconsideration process

Becky Burr: The role of ombudsman is not a typical one. Extra step, created by the accountability work track. The Ombudsman has already provided his evaluation on reconsideration requests.  Different standards for his own review (fairness).

Becky Burr: things have been reconsidered probably.

Liz: there has been a couple of times where a reconsideration request where the BAMC found a procedural violation (new gTLD programme) where it was determined that there was perhaps string confusion, or parties that have not followed procedures

Stepehn: does this apply to IDN ccTLDs?

Sam: not bundle in cc delegation decision or IANA service related issues into reconsideration. For problem resolution to be driven there. When you look at the differences between the processes, the ccTLD fast track is a separate process. Formal ccPDP ongoing work. That process of the evaluation of strings is happening outside of the IANA function. That is an icann org process. Good arguments could be raised about how icann considers fast track evaluation decisions. Not necessarily a preclusion of that type of the iana function, on how icann would process fast track requests.

Allan: follow-up question. ccTLDs being excluded from reconsideration mechanism. Opportunity to understand the nature of the exclusion. The way I understand, the exclusion relates to claims or actions, related to (re)delegation. Nothing that excludes them from taking action as specified under 4.2. Think ccTLDs are not excluded, but the claims regarding delegations or redelegations are.

Eberhard: a ccTLD manager cannot be worse than everyone else. Point is that delegation, transfer and revocation are different. For gtLDs it is contractual. One contract for all. That does not apply to ccTLDs.

Kim Davies: 
As a general rule, ccTLDs are ccTLDs, and whether the label is encoded with IDNA or not is a sub typing that has no operational relevance. It is primarily a distinction when it comes to string selection and eligibility.


Sam Eisner: 
The Bylaws state: (i) Disputes relating to country code top-level domain ("ccTLD") delegations and re-delegations;
As part of the exclusion

Not sure of timing FOI language, and the terminology. Is there an ambiguity between the FOI words, and what is in the bylaws?

Kim: i see no ambiguity

Eberhard: preference to change everything to current terminology.


4.                  Identifying decisions subject to review mechanism


Presentation by Kim Davies. Slides available on wiki. https://community.icann.org/x/gIXsBw

Naela is unable to attend, and sends her apologies.


Process review.

Process similar to routine root zone change process.

Is enough material submitted? Errors to be corrected => tech checks. Are the nameservers correctly configured? => demonstrating consent, slightly different process. Changes following FoI, specific requirements as to how consents need to be obtained for transfer request. Details to follow => regulatory checks. Is the request compliant with all laws and regulations? Legal obstacle? => staff evaluation and findings. E.g. support within the country. Nature of the legal entity, evaluate transfer plans, ask questions to understand the situation etc. followed by a report by staff to ICANN BoD for review, to ensure that procedures were applied correctly in support of the policies => implementation phase.

If it is a request that warrants analysis, it needs to be clearly described. Those that require a transfer or redelgation, are often third parties. Staff needs to explain the roles, procedures, check-lists and guides on the website. Part of the evaluation is pertaining to string eligibility. Not an existing ccTLD for instance.

Technical checks identical to routine root zone change request.

With respect to the consent: significant change as a result of the work of the FoI. criteria that needed to be met for a consent to be recognised by IANA, for transferring a TLD from one party to another. Form available. Not an obligation to use it.

Staff evaluation and findings. High-level summary. Ensure that proposed new manager has enough competencies. Necessary skills needed to manage the engagement, also if they choose to delegate some aspects to a vendor.

Technical checks prior to implementation in the root zone.


Eberhard. Correctness of email address in a-record

Kim: no such technical check. let’s take this offline.


Irina: 
No issues, just a questionLines 25-27

Just for clarity:

According to the current draft of ccTLD Retirement Policy, if IFO follows the procedure properly, in this case ICANN Board plays NO role in ccTLD retirement. It is IFO (=PTI) that makes all the decision based on the triggers described in the proposed Policy (Interim Paper)

Is that correct?

Bart: we will get back to you regarding this question.


a.                  3-step approach document – any comments?

b.                  Overview Delegation and Transfer processes - PTI

c.                   Initial discussion, if time permits


5.                  Next meetings

a.                  17 June (04:00 UTC)

b.                  1 July (12:00 UTC)

c.                   15 July (20:00 UTC)


6.                  AOB


Allan: When will we have a review of the new IRP? Probably most relevant to what we are going to consider? See section 4.3. Of the bylaws.


Bart: addressed either during the next meeting, or the meeting after that. Liz, Sam, probably Becky comes too.


7.                  Closure


Thank you all




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/20200603/0d43588e/attachment-0001.html>