Our understanding 

Preliminary Recommendation 14 is very confusing. Whenever we are talking about RDDS and registration data, a matter of great interest for many parts of the ICANN and Internet communities, we need to be very, very clear. 

We understand that this recommendation sets forth the ability of the IDN Registry to expand the data elements of their Registration Data Directory Services (RDDS) as one option for indicating variant domain names. 

We understand that there may be other alternatives as well for this type of data, which can include the provision of additional information or the enabling of other methods, such as bulk services, to provide the following information:

The required data elements for a given domain name in accordance with the Registration Data Policy.

All other allocated variant domain names under a given gTLD and its delegated gTLD variant labels, if any.

The source domain name used to calculate the variant domain set.

We are very concerned and object to the references to the use of RDDS in any way not currently widely discussed and debated by the community on RDDS. Who would have access to this additional data and under what circumstances? If this recommendation is in any way expanding access to RDDS, we object. If not, we ask for clarification. The entire community would appreciate it!

As the IDNs report does not introduce any new protocols or systems, we do need to clarify. Preliminary Recommendation 14 stipulates the necessity to display variant domain names linked to the primary domain. However, grandfathered domains are exempt due to the significant overhaul it would require for existing systems used by contracted parties, coupled with the lack of substantial demand for legacy second-level variant domains. Recommendation 15 suggests adding a flag to the RDDS system (whether RDAP or WHOIS) to achieve this.

Additionally:

Our ICANN policies must explicitly incorporate privacy and security considerations. The rationale should include a detailed discussion on the conditions that justify additional data access. This is to ensure that such access aligns with rigorous privacy standards and is equipped with safeguards to prevent data exploitation. We advocate for a transparent framework that balances operational needs with the paramount importance of user privacy and data security.

We appreciate the Glossary, and off an edit for consistency and accuracy.  The “Rights Protection Mechanisms PDP Working Group” should be discussed in the Glossary, just as the SubPro PDP WG is set out.  The discussion of the RPM PDP WG could be placed under the Rights Protection Mechanism entry, or just after, but since this working group, and its results, are referenced throughout this report in the context of URS, TMCH, etc, the Working Group must be referenced too. 

As will be discussed below, the excellent Glossary notwithstanding, there is a very difficult report to understand for the broader Community.  One thing missing is examples in an array of scripts. We need clear confirmation that different words, spelled the same in different languages, including with diacritic marks may coexist - just as they do in language today. 

We need to see examples in French and Spanish that show that the same string of characters, with the same accents, are not considered variants of each other. We need clear confirmation that this is true even if the same registry operator chooses to offer multiple gTLD IDNs in both French and Spanish scripts.This may be clear to the EPDP, but needs to be clarified for the larger ICANN Community.

Document Readability

The document is generally structured in a comprehensive manner; however, the dense legal and technical language could be a barrier to understanding for non-commercial stakeholders who may not have specialized knowledge in domain name systems or trademark law. The readability scores for the document are as follows: Flesch-Kincaid Grade Level: 12.96 and Gunning Fog Index: 16.37. These scores suggest that the document has a relatively high level of complexity:

These indices reflect that the document's text is complex and might be challenging for non-specialist audiences, particularly non-commercial stakeholders who may not have specific expertise in legal or technical domains. Clarifying and simplifying the language                                                                                                            providing summaries will enhance accessibility and understanding. We look forward to many more examples, in many more scripts, in the next version so everyone has variations they can read and understand.

Conclusion

In conclusion, the NCSG expresses its sincere gratitude for the chance to provide feedback and guidance on important ICANN policy matters as such. Our comments seek greater clarity on issues and address potential ambiguities that may confuse readers, especially those who are not used to ICANN's procedures and this particular technical language.

Regular summaries and less technical jargon could enhance readability and ensure that non-experts are not alienated from important discussions about domain name policies that may affect them. Our recommendations and comments are submitted in the hope that they will contribute to the clarity of these proposed rules and refine the Implementation Guidance to better balance operational needs with privacy and security requirements, thereby enhancing protection for all domain registrants. We, therefore, extend our thanks to the EPDP team who worked on this initial report.

The NCSG expresses its sincere gratitude for the chance to provide feedback and guidance on important ICANN policy matters as such. Our comments seek greater clarity on issues and address potential ambiguities that may confuse readers, especially those who are not used to ICANN's procedures and this particular technical language.

Regular summaries and less technical jargon could enhance readability and ensure that non-experts are not alienated from important discussions about domain name policies that may affect them. Our recommendations and comments are submitted in the hope that they will contribute to the clarity of these proposed rules and refine the Implementation Guidance to better balance operational needs with privacy and security requirements, thereby enhancing protection for all domain registrants. We, therefore, extend our thanks to the EPDP team who worked on this initial report.