The call for the IDNs EPDP team will take place on Thursday, 25 January 2024 at 14:00 UTC for 2 hours.

For other places see: http://tinyurl.com/njteu2d

PROPOSED AGENDA


  1. Roll Call and SOI Updates (2 min)
  2. Welcome and Chair Updates (5 min)
  3. Harmonization of IDN tables discussion (30 min)
  4. Variant Domain Set Definition (30 min)
  5. Proposed Approach for Deferred Items from Implementation Guidelines 4.0 (25 min)
  6. Proposed Approach for Coordination with ccPDP4 Regarding Implementation Guidelines  (25 min)
  7. AOB (3min)

 

BACKGROUND DOCUMENTS



PARTICIPATION


Apologies: Nigel Hickson, Nitin Walia, Amina Ramallan 

Attendance

RECORDINGS


Audio Recording

Zoom Recording (including audio, visual, rough transcript and chat)

GNSO transcripts are located on the GNSO Calendar

Notes/ Action Items


ACTION ITEMS

  • ACTION ITEM: Leadership requests Team’s review and input on the new batch of draft texts (Preliminary Recommendations and Glossary) by Friday, 2 February
  • ACTION ITEM: Further discussion will take place, but the Chair asked the RySG to have an update by 29 January for the Harmonization of IDN tables.
  • ACTION ITEM: Leadership and Staff to discuss further on including an individual section covering a brief response to the implementation guidelines regarding the proposed approach for deferred items. 
  • ACTION ITEM: leadership and staff will determine appropriate language for referencing the board/ specific working groups.
  • Staff to have an informal discussion with ccPDP4 on preliminary recommendation 14, as ccTLDs are the other impacted party of IDN Implementation Guidelines

NOTES

  • Roll Call and SOI Updates (2 min)
  • Welcome and Chair Updates (5 min)
    • The Chair welcomed everyone to the call and provided an update on tasks completed over the past two months.
    • Saewon Lee was introduced as a new member of the ICANN Policy Development Support Team and will be supporting this EPDP.
  • Harmonization of IDN tables discussion (30 min)
    • Groups of stakeholders got together to discuss IDN Table Harmonization
    • There was a discussion where certain registries may be interested in having common IDN tables as an option, but not a mandate.
      • This could be also for the benefit of registrars to have an open standard to add
    • ACTION ITEM: Further discussion will take place, but the Chair asked the RySG to have an update during the week of 29 January.
  • Variant Domain Set Definition (30 min)
    • A proposed explanation was added to the draft glossary
      • Per a team member, t1v1 hard to say if they are allocatable or blocked unless the source was determined. It was decided that each of the TLDs needed a source domain in order to determine the disposition of each. For example, s1v1 would be unable to be determined without a source domain for t1v1 stated.
        • At points in time, it may be hard to see the disposition of a domain (allocatable / blocked). As soon as a source is declared, then the other variants can be determined. 
      • Another team member shared that there may be two use cases for this broader domain set. 
        • One is for a registrant to register other variant TLDs
        • The other is that while it may not be relevant if a domain is allocatable or blocked, in some cases the disposition value is useful but may not be for others.
      • A comment in chat said “The entire set is established by the first source / primary domain…. if a registrant is not interested in the other variant domain names, then the registrar or registry do not care about it either. When the registrant decides he/she wants any of the variants in the variant TLD, then the coordination between rt/rr/ry happens.”
      • If we have a source registered for a given TLD, variant domain names and their disposition values can be calculated for a given TLD, and the set will consist of variant labels at the second level, but the disposition will be unknown. The set will remain the same but disposition cannot be determined. 
    • Staff presented an unresolved question “IF the second-level label of the source domain name is only valid under T1, but not under T1v1, what does the variant domain set consist of, also factoring in T1v1?”
      • If the two IDN tables are harmonized, the last code point in each table would be considered variants of each other.
      • Certain code points are included with certain rules. If code points are “out of repertoire” then there are procedures in the RZ-LGR. For harmonization, it would be good to have certain rules across tables, but you need to be consistent in order to do that. 
      • This relates to Preliminary Rec (PR) 5.
        • Should the above ideas be listed in the rationale for PR5? Should it be in PR5 itself?
          • This is an important recommendation for the purpose of understanding the source domain. There may be value in expanding on the second part of the recommendation, potentially in a footnote, but it is important not to devalue the recommendation. 
          • It was asked if the variant domain set changes between the two steps?
            • The set does not change but the disposition may change
            • Step 1 defines the set but with underspecified dispositions. Step 2 adds to the missing information on dispositions
          • There was discussion if this is an edge case or a general case
        • Should “out of repertoire” be used?
          • This term is used in the RZ-LGR, so it is appropriate. 
        • Staff will refine the rationale language for PR5, but will not change the recommendation itself.
        • ACTION ITEM: For Variant Domain Set Definition, Staff to include a rationale and refine the rationale language - but no need to change recommendation 5
  • Proposed Approach for Deferred Items from Implementation Guidelines 4.0 (25 min)
    • Leadership described their proposed approach to tackle the deferred items from the Implementation Guidelines 4.0.
    • There was a question if the group agreed with this becoming a section in the report?
      • It was agreed that the second level is out of scope with ccPDP4. Rationale in the report wouldn’t hurt (a brief response in the relevant rationale portion).
    • There were three potential scenarios mentioned as approaches: 
      • One is that the guidelines as stated are acceptable
        • Regarding country code policy, there has not been anything flagged in the guidelines as issues of concern.
      • The second is that they may be acceptable, but with an updated scope to reflect new recommendations
      • The third is that the guidelines are not consistent with recommendations and need to be redeveloped. 
        • These last two would have documentation of divergence between GNSO and ccNSO recommendations. 
    • ACTION ITEM: Leadership and Staff to discuss further on including an individual section covering a brief response to the implementation guidelines
  • Proposed Approach for Coordination with ccPDP4 Regarding Implementation Guidelines  (25 min)
    • Preliminary recommendation 14 is related to the charter question of whether the IDN guidelines should stay the same. There were recommendations for the development of future guidelines. 
    • Given that the guidelines impact the ccPDP4, there may be value in working with the ccPDP4 team on coming to a similar conclusion to avoid confusion.
    • ACTION ITEM: Staff to have an informal discussion with ccPDP4 on preliminary recommendation 14, as ccTLDs are the other impacted party of IDN Implementation Guidelines
    • There is no current liaison to ccPDP4.
    • It was mentioned that specific ICANN Board working groups should not be referenced in the recommendation, but leadership would rather not assign tasks to the board as a whole. 
      • ACTION ITEM: leadership and staff will determine appropriate language for referencing the board/ specific working groups.
  • AOB (3min)
    • ACTION ITEM: Leadership requests Team’s review and input on the new batch of draft texts (Preliminary Recommendations and Glossary) by Friday, 2 February
    • No call scheduled next week, but maybe the week afterwards at the usual time (Thursday 8 February at 12:00 UTC)
  • No labels