Standardisierung im Internet

Die Entwicklung von Internet-Standards ist eng mit der IETF verbunden, deren Philosophie von der pragmatischen Arbeitsweise der so genannten "Netheads" geprägt ist. Viele Standards, mit denen heute im Internet tagtäglich gearbeitet wird, haben ihre Wurzeln in unkonventionellen Standardisierungsbemühungen - nicht immer ohne Schwierigkeiten.

Die Internet Engineering Task Force (IETF)

Die IETF, die Internet Engineering Task Force, ist eine Organisation, die sich um die Weiterentwicklung des Internet und seiner Technologien kümmert. Sie ist dabei weniger als feststehende Organisation zu verstehen, sondern eher als Dach für Entwickler und Interessierte, die an der Standardisierung mitarbeiten wollen. Aus diesem Grund gibt es keine feste Mitgliedschaft in der IETF und letztendlich auch keine Rechtsform der IETF selbst, da sie formell unter der Schirmherrschaft der Internet Society (ISOC) steht. Diese augenscheinliche "Rechtlosigkeit" der IETF steht in guter Tradition der Internet-Geschichte, da die ersten Entwicklungen durchaus hemdsärmelig stattgefunden haben und das erste Diskussionspapier tatsächlich in einem Badezimmer geschrieben wurde. In der einschlägigen Sprache werden die IETF-Entwickler zu den so genannten "Netheads" gezählt (siehe hierzu auch Wer entwickelt das Internet?).

Das erste Treffen der IETF fand im Januar 1986 in San Diego statt, zunächst als Veranstaltung, die alle drei Monate stattfinden sollte und zu der lediglich von der US-Regierung bezahlte Internet-Entwickler eingeladen wurden. Zum vierten IETF-Treffen im Oktober 1986 wurden schließlich auch Entwickler eingeladen, die nicht aktiv auf der Gehaltsliste der US-Regierung standen, so dass ab diesem Treffen die IETF-Treffen allen Interessierten offen standen.

Aufbau der IETF

Die IETF besitzt eine baumartige Struktur. Die oberste Hierarchie sind die so genannten Areas. Dies sind thematisch gegliederte Bereiche, in denen dann einzelne Arbeitsgruppen, so genannte Working Groups, organisiert sind.

Areas

Folgende Areas gibt es aktuell:

• Applications (Anwendungen)
• General (Allgemeine Themen)
• Internet (Internet-Dienste)
• Operations and Management (Betrieb und Netzmanagement)
• Real-time Applications and Infrastructure (Echtzeitanwendungen und Infrastruktur)
• Routing
• Security (Sicherheit)
• Transport (Transportdienste)

Jedem dieser Areas steht ein Team von einem oder mehreren so genannten Area Directors vor, die jeweils die betreffende Area kommissarisch leiten. Sie übernehmen vornehmlich regulierende Funktionen in ihrer Area, entscheiden also beispielsweise über die Einrichtung neuer Working Groups und treten als Vermittler in Aktion, wenn sich Fronten in einzelnen Arbeitsgruppen verhärten. Gleichzeitig sind die Area Directors im so genannten Internet Engineering Steering Board (IESG) organisiert (siehe weiter unten).

Working Groups

Working Groups sind unterhalb von Areas angesiedelt und sind die eigentlichen Entwicklungsschmelztiegel - hier findet die Entwicklung und die Diskussion zu einzelnen Technologien und Standards statt. Die Arbeit und die "Evolution" einer Working Group ist weiter unten näher beschrieben.

Internet Engineering Steering Group (IESG)

Die IESG ist die regulierende Organisationsstruktur für die IETF. Gebildet wird das Personal der IESG durch die Area Directors, dem Direktorium der IETF und dem IAB und jeweils einem Vertreter der IANA und des RFC-Editors.

Zuständig ist die IESG für das Tagesgeschäft der IETF und für die endgültige Revision von Internet-Standards. Gleichermaßen übernimmt sie Kontrollfunktionen in den Standardisierungsprozessen der einzelnen Arbeitsgruppen und ist das Regulierungsorgan, wenn in einzelnen Arbeitsgruppen oder auch Areas schwere Misstöne die Entwicklungsarbeit behindern.

Internet Architecture Board (IAB)

