Resumen
- Draft 2 amplió las dos ventanas normativas de validación y escalamiento de 2+3 días hábiles a 15+15 días, y cambió el mínimo periódico de cada tres meses a cada seis meses. Sin embargo, dejó intacto un ejemplo de 2+3 días, creando una incoherencia interna que impedía saber con certeza qué reloj habría guiado una futura implementación.
- La propuesta añadió como primera consecuencia un bloqueo de la cuenta y del acceso a sus recursos, salvo la corrección de
abuse-co del buzón de abuso; la revalidación restablecería el acceso, pero después seguía existiendo un seguimiento más exhaustivo, en particular mediante procedimientos relacionados con la revocación. - El personal de AFRINIC entendió que el bloqueo afectaría todas las funciones de MyAFRINIC excepto la corrección del buzón, incluido el voto en elecciones celebradas por el portal. El asesor jurídico de AFRINIC consideró desproporcionada esa pérdida de voto por un fallo administrativo de actualización, aunque señaló que no era ilegal según el derecho de Mauricio.
- Validar que una dirección pública recibe un mensaje neutral es una tarea legítima de exactitud registral. Decidir si hubo abuso, juzgar la respuesta del operador o convertir un fallo de contacto en restricción política, operativa o patrimonial rebasa la función de un registro técnico privado.
L3 — Treinta días en la regla, cinco en el ejemplo
Una revisión que aflojó el reloj y endureció la salida
La historia específica de Draft 2 no es la historia general de por qué conviene publicar un contacto de abuso. Tampoco es la historia posterior de la versión que terminó ratificándose. Su objeto es mucho más concreto: qué cambió entre Draft 1 y AFPUB-2018-GEN-001-DRAFT02, publicado el 20 de noviembre de 2018, y qué consecuencias institucionales descubrió la evaluación de 2019. Mirado como un redline, el cambio tiene una forma extraña.
Los autores concedieron más tiempo al titular y redujeron la carga periódica, pero al mismo tiempo insertaron una restricción inmediata que podía extender un defecto de directorio a toda la relación entre el miembro y el registro.
En Draft 1, la sección normativa 8.4 fijaba un máximo de dos días hábiles para la validación inicial. Si esa validación fracasaba, la cuestión escalaba al LIR y se abría un segundo plazo máximo de tres días hábiles. La sección 8.5 exigía validar el contacto al crearlo o actualizarlo, al menos una vez cada tres meses y también cuando AFRINIC lo estimara oportuno. Ante el incumplimiento, el texto remitía a un seguimiento más exhaustivo bajo las políticas y los procedimientos de AFRINIC, con especial mención de los relacionados con la revocación de recursos.
La fecha de Draft 1 exige una cautela que no debe maquillarse. La lista y los detalles actuales de AFRINIC identifican el 12 de agosto de 2018, mientras que el texto superviviente del historial de revisiones dice 12 de marzo de 2018. No hay base en el conjunto documental para escoger una de las dos y borrar la otra. Esa discrepancia no altera el hecho central de este análisis: Draft 2 fue publicado el 20 de noviembre de 2018. Pero sí enseña por qué una cronología institucional debe conservar sus fricciones en vez de alisarlas hasta producir una certeza falsa.
Draft 2 cambió los dos tramos normativos. El primer periodo pasó de un máximo de dos días hábiles a un máximo de quince días. El segundo, abierto tras el fracaso y el escalamiento, pasó de un máximo de tres días hábiles a otro máximo de quince días. No se trataba, por tanto, de treinta días garantizados en todos los casos, sino de dos ventanas máximas sucesivas de quince días dentro del mecanismo de validación. La distinción importa: esos periodos no eran un acuerdo de nivel de servicio para resolver la denuncia de abuso subyacente. Medían pasos destinados a probar o restablecer la validez del canal de contacto.
La cadencia ordinaria también se relajó. Donde Draft 1 pedía una validación al menos trimestral, Draft 2 exigía como mínimo una cada seis meses. Continuaban los controles en la creación o actualización del registro y la facultad de actuar cuando AFRINIC lo estimara oportuno. A ello se añadió una discrecionalidad más explícita: AFRINIC podría modificar las ventanas inicial y de escalamiento si explicaba a la comunidad las razones, y podría variar la frecuencia periódica con la misma condición de motivación. El texto incluso contemplaba un comienzo lento, con una sola validación durante el primer año y un incremento gradual posterior.
Hay dos maneras de leer ese ajuste temporal, y ambas caben sin inventar hechos. La interpretación benigna es operacional. Una campaña de validación masiva puede generar falsos negativos, colas de soporte y errores de entrega; ampliar plazos y empezar despacio permite depurar la herramienta sin castigar al titular por la inmadurez del sistema. Reducir el mínimo de cuatro pruebas anuales a dos limita además el ruido administrativo. La lectura crítica no niega esa utilidad: observa que la frase que permite validar cuando AFRINIC lo estime oportuno seguía en pie y que la nueva facultad de modificar los tiempos aumentaba el margen operativo.
La obligación de explicar las razones era una condición de transparencia, no una definición precisa de cuándo, cómo y con qué salvaguardias debía ejercerse esa discreción.
El cambio decisivo no estaba, sin embargo, en la duración de los plazos. Draft 2 añadió una primera consecuencia que Draft 1 no expresaba de la misma forma. Si persistía el incumplimiento, se bloquearía el acceso de la cuenta a sus recursos, salvo el acceso necesario para actualizar abuse-c o el buzón de abuso. Tras una revalidación satisfactoria, el acceso se restablecería. Esa secuencia contenía un incentivo claro y una vía de cura: corregir el dato, demostrar que el buzón era alcanzable y recuperar la cuenta. Pero el alcance de la frase «acceso a sus recursos» quedó indeterminado, y la intervención no terminaba necesariamente allí.
Draft 2 conservó el seguimiento más exhaustivo conforme a las políticas y procedimientos pertinentes de AFRINIC, especialmente los relacionados con la revocación de recursos. Es decir, la nueva restricción no reemplazaba la cola dura del esquema anterior; se colocaba delante de ella. El diseño resultante podía recorrer tres estaciones: validación fallida, restricción de cuenta hasta la cura y, si el asunto continuaba, procedimientos más graves vinculados con la revocación. Que el texto dibujara esa posibilidad no demuestra que AFRINIC la ejecutara contra nadie en 2018.
Sí permite evaluar el mecanismo que proponía y la desproporción potencial entre su punto de partida —un problema de contacto— y su horizonte final —la continuidad de recursos numéricos—.
El ejemplo que quedó atrás
La revisión de los plazos normativos no fue acompañada por una revisión equivalente del ejemplo procedimental. En la misma versión, el ejemplo seguía dando al código de validación dos días laborables de vigencia y, después, tres días hábiles adicionales antes de declarar la dirección permanentemente inválida y repetir la prueba. Por tanto, Draft 2 contenía a la vez una regla normativa de quince más quince días y una ilustración heredada de dos más tres. No hay fundamento para fusionarlas, seleccionar la más conveniente o presentar el ejemplo como si también hubiera cambiado.
Esa inconsistencia es más que una imperfección editorial. En un sistema sin consecuencias amplias, dos relojes discordantes ya producen dudas sobre cuándo debe actuar el titular, cuándo puede escalar el personal y cuándo debe considerarse fallida la validación. Cuando el resultado puede ser el bloqueo de MyAFRINIC, la ambigüedad afecta la posibilidad real de curar. Un miembro que confíe en los quince días normativos podría descubrir que la automatización sigue un ejemplo de dos; un equipo que programe conforme al ejemplo podría endurecer la propuesta más allá de su texto operativo.
Tampoco se sabe, a partir de estas fuentes, cuál habría prevalecido en código, porque no se ha probado aquí que Draft 2 llegara a implementarse.
La distinción entre texto normativo y ejemplo no autoriza a restar importancia al segundo. Los ejemplos traducen reglas abstractas en expectativas de operación. Influyen en la especificación del software, en los procedimientos del personal y en la conducta del miembro. Si contradicen la norma, introducen una segunda política por la puerta de la implementación. Una organización puede decir que la cláusula formal manda, pero el titular interactúa con correos, temporizadores, estados de cuenta y bloqueos reales. Por eso la armonización de ambos relojes habría sido una condición básica de previsibilidad antes de cualquier despliegue.
También conviene separar tres objetos que la terminología puede confundir. El periodo de validez del código comprueba que alguien recibe y usa un mensaje. El plazo de escalamiento permite buscar al LIR u otros contactos cuando la primera ruta falla. El tiempo necesario para investigar, contener o remediar un abuso depende de hechos técnicos, contractuales y jurídicos que la simple entrega de un correo no resuelve. Convertir quince días en un supuesto límite para satisfacer al denunciante añadiría al texto una obligación que no está definida.
Y considerar incorrecta o ausente una respuesta exige criterios sustantivos que una prueba de entregabilidad no puede proporcionar por sí sola.
Draft 2 sí incluía una cláusula de escalamiento para sospechas de manipulación de la validación y para respuestas incorrectas o inexistentes a casos de abuso. Podía haber revalidación, intermediación de AFRINIC y posible uso de los procedimientos pertinentes. Ese pasaje ampliaba el problema desde la existencia del buzón hasta una evaluación de conducta. Sin un estándar de abuso, prueba, respuesta suficiente, contradicción e independencia decisoria, la frase «respuesta incorrecta» corre el riesgo de transformar al encargado del directorio en árbitro de una disputa entre terceros.
La propuesta no documenta un incidente concreto ni permite acusar a un miembro de manipulación. Lo que ofrece es un diseño cuyos límites deben examinarse antes de atribuirle legitimidad.
Lo que la evaluación de 2019 reveló
El 20 de abril de 2019, el personal de AFRINIC evaluó las implicaciones de Draft 2. Su lectura del bloqueo fue amplia: todas las funciones de MyAFRINIC quedarían deshabilitadas excepto la actualización del buzón de abuso hasta que la validación tuviera éxito. Eso significaba que el alcance no se agotaría en la ficha defectuosa. Si una elección de la AGMM u otra votación utilizaba MyAFRINIC, el miembro tampoco podría votar. Un fallo administrativo de contacto podía, así, alterar su participación en la vida corporativa del registro.
El asesor jurídico de AFRINIC señaló la desproporción. Perder el derecho de voto por no actualizar información de contacto era una consecuencia que debía revisarse, aunque no fuera ilegal bajo el derecho de Mauricio. Las dos partes de esa conclusión son importantes. La ausencia de ilegalidad no convierte una medida en necesaria, prudente o adecuada a la función institucional. La proporcionalidad pregunta si el medio guarda relación con el defecto que pretende corregir y si hay una opción menos invasiva.
Aquí la respuesta era evidente: se podía limitar el estado de la cuenta a la corrección del contacto sin suprimir una facultad política distinta.
El propio personal indicó además que «acceso a sus recursos» no estaba claro y sugirió especificar qué ediciones de base de datos se bloquearían. La incertidumbre podía alcanzar WHOIS o IRR, aunque el texto no fija en esta evidencia un inventario definitivo de funciones. No corresponde convertir esa preocupación en prueba de que se cortó el enrutamiento, RPKI o el DNS inverso de alguien. Corresponde observar que, antes de adoptar una regla, quien la diseña debe definir la superficie exacta de restricción y excluir explícitamente las capacidades cuya continuidad no depende del buzón.
La estimación técnica era de unos seis meses de desarrollo de software, incluidas modificaciones en WHOIS condicionadas por la solución que finalmente fuera ratificada. Esa condicionalidad vuelve a separar propuesta e implementación. Una estimación de trabajo no es un registro de despliegue. Un análisis jurídico tampoco es una decisión de adopción. Y una página publicada con Draft 2 no prueba que sus temporizadores o bloqueos hayan funcionado en producción. Presentar cualquiera de esos documentos como evidencia de ejecución borraría etapas institucionales que precisamente deben permanecer visibles.
La versión que AFRINIC registra como posteriormente ratificada fue Draft 7, fechada el 17 de mayo de 2021, y la ratificación se sitúa el 4 de febrero de 2026. Ese dato posterior cierra una cuestión negativa: Draft 2 no debe presentarse como la versión adoptada. Tampoco prueba por sí solo la fecha exacta de despliegue ni el estado operativo de cada función de validación actual. La cadena correcta es: publicación de Draft 2 en 2018; evaluación de ese proyecto en 2019; aparición de una versión posterior; ratificación de Draft 7 en 2026. Cada verbo tiene una carga probatoria distinta.
La precisión no es un formalismo defensivo. Si se afirma que Draft 2 fue implementado, se atribuyen a AFRINIC actos contra miembros que estas fuentes no documentan. Si se omite la evaluación de 2019, se pierde la mejor evidencia interna de que el bloqueo podía alcanzar el voto y de que su proporcionalidad ya era problemática para el propio asesor jurídico. Si se usa Draft 7 para legitimar retrospectivamente Draft 2, se convierte una revisión de política en una máquina del tiempo. La lectura responsable mantiene juntos el redline y sus consecuencias, pero separados los estados de propuesta, adopción y operación.
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
