Resumen

  • La propuesta correcta fue AFPUB-2018-V6-001-DRAFT01, presentada por Jordi Palet Martinez en marzo de 2018. No debe confundirse con V6-002, que trataba por separado las subasignaciones de IPv6.
  • La actualización sustituyó la referencia obsoleta a RFC 3177 por RFC 6177, retiró la recomendación de /128 para un único dispositivo, redefinió la utilización por número de prefijos asignados, corrigió una referencia interna y eliminó una revisión general de múltiples /48.
  • Aunque la propuesta se presentó como una aclaración sin cambio de aplicación y el personal la consideró implementable sin impacto operativo para AFRINIC, su texto podía influir legítimamente en la planificación, las pruebas solicitadas y el riesgo de renumeración de los operadores.
  • Una corrección transparente y versionada mejora la contabilidad técnica privada. No transforma a AFRINIC en soberano, regulador, legislador, policía, autoridad punitiva, confiscador ni tribunal: ninguna reunión, consenso aproximado o ratificación puede producir esas facultades.
  • La lección institucional es concreta: cada modificación del manual necesita una relación de dependencias, un texto comparado visible, recibos de interpretación e implementación y una barrera de alcance que separe exactitud técnica de expansión de autoridad.

L3 — La referencia obsoleta escondida en el manual

El defecto cabía en una línea, pero no vivía aislado en una página sin consecuencias. En 2018, la sección de IPv6 del manual de políticas de AFRINIC seguía enviando al lector a RFC 3177, un documento de 2001 que había recomendado, a grandes rasgos, /48 para sitios finales, /64 cuando se sabía que existía una sola subred y /128 cuando se conocía un único dispositivo. RFC 6177 había declarado obsoleta esa referencia en marzo de 2011.

Había rechazado la idea de que una sola medida, en particular /48, debiera funcionar como respuesta automática para todos los sitios; había desaconsejado limitar un sitio a un mero /128; y había devuelto la elección exacta del tamaño a un juicio operativo informado por la arquitectura de IPv6. La página del manual llevaba, por tanto, siete años conservando una instrucción externa superada.

Llamar editorial a ese problema no lo vuelve trivial. Un manual de registro no es literatura ornamental. Es una interfaz entre quienes administran el libro técnico y quienes necesitan saber qué presentar, cómo describir una red y qué comportamiento esperar del servicio. Una referencia equivocada puede sobrevivir a numerosas operaciones diarias sin provocar un incidente visible, y aun así desviar decisiones. El lector diligente que siguiera la cita antigua podía diseñar una red alrededor de categorías que la orientación posterior ya no aceptaba como receta universal.

El miembro podía preparar una justificación distinta de la que prepararía ante un criterio basado en necesidad. El personal podía heredar vocabulario y supuestos incompatibles con el documento técnico vigente. El error no adjudicaba por sí solo un prefijo ni prueba que alguien recibiera una asignación dañina. Sí introducía una bifurcación innecesaria en el significado del manual.

La propuesta que abordó esa bifurcación fue IPv6 Policy and References Update Draft 1, con el identificador probado AFPUB-2018-V6-001-DRAFT01. Jordi Palet Martinez figura como autor. La página oficial registra el 11 de marzo de 2018 como fecha de presentación y el historial de revisión señala que el borrador inicial llegó a la lista rpd el 14 de marzo. Conviene fijar esos datos porque el registro de selección que originó la comisión usó por error V6-002. Ese código correspondía a otra propuesta, dedicada a aclarar las subasignaciones de IPv6.

La rectificación no es el tema principal del análisis, pero ilustra la misma disciplina que el artículo exige al manual: un identificador correcto impide mezclar expedientes que tienen alcances diferentes.

V6-001 no se limitó a cambiar una cifra en una cita bibliográfica. El problema declarado era que el despliegue de IPv6 y cambios previos de política habían dejado incoherencias y referencias erróneas en el texto vigente. Tanto la propuesta como el informe anual de AFRINIC describieron la intervención como una aclaración, una corrección de errores y una actualización de referencias, no como una transformación de la aplicación. Esa caracterización oficial importa, pero debe leerse junto a la totalidad del texto comparado.

Una corrección puede carecer de la intención de cambiar resultados y, al mismo tiempo, modificar la manera razonable en que un lector interpreta una obligación. Por eso la buena gobernanza no descansa solo en la etiqueta de “editorial”; exige examinar cada delta.

