Coming from a product management background in a [rather big] company, here is my
contribution:
Al Potter wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Content-Type: text/plain; charset=us-ascii
>
> Greetings:
>
> We're debating what is reasonable for a fortune 500 customer to demand from a
> high-end firewall vendor in terms of support, and have the following questions:
>
> 1. What is the reasonable minimum for response time on a support contract?
>
Leave the phrase "high end firewall" out of the discussion. You have a basic
product support question. It depends on what you are willing to pay. Product
support costs are rather lengthy math calculations that incorporate multiple
MTBF/MTBR factors, actual product costs over time, parts support and availability
and several other innocuous items. Time to correct based in part on the resources
needed. Essentially, you must view the problem as what investment you (whether
F/500 or F/2000) want to set aside to correct the problem at your end.
Essentially, you must totally disregard the performance of the vendor. To wit, if
you need to have a user group back on the air within 30 minutes of a failure, it is
often cheaper to purchase a standby unit than to argue with a vendor whether there
is going to be a dedicated on-site engineering presence 24x7 and a corresponding
commitment to correction (ever ask the F/500 companies how many standby motor
generators they have invested in?). That cost, then becomes a part of the up-front
acquisition cost of the "system" as a whole. In other words, I suggest the F/500
front end planning has failed if you are at the point of arguing with a vendor how
soon they might show up.
>
> 2. What are normal parameters for required escalation to a higher level of
> support?
There are often none unless it has been spelled out by contract. My experience is
that the winner is whomever hoists the largest lever and threatens the other side.
But here again, you get into the "color TV repair syndrome". Who, today, really
fixes color TVs? Your warranty suggests that they will, but in many cases, the
answer is that part or all of the failing unit will be replaced, not repaired.
Scream louder and you will most assuredly get one of two responses: a) "I fixed it"
meaning I stuffed it with different parts and you are going to pay me for them, or
b) "The frazzle-snitchalator is just fried beyond belief, so the cost exceeds my
New Belch-Glow unit" which you are going to want to pay me for because you want a
working TV. Remember, there is little concern in the equation regarding the
product itself. The cost is in locating and dispatching people in an orderly and
timely fashion, and good people (the engineer we all want) are few and far between,
and are very expensive, both from a logistic as well as a burden viewpoint.
>
>
> 3. Is it reasonable to have an absolute contractual deadline for final issue
> resolution, and if so, what is a reasonable amount of time for this?
>
Nope, not at all. (you believe this and you have an inside story for telephone
companies, airlines and ISPs)
Resolution is always based on "best effort", with the final resolution being a
complete change out of the system if all other efforts fail (also known as a
product defective warranty). Why is this the case? Well, consider for a moment
that you or your environment is the ultimate culprit in causing the failure. You
do not know this and do not have the in-house skills to discover it. The vendor
when called does not know this and may not have the skills to detect it either (if
you have a good EE, ask how easy it is to figure out a capacitor discharge that
back circuits a system and how long before he could figure it out). So it would be
foolish of both parties to believe that such a target is reasonable.
You could declare in the contract, however, that after so many time periods of
outage, the unit is to be replaced with a fall back unit. That is reasonable.
Just make sure you know who is responsible for paying for it and that the
replacement unit in question is within "reach" of the deadline.
Final thought - good planning which includes redundancy of critical components is
the safest way to go. That's how we got our Lunar pilots back when we blew out the
cryogenic unit. Replace on-line and repair off-line!
>
> Please note that these questions are in support of the development of ICSA
> Labs Firewall Certification Criteria. If you have strong feelings, here is
> your chance to let them be known. We may solicit more input on related issues
> in the near future.
>
> AL
>
> - --
> +--------------------------------------------------------------------+
> | Al Potter Manager, Network Security Labs |
> | apotter at-yay icsa ot-day net ICSA Labs |
> | (If the spambots learn piglatin...) |
> | PGP Key: 0x58C95451 http://www.icsa.net |
> | PGP Fingerprint: D3 1D BE 8C B5 DD 12 61 5A 4A 65 32 93 E5 D9 36 |
> +--------------------------------------------------------------------+
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.4 (GNU/Linux)
> Comment: Exmh version 2.2 06/23/2000
>
> iQCVAwUBOm4DPtuN3h5YyVRRAQJwxAP/Y9w+om9BABy7v9GMeMm8ghdbagb88dbJ
> 4QIY16I1OeJuytXRm+xSkitoT2CFCbQgFxO1XH09tc6dmjz/hvndmX0+TVemdGZR
> pF7mIjyn2aFHn8mw1hiWTRqD5PyHOMh+dCpFwo2cXC+K1rWXrDU5VBi7i8RbOy87
> f/PQa+O0qTo=
> =7IM3
> -----END PGP SIGNATURE-----
>
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
