While reading Geoff Huston’s excellent article “DNS Privacy and the IETF” (Internet Protocol Journal 22(5), July 2019), I came across the term ‘surveillance capitalism’, coined by Shoshana Zuboff (Harvard Business School in Cambridge).
The software crisis in the late 1960 and early 1970s was about the difficulty of writing useful and efficient computer programs in the required time. Software engineering has evolved as a discipline since then and we have far better tools and techniques in place today for a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software. Nowadays, we face a new crisis, let me call it the cybersecurity crisis, which is triggered by the need to build systems that deliver service that can be justifiably be trusted even in the face of malicious attacks.
I just read (again) Henning Schulzrinne’s reflections about where computer networking research stands in the middle years, titled “Networking research — A reflection in the middle years”. I may not agree with everything said in the paper but there is a lot of very good insight and truth in Henning’s paper.
I have attended a seminar discussing how to encourage reproducability in scientific research of the Internet. Obviously, everybody agrees that it is desirable that research findings are reproduced by independent studies (and I mean reproduced and not just repeated although repeated is more than nothing). The question, however, is how to get there. For me this is largely an issue of incentives and I am sure there are a couple of things that can be done to increase incentives to reproduce research.
I am following up on my previous post on this topic, which was focusing on issues related to the timely development of YANG modules. There are other key factors that determine the speed in which work completes and that are often ignored in the IETF when people discuss work to be taken on and define milestones. A big part is the management of the human resources. Yes, this may sound strange give that the IETF is a volunteer organization and hence does not directly “control” human resources.
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 May 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 of 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.