NO MORE UPDATES TO THIS PAGE PLEASE. SUBMIT ALL FUTURE COMMENTS TO

3.1 pg 51

Where you talk about weakest links, maybe also worth mentioning that security of a client system is no stronger than the weakest link in the security of the infrastructure. For example, if someone can mess with the authentication server then they can get client machine access; if someone can mess with the DNS servers then they could redirect traffic from the client and potentially gain passwords. This is yet another reason for limitting access to the infrastructure servers to SAs only.

[ Tom's reply: Added. Status: DONE ]

3.1.1. pg 53

Perhaps worth mentioning that SLA discussions are a consultative process. A small company with only 1 or 2 SAs will not get 24x7 support, no matter how much they want it. The SAs are a vital resource to be taken into account when creating the SLAs as any other component.

[ Tom's reply: Added. Status: DONE ]

3.1.3 Open Architecture pg57

Nice knock on M$ for their Kerberos extensions. But is it useful to name them specifically? Why not just use "A leading OS vendor". It will get the point across without being seen as attacking M$. I'm pretty sure that the mail system you discuss in the "NJ pharma" example is M$ exchange, so it's not changing policy.

[ Toms reply: Actually the NJ Pharama example was Lotus CC:Mail.]

It's possibly also worth noting that a vendor product may be able to use open standards over-the-wire, but that storage and content may still be proprietory. For example, Exchange server can provide IMAP services, but that doesn't necessarily mean any IMAP client can utilise the calendar. Similarly Lotus Notes can be configured (via a connection document) so that it knows the SMTP server at the other end is another Notes server and so can sent Notes proprietory formatted data, knowing the receiver will display fully and "correctly".

[ Tom's reply: Well, that's 3 different points (open protocols can use proprietary storage; gateways can lose features; proprietary systems can usurp an open protocol). These are all good points but I can't find a place to put them. Status: Incomplete ]

3.1.7 pg 63 Another hazard of non-servers (anecdote):

A startup web company found themselves short of disk space and to save money they NFS exported free disk space from a UNIX desktop. This ended up being mounted on all the servers since it provided a common component. However, after a block-wide power failure that outlasted the UPS the network could not come up; the workstation wouldn't complete booting without the DNS server running, and the DNS server required the NFS partition to be available to complete booting. Shortly afterwards the company hired an SA.

[ Toms reply: Included. Status: DONE ]