Resumen

  • DRAFT02, presentada por AFRINIC el 25 de septiembre de 2026, dice que una comprobación automatizada puede señalar una posible falta de cumplimiento, pero que el personal debe verificar la información antes de una investigación o medida conforme al RSA o a los estatutos.
  • El cambio respecto de DRAFT01 es de fondo: el resultado de una prueba deja de presentarse como una conclusión automática y pasa a ser una pista que debe examinarse.
  • Un mapa entre política y prueba, con versión, fecha de vigencia, alcance, datos y lógica del control, permitiría saber qué demuestra una alerta y qué queda fuera de ella.
  • La propuesta sigue en debate. El registro público no acredita un tablero operativo, avisos a miembros, hallazgos ni sanciones.

Una comparación de datos no determina qué regla rige

Supongamos que una entidad recibe un aviso porque un dato del registro no coincide con una condición prevista. El software pudo haber leído un contacto, comparado un objeto de ruta o contrastado una asignación con una regla. La comparación puede repetirse y arrojar el mismo resultado. Eso no demuestra por sí solo que la política correcta se aplique a ese recurso, que la fuente esté actualizada ni que el titular haya incumplido una obligación.

Esa separación aparece en la propuesta de tablero de cumplimiento de AFRINIC, AFPUB-2026-GEN-002-DRAFT02. La versión del 25 de septiembre pide automatizar sobre todo aquello que pueda medirse de manera tan objetiva como sea posible y hablar de posibles indicios de incumplimiento. También asigna una función concreta al personal: verificar la información obtenida mediante las pruebas automatizadas. Solo si existen elementos que sugieran incumplimiento, el texto contempla una investigación más exhaustiva y posibles medidas bajo el RSA o los estatutos.

No es la descripción de un producto en marcha. El índice vigente de propuestas mantiene DRAFT02 en debate. Aquí se analiza el límite que fija el texto y la evidencia que necesitaría una eventual implantación.

DRAFT02 cambia el significado del resultado automático

DRAFT01, hoy archivada, utilizaba palabras más concluyentes. Preveía avisos cuando se detectara una falta de cumplimiento y añadía recordatorios, plazos de persistencia definidos por el personal, procedimientos posteriores y reglas aún por redactar para suspender servicios, revocar recursos o cerrar la membresía. También planteaba una excepción del Consejo para ciertos casos de infraestructura crítica o situaciones extraordinarias.

DRAFT02 no es solo una versión con un calendario abreviado. Elimina aquellas cláusulas separadas que dejaban al personal fijar el periodo de persistencia y las reglas de sanción. En cambio, explicita dos límites: la conformidad no puede medirse con objetividad absoluta y las comprobaciones solo pueden sugerir señales posibles. La verificación del personal aparece ahora en el propio texto propuesto. La posibilidad de nuevas medidas conforme al RSA o a los estatutos permanece, incluidos la suspensión, la revocación o el cierre.

La revisión, por tanto, cambia la tarea que se asigna al software. DRAFT01 partía de un estado detectado y denominado incumplimiento. DRAFT02 parte de una señal que puede ser incompleta, equivocada o ajena al alcance de la regla. La revisión humana debe conectar ambas etapas. Su calidad dependerá de qué información reciba quien revisa y de si el miembro puede reconstruir el mismo resultado.

La versión de la regla es parte del dato

La propuesta indica que la automatización tendrá que evolucionar con el Manual Consolidado de Políticas (CPM). No es una cuestión menor de mantenimiento. Una prueba que ayer reflejaba fielmente una política podría clasificar mal un recurso después de una modificación, o adelantarse a la fecha en que el nuevo criterio entra en vigor. Un estado verde o rojo sin referencia a una versión oculta ese problema.

