4. DER INTERNET-STANDARDS-TRACK
- DER INTERNET-STANDARDS-TRACK (THE INTERNET STANDARDS TRACK)
Spezifikationen, die zu Internetstandards werden sollen, entwickeln sich durch eine Reihe von Reifegraden, die als "Standards Track" bekannt sind. Diese Reifegrade -- "Proposed Standard" (Vorgeschlagener Standard), "Draft Standard" (Entwurfsstandard) und "Standard" -- werden in Abschnitt 4.1 definiert und diskutiert. Die Art und Weise, wie Spezifikationen entlang des Standards Track voranschreiten, wird in Abschnitt 6 beschrieben.
Selbst nachdem eine Spezifikation als Internetstandard angenommen wurde, findet oft eine weitere Entwicklung auf der Grundlage von Erfahrungen und der Erkennung neuer Anforderungen statt. Die Nomenklatur und Verfahren der Internet-Standardisierung sehen den Ersatz alter Internetstandards durch neue vor und die Zuweisung beschreibender Bezeichnungen zur Angabe des Status "ausgemusterter" Internetstandards. Eine Reihe von Reifegraden ist in Abschnitt 4.2 definiert, um diese und andere Spezifikationen abzudecken, die nicht als auf dem Standards Track befindlich angesehen werden.
4.1 Standards Track Reifegrade (Maturity Levels)
Internet-Spezifikationen durchlaufen Stadien der Entwicklung, Prüfung und Akzeptanz. Innerhalb des Internet-Standardisierungsprozesses werden diese Stadien formell als "Reifegrade" bezeichnet.
Dieser Abschnitt beschreibt die Reifegrade und die erwarteten Eigenschaften von Spezifikationen auf jeder Stufe.
4.1.1 Proposed Standard (Vorgeschlagener Standard)
Der Einstiegsreifegrad für den Standards Track ist "Proposed Standard". Eine spezifische Maßnahme der IESG ist erforderlich, um eine Spezifikation auf den Standards Track auf der Stufe "Proposed Standard" zu bringen.
Eine Proposed Standard-Spezifikation ist im Allgemeinen stabil, hat bekannte Designentscheidungen gelöst, wird als gut verstanden angesehen, hat eine erhebliche Community-Überprüfung erhalten und scheint genug Community-Interesse zu genießen, um als wertvoll angesehen zu werden. Weitere Erfahrungen könnten jedoch zu einer Änderung oder sogar zum Rückzug der Spezifikation führen, bevor sie voranschreitet.
Normalerweise ist weder eine Implementierung noch Betriebserfahrung für die Bezeichnung einer Spezifikation als Proposed Standard erforderlich. Solche Erfahrungen sind jedoch sehr wünschenswert und stellen normalerweise ein starkes Argument zugunsten einer Proposed Standard-Bezeichnung dar.
Die IESG kann eine Implementierung und/oder Betriebserfahrung vor der Gewährung des Proposed Standard-Status für eine Spezifikation verlangen, die die Kern-Internetprotokolle wesentlich beeinflusst oder ein Verhalten spezifiziert, das erhebliche operative Auswirkungen auf das Internet haben kann.
Ein Proposed Standard sollte keine bekannten technischen Auslassungen in Bezug auf die an ihn gestellten Anforderungen aufweisen. Die IESG kann diese Anforderung jedoch aufheben, um einer Spezifikation zu ermöglichen, in den Proposed Standard-Status vorzurücken, wenn sie als nützlich und notwendig (und rechtzeitig) angesehen wird, selbst mit bekannten technischen Auslassungen.
Implementierer sollten Proposed Standards als unreife Spezifikationen behandeln. Es ist wünschenswert, sie zu implementieren, um Erfahrungen zu sammeln und die Spezifikation zu validieren, zu testen und zu klären. Da der Inhalt von Proposed Standards jedoch geändert werden kann, wenn Probleme gefunden oder bessere Lösungen identifiziert werden, wird die Bereitstellung von Implementierungen solcher Standards in einer störungsempfindlichen Umgebung nicht empfohlen.
4.1.2 Draft Standard (Entwurfsstandard)
Eine Spezifikation, aus der mindestens zwei unabhängige und interoperable Implementierungen aus verschiedenen Codebasen entwickelt wurden und für die ausreichende erfolgreiche Betriebserfahrung erlangt wurde, kann auf die Stufe "Draft Standard" erhoben werden. Für die Zwecke dieses Abschnitts bedeutet "interoperabel", funktional gleichwertige oder austauschbare Komponenten des Systems oder Prozesses zu sein, in dem sie verwendet werden. Wenn patentierte oder anderweitig kontrollierte Technologie für die Implementierung erforderlich ist, müssen die separaten Implementierungen auch aus separater Ausübung des Lizenzierungsprozesses resultiert haben. Die Erhebung zum Draft Standard ist ein bedeutender Statusfortschritt, der einen starken Glauben anzeigt, dass die Spezifikation ausgereift und nützlich sein wird.
Die Anforderung für mindestens zwei unabhängige und interoperable Implementierungen gilt für alle Optionen und Funktionen der Spezifikation. In Fällen, in denen eine oder mehrere Optionen oder Funktionen nicht in mindestens zwei interoperablen Implementierungen demonstriert wurden, kann die Spezifikation nur dann auf die Draft Standard-Stufe voranschreiten, wenn diese Optionen oder Funktionen entfernt werden.
Der Vorsitzende der Arbeitsgruppe (Working Group) ist dafür verantwortlich, die spezifischen Implementierungen zu dokumentieren, die die Spezifikation für den Draft oder Internet Standard-Status qualifizieren, zusammen mit Dokumentation über das Testen der Interoperation dieser Implementierungen. Die Dokumentation muss Informationen über die Unterstützung jeder der einzelnen Optionen und Funktionen enthalten. Diese Dokumentation sollte dem Area Director zusammen mit dem Protokollaktionsantrag übermittelt werden. (siehe Abschnitt 6)
Ein Draft Standard muss gut verstanden und als sehr stabil bekannt sein, sowohl in seiner Semantik als auch als Grundlage für die Entwicklung einer Implementierung. Ein Draft Standard kann immer noch zusätzliche oder umfassendere Felderfahrung erfordern, da es möglich ist, dass Implementierungen auf der Grundlage von Draft Standard-Spezifikationen unvorhergesehenes Verhalten zeigen, wenn sie einer großangelegten Nutzung in Produktionsumgebungen ausgesetzt sind.
Ein Draft Standard wird normalerweise als endgültige Spezifikation betrachtet, und Änderungen werden wahrscheinlich nur vorgenommen, um spezifische aufgetretene Probleme zu lösen. Unter den meisten Umständen ist es für Anbieter vernünftig, Implementierungen von Draft Standards in einer störungsempfindlichen Umgebung bereitzustellen.
4.1.3 Internet Standard (Internetstandard)
Eine Spezifikation, für die erhebliche Implementierung und erfolgreiche Betriebserfahrung erlangt wurde, kann auf die Stufe Internet Standard erhoben werden. Ein Internet Standard (der einfach als Standard bezeichnet werden kann) ist durch einen hohen Grad an technischer Reife und durch eine allgemein vertretene Überzeugung gekennzeichnet, dass das spezifizierte Protokoll oder der Dienst der Internet-Gemeinschaft erhebliche Vorteile bietet.
Eine Spezifikation, die den Status eines Standards erreicht, erhält eine Nummer in der STD-Serie, während sie ihre RFC-Nummer behält.
4.2 Nicht-Standards-Track-Reifegrade (Non-Standards Track Maturity Levels)
Nicht jede Spezifikation befindet sich auf dem Standards Track. Eine Spezifikation ist möglicherweise nicht dazu bestimmt, ein Internetstandard zu werden, oder sie ist möglicherweise für eine eventuelle Standardisierung vorgesehen, aber noch nicht bereit, den Standards Track zu betreten. Eine Spezifikation kann durch einen neueren Internetstandard ersetzt worden sein oder ist anderweitig in Ungnade gefallen oder außer Gebrauch gekommen.
Spezifikationen, die sich nicht auf dem Standards Track befinden, sind mit einem von drei "Off-Track"-Reifegraden gekennzeichnet: "Experimental" (Experimentell), "Informational" (Informativ) oder "Historic" (Historisch). Die Dokumente, die diese Bezeichnungen tragen, sind in keiner Weise Internetstandards.
4.2.1 Experimental (Experimentell)
Die Bezeichnung "Experimental" kennzeichnet typischerweise eine Spezifikation, die Teil eines Forschungs- oder Entwicklungsaufwands ist. Eine solche Spezifikation wird zur allgemeinen Information der Internet-Technik-Gemeinschaft und als Archivaufzeichnung der Arbeit veröffentlicht, vorbehaltlich nur redaktioneller Überlegungen und der Überprüfung, dass eine angemessene Koordination mit dem Standardisierungsprozess stattgefunden hat (siehe unten). Eine experimentelle Spezifikation kann das Ergebnis eines organisierten Internet-Forschungsaufwands sein (z.B. eine Research Group der IRTF), einer IETF-Arbeitsgruppe, oder es kann ein individueller Beitrag sein.
4.2.2 Informational (Informativ)
Eine "Informational"-Spezifikation wird zur allgemeinen Information der Internet-Gemeinschaft veröffentlicht und stellt keinen Internet-Gemeinschaftskonsens oder keine Empfehlung dar. Die Informational-Bezeichnung soll die rechtzeitige Veröffentlichung einer sehr breiten Palette verantwortungsvoller Informationsdokumente aus vielen Quellen ermöglichen, vorbehaltlich nur redaktioneller Überlegungen und der Überprüfung, dass eine angemessene Koordination mit dem Standardisierungsprozess stattgefunden hat (siehe Abschnitt 4.2.3).
Spezifikationen, die außerhalb der Internet-Gemeinschaft erstellt wurden und nicht durch irgendeine der Bestimmungen von Abschnitt 10 in den Internet-Standardisierungsprozess einbezogen werden, können als Informational RFCs veröffentlicht werden, mit der Erlaubnis des Eigentümers und der Zustimmung des RFC-Editors.
4.2.3 Verfahren für Experimental und Informational RFCs
Sofern sie nicht das Ergebnis einer IETF-Arbeitsgruppenmaßnahme sind, sollten Dokumente, die mit dem Status Experimental oder Informational veröffentlicht werden sollen, direkt beim RFC-Editor eingereicht werden. Der RFC-Editor wird alle solche Dokumente als Internet-Drafts veröffentlichen, die nicht bereits so veröffentlicht wurden. Um diese Internet-Drafts zu unterscheiden, werden sie im I-D-Verzeichnis gekennzeichnet oder gruppiert, so dass sie leicht erkennbar sind. Der RFC-Editor wird nach dieser Veröffentlichung zwei Wochen auf Kommentare warten, bevor er weiter vorgeht. Es wird erwartet, dass der RFC-Editor sein oder ihr Urteilsvermögen hinsichtlich der redaktionellen Eignung eines Dokuments für die Veröffentlichung mit dem Status Experimental oder Informational ausübt und die Veröffentlichung eines Dokuments ablehnen kann, das nach der Expertenmeinung des RFC-Editors nicht mit Internet-Aktivitäten zusammenhängt oder unter dem technischen und/oder redaktionellen Standard für RFCs liegt.
Um sicherzustellen, dass die Nicht-Standards-Track-Bezeichnungen Experimental und Informational nicht missbraucht werden, um den Internet-Standardisierungsprozess zu umgehen, haben die IESG und der RFC-Editor vereinbart, dass der RFC-Editor der IESG jedes Dokument vorlegen wird, das zur Experimental- oder Informational-Veröffentlichung eingereicht wurde und das nach Meinung des RFC-Editors möglicherweise mit Arbeiten zusammenhängt, die innerhalb der IETF-Gemeinschaft durchgeführt werden oder voraussichtlich durchgeführt werden. Die IESG soll ein solches vorgelegtes Dokument innerhalb eines angemessenen Zeitraums überprüfen und entweder empfehlen, dass es wie ursprünglich eingereicht veröffentlicht oder der IETF als Beitrag zum Internet-Standardisierungsprozess vorgelegt wird.
Wenn (a) die IESG empfiehlt, dass das Dokument in die IETF aufgenommen und im IETF-Kontext vorangebracht werden sollte, der Autor dies jedoch ablehnt, oder (b) die IESG der Ansicht ist, dass das Dokument etwas vorschlägt, das mit einem etablierten IETF-Aufwand in Konflikt steht oder diesem tatsächlich abträglich ist, kann das Dokument dennoch als Experimental oder Informational RFC veröffentlicht werden. In diesen Fällen kann die IESG jedoch einen geeigneten "Haftungsausschluss"-Text in das RFC einfügen, entweder im oder unmittelbar nach dem Abschnitt "Status of this Memo", um die Umstände seiner Veröffentlichung für die Leser klar zu machen.
Von IETF-Arbeitsgruppen für Experimental und Informational RFCs vorgeschlagene Dokumente durchlaufen die IESG-Überprüfung. Die Überprüfung wird unter Verwendung des in Abschnitt 6.1.1 beschriebenen Verfahrens eingeleitet.
4.2.4 Historic (Historisch)
Eine Spezifikation, die durch eine neuere Spezifikation ersetzt wurde oder aus einem anderen Grund als veraltet angesehen wird, wird der Stufe "Historic" zugewiesen. (Puristen haben vorgeschlagen, dass das Wort "Historical" sein sollte; an diesem Punkt ist die Verwendung von "Historic" jedoch historisch.)
Hinweis: Standards Track-Spezifikationen dürfen normalerweise nicht von anderen Standards Track-Spezifikationen abhängen, die sich auf einem niedrigeren Reifegrad befinden, oder von Nicht-Standards-Track-Spezifikationen außer referenzierten Spezifikationen von anderen Standardisierungsgremien. (Siehe Abschnitt 7.)