Zusammenfassung

  • Pull Request 42 wurde am 4. September zusammengeführt; daraus entstand Revision 11 mit optionaler Beobachtungszeit, Gültigkeitsintervall und umfangreichen Betriebshinweisen. Das Dokument ist ein Working-Group-Internet-Draft, kein RFC.
  • Gegen eine Funktionskennung in jeder Metrik entschied sich das Autorenteam ausdrücklich: Mehranbieter-Funktionen sollen offline bei der Initialisierung vereinbart werden, ohne den Selektor zur dynamischen Anpassung zu zwingen.
  • Das Ergebnis wird als formales Konfigurationsmanifest offline synchronisiert und versioniert. Im Betrieb müssen die Komponenten annehmen, dass alle Scores nach den vereinbarten Funktionen entstanden und vollständig vergleichbar sind.
  • Die Felder enthalten keine aktive Manifestversion, keinen Digest und keine Aktivierungsepoche. Ein frischer, korrekt signierter Wert kann deshalb unter einer anderen Skala entstanden sein als jener, die der Selektor anwendet.
  • Benötigt wird keine Laufzeitverhandlung der Algorithmen, sondern eine Bindung an dieselbe Manifestidentität, ein festgelegter Umgang mit Abweichungen und ein nachvollziehbarer Entscheidungsbeleg.

Die neue Betriebsregel

Am 4. September wurde Pull Request 42 in das CATS-Repository übernommen. Der Merge-Commit floss in die feste Revision 11 ein. Der Datatracker führt sie als aktives Dokument der CATS-Arbeitsgruppe mit dem IESG-Stand „I-D Exists“. Das ist weder ein abgeschlossener Standard noch ein Beleg für eine laufende Implementierung.

CATS soll Anfragen anhand von Netz- und Rechenzustand an Dienstinstanzen lenken. Rohwerte wie Verzögerung, Auslastung und verfügbare Ressourcen besitzen verschiedene Einheiten. Normalisierung bringt sie auf eine gemeinsame Skala; Aggregation bildet daraus Kategorie-Scores der Stufe 1 oder einen globalen Score der Stufe 2. Seine Aussage hängt von Grenzen, Parametern, Gewichten und der Vergleichsrichtung ab.

Revision 11 verlangt deshalb vor einer Mehranbieter-Bereitstellung eine Einigung über Scorebereich, Normalisierungsmethode und Parameter, Aggregationsformel und Gewichte sowie darüber, ob ein höherer oder niedrigerer Wert besser ist. Das Verhandlungsergebnis soll in ein formales Konfigurationsmanifest eingehen, bei der Initialisierung offline an entscheidungsrelevante Komponenten verteilt und versioniert werden.

Danach gilt eine starke Laufzeitannahme: Empfangene Scores müssen als Ergebnis der vereinbarten Funktionen und als vollständig vergleichbar betrachtet werden. Dynamische Verhandlung ist nicht erforderlich. Die Komplexität verschwindet nicht; sie konzentriert sich auf die erfolgreiche Verteilung der Konfiguration.

Warum die Kennung bewusst fehlt

Der August-Austausch zeigt die Abwägung. Pull Request 41 schlug pro Wert die angewandte Funktion, den Beobachtungszeitpunkt und die Gültigkeitsdauer vor. Eine parametergebundene Identität sollte helfen, echte Zustandsunterschiede, unterschiedliche Berechnung und veraltete Daten auseinanderzuhalten.

Am 25. August antwortete ein Mitautor, dass die Funktion nicht in jede Meldung gehört. Mehranbieter-Details seien offline beim Start zu vereinbaren. Müsste der C-PS Funktionskennungen auswerten und seinen Algorithmus im Betrieb dynamisch ändern, würde das System zu komplex. Beobachtungszeit und Gültigkeit könnten dagegen optional aufgenommen werden.

Der Beitragende akzeptierte diese Grenze: Das Framework sieht keine Neuverhandlung pro Nachricht vor; eine einmalige Offline-Einigung kann stärker sein. Revision 11 enthält folglich Observation_Time und Validity_Interval, nicht aber Function. In PR 41 heißt es, PR 42 habe die beiden optionalen Felder übernommen; PR 41 war zum Stichtag noch offen.

Dem Entwurf eine vergessene Provenienz vorzuwerfen wäre daher falsch. Er hat den Ort der Provenienz gewählt. Offen bleibt, wie dieser Ort beweist, dass alle aktiven Kopien noch übereinstimmen.

