How to keep up with internet and telecom standards

I read a lot of internet and telecom standards news because we make a free monthly roundup on it. It's a field where a decision in one working group can matter to an engineer somewhere else, and it's hard to follow every mailing list and meeting.

The short answer: keep a short list of sources for the parts you work on, check them at a regular time, and separate published specifications from drafts, study work and discussion. Most of this guide is about why that takes some care, and the ways people usually do it.

Why is internet and telecom standards hard to keep up with?

The news comes from several kinds of source. There are published RFCs and Internet-Drafts, IETF working group decisions, and 3GPP plenary reports. There are also implementations, interoperability results and regulatory moves that cite a standard. Each source tells you something different, and none gives you the whole picture.

Look at September's roundup. 3GPP RAN#113 kept Multi-RAT Spectrum Sharing as the 6G migration baseline but deferred further options to December. The ACME working group proposed proof of possession without a CSR for some clients. RFC 10041 changed how OSPF can mark a link that should not enter the default SPF calculation. A draft proposed HTTP status 419, Purpose Declined, for some refusals of speculative requests. A 6G overview from one6G also set out the technologies and open research questions.

The status of a piece of work matters as much as its subject. The ACME proposal is an initial Internet-Draft, and the HTTP status code is still a draft, so neither sets settled behaviour. The 3GPP work moved one set of choices forward while sending other migration options to a later meeting. A roundup needs to say what changed without making moving work sound final.

How do people usually keep up?

Most people use some mix of these:

• Newsletters. Good for a short overview of RFCs, working groups and telecom decisions, because somebody else has done the selecting. The catch is that a general list may miss the protocol or release work you actually implement.
• Journal alerts and preprint feeds. Useful for research around routing, radio systems, security and network architecture. They are less useful for working group decisions and can leave you with a lot to sort before you know what affects a specification.
• Podcasts. Easy to fit into a commute, and good for hearing why a change matters. Less good when you need the exact RFC, draft name, metric or status to check later.
• Conferences and meetings. The best way to hear what people are working on and where a disagreement sits before the text is settled. They only happen at particular times, and a meeting discussion is not the same thing as an approved specification.
• Colleagues and communities. Often how a useful mailing-list decision or implementation detail reaches you. It works until the person who normally spots those things is busy, and it can pass along an interpretation without the source.

None of them covers everything, so most people end up with a patchwork.

What tends to work

• Keep the list short. Three or four sources for the standards and systems you work on are better than fifteen you feel guilty about. If one hasn't given you anything useful in a month, drop it.
• Pick a time. Fifteen minutes on the same day each week works better than checking every mailing list whenever you have a spare moment. A monthly pass can work for slower areas, but active drafts need a closer look.
• Write one line when you save something. Say whether it is a published RFC, an Internet-Draft, a working group decision or a study item, and why it matters to your implementation. A bare link rarely gets looked at again.
• Go back to the source for anything you'll act on. A summary can tell you that a protocol or release changed. For the exact requirement, status and caveat, read the RFC, draft or official meeting document.

That's most of it. It takes discipline, especially when the work is spread across protocol groups, radio standards and adjacent bodies.

One more option

This is why I built Iris. You describe your work in your own words, something like "I implement QUIC and HTTP infrastructure and need to follow IETF drafts, RFCs and 3GPP work that affects transport", and each month it reads across the field and writes you a briefing on what changed for you, with every source linked so you can check anything yourself.

It's one option, and a good routine with a few focused sources works well too. If you want to see what a briefing looks like first, our free monthly podcast, Keeping up with Internet and Telecom Standards covers the month's biggest stories in about five minutes, with the written report and every source underneath. When you'd like one built around your own work, you can set up your own briefing.

If you work on internet or telecom standards and think I've missed something, I'd like to hear about it: joe@irisbriefings.com.