[gnso-irtp-b-jun09] RE: Recommendation #9 - Requiring a positive confirmation of the transfer by the losing registrar

["Sedo :: Simonetta Batteiger" <simonetta@xxxxxxxx>]

I disagree with the automatic denial of the transfer in case the registrant 
does not positively confirm with the losing registrar within 5 days of the 
transfer request.

A registrant should receive two emails in case of a transfer (one from the 
gaining and one from the losing registrar). Based on the current wording of the 
standard FOA language a registrant must think they're "done" with the 
confirmation when they've responded to the email from the gaining registrar. 
The wording of that email clearly states you need to take action confirming the 
transfer. The wording of the FOA template the losing registrar is required to 
send states:

 "If you want to proceed with this transfer, you do not need to respond to this 
message."

So if we wanted to change the process, we'd have to touch the losing and 
gaining registrar's standard FOA wording as well. I think that's unnecessary 
because the main benefit of the losing registrar's confirmation requirement 
would be to make sure the registrant truly wants the registrar change. If they 
don't want the change the most important thing for them to know is how to get 
in touch with their current registrar, which will be achieved by providing that 
information in the FOA email sent by the losing registrar.

So I do support the requirement for the losing registrar to inform the 
registrant about the transfer request they received and give clear instructions 
on how to get in touch if they did not authorize the transfer.

Taking a look at the FOA templates here http://icann.org/en/transfers/ I 
thought of something else:

Currently the FOA for the losing registrar can be sent to the registrant email 
OR the AdminC email.
How about requiring the losing registrar to send their FOA to the registrant OR 
to better to both the registrant AND the Admin C email?


Finally I had a thought about an issue with FOA wording that also touches on 
recommendation # 4:
The language of the current FOA standard text (for both the losing as well as 
the gaining registrar) is something that should be included as an issue for all 
transfers with ownership change.
The current FOA wording makes little sense in case of transfers with ownership 
change and should be updated.
A place to look for some best practices could be the ccTLDs that have rules 
around the ACK calls for domain trades that differ from the ones for a simple 
transfer without ownership change. This may be something to adopt with the 
gTLDs as well. Some thought should also be given to the timing of the losing 
registrant's confirmation.

From: owner-gnso-irtp-b-jun09@xxxxxxxxx 
[mailto:owner-gnso-irtp-b-jun09@xxxxxxxxx] On Behalf Of Marika Konings
Sent: Wednesday, January 26, 2011 3:02 PM
To: Gnso-irtp-b-jun09@xxxxxxxxx
Subject: [gnso-irtp-b-jun09] Recommendation #9 - Requiring a positive 
confirmation of the transfer by the losing registrar

Recommendation #9 (NEW): The WG proposes to modify section 3 of the IRTP to 
require that the Registrar of Record/Losing Registrar be required to confirm 
the transfer out with the Registered Name Holder/Registrant. The Registrar of 
Record has access to the contact information for the Registrant and could 
modify their systems to automatically send out the Standardized Form for Losing 
Registrars ("Confirmation FOA") to the Registrant. Failure by the Registrant to 
respond within the 5 day pendingTransfer grace period would result in the 
transfer request being automatically denied or Nacked. At the time that the 
transfer is requested via the Gaining Registrar, the Transfer Contact that 
requested the transfer would be informed that positive confirmation by the 
Registrant is required to complete the transfer and that the Registrant will be 
receiving the Confirmation FOA from the Registrar of Record.

Comments to date:

 *   One of the reasons why the IRTP was developed in the first place was that 
pre-IRTP, transfers had to be confirmed by the losing registrar which resulted 
in many transfers being denied because emails were not received, never sent or 
additional layers of confirmation added. As a result, it was agreed in the IRTP 
that the gaining registrar must confirm the transfer and the losing registrar 
may confirm the transfer. Here you can find one of the position papers 
explaining the problem with the original approach (requiring approval from the 
registrant by the losing registrar): 
www.dnso.org/clubpublic/registrars/Arc01/pdf00003.pdf.
 *   An alternative approach might be to indeed require that the losing 
registrar informs / notifies the registrant of the transfer that has been 
requested, but not to allow no response from the registrant as a reason to deny 
the transfer. In this way, it could still reduce potential conflicts between 
admin contact and registrant and reduce the need to undo transfers as any 
potential conflict would hopefully become apparent at this stage, before the 
transfer is completed.
 *   If the transfer contact is informed at the time that they submit their 
transfer request that the losing registrar will be confirming the transfer with 
the registrant within X period of time, if the losing registrar fails to send 
out the standardized confirmation FOA, they can file a complaint with ICANN.  
If ICANN receives numerous complaints regarding a specific registrar, it will 
be very clear that the registrar is not in compliance with the IRTP and the 
registrar should be given an appropriate amount of time to cure the issue.
 *   We are operating in a very different time from when the original Policy on 
the Transfer of Sponsorship of Registrations Between Registrars was done and 
even when the current IRTP was adopted and it may make sense to require a 
positive confirmation from the losing registrar. The policy is very specific in 
the reasons why a registrar may deny a transfer and, as mentioned above, it 
will be very apparent if a registrar is not complying.
Please share your comments, suggestions and/or proposed edits with the mailing 
list.

Marika