Das Tao von IETF: Ein Internet Engineering Task Force-Leitfaden für Einsteiger

Paul Hoffman, Editor


About This Document

Copyright © 2012 IETF Trust. All rights reserved.

The current version of this web page can always be found at http://www.ietf.org/tao.html; that page can also be retrieved protected by TLS. To contribute to this document or to discuss its content, please join the "tao-discuss" mailing list. A history of the major versions of the Tao can be found here. This particular version was created on 2012-11-02.

Diese Webseite ist in Deutsch. Unter finden Sie die Übersetzungen des Tao von IETF.


1. Introduction

Seit ihrer Gründung hat die Zahl der Teilnehmer an den persönlichen Treffen der Internet Engineering Task Force (IETF) beträchtlich zugenommen. An jedem IETF-Treffen nehmen viele neue Besucher teil, von denen viele regelmäßige Teilnehmer werden. Als die Treffen kleiner waren, war es für Neulinge relativ einfach, den richtigen Rhythmus zu finden. Heute trifft ein Neuling jedoch vermehrt auf neue Leute, die zuvor nur als die Autoren von Dokumenten oder zum Nachdenken anregenden E-Mails bekannt waren.

Dieses Dokument beschreibt viele Aspekte der IETF und erklärt Neulingen, wie die IETF funktioniert. Dies vermittelt Neulingen ein Gefühl der Vertrautheit und macht die Treffen und die Diskussionen der Arbeitsgruppen für alle Teilnehmer produktiver. Das Dokument war ursprünglich ziemlich kurz, aber wurde mit der Zeit größer, da die Vorschläge von IETF-Neulingen eingearbeitet wurden, die vor der Teilnahme an ihrem ersten persönlichen Treffen oder der aktiven Beteiligung an einer Arbeitsgruppe mehr wissen wollten.

Natürlich ist es wahr, dass viele IETF-Teilnehmer keine persönlichen Treffen besuchen. Stattdessen sind sie in der Mailingliste verschiedener IETF-Arbeitsgruppen aktiv. Da die internen Abläufe von Arbeitsgruppen für Neulinge schwer verständlich sein können, enthält dieses Dokumente allgemeine Informationen, die Neulinge benötigen, um aktive Teilnehmer zu werden.

Die IETF verändert sich ständig. Obwohl die in diesem Dokument erklärten Leitlinien sich im Großen und Ganzen nicht ändern sollten, haben sich einige praktische Details möglicherweise zum Zeitpunkt, an dem Sie das Dokumente lesen, geändert. Beispielsweise kann eine E-Mail-Adresse für eine bestimmte Anforderung durch ein Webtool ersetzt worden sein.

Im Tao werden viele IETF-Dokumenttypen erwähnt, beispielsweise BCPs, RFCs und STDs. BCPs enthalten Empfehlungen für Best Current Practices im Internet, RFCs sind die Hauptserie der technischen Dokumentation von IETF (Requests for Comments) und STDs sind RFCs, die als Standards identifiziert wurden. Eigentlich sind alle drei Dokumenttypen RFCs, siehe Section 6 für weitere Informationen.

Diese Website ist eine Fortsetzung der RFC-Serie „Tao von IETF“. Siehe [RFC6722] für eine Erklärung wie das letzte RFC in jener Serie diese Webseite wurde. Die Webversion des Tao basiert auf[RFC4677]und wurde zusammen mit Susan Harris verfasst. Die Originalversion des 1994 veröffentlichten Dokuments wurde von Gary Malkin geschrieben.

Warum „das Tao“? Tao ist das Grundprinzip der Lehre von Laotse, einem chinesischen Philosophen. Das vertraute Symbol ist der schwarzweiße Yin-Yang-Kreis. Der Taoismus begreift das Universum als einen einzigen Organismus und Menschen als voneinander abhängige Bestandteile eines kosmischen Ganzen. Tao wird manchmal als „der Weg“ übersetzt, aber gemäß der taoistischen Philosophie kann die wahre Bedeutung nicht in Worten ausgedrückt werden.

1.1 Im Tao verwendete Akronyme und Abkürzungen

Einige der in diesem Dokument verwendeten Akronyme und Abkürzungen sind im Folgenden aufgeführt.

Begriff Bedeutung
AD Area Director
BCP Best Current Practice
BOF Birds of a Feather
FAQ Häufig gestellte Fragen
FYI Zur Information (RFC)
IAB Internet Architecture Board
IAD IETF Administrative Director
IANA Internet Assigned Numbers Authority
IAOC IETF Administrative Oversight Committee
IASA IETF Administrative Support Activity
ICANN Internet Corporation for Assigned Names and Numbers
I-D Internet-Draft
IESG Internet Engineering Steering Group
IETF Internet Engineering Task Force
IPR Geistige Eigentumsrechte (Intellectual Property Rights)
IRTF Internet Research Task Force
ISOC Internet Society
RFC Request for Comments
STD Standard (RFC)
WG Arbeitsgruppe (Working Group)

2. Was ist die IETF?

Die IETF besteht aus einer lockeren, selbstorganisierten Gruppe, deren Mitglieder zur Planung und Weiterentwicklung von Internettechnologien beitragen. Die IETF ist das wichtigste Gremium, das an der Entwicklung neuer Internetstandards beteiligt ist. Die IETF ist ungewöhnlich, da sie aus Veranstaltungen besteht, aber kein Unternehmen ist und keinen Vorstand, keine Mitglieder und keine Gebühren hat siehe [BCP95], „A Mission Statement for the IETF“ (Missionserklärung der IETF) für weitere Informationen.

Die Mission umfasst Folgendes:

Das IETF-Treffen ist keine Konferenz, obwohl technische Präsentationen stattfinden. Die IETF ist keine herkömmliche Standardorganisation, obwohl viele ihrer Spezifikationen als Standards übernommen werden. Die IETF setzt sich aus Ehrenamtlichen zusammen, von denen sich viele drei Mal jährlich treffen, um die Mission von IETF zu realisieren.

Es gibt keine Mitgliedschaft in der IETF. Jeder kann sich für ein Treffen registrieren und daran teilnehmen. Die IETF-Mailingliste bzw. die Mailinglisten von Arbeitsgruppen kommen einer IETF-Mitgliedschaft am nächsten (siehe Section 2.3). Dort finden Sie die besten Informationen über aktuelle IETF-Aktivitäten und Schwerpunkte.

Natürlich kann keine Organisation wie die IETF ohne irgendeine Struktur erfolgreich sein. Im Fall von IETF basiert diese Struktur auf anderen Organisationen, die in [BCP11] „The Organizations Involved in the IETF Standards“ (die am IIETF-Standardisierungsprozess beteiligten Organisationen) beschrieben sind. Wenn Sie bei IETF mitmachen und lediglich ein BCP lesen wollen, ist das das Richtige.

Die IETF-Website http://www.ietf.org, ist die beste Informationsquelle für Treffen, Arbeitsgruppen, Internet-Drafts, RFCs, IETF E-Mail-Adressen und vieles mehr.

Die IETF baut in vielfältiger Weise auf der Überzeugung ihrer Teilnehmer auf. Eine der grundsätzlichen Überzeugungen wird durch ein Zitat über die IETF von David Clark versinnbildlicht: „Wir lehnen Könige, Präsidenten und Wahlen ab. Wir glauben an die grobe Übereinstimmung und das Ausführen von Code“. Ein weiteres Zitat, das zum allgemeinen Glauben an die IETF wurde, stammt vom Jon Postel: „Seien Sie konservativ beim Senden und liberal beim Annehmen“.

Die IETF dreht sich um ihre Teilnehmer. Da die IETF alle interessierten Personen willkommen heißt, kommen die IETF-Teilnehmer aus aller Welt und aus verschiedenen Bereichen der Internetbranche. Die IETF führt ihre Arbeit ausschließlich in Englisch durch. Siehe Section 3.12 für Informationen über die Art und Weise, in der viele Personen an der IETF teilnehmen.

Noch etwas, das für Neulinge wichtig ist: Die IETF betreibt das Internet in keiner Weise, ungeachtet dessen, was einige Leute fälschlicherweise sagen. Die IETF erstellt freiwillige Standards, die oft von Internetbenutzern übernommen werden, aber kontrolliert oder überwacht das Internet nicht. Wenn Sie an der IETF interessiert sind, da Sie einer der Aufpasser sein möchten, werden Sie wahrscheinlich sehr enttäuscht von der IETF sein.

2.1 Bescheidener Anfang

Das erste IETF-Treffen fand im Januar 1986 bei Linkabit in San Diego mit 21 Teilnehmern statt. Das vierte IETF-Treffen bei SRI in Menlo Park im Oktober 1986 war das erste Treffen, an dem Anbieter teilnahmen. Das Konzept von Arbeitsgruppen wurde auf dem fünften IETF-Treffen im NASA Ames Research Center in Kalifornien im Februar 1987 vorgestellt. Das siebte IETF-Treffen bei MITRE in McLean, Virginia, im Juli 1987 war das erste Treffen mit mehr als 100 Teilnehmern.

Das 14. IETF-Treffen wurde in der Stanford University im Juli 1989 abgehalten. Dieses Treffen stellte eine große Änderung in der Struktur des IETF-Universums dar. Die Struktur des IAB (früher Internet Activities Board, jetzt Internet Architecture Board), das bis zu diesem Zeitpunkt viele „Einsatzgruppen“ beaufsichtigte, wurde geändert. Es blieben nur zwei zurück: Die IETF und die IRTF. Die IRTF ist damit beauftragt, langfristige Forschungsprobleme im Internet zu untersuchen. Die IETF änderte sich zu diesem Zeitpunkt ebenfalls.

Nachdem die Internet Society (ISOC) im Januar 1992 gegründet wurde, schlug IAB vor, dass die IAB-Aktivitäten unter der Schirmherrschaft der Internet Society ausgeführt werden sollten. Auf der INET92 in Kobe, Japan, stimmten die ISOC-Beauftragten einer neuen Satzung für die IAB zu, um die vorgeschlagene Beziehung zu reflektieren.

Die IETF traf sich Amsterdam, Niederlande, im Juli 1993. Das war das erste IETF-Treffen in Europa. Die Teilnehmer kamen beinahe zu jeweils 50 Prozent aus den USA und aus anderen Ländern. Die IETF traf sich im Jahr 2000 zum ersten Mal in Asien (in Adelaide, Australien).

Die IETF trifft sich derzeit in Nordamerika, Europa und Asien. Das Ziel ist, sich in jeder Region einmal jährlich zu treffen. Aufgrund von Zeitplanproblemen finden jedoch mehr Treffen in Nordamerika als in Asien und Europa statt. Die Anzahl der Teilnehmer aus anderen Ländern ist weiterhin hoch und beträgt auch auf Treffen in den USA etwa 50 Prozent.

2.2 Die Hierarchie

2.2.1 ISOC (Internet Society)

Die Internet Society ist eine internationale, gemeinnützige Mitgliederorganisation, die die Erweiterung des Internets unterstützt. Eine der Methoden, mit denen die ISOC dies erreicht, ist die finanzielle und rechtliche Unterstützung der anderen „I“-Gruppen, die hier beschrieben sind, insbesondere der IETF. Die ISOC bietet Versicherungsschutz für viele der Personen mit Führungspositionen im IETF-Prozess und agiert als PR-Mittelsmann, wenn eine der „I“-Gruppen mit der Presse sprechen möchte. Die ISOC ist einer der weniger bekannten Zentralfiguren des Internets.

Im Frühjahr 2005 wurde die ISOC der Ausgangspunkt für die direkt angestellten administrativen Mitarbeiter der IETF. Dies wird ausführlicher in [BCP101]„ Structure of the IETF Administrative Support Activity (IASA)“ (Struktur der administrativen Unterstützung der IETF-Arbeit) beschrieben. Das Personal bestand ursprünglich nur aus einem Administrative Director (IAD), der die Planung der IETF-Treffen, die betrieblichen Aspekte der Supportservices, das Sekretariat, die IANA (Internet Assigned Numbers Authority) und den RFC Editor, die später in diesem Abschnitt beschrieben sind, sowie das Budget beaufsichtigt. Der AD leitet die IETF Administrative Support Activity (IASA), die beispielsweise die Gebühren für Treffen kassiert und Rechnungen bezahlt sowie die Tools unterstützt, die die IETF-Arbeitsgruppen, IESG, IAB und IRTF verwenden (mehr Info später in diesem Abschnitt).

Das IETF Administrative Oversight Committee (IAOC) setzt sich aus Ehrenamtlichen zusammen, die direkt oder indirekt von der IETF-Community gewählt werden, sowie aus geeigneten Mitgliedern von Amts wegen aus der ISOC und unter IETF-Führungskräften. Die IASA und der IAD unterstehen dem IAOC.

Weder der IAD noch das IAOC haben Einfluss auf die Entwicklung von IETF-Standards, die im Folgenden beschriebe wird.

2.2.2 IESG (Internet Engineering Steering Group)

Die IESG ist für die technischen Aspekte der IETF-Aktivitäten und die Vorgehensweise bei Internet-Normierungen verantwortlich. Sie verwaltet die Vorgehensweise entsprechend der Regeln und Verfahren, die vom ISOC-Board of Trustees ratifiziert wurden. Die IESG übernimmt jedoch keine direkte Leitung, wie dies in vielen anderen Normierungs-Organisationen üblich ist. Ihre Funktion ist, die Richtung festzulegen, statt Befehle zu erteilen. Die IESG ratifiziert oder lenkt die Ergebnisse der IETF-Arbeitsgruppen (WGs), richtet diese WGs ein und löst sie auf und stellt sicher, dass Entwürfe, die nicht von den Arbeitsgruppen stammen, korrekt sind, bevor diese RFCs werden.

Auf den IESG-Webseiten http://www.ietf.org/iesg.htmlfinden Sie aktuelle Informationen zu bearbeiteten Entwürfen, veröffentlichten RFCs und Dokumenten in Last Call sowie die monatlichen IETF-Statusberichte.

Die IESG besteht aus Area Directors ( auch „ADs“ genannt), die vom Nominations Committee (dem „NomCom“) für eine Zeitdauer von zwei Jahren gewählt werden. Das Verfahren für die Wahl von IESG-Mitgliedern ist in [BCP10]„IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees“ beschrieben.

Die aktuellen Bereiche und Abkürzungen sind im Folgenden aufgeführt.

Bereich Beschreibung
Anwendungen (APP) Protokolle für Benutzerprogramme, beispielsweise E-Mail und das Web
Allgemein (GEN) IETF-Prozess und Catch-All für WGs, die nicht in andere Bereiche passen (dies sind nur wenige)
Internet (INT) Verschiedene Methoden zum Senden von IP-Paketen und DNS-Informationen
Betrieb und Management (OPS) Betriebliche Aspekte, Netzwerküberwachung und Konfiguration
Echtzeit-Anwendungen und Infrastruktur (RAI) Verzögerungsempfindliche persönliche Kommunikation
Routing (RTG) Übermitteln von Paketen an ihr Ziel
Sicherheit (SEC) Authentifizierung und Datenschutz
Transport (TSV) Spezielle Services für spezielle Pakete

Da die IESG großen Einfluss darauf hat, ob Internet-Entwürfe RFCs werden, werden ADs von vielen Leuten als gottähnliche Geschöpfe betrachtet. IETF Teilnehmer fragen Area Directors häufig nach ihrer Meinung zu einem bestimmten Thema. Die meisten ADs unterscheiden sich jedoch nicht von einfachen Sterblichen und halten nur selten Bergpredigten. Tatsächlich verweisen ADS oft auf IETF-Teilnehmer, die ihrer Meinung nach mehr Kenntnisse über das entsprechende Thema haben.

Es wird erwartet, dass die ADs für einen bestimmten Bereich, mehr über die Arbeit der WGs in diesem Bereich wissen, als jeder andere. Andererseits überprüft die gesamte IESG alle Internet-Entwürfe, die eine RFC werden sollen. Jeder AD kann eine „DISCUSS“-Abstimmung für einen Entwurf veranlassen, wenn er ernsthafte Bedenken hat. Wenn diese Bedenken nicht durch Gespräche beseitigt werden können, wird ein Override-Verfahren definiert, das besagt, dass mindestens zwei IESG-Mitglieder Bedenken äußern müssen, bevor ein Entwurf blockiert werden kann. Diese Verfahren stellen sicher, dass das „Lieblingsprojekt“ eines ADs nicht zum Standard wird, wenn es sich negativ auf den Rest der IETF-Protokolle auswirkt, und dass das „Hauptärgernis“ eines ADs etwas nicht unbegrenzt blockieren kann.

