A few quick comments: 1) I would like to see some scenarios that are short. Although it's important to give people a chance to simulate the real day-long lab, a lot of people would probably want to try some shorter labs first.
2) Hints should be hard to get at. It's human nature to cheat if it's easy. 3) I couldn't figure out how to download scenarios. I thought maybe it was because I logged on as an author. So I made myself a normal account. I found a few scenarios and did Add to My Scenarios, but I didn't know what to do next. In general, the Web site is hard to figure out. Priscilla At 11:21 AM 4/19/02, Howard C. Berkowitz wrote: >I'd like to start a discussion on the design of two kinds of scenarios: > 1. lab preparation. (problem recognition, speed building, > interaction among many protocols, time pressure, etc.) > 2. In-depth understanding of protocols (seeing the effects of > alternative configurations, learning how to solve specific > problems with specific technologies). Pure tutorials on > technologies complement these hands-on experiences. > >The two requirements, of course, are not mutually exclusive. #3 are >scenarios that either statically or dynamically switch between the >modes. > >It is my hope that this will stimulate community discussion involving >both people who use scenarios and people who write them. > >Now, a disclaimer: I work for Gettlabs and Gett Communications, the >former of which runs a virtual rack service. Gettlabs itself uses an >open-source model for its own scenarios, as does Fatkid and some >others. Gettlabs has partnerships with IPexpert and >CertificationZone, which sell scenarios and supplemental materials. >My comments here are intended to be neutral, and I will listen, learn >and share with competitors. I have discussed my intentions with Paul >Borghese, and one of our agreements is that this is eligible to stay >off the commercial list as long as I make free scenarios available. > >1. Lab Preparation >------------------- > >Above all, these have to prepare you for pressure and ambiguity. > >A fairly basic question: should all lab preparation scenarios be of >8-plus hour length, or two four-hour segments (forcing the disruption >of a lunch break)? Alternatively, is it acceptable to have sets of >sub-scenarios that build on one another, so you can practice for an >amount of time you have available, then pick up later on? > >I think it's a given that all you should be given is the addressing, >etc., in the one day lab, plus instructions on what you should do, >restrictions (e.g., no statics), and some criteria for judging >success. Estimated completion times/points also are important. > >An interesting question, however, is whether the scenario should >include some of the sorts of things where it is fair (based on >non-NDA statements of Cisco policy and the variations in proctors) to >ask a proctor a question. Should such points include things where >variously the proctor will and will not answer, or even, in marginal >cases, flip a software coin to see if the proctor will answer)? > >I believe it's realistic to be able to see a solved configuration, >but, when you see it, you either should have demonstrated successful >operation or accepted that you will accept losing points to be able >to go on. > >I do not think that hints are appropriate in a lab preparation >scenario, with the caveat that this sort of thing is quite >appropriate to technology learning, and, as I suggested in #3 above, >scenarios could be developed (possibly with a specific execution >engine) that let you switch between preparation and learning modes, >and even back. > >2. Technology Learning >----------------------- > >My general approach to designing such things is again to start with >instructions, initialization, etc., but to break the exercise into >relatively small steps. Each step will have hints available, and >will be fairly small so you can look at the successive changes to the >configuration that move you closer to your goal. > >One difference comes with the physical presentation of the scenario. >If it is a printed document, should the hints be in-line with the >text, or in a separate section so you will use them only if needed? >If the latter, should they be on separate pages or at least have >significant "spoiler space" between them so you don't inadvertently >get an unfair clue to what is coming next? > >If the scenario is running interactively, should hints and hint >answers only be available with a specific user action (clicking a >link, opening a file, etc.)? > >What backup materials should be available for technology learning >scenarios? Is a bibliography necessary, and is it adequate? Should >there be actual tutorials available? > >Should learning scenarios routinely contain show command outputs as >well as solved configurations, or should they simply suggest which >show commands to use and what to look for in their output? There >will always be, of course, specific cases where the full display is >appropriate. > >--------- semi-commercial but free content follows ---- >First examples: > There are several beta-version downloadable scenarios, which >contain some interactive links, at the www.gettlabs.com site. I am >not completely happy with the display formats, and these will change. >The only conditions for their use are: > 1. They are copyrighted, but carry an automatic license for personal > use by the person downloading. > 2. They may not be used commercially without Gettlabs written >permission. > This includes both classroom and distance learning/virtual rack. > 3. We ask that you do not send copies to others, but that each person > download their own copy. The simple reason for this is that the > scenarios are in frequent update and we want to be sure people get > the most recent version. > > You are not required to run these on our racks, but, of course, >we'd like you to. Some scenarios may depend on traffic generators and >such which are not part of the scenario, but of the overall execution >environment. > >Second examples: > I am actively putting together an FTP server that will have more >scenarios, but initially will not be in pretty format but in lots of >separate files. While we experiment with display formats, this >allows me to keep hints, solved configurations, etc., separate. This >server should start being available early next week. > This server will also have downloadable copies of lots of >presentations of mine from NANOG, the IETF and IRTF, ARIN, etc., as >well as other recommended reading. There will be some subdirectories >labeled "working" that contain documents actively being worked on by >teams/committees, and these may not make sense to anyone other than >the coauthors. > Some of these presentations may be a little old, and I'll be updating >them. > Warning, with half a smiley: my ISIS tutorial may carry a curse. >I tried to present it at NANOG twice. The first time, I came down >with a flu bug that had me down for a good six weeks. The second >time, I had to have a cardiac pacemaker installed the day it was to >have been presented. You Have Been Warned. There May Be Things That >Man Is Not Meant To Read. (or, as a bumper sticker some will >recognize says, "Vote for Cthulhu. Why settle for the lesser of two >evils?") > > > >-- >"What Problem are you trying to solve?" >***send Cisco questions to the list, so all can benefit -- not >directly to me*** >******************************************************************************** >Howard C. Berkowitz [EMAIL PROTECTED] >Chief Technology Officer, GettLab/Gett Communications http://www.gettlabs.com >Technical Director, CertificationZone.com http://www.certificationzone.com >"retired" Certified Cisco Systems Instructor (CID) #93005 ________________________ Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=41993&t=41955 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
