Tucows Impact Analysis

of

Policies and Processes for Gaining and Losing Registrars

Consensus Policy Recommendations

January 9, 2003

Prepared by:

Kim Lerch, Director of Customer Service

 

 

 

 

The following document reviews the twenty-nine consensus policy recommendations contained in the report “Policies and Processes for Gaining and Losing Registrars” which can be found at http://www.dnso.org/dnso/notes/20021212.NCTransferTF-gaining-and-losing-registrars.html

Summary

The impact to Tucows is minimal.  The required changes to comply with the recommendations are focused on formalizing the data presentation for the “Form of Authorization”.  Currently, the data required for the “Form of Authorization” is collected and stored, however, it has not been referenced or process as such.   Changes to accommodate this are minimal. 

Providing the “Form of Authorization” within 3 business days is not realistic when a request for FOAs for all domains transferred in the last year is received.  The participants in this process should expect timely response to FOA requests, however, this relies on all the participants requesting FOAs as necessary.  

To determine that the impact was minimal, each recommendation was reviewed based on the following criteria:

-          Tucows current system or manual implementation (if any) of the recommendation, and

-          required changes (if any) to Tucows current system or manual implementation and the associated costs to implement the recommendation

The remainder of this document details the analysis per recommendation and the impact per recommendation.

Analysis

1.       Registrants must be able to transfer their domain name registrations between Registrars provided that the Gaining Registrar's transfer process follows minimum standards and such transfer is not prohibited by ICANN or Registry policies.

Current Status:  Tucows deploys a “Gaining Registrar transfer process” which closely adheres to “Consensus Policy Recommendations Exhibit A – Reference Implementation”. 

 

As features of the reference implementation are explored in the following recommendations, the details of the Tucows process will be discussed in the appropriate recommendation section.

2.       Implementation of these conclusions and recommendations should, wherever possible, use existing protocols and standards.

Current Status:  Tucows currently deploys existing protocols and standards.  The required changes listed in the items below do not use non-existing protocols and standards. 

Required Changes:  none

Impact:   none

3.       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.

Current Status:  Tucows has provided the following contact information at http://www.internic.net/contact.html

TUCOWS.com, Inc.
96 Mowat Avenue
Toronto Ontario
M6K 3M1
Canada

(416) 535-0123

Contact: info@opensrs.org  (Ross Wm. Rader)

In addition, the email address: transfers@opensrs.org is used for email correspondence regarding active transfer requests with the registrant.  Inquiries on the status of a particular transfer maybe sent to this email address.

Required Changes:  none

Impact:   none

4.       Inter-Registrar domain name transfer processes must be clear and concise in order to avoid confusing Registrants or other stakeholders.

Current Status:  Tucows deploys a “Gaining Registrar transfer process” which closely adheres to “Consensus Policy Recommendations Exhibit A – Reference Implementation”.    If this is deemed clear and concise, than the Tucows process is also clear and concise.

 

Unfortunately, a secure transfer approach regardless of how well structured does confuse Registrants.  I cannot claim that we do not confuse Registrants, only that we have streamlined the process as greatly as possible without comprising the required security.

Required Changes:  none

Impact:   none

5.       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.

Current Status:  The registrant can currently request information regarding the Tucows transfer to and transfer away processes, and this information will be provided.   However, this information is not proactively provided.

Required Changes:  Tucows has many web-sites specifically dedicated to Registrants.  Documentation regarding Tucows transfer to and transfer away processes should be added to these sites.    

Impact:   low

6.       In EPP-based gTLD Registries, Registrars must provide the Registrant with the Registrant’s unique “AuthInfo Code” within a reasonable period of time of the Registrant’s initial request. The Task Force observes support that this reasonable time period is 72 hours or a similarly limited period of time.

Current Status:  A registrant can obtain their EPP “AuthInfo Code” at any time by accessing http://manage.opensrs.org with the appropriate domain name, username and password.  The registrant (or the admin contact) supplies the username and password when the domain is initially ordered.

If the registrant (or admin contact) does not remember the username/password information, they may request this information be emailed to registrant (or admin contact) email address.    

The Tucows OpenSRS system allows Tucows staff and resellers to send the required data to the registrant (or admin contact) without viewing the secure username/password.

Tucows requires that its resellers are responsive to their customers and respond to valid customer requests within 1 business week.

Required Changes: none

Impact: none

