Hello Adam,
A very well worded and well thought out position on this issue.
I agree with you about not raising the bar. I think that bar to entry
being where it is at ($250 minimum ongoing buy-in) is sufficient for
the most part to protect the RSPs enough that it is still a worthwhile
business venture. But that only remains true if the value added
services still exist as a real VALUE ADD, not something that anyone
can just up and offer through Tucows with the generic signup scripts
delivered by OpenSRS.
I know from experience that Ross, and Scott and Chuck and all the
others at OpenSRS DO listen to us here. So I have no doubt they are
listening, and giving serious consideration to the comments we are
making on this subject. My posts are more meant to point out to the
RSPs on this list why I take this position, and why I think they
should also, even if it means they might have to do some work before
being able to offer these value added services.
Someone asked me off list today about where I recommend they go to
learn what they need to do this themselves, so I think it has opened
up a couple of eyes that if you are willing to devote a little time
and work into it, you can do this on your own, and make your service
just that much better. You can buy a few books, and spend a little
time, and do it on your own. I've even posted the books I recommend
on a website at http://www.learnperl.org/ just to make it that much
easier to help people do it themselves.
And someone else emailed me asking about if I think this is not
something OpenSRS should offer, why am I writing a script package that
could be used to do this same thing. It is true I am writing a domain
registry software package for running third level domain registries
and it will include URL redirection and DNS services, and
it will be an open source package using a BSD or Apache style license,
but I've intentionally designed it to REQUIRE that the person
installing it must know more than just the simple basics about perl
and SQL and apache and dns in order to install it properly and make it
work. I decided against making an install program that merely
prompted you for the configuration details and then did all the work,
because I considered that a fair enough bar of entry that would help
make sure the people running these services know enough about what
they are doing to do it at least half way decently.
If you don't understand why me, ECS, Bill, Adam, and a few others have
taken a stand against seeing OpenSRS expand their offerings into these
areas of value added services, feel free to email me and ask for
clarification, or ask me any question you have about my position and
why I stand by it. You don't have to do it on the list. I'd be happy
to explain myself, answer questions, or anything along those lines.
Thursday, October 12, 2000, 4:11:54 PM, you wrote:
> OpenSRSers,
> I've been lurking on this issue for a while, because I was pretty much
> undecided myself, and wanted to see what other people thought. In all
> honesty, I filled in the survey on the OpenSRS website last week, and I don't
> think I objected to the offering of secondary services at the time. On
> reflection, and having read the (majority of) postings against the matter, I
> think I have to concur. I think that it may hurt the RSP's and/or OpenSRS in
> the long run, and quite probably both. It was Scott's post that put the nail
> in the coffn though, and made most sense (although some others made a lot of
> sense too) - it might work, but I think there's a bigger chance of it
> screwing it up for everyone. Is there anything to be said for postponing any
> further on-the-ground developments of these services until such time as it
> has been researched more carefully?
> I would also like to comment on the matter of "raising the bar". This is a
> very tricky issue, but as someone rightly pointed out, it is one of the
> downsides of OpenSRS. It's why I hide my "affiliation" with OpenSRS as best I
> can, and why I have posted in the past about ensuring that the renewal
> process has built-in procedures to protect my being identified as an RSP. Of
> course, there are limits to that - all the user has to do is perform a WHOIS
> on their domain and they're "in", but most don't seem to do that anyway.
> However, the point I would like to make is that I *don't* think we should try
> to raise the bar - I think it would be unfair to do so. I was given the
> chance to avail of this opportunity, and I don't feel it's right to block
> others from the it.
> BUT, I *do* think that it *might* be a good idea to have some kind of vetting
> procedure that complements the Rite Test. I'm not suggesting this to try and
> block people from availing of the opportunity, but as a form of quality
> control. The last thing Tucows should want is a lot of moronic script kiddies
> and/or unethical operators bastardising their service. In fact it should be
> the complete opposite, since it's the open community, support, fairness and
> QoS that encourages me to continue purchasing from them.
> I did say "might" though, and "good idea". Rather than insisting, or being
> seen to insist that Tucows implement something like this, I would be more
> interested in hearing commentary from the staff and managment of OpenSRS,
> letting us know what the quality of RSP's is like in their opinion, since
> they deal with them every day.
--
Best regards,
William mailto:[EMAIL PROTECTED]
