Resumen

  • El Borrador 1 proponía hacer obligatorio un contacto abuse-c en los registros inetnum, inet6num y aut-num correspondientes a recursos asignados directamente por AFRINIC. Una dirección accesible y una comprobación objetiva de entrega encajan en el mantenimiento de un directorio técnico útil.
  • La prueba propuesta enviaba dos correos consecutivos —uno con un enlace y otro con un código— y daba dos días laborables para completar un formulario con CAPTCHA y aceptar una declaración sobre vigilancia, medidas y respuesta. Después concedía hasta tres días laborables adicionales antes de declarar el contacto permanentemente inválido; un nuevo fallo pasaba a considerarse incumplimiento de política.
  • El texto no se limitaba a comprobar que el buzón existiera: exigía intervención manual, prohibía el filtrado y que el remitente tuviera que usar un formulario web, permitía validaciones trimestrales o cuando AFRINIC lo estimara oportuno y conectaba el incumplimiento con procedimientos relacionados especialmente con la revocación de recursos.
  • AFRINIC es un registrador técnico privado y coordinador, no una autoridad soberana. La solución proporcionada es publicar un contacto funcional, comprobar solamente su entregabilidad, notificar el defecto, ofrecer un plazo real de subsanación y mostrar un estado de calidad del dato sin convertir el control de recursos numéricos en castigo.

L3 — La máquina de validación de cinco días

Primero llegaría un correo de texto plano con un enlace. Inmediatamente después, otro correo contendría un código único. La persona responsable del buzón tendría que abrir el enlace, superar un CAPTCHA, pegar el código y marcar una casilla. Aquella casilla no certificaba sólo que el mensaje había llegado: afirmaba que la dirección se vigilaba con regularidad, que se adoptaban medidas y que un informe de abuso recibía respuesta. El plazo inicial no podía superar dos días laborables. Si el código seguía sin utilizarse, el contacto pasaría a figurar como temporalmente inválido y AFRINIC escalaría el asunto al registro local de Internet, o LIR.

Se abriría entonces un segundo plazo de hasta tres días laborables. Sin corrección, el estado se volvería permanentemente inválido; si una validación posterior volvía a fracasar, el hecho sería tratado como incumplimiento de política. El texto remitía además a actuaciones más exhaustivas, en especial a procedimientos relacionados con la revocación de recursos.

Ese recorrido estaba unido a un cambio previo y decisivo: el abuse-c dejaría de ser una posibilidad recomendada para convertirse en un campo obligatorio en los objetos que documentaban recursos entregados directamente por AFRINIC. Así, una secuencia administrativa de cinco días podía empezar con un buzón y terminar frente a la sombra de una consecuencia sobre recursos numéricos. La distinción importante aparece justo ahí. Comprobar que una dirección pública recibe correo ayuda a mantener un directorio fiable. Exigir que su titular demuestre una determinada conducta frente a informes de abuso, y respaldar esa exigencia con la posición del registro sobre los recursos, ya no es mantenimiento de datos. Es una pretensión de supervisión operativa.

La propuesta llevaba el nombre Abuse Contact Policy Update Draft 1, el identificador AFPUB-2018-GEN-001-DRAFT01 y la fecha de 12 de agosto de 2018. Fue presentada por Jordi Palet Martinez para sustituir la sección 8.0 del manual consolidado de políticas. Era el primer borrador y permanecía en discusión. Esa condición histórica limita con precisión lo que puede afirmarse: el documento permite reconstruir una propuesta y evaluar la arquitectura que proponía; no demuestra que el Borrador 1 fuera adoptado, implantado o aplicado contra miembro alguno. Tampoco demuestra que una dirección fuera revocada, que alguien perdiera acceso a su cuenta o que se privara de voto a una persona por este texto.

Antes de aquel borrador, AFRINIC ya disponía de una solución específica para publicar contactos de abuso. Una política ratificada en 2011 y descrita como implantada en 2012 había creado un objeto basado en IRT. Los objetos inetnum, inet6num y aut-num podían hacer referencia a él. La referencia, sin embargo, era opcional: se animaba a los miembros a utilizarla como buena práctica, pero el registro no garantizaba que cada recurso emitido directamente condujera a un contacto de abuso visible. Por eso la reforma no partía de un problema imaginario. Un directorio en el que el investigador, el operador de otra red o un equipo de respuesta a incidentes debe adivinar a quién escribir ofrece un servicio incompleto.

El Borrador 1 proponía remediar esa discontinuidad imponiendo al menos un buzón de abuso válido, vigilado y gestionado activamente. Cada recurso asignado directamente por AFRINIC tendría que incluir el contacto abuse-c en la entrada WHOIS correspondiente, fuese un objeto inetnum, inet6num o aut-num. Para los objetos hijos se mantenía flexibilidad: podían heredar el contacto del registro padre o publicar uno propio. Esa regla reconocía una realidad operacional razonable. Un proveedor puede centralizar las denuncias en un equipo común o delegarlas a una unidad que administra un bloque subordinado. Lo indispensable para el usuario del directorio es saber qué puerta está declarada como responsable.