El primer conjunto de deltas estaba en la sección 6.0. El texto anterior hablaba de ISP y reproducía los supuestos de /48, /64 y /128 asociados con RFC 3177. La propuesta cambió ISP por LIR, un término que situaba mejor la instrucción en la relación operativa pertinente. Conservó /48 y /64 como ejemplos, no como una talla obligatoria para todo caso. Retiró la recomendación de /128 para la situación de un único dispositivo. Y reemplazó RFC 3177 por RFC 6177. Vistas juntas, esas modificaciones reducían el peligro de convertir una vieja clasificación en algoritmo automático.

El manual dejaba de sugerir que conocer un único aparato resolvía el problema de dimensionamiento mediante el prefijo más pequeño posible.

La diferencia técnica es importante porque una dirección o un prefijo no se escoge únicamente para describir el instante presente. El diseño debe absorber funciones de red, crecimiento razonable, separación de subredes y continuidad. RFC 6177 no sustituyó una regla rígida por otra regla rígida. Se apartó precisamente del enfoque de talla única y dejó margen al juicio de las comunidades operativas, dentro de las propiedades arquitectónicas de IPv6. De ese cambio no se sigue que todo sitio deba recibir /48, ni que toda asignación /64 sea incorrecta. Tampoco se sigue que el registro pueda imponer cualquier preferencia que desee.

Se sigue algo más sobrio: el manual debía representar con fidelidad la orientación actual y permitir una elección basada en la necesidad, sin presentar el /128 como destino natural de un sitio por el mero hecho de que en ese momento hubiera un dispositivo.

La guía operativa RIPE-690, publicada en octubre de 2017, ayudaba a concretar esa transición. Recomendaba prefijos adecuados para los usuarios finales, persistencia de las asignaciones y /64 globalmente enrutable para enlaces punto a punto. Su valor dentro de este expediente no consiste en conceder poder público a AFRINIC ni en convertir una práctica de operadores en ley. Consiste en mostrar las consecuencias de diseñar mal: una talla insuficiente o una falta de persistencia puede obligar a renumerar, alterar aprovisionamiento, incrementar registros y soporte, y deteriorar la experiencia de clientes.

La propuesta incorporó ese sentido operativo al reemplazar viñetas fijas por una selección basada en la necesidad, recomendar /48 para infraestructuras más sencillas, favorecer prefijos persistentes y recomendar /64 GUA en enlaces punto a punto.

El segundo delta afectaba a la definición de utilización. El texto anterior medía los /48 asignados a sitios finales. Ese denominador daba por sentada una unidad fija que ya no encajaba bien con una política de tamaños elegidos según la necesidad. La propuesta definió la utilización como el número de prefijos asignados. No la hizo depender del tamaño de cada prefijo ni del recuento de direcciones efectivamente usadas. Esta precisión es fácil de perder si el documento se resume como una mera actualización de RFC.

En realidad reparaba el lenguaje con el que un LIR podía planificar su crecimiento y con el que el personal podía interpretar una cifra de utilización.

Las tres nociones no son intercambiables. Contar prefijos asignados responde a cuántas unidades de delegación se han entregado. Contar direcciones usadas intentaría observar ocupación dentro de esas unidades, una medición distinta y a menudo impracticable como sustituto. Usar siempre /48 como denominador convertiría una recomendación histórica en geometría obligatoria, incluso cuando se hubieran elegido otros tamaños por razones operativas. Si el manual no distingue esas posibilidades, dos lectores responsables pueden producir cálculos incompatibles.

La corrección no demuestra que antes hubiera solicitudes rechazadas o aprobadas de modo erróneo; el expediente no cuantifica resultados. Sí elimina una fuente objetiva de ambigüedad entre el modelo de asignación y el método de medirlo.

Un tercer delta reparó una referencia interna. El texto relativo a excepciones apuntaba a la sección 6.3.3, cuando la referencia correcta era 6.5.2. La propuesta redirigió la instrucción y mantuvo que, de ordinario, no se solicitaría información detallada sobre la red del usuario. Un número de sección equivocado parece el ejemplo más puro de errata. Sin embargo, en un manual que organiza motivos, excepciones y documentación, un enlace muerto obliga al miembro a adivinar. Puede llevarlo a presentar información innecesaria, omitir una explicación pertinente o aceptar una petición que el texto correcto no respalda.

Corregir el destino no concede una facultad nueva al personal: aclara el límite ya expresado y hace verificable su aplicación.

El cuarto delta eliminó la sección 6.5.4.2 existente, que regulaba múltiples /48 para un solo sitio final mediante una disposición general de documentación y revisión al nivel de AFRINIC. La supresión quitaba una capa heredada de revisión que ya no armonizaba con el enfoque de tamaño basado en necesidad. Tras la eliminación, la sección que antes era 6.5.4.3 ocupó su lugar en la numeración. De nuevo, no basta decir que se borró texto obsoleto. La existencia o ausencia de una revisión determina quién debe explicar qué, cuándo interviene el registro y cuánto margen queda a una apreciación administrativa.