Ein gesundes System kann semantisch gespalten sein

Bei einer Aktualisierung bleiben Selektor und Hersteller A auf M1, während Hersteller B bereits M2 aktiviert. M2 verändert eine Normalisierungsgrenze oder ein Aggregationsgewicht. Beide Hersteller melden Stufe-2-Score 7. Beide Nachrichten können von erlaubten Schlüsseln stammen, gültig signiert und aktuell sein. Trotzdem stehen die beiden Siebener nicht zwingend für dieselbe Fähigkeit.

Das ist ein hypothetischer Mechanismus, kein nachgewiesener Ausfall. Er verletzt keine einzelne Prüfung des Entwurfs. Source unterscheidet Messung, Schätzung, Aggregation und Normalisierung. Observation_Time datiert die Beobachtung, Validity_Interval begrenzt ihre Nutzbarkeit. Signatur und Autorisierung binden Sender und Inhalt. Keine dieser Angaben nennt M1 oder M2.

Vor dem Merge wies ein Reviewer in PR 42 darauf hin, dass Offline-Synchronisierung in einem verteilten System nicht immer gelingt. Fehlerhafte oder unvollständige Synchronisierung solle erkannt und gemeldet werden. Die zusammengeführte Fassung behielt Manifest und Versionskontrolle, nicht aber diesen Satz. Der Kommentar ist keine Arbeitsgruppenentscheidung, zeigt aber, dass der Fehlerpfad bekannt war.

Die frühe OPSDIR-Prüfung von Revision 10 hatte „Has issues“ vergeben und Hinweise zu Mehranbieter-Vergleich, Policy-Kennungen, Kalibrierung, Fehlermanagement und Migration gefordert. Revision 11 reagiert substanziell: gewöhnliche Melderaten sollen begrenzt, Ereignisupdates erlaubt und bei fehlenden oder alten Werten letzte gute Daten, Herabstufung, Ausschluss oder reine Netzinformation genutzt werden. Alarme für Frische, Komponentenfehler und Anomalien kommen hinzu.

Versionsabweichung kann all diese Schwellen unterschreiten. Ein M2-Wert kann unter M1 plausibel aussehen. Eine Komponente mit alter Konfiguration kann technisch gesund sein. Und „letzter guter Wert“ bleibt nur dann gut nachvollziehbar, wenn sein Manifest mitgespeichert wurde.

Eine Bindung ohne Preisgabe

Die Lösung muss keine Funktion in jedes Paket schreiben. Eine kleine Identität reicht: kanonische Manifestkennung und Digest, administrativer Bereich, Komponenten-Scope, Version oder Aktivierungsepoche, Wirksamkeitszeit und Synchronisierungsstatus.

Erzeuger und Selektor weisen ihren aktiven Digest aus. Er kann mit dem Score reisen, an eine authentifizierte Sitzung gebunden oder vor der Zulassung im Management-Plane geprüft werden. Entscheidend ist nicht der Transportort, sondern die nachweisbare Verknüpfung: Berechnung und Interpretation einer Auswahl müssen demselben Manifest angehören.

Bei Abweichung entscheidet lokale Policy über Ablehnung, Rückfall auf Stufe 1, reine Netzdaten oder Warten. Ein Beleg hält Score, Zeit, beide Digests, Alarm, Ersatzweg, Entscheidung und Wiederherstellungsbedingung fest. Geheime Gewichte und Grenzen müssen nicht veröffentlicht werden; der Digest belegt Identität ohne Inhalt.

Das aktuelle CATS-Framework beschränkt den Aufbau auf eine administrative Domäne und verlangt gemeinsame Funktionen. Damit ist die Prüfung leichter, nicht überflüssig. RFC 8911 zeigt in anderem Zusammenhang, wie feste Parameter zur Identität einer Metrik gehören können. Es ist ein Vorbild, keine Vorgabe für CATS.

Quellen

  1. Datatracker — CATS-Metrikdefinition
  2. Revision 11
  3. Revision 10
  4. Datatracker-Verlauf
  5. OPSDIR-Frühprüfung
  6. Mitautor zur Offline-Einigung
  7. Antwort des Beitragenden
  8. Pull Request 41
  9. Pull Request 42
  10. Merge-Commit von PR 42
  11. Aktuelles CATS-Framework
  12. RFC 8911
  13. Heng Lu über minimale gemeinsame Regeln und lokale Wahl