Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data

Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data
Status:	Active
Issue Areas:	Domain Name Registrant Data
Date Established:	2018/07/19
Charter:	WG Charter
Workspace:	Community Wiki

The Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data (EPDP) was initiated by the GNSO Council on 19 July 2018 to determine if the Temporary Specification for gTLD Registration Data should become ICANN consensus policy, with or without modifications, while ensuring compliance with the European Union's General Data Protection Regulation (GDPR) and other relevant privacy and data protection laws.

Background on the development of the EPDP option

History

On January 8, 2012, GNSO Policy staffers released a discussion paper about the many questions that had arisen from the implementation of the New gTLD Program, especially concerning when policy vs. implementation work was needed. The GNSO Policy & Implementation Working Group was formed in July 2013. On June 24, 2015, the GNSO Council unanimously adopted the WG's recommendations, which included three new GNSO processes. The GNSO Guidance Process (GGP) and the GNSO Expedited Policy Development Process required changes to the ICANN Bylaws. The EPDP procedures, outlined in Annex A-1 of the ICANN Bylaws, went into effect on September 28, 2015.

Criteria

The GNSO Council may invoke the EPDP (1) to address a narrowly defined policy issue that has already been identified and scoped, following the adoption and/or implementation of a GNSO policy recommendation by the Board; or (2) to create new or additional recommendations for an issue on which extensive, pertinent background information already exists; for instance, the issue may have been discussed in an Issue Report for a PDP that was not initiated or completed or was part of a GGP.

Temporary Specificiation Context

History

On 17 May 2018, the ICANN Board adopted the Temporary Specification as an interim model for WHOIS compliance. This temporary specification was designed to allow registries and registrars to be compliant with the GDPR without being in breach of their contract with ICANN. The procedure for Temporary Policies requires the consensus policy development process to be completed within a year of the Temporary Specification effective date of 25 May 2018.
On 19 July 2018, the GNSO Council initiated and chartered a two-phase EPDP on the Temporary Specification for gTLD Registration Data Team. During Phase 1, the EPDP Team determined whether the Temporary Specification should become an ICANN Consensus Policy as is, or with modifications.

On 20 February 2019, the EPDP Phase 1 Team submitted its Final Report.
On 4 March 2019, the GNSO Council adopted all 29 recommendations.
On 15 May 2019, the ICANN Board adopted 27 of the recommendations On 17 May 2019 the Implementation Team published the Interim Registration Data Policy for gTLDs effective as of 20 May 2019, requiring contracted parties to continue implementing the Temporary Specification pending the ultimate Registration Data Policy.
On 29 May 2019, ICANN Org and the implementation review team (IRT) began implementing the Registration Data Policy. On 02 October 2019, the GNSO council liaison informed the GNSO Council that the recommended 29 February 2020 effective date was not feasible.
On 1 November 2019, the implementation team delivered a report on Recommendation 15.1 to the GNSO about how ICANN retains data
On 6 December 2019, the implementation team delivered a report on Recommendation 15.4 to the EPDP Phase 2 Team about the ICANN process for handling registrar data retention waivers

On 18 February 2020, the implementation team delivered the "Recommendation 27 Wave 1" Report to GNSO about the potential Registration Data Policy's impacts on existing consensus policies
On 8 July 2020, the implementation team delivered a report on Recommendation 17.2 to the EPDP Phase 2 Team about differentiating between Legal and Natural Persons in Domain Name Registration and Data Directory Services
In August 2020, the EPDP team completed Phase 2 and published the final report.
On 24 September 2020, the GNSO Council approved the Phase 2 Priority 2 recommendations.

On 23 February 2021, the implementation team delivered Recommendation 27 Wave 1.5 Report to GNSO on Registration Data Policy Impacts on Privacy and Proxy Services Accreditation Issues (PPSAI) and Translation and Transliteration of Contact Information (T/T) On 21 June 2021, the Board adopted Recommendations 19-22 about city field redaction, display of privacy/proxy registrations’ contact data, the purpose of data processing as it relates to the security, stability, and resiliency of the DNS, and registration data retention time periods.