Das heißt nicht, dass die IESG keine Macht ausübt. Die IESG reagiert, wenn eine Arbeitsgruppe von ihrer Satzung abweicht oder eine WG die IESG auffordert, ein schlechtes Protokoll als Standard zu übernehmen. Aufgrund ihrer hohen Arbeitslast ist die IESG normalerweise reaktiv. Sie genehmigt die meisten Anforderungen von Arbeitsgruppen, dass Internet-Entwürfe RFCs werden und greift normalerweise nur ein, wenn etwas schiefläuft. Eine andere Betrachtungsweise ist, dass die ADs gewählt werden, um zu denken, nicht, um nur den Prozess auszuführen. Die Qualität der IETF-Standards basiert auf der Überprüfung durch die Arbeitsgruppen und Kontrolle dieser Überprüfung durch die ADs.

Die IETF basiert auf einem groben Konsens, und die IESG beurteilt, ob eine WG ein Ergebnis liefert, das den Konsens der IETF-Gemeinde hat. (Siehe Section 4.2 für weitere Informationen zum WG-Konsens.)Einer der Hauptgründe, dass die IESG etwas blockiert, das von einer WG produziert wurde, ist, dass das Ergebnis nicht den Konsens der gesamten IETF (der Arbeitsgruppen in allen Bereichen) erhalten hat. Beispielsweise kann das Ergebnis einer WG in Konflikt mit einer Technologie stehen, die von einer anderen Arbeitsgruppe aus einem anderen Bereich entwickelt wurde. Ein wichtige Aufgabe der IESG ist, die Ergebnisse aller WGs zu überwachen, um IETF-Protokolle zu verhindern, die miteinander in Konflikt stehen. Aus diesem Grund müssen ADs die Entwürfe aus anderen Bereichen überprüfen.

2.2.3 IAB (Internet Architecture Board)

Die IAB ist dafür verantwortlich, das „Big Picture“ des Internets zu beobachten und sich auf die langfristige Planung und Koordination der verschiedenen Bereiche der IETF-Aktivität zu konzentrieren. Die IAB ist auf dem Laufenden bezüglich wichtiger langfristiger Angelegenheiten im Internet und lenkt die Aufmerksamkeit der Leute, die sich damit befassen sollten, auf diese Themen.

IAB-Mitglieder achten besonders auf bevorstehende Aktivitäten in der IETF. Wenn eine neue IETF-Arbeitsgruppe vorgeschlagen wird, überprüft die IAB ihre Satzung auf architektonische Konsistenz und Integrität. Bevor die Gruppe gegründet wird, sind die IAB-Mitglieder bereit, neue Ideen mit den Leuten zu diskutieren, die diese vorschlagen.

Die IAB sponsert und organisiert auch die Internet Research Task Force und lädt zu Workshops für umfassende Überprüfungen bestimmter Internet-Architekturprobleme ein. Das Ergebnis eines Workshops ist normalerweise eine Empfehlung für die IETF-Gemeinde und die IESG.

Weitere Aufgaben der IAB:

Wie die IESG werden die IAB-Mitglieder von NomCom für einen Zeitraum von zwei Jahren gewählt und vom ISOC-Überwachungsausschuss genehmigt.

2.2.4 IANA (Internet Assigned Numbers Authority)

