Jump to content

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

From ICANNWiki
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 edit

History edit

On January 8, 2012, GNSO Policy staffers released a discussion paper[1] 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.[2] 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 edit

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.[3]

Temporary Specificiation Context edit

History edit

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[4] On 17 May 2019 the Implementation Team published the Interim Registration Data Policy for gTLDs[5] 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[6] to the GNSO about how ICANN retains data
On 6 December 2019, the implementation team delivered a report on Recommendation 15.4[7] 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[8] 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 edit

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 edit

Structure edit

The EPDP is constituted of participants filling different roles including:

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.[9]

Members edit

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 edit

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 edit

EPDP Phase 1 Final Report edit

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.[10] 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[11]. The recommendations from this report must be adopted by concerned parties on or before 29 February 2020.

EPDP Phase 2 edit

Deliberations and Initial Report edit

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,[12] and developing a standardized access system for nonpublic registration data.[13] The team divided the issues into two priority tiers, with the SSAD as priority 1, and all other questions and issues as priority 2.[13] 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.[13] 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.[13]

The team's Initial Report was published for public comment in February 2020[14] 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.[14]

The Initial Report contained 19 recommendations regarding the proposed model:[14]

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 edit

The public comment period ran from February 7 to March 23, 2020.[15] The EPDP team utilized an intake form[16] for public comment in order to focus comment on the issues and recommendations within the report.[15] 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[16]

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.[17]

In all, 47 comments were received on the Initial Report.[18] 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 edit

Following the publication of the Initial Report, the EPDP team released an Addendum to the Initial Report in March 2020.[19] 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[19]

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:[19]

  • 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[20] 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.[19]

The Addendum was published for public comment in March 2020.[21] 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.[22] The decision to pass over the issues of accuracy of WHOIS data and the accuracy reporting system was met with strong disagreement.[23] 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.[24]

Final Report edit

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.[13]

The GNSO Council approved the Final Report at its meeting in September 2020.[25] 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.[26] The Council decision was to reconvene the EPDP to continue work on a "Phase 2A" to address those two issues.[26]

EPDP Phase 2A edit

Phase 2A was started in November 2020.[27] 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.[26] The Final Report was issued to the GNSO Council on September 13, 2021[28] 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.[29]

Legal vs. Natural Persons edit

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.[29] The team also developed guidance for registrars and registries choosing to make the distinction between legal and natural persons.[29]

Unique Identifiers edit

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.[29]

Registration Data Consensus Policy for gTLDs edit

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:[30]

  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 edit

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.[31]

References edit

  1. ↑ Policy vs. Implementation Framework
  2. ↑ PI WG Recommendations
  3. ↑ ICANN Bylaws Annex A1
  4. ↑ ICANN Board Resolutions, ICANN Resources
  5. ↑ Interim RDP for gTLDs, ICANN Resources
  6. ↑ Rec 15.1 Report, EPDP on Temp Spec
  7. ↑ 15.4 Report, EPDP on Temp Spec
  8. ↑ Rec 27 Wave 1 Report, EPDP on Temp Spec
  9. ↑ https://gnso.icann.org/en/announcements/announcement-2-22apr19-en.htm
  10. ↑ https://www.comlaude.com/epdp-update/
  11. ↑ https://gnso.icann.org/en/announcements/announcement-2-22apr19-en.htm
  12. ↑ ICANN.org - Temporary Specification for gTLD Registration Data: Annex-Important Issues for Further Community Action
  13. ↑ 13.0 13.1 13.2 13.3 13.4 GNSO Archive - EPDP Temp Spec Phase 2 Final Report, July 31, 2020
  14. ↑ 14.0 14.1 14.2 GNSO Archive - EPDP Temp Spec Phase 2 Initial Report, February 7, 2020 (PDF)
  15. ↑ 15.0 15.1 Public Comment Proceeding - Initial Report of the EPDP Temp Spec Phase 2 Team, last updated April 6, 2020
  16. ↑ 16.0 16.1 GNSO.ICANN.org - Initial Report Public Comment Form - Offline, February 7, 2020 (PDF)
  17. ↑ See, e.g., the summary of responses to Recommendation 1 from the EPDP Workspace (.docx)
  18. ↑ ICANN.org - Staff Report on Public Comment Proceeding, May 12, 2020
  19. ↑ 19.0 19.1 19.2 19.3 EPDP Temp Spec Workspace - Addendum to Phase 2 Initial Report, March 20, 2020
  20. ↑ EPDP Workspace - Bird & Bird Memo re: "Batch 2" of questions regarding SSAD, proxies, pseudonymous emails, February 4, 2020
  21. ↑ Public Comment Proceeding: EPDP Temp Spec Phase 2 - Addendum to Initial Report, last updated May 19, 2020
  22. ↑ EPDP Workspace - Collated General Comments, May 6, 2020 (.docx)
  23. ↑ EPDP Workspace - Collated Comments to Accuracy & ARS Preliminary Conclusion, May 6, 2020 (.docx)
  24. ↑ EPDP Workspace - Collated Comments Regarding Legal v. Natural Persons, May 6, 2020 (.docx)
  25. ↑ GNSO ICANN69 Policy Briefing
  26. ↑ 26.0 26.1 26.2 GNSO Council Proposal - EPDP Phase 2 Priority Items, September 10, 2020
  27. ↑ GNSO Workspace - EPDP Temp Spec Phase 2A
  28. ↑ EPDP Workspace - Final Report, Phase 2A, last updated September 20, 2021
  29. ↑ 29.0 29.1 29.2 29.3 EPDP Temp Spec Phase 2A Final Report, as amended September 13, 2021 (PDF)
  30. ↑ Proposed Reg Data Consensus Policy, Public Comments, ICANN
  31. ↑ Public Comment Summary Report on Proposed Reg Data Consensus Policy, ICANN

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).

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).

Retrieved from "https://icannwiki.org/index.php?title=Expedited_Policy_Development_Process_on_the_Temporary_Specification_for_gTLD_Registration_Data&oldid=1345879"