El texto también quería que ese buzón estuviera disponible sin restricciones mediante WHOIS, interfaces de programación y técnicas futuras. En su núcleo, la idea reducía fricción. Un formato consistente evita búsquedas por páginas corporativas desactualizadas, contactos personales o direcciones que sólo entiende el equipo que creó el registro. También permite a herramientas automáticas localizar una dirección por recurso y facilita que un CERT, un operador vecino o una víctima encaminen una advertencia. La estandarización de un campo, por sí sola, no decide si una denuncia es verdadera; simplemente hace encontrable a quien debe recibirla.

El problema aparece al examinar lo que el borrador llamaba validación. Entre las secciones 8.2 y 8.7, la comprobación dejaba de preguntar únicamente «¿puede entregarse un mensaje a esta dirección?». El correo enviado al buzón debía requerir intervención manual en algún momento. Podía existir un acuse inicial automático, pero el proceso no podía agotarse en automatización. El buzón tampoco podía filtrar los mensajes. Y el operador no podía obligar al denunciante a abandonar el correo y completar un formulario web. Con estas reglas, el documento prescribía la configuración de una mesa de atención, no sólo la exactitud del campo que la señalaba.

La casilla del ejemplo de validación revelaba aún mejor esa ampliación. Para confirmar el contacto no bastaba con demostrar posesión del buzón o recepción de los dos mensajes. La persona debía expresar que entendía el procedimiento y la política, que el buzón era revisado regularmente, que se tomaban medidas y que un informe de abuso obtenía respuesta. Esas promesas contienen preguntas muy diferentes. La vigilancia del buzón puede aproximarse a su actualidad como dato.

En cambio, determinar si hubo una «medida» o una «respuesta» suficiente depende del contenido del informe, de su evidencia, de la relación del destinatario con el tráfico y de las obligaciones jurídicas o contractuales aplicables.

La frecuencia convertía la validación en una relación recurrente. AFRINIC debía realizarla cuando se creara o actualizara el contacto, periódicamente al menos una vez cada tres meses y también cuando lo considerara oportuno. El diseño admitía que, en algunas pruebas, se alteraran dominios de envío, asuntos y cuerpos de mensaje. La intención comprensible era impedir que un sistema aparentara estar vivo reconociendo sólo una plantilla previsible.

El efecto era más amplio: el registro obtenía discreción para provocar interacciones de cumplimiento fuera de un calendario cerrado y para interpretar el fracaso de una prueba como algo más grave que un dato pendiente de corrección.

La secuencia de dos correos pretendía separar elementos que juntos permitían completar la comprobación. El enlace aparecía en el primero; el código, en el segundo. Una página protegida por CAPTCHA recibía el código y la atestación. Este método podía probar que alguien tenía acceso suficiente para leer ambos mensajes y actuar sobre ellos. No probaba, sin embargo, que ese alguien hubiera evaluado correctamente un solo informe real.

Tampoco demostraba que el titular de un recurso hubiera permitido abuso, que una denuncia fuese auténtica o que una conducta observada perteneciera al miembro y no a un cliente, un tercero comprometido o un remitente malicioso.

El reloj comprimía esas diferencias. Tras dos días laborables sin uso del código, la dirección se clasificaría temporalmente como inválida y se activaría la intervención del personal. El contacto de escalada del LIR recibiría el seguimiento y tendría hasta tres días laborables más. Si el problema continuaba, la etiqueta pasaría a «permanentemente inválido». Una validación futura fallida se consideraría incumplimiento de política.

La palabra «permanente» describía un estado alcanzado después de apenas cinco días laborables, aunque el defecto del dato pudiera ser fácilmente reversible: una persona ausente, una regla antispam equivocada, un cambio de equipo o una cola de correo rota.

El escalado no acababa en una marca informativa. El Borrador 1 decía que el incumplimiento daría lugar a un seguimiento más exhaustivo conforme a las políticas o procedimientos pertinentes de AFRINIC, especialmente los relacionados con la revocación de recursos. La sección de escalada contemplaba además la intermediación de AFRINIC y la posible utilización de esos procedimientos. La redacción no acredita que se revocara nada. Sí crea una exposición normativa: el fallo de un ritual de correo se vinculaba en el propio diseño con la clase de procedimientos capaz de poner en cuestión la relación registral de un miembro con sus recursos.

La evaluación contemporánea del personal confirma que esa lectura no depende de convertir una frase aislada en una teoría. El personal entendió que el abuse-c sería obligatorio en los registros de asignaciones directas, opcional en los objetos hijos, comprobado en la creación y como mínimo trimestralmente. También entendió que una verificación fallida constituiría incumplimiento de política sujeto a las medidas habituales. Estimó no menos de un mes y medio para desarrollo, pruebas y despliegue. El documento de evaluación no recogió comentarios de asesoría jurídica. La ausencia de observaciones legales no otorga autoridad; sólo delimita el contenido de aquella evaluación.

