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: Business Constituency
Date: 5 Dec 2022
Affiliation: ICANN Business Constituency (BC)
Please provide your feedback:
Section 1 does not accurately reflect the intent of the Registration Data Consensus Policy. (Please provide an explanation including Recommendations from the EPDP-TempSpec Phase 1 or Phase 2 Final Report where there are inconsistencies and the suggested change to make this section consistent.)

If B, C, or D, please elaborate.

Section 1 should be updated to use the defined term “Processing” in Section 3.4. The Consensus Policy is applicable to all aspects of registration data, not just processing.

Please provide your feedback:
Section 2 does not accurately reflect the policy recommendations. (Please provide an explanation including Recommendations from the EPDP-TempSpec Phase 1 or Phase 2 Final Report where there are inconsistencies and the suggested change to make this section consistent.)

If B, C, or D, please elaborate.

The Scope as proposed in Section 2.2 goes beyond the purposes described in the data processing agreements since the data processing agreements do not reflect the purposes for which third parties can request the disclosure of the registration data under applicable law. The DPAs must be written to be consistent with the Consensus Policy and cannot create a carve out for the community recommendations. The EPDP Phase 1 team worked hard to document and detail the data processing activities and responsible parties associated with gTLD registration data in Recommendation #20 of the Final Report. This was necessary as it formed the foundation of the rest of the recommendations agreed to by the team. If DPAs included community recommendations, any changes or deviations from the community, no matter how small or nuanced, from the agreed-to text of Recommendation #20 would undermine the current consensus policy and thus require a detailed review and impact assessment. The BC is concerned that the (unpublished) DPA, the work of an opaque negotiation outside of the ICANN multistakeholder process, may in fact result in a situation where the GNSO and Board approved Phase 1 consensus policy would become irrelevant. This limitation contradicts the policy as recommended by the EPDP since it does not address recommendation 1, (including Purpose 2 regarding third party purposes). As a result, Section 2.2 should be deleted, or include a reference to these purposes. One additional concern: because Data Processing Agreements (DPAs) are not yet negotiated, it is difficult to determine what the "purposes identified in the Data Processing Agreement" are. Further, implementation note A provides for transfer of data that may be outside the scope of this policy. Without knowing what the DPA will specifically contain, it is difficult to comment on the impact of Note A. In addition, DPAs may be renegotiated by the parties. As a result, it is necessary to establish a process for community comment on any changes.

Please provide your feedback:
Section 3 does not accurately reflect the intent of the Registration Data Consensus Policy. (Please provide an explanation including Recommendations from the EPDP-TempSpec Phase 1 or Phase 2 Final Report where there are inconsistencies and the suggested change to make this section consistent.)

If B, C, or D, please elaborate.

Delete 3.9, or specifically call out the definitions in those agreements since there may be contradictions or unintended consequences. For example, the terms "natural person" and "legal person" are not defined. While these terms often have standard meanings in a country's laws, those standard meanings differ from country to country. To facilitate better compliance with privacy regulations in the future, these terms should be defined. Definition of “Urgent Requests” is too narrow and should include “imminent or ongoing serious cybersecurity incidents” (such as those deriving from large scale ransomware, malware or botnet campaigns, which may for example affect consumer protection and would require an immediate need for disclosure) regardless of whether the target is critical infrastructure.

Please provide your feedback:
Section 4 does not accurately reflect the intent of the Registration Data Consensus Policy. (Please provide an explanation including Recommendations from the EPDP-TempSpec Phase 1 or Phase 2 Final Report where there are inconsistencies and the suggested change to make this section consistent.)

If B, C, or D, please elaborate.

