Howard, you, Sir, are to be commended for this post, and for inspiring the discussion that has followed. I've been monitoring the list and the moderator's queue all day. Not a post hit the queue during the height of this thread. I guess folks were too busy reading ( and rereading ) your post, and the intelligent and thoughtful responses.
It is not often that such a great thread comes along. Kudos to everyone who participated. This continues to be an inspiring read. Chuck ""Howard C. Berkowitz"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > 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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=42064&t=41955 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
