Description: ICANN Logo-B&W ‘Thick’ Whois PDP

Working Group (WG) Charter


WG Name:

‘Thick’ Whois PDP Working Group

Section I:  Working Group Identification

Chartering Organization(s):

GNSO Council

Charter Approval Date:


Name of WG Chair:


Name(s) of Appointed Liaison(s):


WG Workspace URL:


WG Mailing List:


GNSO Council Resolution:



Ref # & Link:


Important Document Links:

Section II:  Mission, Purpose, and Deliverables

Mission & Scope:



ICANN specifies Whois service requirements through Registry Agreements (RAs) and the Registrar Accreditation Agreement (RAA) for the generic top-level domain (gTLD) registries.


Registries have historically satisfied their Whois obligations under two different models. The two models are often characterized as “thin” and “thick” Whois registries. This distinction is based on how two distinct sets of data are maintained. 


WHOIS contains two kinds of data about a domain name; one set of data is associated with the domain name (this information includes data sufficient to identify the sponsoring registrar, status of the registration, creation and expiration dates for each registration, name server data, the last time the record was updated in the Registry database, and the URL for the registrar’s Whois service), and a second set of data that is associated with the registrant of the domain name.


In a thin registration model the Registry only collects the information associated with the domain name from the Registrar. The Registry in turn publishes that information along with maintaining certain status information at the Registry level. Registrars maintain data associated with the registrant of the domain and provide it via their own Whois services, as required by Section 3.3 of the RAA for those domains they sponsor [1] .


In a thick registration model the Registry collects both sets of data (domain name and registrant) from the Registrar and in turn publishes that data via Whois.


Mission and Scope


The PDP Working Group is tasked to provide the GNSO Council with a policy recommendation regarding the use of ‘thick’ Whois by all gTLD Registries, both existing and future. As part of its deliberations on this issue, the PDP WG should, at a minimum, consider the following elements as detailed in the Final Issue Report:


-           Response consistency: a ‘thick’ Registry can dictate the labeling and display of Whois information to be sure the information is easy to parse, and all Registrars/clients would have to display it accordingly. This could be considered a benefit but also a potential cost. This might also be a benefit in the context of internationalized registration data as even with the use of different scripts, uniform data collection and display standards could be applied.

-           Stability: in the event of a Registrar business or technical failure, it could be beneficial to ICANN and registrants to have the full set of domain registration contact data stored by four organizations (the Registry, the Registry's escrow agent, the Registrar, and the Registrar's escrow agent), which would be the case in a ‘thick’ registry.

-           Accessibility: is the provision of Whois information at the registry level under the ‘thick’ Whois model more effective and cost-effective than a ‘thin’ model in protecting consumers and users of Whois data and intellectual property owners?

-           Impact on privacy and data protection: how would ‘thick’ Whois affect privacy and data protection, also taking into account the involvement of different jurisdictions with different laws and legislation with regard to data privacy as well as possible cross border transfers of registrant data?

-           Cost implications: what are the cost implications of a transition to 'thick' Whois for Registries, Registrars, registrants and other parties for all gTLDs? Conversely, what are the cost implications to Registries, Registrars, registrants and other parties if no transition is mandated?

-           Synchronization/migration: what would be the impact on the   registry and registrar WHOIS and EPP systems for those Registries currently operating a thin registry, both in the migration phase to ‘thick’ WHOIS as well as ongoing operations?

-           Authoritativeness:  what are the implications of a ‘thin’ Registry possibly becoming authoritative for registrant Whois data following the transition from a thin-registry model to a thick-registry model. The Working Group should consider the term “authoritative” in both the technical (the repository of the authoritative data) and policy (who has authority over the data) meanings of the word when considering this issue.

-           Competition in registry services: what would be the impact on competition in registry services should all Registries be required to provide Whois service using the ‘thick’ Whois model – would there be more, less or no difference with regard to competition in registry services?

