ICANN/DNSO

GNSO Council Transfer Task Force teleconference January 30, 2003 - minutes


31 January 2003

ATTENDEES:

Marilyn Cade - Chair
Registrars - Ross Rader
CBUC - Grant Forsyth
IPIC - David Safran
(Former GA) - Dan Steinberg

Glen de Saint Géry - GNSO Secretariat

Marilyn Cade suggested that Ross Rader walk the group through the latest Transfer Implementation Committee report and note recommendations where there is support, no support and questions.
http://www.dnso.org/dnso/notes/20030130.TransfersImpFinalReport_v5.html
http://www.dnso.org/clubpublic/nc-transfer/Arc00/msg00704.html

Ross Rader explained:
- table one related to the assessment of implementability from an analysis of Registrars and Registries who were on the committee and does not reflect the broader concerns of the community.
- table two related to information on issues associated with implementation. This would be more for consideration when the Board approves the recommendations.

David Safran asked whether the level of support reflected in table I was support relative to the recommendations as they came out of the Transfer Task Force, or relevant to the recommendations as modified or recommended to be modified as reflected in table 2?

Ross Rader went on to comment on Table Two.
Recommendations 1 & 2 accepted.

Recommendation 3
Existing Recommendation:
Registrars must provide and maintain an email address for use by all other Registrars and registries where formal communications concerning the transfer process can be sent and dealt with by the receiving Registrar.
Suggested Replacement text:
Registrars should provide a unique and private email address for use only by other registrars and the registry:
1. This email is for transfer issues only.
2. The address should be managed to ensure messages are received by someone who can respond to the transfer issue.
3. A timeframe should be required for responses such as this: "commercially reasonable" but not to exceed XX time period. XX time period will be determined within 3 months of implementation.

Marilyn Cade suggested an addition, that the time period could be established and agreed to during the implementation process.
Ross Rader requested it to be noted that "unique" was superfluous. He gave as an argument that the response would be better if the request was being dealt with by a person who knows about transfers.


Recommendation 5.
Existing Recommendation:

The Registrant must be informed of and have access to, the published documentation of the specific transfer process of their current Registrar. The Task Force notes that it would also be useful for Registrants to have access to the transfer process documentation of Registrars that the Registrant is considering switching to.
Suggested replacement text:
Reasonable efforts should be made to inform registrant of and have access to, the published documentation of the specific transfer process of their current registrar. The Task Force notes that it would also be useful for Registrants to have access to the transfer process documentation of Registrars that the Registrant is considering switching to.

Ross Rader commented that the change was very small and the replacement text better brought across the idea of Registrars being made "aware of and have access to the transfer".

Recommendation 8:
Current recommendation:
The Gaining Registrar must verify the intention of the Registrant or Administrative Contact of Record to transfer their domain name registration by requiring that the Registrant complete a valid Standardized Form of Authorization.
Suggested replacement text:
The Gaining Registrar must confirm a transfer request, by requiring that the Registrant or Administrative Contact of Record as listed in the WHOIS complete a valid Standardized Form of Authorization. A transfer must not be allowed to proceed if no confirmation is received.

Accepted

Recommendation 9
Existing recommendation:
The Gaining Registrar is solely responsible for validating Registrant requests to transfer domain names between Registrars. (a) However, this does not preclude the Losing Registrar from exercising its option to independently confirm the Registrant's intent to transfer its domain name to the Gaining Registrar.
Proposed revised text:
The Gaining Registrar is responsible for validating Registrant requests to transfer domain names between Registrars. (a) However, this does not preclude the Losing Registrar from exercising its option to independently confirm the Registrant's intent to transfer its domain name to the Gaining Registrar.

Ross Rader said that it was the most contentious issue was "who does the authorization". He explained that it provides the Gaining registrar to undertake an agreement with the losing registrar and make the commercial agreement between two registrars more tenable.
Marilyn Cade disagreed, saying that it would create a non competitive environment for the small registrars. The recommendation is trying to create a fair competitive environment for all Registrars, while the proposed change creates a confusing environment. It was not introducing stability into the system if registrars were individually allowed to negotiate with each other with different agreements.
This recommendation should be marked for further comment from the Task Force

