Chastise me with scorpions, lash me with octopus cables, crimp RJ45's
onto my ears.
Seriously, Chuck, "how to read an RFC" is not a simple answer. As I
answer you, I have to balance between several appropriate and
inappropriate viewpoints -- support, instruction, and product
developer.
Some generalities: start with the relevant IETF working group page
at http://www.ietf.org. The charter will give you a reasonable
overview. If any documents are called "applicability statement," read
them first. Those documents focus on the problem to be solved.
Next, look at any "framework," "requirements," "architecture," or
"roadmap" documents, which will give you a strategy for figuring out
what the detailed protocols are intended to do.
Then, look at specific protocol RFCs. They will very often have an
introductory part before they jump into the nuts and bolts of the
protocols.
>RFC2328 ( OSPF ver 2 ) almost done. Have modified my thoughts on it. Still
>seems to be a lot of repetition, but I believe I am beginning to appreciate
>the complexity of the protocol.
Some of the repetition is just inadequate editing, but what may seem
repetition can very well be the similar information presented from
different points of reference: master vs. slave, initialization vs.
continued operation, levels in a hierarchy, error recovery.
I'm not sure how good an example I am of how to read an RFC in the
support or certification contexts. As part of new product
development, which I can't talk about in any detail, I am indeed
looking at code. There's a great deal on which something like RFC2328
is silent or potentially misleading. In his new OSPF implementation
book, John Moy gives excellent examples of the difference between
specification and code implementation. See, for example, his
discussion of the Dijkstra algorithm on page 208. While RFC2328 says
certain database lookups will be done during the Dijkstra, code can
run faster if they don't. In John's code, these checks are done at
the time of receiving an LSA. The external behavior of the router is
identical.
>Seriously, for those of us browsing RFC's as part of our preparations, what
>is it we should be learning?
Typically, a protocol RFC has several relatively readable
introductory chapters, and then jumps into the protocol formats and
state machines. For the non-implementer, the value is often in those
early chapters, and, surprisingly, often in appendices that give
guidelines as to how to use the protocol timers, etc.
When it comes to reading the protocol details, I find it more useful
to have a question in mind and to research it by following concepts
through the RFC detail, rather than just sequentially reading the
detail. YMMV.
>
>As someone who probably will not be writing router code ever, at what point
>do I turn the page or just close it down entirely?
>
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
