My 42nd RFC has been published and it got the number RFC 8342. Despite the funny number, I believe this is one of the more important RFCs I have worked on since it tells us how to think about configurations and their relationship to operational state. A few more RFCs will appear during the coming weeks providing the technology extensions that allow us to use the new framework in practice. Work on this document started with a trip to Stockholm in 2016 but the discussions have a much longer history and it feels good to have them settled and the document published.
I am using a Garmin running watch, meanwhile seven years old. I had to replace the battery once but otherwise it just works. But recently, Apple decided to remove the serial driver code for this running watch from Mac OS High Sierra and hence I am not able to read out data anymore. Luckily, someone wrote a Linux command line utility some time ago to read out the data from Garmin watches (the tool is currently broken on newer versions of Ubuntu but people seem to be working on fixing this).
I observe that people at a certain age get enthusiastic about creating rules in an attempt to make this a better world, or to improve engineering, or to organize people more efficiently, or whatever they love to create rules for. And then I observe that people further down the road of life get more relaxed again, most likely they learned that long catalogues or rules simply do not achieve much (the more rules there are, the less likely it becomes that they will be read, understood, and followed).
We recently had a storm in the nothern part of Germany - not very unusual in Fall. Three days later I wanted to go home by train via Hannover. There were still some train tracks closed but the train company offered an ‘alternative connection’. Before entering the alternative connection train in Hannover, travelers were informed that they would receive more information in the train. (If you happen to know the German train system, you will know that people working on the trains usually have the least information.
The IETF is slow. The IETF is too slow. We know that, no news here. There was a discussion today about this topic in the OPS area meeting of the 99th IETF meeting, mostly driven by the fact that the networking industry (not just the IETF) is hit by a wave of YANG modules. Some ideas were presented to help organize this process. I personally do not think the IETF has a problem due to a lack of version numbers nor do I think the IETF has a real problem with format conversions of artefacts.
It seems the networking industry has created another hot buzzword: network slicing. The story, however, is more than 20+ years old. Telcos want to use their infrastructure (5G nowadays) to provide different services that are targeted to specific network use cases. Sounds good? Well, the telcos leave out that this is not done just to improve the network usage experience but to create new business models that allow to charge different amounts of money for the different network slices.
After joining Jacobs University, I ordered two computers in order to join PlanetLab, a truly innovative distributed computing and experimentation infrastructure at that time. The two computers become part of PlanetLab about 10 years ago and they recently asked to be retired. I think 10 years of service for mostly unknown researchers running even more unknown experiments is a great achievement and so I pulled the plug. I hope the silicon can enjoy the remaining time in the rack (with less heat) until it is time to make space available for others to come.
The IETF is meeting in Chicago this week and I am participating remotely via Meetecho. The remote participation service is improving every IETF it seems, saving me from a lot of long distance traveling hassle during the semester. While the people providing the remote participation service do a wonderful job, I believe a big part of this working well for me is that I know many of the regular contributors good enough from prior meetings I attended in person so that I can extract many soft signals just from the voice stream.
It appears that there are many motivators that instructors use to make students follow and even enjoy the material taught in computer networking courses. The really strong motivators seem to fall broadly into three categories: Competition and games between students or groups of students. Implementation of real-world protocols and systems where students build something that can be used (by them) afterwards (in principle). Trapping students into developing wrong solutions can be a tool to make them think critically and to make them realize the need to adopt a clear methodology.
I am enjoying a Dagstuhl seminar on Using Networks to Teach About Networks where people talk about their experience with modern teaching methods such active learning, flipped classrooms, online learning, peer reviewing, and learning analytics when teaching computer networks. (Some people even talk about using blockchains to maintain student records.) And then there are of course discussions about what do we teach students and why and which tools people have found useful for student labs.