AT-LARGE GATEWAY

At-Large Website

ALAC

RALOs

At-Large Regional Policy Engagement Program (ARPEP)

At-Large Governance

At-Large Reports

Policy Comments & Advice

Working Groups

ICANN Meetings

At-Large Summit (ATLAS III)

At-Large Review Implementation Plan Development

ALAC and RALO Elections, Selections, and Appointments

At-Large Priority Activities - 2021

Comment Close
Date		Statement
Name 

Status

Assignee(s)

Call for
Comments Open		Call for
Comments
Close 		Vote OpenVote CloseDate of SubmissionStaff Contact and EmailStatement Number
 

Registration Data Access Protocol (RDAP) Operational Profile for gTLD Registries and Registrars

ADOPTED 14Y, 0N, 0A

Holly Raiche

Carlton Samuels

     
Francisco Arias
francisco.arias@icann.org
AL-ALAC-ST-0116-01-00-EN

For information about this Public Comment, please click here 

 

Brief Overview

Purpose: This public comment proceeding is being opened to obtain community input on the Registration Data Access Protocol (RDAP) Operational Profile for gTLD Registries and Registrars.

Current Status: This is a draft version on the Registration Data Access Protocol (RDAP) Operational Profile for gTLD Registries and Registrars.

Next Steps: Following review of public comments received on this profile, ICANN staff will update the profile as appropriate to reflect public comment.

Section I: Description, Explanation, and Purpose

ICANN is seeking input on the Registration Data Access Protocol (RDAP) Operational Profile forgTLD Registries and Registrars, which covers the features within the RDAP protocol that are mandatory, the basic parameters, the mandatory set of objects to be implemented, and other allowed optional objects.

RDAP is the protocol that was developed by the Technical Community within the IETF with the intention to replace the (port-43) Whois protocol.

Section II: Background

Created in the 1980s, Whois began as a service used by Internet operators to identify individuals or entities responsible for the operation of a network resource on the Internet. The Whois service has since evolved into a tool used for many purposes. However, as usage of Whois service evolved, few changes have been made to the protocol that supports the service. As a result, there is growing concern that the protocol would not meet the need of the community.

Beginning in 2002, ICANN's Security and Stability Advisory Committee (SSAC) published various advisories describing deficiencies related to the WHOIS protocol, service and data schema, most recently SAC 051: SSAC Report on Domain Name Whois Terminology and Structure [PDF, 243 KB]. SAC 051 summarizes the previous advisories, and among other things, recommends that the ICANN community evaluate and adopt a replacement protocol.

Recognizing its concerns with the Whois protocol deficiencies, on 28 October 2011, the ICANNBoard approved a resolution directing staff to produce, in consultation with the community, a roadmap for the coordination of the technical and policy discussions necessary to implement the recommendations outlined in SAC 051.

On 4 June 2012, ICANN published a Roadmap [PDF, 218 KB] for the coordination of the technical and policy discussions necessary to implement the recommendations outlined in SAC 051. There are two main recommendations in SAC 051: 1) improve Whois terminology to enhance and disambiguate the discussion; and 2) replace the Whois protocol to address various technical issues (e.g., internationalization).

In 2012, The Internet Engineering Task Force (IETF) chartered the WEIRDS (Web Extensible Internet Registration Data Services) working group to determine the needs of the community. This working group concluded in early 2015 with the publication of several specifications (RFC7480, RFC7481, RFC7482, RFC7483, RFC7484 and RFC7485) defining the behavior of the Registry Data Access Protocol (RDAP), a standardized replacement for WHOIS.

Contracted parties operating according to an agreement, which includes a clause to implement a successor protocol to WHOIS, are required to deploy RDAP.  As of the time this document is published, the set of contracted parties subject to this are: RAA 2013 Registrars, gTLDs of the 2012 round (New gTLDs) and other gTLDs (.biz, .com, .info, .jobs, .name, .org, .xxx).

The Generic Names Supporting Organization (GNSO) Council unanimously approved at its meeting on 31 October 2013 the recommendations of the Thick Whois Policy Development Process (PDP) Working Group. The GNSO Council recommends that: "the provision of thick Whois services, with a consistent labeling and display as per the model outlined in specification 3 of the 2013 RAA, should become a requirement for all gTLD registries, both existing and future".

On 7 February 2014, the board adopted the GNSO Council Policy Recommendations for a newConsensus Policy on Thick Whois and directed the President and CEO to develop and execute an implementation plan for the Thick Whois Policy consistent with the guidance provided by theGNSO Council.