-           Existing Whois Applications:  What, if anything, are the potential impacts on the providers of third-party WHOIS-related applications if ‘thick’ WHOIS is required for all gtLDs?

-           Data escrow: ‘thick’ Whois might obviate the need for the registrar escrow program and attendant expenses to ICANN and registrars.

-           Registrar Port 43 Whois requirements: ‘thick’ Whois could make the requirement for Registrars to maintain Port 43 Whois access redundant.


Should the PDP WG reach consensus on a recommendation that ‘thick’ Whois should be required for all gTLDs, the PDP WG is also expected to consider:

-           Cost implications for gTLD registries, registrars and registrants of a transition to ‘thick’ Whois

-           Guidelines as to how to conduct such a transition (timeline, requirements, potential changes to Registration Agreements, etc.)

-           Are special provisions and/or exemptions needed for gTLD registries which operate a ‘thick’ Whois but provide tiered access [2] , for example?


In addition, the PDP WG should take into account other ICANN initiatives that may help inform the deliberations limited to this specific topic such as;

  • Registry/registrar separation and related developments with regards to access to customer data;
  • Output from any/all of the four Whois Studies chartered by the GNSO Council, if completed in time for consideration by the WG;
  • The 2004 transition of .ORG from thin to thick;
  • The work being done concurrently on the internationalization of Whois and the successor to the Whois protocol and data model;
  • Results of the RAA negotiations, and
  • Recommendations of the Whois Review Team.


The PDP WG is also expected to consider any information and advice provided by other ICANN Supporting Organizations and Advisory Committees on this topic. The WG is strongly encouraged to reach out to these groups for collaboration at an early stage of its deliberations, to ensure that their concerns and positions are considered in a timely manner.

Objectives & Goals:

To develop, at a minimum, an Initial Report and a Final Report regarding the use of 'thick' Whois by all gTLD Registries, both existing and future to be delivered to the GNSO Council, following the processes described in Annex A of the ICANN Bylaws and the GNSO PDP Manual.

Deliverables & Timeframes:

The WG shall respect the timelines and deliverables as outlined in Annex A of the ICANN Bylaws and the PDP Manual. As per the GNSO Working Group Guidelines, the WG shall develop a work plan that outlines the necessary steps and expected timing in order to achieve the milestones of the PDP as set out in Annex A of the ICANN Bylaws and the PDP Manual and submit this to the GNSO Council.

Section III:  Formation, Staffing, and Organization

Membership Criteria:

The Working Group will be open to all interested in participating. New members who join after certain parts of work has been completed are expected to review previous documents and meeting transcripts. 

Group Formation, Dependencies, & Dissolution:

This WG shall be a standard GNSO PDP Working Group. The GNSO Secretariat should circulate a ‘Call For Volunteers’ as widely as possible in order to ensure broad representation and participation in the Working Group, including:

-           Publication of announcement on relevant ICANN web sites including but not limited to the GNSO and other Supporting Organizations and Advisory Committee web pages; and

-           Distribution of the announcement to GNSO Stakeholder Groups, Constituencies and other ICANN Supporting Organizations and Advisory Committees

Working Group Roles, Functions, & Duties:

The ICANN Staff assigned to the WG will fully support the work of the Working Group as requested by the Chair including meeting support, document drafting, editing and distribution and other substantive contributions when deemed appropriate.

Staff assignments to the Working Group:

  • GNSO Secretariat
  • 1 ICANN policy staff member (Marika Konings)


The standard WG roles, functions & duties shall be applicable as specified in Section 2.2 of the Working Group Guidelines.

Statements of Interest (SOI) Guidelines:

Each member of the Working Group is required to submit an SOI in accordance with Section 5 of the GNSO Operating Procedures.

Section IV:  Rules of Engagement

Decision-Making Methodologies:

