[Gnso-epdp-idn-team] Notes - IDNs EPDP Meeting #36 - 19 May 2022

[Ariel Liang]

Dear all,

Please find below the notes from today’s meeting on Thursday, 19 May 2022 at 13:30 UTC.

Kind regards,

Ariel, Steve, Emily


Action Items:

ACTION ITEM: Leadership and staff to develop a proposal to scope further outreach to the three GPs with respect to additional work.

Notes – IDNs EPDP Call – 5 May 2022

1. Roll Call & SOI (2 minutes)

2. Welcome & Chair Updates (5 minutes)

  *   Have received feedback from Chinese, Japanese, and Korean Generation Panels - A7 Part 2. Will cover that if there is time.
  *   Last call for feedback for the draft text for charter questions A7 part 1, A9 and A10.  Deadline is tomorrow at the close of business.  Will look at feedback and decide if there is anything to bring back to the WG if there are suggestions for amendments to the draft text.
  *   Attendance at ICANN74: Remind WG members that there are requests for responses to a survey to indicate if they will be attending the EPDP calls in person.  Even if remotely please still fill in the form answering “no”.

3. Continue discussion of charter question D2 (40 minutes)

Slide 4:

Charter Question D2: In order to ensure that the same entity principle is maintained for a gTLD and its allocated variant TLD labels, what are the operational and legal impacts to the:
● Registry Transition Process or Change of Control in the Registry Agreement;
● Emergency Back-End Registry Operator (EBERO) provisions; and
● Reassignment of the TLD as a result of the Trademark Post-Delegation Dispute Resolution Procedure (TM-PDDRP)?

Implicit Dependency with D1a: “Should each TLD label be the subject of a separate Registry Agreement with ICANN? If not, should each TLD label along with its variant labels be subject to one Registry Agreement with the same entity?”

Slide 10:

SubPro Context
To the extent that the TLD were to change hands at any point after delegation, the variant TLDs must remain linked contractually, which should be considered a persistent requirement (e.g., this would impact gTLD registry transition procedures, including EBERO).

Staff Paper Context

  *   Each of the registry agreements must contain provisions requiring all variant labels in the IDL set to follow the same process in the event of any registry transition via a Registry Transition Process or Change of Control.
  *   In no event, should the composition of the allocated and delegated set of variant TLDs be allowed to change at the same time as the change of the Registry Operator.
  *   Emergency transition of a TLD to an EBERO must trigger an emergency transition of all variant TLDs to the EBERO.
In the case where a Registry Agreement is terminated as a result of a TM-PDDRP determination, the same entity rule would continue to apply so that the allocated and delegated variant TLD labels in the set would be assigned to the same entity together.

Slide 11:

Questions for Discussion

  *   How to maintain the “same entity” principle in the event of a registry transition process, with respect to each of the three types?
  *   Are there any additional consideration related to the registry transition process involving variant gTLD labels?

Discussion:

  *   Continuation of the discussion from the last meeting.
  *   Implicit dependency with D1a.
  *   EBERO process vs. planned retirement of a variant:
     *   Subpro recommended that the variants should be linked contractually,  and should go along with the TLD.
     *   Question: How to maintain this “same entity” principle in the event of a registry transition process?
     *   Question: Should the EBERO process would be triggered for a TLD variant that was intentionally retired?  Answer: Procedurally it is not triggered.  The EBERO would not be triggered in a single case; it would be via a different process to ensure that it is done in a controlled manner.
     *   One additional Subpro requirement: if you have a second-level name variant under a TLD it must be linked with the same entity. Would need a mechanism to make sure that it stays registered to the same entity.
     *   Principle: How to maintain the same-entity rule.
     *   The purpose of the EBERO is to maintain the critical functions of the DNS.
     *   Maybe focus on what is expected for the controlled (intentional) retirement and EBERO.  May not need to consider the edge case of a forced retirement.
     *   Remember that EBERO is an emergency operator.
     *   Need to separate the retirement of a variant from the EBERO process.  Variants that operate under one registry agreement, if you look at the .wed case the primary reason was financial.  Couldn’t image one variant triggering EBERO it would have to be the TLD and its variants.  We shouldn’t confuse the retirement of a TLD and its variants with a TLD triggers the EBERO process.
     *   If you want to retire a variant TLD there is no reason to go into EBERO.  If you do go into EBERO then all of the variant TLDs should go into EBERO (if one goes, all should go).
  *   Seems that there is an agreement to maintain the same entity principle: if one variant goes into EBERO then all variants go.

