Resumen

  • El control de obligaciones contractuales de AFRINIC se aplica a las colas Hostmaster, afrinic-dbm e Internet Routing Registry. Exige un contacto registrado, una cuenta en good standing y un Registration Service Agreement firmado en el expediente.
  • Si falla una condición, la regla niega soporte o recursos, concede un plazo razonable de unos diez días laborables y cierra el ticket si el incumplimiento continúa. Después de subsanar hay que presentar uno nuevo. No se publican gravedad, definición del reloj ni tratamiento provisional para una corrección urgente y reversible.

La defensa más fuerte es la custodia

Un registro no debería ejecutar una instrucción solo porque llega por correo. Una antigua empleada, un proveedor o un tercero pueden conservar credenciales o conocer los datos suficientes para parecer autorizados. Cambiar un contacto WHOIS, una delegación inversa o un objeto de política de rutas afecta a un registro que consultan otras redes.

El Contractual Obligations Check responde a ese problema con tres comprobaciones para Hostmaster, afrinic-dbm e IRR: el solicitante figura como contacto registrado, el Resource Member está en good standing y AFRINIC conserva un RSA firmado.

Cada condición protege algo diferente. El contacto demuestra autoridad; la situación financiera conecta servicios compartidos con deudas ya exigibles; el RSA identifica a la contraparte contractual. No son casillas decorativas. Quitarlas favorecería la velocidad a costa de la integridad del registro.

Además, la vía de corrección existe. Una persona delegada puede ser presentada por un contacto autorizado. Si todos los contactos dejaron la organización, AFRINIC describe una carta con membrete, firma de un responsable como el CEO o CTO y sello corporativo. La guía sobre el RSA firmado dice que, cuando el acuerdo no aparece en el archivo interno, el solicitante recibe un aviso de incumplimiento y las indicaciones para resolverlo.

Un mismo semáforo para tres clases de trabajo

La página de incumplimiento establece que todas las solicitudes de soporte y/o recursos IP se deniegan hasta que la cuenta cumpla todas las secciones. Hay un período “razonable” de unos diez días laborables. Si la situación persiste, se cierra el ticket; tras corregirla, se debe abrir una solicitud nueva.

Como disciplina documental, la secuencia es comprensible. Como política de cola, está incompleta. Una petición de recursos adicionales puede esperar sin alterar un registro existente. Una corrección de contacto, DNS inverso u objeto IRR puede tener otro reloj. La guía del IRR explica que las redes publican políticas de enrutamiento para que otros operadores las utilicen. No demuestra que un ticket tardío haya cambiado una ruta o causado una caída. Sí muestra por qué conviene separar trabajo aplazable de correcciones sensibles al tiempo.

La regla pública no asigna severidad, no ofrece una medida temporal segura y no dice si la solicitud conserva su posición cuando llegan los documentos. “Unos diez días laborables” tampoco identifica el inicio, los festivos, las pausas de revisión ni el huso horario del vencimiento.

Resolver la verificación puede requerir otra intervención

La página de verificación de miembros añade una fricción circular. AFRINIC afirma que los contactos o datos organizativos inexactos incumplen el RSA y suspenden el soporte hasta su corrección. Sin embargo, el nombre de la organización y las direcciones general y de facturación solo pueden cambiarlos empleados de AFRINIC. Para una nueva dirección se pide una factura de servicio público con menos de tres meses.

El remedio es real: contactar con Member Services, aportar pruebas y dejar la cuenta en conformidad. Pero la documentación pública no une ese trámite al ticket operativo bloqueado. El miembro puede terminar gestionando dos números: uno para reparar la cuenta y otro, creado desde cero, para el trabajo original.

El Member Guidebook separa contactos administrativos, técnicos y de facturación. El técnico puede gestionar recursos, registrar asignaciones, administrar delegaciones inversas y pedir direcciones adicionales. Por eso no basta con registrar “contacto sí/no”. Hay que saber si esa persona tiene autoridad para esa acción, qué prueba falta, cuándo llegó y qué riesgo permaneció durante la espera.

También good standing necesita una fecha. Su definición requiere trámites completos, membresía vigente y ninguna deuda vencida sin pagar; una factura todavía no exigible no descalifica. Registrar el saldo y la fecha usados para decidir convertiría una regla legítima en una regla comprobable.

El expediente no acredita un daño

Las fuentes revisadas no identifican un miembro mal atendido, un corte, una fuga de rutas, una retirada de recursos ni una decisión caprichosa. Que la página pública no describa una excepción urgente tampoco demuestra que no haya un proceso interno. El hallazgo es más preciso: la regla visible carece de clase de riesgo, semántica del plazo, acción provisional y recibo que conecte el ticket cerrado con el nuevo.

No conviene convertir un campo vacío en una acusación. Tampoco conviene exigir que el operador adivine un control esencial. La calidad institucional está en explicar tanto la razón para detener como el modo de mantener la detención proporcionada.

Fuentes

El paquete usa el resumen del CoC, la secuencia de incumplimiento, la comprobación del RSA, la verificación de miembros, el Member Guidebook, la guía del IRR y la definición de good standing. Las fuentes prueban el mecanismo publicado, no un incidente concreto.