Resumen

  • El registro vigente de resoluciones de AFRINIC identifica la ratificación de AFPUB-2018-V6-004-DRAFT01 como Resolución 201808.448, mientras que las actas aprobadas de la misma reunión imprimen 201808.449 para ese asunto. El registro reserva 201808.449 para otro acto, de modo que la contradicción debe conservarse, no corregirse por intuición.
  • La Junta ratificó la propuesta el 8 de agosto de 2018, pero los Action Items 201808.22-.23 separaron la notificación y la implementación del acto corporativo. El anuncio posterior del presidente también describió la implementación como trabajo futuro.
  • CPM v1.3 incorporó el 1 de noviembre las secciones 6.8–6.8.4, con una vía IPv6 PI para sitios finales sin depender de un antecedente IPv4 PI, una estructura de asignación y una rectificación única. A finales de noviembre, AFRINIC-29 todavía informó que faltaba automatizar comprobaciones sobre enrutamiento y no desagregación.
  • El beneficio operativo era real, pero acotado. AFRINIC podía autenticar al solicitante, evitar asignaciones duplicadas, registrar una necesidad y administrar su servicio. Ningún número de resolución, declaración de consenso o cláusula del manual le otorgó soberanía, poder regulador, policial, punitivo, confiscatorio ni jurisdicción pública.

Análisis: el error de buscar una fecha mágica

Un mismo acto corporativo aparece bajo dos números distintos en la documentación pública de AFRINIC. El registro actual de decisiones de la Junta denomina Resolución 201808.448 a la ratificación de la actualización IPv6 PI. Las actas aprobadas de la reunión del 7 y 8 de agosto imprimen, para el mismo punto 9.3 y la misma propuesta AFPUB-2018-V6-004-DRAFT01, la Resolución 201808.449. El problema no termina en una cifra intercambiada: el registro asigna 201808.449 a un acto diferente, la autorización para que el director ejecutivo firmara el memorando con el anfitrión de AFRINIC-29.

Después, la Resolución 201809.450 aprobó las actas de agosto «con enmiendas», pero el expediente examinado no publica el texto de esas modificaciones. Ninguna fuente primaria revisada respalda una Resolución 201809.448.

Para un operador, elegir uno de esos rótulos y tratarlo como fecha mágica de eficacia sería una forma de borrar el problema, no de resolverlo. El número del registro acredita cómo AFRINIC presenta hoy el acto; el número de las actas acredita lo que el documento aprobado imprimió para el punto debatido. La aprobación posterior de las actas no revela si la enmienda corrigió esa numeración, otra frase o un aspecto sin relación.

Y aun si existiera un número indiscutible, seguiría faltando distinguir entre la ratificación del 8 de agosto, la incorporación del texto al CPM v1.3 el 1 de noviembre y la capacidad operativa que a finales de noviembre seguía necesitando automatización. La fecha útil depende de la pregunta: cuándo decidió la Junta, cuándo cambió el manual o cuándo pudo ejecutarse cada comprobación. Ningún artefacto contesta por sí solo las tres.

Esa precisión permite reconocer el acto sin inflarlo. El 8 de agosto la Junta consideró el IPv6 PI Update bajo el punto 9.3 de su agenda en Mauricio y ratificó la propuesta. Las fuentes conservan el identificador exacto, AFPUB-2018-V6-004-DRAFT01, y coinciden en la existencia de la ratificación. La divergencia se refiere al número atribuido a la resolución, no a la identidad de la propuesta ni al hecho básico de la decisión corporativa. Por eso sería tan incorrecto negar que hubo un acto como fingir que el expediente ofrece una etiqueta limpia.

También importa lo que las actas no dicen. Registran que SO propuso el asunto y SI lo secundó, pero no imprimen después del punto IPv6 PI una fórmula de aprobación unánime ni un recuento de votos. En los dos asuntos de política inmediatamente anteriores sí aparecen declaraciones expresas de aprobación unánime. Esa diferencia textual impide trasladar la fórmula de unos puntos a otro. La ratificación está documentada; la unanimidad de este punto no lo está. La prudencia no rebaja la fuerza del hecho probado. Se limita a impedir que una práctica narrativa ocupe el lugar del registro.

Cuatro estados, no una sola ceremonia

