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.

Contenido disponible solo en los siguientes idiomas

  • English

Name: Brian King
Date: 5 Dec 2022
Affiliation: IPC
Please provide your feedback:
Section 1 accurately reflects the policy recommendations with no issues.
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.

Section 2.2 is incorrect and inappropriate as drafted. This policy’s scope is not limited to only the purposes listed in yet to be created Data Protection Agreements “DPA” (and assuming agreements are in place, they would be subject to change over time). The scope of this policy clearly includes the following processing, notwithstanding the existence of further Data Protection Agreements: collection; processing; publication; and, importantly, disclosure to third parties as required by this policy and/or governing law. The absence of required DPAs has put numerous initiatives at ICANN in limbo. This certainly true for any type of program that contemplates data management and access. The IPC reiterates the urgency of ICANN completing negotiations with the Contracted Parties to facilitate data processing and data access to the benefit of the entire multistakeholder community.

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.

Section 3.10 appears to be inconsistent with contract drafting principles and should be deleted in favor of explicit language being used throughout where necessary. This is a matter of good business practice and should be employed to avoid the current confusion that exists with ICANN contracts with vague or imprecise language.

Please provide your feedback:
Section 4 accurately reflects the policy recommendations with no issues.
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 first paragraph does not need to be policy language, but it does need to be acted upon. It is unacceptable to implement this policy without first having these critical agreements in place. The intent and the language of the policy recommendations require agreements at the outset; postponing the implementation of agreements contravenes the policy. Such an outcome is contrary to intent and the language of the policy recommendation, and should not be supported by the community, and is not supported by the IPC. The second and third paragraphs are absolute misinterpretations of the policy. The relevant recommendation is meant to be binding on ICANN to enter into the agreements, and is not meant to create an obligation for a Contracted Party to take this up with ICANN. This was clearly the intent of the EPDP team, as evidenced by the plain language of the policy recommendation. The final paragraph should say “from relevant sources” (which could include e.g. courts of law), and should not be limited to “data protection authorities” which are uniquely European and which most likely does not include all relevant authorities.

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.

The “are to” language in Recommendation 5 does not use MUST language, so there is no binding policy language and 6.3 should be MAY.

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.

7.3 neither captures the intent of EPDP Phase 1 nor is it compatible with Thick WHOIS policy, nor is it appropriate policy language. Again, it is inappropriate for this policy to contemplate that data processing agreements may not be in place, because the policy recommendations and this policy itself requires such agreements. Moreover, whether a legal basis exists is and will be a matter of fact, not of opinion. Even if it were a matter of opinion, it is ICANN’s opinion as the enforcer of this policy and the Thick WHOIS policy which must control, not the CP’s opinion. Recommendation 7 did not contemplate that CPs would be able to eliminate the Thick WHOIS policy merely by deciding by themselves that “no legal basis exists.” This intention was subsequently confirmed by both the Board and GNSO Council. However, the language as drafted in Implementation Note B would produce such an unacceptable result and therefore must be deleted.

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.

Any and all data elements collected or generated must be escrowed.

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

If B, C, or D, please elaborate.

9.1.7 Reseller MUST be published if present/provided. 9.1.10 These MUST be published if present/provided. The first MUST in 9.2.1 should be MAY - ICANN is in the business of enforcing policy requirements, not in the business of enforcing laws. In the fourth line of 9.2.1, the word MAY conflicts with the word “requirements.” A different word should be used (“options”?) since ICANN clearly does not intend these to be requirements. The 9.2.1(i) and (ii) carve outs are unacceptable. Each of (i) and (ii) would render this portion of the policy unenforceable as they would permit contracted parties sole discretion to do as they please. Such an outcome would be unacceptable. 9.2.4 should include the Org field in the list which registrar MUST provide the opportunity for the RNH to consent to publication and which consent registrar MUST honor. 9.2.6 insufficiently captures this as it does not explicitly require the registrar to offer the option. In Sections 9.2.2.3 and 9.2.2.4 - Registries should be required to publish if they have the Org and City data elements.

Please provide your feedback:
Section 10 accurately reflects the policy recommendations with no issues.
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.

As drafted, 11.1.1 and 11.1.2 are impossible for CPs to comply with in modern logging software. The redactions/removals called for are overly burdensome in their redaction requirements to the point where they actually conflict with the rest of the good logging requirements in Section 11. It is almost understandable if contents must not be logged, but a log that does not contain the sender or recipient would be useless to the community.

Please provide your feedback:
Section 12 accurately reflects the policy recommendations with no issues.
Please provide your feedback:
Additional concern or issue identified in Section 13. (Please describe further.)

If B, C, or D, please elaborate.

It seems this implicitly excludes RDAP(?), which doesn't make sense.

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

If B, C, or D, please elaborate.

As noted in previous comments from many parts of the community, it would be irresponsible to allow Contracted Parties to delete Registrant Organization data. This risks fundamentally and irreparably changing the entity responsible for domain name ownership, which is an unacceptable outcome.

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.

As noted above, Implementation Note B.3 and B.4 are inappropriate and unacceptable.

Please provide your feedback:
Background Section accurately reflects the policy recommendations with no issues.
Based on the requirements outlined in the Registration Data Consensus Policy, are the proposed redlined changes identified in the AWIP correct?
No
Summary of Submission

The IPC appreciates the opportunity to comment on this draft policy, and we thank ICANN staff and the IPT for its herculean effort.

Among the concerns listed above, a primary concern for the IPC is that - as required by the EPDP policy recommendations - ICANN must enter into DPAs with Contracted Parties before it can implement this policy, not after.

ICANN must also ensure that this policy does not have the effect of overriding the important Thick WHOIS policy, which will be aided by the timely execution of DPAs. Specifically, ICANN must amend this draft policy to be clear that ICANN has the authority to determine whether a legal basis exists for processing WHOIS data. Failure to correct this language would result in the unacceptable outcome of Contracted Parties having sole discretion to determine at their convenience whether to comply with the Thick WHOIS policy, an outcome which would contravene the Board and community's stated intent that this policy not supersede or undo Thick WHOIS.