GNSO Council Policy Recommendations on EPDP Phase 2A

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.