7.       In EPP-based gTLD Registries, Registrars may not employ any mechanism for a Registrant to obtain its AuthInfo Code that is more restrictive than what they require from a Registrant to change any aspect of its contact or nameserver information.

Current Status:  Tucows most restrictive change mechanism occurs when the registrant (and admin contact) email address is no longer functioning and must be changed.  When this occurs, Tucows requires that the registrant (or admin contact) provide detailed information about the individual or organization in written format prior to implementing the change.

As access to the EPP “AuthInfo Code” is only dependant on a valid registrant (or admin contact) email address, the EPP “AuthInfo Code” access mechanism is not more restrictive than other changes to the contact or nameserver information.

Required Changes: none

Impact: none

8.       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.

Current Status:  When Tucows receives a transfer to request via our order processing system:

-          The Tucows system automatically obtains a copy of the domain whois

-          If the whois does not contain a valid email address for the admin contact, the order is flagged for manual intervention.  If a staff member of the “Tucows Transfer team” can obtain the correct email address for the admin contact by performing additional whois inquiries, the valid whois information will be stored and the transfer order processing will continue.  Otherwise, the transfer request will be aborted.

-          If the whois does contain a valid email address for the admin contact, the Tucows system will:

o        send an email to the admin contact containing:

§         instructions to go to a security web site to confirm or deny the transfer (“transfer web site”)

§         a unique login/password combination for logging into the “transfer web site”

o        store the:

§         admin email address, and

§         timestamp when the email was sent

-          If the admin contact:

o        does not go to the web site within 7 days, the Tucows system will abort the transfer request

o        goes to the web site and denies the transfer,  the Tucows system will:

§         store the:

·         IP address used to access the web site

·         Phone number supplied by the admin contact

·         Timestamp when the denial occurred

§         abort the transfer request

o        goes to the web site and approves the transfer, the Tucows system will:

§         store the:

·         IP address used to access the web site

·         Phone number supplied by the admin contact

·         Timestamp when the denial occurred

§         proceed in the transfer request

Required Changes: The “transfer web site” presented to the admin contact does not reference the “Form of Authorization”.  Although all the information required for the Form of Authorization is collected, this information is not provided or displayed to admin contact as a “receipt”.  Minor changes to the “transfer web site” can be implemented so that the registrant is validating the “Standardized Form of Authorization”.

Impact:  low

9.       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.

See recommendation #8.

10.    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.

Current Status:  When Tucows receives a transfer away from the registry:

-          The Tucows system:

o         sends an email to the admin contact containing:

§         instructions to go to a security web site to confirm or deny the transfer (“transfer away web site”)

§         a unique login/password combination for logging into the “transfer away web site”

o        stores the:

§         admin email address, and

§         timestamp when the email was sent.

-          If the admin contact:

o        goes to the web site and denies the transfer,  the Tucows system will:

§         store the:

·         IP address used to access the web site

·         Phone number supplied by the admin contact

·         Timestamp when the denial occurred

§         files a n’ack with the registry

o        goes to the web site and approves the transfer, the Tucows system will:

§         store the:

·         IP address used to access the web site

·         Phone number supplied by the admin contact

·         Timestamp when the denial occurred

§         allow the transfer to proceed

o        does not go to the web site within 5 days, the Tucows system will allow the transfer to proceed

Required Changes:  none

Impact:  none

11.    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.

Current Status:  See recommendation #10.

Required Changes: The “transfer away web site” presented to the admin contact does not reference the “Form of Authorization”.  Although all the information required for the Form of Authorization is collected, this information is not provided or displayed to admin contact as a “receipt”.  Minor changes to the “transfer away web site” can be implemented so that the registrant is validating the “Standardized Form of Authorization”.

 

Impact:  low

12.    The presumption in all cases will be that the Gaining Registrar has received and authenticated the requisite request from the Registrant or Administrative Contact.

See recommendation #8.

13.    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.

Current Status:  Tucows currently contacts the registry regarding transfer disputes.

Required Changes: none

Impact: none

14.    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.)

Current Status: Tucows uses “registrant hold” for securing payment.  This does not affect the transfer process.

Required Changes: none

Impact: none

15.    In EPP-based TLDs, a Losing Registrar must not refuse to release an “AuthInfo Codes” to the Registrant solely because there a dispute between a Registrant and the Registrar over payment.

Current Status:  Tucows does not refuse to release an “AuthInfo Codes” to a registrant solely because there is a dispute over payment.

Required Changes: none

Impact: none

16.    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.