El trayecto empezó antes de la reunión de la Junta. El 28 de marzo de 2018 se publicó el Draft 1 de la propuesta, dirigido al artículo 6.8 del Manual Consolidado de Políticas. Su objetivo relevante para este análisis era eliminar la dependencia de un pasado IPv4 PI para abrir la vía a determinados usuarios finales de IPv6 y prever una posibilidad de rectificar el tamaño inicial. En AFRINIC-28, el 9 de mayo, el debate dejó constancia de una objeción y de aclaraciones: el material del HD-ratio se mantenía y el personal no recibía una instrucción general para vigilar el enrutamiento. Los copresidentes decidieron llevar el texto a Last Call.

Publicación, discusión y Last Call formaban parte del procedimiento privado de elaboración. Ninguna de esas etapas era ya la decisión de la Junta. La remisión de los copresidentes comunicaba que el proceso había llegado a un resultado presentado como consenso; no convertía por sí misma el borrador en una función disponible. El 8 de agosto llegó el segundo estado: la adopción corporativa. La oración operativa publicada para el asunto fue acotada, una ratificación apoyada en considerandos sobre el procedimiento, el consenso y la recomendación de los copresidentes.

No fue una ley y tampoco una declaración técnica de que todas las tareas de implementación estuvieran terminadas.

Las propias actas separaron enseguida el voto de sus consecuencias. El Action Item 201808.22 encargó al presidente informar de la ratificación a los copresidentes del grupo de trabajo. El Action Item 201808.23 encargó al personal implementar las políticas ratificadas. Si la ratificación hubiera sido autoejecutable, ese segundo encargo carecería de sentido. El anuncio del presidente del 21 de agosto sostuvo la misma secuencia: confirmó que la Junta había ratificado V6-004 y dijo que el personal procedería a la implementación y comunicaría a la comunidad cuando estuviese implementada.

El futuro verbal es información operacional, no una fórmula decorativa.

El tercer estado fue documental. La historia de revisiones de CPM v1.3 lleva fecha de 1 de noviembre de 2018 e identifica cambios en 6.8, 6.8.1, 6.8.2 y 6.8.3, además de la nueva 6.8.4. Desde ese día existe una evidencia versionada de que la actualización fue incorporada al manual. Es un hito importante: el solicitante y el personal podían señalar una versión, unas secciones y unas condiciones legibles, en lugar de reconstruir el resultado a partir de un borrador y una resolución. Sin embargo, la presencia de palabras en un manual no demuestra que los sistemas, los flujos internos y las comprobaciones necesarias estuvieran listos.

El cuarto estado aparece en el registro de AFRINIC-29, celebrado del 26 al 30 de noviembre. Allí, la actualización IPv6 PI figuró todavía «en implementación», pendiente de automatizar requisitos ligados a comprobar que el espacio PI asignado se anunciaba y no se desagregaba. El documento no explica qué cláusulas podían gestionarse manualmente entre el 1 de noviembre y esa reunión, ni fija la fecha posterior en que terminó la automatización. Por ello, tampoco sería exacto convertir la revisión del CPM en prueba de una puesta en servicio completa. El manual ya contenía la regla; el soporte operativo declarado aún no estaba cerrado.

Hay así cuatro respuestas posibles a una pregunta aparentemente sencilla. La propuesta existía desde marzo y alcanzó Last Call tras la reunión de mayo. La organización la adoptó corporativamente el 8 de agosto. El manual versionado la incorporó el 1 de noviembre. A finales de ese mes, parte de la implementación seguía abierta. Una cronología responsable conserva los cuatro estados porque cada uno controla un riesgo distinto: usar un texto aún no adoptado, atribuir efectos automáticos a una votación, aplicar una cláusula ausente de la versión vigente o prometer una capacidad que las herramientas todavía no sostienen.

Lo que cambió para el usuario final

El valor benigno de la actualización se entiende mejor desde la continuidad de red. Una organización que utiliza espacio dependiente de un proveedor puede afrontar una renumeración amplia al cambiar de conectividad. Direcciones en equipos, reglas de filtrado, registros DNS, certificados, listas de acceso, herramientas de observación, documentación y soporte al cliente pueden quedar ligados al plan anterior.

