ICANN/DNSO
DNSO Mailling lists archives

[registrars]


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