ICANN ICANN Email List Archives

[gnso-irtp-pdp-jun08]


<<< Chronological Index >>>    <<< Thread Index >>>

RE: [gnso-irtp-pdp-jun08] RE: Issue III

  • To: "James M. Bladel" <jbladel@xxxxxxxxxxx>, "Mike O'Connor" <mike@xxxxxxxxxx>
  • Subject: RE: [gnso-irtp-pdp-jun08] RE: Issue III
  • From: "Steele, Barbara" <BSteele@xxxxxxxxxxxx>
  • Date: Wed, 27 Aug 2008 18:34:49 -0400

All,
I agree with James that we do need to be very cautious about blurring the lines 
between policy development and product development.  I also agree that we 
should narrow the scope to exclude "registrant-initiated" transactions.  That 
is not to say that registrars would be limited in developing an offering that 
would be available to their registrants to manage their domains including the 
transfer of their portfolio from one registrar to another but that process 
should fall outside of the IRTP.  
 
I am hopeful that I can help to clarify how the bulk transfer process currently 
works.  When a registry executes a bulk transfer under the existing policy, the 
registries receive approval from ICANN to use the 'bulk transfer tool' to 
transfer all domains under the management of one ICANN accredited registrar to 
another designated ICANN accredited registrar.  When VeriSign receives these 
notices, we contact both the gaining registrar and the losing registrar to 
coordinate a time when we will be completing the transfer.  As discussed in our 
calls, a script is run that, in essence, only changes the registrar of record 
for the domain names - the expiration date is not changed nor is a registration 
fee assessed.  I have provided the language relating to ICANN approved 
transfers below for reference.  
 
B. ICANN-Approved Transfers

Transfer of the sponsorship of all the registrations sponsored by one Registrar 
as the result of (i) acquisition of that Registrar or its assets by another 
Registrar, or (ii) lack of accreditation of that Registrar or lack of its 
authorization with the Registry Operator, may be made according to the 
following procedure:

        (a) The gaining Registrar must be accredited by ICANN for the Registry 
TLD and must have in effect a Registry-Registrar Agreement with Registry 
Operator for the Registry TLD.

        (b) ICANN must certify in writing to Registry Operator that the 
transfer would promote the community interest, such as the interest in 
stability that may be threatened by the actual or imminent business failure of 
a Registrar.

Upon satisfaction of these two conditions, Registry Operator will make the 
necessary one-time changes in the Registry database for no charge, for 
transfers involving 50,000 name registrations or fewer. If the transfer 
involves registrations of more than 50,000 names, Registry Operator will charge 
the gaining Registrar a one-time flat fee of US$ 50,000.

I would anticipate that a similar process would be followed in a 'voluntary 
partial bulk transfer' request with the exception that the request would not be 
received from ICANN, but instead, from one of the registrars.  Therefore, the 
registries would receive the request to initiate a voluntary partial bulk 
transfer from a registrar and, provided all requirements are met, the registry 
would execute the command to move the designated domain names from the losing 
registrar to the gaining registrar (without further intervention by the 
registrars and without moving the expiration dates of the domain names forward 
or assessing the standard registration fee to the gaining registrar).  To the 
extent that the WG finds that it does make sense to include a provision to 
address 'voluntary partial bulk transfer' requests within the IRTP, the details 
surrounding the minimum requirements for submission of requests would need to 
be addressed.  Much work would need to be done by the WG to define the 
requirements, fee structure, etc.  In my opinion, the requirements should be 
limited to those relating to registry and registrar responsibilities.  How 
various registrars decide to develop products (and establish their fee 
structure that they would charge for the service to their registrants), as well 
as market the product to their registrants, should be left up to the individual 
registrars.  
 
In response, to James' comment:  "And, since some registries (Barbara can help 
here...?) offer a pro-rated monthly renewal rate, they could also develop a 
"synchronization service" to purchase monthly registrations until all domains 
reached a preferred renewal date.", I believe that he is actually thinking of 
the Sync command that is already available.  VeriSign does make this command 
available to all of the registrars affiliated with us but it is up to the 
registrar as to whether or not they make it available to registrants.  I would 
need to check to see if all registries offer this service and am happy to do 
this but I believe that this service falls outside of the scope of this working 
group.
 
I would recommend the following language for Issue III:
 
