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