ICANN/DNSO
DNSO Mailling lists archives

[registrars]


<<< Chronological Index >>>    <<< Thread Index >>>

RE: [registrars] FW: [nc-transfer] Drafting Team Status Update


Ah, right! Must be a Freudian slip ;)

Thanks,
Tim

-----Original Message-----
From: joyce@mail.webex.net [mailto:joyce@mail.webex.net]
Sent: Friday, August 30, 2002 3:12 PM
To: Tom D'Alleva
Cc: tim@godaddy.com; registrars@dnso.org
Subject: RE: [registrars] FW: [nc-transfer] Drafting Team Status Update


Just a note. Can you all  use "losing" instead of "loosing" which sounds
like a  registrar who does not keep good records. May be that
is what you meant.

Joyce

007names.com


On Fri, 30 Aug 2002, Tom D'Alleva wrote:

> Tim,
> You are right on the money!  Hence, the loosing registrar must verify that
> the transfer request is valid and intentional. I only mentioned the
reseller
> model earlier as a useful example of understanding some of the reasons
why.
> Hijacking, inadvertant or otherwise appears to be on the rise.
>   -----Original Message-----
>   From: owner-registrars@dnso.org [mailto:owner-registrars@dnso.org]On
> Behalf Of Tim Ruiz
>   Sent: Friday, August 30, 2002 12:07 PM
>   To: dwascher@iaregistry.com; Tom D'Alleva
>   Cc: registrars@dnso.org
>   Subject: RE: [registrars] FW: [nc-transfer] Drafting Team Status Update
>
>
>   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
>     -----Original Message-----
>     From: dwascher@iaregistry.com [mailto:dwascher@iaregistry.com]
>     Sent: Friday, August 30, 2002 10:22 AM
>     To: tim@godaddy.com; Tom D'Alleva
>     Cc: registrars@dnso.org
>     Subject: RE: [registrars] FW: [nc-transfer] Drafting Team Status
Update
>
>
>     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
>       -----Original Message-----
>       From: Tim Ruiz [mailto:tim@godaddy.com]
>       Sent: Friday, August 30, 2002 10:26 AM
>       To: Tom D'Alleva; dwascher@iaregistry.com
>       Cc: registrars@dnso.org
>       Subject: RE: [registrars] FW: [nc-transfer] Drafting Team Status
> Update
>
>
>       That doesn't change the legal obligation of the registrar.
>         -----Original Message-----
>         From: Tom D'Alleva [mailto:tdalleva@bulkregister.com]
>         Sent: Friday, August 30, 2002 8:12 AM
>         To: dwascher@iaregistry.com; tim@godaddy.com
>         Cc: registrars@dnso.org
>         Subject: 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.
>
>           -----Original Message-----
>           From: owner-registrars@dnso.org
> [mailto:owner-registrars@dnso.org]On Behalf Of dwascher@iaregistry.com
>           Sent: Friday, August 30, 2002 9:04 AM
>           To: tim@godaddy.com
>           Cc: registrars@dnso.org
>           Subject: 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
>             -----Original Message-----
>             From: Tim Ruiz [mailto:tim@godaddy.com]
>             Sent: Friday, August 30, 2002 8:28 AM
>             To: dwascher@iaregistry.com
>             Cc: registrars@dnso.org
>             Subject: RE: [registrars] FW: [nc-transfer] Drafting Team
Status
> Update
>
>
>             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 >>>