Resumen

  • AFPUB-2026-GEN-001-DRAFT01 propone que los copresidentes del PDWG lean las diapositivas antes de la reunión y verifiquen que coinciden con el texto de la propuesta.
  • Si detectan una diferencia, los autores deben remitir una versión actualizada a la lista para informar al grupo, incluso cuando esas modificaciones no puedan entrar en consideración.
  • Un recibo público debería unir la versión y la presentación, describir las diferencias, enlazar el aviso y declarar qué texto está admitido para discusión o consenso.

El archivo puede estar completo y la historia, equivocada

Imaginemos un archivo impecable: una página para la propuesta, un PDF con las diapositivas, un vídeo, mensajes de una lista y unas actas. Nada ha desaparecido. Sin embargo, alguien que llegue seis meses después aún puede no saber qué redacción tenía derecho a convertirse en política. La transparencia de las piezas no garantiza la trazabilidad de la relación entre ellas.

AFRINIC mantiene AFPUB-2026-GEN-001-DRAFT01 en su relación de propuestas actuales con estado de discusión. La página del borrador registra el 20 de mayo de 2026 como fecha de presentación y atribuye la autoría a Grégoire EHOUMI, Noah Maina y Adeola A. P. AINA. El documento intenta dotar al Policy Development Working Group de reglas más detalladas sobre copresidentes, reuniones, consenso, impugnaciones y continuidad.

En la sección propuesta 3.3.2.1(f) aparece un control concreto para antes de una Public Policy Meeting. Los copresidentes deben leer las diapositivas, familiarizarse con los detalles y asegurarse de que coinciden con el texto de la propuesta. Si existe una diferencia, se exige presentar una versión actualizada en la lista de correo para notificar al grupo, incluso si esos cambios no serán considerados.

No es una regla vigente. Es parte de un proyecto aún en debate, y describirla como obligación actual distorsionaría precisamente la secuencia que pretende ordenar. Pero como diseño institucional contiene una idea valiosa: la explicación oral y visual puede acompañar al instrumento sin sustituirlo.

Las diapositivas no son sospechosas por ser breves. Su función es seleccionar. Una frase de treinta palabras se convierte en tres viñetas; una excepción termina en la nota del presentador; una responsabilidad compartida se dibuja como una flecha de una sola dirección. A menudo la presentación hace el proyecto más comprensible. El problema surge cuando la versión fácil de recordar se confunde con la versión que la comunidad examinó.

El verbo «notificar» limita el efecto del documento

La última reserva de la cláusula cambia todo el sentido. Si los cambios deben publicarse aun cuando no vayan a considerarse, AFRINIC reconoce dos estados distintos de un texto público. Uno informa sobre la diferencia. El otro ha sido admitido dentro del procedimiento y puede recibir apoyo, objeciones o una determinación de consenso.

Una versión actualizada puede ser una reconstrucción de lo mostrado en la sala. Puede ser la propuesta de los autores para la siguiente etapa. Puede convertirse, después del plazo y el acto procedimental correspondientes, en el nuevo texto operativo. El mismo archivo podría cumplir sucesivamente esas tres funciones, pero no las cumple a la vez ni por el mero hecho de estar en línea.

Un mensaje en la lista acredita recepción y fecha. No acredita por sí solo que el periodo de debate haya empezado de nuevo, que los participantes conocieran la redacción antes de intervenir, ni que los copresidentes la considerasen apta para consenso. Una URL acredita acceso. No acredita autoridad.

Sin una etiqueta de estado, la cronología puede blanquear una versión sin que nadie lo pretenda. El borrador posterior resuelve una ambigüedad y acaba pareciendo la formulación que siempre estuvo sobre la mesa. Las actas citan el título general, no el hash ni el número de versión. El lector posterior atribuye al texto limpio la legitimidad de una conversación anterior.

La solución no exige burocracia abundante. Hace falta un evento legible: recibido solo para notificación; abierto a discusión desde una fecha; admisible para consenso en una reunión concreta; sustituido para el futuro; retirado. La publicación deja de actuar como sustituto silencioso de la admisión.

AFRINIC-37 no fue una prueba de consenso

Las actas de AFRINIC-37 permiten mantener la narración dentro de los hechos. La Public Policy Meeting se celebró el 24 de junio de 2026. El borrador ocupó el tramo de 10:15 a 11:05. Las actas enlazan la presentación, el índice oficial identifica el PDF de 496 KB y el documento de 20 páginas lleva el mismo identificador y los mismos autores.

