Hey friends,

Thank you very much for helping me in running the client script. It finally
ran with great deal of support from everyone, especially charles and Jim.
Jim actually did it all !!!!

This is probably the liveliest and most co-operative community anywhere.

Thanks one again friends.

ashish
____________________________________________________________________________
______
Monitor your web site, every hour, 24 hours a day, 365 days a year for FREE
at www.industrialmag.com

----- Original Message -----
From: adam <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, September 14, 2000 0:42
Subject: Expirations and renewals - WAS: Re: Probably a silly question
but...


> "Ross Wm. Rader" <[EMAIL PROTECTED]> said:
>
> > Now is the time to let Scott know how you would like to see this
handled.
> > It is currently #2 on his list of things that must get done immediately.
> > We haven't started coding yet, but I believe things kick off on Monday
(?)
> >
>
> As far as I'm aware, the proposed model for gTDL exprirations is to send a
> renewal notice to the *RSP* a set period before the expiration. If the
domain
> still isn't renewed by another set period, OpenSRS will "take over" and
send
> a renewal notice direct to the client. I think this is the best approach
for
> both gTLD's and ccTLD's, with a few amendments:
>
> 1) The RSP should be able to set the period for the first notice in
> their "control panel". I would suggest a month as default. Of course, if
this
> will affect the overhead on OpenSRS machines, it should be set statically.
> 2) OpenSRS should decide the period for the second notice. I would suggest
a
> fortnight as default.
> 3) The second notice should be spoofed as coming from the RSP; be Blind
> Carbon Copied to the RSP; and should contain an RSP-supplied URL for
renewal.
> 4) A third and final notice should be added to the system, say a week
before
> expiration, which should come direct from OpenSRS. This notice should be
> Carbon Copied to the RSP; should contain an informative message about the
> situation; and should contain the RSP's details so the client can "check
up
> on" them.
>
> Optionally, an RSP directory could be added to the OpenSRS website, to
which
> RSP's can add themselves at their discretion. A link to this directory
could
> be added to the final notice. (I think a directory is past due now
anyway.)
>
> Also optionally, the system could log direct notices and warn or remove
RSP's
> who aren't fulfilling their duties. There's a lot of messers out there,
and
> people who don't really know what they're doing - they don't deserve to be
> RSP's. It should be left to people with a bit of cop on. Warn after five,
> remove after ten?
>
> adam
>
> __________________________________________________________
> NetSol - Put The Dot On The Ground And Move Away Slowly...

Reply via email to