Motion 1 on the Adoption of the IRTP Part B Final Report and Recommendations
Made by: Tim Ruiz
...
Seconded by: Jonathan Robinson
...
Motion on the Adoption of the IRTP Part B Final Report and Recommendations
...
RESOLVED (A), the GNSO Council recommends to the ICANN Board of Directors: (requires a GNSO Supermajority - 75% of one house and a majority of the other house)
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:
...
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),(requires a GNSO Supermajority - 75% of one house and a majority of the other house)
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), (requires a GNSO Supermajority - 75% of one house and a majority of the other house)
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), (Simple majority of each House)
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 - http://www.icann.org/en/announcements/announcement-30may11-en.htm(Recommendation #9 #9 - part 2) Upon review of the proposal, the GNSO Council will consider whether to approve the recommendation.
RESOLVED (E), the GNSO Council recommends (Simple majority of each House)
Prior to the consideration of approval of the recommendation regarding the 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 , the GNSO Council requests that ICANN staff develops to provide a proposal for GNSO Council consideration, which ensures that designed to ensure a technically feasible approach is can be developed to implement meet this recommendation, taking into account the IRTP Part B WG .Staff should take into account the deliberations in relation to this issue (see IRTP Part B Final Report). (IRTP Part B Recommendation #8) The goal of these changes is to clarify why the Lock has been applied and how it can be changed. Upon review of the proposed plan, the GNSO Council will consider whether to approve the recommendation.
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)
...