DNSO Mailling lists archives


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

Re: [registrars] Transfer Process-2

Before you go to the trouble of taking
a vote, you might want to check the
legality of what you are asking a vote on. I don't
have any problem with the "on the expiration
date transfers" that are initiated (meaning
we would receive it the day after expiration,
and then approve) I think this
is known in legal theory as "clang of the mailbox",
or something like that.

But as far as requiring a transfer after expiration
date, (allowing as mentioned for the delivery
factor) I don't think you can develop a
policy to require a registrar to do what
you are asking.

As far as what David says is "domain hostage"
"under a different wrapper", this would be similar to
something (I think) like a mechanics lien. If you
don't pay for the auto repairs, the shop can
hold your car until you pay. You can call this
"car hostage" if you want, but it doesn't
change the facts of that situation either.

"Basic Business 101" you say?
Domain registration to me is a service
business. This whole idea that Registrars don't have
any costs other than $6, 
or that our overhead or fixed costs (or profit) should be
ignored, really bothers me. Next time you go
to a restaurant, offer to pay them 
only for the cost of the coffee, instead
of what they charge for the coffee
in a cup, brewed, and served.  Then
go to a movie theater and ask if you can sit
in one of the empty seats since
it won't cost them anything to
have an empty seat filled if they don't
pay the distributor a per ticket fee.
And some lawyers charge $300 per hour. What
is their "cost"?

Larry Erlich


Bhavin Turakhia wrote:
> I am for allowing transfers during expiry - as to whether we should vote
> separately on this process or include it in the document is a decisoin left
> to everyone else
> > -----Original Message-----
> > From: owner-registrars@dnso.org [mailto:owner-registrars@dnso.org]On
> > Behalf Of Elana Broitman
> > Sent: Wednesday, September 26, 2001 6:19 PM
> > To: David Wascher; Registrars List
> > Subject: RE: [registrars] Transfer Process-2
> >
> >
> > David and others discussing this issue - are you advocating a
> > change to the
> > IRDX document, or a separate vote?  I want to understand our current
> > process.
> >
> > thanks
> >
> > -----Original Message-----
> > From: David Wascher [mailto:dwascher@infoave.net]
> > Sent: Tuesday, September 25, 2001 6:16 PM
> > To: Registrars List
> > Subject: [registrars] Transfer Process-2
> >
> >
> > The paper is to provide a constant way for the registrars to do
> > business as
> > seen by the general public. If a customer decides to start a
> > transfer on the
> > expiration date then the domain should be Auto-ACK'ed except for
> > the reasons
> > outlined in the paper 5 days later. In that case that gives the customer a
> > choice and allows the losing registrar away to get his money back
> > from NSI.
> > Zero hours after the expiration the registrar has time to do
> > something else
> > with the domain.
> >
> > All of us have cost - it is the cost of doing business. This cost
> > is in the
> > registration process using different factors - basic business
> > 101. To claim
> > that there are cost that prevent you from releasing the domain is
> > plain and
> > simple "domain hostage" in a different wrapper. This is all part
> > of what we
> > are fighting and trying to bring to closure for each of our customers.
> >
> > So my recommendation (at a minimum) would be if the transfer is
> > initiated on
> > the expiration date (time not included) then it passes. To be more
> > consistent - all of us should use GMT to know when the end of the
> > expiration
> > is. There could still be the argument of allowing the transfer to
> > go through
> > the day after because of the lag in emails and such it the transfer was
> > started 1 minute before midnight on the expiration date.
> >
> > David W.
> > IARegistry
> >
> >

Larry Erlich - DomainRegistry.com, Inc.
215-244-6700 - FAX:215-244-6605 - Reply: erlich@DomainRegistry.com

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