2012-05-06 - IRTP Part B, Recommendation 8

Why is this issue addressed now?
The Inter-Registrar Transfer Policy (IRTP) is a consensus policy that was adopted in 2004 which provides for a straightforward process for registrants to transfer domain names between registrars. The GNSO Council established a series of five Working Groups (Parts A through E) to review and consider various revisions to this policy.

The IRTP Part B PDP is the second in a series of five scheduled PDPs addressing areas for improvements in the existing policy. The IRTP Part B Working Group has addressed five issues focusing on domain hijacking, the urgent return of an inappropriately transferred name, and lock status. Most of these recommendations have already been adopted by the GNSO Council and the ICANN Board. In relation to recommendation #8, a proposal from staff was requested. Following consultations with the IRTP Part B Working Group and a public comment forum on the Staff Proposal, ICANN Staff submitted its proposal to the GNSO Council. Following this, additional comments were submitted by the Intellectual Property Constituency. The GNSO Council reviewed the comments and the updated staff proposal, which was submitted addressing the comments provided by the IPC. The GNSO Council approved IRTP Part B Recommendation #8 and the updated staff proposal unanimously at its meeting on 16 February 2012 (seehttp://gnso.icann.org/resolutions/#201202). The IRTP Part B PDP Final Report received unanimous consensus support from the IRTP Part B Working Group as well as the GNSO Council.

What is the proposal being put forward for Board consideration?
Recommendation #8 recommends standardizing and clarifying WHOIS status messages regarding Registrar Lock status. The goal of these changes is to clarify why the Lock has been applied and how it can be changed. Based on discussions with technical experts, the IRTP Part B WG does not expect that such a standardization and clarification of WHOIS status messages would require significant investment or changes at the registry/registrar level. The IRTP Part B WG recommended that ICANN staff is asked to develop an implementation plan for community consideration which ensures that a technically feasible approach is developed to implement this recommendation.

The ICANN Staff proposal agrees that the standardization and clarification of WHOIS status messages does not require significant investment or changes at the registry/registrar level. As outlined in the IRTP Part B Final Report, it is possible to associate each EPP status value with a message that explains the meaning of the respective status value. Registrars would be required to display a link to information on each status code directly next to the status in the output, for example: "Status: ClientLock http://www.internic.net/status/html/clientlock". This link would then direct to an ICANN controlled web page where the relevant status code information as described in the ‘EPP Status Codes, what do they mean and why should I know?' ¹ is posted. ICANNwill also post translations of the status information. The web page can make use of localization information from the browser the user is using to display the web page in the related language. The requirement for registries and registrars to provide this link and ensure uniformity in the message displayed could be implemented as a standalone ‘WHOIS Status Information Policy' or as an addition to the IRTP. In order to avoid potential blocking or stripping out of URLs from WHOIS output for valid reasons, registrars would be required to not remove Internic.net hyperlinks (or particularly the Internic.net status hyperlink) from their WHOIS output. In addition to the link, registrars would be required to include in the WHOIS output a note that would state "For more information on WHOIS status codes, please visit Internic.net" where the link to the information would be posted.

Outreach conducted by the Working Group to solicit views of groups that are likely to be impacted:
Public comment forums were held by the Working Group on the initiation of the PDP, the Initial Report, the proposed Final Report and the Staff Proposal on Recommendation #8 in additional to regular updates to the GNSO Council as well as workshops to inform and solicit the input from the ICANN Community at ICANN meetings (see for example, Brussels Meeting and San Francisco Meeting). Constituency / Stakeholder Group Statements were submitted (seehttps://community.icann.org/display/gnsoirtpb/IRTP+Part+B). All comments received were reviewed and considered by the IRTP Part B PDP WG (see section 6 of the IRTP Part B Final Report [PDF, 972 KB]). In addition, as prescribed by the ICANN Bylaws, apublic comment forum was held on the recommendations to be considered by the ICANNBoard.

What concerns or issues were raised by the community?
Following the closing of the public comment forum on the staff proposal (no comments received) and the submission of the proposal to the GNSO Council, the Intellectual Property Constituency submitted a number of comments, which ICANN staff responded to by submitting an updated proposal. The comments and updated proposal were considered as part of theGNSO Council deliberations. Subsequently, theGNSO Council adopted the recommendation and updated ICANN Staff proposal unanimously. Following the adoption by the GNSO Council, anotherpublic comment forum was opened on the recommendation and staff proposal. Two comments were received, but these comments did not require changes to the recommendation and/or staff proposal in the opinion of ICANN Staff (seehttp://www.icann.org/en/news/public-comment/report-comments-irtp-b-rec8-16apr12-en.pdf [PDF, 340 KB]).

What significant materials did the PDP Working Group and GNSO Council review outlining the support and/or opposition to the proposed recommendations?
The materials and input reviewed by the IRTP Part BPDP Working Group are outlined in the IRTP Part B Final Report [PDF, 972 KB], which also outlines the full consensus support of the IRTP Part B Working Group for this recommendation. In addition to the regular updates as described above, the GNSOCouncil reviewed this Final Report and the ICANNStaff proposal, as well as the comments submitted by the IPC and Staff's response to those comments.

What factors the GNSO Council found to be significant?
The recommendation was developed by the IRTPPart B Working Group following the GNSO Policy Development Process as outlined in Annex A of theICANN Bylaws and has received the unanimous support from the GNSO Council. As outlined in theICANN Bylaws, the Council's unanimous (supermajority) support for the motion obligates the Board to adopt the recommendation unless by a vote of more than 66%, the Board determines that the policy is not in the best interests of the ICANNcommunity or ICANN. In addition, transfer related issues are the number one area of complaint according to data from ICANN Compliance. Improvements to the IRTP have the potential to reduce the number of complaints, in addition to providing clarity and predictability to registrants as well as registrars.

Are there positive or negative community impacts?
Improvements to the IRTP have the potential to reduce the number of complaints, in addition to providing clarity and predictability to registrants as well as registrars. Adoption of the recommendations will require changes in processes for registrars, but these are considered to have a minimum impact and necessary in order to address the issues that are part of this Policy Development Process. The recommendations, if implemented, would usefully clarify and enhance the IRTP, to the advantage of all parties concerned.

Are there fiscal impacts or ramifications on ICANN (strategic plan, operating plan, budget); the community; and/or the public?

Apart from those changes required in process for registrars as outlined above, no other fiscal impacts or ramifications on ICANN; the community; and/or the public are expected.

Are there any security, stability or resiliency issues relating to the DNS?
There are no security, stability, or resiliency issues related to the DNS if the Board approves the proposed recommendations.