Resumen

  • Las minutas de Agentproto describen las manos alzadas como una impresión no vinculante de la sala, pendiente de confirmar en la lista. No documentan una Working Group constituida ni una carta aprobada.
  • El alcance inicial obtuvo 38 sí, 124 no y 40 sin opinión. Los entregables obtuvieron 92–58–49. Formar una WG «con esta carta» obtuvo 154–51–5.
  • No hay una contradicción necesaria: alguien puede querer un foro y exigir otro alcance. Sin embargo, «con esta carta» conecta el resultado general con un texto específico y obliga a explicar qué reparaciones condicionaban el apoyo.
  • Los totales cambian entre preguntas y no existe una tabla cruzada por participante. Las fuentes no permiten decir que las mismas 124 personas también formaron parte de los 154 sí.
  • El texto de la reunión está fijado en el commit a9405f3d5d0a4e8c67342d7945137c8230b9cd05. Los correos y una pull request posterior, aún abierta y sin fusionar, muestran que seguían sin resolverse límites sustantivos.
  • Al corte, Agentproto seguía en estado BOF, sin carta. Una matriz de conciliación de predicados podría unir preguntas, versión, objeciones, cambios, confirmación en lista y decisión del IESG sin convertir consenso aproximado en una elección.

La exactitud aritmética no basta

El acta publicada de Agentproto registra una sesión WG-forming celebrada el 23 de julio de 2026. También advierte que el texto es un borrador para revisión de los chairs. Se compiló con ayuda de un agente de IA a partir de notas humanas, el chat Zulip y las diapositivas; los nombres y afiliaciones eran provisionales, la asistencia todavía no estaba disponible y la responsabilidad de corregirlo seguía en manos de los chairs.

Esta advertencia no invalida el documento. Define su fuerza probatoria. Es una fuente institucional relevante, no una transcripción definitiva. Cada uso de sus cifras debe conservar ese límite.

La agenda versión 01 había separado la presentación de necesidades y componentes, el micrófono abierto, las llamadas de consenso y el cierre. La entrada previa sobre los BoF de IETF 126 explicó que una reunión formativa busca comprobar consenso, energía y un alcance suficientemente estrecho. No es extraño que esas tres dimensiones arrojen resultados distintos.

Lo extraño sería comprimirlas en un único «aprobado».

Ocho preguntas, ocho predicados

La primera pregunta —problema entendido, resoluble y útil— terminó 124–72–14. La necesidad clara de interoperabilidad, 155–30–8. La idoneidad del IETF como sede, 158–30–14. El alcance inicial correcto, 38–124–40. Los entregables iniciales correctos, 92–58–49. Formar una WG «con esta carta», 154–51–5. La disposición a escribir o revisar, 137–17–40. La disposición a implementar, 42–28–40.

Las minutas interpretan el conjunto sin ocultar la fricción: fuerte apoyo al valor del problema, a la interoperabilidad, al IETF y a formar una WG; falta de apoyo al alcance tal como estaba escrito; opiniones divididas sobre los entregables. Laurent Ciavaglia añadió que preguntar si algo era «correcto» no debía leerse como preguntar si estaba «completo». El debate de alcance y carta seguiría por correo.

Los denominadores ofrecen una segunda advertencia. Las ocho preguntas suman, respectivamente, 210, 193, 202, 202, 199, 210, 194 y 110 respuestas. No son ocho escrutinios de un cuerpo fijo. La caída en la pregunta sobre implementación tampoco puede leerse sin conocer quién decidió responder.

Además, solo tenemos marginales. El cuadro no cruza la respuesta a alcance con la respuesta a formación. Es matemáticamente posible que una parte grande de quienes dijeron no al alcance dijera sí a la WG; también es posible un solapamiento menor. Ninguna fuente revisada lo resuelve. Una frase que atribuyera ambos actos a «las mismas 124 personas» fabricaría un dato individual inexistente.

La IETF no necesita publicar boletas nominativas para reparar esa carencia. Los chairs pueden describir de forma agregada qué significaba el no: demasiado ancho, incompleto, ambiguo, mal repartido o dependiente de trabajo ajeno. También pueden aclarar si el sí a la formación se entendió sujeto a cambios concretos. Eso preserva la sustancia sin crear un mapa de facciones.

