Resumen

  • ARIN-2025-1 sostiene que todos los ISP son LIR, aunque no todos los LIR son ISP. La definición propuesta de LIR exige ser Internet Registry, pertenecer a un RIR, recibir asignaciones y distribuir recursos a clientes, usuarios finales e infraestructura.
  • La definición de ISP sólo exige prestar servicios de Internet a terceros e incluye conectividad, servicios web, colocation, servidores dedicados, VPS y VPN. De esos criterios no se desprende la inclusión anunciada.
  • Una tabla de predicados y una manifestación de migración, ambas versionadas, permitirían reconstruir la clasificación sin obligar al registro a decidir el modelo comercial o la arquitectura de la organización.

Dos preguntas que una sola etiqueta oculta

En una solicitud pueden formularse dos preguntas. ¿Qué servicio presta la empresa? ¿Qué hace con los recursos numéricos que recibe? La primera habla del mercado. La segunda determina si existe una función de registro y qué política debe aplicarse.

El operador de acceso tradicional responde de forma parecida a ambas. Vende conectividad, recibe espacio directamente y delega partes a sus clientes. Esa coincidencia explica que ISP y LIR hayan circulado como sinónimos en la región de ARIN.

Los casos menos familiares muestran el límite. Un proveedor de web administrada puede operar por completo con direcciones de un upstream. Una universidad puede recibir y distribuir una asignación sin vender banda ancha. Una gran empresa puede cumplir una función de registro para unidades o clientes sin presentarse comercialmente como ISP.

El rastreador de NOG Alliance, independiente del registro, clasifica ARIN-2025-1 como Draft Policy y fecha su último cambio el 13 de agosto de 2026. El proyecto parte de una carencia real: LIR está definido, pero ISP no lo está de forma separada. Su planteamiento declara que, por implicación y práctica empresarial común, todos los ISP son LIR, aunque no todos los LIR sean ISP.

La frase no describe sólo una asociación frecuente. Afirma una relación de conjuntos. Toda organización que cumpla la definición de ISP tendría que cumplir necesariamente la definición de LIR. Para lograrlo no basta que la mayoría de los ejemplos conocidos caiga en la intersección.

Una política puede escoger esa inclusión. Lo que no puede hacer una definición clara es dejarla a cargo de la familiaridad del lector.

El LIR sigue el movimiento del recurso

El texto preservado en un archivo independiente de PPML de marzo de 2026 define LIR mediante una cadena. Es un Internet Registry, es miembro de un RIR, recibe de ese RIR asignaciones de números de Internet y las asigna a clientes, usuarios finales e infraestructura.

Cada verbo corresponde a una función registral. Recibir fija la procedencia. Asignar o subdelegar describe el movimiento descendente. Registrar preserva la trazabilidad. La lista de ejemplos —grandes empresas, universidades e ISP— indica que LIR no es un sector comercial único.

La misma distribución archivada muestra una migración amplia: títulos y cláusulas operativas pasarían de ISP a LIR, y la cláusula terminológica trataría ISP como subconjunto de LIR. No es una nota marginal de glosario; el nombre del papel atraviesa asignación, reasignación, utilización y obligaciones hacia clientes downstream.

El archivo demuestra qué texto circuló, no qué texto tiene autoridad. El rastreador sólo establece el límite de versión posterior y el estado. El expediente debe conservar ambas cosas: el objeto exacto analizado y la versión más reciente cuyo texto completo habrá que revisar antes de implementarlo.

El ISP sigue el catálogo de servicios

La definición propuesta de ISP mira en otra dirección. Es una organización que proporciona servicios de Internet a otras organizaciones, a sus clientes o a personas que no son sus empleados. Los ejemplos incluyen conectividad, servicios web, colocation, servidores dedicados, servidores privados virtuales y redes privadas virtuales.

La oración no exige que la organización sea Internet Registry. No exige una asignación directa del RIR, membresía ni distribución de recursos a terceros. Un producto externo basta para entrar en el texto; ninguna transición registral forma parte de ese predicado.

La ambigüedad aparece en un intercambio de PPML preservado de forma independiente. Un participante cita una guía que equipara brevemente LIR con ISP y, a la vez, una definición según la cual los LIR son sólo «generalmente» ISP; pregunta si las categorías son idénticas, están anidadas o son opcionales para titulares de asignación directa. El archivo prueba que la confusión fue expresada, no cómo decidiría staff una solicitud concreta.

La separación sigue siendo saludable. La descripción del servicio ayuda a elegir qué documentación leer. Los criterios de recursos deciden si la solicitud está justificada. Vender VPN no produce por sí solo una asignación. Alojar servidores no prueba que la empresa registre redistribuciones de espacio.