Recommendation10:
Current recommendation:
In the event that a Registrant has not confirmed their intent to transfer with the Losing Registrar and the Losing Registrar has not explicitly denied the transfer request in accordance with these recommendations, the default action will be that the Losing Registrar must allow the transfer to proceed.
Suggested replacement text:
In the event that a Registrant or Admin Contact listed in the WHOIS has not confirmed their request to transfer with the Losing Registrar and the Losing Registrar has not explicitly denied the transfer request in accordance with these recommendations, the default action will be that the Losing Registrar must allow the transfer to proceed.

Ross Rader explained that the language was clarifying that the registrant trumps the admin contact and made the implementation committee more comfortable with the recommendation.
Ross Rader went on to say that the qualifying text was consistent with the Task Force recommendation.

Recommendation 11:
Existing Recommendation:
If the Losing Registrar chooses to independently confirm the intent of the Registrant when the Losing Registrar receives notice of a pending transfer from the Registry, the Losing Registrar must do so in a manner consistent with the standards set forth in these recommendations of this report pertaining to Gaining Registrars. Specifically, the form of the request employed by the Losing Registrar must provide the Registered Name holder with clear instructions for approving or denying the request for authorization and a concise declaration describing the impact of the Registrant's decision(s) including the outcome if the Registrant doesn't respond.
a. This requirement is not intended to preclude the Losing Registrar from marketing to its existing customers through separate communications. This requirement is intended to ensure that the form of the request employed by the Losing Registrar is substantially administrative and informative in nature and clearly provided to the Registrant for the purpose of verifying the intent of the Registrant.
Suggested additional text:
Authentication communications with registrants regarding the transfer process should not include any information other than that contained in the standardized form.,
Authentication communications with registrants should be sent as soon as operationally possible but must be sent not later than 24 hours after receiving the transfer request.

Marilyn Cade remarked that "Authentication communications" were two confusing words and except for that accepted the additional text.

Recommendation 13:
Existing Recommendation:
In instances where the Losing Registrar does not feel that the Gaining Registrar has obtained the requisite authorizations described in these recommendations, the Losing Registrar may file a dispute as described in the Reference Implementation.
Additional text:
Either registrar should be able to file a dispute

The additional text was consistent with the task force recommendation

Recommendation 14:
Existing recommendation:

In the event of dispute(s) over payment, the Losing Registrar must not employ transfer processes as a mechanism to secure payment for services from a Registrant (the Losing Registrar has other mechanisms available to it to collect payment from the Registrant that are independent from the Transfer process.)
Additional text:
Except for non-payment for previous registration period if transfer is requested after the expiration date, or non-payment of the current registration period, if transfer is requested before the expiration date.

Marilyn Cade asked what the other mechanisms there were for collecting payment, to which Ross answered that there were many.

Recommendation 16:
Existing Recommendation:

The Administrative Contact and the Registrant, as outlined in the Losing Registrar's publicly accessible Whois service are the only parties that have the authority to approve or deny a transfer request to the Gaining Registrar. In all cases, the authority of the Registrant supercedes that of the Administrative Contact.
Suggested Replacement text:
The Administrative Contact and the Registrant, as outlined in the Losing Registrar's or Registry's (where available) publicly accessible WHOIS service are the only parties that have the authority to approve or deny a transfer request to the Gaining Registrar. In the event of a dispute, the authority of the Registrant in the authoritative WHOIS service supercedes that of the Administrative Contact.

Ross Rader explained that in the case of a dispute the registrant always has more authority.

Marilyn Cade remzrked that moving data back to the registry could involve system costs to the registrar. Concern was expressed that simplilization of the data could have the effect that there would be stronger controls as to how data can be used by registries. Users of WHOIS data would like to have portal access to searchability over multiple registrars' WHOIS. There is a resistance in the community to centralized data as a solution. Many think that it is easier to limit the use by putting contractual obligations on the registries. In addition, registry data can be governed by individual national laws.

Ross Rader suggested noting that the language in this recommendation should be consistent with the initial defined terms.

