<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: [registrars] FW: [nc-transfer] Drafting Team Status Update
The problem with this is WHO are you going to check with? It becomes a draw
because I use a different Authority then you. You may use the registrant I
use the ADMIN of the domain. So we need some form of compromise between the
two.
David
**-----Original Message-----
**From: owner-registrars@dnso.org [mailto:owner-registrars@dnso.org]On
**Behalf Of Tim Ruiz
**Sent: Friday, August 30, 2002 11:03 AM
**To: Tom D'Alleva; svl@nrw.net; registrars@dnso.org
**Subject: RE: [registrars] FW: [nc-transfer] Drafting Team Status Update
**
**
**Still seems the bottom line is it's the registrar who ultimately ACKs or
**NACKs the transfer, putting themselves potentially at risk if they haven't
**checked out each and every transfer. I would rather do that as the loosing
**registrar, before the domain is gone, than after the fact hoping
**the gaining
**registrar will cooperate fully.
**
**Tim
**
**-----Original Message-----
**From: owner-registrars@dnso.org [mailto:owner-registrars@dnso.org]On
**Behalf Of Tom D'Alleva
**Sent: Friday, August 30, 2002 8:51 AM
**To: svl@nrw.net; registrars@dnso.org
**Subject: RE: [registrars] FW: [nc-transfer] Drafting Team Status Update
**
**
**Siegfried,
**Quite the contrary! Registrants (that are the aministrative contacts) are
**bound by their agreements, hence the problem. The value added
**resellers that
**support their websites and domain names now have to create different tools
**to support these names and DNS entries at different registrars or pay the
**additional costs to transfer them back.
**
**> -----Original Message-----
**> From: owner-registrars@dnso.org [mailto:owner-registrars@dnso.org]On
**> Behalf Of Siegfried Langenbach
**> Sent: Friday, August 30, 2002 9:33 AM
**> To: Tom D'Alleva; registrars@dnso.org
**> Cc: registrars@dnso.org
**> Subject: RE: [registrars] FW: [nc-transfer] Drafting Team Status Update
**>
**>
**> Hallo,
**>
**> does that at the end of the road mean that
**> because I do not understand an ageement I accepted I am not
**> bound to it? :-))
**>
**> siegfried
**>
**> On 30 Aug 2002 at 9:11, Tom D'Alleva wrote:
**>
**> >
**> > 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 stillcan't see how, and don't
**> > believe, any policy that does not allow the current
**> registrar to verifya 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
>>>
|