The EPDP Final Report called for implementation of the recommendations one year from the Report (which was published in 2019 (almost three years ago). There is no reason that the EPDP’s recommended proposed timeline for implementation should be ignored. By the time the final policy documents are approved and the 18 month period begins to run, it will likely be implemented in late 2024, which will be over 5 years from the Final Report, which is highly problematic for an expedited policy process.

Please provide your feedback:
Section 5 does not accurately reflect the intent of the Registration Data Consensus Policy. (Please provide an explanation including Recommendations from the EPDP-TempSpec Phase 1 or Phase 2 Final Report where there are inconsistencies and the suggested change to make this section consistent.)

If B, C, or D, please elaborate.

The second paragraph of section 5 should be updated to be treated the same as the Registrar agreements since the EPDP Phase 1 Policy did not update or eliminate the Thick WHOIS policy. As a result, all registries would need to have DPAs in place. In adopting the EPDP Phase 1 Recommendations, the Board resolution on May 19 confirmed the thick whois policy and specifically called for the EPDP Phase 2 Report to determine whether thick whois policy was to be altered. See the Scorecard for Recommendation 27: Adopt Recommendation. Phase 2 should examine and transparently report on whether these Recommendations require modification of existing Consensus Policies including, specifically, the Thick WHOIS Transition Policy. Since the Phase 2 Report did not identify thick whois as one that required modification, the Thick WHOIS policy cannot be eliminated through the IRT’s work. Moreover, the implementation plan is not consistent with the GNSO’s subsequent resolution with regard to the thick WHOIS policy. On Jan 21, 2020, the GNSO attempted to reconcile the thick whois policy with the EPDP Phase Recommendation. In doing so, it resolved that: The GNSO Council determines that the Recommendation #7 language, "must be transferred from registrar to registry provided an appropriate legal basis exists and data processing agreement is in place" should be included in the Registration Data Policy in order to conform with the intent of the EPDP Phase 1 Team's policy recommendation and the subsequent GNSO Council adoption ("GNSO Council Input"). This did not overrule thick whois but it instead confirmed its existence and required a data processing agreement to be in place with the registries. This reading is consistent with Recommendation 19, where it states that: The EPDP Team recommends that ICANN Org negotiates and enters into required data protection agreements, as appropriate, with the Contracted Parties. And Recommendation 20 where it recognizes that there is a registrar and registry purpose to access personal data: To establish the rights of a Registered Name Holder in a Registered Name; to ensure that a Registered Name Holder may exercise its rights in the use and disposition of the Registered Name Recommendation 20 then identifies the legal basis for registries and registrars to process the personal data as 6(1)(f) or 6(1)(b). Since NIS2 has been adopted (following the EU parliament vote on 10 Nov and Council’s vote on 28 Nov), there is an additional legal basis applicable (Compliance with law), so the implementation of thick whois is consistent with EU law. Specifically, Recital 109 of NIS2 states that: “For that specific purpose, TLD name registries and entities providing domain name registration services should be required to process certain data necessary to achieve that purpose. Such processing should constitute a legal obligation within the meaning of Article 6(1), point (c), of Regulation (EU) 2016/679.” As a result, Section 5 must not divert from the EPDP’s language and require DPAs for all registries. As a result, the new IRT proposed text needs to be stricken because it is inconsistent with the Final Report: STRIKE “Where such agreements between Registry Operator or Registrar and ICANN are required to comply with applicable law“ STRIKE "upon request" from "ICANN MUST upon request and without undue" STRIKE "If Registry Operator or Registrar determines that such agreements are required by applicable law, Registry Operator and Registrar MUST make the request without undue delay pursuant to this policy. In any event, it’s important to note that DPAs are not required to transfer data that is not covered by GDPR - such as the data of legal persons. As a result, transfer of non-personal data as required by the EPDP policy needs to be implemented. Because DPAs are not yet negotiated, it is difficult to comment with specificity. Further, the DPAs may be renegotiated at a later time, based on one party's determination that applicable law now requires changes to the DPA. Because these DPAs form a critical element of the implementation and understanding of this policy, there should be some opportunity for community comment and input on these changes. Finally this paragraph needs to be modified, since it creates a loophole that can go beyond what is necessary to comply with applicable law: The data protection agreements MAY also be modified and updated from time-to-time as necessary to comply with applicable law based on additional guidance from relevant data protection authorities as provided for by applicable law. Finally, it's important to note that DPAS are not required to transfer data that is not covered by GDPR - such as the data of legal persons. As a result, that portion of the policy needs to be implemented.

Please provide your feedback:
Section 6 does not accurately reflect the intent of the Registration Data Consensus Policy. (Please provide an explanation including Recommendations from the EPDP-TempSpec Phase 1 or Phase 2 Final Report where there are inconsistencies and the suggested change to make this section consistent.)

If B, C, or D, please elaborate.

In 6.1, Registrars should not have an option to exclude the Organization Field when collecting registrant data, since it is a mandatory field for any registrant that is an Organization. As a result, 6.1 needs to be updated to require Organization after the Name Field. In 6.1, Registrars should not have an option to exclude Technical Fields, since it is a mandatory field if the registrant elects to provide it. As a result, 6.1 must be updated to require these fields as reflected in the table in the Phase 1 Final Report. The Reseller Field also is required to be listed in the fields collected by the Registrar in 6.1, as was clear in the EPDP Phase 1 Final Report. Reseller can be left blank if the Registrar does not use resellers. But reseller data needs to be processed if the data is provided, per the Final report in the footnote where it says “In both cases, if data is provided, it must be processed.” (Footnote 7 on page 7 of the final report) The WHOIS Server field is also required and was not a drafting error as suggested by the Report: ““Registrar Whois Server” value is only required to be generated if required by the Registrar Accreditation Agreement or ICANN Consensus Policy.(See“Drafting Error” 2)” This element needs to be preserved. As a result, the last sentence of 6.1 must be deleted. Indeed the sentence is inconsistent since it states that “Registrar Whois Server” value is only required to be generated if required bytheRegistrar Accreditation Agreement or ICANN Consensus Policy.(See“Drafting Error” 2).” Since the EPDP Phase 1 Final Report IS creating a consensus policy, it’s obvious that the Registrar WHOIS Server IS now a requirement going forward since the Final Report correctly lists the Registrar WHOIS Server as a requirement in the table for Recommendation 5. Regarding the deletion of the Administrative Contact, we note that implementing this change will violate the newly adopted NIS2 language which requires the collection of specific data in Article 28 , Section 2 including: “the contact email address and telephone number of the point of contact administering the domain name in the event that they are different from those of the registrant.” As a result, the Consensus Policy should also require the collection, transfer and disclosure of the Administrative Contacts.

Please provide your feedback:
Section 7 does not accurately reflect the intent of the Registration Data Consensus Policy. (Please provide an explanation including Recommendations from the EPDP-TempSpec Phase 1 or Phase 2 Final Report where there are inconsistencies and the suggested change to make this section consistent.)

If B, C, or D, please elaborate.

The Reseller Field MUST be transferred if data resides in the field. Reseller can be left blank if the Registrar does not use resellers. But reseller data needs to be processed if it exists, per the Final report in the footnote where it says “In both cases, if data is provided, it must be processed.” (Footnote 7 on page 7 of the final report)

Please provide your feedback:
Section 8 does not accurately reflect the intent of the Registration Data Consensus Policy. (Please provide an explanation including Recommendations from the EPDP-TempSpec Phase 1 or Phase 2 Final Report where there are inconsistencies and the suggested change to make this section consistent.)

If B, C, or D, please elaborate.

The Reseller Field MUST be escrowed if data resides in the field. Reseller can be left blank if the Registrar does not use resellers. But reseller data needs to be processed if it exists, per the Final report in the footnote where it says “In both cases, if data is provided, it must be processed.” (Footnote 7 on page 7 of the final report)

Please provide your feedback:
Additional concern or issue identified in Section 9. (Please describe further.)

If B, C, or D, please elaborate.

Paragraph 9.2.1 allows the redaction of non Personal Data contained in the Registration Data if there is a "commercially reasonable," purpose to do so. The fundamental purpose of the specification is to facilitate compliance with applicable privacy law. Whether redaction of non-personal data impacts a Registry Operator or Registrar's commercial business is beyond the scope of the process. More to the point, the use of the broad term "commercially reasonable" without definition undermines the fundamental purpose of a specification by inserting significant ambiguity into the specification. Furthermore, the proposed implementation is not consistent with the new requirements of NIS2 and must be updated to ensure that all non-personal data be published free of charge. Specifically, Recital 112 states: “Member States should ensure that all types of access to personal and non-personal domain name registration data are free of charge. “ There is no reason that implementation of the NIS2 publication requirements can’t be included in the consensus policy at this time, especially since it would not be “commercially reasonable” to violate NIS2, and because “technical feasibility” cannot excuse compliance with NIS2. Article 28 Section 4 states that: “Member States shall require the TLD name registries and the entities providing domain name registration services to make publicly available, without undue delay after the registration of a domain name, the domain name registration data which are not personal data. “ The implementation of the Consensus Policy should accommodate the new requirements rather than incorporate terms (such as the illegal redaction of legal person’s data), that will cause the Consensus Policy to be out of compliance with NIS2.

Please provide your feedback:
Section 10 does not accurately reflect the intent of the Registration Data Consensus Policy. (Please provide an explanation including Recommendations from the EPDP-TempSpec Phase 1 or Phase 2 Final Report where there are inconsistencies and the suggested change to make this section consistent.)

If B, C, or D, please elaborate.

The BC supports the GAC’s comment regarding Section 10.1 - quoted below: “The GAC supports inclusion of information on registrar websites pertaining to the mechanism and process for submitting Disclosure Requests, however, the GAC notes that a) any requestor seeking unredacted information may not know to look there, and b) the requestor has already viewed the single best channel for sharing such mechanism and process information: the published registration data itself. The GAC therefore suggests the publication of such “mechanism and process” information within the Registration Data as follows: “9.1.1 In responses to RDDS queries, Registrar and Registry operator MUST Publish the following data elements:” … 9.1.1.12 A direct link to a page where the mechanism and process for submitting Disclosure Requests is detailed.” Additional comment to subparagraph 10.6: urgent requests require immediate assistance. Phishing and fraud schemes. Section 3.18.2 of the RAA states that “[w]ell-founded reports of Illegal Activity submitted to these contacts must be reviewed within 24 hours by an individual who is empowered by Registrar to take necessary and appropriate actions in response to the report.” Since registrars already have staff who are able and authorized to respond to critical situations within 24 hours, this same timeline should apply to reveal requests for critical requests. In addition, since the recently approved EU NIS 2 Directive allows an absolute maximum of 72 hours for response to ALL requests for access (not just critical requests), the policy should conform to this new requirement rather than have contracted parties adopt a standard that will not satisfy these new requirements.

