Dear LD PDP WG, Please see below the action items and notes from Meeting #34. [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. Please review PR 1 and PR 39 * Staff and Leadership to prepare additional background information and examples on Edmon’s proposal * Alan to bring the query about fees to the Board and group to discuss whether to keep PR 18 and PR 19 in this context. [NOTES] 1. Welcome and SOI Updates 2. Recap of Meeting #32 a. Key Outcomes and Action Items * Reviewed the slides<https://icann-community.atlassian.net/wiki/x/AQA7PQ> for previous and ongoing AI’s. Discussed PR 29 and Edmon’s proposal of a “High-Risk Scenario” if the application contains more than X LD TLDs it would trigger for a structured evaluation. Options on where this may be added outlined in the slide<https://icann-community.atlassian.net/wiki/x/AQA7PQ> * Discussion about what “high-risk” would be defined, then what kind of evaluation would be different in the review process and would need to be clearly defined. The WG has to put more thought in defining all these aspects * Unclear whether high-risk is the registry or end user. Support for more precisely the scenario. * Sarmad, there is a possibility that we are going to include a string that could be a blocked label of existing TLD. If that is the case then it goes against RZ-LGR. Two strings could be considered similar to each other through the regular process. Through the exception process, those could be delegated, still allowing the string to move forward. There is some inconsistency across strings and the manageability issue where end-users get multiple strings under multiple TLDs. He raised some aspects that need to be assessed * Blocked variants could not be added to the LD set as that is handled in the scope. * Applicants will have to provide information how they implement the whole set so that it is manageable for registrars and registrants. * End user discussion of possible issues and risks. * Steve outlined the high-risk of consumers, a high number of LD/ASCII delegated at once especially at the point of registration. Then there are challenges with operating sets as registrants. Assuming that end users will not understand that these exist or how they work for end-user confusion. A number of opportunities where confusion and weaponizing that confusion may take place. * Proposed language by Edmon postponed to next meeting. * Edmon wanted to address some of the red flags of conservatism. At the end of the day it needs to go to implementation and the Board needs to decide that, so that is what motivated this suggestion. There are uncertainties in this process and that is the motivation from ICANN org and that is the motivation for this proposal. 3. Review of LD PDP Initial Report Public Comment * Continued on the slides<https://icann-community.atlassian.net/wiki/x/AQA7PQ> for PR18 and PR19 ICANN Board adopted EPDP IDNs 7.4 and 7.5 and ICANN org submitted comments on the Board’s rationale and concerns. * Cost recovery principle is just for the application phase. For the operations phase, these are just registry fees. * Ariel gave context on the Board rationale for EPDP-IDNs Board did not adopt these until late as there is a challenge for registry fees. This is not within the usual policy topics for Board’s consideration. Registry fees are normally not in the purview of WG’s. Add in the uncertainty and here if the LD PDP proposes these then the Board may delay to discuss and deliberate. The Board adopted it for EPDP IDNs but does not set a precedent for registry fees. It is not necessary for the LD PDP to answer this. * Goal of PDP is to create an exceptions process to co-exist next to each other. Rec 18 would reduce the fees otherwise the registry would have to pay the fixed fee for each TLD, but also saying that those registries should pay less fees. * If this recommendation goes forward for price will be reduced that this has a high chance of being rejected by the Board as EPDP IDNs was not precedent setting * Alan from the Board reiterated that 7.4 and 7.5 for EPDP IDNs, they felt it was not the place of the policy team to set the fees. * Proposal to simply delete these recommendations? Also, to go to the Board through the liaison to see where the Board might sit then the WG can adjust the recommendations to increase the likelihood of Board approval * Alan has agreed to take this query to the Board to raise it to get feedback. * Steve tried to contextualize this recommendation. IDN variants where the community and Board wanted to encourage it which is not what the LD PDP is trying to do. This exception process will likely present challenges for the Board. Also, should not give recommendations to the Board that are challenging for them. Delay and complications come as a result. WG should try to develop recommendations that can be adoptable by the Board * A few individuals recommended dropping the recommendations. * PR 2 and PR 3 discussed slides<https://icann-community.atlassian.net/wiki/x/AQA7PQ> and the ALAC comment highlighted. Dropping this requirement would make it technically impossible to have the same entity principle. Agreement on the same entity principle, ALAC clarified that this should be flagged for consumer choice even if it cannot be implemented. ALAC is okay with the current way of doing this based on the charter and a technical necessity * Request to add to the rationale that it is a charter requirement for PR2 and PR3 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>