<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: [gnso-irtp-pdp-jun08] RE: Issue III
- To: "IRTP-A " <Gnso-irtp-pdp-jun08@xxxxxxxxx>
- Subject: RE: [gnso-irtp-pdp-jun08] RE: Issue III
- From: "James M. Bladel" <jbladel@xxxxxxxxxxx>
- Date: Wed, 27 Aug 2008 17:05:19 -0700
<html><body><span style="color: rgb(0, 0, 0);"><font size="2"><span
style="font-family: verdana,geneva;"><span style="color: rgb(0, 0, 0);"><span
style="font-family: verdana,geneva;"><span style="color: rgb(0, 0, 0);"><span
style="font-family: verdana,geneva;">Mike:</span></span><br><br>I can see how
one might arrive at that conclusion, but remember that Go Daddy (and probably
others) are already offering effective bulk transfer services to their
customers now, under the existing IRTP. <br><br>This then becomes a
question of creating or modifying policy to compel all registrars to offer
identical services, regardless of the degree of fit with their individual
business models. I'll defer the registry portion of your question to
Barbara...<br></span></span><br>Thanks--<br><br>J.<br><br></span></font></span><br>
<blockquote webmail="1" style="border-left: 2px solid blue; margin-left: 8px;
padding-left: 8px;">
-------- Original Message --------<br>
Subject: RE: [gnso-irtp-pdp-jun08] RE: Issue III<br>
From: "Mike Rodenbaugh" <icann@xxxxxxxxxxxxxx><br>
Date: Wed, August 27, 2008 6:32 pm<br>
To: <Gnso-irtp-pdp-jun08@xxxxxxxxx><br>
<br>
<div><span class="046163023-27082008"><font color="#0000ff" face="Arial"
size="2">Seems like the Registry and Registrar reps in this WG would like to
make it easy for registrars to transfer bulk lists of names among themselves
for their convenience, but do not want to have to offer that same convenience
to registrants who wish to bulk transfer a list of names for their
convenience. Or am I missing something?</font></span></div> <div><span
class="046163023-27082008"><font color="#0000ff" face="Arial"
size="2"></font></span> </div> <div><span class="046163023-27082008"><font
color="#0000ff" face="Arial" size="2">Thanks,</font></span></div> <div><span
class="046163023-27082008"><font color="#0000ff" face="Arial"
size="2">Mike</font></span></div><br> <div class="OutlookMessageHeader"
dir="ltr" align="left" lang="en-us"> <hr tabindex="-1"> <font face="Tahoma"
size="2"><b>From:</b> owner-gnso-irtp-pdp-jun08@xxxxxxxxx [<a onclick="return
true;Popup.composeWindow('pcompose.php?sendto=owner-gnso-irtp-pdp-jun08%40icann.org');;
return false;" href="mailto:owner-gnso-irtp-pdp-jun08@xxxxxxxxx";
target="_blank">mailto:owner-gnso-irtp-pdp-jun08@xxxxxxxxx</a>] <b>On Behalf Of
</b>Steele, Barbara<br><b>Sent:</b> Wednesday, August 27, 2008 3:35
PM<br><b>To:</b> James M. Bladel; Mike O'Connor<br><b>Cc:</b>
Gnso-irtp-pdp-jun08@xxxxxxxxx<br><b>Subject:</b> RE: [gnso-irtp-pdp-jun08] RE:
Issue III<br></font><br></div> <div></div> <div dir="ltr" align="left"><span
class="499150019-27082008"><font color="#0000ff" face="Arial"
size="2">All,</font></span></div> <div dir="ltr" align="left"><span
class="499150019-27082008"><font color="#0000ff" face="Arial" size="2">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. </font></span></div> <div dir="ltr"
align="left"><span class="499150019-27082008"><font color="#0000ff"
face="Arial" size="2"></font></span> </div> <div dir="ltr"
align="left"><span class="499150019-27082008"><font color="#0000ff"
face="Arial" size="2">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. </font></span></div> <div dir="ltr" align="left"><span
class="499150019-27082008"><font color="#0000ff" face="Arial"
size="2"></font></span> </div> <div dir="ltr" align="left"><span
class="499150019-27082008"> <p style="font-size: medium;"><b>B. ICANN-Approved
Transfers</b></p> <div>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:</div> <blockquote> <div>(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.</div> <div>(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.</div></blockquote> <div>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.</div></span></div> <div><font color="#0000ff" face="Arial"
size="2"><span class="499150019-27082008">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. </span></font></div> <div><font color="#0000ff" face="Arial"
size="2"><span class="499150019-27082008"></span></font> </div> <div><font
color="#0000ff" face="Arial" size="2"><span class="499150019-27082008">In
response, to James' comment: <font color="#000000" size="3">"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<font
color="#0000ff" size="2">.", 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.</font></font></span></font></div> <div><font color="#0000ff"
face="Arial" size="2"><span
class="499150019-27082008"></span></font> </div> <div><font
color="#0000ff" face="Arial" size="2"><span class="499150019-27082008">I would
recommend the following language for Issue III:</span></font></div> <div><font
color="#0000ff" face="Arial" size="2"><span
class="499150019-27082008"></span></font> </div><span
class="499150019-27082008"> <div><font color="#0000ff"><font face="Arial"><font
size="2"><strong>Issue III Â Whether the policy should incorporate provisions
for handling Â<span class="499150019-27082008"><font
color="#ff0000">voluntary</font> </span>partial bulk transfers between
registrars  that is, transfers involving a number of names but not the entire
group of names <font color="#ff0000"><span class="499150019-27082008">[
REPLACE "</span>held<span class="499150019-27082008"> by</span><span
class="499150019-27082008">"</span> <span class="499150019-27082008">with
"under the management of"]</span></font> the losing
registrar</strong>.</font></font></font></div> <ul> <li><font color="#0000ff"
face="Arial" size="2">Should the policy incorporate provisions for handling
Â<span class="499150019-27082008"><font color="#ff0000">voluntary</font>
</span>partial bulk transfers between registrars? Please state the reasons
and use-cases for your answer. </font></li></ul> <ul> <li><font color="#0000ff"
face="Arial" size="2">Are you aware of any <span
class="499150019-27082008"><font color="#ff0000">[DELETE "voluntary"]</font>
</span>provisions to facilitate <span class="499150019-27082008"><font
color="#ff0000">voluntary</font> </span>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)).
</font></li></ul> <div><span class="499150019-27082008"><font color="#0000ff"
face="Arial" size="2"></font></span> </div></span> <div><font
color="#0000ff" face="Arial" size="2"><span
class="499150019-27082008"></span></font> </div> <div><font
color="#0000ff" face="Arial" size="2"><span
class="499150019-27082008"></span></font><font color="#0000ff" face="Arial"
size="2"><span class="499150019-27082008"></span></font><font color="#0000ff"
face="Arial" size="2"><span class="499150019-27082008"></span></font><span
class="008440619-12042007"><span style="font-size: 7.5pt; color: rgb(163, 0,
70); font-family:
Arial;">-------------------------------------------------------<br></span><strong><span
style="font-weight: bold; font-size: 10pt; color: rgb(163, 0, 70);
font-family: Arial;">Barbara Steele</span></strong><br><strong><span
style="font-size: 10pt; color: rgb(76, 76, 76); font-family: Arial;">Compliance
Officer</span></strong><br><span style="font-size: 10pt; color: rgb(76, 76,
76); font-family: Arial;">VeriSign Information Services</span><br><span
style="font-size: 7.5pt; color: rgb(76, 76, 76); font-family: Arial;"><a
href="blocked::mailto:bsteele@xxxxxxxxxxxx"; target="_blank"
title="mailto:bsteele@xxxxxxxxxxxx";>bsteele@xxxxxxxxxxxx</a></span><br><span
style="font-size: 7.5pt; color: rgb(76, 76, 76); font-family:
Arial;"><strong>Direct:</strong> 703.948.3343</span><br><span style="font-size:
7.5pt; color: rgb(76, 76, 76); font-family: Arial;"><strong>Mobile:</strong>
703.622.1071<br>Fax: 703.421.4873</span><br><span style="font-size:
7.5pt; color: rgb(172, 160, 149); font-family: Arial;">21345 Ridgetop
Circle<br>Dulles, VA 20166<br><br></span></span></div> <div align="left">
<div> <div dir="ltr" align="left"><font color="#800000"><font size="1"><font
face="Arial"><em><strong>Notice to Recipient: </strong><font
color="#000000">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. <strong>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.</strong> Thank you.</font></em></font></font></font></div> <div
dir="ltr" align="left"><br></div></div></div> <div> </div><br> <div
class="OutlookMessageHeader" dir="ltr" align="left" lang="en-us"> <hr
tabindex="-1"> <font face="Tahoma" size="2"><b>From:</b>
owner-gnso-irtp-pdp-jun08@xxxxxxxxx [<a onclick="return
true;Popup.composeWindow('pcompose.php?sendto=owner-gnso-irtp-pdp-jun08%40icann.org');;
return false;" href="mailto:owner-gnso-irtp-pdp-jun08@xxxxxxxxx";
target="_blank">mailto:owner-gnso-irtp-pdp-jun08@xxxxxxxxx</a>] <b>On Behalf Of
</b>James M. Bladel<br><b>Sent:</b> Wednesday, August 27, 2008 11:50
AM<br><b>To:</b> Mike O'Connor<br><b>Cc:</b>
Gnso-irtp-pdp-jun08@xxxxxxxxx<br><b>Subject:</b> RE: [gnso-irtp-pdp-jun08] RE:
Issue III<br></font><br></div> <div></div><font color="#000000"><font
size="2"><font style="font-family: verdana,geneva;" face="verdana,geneva">Mike
and Group:<br><br>To my knowledge, there is nothing in the existing policy that
would _prevent_ the registrant-initiated transfer you have
described. <br><br>For instance, a (hypothetical?) registrar (or
non-registrar entity) could tailor a service program</font></font></font> 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.<br><br><font
color="#000000"><font size="2"><font style="font-family: verdana,geneva;"
face="verdana,geneva">Aside from a few large, full-service shops,
r</font></font></font>egistrars 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.<br><font color="#000000"><font
size="2"><font style="font-family: verdana,geneva;"
face="verdana,geneva"><br>In my opinion, we need to be cautious about
</font></font></font><font color="#000000"><font size="2"><font
style="font-family: verdana,geneva;" face="verdana,geneva">anything that might
blur</font></font></font> 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.<br><br>J.<br><br><br><br> <blockquote style="border-left: 2px
solid blue; padding-left: 8px; margin-left: 8px;" webmail="1">-------- Original
Message --------<br>Subject: Re: [gnso-irtp-pdp-jun08] RE: Issue III<br>From:
"Mike O'Connor" <mike@xxxxxxxxxx><br>Date: Wed, August 27, 2008 10:16
am<br>To: "Trachtenberg, Marc H." <MTrachtenberg@xxxxxxxxxxx>,
"'Glen<br>de Saint GÃry'" <Glen@xxxxxxxxx>,
<br>"Gnso-irtp-pdp-jun08@xxxxxxxxx"
<Gnso-irtp-pdp-jun08@xxxxxxxxx><br><br><br>Yep, I agree. My position on
transfers is that <br>I'd like a way for registrants to
<br>consistently/securely move a group of names from <br>one registrar to
another in a group, rather than <br>one at a time (which is an inconvenience
that <br>losing registrars sometimes use as a barrier to <br>losing domains).
Here are places where I see some wiggle room;<br><br>- I agree that it's not
fair that registrants get <br>to do this "for free" -- if there's a way to
<br>impose a fair fee structure, I'd support it.<br><br>- One of the problems
that crops up for <br>registrants is that renewal dates are scattered
<br>across the year -- it would be nifty if there was <br>some way to some kind
of pro-rated refund of <br>registration-fees from the losing registrar. I
<br>know, a logistical nightmare, but a fella can <br>dream. And maybe this
could be implemented over <br>some period of time to limit impact on registrar
operations.<br><br>- A hybrid approach to this could be to provide a
<br>mechanism whereby a registrant could "queue up" a <br>group of domains for
an automated transfer at renewal time.<br><br>- At any rate, it may be that I'm
trying to <br>shoehorn too much into "partial bulk <br>transfers". Might it
make sense to set up *two* <br>kinds of partial bulk transfers, one for
<br>registrar-initiated ones and another for <br>registrant-initiated ones?
That way we could <br>fashion the rules to match the circumstances
better.<br><br>mikey<br><br>At 11:51 AM 8/26/2008, Trachtenberg, Marc H.
wrote:<br>>I think first we need to define "partial-bulk <br>>transfer."
In other words, do we mean only <br>>registrar-initiated transfers? How many
domain <br>>names are the minimum for a "partial-bulk <br>>transfer"? Are
these transfers that are not treated as renewals?<br>><br>><br>>Marc
H. Trachtenberg<br>><br>>Winston & Strawn LLP<br>>35 West Wacker
Drive<br>>Chicago, IL 60601-9703<br>>T: +1 (312) 558-7964<br>>F: +1
(312) 558-5700<br>>C: +1 (773) 677-3305<br>><br>><<a
href="http://www.winston.com/index.cfm?contentID=24&itemID=15281";
target="_blank"
mce_href="http://www.winston.com/index.cfm?contentID=24&itemID=15281";>http://www.winston.com/index.cfm?contentID=24&itemID=15281</a>>bio
<br>>| <br>><<a
href="http://www.winston.com/sitefiles/wsvcard/15281.vcf"; target="_blank"
mce_href="http://www.winston.com/sitefiles/wsvcard/15281.vcf";>http://www.winston.com/sitefiles/wsvcard/15281.vcf</a>>vcard
<br>>| <<a href="https://email.secureserver.net/pcompose.php#Compose";
target="_blank" _onclick="return
true;Popup.composeWindow('pcompose.php?sendto=MTrachtenberg%40winston.com');
return false;"
mce_href="https://email.secureserver.net/pcompose.php#Compose";>mailto:MTrachtenberg<b></b>@winston.com</a>>email
| <a href="http://www.winston.com"; target="_blank"
mce_href="http://www.winston.com";>www.winston.com</a><br>><br>><br>>[]<br>><br>><br>><br>><br>><br>><br>><br>><br>>----------<br>>From:
owner-gnso-irtp-pdp-jun08@xxxxxxxxx <br>>[<a
href="https://email.secureserver.net/pcompose.php#Compose"; target="_blank"
_onclick="return
true;Popup.composeWindow('pcompose.php?sendto=owner-gnso-irtp-pdp-jun08%40icann.org');
return false;"
mce_href="https://email.secureserver.net/pcompose.php#Compose";>mailto:owner-gnso-irtp-pdp-jun08<b></b>@icann.org</a>]
On Behalf Of Glen de Saint GÃry<br>>Sent: Tuesday, August 26, 2008 11:07
AM<br>>To: Gnso-irtp-pdp-jun08@xxxxxxxxx<br>>Subject:
[gnso-irtp-pdp-jun08] Issue III<br>><br>><br>>Since we are in an
information gathering phase <br>>of our work, we should leave the use cases
open <br>>for public comment. If we decide to recommend <br>>partial bulk
transfers, we could do so without <br>>the restrictions imposed by the
NueLevel <br>>Registry Service (Âby means of a stock or asset
<br>>purchase, merger or similar transactionÂ). This <br>>would permit
registrars to make their own <br>>business decisions about whether to offer
<br>>partial bulk transfers to their customers <br>>(registrants).
However, voluntary bulk transfers <br>>may not be the answer for registrants
because it <br>>requires the cooperation of the losing and <br>>gaining
registrar and I do not anticipate that <br>>losing registrars will be easily
motivated to <br>>participate. In the information gathering phase,
<br>>can we open for discussion, partial bulk <br>>transfers that do not
require losing registrar <br>>cooperation? This would be a great help for
<br>>owners of domain portfolios (registrants) <br>>especially those who
frequently acquire domains <br>>by purchasing portfolios or business
acquisition.<br>><br>>Completely separate from the bulk transfers
<br>>issue, the collective primary purpose of all of <br>>the
inter-registrar PDPs is to make registrar <br>>transfers easier and more
dependable for <br>>registrants without sacrificing security. There
<br>>are many complaints by registrants that some <br>>registrars make it
tedious and difficult to <br>>transfer out. It may be outside the scope of
<br>>this workgroup, but another work group (C) will <br>>soon deal with
unlocking domains. This issue <br>>should be expanded to easily obtained
<br>>authorization codes because unlocking domains <br>>and providing
auth codes are two required tasks <br>>for inter-registrar transfers that
losing <br>>registrars can use to make transfers extremely
tedious.<br>><br>>Best regards,<br>>Michael Collins<br>><<a
href="http://www.internetcommerce.org/"; target="_blank"
mce_href="http://www.internetcommerce.org/";>http://www.internetcommerce.org/</a>>Internet
Commerce Association<br>>+1. 202 657 4570<br>><br>><br>>No virus
found in this incoming message.<br>>Checked by AVG - <a
href="http://www.avg.com"; target="_blank"
mce_href="http://www.avg.com";>http://www.avg.com</a><br>>Version: 8.0.138 /
Virus Database: 270.6.9/1635 <br>>- Release Date: 8/26/2008 7:29
AM<br>>The contents of this message may be privileged <br>>and
confidential. Therefore, if this message has <br>>been received in error,
please delete it without <br>>reading it. Your receipt of this message is
not <br>>intended to waive any applicable privilege. <br>>Please do not
disseminate this message without the permission of the
author.<br>>******************************************************************************<br>>Any
tax advice contained in this email was not <br>>intended to be used, and
cannot be used, by you <br>>(or any other taxpayer) to avoid penalties under
<br>>the Internal Revenue Code of 1986, as
amended.<br>><br><br><br></blockquote>
</blockquote></body></html>
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|