Al retirar esa hoja, la propuesta reducía una oportunidad de documentación superflua y discreción, siempre bajo la condición de que la regla restante fuera clara.

La intervención también acortó el párrafo introductorio sobre asignaciones independientes del proveedor en la sección 6.8. No sustituyó la arquitectura separada de elegibilidad para PI ni resolvió su debate más amplio. V6-004 pertenecía a ese otro asunto. Del mismo modo, V6-003 abordaba la actualización de asignaciones iniciales y V6-002 las subasignaciones. Mantener esas fronteras evita atribuir a V6-001 cambios que no poseía. Su unidad temática fue más estrecha: alinear lenguaje, definiciones, referencias y una revisión heredada dentro del manual IPv6.

El expediente de la reunión AFRINIC-28 permite observar cómo se presentó ese alcance. El 9 de mayo de 2018, el autor dijo que la propuesta no afectaba la emisión ni la información de justificación. El personal declaró que podía implementarse tal como estaba y sin impacto operativo para AFRINIC. El resultado anunciado por la copresidencia la llevó a Last Call. Esas afirmaciones son evidencia de intención, viabilidad y etapa procedimental; no son demostración matemática de que ningún operador pudiera cambiar su planificación.

“Sin impacto operativo” para la organización puede significar que no eran necesarios sistemas nuevos o procesos complejos. No equivale a afirmar que una referencia actualizada carece de efecto interpretativo para todos los miembros.

Los registros posteriores completan la trayectoria sin justificar invenciones. El manual CPM 1.3 consignó el 1 de noviembre de 2018 los cambios en 6.0, 6.1 y 6.5.4.1 y la eliminación de la antigua 6.5.4.2. El 29 de noviembre, AFRINIC anunció la aplicación de Policy and References Update y la actualización del manual a esa versión. La documentación disponible no ofrece en este expediente el libro completo de mensajes de Last Call, el acta íntegra de ratificación del Board ni la fecha exacta de esa ratificación.

Por tanto, la reconstrucción responsable llega hasta donde llegan los recibos: discusión, paso a Last Call, incorporación al manual e información de implementación. No rellena los huecos con una cronología imaginada.

La página archivada de la propuesta conserva además una etiqueta de estado “Under Discussion”, pese a que los otros registros oficiales muestran Last Call e implementación. Esa discordancia no invalida la aplicación; demuestra que una sola página no constituye un historial de ciclo de vida suficiente. Un registro institucional serio necesita relacionar el borrador con su discusión, la decisión, la versión concreta del manual y el aviso de puesta en práctica. Cuando esos componentes quedan separados, el lector debe reconstruir el estado verdadero a partir de varios documentos.

La precisión editorial incluye también esa costura entre artefactos.

El panorama completo es, así, más significativo que la caricatura de una errata. Había una referencia técnica obsoleta; una taxonomía de tamaños que podía leerse como fórmula; una medición de utilización anclada en /48; una remisión interna incorrecta; una revisión general heredada; y una introducción PI que requería simplificación sin invadir la política PI separada. La propuesta expuso el antes y el después en un cuadro visible. Esa forma era una virtud institucional porque permitía comprobar cada modificación. El lector no tenía que comparar dos documentos consolidados y conjeturar qué se había movido.

Tampoco hay base para convertir el retraso de siete años en acusación de dolo o negligencia. El expediente prueba obsolescencia, no una intención de engañar. No identifica una disputa concreta, una lesión a un miembro, una asignación que debió ser distinta ni un abuso del personal. La disciplina probatoria obliga a resistir dos exageraciones opuestas: decir que el texto no importaba porque se llamó editorial, o decir que su imperfección demuestra corrupción institucional. Lo demostrable se encuentra entre ambos extremos. El manual contenía defectos capaces de aumentar incertidumbre y coste; la reparación fue pertinente, auditable y limitada.

Esa limitación define la naturaleza del acto. AFRINIC es un registro privado de membresía que lleva cuentas técnicas y coordina recursos de numeración. Puede mantener un manual para preservar unicidad, exactitud de registros, contactabilidad, metadatos de seguridad interoperables, cambios resistentes al fraude y continuidad operativa. No es un Estado ni deriva soberanía de una lista de correo. Corregir una referencia no es legislar. El texto comparado no es una ley pública. Last Call no es consentimiento regional soberano. Una ratificación interna no crea policía, castigo, confiscación o jurisdicción.

La propuesta fue útil precisamente dentro de una función privada estrecha, y su utilidad no necesita ficción de autoridad para ser reconocida.