Please provide your feedback:
Section 11 does not accurately reflect the intent of the Registration Data Consensus Policy. (Please provide an explanation including Recommendations from the EPDP-TempSpec Phase 1 or Phase 2 Final Report where there are inconsistencies and the suggested change to make this section consistent.)

If B, C, or D, please elaborate.

11.1.2 should be MUST maintain log files to confirm relay of communications from requestor to tech email address. Rec #13 explicitly says “and which shall contain confirmation that a relay of the communication between the requestor and the Registered Name Holder has occurred” Additionally, all of the log file requirements should be amended to allow logging of information that is not Personal Information.

Please provide your feedback:
Section 12 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.

Rec #15 arrived at 18 months as an “interim”retention period. The final determination of retention period may be longer, based on legitimate purposes identified through community consultation.

Please provide your feedback:
Additional concern or issue identified in Section 13. (Please describe further.)

If B, C, or D, please elaborate.

Web-based lookups are required under the Registrar Accreditation Agreement.

Please provide your feedback:
Addendum II does not accurately reflect the intent of the Registration Data Consensus Policy. (Please provide an explanation including Recommendations from the EPDP-TempSpec Phase 1 or Phase 2 Final Report where there are inconsistencies and the suggested change to make this section consistent.)

If B, C, or D, please elaborate.

