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