{Note: The following material was extracted from the Working Group Guidelines, Section 3.6. If a Chartering Organization wishes to deviate from the standard methodology for making decisions or empower the WG to decide its own decision-making methodology, this section should be amended as appropriate}.


The Chair will be responsible for designating each position as having one of the following designations:

  • Full consensus - when no one in the group speaks against the recommendation in its last readings.  This is also sometimes referred to as Unanimous Consensus.
  • Consensus - a position where only a small minority disagrees, but most agree. [Note: For those that are unfamiliar with ICANN usage, you may associate the definition of ‘Consensus’ with other definitions and terms of art such as rough consensus or near consensus. It should be noted, however, that in the case of a GNSO PDP originated Working Group, all reports, especially Final Reports, must restrict themselves to the term ‘Consensus’ as this may have legal implications.]
  • Strong support but significant opposition - a position where, while most of the group supports a recommendation, there are a significant number of those who do not support it.
  • Divergence (also referred to as No Consensus ) - a position where there isn't strong support for any particular position, but many different points of view.  Sometimes this is due to irreconcilable differences of opinion and sometimes it is due to the fact that no one has a particularly strong or convincing viewpoint, but the members of the group agree that it is worth listing the issue in the report nonetheless.
  • Minority View - refers to a proposal where a small number of people support the recommendation.  This can happen in response to a Consensus , Strong support but significant opposition , and No Consensus; or, it can happen in cases where there is neither support nor opposition to a suggestion made by a small number of individuals.


In cases of Consensus , Strong support but significant opposition , and No Consensus , an effort should be made to document that variance in viewpoint and to present any Minority View recommendations that may have been made.  Documentation of Minority View recommendations normally depends on text offered by the proponent(s).  In all cases of Divergence, the WG Chair should encourage the submission of minority viewpoint(s).


The recommended method for discovering the consensus level designation on recommendations should work as follows:

  1. After the group has discussed an issue long enough for all issues to have been raised, understood and discussed, the Chair, or Co-Chairs, make an evaluation of the designation and publish it for the group to review.
  2. After the group has discussed the Chair's estimation of designation, the Chair, or Co-Chairs, should reevaluate and publish an updated evaluation.
  3. Steps (i) and (ii) should continue until the Chair/Co-Chairs make an evaluation that is accepted by the group.
  4. In rare case, a Chair may decide that the use of polls is reasonable. Some of the reasons for this might be:
    • A decision needs to be made within a time frame that does not allow for the natural process of iteration and settling on a designation to occur.
    • It becomes obvious after several iterations that it is impossible to arrive at a designation. This will happen most often when trying to discriminate between Consensus and Strong support but Significant Opposition or between Strong support but Significant Opposition and Divergence.


Care should be taken in using polls that they do not become votes.  A liability with the use of polls is that, in situations where there is Divergence or Strong Opposition , there are often disagreements about the meanings of the poll questions or of the poll results.


Based upon the WG's needs, the Chair may direct that WG participants do not have to have their name explicitly associated with any Full Consensus or Consensus view/position.  However, in all other cases and in those cases where a group member represents the minority viewpoint, their name must be explicitly linked, especially in those cases where polls where taken.


Consensus calls should always involve the entire Working Group and, for this reason, should take place on the designated mailing list to ensure that all Working Group members have the opportunity to fully participate in the consensus process.  It is the role of the Chair to designate which level of consensus is reached and announce this designation to the Working Group. Member(s) of the Working Group should be able to challenge the designation of the Chair as part of the Working Group discussion.  However, if disagreement persists, members of the WG may use the process set forth below to challenge the designation.


