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: At-Large Advisory Committee (ALAC) Policy staff in support of the At-Large Community
Date:30 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 with no issues.
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 Recommendations were issued in February 2019 and expected to be approved by the GNSO and Board in short order. The EPDP team (including representatives of contracted parties) understood that it would take some time to translate the recommendations in to policy and then to have contracted parties implement that policy. Accordingly, Recommendation 28 extended the validity of terms within the Temporary Specification to allow for the creation and implementation of the policy. After due consideration the EPDP team set a deadline for contracted party compliance at 29 February 2020 (1 year after issuance of the Phase 1 report). Clearly the EPDP team underestimated the amount of time needed to translate the recommendations into policy. However, the EPDP team, including registry and registrar representatives unanimously believed that the allowed period was sufficient for contracted party implementation. Given Recommendation 28, and the fact that these recommendations are reasonably consistent with the Temporary Specification, and that the differences have been well known now for several years, the ALAC believes that allowing an additional 18 months for contracted party implementation is excessive and uncalled for.

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 with no issues.
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 with no issues.
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 Final Report said "A separate timeline of [less than X business days] will be considered for the response to ‘Urgent’ Reasonable Disclosure Requests, those Requests for which evidence is supplied to show an immediate need for disclosure [time frame to be finalized and criteria set for Urgent requests during implementation]." It is important to note the definition of "URGENT" requests. “Urgent Requests for Lawful Disclosure” are limited to circumstances that pose an imminent threat to life, serious bodily injury, critical infrastructure, or child exploitation in cases where disclosure of the data is necessary in combatting or addressing this threat. Critical infrastructure means the physical and cyber systems that are vital in that their incapacity or destruction would have a debilitating impact on economic security or public safety. It is unfortunate that the report specified "business days" as the basis for the policy. That being said, to set it at TWO days in light of the definition of Urgent requests is totally unreasonable! It is not uncommon to have three consecutive non-business days resulting in a potential of 5 calendar days for responses to URGENT requests. The ALAC notes that the RAA already includes provision 3.18.2: Well-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. As such, registrars must already have staff who are able and authorized to respond to critical situation within 24 hours. There is no reason not to use these same capabilities for situations where there is imminent threat to life, serious bodily injury, critical infrastructure, or child exploitation. The ALAC also notes that 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).

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; however, the following clarification(s) are suggested. (Please provide the suggested language change.)

If B, C, or D, please elaborate.

The document gives the date the EPDP Team issued its Initial report and the date the GNSO Council adopted the Final Report, but should also give the date of the Final Report (20 February 2019).

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?
Yes
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?
Yes
Based on the requirements outlined in the Registration Data Consensus Policy, are the proposed redlined changes identified in the CL&D Policy correct?
Yes
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 EPDP recommendation on the transfer of data from registrars to registries makes the implementation of the Thick Whois policy difficult, but it does not make it impossible. This is particularly true for registrations the contain no personal information. Moreover, the recently approved EU NIS2 requires that registries and registrars publish publicly available data, and make available redacted data to legitimate users; AND that registrars and registries cooperate so that data does not need to be collected twice. That implies that if registrars are the prime collector of the data (as they are with gTLDs) that registrars must cooperate and provide registries with the data. NIS 2 notes that this obligation is sufficient legal reason for processing the registration data under GDPR Article 6.1(c). [NIS 2: Recitals 109-112 and Article 28]

Based on the requirements outlined in the Registration Data Consensus Policy, are the proposed redlined changes identified in the Transfer FOA Confirmation correct?
Yes
Based on the requirements outlined in the Registration Data Consensus Policy, are the proposed redlined changes identified in the Transfer FOA Initial Authorization correct?
Yes
Based on the requirements outlined in the Registration Data Consensus Policy, are the proposed redlined changes identified in the TDRP correct?
Yes
Based on the requirements outlined in the Registration Data Consensus Policy, are the proposed redlined changes identified in the Transfer Policy correct?
Yes
Based on the requirements outlined in the Registration Data Consensus Policy, are the proposed redlined changes identified in the UDRP correct?
Yes
Based on the requirements outlined in the Registration Data Consensus Policy, are the proposed redlined changes identified in the UDRP Rules correct?
Yes
Based on the requirements outlined in the Registration Data Consensus Policy, are the proposed redlined changes identified in the URS Procedure correct?
Yes
Based on the requirements outlined in the Registration Data Consensus Policy, are the proposed redlined changes identified in the URS Rules correct?
Yes
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?
Yes
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 Advisory Clarifications to the Registry and Registrar Requirements for Whois Data Directory Services correct?
Yes
Based on the requirements outlined in the Registration Data Consensus Policy, is the proposed the RDAP Technical Implementation Guide correct?
Yes
Based on the requirements outlined in the Registration Data Consensus Policy, is the proposed RDAP Response Profile correct?
Yes
Summary of Attachment

The At-Large Advisory Committee (ALAC) has submitted its comments via completion of this Public Comment proceeding form.


The official ALAC statement has been discussed by the Consolidated Party Working Group (CPWG) and formal ALAC ratification on this statement will happen this week.

 

Kind Regards,

ICANN Policy Staff in support of the At-Large Community

Summary of Submission

The At-Large Advisory Committee (ALAC) has comments and concerns in regards to the following sections of this Public Comment proceeding:

(1) Section 4: Effective Date

(2) Section 10: Disclosure requests

(3) Background Section of the Registration Data Consensus Policy

(4) Thick Whois Transition Policy