Resumen

  • draft-zhang-dawn-agent-discovery-framework-01, fechado el 6 de septiembre de 2026 y actualizado en Datatracker el día 7, es una aportación individual activa sin reconocimiento formal como estándar del IETF.
  • El diseño separa el descubrimiento local de una federación entre dominios. La pasarela selecciona y depura metadatos, firma una Federation Metadata Record y la entrega a pares autenticados.
  • La revisión 01 incorpora un mapa de campos MDI/FMR. Registra origen, capacidades, frescura y procedencia, pero no el conjunto autorizado de receptores, el permiso de redistribución ni la versión de la política aplicada.
  • Daniel Kade plantea una envoltura de distribución ligada al hash de la ficha. Su misión sería conservar la decisión de difusión, no certificar la identidad o calidad del agente ni autorizar su ejecución.

La propuesta fija una frontera administrativa

El registro de Datatracker identifica un Internet-Draft individual de Bin Zhang. No tiene flujo RFC, Area Director responsable ni telechat. El texto se declara informativo y puede cambiar o caducar. Es una arquitectura candidata, no una decisión del IETF.

También conviene separar el nombre DAWN de una autoridad que todavía no existe. La página oficial del grupo lo mantiene en estado BoF y dice que aún no está constituido mediante una carta. Las actas de IETF 126 recuerdan que la carta presentada era un punto de partida sin consenso. Que el borrador hable de un grupo de trabajo no modifica ese estado.

Hecha la salvedad, la revisión 01 aporta una división comprensible. Un plano local reúne anuncios de agentes dentro de una red. Puede valerse de mDNS, un directorio o mecanismos equivalentes. En el borde, una Federation Gateway decide qué parte del inventario puede salir. El Export Policy Engine excluye agentes, oculta campos y produce una FMR ligera para otras organizaciones.

La Capability Card completa permanece en el origen y se obtiene aparte mediante unicast autenticado. Así se evita replicar el documento más sensible y se conserva un control de acceso en la fuente. Además, la pasarela puede entregar subconjuntos distintos a vecinos distintos. La soberanía de los datos se materializa en ese filtro.

El mapa de la ficha expone un vacío

La diferencia oficial entre 00 y 01 añade la correspondencia concreta entre Minimum Discoverable Information y FMR. Ya no es necesario adivinar qué conserva el objeto que se replica.

La ficha puede llevar identificador y tipo de entidad, punto de conexión, resumen de capacidades, referencia a la Capability Card, pista de autenticación, referencia de confianza, fecha, TTL y procedencia. También incluye la pasarela de origen y un indicador de estado. Un campo geográfico sirve como aproximación al Scope Hint de MDI.

La palabra scope puede inducir a error. Ese dato orienta sobre geografía, no enumera receptores permitidos. Tampoco el TTL es una licencia: controla la caducidad del dato, no las copias realizadas durante su vigencia. La procedencia permite atribuir el registro, no conocer el contrato de difusión.

No aparecen una etiqueta de confidencialidad, una audiencia, una prohibición de reenvío, un límite de saltos o la identidad y época de la política. Por eso B puede comprobar que A firmó una ficha sin saber si A permitió que B se la entregara a D.

En el primer enlace el operador aún dispone del contexto. A configura una salida para B y otra para C; el propio borrador admite subconjuntos por vecino. La pérdida ocurre cuando la ficha entra en la base federada de B y B la utiliza en otra relación de sincronización.

La firma resuelve una pregunta distinta

Cada FMR saliente debe ir firmada por la pasarela que la origina. El receptor comprueba la firma y desecha lo que no supere la prueba. De ese modo, un participante no puede modificar la ficha de otro origen ni suplantarlo. La arquitectura reconoce el límite: un miembro admitido todavía puede inventar agentes locales propios. La admisión a la federación se gobierna fuera del protocolo.

La firma prueba autoría de los bytes. No prueba autorización de cada copia posterior. D puede recibir intacta la ficha de A y verificarla con éxito; esa misma verificación no revela si A incluyó a D en el público permitido.

El modelo estructurado reduce la ambigüedad mediante sesiones conocidas. Su apéndice prevé política de importación y exportación por par. En una federación cerrada resulta posible configurar cada relación, limitar reflectores y reconstruir el trayecto.

Gossip busca escalabilidad y tolerancia a fallos. Cada pasarela intercambia resúmenes de su directorio con unos pocos vecinos y después comparte las fichas ausentes o nuevas. El borrador advierte de forma explícita que es difícil aplicar políticas precisas por registro. En una federación mixta, un puente transporta una FMR común entre overlays diferentes. Ese objeto común facilita la interoperabilidad, pero una restricción que solo vive en la configuración del primer protocolo no cruza automáticamente el puente.

La conclusión no es prohibir gossip. Es impedir que “firma válida” pase a significar “redistribución permitida”.

Conservar la decisión sin engordar la FMR

Una distribution-envelope pequeña puede quedar vinculada criptográficamente al hash exacto de la FMR. Contendría origen, identificador de política y época. Nombraría una clase de audiencia o un segmento de federación y elegiría una regla de continuidad: no reenviar, entregar solo al siguiente salto indicado o circular dentro de un segmento limitado.

La envoltura añadiría vencimiento, referencia de retirada y un recibo opaco de la decisión de exportación. El origen podría auditar el resultado sin revelar toda su configuración. Un puente de protocolos podría firmar un recibo del salto anterior, dejando claro qué componente asumió la obligación de preservar la restricción.

Ningún campo impedirá que un vecino deshonesto copie el dato fuera del sistema. Sí permite que una implementación conforme rechace un reenvío, que el registro operativo explique la decisión y que una auditoría distinga entre una ruta permitida y una ficha meramente auténtica.

La envoltura no debe resolver por acumulación todos los problemas de agentes. No es una identidad estable, una puntuación de confianza, una prueba de capacidad ni permiso para invocar. La arquitectura excluye expresamente la evaluación integral de confianza, la negociación de capacidades, las reglas comerciales y la indexación abierta de Internet. El nuevo objeto solo conservaría la respuesta a quién puede seguir recibiendo estos metadatos.

Fuentes