<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: [transfers-wg] Transfers WG Agenda
- To: ross@xxxxxxxxxx
- Subject: RE: [transfers-wg] Transfers WG Agenda
- From: Tim Ruiz <tim@xxxxxxxxxxx>
- Date: Fri, 19 Aug 2005 06:13:00 -0700
<div>Ross,</div>
<div> </div>
<div>Sorry I could not make the call. In the future, more notice would be
appreciated. I would like to add two issues, related to a couple you
and Marcus have already raised.</div>
<div> </div>
<div>1. Transfers immediately following a Registrant transfer (change of
ownership or license) should not be allowed, or at least, the registrar
of record should have the option of not allowing it for some period of
time, 30-60 days perhaps. This was an explicit requirement in the old
transfer policy, not sure why it was removed.</div>
<div> </div>
<div>2. Since the Registrant trumps the Admin contact there should be some
way of automating approval from the Registrant. Currently, there is
often no Registrant email address available since it is not required to
be in the public Whois. However, I am sure most, if not all, registrars
collect that. If that could be available to registrars only when trying
to facilitate a transfer we could eliminate many conflicts later when
the Registrant claims they did not approve the transfer. Some
registrars have gone to completely paper transfer processes as a result
of this issue, and all that does is slow down and complicate the
transfer process for registrants.</div>
<div> </div>
<div>Tim<BR><BR></div>
<BLOCKQUOTE style="PADDING-LEFT: 8px; MARGIN-LEFT: 8px; BORDER-LEFT:
blue 2px solid"><BR>-------- Original Message --------<BR>Subject: Re:
[transfers-wg] Transfers WG Agenda<BR>From: Ross Rader
<ross@xxxxxxxxxx><BR>Date: Thu, August 18, 2005 3:34 pm<BR>To:
Marcus Faure <faure@xxxxxxxxxxxxxxxxxxxxxxxx><BR>Cc:
transfers-wg@xxxxxxxxxxxxxx, Bhavin
Turakhia<BR><bhavin.t@xxxxxxxxxxx>, Bruce Tonkin
<Bruce.Tonkin@xxxxxxxxxxxxxxxxxx><BR><BR>-----BEGIN PGP SIGNED
MESSAGE-----<BR>Hash: SHA1<BR><BR>These are great Marcus. I'm adding a
few based on Tucows experiences...<BR><BR>1. Additional registrar
imposed restrictions. It seems that a number of<BR>registrars are
imposing additional constraints on transfers (i.e. no<BR>transfer for
60 days after contact data changes). While the policy seems<BR>to be
rather clear on this point, enforcement/compliance seems to be
an<BR>issue.<BR><BR>2. Showing identity of reseller in FOA. As a
wholesaler, we're probably<BR>more effected by this than most, but we
are seeing a moderately high<BR>level of confusion from end-users
because their reseller isn't<BR>identified in the FOA. It would be
useful to discuss adding the option<BR>to identify the reseller in
addition to requiring the inclusion of the<BR>registrar's
identity.<BR><BR>3. Repatriation of inappropriately transferred names
is difficult and<BR>processes are still unclear. This is mostly evident
in incidences where<BR>a registrant has objected to a transfer, despite
the approval of the<BR>admin contact. The transfer policy is quite
clear that the registrant<BR>"trumps" the admin contact, but is not
clear how these types of veto<BR>situations should be handled. The
result is an inconsistent application<BR>of the policy and increased
risk of domain theft.<BR><BR>4. TDRP enforcement seems inconsistent and
does not rely on past<BR>precedent as intended. Situations with similar
fact patterns are being<BR>decided differently by the same dispute
provider leading to a distinct<BR>lack of clarity and reliability of
the proceedings. This is primarily<BR>observed at the registry
level.<BR><BR><BR>On 18/08/2005 9:45 AM Marcus Faure noted
that;<BR>> Hi all,<BR>> <BR>> I would like to add issues that
I feel should be addressed<BR>> <BR>> <BR>> 1. Definition of
the term 'transfer'<BR>> <BR>> The policy states that domains may
not be transferred 60 days after a<BR>> transfer took place. Some
registrars claim that an 'internal' transfer<BR>> also falls into
this category, e.g. the domain moved from one reseller to<BR>>
another without registry involvement.<BR>> I do not think that this
qualifies as a transfer. Additionally it is<BR>> impossible to
control, so a registrar might abuse this.<BR>> <BR>> <BR>> 2.
Transfers in autorenew grace period<BR>> <BR>> It has become a
common business practice to use the autorenew grace period<BR>> for
domain monetization programs. Usually the domain is taken offline
for<BR>> a few days on the day of expiration to give the registrant
time to react.<BR>> If the registrant does not react, the registrar
changes the ownership data<BR>> to show the registrar as the new
owner and puts some sponsored pages on<BR>> the domain. This
effectively circumvents the transfer policy requirement<BR>> to
allow transfer in autorenew grace period.<BR>> While there are a
number of arguments pro and contra this behaviour, it is<BR>>
certainly not in line with the intention of the transfer policy. We
should<BR>> ask ourselves if the transfer policy has to be
adopted.<BR>> Add grace period abuse is a related subject, but that
is probably OT.<BR>> <BR>> <BR>> 3. Definition of a FOA
subject line<BR>> <BR>> While the FOA body is well-defined, the
subject line is not. I think it<BR>> will be easier for all
participants if the FOA would have a standardized<BR>> subject
line.<BR>> <BR>> <BR>> 4. Implementation of IANA ids for
transfers<BR>> <BR>> It would be an improvement for everyone to
get rid of the proprietary<BR>> registrar ids that differ from
registry to registry. CORE proposes that<BR>> registries shall
implement IANA ids in transfers instead. This has already<BR>> been
circulated on the RC mailing list and was endorsed by a number
of<BR>> people, but got lost somehow in the .net phase.<BR>>
<BR>> <BR>> 5. ICANN death penalty<BR>> <BR>> Not sure if
this is OT, but I would like to see more possibilities for<BR>>
ICANN to enforce its policies. Currently the threat to cancel
the<BR>> accreditation is ICANN's only possibility to do so. There
should be more<BR>> ways for ICANN. A number of proposals have been
circulated on the RC list.<BR>> <BR>> <BR>> 6. Default lock
mechanism<BR>> <BR>> OK, I know that (big) registrars are happy
with a default domain-lock,<BR>> but I still think that this is not
in line with transfer policy and that<BR>> there is no need for a
lock when you have an authinfo. Hence this should<BR>> be on the
list of topics to address.<BR>> <BR>> <BR>> Yours,<BR>>
Marcus<BR>> <BR>> <BR>> <BR>> On Wed, 17 Aug 2005, Ross
Rader wrote:<BR>> <BR>> <BR>> All -<BR>> <BR>> The first
Transfers working group meeting will be held on Thursday, 18<BR>>
August 2005 at 21:00 UTC (14:00 Los Angeles, 17:00 EST, 23:00 CET,
7:00<BR>> am Friday Melbourne, 9:00am Friday Auckland)<BR>>
<BR>> I apologize for the uncomfortable call time that we've
arranged. There<BR>> was a conflict with the GNSO Council call
earlier today and it was<BR>> important that we moved the ball
forward after so much delay. The next<BR>> call will be scheduled at
a much more reasonable time and much of our<BR>> next work will be
conducted on the mailing list. Hopefully this doesn't<BR>>
inconvenience too many of you.<BR>> <BR>> Call-in details have
already been circulated. Please let me know if you<BR>> did not
receive the phone number and access code.<BR>> <BR>> If there are
other members of your respective constituencies that would<BR>> like
to participate, please let me know.<BR>> <BR>> Call
Agenda:<BR>> <BR>> 1. Review WG Scope and Deliverables.<BR>>
2. Start gathering items that require further clarification from
staff.<BR>> 3. Outline next steps.<BR>> - completion of list of
issues<BR>> - prioritization of list of issues<BR>> - preparation
of document outline further work requirements<BR>> <BR>> Total
time: 45 minutes.<BR>> <BR>> WG Scope:<BR>> <BR>> The goal
of the working group is to document specific issues with the<BR>>
existing Inter-registrar transfer policy that require further<BR>>
clarification necessary to support a recommendation to the GNSO
Council<BR>> to request the preparation of an advisory from ICANN
staff concerning<BR>> the appropriate interpretation of any of the
unclear provisions. The<BR>> working group must identify what
further data analysis or audits will be<BR>> required to produce
sufficient information for the Council to take a<BR>> decision. Any
recommendations from the working group should identify the<BR>>
total amount of time and resources required to collect the
necessary<BR>> level of data. The task force should also prepare a
secondary document<BR>> outlining what areas of further or
additional work the GNSO Council may<BR>> wish to undertake
regarding the existing consensus policy.<BR><BR>- --<BR>-
--<BR>Regards,<BR><BR><BR><BR>
-rwr<BR><BR><BR><BR><BR><BR><BR><BR><BR>
"Every contrivance of man, every tool, every
instrument,<BR>
every utensil, every article designed for use, of each<BR>
and every kind, evolved from
very simple beginnings."<BR>
- Robert
Collier<BR><BR><BR>Got Blog? http://www.blogware.com<BR>My Blogware:
http://www.byte.org<BR>-----BEGIN PGP SIGNATURE-----<BR>Version: GnuPG
v1.2.3-nr1 (Windows
XP)<BR><BR>iD8DBQFDBPDw6sL06XjirooRAmqFAKCHhj74RIH0XfXz0jLbfF+Vc3m8GACeK1ok<BR>yX9CENXHLEfrvymtc9+sBLs=<BR>=AXsA<BR>-----END
PGP SIGNATURE----- </BLOCKQUOTE>
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|