Una respuesta general puede depender de una condición

La lectura benigna es sólida. Un participante puede sostener que el problema merece una sede estable y rechazar el mecanismo propuesto. Puede querer una WG después de quitar el ciclo de vida de sesión. Puede considerar que la palabra «correcto» exige completitud. Puede aceptar la finalidad y rechazar la lista de entregables. El proceso de carta existe precisamente para negociar esas diferencias.

El problema aparece porque la pregunta 6 no decía solo «¿Debe el IETF trabajar en esto?». Decía «¿Formar una WG con esta carta?».

El RFC 5434 recomienda descomponer preguntas para localizar acuerdo y desacuerdo. También usa como pregunta integral el apoyo a formar una WG con una carta concreta y explica que ahí se prueba si la carta está lista. Por eso, el sí general y el no al componente de alcance pueden coexistir, pero no deben quedar sin enlace. La síntesis necesita formular la condición.

Si los 154 sí significaban «sí, después de corregir el alcance», deben identificarse las correcciones. Si «correcto» se confundió con «completo», hay que nombrar las omisiones. Si una versión futura altera sustancialmente el texto, no puede presentarse como si ya hubiese recibido 154 adhesiones en Viena. Recibirá autoridad por sus actos posteriores, no por retroacción.

Esta disciplina protege ambas posiciones. Evita que el 154 se use como cheque en blanco y que el 124 se use como veto a cualquier trabajo sobre comunicación de agentes.

El objeto de la pregunta tiene un hash histórico

Las minutas enlazan la carta y señalan que el texto vigente estuvo visible. El repositorio oficial conserva la versión del commit a9405f3…, creado el 21 de julio, dos días antes del BoF. Al corte, era el único commit devuelto para ese archivo.

La carta incluía comunicación agente-agente y agente-herramienta, además de mecanismos definidos de comunicación humano-agente. Sus consideraciones cubrían identidad separada, autorización, confidencialidad, integridad y auditabilidad. Prometía un protocolo de sesión de Standards Track y un marco informativo. El primero debía abarcar sesiones breves o prolongadas, recuperación, intercambio concurrente de datos con distintos ritmos y topologías punto a multipunto.

No sabemos si cada participante leyó cada línea. Fijar el commit no pretende leer sus mentes. Impide que «esta carta» apunte mañana a un texto diferente. El versionado permite decir qué recibió la pregunta y qué recibió una revisión posterior.

El debate posterior no fue cosmético

En su mensaje del 12 de agosto, «Sussing out points of disagreement on the charter», Suresh Krishnan informó de dos reescrituras desde cero y enumeró seis disputas: sustrato o semántica, ciclo de vida de sesión, correlación o prueba de vinculación, punto a multipunto o bilateral, cantidad/estado/orden de entregables y precisión terminológica.

Son decisiones sobre el producto institucional, no sobre estilo editorial.

La pull request 77, abierta después de la reunión contra el commit base de Viena, propuso reducir el encargo a primitivas mínimas. Sacaría el ciclo de vida de sesión y convertiría el entregable principal en una referencia de interacción con una envolvente de vinculación. Seguía abierta, no fusionada. Su descripción declara análisis del chat asistido por IA; eso ayuda a valorar su procedencia, pero no le concede autoridad.

El correo posterior sobre requisitos de evidencia muestra una dependencia más fina. Nancy Sahu propuso aclarar qué demuestra o no una evidencia operacional y retirar la consideración de auditabilidad si desaparece el único entregable que la realiza. Es una aportación atribuida, no consenso. Demuestra que incluso una palabra de la sección de consideraciones puede quedar huérfana al modificar entregables.

El resumen de IETF 126 del 1 de septiembre dice que la sesión probó consenso para una carta y que el debate continúa en la lista. El Datatracker mantenía el estado BOF, carta (None) y «Not chartered yet». Ese nulo es más importante que cualquier inferencia: ningún texto propuesto había completado la transición.

La autoridad se compone, no se hereda de una sala

