Facebook "Open Compute Project" nothing but hot air

There has been a lot of fuzz about facebook's Open Compute Project, and it seems to originate mostly from journalists without much technical skill.

Did anyone actually bother to check what they released? You can find mechanical designs and simple specification data sheets. More or less every vendor is publishing that kind of information, or at least there are common form factors that are specified (like ATX, eATX, mini-ITX, ...)

It is sad to hear that they are 'openwashing' themselves (like BP is greenwashing itself). Specifically, the following portions are not "open":

• Any type of electrical schematics (mainboards, power supply, ...)
• Any type of detailed data sheets or programming manuals on the electronic components used
• Gerber files of the PCBs

So what this really is all about is: Facebook advertising this is our new mechanical form factor, now we want all of you to adopt it, so we can buy cheaper hardware.

Go home, facebook. Come back if you have something _really_ open.

Following up on my GSM MAP archeology project

In the past weeks, I have been blogging about the work I've been doing in trying to recover the earlier versions of the GSM MAP ASN.1 files in order to support it from my own Osmocom Erlang MAP code.

After having gone through the tiresome exercise of implementing a custom MS Word for DOS file parser to extract the ASN.1 definitions from the 3GPP-published DOC files, I tried to feed them into the Erlang asn1ct code generator.

Unfortunately this didn't work, as the old MAP ASN.1 references very old ITU-T TCAP from 1988. So I went to the ITU website. There again a similar story. From their asn1 website section, you can only get the TCAPMessages from 1997. If you want an older format, like the Q.773 from 1988, you can download a PDF file. Most of that PDF file is actual text. But the ASN.1 sections are included as an image, so there is no way how you can copy+paste them.

So there I went, and manually typed in those few pages of ASN.1 source code. After I was finished, I thought I had finally done enough. Writing a word-for-DOS parser, typing in pages of ASN.1 manually. What more can there be? I should be able to finally generate Erlang code for decoding and encoding the respective messages.

But it would be too simple if it was that easy. The 1988 TCAP as well as the old MAP specifications use the ASN.1 "MACRO" construct to define the individual MAP operations. However, as it seems the MACRO construct had been deprecated in 1994 by the ISO in charge of ASN.1. Successive ISO specs for ASN.1 have completely remove the MACRO construct as similar results can be achieved with newly-introduced information objects. So of course, the Erlang asn1ct (as well as other free software ASN.1 tools) does not support such an antique feature.

So here I am in the year 2011, unable to use information available in the public ITU-T and ETSI/3GPP specifications to build a GSM MAP protocol implementation that can deal with the messages that you encounter on real-world SS7 links. I guess there are now the following different approaches to proceed:

• write a converter that translates MACRO into OBJECT
• manually convert the old MAP specs from MACRO to OBJECT
• add MACRO support to current-day ASN.1 tools
• find some old ASN.1 code generators that still support MACRO

All in all, this is a really dissatisfying situation, and I would say it is a failure of the standardization bodies to provide useful versions of their specifications. You cannot remove operations and associated message types from a specification, while in real life even 15 years later a whole number of users still use messages according to those (now removed) definitions. Meanwhile, the old specs are getting useless, because you not only deprecate but completely remove a language construct of the formal specification language used.

This renders the idea of having a formal specification useless. If I first need to write my own converters or manually convert that very same formal specification, errors can be introduced in the translation/conversion process, just as much as errors could have been introduced in manually writing encoding and decoding routines based on a non-formal-specified protocol like most of the IETF / Internet protocols.