Zusammenfassung

  • Die IETF-Arbeitsgruppe grip ("G & R for Security Incident Processing") bestand laut Datatracker von Februar 1995 bis Dezember 2001; Vorsitzende waren Barbara Y. Fraser und Klaus-Peter Kossakowski.[^1][^3]
  • Ihr praktisches Erbe ist RFC 2350, "Expectations for Computer Security Incident Response" von N. Brownlee und E. Guttman, veröffentlicht am 1. Juni 1998 als Internet Best Current Practice (BCP 21).[^5][^7]
  • BCP 21 enthält bis heute genau einen RFC — RFC 2350. Kein Dokument hat ihn ersetzt; es existieren Errata.[^6]
  • Datatracker warnt selbst, dass Daten abgeschlossener Arbeitsgruppen "occasionally incorrect" sind — die genauen Gruppendaten bleiben also mit Vorbehalt zu lesen.[^1]
  • Heute ist der RFC Editor, nicht die längst geschlossene Gruppe, die Instanz, an der sich die Norm verifizieren lässt.

Das Muster ist Vertrautes mit einem doppelten Boden. Eine Institution gründet eine Arbeitsgruppe; die Gruppe schreibt einen Text; die Gruppe wird geschlossen; der Text überlebt sie um Jahrzehnte. Im Fall von grip hat das Überleben nichts mit Stillstand zu tun: RFC 2350 definiert bis heute, welche Erwartungen Organisationen an einen Computer Security Incident Response Team (CSIRT) stellen dürfen — Dienstleistungsbeschreibung, Kontaktwege, Autorisierung, Politik der Offenlegung. Nichts anderes hat diese Rolle übernommen.

Die Zahlenreihenfolge zeigt die Konstruktion dieser Behauptung: Der Datatracker-Eintrag zur Gruppe nennt den Namen "G & R for Security Incident Processing", während der Charter-Text vom ausgeschriebenen "Guidelines and Recommendations for Security Incident Processing" spricht — eine Diskrepanz in den Primärquellen, die dieser Text nicht geglättet, sondern benennt.[^1] Die Datumsangaben (Start Februar 1995, Abschluss Dezember 2001) stammen aus der Datatracker-Liste der abgeschlossenen Gruppen und sind mit derselben Warnung der Plattform zu lesen.[^3] RFC 2350 selbst lässt sich der Draft-Serie

draft-ietf-grip-framework-irt zuordnen, deren Revisionen von September 1995 bis September 1997 reichen.[^7]

Der Mechanismus, der hier greift, ist nicht Verschleiß, sondern Verdrängung der Zuständigkeit: Die fragliche normative Substanz ist heute nicht der Gruppe, sondern dem RFC-Editor-Verlagsprozess zugeordnet. Wer RFC 2350 auf Fehler prüft, wendet sich an die Errata-Register; wer die Entstehungsgeschichte braucht, nutzt die Datatracker-Historie. Eine Gruppe, die seit einem Vierteljahrhundert nicht mehr tagt, kann auf keine dieser Anfragen antworten. Das ist kein Vorwurf an die beteiligten Personen — Fraser und Kossakowski arbeiteten unter den Bedingungen einer Gemeinwohl-Normung, die solche Nachlässe nicht vorsieht.

Es ist aber ein Befund für alle, die heute Standards schreiben: Der Text überdauert die Institution fast immer.

Was folgt daraus Praktisches? Erstens: Jedes BCP verdient eine dokumentierte Nachfolge-Erwartung — wer aktualisiert, wer widerruft, wer bei inhaltlichen Fragen antwortet. Zweitens: Errata-Register und Historie sollten als Teil des Standards behandelt werden, nicht als Randnotiz; ohne sie wäre die Herkunft von BCP 21 fast unauffindbar. Drittens: Abgeschlossene Gruppen wie grip verdienen eine sorgfältige, öffentlich prüfbare Abschlussdokumentation, gerade weil der Datatracker selbst die eigene Datenqualität relativiert.

[^1]: IETF Datatracker, Gruppenprofil grip — https://datatracker.ietf.org/wg/grip/about/ [^2]: Datatracker, Liste der abgeschlossenen Gruppen — https://datatracker.ietf.org/group/concluded/ [^3]: RFC Editor, RFC 2350 (Infoseite) — https://www.rfc-editor.org/info/rfc2350/ [^4]: Datatracker, RFC 2350 — https://datatracker.ietf.org/doc/rfc2350/ [^5]: RFC Editor, BCP 21 — https://www.rfc-editor.org/info/bcp21/ [^6]: Datatracker, Änderungshistorie zu RFC 2350 — https://datatracker.ietf.org/doc/rfc2350/history/ [^7]: RFC 2350, Volltext (HTML) — https://www.rfc-editor.org/rfc/rfc2350.html [^8]: Datatracker API, Gruppe 1007 — https://datatracker.ietf.org/api/v1/group/group/1007/