Las actas no dicen que los autores llevaran una versión materialmente distinta. Dicen algo más importante para delimitar esta investigación: el debate seguía en la lista RPD, los autores no estaban listos para solicitar consenso y pidieron más tiempo para presentar los conceptos y los detalles. Alain Aina describió la intervención como una oportunidad para exponer la idea y recoger comentarios. Al cerrar la jornada, la propuesta fue devuelta a la lista.

Por tanto, no hay base para sostener que una divergencia entre presentación y Draft01 alterase una decisión en AFRINIC-37. Tampoco para invalidar la sesión, imputar mala conducta o decir que alguien votó sobre palabras distintas. El encuentro fue de explicación y retroalimentación, no una decisión de consenso sobre este proyecto.

El anuncio del 25 de mayo en RPD muestra qué aspecto tiene un recibo elemental de entrada. Los copresidentes dicen que han recibido la propuesta, nombran autores e identificador, enlazan el texto y formulan preguntas para la revisión pública. La cadena entre envío y discusión resulta visible. La presentación debería añadir un eslabón equivalente, no abrir una rama documental sin estado.

El proceso de desarrollo de políticas vigente y el Consolidated Policy Manual son el punto de partida que Draft01 pretende modificar. Esa relación también necesita una versión precisa: no todo lo que aparece en la propuesta nueva forma parte ya de la norma actual, y no todo el trasfondo vigente puede inferirse a partir de una diapositiva del proyecto.

Cómo comparar sin convertir cada coma en un incidente

«Coincidir» no significa identidad tipográfica. Dos archivos pueden presentar el mismo contenido con distinta secuencia y extensión. Tampoco basta una comparación automática de palabras. Una diapositiva puede conservar los términos pero cambiar el alcance mediante una flecha, un encabezado o la desaparición de una condición.

Conviene distinguir tres clases. Las diferencias editoriales incluyen formato, abreviaturas o correcciones que no alteran la regla. Las explicativas aportan un ejemplo o una visualización fiel. Las sustantivas cambian actores, facultades, plazos, umbrales, requisitos, excepciones, cargas o recursos. Solo estas últimas necesitan activar con claridad la transición a una versión de propuesta nueva, aunque las otras puedan quedar anotadas.

Un hash criptográfico no decide en qué clase cae la diferencia. Esa responsabilidad humana debe tener nombre. El hash resuelve otra cuestión: identifica sin ambigüedad qué propuesta y qué presentación fueron comparadas. Si mañana cambia el contenido detrás de la misma URL, la constancia original no queda vinculada por error al archivo nuevo.

Los tiempos son parte del control. Deben constar la recepción de las diapositivas, la terminación de la revisión, el aviso de la diferencia y la llegada del texto actualizado a la lista. Un documento que aparece después de la sesión puede conservar lo sucedido, pero no puede gobernar retroactivamente la sesión. Uno que aparece poco antes puede informar sin satisfacer el tiempo necesario para examinarlo.

También interesa una constancia negativa. «No se detectaron diferencias sustantivas entre estos dos hashes» aporta evidencia limitada y útil. La ausencia de nota, en cambio, admite tres relatos: coincidieron, nadie comprobó o alguien corrigió informalmente. El archivo no debe obligar al público a elegir por intuición.

Un recibo para el cruce de frontera

El recibo empieza con el identificador de la propuesta, la versión, la URL canónica, la hora de presentación y la huella del contenido. Añade los mismos datos para el PDF: enlace, hora de recepción o publicación, número de páginas y huella. Nombra al copresidente responsable y cuándo concluyó la revisión.

Si hay discrepancia, un cuadro enlaza cada diferencia relevante con el número de diapositiva y la sección del proyecto. Indica si es editorial, explicativa o sustantiva. Si requiere una actualización, incorpora el enlace al mensaje de la lista, el nuevo archivo, su hash y sus tiempos.

El campo central no describe el contenido, sino su condición: aviso solamente; abierto a discusión; elegible para consenso; sustituido; retirado. Si una versión posterior reemplaza a Draft01 para el próximo ciclo, el recibo conserva que Draft01 siguió siendo la referencia del encuentro anterior. El pasado no se reescribe al ordenar el futuro.

Las actas y cualquier futura declaración de consenso deberían citar la versión elegible exacta. Las correcciones no han de sobrescribir las piezas que vieron los participantes, sino crear entradas enlazadas. De esa manera puede reconstruirse la secuencia sin convertir la web en un museo de copias sin relación.

Este recibo de presentación a texto es una recomendación editorial de Theo March. AFRINIC no lo anuncia con ese nombre, y los materiales públicos no demuestran qué verificaciones internas conserva. La recomendación parte únicamente de la lógica del propio borrador: si comprobar la coincidencia es una responsabilidad y publicar no implica considerar, el cumplimiento necesita una prueba que mantenga separadas ambas cosas.

Fuentes