The GNSO Implementation Review Team (IRT) for the Thick Whois Policy Implementation agreed with the proposal of ICANN Staff to synchronize implementation of the policy with the adoption of RDAP. The RDAP Operational Profile for gTLD Registries and Registrars includes support for the consistent labeling and display, described in the Thick Whois Policy Recommendation. It should be noted that ICANN staff and the Thick Whois Policy IRT are currently seeking public commenton a Draft Thick RDDS (Whois) Consensus Policy addressing the consistent labeling and display of Whois output for all gTLDs.

On 28 September 2015, ICANN published a proposed draft of the RDAP operational profile forgTLD registries and registrars for discussion with the community. Several members of the community provided valuable inputs that have been incorporated in the version being published for public comments.

On 28 November 2015, ALAC published a statement [PDF, 252 KB] requesting that the profile"must include the feature set that will support differentiated access" (e.g., provide access to all registration data fields to only authenticated users, while the non-authenticated users only can see a subset of fields). Similarly, during and subsequent to the ICANN54 a few others have expressed similar requests. ICANN notes that the current draft gTLD RDAP profile does allow for differentiated access for those that have contracts that permit such a service, or in the event a consensus policy on differentiated access is completed.

A proposal in the gTLD-tech mailing list included details on how to implement differentiated access by describing two different types of access (limited access for anonymous users, and full access for authenticated users). The proposal was sensible to the fact that the majority of current gTLD agreements and existing consensus policies do not contemplate differentiated access. The proposal indicated that differentiated access as described should be implemented by all, but not enabled until a contract change or a consensus policy on the subject had been put in place. ICANN notes that for the three gTLDs that have differentiated access in their registry agreements, there are, at least two models. One model describes two levels of access (similar to the aforementioned proposal) for .tel and .cat (see section 5 of Exhibit A). Another model includes four levels of access for .name. Additionally, there is a Policy Development Process (PDP) initiating on Registry Directory Services that will consider the broader issue of access to registration data, including the potential for differentiated access as described in the adopted Charter for the PDP working group (see Annex C of the Final Issues Report [PDF, 1.2 MB]).

Given the ongoing discussions and work in the community on differentiated access, it is premature to include a requirement for all gTLDs in the RDAP Profile (except for the three aforementioned gTLDs). Once/if there is a consensus policy or some contractual provision allowing for differentiated access in RDAP, the profile could be updated as needed. Those interested in differentiated access are suggested to participate in the upcoming PDP working group in Registry Directory Services. A call for volunteers is planned by January 2016.

Section III: Relevant Resources

Section IV: Additional Information

Thick Whois Policy Public Comment

Section V: Reports

Staff Contact

Francisco Arias
francisco.arias@icann.org

 

FINAL VERSION TO BE SUBMITTED IF RATIFIED

Click here to download the Statement below.

 

FINAL DRAFT VERSION TO BE VOTED UPON BY THE ALAC

The ALAC welcomes the opportunity to comment on the Registration Data Access Protocol (RDAP) Operational Profile for gTLD Registries and Registrars.

While the new RDAP Operational Profile includes many new enhanced features from the previous Whois protocol, it does not include a list of mandatory features and provisions that will support an authentication and authorisation access control framework.

The SSAC in its 2011 report on Domain Name Whois Terminology and Structure (SAC 051) recommended the development of replacement protocol that would provide a uniform and standard framework for accessing Domain Name Registration Data (DNRD). That framework would ‘define and implement verification methods, credential services and access control capabilities’. The Board accepted SSAC recommendations and established the Expert Working Group on gTLD Directory Services (EWG) to begin implementation of the recommendations. In its Final Report, the EWG recommended a paradigm shift whereby gTLD registration data is collected, validated and disclosed for permissible purposes only, with some data elements being accessible only to authenticated requestors that are then held accountable for appropriate use. 

Therefore, while existing ICANN policies do not now require differentiated access to DNRD, it is clear from Board decisions and EWG recommendations that future ICANN policies will likely have that requirement. 

The Operational Profile of RDAP, therefore, should include an obligation on all gTLD registries and registrars that the basic functionality will support an authentication and authorisation framework.

Specifically, the features to allow differentiated access must be required now, as part of this protocol – even if at this stage all access seekers will be in one class - the public. In that way, when differentiated access requirements are imposed, protocol features will already be deployed to provide such access.

 

FIRST DRAFT SUBMITTED

Background: 

