Zusammenfassung

  • Die FANN-Chairs nahmen draft-dong-fann-problem-statement-00 als WG-Dokument an und verlangten eine Neueinreichung unter draft-ietf-; entschieden wurde über ein Arbeitspaket, nicht über eine betriebliche Aktion.
  • Der Entwurf verweist die Aktionskoordination auf weitere Untersuchung außerhalb seines Umfangs. Eine Benachrichtigung kann eine lokale Reaktion informieren, aber weder Empfänger wählen noch Handlung erlauben oder einen Erfolg nachweisen.

Die Annahme hat einen engen Gegenstand

Die öffentliche Schlussfolgerung beschreibt ihren Inhalt genau. Der Call ist beendet, der individuelle Entwurf ist als FANN-WG-Dokument angenommen, die Autoren sollen dieselbe Fassung unter anderem Dateinamen einreichen, und die Rückmeldungen des Calls gehören in spätere Iterationen. Das sind nachprüfbare Verfahrenszustände. Sie wählen kein Lösungsprotokoll, konfigurieren keinen Controller, ordnen keine Verkehrsänderung an und versprechen keinen Dienstzustand.

Auch der ursprüngliche Call stellte nur die Frage, ob die Gruppe diese Problemstellung übernehmen soll, und nannte ein Ende. Zustimmung, Vorbehalt oder Informationsbedarf sind Belege für eine Agendaentscheidung. Sie sind keine Vollmacht der Betreiber, die später eine Meldung annehmen, Betriebsdaten schützen, eine Aktion auslösen oder deren Fehlkosten tragen müssen.

Der aktuelle Dokumentstatus bleibt eigenständig. Der Datatracker führt draft-dong-fann-problem-statement-00 als aktiven individuellen Internet-Draft, nicht von der IETF unterstützt und ohne formale Stellung im Standardprozess. Die Bitte um einen Nachfolgenamen setzt eine nächste Datei in Gang; sie macht den individuellen Text, eine spätere WG-Fassung, eine weitere Entscheidung und einen RFC nicht zu demselben Ereignis.

Eine Meldung trägt ihre mögliche Aktion nicht in sich

Die Problemstellung zieht die technische Grenze selbst. Sie behandelt schnelle Benachrichtigung über Netzbedingungen. Weniger Paketverlust oder schnellere Minderung können aus Aktionen folgen, die solche Meldungen verarbeiten; sie sind aber weder Ziel noch Anforderung des Benachrichtigungsmechanismus. Informationszustellung, Interpretation und Änderung eines realen Systems sind drei unterschiedliche Ereignisse.

Auch eine schnelle Meldung lässt offen, wer sie sendete, welcher Empfänger sie verarbeiten darf, welchen Geltungsbereich die Beobachtung hat, welche lokale Regel sie mit einer Aktion verbindet, was reversibel ist und wer bei einer falschen Umschaltung, Schutzaktion oder Lastverlagerung den Verlust trägt. Die Annahme eines Problems beantwortet diese Fragen nicht an Stelle ihrer Risiko­träger.

Der Entwurf erklärt die Koordination von Aktionen ausdrücklich zur weiteren Untersuchung außerhalb seines Umfangs. Empfänger können im jeweiligen Szenario durch Konfiguration oder Signalisierung bestimmt werden und nach Rolle oder Interesse abonnieren. Zwei Empfänger können denselben Hinweis erhalten und dennoch unterschiedliche Rechte, Verträge, Risikogrenzen und Rückrollmöglichkeiten besitzen. Diese Differenz ist kein Leerraum, den „das Netz reagiert“ ausfüllen darf.

Eine Empfehlung in einer Meldung braucht deshalb weiterhin eine lokale Zulassungsregel. Eine Quelle aus einer anderen Domäne gewinnt kein Vertrauen, weil die Problemstellung angenommen wurde. Eine plausible Beobachtung autorisiert keine Verkehrsänderung. Eine Verbesserung an einem Standort wird nicht zur Eigenschaft eines künftigen Protokolls. Jeder Übergang braucht eigenen Verantwortlichen, eigenen Beleg und eigenen Rückweg.

Die Charter schafft Arbeitsspielraum, keine Betriebsgewalt

Die FANN-Charter nennt Problemstellung, Anforderungen und Lückenanalyse als Arbeiten zur Führung der WG und ihrer verbundenen Ergebnisse. Sie erklärt, warum die Gruppe das Thema behandeln darf. Sie bestimmt nicht, wer in einer konkreten Topologie ein Ereignis empfängt, begründet kein domänenübergreifendes Vertrauen, genehmigt keine Automatisierung und verwandelt kein Zustellziel in ein Serviceversprechen.

Der technische Text legt keine Sicherheitsmechanismen fest, verlangt aber, dass künftige Lösungen Vertrauensgrenzen bei Abonnements, Autorisierung von Quellen und Schutz sensibler Betriebsdaten behandeln. Auch Teilbereitstellung und Konsistenz entsprechender Aktionen müssen bewertet werden. Das sind keine durch Annahme erledigten Fußnoten, sondern Gründe, spätere Lösung, lokale Policy und Produktionsresultat getrennt zu dokumentieren.

Vor einer folgenreichen Änderung braucht ein Betreiber daher mehr als ein angenommenes Problem: geprüfte Version, akzeptierte Ereignisklassen, Quellenidentität und Autorisierungsprüfung, Empfängerrolle, Aktionsregel, Ratenlimit, Dämpfung, Fehlerverhalten, Beobachtbarkeit, Rückrollverantwortung und Prüftrigger. Ein späteres FANN-Dokument kann einzelne Felder interoperabel machen. Es kann sie nicht für jedes Netz vorab genehmigen.

Ein schlanker gemeinsamer Beleg, eine lesbare lokale Entscheidung

Die gemeinsame Ebene kann klein bleiben: Beginn und Ende des Calls, Chair-Schlussfolgerung, genaue Version, Nachfolger wenn vorhanden, Umfangsgrenze und nächster öffentlicher Entscheidungspunkt. Damit lässt sich prüfen, woran die WG arbeiten will und was sie noch nicht entschied. Daneben gehört der lokale Beleg: Quelle, Autorisierungsregel, Policy-Version, Empfängerklasse, Testumgebung, gemessenes Verhalten, Aktionsgrenzen, Ausnahmen, Verantwortlicher und Rückrollrecht.

Diese Trennung verhindert zwei Fiktionen: Ein öffentlicher Verfahrensstand wird nicht als lokale Kontrollentscheidung ausgegeben, und eine lokale Aktion nicht als IETF-Konsens beworben. Das entspricht dem engen Heng-Lu-Grundsatz: Teilnahme liefert Evidenz und Disziplin, aber kein Mandat über Abwesende oder über jene, die den Verlust tragen.

Als Nächstes zählen getrennte Nachweise: die erste draft-ietf-fann--Einreichung, die dokumentierte Behandlung von Call-Kommentaren, ein Text mit Koordinationsmodell, Regeln für Quellenauthentisierung und Empfängerautorisierung, Verhalten bei Teilbereitstellung und eine spätere WG-Entscheidung. Bis dahin ist die präzise Aussage: FANN hat ein Problem zur Arbeit angenommen; die Aktion bleibt bei demjenigen, der das Netz kontrolliert und für sie einsteht.

Quellen

  1. FANN-Chair-Schlussfolgerung zum Call for Adoption
  2. FANN Call for Adoption der Problemstellung
  3. Aktueller Datatracker-Eintrag
  4. Fast Network Notifications Problem Statement, Revision 00
  5. FANN-Charter