6. DER INTERNET-STANDARDISIERUNGSPROZESS
- DER INTERNET-STANDARDISIERUNGSPROZESS (THE INTERNET STANDARDS PROCESS)
Die Mechanik des Internet-Standardisierungsprozesses umfasst Entscheidungen der IESG bezüglich der Aufnahme einer Spezifikation in den Standards Track oder der Bewegung einer Standards Track-Spezifikation von einem Reifegrad zum anderen. Obwohl eine Reihe von vernünftig objektiven Kriterien (die unten und in Abschnitt 4 beschrieben werden) zur Verfügung stehen, um die IESG bei der Entscheidung zu leiten, eine Spezifikation auf, entlang oder vom Standards Track zu bewegen, gibt es keine algorithmische Garantie für die Erhebung auf oder das Fortschreiten entlang des Standards Track für irgendeine Spezifikation. Das erfahrene kollektive Urteil der IESG bezüglich der technischen Qualität einer Spezifikation, die für die Erhebung auf oder den Fortschritt im Standards Track vorgeschlagen wird, ist ein wesentlicher Bestandteil des Entscheidungsprozesses.
6.1 Standards Actions (Standardmaßnahmen)
Eine "Standards Action" -- das Eintreten einer bestimmten Spezifikation in den Standards Track, ihr Voranschreiten innerhalb oder ihre Entfernung aus dem Standards Track -- muss von der IESG genehmigt werden.
6.1.1 Einleitung der Maßnahme (Initiation of Action)
Eine Spezifikation, die in den Internet-Standards Track eintreten oder darin voranschreiten soll, soll zuerst als Internet-Draft veröffentlicht werden (siehe Abschnitt 2.2), es sei denn, sie hat sich seit der Veröffentlichung als RFC nicht geändert. Sie soll für einen Zeitraum von nicht weniger als zwei Wochen als Internet-Draft verbleiben, der eine nützliche Community-Überprüfung ermöglicht, danach kann eine Empfehlung für eine Maßnahme eingeleitet werden.
Eine Standards Action wird durch eine Empfehlung der IETF-Arbeitsgruppe, die für eine Spezifikation verantwortlich ist, an ihren Area Director eingeleitet, kopiert an das IETF-Sekretariat oder, im Fall einer Spezifikation, die nicht mit einer Arbeitsgruppe verbunden ist, eine Empfehlung einer Einzelperson an die IESG.
6.1.2 IESG-Überprüfung und Genehmigung (IESG Review and Approval)
Die IESG bestimmt, ob eine ihr gemäß Abschnitt 6.1.1 vorgelegte Spezifikation die anwendbaren Kriterien für die empfohlene Maßnahme erfüllt (siehe Abschnitte 4.1 und 4.2), und bestimmt zusätzlich, ob die technische Qualität und Klarheit der Spezifikation mit der für den Reifegrad erwarteten übereinstimmt, für den die Spezifikation empfohlen wird.
Um alle Informationen zu erhalten, die notwendig sind, um diese Bestimmungen zu treffen, insbesondere wenn die Spezifikation von der IESG als äußerst wichtig in Bezug auf ihre potenziellen Auswirkungen auf das Internet oder auf die Suite von Internetprotokollen angesehen wird, kann die IESG nach ihrem Ermessen eine unabhängige technische Überprüfung der Spezifikation in Auftrag geben.
Die IESG sendet eine Benachrichtigung an die IETF über die bevorstehende IESG-Prüfung des/der Dokuments/Dokumente, um eine abschließende Überprüfung durch die allgemeine Internet-Gemeinschaft zu ermöglichen. Diese "Last-Call"-Benachrichtigung erfolgt per E-Mail an die IETF Announce-Mailingliste. Kommentare zu einem Last-Call werden von jedem akzeptiert und sollten wie in der Last-Call-Ankündigung angegeben gesendet werden.
Die Last-Call-Periode darf nicht kürzer als zwei Wochen sein, außer in den Fällen, in denen die vorgeschlagene Standards Action nicht von einer IETF-Arbeitsgruppe eingeleitet wurde, in welchem Fall die Last-Call-Periode nicht kürzer als vier Wochen sein darf. Wenn die IESG der Ansicht ist, dass das Interesse der Gemeinschaft durch mehr Zeit für Kommentare gefördert würde, kann sie über eine längere Last-Call-Periode entscheiden oder eine laufende Last-Call-Periode ausdrücklich verlängern.
Die IESG ist nicht an die empfohlene Maßnahme gebunden, als die Spezifikation eingereicht wurde. Beispielsweise kann die IESG entscheiden, die Spezifikation zur Veröffentlichung in einer anderen Kategorie als der angeforderten zu prüfen. Wenn die IESG dies vor der Ausgabe des Last-Call entscheidet, sollte der Last-Call die Ansicht der IESG widerspiegeln. Die IESG könnte auch entscheiden, die Veröffentlichungskategorie basierend auf der Reaktion auf einen Last-Call zu ändern. Wenn diese Entscheidung dazu führen würde, dass eine Spezifikation auf einem "höheren" Niveau veröffentlicht wird, als der ursprüngliche Last-Call vorsah, sollte ein neuer Last-Call ausgegeben werden, der die IESG-Empfehlung angibt. Darüber hinaus kann die IESG entscheiden, die Bildung einer neuen Arbeitsgruppe im Falle erheblicher Kontroversen als Reaktion auf einen Last-Call für eine Spezifikation zu empfehlen, die nicht von einer IETF-Arbeitsgruppe stammt.
In zeitnaher Weise nach Ablauf der Last-Call-Periode trifft die IESG ihre endgültige Entscheidung darüber, ob die Standards Action genehmigt werden soll oder nicht, und benachrichtigt die IETF über ihre Entscheidung per E-Mail an die IETF Announce-Mailingliste.
6.1.3 Veröffentlichung (Publication)
Wenn eine Standards Action genehmigt wird, wird eine Benachrichtigung an den RFC-Editor gesendet und an die IETF kopiert mit der Anweisung, die Spezifikation als RFC zu veröffentlichen. Die Spezifikation wird zu diesem Zeitpunkt aus dem Internet-Drafts-Verzeichnis entfernt.
Eine offizielle Zusammenfassung abgeschlossener und anhängiger Standards Actions erscheint in jeder Ausgabe des Newsletters der Internet Society. Dies stellt die "Veröffentlichung der Aufzeichnung" für Internet-Standards-Maßnahmen dar.
Der RFC-Editor veröffentlicht regelmäßig einen "Internet Official Protocol Standards" RFC [1], der den Status aller Internet-Protokoll- und Dienstspezifikationen zusammenfasst.
6.2 Voranschreiten im Standards Track (Advancing in the Standards Track)
Das in Abschnitt 6.1 beschriebene Verfahren wird für jede Maßnahme befolgt, die das Voranschreiten einer Spezifikation entlang des Standards Track begleitet.
Eine Spezifikation verbleibt mindestens sechs (6) Monate auf der Stufe Proposed Standard.
Eine Spezifikation verbleibt mindestens vier (4) Monate auf der Stufe Draft Standard oder bis mindestens ein IETF-Meeting stattgefunden hat, je nachdem, was später eintritt.
Diese Mindestperioden sollen eine angemessene Gelegenheit für eine Community-Überprüfung gewährleisten, ohne die Aktualität stark zu beeinträchtigen. Diese Intervalle werden ab dem Datum der Veröffentlichung des/der entsprechenden RFC(s) gemessen oder, wenn die Maßnahme nicht zur RFC-Veröffentlichung führt, ab dem Datum der Ankündigung der IESG-Genehmigung der Maßnahme.
Eine Spezifikation kann (und wird wahrscheinlich) überarbeitet werden, wenn sie durch den Standards Track voranschreitet. Auf jeder Stufe bestimmt die IESG den Umfang und die Bedeutung der Überarbeitung der Spezifikation und modifiziert gegebenenfalls die empfohlene Maßnahme. Kleinere Überarbeitungen werden erwartet, aber eine erhebliche Überarbeitung kann erfordern, dass die Spezifikation mehr Erfahrung auf ihrem aktuellen Reifegrad sammelt, bevor sie fortschreitet. Schließlich, wenn die Spezifikation sehr erheblich geändert wurde, kann die IESG empfehlen, dass die Überarbeitung als neues Dokument behandelt wird, das den Standards Track am Anfang wieder betritt.
Eine Statusänderung führt zur erneuten Veröffentlichung der Spezifikation als RFC, außer in dem seltenen Fall, dass es seit der letzten Veröffentlichung überhaupt keine Änderungen an der Spezifikation gegeben hat. Im Allgemeinen werden gewünschte Änderungen zur Einarbeitung auf der nächsten Stufe im Standards Track "gebündelt". Die Verschiebung von Änderungen auf die nächste Standards Action zur Spezifikation wird jedoch nicht immer möglich oder wünschenswert sein; beispielsweise muss ein wichtiger typografischer Fehler oder ein technischer Fehler, der keine Änderung der Gesamtfunktion der Spezifikation darstellt, möglicherweise sofort korrigiert werden. In solchen Fällen kann die IESG oder der RFC-Editor gebeten werden, das RFC (mit einer neuen Nummer) mit Korrekturen erneut zu veröffentlichen, und dies setzt die Mindestzeitenlevel-Uhr nicht zurück.
Wenn eine Standards Track-Spezifikation die Internet Standard-Stufe nicht erreicht hat, aber für vierundzwanzig (24) Monate auf demselben Reifegrad geblieben ist, und danach alle zwölf (12) Monate bis der Status geändert wird, überprüft die IESG die Lebensfähigkeit des für diese Spezifikation verantwortlichen Standardisierungsaufwands und die Nützlichkeit der Technologie. Nach jeder solchen Überprüfung genehmigt die IESG die Beendigung oder Fortsetzung des Entwicklungsaufwands, gleichzeitig entscheidet die IESG, die Spezifikation auf demselben Reifegrad zu halten oder sie auf den Status Historic zu verschieben. Diese Entscheidung wird der IETF per E-Mail an die IETF Announce-Mailingliste mitgeteilt, um der Internet-Gemeinschaft eine Gelegenheit zur Stellungnahme zu geben. Diese Bestimmung soll keine legitimen und aktiven Arbeitsgruppenaufwand bedrohen, sondern vielmehr einen administrativen Mechanismus zur Beendigung eines moribunden Aufwands bereitstellen.
6.3 Überarbeitung eines Standards (Revising a Standard)
Eine neue Version eines etablierten Internetstandards muss den vollständigen Internet-Standardisierungsprozess durchlaufen, als ob es sich um eine völlig neue Spezifikation handelte. Sobald die neue Version die Standard-Stufe erreicht hat, wird sie normalerweise die vorherige Version ersetzen, die auf den Status Historic verschoben wird. In einigen Fällen können jedoch beide Versionen als Internetstandards verbleiben, um die Anforderungen einer installierten Basis zu würdigen. In dieser Situation muss die Beziehung zwischen der vorherigen und der neuen Version explizit im Text der neuen Version oder in einem anderen geeigneten Dokument angegeben werden (z.B. einer Applicability Statement; siehe Abschnitt 3.2).
6.4 Ausmusterung eines Standards (Retiring a Standard)
Da sich die Technologie ändert und reift, ist es möglich, dass eine neue Standard-Spezifikation technisch so eindeutig überlegen ist, dass eine oder mehrere bestehende Standards Track-Spezifikationen für dieselbe Funktion ausgemustert werden sollten. In diesem Fall oder wenn aus einem anderen Grund der Ansicht ist, dass eine bestehende Standards Track-Spezifikation ausgemustert werden sollte, genehmigt die IESG eine Statusänderung der alten Spezifikation(en) auf Historic. Diese Empfehlung wird mit denselben Last-Call- und Benachrichtigungsverfahren ausgegeben, die für jede andere Standards Action verwendet werden. Ein Antrag auf Ausmusterung eines bestehenden Standards kann von einer Arbeitsgruppe, einem Area Director oder einer anderen interessierten Partei stammen.
6.5 Konfliktlösung und Berufungen (Conflict Resolution and Appeals)
Streitigkeiten sind in verschiedenen Stadien während des IETF-Prozesses möglich. So weit wie möglich ist der Prozess so gestaltet, dass Kompromisse geschlossen und echter Konsens erreicht werden können, es gibt jedoch Zeiten, in denen selbst die vernünftigsten und sachkundigsten Menschen nicht in der Lage sind, sich zu einigen. Um die Ziele von Offenheit und Fairness zu erreichen, müssen solche Konflikte durch einen Prozess offener Überprüfung und Diskussion gelöst werden. Dieser Abschnitt spezifiziert die Verfahren, die befolgt werden müssen, um mit Internet-Standards-Themen umzugehen, die nicht durch die normalen Prozesse gelöst werden können, durch die IETF-Arbeitsgruppen und andere Teilnehmer des Internet-Standardisierungsprozesses normalerweise Konsens erreichen.
6.5.1 Arbeitsgruppenstreitigkeiten (Working Group Disputes)
Eine Einzelperson (ob Teilnehmer an der relevanten Arbeitsgruppe oder nicht) kann mit einer Arbeitsgruppenempfehlung nicht einverstanden sein, basierend auf ihrer Überzeugung, dass entweder (a) ihre eigenen Ansichten von der Arbeitsgruppe nicht angemessen berücksichtigt wurden, oder (b) die Arbeitsgruppe eine falsche technische Wahl getroffen hat, die die Qualität und/oder Integrität der Produkte der Arbeitsgruppe erheblich gefährdet. Die erste Frage ist eine Schwierigkeit mit dem Arbeitsgruppenprozess; die letztere ist eine Behauptung eines technischen Fehlers. Diese beiden Arten von Meinungsverschiedenheiten sind recht unterschiedlich, werden aber beide durch denselben Überprüfungsprozess behandelt.
Eine Person, die mit einer Arbeitsgruppenempfehlung nicht einverstanden ist, muss die Angelegenheit immer zuerst mit dem/den Vorsitzenden der Arbeitsgruppe besprechen, der/die andere Mitglieder der Arbeitsgruppe (oder die Arbeitsgruppe als Ganzes) in die Diskussion einbeziehen kann.
Wenn die Meinungsverschiedenheit auf diese Weise nicht gelöst werden kann, kann jede der beteiligten Parteien sie dem/den Area Director(s) für den Bereich zur Kenntnis bringen, in dem die Arbeitsgruppe gechartert ist. Der/die Area Director(s) versuchen, die Streitigkeit zu lösen.
Wenn die Meinungsverschiedenheit nicht durch den/die Area Director(s) gelöst werden kann, kann jede der beteiligten Parteien dann an die IESG als Ganzes appellieren. Die IESG überprüft dann die Situation und versucht, sie auf eine Weise ihrer eigenen Wahl zu lösen.
Wenn die Meinungsverschiedenheit nicht zur Zufriedenheit der Parteien auf IESG-Ebene gelöst wird, kann jede der beteiligten Parteien die Entscheidung an die IAB appellieren. Die IAB überprüft dann die Situation und versucht, sie auf eine Weise ihrer eigenen Wahl zu lösen.
Die IAB-Entscheidung ist endgültig in Bezug auf die Frage, ob die Internet-Standardisierungsverfahren befolgt wurden oder nicht, und in Bezug auf alle Fragen der technischen Verdienste.
6.5.2 Prozessfehler (Process Failures)
Dieses Dokument legt Verfahren fest, die befolgt werden müssen, um Offenheit und Fairness des Internet-Standardisierungsprozesses und die technische Lebensfähigkeit der erstellten Standards sicherzustellen. Die IESG ist der Hauptagent der IETF für diesen Zweck, und es ist die IESG, die damit beauftragt ist, sicherzustellen, dass die erforderlichen Verfahren befolgt wurden und dass alle notwendigen Voraussetzungen für eine Standards Action erfüllt wurden.
Wenn eine Einzelperson mit einer von der IESG in diesem Prozess ergriffenen Maßnahme nicht einverstanden sein sollte, sollte diese Person die Frage zuerst mit dem IESG-Vorsitzenden besprechen. Wenn der IESG-Vorsitzende den Beschwerdeführer nicht zufriedenstellen kann, sollte die IESG als Ganzes die ergriffene Maßnahme zusammen mit dem Input des Beschwerdeführers erneut prüfen und feststellen, ob weitere Maßnahmen erforderlich sind. Die IESG gibt einen Bericht über ihre Überprüfung der Beschwerde an die IETF heraus.
Sollte der Beschwerdeführer mit dem Ergebnis der IESG-Überprüfung nicht zufrieden sein, kann eine Berufung bei der IAB eingelegt werden. Die IAB überprüft dann die Situation und versucht, sie auf eine Weise ihrer eigenen Wahl zu lösen und der IETF über das Ergebnis ihrer Überprüfung zu berichten.
Wenn die Umstände es rechtfertigen, kann die IAB anordnen, dass eine IESG-Entscheidung annulliert wird, und die Situation ist dann so, wie sie vor der IESG-Entscheidung war. Die IAB kann der IESG auch eine Maßnahme empfehlen oder solche anderen Empfehlungen abgeben, wie sie es für angemessen hält. Die IAB kann jedoch nicht die Rolle der IESG präemptieren, indem sie eine Entscheidung trifft, die nur die IESG ermächtigt ist zu treffen.
Die IAB-Entscheidung ist endgültig in Bezug auf die Frage, ob die Internet-Standardisierungsverfahren befolgt wurden oder nicht.
6.5.3 Fragen des anwendbaren Verfahrens (Questions of Applicable Procedure)
Weitere Rechtsmittel sind nur in Fällen verfügbar, in denen behauptet wird, dass die Verfahren selbst (d.h. die in diesem Dokument beschriebenen Verfahren) für den Schutz der Rechte aller Parteien in einem fairen und offenen Internet-Standardisierungsprozess unzureichend oder unzureichend sind. Ansprüche auf dieser Grundlage können beim Board of Trustees der Internet Society geltend gemacht werden. Der Präsident der Internet Society bestätigt eine solche Berufung innerhalb von zwei Wochen und teilt dem Petenten zum Zeitpunkt der Bestätigung die voraussichtliche Dauer der Überprüfung der Berufung durch die Trustees mit. Die Trustees überprüfen die Situation auf eine Weise ihrer eigenen Wahl und berichten der IETF über das Ergebnis ihrer Überprüfung.
Die Entscheidung der Trustees nach Abschluss ihrer Überprüfung ist endgültig in Bezug auf alle Aspekte der Streitigkeit.
6.5.4 Berufungsverfahren (Appeals Procedure)
Alle Berufungen müssen eine detaillierte und spezifische Beschreibung der Fakten der Streitigkeit enthalten.
Alle Berufungen müssen innerhalb von zwei Monaten nach öffentlicher Kenntnis der anzufechtenden Maßnahme oder Entscheidung eingeleitet werden.
In allen Phasen des Berufungsprozesses haben die Einzelpersonen oder Gremien, die für die Entscheidungen verantwortlich sind, das Ermessen, die spezifischen Verfahren zu definieren, die sie im Prozess der Entscheidungsfindung befolgen werden.
In allen Fällen muss eine Entscheidung über die Disposition der Streitigkeit und die Mitteilung dieser Entscheidung an die beteiligten Parteien innerhalb eines angemessenen Zeitraums erfolgen.
[HINWEIS: Diese Verfahren legen absichtlich und ausdrücklich keine feste maximale Zeitspanne fest, die in allen Fällen als "angemessen" angesehen werden soll. Der Internet-Standardisierungsprozess legt einen Wert auf Konsens und Bemühungen, ihn zu erreichen, und verzichtet bewusst auf deterministisch schnelle Ausführung von Verfahren zugunsten eines Spielraums, innerhalb dessen echte technische Vereinbarungen getroffen werden können.]