Summary

  • La sección 3.7 de la política vigente de ARIN exige que quien recibe una reasignación detallada o una reallocation ya figure en su base como organización y tenga al menos un punto de contacto validado. Sin ese contacto, ARIN rechaza la solicitud. Las reasignaciones simples no establecen ese vínculo.
  • Según la guía oficial de administración, una ficha simple usa un nombre de cliente introducido como texto libre sin verificación; el titular directo puede modificarla o borrarla. La ficha detallada y la reallocation requieren Org ID y acuerdo de servicios, y conceden distintas facultades al receptor.
  • La plantilla de rechazo de ARIN indica al cliente que valide un contacto y avise después al proveedor para que reintente el registro. La plantilla documenta una transacción registral fallida; no contiene datos de tráfico.

ARIN describe la reasignación simple con una franqueza poco habitual: el nombre del cliente se introduce como «free text» en su guía y no se comprueba. La ficha muestra que una parte del bloque del proveedor sirve a un tercero. Pero ese tercero no puede gestionar la ficha. El titular directo conserva la capacidad de cambiarla o eliminarla cuando quiera. El cliente aparece en el libro; el bolígrafo permanece arriba.

La reasignación detallada coloca al cliente en otra posición. ARIN exige un identificador de organización, el Org ID, y un Registration Services Agreement. El destinatario puede añadir contactos y administrar las direcciones recibidas desde ARIN Online. También puede trabajar, junto con el proveedor, sobre objetos del registro de rutas y DNS inverso. El proveedor aún puede recuperar la reasignación. El cliente consigue controles reales dentro de una relación que el titular directo puede cerrar.

La reallocation, o redelegación a un operador que distribuirá direcciones a otros, amplía esas facultades. También necesita Org ID y acuerdo. El destinatario puede crear registros para sus propios clientes. ARIN indica que el titular directo sigue pudiendo reclamar la reallocation. Las tres fichas forman una escala: nombre anotado por el proveedor; cliente capaz de gestionar su registro; cliente capaz de registrar a sus propios destinatarios. La identidad exigida se endurece a medida que la ficha concede más poder.

La sección 3.7 del manual de políticas convierte esa escala en una puerta de entrada. Para una reasignación detallada o una reallocation, la organización destinataria debe existir ya en la base de ARIN y contar con al menos un Point of Contact validado. Si no lo tiene, ARIN debe rechazar la petición. La misma sección aclara que una reasignación simple se hace sin vínculo con objetos de organización o contacto de esa base. Dos fichas pueden referirse al mismo uso de direcciones y, aun así, asignar derechos de operación completamente distintos.

La guía de registro de reasignaciones explica por qué el cliente puede necesitar la ficha más exigente. Una reasignación detallada sirve cuando quiere mantener su propia delegación de DNS inverso o mostrar puntos de contacto separados. Si debe dividir el espacio para clientes propios, entra en juego la reallocation. Optar por la ficha simple para ahorrar el trámite de validación deja esas necesidades técnicas sin la capacidad registral correspondiente. El problema nace antes de la primera incidencia de red: nace al elegir qué relación se escribe.

ARIN ha publicado las palabras que aparecen cuando el trámite falla. En sus modelos de mensajes, el Org ID del destinatario carece de POC validado y la reasignación no se procesa. El aviso al cliente le pide entrar en ARIN Online, validar el contacto y avisar a su proveedor. El aviso al proveedor le pide solicitar esa validación y volver a enviar la solicitud. El proveedor inicia; el cliente repara; el proveedor reintenta. Una petición comercial puede quedar esperando a dos buzones diferentes.

El estado de los contactos tiene su propio calendario. La sección 3.6 de la política prevé un correo anual y concede hasta sesenta días para confirmar o corregir la información Whois. El personal de ARIN puede marcar un POC como inválido tras analizar que ha sido abandonado por completo y de forma permanente o que es ilegítimo por otro motivo. La norma describe esa evaluación, no una invalidación automática al terminar el plazo. Un POC inválido solo puede usar funciones de pago y actualización de contactos en ARIN Online. Si la organización no tiene ninguno válido, pierde otras funciones hasta que un contacto administrativo o técnico valide o corrija su registro.

Tampoco puede el proveedor inventar por su cuenta la identidad que falta. La sección 3.8 dispone que ARIN cree una organización a petición directa de un representante autorizado de una entidad verificable; rechaza la creación solicitada por terceros. Esa frontera frena las organizaciones ficticias y exige cooperación del cliente real. El proveedor puede comprometerse a entregar direcciones en un contrato, pero la identidad con la que el cliente las manejará ante ARIN necesita su propia intervención.

Los documentos oficiales no incluyen un expediente fechado que permita medir el retraso sufrido por un cliente concreto. Un rechazo y su reenvío con fechas mostrarían ese costo. Las reglas ya revelan la elección institucional: ARIN acepta el nombre libre mientras el proveedor lleva la ficha; cuando la ficha concede una mano al cliente, exige una organización reconocida y un contacto que haya respondido.