4. Introduction to charter question D3 (30 minutes):

Slide 13:

Charter Question D3:  In order to ensure that the same entity principle is maintained, what are the operational and legal impacts to the data escrow policies, if any.

Slide 15:

Question for Discussion
Registry Data Escrow: The EPDP recommends that each gTLD and its variant labels (if any) are to be subject to one Registry Agreement with the same registry operator. Given this preliminary recommendation, do the technical specifications and legal requirements of the data escrow policy for gTLDs need to be adjusted in order to account for the possibility of having more than one label under one registry agreement?

Discussion:

  *   Assumption: Data escrow requirements apply to each TLD variant.
  *   This is about ensuring that the data is available in circumstances where something goes astray.  The registry operator can decide who their escrow provider is and this should be the same for the TLD and its variants, but we may need to make the explicit.
  *   Having one escrow for the provider and its variants makes it easier from a tech perspective.
  *   Current design is that each TLD has to have a separate escrow contract.  But, we shouldn’t try to require that all of the data of all the variants must be squeezed into the same file.
  *   In the escrow definition there is a field for variants.
  *   Wonder if we should provide implementation guidance about keeping the current practice of separate files for each TLD.
  *   Suggestion: Don’t see changes to the current practice of each TLD having its own data escrow provider, just that it must be the same provider for the variant subset under a TLD.

5. Feedback from Chinese, Japanese, and Korean Generation Panels - A7 Part 2 (10 mins)

Slide 17:

Charter Question A7: What mechanism or criteria should be used to identify the scripts/languages appropriate for single-character TLDs? Once those scripts/languages are identified, what mechanism or criteria should be used to identify a specific list of allowable characters which can be used as a single-character TLD within such scripts/languages? Should any specific implementation guidance be provided? Furthermore, should the relevant GP tag these code points in the RZ-LGR for a consistent analysis and to ease their identification and algorithmic calculation?

Slide 18:

Q1. What is the definition of ideograph or ideogram?
1a. Based on this definition, are all Han characters considered ideograph or ideogram?
1b. If not, does the definition clearly provide a way to identify which Han characters are ideograph or ideogram?

Chinese (Chair response): All Han characters are ideographs
Japanese (GP response): Except for “々” (U+3005), all Han (Kanji) characters are ideographs
Korean (GP response): All Han (Hanja) characters are ideographs

Slide 19:

GP Outreach: Questions 2 & 3:

Q2. Is it possible for the three GPs to coordinate and develop criteria by which to identify a subset of the Han script allowed for single-character gTLDs that present no risk of user confusion? Alternatively, is it possible to develop criteria by which to identify a list of Han characters that may introduce confusion risks that rise above commonplace similarities and should NOT be allowed for single-character gTLDs?
Q3. Is it possible for the three GPs to coordinate and develop criteria for the evaluation of future single-character gTLD applications in Han script, particularly in the context of string confusion, to ensure they are introduced to the root-zone in a conservative manner?

Chinese (Chair response):

  *   Difficult for three GPs to coordinate but may not be necessary as applications need to follow language rules not script rules
  *   Chinese-GP variant rules have eliminated the possibility of confusion risk to the maximum extent
  *   Family name characters and geo-location name characters are most liked be applied as single character TLD
Not all Han characters are suitable to be applied as a single character TLD. E.g., 丿 (U+4E3F), 乀 (U+4E40), 乁 (U+4E41) are used as basic radicals rather than full characters with semantic meaning

