Zusammenfassung

  • draft-zhang-dawn-agent-discovery-framework-01 ist auf den 6. September 2026 datiert und im Datatracker zuletzt am 7. September aktualisiert. Es handelt sich um einen aktiven Individualentwurf ohne formale Stellung im IETF-Standardisierungsprozess.
  • Die Architektur trennt lokale Erkennung von einer domänenübergreifenden Föderation. Ein Gateway wendet Exportregeln an, bereinigt Metadaten und signiert einen Federation Metadata Record für authentisierte Peers.
  • Revision 01 bildet DAWNs Minimum Discoverable Information auf FMR-Felder ab. Herkunft, Fähigkeiten, Aktualität und Provenienz sind enthalten; autorisierte Empfänger, Weitergaberecht und die Version der angewandten Exportregel fehlen.
  • Daniel Kade schlägt einen kleinen, an den Datensatz-Hash gebundenen Verteilungsumschlag vor. Er bewahrt die Freigabeentscheidung, ohne Identität, Vertrauenswürdigkeit oder Nutzungsbefugnis des Agenten zu bescheinigen.

Der Entwurf setzt eine Verwaltungsgrenze

Der Datatracker-Eintrag führt den Text von Bin Zhang als aktiven Individual Draft. Weder RFC Stream noch verantwortlicher Area Director oder Telechat sind angegeben. Der Text strebt einen informativen Charakter an. Die neue Fassung ist deshalb ein Vorschlag, keine vom IETF beschlossene Architektur.

Auch die institutionelle Bezeichnung ist vorläufig. Im Entwurf ist von einer DAWN Working Group die Rede. Die offizielle DAWN-Seite zeigt dagegen weiterhin den Zustand BoF und „Not chartered yet“. Das Protokoll der IETF-126-Sitzung beschreibt ein Working-Group-Forming BoF; der Chartertext war Ausgangspunkt und noch kein Konsens. Ein Individualentwurf kann diesen Schritt nicht sprachlich vorwegnehmen.

Innerhalb dieser Grenzen entwickelt Revision 01 eine nachvollziehbare Zweiteilung. Die Local Discovery Plane sammelt Agentenankündigungen innerhalb eines Standorts, etwa per mDNS oder lokalem Verzeichnis. An der Verwaltungsgrenze steht ein Federation Gateway. Seine Export Policy Engine wählt Agenten aus, entfernt sensible Felder und erzeugt einen knappen FMR für andere Domänen.

Die ausführliche Capability Card bleibt am Ursprung und wird bei Bedarf über authentisierten Unicast abgerufen. Dadurch muss die Föderation nicht das sensible Vollprofil replizieren, und der Ursprung behält eine zweite Zugriffskontrolle. Unterschiedliche Peers dürfen unterschiedliche Teilmengen sehen. Diese erste Auswahl ist das konkrete Instrument der im Entwurf versprochenen Datensouveränität.

Die neue Feldkarte zeigt eine Leerstelle

Der offizielle Vergleich mit Revision 00 ergänzt eine Tabelle, die DAWNs Minimum Discoverable Information an den Federation Metadata Record bindet. Damit lässt sich prüfen, welche Governance-Information die Domänengrenze tatsächlich überquert.

Der FMR kann Entitätskennung und -typ, einen erreichbaren Endpunkt, Capability Summary und Verweis auf die Capability Card tragen. Hinzu kommen Authentication Hint, Trust Reference, Veröffentlichungszeit, TTL, Provenienz, Origin-GW-ID und Record-Flag. Ein Geographic-Hint nähert den Scope Hint des MDI an.

Empfänger können feststellen, welches Gateway die Bytes erzeugt hat, ob der Eintrag noch frisch ist und wo ausführlichere Angaben liegen. Die Herkunft bleibt sichtbar, obwohl das Vollprofil am Ursprung verbleibt.

Nicht sichtbar ist der erlaubte Weg nach dem ersten Export. Die Tabelle enthält keinen Empfängerkreis, keine Vertraulichkeitsklasse, kein Weitergabeverbot, keine maximale Pfadlänge und keine Kennung oder Epoche der Exportregel. Geografie ist Kontext, keine Autorisierung. Eine TTL begrenzt das Alter, nicht die Reichweite der Kopien während der Gültigkeit. Provenienz zeigt den Ursprung, nicht die Offenlegungsbedingung.

