Re: First Impressions - CCIE Practical Studies [7:32237]
I got my CCIE Practical Studies book via half.com yeaterday and I had the same shipping problem. I saved about $25 on the price of the book, but the delivery took over 3 1/2 weeks! I don't think there was even a stamp or postmark on the media mail package, so I have no idea how it arrived I'd just as soon pay Amazon's price and get normal shipping (plus my company re-imburses me for all books I buy anyways). The book looks pretty good, but some people have told me that the book is still simple compared to the lab iteslf. But all in all, it does give you a blueprint of topics to study, then you can branch off in each subject for more in-depth studies in other books, etc. ""Chuck Larrieu"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Just got my copy. > > Reading the "About the Authors" section alone is impressive. All those > associated with the book are CCIE's. I look forward to discovering if there > are any errors in the book. One would hope not, given the credentials of the > writers and reviewers, one of whom was the Halifax Lab Proctor for several > years. > > So far I have browsed all of the first chapter "The Key Components for > Modeling an Internetwork" > > This chapter covers in good detail all those basic questions - the config > register, configuring a router as a frame switch, password recovery, show > and debug ( called "the big show" and "the big d" respectively, throughout > the book. ) building a terminal server, and much much more. This alone tells > me that this book might be a good investment for those just starting out, as > well as those prepping for the CCIE Lab. Sure, all of this information is > available elsewhere, but with this book, it is in one place, easily located, > and clearly explained. > > There is even a section about configuring networking on windoze computers. > Considering the number of raw beginners who are coming into the > certification process, this is helpful. > > I'll have more comments after I have had a chance to look at the "good" > stuff. > > Chuck Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=32240&t=32237 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: First Impressions - CCIE Practical Studies [7:32237]
Chuck, Check out my review of the book: http://www.optsys.net/review.htm Let me know your thoughts on it. If you put a formal review together as well, I can add it to that web page. thanks, -Brad Ellis CCIE#5796 (R&S / Security) Network Learning Inc [EMAIL PROTECTED] used Cisco gear: www.optsys.net CCIE Labs, racks, and classes: http://www.ccbootcamp.com/quicklinks.html ""Chuck Larrieu"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Just got my copy. > > Reading the "About the Authors" section alone is impressive. All those > associated with the book are CCIE's. I look forward to discovering if there > are any errors in the book. One would hope not, given the credentials of the > writers and reviewers, one of whom was the Halifax Lab Proctor for several > years. > > So far I have browsed all of the first chapter "The Key Components for > Modeling an Internetwork" > > This chapter covers in good detail all those basic questions - the config > register, configuring a router as a frame switch, password recovery, show > and debug ( called "the big show" and "the big d" respectively, throughout > the book. ) building a terminal server, and much much more. This alone tells > me that this book might be a good investment for those just starting out, as > well as those prepping for the CCIE Lab. Sure, all of this information is > available elsewhere, but with this book, it is in one place, easily located, > and clearly explained. > > There is even a section about configuring networking on windoze computers. > Considering the number of raw beginners who are coming into the > certification process, this is helpful. > > I'll have more comments after I have had a chance to look at the "good" > stuff. > > Chuck Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=32241&t=32237 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: First Impressions - CCIE Practical Studies [7:32237]
hmmm.. don't know why you said that "I had the same shipping problem..." I didn't read that in Chuck's post. However, on the same topic, I just got my copy yesterday. I bought mine from Pearson Education for $48.75 with $7.00 shipping ordinary mail to Canada. It took 2 weeks which was fine with me. Like Chuck I am immediately impressed by the authors/reviewers. All told - 9 - CCIEs. I am just getting through chapter one but I have perused the appendices and Chapter 18 (the timed labs). I'm excited with what "looks" like is there. Can't wait to devote more time to it. Kevin Wigle - Original Message - From: "Steven A. Ridder" To: Sent: Wednesday, 16 January, 2002 20:43 Subject: Re: First Impressions - CCIE Practical Studies [7:32237] > I got my CCIE Practical Studies book via half.com yeaterday and I had the > same shipping problem. I saved about $25 on the price of the book, but the > delivery took over 3 1/2 weeks! I don't think there was even a stamp or > postmark on the media mail package, so I have no idea how it arrived > I'd just as soon pay Amazon's price and get normal shipping (plus my company > re-imburses me for all books I buy anyways). > > The book looks pretty good, but some people have told me that the book is > still simple compared to the lab iteslf. But all in all, it does give you a > blueprint of topics to study, then you can branch off in each subject for > more in-depth studies in other books, etc. > > ""Chuck Larrieu"" wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > Just got my copy. > > > > Reading the "About the Authors" section alone is impressive. All those > > associated with the book are CCIE's. I look forward to discovering if > there > > are any errors in the book. One would hope not, given the credentials of > the > > writers and reviewers, one of whom was the Halifax Lab Proctor for several > > years. > > > > So far I have browsed all of the first chapter "The Key Components for > > Modeling an Internetwork" > > > > This chapter covers in good detail all those basic questions - the config > > register, configuring a router as a frame switch, password recovery, show > > and debug ( called "the big show" and "the big d" respectively, throughout > > the book. ) building a terminal server, and much much more. This alone > tells > > me that this book might be a good investment for those just starting out, > as > > well as those prepping for the CCIE Lab. Sure, all of this information is > > available elsewhere, but with this book, it is in one place, easily > located, > > and clearly explained. > > > > There is even a section about configuring networking on windoze computers. > > Considering the number of raw beginners who are coming into the > > certification process, this is helpful. > > > > I'll have more comments after I have had a chance to look at the "good" > > stuff. > > > > Chuck Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=32249&t=32237 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: First Impressions - CCIE Practical Studies [7:32237]
HI, I received my copy last week, here in the UK. I was given a good review before I bought the book (Thanks Brad Ellis). I am happy with the content of the book and the LAB's at the end are well worth the price of the book (and more). I have only found spelling mistakes (like form instead of from), but I have not completed it yet. But, saying that, I am glad I was not asked to author a book that would have such a wide audience and a list of reviewers (all those that use groupstudy). Its a good book and I am waiting for Practical Studies Vol 2. Impressed Rob > -Original Message- > From: Kevin Wigle [SMTP:[EMAIL PROTECTED]] > Sent: 17 January 2002 02:32 > To: [EMAIL PROTECTED] > Subject: Re: First Impressions - CCIE Practical Studies [7:32237] > > hmmm.. don't know why you said that "I had the same shipping > problem..." > > I didn't read that in Chuck's post. > > However, on the same topic, I just got my copy yesterday. > > I bought mine from Pearson Education for $48.75 with $7.00 shipping > ordinary > mail to Canada. > > It took 2 weeks which was fine with me. > > Like Chuck I am immediately impressed by the authors/reviewers. All told > - > 9 - CCIEs. I am just getting through chapter one but I have perused the > appendices and Chapter 18 (the timed labs). I'm excited with what "looks" > like is there. Can't wait to devote more time to it. > > Kevin Wigle > > > ----- Original Message ----- > From: "Steven A. Ridder" > To: > Sent: Wednesday, 16 January, 2002 20:43 > Subject: Re: First Impressions - CCIE Practical Studies [7:32237] > > > > I got my CCIE Practical Studies book via half.com yeaterday and I had > the > > same shipping problem. I saved about $25 on the price of the book, but > the > > delivery took over 3 1/2 weeks! I don't think there was even a stamp or > > postmark on the media mail package, so I have no idea how it arrived > > I'd just as soon pay Amazon's price and get normal shipping (plus my > company > > re-imburses me for all books I buy anyways). > > > > The book looks pretty good, but some people have told me that the book > is > > still simple compared to the lab iteslf. But all in all, it does give > you > a > > blueprint of topics to study, then you can branch off in each subject > for > > more in-depth studies in other books, etc. > > > > ""Chuck Larrieu"" wrote in message > > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > Just got my copy. > > > > > > Reading the "About the Authors" section alone is impressive. All those > > > associated with the book are CCIE's. I look forward to discovering if > > there > > > are any errors in the book. One would hope not, given the credentials > of > > the > > > writers and reviewers, one of whom was the Halifax Lab Proctor for > several > > > years. > > > > > > So far I have browsed all of the first chapter "The Key Components for > > > Modeling an Internetwork" > > > > > > This chapter covers in good detail all those basic questions - the > config > > > register, configuring a router as a frame switch, password recovery, > show > > > and debug ( called "the big show" and "the big d" respectively, > throughout > > > the book. ) building a terminal server, and much much more. This alone > > tells > > > me that this book might be a good investment for those just starting > out, > > as > > > well as those prepping for the CCIE Lab. Sure, all of this information > is > > > available elsewhere, but with this book, it is in one place, easily > > located, > > > and clearly explained. > > > > > > There is even a section about configuring networking on windoze > computers. > > > Considering the number of raw beginners who are coming into the > > > certification process, this is helpful. > > > > > > I'll have more comments after I have had a chance to look at the > "good" > > > stuff. > > > > > > Chuck Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=32284&t=32237 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: First Impressions - CCIE Practical Studies [7:32237]
I have a couple of "nit-picky" complaints about the book (as I do about almost every book I read). There are some typo's as a previous poster indicated. One of my biggest pet peeves is the use of the term "continuous" when the author (probably) means "contiguous" - one sees this most often when discussing OSPF. Note, this book isn't unique in this mis-use of the term; there are many CCO documents that also make this "error." I'm assuming that this is the product of a spell-checker that didn't know the term contiguous, suggested continuous and someone hit "replace all." Before the flame-war starts, I know that these two words have *similar* meanings but in this case I - my personal opinion - think that contiguous is 'more right' - besides, it's the term used in the RFC. Since I'm picking nits; the author indicates that the OSPF process ID on a router should be thought of "as an Autonomous System ID. This number should be the same on all routers within the autonomous system." Per CCO, this is a locally significant setting used only to distinguish between multiple OSPF routing process on a particular router. If we were to apply the RFC2119 definition of "should" to this statement one might think that certain problems may occur if this practice wasn't followed. I don't believe this to be the case but I'm sure someone on the list will correct me if I'm wrong. There's nothing wrong with using the same process ID on all of your OSPF routers; I would guess that networks are configured that way more often than not; but isn't a requirement. Given that the lab exam is all about splitting hairs to the most minute detail and knowing the various protocols in depth, it probably should have been noted (as in other texts) that two adjacent routers can have different process IDs configured. There are some outright mistakes in the book - I just checked the CiscoPress site for an errata and didn't see one yet. Here one that I recall off the top of my head: EIGRP - (p.691) at the bottom of the page, the 'distance' command. - this is almost a direct copy/paste from the IGRP chapter; does not include the required information to change the admin distance of the EIGRP routing process (which requires both an internal and external distance); it only lists the syntax to change the distance of a specific neighbor's updates. I find it funny that the EIGRP chapter says "For a specific example and more practice with the 'distance' command, see" the IGRP chapter. When you look at the IGRP chapter, it uses the same sentence to point you to the RIP chapter. Anyone who has walked into an EIGRP network with multiple, unfiltered redistribution points into a RIP domain will know first-hand the importance of knowing how a router handles internal vs. external EIGRP routes. Additionally, I thought the section on PPP authentication could have used some more work on the one-way authentication options (both PAP and CHAP). Bottom-line, this seems to be a well written book; it gives you some good examples and labs to work on your own, etc. It won't replace any of the other "must haves" on the bookshelf (e.g. Doyle, Caslow, Thomas, etc.) and unfortunately, (as it seems with all of the books published these days) you have to play 'reporter' and verify the information in the book with some other source (CCO, RFCs, other texts) - this is a topic I could rant on for quite some time (considering the $thousands - literally - I've spent on training materials which contain errors). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 16, 2002 7:18 PM To: [EMAIL PROTECTED] Subject: OT: First Impressions - CCIE Practical Studies [7:32237] Just got my copy. Reading the "About the Authors" section alone is impressive. All those associated with the book are CCIE's. I look forward to discovering if there are any errors in the book. One would hope not, given the credentials of the writers and reviewers, one of whom was the Halifax Lab Proctor for several years. So far I have browsed all of the first chapter "The Key Components for Modeling an Internetwork" This chapter covers in good detail all those basic questions - the config register, configuring a router as a frame switch, password recovery, show and debug ( called "the big show" and "the big d" respectively, throughout the book. ) building a terminal server, and much much more. This alone tells me that this book might be a good investment for those just starting out, as well as those prepping for the CCIE Lab. Sure, all of this information is available elsewhere, but with this book, it is in one place, easily located, and clearly explained. There is even a section about configuring networking on windoze computers. Considering the number of raw beginners who are coming into the certification process, this is helpful. I'll have more comments after I have had a chance to look at the "good" stuff. Chuck Message Posted at: http://www
RE: First Impressions - CCIE Practical Studies [7:32237]
I have a similar impression of the book. While it is very useful and has lots of good information, it is littered with typos and minor errors that you *should* be able to spot. I'm hoping they'll get an errata posted soon, but I wouldn't count on it happening too quickly. >>> "R. Benjamin Kessler" 1/17/02 10:21:29 AM >>> I have a couple of "nit-picky" complaints about the book (as I do about almost every book I read). There are some typo's as a previous poster indicated. One of my biggest pet peeves is the use of the term "continuous" when the author (probably) means "contiguous" - one sees this most often when discussing OSPF. Note, this book isn't unique in this mis-use of the term; there are many CCO documents that also make this "error." I'm assuming that this is the product of a spell-checker that didn't know the term contiguous, suggested continuous and someone hit "replace all." Before the flame-war starts, I know that these two words have *similar* meanings but in this case I - my personal opinion - think that contiguous is 'more right' - besides, it's the term used in the RFC. Since I'm picking nits; the author indicates that the OSPF process ID on a router should be thought of "as an Autonomous System ID. This number should be the same on all routers within the autonomous system." Per CCO, this is a locally significant setting used only to distinguish between multiple OSPF routing process on a particular router. If we were to apply the RFC2119 definition of "should" to this statement one might think that certain problems may occur if this practice wasn't followed. I don't believe this to be the case but I'm sure someone on the list will correct me if I'm wrong. There's nothing wrong with using the same process ID on all of your OSPF routers; I would guess that networks are configured that way more often than not; but isn't a requirement. Given that the lab exam is all about splitting hairs to the most minute detail and knowing the various protocols in depth, it probably should have been noted (as in other texts) that two adjacent routers can have different process IDs configured. There are some outright mistakes in the book - I just checked the CiscoPress site for an errata and didn't see one yet. Here one that I recall off the top of my head: EIGRP - (p.691) at the bottom of the page, the 'distance' command. - this is almost a direct copy/paste from the IGRP chapter; does not include the required information to change the admin distance of the EIGRP routing process (which requires both an internal and external distance); it only lists the syntax to change the distance of a specific neighbor's updates. I find it funny that the EIGRP chapter says "For a specific example and more practice with the 'distance' command, see" the IGRP chapter. When you look at the IGRP chapter, it uses the same sentence to point you to the RIP chapter. Anyone who has walked into an EIGRP network with multiple, unfiltered redistribution points into a RIP domain will know first-hand the importance of knowing how a router handles internal vs. external EIGRP routes. Additionally, I thought the section on PPP authentication could have used some more work on the one-way authentication options (both PAP and CHAP). Bottom-line, this seems to be a well written book; it gives you some good examples and labs to work on your own, etc. It won't replace any of the other "must haves" on the bookshelf (e.g. Doyle, Caslow, Thomas, etc.) and unfortunately, (as it seems with all of the books published these days) you have to play 'reporter' and verify the information in the book with some other source (CCO, RFCs, other texts) - this is a topic I could rant on for quite some time (considering the $thousands - literally - I've spent on training materials which contain errors). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 16, 2002 7:18 PM To: [EMAIL PROTECTED] Subject: OT: First Impressions - CCIE Practical Studies [7:32237] Just got my copy. Reading the "About the Authors" section alone is impressive. All those associated with the book are CCIE's. I look forward to discovering if there are any errors in the book. One would hope not, given the credentials of the writers and reviewers, one of whom was the Halifax Lab Proctor for several years. So far I have browsed all of the first chapter "The Key Components for Modeling an Internetwork" This chapter covers in good detail all those basic questions - the config register, configuring a router as a frame switch, password recovery, show and debug ( called "the big show" and "the big d" respectively, throughout the book. ) building a terminal server, and much much more. This alone tells me that this book might be a good investment for those just starting out, as well as those prepping for the CCIE Lab. Sure, all of this information is available elsewhere, but with this book, it is in one place, easily loc
RE: First Impressions - CCIE Practical Studies [7:32237]
At 12:21 PM 1/17/02, R. Benjamin Kessler wrote: >I have a couple of "nit-picky" complaints about the book (as I do about >almost every book I read). There are some typo's as a previous poster >indicated. One of my biggest pet peeves is the use of the term "continuous" >when the author (probably) means "contiguous" - one sees this most often >when discussing OSPF. That says that the author didn't look at the copy-edited material. New authors assume that publisher's copy editors have a clue. They don't. They apply rules for "fixing" words and sentences without any idea what they are doing. This means that you will probably find other minor mistakes in the book too. Don't blame the author, although the author should have been more careful during the final phases of the book project. Cisco Press copy editors once changed every case of Mbps to MByte in a book! In my book, in the index, they changed long fat network (LFN) to long file names. See RFC 1323 for the true meaning of elephant (LFN). Thanks for your thorough review of the book. Priscilla > Note, this book isn't unique in this mis-use of the >term; there are many CCO documents that also make this "error." I'm >assuming that this is the product of a spell-checker that didn't know the >term contiguous, suggested continuous and someone hit "replace all." Before >the flame-war starts, I know that these two words have *similar* meanings >but in this case I - my personal opinion - think that contiguous is 'more >right' - besides, it's the term used in the RFC. > >Since I'm picking nits; the author indicates that the OSPF process ID on a >router should be thought of "as an Autonomous System ID. This number should >be the same on all routers within the autonomous system." Per CCO, this is >a locally significant setting used only to distinguish between multiple OSPF >routing process on a particular router. If we were to apply the RFC2119 >definition of "should" to this statement one might think that certain >problems may occur if this practice wasn't followed. I don't believe this >to be the case but I'm sure someone on the list will correct me if I'm >wrong. There's nothing wrong with using the same process ID on all of your >OSPF routers; I would guess that networks are configured that way more often >than not; but isn't a requirement. Given that the lab exam is all about >splitting hairs to the most minute detail and knowing the various protocols >in depth, it probably should have been noted (as in other texts) that two >adjacent routers can have different process IDs configured. > >There are some outright mistakes in the book - I just checked the CiscoPress >site for an errata and didn't see one yet. Here one that I recall off the >top of my head: > >EIGRP - (p.691) at the bottom of the page, the 'distance' command. >- this is almost a direct copy/paste from the IGRP chapter; does not include >the required information to change the admin distance of the EIGRP routing >process (which requires both an internal and external distance); it only >lists the syntax to change the distance of a specific neighbor's updates. I >find it funny that the EIGRP chapter says "For a specific example and more >practice with the 'distance' command, see" the IGRP chapter. When you look >at the IGRP chapter, it uses the same sentence to point you to the RIP >chapter. > >Anyone who has walked into an EIGRP network with multiple, unfiltered >redistribution points into a RIP domain will know first-hand the importance >of knowing how a router handles internal vs. external EIGRP routes. > >Additionally, I thought the section on PPP authentication could have used >some more work on the one-way authentication options (both PAP and CHAP). > >Bottom-line, this seems to be a well written book; it gives you some good >examples and labs to work on your own, etc. It won't replace any of the >other "must haves" on the bookshelf (e.g. Doyle, Caslow, Thomas, etc.) and >unfortunately, (as it seems with all of the books published these days) you >have to play 'reporter' and verify the information in the book with some >other source (CCO, RFCs, other texts) - this is a topic I could rant on for >quite some time (considering the $thousands - literally - I've spent on >training materials which contain errors). > >-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, January 16, 2002 7:18 PM >To: [EMAIL PROTECTED] >Subject: OT: First Impressions - CCIE Practical Studies [7:32237] > > >Just got my copy. > >Reading the "About the Authors" section alone is impressive. All those >associated with the book are CCIE's. I look forward to discovering if there >are any errors in the book. One would hope not, given the credentials of the >writers and reviewers, one of whom was the Halifax Lab Proctor for several >years. > >So far I have browsed all of the first chapter "The Key Components for >Modeling an Internetwork" > >This chapter covers
Re: First Impressions - CCIE Practical Studies [7:32237]
It may also be that copy editors think that because it is tech, that what they see, although it does not make sense grammatically, does make sense to other techies. For a tech review I am currently working on, I had to specifically call the editor and tell him that the chapters were very poorly written, had lots of poor sentence construction, not to mention bad grammar, and that he should specifically be aware that the text made no sense no matter who was reading it. Hmmm... come to think of it, I haven't heard from those people lately. I wonder if they fired me? ;-> I suspect that in this mad rush to get tech books out the door, many of the publishing houses are operating under the assumption that whatever a tech writer writes is correct. Kinda like the emperor's new clothes? Can't be understood by a fool? Chuck ""Priscilla Oppenheimer"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > At 12:21 PM 1/17/02, R. Benjamin Kessler wrote: > >I have a couple of "nit-picky" complaints about the book (as I do about > >almost every book I read). There are some typo's as a previous poster > >indicated. One of my biggest pet peeves is the use of the term "continuous" > >when the author (probably) means "contiguous" - one sees this most often > >when discussing OSPF. > > That says that the author didn't look at the copy-edited material. New > authors assume that publisher's copy editors have a clue. They don't. They > apply rules for "fixing" words and sentences without any idea what they are > doing. > > This means that you will probably find other minor mistakes in the book > too. Don't blame the author, although the author should have been more > careful during the final phases of the book project. > > Cisco Press copy editors once changed every case of Mbps to MByte in a > book! In my book, in the index, they changed long fat network (LFN) to long > file names. See RFC 1323 for the true meaning of elephant (LFN). > > Thanks for your thorough review of the book. > > Priscilla > > > Note, this book isn't unique in this mis-use of the > >term; there are many CCO documents that also make this "error." I'm > >assuming that this is the product of a spell-checker that didn't know the > >term contiguous, suggested continuous and someone hit "replace all." Before > >the flame-war starts, I know that these two words have *similar* meanings > >but in this case I - my personal opinion - think that contiguous is 'more > >right' - besides, it's the term used in the RFC. > > > >Since I'm picking nits; the author indicates that the OSPF process ID on a > >router should be thought of "as an Autonomous System ID. This number should > >be the same on all routers within the autonomous system." Per CCO, this is > >a locally significant setting used only to distinguish between multiple OSPF > >routing process on a particular router. If we were to apply the RFC2119 > >definition of "should" to this statement one might think that certain > >problems may occur if this practice wasn't followed. I don't believe this > >to be the case but I'm sure someone on the list will correct me if I'm > >wrong. There's nothing wrong with using the same process ID on all of your > >OSPF routers; I would guess that networks are configured that way more often > >than not; but isn't a requirement. Given that the lab exam is all about > >splitting hairs to the most minute detail and knowing the various protocols > >in depth, it probably should have been noted (as in other texts) that two > >adjacent routers can have different process IDs configured. > > > >There are some outright mistakes in the book - I just checked the CiscoPress > >site for an errata and didn't see one yet. Here one that I recall off the > >top of my head: > > > >EIGRP - (p.691) at the bottom of the page, the 'distance' command. > >- this is almost a direct copy/paste from the IGRP chapter; does not include > >the required information to change the admin distance of the EIGRP routing > >process (which requires both an internal and external distance); it only > >lists the syntax to change the distance of a specific neighbor's updates. I > >find it funny that the EIGRP chapter says "For a specific example and more > >practice with the 'distance' command, see" the IGRP chapter. When you look > >at the IGRP chapter, it uses the same sentence to point you to the RIP > >chapter. > > > >Anyone who has walked into an EIGRP network with multiple, unfiltered > >redistribution points into a RIP domain will know first-hand the importance > >of knowing how a router handles internal vs. external EIGRP routes. > > > >Additionally, I thought the section on PPP authentication could have used > >some more work on the one-way authentication options (both PAP and CHAP). > > > >Bottom-line, this seems to be a well written book; it gives you some good > >examples and labs to work on your own, etc. It won't replace any of the > >other "must haves" on the bookshelf (e.g. Doyle,
Re: First Impressions - CCIE Practical Studies [7:32237]
Some publishers (including Cisco Press) have authors work with a development editor during the writing of the book. This is especially important for new writers or engineers who don't have very good writing skills. Cisco Press also has the writer work with technical reviewers as the writing is progressing. I realize I was critical of Cisco Press copy editing in my previous message, but, in general, their books are much better than the competition because they work in this mode (with development editors and technical reviewers). Some publishers, such as Wiley, won't let an author in the door unless the author has proven writing skills and technical expertise. That method works also. And then there are the publishers that just want to push content out there and start collecting s as quickly as possible. Their stuff tends to suck. ;-) Priscilla At 04:02 PM 1/17/02, Chuck Larrieu wrote: >It may also be that copy editors think that because it is tech, that what >they see, although it does not make sense grammatically, does make sense to >other techies. For a tech review I am currently working on, I had to >specifically call the editor and tell him that the chapters were very poorly >written, had lots of poor sentence construction, not to mention bad grammar, >and that he should specifically be aware that the text made no sense no >matter who was reading it. Hmmm... come to think of it, I haven't heard from >those people lately. I wonder if they fired me? ;-> > >I suspect that in this mad rush to get tech books out the door, many of the >publishing houses are operating under the assumption that whatever a tech >writer writes is correct. Kinda like the emperor's new clothes? Can't be >understood by a fool? > >Chuck > > >""Priscilla Oppenheimer"" wrote in message >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > At 12:21 PM 1/17/02, R. Benjamin Kessler wrote: > > >I have a couple of "nit-picky" complaints about the book (as I do about > > >almost every book I read). There are some typo's as a previous poster > > >indicated. One of my biggest pet peeves is the use of the term >"continuous" > > >when the author (probably) means "contiguous" - one sees this most often > > >when discussing OSPF. > > > > That says that the author didn't look at the copy-edited material. New > > authors assume that publisher's copy editors have a clue. They don't. They > > apply rules for "fixing" words and sentences without any idea what they >are > > doing. > > > > This means that you will probably find other minor mistakes in the book > > too. Don't blame the author, although the author should have been more > > careful during the final phases of the book project. > > > > Cisco Press copy editors once changed every case of Mbps to MByte in a > > book! In my book, in the index, they changed long fat network (LFN) to >long > > file names. See RFC 1323 for the true meaning of elephant (LFN). > > > > Thanks for your thorough review of the book. > > > > Priscilla > > > > > Note, this book isn't unique in this mis-use of the > > >term; there are many CCO documents that also make this "error." I'm > > >assuming that this is the product of a spell-checker that didn't know the > > >term contiguous, suggested continuous and someone hit "replace all." >Before > > >the flame-war starts, I know that these two words have *similar* meanings > > >but in this case I - my personal opinion - think that contiguous is 'more > > >right' - besides, it's the term used in the RFC. > > > > > >Since I'm picking nits; the author indicates that the OSPF process ID on >a > > >router should be thought of "as an Autonomous System ID. This number >should > > >be the same on all routers within the autonomous system." Per CCO, this >is > > >a locally significant setting used only to distinguish between multiple >OSPF > > >routing process on a particular router. If we were to apply the RFC2119 > > >definition of "should" to this statement one might think that certain > > >problems may occur if this practice wasn't followed. I don't believe >this > > >to be the case but I'm sure someone on the list will correct me if I'm > > >wrong. There's nothing wrong with using the same process ID on all of >your > > >OSPF routers; I would guess that networks are configured that way more >often > > >than not; but isn't a requirement. Given that the lab exam is all about > > >splitting hairs to the most minute detail and knowing the various >protocols > > >in depth, it probably should have been noted (as in other texts) that two > > >adjacent routers can have different process IDs configured. > > > > > >There are some outright mistakes in the book - I just checked the >CiscoPress > > >site for an errata and didn't see one yet. Here one that I recall off >the > > >top of my head: > > > > > >EIGRP - (p.691) at the bottom of the page, the 'distance' command. > > >- this is almost a direct copy/paste from the IGRP chapter; does not >include > > >the requi
Re: First Impressions - CCIE Practical Studies [7:32237]
>Some publishers (including Cisco Press) have authors work with a >development editor during the writing of the book. This is especially >important for new writers or engineers who don't have very good writing >skills. Cisco Press also has the writer work with technical reviewers as >the writing is progressing. Macmillan Technical Publishing, sister organization of Cisco Press, also uses development editors. In my case, it was an awful experience. The development editor constantly tried to rephrase things in a manner that changed meaning, even when the reviewers told her I was correct. I believe Cisco Press now has the option of working with, or not working with, a development editor. If the relationship can develop over time, it can also work out that authors with similar writing styles can trade reviews. I've done this with Galina Pildush and Jeff Doyle, variously at the chapter and book level. For people interested in eventually writing books, contacting the publishers and getting on the list of reviewers can be an excellent introduction to the process. > >I realize I was critical of Cisco Press copy editing in my previous >message, but, in general, their books are much better than the competition >because they work in this mode (with development editors and technical >reviewers). > >Some publishers, such as Wiley, won't let an author in the door unless the >author has proven writing skills and technical expertise. That method works >also. Wiley uses fewer technical reviewers than Macmillan, but they aren't the same kind of configuration-oriented books. The reviewer (an "advisor" when a Networking Council member) is more of a sounding board. Scott Bradner did this for my first Wiley book. For my second, Lyman Chapin started out as advisor but changed jobs and was unable to continue. Annlee Hines took over and was a tremendous help. I hadn't realized the proved writing, but I've been extremely happy working with Wiley. Since I'm going through copy edit on the new book (to ship in early April), I have to share something that had me in hysterics. In the book, I have a number of "running case studies." One is about a law firm, which I named "Huffle, Puffle, and Cetera." The copy editor carefully changed every reference to "Huffle, Puffle, etc." The managing editor giggled and put it back. > >And then there are the publishers that just want to push content out there >and start collecting s as quickly as possible. Their stuff tends to >suck. ;-) > >Priscilla > >At 04:02 PM 1/17/02, Chuck Larrieu wrote: >>It may also be that copy editors think that because it is tech, that what >>they see, although it does not make sense grammatically, does make sense to >>other techies. For a tech review I am currently working on, I had to >>specifically call the editor and tell him that the chapters were very poorly >>written, had lots of poor sentence construction, not to mention bad grammar, >>and that he should specifically be aware that the text made no sense no >>matter who was reading it. Hmmm... come to think of it, I haven't heard from >>those people lately. I wonder if they fired me? ;-> >> >>I suspect that in this mad rush to get tech books out the door, many of the >>publishing houses are operating under the assumption that whatever a tech >>writer writes is correct. Kinda like the emperor's new clothes? Can't be >>understood by a fool? >> >>Chuck >> >> >>""Priscilla Oppenheimer"" wrote in message >>[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... >> > At 12:21 PM 1/17/02, R. Benjamin Kessler wrote: >> > >I have a couple of "nit-picky" complaints about the book (as I do about >> > >almost every book I read). There are some typo's as a previous poster >> > >indicated. One of my biggest pet peeves is the use of the term >>"continuous" >> > >when the author (probably) means "contiguous" - one sees this most often >> > >when discussing OSPF. >> > >> > That says that the author didn't look at the copy-edited material. New > > > authors assume that publisher's copy editors have a clue. They don't. >They >> > apply rules for "fixing" words and sentences without any idea what they >>are >> > doing. >> > >> > This means that you will probably find other minor mistakes in the book >> > too. Don't blame the author, although the author should have been more >> > careful during the final phases of the book project. >> > >> > Cisco Press copy editors once changed every case of Mbps to MByte in a >> > book! In my book, in the index, they changed long fat network (LFN) to >>long >> > file names. See RFC 1323 for the true meaning of elephant (LFN). >> > >> > Thanks for your thorough review of the book. >> > >> > Priscilla >> > >> > > Note, this book isn't unique in this mis-use of the >> > >term; there are many CCO documents that also make this "error." I'm >> > >assuming that this is the product of a spell-checker that didn't know >the >> > >term contiguous, su
Re: First Impressions - CCIE Practical Studies [7:32237]
I must join the discussion and add some of my most recent experience here with Addison Wesley ;-) They used their external reviewer and I must say they chose him very well. I am sure I would not be able to do such a thorough review he did. Of course, I had quite a few peer (voluntary) reviewers which concentrated on their relevant parts only. However, these were the superb technical experts but without much writing experience. (Contrary to Howard, I think the good technical reviewer/editor should already have some books published to realize both that writing is hard work and that getting this work thoroughly reviewed is crucial). As for editors that is another story: I had one who did all the editing in one go. Not very funny thing was that although I supplied him immediately with replies to his queries after every set of pages he did, he did not look at them until after he reached almost the end of book! Which, as you may easily imagine, meant that he made consistent changes where they were not necessary or plain wrong. One mistake I will never do again is to rely that the editor will make any formatting consistent throughout the text. No, you have to do it despite of the fact that the final product will use something very different to what you suggested, but close to wished consistency, at least. But all technical and editing comments you get in the process are piece of cake compared to proofreading of your own text (!) having gone through the complex publishing house mill ... at the time you would really like to relax, eventually. Rita "Howard C. Berkowitz" wrote: > > >Some publishers (including Cisco Press) have authors work with a > >development editor during the writing of the book. This is especially > >important for new writers or engineers who don't have very good writing > >skills. Cisco Press also has the writer work with technical reviewers as > >the writing is progressing. > > Macmillan Technical Publishing, sister organization of Cisco Press, > also uses development editors. In my case, it was an awful > experience. The development editor constantly tried to rephrase > things in a manner that changed meaning, even when the reviewers told > her I was correct. > > I believe Cisco Press now has the option of working with, or not > working with, a development editor. > > If the relationship can develop over time, it can also work out that > authors with similar writing styles can trade reviews. I've done this > with Galina Pildush and Jeff Doyle, variously at the chapter and book > level. > > For people interested in eventually writing books, contacting the > publishers and getting on the list of reviewers can be an excellent > introduction to the process. > > > > >I realize I was critical of Cisco Press copy editing in my previous > >message, but, in general, their books are much better than the competition > >because they work in this mode (with development editors and technical > >reviewers). > > > >Some publishers, such as Wiley, won't let an author in the door unless the > >author has proven writing skills and technical expertise. That method works > >also. > > Wiley uses fewer technical reviewers than Macmillan, but they aren't > the same kind of configuration-oriented books. The reviewer (an > "advisor" when a Networking Council member) is more of a sounding > board. Scott Bradner did this for my first Wiley book. For my > second, Lyman Chapin started out as advisor but changed jobs and was > unable to continue. Annlee Hines took over and was a tremendous help. > > I hadn't realized the proved writing, but I've been extremely happy > working with Wiley. Since I'm going through copy edit on the new book > (to ship in early April), I have to share something that had me in > hysterics. > > In the book, I have a number of "running case studies." One is about > a law firm, which I named "Huffle, Puffle, and Cetera." The copy > editor carefully changed every reference to "Huffle, Puffle, etc." > The managing editor giggled and put it back. > > > > >And then there are the publishers that just want to push content out there > >and start collecting s as quickly as possible. Their stuff tends to > >suck. ;-) > > > >Priscilla > > > >At 04:02 PM 1/17/02, Chuck Larrieu wrote: > >>It may also be that copy editors think that because it is tech, that what > >>they see, although it does not make sense grammatically, does make sense to > >>other techies. For a tech review I am currently working on, I had to > >>specifically call the editor and tell him that the chapters were very > poorly > >>written, had lots of poor sentence construction, not to mention bad > grammar, > >>and that he should specifically be aware that the text made no sense no > >>matter who was reading it. Hmmm... come to think of it, I haven't heard > from > >>those people lately. I wonder if they fired me? ;-> > >> > >>I suspect that in this mad rush to get tech books out the door, many of the > >>publishing