Das Internet Architecture Board ist ein Komitee, das ebenfalls innerhalb der Internet Society organisiert ist und sein Auge auf das so genannte "Big Picture" hält, also den weitläufigen Überblick über Internet-Entwicklungen behält. Dies dient zum einen der Entwicklungsarbeit innerhalb der IETF, da auf diese Weise das IAB Koordinierungsarbeit leisten kann und zum anderen auch der Mitarbeit mit anderen Standardisierungsinstitutionen außerhalb der IETF, um gemeinsame Entwicklungsarbeiten besser miteinander vernetzen zu können.

Weiterhin ist das IAB zuständig für das Management des RFC-Editors (siehe weiter unten) und dient als Klärungsstelle für Appelle, die sich mit der falschen Anwendung von Standardisierungsprozessen innerhalb der IETF beschäftigen. Das IAB grenzt sich hierbei von der IESG dadurch ab, dass die IESG für Probleme im Tagesgeschäft der IETF zuständig ist und das IAB für architektonische Probleme bei Internet-Standards.

Wege und Sackgassen eines Standards

Ein Internet-Standard hat in der Regel innerhalb der IETF einen komplexen Weg zu bestreiten, bevor er als offizieller Internet-Standard deklariert wird und entsprechende Implementierungssicherheit bietet. "Komplex" bedeutet hier nicht unbedingt auch "lang", denn wenn sich genügend fähige Leute finden, die an einem Strang ziehen und gut abgestimmte Entwicklungsarbeit bestreiten, kann ein Internet-Standard auch durchaus schneller auf die Welt kommen, als in anderen Entwicklungsorganisationen üblich.

Bildung einer Working Group - "Birds of a Feather" (BOF)

Zunächst einmal müssen sich für eine neue Entwicklung die geeigneten Personen finden lassen, die die Notwendigkeit einer Neu- oder Weiterentwicklung einer bestimmten Thematik sehen und daran arbeiten wollen. Oft rekrutieren sich solche Interessenskreise über bereits bestehende Kontakte und über Aushänge und Gespräche bei IETF-Treffen. Erfahrende Entwickler setzen sich zusammen, besprechen die Problematik und finden hier meist schon erste Gedanken, Gemeinsamkeiten und/oder Lösungsansätze.

Der erste, offizielle Schritt ist ein Treffen dieser ersten Entwickler, der so genannten Birds of a Feather, was in der deutschen Sprache am ehesten mit "Vögel aus dem gleichen Schlage" oder am einfachsten (und sachlichsten) mit "Gleichgesinnten" übersetzt werden kann. In diesem BOF-Meeting, an dem alle interessierten Entwickler teilnehmen können, wird versucht, eine Charta der Gruppe festzulegen, sich über eine Leitung der Gruppe zu einigen und einen groben Zeitplan aufzustellen. Die Ergebnisse eines solchen BOF-Meetings werden dann den/die zuständigen Area Director(s) übermittelt, denn diese(r) muss/müssen letztendlich über die Neueinrichtung einer Working Group entscheiden. Fällt die Entscheidung positiv aus, gilt die Gruppe als eingerichtet und kann umgehend mit ihrer Entwicklungsarbeit beginnen.

Arbeit und Zielsetzung einer Working Group

Das zentrale Ziel einer technischen Working Group ist so genannter "roughly code", also weitgehend lauffähiger Programmcode. Dieser Ansatz, lieber einen groben Konsens in einer absehbaren Zeit herbeizuführen, als sich in viel zu langer Zeit in Details zu verlieren, gilt auch für weniger technische Working Groups, die beispielsweise administrative Verfahren behandeln.

Die Entwicklungsarbeit selbst ist ein schrittweiser Prozess, bei dem für gewöhnlich ein Entwurfspapier zur Diskussion innerhalb der Working Group steht und dieses nach und nach ergänzt wird, je nach Wünschen, Anforderungen und Testergebnissen der Entwickler. Innerhalb dieser Entwicklung können auch schon erste Programmcodes entwickelt werden, die jedoch in der Regel eben nur "roughly" sind, also von grober Natur, und meist nur dazu dienen, Verfahren und grundsätzliche Funktionsfähigkeit einer Entwicklung darzustellen.

