Re: [registrars] Transfer Ballot

[Larry Erlich <erlich@domainregistry.com>]

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