DN IDN Table Harmonization: The RySG will deliberate this week and staff will request proposed language to be circulated ahead of the next meeting for a more efficient discussion/conclusion
Recommendation 12 (RDAP profile): Leadership to develop language that is an overarching/general recommendation
Recommendation 14: Staff to revise language and rationale (to refer to CSC Charter). Merging 14.2 and 14.3 and then reordering the items was suggested.
Glossary: Staff to draft “variants” in the context of IDN EPDP while Leadership finalizes review
Implementation Guidance 15 (Automatic activation): This was not covered during Team meeting and will be discussed in upcoming meetings or on the email list
NOTES
Roll Call and SOI Updates (2 min)
Welcome and Chair Updates (5 min)
The chair welcomed everyone to the call
Timeline Overview & Public Comment Approach (15 min)
The chair then briefed the team on the timeline, including a meeting (#107) next week on 22 February, leading all the way through the public comment break, and all the way until mid-May when meetings pick back up (#108 on 16 May)
Glossary Review (30 min)
Without substantive comments, the glossary entries will be accepted. Staff will make any grammatical or formatting changes that have been recommended.
One comment received was regarding the word “variant” and it was suggested that there could be an entry added to “variant” to clarify that this document always refers to IDN Variants when “variant” is mentioned.
In phase 1, “IDN” was specifically divorced from “variant” to allow for separation to occur but now there are suggestions for phase 2 to bring them back together?
ACTION ITEM: Staff to draft “variants” in the context of IDN EPDP while Leadership finalizes review for the glossary
Close Loop on Draft Recommendations (50 min)
Preliminary Recommendation 12: RDAP Query
The RySG Reported back on their discussions
There was a sense that RDAP might not be the right protocol to be used to identify variants
The volume might be overwhelming, per a team member.
It may be out of scope for the EPDP team to prescribe specific RDAP changes, including potential contractual issues
A different team member disagreed with this evaluation
This should not be a major issue to performance of RDAP as the work already has to be done by the Registry, per that team member.
It was suggested that the actions of the RDDS contract are specified (stemming from the Registration Data Policy EPDP) and this would change that
A team member recommended that the specificity of the PR12 should be changed to a recommendation for registries to review /update RDAP profile documents
Potentially the chair thought that specifics could be added to implementation guidance while the recommendation could stay general like in the suggestion.
Another team member talked about the difference between policy changes and contractual changes. While PDPs may change contracts, the specific language to the contracts are different from the language in the PDPs. If updates to the RDAP lead to megabytes of information included on each query, then there will need to be significant structural changes to RDAP and its SLAs.
If the result of such changes leads to significant increases in volume for output, than the SLAs should be reviewed
The Chair suggested the creation of a general recommendation that does not prescribe contractual changes but says the RDAP profile needs to account for variants, with specific context in the implementation guidance.
Another team member described the potential need for specific tasks within the policies
Registries should be much more amenable to this situation
ACTION ITEM: Leadership will look at creating a general recommendation with specifics in implementation guidance for PR 12
There is a need to update RDAP profile in response to a query to see variants and this needs to be clear why the recommendation is being made but then “should” statements like what to display when a query is received could be in the implementation guidance
Implementation Guidance 15: Automatic Activation
This was not covered during Team meeting and will be discussed in upcoming meetings or on the email list
Initial Feedback from ccPDP4 on Preliminary Recommendation 14: IDN Implementation Guidelines
The ccPDP4 team does not have significant concerns about the recommendation. There were some reservations on the specific language, which they allege may be a bit confusing.
“Working group” is mentioned twice but regarding different groups. Could there be modifiers to resolve confusion?
In terms of 14.1, who develops the process and what goes into the process of establishing the working group. This is well defined for the ccNSO processes, but not as clear here. Who is responsible for the actions in this recommendation?
Additional confusion on who would approve the Implementation Guidelines? GNSO? ccNSO? ICANN Board?
Regarding 14.2, there was confusion on the order of establishing the working group and establishing a charter.
The charter must be formalized before the working group is created and text should be updated to clearly define this.
14.3 may be combined with 14.2 for additional clarity
This was supported by multiple members of the team
ACTION ITEM: Leadership and staff will review PR 14 to revise language and rationale (to refer to CSC Charter) - Merging 14.2 and 14.3 and then reordering the items was suggested.
Other Comments
IDN Table Harmonization Update (15 min)
PR1 received a detailed discussion in the past, but there are still outstanding issues
There is a key component of harmonization not reflected in PR1. In Implementation Guidelines 4.0 there is a prescription to identify additional variant codepoints. Currently IDN variant tables don’t look at cross script codepoints and it would be beneficial to reference these points in the recommendation.
Recommendations from team members included referencing community work from the RZ-LGR.
There have been multiple meetings between the Registries and ICANN Org experts on this topic
Discussions are still ongoing and there is another call between the two on the 20th.
The recommendation language in C4 and C5 is generally okay per a member of the RySG, but the conversations center around how these changes could be implemented.
It was recommended by the chair that additional text should supplement the implementation guidance but not the recommendation language itself.
Draft text will be circulated internally within the RySG members to review before going out to the larger EPDP team
ACTION ITEM: The RySG will deliberate this week and staff will request proposed language to be circulated ahead of the next meeting for a more efficient discussion/conclusion
AOB (3 min)
IG 25.3 of the Sub Pro PDP says applicants can apply for labels in scripts not in RZ-LGR (it will not be delegated if the script is not in the RZ-LGR). The Phase 1 IDN EPDP report says that variants can be applied for if the script is in the RZ-LGR. It could be considered that IG 25.3 could be an overarching recommendation, while the IDNs recommendation could be a subset of the IDN labels and variants.
The chair stated that this EPDP was grounded in the principles of the RZ-LGR. It's possible that someone could apply for a variant that was not involved in the RZ-LGR process, but it may not be an inconsistency.
A team member echoed this latter argument. They can work in conjunction, but it is possible to view them as incongruent.
Staff reminded the team to review the documents that have been circulated for a final review before implementation into the initial report.
Staff also walked through the table of content for the P2 Initial Report.
For the P2 initial report public comment, a guided input form will be used.