Beim ersten Peer bleibt die Lücke in der Konfiguration verborgen. A weiß, dass B eine bereinigte Fassung erhält und C nicht. Sobald B den Eintrag in seine Federated Agent Directory übernimmt und an einer weiteren Synchronisation teilnimmt, lässt sich aus dem FMR nicht mehr ablesen, ob A auch D zulassen wollte.

Eine gültige Signatur ist keine Weitergabelizenz

Das Sicherheitsmodell verlangt eine Signatur des Ursprungsgateways für jeden ausgehenden FMR. Empfänger prüfen sie und verwerfen ungültige Einträge. Ein Teilnehmer kann damit weder den Eintrag eines anderen Ursprungs unbemerkt verändern noch in dessen Namen signieren. Der Entwurf nennt auch die Grenze: Ein zugelassenes bösartiges Gateway kann Behauptungen über seine eigenen lokalen Agenten erfinden. Die Aufnahme in die Föderation ist administrative Policy außerhalb des Protokolls.

Gibt B den unveränderten, von A signierten Eintrag an D weiter, kann D die Herkunft korrekt verifizieren. Die erfolgreiche Prüfung sagt jedoch nicht, ob A die Offenlegung an D erlaubt hat. Authentizität und Verteilungsbefugnis bleiben zwei verschiedene Aussagen.

Im strukturierten Peering lässt sich die zweite Aussage lokal stützen. Der Anhang sieht Import- und Exportregeln pro Peer vor. Eine geschlossene Föderation kennt ihre Sessions, kann Route Reflection begrenzen und einen Abfluss entlang definierter Beziehungen untersuchen.

Gossip optimiert für horizontale Skalierung und Fehlertoleranz. Gateways tauschen Directory-Digests mit wenigen Nachbarn aus und liefern fehlende oder geänderte FMRs nach. Der Entwurf räumt selbst ein, dass genaue Verteilungsregeln pro Datensatz dabei schwer durchzusetzen sind. In einer gemischten Föderation kann eine Bridge denselben FMR zwischen strukturiertem Peering und Gossip übertragen. Das gemeinsame Format schafft Interoperabilität; eine Beschränkung, die nur in der ersten Transportkonfiguration lebt, überquert die Bridge nicht automatisch.

Gossip ist damit nicht grundsätzlich unbeherrschbar. Die Architektur kann im Moment nur die Herkunft maschinenlesbarer bewahren als den Offenlegungswillen des Ursprungs.

Ein schlanker Umschlag für die Freigabe

Der FMR muss nicht zu einem zweiten Vollprofil anwachsen. Eine kryptografisch an seinen exakten Hash gebundene distribution-envelope könnte Origin-GW-ID, Policy-Kennung und Policy-Epoche tragen. Sie benennt eine Empfängerklasse oder ein Föderationssegment und wählt eine Weitergabestufe: keine Weitergabe, nur an einen angegebenen nächsten Hop oder Zirkulation innerhalb eines begrenzten Segments.

Erforderlich wären außerdem Ablaufzeit und ein Verweis auf Withdrawal oder Widerruf. Eine undurchsichtige Export-Receipt-ID würde dem Ursprung die Prüfung der Policy-Engine-Ausgabe erlauben, ohne interne Regeln offenzulegen. Bei einem Protokollwechsel könnte eine Previous-Hop-Quittung festhalten, welche Bridge die Wahrung der Grenze übernommen hat.

Ein unredlicher Peer kann Daten weiterhin außerhalb des Protokolls kopieren. Der engere Nutzen ist dennoch erheblich: Konforme Software kann unzulässige Weitergabe verweigern, Logs können die angewandte Regel nennen, und Prüfer können einen erlaubten Pfad von einem bloß echten Datensatz unterscheiden. Kann eine Bridge die Bedingung nicht darstellen, muss sie die Umwandlung ablehnen, statt die Bedingung still zu löschen.

Der Umschlag darf nicht alle offenen DAWN-Fragen aufnehmen. Stabile Identitätsvergabe, umfassende Vertrauensbewertung, Capability Negotiation, offene Internet-Indexierung und Geschäftsregeln nennt der Entwurf ausdrücklich außerhalb seines Umfangs. Die neue Schicht sagt nicht, ob ein Agent sicher oder einsatzberechtigt ist. Sie bewahrt nur, unter welcher Policy seine Metadaten weitergegeben werden dürfen.

Quellen