Resumo
- A Draft Policy ARIN-2025-1 declara que todos os Internet Service Providers são Local Internet Registries, mas nem todo LIR é ISP. A definição proposta de LIR exige função de Internet Registry, associação a um RIR, recebimento de alocações e distribuição de números para clientes, usuários finais e infraestrutura.
- Já a definição de ISP requer somente a oferta de serviços de Internet a pessoas externas à organização. Conectividade, serviços web, colocation, servidores dedicados, VPS e VPN não demonstram, por si, nenhuma das funções de registro necessárias para a inclusão declarada.
- A correção pode preservar a autonomia empresarial: cada classificação deve registrar versão do vocabulário, ciclo de vida do recurso, função de delegação e cláusula aplicável, enquanto uma matriz protegida acompanha cada troca relevante de ISP por LIR.
Duas fichas que não se encaixam sozinhas
No caso mais conhecido, ISP e LIR parecem duas maneiras de olhar para a mesma organização. Uma operadora vende conectividade, recebe um bloco diretamente, distribui partes dele a clientes e registra essas distribuições. A atividade comercial e a função sobre recursos numéricos coincidem.
Uma definição pública, porém, precisa funcionar nas bordas. Um provedor de aplicações web pode usar exclusivamente endereços recebidos de seu upstream. Uma universidade pode receber uma alocação e distribuí-la entre unidades e usuários vinculados sem vender acesso ao varejo. Um grupo empresarial pode exercer uma função de registro para afiliadas sem adotar ISP como identidade comercial.
O rastreador independente da NOG Alliance classifica a ARIN-2025-1 como Draft Policy e registra 13 de agosto de 2026 como a mudança mais recente. O projeto começa com uma lacuna real: LIR está definido, enquanto ISP permanece implícito. Em seguida, o enunciado estabelece uma relação precisa. Por implicação e pela prática comercial comum, todos os ISPs seriam LIRs, embora nem todos os LIRs fossem ISPs.
Isso não significa apenas que os grupos costumam se sobrepor. Significa que todo membro do conjunto ISP também pertence ao conjunto LIR. Uma lista de operadoras conhecidas no centro da interseção não prova o que acontece com todos os casos de fronteira.
A comunidade pode escolher essa hierarquia. Para que a mudança seja uma clarificação, as condições escritas precisam tornar a hierarquia verificável por quem não conhece a prática informal da ARIN.
LIR descreve a cadeia do recurso
O texto preservado em um arquivo independente da PPML de março de 2026 dá vários elos ao LIR. Ele é um Internet Registry, integra um RIR, recebe desse RIR alocações de números de Internet e os aloca para clientes, usuários finais e infraestrutura.
Cada elemento fala de uma relação com o recurso. O recebimento é um evento do ciclo de vida; a distribuição a jusante e seu registro são funções distintas. Os exemplos também vão além da operadora de varejo: incluem grandes empresas, universidades e ISPs.
A mesma mensagem arquivada revela o alcance da migração: títulos e cláusulas operacionais passariam de ISP para LIR, enquanto a cláusula terminológica trataria ISP como subconjunto de LIR. Não é uma nota de glossário, mas uma troca de papel em alocação, reatribuição, utilização e deveres para clientes downstream.
O arquivo comprova o texto distribuído, não sua autoridade. O rastreador comprova apenas o limite posterior de versão e o estado. O registro editorial precisa manter os dois: o objeto exato analisado e a versão mais recente cujo texto integral deve ser revisto antes da implementação.
ISP descreve uma atividade de mercado
A definição proposta de ISP parte de outro eixo. ISP é a organização que presta serviços de Internet a organizações, clientes ou indivíduos que não sejam seus empregados. Os exemplos abrangem conectividade, serviços web, colocation, servidores dedicados, servidores privados virtuais e redes privadas virtuais.
Nenhuma frase exige que o ISP seja Internet Registry. Não há requisito de alocação direta recebida de um RIR, de vínculo associativo específico nem de realocação ou reatribuição de recursos a clientes.
A ambiguidade aparece em um debate da PPML preservado de forma independente. Um participante cita um guia que resume LIR como ISP e, ao mesmo tempo, uma definição em que LIRs são apenas “em geral” ISPs; pergunta então se as categorias são idênticas, aninhadas ou opcionais para titulares de direct allocation. O arquivo comprova que a dúvida foi expressa, não como a equipe decidiria um pedido específico.
A sequência revela a ponte que falta. O nome do serviço pode indicar qual porta merece inspeção. Não satisfaz automaticamente o teste que existe depois da porta. Vender VPN não equivale a receber uma alocação de RIR. Operar servidores dedicados não prova que a empresa registra distribuições de recursos numéricos a terceiros.
Há mais de uma solução coerente. ISP pode voltar a ser definido como um tipo de LIR. A definição de serviço pode ser limitada a quem exerce uma função qualificada de distribuição. Os conjuntos podem ser descritos como sobrepostos, sem inclusão total. Ou ISP pode sair das cláusulas normativas, que passariam a depender diretamente do uso e da delegação do recurso.
O ponto não é impor uma opção. É impedir que cada leitor precise adivinhar qual delas foi escolhida.
A implicação ausente
Cinco predicados analíticos expõem o problema. Eles não são terminologia da ARIN nem proposta de esquema de dados.
Seja IR(x) a afirmação de que a organização x distribui recursos numéricos e registra as distribuições. Seja M(x) a relação especificada de associação ao RIR, A(x) o recebimento de uma alocação desse RIR, D(x) a alocação ou delegação a terceiros e S(x) a prestação externa de pelo menos um serviço listado.
A definição proposta permite ler LIR(x) = IR(x) ∧ M(x) ∧ A(x) ∧ D(x). Para o ISP, a leitura é ISP(x) = S(x).
Para que todo ISP seja LIR, o texto precisa da implicação S(x) → IR(x) ∧ M(x) ∧ A(x) ∧ D(x). Ela não aparece.
Esse exercício não prova um erro operacional da ARIN. Políticas públicas têm contexto, outras cláusulas de qualificação e interpretação de equipe. Ele sustenta uma conclusão mais estreita: a relação de subconjunto não pode ser derivada apenas das duas definições publicadas no projeto.
Um provedor fictício na fronteira
Considere uma empresa inventada que vende serviço web gerenciado e acesso VPN. Todos os seus endereços vêm de uma operadora upstream. Ela não possui alocação direta do RIR nem distribui e registra recursos numéricos para clientes como Internet Registry.
Trata-se de um teste lógico sintético. Não é uma operadora identificada, uma solicitação real nem um relato sobre a conduta da equipe da ARIN.
A empresa satisfaz o predicado público de ISP: oferece a terceiros dois dos serviços listados. Ela não satisfaz ao menos os predicados de alocação direta e de distribuição a jusante da definição de LIR. Dependendo do significado pretendido de member of an RIR, pode falhar também nesse ponto.
Chamá-la de ISP pode ser perfeitamente normal no mercado. Encaminhá-la ao guia para ISPs também pode ser útil, pois o guia permite investigar se futuras atribuições a clientes justificariam uma alocação direta. O encaminhamento, porém, não cria retroativamente uma alocação nem converte o uso de espaço upstream em função registral.
Um caso de fronteira não é uma armadilha semântica. É o ensaio mais barato para saber se a definição transporta a relação que seus autores pretendem.
Função de recurso e rótulo empresarial seguem eixos distintos
RFC 7020 descreve o sistema de registros de números como uma hierarquia em que registros alocam recursos a clientes e LIRs são tipicamente ISPs. “Tipicamente” descreve uma relação recorrente; não cria identidade entre um papel registral e toda empresa que vende serviço de Internet.
No eixo de recursos há solicitante, titular direto, distribuidor downstream, end user e usuário de espaço upstream. No eixo de serviços há conectividade, hospedagem, colocation e VPN. A classificação pode consultar ambos, mas deve declarar qual combinação aciona o papel normativo.
Uma definição alternativa sugerida na PPML tornou a escolha explícita: ligou LIR ao sistema da RFC 7020 e tratou consumo e justificativa de recursos para clientes como traço importante de ISP. Era uma proposta de participante, não texto adotado. Seu valor é diagnóstico: quando a função pretendida é conhecida, a ponte cabe em uma frase.
Se member of an RIR permanecer como condição de LIR, será preciso nomear a relação exata e o momento do ciclo em que ela é testada. Um serviço comercial não cria esse estado por implicação, nem uma relação de recursos deve ser inferida de uma marca empresarial.
A história administrativa manteve os papéis separados
RFC 2901, guia informativo de 2000, encaminhava organizações a materiais diferentes conforme obtivessem e usassem endereços. É história e não define requisitos atuais da ARIN. Mas preserva um ponto analítico: ISP há muito serve como rótulo de caminho de solicitação, enquanto LIR pertence à hierarquia registral.
As palavras podem convergir na conversa e os procedimentos continuarem perguntando fatos distintos. O fato comum útil não é o substantivo preferido pela empresa, mas a função do recurso que seleciona uma regra em determinada versão e data.
O debate público já encontrou a ponte fraca
O debate arquivado não tratou apenas de estilo. Uma resposta de março de 2026 concordou que a frase proposta para LIR estava gramaticalmente incompleta e questionou at a local level, pois alguns LIRs operam além de uma única região de RIR. A mesma mensagem reproduziu a definição de ISP baseada em serviços.
A resposta não decide a política nem registra uma implementação. Mostra que os participantes já testavam os predicados e seu alcance antes do limite de versão de 13 de agosto. O achado deste artigo não é uma acusação escondida, mas uma pergunta textual reproduzível que uma versão posterior pode resolver.
Terminologia é estado distribuído. Uma definição chega a títulos, guias, instruções, treinamento e campos de aplicação. A versão posterior precisa ser examinada como objeto novo, não como continuação silenciosa do texto arquivado em março.
Uma matriz mínima de papel e predicado
Corrigir a lacuna não exige que a ARIN inventarie tudo o que uma empresa vende. Exige um registro pequeno e protegido que ligue a decisão de papel à regra e à função real do recurso.
Dezesseis campos bastam para uma matriz inicial e um manifesto de migração.
- Identidade da organização e do Org ID. Registre a entidade jurídica e registral usada na classificação, com o limite temporal relevante.
- Identidade da solicitação ou decisão. Dê ao caso uma chave estável, horário de envio e ligações explícitas para revisões ou pedidos substitutos.
- Versão e vigência do vocabulário. Fixe o NRPM, projeto ou implementação que definiu ISP, LIR, IR, end user e delegação.
- Finalidade da classificação. Declare qual decisão de política está sendo testada; um rótulo comercial universal não deve decidir ações sem relação entre si.
- Predicado do serviço comercial. Registre apenas a classe externa necessária, sem importar para a política todo o catálogo privado da empresa.
- Predicado de Internet Registry. Indique se a organização distribui recursos numéricos e registra essas distribuições, com referência protegida à evidência.
- Estado da alocação direta. Distinga inexistente, solicitada, aprovada, emitida, devolvida, revogada e substituída, vinculando o estado ao evento do recurso.
- Função de delegação a jusante. Registre realocação ou reatribuição, a classe de destinatário e a cláusula controladora.
- Uso em infraestrutura interna. Mantenha o uso próprio delimitado separado da distribuição a clientes.
- Estado de membership. Registre solicitante não membro, Service, General, General in Good Standing ou Trustee sob a regra pertinente; nunca infira poder de voto a partir do papel sobre o recurso.
- Estado de acordo e autoridade. Vincule a cobertura por RSA ou LRSA e a autoridade organizacional à evidência protegida, sem publicar os documentos de autorização.
- Caminho de política aplicável. Nomeie as cláusulas, os testes de qualificação e as exclusões escolhidas pela função verificada.
- Correspondência das ocorrências de termos. Para cada uso consequente, guarde termo antigo, termo novo, seção, superfície e um código delimitado de efeito semântico.
- Vínculo de implementação. Ligue o significado da política às versões correspondentes do guia público, orientação interna, treinamento, campo do formulário e vetor de teste.
- Resultado, explicação e correção. Preserve os predicados decisivos, resultado, caminho de revisão, mudança posterior de papel e histórico de correções.
- Projeção agregada com privacidade. Publique contagens de caminhos, mudanças de classificação, divergências de versão de formulário e correções sem nomes de solicitantes ou segredos de produto.
Não se trata de impor um esquema de banco de dados. É a informação mínima que permite a outro revisor reproduzir por que determinado caminho de política foi aplicado.
A camada comum deve conhecer a função, não desenhar a empresa
A fronteira da Minimum Initial Specification serve para este caso. A coordenação compartilhada deve ser rigorosa quanto aos fatos determinísticos necessários à unicidade, interoperabilidade, prova, segurança e proteção. Arranjos comerciais, ambição institucional e preferências discricionárias permanecem locais.
Aqui, os fatos comuns são identidade organizacional, versão do vocabulário, ciclo de vida do recurso, função de delegação, regra aplicável e transição de estado registrada. Evidência protegida pode provar acordo e autoridade. Uma projeção pública agregada pode mostrar quantas vezes o caminho mudou ou a versão do formulário divergiu.
A composição do produto continua local. A ARIN não precisa decidir se hospedagem web é o negócio principal, se VPN vem no pacote de conectividade, qual hipervisor executa o VPS, qual roteador atende o colocation ou como uma universidade organiza seus departamentos. Esses fatos só entram quando um predicado nomeado os torna necessários.
Mínimo não quer dizer vago. Uma definição que reivindica menor jurisdição sobre a empresa deve ser mais exata justamente quanto ao pouco que escolhe compartilhar.
Fontes
- NOG Alliance: acompanhamento das propostas dos RIRs
- Mail-Archive: distribuição de março de 2026 do texto revisto da ARIN-2025-1
- Mail-Archive: debate sobre a ambiguidade do guia de solicitações
- RFC 7020: The Internet Numbers Registry System
- Mail-Archive: definições alternativas sugeridas na PPML
- RFC 2901: Guide to Administrative Procedures of the Internet Infrastructure
- Mail-Archive: crítica de março de 2026 aos predicados e ao escopo
- Lu Heng: Minimum Initial Specification, Localized Future Decision and Voluntary Adoption
O que a evidência não demonstra
Nenhuma fonte deste pacote identifica uma organização real que tenha sido colocada pela ARIN no caminho errado devido à terminologia ISP/LIR. Não há medição de chamados extras, demora, indeferimentos ou mudança no tamanho de uma alocação. Os campos internos atuais, o treinamento e toda a lógica de classificação também não estão expostos.
A evidência sustenta, portanto, uma constatação textual e uma recomendação de migração. Não sustenta acusação de conduta imprópria nem estimativa de incidência.
Tampouco prevê o resultado do processo. O rastreador independente classifica a ARIN-2025-1 como Draft Policy. Uma nova versão pode restaurar o vínculo direto, eliminar a afirmação de subconjunto, adotar somente LIR ou redesenhar as definições. Uma análise do novo objeto seria fato novo, não confirmação da inferência presente.
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
