On the ‘net: Networking Models

I’m writing a series on network models over at Packet Pushers; links to the first three are below.

Looking back at my career in network engineering, beyond some basic concepts and naming conventions, I cannot remember using the OSI model once. I have used the concept of layering, but never the OSI model specifically.

First, models are not sacrosanct. A model is just a tool. If the model you are using is not working for you, feel free to modify it. I find simpler yet extensible models far more effective than complex models for channeling my thoughts. In the past I have tried building huge models that “put everything in one place,” but they do not work for me.

How does a host differ from a middlebox? Hosts are designed to run applications that create and consume packets rather than quickly forwarding traffic through the network. The primary difference is that the source and destination are not two different ports on the same device but rather a virtual interface representing an application and a physical interface.

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?

On the ‘net: Two on AI

I occasionally write over at Mind Matters on topics “other than technical.” Here are my two latest posts over there.

But what if you could steal something just as valuable as the contents of a lady’s handbag without anyone suspecting it and without impacting your user’s trust? What if you could take private information about millions of people, across the world, using that information to create what Shoshana Zuboff calls “behavioral surplus?” What if you could use that information to discover — and shape — people’s preferences without them even realizing it is happening? What if you could sell your user’s attention to the highest bidder?

While it seems evident that content created by a user prompt should not be copyrightable by the user, what about the designer and operator of the AI system? It might seem reasonable to infer the humans who create a system that, in turn, creates new “works” should be able to copyright those works.

On the ‘net: Network Models at Packet Pushers

I’ve just started a new series on network models over at Packet Pushers. The first two installments are here:

I learned the Open Systems Interconnect (OSI) model way back in the mid-1980s, as a part of my basic networking education. Ever since then, I’ve used the OSI model in my day-to-day work as a network engineer.

First, models are not sacrosanct. A model is just a tool. If the model you are using is not working for you, feel free to modify it.