Dear All, Please find below ICANN staff's response to the questions outlined in the motion that was adopted by the GNSO Council on 18 December 2008 on the Post-Expiration Domain Name Recovery Issues report (https://st.icann.org/gnso-council/index.cgi?18_dec_2008_motions). With best regards, Marika ===================== ICANN Staff is asked to provide clarification no later than 15 January 2009 on the following from the Issues Report: 1. In Section 4.2, in reference to the last bullet on page 15 regarding "how best to enable the transfer of a domain name in RGP", the continuation of the same paragraph on page 16 reads, "On the latter point, the GNSO Council might want to consider whether this should be investigated in the context of the upcoming Inter-Registrar Transfer Policy PDP C, 'IRTP Operational Rules Enhancements'." * Is it recommended that this would be added to the requirements for IRTP PDP C? As the issue of whether or not to allow the transfer of a domain name in RGP directly relates to the Inter-Registrar Transfer Policy, ICANN staff deems it appropriate for the GNSO Council to consider whether this issue can be included in one of the upcoming PDPs in this area. As noted by the Technical Steering Group (http://www.icann.org/en/meetings/bucharest/redemption-topic.htm) that developed an RGP implementation proposal, 'allowing registrants to choose the redeeming registrar will introduce numerous technical and operational complications into the system', which staff thinks might be best dealt with in the context of the inter-registrar transfer policy. From the upcoming IRTP PDPs, PDP C (operational rule enhancements) seems to be best suited to potentially deal with this issue. The issue of whether or not to allow the transfer of a domain name in RGP could also be considered as part of an overall PDP dealing with other post-expiration domain name recovery issues. However, in consideration of the above, ICANN staff recommends that the GNSO Council consider the issue in one of the already foreseen IRTP PDPs, most logically IRTP PDP C. * What action items might be needed to accomplish this recommendation? The GNSO Council would need to adopt a motion stating that it would like to see this issue addressed in one of the upcoming IRTP PDPs. Following the adoption of this motion, the charter for the IRTP PDP that deals with this issue would contain text to reflect this decision to add this specific issue to that PDP. * What changes would need to be made to IRTP PDP C? This issue would be included in the Charter for the relevant Working Group, when drafted. 2. In the last paragraph of Section 4.2 on page 16, Staff recommends ". . . the GNSO Council could consider enhancements, which would highlight more clearly and visibly the provisions of the contract in relation to auto-renew and expiration policies. It should be noted that ICANN staff does not recommend that this be included in a PDP . . ." * How is it envisioned that this would happen if not via a PDP? Compliance efforts in combination with information and educational activities might be considered in this context. It should be noted that such actions would not necessarily require Council action. For example, ICANN's compliance department currently organizes educational workshops in conjunction with ICANN meetings at which information provision requirements incorporated in the RAA relevant to this topic could be included as a topic of discussion. Furthermore the Compliance team is currently conducting an audit as part of its 2009 audit schedule regarding the registrar requirement to have deletion and renewal policies clearly displayed on registrar websites. In addition, a workshop with interested parties such as the ALAC and registrars could be considered to discuss potential enhancements and/or educational initiatives. Another avenue to be explored, as noted by a previous Chair of the GNSO Council could be that 'perhaps ICANN and the GNSO can assist with providing authoritative information on the policies and processes of domain name registration to these [consumer protection] organisations'. * What action items might be needed to accomplish this recommendation? As noted above, the activities described do not necessarily require Council action. ICANN's Compliance team has already commenced some of above referenced work and further discussions are being held internally to determine the best way to conduct educational sessions relevant to registrar requirements concerning deletion and renewal policies. 3. Section 3.7.5 of ICANN's Registrar Accreditation Agreement, as quoted on page 28, says, "At the conclusion of the registration period, failure by or on behalf of the Registered Name Holder to consent that the registration be renewed within the time specified in a second notice or reminder shall, in the absence of extenuating circumstances, result in cancellation of the registration by the end of the auto-renew grace period (although Registrar may choose to cancel the name earlier)." * Is this requirement being enforced? If not, why not? Yes, this requirement is consistently enforced. The ICANN Compliance Department investigates all complaints that are received with regard to the non-cancellation of the registration if the Registered Name Holder or someone acting on behalf of the Registered Name Holder does not renew the registration. It should be noted that there have been complaints that turned out to be unfounded, as many registration agreements contain provisions in which the Registered Name Holder consents to someone acting on behalf of the Registered Name Holder to renew the registration, an issue that has also been outlined in the Issues Report in further detail. * Under this policy, wouldn't registrars be required to cancel (delete) a registration, in the absence of extenuating circumstances as defined in this section, if a Registered Name Holder does not consent to renewal? If not, why not? The above statement is not completely correct. Registrars are required to delete a registration, in the absence of extenuating circumstances as defined in the RAA, if a Registered Name Holder or someone acting on behalf of the Registered Name Holder does not consent to renewal. In this context it might be worth pointing to an advisory that ICANN published in 2004 to make the community aware of modifications that many registrars have made in registration agreements that result in the registrar obtaining the consent of the registrant to auction and/or transfer a domain name registration to a third party if the Registered Name Holder does not renew his/her registration. See http://www.icann.org/en/announcements/announcement-21sep04-1.htm for further details. 4. Section 3.7.5.3 on page 29 reads, "In the absence of extenuating circumstances (as defined in Section 3.7.5.1 above), a domain name must be deleted within 45 days of either the registrar or the registrant terminating a registration agreement." * Is this requirement being enforced? If not, why not? Yes, this requirement is being enforced. However as noted before, this only applies if the registration is not renewed by the Registered Name Holder or someone acting on behalf of the Registered Name Holder. * Under this policy, wouldn't registrars be required to cancel (delete) a registration, in the absence of extenuating circumstances as defined in this section, if a Registered Name Holder or the Registrar terminates a registration agreement? If not, why not? In the case of termination of a registration agreement, the respective registration agreement would need to be analyzed in order to determine which conditions apply. The Expired Domain Deletion Policy only applies to expired domain names.