Re: Core Knowledge - Don't mis-interpret this

Well said, and I agree.

The questions should not focus on minutia, but they also should not be too
broad either. As I mentioned in a previous post some questions could have
five different arguably correct answers. If the grading proctor only
subscribes to one of these answers as being acceptable, then the other
four will be marked wrong. Without an appeal process providing a re-read
option, or conducting additional oversight (ie. have at least two proctors
grade every OEQ section), the OEQs are going to remain controversial.

-Josh

On Wed, Apr 22, 2009 at 10:14 AM, Scott Morris <
smorris_at_internetworkexpert.com> wrote:

> I've posted a few times about this already (not RFC's, but answer
> formats), but we'll take a slightly different perspective here...
>
> An answer can take on entirely different meaning depending on HOW you
> answer it. As a quick example, since I have a dissenting opinion
> here... Had I simply responded to the message with "You are wrong." and
> that was it, what would your reaction have been? Quite colorful I'm sure.
>
> Instead, to lay out a scenario about WHY I believe you are wrong and
> here are some potential examples can be much better where you don't
> simply write me off as being clueless. The Core Technology questions
> aren't much different. You have a half-hour to answer four questions.
>
> They shouldn't be viewed as one-word answers. View them as 2-3 sentence
> answers.
>
> Your customer asks "What's up with private addresses?". You could
> answer "RFC1918" and walk away. What's their reaction? Elaborate.
> Don't write a book about it, but elaborate.
>
> If you come up with an RFC number and just some summarization about why
> it's the answer, or some quip about the latest revision, or part of a
> long string of RFCs or something more useful than just a number, it may
> signify that you know something about it as opposed to simply being a
> potentially memorized trivia nugget.
>
> If someone asks about the IP address of Google, even if I DID know it
> (which I do not in case you cared), I would elaborate about how to look
> it up, and probably say something about a company the size of Google
> will most likely have multiple web servers eithe hiding behind a load
> balancer with a single IP, or more likely having a group of IPs in a
> round-robin DNS in order to distribute the obviously massive load of web
> requests throughout the day and not stress out any particular router,
> switch or server along the way.
>
> Trivia vs. clueful.
>
> HTH,
>
> Scott
>
>
> George Roman wrote:
> > Paul do not want to be rude but to learn RFC numbers does not define you
> as
> > an expert (unless you are out of your mind or have to much free time)
> > knowing those numbers does not meen that you know what is inside the
> > document itself.
> > To me it is like you learn ip numbers by hard just in case. BTW do you
> know
> > the ip address of google ? i guess you are using it every day but you
> never
> > wandered.
> >
> > Best regards,
> > George
> >
> > On Wed, Apr 22, 2009 at 12:02 PM, Paul Cosgrove <paul.cosgrove_at_gmail.com
> >wrote:
> >
> >
> >> Hi Salah,
> >>
> >> Asking a small number of simple questions about common RFCs does not
> strike
> >> me as unfair.
> >>
> >> Will most customers be interested in them, no. Will they be interested
> in
> >> interoperability, yes. RFCs are developed to provide a common
> understanding
> >> of how protocols should operate. They are the authoritative source for
> what
> >> behaviour should be, and vendor specs refer to them to explain what
> their
> >> products can do. If you are familiar with common RFC numbers, and what
> they
> >> represent, then you will understand product specs more quickly and can
> >> understand their differences and limitations. If you want to check to
> see
> >> if a feature is supported by multiple vendors, you can either check
> through
> >> all the vendors product docs for every tiny detail, or you can check to
> see
> >> if they support the RFC.
> >>
> >> There are obviously a huge number of RFC, and I would have thought most
> >> people are (and should be) familiar with a small number; particularly
> those
> >> related to ingress filtering, private addresses and some of the more
> common
> >> routing protocols RFCs. Many text books were written based on old RFCs
> >> which have since been updated. If your studies are based on only
> reading
> >> old books you may achieve a good understanding of old protocol behaviour
> and
> >> terminology, but little understanding of how it has changed and how it
> >> currently operates. Familiarity with a few common RFCs, and their key
> >> differences, may also suggest that someone has really studied the topic
> in
> >> detail rather than focusing their studies on simply producing configs
> for
> >> the lab, perhaps not gaining a good general understanding in the
> process.
> >>
> >> Quite apart from their use as a reference of what behaviour is like now,
> >> RFCs also define new proposed protocols. They are a good indication of
> which
> >> areas are the focus of current research, and the direction in which the
> >> industry is moving. You wouldn't expect someone to know about cutting
> edge
> >> technologies for the lab, but they can be interesting and good for your
> >> general knowledge.
> >>
> >> Paul.
> >>
> >>
> >>
> >> Salah ElShekeil wrote:
> >>
> >>
> >>> RFCs?!?i
> >>>
> >>> On Wed, Apr 22, 2009 at 10:56 AM, Paul Cosgrove <
> paul.cosgrove_at_gmail.com
> >>>
> >>>> wrote:
> >>>>
> >>>
> >>>
> >>>> Hold times are very important. Customers often ask about failover.
> How
> >>>> long will it take? Well it largely depends on your hold time, since
> that
> >>>> often determines how long it takes to detect the failure.
> >>>>
> >>>> Paul.
> >>>>
> >>>>
> >>>> Salah ElShekeil wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> Agree with u Mohammed, or rfc#, what it will add to my knowledge!!!!!
> >>>>> nothing,
> >>>>>
> >>>>> It s a networking lab exam not a history exam.
> >>>>>
> >>>>> On Wed, Apr 22, 2009 at 9:46 AM, Mohamed El Henawy <
> m.henawy_at_link.net
> >>>>>
> >>>>>
> >>>>>
> >>>>>> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>> i don't think customers ask about hold time :)
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> ----- Original Message ----- From: "Pavel Bykov" <
> slidersv_at_gmail.com>
> >>>>>> To: "Joseph L. Brunner" <joe_at_affirmedsystems.com>
> >>>>>> Cc: "Larry" <cc13lab_at_gmail.com>; <ccielab_at_groupstudy.com>
> >>>>>> Sent: Wednesday, April 22, 2009 7:20 AM
> >>>>>> Subject: Re: Core Knowledge - Don't mis-interpret this
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> I think Cisco may have wanted to simulate customer environment.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> When I visit a customer, they ask some questions and they do expect
> >>>>>>> answers.
> >>>>>>> If I give them the correct answer, they ask a few more and if it's
> all
> >>>>>>> correct answers they want me to look at this and that is basically
> >>>>>>> living
> >>>>>>> up
> >>>>>>> to the reputation of CCIE. The customer wants to do business
> because
> >>>>>>> of
> >>>>>>> supplier knowledge. They see what they pay for.
> >>>>>>>
> >>>>>>> On the other hand, if you answer your customer, don't know and that
> >>>>>>> you
> >>>>>>> have
> >>>>>>> to look it up, well... If the customer thinks it's just a simple
> >>>>>>> question
> >>>>>>> that you should have known, maybe that will be the missed
> opportunity
> >>>>>>> for
> >>>>>>> huge projects.
> >>>>>>>
> >>>>>>> That's why I think Cisco puts only a few questions in.
> >>>>>>>
> >>>>>>> Pavel
> >>>>>>>
> >>>>>>>
> >>>>>>> Blogs and organic groups at http://www.ccie.net
> >>>>>>>
> >>>>>>>
> >>>>>>>
> _______________________________________________________________________
> >>>>>>> Subscription information may be found at:
> >>>>>>> http://www.groupstudy.com/list/CCIELab.html
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> Blogs and organic groups at http://www.ccie.net
> >>>>>>
> >>>>>>
> _______________________________________________________________________
> >>>>>> Subscription information may be found at:
> >>>>>> http://www.groupstudy.com/list/CCIELab.html
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> Blogs and organic groups at http://www.ccie.net
> >>>>>
> >>>>>
> _______________________________________________________________________
> >>>>> Subscription information may be found at:
> >>>>> http://www.groupstudy.com/list/CCIELab.html
> >>>>>
> >>>>>
> >> Blogs and organic groups at http://www.ccie.net
> >>
> >> _______________________________________________________________________
> >> Subscription information may be found at:
> >> http://www.groupstudy.com/list/CCIELab.html
> >>
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Wed Apr 22 2009 - 11:08:24 ART