Resumen

  • La IETF abrió el 28 de agosto de 2026, con plazo hasta el 11 de septiembre, la última llamada sobre una propuesta de Best Current Practice para motores de publicación RPKI y repositorios RRDP y rsync. Todavía no es una BCP aprobada.
  • La notificación RRDP nueva no debe aparecer antes que el snapshot y los deltas a los que apunta. En una granja, el cliente debe seguir una sola vista coherente o todos los nodos deben recibir el contenido antes de que alguno publique la notificación.
  • Ver un serial nuevo prueba la respuesta de un extremo. No prueba disponibilidad en todos los caminos, validez criptográfica, aceptación por un relying party, aplicación en el router ni cambio de tráfico.

Un relying party descarga la notificación desde un balanceador. El serial ha aumentado y existe un enlace a un delta. La solicitud siguiente cae en otro servidor, donde el delta aún no llegó. Respuesta: 404. Una conexión persistente lleva después al cliente a un nodo retirado que todavía muestra la sesión anterior.

La contradicción no está dentro del objeto firmado. Está entre el anuncio y la capacidad del servicio para cumplirlo.

La última llamada del 28 de agosto propone elevar estas prácticas a guía común. El borrador vigente exige que la notificación nueva espere a sus snapshots y deltas. Los comentarios siguen abiertos hasta el 11 de septiembre; el texto no es aún un resultado de consenso ni demuestra fallos en una organización concreta.

Lo visible es el servicio, no el disco de origen

RFC 8182 separa la notificación de los archivos que permiten actualizar la copia local. Esa separación hace eficiente la sincronización, pero abre una carrera. Copiar primero el índice y después el contenido invierte la relación entre prueba y realidad.

Con varios backends, la coherencia puede obtenerse manteniendo solicitudes sucesivas en el mismo nodo o propagando los datos a todos antes de abrir la notificación en cualquiera. El primer diseño conserva una cronología local. El segundo crea un punto de exposición global. Ambos fracasan si el cliente puede combinar un índice nuevo con un almacén viejo.

La superficie incluye CDN y cachés. Un 404 guardado antes de que exista una ruta aleatoria puede seguir negando un objeto ya creado. Una notificación retenida durante demasiado tiempo puede ocultar una actualización. HTTP keepalive puede mantener viva la conexión hacia un servidor fuera del pool. Ningún inventario interno observa por sí solo todas esas rutas.

El serial tampoco resuelve el conflicto. RFC 8182 no fija cómo debe reaccionar el RP ante una regresión. Algunos pueden descargar el snapshot completo. Esa conducta recupera estado, quizá, pero no convierte el número mayor en prueba de actualidad ni el menor en prueba de falsedad.

El intento de recuperación puede multiplicar el incidente

Cuando falla un delta, el RP suele pedir el snapshot, que es más grande. Si también falla, recurre a rsync. En el siguiente ciclo RRDP puede volver a necesitar el snapshot. Una carrera de publicación crea así una escalera de consumo: delta, snapshot, rsync.

Por eso el borrador pide medir capacidad, memoria, E/S y fallbacks inesperados mediante un RP canario externo. El dato útil no es solo el volumen. Hay que unir cada transferencia con sesión, serial, backend, URI, caché y respuesta. Solo entonces se distingue crecimiento legítimo de trabajo repetido por una vista partida.

Mantener snapshots y deltas antiguos durante dos horas protege a clientes lentos y solicitudes que empezaron antes del cambio. No autoriza publicar el siguiente índice antes de sus archivos. Del mismo modo, agrupar cambios y limitar la frecuencia de deltas reduce coste, pero no reduce la obligación de ordenar su exposición.

Una publicación no es una sola acción

La CA genera material firmado y lo entrega al motor mediante RFC 8181. Consultar list antes del cambio permite comparar estados. Reunir varias PDU en una consulta multi-elemento reduce la posibilidad de aplicar a medias una operación que debía ser conjunta.

Después aparecen recibos diferentes. El registro de la CA describe intención. La respuesta del motor describe aceptación. La notificación describe lo que anunció un endpoint. La descarga describe bytes. La validación del RP evalúa certificados, manifiestos, CRL y objetos bajo una ancla. La alimentación del router y la política local son otros pasos. El paquete observado es otro más.

El éxito de un nivel no se presta al siguiente. Un snapshot puede descargarse y fallar la validación. Un ROA válido puede no corresponder a un anuncio BGP presente. Una salida validada puede llegar al router sin cambiar su selección. Son las capas de realidad de Heng Lu: índice, objeto, decisión y efecto deben conservar su propia procedencia.

rsync ofrece un espejo útil. Si el árbol cambia mientras el cliente lo lee, puede reunir archivos nuevos y antiguos en una lectura fantasma. El borrador propone construir un directorio completo y mover un enlace simbólico al final. La técnica es distinta, pero la idea coincide con notification-last: terminar la vista antes de exponerla.

Reiniciar puede ser más honesto que seguir contando

Un serial ascendente ordena eventos dentro de una sesión; no es un reloj ni una garantía de exactitud. Tras restaurar una copia antigua, fingir continuidad con el número siguiente oculta pérdida de estado. La propuesta exige iniciar una sesión RRDP nueva si hubo regresión y avisar a las CA dependientes para que resincronicen.

Ese reset no recupera solo los ROA omitidos, los publishers recién registrados o un manifiesto próximo a caducar. Declara que terminó la continuidad anterior y abre un proceso verificable de reconstrucción.

La primacía del código en ejecución exige pruebas desde fuera, atravesando balanceadores y cachés. El control práctico se ve en quién puede cerrar la notificación, purgar un 404, drenar conexiones, conservar la vista anterior y ordenar el reset.

Notification-last no garantiza que una ruta sea correcta. Garantiza algo anterior y verificable: el servicio no anuncia material que todavía no puede entregar.

Sources