[Gnso-epdp-idn-team] Notes and Action Items from IDN EPDP Meeting #105
Daniel Gluck
daniel.gluck at icann.org
Wed Feb 14 07:00:59 UTC 2024
Hi All,
Please find below the notes and action items from last Thursday’s (Feb 8, 2024) IDN EPDP Meeting #105<https://community.icann.org/x/d4D6EQ>
Thanks!
Ariel, Steve, Saewon, and Dan
ACTION ITEMS
* Leadership and the registries will review the D8 Team Response comments and get back to the team.
* Staff will update D8 EPDP Team response to clarify #3 to “3) The source domain name used to calculate the variant set that the queried domain name is a part of, if applicable"
* Staff will look at PR 6 to incorporate “there is some view” instead of “some members
* The team will review the glossary before the next call and update the document accordingly
* Staff will revise text in Rec 13 to remove the clause about the accuracy between the HTML and TXT versions of the Root Zone Database
* Staff will remove IG 9 in response to ICANN org comments.
NOTES
* Roll call and SOI updates (2 min)
* There was an SOI update from Anil Kumar Jain.
* Welcome and chair updates (5 min)
* The chair welcomed everyone to the call and noted the greater than usual amount of apologies due to the lunar new year.
* Second reading of draft recommendation text & glossary – review of input received (60 min)
* Leadership and staff are still waiting on Team feedback on harmonization tables
* Comments were received for the D8 EPDP Team Response
* Does the team want to make any rules regarding querying a domain that is not registered / allocated, but has allocated variants?
* This may depend on how registry systems work and it also might already be accounted for.
* If non registered domain names should be included, there should be further explanation. When talking about RDAP in other areas it is not explicitly stated that it means
* If the team wants to include all allocated variant domain names, then they should include them all and not just a subset of the listing, per a participant and later echoed by another.
* Since we are talking about the variant set, then all variants under variant TLDs should be included. The source domain name under the TLD should be included at a minimum, variant TLDs should be included in RDAP.
* If RDAP requests are per TLD, what kind of complexities are being added?
* This could potentially be too heavy of a lift for registries?
* From chat: ”without response to domains that are un"registered" but actually in an existing domain registration set of variants would add a huge burden on registrar systems actually”
* Potentially a minimal recommendation that says something along the lines of “it would be good to encapsulate the variant domain set” but the team will not be sure if this is necessary until a better understanding of the concept is achieved.
* Does the team have an agreement on a preliminary recommendation? Initial thoughts include potentially keeping the text as is and leadership will discuss a path forward.
* Does the context for “domain name” need to change in the first line of the D8 Team Response?
* ACTION ITEM: Leadership and the registries will review the D8 Team Response comments and get back to the team.
* Comments were also received to improve on subsection 3 in the first bullet on calculating the variant domain set.
* "3) The source domain name used to calculate the variant set that the queried domain name is a part of, if applicable"
* This suggestion was Accepted by the team
* ACTION ITEM: Staff will update D8 EPDP Team response to clarify #3 to “3) The source domain name used to calculate the variant set that the queried domain name is a part of, if applicable"
* There was a question about the process about GNSO and ccNSO PDP mechanisms.
* The GNSO PDP does not impact the ccNSO. The consequences are different and they do not have to abide by what is made in this group.
* There was an edit made to PR 5 during the call to reflect best practices in RFC 2119.
* Under the Rationale for PR 5, there were discussions over redline text. There was agreement from the team to accept the redline text under this section.
* Under the Rationale for PR 6 there was a discussion about the use of “some members” in the text. This could be tweaked to sound a bit better.
* ACTION ITEM: Staff will look at PR 6 to incorporate “there is some view” instead of “some members”
* ACTION ITEM: The team will review the glossary before the next call and update the document accordingly.
* Review of ICANN org SMEs’ comments for draft recommendations (20 min)
* There was additional feedback from SMEs within ICANN that will be considered regarding the TMCH on charter question F1.
* The registries that have established variant registration policies essentially concern both ROs that block variants and those that allow activation. There is the possibility that there could be allocation without activation.
* Per Section 4.1.3 of the Trademark Clearinghouse Rights Protection Mechanism Requirements, the RO, in both situations (block variants vs. activate variants), needs to check all labels (i.e., allocatable and blocked) in a variant label set against the Domain Name List recorded in the TMCH before any domain names from the set are registered.
* There was a question from a team member if this is just for registries that activate variants?
* No.
* The suggested action for this recommendation is to not make any changes to the text. A footnote could be created for context but that is not necessary.
* Agreement from the team was given for this recommendation of no action
* Regarding Recommendations 12 and 13, IANA Staff members provided feedback
* On Rec 12: There are no plans to implement an RDAP server at the IANA level for variant TLDs.
* No concerns about the recommendations but wanted to clarify a comment
* From a team member, there are questions about implementation. Will the team have to go back and reinvent the wheel? Is it possible for the EPDP to develop technical standards? Based on the comments from IANA there are different opinions on how to proceed.
* From a leadership perspective, there is no action required. Potential benefit to make the recommendation clearer relating to the intent, but not necessary at this time.
* The Chair asked the team if somebody was to query a domain through RDAP and it turned out to be an unallocated variant, could someone attempt to register that domain?
* The understanding is that the registrant would have to be the person for whom the variant is reserved. Due to the same entity principle, if there is an existing domain in the variant set, it would be reserved for whoever owns the entity.
* By adding things onto RDAP that don’t create value, is the team spending its time wisely?
* It could add value if you could query non existing domain names. If a set exists, but a variant is unregistered, it would be beneficial to users for them to see that in a query of all of the variant set.
* Users can make any query, it's up to the registry / registrar on how to answer. Some TLDs answer that a string cannot be registered or reserved. Some do not because they do not have to. It is up to the contracted party to give the level of detail requested by the Chair.
* On Rec 13: There were concerns about a comment in the rationale for Recommendation 13. During the workshop it was discussed the accuracy between the HTML and TXT versions of the Root Zone Database. IANA disagrees with this characterization.
* Staff asked if the rationale should be modified in Rec 13 to account for IANA comments?
* The chair is in favor of removing the rationale text in Rec 13 as it is not necessary for the text and the team agreed.
* ACTION ITEM: Staff will revise text in Rec 13 to remove the part about the accuracy between the HTML and TXT versions of the Root Zone Database.
* On Rec 8 and IG 9, There were IANA staff comments that IG 9 would delay Rec 8. Staff asked the team if they would require IG 9?
* Leadership is in favor of removing IG 9 as it is unclear if it's beneficial at this time.
* The team agreed. Since it is already a “Should” clause and already weak
* As it is already written, it can be interpreted that this should be delayed pending the URDP review, but that is not the intent of the team.
* ACTION ITEM: Staff will remove IG 9 in response to ICANN org comments.
* Update from ccPDP4 on Preliminary Recommendations 14 (10 min)
* ccPDP4 welcomed EPDP IDN policy staff to present to their group and provide an introduction to the preliminary recommendation. The ccPDP4 team will present to the ccNSO council and there should be an update from the ccNSO and ccPDP4 team by Friday, 16 Feb.
* Draft section to address deferred guidelines from IDN Implementation Guidelines version 4.0 (20 min)
* For Implementation Guidance 15, There was a question if automatic activation should be allowed or be only considered for where generally the community agrees with the need?
* This was raised because automatic registration poses a challenge for registrants (Someone applies for 1 and gets 4, can be challenging to manage). SAC060 notes this challenge.
* Some comments from the team said they could see the reasoning that some automatic activation could be sensible, but also that it should be restricted.
* May have an impact, for example, that a registrant applying for Simplified Chinese may want to automatically receive the Traditional Chinese variant automatically. In the IDNs guidelines, this was only applicable to Chinese.
* There was a point that the team should not be overly prescriptive, specifically in implementation guidance. We could go further on IG 15.2, but also valid to not expand further.
* AOB (3 min)
* Next call will take place next week. Looking longer out, there will be two calls before ICANN79, with a meeting still planned for ICANN79.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-epdp-idn-team/attachments/20240214/b9846eca/attachment-0001.html>
More information about the Gnso-epdp-idn-team
mailing list