Resumen

  • draft-sparysh-pala-audit-00 se anunció el 3 de septiembre de 2026. Datatracker lo registra como Internet-Draft individual, sin respaldo ni posición formal del IETF, sin flujo RFC y sin Area Director responsable.
  • El texto presenta PALA-1 como un formato de registro de auditoría ya existente y congelado en la versión 1.0. El proyecto Palimpsests tomó esa decisión el 9 de agosto, antes de publicarlo en el IETF.
  • El draft declara cinco implementaciones, pero separa la referencia de los autores de cuatro implementaciones basadas en el texto y contrastadas con vectores proporcionados por el proyecto.
  • Una ejecución posterior sobre la etiqueta v1.0 halló ambigüedades y una carencia en el emparejamiento de spans. El draft dice que la especificación cambió después del congelamiento, sin presentar un cambio de bytes o vectores.
  • Un recibo mínimo debería unir objeto congelado, autoridad del proyecto, estado institucional, issue revisada, clase de cambio, decisión y consecuencia para lectores y escritores existentes.

Congelar un formato no congela un proceso

El anuncio del IETF apareció el 3 de septiembre. La ficha de Datatracker identifica el documento como una contribución individual activa. Cualquiera puede presentar un I-D; el propio sitio advierte que no tiene respaldo del IETF ni posición formal dentro del proceso de estándares. Al cierre no figuraban un RFC stream ni un Responsible AD, y el estado ante el IESG era “I-D Exists”.

El encabezado del documento apunta a Informational, mientras la ficha resumida no mostraba intended RFC status. Ninguno de los dos campos equivale a aprobación. El RFC Editor explica que un Internet-Draft es un documento de trabajo y que su publicación no significa que haya sido aprobado o vaya a convertirse en RFC. Una futura adopción por un Working Group tampoco sería el final: seguirían revisión, debate y posibles revisiones.

Palimpsests había detenido otro reloj. El commit 50b47edb1ed8, del 9 de agosto, cambió el estado de la especificación de Draft a “Frozen — v1.0”. Definió el alcance como wire format: una modificación del wire exige otro format_version, mientras los perfiles pueden crecer de forma aditiva en sus espacios. El I-D de septiembre dice con claridad que presenta un formato existente y no pretende revisarlo.

No hay nada ilegítimo en ese orden. Un proyecto puede proteger una base instalada antes de pedir comentarios en un foro de estándares. La disciplina consiste en conservar dos estados. El congelamiento compromete al proyecto con sus implementadores; no demuestra consenso del IETF. La falta de adopción institucional tampoco borra la utilidad o la promesa local del formato.

La evidencia de implementación merece sus apellidos

La sección Implementation Status informa de cinco implementaciones: la referencia de los autores, una de un co-mantenedor bajo un límite de contaminación declarado y tres construidas por personas externas al proyecto en el momento de las pruebas. Una de ellas pasó a ser mantenedor más tarde.

El draft no las presenta como cinco votos idénticos. Las cuatro no referenciales se escribieron a partir del texto, sin mirar una implementación previa, y reprodujeron resultados de vectores suministrados por el proyecto. El propio texto puntualiza que no son vectores independientes. La diferencia importa: reproducir una especificación, interoperar con otro producto y operar en producción son clases de evidencia distintas.

Esta trazabilidad da contenido a la primacía del código en ejecución. El código no gana autoridad política; fuerza a que una ambigüedad produzca una diferencia observable. Un hash distinto, una clasificación opuesta de GENESIS o un Merkle root no reproducible convierten una discusión verbal en un caso verificable. El registro de verificación muestra además que los defectos se usan para corregir, no para adornar una cifra.

El RFC 7942 propone justamente ese uso acotado. La sección puede describir madurez, cobertura, compatibilidad de versiones, licencias y experiencia. Los grupos de trabajo deciden qué peso darle. Enumerar código no implica respaldo del IETF; la información envejece y normalmente se retira antes de publicar un RFC.

El hallazgo posterior al congelamiento

La quinta ejecución expone el problema central. Según el draft, un implementador externo en ese momento trabajó sobre la etiqueta pala1-v1.0, superó las pruebas publicadas, añadió casos adversos y registró ocho ambigüedades y una falta de emparejamiento de spans.

La especificación decía que un crash debía dejar visible un span sin cerrar, pero no había definido una comprobación que produjera ese aviso de forma uniforme. La solución no trató un trail incompleto como falsificado. Lo convirtió en un advisory finding. El I-D denomina a esta ejecución la que cambió la especificación después del congelamiento y dice que publicó tanto el razonamiento como el resultado.

