I’m teaching a live webinar, How the Internet Really Works, next Friday on Safaribooks.com. You can register here. I’ve expanded this from a three-hour webinar to a four-hour webinar, which means I’m adding about 30’ish slides, and redoing a few bits and pieces of the presentation. In fact, I’m revamping a few of my webinars, creating two new ones, rebuilding two of them as livelessons, and working on some new material with Ethan as well.

Please join me this next Friday—first time with the new slides, so it should be interesting.

I am teaching a live webinar, How the Internet Really Works, on Safari Books Online on the 20th of March. I have expanded the material a bit, and plan to slow down a little, so it is now a four hour session. Generally, I start with DNS, then look at routing, then finally at organizations and other odds and ends. My general goal is for you have a broad overview of the technical bits, as well as an understanding of the costs and income streams of the major players. I will probably also discuss some of the current challenges facing the Internet, as I have a little bit more time, including the problems transit providers are facing and the general “centralization of everything” we are starting to see.

Webinar registration is available here.

My next course on Safari Books is a data center design webinar. I’ll talk about the history of the Clos fabric, fabric sizing with single-SKU designs, some of the pros and cons of single-SKU versus chassis based scaling, and underlay control planes. I generally go through these slides each time I give one of these webinars and rework various bits and pieces of it to smooth over things I remember being “rough” last time, and to update the material based on what I think is more relevant.

Sign up here.

Yep, it’s that time of year when everyone does “retrospective pieces…” So… why not? There were several notable events this year—first and foremost, I kicked off a new podcast called the Hedge for network engineers. It’s probably not going to make anyone’s “top ten list of must listen to podcasts” anytime soon (if ever), but it’s been a lot of fun to move out of the commercial podcast space and just talk about “whatever seems interesting.” The History of Networking podcast also became independent this year; we are chugging along at more than 60 episodes, and there are a lot of great guests yet to come.

On the personal front, I moved from LinkedIn to Juniper Networks, and made some progress at school. I have finished my coursework and passed my comprehensive exams, so I’m now a PhD candidate, or as it is more commonly known, ABD.

Rule11 has, as a blog, had a good year. The most popular posts were:

When deploying IPv6, one of the fundamental questions the network engineer needs to ask is: DHCPv6, or SLAAC? As the argument between these two has reached almost political dimensions, perhaps a quick look at the positive and negative attributes of each solution are. Originally, the idea was that IPv6 addresses would be created using stateless configuration (SLAAC).

We often hear about fabrics, and we often hear about networks—but on paper, an in practice, they often seem to be the same thing. Leaving aside the many realms of vendor hype, what’s really the difference? Poking around on the ‘net, I came across a couple of definitions that seemed useful, at least at first blush.

We all use the OSI model to describe the way networks work. I have, in fact, included it in just about every presentation, and every book I have written, someplace in the fundamentals of networking. But if you have every looked at the OSI model and had to scratch your head trying to figure out how it really fits with the networks we operate today, or what the OSI model is telling you in terms of troubleshooting, design, or operation—you are not alone.

BMP is described in RFC7854 as a protocol intended to “provide a convenient interface for obtaining route views.” How is BMP different from setting up an open source BGP process and peering with all of your edge speakers? If you peer using eBGP, you will not see parroted updates unless you look for them; if you peer using iBGP, you might not receive all the updates (depending on how things are configured).

An article on successful writers who end up driving delivery trucks. My current reading in epistemology for an upcoming PhD seminar. An article on the bifurcation of network engineering skills. Several conversations on various slacks I participate in. What do these things have in common? Just this: What is to become of network engineering?

For any field of study, there are some mental habits that will make you an expert over time. Whether you are an infrastructure architect, a network designer, or a network reliability engineer, what are the habits of mind those involved in the building and operation of networks follow that mark out expertise?

If you’re still confused about why this blog is called rule11, then you need to read this post.

