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