Eso no prueba una mutación del wire. Prueba que la palabra “congelado” necesita un objeto. Aclarar una frase, agregar un diagnóstico, modificar una regla semántica, revisar un perfil o mover un offset son actos diferentes. Pueden dejar iguales los vectores y, aun así, cambiar lo que un operador debe mostrar. O pueden conservar la intención y romper todos los parsers antiguos.

Una bitácora evita dos malas conclusiones: que cualquier edición posterior invalida v1.0, o que bytes idénticos implican una interpretación idéntica. Para un operador importan tres datos más concretos: qué cambió, quién lo clasificó y qué debe hacer su implementación.

El núcleo congelado puede ser pequeño

La especificación de PALA-1 describe un header fijo de 156 bytes, extensiones TLV, tipos de registros y una cadena hash. La compatibilidad hacia adelante exige seguir verificando registros con versión, tipo o TLV desconocidos, marcarlos como no interpretables y no rechazar por ello toda la cadena.

Algunos offsets forman una columna vertebral permanente: magic, versión, longitud del header, tipo, secuencia, boot ID, hash previo, longitud y digest del body. Gracias a ella, un lector antiguo puede saltar un registro futuro y mantener la verificación. Congelar esa mecánica no significa congelar para siempre toda semántica.

Los profiles definen el contenido de EVENT, cantidades agregadas, fuentes de hojas Merkle y vocabulario de roles. La documentación del despliegue dice qué profile sigue una cadena. Este reparto conserva un mínimo común y deja decisiones futuras cerca de los implementadores, en vez de inflar la capa central.

PALA-1 también separa la fuerza probatoria: consistencia interna, integridad contra un anchor externo y existencia ante un witness externo. La cadena no prueba que el registrador dijera la verdad. Es una limitación bien gobernada, porque impide que un mecanismo técnico reclame una autoridad que no tiene.

Un recibo que una promesa y revisión

El recibo del congelamiento debería conservar el commit, la etiqueta, los hashes de los vectores, el actor que decidió, la fecha, el test de salida y los hallazgos abiertos. También debe nombrar el alcance: bytes, esqueleto de parsing, semántica normativa, profile, guía de implementación o prueba.

Cada issue posterior necesita identificador estable, revisión exacta, sección afectada y clase de cambio: editorial, interpretativa, semántica, profile, extensión aditiva, reparación de vector o incompatibilidad de wire. La decisión identifica el rol del proyecto o del IETF que la tomó, la razón y el destino: sin cambio, aclaración, aviso, versión de profile, extensión, nota compatible, nueva versión o aplazamiento.

El efecto operativo no puede quedar implícito. ¿El lector v1 conserva los límites? ¿Verifica la cadena? ¿El writer v1 sigue conforme? ¿Hay que cambiar el profile? Las correcciones futuras se añaden, no borran el historial.

En otra columna van los estados institucionales: I-D individual, debate en un foro identificado, adopción WG, consenso, aprobación IESG y RFC. Un mantenedor habla por su release, no por el IETF. Un grupo revisa el documento, no se apropia automáticamente de sus usuarios. Un operador puede adoptar v1 voluntariamente sin llamarlo estándar.

El RFC 2026 coloca implementación y pruebas junto con excelencia técnica, claridad, apertura, equidad y revisión repetida. La experiencia práctica es indispensable, pero no una vía rápida para evitar objeciones.

El marco de Heng Lu añade una restricción útil: congelar sólo la capa común imprescindible, someter las palabras a la realidad del código y mantener locales las decisiones que no rompen la interoperabilidad. PALA-1 puede conservar v1 sin cambios, recibir aclaraciones o necesitar otro wire en el futuro. No lo sabemos. Sí sabemos que frozen no puede representar a la vez identidad, compatibilidad, autoría y autoridad institucional.

Fuentes

  1. Anuncio del Internet-Draft
  2. Datatracker: PALA-1
  3. Datatracker: historial
  4. Archivo IETF: versión 00
  5. Especificación PALA-1
  6. Commit de congelamiento 50b47edb1ed8
  7. Registro de verificación independiente
  8. Vectores de prueba
  9. Archivo de ejecuciones independientes
  10. RFC 7942: Improving Awareness of Running Code
  11. RFC 2026: The Internet Standards Process
  12. RFC Editor: How RFCs Are Created
  13. Heng Lu: Running-Code Primacy
  14. Heng Lu: Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption