Historical Resolution Tracking Feature » GNSO Council Policy Recommendations on EPDP Phase 2A
Important note: The explanatory text provided through this database (including the summary, implementation actions, identification of related resolutions, and additional information) is an interpretation or an explanation that has no official authority and does not represent the purpose behind the Board actions, nor does any explanations or interpretations modify or override the Resolutions themselves. Resolutions can only be modified through further act of the ICANN Board.
Whereas, on 17 May 2018, the ICANN Board adopted the Temporary Specification for gTLD Registration Data (Temporary Specification) pursuant to the procedures in the Registry Agreement (RA) and Registrar Accreditation Agreement (RAA) concerning the establishment of temporary policies.
Whereas, following the adoption of the Temporary Specification, and per the procedure for Temporary Policies as outlined in the RA and RAA, a Consensus Policy development process as set forth in ICANN's Bylaws must be initiated immediately and completed within a one-year time period from the implementation effective date (25 May 2018) of the Temporary Specification.
Whereas, the GNSO Council approved the EPDP Initiation Request (https://gnso.icann.org/sites/default/files/file/field-file-attach/temp-s...) and the EPDP Team Charter (https://gnso.icann.org/sites/default/files/file/field-file-attach/temp-s...) on 19 July 2018.
Whereas, the EPDP Team divided the work into two phases. Phase 1 completed with the adoption of the EPDP Phase 1 Final Report on 4 March 2019, at which point the GNSO Council indicated its non-objection, as required per the EPDP Team Charter, for the EPDP Team to commence work on a System for Standardized Access/Disclosure to Non-Public Registration Data (SSAD) as well as other topics identified in Phase 2 of the Charter and/or carried over from Phase 1 (priority 2 items).
Whereas, the Phase 2 Final Report noted that "As a result of external dependencies and time constraints, this Final Report does not address all priority 2 items". It furthermore noted that the EPDP Team would "consult with the GNSO Council on how to address the remaining priority 2 items".
Whereas, following these consultations, the GNSO Council adopted on 21 October 2020 instructions for the EPDP Phase 2A to address the remaining priority 2 items, namely 1) differentiation between legal and natural person registration data, and 2) feasibility of unique contacts to have a uniform anonymized email address.
Whereas, the EPDP Team commenced its deliberations on Phase 2A on 17 December 2020.
Whereas, the EPDP has followed the prescribed EPDP steps as stated in the Bylaws, including the publication of an Initial Report for public comment on 3 June 2021, resulting in a Final Report delivered on 3 September 2021 with an updated version containing all minority statements submitted on 13 September 2021.
Whereas, all recommendations received the consensus support of the EPDP Phase 2A Team but the Chair's statement indicated that "it's important to note that some groups felt that the work did not go as far as needed, or did not include sufficient detail, while other groups felt that certain recommendations were not appropriate or necessary".
Whereas, the GNSO Council reviewed and discussed the recommendations of the EPDP Team and approved all Phase 2A on 27 October 2021 by a GNSO Supermajority vote.
Whereas, after the GNSO Council vote, a public comment period was held on the approved Recommendations, and the comments received (see summary report) are similar to comments provided by the EPDP Phase 2A Team members during its deliberations, the comments received in response to the EPDP Phase 2A Team's Initial Report, and the positions demonstrated in the minority statements to the Final Report, represent a clear divergence of views as also reflected in the Chair's statement referenced above.
Whereas, the Governmental Advisory Committee (GAC) was requested to raise any public policy concerns that might occur if the proposed policy is adopted by the Board (https://www.icann.org/en/system/files/correspondence/botterman-to-ismail...).
Whereas, the GAC responded to the Board's notice, and provided its response on 9 February 2022 requesting that the ICANN Board consider "the GAC Minority Statement in its entirety, as well as available options to address the outstanding public policy concerns expressed therein".
Whereas, ICANN org reviewed the Recommendations as well as the Minority Statements, and, based on current information and subject to further inputs from Data Protection Authorities and legal analysis, believes the EPDP Phase 2A recommendations do not appear to be in conflict with (a) the GDPR, (b) existing requirements for gTLD registry operators and registrars, or (c) ICANN's mandate to ensure the stability, security, and resiliency of the Internet's DNS.
Resolved (2022.03.10.04) the Board adopts the GNSO Council EPDP Phase 2A Policy Recommendations as set forth in section 3 of the Final Report.
Resolved (2022.03.10.05), the Board directs the President and CEO, or his designee(s), to develop and execute an implementation plan for the adopted Recommendations that is consistent with the guidance provided by the GNSO Council and to continue communication with the community on such work.
Why is the Board addressing this issue now?
The GNSO Council approved all of the final recommendations from the EPDP Working Group's Final Report dated 13 September 2021 at its meeting on 27 October 2021, and a Recommendations Report from the Council to the Board on the topic on 16 December 2021. In accordance with the ICANN Bylaws, a public comment forum was opened to facilitate public input on the adoption of the Phase 2A Recommendations. The public comment period closed on 13 January 2022. As outlined in Annex A of the ICANN Bylaws, the EPDP recommendations are now being forwarded to the Board for its review and action.
What are the proposals being considered?
The four Phase 2A recommendations relate to the topics of 1) the differentiation of legal vs. natural persons' registration data and 2) the feasibility of unique contacts to have a uniform anonymized email address. In short, the four recommendations recommend that:
A field or fields MUST be created to facilitate differentiation between legal and natural person registration data and/or if that registration data1 contains personal or non-personal data. This field or fields MAY be used by those Contracted Parties that differentiate.
Contracted Parties who choose to differentiate based on person type SHOULD follow the guidance included in the Final Report.
If a GDPR Code of Conduct is developed within ICANN by the relevant controllers and processors, the guidance to facilitate differentiation between legal and natural person data SHOULD be considered within ICANN by the relevant controllers and processors.
Contracted Parties who choose to publish a registrant-based or registration-based email address in the publicly accessible RDDS SHOULD evaluate the legal guidance obtained by the EPDP Team on this topic.
The full list and scope of the final recommendations can be found in Annex B of the GNSO Council's Recommendations Report to the Board (see https://gnso.icann.org/sites/default/files/file/field-file-attach/draft-...).
What significant materials did the Board review?
In taking this action, the Board considered:
The EPDP Team's Phase 2A Final Report, dated 13 September 2021, including minority statements;
The GNSO Council's Recommendations Report to the Board, dated 6 December 2021;
The comments and the summary of public comments received in response to the public comment period that was opened following the GNSO Council's adoption of the recommendations contained in the Final Report, and GAC advice received on the topic;
The letter from the GAC to the Board, dated 9 February 2022.
What factors did the Board find to be significant?
The EPDP Team's Phase 2A recommendations were developed following the GNSO Expedited Policy Development Process as set out in Annex A of the ICANN Bylaws and have received the support of the GNSO Council. As outlined in the ICANN Bylaws, the Council's Supermajority support obligates the Board to adopt the recommendations unless, by a vote of more than two-thirds, the Board determines that the recommended policy is not in the best interests of the ICANN community or ICANN. The Bylaws also allow input from the GAC in relation to public policy concerns that might be raised if a proposed policy is adopted by the Board. The GAC responded by requesting the ICANN Board to consider the GAC Minority Statement in its entirety, as well as available options to address the outstanding public policy concerns expressed therein. The Board has taken note of the comments received during the public comment period which seem to echo the sentiments of the minority statements, in which some are of the view that some of the recommendations do not go far enough while others question whether these are even necessary. The Board observes that these positions were also known to the EPDP Phase 2A Working Group as well as the GNSO Council who adopted the recommendations with the required GNSO Supermajority support.
Are there positive or negative community impacts?
Although the recommendations do not create new obligations for Contracted Parties, the recommendations are intended to facilitate differentiation between legal and natural person registration data as well as personal and non-personal data for those Contracted Parties that choose to differentiate, in line with the EPDP Phase 1 recommendations. In addition, Contracted Parties who choose to publish a registrant-based or registration-based email address may benefit from the guidance provided. Promotion of this guidance may furthermore help standardize the way in which Contracted Parties who choose to differentiate implement this in practice.
Are there fiscal impacts or ramifications on ICANN (strategic plan, operating plan, budget); the community; and/or the public?
There may be fiscal impacts on ICANN associated with the implementation of policy recommendations. These would be related to the use of ICANN org resources to implement the recommendations.
Implementation Considerations considered
The creation of a field or fields would require coordination and work through the Internet Engineering Task Force (IETF). ICANN org participates voluntarily and org staff act in their individual capacity in the IETF. Therefore, ICANN org staff can coordinate with the technical community/RDAP WG to put forward relevant proposals in IETF Working Groups to develop the necessary standards; however, it is ultimately up to the IETF to make the changes.
ICANN org estimates that implementing Recommendation 1 would require coordination through the IETF for (1) EPP extension and (2) support in RDAP (i.e., jCard and JSContact). ICANN org estimates that the EPP extension could take between 12-24 months, depending on the milestones and priorities of the IETF Registration Protocols Extensions (REGEXT) Working Group. The IETF REGEXT WG is the home of the coordination effort for standards track extensions. In the case of RDAP, (i) adding support in jCard may require adding properties or values (e.g., KIND). ICANN org estimates that this should take between 6 – 12 months. (ii) Adding support in JSContact could take between 12 – 24 months depending on whether the change could make it into the current internet draft of JSContact or require an extension. The three lines of work: (a) EPP, (b) jCard, and (c) JSContact; could be done in parallel.
In relation to recommendation #2, ICANN org has reiterated its previous feedback2 to the EPDP Phase 2A WG with regards to guidance for Contracted Parties. ICANN Contractual Compliance enforces requirements placed on contracted parties via the RA, RAA, and ICANN Consensus Policies, in furtherance of ICANN's mission, as recognized in the ICANN Bylaws. Guidance and best practices would exist outside these agreements and are not contractual requirements; thus, ICANN Contractual Compliance would not have contractual authority to take enforcement action against a contracted party related to its implementation of best practices or guidance, even if those best practices or guidance is developed through the EPDP Process.
Are there any Security, Stability or Resiliency issues relating to the DNS?
There are no security, stability, or resiliency issues relating to the DNS that can be directly attributable to the implementation of the EPDP recommendations.
Is this decision in the public interest and within ICANN's mission?
Consideration of community-developed policy recommendations is within ICANN's mission as defined at Article 1, section 1.1(i) of the ICANN Bylaws. This action serves the public interest, as ICANN has a core role as the "guardian" of the Domain Name System.
Is this either a defined policy process within ICANN's Supporting Organizations or ICANN's Organizational Administrative Function decision requiring public comment or not requiring public comment?
Public comment has taken place as required by the ICANN Bylaws and GNSO Operating Procedures in relation to GNSO policy development.