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