Finally, just for fun… My family entered a gingerbread house competition in our town, and won. Now I can add “prize winning gingerbread house maker” to my resume, I suppose.

Keep watching this space, because there is plenty more to come in 2020.

A long while back now, Daniel Dib and I put together a collection of blog posts and new material, and released the collection as Unintended Features. Yes, this little book needs a serious update with more recent material, but … Anyway, after setting things up so you could purchase electronic copies on Amazon, things went well for a while.

Until Amazon decided I had violated the copyright on the material published on our blogs by republishing some of the same material in a book form. It’s not that anyone actually investigated if the copyright holders on the material were the same people, it was just assumed that the same material being in two different places at the same time must be a copyright violation. After I received the first take-down notification, I patiently wrote an explanation of the situation, and the book was restored. I received another take-down notice a week or so later, to which I also responded. And another a week or so after that, then two more on a single day a bit later, finally receiving a dozen or so on one day a month or two after receiving the initial notice.

At this point, I gave up. Unintended Features is no longer available on Amazon, though it is still available here.

What brought this to mind is this—I received another take-down notice today, this time for violating the copyright on a set of slides I shared on Slideshare. Specifically, an old set of slides for a presentation called How the Internet Really Works. It might be useful to recount some of the history of this presentation to give a sense of the situation.

When I worked for Verisign Labs, I was asked to create a set of slides that could be used to explain the importance of the DNS and generally how the Internet really works for various uses. I built the slide set, used it a couple of times, and then kind-of put it on the back shelf. After some time, I doubled the length of the presentation and gave it at conference. Some other folks, most notably Alvaro Retana, used a modified set of slides based on the originals to present in several places. Since then, I’ve created several versions of these slides, mostly a half an hour to an hour in length. I have the original version I developed at Verisign sitting around, as well as a version I developed while at E///, and versions I developed for several conferences.

Most recently, I’ve developed a three hour version which I present every six months or so as a live webinar over on Safari Books Online through Pearson. I update this version regularly (every six months, in fact), to account for feedback from past presentations of this material, new developments, etc. It has become packed enough that I will probably need to make this a four hour webinar in the next iteration. The quantity of information is so different that these two versions of this presentation are only related in their general outline and some common slides.

What is odd, to me, is that someone, or some system, has apparently flagged that older one hour version of the presentation as a copyright violation against some later recording. I’m being called out for copyright infringement against material I originally developed, and many people have picked up on and used in a lot of different places. This shorter version of the presentation, or ones similar to it, have been recorded and presented many different times, by different people; I doubt the concept of “copyright” against the slides (as opposed to some specific recording) holds much water. Yes, there is a difference between copyrighting a recording of a presentation and the slides used in the presentation. They are two separate works, and you can intentionally maintain the copyright on one while not maintaining the copyright on the other.

As a content creator, I’m all for copyright and protecting copyright. But in this case, there is no copyright violation I can figure out. And yet, there is no way for me to effectively argue against this sort of take-down notice. I can respond, but there is more than one notice—they are already piling up in my inbox, threatening me with legal action if I do not remove this set of slides. Each notice will require some amount of my time, and once these notices begin, experience tells me they will not end. Instead, they will pile up like that woeful pile of paper sitting in the corner of that little table that I really need to get around to looking at, but probably never will.

What I’m going to do, at this point, is pull all my presentations off Slideshare—there’s no point in using a system that won’t tell me who has complained, nor give me any real way to address the issue with a permanent solution. Most of the presentations I have uploaded there are really old anyway. Instead, I will probably upload some shorter presentations I’ve used in a lot of places over the years here on rule11.tech for folks to use for reference and to draw from for their own presentations.

But I’m not going to argue with an automated system that does not, will not, understand what is actually going on. Automating poorly thought-out systems almost never produces a good result. Taking shortcuts in the way things should work because the shortcut is easier to automate is always a bad idea. A fool with a tool is just a faster fool.

I don’t know when we are going to learn these lessons, but they are worth learning.