If you are sued in court, you can say to the judge,
"the registrant could have put his name on registrar-lock,
sir,
and decided not to"
As I said time and time again, this is what registrar-lock is
for.
I don't suggest blanket-locking all domains, but I do suggest
giving
the registrants the ability lock their particular
domain.
In my opinion, NOT providing that ability to registrants opens
you up for just the
lawsuit you describe.
you asked "What's the difference?"
The difference is:
1) with lock, the gaining registrar knows immediately the
name
is locked and therefore the true intentions of the real
registrant,
whereas the other method takes longer and results in
ambiguity.
2) without lock, additional burden is placed on losing
registrar
to send and receive the emails. send/receive emails is
more
complicated, takes longer and is more prone to
problems,
and therefore can be used as an excuse to NACK
when
really the legitimate wants to transfer out.
Which contact to send the mail to?
What happens if the mail bounces (bad email
address
due to many
legitimate registrants put false email address in the
whois
to avoid spam, etc.)?
Are you equally concerned about a lawsuit where the
legitimate
registrant wants to transfer out, but you mistakenly NACKed
it
because the email bounced (or other reason), then the
name
expired and he lost it?
What happens if registrant@example.com is used as
admin
address on transferdomain.com but that the registrant login
no
longer exits at example.com and all error email is directed
by
example.com to say the postmaster address at example.com? In
this case
the email ended up in the hands of someone who is not the
registrant,
admin or any other contact of
transferdomain.com.
What happens if example.com was already hijacked, and
is
now being used by a bad guy as the authority to transfer
transferdomain.com?
I'm not opposed to the losing registar doing due-dilligence to
double check,
but in the case of no response, (and the name is not locked),
the transfer
should be ACKed.
Their intent to transfer is confirmed by
1) the gaining registrar and
2) not having the name on registrar-lock. (this in my opinion is
the strongest confirmation)
3) optionally, the losing registar sending an email and getting a
reply,
one way or the other.
Paul
What I am getting at is that if, as the loosing registrar
(the one that said, "Yeah, sure I'll let you have this domain."), I
am sued over a fraudulent transfer, waiving Exhibit B around in court
saying "It wasn't my responsibility" may not get me anywhere.
So, I question whether the currently proposed process will be legally
binding. You can't tell me that I can't decide what due diligence I want
to perform to protect my legal obligations to the registrant. The proposed
process is at odds with that.
And if it's OK for us to just decide to lock all domains and then
sit back and watch all requests get rejected at the registry
level unless the registrant unlocks them first, why isn't it OK
to expect a response to an email or other communication confirming their
intent to transfer? What's the difference?
Tim
Tim,
I am not for sure how you are interpreting legal obligation with
regards to the losing registrar.
In the registry-registrar agreement Exhibit B
1) Obtain authorization of an individual who has apparent
authority to legally bind the registered name holder - Gaining
registrar discretion
That would be the person that I decide since I am the gaining
registrar - that is *not* up to the losing registrar. I am not denying
the losing registrar to check - but they can not stop the transfer
because the losing registrar did not get an email back. A simple
solution would be if the losing registrar has an online system for the
person to authorize / unlock the domain for transfer that is
fine.
David
That doesn't change the legal obligation of the
registrar.
I agree with David on this issue. In a reseller
model, when the admin contact is the registrant, they often don't
understand the emails/smails that result in inadvertent approvals of
transfers and renewals. This creates a support nightmare for both
the losing registrar, the
reseller and the registrant that
didnt understand the whole process. It happens every
day.
Tim,
I know I went to far in the description
and I apologize. In many cases the domains we bought in conjunction with a web site.
The registrant knows nothing about the registrant agreement or a
registrar. Because the Independent TELCO is re-branding the
registrant is unaware of the backend process. That is where the
determining of the Apparent authority is vital in my
situation.
David
David,
Not sure I
completely understand what you're describing. But I would
think that the current registrar is still bound by their
agreement with the registrant. I still can't see how, and
don't believe, any policy that does not allow the current
registrar to verify a transfer of a domain name is
legitimate and within their agreement terms with the registrant
is legally enforceable.
Tim
--------
Original Message --------
Subject: RE: [registrars] FW:
[nc-transfer] Drafting Team Status Update
From: "David
Wascher" <dwascher@iaregistry.com>
Date: Thu, August
29, 2002 6:45 pm
To: "Paul Stahura"
<stahura@enom.com>,
"'Registrar Constituency'"
<registrars@dnso.org>, <tim@godaddy.com>
Paul
and Tim,
I have to disagree about the losing registrar
determining the apparent
authority. In our case that has been
the problem with transfers from
VeriSign and others. The
authority as seen from the losing registrar
has mostly been
the registrant. I am dealing with TELCO's that manage
their
Web site, dialup connection and more then likely did not
really
know that they had a domain. They asked for a web site
name and think
of the web site and the domain as the same. In
many cases a TELCO
sells out to another which then changes
the "apparent authority" all
together. Many Independent
TELCO's farm out the backend services like
the dial-up, tech
support, web hosting, DNS and domain registration.
All of
this is part of our business. When a TELCO changes the
backend
provider say from NeoNova to Info Avenue their is a
very large
conversion that takes place - normally several
thousand users will be
migrated to our ISP side of the house.
To keep things simple and in
one place they will also migrate
the domains to IARegistry. I think
you would agree that most
customers when dealing with an array of
services like one
place to go. That is the case here. The losing
registrar will
not know anything about the move and who we have
established
as the apparent authority which is the Admin listed in
our
partner account. We recognize the ADMIN as the apparent
authority.
They have been setup to Administer the registrants
domain.
Thanks,
David
IARegistry
::-----Original
Message-----
::From: owner-registrars@dnso.org
[mailto:owner-registrars@dnso.org]On
::Behalf Of Paul
Stahura
::Sent: Wednesday, August 28, 2002 5:53 PM
::To:
'Registrar Constituency'
::Subject: RE: [registrars] FW:
[nc-transfer] Drafting Team Status
Update
::
::
::Ross,
::
::I agree that the loosing
registrar is best qualified to
::figure out if a person has
the apparent authority.
::Unfortunately the loosing registrar
has no incentive
::to validate authority, and actually has an
incentive
::to screw around in the hopes of reducing market
share loss
::(or for whatever business purpose).
::This
had been proven time and time again. Name hostage
::taking to
protect market share decline, or even
inadvertently
::(because the email bounced, or did not get
responded to for whatever
::reason),
::is much more
widespread than fraudulent transfers, and causes
::more
customer service complaints.
::Auto-nack will not remove this
problem. In my opinion
::it will make it worse. If you are
worried about fraudulent
::transfers, allow your registrants
to put their names on
registrar-lock. ::There is no way a
name on registrar-lock can
transfer. If the gaining
::registrar gets a legitimate request to
transfer, the
gaining
::registrar can tell the name holder to go to the
losing registrar
::and remove the registrar-lock (the losing
registrar must provide an
::easy way to remove the lock by
the verified name holder).
::So I disagree that the solution
is "auto-nack" if no response to
::an attempted contact of
the name holder by the losing registrar. ::
::I also note 9)
would have to change to implement Tim's
suggestion.
::
::Most fraudulent transfers that we have
encountered occur when
::the bad guy gets control of a domain
that was used as part
::of an email address on a number of
other domains. Then the
::bad guy requests transfer on *all*
the other domains, acking
::each email sent by both the
losing and gaining registrars.
::"auto-nack" does not solve
this, but registrar-lock does.
::Additionally, if there is an
"auto-nack" policy in place,
::where is the gaining registrar
redress,
::if the losing registrar abuses the "auto-nack"
privilege?
::
::I believe the root of the problem is with
the RRP protocol,
::and to really go a long way to solve the
problem, the RRP
::would need to be changed slightly (or of
course switch to EPP,
::even a "thin" EPP). RRP
Registrar-lock is over-loaded,
::and was not intended to
solve the general transfer problem,
::even though it does
help solve fraudulent transfers, IMO.
::
::It would not be
too difficult for the registry to
::implement an "auth code"
with RRP. The code will be
::passed with each "register"
command, could be modified with
::the "modify" command and be
required with a "transfer" command.
::Only 3 commands would
need to be modified. Other Verisign
::registrys have already
modified the RRP in various ways
::(v1.4, with .tv is one
example i believe).
::
::My comments on the
document
::on 5b)
::what happens when the losing
registrar
::blocks access to the gaining registrar's repeated
requests for
::the whois information? or if the losing
registrar's whois
::server is down for an extended
period?
::
::I think a "blacklist of domains that must not
be transferred"
::is redundant. Why not put those names on
registrar lock?
::Maybe I'm missing the intent
here.
::
::I think the losing registrar MAY/MUST? nack the
request if the
gaining ::registrar notifies the losing
registrar that a mistake has
been
::made in the transfer
initiation (an exception to 9).
::
::is 10) the only
minimum standards that apply to 9)?
::10b) and 10c) do not
pertain to the gaining registrar, so is
::9b) really just
10a)?
::as in "9(b) the Gaining Registrar fails to comply
with 10a)"
::I think i agree with the intent of 9 and 10, I
just think
::it could be worded clearer.
::do Gaining
registrars get to inspect the form of 9a) that
::the losing
regisrar used to deny the transfer?
::
::I agree with
Tim's suggestion 5.r below if the intent is
::to prevent
registrar hopping.
::
::
::Paul
::eNom,
Inc.
::
::
::-----Original Message-----
::From: Tim
Ruiz [mailto:tim@godaddy.com]
::Sent: Wednesday, August 28,
2002 11:51 AM
::To: ross@tucows.com; 'Registrar
Constituency'
::Subject: RE: [registrars] FW: [nc-transfer]
Drafting Team Status
Update
::
::
::Ross,
::
::The method of obtaining apparent
authority here is backwards. In
reality, ::the loosing
registrar is the best gauge of who truly has
current apparent
::authority. Registrars are not required to update
their
Whois
::information any
::more often than once in 24
hours. As a result, using Whois data for
the ::gaining
registrar to try and figure out who has apparent
authority is
not ::safe. Requiring them to go beyond that adds
undue
burden on the gaining ::registrar and the registrant
making the
request.
::
::As a result I strongly urge
that 7.f does NOT result in an ACK of
the ::transfer by the
loosing registrar. The person with the apparent
authority
::according to the loosing registrar's records MUST
verify
the transfer ::request for it to go through. Nothing
else really makes
sense
::here if one of
::our goals is
to truly protect the registrant from fraudulent
transfers. If
::the party with apparent authority confirms with the
loosing
registrar that ::the transfer request is valid, the
loosing
registrar HAS confirmation then ::that the gaining
registrar has
acquired the appropriate FOA.
::
::I
don't like the idea of counting on the gaining registrar to
be
::honest and
::complete in their dealings regarding
transfers. It is too
::difficult, if not
::impossible, to
get things reversed with certain registrars. We had
some
::rather unpleasant dealings with one in China a few months
ago
on a related ::issue.
::
::If transfers are
conducted in this manner, the number of instances
of
::registrars needing to invoke the unnecessarily complicated
and
time ::consuming Losing Registrar Redress will be greatly
reduced, if
not ::eliminated altogether.
::
::In
addition, I strongly urge the addition of the following v.
to
5.r: ::
::v. Request to transfer sponsorship occurs in
the first 60 days after
a ::transfer of
sponsorship.
::
::This would add another seriously needed
level of protection against
fraud. ::However, if the loosing
registrar MUST obtain approval from
someone with ::apparent
authority, this may not be as necessary.
::
::Tim
Ruiz
::Go Daddy Software, Inc.
::
::-----Original
Message-----
::From: owner-registrars@dnso.org
[mailto:owner-registrars@dnso.org]On
::Behalf Of Ross Wm.
Rader
::Sent: Wednesday, August 28, 2002 11:17 AM
::To:
'Registrar Constituency'
::Subject: [registrars] FW:
[nc-transfer] Drafting Team Status
Update
::
::
::Members,
::
::Please find to
follow below a brief report on the status of the work
of
::the Transfers TF as it relates to Transfers. Note that we
are
::progressing reasonably well through a review of the
Registrar
::Constituency proposal and have made a few
modifications that I
believe ::are amenable to the interests
of Registrars. I had hoped at
this point ::that we would have
received feedback from the Registry
Constituency ::given
their renewed commitment to the issue, however I
suspect that
::"real life" is somehow interfering with finalizing
the
revisions ::referenced below. I don't expect this delay
to draw out in
any
::meaningful way (we should be able to
resolve it this afternoon
during ::our call) but it needs to
be brought to the attention of the
::constituency
nonetheless.
::
::The Task Force is still targetting the
Shanghai meeting for tabling
of ::our recommendations and we
look to be in good shape at this
point. If ::there are any
questions between now and Amsterdam, I am
happy to answer
::them as they come up. I expect to deliver a full
progress
report and ::draft recommendations during the timing of
the
Amsterdam meeting. ::
::Thanks in advance, (and as
noted below, apologies for the
proprietary ::document
format).
::
::
::
::
-rwr
::
::
::
::
::"There's a fine line between
fishing and standing on the shore like
an ::idiot."
::-
Steven Wright
::
::Got Blog?
http://www.byte.org/blog
::
::Please review our ICANN
Reform
Proposal:
::http://www.byte.org/heathrow
::
::
::
::
::-----Original
Message-----
::From: owner-nc-transfer@dnso.org
[mailto:owner-nc-transfer@dnso.org]
On ::Behalf Of Ross Wm.
Rader
::Sent: Wednesday, August 28, 2002 12:10 PM
::To:
'Transfer TF (E-mail)'
::Subject: [nc-transfer] Drafting Team
Status Update
::
::
::Folks,
::
::Please find
attached a copy of the latest draft (version 1, revision
2,
::draft 2) of the IRDX proposal that the drafting team has
been
working on ::for the last two weeks or
so.
::
::During the call today, I would like to focus on a
review of points 8
::through 15 (pages 14, 15 and 16)
(highlighted in blue) with an eye
::towards ensuring that the
process appropriately takes into account
the ::needs of
R'ants, R'rars and R'ry's. The feedback that the
drafting
team ::gathers through this review will be invaluable
in
providing us with the ::guidance that we need to complete
our task.
::
::I would also like to review the formal
revisions made thus far to
ensure ::that the language used
appropriately captures the intent and
sentiment ::of the
larger group.
::
::Please note that the revisions are not
as sweeping as I had expected
as ::we are still waiting for
input on enforcement mechanisms from the
::Registry
Constituency reps to the Drafting Team. I do not have an
ETA
::for delivery of these details, so its not likely that we
can
cover them ::on the call, however the call will give us
the capability
to rework the ::deadlines in order to keep the
document on track
::
::If there are any questions, please
don't hesitate to drop me a note.
::
::Apologies in
advance for the proprietary document
format.
::
::
::
::
-rwr
::
::
::
::
::"There's a fine line between
fishing and standing on the shore like
an ::idiot."
::-
Steven Wright
::
::Got Blog?
http://www.byte.org/blog
::
::Please review our ICANN
Reform Proposal:
http://www.byte.org/heathrow
::
::
::