<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [registrars] FW: [nc-transfer] Drafting Team Status Update
We should not mix the business model
issues between each registrar and their resellers, into
our effort to clarify our contractual issues.
I believe it is each registar's
own responsibility and should be handled by the registar. This side
issue can be discussed but should not obfuscate the issues of our
basic legal obligation of contract with the registrants.
Joyce
----- Original Message -----
Sent: Friday, August 30, 2002 10:25
AM
Subject: 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
>>>
|