Okay, this sounds all well and good, but in the case of the script I mentioned, we're actually using it to turn a pending orders into real orders upon confirmation of payment.
Were it not for the script, I would do manually do exactly the same thing for registrations -- confirm the VISA authorization, log in to the RWI and un-pend the order. For bulk things, I would certainly point things at batch.opensrs.net, but wouldn't single-domain unpends be categorized as "other" activities? What's unwholesome about pending first and confirming later? I realize it's not a big issue for me in particular, but if you're going to get firmer with the policies, I think it's important to ensure that the policies properly represent the issues. "All scripts" is not the same as "all high-volume non-registration traffic". p On Mon, Sep 09, 2002 at 01:38:19PM -0400, Charles Daminato wrote: > > We try to get you, wherever possible, to point any and all scripts at the > batch pool. When we say "not guaranteed", it doesn't mean that if this box > goes offline we don't care (far from it). But since it points to Verisign's > "auto batch" pool (for the CNO registrations), we have no guaranteed (from > the registry) connections to their systems, so we can't extend that > guarantee to you guys. > > The intent of the batch pool was extended by the same intent for verisign to > create a "batch" pool, whereby massive "checks" for domains could be > performed and not affect the regular "legitimate" pool (I'm using a lot of > quoted words and paranthesized comments ... hrm). Basically we want good > wholesome transactions to go through our regular pool, and other activities > (massive scripting, scripted lookups, digging for data through the RWI > interfaces, etc) to go through batch.opensrs.net so the "other" activities > don't affect the regular day to day business of other resellers (as these > activities occasionally do, especially during the daily "drop" time) > > Phew... > > Charles Daminato > OpenSRS Product Manager > Tucows Inc. - [EMAIL PROTECTED] > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Chvostek > > Sent: September 9, 2002 1:20 PM > > To: Charles Daminato > > Cc: [EMAIL PROTECTED] > > Subject: Re: Bulk Check > > > > > > On Mon, Sep 09, 2002 at 07:59:14AM -0400, Charles Daminato wrote: > > > > > > The difference is that the two systems are seperate. rr-n1-tor > > is a pool of > > > machines setup for general use and is 100% supported by our > > organization. > > > Also, the backend points to "guaranteed" pools at the registry > > > > > > batch.opensrs.net is the same code as rr-n1-tor, but it's setup > > to point to > > > the "batch pools" at the registries, and NOT a guaranteed > > interface - but we > > > DO allow scripting against that machine (within reason). > > > > It is wonderful to hear the difference finally. (If it was mentioned > > before, I missed it.) > > > > > We do NOT allow scripting against the rr-n1-tor pools > > > > Uh... Scripting AT ALL, or within reason? > > > > At present, I put new domain orders into pending, and run credit cards > > through a batch-based process with my bank (which is *way* cheaper than > > the standard Internet clearing mechanisms). It costs me $0.08 per batch > > to upload, and take 10 to 15 minutes for a batch to be processed. So > > when a batch result comes back saying that a particular transaction > > cleared, I've got a script (based on Tom Brown's old Perl password.cgi) > > which logs in to the RWI, finds the order and processes it. > > > > Personally, I'd much rather this sort of thing go through "guaranteed" > > channels. Do you see potential for abuse? Should I point it at batch > > rather than rr-n1-tor? > > > > -- > > Paul Chvostek <[EMAIL PROTECTED]> > > Operations / Abuse / Whatever +1 416 598-0000 > > it.canada - hosting and development http://www.it.ca/ > > -- Paul Chvostek <[EMAIL PROTECTED]> Operations / Abuse / Whatever +1 416 598-0000 it.canada - hosting and development http://www.it.ca/
