Resumen

  • prop-167-v002 solicitó estadísticas públicas horarias de WHOIS/RDAP y, por separado, una función MyAPNIC para que cada titular viera las consultas realizadas sobre sus recursos.
  • La Resolución 2025-32 respaldó las estadísticas públicas. Para MyAPNIC, el EC concluyó que coste, recursos y posibles preocupaciones de privacidad superaban el beneficio inmediato, por lo que no la consideró viable entonces.
  • La rama pública está implementada: el archivo de junio enumera ficheros horarios el 30 de junio de 2026 y el JSON actual contiene objetos diferenciados de RDAP y WHOIS.
  • El único estado Implemented puede describir correctamente el ámbito respaldado, pero no conserva por sí solo la decisión distinta aplicada a la segunda salida.

La mejor forma de empezar esta historia no es con una ausencia. En el FTP de APNIC hay un JSON actual, su checksum y un archivo por años. El directorio de junio de 2026 enumera ficheros horarios del día 30. El objeto corriente separa RDAP y WHOIS, marca el intervalo temporal y distribuye consultas por tipo, ASN y cantidad de IP de origen distintas.

El resultado técnico coincide con el cierre administrativo. La página de prop-167 muestra Implemented y anota el 30 de junio de 2026 como Implementation Complete. El flujo público no es una aspiración ni una promesa pendiente: es un artefacto accesible.

El problema aparece al recuperar el texto que llegó al consenso y la decisión del EC. Ahí no hay una sola línea.

Salida de v002 Decisión del 4 de diciembre de 2025 Prueba pública observada en agosto de 2026
Estadísticas horarias y legibles por máquina sobre WHOIS y RDAP Respaldada por la Resolución 2025-32 JSON actual y ficheros horarios verificados el 30 de junio
Vista MyAPNIC de consultas sobre los recursos de cada titular No considerada viable en aquel momento por los motivos publicados Ninguna fuente revisada acredita una decisión posterior o implementación

La tabla no convierte la segunda línea en un fracaso. Tampoco resta valor a la primera. Expone una relación más sencilla: el texto comunitario tenía dos productos y la fase de respaldo les asignó dos estados.

El volumen fue el argumento, no el veredicto

prop-167-v002, publicado el 21 de agosto de 2025, decía que APNIC había respondido aproximadamente 5.500 millones de consultas entre el 1 de abril y el 30 de junio. Añadía que, en algunas horas, RDAP recibió consultas de más de 365.000 IP distintas. La fuente indicada era información interna de APNIC.

Esas cifras deben conservar su procedencia. El paquete público revisado no permite reproducir el cálculo histórico ni identificar por qué se originó cada solicitud. La propuesta hablaba de posibles usos automatizados, minería o recolección masiva; no probaba abuso de un ASN, una empresa o un investigador.

La respuesta colectiva era un flujo horario en JSON o CSV. Debía distinguir WHOIS de RDAP e incluir los ASN de origen —al menos los mil principales—, el número de IP de origen por ASN y metadatos como tipo y método de consulta.

La respuesta para el titular era otra superficie. MyAPNIC debía mostrar cuántas veces se habían consultado sus IP o ASN, con desglose por tipo y, cuando fuera posible, por ASN de origen. Esa función relacionaba una cuenta autenticada, sus recursos y eventos de consulta con una granularidad diferente.

La evaluación de impacto reconocía esa separación. El flujo público requería extracción y publicación, se ofrecería best-effort y no tendría SLA. El añadido MyAPNIC podía exigir un volumen grande de trabajo en los registros de los sistemas WHOIS subyacentes.

El 11 de septiembre de 2025, la versión 2 alcanzó consenso en APNIC 60. La llamada final terminó el 14 de octubre. El objeto comunitario que llegó al EC contenía ambas salidas. Lo que todavía faltaba era la fase que el propio PDP reserva al respaldo ejecutivo.

La palabra decisiva fue “con respecto a”

El Policy Development Process no presenta el consenso como una orden directa a producción. Tras mantenerse el consenso, el SIG Chair solicita respaldo al EC; después de ese respaldo, el Secretariat implementa la política.

La Resolución 2025-32 respaldó la adopción de prop-167-v002 con respecto a las estadísticas públicas en tiempo real o casi real. A continuación citó la función MyAPNIC y registró otra conclusión. El coste, los recursos y las posibles preocupaciones de privacidad superaban el beneficio inmediato; por eso el EC no la consideraba viable en aquel momento. La resolución fue unánime.

Ese lenguaje limita tanto la crítica como el resumen. No hay base para acusar al EC de carecer de autoridad dentro del proceso publicado. Tampoco hay base para convertir sus razones en pretexto. Y “en aquel momento” no significa “para siempre”, del mismo modo que no contiene una promesa de revisión futura.

