Re: [council] IRTP-B Motion

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

Thanks Tim.

I have added this to the agenda for our Singapore meeting.

Is there a second for this motion?

Stéphane



Le 14 juin 2011 à 05:41, Tim Ruiz a écrit :

> There were no other concerns expressed by Councilors regarding the ITRP-B 
> proposed motion, and Marika made a very helpful suggestion that addressed my 
> concerns regarding two of the recommendations. So I make the following motion 
> (also attached as .doc and .txt files):
>  
> Tim
>  
> Motion on the Adoption of the IRTP Part B Final Report and Recommendations
> 
> WHEREAS on 24 June 2009, the GNSO Council launched a Policy Development 
> Process (PDP) on IRTP Part B addressing the following five charter questions:
> 
> a. Whether a process for urgent return/resolution of a domain name should be 
> developed, as discussed within the SSAC hijacking report
> (http://www.icann.org/announcements/hijacking-report-12jul05.pdf); see also 
> (http://www.icann.org/correspondence/cole-to-tonkin-14mar05.htm);
> 
> b. Whether additional provisions on undoing inappropriate transfers are 
> needed, especially with regard to disputes between a Registrant and Admin 
> Contact (AC). The policy is clear that the Registrant can overrule the AC, 
> but how this is implemented is currently at the discretion of the registrar;
> 
> c. Whether special provisions are needed for a change of registrant when it 
> occurs near the time of a change of registrar. The policy does not currently 
> deal with change of registrant, which often figures in hijacking cases;
> 
> d. Whether standards or best practices should be implemented regarding use of 
> a Registrar Lock status (e.g. when it may/may not, should/should not be 
> applied);
> 
> e. Whether, and if so, how best to clarify denial reason #7: A domain name 
> was already in 'lock status' provided that the Registrar provides a readily
> accessible and reasonable means for the Registered Name Holder to remove the 
> lock status.
> 
> WHEREAS this PDP has 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 WG has reached full consensus on the recommendations 
> in relation to each of the five issues outlined above;
> 
> WHEREAS the GNSO Council has reviewed and discussed these recommendations.
> 
> RESOLVED (A), the GNSO Council recommends to the ICANN Board of Directors:
> 
> 1. Requiring Registrars to provide a Transfer Emergency Action Contact 
> (TEAC). To this end the language of section 4 (Registrar Coordination) and 
> Section 6 (Registry Requirements of the Inter-Registrar Transfer Policy 
> should be updated as follows:
> 
> Transfer Emergency Action Contact (Append to Section 4)
> Registrars will establish a Transfer Emergency Action Contact (TEAC) for 
> urgent communications relating to transfers. The goal of the TEAC is to 
> quickly establish a real-time conversation between registrars (in a language 
> that both parties can understand) in an emergency. Further actions can then 
> be taken towards a resolution, including initiating existing (or future) 
> transfer dispute or undo processes.
> 
> Communications to TEACs will be reserved for use by ICANN-Accredited 
> Registrars, gTLD Registry Operators and ICANN Staff. The TEAC point of 
> contact may be designated as a telephone number or some other real-time 
> communication channel and will be recorded in, and protected by, the ICANN 
> RADAR system. 
> 
> Communications to a TEAC must be initiated in a timely manner, within a 
> reasonable period of time following the alleged unauthorized loss of a domain.
> 
> Messages sent via the TEAC communication channel must generate a 
> non-automated response by a human representative of the gaining Registrar. 
> The person or team responding must be capable and authorized to investigate 
> and address urgent transfer issues. Responses are required within 4 hours of 
> the initial request, although final resolution of the incident may take 
> longer. 
> 
> The losing registrar will report failures to respond to a TEAC communication 
> to ICANN Compliance and the registry operator. Failure to respond to a TEAC 
> communication may result in a transfer-undo in accordance with Section 6 of 
> this policy and may also result in further action by ICANN, up to and 
> including non-renewal or termination of accreditation.
> 
> Both parties will retain correspondence in written or electronic form of any 
> TEAC communication and responses, and share copies of this documentation with 
> ICANN and the registry operator upon request. This documentation will be 
> retained in accordance with Section 3.4 of the Registrar Accreditation 
> Agreement (RAA). Users of the TEAC communication channel should report 
> non-responsive Registrars to ICANN. Additionally, ICANN may conduct periodic 
> tests of the Registrar TEAC communication channel in situations and a manner 
> deemed appropriate to ensure that registrars are indeed responding to TEAC 
> messages. 
> 
> (Append to Section 6) 6 iv. Documentation provided by the Registrar of Record 
> prior to transfer that the Gaining Registrar has not responded to a message 
> via the TEAC within the timeframe specified in Section 4.
> 
> In addition, update section 6 to reflect that the registry, in case of a 
> transfer undo, will reverse the transfer and reset the registrar of record 
> filed to its original state (‘In such case, the transfer will be reversed and 
> the Registrar of Record field reset to its original state'). (IRTP Part B 
> Recommendation #1)
> 
> 2. 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. (IRTP Part B Recommendation #5) 
> 
> 3. 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. (IRTP Part B Recommendation #6)
> 
> 4. 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. (IRTP Part B Recommendation #9 - part 1)
> 
> RESOLVED (B), the GNSO Council recommends the promotion by ALAC and other 
> ICANN structures of the measures outlined in the recent report of the 
> Security and Stability Advisory Committee on A Registrant's Guide to 
> Protecting Domain Name Registration Accounts (SAC 044). In particular, the 
> GNSO Council recommends that registrants consider the measures to protect 
> domain registrar accounts against compromise and misuse described in SAC044, 
> Section 5. These include practical measures that registrants can implement 
> "in house", such as ways to protect account credentials and how to 
> incorporate domain name registrations into employee or resource management 
> programs typically found in medium and large businesses. It suggests ways 
> that registrants can use renewal and change notifications from registrars as 
> part of an early warning or alerting system for possible account compromise. 
> The GNSO Council Chair will reach out to the ALAC and other ICANN structures 
> to inform them of this recommendation and discuss how the GNSO may contribute 
> to this promotion. (IRTP Part B Recommendation #2)
> 
> RESOLVED (C), the GNSO Council recommends that if a review of the UDRP is 
> conducted in the near future, the issue of requiring the locking of a domain 
> name subject to UDRP proceedings is taken into consideration. (IRTP Part B 
> Recommendation #7)
> 
> RESOLVED (D), denial reason #7 should be replaced by adding a new provision 
> in a different section of the IRTP on when and how domains may be locked or 
> unlocked. ICANN Staff is requested to provide a proposal for such a new 
> provision to the GNSO Council for its consideration, taking into account the 
> IRTP Part B WG deliberations in relation to this issue (see IRTP Part B Final 
> Report - (Recommendation #9 - part 2)
> 
> RESOLVED (E), the GNSO Council 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. The GNSO 
> Council requests that ICANN staff develops a proposal for GNSO Council 
> consideration, which ensures that a technically feasible approach is 
> developed to implement this recommendation, taking into account the IRTP Part 
> B WG deliberations in relation to this issue (see IRTP Part B Final Report). 
> (IRTP Part B Recommendation #8)
> 
> RESOLVED (F), the GNSO Council requests an Issues Report on the requirement 
> of ‘thick' WHOIS for all incumbent gTLDs. Such an Issue Report and possible 
> subsequent Policy Development Process should not only consider a possible 
> requirement of 'thick' WHOIS for all incumbent gTLDs in the context of IRTP, 
> but should also consider any other positive and/or negative effects that are 
> likely to occur outside of IRTP that would need to be taken into account when 
> deciding whether a requirement of 'thick' WHOIS for all incumbent gTLDs would 
> be desirable or not. (IRTP Part B Recommendation #3)
> 
> RESOLVED (G), the GNSO Council requests an Issue Report on IRTP Part C, which 
> should include:
> 
> - "Change of Control" function, including an investigation of how this 
> function is currently achieved, if there are any applicable models in the 
> country-code name space that can be used as a best practice for the gTLD 
> space, and any associated security concerns. It should also include a review 
> of locking procedures, as described in Reasons for Denial #8 and #9, with an 
> aim to balance legitimate transfer activity and security. (IRTP Part B 
> Recommendation #4)
> 
> - Whether provisions on time-limiting FOAs should be implemented to avoid 
> fraudulent transfers out. For example, if a Gaining Registrar sends and 
> receives an FOA back from a transfer contact, but the name is locked, the 
> registrar may hold the FOA pending adjustment to the domain name status, 
> during which time the registrant or other registration information may have 
> changed.
> 
> - Whether requirements should be in place for Registrars of Record to send an 
> FOA to the Registrant or Admin Contact. [Is this issue addressed by IRTP Part 
> B Recommendation #5?]
> 
> - Whether the process could be streamlined by a requirement that registries 
> use IANA IDs for registrars rather than proprietary IDs.
> <Motion-IRTP-PartB-Final-Report-and-Recommendations-13June2011.doc><Motion-IRTP-PartB-Final-Report-and-Recommendations-13June2011.txt>