El coste de implantación calculado por el personal ayuda a ver que el borrador no describía una simple corrección de etiqueta. Había que construir el envío, la separación del enlace y el código, el formulario, el CAPTCHA, los estados temporales y permanentes, la cadencia trimestral, los avisos, el escalado y la gestión de repetidos fallos. Cada componente codificaba una decisión sobre lo que el registro esperaría del operador. Un mes y medio era una estimación mínima del trabajo técnico de AFRINIC, no una medición del coste agregado que asumirían los miembros ni una prueba de que el régimen fuese jurídicamente válido.

También importa distinguir la publicación del contacto de la investigación del abuso. La primera opera sobre hechos limitados: hay un campo, apunta a una dirección y el sistema de correo acepta o rechaza la entrega. La segunda exige tratar alegaciones. Un informe puede carecer de cabeceras, identificar mal una dirección, proceder de un remitente automatizado defectuoso, confundir una marca de tiempo, referirse a un cliente o intentar que el destinatario abra un archivo peligroso. Que exista una persona detrás del buzón no convierte a AFRINIC en competente para resolver esas variables ni hace del silencio dentro de dos días una admisión.

El borrador mezclaba ambos planos mediante verbos de conducta. «Vigilar» puede indicar que el contacto no ha sido abandonado. «Tomar medidas» presupone que hay algo sobre lo que actuar. «Responder» presupone una obligación hacia quien escribe. «Intervención manual» privilegia un modelo de mesa de ayuda. «No filtrar» sustituye el criterio de seguridad del receptor. «No exigir un formulario» decide el canal por el cual una organización debe recibir datos potencialmente sensibles o peligrosos. Ninguna de esas decisiones es necesaria para responder a la pregunta objetiva de si el buzón es alcanzable.

Hay una razón plausible detrás de cada exigencia. Un buzón que sólo devuelve un acuse automático podría estar desatendido. Un filtro excesivo podría descartar denuncias legítimas. Un formulario complicado podría desalentar a una víctima. Una respuesta humana puede cerrar la incertidumbre del remitente. Pero acumular buenas intenciones no elimina el cambio de categoría. Una regla de datos puede exigir un destino funcional. En cuanto el registrador define el tratamiento adecuado del mensaje y enlaza su interpretación a una amenaza registral, pasa de describir un punto de contacto a gobernar una operación.

La situación posterior confirma que estas distinciones no eran meramente semánticas, aunque no debe reescribirse el Borrador 1 con materiales posteriores. El Borrador 2 apareció el 20 de noviembre de 2018. En la reunión AFRINIC-29 del 29 de noviembre se discutieron la verificación de contactos, el bloqueo de MyAFRINIC, los efectos sobre el voto, la proporcionalidad del castigo y la objeción de que el registro se convirtiera en «policía de Internet». Los copresidentes registraron que no había consenso y devolvieron la propuesta para su revisión. Ese debate pertenece al ciclo posterior al segundo borrador, no al texto literal del primero.

Del mismo modo, el informe anual de 2018 describió la propuesta después de que ya existiera el Borrador 2 y mencionó medidas punitivas como el bloqueo de acceso a MyAFRINIC, incluido el acceso al voto. Sirve para entender cómo se presentaba el conflicto a final de año, no para introducir cada detalle posterior en el documento del 12 de agosto. Hubo siete versiones registradas; el Borrador 7 fue presentado el 17 de mayo de 2021 y materiales posteriores lo describen como ratificado. Nada de ello convierte retrospectivamente al Borrador 1 en política adoptada ni permite atribuirle la redacción final.

La prueba histórica correcta es más sobria y, precisamente por eso, más útil. El 12 de agosto de 2018 se publicó una primera propuesta que tomaba un contacto hasta entonces opcional, lo hacía obligatorio para asignaciones directas, diseñaba comprobaciones recurrentes y vinculaba las respuestas esperadas a una cadena de incumplimiento. El documento permaneció en discusión. No conocemos a partir de él un caso real de revocación ni un daño individual probado. Lo que sí podemos evaluar con exactitud es la máquina institucional que pretendía construir y el tipo de poder que esa máquina habría ejercido.

Su núcleo registral era sólido: una entrada homogénea, accesible y actualizada. Su envoltura de cumplimiento no lo era: reglas sobre filtros, formularios, intervención, medidas, respuesta y sanciones potenciales. Ver ambas partes no exige una falsa equidistancia. Permite rescatar la función útil y rechazar el mecanismo que la excede. La pregunta no es si las redes deben recibir informes de abuso. Claro que deben disponer de canales responsables. La pregunta es si el custodio privado de la libreta de direcciones puede decidir cómo deben procesarlos y convertir su acceso a servicios registrales en instrumento para imponer esa decisión.

No puede.