joepruitt

Thanks for the link for my PoshBing library guys.  You commented on the lack of usages for such a library.  While I agree, translating a string from a PowerShell console session is probably not the best use case, but using it as a conduit for other PowerShell related projects is viable.  As an example, I wrote a Twitter bot in PowerShell that uses my PoshTweet PowerShell Twitter library along with my PoshBing project.  This all runs in a console on my desktop but with it anyone can Twitter @askbing with a question and it will use PoshBing to query the Bing APIs for the relevant answer.  Here's a post on the project along with details:

http://devcentral.f5.com/weblogs/Joe/archive/2009/06/08/introducing-askbing-ndash-the-powershell-bing-twitter-proxy.aspx

Thanks again for the post, I really like your show.

-Joe

Manip,I respect your opinions on management issues.  Trust me, I do not believe that any of our customers hire "lazy developers" to write front ends for our devices.  Our API's allow their admins to build value-add solutions on top of the device and for the most part make use of existing in-house specialists (whether from the ops or apps side of the staff).

As for your point about the "smart-(I need to watch my language)", that is true for any product.  If you give access to a system (whether admin, or guest), that user could cause havoc that they have access to.  I've witnessed that first hand when my kids get access to my windows machine at home .  That is why auditing and logging is very important.  It's also important to have a staging system setup for development so that you keep the authentication information for your production system away from those who don't need it.

If you are really concerned about what OS we are running on, I'd suggest you get in touch with our Sales department.  I'm sure that they can give you whatever info you need if you are considering buying from us.  Believe me, we take security very seriously...

As for expandability, our systems are highly tuned for our software and don't support the device for hosting customer-supplied application code.  I'd suggest going to Dell, it'll cost you much less .

Cheers!

-Joe

We don't disclose the operating system that our platforms run on. As you say, it really is not relevant as we provide a closed box system which is transparent to the users using it.  Let's just say that we've written our own, highly optimized, intelligent, modular and scalable architecture that we call TMOS that runs the core of our processing.  Do a web search on "TMOS" and "F5" and you'll find more information.

As for access control, currently our iControl interfaces are tied to the user policies that govern our Administrative GUI.  We currently allow admin (full access), operator (read + partial write), and guest (read-only).  We are currently working on expanding the features with a more extensive authorization model in one of our upcoming releases.

As for custom encryption, I'm not quite sure what you mean.  Is this in regards to our management interfaces, or traffic level encryption.  For our management interfaces, we transport everything over SSL and there really is no option to customize this.  As for traffic level encryption, we offer full extensibility in how you configure and deploy.  Our devices are a full proxy so we can proxy client-to-device and device-to-server.  Also, this is configurable at runtime by making use of our iRules scripting language.  And, since you have full control of all traffic content (including the payload), you can decide to partially encrypt the content in full or parially.  A good example of this would be if you wanted to not allow credit card numbers outside of your enterprise.  You could write an iRule that scanned all traffic for patterns matching valid credit card numbers and either mask out, encode, or encrypt the numbers.  It's very flexible stuff.

Hope that answers your questions

-Joe