Resumen
- ARIN distingue objetos IRR simples, creados en ARIN Online o con XML, y avanzados, creados con RPSL o migrados desde IRR-email. La clase decide qué canal permite crear, consultar, modificar o borrar.
- Un objeto migrado puede verse y eliminarse en la interfaz web, pero no editarse allí. Si el operador lo borra y lo vuelve a crear en Online, deja de ser una corrección dentro del mismo linaje.
- Dos páginas actuales de ARIN discrepan sobre el uso de RPSL REST con objetos nacidos en Online. Este análisis no probó una cuenta real y no convierte esa discrepancia en una afirmación sobre el sistema en producción.
- ARIN podría conservar la continuidad con un recibo acotado que una clase, huella previa, autoridad, canal, acción, resultado y huella sucesora, sin publicar credenciales ni datos personales innecesarios.
La diferencia operativa empieza antes del contenido
Supongamos que un operador detecta un atributo que debe corregir en un objeto IRR migrado. En ARIN Online puede abrirlo. También tiene una opción para eliminarlo. La posibilidad que no tiene es editarlo. El guía de usuario indica que la modificación de los objetos procedentes de IRR-email se hace por REST; las notas de implementación dicen que, para administrarlos desde Online, es necesario eliminarlos y crearlos de nuevo. Guía de usuario del IRR de ARIN
La pantalla presenta una tarea: «dejar el objeto correcto». El registro ejecuta dos acontecimientos: retirar una aserción y aceptar otra. El segundo objeto puede repetir cada atributo visible del primero, pero ya no conserva el mismo origen técnico. Ha sido creado por un canal nuevo y entra en la clase asociada a ese canal.
No hay evidencia pública en el paquete examinado de que ese proceso haya perdido una ruta, provocado una incidencia o perjudicado a una organización. Tampoco se probó una cuenta, una clave ni un objeto. La investigación no evalúa un caso de producción; evalúa una regla documentada de control. Precisamente por eso conviene no mezclarla con una acusación de seguridad.
El límite puede tener una razón sólida. Si el formulario no representa todos los matices de un objeto RPSL antiguo, editar una parte en Online podría reescribir otra sin que el usuario lo vea. Rechazar la modificación protege la semántica. La pregunta razonable no es por qué ARIN no permite cualquier edición, sino cómo conserva la relación entre el objeto retirado y el que nace cuando el usuario decide cambiar de canal.
La matriz de permisos guarda la biografía del objeto
La página general de ARIN usa dos categorías. Los objetos simples son los creados en ARIN Online o mediante REST con XML. Según su matriz, se pueden crear, consultar, modificar y borrar por esas dos vías, pero no tienen permisos en REST con RPSL. Los objetos avanzados se crean mediante REST/RPSL o proceden de la migración de IRR-email. Para ellos, RPSL REST admite las cuatro operaciones, XML REST ninguna, y Online solo consulta y eliminación. Descripción general del IRR de ARIN
«Simple» y «avanzado» describen una superficie de gestión. No afirman que un origen AS sea más legítimo, que una política esté más vigente o que una ruta tenga mayor alcance. ARIN señala además que la diferencia no altera el formato público de consulta: la respuesta se entrega en RPSL.
Esa separación es correcta. El consumidor de un route, route6, aut-num, as-set o route-set necesita leer la aserción de política. No necesita conocer la clave API ni la interfaz usada por el mantenedor. El sistema de control, en cambio, sí debe recordar qué validación y qué representación autorizaron el cambio.
RFC 2622 aporta el límite técnico. RPSL es un lenguaje para especificar políticas de encaminamiento en registros IRR. Describe objetos y relaciones; no observa el plano de rutas. Un objeto válido no demuestra que una sesión BGP anuncie lo mismo, ni que todos los operadores acepten esa información al construir filtros. RFC 2622
Por tanto, la biografía del objeto sirve para auditar el registro, no para certificar Internet. Es posible defender una trazabilidad estricta de escritura y rechazar, al mismo tiempo, que esa trazabilidad se use como sustituto de una medición de rutas.
Una migración responsable no finge un nacimiento nuevo
Las notas de implementación explican parte de la historia. Los registros del servicio por correo se sometieron al entorno más nuevo y quedaron separados entre objetos validados de ARIN y objetos de ARIN-NONAUTH. ARIN afirma que los migrados superaron una validación más estricta y que la interfaz los identifica. También advierte que, cuando una organización usa por primera vez la web o REST, pierde de forma permanente la posibilidad de seguir actualizando por IRR-email. Notas de implementación de IRR Online
Cerrar el canal antiguo evita dos escritores con credenciales, parsers y reglas distintas. Es una decisión de reducción de ambigüedad. Mantener una marca de migración reconoce algo que el registro sabe: el objeto no nació bajo la experiencia actual aunque hoy cumpla sus validaciones.
La defensa importa porque cambia el remedio. Unificar todas las vías sin comprobar el recorrido completo de los datos podría ser peor que mantenerlas separadas. XML, un formulario y RPSL no tienen por qué expresar cada objeto con la misma fidelidad. Si una conversión no es reversible, la interfaz debe decirlo antes de tocar el estado, no después.
Lo que falta en la descripción pública es una salida verificable. El operador necesita una preimagen canónica, la clase vigente, el motivo de la incompatibilidad, una validación previa del candidato y un enlace entre el borrado y la recreación. Esa cadena permite cambiar de herramienta sin borrar la explicación de por qué el objeto tenía unos permisos determinados.
Un PUT y una pareja DELETE/POST dejan riesgos diferentes
La API REST de ARIN documenta GET, POST, PUT y DELETE. PUT modifica un objeto; DELETE lo elimina. Admite cargas RPSL y XML conforme a los permisos aplicables. Esta gramática del protocolo deja claro que «editar» y «sustituir» no son sinónimos, aunque el objetivo humano sea el mismo. API REST del IRR de ARIN
Una modificación puede registrar la huella anterior y la posterior bajo una continuidad. El borrado y la creación tienen dos resultados independientes. La creación puede fallar la validación; el objeto nuevo puede incorporar una normalización; la observación pública puede producirse después del retiro. Ninguno de esos desenlaces se ha observado aquí. Son estados que el diseño debe poder distinguir.
El periodo entre operaciones tampoco puede cuantificarse con las fuentes disponibles. No se conocen estadísticas de objetos migrados, tiempos de propagación, series NRTM ni frecuencia de uso del atajo. No es lícito afirmar que un generador de filtros vio una ausencia. Sí es lícito pedir que el sistema no reduzca dos actos falibles a una etiqueta genérica de «cambio».
La continuidad es especialmente delicada si se reutiliza la misma clave del objeto. El consumidor puede creer que se trata del mismo registro, aunque la clase y el canal autorizante hayan cambiado. Si se utiliza otra clave, la sucesión puede resultar todavía menos visible. Un ticket interno podría explicar la intención a corto plazo, pero no es una prueba pensada para el mantenedor futuro ni para una herramienta automática.
ARIN publica dos respuestas para una vía RPSL
La matriz actual de la página general dice que los objetos simples no admiten ninguna operación mediante RPSL REST. Las notas de implementación, en una página que enumera actualizaciones hasta el 17 de enero de 2025, dicen que un objeto creado en ARIN Online puede verse, actualizarse y borrarse por REST usando RPSL o XML.
No se pueden convertir esas frases en una respuesta única sin añadir información que las fuentes no contienen. Puede haber una diferencia de versión, tipo de objeto o condición de cuenta. También puede haber documentación desfasada. Una prueba autenticada de un solo caso no resolvería todas esas dimensiones.
El artículo histórico de febrero de 2021 ayuda a entender que las capacidades cambiaban y que algunas restricciones estaban previstas para una etapa posterior. ARIN lo conserva en Vault con un aviso de posible obsolescencia. Su valor es cronológico; no debe ganar una disputa entre documentos actuales. ARIN Vault: llegada de la API REST
La reparación documental sería pequeña y concreta: una matriz única con versión efectiva que cruce clase, tipo, operación, canal y codificación. El comportamiento observado en producción seguiría siendo evidencia de un caso; la matriz sería el compromiso público. Mientras no coincidan, el desacuerdo debe acompañar cualquier instrucción operativa.
Un recibo de continuidad puede ser deliberadamente pobre
No hace falta publicar un historial laboral ni las credenciales de quien actúa. Un recibo útil puede limitarse al tipo y la clave pública del objeto, la clase y procedencia previas, la versión de permisos, la huella canónica anterior, la acción, la categoría de actor autorizado, el canal y formato, el resultado, la clase y huella posteriores y un vínculo de sucesión. Si ARIN puede observarlo con precisión, una referencia de publicación o serie NRTM añadiría contexto.
El recibo demuestra una transición controlada por el registro. No asegura que cada espejo haya recibido el dato, que un tercero lo haya utilizado para generar filtros ni que el tráfico siga la política escrita. Tampoco debe contener la clave API o el nombre de una persona si basta con su clase de autorización.
El guía de ARIN reserva la gestión IRR a POC Admin, Tech y Routing; los Resource POC quedan fuera. Esa autorización por rol no sustituye la regla de canal. Una persona puede estar facultada para administrar la organización y seguir sin poder editar un objeto migrado desde Online. Registrar ambas dimensiones evita que un error de interfaz parezca un error de identidad.
La conclusión es modesta. ARIN puede conservar con razón el canal de origen para proteger validación y procedencia. Pero cuando el cambio de herramienta requiere destruir y reconstruir, la institución también debe conservar el hilo entre ambos estados. Sin él, el sistema resuelve la incompatibilidad haciendo desaparecer precisamente la historia que usaba para imponerla.
Fuentes
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