Public Comment

Public Comment is a vital part of our multistakeholder model. It provides a mechanism for stakeholders to have their opinions and recommendations formally and publicly documented. It is an opportunity for the ICANN community to effect change and improve policies and operations.

Name: Mesumbe Tomslin Samme-Nlar
Date: 21 May 2024
Are you providing input on behalf of a group (e.g., ICANN community group, organization, company, government)?
Yes

If yes, please explain.

Non-Commercial Stakeholder Group - NCSG

Please indicate your response to Preliminary Recommendation 1
Support Recommendation as written
Please indicate your response to Implementation Guidance 2.
Support Recommendation as written
Please indicate your response to Preliminary Recommendation 3
Support Recommendation as written
Please indicate your response to Preliminary Recommendation 4
Support Recommendation as written
Please indicate your response to Preliminary Recommendation 5
Support Recommendation as written
Please indicate your response to Preliminary Recommendation 6
Support Recommendation as written
Please indicate your response to Implementation Guidance 7
Support Recommendation as written
Please indicate your response to Preliminary Recommendation 8
Support Recommendation as written
Please indicate your response to Preliminary Recommendation 10
Support Recommendation as written
Please indicate your response to Preliminary Recommendation 11
Support Recommendation as written
Please indicate your response to Implementation Guidance 12
Support Recommendation as written
Please indicate your response to Preliminary Recommendation 13
Support Recommendation as written
Please indicate your response to Preliminary Recommendation 14
Significant change required: changing intent and wording
Are there any comments or issues you would like to raise pertaining to the Rationale for Preliminary Recommendation 14? If yes, please provide your comments here.

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.


Please indicate your response to Implementation Guidance 15
Support Recommendation as written
Please indicate your response to Preliminary Recommendation 16
Support Recommendation as written
Please indicate your response to Implementation Guidance 17
Support Recommendation as written
Please indicate your response to Preliminary Recommendation 18
Support Recommendation as written
Please indicate your response to Implementation Guidance 19
Support Recommendation as written
Please indicate your response to Preliminary Recommendation 20
Support Recommendation as written
Are there any comments or issues you would like to raise pertaining to Section 3: Glossary (pages 11-28) of the Initial Report? If yes, please provide your comments here.

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.


Other Comments

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.


Summary of Submission

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.