Japanese (GP response):
It may be safer to disallow Han characters that are defined as visually identical to Kana characters in Japanese RZ-LGR (see Section 7<https://www.icann.org/en/system/files/files/proposal-japanese-lgr-20dec21-en.pdf#page=14>), but it is up to Integration Panel and ICANN to decide

Korean (GP response):

  *   Several Hanja characters have the same pronunciation, and there may be risk to cause confusion
  *   Korean GP is willing to participate in further discussion about these criteria

Slide 20:

GP Outreach: Question 4:

Q4. Is it feasible for the three GPs to reconvene to conduct the above mentioned work, and if so, what is the estimated level of effort and time required.

Chinese (Chair response): A six-month period may be needed to generate a limited allowable list from the most conservative perspective
Japanese (GP response): No answer
Korean (GP response): Not sure how long it will take

Reminder that these are preliminary responses with the with an eye towards future coordination work to develop more full answers, but these are just the preliminary responses from the GP chairs.

Observations from Sarmad Hussain, Staff:


  *   Some general principles: For example, one principle is that if there is a character in Han script which may actually look similar to another character in another script example being Han or Congee character looking the same in as Congee characters in Japanese there may be a motivation to not include those characters in a single-character TLDs because, since there is no context available there is a possibility that that single character can be interpreted as the character in the other script, which means that we are possibly at least visually allowing a TLD which is probably a visual point of view – from a technical point of view.  So that’s one.
  *   A principle in the Japanese case was one more point, which is not included here, that's kind of a second principle which is also common with Chinese that there are some other characters which may not qualify for single character for various reasons.  One reason provided by Chinese cases that there are some basic radicals, which don't have a semantic meaning so they're not really into graphic in that sense.
  *   The other example which is not here, but shared by Japanese was the iteration mark where iteration mark means, of course, that it says that the character, before it is should be repeated, so it has to come after a character, it cannot come by itself.  Because, then you don't really know what is being iterated so you shouldn't really make a single-character TLD with an iteration mark so that's another kind of principle which is coming out.
  *   Korean case is a little more challenging because in in addition to visual sort of similarity you know string similarity is largely motivated by visual sort of analysis, but they are now going into pronunciation which is not entirely visual so that's sort of a discussion which we need to have, and also the need to have that whether such a criteria should be eligible for string similarity cases or not and so those are some of the points looking at it from a big picture point of view – what this also means is that there is really work which needs to be done by the GPs by these communities as well as perhaps the PDP working group to either document the principles or document the data or a combination of both to guide the strings similarity review process.

Discussion:

  *   Wondering whether we can consider having implementation guidance, or even a recommendation, in principle, to say that support the efforts of the C, J, K GPs to develop the criteria in order for the evaluation to be done, prior to the next round, so that there's a mechanism by which the evaluators can rely on to evaluate whether particular application for a single character TLDs is allowable or not.
  *   Another way to look or approach this is that the PDP now has these preliminary responses from the three GPs and there's an indication at least that they seem to be willing to work on the topic and willing to work together, even if it might be a little bit difficult so one of the plenary outcomes of this discussion could be that the PDP wants to request the GPs to undergo the more detailed work rather than just these preliminary responses and then you know with the knowledge that again it's going to take a little bit of time, but basically the conclusion could be that the PDP team likes the direction of the analysis and but is now requesting the three GPs to undertake a more rigorous analysis will work together to develop for answers and possibly the criteria.
  *   A possible way ahead is to actually go back to the GPs and request them to conduct that extra work, but when reaching out, I think it may be useful to make it clear what it is, I think what is needed is the scope of the work.  So, pronunciation, for example, a factor in determining confusability between 200 characters, that's something that the PDP working group should decide, or would decide that something which should be left to the generation panel so some of this discussion I guess also would be helpful here, so that when we reach out to GPs, we reach out with a clear scope of work.
  *   Leadership could take the action to develop something to progress the outreach to the three GPs. Leadership can have a look at what's been provided in terms of input today and to see how we want to scope the further outreach to the GPs to elaborate on what we think they need to do.
  *   Question re: the difference between Question 2 and 3: the difference between 2 and 3, is that 2 is looking at specific lists from two angles so 2 is a specific list of allowable or potentially a list of not allowed, whereas 3 is more about general criteria that would allow for single character on script strings to be accepted and delegated --  so question 2 is about specific lists of strings either allowable or dis-allowable whereas 3 is more about general criteria


ACTION ITEM: Leadership and staff to develop a proposal to scope further outreach to the three GPs with respect to additional work.

6. AOB (3 minutes): None.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-epdp-idn-team/attachments/20220520/88d67f79/attachment-0001.html>