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

Well...here we have the actual lab portion and the theory about the items in
the blueprint. I am the first to tell you that RFCs don't mean that much
because you have to see how this vendor has implemented that particular RFC.
BUT reading the RFCs can help the theory section, but i don't think they are
saying that you should read and memorize every RFC under the sun, just focus
on the ones stated in the Blueprint, or may be instead of reading the RFCs
focus on reading the doc CD, read the sections that are mentioned in the
Blueprint. That will help you understand the theory and it will be a GR8
help in the lab portion as well.
But don't go focusing 2 much on the Core section, don't forget the lab
portion.

On Wed, Apr 22, 2009 at 7:25 AM, Cyrus <cyrus.mgh_at_gmail.com> wrote:

> Hey folks,
>
> At the end of the day, memorizing RFCs and holdtimes is not what experts
> call for. Docs are there for referencing.An expert must know concepts that
> able him to analyze problems and refer to docs for things like numbers,
> formats, standards, u shouldn't have these stuff off the top of your head.
>
> This is my point of view of an expert.
>
>
> Cyrus
>
> On Wed, Apr 22, 2009 at 10:31 PM, Paul Cosgrove <paul.cosgrove_at_gmail.com
> >wrote:
>
> > Hi George,
> >
> > I completely agree that knowing an RFC name (and purpose) does not make
> you
> > an expert, and that was not a point I put forward. My point there was
> > simply that:
> >
> > Asking a small number of simple questions about common RFCs does not
> strike
> > me as unfair.
> >
> > Does knowledge of RFCs help you meet other peoples expectations of an
> > expert? I would say so.
> >
> > RFCs are authoritative information sources. The features, books, and all
> > other training material are based on simplified interpretations and
> > explanations of them (which may or may not be accurate). An expert
> might
> > not be expected to know everything about a topic, but may be expected to
> > know where to look. Knowing which RFCs define a protocol could be seen
> that
> > way, they show that you know where to look for more details. Actually
> > reading those documents tells you what the standard, multivendor
> definition
> > of the protocol is, which, combined with a knowledge of the way cisco
> > implement that protocol tells you which aspects of the implementation are
> > proprietary, and where issues may occur with other vendors equipment.
> >
> > The multiple google IPs on the other hand are transient, and do not in
> > themselves represent any specific information. Google will return
> multiple
> > results when you perform a search, and depending on which you select you
> may
> > read old information (e.g. outdated RFCs). Old RFCs do not indicate
> which
> > RFC supercedes them, so if you don't know the correct one already your
> > google search may take you down the wrong path.
> > Google IPs facilitate a service you may use to find information when you
> > only have a basic understanding of where to look. RFCs are the actual
> > authoritative documents which define a protocol, so talking about an RFC
> > conveys a meaning which is well understood in the industry. They are
> > commonly referred to in product specs and presentations, so even if you
> do
> > not use them as a reference source yourself, knowing what protocols the
> more
> > common ones define is really quite useful.
> >
> > Paul.
> >
> >
> >
> > 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
>
>
>
>
>
>
>
>

-- 
Narbik Kocharians
CCSI#30832, CCIE# 12410 (R&S, SP, Security)
www.MicronicsTraining.com
www.Net-Workbooks.com
Sr. Technical Instructor
Blogs and organic groups at http://www.ccie.net