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