Skip to main content

Call for Volunteers: New GNSO Policy Development Process Working Group to Review All Rights Protection Mechanisms in All gTLDs

In Brief

The Generic Names Supporting Organization (GNSO) Council seeks volunteers for a new Working Group that will conduct a Policy Development Process (PDP) to Review All Rights Protection Mechanisms (RPMs) in All Generic Top-Level Domains (gTLDs). The GNSO Council approved the PDP Working Group's Charter [PDF, 510 KB] on 9 March 2016.

What This Team Will Do

  1. Conduct the PDP in two phases

    This PDP Working Group is being chartered to conduct a review of all RPMs in all gTLDs in two phases as defined in the approved charter [PDF, 524 KB]: Phase One will focus on a review of all the RPMs that were developed for the New gTLD Program (i.e. the Trademark Clearinghouse and associated notification and sunrise mechanisms, the Uniform Rapid Suspension procedure, and the Post-Delegation Dispute Resolution Procedures), and Phase Two will focus on a review of the Uniform Dispute Resolution Policy (UDRP).

    At a minimum, in each Phase of this PDP, the Working Group will be expected to first assess the effectiveness of the relevant RPM(s), for which it should seek the input of experienced online dispute resolution providers and other subject matter experts, as appropriate. The Working Group is also expected to look at the interplay between and complementary roles of each RPM in seeking to more fully understand their overall functioning and effectiveness. Ultimately, the goal is for the Working Group to consider the overarching issue as to whether or not all the RPMs collectively fulfill the purposes for which they were created, or whether additional policy recommendations are needed, including to clarify and unify the policy goals.

    In public comments to the UDRP Final Issue Report [PDF, 2.69 MB], the RPM Staff Paper [PDF 2.5 MB], and the Preliminary Issue Report for this PDP, various community groups and participants had identified a number of issues that they considered appropriate for review in a PDP. As such, the Working Group is expected to consider these community suggestions, which have been listed in the Working Group Charter, with further modifications, additions and deletions to be determined by consensus of the Working Group.

  2. Coordinate its work with other parallel efforts

    The Working Group will monitor the progress of and, where appropriate, coordinate with, other ICANN groups that are working on topics that may overlap with or otherwise provide useful input to this PDP. These other efforts include the Competition, Consumer Trust and Consumer Choice Review Team, the Trademark Clearinghouse Independent Review and the GNSO's PDP Working Group on New gTLDs Subsequent Procedures. In this regard, the GNSO Council directed that a GNSO community liaison be appointed by the two GNSO PDP Working Groups. Further, as the manager of the policy development process, the GNSO Council is to be kept informed about the various coordination efforts so that in case of conflict between these groups, the Council may take the appropriate action to align the different work processes.

    At the conclusion of Phase One of its work, the Working Group is expected to assess the need for modification to its Charter and, if appropriate, submit a request to the GNSO Council accordingly for the subsequent phase(s) of its work.

How This Team Will Work

ICANN Working Groups use transparent, open processes. The meetings of this PDP Working Group will be recorded and transcribed, and the recordings and transcriptions will be available to the public. The mailing list for the Working Group will be archived publicly. The group will collaborate using a public workspace for draft materials and all final work products and milestones will be documented on the WG's wiki. The PDP WG is expected to follow the GNSO Working Group Guidelines [PDF, 350 KB] as well as the GNSO PDP Manual [PDF, 300 KB].

How to participate

There are two ways to volunteer:

  • Individual Members – anyone interested can volunteer to join the PDP Working Group as a member, regardless of whether they are members of the ICANN community. Members are expected to actively contribute to mailing list conversations as well as meetings – it is anticipated that the Working Group will at a minimum meet on a weekly basis via teleconference. Members are expected to provide essential input to the process. Members will be required to provide a Statement of Interest (SOI).
  • Mailing list observers – for those who are merely interested in monitoring the Working Group's deliberations, it is possible to sign up as a mailing list "observer" which offers read-only access to the mailing list. Mailing list observers will not be permitted to post, will not receive invitations to the meetings of the Working Group and will not have to complete a Statement of Interest. At any point in time, a mailing list observer can join the WG as a member simply by informing the GNSO Secretariat.

In addition, there will be opportunities to provide input through public consultations and public comment processes that the PDP Working Group is expected to organize.

How to Join

If you are interested in joining the Working Group either as an individual participant or mailing list observer, please fill in the sign up form or send the Word document [DOCX, 72 KB], filled in, to the GNSO Secretariat.

All members and observers will be listed on the PDP Working Group's wiki page.

Next steps

The GNSO Council directed that this call for volunteers be circulated as widely as possible in order to ensure broad representation and participation in the Working Group. it is anticipated that the Working Group will convene online for the first time in early April 2016. Following that, regular online meetings will be scheduled in accordance with the Working Group's work plan, which it is expected to develop as one of its first tasks.

Further information and preparation

For those interested in volunteering for this effort, you are strongly encouraged to review the following materials prior to the first meeting of the PDP WG:

Background

The question of who legally has rights to, or is the legitimate holder of, a domain name can be open to dispute. In relation to domain name disputes concerning the registration and use of legally protected trademarks, the Uniform Dispute Resolution Policy (UDRP) is the longest standing alternative dispute resolution procedure. As a result of the New gTLD Program, several new rights protection mechanisms (RPMs) were developed to mitigate potential risks and costs to trademark rights holders that could arise in the expansion of the gTLD namespace, which included certain safeguards to protect registrants who engage in legitimate uses of domain names: the Uniform Rapid Suspension System (URS); the Trademark Clearinghouse (TMCH) and the associated availability through the TMCH of Sunrise periods and the Trademark Claims notification service; and the Post-Delegation Dispute Resolution Procedures (PDDRPs). Prior to the launch of the New gTLD Program, on 3 October 2011 ICANN staff had published a Final Issue Report on the current state of the UDRP. The recommended course of action in that UDRP Final Issue Report [PDF, 2.69 MB] was not to initiate a PDP at the time, but to hold off launching any such PDP until after the new URS had been in operation for at least eighteen (18) months. In addition, the September 2015 revised RPM Staff Paper [PDF 2.5 MB] had explicitly noted that some of the concerns identified by the community for consideration as part of a review of the RPMs might be appropriate topics for policy development work. The UDRP has not been subject to comprehensive review. There has also not been a full review of all the RPMs developed to date by ICANN, to consider whether or not they are collectively achieving the objectives for which they were created.

In preparation for this PDP, a new Preliminary Issue Report [PDF, 1.4 MB] was published for public comment on 9 October 2015. A Final Issue Report [PDF, 1.2 MB] was subsequently published on 7 October 2015, including links to all public comments received, along with a draft charter for the PDP WG [PDF, 510 KB]. The final charter was approved by the GNSO Council on 9 March 2016, enabling the formation of a GNSO working group of community volunteers to conduct this PDP.

More information can be found on the activities webpage for GNSO PDP Review of All Rights Protection Mechanisms in All gTLDs and the Working Group's online wiki workspace, which includes the charter, community input provided during the public comment period, and an extensive library of foundational materials to inform the Working Group's deliberations.

As this will be a complex multi-phase PDP, anyone interested in helping to shape the review of all RPMs in all gTLDs are encouraged to volunteer for this Working Group.


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