This should be clarified to require that the RNH field have an accurate value before deleting the Organization Field provided by the registrant. Rec #12 says, “If the registrant declines, or does not respond to the query, the Registrar may redact the Organization field, or delete the field contents. If necessary, the registration will be reassigned to the Registered Name Holder.” Implementation says, “Prior to deleting Registrant Organization value, Registrar MUST ensure that the value for the required Registered Name Holder Data element in Section 6.1.9 has been collected.

Please provide your feedback:
Implementation Notes do not accurately reflect the intent of the Registration Data Consensus Policy. (Please provide an explanation including Recommendations from the EPDP-TempSpec Phase 1 or Phase 2 Final Report where there are inconsistencies and the suggested change to make this section consistent.)

If B, C, or D, please elaborate.

This implementation should be paused to take into account the approved EU NIS2 Directive (Nov-2022) and the required transposition by EU member states. Specifically: Publication requirements, specifically for legal persons Accuracy and proactive verification requirements for registrant data Legal basis for processing, transfer from registrar to registry, and disclosure Disclosure requirements, with standards for response and service level

Please provide your feedback:
Background Section does not accurately reflect the intent of the Registration Data Consensus Policy. (Please provide an explanation including Recommendations from the EPDP-TempSpec Phase 1 or Phase 2 Final Report where there are inconsistencies and the suggested change to make this section consistent.)

