Resumo

  • O AFPUB-2019-v4-001-DRAFT01, versão 1.0, foi apresentado por Jordi Palet Martinez em 13 de maio de 2019 e permaneceu “Under discussion”. Sua finalidade declarada era criar um caminho para transferências IPv4 legadas intra-RIR e inter-RIR sem perder a história registral.
  • A parte sólida da proposta era a manutenção do registro: confirmar o titular atual reconhecido pelo RIR pertinente, verificar se havia disputa sobre o recurso, coordenar a mudança entre registros e publicar uma atualização coerente. Sem essas etapas, um pedido falso ou uma movimentação fora do processo poderia deixar controle, roteamento e registro apontando para realidades diferentes.
  • A dificuldade começava quando a atualização vinha acompanhada de consequências distintas: demonstração de necessidade para o destinatário na região da AFRINIC, adesão às políticas e aos documentos jurídicos ou acordos de serviço do RIR pertinente e perda expressa do caráter legado em transferências intra-AFRINIC e nas entradas inter-RIR. O texto de 13 de maio não definiu o status resultante de uma saída inter-RIR.
  • O Draft 1 não criou uma tarifa. A referência tarifária disponível vinha do guia de transferências com base de fevereiro de 2018: o cedente legado que não fosse membro não pagava tarifa de transferência, enquanto o destinatário assumia cobranças aplicáveis de associação e de alocação ou designação.
  • A proposta não obteve consenso na AFRINIC-30, em 19 de junho de 2019. A seção datada de 20 de julho na página oficial registra uma compreensão posterior da equipe, não a redação do autor em 13 de maio. Não há prova de adoção, implementação ou transferência concluída sob esse Draft 1.
  • A fronteira institucional é clara: a AFRINIC pode prestar um serviço privado de autenticação, coordenação e manutenção de registros, além de recuperar custos transparentes. Não pode converter esse serviço em poder soberano, regulatório, policial, punitivo, confiscatório ou adjudicativo, nem tratar a atualização do livro como consentimento automático a um novo contrato ou à extinção de um status histórico.

L3 — O registro que chegou sem contrato

O problema começa antes da transferência. Parte do espaço IPv4 chamado de legado foi distribuída antes de o sistema contemporâneo de Registros Regionais da Internet assumir sua forma atual. A AFRINIC informou que recebeu de RIPE NCC, ARIN e APNIC registros referentes a organizações situadas em sua região de serviços. Também reconheceu uma característica decisiva: mantinha esses registros sem que houvesse uma relação contratual ordinária entre ela e os respectivos titulares legados.

O banco de dados, portanto, continha informações indispensáveis à coordenação da Internet, mas sua existência não era produto de um acordo de serviço comum firmado pelo titular com a AFRINIC.

Essa condição não tornava o registro dispensável. Ao contrário, fazia com que uma alteração exigisse cuidado redobrado. Uma linha herdada pode estar correta, desatualizada ou ser alvo de pedidos concorrentes. Se alguém solicitar a troca dos dados de uma organização ou de um recurso, a administradora do registro não deve aceitar a mera afirmação de que houve uma venda, uma reorganização ou uma cessão.

A orientação da própria AFRINIC para titulares legados diz que a organização exige prova de titularidade antes de efetuar uma atualização de WHOIS e modifica os dados da organização e do recurso depois de concluir que o solicitante tem legitimidade para pedir a mudança. Essa é uma função necessária: impedir que um formulário, um documento insuficiente ou uma identidade falsificada desloque quem consta no registro.

Também existe uma razão operacional para registrar uma transferência autêntica. O controle comercial pode mudar enquanto o livro continua no passado. Nesse intervalo, o destinatário pode enfrentar dificuldade para demonstrar sua posição a redes, prestadores e contrapartes; o cedente pode continuar aparecendo como contato; a delegação de DNS reverso pode não acompanhar a mudança; sistemas de segurança e diligência podem encontrar sinais incompatíveis; e uma futura transação pode começar com uma cadeia documental incompleta.

O registro não cria o negócio subjacente, mas um registro desatualizado aumenta o custo de distinguir um negócio verdadeiro de uma fraude.

Foi nesse espaço que surgiu o IPv4 Inter-RIR Legacy Resource Transfers. A página oficial identifica o documento como AFPUB-2019-v4-001-DRAFT01, versão 1.0, de Jordi Palet Martinez, apresentado em 13 de maio de 2019. Seu status era “Under discussion”, e sua proposta era alterar o artigo 5.7 do Consolidated Policy Manual. O diagnóstico do documento era que não havia na AFRINIC um mecanismo inter-RIR para a transferência de IPv4 legado, embora existisse um mercado. Segundo a justificativa apresentada, movimentações ocorridas fora de um procedimento registral poderiam romper a história da inscrição.

