Zusammenfassung

  • Ungültiger Trace Context soll eine Management-RPC nicht grundsätzlich scheitern lassen; das RESTCONF-Beispiel liefert 201 Created und startet einen neuen Trace.
  • Der neue traceparent mit Flags null und ohne altes tracestate erhält lokale Beobachtbarkeit, aber nicht die verlorene Abstammung.
  • Ein belastbarer Abgleich verbindet authentisierte Anfrage, Trace-Entscheidung, Protokollergebnis, Datastore-Beleg, Rücklesen und Servicewirkung, ohne deren Aussagebereiche zu vermischen.

Zwei zulässige Implementierungsentscheidungen

Ein Server empfängt eine Management-Anfrage mit nicht auswertbarem traceparent. Er kann die fachliche Operation fortsetzen und den Trace neu beginnen. Oder er kann nach lokaler Richtlinie ablehnen. Die aktuellen Entwürfe raten von der Ablehnung allein wegen der Trace-Werte ab, definieren aber für diesen Fall einen operation-failed-Protokollfehler.

Die Wahl ist nicht nebensächlich. Sie bestimmt, ob ein Beobachtungsfehler die Verfügbarkeit des Managementpfads beeinflusst. Entscheidend ist, dass die Wahl sichtbar bleibt.

Revision 11 des RESTCONF-Entwurfs zeigt den Fortsetzungsfall. Der Server kann einen höher versionierten traceparent und ein fehlerhaftes tracestate nicht verarbeiten. Trotzdem erzeugt er die Ressource und antwortet 201 Created. Er gibt einen neuen Trace der Version 00 zurück, setzt die Trace-Flags auf null und entfernt tracestate.

Die Operation ist erfolgreich; die ursprüngliche Korrelation endet. Der neue Trace ist keine reparierte Fortsetzung, sondern eine neue Beobachtung ab der Vertrauensgrenze.

Warum Trace Context keine Transaktionsurkunde ist

traceparent transportiert Trace- und Elternbeziehung, tracestate herstellerspezifischen und undurchsichtigen Kontext. NETCONF verwendet XML-Attribute, RESTCONF HTTP-Header. Der NETCONF-Entwurf grenzt ausdrücklich ab: Trace Context ist nicht die Konfiguration, keine Servicekennung und kein Zustandsdatensatz.

Gegenseitige Authentisierung bezeichnet den Kommunikationspartner. NACM entscheidet über Zugriffsrechte. Eine NETCONF-message-id ordnet Antwort und RPC in einer Sitzung zu. HTTP-Status, Location und ETag beschreiben die RESTCONF-Antwort. Transaktionsjournal, Rücklesen und externer Servicetest liefern weitere, eigenständige Belege.

Der Trace kann diese Belege auffindbar machen. Er kann ihre Autorität nicht übernehmen. Ein vollständiger Trace beweist weder Berechtigung noch Persistenz. Ein unterbrochener Trace widerlegt beides nicht.

Nach dem W3C-Modell werden ohne gültigen traceparent neue Trace- und Parent-IDs erzeugt; ein isoliertes tracestate ist zu verwerfen. Das verhindert die Übernahme unzuverlässigen Kontexts, erzeugt aber eine Nachweislücke zwischen altem und neuem Identifikator.

Die gefährliche dritte Variante

Fortsetzen mit dokumentiertem Reset ist beherrschbar. Explizites Ablehnen ist beherrschbar. Gefährlich ist Fortsetzen ohne Reset-Beleg. Dann interpretiert eine Retry-Logik den fehlenden Span als fehlende Ausführung und wiederholt eine bereits wirksame, womöglich nicht idempotente Änderung.

Auch das ungeprüfte Übernehmen eingehender Trace-Felder wäre falsch. W3C nennt Informationsabfluss, erzwungene Sampling-Kosten und manipulierte Kollisionen. Der NETCONF-Entwurf weist darauf hin, dass Korrelation bei der Kartierung eines verwalteten Netzes helfen kann. Ein Neustart an einer Vertrauensgrenze kann Sicherheits- oder Datenschutzpolitik sein.

Darum braucht der Betrieb einen Beleg außerhalb des Tracing-Systems: lokale Anfrage-ID, authentisierte Identität, Autorisierungsentscheidung, Anfragefingerabdruck, Trace-Disposition, Ersatz-ID, Protokollantwort, Datastore-Beleg, Rücklesen zu einer benannten Epoche und unabhängige Servicebeobachtung.

Fehlt ein Glied, bleibt es als Lücke markiert. „Kein Device-Span“ wird dann zur Aufforderung, den Übergangsbeleg zu prüfen, nicht zur automatischen Wiederholung.

Entwurfsstatus begrenzt die Aussage

Die Revisionen 09 und 11 sind aktive Internet-Drafts vom 17. September 2026 mit Ziel Proposed Standard. Sie sind keine RFCs und belegen weder Produktverhalten noch Einsatz. Auch eine YANG-Library-Ankündigung beweist keine vollständige Span-Ausgabe oder Collector-Verwahrung.

Die Entwürfe standardisieren die Schnittstelle. Die Organisation muss die Verantwortung über den Schnitt hinweg sichern.

Quellen