If B, C, or D, please elaborate.

Background does not reflect important considerations for the work of the EPDP: Original mandate from the Board for developing policy that “preserves Whois to the greatest extent possible while complying with GDPR” check and cite. Background should document that the WG was asked to develop policy that could evolve with changes in GDPR interpretation by courts and member states, and the majority rejected that request. With the NIS2 adopted in Nov-2022, it is now clear that evolution should be part of the implemented policies. Background should explain specifically how EPDP recommendations could possibly lead to making it optional for registries and registrars to maintain Thick Whois consensus policy. Specifically, the background should document Thick Whois changes after the policy was adopted by the board (Scorecard).

Based on the requirements outlined in the Registration Data Consensus Policy, are the proposed redlined changes identified in the AWIP correct?
Yes
Based on the requirements outlined in the Registration Data Consensus Policy, are the proposed redlined changes identified in the ERRP correct?
No

If no, please explain why the suggested changes are incorrect and provide any suggested changes.

The recommended changes include dropping the term “Registrant” and replacing with “Registered Name Holder.” This change was not part of the recommendations and this change makes the policy inconsistent with prior policies that refer to “registrant”. This policy should make clear that Registrant and "Registered Name Holder" are synonymous.

Based on the requirements outlined in the Registration Data Consensus Policy, are the proposed redlined changes identified in the Protection of IGO and INGO Identifiers in all gTLDs Policy correct?
No

If no, please explain why the suggested changes are incorrect and provide any suggested changes.

The recommended changes include dropping the term “Registrant” and “domain name registrant” and replacing with “Registered Name Holder.” This change was not part of the recommendations and this change makes the policy inconsistent with prior policies that refer to “registrant”. This policy should make clear that Registrant, “Domain Name Registrant”, and “Registered Name Holder” are synonymous.

Based on the requirements outlined in the Registration Data Consensus Policy, are the proposed redlined changes identified in the CL&D Policy correct?
No

If no, please explain why the suggested changes are incorrect and provide any suggested changes.

The requirement for maintaining a WHOIS lookup web based service on the contracted parties website’s should not be eliminated. See the BC’s comments to the RDAP implementation posted at https://www.icann.org/en/public-comment/proceeding/proposed-amendments-to-the-base-gtld-ra-and-raa-to-add-rdap-contract-obligations-06-09-2022/submissions/icann-business-constituency-bc-16-11-2022

Based on the requirements outlined in the Registration Data Consensus Policy, are the proposed redlined changes identified in the RNAP correct?
Yes
Based on the requirements outlined in the Registration Data Consensus Policy, are the proposed redlined changes identified in the Revised ICANN Procedure for Handling Whois Conflicts with Privacy Law correct?
Yes
Based on the requirements outlined in the Registration Data Consensus Policy, are the proposed redlined changes identified in the Thick Whois Transition Policy correct?
No

If no, please explain why the suggested changes are incorrect and provide any suggested changes.

The proposed changes is to eliminate Thick Whois transition for COM, NET, and Jobs: “As of [INSERT Registration Data Policy Effective Date] all requirements of this Policy have been superseded by the Registration Data Policy.” However, final NIS2 text approved 10-Nov-2022 by the Parliament and approved by the Council on 28 Nov 2022 requires Thick Whois. Specifically Article 28 states that “...member states shall require TLD name registries and entities providing domain name registration services to collect and maintain accurate and complete domain name registration data in a dedicated database with due diligence in accordance with Union data protection law as regards data which are personal data. “ So this Policy Recommendation would require Thick Whois: “Registry Operator and Registrar are not required to establish legal basis to process Personal Data, including transfer from Registrar to Registry Operator, if not required by applicable law” As EU member states begin transposing NIS2, applicable law will require registrant data transfer to all registries. So instead of eliminating the Thick WHOIS requirement, the Registry operator for COM, NET, and JOBS should propose a new transition policy, possibly drawing upon the prior transition policy and implementation plans.

