Zusammenfassung

  • RFC 2860 hält das im März 2000 geschlossene IETF–ICANN-Abkommen über die technische Arbeit der IANA fest. RFCs liefern die Kriterien, das IESG gibt bei technischen Zweifeln Orientierung, und das IAB entscheidet über bestimmte Streitfälle.
  • Politische Fragen bei der Vergabe von Domainnamen und IP-Adressblöcken sind ausgenommen; bestimmte technische Zuweisungen in diesen Räumen bleiben jedoch erfasst. Das Abkommen verlangt außerdem öffentliche Zuweisungsdaten, einen Online-Antragsweg, legitime technische Ablehnungsgründe, Rechtsmittel und eine sechsmonatige Kündigungsfrist.

Analyse

Der Entscheidungsweg in RFC 2860 ist keine pauschale Übertragung von Autorität. Er ist eine abgestufte Regel für Protokollparameter im Zuständigkeitsbereich der IETF. Abschnitt 4.1 verweist zuerst auf die Kriterien und Verfahren in RFCs: vorgeschlagene, vorläufige und vollständige Internetstandards, Best Current Practice sowie andere RFCs, die eine IANA-Zuweisung verlangen. Fehlen Kriterien oder sind sie mehrdeutig, führt die IANA die traditionelle Praxis fort, sofern das IESG nichts anderes anordnet. Bei Zweifeln oder technischen Streitigkeiten soll die IANA technische Anleitung ausschließlich beim IESG einholen und befolgen.

Das IESG kann Fachleute hinzuziehen; fehlende Kriterien sollen IETF und IANA mit der Zeit ausarbeiten.

Für den Konflikt zwischen IANA und IESG reicht diese erste Stufe nicht. Abschnitt 4.2 überträgt die Frage an das IAB, dessen Entscheidung nach dem Abkommen endgültig ist. Daneben regelt Abschnitt 4.5 die Perspektive eines Antragstellers: Die IANA muss ein Online-Verfahren für Anträge auf Protokollparameter bereitstellen und zügig zuweisen oder wegen Verstoßes gegen anwendbare technische Anforderungen ablehnen. Eine Ablehnung ist nur aus legitimen technischen Gründen zulässig. Bei einem von der IETF geschaffenen Register kann der Antragsteller die Ablehnung zunächst beim IESG und anschließend beim IAB anfechten.

So unterscheidet der Text die laufende technische Orientierung, den Streit zwischen Operator und IESG und den Rechtsbehelf gegen eine Ablehnung.

Ein solcher Weg ist nur überprüfbar, wenn der Gegenstand des Verfahrens sichtbar ist. Abschnitt 4.4 verpflichtet die IANA, Informationen zu jeder aktuellen Zuweisung einschließlich der Kontaktdaten des Empfängers kostenlos online zu veröffentlichen. Eine vom RFC Editor veröffentlichte Zuweisung gilt als öffentlich zugänglich. Zusammen mit dem Antragsweg schafft dies eine Spur von Kriterien, Anfrage, Eintrag und möglicher Ablehnung. Ein veröffentlichter Eintrag belegt aber nicht, dass eine andere streitige Anfrage angenommen oder in allen Implementierungen umgesetzt wurde.

Der heikle Grenzfall steht in Abschnitt 4.3. Politische Fragen bei der Zuweisung von Domainnamen und IP-Adressblöcken liegen außerhalb des Abkommens. Technische Domainnamen für Reverse DNS, spezielle Adressblöcke wie Multicast oder Anycast und experimentelle Zuweisungen bleiben dagegen unter Abschnitt 4, sofern sie nicht als politische Fragen gelten. Sollte eine ICANN-Politik die Einhaltung der technischen Regeln für diese Fälle verhindern, muss ICANN die IETF benachrichtigen; die IETF kann daraufhin das Kündigungsrecht aus Abschnitt 2 ausüben. Der Text grenzt also die Art der Entscheidung ab, nicht einfach die Kategorien Name und Adresse.

Die organisatorischen Nebenregeln füllen den technischen Prozess aus. Die IANA erhält nach Abschnitt 4.6 nicht stimmberechtigte Verbindungsplätze in geeigneten, von der IETF bestimmten Gremien und kann an Gesprächen über Zuweisungsanforderungen teilnehmen. Abschnitt 4.7 verpflichtet sie, Dokumente während des IETF Last Call auf Bedenken zu prüfen und diese an das IESG zu melden. Das gibt der Registerpraxis einen Zugang zur Standardisierungsarbeit, ohne die im Abkommen genannten Kriterienquellen zu vertauschen.

Für die Forschung sieht Abschnitt 5 eine parallele Spur vor: Bei Parametern, die hauptsächlich zur IRTF gehören, werden IRTF und IRSG an die Stelle von IETF und IESG gesetzt. Ist die Zuordnung selbst unklar, entscheidet das IAB nach eigenem Ermessen, welchem Bereich der Parameter hauptsächlich zuzuordnen ist. Die Einordnung bestimmt somit, welches Verfahren greift.

Das Abkommen selbst beschreibt eine begrenzte Beziehung. RFC 2860 erschien im Juni 2000 als Informational und stellt ausdrücklich keinen Internetstandard auf. Er dokumentiert das am 1. März von IETF und ICANN unterzeichnete und am 10. März vom ICANN-Vorstand ratifizierte Memorandum. Dessen Zweck ist ausschließlich, die technische Arbeit der IANA im Auftrag von IETF und IRTF festzulegen. Zugleich bleibt ICANN frei, ähnliche Dienste für Register außerhalb dieses Bereichs anzubieten.

Beide Seiten können das Memorandum gemeinsam ändern oder beenden; jede Seite kann es mit mindestens sechs Monaten Vorlauf kündigen. Das ist ein dokumentierter Ausstieg, kein Beleg, dass er genutzt wurde. RFC 6220 beschreibt 2011 später die Rolle delegierter Betreiber von IETF-Protokollparameter-Registern und hält fest, dass die IETF Verantwortung für ihre Parameter behält. Dieser spätere Text ordnet Betreiberfunktionen ein, beweist aber weder, dass alle Einzelheiten von 2000 unverändert blieben, noch wie ein konkreter Zuweisungsstreit ausging.

RFC 2860 belegt einen Entscheidungsweg, Publikationspflichten und eine klar formulierte Grenze. Er belegt nicht die Einhaltung in jedem Einzelfall und benennt keine Instanz, die alle ausgeschlossenen politischen Fragen entscheidet. Wer aus der technischen Zuweisung eine allgemeine Zuständigkeit ableitet, liest mehr hinein, als das Dokument hergibt.

Quellen

Primärquelle ist RFC 2860, Memorandum of Understanding Concerning the Technical Work of the IANA, insbesondere die Abschnitte 1–5. Die spätere Beschreibung der Registerbetreiber steht in RFC 6220.