<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: [gnso-irtp-pdp-jun08] RE: Issue III
- To: "Mike O'Connor" <mike@xxxxxxxxxx>
- Subject: RE: [gnso-irtp-pdp-jun08] RE: Issue III
- From: "James M. Bladel" <jbladel@xxxxxxxxxxx>
- Date: Wed, 27 Aug 2008 08:50:10 -0700
<html><body><font style="" 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
style="" 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 style=""
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 style="" 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 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 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 onclick="return
true;Popup.composeWindow('pcompose.php?sendto=MTrachtenberg%40winston.com');
return false;" href="https://email.secureserver.net/pcompose.php#Compose";
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 onclick="return
true;Popup.composeWindow('pcompose.php?sendto=owner-gnso-irtp-pdp-jun08%40icann.org');
return false;" href="https://email.secureserver.net/pcompose.php#Compose";
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></body></html>
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|