<<<
Chronological Index
>>> <<<
Thread Index
>>>
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
>>>
|