Based on the requirements outlined in the Registration Data Consensus Policy, are the proposed redlined changes identified in the Transfer FOA Confirmation correct?
No

If no, please explain why the suggested changes are incorrect and provide any suggested changes.

The EPDP Phase 1 Policy did not authorize these changes: - The change of “registrant” to “registered name holder.” - The deletion of “ in the event of a dispute the Registered Name Holder’s authority supersedes the administrative contact’s authority” - Footnote 1 which incorrectly attempts to define “Registered Name Holder” This definition is inconsistent with RAA Section 1.16 where it states that "Registered Name Holder" means the holder of a Registered Name. The IRT did not have authority to redefine definitions in the RAA. - Elimination of the “Transfer Contact” throughout. - Elimination of the Form of Authorization. Indeed they create security risks since Forms of Authorizations (FOA) were intended to make transfers more secure by preventing domain name hijacking. When DPAs are implemented and more contact information is available (such as when NIS2 requirements apply to the data of legal persons and/or natural person registrants consent to the publication of their information), the FOAs should be required rather than eliminated. - Addition of the “where required pursuant to Section I.A.2.” throughout, such as in Section 2.2.1., 2.2.4, 4.1, 4.3 - Registrant Transfers- Deletion of 1.1.4 in Section II.A. Instead - technical contact should be substituted for the administrative contact. These changes are not necessary to implement the Phase 1 Policy and should be deleted. In addition, more work is needed to determine whether it would be more appropriate to substitute the “technical contact” for the “administrative contact” in the transfer policy since there may be instances where the technical contact may be more closely aligned with what was formerly the administrative contact. Indeed, this creates a security risk when there are multiple contacts (registrant and tech contact), and the registrant is unresponsive or goes out of business. Examples of where this might arise could be situations where the reseller or privacy/ proxy service is the registrant, and the technical contact is the customer of the reseller, privacy/proxy service. This is especially important when more registrations reflect registrant information that apply to resellers or privacy/proxy providers. Instead, the policy should replace “administrative contact” with “technical contact” to have an additional way of enabling the transfer.

Based on the requirements outlined in the Registration Data Consensus Policy, are the proposed redlined changes identified in the Transfer FOA Initial Authorization correct?
No

If no, please explain why the suggested changes are incorrect and provide any suggested changes.

The EPDP Phase 1 Report did not authorize these changes: - The elimination of a second form of authorization in the FOA. As a result, the policy should reflect “technical contact” in lieu of “administrative contact” throughout. - The elimination of a reference to a “WHOIS database”. The changes assume that there are no contacts in the RDS database that are public, yet ICANN policy clearly requires contacts to be published when the registrant consents, and there may be legal requirements such as NIS2 where the data of legal persons is required to be published. These changes are not necessary to implement the Phase 1 Policy and should be deleted.

Based on the requirements outlined in the Registration Data Consensus Policy, are the proposed redlined changes identified in the TDRP correct?
No

If no, please explain why the suggested changes are incorrect and provide any suggested changes.

The EPDP Phase 1 Policy did not authorize these changes: - The change of “registrant” to “registered name holder.” - Elimination of the “Transfer Contact” throughout. - Elimination of the Form of Authorization. Indeed they create security risks since Forms of Authorizations (FOA) were intended to make transfers more secure by preventing domain name hijacking. When DPAs are implemented and more contact information is available (such as when NIS2 requirements apply to the data of legal persons and/or natural person registrants consent to the publication of their information), the FOAs should be required rather than eliminated. - The deletion of a duplicate form of authorization - instead of eliminating the “administrative contact “ throughout, it should be replaced with the technical contact. These changes are not necessary to implement the Phase 1 Policy and should be deleted. See above for explanation for why these changes are inappropriate.

Based on the requirements outlined in the Registration Data Consensus Policy, are the proposed redlined changes identified in the Transfer Policy correct?
No

If no, please explain why the suggested changes are incorrect and provide any suggested changes.