O Draft 1 reconhecia duas formas de transferência. A intra-RIR abrangia situações em que fonte e destinatário estavam na região de serviços da AFRINIC. A inter-RIR abrangia situações em que uma parte estava nessa região e a outra estava na região de outro RIR. Essa distinção geográfica determinava quais registros teriam de coordenar o reconhecimento da fonte, a elegibilidade do destinatário e a atualização dos respectivos dados.

O desenho era assimétrico quanto ao que poderia sair ou entrar. Quando a fonte estivesse na região da AFRINIC e o destinatário na região de outro RIR, somente recursos IPv4 legados poderiam sair. O texto não aplicava a mesma limitação de “somente legado” aos recursos que entrassem na região da AFRINIC. A ata da AFRINIC-30 resumiu a proposta nessa direção: qualquer tipo de IPv4 poderia entrar, mas apenas IPv4 legado poderia deixar a região por esse caminho. A assimetria era parte do Draft 1 e não deve ser convertida em uma regra geral sobre toda transferência ou em uma descrição de outro documento apresentado no mesmo período.

Na ponta da fonte, havia dois controles centrais. Primeiro, a fonte deveria ser o titular legítimo atual reconhecido pelo RIR pertinente. Segundo, não poderia estar envolvida em disputa relativa ao status do recurso. Essas exigências procuravam impedir que o livro fosse alterado em favor de alguém sem posição reconhecível ou durante um conflito que tornasse o pedido contestado. O registro precisava saber quem estava pedindo, em que documentos o pedido se apoiava e se existia uma reivindicação conflitante que recomendasse não executar uma mudança administrativa naquele momento.

A expressão “titular legítimo reconhecido”, porém, descreve um requisito de processamento, não uma sentença universal sobre propriedade. Um RIR pode conferir os documentos disponíveis, comparar a identidade do solicitante com o registro e recusar uma alteração quando houver conflito material. Isso não transforma a instituição em tribunal, nem faz de seu reconhecimento a origem da posição privada das partes. O Draft 1 não resolveu se IPv4 constitui propriedade em qualquer jurisdição e não decidiu uma disputa de venda ou de título. A prova disponível tampouco contém decisão judicial sobre esse tema.

O texto manteve uma restrição de doze meses depois da transferência: a fonte não estaria apta a receber novas alocações ou designações de IPv4 da AFRINIC durante esse período. Ao mesmo tempo, a coluna proposta omitia a restrição então existente relativa ao recebimento de recursos nos doze meses anteriores à transferência. Essa mudança pertence ao conteúdo específico do Draft 1. Ela não autoriza inferir que a proposta tenha entrado em vigor, que alguém tenha sido atingido pela restrição posterior ou que a omissão tenha produzido um efeito prático.

Na ponta do destinatário, o documento criava outra camada de avaliação. Se o destinatário estivesse na região da AFRINIC, deveria demonstrar necessidade de IPv4 segundo as políticas existentes e obter aprovação da AFRINIC. Se estivesse na região de outro RIR, as políticas do RIR de destino forneceriam o critério aplicável. Além disso, o destinatário deveria ser membro do RIR pertinente e ficar sujeito às políticas e aos documentos jurídicos ou acordos de serviço desse RIR.

Essas condições misturavam questões que precisam permanecer analiticamente separadas. Uma delas é se o destinatário foi identificado corretamente e se o registro de destino pode receber a inscrição sem duplicidade. Outra é se ele deseja contratar serviços continuados, em quais termos e por qual preço. Uma terceira é se uma regra de necessidade deve poder impedir a transferência depois de fonte e destinatário terem chegado a um acordo. A primeira questão protege a exatidão do livro. As duas seguintes alteram a posição econômica ou contratual do destinatário e não são consequências lógicas da mera constatação de que o controle mudou.

O ponto mais sensível estava na condição histórica do recurso. O Draft 1 dizia expressamente que o IPv4 legado deixaria de ser considerado legado em duas situações: na transferência intra-RIR e na transferência inter-RIR que entrasse na região de serviços da AFRINIC. O texto de 13 de maio não dizia qual seria o status resultante do recurso legado que saísse da região em uma transferência inter-RIR. Essa ausência deve ser preservada. Não é correto completar o silêncio com uma regra posterior, com a preferência de outro RIR ou com uma suposição de que toda transferência eliminaria automaticamente o caráter legado.

A perda de status não é apenas uma mudança de rótulo. O caráter legado aponta para a origem histórica do registro e para o fato de que o titular não entrou pela cadeia contratual comum da AFRINIC. Se uma transferência faz essa informação desaparecer ou a converte em uma posição contratual moderna, ela pode alterar expectativas sobre cobrança, acesso a serviços, obrigações documentais e poder de negociação. Mesmo quando o destinatário voluntariamente deseja um acordo de serviço, é necessário distinguir sua escolha de contratar da obrigação da administradora de manter um registro verdadeiro.

