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.

Контент доступен только на следующих языках

  • English

Name: Registries Stakeholder Group (RySG)
Date: 21 Nov 2022
Please provide your feedback:
Section 1 accurately reflects the policy recommendations with no issues.
Please provide your feedback:
Section 2 accurately reflects the policy recommendations with no issues.
Please provide your feedback:
Section 3 accurately reflects the policy recommendations; however, the following clarification(s) are suggested. (Please provide the suggested language change.)

If B, C, or D, please elaborate.

Unless there is a compelling reason, all definitions in the policy should reside in this section. For example, Section 9.2.2. Defines “Redact”, and Implementation Note H defines “Creation Date”. For clarity, these definitions should be moved to Section 3.

Please provide your feedback:
Section 4 accurately reflects the policy recommendations with no issues.
Please provide your feedback:
Section 5 accurately reflects the policy recommendations with no issues.
Please provide your feedback:
Section 6 accurately reflects the policy recommendations; however, the following clarification(s) are suggested. (Please provide the suggested language change.)

If B, C, or D, please elaborate.

The RySG is aware that the global legislative environment continues to evolve and believes that a slight addition to Section 6.7 would add clarity to what is allowable as part of this section. Suggested amendment (additional text between **): 6.7. Registrar MAY collect additional data elements as required by its Registry-Registrar Agreement and/or the Registry Operator’s Registration Policy, **including if required by law**.

Please provide your feedback:
Section 7 accurately reflects the policy recommendations with no issues.
Please provide your feedback:
Section 8 accurately reflects the policy recommendations with no issues.
Please provide your feedback:
Section 9 accurately reflects the policy recommendations; however, the following clarification(s) are suggested. (Please provide the suggested language change.)

If B, C, or D, please elaborate.

For clarity, 9.2.1. should be separated into two separate sections as follows: (additional text between **) 9.2.1: Registry Operator and Registrar MUST apply the (deleted text: [following requirements]) **requirements of this Section 9** in RDDS if redaction of Personal Data contained in Registration Data is required in order to comply with applicable laws. 9.2.2: **Where redaction of Personal Data contained in Registration Data is not required by law,** Registry Operator and Registrar MAY apply the ( deleted text: [following requirements]) **requirements of this Section 9** IF (i) they have a commercially reasonable purpose to do so; OR (ii) where it is not technically feasible to limit application of the requirements of this section. In determining whether to apply the following requirements, Registry Operator and Registrar MAY, but are not required to, consider (i) whether Registration Data pertains to a legal person or contains Personal Data; and (ii) the geographic location of the Registered Name Holder or relevant contact.

Please provide your feedback:
Section 10 accurately reflects the policy recommendations; however, the following clarification(s) are suggested. (Please provide the suggested language change.)

If B, C, or D, please elaborate.

Section 10. Requires “Registrar and Registry Operator MUST publish on their homepage a direct link to a page where the mechanism and process for submitting Disclosure Requests is Detailed”. The relevant source recommendation, Recommendation 18, refers to the fact that “Registrars and Registry Operators must publish, in a publicly accessible section of their website, the mechanism and process for submitting Reasonable Requests for Lawful Disclosure”. The policy recommendations deliberately do not use the word “homepage” as this is not always the best or most appropriate place to provide the link. Some flexibility should be given to Registrars and Registry operators to make that determination.

Please provide your feedback:
Section 11 accurately reflects the policy recommendations with no issues.
Please provide your feedback:
Section 12 accurately reflects the policy recommendations with no issues.
Please provide your feedback:
Addendum I accurately reflects the policy recommendations with no issues.
Please provide your feedback:
Addendum II accurately reflects the policy recommendations with no issues.
Please provide your feedback:
Implementation Notes accurately reflect the policy recommendations with no issues.
Please provide your feedback:
Background Section accurately reflects the policy recommendations with no issues.
Summary of Submission

The Registries Stakeholder Group (RySG) appreciates the opportunity to comment on the Draft Registration Data Consensus Policy for gTLDs.  The RySG has noted a few areas where we believe slight changes will provide beneficial clarity for those implementing the policy but overall, the RySG is supportive of the policy. 

Further, the RySG did not specifically weigh in on each impacted policy in Part II of this comment as several are specific to individual operators, but are generally supportive of the work. 


The RySG appreciates the time and effort put forth by every participant across the community to craft this draft policy. We believe it provides an important baseline for registration data processing that will provide Registry Operators certainty and flexibility.