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
::
::
::