Exactly. A technology learning scenario might benefit from having hints and suggestions there for you. A lab scenario should have no explanation whatsoever in the scenario itself, it should be just as vague as the real thing. At the end of the scenario though, in the solution, I would definitely benefit from an explanation of why a particular method was used, I believe others would too.
~-----Original Message----- ~From: Howard C. Berkowitz [mailto:[EMAIL PROTECTED]] ~Sent: Friday, April 19, 2002 5:25 PM ~To: [EMAIL PROTECTED] ~Subject: RE: Scenario Design: Comments Invited [7:41955] ~ ~ ~At 5:00 PM -0400 4/19/02, Lupi, Guy wrote: ~>The biggest problem I have with scenarios out there is that ~the solutions ~>are not explained in enough detail. I suppose something ~could be said about ~>the requirement to then go look up a particular command and learn it ~>yourself, but part of the reason you have the scenarios is so ~that you can ~>learn. Nothing irritates me more than to go through a lab, ~look at the ~>solution and find that the author solved it in a completely ~different manner ~>than you did, with no explanation. This is especially ~important when there ~>is more than one way to come to a working solution. A lot of ~times there is ~>a perfectly valid reason to use the method in the solution, ~but the reasons ~>are sometimes very hard to see, especially if you are not ~well versed in the ~>technology. Some scenarios could be significantly improved ~if they gave the ~>reason behind a particular method used. ~ ~Excellent point. There is utterly no question you are right for ~technology learning scenarios. As far as lab practice scenarios, ~however, there's been a tendency in commercial labs not to do so, ~because Cisco doesn't do so. Perhaps more correctly, Cisco doesn't ~do so any more, with the one-day format. ~ ~Would you agree that this sort of explanation should be done only at ~the very end of the lab, as distinct from "hints" that may be ~available during the scenario? ~ ~Let me throw out an example and see if it's a way of approaching it. ~I've written three scenarios, each of which has the same first step: ~establishing BGP connectivity to two POPs of the same ISP. ~ ~Next, you are directed to implement load sharing, with certain of the ~address space preferring each POP. There are three variants, ~deliberately being a bit vague in the instructions. ~ ~One says, for example,."you cannot use any method that adds addresses ~or manipulates AS information." In other words, I expect the student ~to know that a MED is the only general option remaining (ignoring ~ISP-specific communities). ~ ~Another says "you may not manipulate addresses or metrics." It's ~looking for AS path prepending. ~ ~The third is written to look for more-specific and summary addresses. ~ ~I've set up hints in each one, which really say the same thing...the ~hints are multiple levels of questions, only giving a specific answer ~at the end. By the time you are through the hints, you will have ~reviewed the three possible options. ~ ~ From what you are saying, it sounds like a technology-learning ~scenario would do well with the hints, but a lab-practice scenario ~should simply consolidate these explanations at the end. Is that a ~fair interpretation? ~ ~Thanks, ~ ~Howard ~ ~ ~ ~ ~Report misconduct ~and Nondisclosure violations to [EMAIL PROTECTED] ~ Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=42028&t=41955 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
