>This is a topic maddening to all involved. Some things are preventable. Some
>aren't. Some things there is no excuse for.
>
>Long past history, but the first edition of the Syngress CCNA book had some
>rather egregious errors - wrong network numbers and the like. I no longer
>have the book, but I recall one where the question talked about subnet X and
>the only answers were subnets A, B, and C. And I mean whole classes of
>networks wrong.
>
>I'm currently reading a very good book called Quality of Service by Paul
>Ferguson and Geoff Huston.
Both authorities in the field. I've coauthored RFC2071 with Paul,
who is a consulting engineer for Cisco, and Geoff is another author
in the Wiley Networking Council series. He's the technical guru for
Telstra in Australia.
Geoff has a newer book that goes beyond the Quality of Service book,
dealing with ISP performance issues.
>What mars my enjoyment are a number of simple
>spelling errors - fat finger kinds of things. It is as if the editor just
>decided not to use his spell checker because of all the technical terms it
>would choke on. The result is quite unprofessional.
>
>I have even found a technical error or two in books by some rather well
>known participants in this group.
>
>These things do not necessarily diminish the value of these sources. But
>they can lead to a lot of frustration, particularly among folks just
>starting out.
>
>Chuck
Since I'm in the process of turning in the final copy edit today for
my new book, The WAN Survival Guide, believe me, I know there can be
errors. And I caught a few things my copy editor didn't. My technical
reviewer is Scott Bradner, but there are some things that even he
didn't spot. Frankly, this is one reason I prefer writing things on
the design side -- the concepts are important, and there's less of a
danger of screwing up things by getting a command syntax wrong.
There's no simple answer. An author can proof his own work only to a
certain extent. Your eye sees what you meant, not necessarily what
you wrote. At the larger publishers, you can't expect the copy editor
to spot technical problems. One of the nice things about
CertificationZone is that Erik Roy, Ken Fleming, and Rob Roy, who are
at varying stages of the editing process, are getting familiar enough
with the subject matter to backstop me.
Even though RFCs literally are read by dozens of experts while being
drafted, there can be bugs that don't show up until implementation.
It certainly doesn't help when the real exam is looking for an answer
that is technically wrong, but was taken from the Cisco courseware.
The best I can suggest, in exam studies, is never to rely on one
source alone. If for no other than it's easier to learn something
presented from one viewpoint, it's a good idea not to depend on a
single book. Don't be afraid to go back and verify things in the
original standards.
___________________________________
UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
FAQ, list archives, and subscription info: http://www.groupstudy.com
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