Mission and Scope

The EPDP Team's objective is to determine if the Temporary Specification should become an ICANN Consensus Policy, as is or with modifications, while complying with the GDPR and other relevant privacy and data protection law. At a minimum, the EPDP is expected to consider the questions laid out in the charter.

The charter questions break down into two sections:

1. Questions on the "Terms of the Temporary Specification"
2. Questions on a "System for Standardized Access to Non-Public Registration Data"

EPDP Team

Structure

The EPDP is constituted of participants filling different roles including:

• Team Members
  • GNSO Members are appointed by Stakeholder Groups (SGs)
    • Contracted Party House (6 Members, 6 Alternates)
      • Registries Stakeholder Group (3 Members, 3 Alternates)
      • Registrars Stakeholder Group (3 Members, 3 Alternates)
    • Non-Contracted Party House (12 Members, 6 Alternates)
      • Commercial Stakeholder Group (6 Members, 3 Alternates)
      • Non-Commercial Stakeholder Group (6 Members, 3 Alternates
  • ALAC ( 2 Members, 2 Alternates)
  • SSAC (2 Members, 2 Alternates)
  • GAC (3 Members, 3 Alternates)
  • RSSAC (2 Members, 2 Alternates) (Not Filled)
  • ccNSO (2 Members, 2 Alternates) (Not Filled)
• Liaisons
• Team Alternates
• Observers

On 18 April 2019, the GNSO Council approved the appointment of Janis Karklins, Latvian Ambassador to the United Nations at Geneva, as the chair for the EPDP Team Phase 2.

Members

	Members/Liaisons	Affiliation	SOI
1	Alan Woods	RySG	SOI
2	Kristina Rosette	RySG	SOI
3	Marc Anderson	RySG	SOI
4	James Bladel	RrSG	SOI
5	Matt Serlin	RrSG	SOI
6	Emily Taylor	RrSG	SOI
7	Alex Deacon	IPC	SOI
8	Diane Plaut	IPC	SOI
9	Margie Milam	BC	SOI
10	Mark Svancarek	BC	SOI
11	Esteban Lescano	ISPCP	SOI
12	Thomas Rickert	ISPCP	SOI
13	Stephanie Perrin	NCSG	SOI
14	Ayden Ferdeline	NCSG	SOI
15	Milton Mueller	NCSG	SOI
16	Julf Helsingius	NCSG	SOI
17	Amr Elsadr	NCSG	SOI
18	Farzaneh Badiei	NCSG	SOI
19	Georgios Tselentis	GAC	SOI
20	Kavouss Arasteh	GAC	SOI
21	Ashley Heineman	GAC	SOI
22	Alan Greenberg	ALAC	SOI
23	Hadia Elminiawi	ALAC	SOI
24	Benedict Addis	SSAC	SOI
25	Ben Butler	SSAC	SOI
26	Chris Disspain	ICANN Board Liaison	SOI
27	Leon Felipe Sanchez	ICANN Board Liaison	SOI
28	Rafik Dammak	GNSO Council Liaison	SOI
29	Trang Nguyen	ICANN Org Liaison (GDD)	SOI
30	Dan Halloran	ICANN Org Liaison (Legal)	n/a
31	Kurt Pritz	EPDP Team Chair	SOI

Alternates

	Alternates	Affiliation	SOI
1	Matthew Crossman	RySG	n/a
2	Arnaud Wittersheim	RySG	SOI
3	Sebastien Ducos	RySG	SOI
4	Jeff Yeh	RrSG	SOI
5	Volker Greimann	RrSG	SOI
6	Lindsay Hamilton-Reid	RrSG	SOI
7	Sarah Wyld	RrSG	SOI
8	Theo Geurts	RrSG	SOI
9	Brian King	IPC	SOI
10	Steve DelBianco	BC	SOI
11	Suman Lal Pradhan	ISPCP	SOI
12	Tatiana Tropina	NCSG	SOI
13	David Cake	NCSG	SOI
14	Collin Kurre	NCSG	SOI
15	Chris Lewis-Evans	GAC	SOI
16	Rahul Gosain	GAC	SOI
17	Laureen Kapin	GAC	SOI
18	Holly Raiche	ALAC	SOI
19	Seun Ojedeji	ALAC	SOI
20	Greg Aaron	SSAC	SOI
21	Rod Rasmussen	SSAC	SOI

Phases

EPDP Phase 1 Final Report

The Final Report of the Temporary Specification for gTLD Registration Data (EPDP) was published on 20 February 2019. The representatives from the Intellectual Property Constituency (IPC) and Business Constituency (BC) voted against the Final Report, but since all other GNSO Councillors were in favour, the Final Report was approved. The report was then passed to the ICANN Board for adoption.

The report contains an analysis of affected parties, anticipated time to implement recommendations, and other pertinent information that will assist the Board's deliberations on the EPDP Phase 1 policy recommendations. The recommendations from this report must be adopted by concerned parties on or before 29 February 2020.

EPDP Phase 2

Deliberations and Initial Report

In Phase 2, the EPDP team was tasked with addressing open issues left unresolved from Phase 1, addressing issues listed in the Annex to the Temporary Specification, and developing a standardized access system for nonpublic registration data. The team divided the issues into two priority tiers, with the SSAD as priority 1, and all other questions and issues as priority 2. This prioritization resulted in an initial report that was solely focused on the SSAD, with an addendum being released a month later that discussed priority 2 issues. The team initially considered two models for the SSAD: a fully centralized model where accreditation of requestors, request processing, and disclosure decisions were all handled within a single clearinghouse; and a decentralized model where requests were handled by contracted parties, with no central hub for requests. Neither model appeared to meet all the needs of a trusted system.

The team's Initial Report was published for public comment in February 2020 The report outlined a proposed hybrid model for SSAD, where requests were sent to a centralized clearinghouse, and then action on requests, decisions, and disclosure of requested information were taken up by each contracted party, as applicable. The model was based on the following broad principles:

• Ideally, receipt, authentication, and transmission of SSAD requests should be automated wherever feasible. Disclosure decisions may be automated to the extent feasible, but should be standardized as much as possible across decisions.
• SSAD should be subject to continuous improvement, via a method of review and improvement that operates within the policies outlined by the EPDP, ICANN Bylaws, GNSO procedures & guidelines, and data protection legislation and regulation.
• Contracted parties should be subject to service-level agreements (SLAs) regarding response time for SSAD requests, based on priority.
• Responses to requests should be transmitted directly from the contracted party to the requestor, but there must be some sort of logging or tracking mechanism so that the SSAD "clearinghouse" is able to monitor and record decisions, compliance with SLAs, and perform other oversight of request processing.

The Initial Report contained 19 recommendations regarding the proposed model:

Recommendation(s)	Subject	Notes
1-2	Accreditation	Accreditation requirements for entities (1) and government agencies (2)
3-5	Requests	Processing of requests, form & content of request, and receipt acknowledgement
6-8	Responses	Authorization of requests, including automated requests, and form and content of responses from contracted parties
9	SLAs	Priority levels and required response times
10, 12, 13, 14	Terms of Use	Acceptable use policy recommendations (10), terms of use and privacy policy (13), and monitoring & enforcement of policies (12); requestors must agree to store & maintain disclosed data in a secure manner, and dispose of data once its purpose has been fulfilled (14)
11	Disclosure	Rules and requirements regarding disclosure of information in response to an SSAD request
15	Financial Sustainability	Distinguishing SSAD start-up costs from operating costs; possible cost-recovery measures to maintain financial viability
16-17	Automation	SSAD should be automated to the greatest extent possible (16); logging (17) should include a variety of metrics and transactional milestones for requests, responses, and enforcement actions;
18	Audit	Audit procedures for the accrediting authority, contracted parties, and accredited parties
19	Evolution	Mechanism for review, improvement, and evolution of SSAD to increase effectiveness and streamline operations

Public Comments on Initial Report

The public comment period ran from February 7 to March 23, 2020. The EPDP team utilized an intake form for public comment in order to focus comment on the issues and recommendations within the report. The form asked commenters to score each recommendation, with options indicating support or disagreement with the recommendation:

• Support recommendation as written
• Support intent of recommendation with edits
• Intent and wording of this recommendation requires amendment
• Delete recommendation
• No opinion

For purposes of review, the EPDP team collated the responses into three substantive categories (Support, Concern, Delete), as well as tracking "no opinion" responses and the absence of any response.

In all, 47 comments were received on the Initial Report. Numerous SOs and ACs submitted comments that were critical of elements of the SSAD process as proposed. There were also complaints about the use of a form rather than allowing less structured comments. A summary of highlights follows. The "Comments in Support" numbers listed below reflect the EPDP team's substantive categories described above.

Recommendation	Comments in Support	Proposed Changes	Other Comments	Link to Comments
1 - Accreditation	25	Add a "Trusted Notifier" designation for entities with a record of good faith use of SSAD and previous tools - BC, IPC, and industry groupsSubstantial edits to process & requirements - INTAChanges required to conform to data protection principles - Council of Europe Data Protection Unit	"The creation of an Accreditation Authority brings significant complications to what should be a simple transaction…the reliance on an Accreditation Authority is misplaced." - Tucows	GNSO Summary
2 - Gov't Entity Accreditation	23	Further work needed to understand the implementation path for governments and their designees (which are sometimes separate from the government) - GACNumerous objections to the breadth of terminology, particularly the purpose of requests being related to a "public policy task."	"Further, the existence of an accreditation for an extrajurisdictional governmental entity must not presume, under this or any other model, that the entity or government in question can extend its jurisdiction to a CP that would not otherwise be subject to it; ICANN PDPs cannot create new international law." - Tucows	GNSO Summary
3 - Criteria & Content of Requests	23	More work needed to refine the requirements to comply with jurisdiction-specific expectations and IP law standards - WIPO, Council of Europe Data Protection UnitThis recommendation involves the processing of personal data as defined under GDPR - ICANN OrgRequest form needs to be as simple and user friendly as it can be - Motion Picture Assocation		GNSO Summary
4 - Third Party Justifications	25	Eliminate "purposes" and specify only requestor justifications; clarify that the existence of a valid justification does not warrant disclosure - mulitple commenters		GNSO Summary
5 - Acknowledgement of Receipt	25	Given the system will be automated, an immediate response upon submission is reasonable and necessary - multiple commenters		GNSO Summary
6 - Contracted Party Authorization	23		Multiple commenters suggested changes to the proposed mechanisms; other commenters objected to a decentralized decision-making process and urged the EPDP team to reconsider a centralized decision model.	GNSO Summary
7 - Authorization for Automated Disclosure Requests	18	Many attempts to improve or clarify the language of this section	Notably, three commenters recommended deletion of this recommendation. "Automated disclosures raise important legal questions, which this Recommendation does not resolve. Automation of disclosure poses a real danger that all of the legal rights for data subjects could be bypassed by a system that essentially recreates the open-access Whois for any accredited user." - Georgia Institute of Technology	GNSO Summary
8 - Response Requirements	27	Edits suggested for consistency and predictability		GNSO Summary
9 - Service Level Agreements	25	Some proposed alterations to priority categories and timeframes	IPC, INTA, and SSAC took issue with the priority classifications, response times, and other aspects of the recommendation.	GNSO Summary
10 - Acceptible Use Policy	18	Proposed edits to expand the definition of reasonable use	Intellectual property practitioners and groups, including INTA and the IPC, took issue with many aspects of this recommendation.	GNSO Summary
11 - Disclosure Requirement	20	Multiple recommendations to clarify intent and process	ICANN Org had multiple questions regarding EPDP's considerations of factors that would impact disclosure determination processes.	GNSO Summary
12 - Query Policy	22	Disparate treatment of registrants and requestors should be amended - no one should be permitted to use false credentials	In this and many other recommendations around rights to request information, the lack of access historical data was noted by IP practitioners and brand owners as problematic for enforcement of rights.	GNSO Summary
13 - Terms of Use	21	Any such terms should be drafted by and approved by the community - IPC	Tucows found recommendations for both an "Acceptible Use Policy" and a "Terms of Use" to be redundant	GNSO Summary
14 - Retention and Destruction of Data	25	Proposed edits to allow requestors to comply with applicable data retention laws in their jurisdiction.	ICANN Org suggested consolidation of this recommendation with the Terms of Use recommendation	GNSO Summary
15 - Financial Sustainability	20	Strong opinions regarding the possibility of request or accreditation fees, and the notion that requestors should fund the system's continued operation	ICANN Org noted that there may be legal issues with fees for requests; SSAC argued that the entire recommendation was out of scope.	GNSO Summary
16 - Automation	20	SSAC and others found the intent to automate requests worthwhile, and proposed edits in support of clearer implementation		GNSO Summary
17 - Logging	24		Tucows found the proposed requirements excessive and convoluted.	GNSO Summary
18 - Audits	23	Many comments that auditing should also apply to Contracted Party activity.		GNSO Summary
19 - Mechanism for Evolution of SSAD	22	A large number of commenters stated that any review mechanism should include the GAC, ALAC, and SSAC		GNSO Summary

Addendum to Initial Report

Following the publication of the Initial Report, the EPDP team released an Addendum to the Initial Report in March 2020. The addendum reported the team's deliberation of the priority 2 issues delegated to Phase 2:

• Display of information of affiliated vs. accredited privacy/proxy providers
• Legal vs. natural persons
• City field redaction
• Data retention
• Potential Purpose for ICANN’s Office of the Chief Technology Officer
• Feasibility of unique contacts to have a uniform anonymized email address
• Accuracy and WHOIS Accuracy Reporting System

The addendum included three additional recommendations and several "preliminary conclusions," with conclusions ranging from reports of significant divergence of opinion on issues to preliminary assessments that the status quo likely did not need to be changed:

• Recommendation 20: In situations where an accredited privacy/proxy service is used, the registrar (and registry, if applicable) must include the full RDDS data of the service in response to an RDDS query. The data may include an anonymized email.
• Recommendation 21: "The EPDP Team confirms its recommendation from Phase 1 that registrars be required to retain only those data elements deemed necessary for the purposes of the TDRP, for a period of fifteen months following the life of the registration plus three months to implement the deletion, i.e., 18 months."
• Recommendation 22: Add "contribute to the maintenance of the security, stability, and resiliency of the Domain Name System in accordance with ICANN's mission" to the "ICANN Purposes for processing gTLD registration data" listed in Recommendation 1 of the Phase 1 Final Report.
• Legal vs. natural persons: "There is a persistent divergence of opinion on if/how to address this topic within the EPDP Team." The team suggested that they confer with the GSNO Council for next steps.
• City field redaction: No changes are recommended to the Phase 1 recommendation that redaction must be applied to the city field.
• Office of Chief Technology Officer: No need to propose additional purpose(s) to facilitate ICANN's OCTO in carrying out its mission.
• Feasibility of unique contacts to have a uniform anonymized email address: EPDP team received legal guidance that publication of uniform masked email addresses represents the publication of personal data under the GDPR. Therefore, this policy does not appear to be feasible.
• Accuracy of WHOIS data and WHOIS accuracy reporting system: Per instructions from GNSO Council, the EPDP team will not pursue these issues during Phase 2. Instead, the GNSO will form a scoping team to identify what the next steps should be regarding these topics.

The Addendum was published for public comment in March 2020. The EPDP team again prepared an intake form for responses. Many constituencies and advisory committees expressed dismay at the lack of progress on many serious issues, and in particular those issues for which "preliminary conclusions" were reported. The decision to pass over the issues of accuracy of WHOIS data and the accuracy reporting system was met with strong disagreement. There was also strong opposition to the failure to take up the issue of legal versus natural persons. After a thorough review of current practice, legal opinion, and other factors, the GAC's comment put the matter succinctly:

The clear implication of this legal advice, as well as the EDPB guidance, is that there is a variety of measures to ensure that registrants accurately designate themselves as legal entities. The fact that many ccTLDs (including those based in the EU) already make certain registrant data of legal entities publicly available demonstrates that such distinction is both legally permissible and feasible.
Consequently, the GAC suggests that the EPDP reconsider its position. Instead of deferring this issue, the EPDP team could focus upon the legal guidance provided to develop reasonable policies to permit the information of legal entities to remain public. The time is now to implement a policy that deals with this issue in a manner that promotes public safety and provides useful information to internet users seeking to navigate the internet safely and securely.

Final Report

The EPDP team submitted the Phase 2 Final Report to the GNSO Council on July 31, 2020. As proposed in the initial report, the EPDP Team advised the GNSO council to treat the recommendations as one package and pass them on as such to the ICANN Board.

The GNSO Council approved the Final Report at its meeting in September 2020. The following month, at ICANN 69, the GNSO provided a policy update on the Phase 2 work, including an overview of approved next steps regarding two priority 2 issues: legal versus natural persons; and feasibility of unique contacts to have a uniform anonymized email address. The Council decision was to reconvene the EPDP to continue work on a "Phase 2A" to address those two issues.

EPDP Phase 2A

Phase 2A was started in November 2020. This final phase exclusively addressed the issues of legal vs. natural persons and the feasibility of unique contacts to have a uniform anonymized email address. The Final Report was issued to the GNSO Council on September 13, 2021 The report made sure to highlight the limitations of the working group's consensus regarding the recommendations:

This Final Report constitutes a compromise that is the maximum that could be achieved by the group at this time under our currently allocated time and scope, and it should not be read as delivering results that were fully satisfactory to everyone. This underscores the importance of the minority statements in understanding the full context of the Final Report recommendations.

Legal vs. Natural Persons

The GDPR only protects natural persons. In Phase 1 of the EPDP, the team determined that contracted parties should have the option to distinguish between registrants that are legal persons (i.e. organizations or corporate forms) and those that are natural persons. The Phase 2A team was tasked with reviewing those Phase 1 recommendations and providing any additional guidance it deemed necessary.

The final report took no position on whether or not the recommendations in Phase 1 should be changed regarding the option for registrars and registries to draw distinctions between natural and legal persons. The working group did recommend that ICANN org work with technical policy groups to ensure that such distinctions could be made by contracted parties, and that systems such as SSAD would be compatible with contracted party systems. The team also developed guidance for registrars and registries choosing to make the distinction between legal and natural persons.

Unique Identifiers

The team was unable to reach a consensus on the development of mandatory unique identifiers:

Certain stakeholders see risks and other concerns that prevent the EPDP Team from making a recommendation to require Contracted Parties to make a registrant-based or registration-based email address publicly available at this point in time. The EPDP Team does note that certain stakeholder groups have expressed the benefits of 1) a registration-based email contact for contactability purposes as concerns have been expressed with the usability of web forms and 2) a registrant-based email contact for registration correlation purposes.