El espacio independiente del proveedor no elimina todos los problemas de enrutamiento ni garantiza que cualquier contraparte acepte cualquier anuncio, pero puede reducir la dependencia de un único upstream y dar continuidad al plan de direccionamiento.

CPM v1.3 describió la elegibilidad para sitios finales que servían a una sola organización administrativa. El solicitante no debía ser LIR, debía hacerse miembro usuario final de AFRINIC, justificar la necesidad, planear el uso dentro de doce meses y no desagregar el espacio PI anunciado. La estructura contemplaba una asignación inicial /48 o un prefijo más corto cuando estuviera justificado. Las asignaciones posteriores debían documentarse, con preferencia por una extensión contigua cuando fuese posible. Esas condiciones convertían una aspiración general en una solicitud que el registro podía evaluar y registrar.

La nueva sección 6.8.4 abordó un problema práctico adicional: un plan inicial puede resultar equivocado. Permitió una rectificación única basada en un plan actualizado. Según las circunstancias, podía existir una extensión dentro del mismo bloque; otras alternativas incluían renumerar a un bloque nuevo en seis meses o conservar un bloque complementario. No hace falta suponer que cada solicitante utilizó esas opciones para comprender el mecanismo. Una vía de corrección reduce el riesgo de que una estimación inicial imperfecta se transforme de manera automática en una carga permanente.

El expediente no aporta datos de solicitudes, aprobaciones, rechazos, tiempos de tramitación, cuotas, prefijos rectificados o renumeraciones evitadas bajo la actualización de 2018. Tampoco cuantifica efectos sobre la agregación de rutas. Por eso el beneficio debe describirse como capacidad de servicio y no como resultado medido. La regla abrió una ruta y definió opciones; no hay base para afirmar cuántas organizaciones la usaron, cuánto ahorraron o si una demora concreta causó perjuicio a alguien.

Esa diferencia entre posibilidad y resultado protege el análisis frente a dos exageraciones opuestas. Una diría que todo procedimiento registral es inútil porque no gobierna Internet. La otra convertiría la existencia de la política en prueba de que AFRINIC condujo el despliegue regional de IPv6. La realidad documentada es más estrecha y más interesante. Una organización privada de registro hizo más legible una vía de asignación, pero el despliegue, la arquitectura y el coste continuaron en manos de quienes construían y operaban redes.

El mínimo que el registro sí debe hacer

La crítica al exceso de autoridad no requiere debilitar el trabajo básico de registro. Para prestar un servicio no duplicativo, AFRINIC necesitaba identificar al solicitante, comprobar su relación contractual o de membresía, evaluar una necesidad de direccionamiento dentro de la regla publicada, asignar un bloque único y mantener datos suficientemente exactos para la coordinación. También tenía motivos razonables para pedir un plan técnico, registrar el tamaño concedido y ofrecer una ruta documentada cuando ese tamaño inicial no resultase adecuado.

La guía operativa posterior de NRS ayuda a visualizar, sin probar el estado de 2018, la fricción real de una solicitud: documentos de la organización, diagramas de red, planes de despliegue, evaluación por personal, pagos y registro. Ese contexto recuerda que una política no llega al usuario como una abstracción. Se convierte en formularios, pruebas, intercambios, decisiones y entradas de base de datos. Pero la guía es de 2025 y no puede utilizarse para rellenar los huecos del expediente de 2018, fechar la implementación ni atribuir a la Junta requisitos posteriores.

El límite es igualmente concreto. Comprobar identidad y unicidad no equivale a dirigir el negocio del solicitante. Evaluar un tamaño dentro de una política de asignación no convierte al registro en regulador de arquitectura. Mantener una entrada correcta no le permite castigar opciones de interconexión, confiscar recursos, ejercer policía económica ni resolver derechos públicos. El registro hace valiosa su función cuando la mantiene estrecha: autenticar, asignar sin duplicación, documentar y corregir con transparencia.

Visto así, la contradicción de numeración no prueba mala conducta ni invalida por sí sola la actualización. Sí demuestra por qué la disciplina documental forma parte del servicio. Si el libro mayor técnico pretende reducir incertidumbre, sus propios recibos de decisión deben permitir identificar qué cambió y cuándo. Una etiqueta ambigua añade un coste evitable a operadores, auditores y personal. No les autoriza a inventar una respuesta; obliga a la institución a conservar y aclarar el historial.