Resumen

  • Richard Laager describió en la sugerencia 2026.4 una reasignación detallada desde uno de sus NET a otra organización. La clave del bloque padre no podía hacer GET del hijo por identificador, aunque sí podía eliminarlo y obtenerlo mediante mostSpecificNet; la clave de la organización receptora sí podía leerlo por identificador.
  • ARIN respondió el 30 de marzo de 2026 que otras herramientas de consulta y sus planes futuros hacían innecesario cambiar los permisos API entonces. Cerró la sugerencia con el acuerdo del solicitante.

La consulta directa decía no. El borrado decía sí. En la sugerencia 2026.4, Richard Laager relató los pasos: reasignó de forma detallada parte de su NET a otra Org y, después, intentó leer el NET hijo por su handle con la clave API del titular del bloque padre. ARIN rechazó ese GET por falta de permisos. Laager señaló que la misma clave podía borrar el registro, encontrarlo al pedir el NET más específico para las direcciones inicial y final, y que cualquiera podía consultar los datos públicos por Whois. El identificador oficial era, en su caso, la vía más difícil hacia un objeto al que aún tenía acceso de otras maneras.

Una reasignación detallada reparte responsabilidades. La guía de gestión de ARIN dice que la organización receptora debe tener su propio Org ID y puede administrar las direcciones reasignadas. El registrante directo conserva la capacidad de recuperar esa reasignación. La gestión de objetos IRR y DNS inverso asociados se comparte entre ambas partes. Esa estructura explica por qué hay dos credenciales interesadas en un mismo registro. No convierte todas las operaciones de lectura y escritura en un permiso único.

El mapa que aportó Laager tiene cuatro accesos. La clave de la Org receptora obtiene el hijo mediante su handle. La del padre recibe un rechazo en ese endpoint. La del padre sí obtiene un NET al dar el rango a mostSpecificNet. Whois permite ver información equivalente de forma anónima, por identificador o dirección. El objeto no desapareció de la vista pública. La elección del endpoint y de la identidad autenticada cambiaba la respuesta.

La documentación de Reg-RWS distingue esas operaciones. GET /rest/net/NETHANDLE entrega una carga NET. GET /rest/net/mostSpecificNet/STARTIP/ENDIP busca el objeto más específico para un rango. DELETE /rest/net/NETHANDLE genera una solicitud gestionada mediante ticket para retirar reasignaciones o redistribuciones; no borra directamente una asignación primaria. PUT /rest/net/NETHANDLE modifica el registro con una carga NET. Son superficies diferentes. Una automatización que almacena un handle no puede tratar un éxito de búsqueda por rango como si el GET directo también funcionara.

Ahí aparece el coste real. Un sistema de provisión conserva el identificador del hijo creado y vuelve a él para comparar la base de ARIN con su inventario. Si el GET se rechaza, necesita guardar también los extremos del rango, usar otra llamada, comprobar que el resultado tiene el mismo handle y padre, y solo después reconciliar. La consulta pública Whois puede ayudar a una persona, pero produce otra clase de prueba. Usar el permiso de borrado como atajo para reconstruir un estado limpio sería una mala apuesta: un error de lectura nunca justifica remover un registro que sigue vivo.

Laager pidió que GET devolviera datos de NET sin esa restricción. También planteó que quien puede borrar y recrear un hijo directo debería poder modificarlo mediante PUT. Son dos decisiones distintas. Consultar campos que Whois ya publica afecta al acceso de lectura. Modificar el nombre de red, los contactos o los comentarios públicos descritos en la guía de modificaciones afecta al estado que terceros usarán. La propuesta de PUT fue una petición del usuario; ARIN no la adoptó en su respuesta.

El 30 de marzo ARIN dijo que había evaluado otros medios existentes para recuperar la información y futuros planes de desarrollo. Concluyó que cambiar los permisos actuales no era necesario en ese momento. La sugerencia se cerró con el acuerdo del autor. La respuesta deja el comportamiento de los endpoints como una obligación para el cliente: conozca el camino que admite su clave y mantenga las comprobaciones de identidad al cambiar de ruta de lectura.

El límite de la prueba es concreto. La secuencia de rechazo proviene del informe reproducible de Laager; una traza actual con ambas claves y los endpoints documentados mostraría si continúa ocurriendo después de marzo. La decisión pública de ARIN fue conservar el control vigente. Para quien opera un inventario de reasignaciones, la diferencia entre «no puedo leer por este handle» y «este NET no existe» ya exige diseño desde el primer día.

Un registro puede tener dos administradores, varios caminos de consulta y una sola identidad. Cuando el padre puede quitarlo pero no leerlo por su nombre en la API, la institución ha hecho del camino una parte de la autorización. Al cliente le toca recordar esa regla cada vez que un programa intenta comprobar el estado de su propia reasignación.

Sugerencia y respuesta de ARIN · Métodos Reg-RWS · Gestión de recursos · Modificación de NET