Resumen

  • LAC-2026-6 entró en discusión el 25 de septiembre de 2026 y permanece en esa etapa. Su primera versión cambia en distintos pasajes del PDP las referencias genéricas a una propuesta por referencias a una versión concreta; no es una política adoptada.
  • El autor dice que pretende ajustar las palabras a la práctica existente. También reconoce que el motivo técnico exacto por el que el sistema no permitiría reiniciar una discusión sin crear otra versión no ha sido confirmado por el personal de LACNIC. Su explicación no equivale a una constatación institucional.
  • El código común ordena una familia de textos. Para comprobar la legitimidad del resultado haría falta enlazar cada texto publicado con el debate, la presentación en el foro, la evaluación del consenso, el último llamado y la decisión del Directorio que efectivamente le correspondan.

El expediente conserva el código; las palabras no siempre

La ficha oficial muestra una versión inicial de la propuesta. Identifica a Jordi Palet Martinez como autor y la mantiene «En discusión». Consigna una última modificación del 22 de septiembre y el comienzo de la discusión el día 25. Esas fechas no son intercambiables. Que un archivo tenga una fecha de modificación no demuestra que la comunidad pudiera leerlo desde entonces; que el sistema le asigne un código no demuestra que haya sido anunciado en la lista pública.

El texto propuesto vuelve sobre esa separación en una docena de puntos. En vez de hablar indistintamente de «la propuesta», se refiere a la versión que se envía por formulario, se publica en la lista y se anuncia para el foro. Los moderadores considerarían la discusión de una versión al evaluar el consenso; el foro debatiría versiones; el Directorio aceptaría o rechazaría una versión. No se trata de una preferencia estilística inocua si el texto cambia. Cada verbo corresponde a una prueba distinta.

Publicar es ofrecer una oportunidad de conocer y objetar; debatir no es dar consenso; determinar consenso no es ratificar; ratificar no demuestra por sí sola que el texto ya esté implementado.

La mejor defensa del borrador está en su propia justificación. Según el autor, el PDP ha funcionado en la práctica con versiones identificables, pero todavía conserva frases que permiten leer todo el expediente como un texto único. Corregir esa ambigüedad puede facilitar el trabajo de autores y moderadores y evitar impugnaciones nacidas de una lectura equivocada. No hay motivo para presentar cada precisión del procedimiento como un intento de ampliar competencias.

Precisamente porque una precisión puede ser útil, conviene probarla en el caso difícil. Un operador afectado por una futura regla de transferencia o asignación no necesita saber solo el código de la propuesta; necesita saber si el requisito que deberá cumplir aparecía en la versión debatida. Si el requisito se añadió después, hace falta explicar qué oportunidad tuvieron los participantes de examinarlo y qué objeciones quedaron resueltas. Un identificador persistente puede ocultar esa transición si se usa como sustituto del historial de textos.

Los plazos tienen objeto, no solo duración

El PDP vigente establece un mínimo de ocho semanas de discusión y, en el recorrido ordinario, una presentación en el Foro Público de Políticas antes de la evaluación del consenso. Tras ese resultado prevé un último llamado de cuatro semanas. Los plazos no son una ceremonia que se cumple una vez para toda una familia de versiones; permiten que personas concretas revisen palabras concretas y que los moderadores sepan a cuáles responden las objeciones.

El borrador de LAC-2026-6 aclara bifurcaciones que pueden confundirse. Si una versión no alcanza consenso, los autores podrían seguir con una nueva o retirar la propuesta. Si el debate provoca una revisión, los moderadores y autores tendrían que distinguir entre un cambio que reinicia la discusión y una modificación menor admisible durante el último llamado. El antecedente LAC-2020-6 ayuda a ubicar otro caso: una corrección editorial durante el último llamado puede requerir nueva versión y reinicio de esa etapa. Esos caminos no autorizan a reemplazar libremente el texto después del consenso, pero tampoco exigen volver siempre al comienzo por cada ajuste.

Supongamos que la versión 1 se anuncia, se discute y se presenta al foro. Luego aparece una versión 2 que cambia una condición de fondo. No bastaría llamar al segundo archivo «la misma propuesta» para trasladarle automáticamente el trabajo hecho sobre el primero. Habría que mostrar qué discusión o presentación corresponde a las palabras nuevas. Si una versión 3 corrige una expresión sin modificar el alcance, el registro debería justificar el tratamiento menor y señalar qué etapa se repitió. No afirmamos que ese encadenamiento haya ocurrido con LAC-2026-6; es una prueba de lectura para las reglas que propone.

El autor añade que, por razones del sistema de políticas o de sus componentes, no parece posible reiniciar el plazo de discusión sin abrir otra versión, aunque el texto no cambie. En el mismo párrafo advierte que el detalle técnico no ha sido confirmado por el personal. Ese matiz evita convertir una hipótesis operativa en una conclusión de LACNIC. Si más adelante se confirma, explicaría una restricción de la herramienta; no resolvería automáticamente cuándo una versión revisada debe regresar a la lista o al foro. Una plataforma puede exigir un archivo nuevo. La legitimidad de una decisión requiere explicar qué hizo la comunidad con él.

Hay otra corrección pequeña con consecuencias para la trazabilidad. La redacción actual citada en la propuesta sitúa la asignación del código después de una revisión. La alternativa dice que el sistema lo otorga automáticamente, antes de revisar, publicar y anunciar. Así queda claro que el código acredita la existencia de un registro de trabajo, no su exposición pública ni su aptitud para pasar a una fase decisoria. El momento de creación es un dato útil, pero no puede reemplazar el momento en que la comunidad recibió el texto.

Mostrar la herencia entre versiones

Una política viva debe permitir que un autor corrija errores y atienda críticas. El problema no es que exista una versión 2. El problema aparece cuando se da por supuesto que todas las observaciones hechas a la versión 1 se transfieren intactas, o que ninguna puede transferirse. Ambas respuestas son demasiado simples. Algunas objeciones se resuelven con el cambio; otras sobreviven; una exigencia nueva puede abrir una cuestión que nadie tuvo ocasión de comentar.

Una matriz pública y acotada podría unir el código de la familia con el archivo preciso de cada versión, sus fechas de publicación, la sesión del foro en que se presentó, las objeciones sustanciales y su tratamiento, el tipo de cambio, la determinación de los moderadores, el intervalo del último llamado y la resolución del Directorio. Conservaría las versiones sustituidas sin confundirlas con la vigente. No requiere exponer planes privados de operadores ni convertir el tamaño de una reunión en un mandato sobre quienes no asistieron.

Es una propuesta editorial para comprobar la continuidad del procedimiento, no un producto prometido por LACNIC.

El proyecto sigue abierto a discusión. Nada en las fuentes revisadas demuestra que ya obtuvo consenso, que el Directorio lo ratificó, que una decisión anterior fue inválida o que un titular sufrió un daño. El autor puede tener razón en que el proceso no cambia. Esa afirmación resultará más convincente cuando pueda recorrerse, paso por paso, el camino de la versión que recibió cada acto. Si la comunidad debatió un texto y otro terminó convertido en regla, el número compartido no explicará el salto. La legitimidad del PDP reside en poder verlo y justificarlo.

Fuentes