| orm@doc-tcpip.org | Erstellt: Mai 2001 - Letzte Modifikation: Juni 2001 |
Entgegen landläufiger Meinung: nein. Das ist im RFC 1796 genau erklärt.
Die RFCs (Request For Comment) sind der offizielle Weg
zur Publikation von Dingen, die IESG, IAB, IETF
und die Internet Community als solche betreffen - es müßen nicht
immer Standards sein. Daher auch der Name: Es wird um ein Kommentar zu
einer Angelegenheit gebeten.
Damit nicht jeder jeden Mist veröffentlicht, gibt es einen Prozess, der
vom RFC-Editor durchgeführt wird und so eine gewisse Qualität
erzwingt. Man kann nun in diesem Prozess verlangen, das der geschriebene
RFC als RFC im Standard Track betrachtet wird. Das ist ein
wirklicher Standard auf dem Weg zur Reife. Der aktuelle Status des
Dokumentes wird im Dokument selbst nicht mehr nachgehalten (ein RFC wird
nach der offiziellen Veröffentlichung nicht mehr geändert. Man findet
den aktuellen Status in einem extra RFC bzw. einer Web-Page des
RFC-Editors. Bei Dokumenten im Standards Track gilt die ASCII Version
als die verbindliche.
Dieser RFC hält den aktuellen Stand der Standardisierung der Protokolle fest: RFC 2800, STD 1. (In einer tagesaktuellen Form ist er auf www.rfc-editor.org zu finden).
Mit der technischen Entwicklung betraut sind folgende Organismen, die
im Prinzip jedem offenstehen:
IAB = Internet Architecture Board
IETF = Internet Engineering Task Force
IESG = Internet Engineering Steering Group
Der Zusammenhang bzw. die Abhängigkeiten sind wie folgt definiert: Die IETF (www.ietf.org) ist der ausführende Arm der Internet Society (ISOC, (www.isoc.org)); hier kann man Mitglied werden - es gibt in fast allen Ländern ein Chapter. Im IETF werden die Working Groups gebildet, die über Mailing Lists kommunizieren. Jede Gruppe hat einen Vorsitzenden, einen Moderator. Ähnliche Working Groups sind in Areas zusammengefaßt, denen ein Direktor vorsteht. Diese Direktoren bilden die IESG. Überwacht wird die IESG und somit die IETF vom IAB. Ähnlich läuft auch der Review-Prozess für RFCs.
Das ganze im Bild:IAB ****** IESG ** ** ** ** ** ** ** ** Area1 Area2 Area3 Area4 Area5 Area6 Area7 Area8 Working Groups, einem Area zugeordnet: *****# *****# *****#* ******# ****# *******# ****# ***# *******# *****# *****# ******# ******# ******# *****# ***# ***# ****# ******#Jede Working Group hat einen Moderator: # (Der Working Group Chair)
STD - Internet Standard: Das ist eine Untermenge aller RFCs. Es ist also immer noch ein RFC, der nur zusätzlich noch eine STD-Nummer bekommt. Dadurch wird dieser RFC als momentan gültiger Standard anerkannt.
BCP - Best Current Praxis: Auch eine Untermenge aller RFCs. Hier wird Einigkeit erzielt über Vorgehensweisen und Prozesse. Ist die in einem RFC beschriebene Vorgehensweise konsensfähig und allgemein anerkannt, bekommt dieser RFC eine BCP-Nummer und ist als momentan gültige Best Current Praxis anerkannt.
FYI - For Your Information: Eine weitere Untermenge mit RFCs, die allerlei nützliche Informationen enthalten.
Viele RFCs befinden sich weder auf dem Weg zum Standard, noch dienen sie zum Finden der besten Vorgehensweise (Best Praxis). Das sind die sogenannten Non-Standard Track-Spezifikationen. Sie werden in der Regel als Experimental oder Informational publiziert - oder es handelt sich um aus irgendwelchen Gründen überholte RFC, die als "historisch" verstanden werden. Das ist die Klassifikation Historic.
Also sei es nochmal wiederholt: Nicht alle RFC sind Standards - was im RFC 1796 genau erklärt ist. Nicht alle RFCs, die sich im Standard Track befinden, werden einmal ein Standard werden. Und einige RFCs befinden sich noch im Standard Track, sind aber defacto schon als Standard anerkannt.
Ein RFC wird nie modifiziert. Er kann immer nur durch einen anderen RFC geändert oder erweitert werden. Dazu gibt es zwei Möglichkeiten: der neue RFC ist ein update zum alten RFC, oder der neue RFC beerbt den alten RFC - dieser (der alte RFC) wird somit obsolet. Diese Beziehung untereinander kann man dem aktuellen Index-File entnehmen. Hier ist der Status eines jeden RFC gegeben, und zwar in beide Richtungen, also welche RFCs dieser RFC updated oder beerbt und von welchen RFCs dieser RFC geupdated oder beerbt wird.
Internet Drafts: Das sind keine RFCs, sondern rohe Vorlagen bzw. Versionen von Dokumenten der IETF Working Groups. Hat sich innerhalb von 6 Monaten an einem solchen Dokumnet nichts getan, so wird es gelöscht. Um ein RFC zu werden, muß ein Internet Draft von der IESG zur Veröffentlichung empfohlen werden. Man sollte Drafts nicht referenzieren.
Bezeichnet den gesamten Weg eines Vorschlages (also der Spezifikation eines Protokolles oder Verfahrens) durch die verschiedenen Ebenen: Entwicklung, Test, Annahme.
Die einzelnen Stufen sind:
Proposed Standard: Die IESG hebt einen RFC auf dieses Level,
wenn der Gegenstand
gut ausgeführt ist und schon eine gewisse Verbreitung erfahren hat.
Für Programmierer heisst das: Die Spezifikation ist noch unreif, es ist aber
Wünschenswert, das Ganze zu testen und Erfahrungen zu sammeln. Die Technik
sollte nicht in kritischen Umgebungen benutzt werden und ist nicht
Zukunftssicher, da sich noch erhebliche Änderungen ergeben können.
Draft Standard: Es gibt mindestens zwei unabhängige und interoperable Implementationen. Die IESG hält die Spezifikation ausserdem für nützlich und zukunftsweisend. Es müßen alle Features des Proposed Standards umgesetzt sein. Wird ein RFC zum Draft Standard erklärt, dann ist die Spezifikation weitgehend abgeschloßen. Hersteller können entsprechende Produkte entwickeln und auch in kritischen Umgebungen einsetzen. Es sind keine tiefgreifenden Änderungen mehr zu erwarten, es kann aber zu Modifikationen im Detail kommen. Das Protokoll tritt in die Phase der sehr weiten Verbreitung ein.
Internet Standard: Ein Standard nach Abschluß der Entwicklung, das Produkt hat Stabilität und Nützlichkeit im breiten Einsatz bewiesen. In diesem Moment wird zusätzlich zur RFC-Nummer noch eine Standard-Nummer (STD) vergeben. Die RFC-Nummer bleibt erhalten und voll gültig.
Hier finden sich RFC, die sich nicht im Standard Track befinden. Es kann sein, daß sie nie dafür gedacht waren, keinen Anklang fanden, oder von einer neuen Entwicklung überholt wurden. Ein RFC kann ein Standard gewesen sein und hier sein Altenteil fristen.
Experimental: Spezifikationen, die aus Forschung und Entwicklung resultieren und auch nur von solchem Interesse sind.
Informational: Spezifikationen, die als Informationen für die Internet Community gedacht sind.
Diese beiden Klassen werden nach Annahme durch den RFC-Editor als Internet Drafts veröffentlicht.
Historic: Wird eine Spezifikation durch eine Neue komplett abgelöst, dann wird die erstere als "historisch" gekennzeichnet.
Der Non Standard Track beherbergt die Unterklassen
BCP und FYI.
Das Feststellen der Besten Praxis ist auch einem
Auswahl-Prozess unterworfen,
die Unterklasse For Your Information ist eine Sammlung
von informativen Texten ohne spezielle Struktur.
BCP: Hier gibt es keinen fest vorgegebenen Rahmen wie bei den Standards. Standards beschäftigen sich mit der Ausarbeitung von Protokollen, während das beste Vorgehen, die beste Praxis erheblich auf den Erfahrungen der Anwender beruht. BCPs werden von der IESG reviewed, dann offen diskutiert und nach Ablauf einer gewissen Zeit als beste Praxis veröffentlicht. Es soll dabei ein breiter Konsens innerhalb der Internet Community erzielt werden.
Das genaue Prozedere für Standards und Best Current Praxis ist im RFC 2026 genau beschrieben.
FYI: Auch hier gibt es keinen festen Rahmen. Wenn das Dokument den formalen Anspüchen genügt und der Inhalt vor dem RFC-Editor Gnade gefunden hat, dann wird das Dokument veröffentlicht.
[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | RPi | SMTP | Tracing | GPS | LW ]
Copyright 2001-2021 by Orm Hager - Es gilt die GPL