Page History

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="ff471f09fdbe6afc-65fd01a0-45e4408d-946d88d4-e401123407af5140610d340a"><ac:plain-text-body><![CDATA[

Resolved

Required Voting Threshold [[1]

[https://community.icann.org/#_ftn1] ]

]]></ac:plain-text-body></ac:structured-macro>

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)

More than 75% of one House and a majority of the other House ("GNSO Supermajority")

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="2563ee035cb5822d-5637c5e3-4a3e42df-a3f69dd9-c50e3bc2199bfd8ddb9960b7"><ac:plain-text-body><![CDATA[Approve a PDP Recommendation Imposing New Obligations on Certain Contracting Parties: where an ICANN contract provision specifies that “a two-thirds vote of the council” demonstrates the presence of a consensus, the GNSO Supermajority vote threshold will have to be met or exceeded with respect to any contracting party affected by such contract provision. In the event a GNSO Supermajority Vote is not achieved, approval of the recommendations contained in the Final Report requires a majority of both houses and further requires that one representative of at least 3 of the 4 Stakeholder Groups supports the recommendations. Abstentions shall not be permitted; thus all Council members must cast a vote unless they identify a financial interest in the outcome of the policy issue.[[2]

[https://community.icann.org/#_ftn2] ]

]]></ac:plain-text-body></ac:structured-macro>