ICANN/DNSO
|
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 |