ALAC has already sent a letter to the Board on this issue so the statement does not have to be lengthy. However, it would look very odd if we did not take the opportunity to formally express our concerns on the issue.  The actual protocol is a very technical document, largely addressing the many issues highlighted by SAC051 - which is a good thing.  Our concern, however, is that the additional features of the Protocol that would provide a framework for authentication and authorisation are not mandatory.  The reason I have included mention of the SAC051 is that the Board endorsed all of its recommendations, including the need to support differentiated access. Therefore, it is clear that the policy direction is for differentiated access, and the Protocol should include mandatory requirements that will support differentiated access so that when the policies are changed, the technical features will be in place to support the policy change.

 

Proposed Statement:

The ALAC welcomes the opportunity to comment on the Registration Data Access Protocol (RDAP) Operational Profile for gTLD Registries and Registrars.

While the new RDAP Operational Profile includes many new enhanced features from the previous Whois protocol, it does not include in its list of mandatory features provisions that will support an authentication and authorisation access control framework.

The SSAC in its 2011 report on Whois Terminology and Structure (SAC 051) recommended the development of replacement protocol that would provide a uniform and standard framework for accessing Domain Name Registration Data (DNRD) that would ‘define and implement verification methods, credential services and access control capabilities’.   The Board accepted SSAC recommendations and established the Expert Working Group to begin implementation of the recommendations.  In its Final Report, the EWG recommended a paradigm shift whereby gTLD registration data is collected, validated and disclosed for permissible purposes only, with some data elements being accessible only to authenticated requestors that are then held accountable for appropriate use. 

Therefore, while existing ICANN policies do not now require differentiated access to DNRD, it is clear from Board decisions and EWG recommendations, that future ICANN policies will. 

The Operational Profile of RDAP, therefore, should include an obligation on all gTLD registries and registrars the basic functionality that will support an  authentication and authorisation framework.

Specifically, the features required to allow differentiated access must be required now, as part of this Protocol – even if at this stage, all access seekers will be in  one class – the public.  In that way, when differentiated access requirements are imposed, Protocol features will already be deployed to provide such access.

 

  • No labels

2 Comments

  1. Holly Raiche

    Background:  ALAC has already sent a letter to the Board on this issue so the statement does not have to be lengthy. However, it would look very odd if we did not take the opportunity to formally express our concerns on the issue.  The actual protocol is a very technical document, largely addressing the many issues highlighted by SAC051 - which is a good thing.  Our concern, however, is that the additional features of the Protocol that would provide a framework for authentication and authorisation are not mandatory.  The reason I have included mention of the SAC051 is that the Board endorsed all of its recommendations, including the need to support differentiated access. Therefore, it is clear that the policy direction is for differentiated access, and the Protocol should include mandatory requirements that will support differentiated access so that when the policies are changed, the technical features will be in place to support the policy change.

     

    Proposed Statement:

    The ALAC welcomes the opportunity to comment on the Registration Data Access Protocol (RDAP) Operational Profile for gTLD Registries and Registrars.

     

    While the new RDAP Operational Profile includes many new enhanced features from the previous Whois protocol, it does not include in its list of mandatory features provisions that will support an authentication and authorisation access control framework.

     

    The SSAC in its 2011 report on Whois Terminology and Structure (SAC 051) recommended the development of replacement protocol that would provide a uniform and standard framework for accessing Domain Name Registration Data (DNRD) that would ‘define and implement verification methods, credential services and access control capabilities’.   The Board accepted SSAC recommendations and established the Expert Working Group to begin implementation of the recommendations.  In its Final Report, the EWG recommended a paradigm shift whereby gTLD registration data is collected, validated and disclosed for permissible purposes only, with some data elements being accessible only to authenticated requestors that are then held accountable for appropriate use.

     

    Therefore, while existing ICANN policies do not now require differentiated access to DNRD, it is clear from Board decisions and EWG recommendations, that future ICANN policies will.

     

    The Operational Profile of RDAP, therefore, should include an obligation on all gTLD registries and registrars the basic functionality that will support an  authentication and authorisation framework.  Specifically, the features required to allow differentiated access must be required now, as part of this Protocol – even if at this stage, all access seekers will be in  one class – the public.  In that way, when differentiated access requirements are imposed, Protocol features will already be deployed to provide such access.

  2. Ariel Liang

    Sebastien Bachollet voted Yes for this Statement but he has the following comments/questions for Holly Raiche and Carlton Samuels:

    I vote yes but I have the following questions/comments:
    WhoIs is both for cc and g TLDs, with RDAP only for gTLDs end users will have different tools to find data (cc vs g). It will add complexity for end users.
    What is the plan for transition for gTLDs (both thin and thick WhoIs)?