Ebenso "hemdsärmelig" sind Abstimmungen innerhalb einer Working Group, da es eigentlich keine wirklichen Abstimmungen gibt. Zustimmungen oder Ablehnungen zu bestimmten Aspekten werden für gewöhnlich über Stimmungsbilder der Teilnehmer erhoben. Dies kann in gut eingespielten Working Groups sehr schnell erfolgen, in komplexen Working Groups allerdings auch unter Umständen ein fast unmögliches Unterfangen sein. Die Protagonisten einer Working Group und nicht zuletzt die Leitung einer Working Group müssen deshalb nicht zuletzt auch eine Art von diplomatischem Geschick an den Tag legen, um konträre Meinungen unter einen Hut zu bekommen. Das ideale Ziel bleibt auch in solchen Fällen immer, das Entwurfspapier so weit zu entwickeln, dass bei der Erhebung eines Stimmungsbildes möglichst eine einheitlich positive oder zumindest keine negative Grundstimmung messbar ist.

Interne Kommunikation und IETF-Treffen

Der Großteil der Kommunikation innerhalb einer Working Group (und übrigens auch innerhalb der IETF) wird traditionell elektronisch über Mailinglisten geführt, in die sich Arbeitsgruppenteilnehmer und meist auch Interessierte eintragen können. Da diese Mailinglisten in der Regel unmoderiert sind und jeder Listenteilnehmer grundsätzlich schreiben darf, sind Mailaufkommen und gelegentlich aufschaukelnde Emotionen gerade in aktiven Working Groups und bei "heißen" Themen nicht zu unterschätzen. Ein effizientes Mailprogramm und Kenntnisse über das Einrichten von Filter- und Sortierrichtlinien sind deshalb Grundbedingungen für Teilnehmern, die nicht schon in den ersten Tagen an der Mailflut ersticken wollen.

Nach wie vor Höhepunkt der IETF-Arbeiten sind die dreimal im Jahr stattfindenden und mehrtägigen, offiziellen IETF-Treffen. Diese Treffen sind zentrale Treffpunkte aller IETF-Entwickler und Working Groups, um in der fortwährenden Entwicklungsarbeit auch "Face-to-Face" miteinander zu kommunizieren. Obwohl Videokonferenzen über das Internet technisch inzwischen gang und gäbe sind, wird das soziale Element von IETF-Treffen sehr geschätzt und dementsprechend hoch sind auch nach wie vor die Teilnehmerzahlen.

Die meisten "realen" Treffen von Working Groups finden bei IETF-Treffen statt, da viele Entwickler gleichzeitig in mehreren Working Groups aktiv sind und auf diese Weise mehrere Veranstaltungen nacheinander besucht werden können. Viele Diskussionen finden in, aber auch neben den eigentlichen Veranstaltungsorten in Restaurants, Bars und Kneipen statt. Gleichzeitig ist mit speziellen Veranstaltungen für Neulinge auch dafür gesorgt, dass "Rookies" in der Entwicklungsarbeit möglichst nah an das Geschehen kommen und Working Groups nach ihrem Interesse finden, in denen sie aktiv sein können.

Teilnehmen können an IETF-Treffen grundsätzlich alle Interessierte, die die Teilnahmegebühren (derzeit zwischen 600 und 750 US-Dollar, Ermäßigungen für bestimmte Personengruppen) bezahlen, unterschieden wird hierbei nicht zwischen Personen, die bestimmten Organisationen angehören; jeder ist letztendlich gleichgestellt.

Der Weg zum Standard

Existiert in einer Working Group irgendwann ein Konsens über ein Entwurfspapier, nähert sich ein Entwurf langsam einem so genannten Draft, also einer frühen Fassung eines möglichen Standards, der nun auch außerhalb der eigentlichen Working Group diskutiert werden kann und soll. Das kann in Veranstaltungen im Rahmen von IETF-Treffen oder anderen Branchentreffen sein, in Workshops, an denen Interessierte teilnehmen können, aber auch in Veröffentlichungen im Internet mit der Bitte um Rückmeldung aus der Netz-Community. Da eine Working Group im Normalfall sehr daran interessiert ist, einen öffentlichen Diskurs über seine Arbeit zu erzeugen, die freilich im Eskalationsfall auch zu einem schweren Erbe werden kann.

