Skip to main content

Expressions of Interest Sought for Chair of GNSO EPDP on the Temporary Specification for gTLD Registration Data – Phase 2

Expressions of Interest Sought for Chair of GNSO EPDP

LOS ANGELES –1 March 2019 – The Generic Names Supporting Organization (GNSO) is looking for expressions of interest to chair Phase 2 of the Expedited Policy Development Process (EPDP) on the Temporary Specification for gTLD Registration Data. The EPDP Team recently completed its Phase 1 work and is expected to commence planning for Phase 2 at ICANN64 meeting in Kobe, Japan. During Phase 2, the EPDP Team will work on a system for standardized access to non-public registration data, topics identified in the annex to the Temporary Specification, as well as a number of carry over items from Phase 1.

The GNSO Council is looking to appoint a neutral Chair to the EPDP Team. With such an important issue under consideration, significant responsibility comes with the role to ensure the success of deliberations.

The EPDP Team is expected to have regular calls, although it may be necessary to hold calls more frequently if need arises. Additionally, the EPDP Team may have face-to-face meetings in order to meet the required milestones of the EPDP. The EPDP Team is expected to start developing the work plan for Phase 2 at ICANN64 in Kobe for which the GNSO Council may provide further guidance.

There will be no compensation associated with the role of the EPDP Team Chair; however, travel associated with any face-to-face meetings may be supported by ICANN org.

To express interest in this role, please submit an Expression of Interest to EOI-EPDPTeam-Chair@icann.org by 22 March 2019 at 14:00 UTC.

Please answer the following questions:

  • What is your interest in this position?
  • What particular skills and attributes do you have that will assist you in chairing the EPDP?
  • What is your knowledge of the Temporary Specification for gTLD Registration Data, EPDP Team's Phase 1 work and associated challenges and requirements particularly as it relates to the EPDP?
  • What is your experience in and knowledge of the GNSO Policy Development Process, ICANN's consensus policies, ICANN's registry agreements and the Registrar Accreditation Agreement related to gTLD registration data?
  • Are you able to commit the time required and necessary work needed to chair the EPDP, noting that this to a certain extend will be dependent on the EPDP Team's work plan for phase 2 which is under development?
  • Conflict of Interest Statement – do you have any affiliation with or involvement in any organization or entity with any financial or non-financial interest in the subject matter of this EPDP?
  • Please also include:

Application materials will be reviewed by the Council leadership and will not be shared publicly. Names of applicants, including the recommended candidate, will be shared with the GNSO Council for its consideration. The Council leadership is expected to provide its recommendation to the GNSO Council in time for the GNSO Council meeting on 18 April 2019.

Additional questions and inquiries can be sent to EOI-EPDPTeam-Chair@icann.org.

More Information

About EPDP

On 17 May 2018, the ICANN Board approved the Temporary Specification for gTLD Registration Data. The Board took this action to establish temporary requirements for how ICANN and its contracted parties would continue to comply with existing ICANN contractual requirements and community-developed policies related to WHOIS, while also complying with the European Union's General Data Protection Regulation (GDPR). The Temporary Specification has been adopted under the procedure for Temporary Policies outlined in the Registry Agreement (RA) and Registrar Accreditation Agreement (RAA). Following adoption of the Temporary Specification, the Board "shall immediately implement the Consensus Policy development process set forth in ICANN's Bylaws." This Consensus Policy development process on the Temporary Specification would need to be carried out within a one-year period. Additionally, the scope includes discussion of a System for Standardized Access to Non-Public Registration Data. However, the discussion of a Standardized Access System will occur only after the EPDP Team has comprehensively answered a series of "gating questions" and non-objection by the GNSO Council.

About ICANN

ICANN's mission is to help ensure a stable, secure, and unified global Internet. To reach another person on the Internet, you need to type an address – a name or a number – into your computer or other device. That address must be unique so computers know where to find each other. ICANN helps coordinate and support these unique identifiers across the world. ICANN was formed in 1998 as a not-for-profit public-benefit corporation with a community of participants from all over the world.

ANNEX A – CHAIR RESPONSIBILITIES AND EXPECTATIONS

As outlined in the GNSO Working Group Guidelines, the purpose of a Chair is to call meetings, preside over working group (WG) deliberations, manage the process so that all participants have the opportunity to contribute, and report the results of the WG to the Chartering Organization. These tasks require a dedicated time commitment as each call has to be prepared, the agenda concretized, and relevant material has to be reviewed. The Chair shall be neutral. While the Chair may be a member of any group which also has representation on the EPDP Team, the Chair shall not act in a manner which favors such group. The Chair shall not be a member of the PDP Team for purposes of consensus calls.

In addition, it is required – that interested candidates have considerable experience in Chairing working groups, and direct experience with at least one GNSO Policy Development Process throughout its lifecycle would be an advantage. Familiarity with the functioning of a Working Group is important to understand the various leadership skills that are necessary to employ during a WG's lifecycle. For example, a chair has to ensure that debates are conducted in an open and transparent matter and that all interests are equally represented within the WG's discussions. During the later stages of a WG when recommendations are drafted, a Chair will benefit from understanding the viewpoints of various members to ensure that an acceptable and effective outcome – ideally in form of consensus – can be achieved.

In short, the EPDP Team Chair is expected to:

  1. Attend all EPDP Team meetings to ensure continuity and familiarity with the subject matter and the on-going discussions;
  2. Prepare meetings by reading all circulated materials;
  3. Be familiar with the subject matter, including but not limited to GDPR and data protection laws, and actively encourage participation during the calls
  4. Be active on the EPDP Team mailing list and invite EPDP Team participants to share their viewpoints;
  5. Drive forward the EPDP Team and assure that discussions remain on point;
  6. Work actively towards achieving policy recommendations that ideally receive full consensus;
  7. Ensure that particular outreach efforts are made when community reviews are done of the EPDP Team's output;
  8. Underscore the importance of achieving overall representational balance on any sub-teams that are formed;
  9. Encourage and, where necessary, enforce the ICANN Standards of Behavior and resolve any conflicts in a timely manner.
  10. Co-ordinate with ICANN staff and ensure that the EPDP Team is supported as effectively as possible
  11. Conduct consistent timely reporting to the GNSO Council on the progress of the EPDP.

Finally, as also pointed out the in GNSO Working Group Guidelines, 'appointing a co-chair(s) or vice-chair(s) may facilitate the work of the Chair by ensuring continuity in case of absence, sharing of workload, and allowing the Chair to become engaged in a particular debate.' As a result, similar tasks and skills are expected from vice chairs, although the overall workload may be reduced as a result of being able to share this with the Chair.


More Announcements
Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."