The EPDP Phase 1 Policy did not authorize these changes: - The change of “registrant” to “registered name holder.” - The deletion of “ in the event of a dispute the Registered Name Holder’s authority supersedes the administrative contact’s authority” - Footnote 1 which incorrectly attempts to define “Registered Name Holder” This definition is inconsistent with RAA Section 1.16 where it states that "Registered Name Holder" means the holder of a Registered Name. The IRT did not have authority to redefine definitions in the RAA. - Elimination of the “Transfer Contact” throughout. - The requirement of a “secure method of transfer” in Section 2.2.1 before any registration data can be transferred. No secure method of transfer is needed for information that is publicly available. When DPAs are implemented and more contact information is available (such as when NIS2 requirements apply to the data of legal persons and/or natural person registrants consent to the publication of their information), this information can be shared without further restrictions as imposed by proposed implementation. - Elimination of the Form of Authorization. Indeed they create security risks since Forms of Authorizations (FOA) were intended to make transfers more secure by preventing domain name hijacking. When DPAs are implemented and more contact information is available (such as when NIS2 requirements apply to the data of legal persons and/or natural person registrants consent to the publication of their information), the FOAs should be required rather than eliminated. - Addition of the “where required pursuant to Section I.A.2.” throughout, such as in Section 2.2.1., 2.2.4, 4.1, 4.3 - Registrant Transfers- Deletion of 1.1.4 in Section II.A. Instead - technical contact should be substituted for the administrative contact. - The language regarding “best practices” for generating AuthCodes should be strengthened to require the generation of AuthCodes, with the “best practices” to apply to how they are transmitted. These changes are not necessary to implement the Phase 1 Policy and should be deleted. In addition, more work is needed to determine whether it would be more appropriate to substitute the “technical contact” for the “administrative contact” in the transfer policy since there may be instances where the technical contact may be more closely aligned with what was formerly the administrative contact. Indeed, this creates a security risk when there are multiple contacts (registrant and tech contact), and the registrant is unresponsive or goes out of business. Examples of where this might arise could be situations where the reseller or privacy/ proxy service is the registrant, and the technical contact is the customer of the reseller, privacy/proxy service. This is especially important when more registrations reflect registrant information that apply to resellers or privacy/proxy providers. Instead, the policy should replace “administrative contact” with “technical contact” to have an additional way of enabling the transfer.

Based on the requirements outlined in the Registration Data Consensus Policy, are the proposed redlined changes identified in the UDRP correct?
No

If no, please explain why the suggested changes are incorrect and provide any suggested changes.

The EPDP Phase 1 Report did not authorize these changes: - The elimination of a reference to a “WHOIS database”. The changes assume that there are no contacts in the RDS database that are public, yet ICANN policy clearly requires contacts to be published when the registrant consents, and there may be legal requirements such as NIS2 where the data of legal persons is required to be published. - Footnote 1 should be deleted since there is no reason to replace “WHOIS database” with Registration Data. These changes are not necessary to implement the Phase 1 Policy and should be deleted.

Based on the requirements outlined in the Registration Data Consensus Policy, are the proposed redlined changes identified in the UDRP Rules correct?
No

If no, please explain why the suggested changes are incorrect and provide any suggested changes.

The EPDP Phase 1 Report did not authorize these changes: - The elimination of a reference to a “WHOIS database”. The changes assume that there are no contacts in the RDS database that are public, yet ICANN policy clearly requires contacts to be published when the registrant consents, and there may be legal requirements such as NIS2 where the data of legal persons is required to be published. - Footnote 1 should be deleted since there is no reason to replace “WHOIS database” with Registration Data. - In Section 2(a)(2) - the insertion of “Registration Data Directory Service (hereinafter “RDDS”) or in the Registration Data provided by the Registrar or Registry Operator when the Registration Data is redacted in the RDDS” is not needed. When there is a Redacted Contact in the public RDDS queries, the unredacted RDDS would still be available to be provided under the Rules. This change implies that the Registrar can list other data (such as customer data) beyond the unredacted information - which is clearly not possible. These changes are not necessary to implement the Phase 1 Policy and should be deleted.

Based on the requirements outlined in the Registration Data Consensus Policy, are the proposed redlined changes identified in the URS Procedure correct?
No

If no, please explain why the suggested changes are incorrect and provide any suggested changes.

