2024-02-22 IDNs EPDP - Meeting #107

Notes/ Action Items

ACTION ITEMS

• IDN Table Harmonization: Leadership will discuss this draft text and work through a potential way forward to incorporate the Registries Small Team work into the P2 report, but also other feedback around potential changes to the third point in the text and also how everything interacts with question C5. 
• Updated Preliminary Recommendations: Staff and Leadership will draft an updated PR12 and IG 17 to best reflect the desires of the team by keeping the guidance generic but allowing a path forward.

NOTES

• Roll Call and SOI Updates (2 min)
• Welcome and Chair Updates (5 min)
• The Chair welcomed the team to the call
• IDN Table Harmonization Update (40 min)
• The small team from the RySG presented their findings on IDN Table Harmonization
• A draft of the text was circulated to the email list https://mm.icann.org/pipermail/gnso-epdp-idn-team/2024-February/001279.html
• This was communicated over the call and clarified with additional observations
• The original draft had conversations about IDN Tables. This was consciously moved away from by the small team
• Through conversations with ICANN org, there was a discussion that while IDN Tables are a solution, they're not the only solution
• This is a placeholder for future IDN Guidelines work groups to discuss and then implement
• A member of the EPDP Team asked why IDN tables were removed and commented that the recommendation does not clarify how harmonization is completed and; 
• There are two parts of the harmonization process.
• The process of how the table should be harmonized
• The data that is used 
• The new text does not specify which data should be used for harmonization.
• RZ-LGR is a representation of the script community and end users. It contains scripts and additional code points. It was the fallback baseline recommendation when the text was originally being discussed. 
• What was recently discussed was that the registries team was the RZ-LGR could work at the top level, but not for the second level.
• A second data set was recommended 
• Also recommended if a dataset could not be defined, then a followup action / IG could be created to get to this data.
• The current language is fine but does not provide a path to the data.
• It was asked if the circulated text above should supplement or replace the current text? 
• Unclear at this point, but it's possible to pull out the second point in the email and turn it into a recommendation, per the Chair, along the lines of harmonization at the second level is at the discretion of the registrar / registry / registrants, with a provision that future implementation guidelines would address this issue.
• Point 1 is a statement of fact. Point 2 could be used to draft a recommendation around and would replace what is in C5. The Chair does not want to lose what is currently in C5. Point 3 could be viewed as a starting point for the IDN Implementation Guideline Working Group.
• An author of the circulated text said it could be used to tease out a response for question C5 and not replace the current response. The text could also be used as implementation guidance.
• There is a “clear demarcation” for the 1st point in the text per a team member
• At the second level, it is up to the registries to implement harmonization.
• The rules from the root zone do not need to be applied directly to the second level, and is why the registries small team clarified this in the circulated text. 
• It was asked if there would be any willingness from the Registries small team to augment the second point in the text to incorporate details from the team member earlier around a path for data.
• The third point in the text was where there was room identified to incorporate this point, but there was a concerted effort to not specifically mention any process and constrain the text, per an author of the circulated text. If the text is a bit too high level, the registries small team would be amenable to updating the third bullet over the second. The second point for the registries is a sticking point at this time.
• With the principles and need to interpret them correctly, there may be a need to update the 2nd and 3rd points to describe the mechanism to make it more clear. Also potential to collapse into C4, but aiming for C5.

• [ACTION ITEM] Leadership will discuss this draft text and work through a potential way forward to incorporate the Registries Small Team work into the P2 report, but also other feedback around potential changes to the third point in the text and also how everything interacts with question C5. 

• As a summary, there is a recommendation that tables have to be harmonized. It was agreed that the team wouldn’t suggest “how”. The registries have not suggested the “how” but these are principles on how ICANN org and other stakeholders could work on this. There could be an IG to suggest this. A recommendation that says the implementation guideline working group could work on this shouldn't hold up the IRT or hold up the next round as a dependency. 
• Close Loop on Draft Recommendations (70min)
• Updated Preliminary Recommendations 12 and 14
• PR12
• Text was proposed by a team member to elevate the recommendation to not focus on the protocol but to discuss the services rendered and how the behavior should be shaped.
• Registration data services returns information on registered / existing domain names / objects. Unallocated variants being introduced to this system would not be a great use case for RDAP. 
• Since RDAP is the replacement protocol for WHOIS, it was included in the D8 response when the text was drafted. It was suggested to replace RDAP with RDDS in a comment on the text. The intent from this comment is to differentiate between the protocol (WHOIS and RDAP) and the service (RDDS). 
• RDDS may be safer to use in case the protocol is replaced in the future. It refers to both current protocols. It is up to the requester which service to use (RDAP vs WHOIS) 
• It may be difficult to find a one size fits all answer for PR12. RDAP may not have to be replaced by RDDS in all cases. 
• The team must be very clear with their terminology. RDDS is in registry contracts and refers to both RDAP and WHOIS. It was suggested that using RDAP could make registry jobs more complicated.
• It was asked what the authoritative source for an end user to determine the complete data set?
• The authoritative source would be the registry. The registry determines the set. The list of potential variants could be registered, unregistered, delegated, undelegated, etc. 
• Clarity for what information is being asked for here could be important. 
• RDDS will not solve all of the problems here, but it is an improvement to RDAP. 
• Text was submitted as a consideration to replace PR12.
• In the case of a variant, it should be possible for a registrant to look up the full variant set. The query should overcome the potential confusion on if a name is part of a variant set. Some registrars have a way to display that information, but the team discussions are working on ways to overcome similar issues.
• The intent is clear but the terminology is to be determined. 
• Proposed initial draft from staff would mention that the user must be able to see allocated and source domains to calculate the variants with additional text that would not specify the protocol or service (keep it generic) and this was preliminarily welcomed by the team.
• There was caution to use “should” instead of “must” when drafting that idea.

• [ACTION ITEM] Staff and Leadership will draft an updated PR12 and IG 17 to best reflect the desires of the team by keeping the guidance generic but allowing a path forward.

• PR14 
• Proposed text was drafted for new PR14 and IG 18 to reflect recent discussions with ccPDP4.
• Implementation Guidance 18 being separated from the recommendation allows for flexibility in how this is carried out in terms of the level of detail of a charter. The elements / level of detail of the CSC Charter vs PDP charters was discussed as an example. Allowing the flexibility for the IDN Implementation Guidelines Working Group is the goal of this.
• The ccNSO discussion was very fruitful and one issue of concern was the charter being in the recommendation and it is why it was split off into implementation guidance.
• The process described to establish the work group was discussed.
• There were comments submitted about if the approval / documentation  process is a one time event or recurring. What is a triggering event to constitute the IDN Implementation Guidelines Working Group?  
• There was some desire to leave the text as is from some team members.
• No substantive changes to the PR or IG are needed, a sentence was deleted during this call within the rationale. 

• Glossary: Variant
• Staff walked the team through some of the updates made to glossary entries, specifically for “Variant”. Context and notes were provided for the new definition to ensure the understanding that “variant” is not used on its own. 
• There were no comments from the team.

• AOB (3 min)
• Due to discussions today, there will likely be a meeting at ICANN79 in San Juan (Saturday, 2 March at 9:00 am local time)