El RFC 2418 / BCP 25 sitúa la aprobación final en el IESG, con asesoramiento del IAB, después de la elaboración con el Area Director. El IESG puede aceptar, exigir cambios o rechazar. Solo una aprobación lleva al registro y anuncio del grupo.

El documento también dice que 51 % no constituye rough consensus y trata la verificación por lista de conclusiones presenciales. No hay una guerra entre números y juicio: los números muestran intensidad y distribución; los chairs sopesan argumentos; la lista incluye a quienes no estaban; los órganos competentes autorizan el texto.

La advertencia de Heng Lu sobre convertir asistencia en mandato se aplica aquí con precisión limitada. Participar produce evidencia, experiencia, aviso y objeción. No sustituye por sí solo el acto de la autoridad designada. Tratar así la sala no la rebaja; impide que una parte de su registro sea borrada por la frase «la comunidad aprobó».

Una matriz de conciliación de predicados

La solución no es otra narración libre. Es una tabla pública, breve y versionada.

Cada fila debería comenzar con el identificador y texto exacto de la pregunta, su finalidad institucional y el commit/blob de la carta mostrada. A continuación: hora, método, sí, no, sin opinión, total y carácter no vinculante.

Las columnas interpretativas registrarían términos ambiguos, familias de objeciones, distinción entre corrección y completitud, cláusulas que requieren cambio y condiciones atribuidas al apoyo. No hace falta identificar a nadie. Si existe una tabla cruzada agregada segura, puede aclarar patrones; si no, debe conservarse el nulo.

La mitad final seguiría el traspaso: periodo de confirmación en lista, hilos, síntesis de los chairs, disposición de objeciones, actuación del Area Director, asesoramiento del IAB, decisión del IESG y commit final. Hasta que exista, el campo de carta aprobada debe ser nulo. Las correcciones se añaden y fechaban; no reescriben el pasado.

Aplicada hoy, la matriz diría que el problema y la sede tienen apoyo, el alcance inicial no, los entregables están divididos y el trabajo de texto continúa. Esa combinación no es vergonzosa. Es exactamente la información que un BoF debe producir.

Objeciones serias y límites de la prueba

Una tabla puede fomentar la falsa idea de mayoría. Por eso el razonamiento de los chairs y el estado de autoridad deben pesar visualmente tanto como los recuentos. Una versión fija tampoco debe congelar el texto: debe permitir comparar cada cambio con el objeto anterior.

La privacidad descarta las boletas nominativas. Los patrones agregados bastan y la ausencia de un cruce debe declararse. La carga operativa también importa: la matriz debería proyectarse a partir de actas, commits, lista y Datatracker ya existentes, no convertirse en otro expediente manual.

Este artículo no decide si Agentproto debe formarse, qué tecnología debe normalizar ni dónde encaja cada componente. No prueba error en los recuentos, mala fe, manipulación ni invalidez procesal. No conoce identidades ni cambios de opinión. Las minutas son borrador; los correos y pull requests son propuestas; el estado futuro puede cambiar.

La afirmación comprobable es más pequeña. Una pregunta integral obtuvo apoyo mientras un componente explícito no lo obtuvo, y el texto siguió en discusión. Si se conserva la unión entre predicado, versión y decisión posterior, el proceso puede evolucionar sin atribuir a la sala algo que nunca dijo.

Fuentes

  1. Heng Lu — The Multi-Stakeholder Mirage
  2. IETF 126 — Minutas del BoF Agentproto
  3. IETF 126 — Agenda Agentproto, versión 01
  4. IETF — IETF 126 Highlights
  5. IETF — Birds of a Feather at IETF 126
  6. Carta propuesta de Agentproto en a9405f3…
  7. Datatracker — Estado actual de Agentproto
  8. RFC 5434 — Considerations for Having a Successful BOF Session
  9. RFC 2418 / BCP 25 — IETF Working Group Guidelines and Procedures
  10. Lista Agentproto — Sussing out points of disagreement on the charter
  11. Lista Agentproto — Proposed charter text: evidence requirements
  12. Repositorio de cartas ART — Pull request 77