The EPDP Phase 1 Report did not authorize these changes: - In Section 4(2) - the insertion of “or to the addresses listed in the Registration Data provided by the Registrar or Registry Operator when the Registration Data is redacted in the RDDS,” is not needed. When there is a Redacted Contact in the public RDDS queries, the unredacted RDDS would still be available to be provided under the Rules. This change implies that the Registrar can list other data (such as customer data) beyond the unredacted information - which is clearly not possible. These changes are not necessary to implement the Phase 1 Policy and should be deleted.

Based on the requirements outlined in the Registration Data Consensus Policy, are the proposed redlined changes identified in the URS Rules correct?
No

If no, please explain why the suggested changes are incorrect and provide any suggested changes.

Section 4 should replace the new “Registrant Data” with “RDDS”.

Based on the requirements outlined in the Registration Data Consensus Policy, are the proposed redlined changes identified in the URS Requirements correct?
Yes
Based on the requirements outlined in the Registration Data Consensus Policy, are the proposed redlined changes identified in the WDRP correct?
No

If no, please explain why the suggested changes are incorrect and provide any suggested changes.

The EPDP Phase 1 Policy did not authorize these changes: - The change of “registrant” to “registered name holder” throughout. - In the first paragraph the replacement of “Registration Data” is incorrect since Registration Data includes information that is not generated by the Registrant. - The deletion of the requirement to send the notice to a duplicate contact - instead of eliminating the “administrative contact “ throughout, it should be replaced with the technical contact. More work is needed to determine whether it would be more appropriate to substitute the “technical contact” for the “administrative contact” in the WHOIS Data Reminder Policy since there may be instances where the technical contact may be more closely aligned with what was formerly the administrative contact. Indeed, this creates a security risk when there are multiple contacts (registrant and tech contact), and the registrant is unresponsive or goes out of business. Examples of where this might arise could be situations where the reseller or privacy/ proxy service is the registrant, and the technical contact is the customer of the reseller, privacy/proxy service. This is especially important when more registrations reflect registrant information that apply to resellers or privacy/proxy providers. Instead, the policy should replace “administrative contact” with “technical contact” to have an additional way of ensuring that the information provided is accurate.

Based on the requirements outlined in the Registration Data Consensus Policy, are the proposed redlined changes identified in the Whois Marketing Restriction Policy correct?
Yes
Based on the requirements outlined in the Registration Data Consensus Policy, is the proposed the RDAP Technical Implementation Guide correct?
No

If no, please explain why the suggested changes are incorrect and provide any suggested changes.

As stated above the BC believes that Web-based lookups must continue to be required under the Registrar Accreditation Agreement. An obligation to only respond to RDAP queries using a non-human readable/parsable network protocol is insufficient to ensure Internet users have access to Registration Data as required by the ICANN bylaws.

Based on the requirements outlined in the Registration Data Consensus Policy, is the proposed RDAP Response Profile correct?
No

If no, please explain why the suggested changes are incorrect and provide any suggested changes.

As stated above the BC believes that Web-based lookups must continue to be required under the Registrar Accreditation Agreement. An obligation to only respond to RDAP queries using a non-human readable/parsable network protocol is insufficient to ensure Internet users have access to Registration Data as required by the ICANN bylaws

Summary of Attachment

The attached PDF is in lieu of completing this form, since the attachment includes formatting that should assist readers in identifying line breaks, lists, text excerpts, strike-throughs, etc.

Summary of Submission

The final NIS2 text was adopted by the European Parliament on 10-Nov-2022. The BC and other members of the EPDP frequently cited pending NIS2 regulation in our advice to create evolution mechanisms for registrant data policy. Unfortunately, the EPDP Working Group and GNSO Council did not follow that advice.

NIS2 now requires EU Member States to enact regulation that may render some EPDP policy recommendations in conflict with law. Specifically, NIS2 requirements to publish registrant data for legal persons, requirements to maintain accurate registrant data, and potentially requirements for registries to maintain registrant data (i.e. Thick Whois).

The BC therefore recommends that implementation of EPDP Phase 1 and Phase 2 be reassessed after the first EU Member State implements regulations pursuant to NIS2.

This comment was drafted by Margie Milam, David Snead, and Steve DelBianco. It was approved in accord with the BC Charter.