Hello LD PDP, Please find attached the outcomes, action items, and notes from meeting #37. There will be no call next week on 3 June, so we will see all of you in person or online in Seville. [OUTCOMES] * IG 11 agreement to delete “necessary” * Rec X agreement from the group to include, with some adjustments to wording necessary * PR 1 WG agreed with option 2 to utilize the expanded character scope with a limit * WG Agreement to require same entity principle at the 2nd level [ACTION ITEMS] * LD PDP WG to continuously review the Public Comment Review Tool<https://docs.google.com/spreadsheets/d/1lsDs0nV1Lh5Tf1CMZXOyxRRdKR0s9GMB-4BE...> and the proposed draft after each WG Meeting and provide input, if any. * Staff and Leadership to adjust wording of Rec X and add a rationale to clarify * Staff and Leadership to update PR 1 especially on 1.1, 1.2, and the unicode table based on WG decision to go with option 2 * Staff and Leadership to use concrete examples for PR 39 and explain the broader principles * Staff and leadership to update WG agreement to require the same entity principle at the 2nd level [NOTES] 1. Welcome and SOI Updates 2. Recap of Meeting #36 a. Key Outcomes and Action Items * Reviewed the slides<https://icann-community.atlassian.net/wiki/x/AoC2R> for key outcomes and action items * IG 11 was updated to give ICANN a bit more flexibility as outlined in slide<https://icann-community.atlassian.net/wiki/x/AoC2R> 7. ICANN org agreed with the edits. WG agreed to eliminate “necessary” * Option for Conservatism for Rec X was discussed and an overview given in the slides<https://icann-community.atlassian.net/wiki/x/AoC2R> with examples included. If you want to apply for ASCII and LD as a set, it is just saying they can’t be run by a separate registry. * Rec X will be written in the rationale to ensure that the meaning will be conveyed to give additional certainty and conservatism * Suggestion to replace “applicant” with “applications” in Rec X but overall agreement that some new wording will be needed * Agreement from the group for Rec X to move toward conservatism * PR 1 discussion on slide<https://icann-community.atlassian.net/wiki/x/AoC2R> 11. RZ LGR Option 2 is okay as it only includes characters from that, so there is no increase to the RZ-LGR. Whether there are other SSR issues, we cannot think of any, but will check back on that issue * Concern overall for a question for defining a diacritic and the Unicode approach was option 1, option 2 is the expanded character. * Broader discussion on all these character points have been used on the IDN tables, it is not about the code points, it is the definition of a diacritic, it is an arbitrary point by this group. All these points are in the RZ-LGR and the 2nd level. It is a question of what we consider a diacritic and the conservatism principle does not apply here and SSR is not an issue here * Ariel weighed in and noted that the WG has worked hard to the conservatism principle as a total package. There are already other steps introduced to make the application for LD/ASCII sets more conservative as a whole. * For PR 1 the group agreed to option 2 * PR39 overview given in the slides<https://icann-community.atlassian.net/wiki/x/AoC2R> with a robust discussion of Figure 3 from simple to complex cases. Even the experts are having trouble with the figures. It is better to explain the core principles for variants and ASCII/LD TLDs. If this group is confused, then likely we would need real examples * The general idea is that every label and all variants need to be in the same entity set. We also have to include all those labels in all the other TLDs and do a transitive closure on the variants. * PR39 and PR 40 continued for discussion at the 2nd level, and there is a comment from ICANN that the ASCII/LD has to be same entity at the top level, at the 2nd level there is not this requirement and it is left open to the registry operator * This is a crucial question about the main mandate to allow LD/ASCII TLD sets if we reduce the risk of user confusion. * Ultimately, for the DNS the 1st and 2nd level we may have contradictory policies. This does not reduce confusion, it actually increases confusion. With all of this, it is going away from the mandate that this group was given in the Charter. Amadeu referenced his email to his systematic review of PR39 and PR40 and the contradictory nature of allowing registries to determine the 2nd level. The primary concept is avoiding user confusion and not registry freedom. In general, this goes along with conservatism. * Examples given in the slides<https://icann-community.atlassian.net/wiki/x/AoC2R> 18 and 19 that 2nd level should not be left to registry discretion. This is inconsistent with the general rule for TLDs. Same entity principle should hold at the top level but at the 2nd level it is up to the registry and both ICANN and Amadeu argue it is inconsistent. * The group discussed this and was persuaded that the 2nd level should be consistent with the top level same registry principle for an LD/ASCII set. It is only enforcing policy rules for ASCII/LD sets. Proposal to set a high bar, not to prohibit. Theoretically a registry could do it differently. * Same entity principle there are very good reasons to enforce it at the 2nd level as this would create user confusion. * For the TLDs the diacritics should be the same, then it should be consistent as a registry at the 2nd level * General agreement that the same entity principle should apply at the 2nd level. Some disagreement as to whether there should simply be a very high bar for exceptional cases, or an outright ban. * Discussion that the solution may be a footnote that registries could apply for an amendment which is part of recommendation 42. 3. Review of LD PDP Initial Report Public Comment All the best, John R. Emery, Ph.D. Policy Development Support Senior Specialist Generic Names Supporting Organization (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) www.icann.org<http://www.icann.org>