Recommendation 17:
Existing recommendation

The Gaining Registrar must use a Standardized Form of Authorization to seek the approval of the Registrant or Administrative Contact.
Suggested replacement text:
The Gaining or Losing Registrar must use a Standardized Form of Authorization to seek the approval of the Registrant or Administrative Contact. English is the mandatory default language for all registrar, registry and registrant transfer communications. Additionally, registrars may communicate with registrants in other languages provided that the principle of standardization this principle is satisfied.

It was noted that a registrant could receive a notice in two languages, but the standardized form is important.

Recommendation 20:
Existing recommendation:

Gaining Registrars must maintain copies of the Standardized Form of Authorization by the Registrant or Administrative Contact of Record as per the standard document retention policies of the contracts.
Suggested replacement text:
Registrars are responsible for keeping copies of documentation required for filing and supporting a dispute resolution process.

The Task Force decided that the suggested replacement text should be additional text to the recommendation.
Discussion followed on the length of time documents had to be kept.
In the second sentence, when a dispute can no loger be filed, there should be no obligation to keep the document unless local law so requires.

Ross Rader noted that either option is acceptable.

Recommendation 21:
Existing Recommendation:
Gaining Registrars must allow inspection by the Losing Registrar, and other relevant third parties such as ICANN, the Registry Operator or a third party Dispute Resolution Panel, of the evidence relied upon for the transfer during and after the applicable Inter-Registrar domain name transfer transaction(s).
Suggested Replacement text:
Gaining and losing registrars must allow inspection by the matching registrar, and other relevant third parties such as ICANN, the Registry Operator or a third party Dispute Resolution Panel, of the evidence relied upon for the transfer during and after the applicable Inter-Registrar domain name transfer transaction(s).

The "matching registrar" was clarified - previously everything was done by the gaining registrar, but in the replacement text it can be either the gaining or losing regsitrar.

Replacement text accepted


Recommendation 24:
Existing Recommendation:

A Losing Registrar may deny a transfer request only in the following instances;
a. Evidence of fraud
b. UDRP action
c. Court order
d. Reasonable dispute over the identity of the Registrant or Administrative Contact
e. No payment for previous registration period (including credit card charge-backs) if the domain name is past its expiration date or for previous or current registration periods if the domain name has not yet expired.
In all such cases, however, the domain name must be put into "Registrar Hold" status by the Losing Registrar prior to the denial of transfer.
f. Express written objection from the Registrant or Administrative contact. (e.g. - email, fax, paper document or other processes by which the Registrant has expressly and voluntarily objected through opt-in means)
Additional text:
- domain name is in lock status provided that the registrar provides a readily accessible and easy means for the registrant to remove the lock status.
- A domain name is in the first 60 days of an initial registration period
- A domain name is within 60 days (or a lessor period to be determined) of being transferred (apart from a transfer back to the original registrar)
There should be a finite list of allowable reasons for denying a transfer request with the understanding that procedures should be put into place to modify the list if registrars support any changes.
Upon denying a transfer request for any reason, registrars must provide the registrant and the other registrar the reason for denial.

Marilyn Cade remarked that there was a policy change being suggested that there had been no comment on.
It was agreed that the procedure must be authorized by the ICANN staff and it must be appropriately reffered to the Council.

Recommendation 27
Existing Recommendation:

That Registries implement a "Transfer Undo" command that will assist Registrants and Registrars in resetting a domain name back to its original state in the event that a transfer has occurred in contravention of the recommendations of this document.
Suggested Replacement text:
That Registries implement a "Transfer Undo" mechanism that will assist Registrants and Registrars in resetting a domain name back to its original state in the event that a transfer has occurred in contravention of the recommendations of this document.

Accept

The Task Force concluded:
1. Recommendation 9 should be discussed with the Task Force.
2. Table One should be modified to include the Task Forces review.
3. The Implementation report should be attached to the previous report.
4. Draft a recommendation for the GNSO Council to meet the agenda timeline for the February 20, GNSO Council teleconference.


The call ended at 21:20 CET, 3:20 PM EST




 


Information from:
GNSO Council