Re: [council] Adoption of IRTP Part B recommendations by ICANN Board

[Stéphane Van Gelder <stephane.vangelder@xxxxxxxxx>]

Great new, thanks Marika.

Copying Michele, as Chair of the group, for his info. Michele, please thank the 
group once again for their hard work on the Council's behalf and please accept 
our thanks for your work as Chair of the group.

Stéphane



Le 30 août 2011 à 09:59, Marika Konings a écrit :

> Dear All,
> 
> For your information, the ICANN Board adopted the IRTP Part B recommendations 
> approved by the GNSO Council at its meeting on 25 August (see 
> http://www.icann.org/en/minutes/resolutions-25aug11-en.htm or resolution 
> below).
> 
> With best regards,
> 
> Marika
> 
> ============
> 
> 1.2. Approval of Recommendation of GNSO Council on IRTP Part B
> Whereas on 24 June 2009, the GNSO Council launched a Policy Development 
> Process (PDP) on the Inter-Registrar Transfer Procedure Part B (IRTP Part B) 
> addressing five charter questions, set forth at 
> https://community.icann.org/display/gnsoirtpb/3.+WG+Charter;
> Whereas the PDP followed the prescribed PDP steps as stated in the Bylaws, 
> resulting in a Final Report delivered on 30 May 2011;
> Whereas the IRTP Part B Working Group (WG) reached full consensus on the 
> recommendations in relation to each of the five issues outlined in the 
> Charter;
> Whereas the GNSO Council reviewed, and discussed the recommendations of the 
> IRTP Part B WG, and adopted the Recommendations on 22 June 2011 by a 
> Supermajority and unanimous vote (see: 
> http://gnso.icann.org/resolutions/#201106);
> Whereas the GNSO Council vote met and exceeded the required voting threshold 
> to impose new obligations on ICANN contracted parties.
> Whereas after the GNSO Council vote, a 30-day public comment period was held 
> on the approved recommendations, and the comments have been summarized and 
> considered 
> (http://www.icann.org/en/public-comment/irtp-b-recommendations-08jul11-en.htm).
> Resolved (2011.08.25.02) the Board adopts the GNSO Council Policy 
> Recommendations amending the Inter-Registrar Transfer Policy set forth at 
> http://www.icann.org/en/transfers/policy-en.htm.
> Resolved (2011.08.25.03) the CEO is to develop and complete an implementation 
> plan for these Recommendations and continue communication with the community 
> on such work.
> Resolved (2011.08.25.04) the CEO is directed to undertake the studies 
> identified by the GNSO Council at [identify resolutions here] to facilitate 
> further work on this issue.
> Resolved (2011.08.25.05) the Board encourages the GNSO, the ALAC and all 
> other parts of the ICANN community to work together to promote the measures 
> outlined in the SSAC's report A Registrant's Guide to Protecting Domain Name 
> Registration Accounts (SAC 044), as identified within the GNSO Council 
> Resolutions.
>> Rationale for Resolutions 2011.08.25.02-05
>> 
>> Why the Board is addressing the issue 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. The 
>> IRTP Part B PDP Final Report received unanimous consensus support from the 
>> IRTP Part B Working Group as well as the GNSO Council. Following the closing 
>> of the public comment period on 8 August, the next step as outlined in Annex 
>> A of the ICANN Bylaws is consideration by the ICANN Board of the 
>> recommendations.
>> What is the proposal being considered?
>> The following recommendations are being considered:
>> Requiring Registrars to provide a Transfer Emergency Action Contact (TEAC). 
>> To this end proposed language to modify section 4 (Registrar Coordination) 
>> and Section 6 (Registry Requirements) of the Inter-Registrar Transfer Policy 
>> has been provided (see Annex for further details). The Transfer Emergency 
>> Action Contact (TEAC) is a mechanism to facilitate urgent communications 
>> relating to transfers. The goal of the TEAC is to quickly establish real 
>> time communication between registrar representatives in case of emergency 
>> such as a transfer as a result of a domain name hijacking so that the 
>> registrar can take steps to resolving the issue. The TEAC only addresses 
>> establishing that communication not resolving any disputes that may arise 
>> for which other policies and procedures apply.
>> Modifying section 3 of the IRTP to require that the Registrar of 
>> Record/Losing Registrar be required to notify the Registered Name 
>> Holder/Registrant of the transfer out. The Registrar of Record has access to 
>> the contact information for the Registrant and could modify their systems to 
>> automatically send out the Standardized Form for Losing Registrars 
>> ("Confirmation FOA") to the Registrant. Requiring this notification would 
>> alert the registrant at an earlier stage that a transfer has been requested, 
>> which as a result would bring any potential conflicts to light before a 
>> transfer has been completed and therefore might reduce the number of 
>> conflicts between the admin contact and registrant that would require 
>> undoing a transfer.
>> Modifying Reason for Denial #6 as follows: Express objection to the transfer 
>> by the authorized Transfer Contact. Objection could take the form of 
>> specific request (either by paper or electronic means) by the authorized 
>> Transfer Contact to deny a particular transfer request, or a general 
>> objection to all transfer requests received by the Registrar, either 
>> temporarily or indefinitely. In all cases, the objection must be provided 
>> with the express and informed consent of the authorized Transfer Contact on 
>> an opt-in basis and upon request by the authorized Transfer Contact, the 
>> Registrar must remove the lock or provide a reasonably accessible method for 
>> the authorized Transfer Contact to remove the lock within five (5) calendar 
>> days. The current language of denial reason #6 is not clear and leaves room 
>> for interpretation especially in relation to the term ‘voluntarily' and it 
>> is therefore recommended that this language is expanded and clarified to 
>> tailor it more to explicitly address registrar-specific (i.e. non-EPP) locks 
>> in order to make it clear that the registrant must give some sort of 
>> informed opt-in express consent to having such a lock applied, and the 
>> registrant must be able to have the lock removed upon reasonable notice and 
>> authentication.
>> Deleting denial reason #7 as a valid reason for denial under section 3 of 
>> the IRTP as it is technically not possible to initiate a transfer for a 
>> domain name that is locked, and hence cannot be denied, making this denial 
>> reason obsolete.
>> Which stakeholders or others were consulted?
>> Public comment forums were held on the initiation of the PDP, the Initial 
>> Report, the proposed Final Report and the recommendations subject to Board 
>> Consideration, 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 (see 
>> https://community.icann.org/display/gnsoirtpb/IRTP+Part+B). All comments 
>> received have been 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, a public comment forum was held on the 
>> recommendations to be considered by the ICANN Board.
>> What concerns or issues were raised by the community?
>> The only concern raised as part of the public comment forum on the 
>> recommendations to be considered by the ICANN Board was with regard to the 
>> four hour response time required as part of the Transfer Emergency Action 
>> Contact (TEAC) recommendation. The commenter noted that it would put ‘too 
>> much burden on small and medium sized registrars'. However, the commenter 
>> seemed to assume that a resolution is required within four hours (‘A final 
>> solution/ settlement can take place also after 1 or 2 days') instead of an 
>> initial response, which is the only requirement under the proposed TEAC. As 
>> the IRTP Part B PDP Working Group explained it in its Final Report ‘the goal 
>> of the TEAC is to quickly establish real time communication between 
>> registrar representatives who can take steps to resolving the issue, but 
>> this policy only addresses establishing that communication not resolving any 
>> disputes that may arise'. With regard to the four hour response time, the 
>> IRTP Part B PDP Working Group noted that ‘even the smallest of registrars 
>> can simply rotate this function among operational staff, just as they rotate 
>> other "emergency" aspects of their business. The number of TEAC requests is 
>> likely to be very small and quite infrequent, but when they occur there is a 
>> genuine emergency that needs to be dealt with quickly'. It should be noted 
>> that both small as well as big registrars participated in the deliberations 
>> of the IRTP Part B Working Group and supported the recommendations.
>> What significant materials did the Board review?
>> The Board reviewed the GNSO Council Report to the Board, as well as the 
>> summary of public comments and Staff's response to those comments.
>> What factors the Board found to be significant?
>> The recommendations were developed following the GNSO Policy Development 
>> Process as outlined in Annex A of the ICANN Bylaws and have received the 
>> unanimous support from the GNSO Council. As outlined in the ICANN 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 ICANN 
>> community 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.