We prefer to use the disctinction of "scripting" as opposed to using a "script"
Let's put it this way - if your customer hit your systems with a script, how would you react? If it was innocuous (say, unpending an order every once in a while), you wouldn't mind (or even notice - there's no distinction in the logs from you typing and clicking, or a script doing the work). If a customer of yours was performing multiple commands in rapid succession, you'd be upset :) It's not all cut and dried like this - basically, if your activities are affecting our system, we react. If you believe your activities may affect us, use the batch pool. If you feel (and are confident) that your activities are quite low volume and unimpactful overall, do what you are most comfortable with. Charles Daminato OpenSRS Product Manager Tucows Inc. - [EMAIL PROTECTED] > -----Original Message----- > From: Paul Chvostek [mailto:[EMAIL PROTECTED]] > Sent: September 11, 2002 2:51 AM > To: Charles Daminato > Cc: [EMAIL PROTECTED] > Subject: Re: Bulk Check > > > > 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/
