ICANN/DNSO
DNSO Mailling lists archives

[registrars]


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

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