Der Hauptregistrar für die IETF-Aktivitäten ist IANA (siehe http://www.iana.org). Viele Internetprotokolle erfordern, dass die Protokollelemente, die nach Freigabe des Protokolls hinzugefügt wurden, nachverfolgt werden. Typische Beispiele der erforderlichen Registrierungen sind für TCP-Portnummern und MIME-Typen. Die IAB hat die IANA-Organisation mit der Ausführung dieser Aufgaben beauftragt. Die IANA-Aktivitäten werden von ICANN (Internet Corporation for Assigned Names and Numbers) finanziell unterstützt. Die IAB hat ICANN gewählt, und die IANA-Aktivitäten sind kostenlos, wie angegeben in [RFC2860].

Vor 10 Jahren hat niemand gedacht, dass die IANA auf dem Titelblatt einer Zeitung auftauchen würde. Die Rolle von IANA war immer eher zurückhaltend. Die Tatsache, dass die IANA die Hüterin der Wurzel des Domain Name Systems war, hat sie gezwungen, eine öffentliche Einrichtung zu werden, die von verschiedenen Leuten, die niemals ihre Aufgabe betrachteten, schlechtgemacht wurde. Heute ist die IETF gewöhnlich nicht mehr an der Zuweisung von Domänennamen und IP-Adressen durch die IANA beteiligt, da diese von der ICANN beaufsichtigt werden.

Obwohl die Rolle eines Registrars möglicherweise nicht interessant zu sein scheint, werden viele IETF-Teilnehmer bezeugen, wie wichtig die IANA für das Internet war. Ein stabiles, langfristiges, von sorgfältigen und konservativen Betreibern administriertes Repositorium vereinfacht das Experimentieren, ohne sich darum sorgen zu müssen, dass etwas verpfuscht wird. Viele verließen sich auf Jon Postel, den Gründer von IANA, um alles in Ordnung zu halten, während das Internet sprunghaft wuchs. Er erledigte diese Aufgabe bis zu seinem frühzeitigen Tod im Jahr 1998.

2.2.5 RFC Editor

Der RFC Editor bearbeitet, formatiert und veröffentlicht Internet-Entwürfe als RFCs in Zusammenarbeit mit der IESG. Eine wichtige sekundäre Rolle ist das Bereitstellen eines definitiven Repositoriums für alle RFCs (siehe http://www.rfc-editor.org). Nachdem eine RFC veröffentlicht ist, wird sie nicht mehr geändert. Wenn die RFC-Spezifikation geändert wird, wird der Standard in einem anderen RFC veröffentlicht und ersetzt den ersten Standard.

Eines der häufigsten Missverständnisse in der IETF-Gemeinde ist, dass die Rolle des RFC Editors von IANA ausgeführt wird. Obwohl viele Jahre lang die gleichen Leute beim RFC Editor und bei IANA beteiligt waren, ist der RFC Editor eine separate Aufgabe. Heute werden diese Aufgaben von separaten Organisationen ausgeführt. Die IAB genehmigt die Organisation, die als RFC Editor agiert, und die allgemeine Richtlinie des RFC Editors. Der RFC Editor wird von IASA finanziert.

Bis Ende 2009 war der RFC Editor eine einzige Einheit. Die Funktion wurde von der IAB zusammen mit der IETF-Gemeinde in mehrere Rollen aufgeteilt, die von verschiedenen Personen oder Organisationen ausgeführt werden können, die vom RFC Series Editor, der von IAB benannt wird, geleitet werden. Das RFC Editor-Modell ist beschrieben in [RFC6635].

2.2.6 IETF Secretariat

Es gibt tatsächlich einige Leute, die bezahlt werden, um IETF zu verwalten. Das IETF Sekretariat ist für die tägliche logistische Unterstützung zuständig, hauptsächlich für die Koordination persönlicher Treffen und die IETF-spezifischen Mailinglisten. Das Sekretariat ist außerdem dafür verantwortlich, das offizielle Internet-Entwurfsverzeichnis auf dem neuesten Stand zu halten, die IETF-Website zu verwalten und die Arbeit der IESG zu unterstützen. Das Sekretariat stellt verschiedene Tools für die Gemeinde und die IESG bereit. Das IETF-Sekretariat untersteht der IASA, die wiederum durch die Gebühren für die persönlichen Treffen finanziell unterstützt wird.

2.2.7 IETF Trust

Ende 2005 wurde der IETF Trust für den Besitz und die Lizenzierung des geistigen Eigentums der IETF ins Leben gerufen. Der Grund für den IETF Trust ist, dass jemand das geistige Eigentum besitzen muss und dass dies eine stabile juristische Person sein sollte. Bei den IETF-Treuhändern handelt es sich um IAOC-Mitglieder zu einem gegebenen Zeitpunkt. Nur wenige IETF-Teilnehmer kommen in Kontakt mit dem IETF Trust. Das ist ein gutes Zeichen, dass sie ihre Arbeit erledigen. Weitere Informationen zum IETF Trust finden Sie auf der Website http://trustee.ietf.org.

2.3 IETF Mailinglisten

Jeder, der die Teilnahme an einem IETF-Treffen plant, sollte sich für die Mailinglist für IETF-Ankündigungen registrieren lassen (siehe https://www.ietf. org/mailman/listinfo/IETF-Announce). Dort werden alle Informationen über Treffen, RFC-Ankündigungen und „IESG Protocol Actions and Last Calls“ veröffentlicht. Wenn Sie sich für Technik interessieren, sollten Sie sich für die allgemeine IETF-Diskussionsliste registrieren lassen (siehe https://www.ietf.org/ mailman/listinfo/ietf). Hier finden Diskussionen von kosmischer Wichtigkeit statt (Arbeitsgruppen haben ihre eigenen Mailinglisten für Diskussionen, die sich auf ihre Arbeit beziehen). Eine weitere Mailingliste kündigt jede neue Version eines Internet-Entwurfs an, sobald er veröffentlicht wird (siehe https://www.ietf. org/mailman/listinfo/I-D-Announce).

Abonnements für diese und andere IETF-Mailinglisten werden von einem Programm namens „Mailman“ verwaltet. Dieser Postbote kann etwas pingelig bezüglich des Formats von Abonnementnachrichten sein und funktioniert manchmal nicht gut mit E-Mail-Programmen, die alle E-Mails in HTML-Dateien umwandeln. Mailman ist jedoch freundlich, wenn Sie Ihre Nachrichten richtig formatieren.

Die IETF-Diskussionsliste ist unmoderiert. Das heißt, dass jeder seine Meinung zu Angelegenheiten, die das Internet betreffen, sagen kann. Es ist jedoch kein Ort für Unternehmen oder Einzelpersonen, um für etwas zu werben. Siehe [BCP45], „IETF Discussion List Charter“. Es ist eine gute Idee, den gesamten RFC zu lesen (er ist kurz!), bevor Sie einen Beitrag in der IETF-Diskussionsliste veröffentlichen. Die Liste hat zwei „Ordnungshüter“, die nach unangemessenen Beiträgen Ausschau halten. Wiederholte Übeltäter werden aus der Liste verbannt, aber das kommt glücklicherweise nur sehr selten vor.

Nur das Sekretariat und einige IETF-Führungskräfte können Nachrichten genehmigen, die an die Ankündigungsliste gesendet werden, obwohl diese Nachrichten von verschiedenen Personen stammen können.

Obwohl die IETF-Mailingslisten die IETF-Teilnehmer repräsentieren, sollten Sie beachten, dass die Teilnahme an einem IETF-Treffen nicht bedeutet, dass Sie automatisch zu einer Mailingliste hinzugefügt werden.


3. IETF-Treffen

Die Computerbranche ist voller Konferenzen, Seminare, Ausstellungen und vielen anderen Treffen. Die persönlichen IETF-Treffen sind vollkommen anders. Die drei Mal jährlich stattfindenden Treffen sind eine Woche dauernde Zusammenkünfte mit dem primären Ziel, die Arbeitsgruppen neu zu beleben, damit diese ihre Aufgaben erledigen können. Das sekundäre Ziel ist, die Arbeitsgruppen und Bereiche zusammenzubringen. Die Kosten der Treffen werden von den Teilnehmern und gegebenenfalls dem Gastgeber bezahlt, obwohl IASA zusätzliche Gelder bereitstellt, beispielsweise für den Audiobroadcast einiger Arbeitsgruppensitzungen.

Für viele Teilnehmer sind die IETF-Treffen im Vergleich mit den normalen Konferenzen der Computerbranche ein frischer Wind. Es gibt keine Ausstellungshalle, nur wenige Seminare und keine Branchengrößen. Stattdessen gibt es eine Menge Arbeit und ziemlich viel Zeit zum Knüpfen von Kontakten. IETF Treffen sind für Vertriebs- und Marketingmitarbeiter nicht interessant, aber für Ingenieure und Entwickler.

Normalerweise beginnt ein IETF-Treffen mit Seminaren und einer informellen Zusammenkunft am Sonntag. Von Montag bis Freitag finden WG- und BoF-Treffen statt. WG-Treffen dauern jeweils zwischen einer und 2,5 Stunden, und einige WGs treffen sich mehrmals, abhängig von ihrer anstehenden Arbeit.

Abends finden jeweils ein technische und eine administrative Plenarsitzung statt. Die technische Plenarsitzung wird von der IAB organisiert und hat normalerweise zwei Fachgremien für interessante Themen der WGs und Bereiche. Die administrative Plenarsitzung, die vom IETF-Vorsitzenden organisiert wird, befasst sich beispielsweise mit den Statusberichten des RFC Editors und den Ankündigungen künftiger Treffen. Die Plenarsitzungen sind ein guter Zeitpunkt für die Kommunikation mit der IESG und IAOC. Lob ist willkommen, aber Bedenken und Beschwerden sind öfter zu hören.

Die IETF trifft sich derzeit in Nordamerika, Europa und Asien (ca. einmal jährlich in jeder Region). Die letzten Treffen hatten etwa 1200 Besucher. Bis heute fanden mehr als 80 IETF-Treffen statt, und eine Liste der künftigen Treffen ist auf der IETF-Website verfügbar.http://www.ietf.org/meeting/upcoming.html.

Neue Teilnehmer sind oft etwas schockiert. Sie erwarten, dass die IETF-Treffen so wie die Treffen anderer Standardisierungsorganisationen oder wie Computerkonferenzen sind. Glücklicherweise legt sich der Schock nach einem oder zwei Tagen und viele neue Teilnehmer haben viel Spaß. Andererseits können IETF-Mitglieder manchmal erstaunlich rüpelhaft sein, beispielsweise wenn sie während einer Präsentation in das Mikrophon sprechen oder sich den Weg durch eine Menge zum Buffet bahnen. Dieses Verhalten scheint auf IETF-Treffen üblicher als auf anderen Computerkonferenzen zu sein.

3.1 Registrierung

Um an einem IETF-Treffen teilzunehmen, müssen Sie sich registrieren lassen und eine Gebühr bezahlen. Der Ort des Treffens und die Registrierung werden etwa zwei Monate vor dem Treffen bekanntgegeben (oder früher, wenn das möglich ist). Eine Ankündigung wird per E-Mail an die IETF-Mailingliste für Ankündigungen gesendet, und die Informationen werden am selben Tag auf der IETF-Websitehttp://www.ietf.orgveröffentlicht .

Sie können sich auf der Website oder vor Ort registrieren lassen und für das Treffen bezahlen. Um eine niedrigere Registrierungsgebühr zu erhalten, müssen Sie die Gebühr bis zur Anmeldefrist (etwa eine Woche vor dem Treffen) bezahlen. Die Registrierungsgebühr deckt alle Treffen ab, die in dieser Woche stattfinden, den Empfang am Sonntag Abend (Cash-Bar), das tägliche kontinentale Frühstück sowie den Imbiss am Nachmittag.

Die Registrierung ist die ganze Woche über möglich. Das Sekretariat empfiehlt jedoch, dass die Teilnehmer frühzeitig zur Registrierung eintreffen, normalerweise vom Sonntag Mittag an und dann weiter den ganzen Empfang über am Sonntag Abend. Der Empfang ist eine beliebte Veranstaltung, auf der Sie etwas essen und mit anderen Teilnehmern Kontakte knüpfen können.

Es ist erwähnenswert, dass weder die Namen und Adressen der Teilnehmer noch die IETF-Mailinglisten verkauft werden.

Bevor Sie sich registrieren, sehen Sie die Webseite „Note Well“. Sie sollten diese Webseite sorgfältig lesen, da sie die Regeln für die geistigen Eigentumsrechte der IETF erklärt.

Auf den Pinnwänden in der Nähe der Rezeption können Sie Nachrichten für andere Teilnehmer hinterlassen. Auf den Pinnwänden finden Sie auch kurzfristige Treffen- und Raumänderungen.

Bei der Rezeption können Sie auch gefundene Gegenstände abgeben. Am Ende des Treffens werden alle gefundenen Gegenstände, die nicht abgeholt wurden, an das Hotel übergeben oder in das Büro des Sekretariats gebracht.

Die IETF-Rezeption ist oft auch ein praktischer Ort, um Treffen mit anderen Leuten zu arrangieren. Wenn jemand sagt „Triff mich an der Rezeption“, sollten Sie abklären, ob er die IETF-Rezeption oder die Hotelrezeption meint. Dies war eine häufige Ursache für verpasste Treffen.

3.2 Wagen Sie es und bleiben Sie die ganze Woche!

Die IETF WG-Treffen finden von Montag Morgen bis Freitag Nachmittag statt. Die entsprechenden Nicht-WG-Treffen werden oft am vorhergehenden oder folgenden Wochenende abgehalten. Am besten planen Sie, die ganze Woche anwesend zu sein, um von den Arbeitsgruppen und Diskussionen auf dem Gang zu profitieren. Wie im Folgenden beschrieben ist die Tagesordnung flexibel und viele Teilnehmer haben wichtige Sitzungen verpasst, da der Zeitplan kurzfristig geändert wurde, nachdem sie ihren Reiseplan festgelegt hatten. Dieses Ärgernis können Sie nur vermeiden, wenn Sie die ganze Woche anwesend sind.

Wenn Sie keine Treffen finden, die für Sie interessant sind, können Sie das beste aus den IETF-Treffen machen, indem Sie zwischen den Sitzungen arbeiten. Die meisten IETF-Teilnehmer haben Laptops und arbeiten während der Sitzungen oft im Terminalraum oder in den Gängen. Viele Orte (Restaurants, Cafés usw.), an denen die Treffen stattfinden, haben eine gute Internet-Drahtlosverbindung, und das Lesen von E-Mails ist eine übliche Beschäftigung für IETF-Teilnehmer außerhalb der Treffen.

3.3 Training für Anfänger

Neulinge sollten an der Orientierung am Sonntag Nachmittag teilnehmen, die speziell für neue Teilnehmer abgehalten wird. Die Orientierung, die vom IETF EDU-Team organisiert und abgehalten wird, bietet nützliche Informationen für Neulinge. Die Sitzung erklärt, was die Punkte auf den Namensschildern bedeuten, die Struktur der IETF und viele andere für IETF-Mitglieder wichtige Themen.

Später am Nachmittag findet das „Meet and Greet“ für Neulinge statt, an dem ausschließlich Neulinge und WG-Vorsitzende teilnehmen. Dies ist eine hervorragende Gelegenheit, um Leute mit Kenntnissen in den Bereichen zu treffen, an denen Sie interessiert sind. Sie können mit allen WG-Vorsitzenden sprechen, nicht nur mit denen in Ihrem Bereich, um mehr über die WG zu erfahren oder um jemanden in Ihrer zu finden.

3.4 Dress Code

Da Teilnehmer ein Namensschild tragen müssen, müssen sie auch Hemden oder Blusen tragen. Hosen oder Röcke sind ebenfalls sehr empfehlenswert. Ernsthaft, viele Neulinge geraten in Verlegenheit, wenn Sie am Montag im Anzug auftauchen und feststellen, dass alle anderen T-Shirts, Jeans (oder Shorts, wenn es das Wetter erlaubt) und Sandalen tragen. Es gibt IETF-Mitglieder, die sich weigern, etwas anderes als Anzüge zu tragen. Zum Glück sind diese Mitglieder bekannt (aus anderen Gründen) und diese Eigenart wird vergeben. Die allgemeine Regel ist, sich wettergemäß anzuziehen (außer wenn Sie planen, so hart zu arbeiten, dass Sie keine Zeit haben, nach draußen zu gehen. Ziehen Sie sich in diesem Fall bequem an.

3.5 WG-Treffen

Das Herzstück eines IETF-Treffens sind die WG-Treffen. Die WG-Vorsitzenden haben unterschiedliche Stile und es ist unmöglich, die WG-Treffen zu verallgemeinern. Obwohl beinahe alle WGs Tagesordnungen für ihre Treffen haben, halten sich einige Treffen streng an die Tagesordnung, während andere Treffen lockerer sind.

Einige wenige wichtige Dinge gelten jedoch für alle WG-Treffen. Zu Beginn eines Treffens teilt der Vorsitzende blaue Formulare aus, auf die alle Teilnehmer ihren Namen und ihre E-Mail-Adresse schreiben. Die Formulare werden für die langfristige Archivierung verwendet, um zu sehen, wie viele Personen an einem bestimmten Treffen teilgenommen haben, und in seltenen Fällen, wer teilgenommen hat. Die normale Etikette ist, die blauen Formulare in die Richtung weiterzugeben, aus der sie gekommen sind.

Wenn Sie auf einem Treffen sprechen, sollten Sie immer ein im Raum befindliches Mikrofon verwenden. Für brisante Themen wird sich eine Schlange am Mikrofon bilden, aber zögern Sie nicht, der erste am Mikrofon zu sein, wenn Sie eine Frage haben oder an der Diskussion teilnehmen möchten. Der WG-Vorsitzende oder Präsentator lässt Sie wissen, wenn Sie sprechen können. Obwohl es einfacher wäre, einfach die Hand zu heben, erfüllen die Mikrofone einen nützlichen Zweck: Remoteteilnehmer oder die Teilnehmer im Raum hören Ihre Frage oder Ihren Kommentar. Es wird erwartet, dass Sie Ihren Namen sagen, damit die Person, die Notizen macht, weiß, wer spricht.

3.6 Die Punkte vor Ihren Augen ansehen

Einige IETF-Teilnehmer haben einen kleinen farbigen Punkt auf ihrem Namensschild. Einige Teilnehmer haben mehrere Punkte. Diese Punkte identifizieren Teilnehmer, die verrückt genug sind, um freiwillig zusätzliche Arbeit zu übernehmen. Die Farben haben die folgenden Bedeutungen.

Farbe Bedeutung
Blau Arbeitsgruppe/BOF-Vorsitzender
Grün Gastgebergruppe
Rot IAB-Mitglied
Gelb IESG-Mitglied
Orange Nominating Committee-Mitglied
Lila IAOC
Rosa IRSG
Türkis RSE

(Pressemitglieder haben orange Namensschilder.)

Die Gastgeber können Fragen bezüglich des Terminalraums, der Restaurants und Sehenswürdigkeiten in der Region beantworten.

Es ist wichtig, dass IETF-Neulinge nicht zurückhaltend sind, Gespräche mit den Personen zu führen, die Punkte haben. Wenn die IAB- und IESG-Mitglieder sowie die WG- und BOF-Vorsitzenden nicht mit jemandem sprechen möchten, würden sie diese Punkte nicht tragen. Beachten Sie jedoch, dass IETF-Treffen normalerweise anstrengend für Area Directors sind. Wenn Sie auf einem IETF-Treffen mit einem AD sprechen, fordert Sie dieser oft auf, ihm zwei Wochen später eine E-Mail zu senden. Wenn Sie im Gang ein Gespräch mit einem Area Director (oder einem WG-Vorsitzenden) beginnen, sollten Sie diesem eine etwa 30 Sekunden lange Erklärung für das Gespräch geben.

3.7 Terminal-Raum

Eines der wichtigste Dinge (abhängig von Ihrem Blickwinkel), die der Gastgeber bereitstellt, ist der Internetzugriff für die Teilnehmer. Im Allgemeinen ist die Drahtlosverbindung in allen Räumen und den meisten Aufenthaltsbereichen hervorragend. Kabelverbindungen sind verfügbar im Terminalraum. Wir möchten uns bei den Personen und Unternehmen bedanken, die Geräte, Services und ihre Zeit bereitstellen.

Obwohl eine frühzeitige Vorbereitung des Treffens empfohlen wird, gibt es möglicherweise einige nicht vermeidbare kurzfristige Vorbereitungen, die im Terminalraum ausgeführt werden können. Dies kann auch nützlich für Teilnehmer sein, die Reise- oder Statusberichte erstellen müssen, solange die Erinnerung noch frisch ist.

Sie müssen Ihr Namensschild tragen, um in den Terminalraum zu gehen. Der Terminalraum ist mit Mehrfachsteckdosen, Ethernet-Ports für Laptops, Drahtloszugang (für Teilnehmer, die kein Ethernet benötigen), Druckern und manchmal Arbeitsstationen ausgestattet. Was der Terminalraum nicht enthält sind Terminals. Der Name ist historisch. Das Helpdesk im Terminalraum ist eine gute Anlaufstelle bei Netzwerkproblemen, obwohl Sie möglicherweise an einen anderen Mitarbeiter verwiesen werden.

3.8 Mahlzeiten und andere Freuden

Marshall Rose sagte, dass die IETF ein Ort für viel gutes Essen ist. Obwohl es wahr ist, dass einige Leute sehr gut essen, müssen sie die Plätze zum Essen selbst finden, da Mittag- und Abendessen nicht in der Registrierungsgebühr enthalten sind. Das Sekretariat stellt Imbisse am Sonntag Abend für den Empfang (kein Ersatz für Abendessen), ein kontinentales Frühstück von Montag bis Freitag (abhängig vom Ort des Treffens) sowie Kekse, Brownies, Obst und Anderes an einigen Nachmittagen bereit. Diese werden oft vom Gastgeber oder einem Sponsor bezahlt.

Wenn Sie nicht im Hotel essen möchten, hat der Gastgeber normalerweise eine Liste der Restaurants in der Nähe des Treffens.

3.9 Gesellschaftliches Ereignis

Eine andere wichtige Sache, die vom Gastgeber organisiert wird, ist ein gesellschaftliches Ereignis der IETF. Das gesellschaftliche Ereignis ist manchmal eine Veranstaltung in High-Tech-Umgebung, aber kann auch in einem Kunstmuseum oder einem Empfangssaal sein. Beachten Sie jedoch, dass nicht alle IETF-Treffen ein gesellschaftliches Ereignis umfassen.

Neulinge sollten am gesellschaftlichen Ereignis teilnehmen, ihr Namensschild tragen und ihren Laptop zurücklassen. Das gesellschaftliche Ereignis gibt den Teilnehmern die Chance, sich auf einer sozialen anstatt technischen Ebene zu treffen.

3.10 Tagesordnung

Die Tagesordnung von IETF-Treffen ist ausgesprochen flexibel. Sie ist einige Wochen vor dem Treffen im Web verfügbar. An der Rezeption werden kleine Tagesordnungen an Teilnehmer mit gutem Augenlicht ausgegeben, die eine Kopie mit sich herumtragen möchten. Natürlich bedeutet „fertig“ in der IETF nicht das gleiche, wie überall sonst. Die fertige Tagesordnung ist lediglich die Version, die gedruckt wurde. Das Sekretariat hängt Änderungen der Tagesordnung am Schwarzen Brett in der Nähe der IETF-Rezeption (nicht der Hotelrezeption) aus. Diese kurzfristigen Änderungen sind nicht willkürlich, sondern werden gerade noch rechtzeitig vorgenommen, wenn Vorsitzende und Sprecher nicht vorhergesehene Konflikte bemerken. Die IETF ist zu dynamisch für Tagesordnungen, die Wochen im Voraus erstellt werden.

Die Tagesordnung enthält auch eine Karte der Räume. Räume können sich entsprechend der Tagesordnung ändern. Einige Arbeitsgruppen treffen sich mehrmals und möglichst im gleichen Raum.

3.11 Schulungen zum Weiterkommen

Wenn Sie bestimmte Aspekte der IETF immer noch verwirren (auch nachdem Sie das Tao gelesen haben), können Sie an einer Schulung des EDU-Teams (Education-Teams) teilnehmen. Es gibt informelle Kurse für Neulinge und erfahrene IETF-Mitglieder. Zusätzlich zur Schulung für Neulinge bietet das EDU-Team Workshops für Dokumenteditoren und WG-Vorsitzende sowie ein Sicherheitsseminar an, das sowohl für Einsteiger als auch erfahrene IETF-Mitglieder unentbehrlich ist. EDU-Sitzungen finden normalerweise Sonntag Nachmittag statt. Weitere Informationen zum EDU-Team finden Sie unter http://www.ietf.org/edu/.

3.12 Wo passe ich rein?

Die IETF bedeutet für jeden etwas anderes. Es gibt viele Leute, die in der IETF sehr aktiv sind und nie an einem IETF-Treffen teilgenommen haben. Sie sollten sich nicht zur Teilnahme an einem IETF-Treffen verpflichtet fühlen. Die folgenden Richtlinien (basierend auf den Klischees von Leuten aus verschiedenen Branchen) können Ihnen helfen zu entscheiden, ob Sie an einem Treffen teilnehmen möchten und wie Sie Ihre Zeit auf dem ersten Treffen am besten nutzen.

3.12.1 IS-Manager

Wie in diesem Dokument bereits erwähnt, hat ein IETF-Treffen nichts mit den Messen gemeinsam, die Sie besucht haben. IETF-Treffen sind ein schlechter Ort, um herauszufinden, was nächstes Jahr in der Internetbranche angesagt ist. Sie können davon ausgehen, dass Sie die Teilnahme an WG-Treffen eher verwirren als helfen wird, zu verstehen, was in der Branche passiert bzw. passieren wird.

Das heißt jedoch nicht, dass niemand aus der Branche an IETF-Treffen teilnehmen sollte. Als IS-Manager könnten Sie die Mitarbeiter, die für die von der IETF entwickelten Technologien verantwortlich sind, zu einem Treffen schicken wollen. Wenn diese Mitarbeiter die aktuellen Internet-Entwürfe lesen und die relevanten WG-Listen überprüfen, können sie bestimmen, ob die Teilnahme für Ihr Unternehmen oder die Arbeitsgruppen interessant ist.

3.12.2 Netzwerker und Internetprovider

Das Betreiben eines Netzwerks ist schwierig genug, ohne sich mit neuen Protokollen oder neuen Versionen der vorhandenen Protokolle herumschlagen zu müssen. Wenn Ihr Netzwerk immer die neueste Hardware und Software verwendet und Sie in Ihrer Freizeit den relevanten Arbeitsgruppen folgen, ist die Teilnahme in der IETF möglicherweise hilfreich. Ein großer Teil der Arbeit von IETF befasst sich mit vielen anderen betrieblichen Aspekten von ISPs und großen Unternehmen, und der Input von Betreibern kann sich als nützlich erweisen, damit die Arbeit dynamisch und relevant bleibt. Viele der besten Betriebsdokumente von IETF stammen von Betreibern, nicht von Anbietern oder Akademikern.

3.12.3 Verkäufer von Netz-Hardware und -Software

Die Meinung, dass die IETF hauptsächlich aus weltfremden Akademikern besteht, war in der Vergangenheit möglicherweise wahr, aber die Aufgaben typischer Teilnehmer sind heute branchenbezogen. In den meisten Bereichen der IETF schreiben die Mitarbeiter von Anbietern die Protokolle und leiten die Arbeitsgruppen. Daher ist es angebracht, dass Anbieter teilnehmen. Wenn Sie Hardware und Software für das Internet entwickeln und noch niemand aus Ihrem Unternehmen an einem IETF-Treffen teilgenommen hat, sollten Sie zu einem Treffen kommen, um herauszufinden, ob das Treffen für Sie relevant ist oder Ihr Unternehmen nicht betrifft.

Das heißt nicht, dass Unternehmen während eines IETF-Treffens den Laden dicht machen sollten, damit alle Mitarbeiter am Treffen teilnehmen können. Marketing-Mitarbeiter (auch technisch versierte) können sich normalerweise von der IETF fernhalten, wenn einige technische Mitarbeiter des Unternehmen teilnehmen. Desgleichen ist es nicht erforderlich oder nützlich, dass alle Mitarbeiter einer technischen Abteilung am Treffen teilnehmen, insbesondere wenn nicht alle die Internet-Entwürfe lesen und in den WG-Mailinglisten registriert sind. Viele Unternehmen schicken nur einige Teilnehmer, die vollständige und nützliche Reiseberichte erstellen können. Außerdem besitzen viele Unternehmen interne Koordinierungsmechanismen und eine Normierungsstrategie. Wenn das Geschäft eines Unternehmens ganz oder teilweise vom Internet abhängig ist, sollte die Strategie die IETF einbeziehen.

3.12.4 Akademiker

IETF-Treffen eignen sich oft hervorragend für Informatiker, um herauszufinden, was bezüglich neuer Protokolle angesagt ist. Professoren und Hochschulabsolventen (und manchmal auch ehrgeizige Studenten), die Netzwerkbetrieb oder Kommunikationswesen untersuchen, erhalten eine Unmenge an Informationen von den Arbeitsgruppen in ihrem Interessenbereich. Die Teilnahme an verschiedenen WG-Treffen kann den gleichen Effekt wie die Teilnahme an einem Symposium oder Seminar in Ihrer Abteilung haben. Forscher sind wahrscheinlich auch an den IRTF-Aktivitäten interessiert.

3.12.5 Computer Fachpresse

Wenn Sie ein Pressemitarbeiter sind und die Teilnahme an der IETF-Treffen erwägen, haben wir speziell für Sie einen Abschnitt des Tao vorbereitet, siehe Section 8.2.

3.13 Proceedings

Die IETF-Proceedings werden in den beiden Monaten nach einem Treffen zusammengestellt und sind im Web verfügbar. Sie sollte diese lesen, da die Proceedings Informationen enthalten, die Sie wahrscheinlich nirgendwo anders finden werden. Beispielsweise finden Sie Snapshots der meisten WG-Satzungen zum Zeitpunkt des Treffens, um die Weiterentwicklung einer bestimmten Arbeit besser verstehen zu können.

Die Proceedings beginnen manchmal mit einer informativen (und amüsanten) Nachricht. Jede Ausgabe enthält die fertige Tagesordnung, eine IETF-Übersicht, Bereichs- und WG-Berichte sowie Folien der Protokollpräsentationen und technischen Präsentationen. Die WG-Berichte und Präsentationen sind manchmal unvollständig, wenn das Sekretariat das Material nicht rechtzeitig für die Veröffentlichung erhalten hat.

Ebenfalls inbegriffen ist eine Teilnehmerliste mit den Namen und der Zugehörigkeit der Teilnehmer, die auf dem Registrierungsformular angegeben wurden. Weitere Informationen dazu, wie Sie eine Kopie der Proceedings erhalten, finden Sie unter http://www.ietf.org/meeting/proceedings.html.

3.14 Andere allgemeine Angelegenheiten

IETF-Mitglieder sind im Allgemeinen sehr aufgeschlossen. Haben Sie keine Angst, jemanden anzusprechen oder sich vorzustellen. Haben Sie ebenfalls keine Angst, Fragen zu stellen, insbesondere nicht zu Jargon und Abkürzungen.

Unterhaltungen auf dem Gang sind sehr wichtig. Eine Menge Arbeit wird von Leuten erledigt, die zwischen den Treffen und beim Essen miteinander ins Gespräch kommen. Jeder Minute der IETF kann als Arbeitszeit betrachtet werden (zum Entsetzen einiger Teilnehmer).

Ein Randtreffen ist eine inoffizielle Zusammenkunft zwischen WG-Treffen oder am späten Abend, um eine Menge Arbeit zu erledigen. Randtreffen finden an vielen verschiedenen Orten während eines IETF-Treffens statt, beispielsweise in Restaurants, Cafés, Gängen und (wenn wir Glück haben) Pools.

Es ist unklug, in der Kaffeepause zwischen ein hungriges IETF-Mitglied (und das ist der Normalzustand) und das Kuchenbuffet zu geraten, egal wie interessant das Gespräch auf dem Gang ist. Steve Coya, der erste IETF Executive Director, sagte oft „Nehmen Sie Ihren Keks und verlassen Sie den Tisch.“

IETF-Mitglieder sind ausgesprochen unabhängig. Es ist ungefährlich, Meinungen anzuzweifeln und Alternativen vorzuschlagen, aber erwarten Sie nicht, dass ein IEFT-Mitglied Befehle befolgt.

Die IETF-Treffen und insbesondere die Plenarsitzungen sind kein Ort für Anbieter, ihre Produkte zu verkaufen. Die Teilnehmer können natürlich Fragen bezüglich ihres Unternehmens und seiner Produkte beantworten, aber vergessen Sie nicht, dass die IETF keine Handelsmesse ist. Das hält Teilnehmer jedoch nicht davon ab, die Kosten für IETF-T-Shirts, Anstecknadeln und Kugelschreiberetuis wieder hereinzuholen.

In der Nähe der Rezeption befindet sich immer ein „Materialtisch“. Dieser Tisch wird verwendet, um Informationen für die Teilnehmer zur Verfügung zu stellen (beispielsweise Notizen der in einer WG-Sitzung besprochenen Themen, Beschreibungen von IETF-Onlineinformationen). Erkundigen Sie sich bitte beim Sekretariat, bevor Sie Material auf den Tisch legen. Das Sekretariat kann Material entfernen, das es als nicht angemessen ansieht.

Wenn Sie während des Treffens Ihren Laptop verwenden, sollten Sie einen Ersatzakku mitbringen. In einigen Räumen ist es nicht immer einfach, eine Steckdose zu finden und der Drahtloszugriff kann Ihren Akku schneller als erwartet schwach werden lassen. Wenn Sie in der Nähe einer Mehrfachsteckdose sitzen, werden Sie wahrscheinlich von anderen Teilnehmern gebeten, ihren Laptop ein- und auszustecken. Viele Teilnehmer bringen ein Verlängerungskabel mit zusätzlichen Steckdosen mit. Dies ist eine effektive Methode, um auf einem Treffen Freundschaften zu schließen. Wenn Sie einen Adapter benötigen, sollten Sie diesen vor dem Treffen kaufen, da Adapter normalerweise einfacher in Ihrem Land zu finden sind.


4. Working Groups (Arbeitsgruppen)

Die meiste Arbeit der IETF wird in vielen Arbeitsgruppen erledigt. Zum Zeitpunkt der Erstellung dieses Dokuments, gab es etwa 115 verschiedene Arbeitsgruppen. [BCP25], „IETF Working Group Guidelines and Procedures“ ist eine hervorragende Ressource für alle, die an WG-Diskussionen teilnehmen.

Eine WG ist eigentlich nur eine Mailingliste, die ein bisschen von Erwachsenen beaufsichtigt wird. Sie treten der WG bei, indem Sie die Mailingliste abonnieren. Mailinglisten stehen allen offen. Jeder kann einen Beitrag in einer WG-Mailingliste veröffentlichen, obwohl die Beiträge von Nicht-Abonnenten in den meisten Listen moderiert werden. Jede Arbeitsgruppe hat einen oder zwei (selten drei) Vorsitzende.

Jede Arbeitsgruppe hat eine Satzung, die von der WG eingehalten werden sollte. Die Satzung legt den Umfang der Diskussionen sowie die Ziele der Arbeitsgruppe fest. Die Mailingliste der WG und die persönlichen Treffen sollten sich auf den Inhalt der Satzung konzentrieren und nicht vom Thema abschweifen. Natürlich ist es gelegentlich hilfreich, über den Umfang der WG hinaus zu blicken, aber die meisten Diskussionen sollten sich mit den in der Satzung aufgeführten Themen befassen. Tatsächlich legen einige WG-Satzungen fest, was die Arbeitsgruppe nicht tun sollte, insbesondere wenn beim Schreiben der Satzung einige interessante, aber unklare Themen aufgebracht wurden. Die Liste der WG-Satzungen ist interessant für alle, die wissen möchten, was die einzelnen Arbeitsgruppen machen.

4.1 Arbeitsgruppenvorsitzende

Die Rolle der WG-Vorsitzenden ist beschrieben in [BCP11] und [BCP25].

Als freiwilliger Schafhirte muss ein Vorsitzender in erster Linie die Konsensziele und Meilensteine der WG festlegen sowie die Satzung auf dem neuesten Stand halten. Außerdem muss der Vorsitzende (oft mit Hilfe der WG-Sekretäre oder Dokumenteditoren) die WG-Diskussionen leiten sowie gegebenenfalls Treffen planen. Manchmal geraten Diskussionen bei strittigen Punkten ins Stocken und der Vorsitzende muss die Diskussion zu einem produktiven Gedankenaustausch lenken und verkünden, wenn ein grober Konsens erreicht wurde und die Diskussion beendet ist. Vorsitzende sind manchmal auch für die Interaktionen mit Nicht-WG-Teilnehmern oder der IESG zuständig, insbesondere, wenn ein WG-Dokument veröffentlicht werden soll. Vorsitzende sind für die technische und nicht technische Qualität des WG-Ergebnisses verantwortlich. Wie Sie sich sicher vorstellen können, sind angesichts der administrativen, zwischenmenschlichen und technischen Anforderungen einige WG-Vorsitzende besser als andere.

WG-Vorsitzende sollten an der WG-Führungsschulung teilnehmen, die normalerweise am Sonntag vor dem IETF-Treffen abgehalten wird. In der Mitte der Woche des Treffens findet normalerweise ein Mittagessen für WG-Vorsitzende statt, während dem für Vorsitzende wichtige Themen präsentiert und diskutiert werden. Wenn Sie erfahren möchten, was dort besprochen wird, werfen Sie einen Blick auf die Folien unter http://edu.ietf.org.

4.2 Die Arbeit in einer Arbeitsgruppe

Ein Faktor, der viele Neulinge verwirrt, ist, dass in der IETF die persönlichen WG-Treffen weniger wichtig als in den meisten anderen Organisationen sind. Jede Entscheidung, die auf einem persönlichen Treffen getroffen wird, muss auch den Konsens der WG-Mailingliste erhalten. Es gibt zahlreiche Beispiele für wichtige Entscheidungen, die auf WG-Treffen getroffen und später von der Mailingliste umgestoßen wurden, da jemand, der nicht zum Treffen kommen konnte, auf eine Schwachstelle in der Logik hinwies, auf der die Entscheidung beruht. WG-Treffen sind keine „Entwurfssitzungen“ wie in einigen anderen Normierungsorganisationen. In der IETF findet der Entwurf woanders statt.

Ein weiterer Aspekt von Arbeitsgruppen, der viele Leute verblüfft, ist die Tatsache, dass es keine formelle Abstimmung gibt. Die allgemeine Regel für strittige Themen ist, dass die Arbeitsgruppe einen „groben Konsens“ erreichen muss. Das heißt, dass die Mehrheit übereinstimmen muss. Die genaue Methode zum Bestimmen des groben Konsens hängt von der Arbeitsgruppe ab. Manchmal wird der Konsens durch „Summen“ bestimmt. Wenn Sie einem Vorschlag zustimmen, summen Sie, wenn der Vorsitzende dazu auffordert. Die meisten Fragen bestehen aus zwei Teilen, Sie summen beim ersten Teil, wenn Sie dem Vorschlag zustimmen, oder beim zweiten Teil, wenn Sie nicht zustimmen. Neulinge finden das ziemlich seltsam, aber es funktioniert. Der Vorsitzende entscheidet, ob die Arbeitsgruppe einen groben Konsens erreicht hat.

Da keine formelle Abstimmung stattfindet, wurden einige Vorschläge sehr lang hinausgeschoben, aber die meisten IETF-Teilnehmer, die einen groben Konsens nach erbitterten Debatten miterlebt haben, glauben, dass die Verzögerungen in besseren Protokollen resultierten. (Und wie wäre eine Abstimmung in einer Gruppe möglich, die alle interessierten Personen einlädt, und es unmöglich ist, die Teilnehmer zu zählen?) Der grobe Konsens wurde auf viele Arten definiert. Eine einfache Version ist, dass er bedeutet, dass starke Einwände diskutiert werden müssen, bis die meisten Teilnehmer davon überzeugt sind, dass diese Einwände falsch sind.

Ein ähnliches Problem ist, dass einige Leute glauben, dass ihre Vorschläge in der Arbeitsgruppe diskutiert werden sollten, auch wenn der WG-Vorsitzende nicht davon überzeugt ist. Wenn die vorgeschlagene Arbeit beispielsweise nicht in der Satzung enthalten ist, kann der WG-Vorsitzende die Diskussion des Vorschlags einschränken, damit sich die WG auf die Arbeit in der Satzung konzentriert. Personen, die glauben, dass eine WG ein Thema besprechen sollte, das der WG-Vorsitzende als außerhalb der Satzung ansieht, können sich an den verantwortlichen AD wenden. Der AD kann zustimmen, das Thema in die Satzung aufzunehmen, oder zum Schluss kommen, dass das Thema bereits von der Satzung abgedeckt ist bzw. dass der WG-Vorsitzende recht hat und der Teilnehmer außerhalb der Arbeitsgruppe am Vorschlag arbeiten sollte.

Nachdem ein WG-Dokument ausreichend diskutiert wurde, durchläuft es normalerweise den Working Group Last Call (WGLC). Das ist die letzte Gelegenheit für die WG, Probleme aus dem Weg zu räumen. Manchmal deckt ein WGLC so viele Probleme auf, dass ein zweiter WGLC nötig ist, nachdem die Korrekturen eingearbeitet sind. Es gibt keine formellen Regeln für einen WGLC oder zum Bestimmen, ob ein WGLC erforderlich ist. Dies liegt im Ermessen des WG-Vorsitzenden.

Eine andere Methode einiger Arbeitsgruppen ist, einen WG-Sekretär einzusetzen, der die Dokumente und Änderungen jongliert. Der Sekretär kann einen Problem-Tracker benutzen (wenn einer vorhanden ist) oder sonst sicherstellen, dass alle Entscheidungen, die von der Mailingliste getroffen werden, in neueren Versionen der Dokumente berücksichtigt werden.

Wenn eine WG ihre Aufgabe erfüllt hat, sollte sie den Betrieb einstellen. (Die meisten WG-Mailinglisten werden nach Einstellung der Arbeitsgruppe fortgesetzt, um weiterhin die gleichen Themen zu diskutieren.)In der IETF wird die Einstellung einer WG als Erfolg angesehen, da diese ihre Aufgabe erfüllt hat. Dies ist einer der Aspekte der IETF, den Neulinge, die Erfahrung mit anderen Normierungsorganisationen haben, nur schwer verstehen. Einige WG-Vorsitzenden können jedoch nicht damit umgehen, dass ihre WG fertig ist oder fügen neue Aufgaben zur Satzung hinzu, und die Arbeitsgruppe schleppt sich viele Jahre (oder in einigen Fällen Jahrzehnte) lang weiter. Das Ergebnis dieser alternden WGs ist oft nicht annähernd so nützlich, wie die früheren Produkte, und die chaotischen Ergebnisse werden manchmal dem sogenannten „degenerativen WG-Syndrom“ zugeschrieben.

4.3 Arbeitsgruppendokumente

Es gibt eine offizielle Unterscheidung zwischen WG-Entwürfen und unabhängigen Entwürfen, aber in der Praxis besteht kein verfahrenstechnischer Unterschied. Beispielsweise diskutieren viele WG-Mailinglisten auch unabhängige Entwürfe (nach Ermessen des WG-Vorsitzenden). Der WG-Vorsitzende entscheidet, welche Entwürfe zu WG-Entwürfen werden, und wer diese Entwürfe schreibt oder bearbeitet. Diese Entscheidung wird normalerweise nach Beratung mit der WG und manchmal mit dem Area Director getroffen. Dieser Prozess kann schwierig sein, wenn viele Leute der Autor eines Entwurfs sein möchten, aber auch, wenn niemand einen Entwurf schreiben möchte und die WG mit einer bestimmten Aufgabe beauftragt ist. Die Verfahren für Internet-Entwürfe werden später in diesem Dokument ausführlich beschrieben.

Einige Arbeitsgruppen haben komplexe Dokumente oder einen komplexen Satz von Dokumenten (oder beides). Das Entfernen aller Fehler aus einem oder mehreren komplexen Dokumenten ist eine schwierige Aufgabe. Um diese Aufgabe zu erleichtern, verwenden einige Arbeitsgruppen Problem-Tracker, bei denen es sich um Online-Listen der offenen Probleme mit den Dokumentnamen, dem Problemstatus, den vorgeschlagenen Korrekturen, usw. handelt. Die Verwendung eines Problem-Trackers hilft nicht nur der WG, sich wichtige Vorgänge zu merken, sondern auch, wenn später Fragen gestellt werden, warum etwas auf eine bestimmte Weise durchgeführt wurde.

Der Dokument-Editor für WG-Dokumente wird vom WG-Vorsitzenden bestimmt. Oft sind mehrere Editoren für WG-Dokumente vorhanden, insbesondere für komplexe Dokumente. Der Dokument-Editor ist dafür verantwortlich, sicherzustellen, dass der Inhalt des Dokuments die Entscheidungen der Arbeitsgruppe genau wiedergibt, insbesondere wenn eine neues Protokoll oder eine neue Erweiterung erstellt wird. Wenn ein Dokument-Editor dem WG-Konsensus nicht folgt, muss der WG-Vorsitzende die entsprechenden Änderungen energisch durchsetzen oder den Dokument-Editor durch jemanden ersetzen, der für die WG ansprechbar ist. Wenn ein WG-Dokument Fortschritte macht, schlagen die Teilnehmer der WG-Mailingliste Änderungen vor. Es wird erwartet, dass der Editor den Diskussionen folgt und vereinbarte Änderungen vornimmt.

Wenn ein Teilnehmer einen signifikanten Beitrag leistet, können der Dokument-Editor oder der Vorsitzende den Teilnehmer auffordern, ein Mitautor oder Miteditor zu werden, obwohl dies von den WG-Vorsitzenden genehmigt werden muss. Manchmal erwägt eine Arbeitsgruppe mehrere Alternativen, bevor sie einen bestimmten Internet-Entwurf als WG-Dokument wählt. Eine Arbeitsgruppe nimmt oft die Ideen von mehreren Alternativen auf, um ein WG-Dokument zu erstellen. In diesem Fall bestimmt der Vorsitzende, wer als Autor auf der Titelseite und wer als Beitragender im Dokument genannt wird.

Wenn ein WG-Dokument über die WG hinauskommt, benennt der WG-Vorsitzende einen „Hirten“, der den letzten Prozess übernimmt. Die Rolle des Hirten ist beschrieben in [RFC4858].

4.4 Arbeitsgruppentreffen vorbereiten

Es ist ausgesprochen wichtig, dass jeder (Neuling oder erfahrene Experte), die Internet-Entwürfe und RFCs liest, bevor er an einem persönlichen Treffen teilnimmt. WG-Treffen sind nicht als Schulung gedacht, sondern vorgesehen, um die Dokumente der Gruppe voran zu treiben. Auch wenn Sie nicht vorhaben, auf dem Treffen zu sprechen, sollten Sie die Dokumente der Gruppe lesen, oder wenigsten überfliegen, damit Sie wissen, worum es geht.

Der WG-Vorsitzende legt die Tagesordnung normalerweise einige Wochen im Voraus fest. Wenn Sie möchten, dass etwas auf dem Treffen diskutiert wird, sagen Sie dem Vorsitzenden Bescheid. Die Tagesordnungen der WG-Treffen sind im Voraus auf der IETF-Website verfügbar, aber einige WG-Vorsitzende sind nachlässig (oder sogar gleichgültig), wenn es darum geht, die Tagesordnung einzureichen.

Das Sekretariat plant WG-Treffen nur einige Wochen im Voraus und der Zeitplan kann sich auch eine Woche vor dem Treffen noch ändern. Wenn Sie nur an einem WG-Treffen teilnehmen, ist es möglicherweise schwierig, kurzfristig einen Flug zu buchen, insbesondere dann, wenn sich der Zeitplan des WG-Treffens ändert. Beobachten Sie die aktuelle Tagesordnung, damit Sie den Flug und ein Hotel buchen können. Aber letzten Endes sollten Sie wahrscheinlich nicht für nur ein WG-Treffen kommen. Wahrscheinlich können Ihre Kenntnisse für einige WGs von Wert sein, vorausgesetzt Sie haben die Entwürfe und RFCs dieser Gruppen gelesen.

Wenn Sie in der Tagesordnung eines persönlichen Treffens aufgeführt sind, sollten Sie einige Folien mitbringen. Aber kommen Sie nicht mit einem Tutorial an. Die Teilnehmer sollen die Entwürfe im Voraus lesen. In allen Räumen sind Projektoren für Präsentationen auf Laptops verfügbar.

Hier ein Tipp für Ihre Folien für WG- oder Plenarpräsentationen: Fügen Sie das Logo Ihres Unternehmens nicht auf allen Folien ein, auch wenn das außerhalb der IETF üblich ist. Die IETF missbilligt diese Art der Werbung (außer für den Sponsor des Treffens in der Plenarpräsentation) und die meisten Präsentatoren fügen ihr Logo nicht einmal in der ersten Folie ein. Die IETF befasst sich mit technischem Inhalt, nicht mit dem Fördern von Unternehmen. Folien sind für die bessere Lesbarkeit oft schwarzweiß. Farben werden nur verwendet, um etwas klarzustellen. Der Inhalt ist der wichtigste Teil der Folien, nicht deren Darstellung.

Etwas, das Sie während der WG-Sitzungen möglicherweise nützlich oder sogar unterhaltsam finden werden, sind die laufenden Kommentare im Jabber-Raum der Arbeitsgruppe. Die laufenden Kommentare dienen oft als Basis für die Besprechungsnotizen, aber können auch Witze, Seufzer und anderes belangloses Geplauder enthalten. Jabber ist eine kostenlose XML-Streamingtechnologie, die hauptsächlich für Instant Messaging verwendet wird. Sie finden Pointer zu Jabber-Clients für viele Plattformen unter http://xmpp.org/xmpp-software/ clients.Die Jabber-Chaträume haben den Namen der Arbeitsgruppe gefolgt von "@jabber.ietf.org". Diese Räume sind das ganze Jahr über verfügbar, nicht nur während IETF-Treffen. Einige dieser Räume werden von aktiven WG-Teilnehmern während der Protokollentwicklung verwendet.

4.5 Mailinglisten der Arbeitsgruppen

Wie bereits erwähnt, sind die IETF-Mailinglisten für Ankündigungen und Diskussionen die zentralen Mailinglisten für IETF-Aktivitäten. Es gibt jedoch viele andere Mailinglisten, die sich auf die Arbeit der IETF beziehen. Beispielsweise hat jede Arbeitsgruppe ihre eigene Diskussionsliste. Außerdem gibt es einige langfristige technische Diskussionen, die aus der IETF-Liste in Listen speziell für diese Themen ausgelagert wurden. Es ist empfehlenswert, dass Sie den Diskussionen in den Mailinglisten der Arbeitsgruppen folgen, an denen Sie teilnehmen möchten. Umso mehr Arbeit in den Mailinglisten erledigt wird, desto weniger Arbeit fällt auf dem Treffen an und Sie haben mehr Zeit, an Arbeitsgruppen außerhalb ihres Bereichs teilzunehmen, um ihren Horizont zu erweitern.

Die Mailinglisten bieten außerdem ein Forum für alle, die der Arbeit einer Arbeitsgruppe folgen oder dazu beitragen möchten, aber nicht am IETF-Treffen teilnehmen können. Aus diesem Grund müssen alle Entscheidungen von der Liste bestätigt werden. Sie werden einen WG-Vorsitzenden oft sagen hören, „Lasst uns das zur Liste bringen“, um eine Diskussion zu beenden.

Viele IETF-Diskussionslisten verwenden entweder Mailman oder einen anderen Listenmanager, Majordomo. Diese haben eine Adresse für Anforderungen, der Liste beizutreten oder diese zu verlassen. (Siehe Section 2.3 für weitere Informationen zum Mailman.) Es wird normalerweise nicht gern gesehen, wenn diese Verwaltungssachen in der Mailingliste auftauchen.

Die IETF-Diskussionslisten werden archiviert. Das heißt, alle Nachrichten, die an die Liste gesendet werden, werden automatisch für den anonymen HTTP- oder FTP-Zugriff auf einem Host gespeichert. Viele dieser Archive sind unter ftp://ftp.ietf.org/ietf-mail-archive aufgelistet oder sind webbasierte Archive. Wenn Sie eine Liste nicht finden können, senden Sie eine Nachricht an die Anforderungsadresse (nicht die Liste). Die WG-Satzungslisten unter http://datatracker.ietf.org/wg sind eine nützliche Quelle. http://www.ietf.org/wg/concluded ist eine Liste der alten, abgeschlossenen WGs.

Einige WG-Listen schränken die Größe von Nachrichten ein, um zu verhindern, das große Dokumente oder Präsentationen im Posteingang aller Teilnehmer landen. Es sollte beachtet werden, dass nicht alle Teilnehmer über eine Breitbandverbindung verfügen (auch die Teilnehmer mit Breitbandverbindungen verwenden unterwegs oft langsame Verbindungen) und kürzere Nachrichten werden bevorzugt. Dokumente können als Internet-Entwürfe und Präsentationen auf einer Website veröffentlicht werden, die vom Absender verwaltet oder an bestimmte Personen gesendet werden. Einige WGs richten spezielle Websites für große Dokumente ein, auf der diese veröffentlicht werden, und an die Liste wird lediglich der URL zum Dokument gesendet.

4.6 Nebentreffen von Arbeitsgruppen

Arbeitsgruppen treffen sich manchmal zwischen den IETFs. Diese Treffen sind kein Ersatz für die IETF-Treffen. Eine Gruppe kann jedoch ein Treffen an einem ungünstigen Ort überspringen und sich drei Wochen später beispielsweise in Cancún treffen. Diese Treffen müssen vom AD genehmigt und mindestens einen Monat im Voraus angekündigt werden. Der Ort und der Zeitplan müssen für alle Teilnehmer angemessen sein. Wie auf normalen IETF-Treffen muss jemand Besprechungsnotizen erstellen, und die Gruppe muss die Anwesenheit kontrollieren. Die während einem WG-Nebentreffen getroffenen Entscheidungen müssen von der Mailingliste ratifiziert werden.

In den letzten Jahren haben einige Arbeitsgruppen begonnen, Nebentreffen telefonisch und/oder online abzuhalten, anstatt an persönlichen Treffen teilzunehmen. Virtuelle Nebentreffen helfen einer Arbeitsgruppe, sich zwischen den normalen IETF-Treffen auf ihre Arbeit zu konzentrieren. Außerdem sind diese Treffen für die Teilnehmer billiger als persönliche Treffen. Für virtuelle Nebentreffen gelten die gleichen Berichtsanforderungen wie für persönliche virtuelle Treffen.

Die IESG hat Regeln für die rechtzeitige Bekanntgabe des Zeitpunkts und des Orts von WG-Nebentreffen sowie für Berichte der Ergebnisse des Treffens. Diese Regeln sollen Nebentreffen für möglichst viele WG-Mitglieder zugänglich machen und die Transparenz des WG-Prozesses sicherstellen.


5. BOFs

Um eine Arbeitsgruppe zu gründen, benötigen Sie eine Satzung und einen Vorsitzenden. Deshalb müssen Sie andere interessieren, die Ihnen helfen, die Satzung zu erstellen und einen Area Director davon überzeugen, dass das Projekt den Aufwand wert ist. Hierfür ist ein persönliches Treffen hilfreich. Tatsächlich werden nur wenige WGs von einem Area Director ins Leben gerufen. Die meisten WGs werden nach einem persönlichen BOF gegründet, wenn die Teilnehmer Interesse an einem Thema gezeigt haben.

Ein BOF-Treffen (Birds of a Feather) muss vom Area Director im relevanten Bereich vor der Planung genehmigt werden. Wenn Sie eine neue WG benötigen, wenden Sie sich mit Ihrem Vorschlag an einen AD, um zu erfahren, was dieser darüber denkt. Der nächste Schritt ist, auf dem nächsten persönlichen Treffen einen Zeitpunkt festzulegen Natürlich müssen Sie für einige Aufgaben nicht auf das nächste Treffen warten, um beispielsweise eine Mailingliste zu erstellen und die Satzung zu diskutieren.

BOF-Treffen unterscheiden sich wesentlich von WG-Treffen. Der Zweck eines BOF-Treffens ist, sicherzustellen, dass eine gute Satzung mit angemessenen Meilensteinen erstellt werden kann und genügend Leute bereit sind, die Arbeit zu übernehmen, die beim Erstellen von Standards erledigt werden muss. Einige BOFs arbeiten bereits an Internet-Entwürfen und andere BOFs beginnen von vorn.

Es ist vorteilhaft, vor dem BOF einen Entwurf zu haben, auf den sich die Diskussion konzentrieren kann. Andererseits kann der Entwurf einschränken, was die anderen BOF-Teilnehmer in die Satzung aufnehmen möchten. Beachten Sie, dass die meisten BOFs abgehalten werden, um die Unterstützung für eine künftige Arbeitsgruppe zu erhalten, nicht für ein bestimmtes Dokument.

Viele BOFs enden aus verschiedenen Gründen nicht in WGs. Ein übliches Problem ist, dass nicht genügend Teilnehmer zustimmen. Ein weiterer typischer Grund ist, dass die Arbeit nicht in einem Standard resultieren würde. Beispielsweise wenn die Dokumentautoren die Änderungskontrolle nicht an eine WG abgeben möchten. (Die Änderungskontrolle wird später in diesem Dokument erklärt.) Für ein bestimmtes Thema können nur zwei BOFs geplant werden. Entweder wird eine WG gegründet oder das Thema sollte fallen gelassen werden.


6. RFCs und Internet-Entwürfe

Wenn Sie ein neuer IETF-Teilnehmer sind und einen bestimmten RFC oder Internet-Entwurf suchen, besuchen Sie die Website des RFC Editors: http://www.rfc-editor.org/rfc.html.Diese Website enthält Links zu anderen RFC-Sammlungen (viele mit Suchfunktionen). Wenn Ihnen die Nummer des gesuchten RFC bekannt ist, besuchen Sie die RFC-Seiten des RFC Editors: http://www.rfc-editor.org/rfc.html.Eine gute Quelle für Internet-Entwürfe ist die IETF-Website https://datatracker.ietf.org/doc, auf der Sie nach Titeln und Schlüsselwörtern suchen können.

6.1 Ein RFC veröffentlichen

Eine der häufigsten Fragen, die IETF-Mitgliedern von Neulingen gestellt werden, ist „Wie veröffentliche ich einen IETF-Standard?“Eine bessere Frage ist „Soll ich einen IETF-Standard schreiben?“.Die Antwort ist nicht immer „Ja“. Wenn Sie planen, ein Dokument zu schreiben, das ein IETF-Standard werden soll, seien Sie gewarnt, dass dieser Prozess mühsam ist, auch wenn die einzelnen Schritte relativ unkompliziert sind. Viele Leute überstehen den Prozess jedoch unversehrt und es gibt zahlreiche Leitfäden, die Autoren helfen, mehr oder weniger ungeschoren davonzukommen.

Als erstes müssen Sie entscheiden, ob Ihr Dokument in einer Arbeitsgruppe überprüft oder der gesamten IETF vorgelegt werden soll. Obwohl die meisten IETF-Standards aus Arbeitsgruppen stammen, werden einige Standards von Einzelpersonen erstellt, da keine geeignete Arbeitsgruppe verfügbar ist oder die passende Arbeitsgruppe mit anderen Aufgaben beschäftigt ist.

Alle IETF-Standards werden als RFC (Request for Comments) veröffentlicht und jeder RFC beginnt als Internet-Entwurf. Um etwas zu veröffentlichen, führen Sie die folgenden Schritte aus:

  1. Veröffentlichen Sie das Dokument als Internet-Entwurf.
  2. Lesen Sie die Kommentare zum Entwurf.
  3. Bearbeiten Sie den Entwurf basierend auf den Kommentaren.
  4. Wiederholen Sie die Schritte 1 bis 3 mehrmals.
  5. Fordern Sie einen Area Director auf, Ihren Entwurf der IESG vorzulegen. Wenn der Entwurf das Produkt einer offiziellen Arbeitsgruppe ist, fordert der WG-Vorsitzende den AD auf, den Entwurf der IESG vorzulegen.
  6. Wenn der Area Director den Entwurf akzeptiert, überprüft er den Entwurf und verlangen möglicherweise Änderungen, bevor er weitergeleitet wird.
  7. Lassen Sie den Entwurf von mehreren IETF-Mitgliedern überprüfen. Einige der Bereiche in der IETF haben Teams, die Entwürfe überprüfen, bevor diese der IESG vorgelegt werden. Zwei der aktiveren Teams kommen aus dem Security Directorate- (SecDir) und General Area Review-Team (Gen-Art). Denken Sie daran, dass diese Überprüfungen, die Qualität des resultierenden RFC verbessern können.
  8. Diskutieren Sie Bedenken mit den IESG-Mitgliedern. Die Bedenken können möglicherweise mit einer einfachen Antwort beseitigt werden oder erfordern, dass Änderungen am Dokument vorgenommen werden.
  9. Warten Sie, bis das Dokument vom RFC Editor veröffentlicht wird.

Eine ausführlichere Beschreibung dieser Schritte finden Sie in [BCP9] „The Internet Standards Process“. Wenn Sie einen Entwurf schreiben, der ein IETF-Standard werden soll, lesen Sie BCP 9, um den Weg Ihres Dokuments durch den Prozess zu verfolgen. Sie können den Fortschritt im IETF Datatracker überwachen: http://datatracker.ietf.org.BCP 9 (und verschiedene andere Zusatzdokumente) beschreiben ein Thema ausführlich, das oft auch von erfahrenen IETF-Teilnehmern missverstanden wird: Die verschiedenen RFC-Typen durchlaufen unterschiedliche Prozesse und werden verschieden bewertet. Es gibt sechs RFC-Typen:

Nur die ersten beiden Typen sind Standards in der IETF. Eine gute Übersicht finden Sie unter dem Titel [RFC1796], „Not All RFCs are Standards“.

Es gibt zwei Unterserien von RFCs, die als BCPs und STDs bekannt sind. BCP-Dokumente beschreiben die Verwendung verschiedener Technologien im Internet und werden häufig verwendet, um die vielen Teile des IETF-Prozesses zu dokumentieren. Die Unterserie von FYIs besteht aus Informationsdokumenten mit spezieller Kennzeichnung. (Es gab auch eine „For Your Information“ RFC-Unterserie, die erstellt wurde, um Überblicke und neue Themen für ein breites Publikum zu dokumentieren. Diese Serie wurde jedoch offiziell eingestellt.)

Die STD RFC-Unterserie wurde erstellt, um RFCs zu identifizieren, die Internet-Standards spezifizieren. Einige STDs sind in der Tat Sammlungen von mehreren RFCs und die Bezeichnung „Standard“ gilt für alle Dokumente.

6.2 Letting Go Gracefully Verantwortung abgeben

Der Hauptgrund, aus dem einige Leute ihre Dokumente nicht dem IETF-Standardisierungsprozess überlassen möchten, ist, dass sie die Kontrolle über Protokolländerungen abgeben müssten. In dem Moment, in dem Sie vorschlagen, dass Ihr Protokoll ein IETF-Standard wird, verlieren Sie die Kontrolle über das Protokoll. Wenn eine allgemeine Übereinkunft erzielt wird, werden möglicherweise Teile des Protokolls vollständig geändert, Abschnitte gelöscht, neue Teile hinzugefügt und sogar der Name geändert.

Für einige Autoren ist es schwer, die Kontrolle über ihr Protokoll abzugeben. Wenn Sie zu diesen Autoren gehören, denken Sie noch nicht einmal daran, zu versuchen, dass Ihr Protokoll ein IETF-Standard wird. Wenn Sie andererseits das Ziel haben, den besten Standard mit der umfangreichsten Implementierung zu erstellen, ist der IETF-Prozess wahrscheinlich nach Ihrem Geschmack.

Die Änderungskontrolle für Internet-Standards endet nicht, wenn das Protokoll dem Standardisierungsprozess überlassen wird. Das Protokoll kann aus vielen Gründen zu einem späteren Zeitpunkt geändert werden. Der Hauptgrund hierfür ist, dass beim Implementieren des Standards ein Problem gefunden wird. Diese späteren Änderungen werden ebenfalls von der IETF kontrolliert, nicht von den Editoren des Standarddokuments.

IETF-Standards existieren, damit sie zum Schreiben von Internetprogrammen verwendet werden können, die miteinander kooperieren können. Die Standards existieren nicht, um die (möglicherweise großartigen) Ideen ihrer Autoren zu dokumentieren oder damit ein Unternehmen sagen kann „Wir haben einen IETF-Standard“. Wenn ein vorgeschlagener RFC nur eine Implementierung hat (obwohl zwei erforderlich sind, um den Standardisierungsprozess fortzusetzen), war es vermutlich von vornherein ein Fehler, ihn in den Standardisierungsprozess aufzunehmen.

Beachten Sie, dass neue Autoren das Dokument von jemand anderem nicht als ihr eigenes Dokument ausgeben können; siehe [BCP78], Abschnitt 5.6 (a).

6.3 Internetentwürfe

Aber eins nach dem anderen. Jedes Dokument, das im RFC-Speicher ankommt. beginnt seinen Lebenszyklus als Internet-Entwurf. Internet-Entwürfe sind vorläufige Dokumente, die von den Lesern kommentiert werden können. Die Autoren können die Kommentare überprüfen und entscheiden, welche Kommentare in den Entwurf eingearbeitet werden. Da Entwürfe vorläufig sind, werden sie nach sechs Monaten automatisch aus den Online-Verzeichnissen entfernt. Entwürfe sind absolut keine Standards. Wie [BCP9] gesagt:

Ein Internet-Entwurf ist kein Mittel, um eine Spezifikation zu veröffentlichen. Spezifikationen werden über den RFC-Prozess veröffentlicht. Internet-Entwürfe haben keinen formellen Status und können jederzeit geändert oder entfernt werden. Ein Internet-Entwurf sollte unter keinen Umständen in einem Dokument, Bericht oder Request-for-Proposal referenziert werden, und ein Anbieter sollte nicht behaupten, mit einem Internet-Entwurf kompatibel zu sein.

Jemand der die IETF nicht versteht (oder andere täuschen möchte), kann immer dann leicht erkannt werden, wenn er angibt, einen Internet-Entwurf veröffentlicht zu haben. Das erfordert keinen großen Aufwand.

Wenn Sie einen Internet-Entwurf einreichen, geben Sie einige der Veröffentlichungsrechte an die IETF ab, damit Ihr Entwurf allen zur Verfügung gestellt werden kann, die ihn lesen und kommentieren möchten. Die Rechte, die Sie an die IETF abgeben bzw. nicht abgeben, sind beschrieben in[BCP78], „IETF Rights in Contributions“.

Ein ausgesprochen nützliches Überprüfungstool finden Sie unter http://tools.ietf.org/tools/idnits.Wenn Sie dieses Tool verwenden, bevor Sie einen Internet-Entwurf einreichen, können Sie verhindern, dass der Entwurf aufgrund von Fehlern in Form und Formatierung abgelehnt wird.

Ein Internet-Entwurf sollte in etwa das gleiche Format wie ein RFC haben. Im Gegensatz zur landläufigen Meinung, muss ein Internet-Entwurf nicht genauso wie ein RFC aussehen, aber Sie können dieselben Formatierungsverfahren wie der RFC Editor verwenden, wenn Sie den Entwurf erstellen. Die Veröffentlichung des Entwurfs als RFC erleichtert die Arbeit des RFC-Editors. [RFC2223], Unter „Anleitungen für RFC-Autoren“ ist das Einreichungsformat beschrieben. Das Tool „xml2rfc“, das unter http://xml.resource.org, verfügbar ist, wandelt den als XML formatierten Text in einen zulässigen Internet-Entwurf um.

Bei einem Internet-Entwurf kann es sich um den Entwurf einer Arbeitsgruppe oder einer Einzelperson handeln. Die Entwürfe von Arbeitsgruppen werden normalerweise von der Arbeitsgruppe überprüft, bevor sie akzeptiert werden, obwohl der Vorsitzende das letzte Wort hat.

Wenn Sie den Status eines Entwurfs sehen möchten und den genauen Namen nicht kennen oder herausfinden möchten, an welchen Entwürfe eine Arbeitsgruppe derzeit arbeitet, können Sie eines von zwei praktischen Tools verwenden. Mit „Internet-Drafts Database Interface“ unter https://datatracker.ietf.org/dock önnen Sie einen Entwurf nach Autor, Arbeitsgruppe, Datum oder Dateinamen suchen. Dies ist insbesondere für Autoren hilfreich, die den Status ihres Entwurfs im Veröffentlichungsprozess nachverfolgen möchten.

Mit den Jahren haben sich einige informelle Regeln für die Namen von Internet-Entwürfen herausgebildet. Internet-Entwürfe, die vorhandene RFCs korrigieren, haben oft Namen, die „bis“ enthalten, was „wieder“ oder „zwei Mal“ bedeutet. Ein Entwurf kann beispielsweise den Namen draft-someone-rfc2345bis-00.txt haben.

6.3.1 Für Autoren zum Lesen empfohlen

Bevor Sie den ersten Entwurf Ihres Internet-Entwurfs erstellen, sollten Sie vier Dokumente lesen:

Außerdem sollten Sie die IETF Tools-Website http://tools.ietf.org besuchen, auf der Sie Links zu anderen Tools finden, die Einiges der Arbeit für die IETF automatisieren.

6.3.2 Filenamen und Anderes

Wenn Sie bereit sind, Ihren Internet-Entwurf einzureichen, senden Sie ihn an http://datatracker.ietf.org/submit. Die Anweisungen auf der Webseite führen Sie durch die erforderlichen Schritte. Außerdem enthält die Webseite eine E-Mail-Adresse, an die Sie sich wenden können, falls Sie weitere Hilfe benötigen.

Wenn Sie die erste Version des Entwurfs übermitteln, teilen Sie dem Entwurfsadministrator den vorgeschlagenen Dateinamen für den Entwurf mit. Wenn der Entwurf ein offizielles WG-Produkt ist, beginnt der Name mit „draft-ietf-“ gefolgt vom Kennzeichen der WG, einem beschreibenden Wort und „00.txt“.

Beispielsweise kann ein Entwurf zum Erstellen von Schlüsseln in der S/MIME WG den Namen „draft-ietf-smime-keying-00.txt“ haben. Wenn es sich nicht um das Produkt einer Arbeitsgruppe handelt, beginnt der Name mit „draft-“ und dem Nachnamen des Autors gefolgt von einem beschreibenden Wort und „00.txt“. Beispielsweise kann der Entwurfs eines Autors mit dem Namen Smith „draft-smith-keying-00.txt“ genannt werden. Wenn der Entwurf von einer Einzelperson stammt, sich aber auf eine bestimmte Arbeitsgruppe bezieht, hängen Autoren manchmal den Namen der Arbeitsgruppe an ihren Namen an (beispielsweise „draft-smith-smime-keying-00.txt“). Wenn Sie sich an die Namensrichtlinien unter http://www.ietf.org/ietf/1id-guidelines.txt, halten, ist der von Ihnen vorgeschlagene Dateiname aller Wahrscheinlichkeit nach in Ordnung.

Nach der ersten Version eines Entwurfs wird die Zahl im Dateinamen erhöht. Beispielsweise hätte die zweite Version des oben erwähnten S/MIME-Entwurf den Namen „draft-ietf-smime-keying-01.txt“. Beachten Sie, dass es Fälle gibt, in denen sich der Dateiname nach einer oder mehr Versionen ändern, beispielsweise wenn eine persönliche Arbeit in die Arbeitsgruppe einbezogen wird. Wenn der Dateiname eines Entwurfs geändert, ist die Nummer wieder -00. Der WG-Vorsitzende teilt dem Administrator für Internet-Entwürfe den früheren Namen den Entwurfs mit, wenn sich ein Name ändert, damit die Datenbanken auf dem neuesten Stand gehalten werden können.

6.4 RFCs im Standardisierungsprozess

Das Verfahren zum Erstellen und Vorantreiben eines Standards ist beschrieben in [BCP9].Nachdem ein Internet-Entwurf ausreichend diskutiert wurde und ein grober Konsens, dass dieser Standard nützlich ist, erzielt wurde, wird der Entwurf der IESG zur Erörterung vorgelegt. Wenn der Entwurf ein offizieller WG-Entwurf ist, sendet ihn der WG-Vorsitzende an den zuständigen Area Director. Wenn der Entwurf von einer Einzelperson erstellt ist, wird er vom Autor oder Editor an den zuständigen Area Director eingereicht. BCP 9 beschreibt auch das Einspruchsverfahren, wenn ein WG-Vorsitzender, ein AD oder die IESG vermeintlich die falsche Entscheidung getroffen hat.

Nachdem der Internet-Entwurf an die IESG übermittelt wurde, kündigt die IESG einen IETF-weiten Last Call (LC) an. Das macht die Leute aufmerksam, die den Status des Entwurfs nicht verfolgt haben, und kann weitere Änderungen des Entwurfs zur Folge haben. Zu diesem Zeitpunkt können die Mitglieder der WG, die ihre Meinung äußern möchten, ihre Kommentare veröffentlichen. Der IETF Last Call dauert mindestens zwei Wochen für WG-Entwürfe und vier Wochen für die Entwürfe von Einzelpersonen.

Der IETF Last Call soll die gemeindeweite Diskussion in Schwung bringen, bevor die IESG die Dokumente erörtert. Beachten Sie hier das Wort „Diskussion“. Es wird normalerweise als schlechte Form betrachtet, IETF Last Call-Kommentare für Dokumente zu senden, die Sie nicht gelesen haben, oder wenn Sie nicht darauf vorbereitet sind, Ihre Ansichten zu diskutieren. Der IETF Last Call ist keine Abstimmung, und Kampagnen für Unterstützung oder Widerstand bezüglich eines Dokuments können nach hinten losgehen. Nichtsdestoweniger, können die IETF Last Call-Kommentare von Leuten, die das Dokument zum ersten Mal gelesen haben, Probleme aufdecken, die von den IETF- und WG-Mitgliedern übersehen wurden. Aus diesem Grund kann jeder an der Diskussion teilnehmen.

Wenn die IESG genehmigt, dass der Entwurf zu einem RFC im Standardisierungsprozess wird, veröffentlicht der RFC Editor den Entwurf als vorgeschlagenen Standard. Zu diesem Zeitpunkt passiert einiges. Es ist nicht ungewöhnlich, dass einige Spezifikationen im Standard neu formuliert werden müssen, da diese bei der Implementierung missverstanden wurden. Ein weiteres übliches Ereignis ist, dass nicht versucht wurde, einige der Features des Standards zu implementieren. Diese Features werden nicht nur entfernt, da sie nicht getestet wurden, sondern auch, da sie nicht benötigt werden.

Seien Sie nicht überrascht, wenn es ein bestimmter vorgeschlagener Standard nicht zum Internetstandard wird. Um ein Internetstandard zu werden, muss ein RFC mehrere interoperable Implementierungen haben und die nicht verwendeten Fatures im vorgeschlagenen Standard müssen entfernt werden. Zusätzliche Anforderungen sind aufgelistet in [BCP9]. Die meisten Standards in allgemeiner Verwendung sind vorgeschlagene Standards und kommen nie voran. Dies mag daran liegen, dass sich niemand die Zeit genommen hat, den Standard zum Internetstandard zu machen, einige der normativen Referenzen im Standard noch den Status „Vorgeschlagen“ haben oder alle Wichtigeres zu tun hatten.

6.4.1 Sagen wie es ist — Benutzung von MUSS und SOLLTE und KANN

Das Schreiben von Spezifikationen, die auf die von Ihnen gewünschte Weise implementiert werden, ist eine Kunst. Sie können die Spezifikation mit einer Liste der Anforderungen kurz halten, aber das lässt bei der Implementierung zu viel Spielraum. Wenn die Spezifikation jedoch sehr lang ist und viele Vorschläge enthält, werden bei der Implementierung oft die Anforderungen übersehen (und Ihren Vorschlägen wird sowieso widersprochen). Eine optimale Spezifikation liegt irgendwo in der Mitte.

Eine Methode zum Sicherstellen, dass Entwickler interoperable Implementierungen von Standards erstellen, ist klarzustellen, was in einer Spezifikation verlangt wird. Frühere RFCs verwendeten alle Arten von Ausdrücken, um zu erklären, was erforderlich ist. Deshalb konnte bei der Implementierung nicht immer zwischen Vorschlägen und Anforderungen unterschieden werden. Aus diesem Grunde waren sich die Autoren von Standards in der IETF einig, die Formulierungen auf einige Wörter mit einer bestimmten Bedeutung zu beschränken.

[STD3]„Requirements for Internet Hosts -- Application and Support“ wurde 1989 geschrieben und enthielt eine kurze Liste nützlicher Wörter, beispielsweise „MUST“, „SHOULD“ und „OPTIONAL“. Diese Definitionen wurden in [BCP14]„Key words for use in RFCs to Indicate Requirement Levels“, auf das in aktuellen Internetstandards verwiesen wird, aktualisiert und erweitert. BCP 14 definiert auch ausdrücklich „MUST NOT“ und „SHOULD NOT“ sowie einige Synonyme für die definierten Wörter.

Um klarzustellen, dass Sie die Definitionen in BCP 14 in einem Standard verwenden, sollten Sie zwei Dinge tun. Erstens: Verweisen Sie auf BCP 14 (obwohl das meistens als RFC 2119 bezeichnet wird, da dies in BCP 14 angegeben ist), damit der Leser weiß, wie Sie Wörter definieren. Zweitens: Sie sollten angeben, welche Instanzen der verwendeten Wörter aus BCP 14 kommen. Ein akzeptiertes Verfahren ist die Großschreibung der Wörter. Deshalb werden in IETF-Standards beispielsweise „MUST“ und „SHOULD“ groß geschrieben.

BCP 14 ist ein kurzes Dokument, das von allen gelesen werden sollte, die IETF-Standards lesen oder schreiben. Obwohl die Definitionen von „MUST“ (muss) und „MUST NOT“(darf nicht) (im Englischen) ziemlich eindeutig sind, ist die Definition von „SHOULD“ (sollte oder könnte) und „SHOULD NOT“ die Ursache für Diskussionen in vielen WGs. Bei der Überprüfung eines Internet-Entwurfs kommt oft die Frage auf „Sollte dieser Satz ein MUST oder ein SHOULD enthalten?“ Das ist tatsächlich eine gute Frage, da Spezifikationen kein überflüssiges MUST, aber auch kein SHOULD enthalten sollten, wenn ein MUST für die Interoperabilität erforderlich ist. Das wiederum wirft die Frage der Über- oder Unterspezifizierung in Standards auf.

6.4.2 Normative Referenzen in Standards

Ein Aspekt beim Schreiben von IETF-Standards, über den viele Anfänger (und auch erfahrene IETF-Mitglieder) stolpern, ist die Regel zum Erstellen von normativen Referenzen auf Nicht-IETF-Dokumente oder andere RFCs in einem Standard. Eine normative Referenz ist eine Referenz auf ein Dokument, das erforderlich ist, um den Standard zu implementieren. Eine nicht normative Referenz (oder „informative Referenz“) ist bei der Implementierung hilfreich, aber nicht erforderlich.

Ein IETF-Standard kann eine normative Referenz auf einen anderen RFC im Standardisierungsprozess auf der gleichen oder einer höheren Stufe oder auf einen „offenen Standard“ enthalten, der außerhalb der IETF entwickelt wurde. Die Regel zur gleichen oder höheren Stufe bedeutet, dass alle RFCs für die eine normative Referenz enthalten ist, ein Entwurf oder Internetstandard sein müssen, bevor ein vorgeschlagener Standard zum Entwurf werden kann. Diese Regel ist beschrieben in [BCP97].Die Regel stellt bei der Implementierung sicher, dass alles in einem Internetstandard relativ stabil ist (auch die Komponenten, die außerhalb des Standards referenziert sind). Das kann die Veröffentlichung des Entwurfs oder Internetstandards um viele Monate (manchmal sogar Jahre) verzögern, während die anderen Dokumente aufholen.

Es gibt keine bindende Regel, um einen offenen Standard zu definieren, aber im Allgemeinen handelt es sich um einen stabilen Standard, den jeder erhalten kann (obwohl manchmal gegen Bezahlung) und der von einer anerkannten Normierungsgruppe erstellt wurde. Wenn sich der externe Standard ändert, müssen Sie in Ihrer Spezifikation auf die entsprechende Instanziierung dieses Standards verweisen und das Datum des Standards angeben. Einige externe Normenorganisationen stellen alte Standards nicht zur Verfügung. Das ist ein Problem für IETF-Standards, die künftig verwendet werden müssen. Im Zweifelsfall sollte der Autor eines Entwurfs den WG-Vorsitzenden oder den zuständigen Area Director fragen, ob ein externer Standard in einem IETF-Standard verwendet werden kann.

6.4.3 IANA-Betrachtunngen

Immer mehr IETF-Standards erfordern die Registrierung verschiedener Protokollparameter, beispielsweise benannter Optionen im Protokoll. Wie bereits erwähnt, ist die IANA Section 2.2.4die Hauptregistrierungsstelle für alle IETF-Standards. Aufgrund der umfangreichen und unterschiedlichen Registraturen, die für Standards erforderlich sind, benötigt die IANA bestimmte Informationen, beispielsweise, wie Parameter registriert werden, was nicht registriert wird und wer entscheidet, was registriert wird.

Alle Autoren von Internetstandards, die eine neue IANA-Registrierung oder neue Werte in einer aktuellen IANA-Registrierung brauchen, sollten [BCP26]„Guidelines for Writing an IANA Considerations Section in RFCs“ lesen, in dem beschrieben wird, wie RFC-Autoren die IANA fragen sollten, um eine Registrierung zu starten oder zu übernehmen. Die IANA verwaltet auch Registrierungen, die lange vor BCP 26 erstellt wurden.

6.4.4 Sicherheitsbetrachtungen

Jeder RFC und Internet-Entwurf muss einen „Security Considerations“-Abschnitt enthalten. In diesem Abschnitt sollten alle bekannten Schwachstellen des Protokolls, mögliche Gefährdungen und Methoden oder Strategien zum Ausschalten dieser Gefahren beschrieben sein. Kehren Sie diesen Abschnitt nicht unter den Teppich. Sagen Sie insbesondere nicht, „Hier ist unser Protokoll. Wenn Sie Sicherheit möchten, verwenden Sie IPsec.“ Das genügt nicht, da die Frage wie IPsec mit Ihrem Protokoll interagiert und umgekehrt nicht beantwortet wird. Siehe [BCP72]„Guidelines for Writing RFC Text on Security Considerations“ für weitere Informationen zum Schreiben eines guten Abschnitts mit Sicherheitsbetrachtungen.

6.4.5 Patente in IETF Standards

In den letzten Jahren sind immer mehr Probleme bezüglich geistigen Eigentums aufgetreten, insbesondere in Zusammenhang mit Patenten. Das Ziel der IETF ist, ihre Standards im Markt zu verbreiten und zu validieren. Wenn zum Erstellen eines Produkts, das einen Standard verwendet, eine Lizenz für ein Patent erforderlich ist, wird der Standard vermutlich nicht implementiert. Es ist deshalb keine Überraschung, dass die allgemeine Regel ist, möglichst gute nicht patentierte Technologien zu verwenden.

Natürlich ist das nicht immer möglich. Patente tauchen manchmal auf, nachdem ein Standard eingeführt wurde. Manchmal ist etwas patentiert, das so nützlich ist, dass keine gleichwertige, nicht patentierte Alternative verfügbar ist. Manchmal ist der Patentinhaber großzügig und gibt eine gebührenfreie Lizenz für die Implementierung eines Standards aus. Die Implementierung eines solchen Standards ist beinahe so einfach wie die Implementierung eines nicht patentierten Standards.

Die Methoden der IETF für die Handhabung von Patenten in Standards sind das Thema vieler Diskussionen. Die offiziellen Regeln für geistige Eigentumsrechte in den IETF-Dokumenten (nicht nur Patenten) sind beschrieben in [BCP78] und [BCP79]„Intellectual Property Rights in IETF Technology“. Diese Dokumente sind für alle, die an IETF-Arbeitsgruppen teilnehmen, interessant, da sie die vereinbarten Regeln beschreiben.

Patentinhaber, die die Verwendung ihrer Patente für die Implementierung von IETF-Standards erlauben, sind bei den IETF-Mitgliedern sehr angesehen. Diese Großzügigkeit ist üblicher als Sie vielleicht denken. Beispielsweise ist RFC 1822 eine Lizenz von IBM für eines seiner Sicherheitspatente in einem bestimmten Protokollkontext und die Sicherheitsgemeinde hat sehr positiv auf die Großzügigkeit von IBM reagiert (wohingegen andere Unternehmen für die Verweigerung ihrer Sicherheitspatente geächtet werden).

Wenn Sie einen Internet-Entwurf schreiben und ein Patent für die Technologie, über die Sie schreiben, vorhanden ist, erwähnen Sie das Patent nicht im Dokument. Holen Sie sich stattdessen auf der IETF IPR-Webseite http://www.ietf.org/ipr Informationen zur weiteren Vorgehensweise. Geistige Eigentumsrechte werden in RFCs nicht erwähnt, da RFCs nach ihrer Veröffentlichung nicht mehr geändert werden, aber sich die Kenntnisse über geistige Eigentumsrechte jederzeit ändern können. Deshalb kann ein in einem RFC aufgeführtes geistiges Eigentumsrecht unvollständig sein oder den Leser irreführen. [BCP79] enthält Text, der zu RFCs hinzugefügt werden sollte, wenn dem Autor Probleme mit geistigen Eigentumsrechten bekannt sind.

6.5 Informative und Experimentelle RFCs

Wie bereits erwähnt, sind nicht alle RFCs Standards. Tatsächlich durchlaufen viele wichtige RFCs den Standardisierungsprozess nicht. Derzeit gibt es zwei Bezeichnungen für RFCs, die nicht als Standards vorgesehen sind: Informativ, wie das Tao, und experimentell. (Es gibt noch die dritte Bezeichnung „historisch“, aber die ist für Dokumente reserviert, die aufgrund ungenügender Verwendung entfernt oder als schädlich für das Internet befunden wurden.)

Die Rolle der informativen RFCs wird in der IETF oft diskutiert. Viele Leute mögen diese RFCs, insbesondere für Spezifikationen, die außerhalb der IETF erstellt wurden, aber in IETF-Dokumenten referenziert sind. Diese RFCs sind auch für Spezifikationen nützlich, die der Wegbereiter für die Arbeit der IETF-Arbeitsgruppen sind. Einige Leute bezeichnen informative RFCs als Standards, obwohl diese keine Standards sind, um die leichtgläubige Öffentlichkeit bezüglich etwas zu täuschen, das sie verkaufen oder unterstützen. Wenn das passiert, lebt die Diskussion über informative RFCs wieder auf.

Experimentelle RFCs sind Spezifikationen, die möglicherweise interessant sind, aber nicht klar ist, wofür (wenn überhaupt Interesse besteht, sie zu implementieren), oder ob sie nach der Bereitstellung funktionieren. Wenn eine Spezifikation ein Problem behebt, aber das Problem als eher unwichtig angesehen wird oder sich nicht viele Leute die Mühe machen, das Problem mit der Spezifikation zu beheben, wird die Spezifikation als ein experimenteller RFC bezeichnet. Wenn die Spezifikation später beliebt wird (oder gut funktioniert), kann sie als ein RFC im Standardisierungsprozess erneut ausgegeben werden. Experimentelle RFCs werden auch verwendet, um mit einer Technologie zu experimentieren, die sich möglicherweise für den Standardisierungsprozess eignet, aber noch nicht erprobt ist.

Die IESG hat Richtlinien zur Auswahl des informellen und experimentellen Status herausgegeben: http://www.ietf.org/iesg/informational-vs-experimental.html.Wenn Sie ein Dokument erstellen, das möglicherweise ein experimenteller RFC werden kann, hilft Ihnen der dort beschriebene Denkprozess, Ihre Wahl zu rechtfertigen.


7. Wie zur Arbeit der IETF beitragen

7.1 Was Sie tun können

Lesen — Lesen Sie die Internet-Entwürfe aus Ihrem Bereich und kommentieren Sie diese in den Arbeitsgruppen. Seien Sie in Diskussionen freundlich und hilfreich, um den bestmöglichen Internetstandard zu erstellen. Sie sollten mehr zuhören als sprechen. Wenn Sie anderer Meinung sind, diskutieren Sie die technischen Probleme und greifen Sie keine anderen Personen an.

Implementieren — Schreiben Sie Programme, die die aktuellen Internetstandards verwenden. Standards sind nicht viel wert, wenn Sie den Internetbenutzern nicht zur Verfügung stehen. Implementieren Sie auch unbedeutende Standards, da diese mehr Bedeutung erhalten, wenn Sie in mehr Softwareanwendungen verwendet werden. Melden Sie alle Probleme mit Standards der zuständigen Arbeitsgruppe, damit der Standard in Folgeversionen korrigiert werden kann. Einer der oft zitierten Grundsätze der IETF ist „Ausführbarer Code gewinnt“. Sie können die Standards unterstützen, die Sie verbreiten möchten, indem Sie mehr ausführbaren Code erstellen. Sie können bei der Entwicklung von Protokollen helfen, bevor diese Standards werden, indem Sie von I-Ds implementieren (aber nicht öffentlich bereitstellen), um sicherzustellen, dass die Autoren gute Arbeit geleistet haben. Wenn Sie Fehler oder Auslassungen finden, bieten Sie Verbesserungen auf Grund Ihrer Implementierungserfahrung an.

Schreiben — Bearbeiten oder schreiben Sie an Internet-Entwürfen in Ihrem Fachbereich mit. Machen Sie das für die Internetgemeinde, nicht um Ihren Namen (oder noch schlimmer, den Namen Ihres Unternehmens) in einem Dokument zu verewigen. Die Autoren von Entwürfen sind technischer (und manchmal persönlicher) Kritik ausgesetzt. Tragen Sie die Kritik gelassen und nutzen Sie sie, um Ihren Entwurf zu verbessern und um den besten und interoperabelsten Standard zu erstellen.

7.2 Was Ihr Unternehmen tun kann

Teilen — Vermeiden Sie proprietäre Standards. Wenn Sie ein Implementierer sind, zeigen Sie eine starke Vorliebe für IETF-Standards. Wenn die IETF-Standards nicht so gut wie die proprietäten Standards sind, arbeiten Sie daran, die IETF-Standards zu verbessern. Wenn Sie ein Käufer sind, vermeiden Sie Produkte, die proprietäre Standards verwenden, die mit den offenen Standards der IETF konkurrieren, und teilen Sie das den Unternehmen mit, deren Produkte Sie kaufen.

Öffnen — Wenn Ihr Unternehmen ein Patent kontrolliert, das in einem IETF-Standard verwendet wird, überzeugen Sie das Unternehmen, das Patent kostenlos für die Implementierung des Standards zur Verfügung zu stellen. In den letzten Jahren, haben Patente viele ernsthafte Probleme für Internetstandards verursacht, da sie verhindern, dass einige Unternehmen die Standards implementieren können. Glücklicherweise, bieten viele Unternehmen unbefristete Lizenzen für bestimmte Patente an, um die IETF-Standards zu unterstützen. Diese Unternehmen werden gewöhnlich mit positiver Publicity belohnt, da sie nicht so raffgierig oder kurzsichtig wie andere Patentinhaber sind.

Teilnehmen — Werden Sie ein Mitglied der ISOC. Noch wichtiger ist es, alle Unternehmen, die vom Internet profitieren, als ISOC-Mitglieder anzuwerben, da dies die größten finanziellen Vorteile für die Gruppe hat. Außerdem profitiert davon das gesamte Internet.


8. IETF und die Welt draußen

8.1 IETF und andere Standardisierungsgruppen

Obwohl viele IETF-Teilnehmer das gern glauben würden, existiert die IETF nicht in einem Normierungsvakuum. Es gibt viele (vermutlich zu viele) andere Normierungsorganisationen, deren Entscheidungen das Internet beeinflussen. Außerdem gibt es viele Normierungsorganisationen, die das Internet lange Zeit ignoriert haben, und nun ein Stück vom Kuchen abhaben möchten.

Im Allgemeinen versucht die IETF, freundschaftliche Beziehungen mit anderen Normierungsorganisationen einzugehen. Das ist jedoch nicht immer einfach, da andere Organisationen andere Strukturen als die IETF haben und die IETF hauptsächlich von Ehrenamtlichen geleitet wird, die es vorziehen, Standards zu schreiben, anstatt sich mit den Repräsentanten von anderen Organisationen zu treffen. Einige andere Normierungsorganisationen bemühen sich trotz der kulturellen Unterschiede um eine gute Interaktion mit der IETF.

Zum Zeitpunkt, zu dem dieses Dokument geschrieben wurde, unterhielt die IETF Beziehungen mit großen Normierungsorganisationen, einschließlich dem ITU-T (dem Telecommunication Standardization Sector der International Telecommunication Union), dem W3C (World Wide Web Consortium), dem IEEE (Institute of Electrical and Electronics Engineers) und dem Unicode Consortium. In der IAB-Satzung steht Folgendes: [BCP39]„Beziehungen sollten so informell wie möglich sein und müssen die Qualität der IETF-Spezifikationen nachweislich verbessern.“ In der Praxis bevorzugt die IETF Beziehungen auf Arbeitsgruppenebene, und formelle Beziehungen und Dokumente spielen eine untergeordnete Rolle.

Einige der Aufgaben bezüglich Beziehungen fallen der IESG zu und andere der IAB. Detailorientierte Leser erfahren viel über die formellen Methoden für den Umgang mit anderen Normierungsorganisationen in [BCP102] „IAB Processes for Management of IETF Liaison Relationships“ und [BCP103], „Procedures for Handling Liaison Statements to and from the IETF“. Der beste Ort um nachzusehen, ob die IETF eine formelle Beziehung hat, ist die Liste mit den IETF-Beziehungen unter http://www.ietf.org/liaison.In der Liste sind viele Beziehungen mit ISO/IEC JTC1-Unterausschüssen aufgeführt.

8.2 Presseberichterstattung über die IETF

Da die IETF eine der bekanntesten Organisationen für die Weiterentwicklung des Internets ist, möchte die Computerpresse (und auch die Fachpresse) über ihre Aktionen berichten. In den letzten Jahren haben einige Zeitschriften lange Zeit Reporter und Redakteure damit beauftragt, umfassend über die IETF zu berichten. Diese Reporter haben viele Narben von irreführenden Artikeln, falschen Aussagen über den Status von Internet-Entwürfen, Zitaten von Leuten, die nichts mit der Arbeit der IETF zu tun haben usw.

Die größten Fehler der Presse fallen in zwei Kategorien: Die Behauptung, dass die IETF etwas in Erwägung zieht, wenn es sich in Wirklichkeit lediglich um den Internet-Entwurf einer Arbeitsgruppe handelt, und die Behauptung, dass die IETF etwas genehmigt hat, wenn nur ein informativer RFC veröffentlicht wurde. In beiden Fällen trägt die Presse nicht die alleinige Schuld für das Problem, da sie oft von einem Unternehmen auf die Story aufmerksam gemacht wird, das Publicity für ein Protokoll möchte, das vom Unternehmen entwickelt oder unterstützt wird. Natürlich könnten die Reporter Recherchen anstellen, um mit jemandem zu sprechen, der den Sachverhalt klarstellen kann, beispielsweise mit einem WG-Vorsitzenden oder einem Area Director. Der erste Ort, an dem die Presse nach IETF-Kontakten suchen sollte, ist <http://www.ietf.org/media.html>.

Die Tatsache, dass die Reporter, die einmal einen Fehler gemacht haben, trotzdem zu IETF-Treffen kommen, zeigt, dass es möglich ist, es letztendlich doch noch richtig zu machen. Die IETF-Treffen sind nichts für Reporter, die keine Ahnung vom IETF-Prozess haben (obwohl es ein gutes Zeichen ist, dass Sie als Reporter dieses Dokument lesen). Wenn Sie außerdem glauben, dass Ihnen die Teilnahme an einem IETF-Treffen eine Titelgeschichte einbringt, werden Sie sehr enttäuscht sein.

Wenn man all dies in Betracht zieht, ist es keine Überraschung, dass es einige IETF-Mitglieder lieber haben, dass sich die Presse so weit wie möglich von den Treffen fernhält. Etwas Publicity für Protokolle, die beinahe fertig sind und nächstes Jahr eine wichtige Rolle in der Branche spielen werden, kann jedoch positiv sein. Es gibt jedoch nur selten einen Reporter, der der Versuchung widerstehen kann, ein im Entstehen begriffenes Protokoll als den Retter des Internets anzupreisen. Diese Artikel schaden dem Leser und der IETF mehr, als sie nützen.

Der Hauptgrund, warum ein Reporter zu einem IETF-Treffen kommt, ist nicht, über neue Technologien zu berichten (da er das auch bequem im Büro machen kann, indem er die Mailinglisten liest), sondern um persönlich mit Leuten zu sprechen. Leider sind die interessantesten Leute die, die auf dem IETF-Treffen am meisten beschäftigt sind. Außerdem tendieren einige Leute dazu, wegzurennen, wenn sie einen Presseausweis sehen. Ein IETF-Treffen ist jedoch ein hervorragender Ort, um mit den Autoren von Dokumenten oder den Vorsitzenden von Arbeitsgruppen zu sprechen. Die Gespräche können für Reporter hilfreich sein, die über den Status eines Protokolls berichten.

Reporter, die herausfinden möchten, was die IETF bezüglich eines bestimmten Themas macht, sollten mit mehreren Personen sprechen, die aktiv an dem diesem Thema beteiligt sind, sowie mit dem WG-Vorsitzenden. Es ist unmöglich vorherzusagen, was mit einem Entwurf passiert, wenn man sich ihn nur ansieht oder mit seinem Autor spricht. Glücklicherweise haben alle WGs Archive, die ein Reporter durchsehen kann, um Anzeichen für dem Status eines Entwurfs zu finden. Leider haben nur wenige Reporter die Zeit oder Geduld für diese Art der Recherche. Da die IETF keinen Pressesprecher hat, sprechen Zeitungen und Zeitschriften, die einen fehlerhaften Artikel veröffentlichen, nicht direkt mit der IETF und wissen deshalb oft nicht, was sie falsch gemacht haben, und wiederholen den Fehler später.


9. Sicherheitsbetrachtungen

Section 6.4.4 erklärt, warum jeder RFC einen Abschnitt mit Sicherheitserklärungen enthalten muss und was der RFC enthalten sollte bzw. nicht enthalten sollte. Außer diesen Informationen befasst sich das Dokument nicht mit der Internetsicherheit.

10. Informative References

[BCP9] Bradner, S., “-- Revision 3”, BCP 9, RFC 2026, RFC 6410, October 1996.
[BCP10] Galvin, J., “IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees”, BCP 10, RFC 3777, June 2004.
[BCP11] Hovey, R. and S. Bradner, “The Organizations Involved in the IETF Standards Process”, BCP 11, RFC 2028, October 1996.
[BCP14] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
[BCP22] Scott, G., “Guide for Internet Standards Writers”, BCP 22, RFC 2360, June 1998.
[BCP25] Bradner, S., “IETF Working Group Guidelines and Procedures”, BCP 25, RFC 2418, September 1998.
[BCP26] Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 5226, May 2008.
[BCP39] Internet Architecture Board and B. Carpenter, “Charter of the Internet Architecture Board (IAB)”, BCP 39, RFC 2850, May 2000.
[BCP45] Harris, S., “IETF Discussion List Charter”, BCP 45, RFC 3005, November 2000.
[BCP72] Rescorla, E. and B. Korver, “Guidelines for Writing RFC Text on Security Considerations”, BCP 72, RFC 3552, July 2003.
[BCP78] Bradner, S., “IETF Rights in Contributions”, BCP 78, RFC 5378, November 2008.
[BCP79] Bradner, S., “Intellectual Property Rights in IETF Technology”, BCP 79, RFC 3979, March 2005.
[BCP95] Alvestrand, H., “A Mission Statement for the IETF”, BCP 95, RFC 3935, October 2004.
[BCP97] Bush, R. and T. Narten, “Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level”, BCP 97, RFC 3967, December 2004.
[BCP101] Austein, R. and B. Wijnen, “Structure of the IETF Administrative Support Activity (IASA)”, BCP 101, RFC 4071, April 2005.
[BCP102] Daigle, L. and Internet Architecture Board, “IAB Processes for Management of IETF Liaison Relationships”, BCP 102, RFC 4052, April 2005.
[BCP103] Trowbridge, S., Bradner, S., and F. Baker, “Procedures for Handling Liaison Statements to and from the IETF”, BCP 103, RFC 4053, April 2005.
[RFC1796] Huitema, C., Postel, J., and S. Crocker, “Not All RFCs are Standards”, RFC 1796, April 1995.
[RFC2223] Postel, J. and J. Reynolds, “Instructions to RFC Authors”, RFC 2223, October 1997.
[RFC2860] Carpenter, B., Baker, F., and M. Roberts, “Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority”, RFC 2860, June 2000.
[RFC6635] Kolkman, O. and J. Halpern, “RFC Editor-Model (Version 2)”, RFC 6635, March 2012.
[RFC4677] Hoffman, P. and S. Harris, “The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force”, RFC 4677, September 2006.
[RFC4858] Levkowetz, H., Meyer, D., Eggert, L., and A. Mankin, “Document Shepherding from Working Group Last Call to Publication”, RFC 4858, May 2007.
[RFC6722] Hoffman, P., “Publishing the "Tao of the IETF" as a Web Page”, RFC 6722, August 2012.
[STD3] Braden, R., “Requirements for Internet Hosts - Application and Support”, STD 3, RFC 1123, October 1989.

A. IETF Guiding Principles

Wenn Sie so weit im Tao gekommen sind, haben Sie eine Menge darüber gelernt, wie die IETF funktioniert. In diesem Anhang finden Sie eine Zusammenfassung dessen, was Sie gelesen haben, sowie einige neue Punkte. Lesen Sie die Richtlinien, um einen neuen Blickwinkel in die Funktionsweise der IETF zu erhalten.

A.1 Allgemein

Die IETF arbeitet mit einem offenen Prozess und durch groben Konsens. Das ist nicht die einzige verwendete Arbeitsmethode, trifft aber auf alle Aspekte der IETF-Tätigkeiten zu, einschließlich der Erstellung von IETF-Dokumenten und der Entscheidung, welche Prozesse verwendet werden. Die IETF verfolgt jedoch auch Experimente und ausführbaren Code sowie die betrieblichen Prozesse der Organisation mit großem Interesse.

Die IETF arbeitet in den Bereichen, in denen sie technische Kompetenz hat.

Die IETF ist von ehrenamtlichen, aktiven Teilnehmern abhängig.

Die Teilnahme an der IETF oder einer WG ist nicht gebührenpflichtig oder organisatorisch definiert, sondern basiert auf der Selbstidentifikation und der aktiven Beteiligung durch Teilnehmer.

A.2 Management und Führung

Die IETF erkennt Führungspositionen an und erlaubt Führungskräften, Entscheidungen zu treffen, die jedoch angefochten werden können.

Die Delegierung von Macht und Verantwortung ist ausschlaggebend für die effektive Arbeit der IETF. Es sollten so viele Personen wie möglich die Leitung von IETF-Aufgaben übernehmen.

Meinungsverschiedenheiten, Beschwerden und Einsprüche sind eine Konsequenz der Beschaffenheit der IETF und sollten als normale Ereignisse betrachtet werden. Letztendlich ist es jedoch eine Gegebenheit, dass bestimmte Entscheidungen nicht effektiv angefochten werden können.

Führungspositionen sind befristet (obwohl nicht festgelegt ist, wie oft eine Führungsposition belegt werden kann).

Es ist wichtig, künftige Führungskräfte innerhalb der aktiven Gemeinde auszubilden.

Es wird ein offener gemeinschaftlicher Prozess verwendet, um die Führungskräfte auszuwählen.

Führungskräfte werden ermutigt, das Urteil zu fällen, ob ein grober Konsens erzielt wurde. Ohne formelle Mitgliedschaft, gibt es keine formellen Regeln für den Konsens.

A.3 Prozess

Obwohl die IETF im Normalfall klare und dokumentierte Prozessregeln benötigt, sollte genügend Flexibilität vorhanden sein, um ungewöhnliche Fälle mit gesundem Menschenverstand zu behandeln. Wir nutzen unser eigenes Urteilsvermögen und kodifizieren nur, wenn wir sicher sind. (Aber wir kodifizieren, wer persönliche Urteile fällen kann.)

Die technische Entwicklungsarbeit sollte durch geregelte und zielorientierte Arbeitsgruppen durchgeführt werden.

Die Teile des Prozesses, die sich als unpraktisch erwiesen haben, sollten entfernt oder optional gestellt werden.

A.4 Arbeitsgruppen

Arbeitsgruppen (WGs) sollten in erster Linie für die Qualität ihrer Ergebnisse verantwortlich sein. WG-Vorsitzende als WG-Führungskräfte, die von IETF-Führungskräften unterstützt werden, sollten als Qualitätsschützer agieren.

WGs sollten hauptsächlich für die Beurteilung der negativen Auswirkungen ihrer Arbeit auf das gesamte Internet und daher für bereichsübergreifende Überprüfungen verantwortlich sein. Die IETF-Führungskräfte sollten als eine bereichsübergreifende Rückendeckung agieren.

Die frühzeitige Überprüfung von Dokumenten, insbesondere durch WGs, ist effektiver bei der Behandlung von großen Problemen, als eine spätere Überprüfung.

Area Directors (ADs) sind für die Bildung und die Satzungsgebung von WGs, die erforderliche Anleitung und ihre Auflösung verantwortlich. WG-Vorsitzende werden nach Ermessen des verantwortlichen ADs benannt.

WG-Vorsitzende sind dafür verantwortlich, sicherzustellen, dass die WGs ihre Satzung einhalten, ihre Meilensteine erfüllen und Ergebnisse liefern, die veröffentlicht werden können. Dokument-Editoren werden nach Ermessen des WG-Vorsitzenden benannt.

ADs sind für das Organisation der letzten Überprüfung und die Genehmigung der Dokumente verantwortlich.

A.5 Dokumente

IETF-Standards beginnen oft als private Entwürfe, können WG-Entwürfe werden und werden von einem Führungsorgan unabhängig von der WG und den Einzelpersonen, die den Entwurf erstellt haben, für die Veröffentlichung genehmigt.

IETF-Standards gehören der Gemeinde, nicht dem Autor. Die Autorenschaft sowie untergeordnete Beiträge werden jedoch anerkannt und geschätzt.

Die technische Qualität und Genauigkeit sind die wichtigsten Kriterien, um den Konsens für Dokumente zu erzielen.

IETF-Spezifikationen können als informativ, experimentell, historisch, BCP (Best Current Practice) oder im Standardisierungsprozess veröffentlicht werden.

IETF-Spezifikationen im Standardisierungsprozess werden erst als zufriedenstellende Standards angesehen, nachdem interoperable, unabhängige Implementierungen vorhanden sind. (Dies ist die Verkörperung des Slogans über den „ausführbaren Code“.) Die IETF ist jedoch nicht für Interoperabilitätstests verantwortlich und bestätigt die Interoperabilität nicht.

IETF-Prozesse werden als BCP-Dokumente veröffentlicht.

Nützliche Informationen, bei denen es sich weder um eine Spezifikation noch um einen Prozess handelt, können als informativ veröffentlicht werden.

Veraltete oder überholte Spezifikationen und Prozesse sollten als historisch eingestuft werden.

Der Standardisierungsprozess sollte Spezifikationen hervorheben, die nachweislich interoperabel sind.

Dokumente im Standardisierungsprozess und BCP-Dokumente unterliegen dem IETF-weiten groben Konsens (Last Call-Prozess). Der grobe WG-Konsens reicht normalerweise für andere Dokumente aus.

Signifikante Änderungen, die aufgrund eines IETF Last Call oder einer IESG-Evaluierung vorgenommen werden, müssen an die WG zurück übermittelt werden.

Die IETF legt die Anforderungen für die Veröffentlichung und Archivierung ihrer Dokumente fest.