<<<
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
>>>
|