La evaluación de impacto asociada a DRAFT01 citó ejemplos como la exactitud de contactos, la validez de contactos de abuso, la coherencia de objetos de ruta, la cobertura RPKI cuando corresponda y los requisitos de DNS inverso. Son ejemplos del análisis de la versión anterior, no un catálogo definitivo de DRAFT02 ni prueba de que esos controles estén desplegados. Muestran por qué un resultado «automatizado» no se explica solo. La ausencia de un campo puede observarse directamente; determinar si la política aplicable exige ese campo para ese recurso es una pregunta distinta.

La comparación de rutas o de RPKI también requiere identificar fuente, hora y alcance.

Cada control debería vincular dos registros. El primero define la regla: identificador, versión, fecha de vigencia, clase de recursos y condiciones de aplicación. El segundo conserva el recibo de la prueba: fuente, hora de consulta, transformación, versión del test, resultado y límites conocidos. Así, el personal puede volver al dato y explicar por qué se aplica la regla —o por qué hay que cerrar la alerta—. El miembro afectado puede revisar el mismo fundamento sin acceder a información privada de otras entidades.

Esto es una recomendación editorial, no una función anunciada por AFRINIC. DRAFT02 no define un catálogo completo, un método de versionado, una medida de precisión ni un registro de las decisiones del personal. Pero si el resultado solo es un posible indicio hasta su verificación, deben quedar visibles tanto el dato como la regla que se revisan.

El recorrido hasta una medida debe conservar sus etapas

Una cadena comprobable distinguiría al menos cuatro estados: un dato del registro o de la red; una comparación automática que genera un posible indicio; una verificación del personal sobre la fuente y la regla aplicable; y, por separado, cualquier medida permitida por el RSA o los estatutos. No son afirmaciones intercambiables. Una etiqueta del tablero no debería convertir silenciosamente el primer estado en el último.

La separación protege a ambas partes. Un miembro puede corregir un registro inexacto o explicar por qué una regla no le alcanza. El personal puede diferenciar un problema de calidad de datos de una cuestión interpretativa. AFRINIC puede documentar qué evidencia justificaría una investigación posterior. Si la prueba era errónea, la alerta podría corregirse sin dejar en el historial del miembro un estado de cumplimiento imposible de explicar.

El efecto económico es posible, no observado. La propuesta dice que futuras solicitudes, servicios o la membresía podrían verse afectados bajo el RSA. Un estado engañoso podría consumir tiempo del operador o influir en una revisión posterior; un aviso certero podría ayudar a corregir un problema. El material público no demuestra hoy ninguno de esos resultados. Sí permite plantear la pregunta de diseño: ¿cómo se distingue una advertencia útil de una prueba desactualizada o aplicada fuera de contexto?

El historial explica la revisión, no el resultado de DRAFT02

AFRINIC-37 examinó DRAFT01 el 24 de junio. Las actas señalan que los copresidentes no encontraron consenso aproximado y devolvieron esa versión a la lista de correo; un aviso de agosto recoge el mismo resultado. DRAFT02 se presentó el 25 de septiembre y su historial dice que incorpora intercambios en RPD y una evaluación de impacto. La decisión de junio se refiere a DRAFT01, no resuelve la versión actual.

El texto revisado reduce lo que la automatización debe decidir y añade verificación humana. Es un límite probatorio más claro, pero todavía no es una garantía comprobada en servicio. El siguiente paso debería hacer visible el catálogo de controles junto a la política: versión, vigencia, alcance, fuente, lógica, límites y constancia de la verificación. Así, miembros y operadores podrían examinar el mecanismo antes de que una alerta se trate como algo más que una pista.

Fuentes y alcance. La propuesta DRAFT02 y el índice actual muestran el texto y el estado vigentes. La DRAFT01 archivada y su evaluación de impacto contienen la redacción anterior y ejemplos de controles. Las actas de AFRINIC-37 y el aviso de los copresidentes del 12 de agosto documentan la devolución de DRAFT01 a la lista. Ninguno prueba que el sistema se haya desplegado ni acredita un resultado para un miembro.