Dear all,

Please find below the notes from today’s meeting on Thursday, 18 November 2021 at 13:30 UTC.

Best regards,

Ariel, Steve, and Emily

Action Items:

Action Item #1: Drawing on the high-level agreements, leadership team to draft response to charter question A3 and corresponding recommendations for review by the EPDP.

Notes – IDNs EPDP Call – 18 November 2021

Welcome & Chair Updates

• The working group is currently running somewhat behind the anticipated schedule. There will be further discussion about whether adjustments will be needed to the call schedule to make up time or whether the work plan needs to be adjusted.

Continued Deliberations on Topic A

Charter question A3

• First, seek to agree on high-level points, and then the leadership team will draft a response to the charter question. Leadership will share this text on the mailing list and provide members with two weeks to review and provide feedback before we move on.
• High-level points for A3: 1. An applicant can challenge an evaluation determined by the DNS Stability Panel that the applied-for TLD label, whose script is supported by the RZ-LGR, is “invalid” 2. Eligibility for filing such a challenge is limited to the applicant’s belief that the DNS Stability Panel has incorrectly assessed the label as “invalid”. 3. The evaluation challenge processes and criteria applicable to the DNS Stability Review recommended in the SubPro Final Report should be used for such a challenge.
  • Comment: On the second point, should it also include cases where the applicant believes that the algorithm has been applied incorrectly (the application system is believed to be wrong)?
  • Response: Ultimately it will be the panel that will make the assessment. It may be helpful to add some clarification that the panel will be validating the outcome of the algorithmic check.
  • Support for the high-level points, although some additional detail is needed about the role of the panel.
• Review of applicable recommendations and implementation guidance from SubPro (see slide deck beginning on slide 6). For discussion: 1. Are any or all of the additional SubPro recommendation and implementation guidance applicable? 2. Should any additional implementation guidance be developed?
• The only IG item not included in the slides is 32.6, which only applies to appeals (not challenges) and is therefore is not applicable to the scenarios being discussed in this EPDP.
• Comment: This group needs to have a good reason to not accept any of the SubPro recs. The SubPro WG reached consensus on their recommendations.
• Response: It is still important to review the SubPro outputs to determine if they are applicable to the scenarios we are discussing. To the extent that we believe that they are not, we need to understand the implications and provide a rationale. This is a due diligence step and not intended to manipulate the recommendations from SubPro.
• Question: Did SubPro consider cases where an algorithm was part of the evaluation?
• Response: SubPro’s discussion focused on the outcomes of the evaluation and not specifically how the evaluations are done. In the end, there is going to be a DNS Stability Panel that validates the results of the algorithmic check. The tools used by the panel is not necessarily a relevant factor.
• General support expressed for the framework provided by SubPro. It is up to this EPDP to determine the thresholds for which a challenge can be triggered, but the general framework seems to work.
• Question: does there need to potentially be additional implementation guidance with respect to the human element of the evaluation?
• Response: We had envisioned that there would be a manual check of the algorithm’s ouput in all cases. Does this address the concern?
• Members confirmed that this addresses the concern, as long as it is explained in the EPDP recommendations/response to charter questions.
• Reminder: We do not need to adopt SubPro recommendations, we can just include in the charter question that the working group confirms that the SubPro outputs are fit for purpose.

Update on data gathering for charter questions A1 and A2

• Data collection task: Use the latest version of the RZ-LGR determine the variant labels of the 2012 New gTLD Round and determine whether the list of calculated variants match those that were identified by the applicant.
  • For New gTLD applications, there are two cases where there is a difference between self-identified variants and those calculated by the RZ-LGR, one likely related to a spelling variation and the other potentially a typo. There is also one ccTLD case.
• For potential further discussion: the definition of “variant” is the one from the RZ-LGR. Outside RZ-LGR a “variant” could be defined as something different e.g. spelling variant.
• The purpose of this exercise was to confirm that there is no significant difference between the variants calculated by the RZ-LGR and those self-identified variants from the 2012 round to confirm with the output of the RZ-LGR is consistent with the community’s expectations.
• Based on this data, it appears that if we decide that RZ-LGR is the sole source for existing gTLD labels, it won’t have a major impact on existing gTLD operators.
• Comment: It was not possible in the 2012 round to self-identify variants in an application for an ASCII TLD. Do we have to consider cases where applicant applied for an ASCII TLD and would have wanted to apply for a variant but were not allowed to do so? Example: . Quebec and .Québec.
• Response: This might be an opportunity for .Quebec for submitting a public comment on the Initial Report if they want specific use cases taken into account.
• Response: From one perspective, if .Québec is not a variant of .Quebec for the purposes of this group,  .Quebec can apply for .Québec as a separate application in the next round.
• It would be an interesting exercise but the purpose of the data collection in this case was to inform whether the two sets of variants coincide in order to determine how this should work for applicants who apply for variants in the future.
• There is no standard of variants outside of the RZ-LGR. There might be other instances where, since there was no definition, the applicant came up with their own variant, for example a spelling difference.
• Comment: RZ-LGR is good to use for the existing applied for TLDs. The few cases where self-identified variants are not in the RZ-LGR, they are alternative spellings and should therefore not be considered variant.
• If the RZ-LGR is used for existing gTLDs going forward, some of the self-identified variants would be blocked. Does this impact the WG’s thinking?
• Preliminarily, WG members provided feedback that this data should not impact the WG’s conclusion. The WG can return to this on the next call if it requires further discussion.

Charter question A2

• There are only a couple of cases in the data where self-identified variants are inconsistent with the list of variants generated by the RZ-LRG. It doesn’t seem that they have been used. Is this correct?
• The key here is the legal standing. Former applicants were informed that they would not have legal standing so they would not have claims to the self-identified variants. Those strings were for information purposes. That is the fundamental basis for us making our decision. In drafting the charter questions, it was brought to the group’s attention that these strings were used in some manner, for example in string similarity reviews. Therefore, this group may want to consider whether there is additional implementation guidance that needs to be applied for future processes. One possible assumption: For future processes, the RZ-LGR is used as the sole source, and that determines which variants you have a right to. This is for the working group to consider.
• Comment: Data appears to support that no further considerations are needed by this group.
• Question: Do we need to investigate if any of these variants that deviate were used in certain processes, such as string contention resolution, in the 2012 round?
• Comment: This may not be necessary to investigate further. One of the principles of SubPro is that to the extent that new rules are put in place in the New gTLD Program, those rules apply to the specific round and are not retroactively applied. Therefore, it might not be important how these strings were used in the past.
• Agreement that if it is time consuming, the additional data collection may not be necessary.
• Comment: To the extent that existing applicants from 2012 round want variants allocated to them going forward, new rules will apply.
• If there is a 2012 applicant for an IDN label and they requested variants at that time, there is a question about whether that application is still in the 2012 round or whether it ends up in a future round for the variants. This is something that may become clear as we work through the other questions.