Current Status: Tucows emails the admin contact regarding the transfer.  However, if the registrant contacts Tucows to indicate that the administrative contact is not acting as per their wishes, and provides appropriate identity information (photo id, articles of incorporation etc.), Tucows will stop or reverse the transfer.

Required Changes: none

Impact: none

17.     The Gaining Registrar must use a Standardized Form of Authorization to seek the approval of the Registrant or Administrative Contact.

See recommendation #8.

18.    ICANN should support the development of this Standardized Form of Authorization through staff consultation with impacted stakeholders with guidance as to intent and scope from this Task Force. This form must be useable in both physical and online automated systems (web, email).

N/A – ICANN directive.

19.    In the event that the Gaining Registrar must rely on a physical process to obtain this authorization, a paper copy of the Standardized Form of Authorization will suffice insofar as it has been signed by the Registrant or Administrative Contact and is accompanied by a physical copy of the Losing Registrar’s Whois output for the domain name in question.

a.       If the gaining Registrar relies on a physical authorization process, they assume the burden of obtaining Reliable Evidence of Identity of the Registrant or Administrative Contact and that the entity making the request is indeed authorized to do so.

b.       The Task Force notes support for the concept that recommended forms of identity that constitute Reliable Evidence of Authority include:

§         Notarized statement

§         Valid Drivers license

§         Passport

§         Article of Incorporation

§         Military ID

§         State/Government issued ID

§         Birth Certificate

c.        The Task Force notes support for the concept that in the event of an electronic authorization process, recommended forms of identity would include;

§         electronic signature in conformance with national legislation, for instance, the United States e-Sign Act

§         Email address matching Registrant or Administrative Contact email address found in authoritative Whois database.

Current Status:  Tucows deploys an electronic authorization process using email address matching with the Administrative Contact email address found in the authoritative Whois Database.

Required Changes: none

Impact: none

20.    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.

Current Status: Tucows electronically stores for each transfer and the required retention period:

§         timestamp of transfer request

§         admin email address

§         timestamp when confirmation email was sent to the admin contact

§         IP address used to access the “transfer web site”

§         phone number supplied by the admin contact

§         timestamp when the admin contact approved or rejected the transfer

Required Changes:  This stored data can be used to produce the “Form of Authorization”.

Impact: low

21.    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).

Current Status:  Tucows does provide to the Losing Registrar, and other relevant third parties such as ICANN, the Registry Operator or a third party Dispute Resolution Panel, the evidence relied upon for the transfer during and after the applicable Inter-Registrar domain name transfer transaction(s).

Required Changes: none

Impact: none

22.    Copies of the Reliable Evidence of Identity must be kept with the Standardized Form of Authorization. The Gaining Registrar must retain, and produce pursuant to a request by a Losing Registrar, a written or electronic copy of the Standardized Form of Authorization. The Losing Registrar retains the right to inspect this documentation at all times consistent with existing document retention requirements.

Current Status: Tucows electronically stores for each transfer and the required retention period:

§         timestamp of transfer request

§         admin email address

§         timestamp when confirmation email was sent to the admin contact

§         IP address used to access the “transfer web site”

§         phone number supplied by the admin contact

§         timestamp when the admin contact approved or rejected the transfer

(See recommendation #21 re “The Losing Registrar retains the right to inspect this documentation at all times consistent with existing document retention requirements”.)

Required Changes: none

Impact: none

23.    In instances where the Losing Registrar has requested copies of the Standardized Form of Authorization, the Gaining Registrar must fulfill the Losing Registrar’s request (including providing the attendant supporting documentation) within a reasonable period of time from the receipt of the request. The Task Force recommends (3) business days. Failure to provide this documentation within the time period specified is grounds for reversal by the Registry Operator or Dispute Resolution Panel in the event that a transfer complaint is filed in accordance with the recommendations of this report.

Current Status: Tucows currently does provide the evidence relied upon for the transfer during and after the applicable Inter-Registrar domain name transfer transaction(s). 

The 3 business day requirement must be related to “a number of requests”.  If a registrar receives a request for all domain transfers for the last year, obviously this request will not be completed within 3 business days.

Required Changes: none

Impact: undefined, the 3 day response time recommendation is dependant on the volume of requests.  The volume of requests cannot be anticipated at this time.

24.    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)

Current Status: Tucows denies a transfer when there is:

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.

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)

The Registry will not transfer the domain when it has been placed on registrar lock.   Tucows provides the registrant with amble opportunity to unlock the domain, and will not placed the domain on “registrar lock” after a transfer away request has been received (however, the registrant may do so).

