My name includes three umlauts. It can be written correctly using six plus eleven unicode characters (first and last name). In the early 1990s, I never considered the idea of using my name as an identifier on a computer because most systems back then were still living in a US-ASCII world or the unfortunate ISO/IEC 8859 8-bit extensions, where the interpretation of the code points depends on the context.

Back in the 1990s, when I went to a bank to get a printout of my account status (yes, this is how banks worked back then; they had printers, and you had to visit them physically to check your account), I was always amazed at what came out of the printer. Often umlauts were replaced by curly braces and other fancy symbols. Back then, I used to be an optimist, and I believed that these problems would be overcome at the beginning of the 21st century. After all, the Unicode consortium was established in 1991, and Unicode 1.0 was released in the same year. In 1996, the initial specification of the UTF-8 transformation format was published as RFC 2044. So things looked promising. Sure, banks run mainframes, but give them 20 years and they may have made a transition to unicode.

Intended learning outcomes define what a student will have learned upon successfully completing a course or module. Intended learning outcomes play a central role in modern education as they describe clear and measurable learning goals that guide teaching and assessments. Intended learning outcomes can exist at different levels or granularity. At the program level, they describe the overall learning goals of a study program. At the course or module level, they define the learning goals of a course or module. Within the learning materials of a course or module, they may be further broken down. Writing intended learning outcomes has developed into an art of its own where often specific formats have to be followed, certain sets of verbs have to be used (see Blooms Taxonomy) and so on.

During my life, many remarkable things have happened. Numerous software technologies and services that we take for granted today were invented. Some of them are not really that old, given how important they are today, some even became part of our language. The way we live today has changed substantially over the last 40 years due to software and technology. While many influential moments look like incremental steps, there were also absolutely disruptive changes. I assume our generation will never forget how Steve Jobs introduced the iphone and turned the mobile phone market upside down. My first interaction with Alexa was another moment I will always remember, as was not long ago my first interaction with generative AI systems.

In a previous blog post (which I wrote about three years ago), I wrote about the consequences of adding version numbers to the YANG naming scheme. The take away message was that doing so has major consequences also for the protocols that are used to manipulate YANG defined data. Meanwhile, a concrete proposal has appeared to change the YANG versioning rules and to introduce semantic version numbers. Hence it is a good time to look at this topic again.

Network interfaces are identified by a numeric interface index or an interface name. The definition of interface indexes and names goes back to the early days of SNMP, see for example RFC 1066 (published in 1988). In the late 1990s, a scoped address architecture was introduced by RFC 2373 (published in 1998), and with it came zone indexes and zone names, both were introduced in RFC 4007 (published in 2005).

Note that Interface indexes and zone indexes as well as interface names and zone names are related concepts but not necessarily the same. However, in today’s deployed Internet technology, interface indexes and interface names are commonly used as zone indexes and zone names since they work well of link-local scopes and other non-global scopes are not widely deployed.

The following email exchange took please end of March 2021 between me and someone who claimed to be be one of my bosses. (The name appearing below is a pseudonym in order to avoid any confusion with real persons.)

Date: Tue, 30 Mar 2021 01:42:01 -0700
From: David Gammas <onikutem.o@gmail.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Subject:

I need a help, email me back asap

Regards,
Prof. Dr. David Gammas
Dean

Sent from Iphone

The email looked a bit odd to me (no subject line, email coming from an unknown @gmail.com address, an unusual timezone for someone working in Germany). But since the email did pretend to come from a Dean, I thought I check things out…

There are several attempts to record the history of networking or more specifically the Internet. One of these efforts is run by Russ White, who is conducting interviews with people that have contributed to the networking history.

People often have strong opinions about programming languages and so do I. Well, perhaps a bit less strong than others. Yesterday I took a moment to reflect about the things I liked and disliked through my journey with different languages. I started to write things down, and I decided to share my notes. This likely has little value for anyone, do not expect any deep insights here.

BASIC (late 1970s)

I first touched what we call a “computer” these days in the late 70s. I think it was a Wang 2200, an incredible device with a CPU built out of hundreds of TTL chips. The programming language of the Wang was BASIC. Learning to code simple algorithms in BASIC (i.e., the classic moon lander) was relatively easy. The Wang computer was owned by the school, and I got the permission to stay longer in the afternoon to work with the system. I had two really enthusiastic school teachers. One of them exposed me to an algorithm that was called RSA and brand new and I implemented it for the numbers the box could handle, small numbers, fairly small numbers….

It is perhaps a side effect of getting older that I spent more and more time on administrative issues and as a consequence I interact more frequently with people working in administrative offices. The more I get to see how they work, the more I am realizing how strange computer scientists are. One of the first rules they seem to learn in business administration is that everything can be made to fit into a two-dimensional table. And then they seem to drive this to perfection during their career. We computer scientists love to model things using inductively defined structures that can be nested arbitrarily deep or we paint walls with UML diagrams or model data in N dimensional sparse spaces. We teach our students how important it is to find the appropriate data representation for a given problem since often algorithms follow from the way data is represented. But this may all be misguided effort since business administration proves us every day that a two-dimensional table is a universal tool for everything.

Introduction

The YANG data modeling language [RFC7950] and the associated protocols NETCONF [RFC6241] and RESTCONF [RFC8040] use a naming scheme that essentially consists of tuples of the form (module, path). The tuple (ietf-system, /system/contact) is an example uniquely identifying the leaf /system/contact in the YANG data tree of the module ietf-system. (The module may be identified by the module name or a module namespace but since there is 1:1 mapping between the two, the difference is not relevant for the discussion here and we simply use the module name.)