<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [registrars] Transfer Ballot
Ross Wm. Rader wrote:
>
> Larry,
>
> This goes back to the premise that if the gaining registrar is doing their
> job (as required by the gaining registrar processes), then the losing
> registrar should not have concern in any of the cases that you describe
> below. If there is concern, then the redress and denial processes can most
> certainly be invoked.
Please re-read my comments. The issues that I raised
are not covered by the above. I am stipulating that the gaining
registrar HAS done their job. I am saying that there are
cases where the losing registrar may need, on a limited basis,
to overide that in certain cases.
Larry
>
> ICANN has clearly specified that failure to respond to a request made by the
> losing registrar does not constitute a valid reason for the losing registrar
> to deny the request (as the sole determinant). ICANN's contract also makes
> it very clear that the registered name holder or *someone with the apparent
> authority* can approve or deny requests.
>
> I'm not pretending that these document are perfect. But they do constitute a
> much more solid foundation than what we have under our current agreements.
> These documents can be changed, but they have to be accepted first. If their
> not accepted, then we are right back at square one with this. If we move
> back to square one, then the rules of engagement will most certainly change.
>
> Thanks,
>
> -rwr
>
> Tucows Inc.
> t. 416.538.5492
> ----- Original Message -----
> From: "Larry Erlich" <erlich@domainregistry.com>
> To: "Ross Wm. Rader" <ross@tucows.com>
> Cc: <registrars@dnso.org>
> Sent: Sunday, October 07, 2001 1:11 PM
> Subject: Re: [registrars] Transfer Ballot
>
> > Ross Wm. Rader wrote:
> > >
> > > Perhaps I should have been more explicit with my answer Larry. How does
> your
> > > sister grant authorization to the gaining registrar if she is on
> vacation?
> >
> > Maybe, in this particular case I happen to
> > know that "no way no how" that my sister,
> > with a domain that she controls, would switch
> > registrar.
> >
> > Let's start with that assumption.
> >
> > And maybe, the same might be true for my
> > best friend, and for certain clients
> > that we deal with.
> >
> > In the case of the clients,
> > perhaps the person that I deal with is
> > the highest ranking person in the firm,
> > but the contact on the account is a person
> > under that person. (After all, the Chairman of
> > GM is not the admin contact, on the domain.
> > But maybe Elliot Noss golfs with him, or maybe
> > he plays tennis with the head of IT at GM?
> >
> > Further to that point, this is the admin
> > contact at GM.com (where TUCOWs is registrar):
> >
> > DNS Contact, EDS NNAM dnsmaster@eds.com
> > 300 Renaissance Center
> > Detroit, MI 48265
> > US
> > 248-265-5000 #2
> >
> > Which of course is not even a person.
> > So using your document, there is no common
> > sense override for someone who manages to
> > get hold of the dnsmaster@eds.com email
> > account.)
> >
> >
> > Back to the case of my sister. She is the Director
> > of Research at a Hospital, and runs a small
> > consulting business.
> >
> > Maybe someone who works under her "her computer person"
> > has put the transfer in. Or maybe her (soon to be ex) husband, who
> > has access to her email, has put in or approved the change request.
> > Or maybe she was duped when she signed up for hosting.
> >
> > Your document does not allow for a common
> > sense exception to be invoked if the registrar
> > has a reasonable belief that the request should
> > not have been made, or should not have
> > been approved.
> >
> > There is precedent for this. A Doctor writes
> > a prescription. A pharmacist is supposed to fill the prescription,
> > but will not if they have reason to believe that
> > there is an error. (They will try and get in touch
> > with the Doctor. But if they can't they might not
> > fill the prescription.) One reason that medical
> > errors happen is that people tend not to question
> > with common sense what the Doctor orders or says.
> > I have personal experience with this and
> > would be glad to give you examples.
> >
> > By the way, in Bensalem, a Doctor (in the building
> > that we are located in) was arrested for writing
> > prescriptions for Oxy-Contin to drug addicts.
> > The pharmacist called the doctor to verify the prescriptions and
> > the Doctor said everyting was "ok". The pharmacist
> > STILL did not fill the presciptions, and alerted
> > the authorities. Turns out the Doctor was practicing
> > without a medical license, among other things.
> > The pharmacist used his common sense and
> > helped save lives.
> >
> >
> > > The answer is that the process makes it extremely unlikely your
> fictitious
> > > example would occur.
> >
> > It doesn't matter how unlikely. What do you see as the harm
> > (by having a common sense exception)?
> > Do you think Verisign or Register.com
> > are going to invoke this exception 7,000 times per week?
> >
> >
> > > The registered name holder must provide authorization
> > > for the transfer to occur.
> >
> > Registered name holder takes many forms. The authorization
> > is as simple as someone who has access to the email account
> > making an approval. Many of our clients allow their
> > admin assts. to answer their email.
> >
> > > In order for things to get to the point that you
> > > describe, someone with some level of authority related to the name had
> to
> > > undertake the transfer. Gut feel doesn't count when it comes to denying
> > > transfers.
> >
> > That is where we differ.
> >
> > > This is where the out-of-band resolution becomes necessary. Who
> > > requested the transfer, who approved it etc...
> >
> > Doesn't matter. The question is not whether the
> > gaining registrar has received what THEY THINK is the
> > approval. I will stipulate that they have. This is just
> > a final check to allow a denial based upon some reasonable
> > belief that the request should not have been made.
> >
> > >
> > > I'm disappointed that you would vote to disapprove the process based on
> this
> > > misunderstanding.
> > > This document has been in the wild for weeks now.
> >
> > Well, sorry about that.
> > One of the realities of this group is that there
> > are some who have the ability to spend more time
> > on these issues (because of the nature of their
> > jobs) creating formal documents that the rest
> > of us get to comment on. Sometimes there is just
> > not enough time to run a business and spend the
> > proper time analysing and commenting on these
> > things. So this is what ends up happening.
> >
> >
> > > Further
> > > to that, it has been made painfully clear that it is open to amendment.
> If
> > > you feel strongly that gut-feel mechanisms must be in place as you
> describe
> > > below, then the most appropriate way to accomplish this is not to block
> the
> > > document, but to work with it and improve it going forward.
> >
> > The point of needing a common sense exception was made
> > in at least 1 (and possibly 2) teleconferences that I
> > attended. I'm almost certain that other registrars also
> > had the same concern. It also had to do with blocking
> > a rogue registrar. I'm sorry that I did not catch
> > that it was missing when it was out for review.
> >
> > >
> > > You do imply that there are "other things" that are causing you to hold
> back
> > > your approval. Could you elaborate on this further?
> >
> > May or may not be the case. I just didn't
> > want to imply that it was 100% ok except for this.
> >
> >
> > > If there are truly
> > > serious flaws with this document, then the time to hear about them is
> now.
> >
> > You seem to imply that the document could
> > be modified at this point.
> >
> > Larry Erlich
> >
> > >
> > > -rwr
> > >
> > > Tucows Inc.
> > > t. 416.538.5492
> > > ----- Original Message -----
> > > From: "Larry Erlich" <erlich@domainregistry.com>
> > > To: "Michael D. Palage" <michael@palage.com>
> > > Cc: <registrars@dnso.org>
> > > Sent: Saturday, October 06, 2001 5:14 PM
> > > Subject: Re: [registrars] Transfer Ballot
> > >
> > > > IRDX
> > > > >
> > > > > [ ] APPROVE
> > > > >
> > > > > [X] DISAPPROVE
> > > > >
> > > > > *** END BALLOT ***
> > > >
> > > >
> > > > Among other things, I feel that there should have
> > > > been some "common sense" exception
> > > > to deny a transfer, if used on a limited
> > > > basis. I know that this had been discussed.
> > > >
> > > > I asked the following question
> > > > of the drafters, and Mike Palage:
> > > >
> > > > "A review of the IRDX seems to indicate
> > > > that a losing registrar couldn't deny a request
> > > > based upon reasonable belief that the registrar's
> > > > customer would not make such a request (and there
> > > > is no time, or no way, to verify it with the
> > > > current registrar). Example: My sister is on
> > > > vacation and a request has been entered to
> > > > transfer her name."
> > > >
> > > > And received the following response (from Ross):
> > > >
> > > > -- Both the gaining and losing registrar may both request
> authorization
> > > from
> > > > -- the registrant. If the gaining registrar requests a transfer, the
> > > losing
> > > > -- registrar must approve the transfer unless the registrant
> specifically
> > > > -- objects based on the presumption that the gaining registrar has
> > > acquired
> > > > -- authorization. If the losing registrar wishes, he may request
> > > confirmation
> > > > -- of the authorization from the gaining registrar.
> > > > --
> > > > -- In a case like this, I would suggest that a phone call to the
> gaining
> > > > -- registrar would be in order so that the unique case could be
> handled
> > > > -- out-of-band.
> > > >
> > > > I don't see the above suggestion as a practical
> > > > way to handle THIS situation. (Different time zones
> > > > of registrars, and the need to deny a transfer
> > > > in 5 days to name a few reasons. And I don't have
> > > > "hotline" email addresses of MOST other registrars,
> > > > only the same email address that anyone would
> > > > have to write to. )
> > > >
> > > > Larry Erlich
> > > >
> > > > http://www.DomainRegistry.com
> > > > --
> > > > -----------------------------------------------------------------
> > > > Larry Erlich - DomainRegistry.com, Inc.
> > > > 215-244-6700 - FAX:215-244-6605 - Reply: erlich@DomainRegistry.com
> > > > -----------------------------------------------------------------
> >
> > --
> > -----------------------------------------------------------------
> > Larry Erlich - DomainRegistry.com, Inc.
> > 215-244-6700 - FAX:215-244-6605 - Reply: erlich@DomainRegistry.com
> > -----------------------------------------------------------------
--
-----------------------------------------------------------------
Larry Erlich - DomainRegistry.com, Inc.
215-244-6700 - FAX:215-244-6605 - Reply: erlich@DomainRegistry.com
-----------------------------------------------------------------
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|