Lo importante es que el alcance no fue implícito. El EC lo escribió. Si la página posterior borra la separación, no desaparece el documento; aumenta el trabajo necesario para interpretarlo correctamente.

El archivo hace verificable la rama respaldada

La presentación de APNIC 61 situó prop-167 en implementación y proyectó el final del segundo trimestre. Su descripción se concentró en la publicación legible por máquina. Los datos actuales de la Product Roadmap hablan de cumplir los requisitos de la propuesta respaldada.

El FTP convierte esas expresiones en evidencia operativa. El archivo de junio conecta la fecha de cierre con horas concretas. El JSON actual permite inspeccionar la forma del producto. No hace falta inferir su existencia de una diapositiva.

Conviene no cargar ese artefacto con más significado. Una muestra no demuestra continuidad perfecta, exhaustividad histórica ni estabilidad futura del esquema. Un archivo ausente no sería automáticamente una violación de política, menos aún de un SLA que la evaluación excluye. Tampoco valida por sí solo los 5.500 millones citados para 2025.

Sí demuestra lo esencial: APNIC materializó la salida pública respaldada. Esa afirmación positiva es el punto de partida de cualquier análisis responsable.

Implemented necesita una regla de derivación

En la página canónica, el lector ve la versión 2, el análisis de impacto que aún menciona MyAPNIC, una fecha de respaldo y una fecha de finalización. No ve, en las filas de estado e historia, el desglose que aparece en la resolución.

Si Implemented significa «se ha implementado el ámbito respaldado por el EC», el estado tiene apoyo empírico. Si significa «todo lo que recibió consenso está en producción», los documentos lo contradicen. La página no declara cuál de las dos lecturas utiliza.

No se resuelve el problema suprimiendo el resumen. Una propuesta seguirá necesitando un estado para índices y búsquedas. Se resuelve mostrando las unidades mínimas de decisión de las que se deriva ese estado: cada salida o cláusula con su disposición propia.

La segunda salida necesita una etiqueta exacta, no punitiva. Fallida confundiría viabilidad con incumplimiento. Abandonada excedería la frase temporal. Puede registrarse como no respaldada el 4 de diciembre de 2025, no viable entonces por las razones declaradas y sin revisión posterior acreditada por las fuentes consultadas.

El registro no debe publicar las consultas privadas

Una proyección por salida no obliga a APNIC a crear hoy la función MyAPNIC. Mucho menos a revelar direcciones de origen, consultas individuales o datos de una cuenta. El objeto público es la decisión, no el historial privado que la función habría mostrado.

La página podría enlazar el hash de v002, identificar cada producto y conservar fechas de consenso y final comment. Después asociaría Resolution 2025-32 y la disposición correspondiente. Para la rama implementada, añadiría el FTP, formato y primera hora verificada. Para la otra, mantendría la razón con fecha y cualquier decisión posterior de reconsideración o sustitución.

Campo mínimo Función de control
Versión y huella del texto Evitar que una edición posterior sustituya al objeto decidido
Identificador de salida Separar la unidad documental de la unidad de decisión
Estado comunitario Conservar el consenso sin convertirlo en autoridad ejecutiva
Resolución, autoridad y disposición Demostrar qué alcance avanzó
Artefacto y fecha de producción Unir implementación con un resultado observable
Estado de la salida no respaldada Distinguir juicio temporal, revisión y sustitución
Linaje de corrección Actualizar sin borrar la decisión anterior
Regla del estado global Explicar lo que resume Implemented

No es un proceso paralelo. Es la representación compacta del proceso que ya ocurrió. APNIC puede mantener privados los test, los costes y la evaluación detallada de privacidad.

Lo desconocido no autoriza una acusación

Las fuentes no muestran si APNIC estudió después una arquitectura más segura o barata para MyAPNIC. No aparece una resolución posterior, un release note o un elemento específico de roadmap que demuestre la vista por recurso. La falta de publicación tampoco prueba que no exista trabajo interno.

No hay un caso de titular perjudicado, filtración, incumplimiento de servicio o incidente de seguridad asociado. Las hipótesis de minería y recolección masiva pertenecen a la justificación del autor de la propuesta, no a una constatación contra alguien.

Tampoco se conoce la convención general con la que APNIC transforma un respaldo acotado en estado de propuesta. La mejora puede respetar cualquier convención estable: conservar el estado global y hacer visibles sus premisas.

La implementación pública merece un cierre inequívoco. La función que no avanzó merece una memoria igual de precisa. Presentar dos resultados no reabre la votación; permite leerla como realmente ocurrió.

Fuentes