Dear all,
Please find below the notes and action items from today’s ICANN75 sessions. Slides are attached.
Kind regards,
Ariel, Steve, and Emily
Notes and Action Items
Session 1 – Saturday 17 September 2022 at 9:00 MYT
Round the Room Introductions
“Chunking” Exercise
* Purpose of this “chunking” exercise: divide top level and second level work, so that the report on the top level can be delivered in December 2022 and work can simultaneously happen in the CPH Tech Ops group on some of the operational implications of work at the second level. A second report on second level issues will be delivered later.
* This will require an updated project plan to be delivered to the GNSO Council.
* Session Deck Slide 8-9 – “Chunking” Overview
* Session Deck Slide 10 – Initial Report Part 1 – Group 1 Charter Questions
* Session Deck Slide 11 – Initial Report Part 1 – Group 2 Charter Questions
* Session Deck Slide 12 – Initial Report Part 1 – Group 3 Charter Questions
* Session Deck Slide 13 – Initial Report Part 2 – Group 4 Charter Questions
* Session Deck Slide 14 – Initial Report Part 2 – Group 5 Charter Questions
* Session Deck Slide 15 – Initial Report Part 2 – Group 6 &7 Charter Questions
* Another consideration is that part 1 is about the new gTLD process. The Board wants to see this PDP done before they introduce more new gTLDs. Those that focus on the post-contracting phase are in group 2.
* It wasn’t clear where Charter Questions F1 and F2 sat in the process, and therefore whether they fit is group 1 or group 2.
* Any reactions to the proposed approach?
* Comment from the Board Liaison: The Board has not discussed this. The Board does not have a position about whether there is a dependency here for new gTLD rounds.
* Comment that splitting the work is a good idea and is logical. The approach gives the community visibility into the work has been done.
* One topic that is not explicitly included in the charter is if and how variant relationships show up in WHOIS. The topic might belong under Charter Question a8, which is in the first “chunk” of work. We might want to seek IANA’s input on this topic.
* Comment that it may be useful to develop an additional Charter Questions specifically on this topic.
Action Item 1: Leadership team to coordinate with Council Liaison about when and how to inform Council that the EPDP Team needs to consider this additional topic.
* Suggestion to add this topic to group 2, because only delegated TLDs have IANA records.
Action Item 2: Leadership team will update project plan and produce a project change request, which it will share with the WG before sending to Council.
Risk Management Methodology
* There are risks associated with the introduction of IDN variants, for example risks misconnection and denial of service.
* There are differences of opinion within the team about whether these are edge cases and what that means for policy development.
* The leadership team is looking to introduce tools to help assess possible risks associated with potential recommendations.
* Security and stability are always top of mind. The EPDP Team relies on SSAC reports and other sources to take these into account.
* Some other risks are harder to assess.
* Session Deck Slide 17 – Problem Statement
Risk Management
* Presentation: Intro to Risk Management Approach from James Caulfield from ICANN org’s Risk Management function
* Risk Management Deck Slide 2 - The Nature of Risk
* Risk Management Deck Slide 3 – Informed Management of Risk
* Risk Management Deck Slide 4-5 – How to Articulate a Risk: Risk Title, Consequences, Existing Controls or Mitigation, Risk Rating, Proposed New or Changed Controls or Mitigation.
* Risk Management Deck Slides 6- 7 – Risk Ratings: Heat maps reflecting patterns of likelihood and severity
* Risk Management Deck Slide 8-9: Rating a Risk: Importance of defining the ratings associated with risk
* In the policy development context, it may be helpful to use this framework: to understand the likelihood and severity, but also to consider possible mitigation measures.
* This may especially be useful to reflect in the rationale of the policy recommendations. The recommendations may be considered more sound if the EPDP Team can show that is has gone through this exercise.
* From one perspective, a challenge is that there may be differences of opinion within the group about what kinds of risks are severe. Some might think that an issue poses a security and stability risk to the Internet. There is no way to prove who is right and who is wrong. What do you do about that in the context of a risk analysis?
* Perhaps the next step is to accept that there are differences of opinion about the impact, but in such cases, you might be able to focus on the mitigation that could be mutually agreeable.
* Comment that much of risk management is subjective. It relies on professional judgement. If the group can agree on what will be the consequence of a risk, that is a good first step. At the same time, in risk management, there does need to be an ultimate decision maker.
* From on one perspective, it also depends on the ICANN community’s level of risk tolerance. The EPDP Team can do the analysis, but ultimately someone needs to decide what level or risk is acceptable.
* Comment that this is a good exercise for the EPDP Team. It will help with developing the rationale and potentially also help implementation. How does the group converge on understanding of consequences?
* Response that often this is done through a root cause analysis.
* It was noted that this approach could be used in supporting development of policy recommendations on string similarity.
* Agreement that this is good way to approach the EPDP’s work. Given that the group is making new changes that impact the root it’s important to look at risks.
* As a next step, if the EPDP Team agrees that they want to take this work further, a future call can be used to do a deeper dive into risk analysis.
* Session Deck Slide 18: Denial of Service: Example & Illustration
* Session Deck Slide 19: Misconnection: Example & Illustration
* Question about how these examples are different from trademark infringement.
* Response that the discussion is around string similarity and how the blocked variant may or may not be taken into account in this review.
Session 2 – Saturday 17 September 2022 at 10:30 MYT
Strawman Process Flow
* Background
* Origins from questions D1b and B4
* Purpose
* Understand which elements of new gTLD process will be impacted by variants
* Which how those elements must be modified
* Consider level of effort
* What to review and discuss
* Review mapping of charter questions and prelim recommendations
* Identify potential gaps
* Analyze feasibility of a standalone round
* Analyze feasibility of activating variants between application rounds
* Is NOT a comprehensive capture of all charter questions, only charter questions/recs relative to New gTLD Application process
* Chinese and Arabic gTLD Registry Operators survey – reviewing results on slides
* Question about the importance of the survey results in policy making. Noted that this is a data point, not binding in any way. Recognizes that the factors that may affect decision-making are still pending, understandable that outcomes from this EPDP and SubPro implementation may be impactful.
* Assumption that the general flow of the program will look generally similar. The updated process flow includes new elements as identified by SubPro. Other new addition is the inclusion of charter questions and preliminary recommendations. And finally, boxes are numbered.
* Two labels possible for each box: Applicable and Specific. Applicable means that IDN variants would still be required to go through the program element. Specific means that some sort of change will need to be made to the process to accommodate IDN variants. The Specific questions will naturally likely have charter questions associated.
* Pre-Program Processes from SubPro include Predictability Framework and RSP Pre-Evaluation
* Reviewing application submission process impacts
* Notes new impact from IGO-INGO PDP
* Two new SubPro processes are “Persistent” Processes meaning they can occur at various stages of the program. This includes RVCs and PICs and Application Change Requests (including ability for .Brand to revise strings to resolve string contention).
* Reviewing Initial Evaluation process impacts
* Noted that - “To be consistent with other boxes that have a relationship with Rec 2.8, I think box 25 should also be 'Specific'”
* Another persistent process – Limited Challenge / Appeal Mechanism
* Reviewing Objection mechanisms
* Reviewing Extended Evaluation
* Reviewing String Contention Resolution
* Reviewing contracting, pre-delegation, and delegation
* Question – are there any gaps?
* Potential gap within box 2 – would a different pre-del process be needed for RSPs that want to provide services for IDN variants versus those that do not intend to do so.
* There are at least two models to manage primary and variants – variant as object versus variant as attribute. May need to look at this.
* Is there a possibility that the backend-registry operator is unable to handle variants? It seems that this is the basis for flagging this process.
* Pre-evaluation for RSPs will not include the business, policies, etc. for the Registry Operator. It would be limited to just the technical capabilities of the pre-eval.
* Background on RSP pre-eval: uses same criteria as during application evaluation process. String agnostic process. It allows applicants to potentially just check a box that they will use a pre-evaluated RSP. There may be initial elements needed once the primary/IDN variants are needed.
* There may be a gap for pre-delegation testing as well, similar in nature.
* Potential gap for geographic names? What would happen if a variant is a geographic name. Probably not a gap as the variants would be subject to any restrictions on the primary.
* Question also from other angle - variants of ISO 3166. There may be a charter question that connects to this issue.
* E6: is there any reason to permit the registration of gTLDs consisting of decorated two-character Latin labels which are not variant labels of any two-letter ASCII labels?
* Registry Services – reviews anything above and beyond the typical services, which could include variant management.
* Question about relevance of IDN retirement processes? Seems out of scope.
* There appears to be existing processes to cover this (e.g., EBERO)
* What happens if only one of the delegated variants is to be retired? Can be covered in part 2 of the chunking exercise.
* Moving to discussion about whether an existing TLD operator could apply in a separate program process. One option is to roll these applications into a future round. A separate process requires setting up standing up all needed infrastructure, which would be complicated under cost-recovery.
* At least for the next round, there should not be a standalone round just for existing operators. This should help address cost recovery. Group will need to determine which elements would apply to just variants of existing ROs, even if combined into the next round.
* What happens if a ccTLD operator applies for a gTLD IDN and IDN variants? Would they also require different requirements.
* Need to consider if the variant is protected in some manner.
* Haven’t yet made a decision whether variants would be allowed in the future, between the regular rounds. This question is likely about “activation” between rounds.
* One of the purposes of the process flow is to help answer questions like this – can any processes be dispensed with just for activation? If enough processes can be dispensed with, it makes it more feasible. However, if almost all of the processes remain needed, standalone rounds is less practical.
* Application and activation is an important distinction. It appears to some that the majority of the processes would be needed for IDN variants as at the end of the day, they are gTLDs. The string and the applicant must be evaluated, and there are other elements objections, application comment, etc.
* There will three different views of the program: Applying for primary; primary and variants; just variants for an existing RO.
* What also makes things challenging is that next round of the New gTLD Program is not yet established.
* Would it be possible to apply for just a variant in the absence of a primary? No, the issue being raised is about an existing registry applying for/requesting activation of a variant.
* Primary is not absolute – it is what the applicant wants to be the primary.
