ICANN/DNSO

GNSO Transfer Implementation Committee teleconference on 22 January 2003 - minutes


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