ICANN/DNSO
|
http://www.dnso.org/dnso/mp3/20030122.GNSO-trf.mp3
ATTENDEES:
Registrar - Bruce Tonkin
Registrar - Nikolaj Nyholm
Registrar - Tim Ruiz
Registrar - Ross Rader
Registrar - Donna McGehee
Registrar- Elana Broitman
Registrar - Steve Miholovich
Registrar - Vincent Chavanis
Registry - Jeff Neuman
Registry - Chuck Gomes
Registry - Andrew Sullivan
Registry - Bruce Beckwith
Transfer Task Force User Rep - Grant Forsyth
TransferTask Force User - David Safran
http://www.dnso.org/dnso/notes/20030122.Draft_Transfers_Imp_Report_v2.0.htm
Bruce Tonkin referred to the draft Transfers Implementation report and asked
people on the call for initial comments on the key issues which were being suggested
such as c change of existing wording.
Donna McGehee asked about recommendation16,
Only the Admin Contact or Registrant as listed in the losing registrar’s Whois
may authorize transfers. The Registrant’s authority overrules the Admin Contact
in case of a dispute.
In the case where there was no way to validate who the registrant is?
Bruce Tonkin explained his view, if the gaining registrar would primarily work
via using the admin contact in the WHOIS; some losing registrars list both the
admin and the registrant contact - this is part of the issue with different
WHOIS formats. Some EPP registries can can separately identify those two identities.
The legal license holder of the domain name takes precedence. If the gaining
registrar has approval from the admin contact or the registrant then the transfer
policy has been met. The gaining registrar may have approval from the admin
contact and when the losing registrar gets the transfer request they may have
details of the registrant who refused it and the losing registrar would not
know about it, the transfer would be denied under these circumstances. If there
is a dispute resolution process than the losing registrar would need to have
proof of the registrant to sign up.
Jeff Neuman referring to the same recommendation16, said that in RRP registries
there should be a statement:
Only the admin contact or registrar
as listed in
(1) the losing registrars WHOIS database in the case of RRP registries
(2) the registrants WHOIS database in the case of EPP registries.
Bruce Tonkin said this would be added.
Tim Ruiz expressed concern that in the RAA there was no requirement to update
the thick registry in seconds with contact details so there would be a time
lapse between the update and when it is displayed in the registry.
For timing, the registrars port 43 should be continued to be used, an the change
always starts with the registrar and not with the registry.
Bruce Tonkin noted that not all registrars update their own WHOIS faster than
the registry.
Asking Jeff Neuman in the .biz registry what is in the contract, he replied
the registry.
Discussion followed which resulted
that the wording of the recommendation should be modified to read:
Only the Admin Contact or Registrant as listed in the losing registrar’s
Whois or the registries WHOIS may authorize transfers. The Registrant’s
authority overrules the Admin Contact in case of a dispute.
Recommendation 27
Registries must 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.
Jeff Neuman commented that the "undo" command could be done in
other ways.
Bruce Tonkin agreed that it does not have to be a protocol and it would
impact on the wording of the recommendation.
The suggested change was to add mechanism instead of command.
Andrew Sullivan commented that the 60 day period was to guard against many
transfers taking place.
It was agreed that 60 days is not a technical or particular issue.
Bruce Tonkin mentioned that the 60 day time period was chosen to match
the block after a new or initial registration, rather than having a number of
different time periods.
Ross Rader said that it should depend on the retrieval process.
Nikolaj Nyholm commented that there should not be so many options open
which could lead to abuse of specifications.
Bruce Tonkin stated that there were two ways of implementing:
- At the registry level, which is how the initial registration is handled. The
registry blocks the transfer if done within 60 days
- It would not available to the registrar which is in recommendation 24, as
one of the reasons to deny the transfer
Bruce Tonkin summarized the concern expressed when a registrant is confused,
the transfer has been approved, the registrars have acted correctly and the
registrant has not understood and wants to turn it back. There should not be
a period of 60 days to wait before this can be done.
Transfers over multiple registrars would be covered in recommendation 27 that
addresses the issue when a mistake has been made with the approval of the registrant.
The mechanism should take into account that the registrant or admin contact
should be able to reverse the process.
Ross Rader maintained that it forces every transfer where an agreement
can not be reached with the other registrar, to a dispute resolution, or to
wait for the 60 day period.
Elana Broitman said that it was not likely that the registrars would
be worse off with a way to address the issue.
Bruce Tonkin, summarizing, said that the main issue lay in the fact that
the transfer mechanism needs to be discussed more fully. It could be something
that the registrant can do. It does not need to be after a dispute, the registrar
can provide enough paper work from the registrant to say that he wants it undone.
Bruce Tonkin suggested that the wording be changed, the issues mentioned
and the mechanism itself needs to take these issues into account.
Recommendation 9 in table 2:
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.
Jeff Neuman asked whether it meant that the losing registrar could independently
confirm a transfer where there is an auth info code or is it limited to com
and net space.
There is no difference in RRP registries, the registrar acts if it not a confirmation.
Bruce added that in the EPP protocol it is the same as after the transfer,
a losing registrar can approve or deny a transfer. The process is dealing with
how the file would be obtained and not the difference between an EPP and RRP
registry.
Deleting the word "solely" allows for more flexibility and allows
that the losing registrar could also independently verify the registrants intent.
Jeff Neuman said that he did not understand it that way from the wording.
Ross Rader mentioned that the wording implies a loss of predictability
from a registrant perspective, operating from a registrar perspective and even
from a legal and liability perspective. The modification goes further than intended.
Jeff Neuman suggested linking it a section that stipulates it must be
done in a certain time period.
Steve Miholovich mentioned concern with word "solely" and the
potential damage prior to the decision being reversed.
Elana Broitman commented on recommendation
11, paragraph 2:
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.
This sounded too much like limiting competition, and Elana went on to say that
the issue should rather be when and how the confirmation note is sent out.
Bruce Tonkin explained that
while smaller registrars needed more time, this was to obviate delays from bigger
registrars, but was willing to leave out the 24 hour text.
Jeff Neuman referred to the dispute process and asked whether this would
be the topic for another implementation committee.
Bruce Tonkin agreed that the standard form of authorization and dispute
resolution should be left for further work.
Steve Miholovich mentioned security and expressed concern that transfers
are still exposed to security.
Bruce Tonkin commented that EPP protocol gives security and is dealt
with in the use of auth info codes which would provide a solution.
Ross Rader commented on certain paragraphs being incorrectly paraphrased
and said that there was little to gain out of paraphrasing.
Remove the description in Table 1
In legend medium should be deleted and part of the legend itself.
Should concentrate on impact in this report.
Grant Forsyth mentioned concern in the process that the group is going
beyond implementation.
In recommendation 15 the comment is of concern because it is seen to have no
impact on implementation.
The task force took as guidance that the frustration lay in legitimate transfers
and not slamming.
Chuck Gomes disagreed and said that registrars and registries only have
to implement policy if there is some demonstrated consensus and that changes
to the registry and registrar agreements must be supported by both the registrars
and the registries.
It was agreed that there were different interpretations of "impact".
Bruce Tonkin said that there were very few changes, most was clarification
and depending on the wording, there can be an impact. Registrars and registries
have a greater understanding of the recommendations.
The involvement of transfer task force members has been very beneficial in explaining
the intent of the recommendations.
Bruce Tonkin noted that receiving comments within 24 hours would be most
helpful.
The next stage would be drafting the final report to be discussed at the
next teleconference.
Bruce Tonkin thanked all the
participants for their attendance and comments that had been sent to
the list.
Teleconference ended at 21:35 UTC, 8:35 Melbourne time
Next teleconference:
Wednesday 29 January 20:00 UTC, Thursday 30 January, 07:00 Melbourne time.
see: http://www.dnso.org/meetings.html
Dial in details will be sent individually
to all the members.
Information from: |
© GNSO Names Council |