Required Changes: none

Impact: none

25.    Instances when the Losing Registrar may not deny a transfer include, but are not limited to;

a.       Nonpayment for a pending or future registration period

b.       No response from the Registrant or Administrative contact unless the Losing Registrar shows evidence of express written objection from the Registrant or Administrative Contact. (egg – email, fax, paper document or other processes by which the Registrant has expressly and voluntarily objected through opt-in means)

c.        Domain name in Registrar Lock Status unless the Registrant is provided with the reasonable opportunity and ability to unlock the domain name prior to the Transfer Request.

d.       Domain name registration period time constraints other than during the first 60 days of initial registration.

e.       General payment defaults between Registrar and business partners / affiliates in cases where the Registrant for the domain in question has paid for the registration.

Current Status: Tucows does not denies a transfer when there is:

a.       Nonpayment for a pending or future registration period

b.       No response from the Registrant or Administrative contact unless the Losing Registrar shows evidence of express written objection from the Registrant or Administrative Contact. (eg – email, fax, paper document or other processes by which the Registrant has expressly and voluntarily objected through opt-in means)

c.       Domain name registration period time constraints other than during the first 60 days of initial registration.

d.       General payment defaults between Registrar and business partners / affiliates in cases where the Registrant for the domain in question has paid for the registration.

Tucows will not place a domain on registrar hold after a transfer away request has been made.  The registrant can however place the domain on registrar hold at any time.

Required Changes:  none

Impact: none

26.    That Registrars have access to a suitable process(es) by which they can dispute any specific transfers that they might object to after the fact (i.e. – a dispute resolution processes as outlined in the Reference Implementation described elsewhere in this report). And that such processes specifically include provisions that fulfill the following requirements;

a.       Resolution of the disputes should be administered by a third party or the pertinent Registry operator or both.

b.       That the processes be limited in scope to issues arising out of inter-Registrar domain name transfers

c.        That the processes be solely initiated by a Registrar.

d.       That appeal of rulings is allowed, but is limited in number.

e.       That the policy include specific obligations for all parties to the dispute to provide documentation to the dispute resolution provider

f.         That the Registrar filing a dispute pay the cost of filing the dispute, that the party that “loses” the dispute pay the cost of administering the dispute resolution and reimburse the filing Registrar for the filing fees if applicable.

g.       That the third party dispute resolution service or Registry be able to direct the appropriate Registry or Registrar to return a domain name to whatever state the dispute resolution provider deems appropriate based on the facts presented during the proceeding.

Current Status: Tucows does not have access to such a process, but see great benefits to this process.

Required Changes:  none

Impact: none

27.    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.

Current Status:  As a “transfer undo” command does not currently exist, resetting a domain name back to its original state is a laborious manual process.

Required Changes:  Tucows would have to develop an interface to allow Tucows staff to invoke the “transfer undo” command as required.  However, the cost of this initial development would be offset by the long-term reduction in manual intervention.

Impact:  low

 

 

 

 

 

28.    That the implementation and execution of these recommendations be monitored by the DNSO. Specifically that;

a.       ICANN Staff analyse and report to the Names Council at three, six and twelve month intervals after implementation with the goal of determining;

                                                         i.            How effectively and to what extent the policies have been implemented and adopted by Registrars, Registries and Registrants,

                                                        ii.            Whether or not modifications to these policies should be considered by the DNSO as a result of the experiences gained during the implementation and monitoring stages,

                                                      iii.            The effectiveness of the dispute resolution processes and a summary of the filings that have been resolved through the process.

b.       Pursuant to which, the Names Council may instruct the staff to;

                                                         i.            Continue bi-annual reviews in a manner consistent with the aforementioned requirements, or;

                                                        ii.            Report again to the Names Council in an additional twelve month time frame.

c.        The purpose of these monitoring and reporting requirements are to allow the Names Council to determine when, if ever, these recommendations and any ensuing policy require additional clarification or attention based on the results of the reports prepared by ICANN Staff.

N/A – ICANN directive.

29.   Guidance. The Task Force has completed three supplementary documents (“Exhibit A, Reference Implementation”, “Exhibit B, Proposed Dispute Resolution Model” and “Exhibit C, Standardized Definitions”) in support of these recommendations. These exhibits are submitted as guidance to those that will be required to craft and/or implement the policies adopted as a result of these recommendations.

The 3 documents have been reviewed in conjunction with the preceding recommendations.