If several participants (see Note 1 below) in a WG disagree with the designation given to a position by the Chair or any other consensus call, they may follow these steps sequentially:

  1. Send email to the Chair, copying the WG explaining why the decision is believed to be in error.
  2. If the Chair still disagrees with the complainants, the Chair will forward the appeal to the CO liaison(s).  The Chair must explain his or her reasoning in the response to the complainants and in the submission to the liaison. If the liaison(s) supports the Chair's position, the liaison(s) will provide their response to the complainants.  The liaison(s) must explain their reasoning in the response.  If the CO liaison disagrees with the Chair, the liaison will forward the appeal to the CO.  Should the complainants disagree with the liaison support of the Chair’s determination, the complainants may appeal to the Chair of the CO or their designated representative.  If the CO agrees with the complainants’ position, the CO should recommend remedial action to the Chair.
  3. In the event of any appeal, the CO will attach a statement of the appeal to the WG and/or Board report.  This statement should include all of the documentation from all steps in the appeals process and should include a statement from the CO (see Note 2 below).


Note 1 :  Any Working Group member may raise an issue for reconsideration; however, a formal appeal will require that that a single member demonstrates a sufficient amount of support before a formal appeal process can be invoked. In those cases where a single Working Group member is seeking reconsideration, the member will advise the Chair and/or Liaison of their issue and the Chair and/or Liaison will work with the dissenting member to investigate the issue and to determine if there is sufficient support for the reconsideration to initial a formal appeal process.


Note 2 :  It should be noted that ICANN also has other conflict resolution mechanisms available that could be considered in case any of the parties are dissatisfied with the outcome of this process.

Status Reporting:

As requested by the GNSO Council, taking into account the recommendation of the Council liaison to this group.

Problem/Issue Escalation & Resolution Processes:

{Note:  the following material was extracted from Sections 3.4, 3.5, and 3.7 of the Working Group Guidelines and may be modified by the Chartering Organization at its discretion}


The WG will adhere to ICANN’s Expected Standards of Behavior as documented in Section F of the ICANN Accountability and Transparency Frameworks and Principles, January 2008.


If a WG member feels that these standards are being abused, the affected party should appeal first to the Chair and Liaison and, if unsatisfactorily resolved, to the Chair of the Chartering Organization or their designated representative.  It is important to emphasize that expressed disagreement is not, by itself, grounds for abusive behavior.  It should also be taken into account that as a result of cultural differences and language barriers, statements may appear disrespectful or inappropriate to some but are not necessarily intended as such.  However, it is expected that WG members make every effort to respect the principles outlined in ICANN’s Expected Standards of Behavior as referenced above.


The Chair, in consultation with the Chartering Organization liaison(s), is empowered to restrict the participation of someone who seriously disrupts the Working Group.  Any such restriction will be reviewed by the Chartering Organization.  Generally, the participant should first be warned privately, and then warned publicly before such a restriction is put into place. In extreme circumstances, this requirement may be bypassed.


Any WG member that believes that his/her contributions are being systematically ignored or discounted or wants to appeal a decision of the WG or CO should first discuss the circumstances with the WG Chair.  In the event that the matter cannot be resolved satisfactorily, the WG member should request an opportunity to discuss the situation with the Chair of the Chartering Organization or their designated representative.


In addition, if any member of the WG is of the opinion that someone is not performing their role according to the criteria outlined in this Charter, the same appeals process may be invoked.


Closure & Working Group Self-Assessment:

The WG will close upon the delivery of the Final Report, unless assigned additional tasks or follow-up by the GNSO Council.

Section V:  Charter Document History





8 October 2012

Final version submitted by the DT to the GNSO Council for consideration
















Staff Contact:

Marika Konings



[1] 'A Registered Name is "sponsored" by the registrar that placed the record associated with that registration into the registry. Sponsorship of a registration may be changed at the express direction of the Registered Name Holder or, in the event a registrar loses accreditation, in accordance with then-current ICANN specifications and policies' (see )

[2] For some registries, ‘Thick’ Whois information is available at the registry, but public access to the data is organized in tiers. For example, for .name, the full set of data is available to requesters if the requester enters into an agreement with the registry under the Extensive Whois Data tier. See for further details.

  • No labels