Jürgen Schönwälder's Home Page and Weblog

While uploading a paper today, I was directed to the new IEEE online copyright transfer site. To sign the electronic form, I has to type my name. The legal basis for this form of electronic signature was given as well:

By clicking this button, you certify that such action constitutes your electronic signature to the IEEE Copyright Form in accordance with Federal Law, which authorizes electronic signature by authenticated request from a user over the internet as a valid substitute for a written signature.

I am not sure which Federal Law they refer to, given the global nature of IEEE authors. Assuming they refer to a law in the United States of America, it perhaps even applies to someone or something able to type my name correctly. So the real question seems to be what constitutes an "authenticated request" in the sense of this Federal Law. Given the rather unspectacular web site user registration system and the rather simple minded mechanisms for password resets via unprotected email, I consider the level of authentication rather poor. Will be interesting to see whether these signatures hold in front of courts.

I had to go to Brussels for a project review and as usual I preferred to travel by train. When I left home, I checked my connection and the Internet told me the trains run on time. About an hour later, when I reached the main station in downtown Bremen, I learned that my train got cancelled. This meant an hour waiting time for the next train to arrive and plus the (usual) delay we accumulated during the trip to Cologne. I arrived about 1h30m late in Cologne. (I will file some papers and I should get ~7 Euro back for the delay, close to 5 Euro/hour - wow.) In Cologne, I got warned that there might be trouble with the trains running to Brussels the next day.

When I left Cologne, the train was on time and I arrived well in time of the meeting. The project review went very well and it was becoming clear that we finish early. So I went to the train website to check whether there are any earlier connections I could take with my ticket. This way, I learned that my train back to Cologne was cancelled. When I arrived at the main station in Brussels, I could change my ticket to use the Belgium high speed train running to Cologne. Luckily, the train that was scheduled to leave while I changed my ticket was 45 minutes late - so I could get something to eat and jump on the train. While on the train, we were told that the train does not go to Cologne and we were told that we have to leave the train in Aachen. Well, since I took an earlier train, I thought I still can be happy. When we arrived in Liege (thats before we reached Aachen), we were told that all passengers to Cologne should step over in Liege to another train running to Cologne, which was immediately following us. After stepping over and leaving Liege, we were told that the train has a technical problem and thus the train gets rerouted and will be a about 30 minutes late in Aachen, but it will then continue at normal speed to Cologne.

The bottom line is that I was happy to get on a train earlier than my scheduled train to Cologne. However, the rerouting and the problems with the train did eat up all the time benefit - so I finally arrived in Cologne at the time the cancelled train would have arrived in Cologne. The funny thing is that I can't really complain about anything since according to German regulations, you can only ask for refunds if you are at least one hour late. Since I arrived still on time, it does not matter that I spent several additional hours in various trains.

Jacobs University is establishing Research Centers in order to focus research activities and graduate education. During the past few month (well, the whole year to be more precise), I have been working on a proposal of a research center called the Center for Advanced Systems Engineering (CASE). The CASE research center is rooted in the Electrical Engineering and Computer Science faculty but in addition integrates colleagues from Ocean Research and Logistics. The CASE research center proposal finally got officially approved and we are now working on filling the center with life in 2010. Expect more CASE related news to come.

I just returned from Venice (Italy), where I attended DSOM 2009 and IPOM 2009. This was my first trip to Venice and the city is more than interesting. I enjoyed going straight to the airport by boat (not necessarily fast but pretty special) and I liked the water taxi I used every morning to reach the conference site, the Telecom Italia Future Centre.

The main conference room was truely exceptional, combining Venecian history with modern meeting room technology. The audience was sitting on the left and right side of the room facing each other but not the presenter, who was located at the head of the room. Being futuristic meant in this specific case that every participant had his own screen for watching the slides and a microphone for live interaction. Despite a few feedback issues, the microphones worked reasonably well for the audience - but less so for the presenter located at the head of the room since the speakers were all directed towards the audience. But the fact that it was difficult for the presenter to understand questions was just a minor challenge - the by far bigger challenge was to deliver a lively talk in front of an audience where nobody is facing the presenter and all peopel are starring into computer screens (either their own notebooks or the screens showing the slides or even both). Giving a lively presentation from an office via a web conferencing system is likely easier than this setup.

Two new RFCs have just been posted: RFC 5675 defines how to represent SNMP notifications as structured SYSLOG messages and RFC5676 defines a MIB module for representing structured SYSLOG messages as SNMP MIB objects and SNMP notifications.

The specification of a transport subsystem for the Simple Network Management Protocol (SNMP) has been posted as RFC 5590.

I accepted an invitation to join the editorial board of the International Journal of Network Management (IJNM), published by Wiley.

I am attending the IM 2009 conference. It was originally planned to take place at Columbia University in upper Manhattan in New York. For some reasons, this did not work out and the event was moved to Hofstra University located in Long Island. I booked the conference hotel, located adjacent to the Nassau Coliseum. The Coliseum has a huge parking lot and the hotel and the Coliseum; no trees or any other things that are not made out of concrete. Google for this place if you want to see the amount of concrete I walk now every day. Yeah, I walking in the US - I should have rented a car.

I co-organized a Dagstuhl seminar on the Visualization and Monitoring of Network Traffic, which brought together researchers from the information visualization community and the networking community. I very much enjoyed the discussions with people with a very different background and the visualization demonstrations participants showed during the event. This seminar definitely was worth the effort of organizing it.

The IETF week is over and one of the questions raised in one of my documents was as simple as this: What are the restrictions for valid domain names? Guess what, there is no simple answer. There are several RFCs stating some constraints on domain names and there is practical usage of domain names (not necessarily consistent with all relevant RFCs). It turns out that there is not a single specification that states all the restrictions under which valid domain names can be formed and the DNS directorate of the IETF is now helping to sort this out.

Another simple question asked before the last IETF (and discovered independently by others during the last IETF) was this one: What is the canonical textual representation of IPv6 addresses? While RFC 4291 says the preferred format is x:x:x:x:x:x:x:x, where the 'x's are one to four hexadecimal digits of the eight 16-bit pieces of the address, it seems most operating systems and server implementations produce a compressed zeros format, likely by calling inet_ntop(). Unfortunately, RFC 3493 only says this about the format produced by inet_ntop():

The inet_ntop() function shall convert a numeric address into a text string suitable for presentation.

By doing some tests to figure out what "suitable for presentation" means to implementors, it was discovered that inet_ntop() implementations indeed to different things (and we did not even bother to investigate the details of the getnameinfo() conversion function). The funny thing is that independent of this investigation, some operators wrote a draft explaining why different textual representations of IPv6 addresses are making life more complicated for operators than it needs to be...