Registration Data Consensus Policy for gTLDs

The recommendations to be implemented by the Implementation Review Team (IRT) were shared with ICANN Organization to create an ICANN Consensus Policy that complies with the GDPR and other relevant privacy and data protection laws. In August 2022, a Public Comment proceeding was opened concerning the proposed Registration Data Consensus Policy for gTLDs. ICANN Org sought feedback on:

1. the collection, transfer, and publication of gTLD registration data, especially as it relates to
   • the Thick Whois Transition Policy (Section 7)
   • the prohibition of personal data in the log file requirements relating to communications sent to RDDS/WHOIS Contacts (Section 11)
   • Changes to processing requirements for administrative and technical contact data elements (Section 6)
   • Standardization of the Registrant Organization data element, especially notifications to the registrant and how and when the value must be published (Sections 6 and 9, Addendum II)
   • Changes to the duration of retention requirements (Section 12)
2. EPDP-TempSpec Phase 1 Recommendation 27, concerning
   • updates to existing policies and procedures that touch on Registration Data
   • ICANN Org determined that 18 of 24 existing policies and procedures would be impacted by the Registration Data Consensus Policy, including outdated provision language, high-level issues, such as the relevance or inconsistency of an existing policy or procedure with the new Registration Data Consensus Policy, and implications for existing contractual provisions.

