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