Issue III - Whether the policy should incorporate provisions for handling 
"voluntary partial bulk transfers" between registrars - that is, transfers 
involving a number of names but not the entire group of names [ REPLACE "held 
by" with "under the management of"] the losing registrar.

*       Should the policy incorporate provisions for handling "voluntary 
partial bulk transfers" between registrars? Please state the reasons and 
use-cases for your answer. 

*       Are you aware of any [DELETE "voluntary"] provisions to facilitate 
voluntary partial bulk transfers? If so, could you please provide further 
details on those provisions (apart from those already identified in the issues 
paper - NeuLevel (.biz), Nominet (.uk)). 

 
 
-------------------------------------------------------
Barbara Steele
Compliance Officer
VeriSign Information Services
bsteele@xxxxxxxxxxxx <blocked::mailto:bsteele@xxxxxxxxxxxx> 
Direct: 703.948.3343
Mobile: 703.622.1071
Fax:  703.421.4873
21345 Ridgetop Circle
Dulles, VA  20166


Notice to Recipient:  This e-mail contains confidential, proprietary and/or 
Registry Sensitive information intended solely for the recipient and, thus may 
not be retransmitted, reproduced or disclosed without the prior written consent 
of VeriSign Naming and Directory Services.  If you have received this e-mail 
message in error, please notify the sender immediately by telephone or reply 
e-mail and destroy the original message without making a copy.  Thank you.

 

________________________________

From: owner-gnso-irtp-pdp-jun08@xxxxxxxxx 
[mailto:owner-gnso-irtp-pdp-jun08@xxxxxxxxx] On Behalf Of James M. Bladel
Sent: Wednesday, August 27, 2008 11:50 AM
To: Mike O'Connor
Cc: Gnso-irtp-pdp-jun08@xxxxxxxxx
Subject: RE: [gnso-irtp-pdp-jun08] RE: Issue III


Mike and Group:

To my knowledge, there is nothing in the existing policy that would  _prevent_  
the registrant-initiated transfer you have described.  

For instance, a (hypothetical?) registrar (or non-registrar entity) could 
tailor a service program to act as an agent/proxy on your behalf, and handle 
all of the tedium associated with the "batch" transfer in your first paragraph. 
 And, since some registries (Barbara can help here...?) offer a pro-rated 
monthly renewal rate, they could also develop a "synchronization service" to 
purchase monthly registrations until all domains reached a preferred renewal 
date.

Aside from a few large, full-service shops, registrars come in all shapes and 
sizes and have targeted service offerings to a variety of market segments.  The 
existing environment encourages niche or boutique registrars to be innovative 
and develop new offerings, and I think the industry as a whole benefits from 
registrar diversity.  If there are no registrars that satisfactorily offer a 
desired service, then that should be thought of as an identified business 
opportunity, rather than a call for policy.

In my opinion, we need to be cautious about anything that might blur the 
boundaries between Policy development and Product development.  Ideas that are 
written into ICANN policy will become SOP for all registrars, regardless of 
scale, market, or business model considerations.  This will restrict the 
boundaries of innovation, and over time move towards a commoditized and 
homogeneous registrar environment.

J.





        -------- Original Message --------
        Subject: Re: [gnso-irtp-pdp-jun08] RE: Issue III
        From: "Mike O'Connor" <mike@xxxxxxxxxx>
        Date: Wed, August 27, 2008 10:16 am
        To: "Trachtenberg, Marc H." <MTrachtenberg@xxxxxxxxxxx>, "'Glen
        de Saint Géry'" <Glen@xxxxxxxxx>, 
        "Gnso-irtp-pdp-jun08@xxxxxxxxx" <Gnso-irtp-pdp-jun08@xxxxxxxxx>
        
        
        Yep, I agree. My position on transfers is that 
        I'd like a way for registrants to 
        consistently/securely move a group of names from 
        one registrar to another in a group, rather than 
        one at a time (which is an inconvenience that 
        losing registrars sometimes use as a barrier to 
        losing domains). Here are places where I see some wiggle room;
        
        - I agree that it's not fair that registrants get 
        to do this "for free" -- if there's a way to 
        impose a fair fee structure, I'd support it.
        
        - One of the problems that crops up for 
        registrants is that renewal dates are scattered 
        across the year -- it would be nifty if there was 
        some way to some kind of pro-rated refund of 
        registration-fees from the losing registrar. I 
        know, a logistical nightmare, but a fella can 
        dream. And maybe this could be implemented over 
        some period of time to limit impact on registrar operations.
        
        - A hybrid approach to this could be to provide a 
        mechanism whereby a registrant could "queue up" a 
        group of domains for an automated transfer at renewal time.
        
        - At any rate, it may be that I'm trying to 
        shoehorn too much into "partial bulk 
        transfers". Might it make sense to set up *two* 
        kinds of partial bulk transfers, one for 
        registrar-initiated ones and another for 
        registrant-initiated ones? That way we could 
        fashion the rules to match the circumstances better.
        
        mikey
        
        At 11:51 AM 8/26/2008, Trachtenberg, Marc H. wrote:
        >I think first we need to define "partial-bulk 
        >transfer." In other words, do we mean only 
        >registrar-initiated transfers? How many domain 
        >names are the minimum for a "partial-bulk 
        >transfer"? Are these transfers that are not treated as renewals?
        >
        >
        >Marc H. Trachtenberg
        >
        >Winston & Strawn LLP
        >35 West Wacker Drive
        >Chicago, IL 60601-9703
        >T: +1 (312) 558-7964
        >F: +1 (312) 558-5700
        >C: +1 (773) 677-3305
        >
        ><http://www.winston.com/index.cfm?contentID=24&itemID=15281>bio 
        >| 
        ><http://www.winston.com/sitefiles/wsvcard/15281.vcf>vcard 
        >| <mailto:MTrachtenberg@xxxxxxxxxxx 
<https://email.secureserver.net/pcompose.php#Compose> >email | www.winston.com
        >
        >
        >[]
        >
        >
        >
        >
        >
        >
        >
        >
        >----------
        >From: owner-gnso-irtp-pdp-jun08@xxxxxxxxx 
        >[mailto:owner-gnso-irtp-pdp-jun08@xxxxxxxxx 
<https://email.secureserver.net/pcompose.php#Compose> ] On Behalf Of Glen de 
Saint Géry
        >Sent: Tuesday, August 26, 2008 11:07 AM
        >To: Gnso-irtp-pdp-jun08@xxxxxxxxx
        >Subject: [gnso-irtp-pdp-jun08] Issue III
        >
        >
        >Since we are in an information gathering phase 
        >of our work, we should leave the use cases open 
        >for public comment. If we decide to recommend 
        >partial bulk transfers, we could do so without 
        >the restrictions imposed by the NueLevel 
        >Registry Service (...by means of a stock or asset 
        >purchase, merger or similar transaction...). This 
        >would permit registrars to make their own 
        >business decisions about whether to offer 
        >partial bulk transfers to their customers 
        >(registrants). However, voluntary bulk transfers 
        >may not be the answer for registrants because it 
        >requires the cooperation of the losing and 
        >gaining registrar and I do not anticipate that 
        >losing registrars will be easily motivated to 
        >participate. In the information gathering phase, 
        >can we open for discussion, partial bulk 
        >transfers that do not require losing registrar 
        >cooperation? This would be a great help for 
        >owners of domain portfolios (registrants) 
        >especially those who frequently acquire domains 
        >by purchasing portfolios or business acquisition.
        >
        >Completely separate from the bulk transfers 
        >issue, the collective primary purpose of all of 
        >the inter-registrar PDPs is to make registrar 
        >transfers easier and more dependable for 
        >registrants without sacrificing security. There 
        >are many complaints by registrants that some 
        >registrars make it tedious and difficult to 
        >transfer out. It may be outside the scope of 
        >this workgroup, but another work group (C) will 
        >soon deal with unlocking domains. This issue 
        >should be expanded to easily obtained 
        >authorization codes because unlocking domains 
        >and providing auth codes are two required tasks 
        >for inter-registrar transfers that losing 
        >registrars can use to make transfers extremely tedious.
        >
        >Best regards,
        >Michael Collins
        ><http://www.internetcommerce.org/>Internet Commerce Association
        >+1. 202 657 4570
        >
        >
        >No virus found in this incoming message.
        >Checked by AVG - http://www.avg.com
        >Version: 8.0.138 / Virus Database: 270.6.9/1635 
        >- Release Date: 8/26/2008 7:29 AM
        >The contents of this message may be privileged 
        >and confidential. Therefore, if this message has 
        >been received in error, please delete it without 
        >reading it. Your receipt of this message is not 
        >intended to waive any applicable privilege. 
        >Please do not disseminate this message without the permission of the 
author.
        
>******************************************************************************
        >Any tax advice contained in this email was not 
        >intended to be used, and cannot be used, by you 
        >(or any other taxpayer) to avoid penalties under 
        >the Internal Revenue Code of 1986, as amended.
        >
        
        
        



<<< Chronological Index >>>    <<< Thread Index >>>