Klassischerweise werden Drafts und später auch der fertige Internet-Standard als RFC veröffentlicht:

Exkurs: Was ist ein Request For Comments (RFC)?

Die so genannten RFC-Dokumente sind der deutlichste und nachhaltigste Beweis für die Entwicklung von funktionsfähigen Standards innerhalb der Internet-Community und stellen viel mehr dar, als nur eine numerische Sammlung von Internet-Standards. Näher betrachtet bilden die RFC-Dokumente nämlich eine sehr anschauliche Grundlage für Standardisierungsvorgänge im Internet und ARPANet und sind nicht zuletzt ein bemerkenswertes Zeugnis der Netzwerktechnologien über viele Jahrzehnte hinweg.

Entstanden ist die Idee der RFC in den Anfangstagen des ARPANet (siehe hierzu auch Die Anfänge des Internet), als Steve Crocker im April 1969 das erste RFC mit der Nummer 1 schrieb, der Legende nach im Badezimmer eines Bekannten, das mit der Überschrift Host Software betitelt war und die Software zwischen einem an das ARPANet anzuschließenden Großrechner und dem Interface Message Processor (IMP), die untereinander die Kommunikation im ARPANet vollzogen, beschrieb. Später schrieb er dazu:

"Die meisten von uns waren Studenten im Aufbaustudium und wir erwarteten, dass sich eine professionelle Crew später um die Probleme kümmert, mit der wir uns herumschlugen. [..] Wir haben einige Notizen zum Design der DEL ['Decode-Encode-Language', die Sprache, mit dem Großrechner mit den IMP kommunizierten, Anmerk. des Autors] und zu anderen Dingen gesammelt und wir beschlossen, diese in eine Serie von Notizen zusammenzulegen. [..] Die Grundregel war, dass jeder alles sagen kann und das nichts offiziell war. Und um diesen Punkt zu unterstreichen, nannte ich die Notizen 'Bitte um Stellungnahmen' ['Request for Comments']. Ich habe mir nicht träumen lassen, dass diese Dokumente durch das ganze Medium, in dem wir diese Notizen diskutierten, verteilt würden."
-- Steve Crocker im RFC 1000 aus dem Jahre 1987, einem Rückblick auf die Entwicklungsarbeit der letzten 18 Jahre

Im Laufe der Zeit entwickelte sich die RFC-Sammlung zu der zentralen Dokumentensammlung , in der neue Technologien und Standards zur Diskussion und zur Standardisierung veröffentlicht wurden. Dazu gehören neben Beschreibungen von Technologien auch Nutzungsempfehlungen (Hinweise an Entwickler zu Implementierung bestimmter Dienste und Protokolle, aber auch beispielsweise die Veröffentlichung der Netiquette), aber auch Rückblicke auf die Entwicklungsarbeit, Nachrufe auf verdiente Entwickler, oder inzwischen legendäre RFC mit humorvollen Beiträgen, beispielsweise als jährlicher Aprilscherz.

RFC werden numerisch geordnet und nach der Veröffentlichung niemals mehr inhaltlich verändert, selbst wenn das ursprüngliche Dokument Fehler enthält oder der Inhalt eines RFC dadurch obsolet wird, weil es eine neue Fassung des beschriebenen Inhaltes gibt, beispielsweise durch eine neue Protokollversion. In so einem Fall wird lediglich darauf verwiesen, dass der Inhalt des Dokuments durch ein neueres RFC obsolet gesetzt ist.

Verwaltet wird die Herausgabe von RFC durch den so genannten RFC Editor. Lange Jahre war dies bis zu seinem Tode im Jahre 1998 der Wissenschaftler Jon Postel, der der IANA vorstand. In der Zwischenzeit ist der RFC Editor eine unabhängige Stelle, die von der Internet Society finanziert wird.

Eskalierende Working Groups

