Resumen

  • AFPUB-2026-IPv4-003-DRAFT01 propone cuatro pools IPv4, rastreo de bloques recuperados, límites de solicitud y una cola posterior al agotamiento.
  • AFRINIC lo registra hoy como “Under Discussion”, aunque una respuesta fechada de los copresidentes del PDWG dijo que la presentación de junio no llegó a tiempo para entrar como propuesta nueva en la siguiente reunión.
  • La gobernanza necesita dos registros unidos: uno para las direcciones y otro para la autoridad procesal de las reglas.

La precisión numérica no convierte un borrador en norma

El texto parece un manual operativo. En el pool Pre-Softlanding, una solicitud normal iría de /24 a /18 y podría llegar a /16 con métricas de crecimiento y un plan de despliegue verificable. El solicitante tendría que acreditar un 80 % de uso eficiente de sus delegaciones anteriores durante un periodo justificativo de doce meses. Cuando se agotaran los dos pools principales, una cola distribuiría normalmente de /23 a /24, caducaría las solicitudes sin respuesta a los treinta días y limitaría durante veinticuatro meses las transferencias voluntarias.

Son reglas propuestas, no instrucciones vigentes. El índice oficial identifica la versión 1.0, presentada el 8 de junio de 2026, como objeto de discusión. No la presenta como consensuada, ratificada ni implantada. La diferencia importa porque los operadores pueden cambiar inversiones y solicitudes ante cifras muy concretas incluso antes de que exista autoridad para aplicarlas.

Cuatro pools exigen procedencia verificable

La arquitectura separaría el pool Soft Landing, reservas para políticas específicas, un pool Pre-Softlanding y un pool temporal de recursos recuperados. Cada bloque recuperado entraría primero en este último. El personal rastrearía su categoría original y, si no pudiera establecerla con certeza razonable, lo enviaría al Pre-Softlanding. Los bloques parciales se clasificarían proporcionalmente y cada decisión se anunciaría.

El origen decidiría las condiciones de elegibilidad, tamaño y aplazamiento. Un error podría alterar quién recibe un recurso escaso, cuánto obtiene y si puede transferirlo. Por eso el registro debería mostrar bloque, estado previo, evidencia de origen, regla aplicada, responsable, hora, pool de destino y delegación posterior. Los totales agregados no bastan para revisar un caso discutido.

Las afirmaciones de que el pool activo duraría unos dos años, un /12 reservado otros tres, habría más de tres millones de direcciones recuperadas y algunos miembros habrían obtenido más de ocho bloques /22 mediante solicitudes sucesivas proceden de los autores. Este paquete no audita por separado esos datos.

El proceso de políticas tiene otra cola

El 18 de junio, los copresidentes acusaron recibo de la entrega del día 8, pero indicaron que el plazo para propuestas nuevas de la siguiente reunión había cerrado el 26 de mayo a las 23:59 UTC. También señalaron otra propuesta sobre espacio recuperado. Por ello, este borrador no podía entrar como nueva propuesta en aquella reunión.

No fue un rechazo de fondo. Los copresidentes animaron al autor a compartirlo como mejora o alternativa en la lista. “Under Discussion” y no ser elegible para una reunión concreta son estados distintos; ninguno demuestra por sí solo consenso, retirada o ratificación.

Unir el estado del recurso y el de la regla

El control adecuado es un registro doble. El lado de recursos seguiría cada entrada, reclasificación y salida. El lado de autoridad conservaría versión, discusión, elegibilidad para reunión, consenso, acción de la Junta y fecha efectiva. Cada movimiento apuntaría a la regla vigente en aquel momento.

Así se evitaría que una práctica de escasez se adelantara a la autoridad. También permitiría comparar propuestas superpuestas por sus efectos concretos sobre procedencia, reposición, utilización, límites, prioridad, transferencias y transparencia.

Fuentes