I'm not sure I can agree with your response here. I am set up to register
domain names with BulkRegister.com and now with OpenSRS.
BulkRegister.com gives the control of the domain name to the RSP. In fact,
anybody that I registered under BulkRegister must work through me to make
any changes on their domain name, whether it is nameservers, change in
admin, tech or billing contact info, etc. BulkRegister does restrict their
RSP's to ISPs and hosting companies, but I'm not sure how set in concrete
that is. Financial check is can you pay the $79.00 registration fee. (Just
kidding, but I'm not aware of background checks they do.) If a client
refuses to pay for the domain name or files a chargeback several months
later, the name reverts back to the RSP. So it can be done under the
agreement.
I suspect OpenSRS is taking this positon because it's the easiest one for
them to take, allowing the RSP to assume all risk while denying them any
protection what so ever.
And I do think the request that OpenSRS "tell me what they do when it
happens to Domain Direct (e.g., a ten-year
domain registration that results in a chargeback). Scott or Ross -- please
answer?" is a reasonable one.
And before you ask, the reason I joined OpenSRS is BulkRegister's process is
not automated like the OpenSRS system. All entries must currently by done
manually from an order form submitted by the customer. They are also a
little higher in cost, but I suspect that could be negotiated if it was the
only factor.
----- Original Message -----
From: "William X. Walsh" <william@userfriendly.com>
To: "David Denney" <daud@dimensional.com>
Cc: <discuss-list@opensrs.org>; "Scott Allan" <sallan@opensrs.org>
Sent: Friday, March 31, 2000 6:08 PM
Subject: Re: Transfers: A bit of an explanation
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On 01-Apr-2000 David Denney wrote:
> > On Fri, Mar 31, 2000 at 06:16:50PM -0500, Scott Allan wrote:
> >> We will not block a transfer after 60 days under these conditions - if
you
> >> feel this is a great risk, you should consider only using more concrete
> >> payment methods.
> >
> > There are no gidelines established by ICANN on this?
> > The luser has NOT PAID for the domain, and yet you will
> > let them STEAL from us? And I thought OpenSRS was trying
> > to HELP ISPs, not put them out of business ... :(
>
> I'm really beginning to think that being a RSP is not the correct course
for
> you. Perhaps in your situation you would be better of not being a party
to
> your customer's domain registration, and instead partner with a
registration
> provider who can provide the service you require?
>
> There is a real risk for the ISP whenever they get in the middle of the
domain
> registration process. I've said this on other lists many times. Many
ISPs
> were paying the NSI fees for their customers for example, and billing
their
> customers directly. They were taking a real risk in doing that, and had
a
> real harm if the customer charged back on them. The situation between
RSPs and
> opensrs is much the same. Our merchant bank won't permit us to do credit
card
> charges for domain registration, because of some silly 3 month rule they
have.
> So this issue isn't as big a one for us.
>
> However, if this is a substantial issue for you, then maybe you should
consider
> either not accepting credit card payments for domain registration fees, or
to
> get out of the domain registration process and instead let your customer
be
> directly responsible for the payment to the registrar.
>
> The bottom line is that opensrs has told us what to expect. We then, each
of
> us, have to decide if we are going to do business under those terms. If
you
> aren't willing to, then you need to examine what other options you have,
rather
> than getting hostile on the lists about it. It's the hostility over the
issue
> that really makes we wonder if you shouldn't look at other alternatives.
>
> Opensrs is in a real bind here. There is no screening of RSPs. They have
an
> obligation under their accreditation to the domain registrant above all.
The
> domain registrant's interests MUST be protected. All it takes is one bad
RSP
> to cancel domains for the wrong reasons for the entire opensrs system to
be
> tainted.
>
> Unlike accredited registrars, none of us had to be screened for our
security
> protocols, our financial status, bonding and insurance, credit history,
> background, business plans, etc. All of this is a part of the registrar
> process, however. Opensrs would be negligent if it gave us too much
control
> and access at the potential expense of the domain registrant.
>
> This does not mean that you concerns are not valid ones. I hope you see
that
> I am not saying that.
>
> Opensrs's policies in this area actually speak very well for them, that
they do
> place such an importance on the rights of the domain registrant. They
are
> required to do that.
>
> All I see is "I want this" "I want that" but what is missing is a
practical way
> that opensrs can do that and still protect the domain name owner from
potential
> abuse by an RSP. People's answer to this has always been that the RSP
can
> only get away with that one time, etc. But even ONCE is too much.
Especially
> with domain names having the potential values that they have been known to
get
> today. The potential loss to the domain registrant is way too high a
risk
> to take.
>
> The only answer then is to stop the opensrs program and do screen all RSPs
and
> set all kinds of minimum qualifications and standards. That is the only
way
> that the rules you want could be implemented in a even semi safe fashion.
I
> don't see this happening, since this is a lot of the appeal of the opensrs
> system.
>
> You could always pay $10,000 and become a member of CORE, but with all
their
> legal problems, I don't know that I would recommend that.
>
> - --
> William X. Walsh <william@userfriendly.com>
> http://userfriendly.com/
> GPG/PGP Key at http://userfriendly.com/wwalsh.gpg
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.1c (Mandrake Linux)
> Comment: Userfriendly Networks http://www.userfriendly.com/
>
> iD8DBQE45ViA8zLmV94Pz+IRAuf7AJ4wsT9daatQrnJ/jEJlssZA3simPgCfVuC7
> 5dANDQXumziXY030e6KitXU=
> =E4ym
> -----END PGP SIGNATURE-----
>
This archive was generated by hypermail 2.1.3 : Tue Oct 19 2004 - 23:35:28 EDT