Die eher hemdsärmelige Arbeitsweise in einer Working Group funktionierte Jahrzehnte gut in einer kollegialen Umgebung, in der praktisch jeder jeden kennt. In verhältnismäßig kurzer Zeit konnten Probleme erkannt und diskutiert und erste Lösungen in tragfähigem Programmcode entwickelt werden. Die Maßgabe, dass lediglich ein Konsens benötigt wird und das Ergebnis "roughly code" sein sollte, sorgte verhältnismäßig schnell für viele neue und benötigte Dienste, Protokolle und Abläufe im Internet, die zu einem großen Teil auch heute noch im Einsatz sind.

In den letzten Jahren hat sich die Entwicklerszene grundlegend gewandelt: Die Entwicklung von Standards erfolgt immer weniger durch Eigenmotivation, sondern wird immer stärker durch Softwareunternehmen gesteuert, die eine Vielzahl von angestellten Entwicklern abkommandieren und in ihrer Entscheidung beeinflussen können. Angekurbelt wird diese Entwicklung durch so genannte Softwarepatente, mit denen sich Softwareunternehmen bereits vor der Teilnahme an Entwicklungsarbeiten bereits selbstentwickelte Programmteile vorab patentrechtlich schützen lassen und dann in der Gremienarbeit darauf pochen, dass genau diese Programmteile in einen Standard einfließen und andere Softwarehersteller daraufhin gegen Lizenzgebühren diese Patente nutzen sollen.

Ein solches, hart umkämpftes Beispiel ist die Suche nach einheitlichen Anti-Spam-Maßnahmen. Im Jahr 2004 wurde eine entsprechende Working Group namens MARID (MTA Authorization Records in DNS) gebildet. Diese hatte sich die Aufgabe gegeben, einen einheitlichen Standard für DNS-Einträge zu finden, mit denen im DNS für jede Domain hinterlegt werden konnte, welcher Mailserver tatsächlich Mails für diese Domain absendet. Ein anderer Mailserver kann vor dem Empfang dies nachprüfen und eine betreffende E-Mail verwerfen, wenn diese Einträge nicht auf den absenden Mailserver passen. Da das Thema von Anfang an prominent war, arbeiteten auch Entwickler großer Softwarehersteller in dieser Working Group, darunter von Yahoo und Microsoft.

Während der Arbeit in der Working Group kristallisierte sich heraus, dass Microsoft seinen eigenen Standard namens Caller ID als Grundlage für einen einheitlichen Standard positionieren wollte. Dies war insofern inakzeptabel für andere Teilnehmer der Working Group, da Microsoft Patentansprüche geltend machte und eine Verabschiedung von Sender ID als MARID-Ergebnis die Abgabe von Lizenzgebühren an Microsoft zur Folge haben könnten, wenn andere Softwarehersteller dieses Verfahren in ihre eigene Software integrieren wollten. Da schon nach wenigen Wochen klar wurde, dass es zu keinem sinnvollen Konsens mehr kommen konnte, wurde die Working Group mit einem gewaltigen Presseecho am 23. September 2004 ohne Ergebnis geschlossen.

Viele Fachleute sind inzwischen einhellig zur Feststellung gekommen, dass die bisherige Arbeitsweise der IETF nicht mehr den immer stärker unternehmenspolitisch gefärbten Ansprüchen genügt und Working Groups durch gegenteilige Interessen von großen Softwareunternehmen massiv beeinflusst werden könnten. Gerade die Offenheit der Standardisierungsarbeit erweist sich nun ausgerechnet als ein großes Problem, denn es ist weitgehend problemlos möglich, mit vielen eigenen Entwicklern den Konsens innerhalb einer Working Group bedeutend zu beeinflussen oder die Entwicklungsarbeit gänzlich zu blockieren.

Abwägungen

Allen möglichen Schwierigkeiten zum Trotz: Die Arbeit der Netheads innerhalb der IETF war und ist erfolgreich. Das Internet ist von Anfang an eine Welt der Unkonventionalität und immer schon waren deren Entwickler in der Situation, völlig neue Wege zu gehen, oft genug entgegen den jeweils geläufigen Arbeitsweisen.

Der Ansatz des "roghly coding" und die Bildung von Meinungsbildern, anstatt von festen Abstimmungen führen in der Regel zu größeren Diskussionen, letztendlich aber in den meisten Fällen zu relativ frühen Konsensen.

Weiterführende Links

http://www.rfc-editor.org/
Offizielle Homepage der Koordinierungsstelle von RFC-Dokumenten