Summary

  • A seção 3.7 da política vigente da ARIN exige que o destinatário de reatribuição detalhada ou realocação já exista no banco da entidade e tenha ao menos um Point of Contact validado. Sem contato validado, a ARIN deve rejeitar o pedido. A reatribuição simples não estabelece vínculo com esses objetos.
  • Segundo a orientação oficial de gestão de registros, a modalidade simples usa um nome de cliente digitado livremente e não verificado; o titular direto mantém a capacidade de alterar ou apagar o registro. As modalidades detalhada e de realocação exigem Org ID e acordo de serviços e concedem poderes diferentes ao destinatário.
  • O modelo de mensagem de rejeição manda o cliente validar um contato e procurar o provedor para que ele tente novamente. O documento registra uma falha na transação de cadastro e não traz medição de tráfego.

A orientação da ARIN chama o nome do cliente numa reatribuição simples de texto livre. O provedor direto informa que parte de seu espaço está em uso por outra entidade, mas a ARIN não verifica o nome inserido. O cliente listado não consegue gerenciar o bloco por essa ficha. O provedor pode modificá-la ou removê-la quando quiser. Há um nome na base pública e uma única mão na caneta.

Na reatribuição detalhada, a distribuição de poderes muda. O cliente precisa de um Organization Identifier, ou Org ID, e de um Registration Services Agreement. Passa então a poder incluir contatos e administrar os endereços recebidos no ARIN Online. Cliente e provedor podem trabalhar em objetos do registro de roteamento e no DNS reverso.

O provedor direto ainda pode retomar a reatribuição. O cliente ganha comandos reais dentro de uma relação que a operadora de origem conserva o poder de recolher.

A realocação serve ao destinatário que pretende distribuir partes do bloco a clientes próprios. Também requer Org ID e acordo com a ARIN. Esse destinatário pode criar registros posteriores de reatribuição e realocação. A operadora direta mantém a possibilidade de retomar o registro. As três modalidades formam uma escala: o nome escrito pelo provedor, o cliente com gerenciamento próprio e o cliente que consegue registrar uma cadeia de destinatários. Mais autonomia no cadastro exige identidade mais estruturada.

O portão aparece com clareza na seção 3.7 do manual de políticas. Para reatribuições detalhadas e realocações, a organização receptora deve estar no banco da ARIN e vinculada a pelo menos um contato validado. Na ausência dele, a ARIN rejeita o pedido. O mesmo dispositivo ressalva que a reatribuição simples não se liga a objetos de organização ou de contato na base. Um mesmo cliente pode usar endereços do mesmo provedor, mas a natureza do registro determina se ele possui uma posição ativa no sistema.

O guia de comunicação de reatribuições explica as razões técnicas para escolher a via detalhada. Um cliente que queira manter sua própria delegação de DNS reverso ou exibir pontos de contato separados precisa dessa modalidade. Quem pretende subdividir endereços entre clientes próprios entra na realocação. O atalho da modalidade simples pode registrar o uso, mas deixa essas funções com o provedor. A economia de um passo burocrático pode custar a autonomia que motivou a delegação.

A ARIN também publicou o texto enviado quando o pedido falha. Seus modelos de status informam que o Org ID receptor não possui POC validado e que a reatribuição não foi processada. A mensagem ao cliente o orienta a entrar no ARIN Online, validar o contato e avisar ao provedor. A mensagem ao provedor manda solicitar a validação ao cliente e reenviar o pedido. O provedor inicia a operação, o cliente conserta a identidade cadastral e o provedor tenta de novo. São ações distribuídas por duas organizações.

Essa condição tem um calendário próprio. A seção 3.6 prevê aviso anual aos contatos e prazo de até sessenta dias para confirmar ou corrigir seus dados Whois. Após análise cuidadosa, funcionários da ARIN podem marcar como inválido um contato completamente e permanentemente abandonado ou de outro modo ilegítimo. O texto não determina invalidação automática pelo mero fim do prazo. Um POC inválido fica limitado a pagamentos e atualizações de contato no ARIN Online. Uma organização sem POC válido perde as demais funções até que um contato administrativo ou técnico valide ou corrija os dados.

O provedor não pode criar sozinho a identidade que falta. Pela seção 3.8, a ARIN cria uma organização mediante solicitação direta de representante autorizado de entidade que possa validar; pedidos de terceiros não bastam. A regra impede que uma operadora fabrique o destinatário de um bloco.

Ao mesmo tempo, obriga o cliente legítimo a participar da etapa cadastral antes de receber acesso às funções que o contrato comercial pode ter prometido.

As fontes oficiais consultadas não incluem um caso de cliente datado para medir quanto tempo esse portão atrasou uma reatribuição. Uma notificação de rejeição com o respectivo reenvio permitiria medir um episódio.

A política e os modelos já mostram o desenho do poder: a ARIN aceita o nome do cliente enquanto o provedor segura a ficha; quando o cliente quer segurá-la também, é preciso apresentar organização e contato verificados.