<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: [registrars] FW: [nc-transfer] Drafting Team Status Update
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
::
::
::
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|