La propuesta original decía que el ISP era un tipo de organización LIR. El borrador actual dice que es un tipo de organización. Esa omisión no cambia el catálogo comercial; cambia la lógica del conjunto.

La relación necesita una implicación

Cinco símbolos bastan para probar el alcance del texto sin convertir la política en código.

IR(x) significa que la organización distribuye recursos numéricos y registra esas distribuciones. M(x) representa la membresía del RIR en el sentido versionado que se elija. A(x) indica que recibe una asignación directa. D(x) indica asignación o subdelegación descendente. S(x) significa que presta al menos uno de los servicios de Internet enumerados a un tercero.

La definición propuesta puede expresarse como LIR(x) = IR(x) ∧ M(x) ∧ A(x) ∧ D(x). Para ISP queda ISP(x) = S(x).

La afirmación de que todo ISP es LIR requiere S(x) → IR(x) ∧ M(x) ∧ A(x) ∧ D(x). El texto público no contiene esa implicación.

Esto no demuestra una clasificación operativa errónea. Los analistas pueden pedir datos adicionales y otras cláusulas regulan la elegibilidad. El hallazgo es más limitado: las definiciones que prometen claridad no permiten derivar por sí solas la relación que el propio problema anuncia.

La comunidad dispone de varias soluciones. Puede volver a definir ISP como tipo de LIR. Puede exigir una función de distribución para que el término ISP tenga efecto normativo. Puede reconocer conjuntos superpuestos. Puede suprimir ISP de las reglas decisorias y utilizar sólo predicados de uso y subdelegación.

No es necesario elegir esa política desde fuera. Sí es necesario que la opción elegida quede en el texto.

Una empresa sintética en la frontera

Imaginemos una empresa que vende web administrada y acceso VPN. Obtiene todas sus direcciones de un proveedor upstream. No tiene una asignación directa de ningún RIR y no asigna ni registra recursos numéricos para clientes como Internet Registry.

El ejemplo es sintético. No representa a una compañía, solicitud o decisión real de ARIN.

Según la lista propuesta, la empresa cumple S(x) porque ofrece a terceros dos servicios expresamente incluidos. No cumple al menos A(x) y D(x). Puede tampoco cumplir el requisito de miembro, según el significado que se otorgue a esa palabra.

En el mercado puede llamarse ISP. La guía ISP puede ser el mejor punto de partida para descubrir si un futuro modelo de asignaciones a clientes justifica recursos directos. Pero una ruta de información no debe confundirse con el evento que aún no ha ocurrido.

El valor del caso no depende de que sea habitual. Si una regla de inclusión falla con un caso posible dentro de sus propias palabras, necesita un puente adicional.

Función de recursos y etiqueta empresarial son ejes distintos

RFC 7020 describe el sistema de registros de números de Internet como una jerarquía en la que los registros asignan recursos a clientes y los LIR son típicamente ISP. «Típicamente» describe una relación frecuente; no define una identidad entre el papel registral y toda empresa que vende un servicio de Internet.

En el eje de recursos aparecen solicitante, titular directo, distribuidor downstream, end user y operador que usa espacio upstream. En el eje de servicios aparecen conectividad, hosting, colocation y VPN. Una clasificación puede consultar ambos, pero debe decir qué combinación activa el papel normativo.

Una definición alternativa propuesta en PPML hacía explícita esa elección: vinculaba LIR al sistema de RFC 7020 y señalaba el consumo y la justificación de recursos para clientes como rasgo importante de ISP. Era la sugerencia de un participante, no texto adoptado. Su utilidad es diagnóstica: cuando se conoce la función buscada, el puente cabe en una frase.

Si member of an RIR sigue siendo condición de LIR, el texto debe nombrar la relación exacta y el momento del ciclo en que se comprueba. Un servicio comercial no crea ese estado por implicación y una relación de recursos no debe inferirse de una marca empresarial.

La historia administrativa mantuvo separados los papeles

RFC 2901, guía informativa publicada en 2000, encaminaba a las organizaciones hacia procedimientos distintos según cómo obtendrían y usarían direcciones. Es historia y no establece requisitos actuales de ARIN. Sí fija un punto analítico duradero: ISP se ha usado como etiqueta de vía de solicitud, mientras LIR pertenece a la jerarquía registral.

Los términos pueden converger en conversación y los procedimientos seguir haciendo preguntas diferentes. El dato común útil no es el sustantivo preferido por la empresa, sino la función del recurso que selecciona una regla en una versión y fecha concretas.

El debate público ya encontró el puente débil

La discusión archivada no trató sólo de estilo. Una respuesta de marzo de 2026 coincidió en que la frase propuesta para LIR estaba gramaticalmente incompleta y cuestionó at a local level, porque algunos LIR operan más allá de una sola región RIR. El mismo mensaje reprodujo la definición de ISP basada en servicios.

