Resumen

  • Un participante no pudo abrir dos enlaces sin extensión a las actas de IETF 84, pero una copia por rsync aún contenía archivos de las sesiones AVTCORE y MMUSIC.
  • El personal de IETF amplió las extensiones que el servidor prueba para nombres antiguos, incluyendo PDF y HTM; una comprobación limitada del 6 de septiembre obtuvo respuesta satisfactoria de ambas rutas.
  • Encontrar un archivo en una copia, recibir una respuesta pública, identificar el objeto correcto y verificar sus bytes son afirmaciones diferentes y requieren pruebas diferentes.
  • Un manifiesto público puede unir el identificador estable de cada acta con su ruta concreta, formato, tamaño, huella, versión, estado de corrección y último control de enlace.
  • Ese registro técnico no valida la exactitud de las actas ni sustituye el proceso de IETF; evita que la flexibilidad útil del servidor oculte decisiones sobre identidad y reemplazo.

Dos superficies contaban historias distintas

El 29 de agosto, Jörg Ott siguió enlaces desde las actas de IETF 84 y no obtuvo las minutas de AVTCORE ni de MMUSIC. Otros grupos elegidos al azar sí parecían responder. Su mensaje inicial propuso comprobar enlaces de forma automática y consignó además un error 1015 de Cloudflare durante una investigación hecha desde una conexión móvil remota deficiente.

La experiencia demostraba que el camino público fallaba. No demostraba que los documentos hubieran sido borrados. Carsten Bormann consultó una superficie diferente: en una copia de las actas obtenida por rsync encontró archivos para ambos grupos dentro de un corpus local que cifró en 68 GB. Es una fotografía de una copia, no una garantía sobre toda la colección ni sobre la historia de cada byte. Para esos dos casos bastaba, sin embargo, para separar conservación de navegabilidad.

Ott relacionó después el comportamiento con variantes de extensión PDF y HTM. La explicación operativa llegó el 2 de septiembre. Las viejas páginas enlazaban nombres de actas sin extensión, y el servidor probaba un conjunto limitado de terminaciones. El personal de IETF amplió esa lista para cubrir .pdf, .htm y otras variantes realmente presentes en los datos. Indicó que los ejemplos denunciados y varios más deberían volver a abrirse.

Sobre la limitación, la respuesta señaló que el umbral era bastante alto para que la navegación ordinaria no lo alcanzara con facilidad y pidió conservar el Ray ID si volvía a ocurrir. La observación acota el diagnóstico: no borra el 1015 visto por Ott y tampoco confirma una indisponibilidad general. Una regla de resolución y un control de tráfico pertenecen a capas distintas.

El éxito del enlace no basta para citar el archivo

El 6 de septiembre, una prueba de baja frecuencia recibió HTTP 200 de las dos rutas sin extensión. La de AVTCORE sirvió un PDF de 242.140 bytes con una fecha Last-Modified de 2012. Su SHA-256 observado fue 937e224285a7eae6bf1cbeb9106e5eb0bf4df7b34bf02a10587f6da9ef4e49e1. La de MMUSIC devolvió HTML, también con fecha de 2012, y SHA-256 88a6f5fd2d5459bfa1c66dc7d24b54e441a4e05507e009adf99409486c19a214.

Las huellas describen lo observado ese día. No convierten esos objetos en versiones canónicas eternas. Rutas directas acabadas en avtcore.html y mmusic.html también respondían, pero entregaban bytes distintos y páginas de resumen del grupo con otra fecha, no las actas. Añadir .html porque parece natural habría producido un documento real y a la vez equivocado.

El índice de IETF 84 está hecho para que una persona recorra una reunión histórica. Probar extensiones conserva esa experiencia frente a convenciones antiguas e irregulares. Pero cada resolución reúne bajo una sola pantalla cuatro estados:

  • Existencia: hay algún objeto asociado a la sesión en un almacenamiento o espejo.
  • Acceso: una petición pública recupera algo en este momento.
  • Identidad: lo recuperado es el acta declarada, no una ficha del grupo ni un candidato accidental.
  • Integridad: sus bytes coinciden con la versión declarada para una fecha concreta.

El arreglo mejoró el acceso. La copia de Bormann aportó evidencia de existencia. El tipo, tamaño y hash medidos permiten examinar identidad e integridad. Ninguna de esas señales certifica que las actas sean completas, exactas o aprobadas más allá del proceso que las produjo.

La obligación de documentar no termina al subir el fichero

El RFC 2418 exige informar de cada sesión de un grupo de trabajo, responsabiliza al presidente de asegurar que haya actas y considera los archivos públicos de correo parte de la memoria del trabajo. También pide resumir y archivar las decisiones importantes y su historia. La accesibilidad de esos materiales afecta, por tanto, a la posibilidad práctica de reconstruir el proceso.

La guía actual para presidentes declara obligatoria la entrega de las actas, enumera formatos aceptados y distingue el plazo de presentación del de correcciones. Un recordatorio del Secretariado sobre IETF 126 enumeró sesiones aún sin actas antes del cierre del 14 de agosto y señaló un plazo posterior para corregirlas. No conocemos por ese mensaje el resultado final. Sí vemos una secuencia: aún no entregado, recibido, publicado, corregido, sustituido y accesible son estados independientes.

Una ficha de integridad para cada pieza

El archivo debería publicar un manifiesto legible por máquinas. Cada entrada identificaría reunión, grupo o sesión, clase de material e identificador lógico estable. A esa identidad añadiría la ruta exacta del objeto, tipo MIME, número de bytes y huella criptográfica.

La historia importaría tanto como el estado actual: fecha de recepción y publicación, número de versión, condición vigente, corregida o sustituida, enlace al reemplazo, último control público satisfactorio y cambio de resolución o migración que modificó el acceso. La procedencia puede expresarse mediante un rol cuando sea seguro, sin exponer correspondencia privada, datos personales de red ni detalles de protección.

Una corrección generaría una versión nueva y una relación de sucesión inmutable. El enlace cómodo para lectores podría apuntar a lo vigente; la identidad exacta de las versiones anteriores seguiría disponible para quien necesite reproducir una cita.

Este manifiesto no reescribe el acta, no decide si refleja bien una reunión y no otorga legitimidad institucional. Hace comprobables afirmaciones operativas. Un auditor podría distinguir ausencia del objeto, enlace no resuelto, candidato equivocado, formato inesperado, restricción de acceso, discrepancia de checksum, sustitución o causa desconocida.

Las comprobaciones deben ser pausadas y públicas, precisamente para no crear carga ni confundir limitación con pérdida. Un resultado verde significaría algo estrecho: el objeto declarado se recuperó a una hora registrada y coincidió en formato, tamaño y hash. Esa modestia es una fortaleza.

Fuentes

  1. Aviso inicial de Jörg Ott
  2. Carsten Bormann sobre la copia por rsync
  3. Seguimiento sobre extensiones PDF y HTM
  4. Explicación y reparación del personal de IETF
  5. Recordatorio sobre las actas de IETF 126
  6. Guía de materiales de reunión
  7. RFC 2418
  8. Actas generales de IETF 84
  9. Ruta de las actas AVTCORE
  10. Ruta de las actas MMUSIC
  11. Lu Heng sobre la primacía del código en funcionamiento