Public Comments Summary Report

On January 20, 2023, ICANN Org released its summary report on the 14 submissions it received. The summary identified several key themes, including:

1. the need for clarification in sections 2, 3, 5, 6, 7, 9, 10, 12, and addendums I and II.
2. areas in the drafted policy language did not accurately reflect the policy recommendations, such as "processing" in sections 1, the "scope" in section 2, the entirety of section 2.2, sections 3.8-3.10, and "consent" and "personal data" as they relate to the GDPR, the timeline in section 4, updates to section 5 to reflect events that have happened in the meanwhile, the use of "must" in sections 6, 7, 8, and 9, the use of "urgent," the proposed deadlines, and the lack of explanation for circumstances under which a request must be considered in section 10, issues with the specifics of logging in section 11, and the "minimum retention period" in section 12.
3. the need to correct some of the redlines in the Additional Whois information Policy, the ERRP, the Protection of IGO and INGO Identifiers, the CL&D Policy, the Thick Whois Transition Policy, the Transfer FOA and initial authorization, the TDRP, the Transfer Policy, UDRP-related documents, the Whois Data Reminder Policy (WDRP) Rules, and RDAP-related documents.

ICANN Org interpreted and summarized the public comments as outlining clarifications needed on requirements for the transfer of specific registration data from registrar to registry and the impact on the Thick WHOIS Transition Policy, changes needed to processing requirements for administrative and technical contact data elements and disclosure requirements, ensuring the Registration Data Policy is consistent with amended RA and RAA, and updates to reflect the November 2022 adoption of The Network and Information Security (NIS2) Directive.

General Data Protection Regulation

Generic Names Supporting Organization. Develops and recommends to the Board substantive policies relating to generic top-level domains and other responsibilities set forth in the Bylaws (ICANN Bylaws).

Policy Development Process

At-Large Advisory Committee. Considers and provides advice on the activities of ICANN related to the interests of individual Internet users (ICANN Bylaws). Not to be confused with the Non-Commercial Stakeholder Group.

Security and Stability Advisory Committee. Advises the ICANN community and Board on matters relating to the security and integrity of the Internet's naming and address allocation systems (ICANN Bylaws).

Governmental Advisory Committee. Considers and provides advice on the activities of ICANN as they relate to concerns of governments, particularly matters where there may be an interaction between ICANN's policies and various laws and international agreements or where they may affect public policy issues (ICANN Bylaws).

Root Server System Advisory Committee. Advises the ICANN community and Board on matters relating to the operation, administration, security, and integrity of the Internet's Root Server System (ICANN Bylaws).

Country Code Names Supporting Organization. Develops and recommends to the Board global policies relating to country-code top-level domains (ICANN Bylaws).

World Intellectual Property Organization