The RFC Process

I’ve just finished a seven-part series over at Packets Pushers about the process of writing and publishing an RFC. Even if you don’t ever plan to write a draft or participate in the IETF, this series will give you a better idea of the work that goes into creating new standards and IETF documents.

So … you have an idea you think would fit perfectly into the realm of the Internet Engineering Task Force (IETF)—but where do you start?

This, the second, post, will consider document formatting and two of the (sometimes) more difficult sections of an IETF draft to fill in.

There are other seemingly mystical concepts in the IETF process as well—for instance, what is a “document stream,” and what is a document’s “status?”

You’re almost ready to submit a shiny new document to the IETF for consideration, right? Not quite yet—we still need to deal with mandatory sections and language.

You cannot simply post a draft to the IETF repository and expect “someone, somewhere,” to take action.

The working group chairs asked if your draft should become a working group item, and the consensus was to accept! It might seem like your draft is home free at this point—but there is still a lot of work to do.

Once the draft is written, socialized, accepted by a working group, and passes through the IESG telechat and review, what is next?

Hedge 206: Taking Care of Yourself with Ethan Banks

As we reach the end of what has been a hard two-year stretch for what seems like the entire world, Ethan Banks joins Tom, Eyvonne, and Russ to talk about the importance of taking care of yourself. In the midst of radical changes, you can apply self-discipline to make your little part of the world a better place by keeping yourself sane, fit, and well-rested.

 

 

download
 
transcript

Hedge 205: Old Engineering Books (2)

For this month’s roundtable, Eyvonne, Tom, and I return to Addresses to Engineering Students by Harrington and Waddell. This book, published in 1912, is a “product of its time,” and hence deserves some trigger warnings. But it is also interesting to see how advice given to engineering students over 100 years ago holds up for today. Have engineering challenges, and the engineering life, changed all that much? What kinds of advice stand the test of time, what kinds do not?

 

download
 
transcript

Upcoming Pearson Class: Modern Network Troubleshooting

On the 26th of January, I’ll be teaching a webinar over at Safari Books Online (subscription service) called Modern Network Troubleshooting. From the blurb:

The first section of this class considers the nature of resilience, and how design tradeoffs result in different levels of resilience. The class then moves into a theoretical understanding of failures, how network resilience is measured, and how the Mean Time to Repair (MTTR) relates to human and machine-driven factors. One of these factors is the unintended consequences arising from abstractions, covered in the next section of the class.
The class then moves into troubleshooting proper, examining the half-split formal troubleshooting method and how it can be combined with more intuitive methods. This section also examines how network models can be used to guide the troubleshooting process. The class then covers two examples of troubleshooting reachability problems in a small network, and considers using ChaptGPT and other LLMs in the troubleshooting process. A third, more complex example is then covered in a data center fabric.

Register here.

Hedge 202: Internet Governance with George Michaelson

How is the Internet governed? Who sets the rules for the Internet, civil society, and government control? How much input should techies have, and how much should government control things? These are questions we don’t often ask, and yet are crucial to building and operating networks connected to the global Internet. George Michaelson joins Toms and Russ to talk about Internet governance—including contrary views of where things should be versus where they are.

download