A tarifa é outra superfície que exige precisão. O Draft 1 não criou, fixou nem cobrou tarifa de transferência. A referência disponível vinha do guia de transferências da AFRINIC, identificado com uma base de fevereiro de 2018. Nesse guia, uma fonte de transferência que fosse titular legado e não membro não pagava tarifa de transferência. Um destinatário que se tornasse novo membro pagava a associação anual e uma cobrança única aplicável à alocação ou designação; um destinatário que já fosse membro pagava a cobrança única aplicável e precisava permanecer em situação regular.

Trata-se do contexto do serviço, não de uma disposição nova do Draft 1.

Essa separação de origem é importante por duas razões. Primeiro, atribuir a cobrança ao documento de maio seria inventar conteúdo. Segundo, a assimetria do guia oferece uma leitura administrativa plausível: não onerar o cedente legado que está fora do contrato pode facilitar a entrada de uma mudança histórica no processo oficial, enquanto a parte que recebe serviços continuados arca com cobranças pertinentes. Mas o material disponível não contém um estudo de custos, não demonstra que cada valor correspondia ao custo de processamento e não mede se a estrutura incentivou ou desestimulou registros.

É possível avaliar o princípio sem alegar um resultado que não foi observado.

O percurso público do Draft 1 foi curto e inconclusivo. Em 19 de junho de 2019, na AFRINIC-30, ele foi discutido ao lado de uma proposta separada de escopo abrangente. A ata registra que o autor descreveu a diferença de conteúdo entre as duas como uma frase. Essa proximidade não permite fundi-las: o objeto aqui é somente o AFPUB-2019-v4-001-DRAFT01, voltado ao recorte legado. Houve objeções durante a sessão, e os copresidentes concluíram que não havia consenso, devolvendo as duas propostas à discussão na lista.

“Sem consenso” significa precisamente que o Draft 1 não atravessou naquele encontro nem mesmo o limiar interno do processo privado da AFRINIC. Não significa que uma lei foi rejeitada, porque o processo não possuía poder legislativo público. Também não prova que uma versão tenha sido implementada por outro caminho. A página oficial conserva o status “Under discussion”, uma única entrada no histórico de revisões e uma última modificação registrada em 3 de dezembro. Nada disso demonstra adoção, operação ou uma transferência executada sob suas cláusulas.

Na mesma página oficial aparece uma avaliação da equipe datada de 20 de julho. Ela deve ser lida como compreensão posterior da equipe da AFRINIC. Não é a voz de Jordi Palet Martinez em 13 de maio, nem parte da redação original apenas por estar na mesma página. A equipe entendeu que o espaço legado transferido passaria a um RSA e perderia o status legado; também indicou questões de implementação. A seção não registrava comentários de assessor jurídico.

Essa compreensão ajuda a enxergar como a instituição interpretava as consequências do texto, mas não pode preencher retroativamente o silêncio sobre a saída inter-RIR nem adquirir a força de um parecer judicial.

O que sabemos, portanto, é delimitado. Sabemos a identidade, a data, o autor e o status do Draft 1. Sabemos quais transferências ele descrevia, quais verificações exigia, quais condições aplicava ao destinatário e em quais direções declarava a perda do status legado. Sabemos que não houve consenso em 19 de junho e que a equipe publicou uma leitura em 20 de julho. Sabemos também que a AFRINIC mantinha registros legados sem contrato ordinário e tinha uma prática de pedir prova antes de atualizá-los.

Não sabemos se um titular legado solicitou ou concluiu uma operação sob o texto não adotado. Não temos número de transações fora do registro, preço de mercado, volume, perda mensurável de liquidez ou impacto comprovado sobre uma empresa. As afirmações do autor sobre compatibilidade com LACNIC, RIPE, APNIC e ARIN eram afirmações da proposta: ela dizia que haveria transferências bidirecionais com LACNIC e RIPE, intercâmbios apenas de legado com APNIC e nenhuma troca com ARIN por causa da redação de reciprocidade.

Esses pontos não foram confirmados de forma independente no recorte disponível e não devem ser apresentados como decisões finais de cada RIR.

Ainda assim, o caso não é abstrato. Um titular precisa impedir que um terceiro altere seu registro e, ao mesmo tempo, não deveria ter de renunciar silenciosamente à sua posição histórica para manter o livro correto. Um destinatário precisa de uma cadeia de controle verificável e de dados que possam ser usados por redes e prestadores, mas também precisa saber se está comprando um recurso, contratando um serviço, submetendo-se a uma avaliação de necessidade ou fazendo tudo isso em negócios distintos.

Um operador precisa confiar que WHOIS, DNS reverso e contatos correspondem à realidade, sem depender de uma instituição que possa mudar condições fundamentais cada vez que o registro precisa ser corrigido.

O mérito inicial do Draft 1 foi tornar visível esse conjunto de dependências. Seu limite foi tratar algumas delas como se pertencessem ao mesmo ato. A passagem seguinte separa as cinco superfícies — autenticação, disputa, coordenação, tarifa e consequência contratual — para mostrar quais sustentam um livro confiável e quais exigem uma justificativa e um consentimento próprios.