Esa respuesta no decide la política ni describe una implementación. Muestra que los participantes ya estaban probando los predicados y su alcance antes del límite de versión del 13 de agosto. El hallazgo de este artículo no es una acusación oculta, sino una pregunta textual reproducible que una versión posterior puede resolver.

La terminología es estado distribuido. Una definición llega a títulos, guías, instrucciones, formación y campos de solicitud. La versión más reciente debe revisarse como un objeto nuevo, no como continuación silenciosa del texto archivado en marzo.

Registro mínimo de predicados y migración

Un segundo revisor no necesita conocer cada producto o cliente. Necesita saber qué función decidió la vía, bajo qué vocabulario y con qué transición de recursos. Dieciséis campos bastan para empezar.

  1. Identidad de organización y Org ID. Fijar la identidad jurídica y registral, junto con el periodo al que corresponde.
  2. Identidad de solicitud o decisión. Crear una clave estable, hora de presentación y vínculos a revisiones o reemplazos.
  3. Versión del vocabulario. Nombrar la versión exacta de NRPM, draft o perfil operativo, su fecha efectiva y sus definiciones.
  4. Propósito de la clasificación. Especificar qué decisión requiere el rol; una etiqueta general no debe decidir acciones diferentes.
  5. Predicado de servicio comercial. Registrar la clase externa pertinente sin incorporar todo el catálogo privado.
  6. Predicado de Internet Registry. Indicar si la organización distribuye recursos y registra las distribuciones, enlazando la evidencia protegida.
  7. Estado de asignación directa. Separar ninguna, solicitada, aprobada, emitida, devuelta, revocada o reemplazada y vincular el evento.
  8. Función de delegación descendente. Distinguir reallocation y reassignment, clase de receptor y cláusula que las rige.
  9. Uso de infraestructura interna. Mantener el uso propio separado de la distribución a clientes.
  10. Estado de membresía. Registrar solicitante no miembro, Service, General, General en regla o Trustee conforme a la versión; no inferir voto del rol técnico.
  11. Acuerdo y autoridad. Vincular RSA/LRSA y autoridad organizativa a pruebas protegidas sin publicar documentos privados.
  12. Vía de política aplicable. Enumerar secciones, criterios y exclusiones seleccionados por la función verificada.
  13. Correspondencia de ocurrencias. Conservar término viejo, término nuevo, sección, superficie y código limitado de efecto semántico.
  14. Vinculación de implementación. Unir el significado con guía pública, instrucciones, formación, campo de aplicación y versión de test.
  15. Resultado, explicación y corrección. Preservar predicados decisivos, resultado, revisión, transición posterior y correcciones.
  16. Proyección agregada con privacidad. Publicar conteos de vías, cambios de clasificación, desajustes de formularios y correcciones sin nombres ni secretos.

La lista no ordena una arquitectura informática. Define la unidad mínima de memoria que impide que una etiqueta sustituya a la razón.

Lo común es la función; el negocio permanece local

La doctrina de Minimum Initial Specification exige precisión únicamente sobre las reglas deterministas necesarias para unicidad, interoperabilidad, prueba, seguridad compartida y transición. Las preferencias comerciales y el juicio institucional no deben entrar por defecto en la capa común.

Aquí son comunes la identidad, la versión terminológica, el ciclo de vida de la asignación, la función de delegación, la cláusula aplicable y la transición registrada. Las pruebas de acuerdo y autoridad pueden permanecer protegidas. Los agregados pueden revelar correcciones sin exponer clientes.

El modelo empresarial es local. ARIN no necesita decidir cuánto ingreso procede de web hosting, cómo se empaqueta el VPN, qué hipervisor aloja un VPS ni qué fabricante sirve una sala. Sólo una relación explícita con un predicado de recursos justifica preguntar por el hecho correspondiente.

Una especificación mínima no es una especificación blanda. Cuanto menos intenta gobernar la empresa, más estricta puede ser respecto del dato que coordina.

Fuentes

Lo que las fuentes no prueban

Ninguna fuente identifica una organización real que ARIN haya clasificado mal por estos términos. No hay cifras de tickets, demora, rechazo, variación de tamaño o disparidad entre analistas. Tampoco se publican aquí los campos actuales de la aplicación, la formación interna o toda la lógica de clasificación.

La evidencia respalda una observación textual y la recomendación de una memoria versionada. No respalda una acusación de conducta ni una estimación de incidencia.

Tampoco predice el destino del borrador. El rastreador independiente clasifica ARIN-2025-1 como Draft Policy. Una versión nueva puede restaurar el enlace entre conjuntos, retirar la relación, escoger sólo LIR o rehacer las definiciones. Una evaluación de ese nuevo objeto sería un hecho posterior.