Resumo

  • A tabela de compatibilidade vinculada ao Draft 2 registrou quatro desencontros concretos: ARIN e APNIC rejeitaram a obrigação imposta ao titular de origem, RIPE NCC rejeitou o ponto de início do pedido, e LACNIC, embora não exigisse reciprocidade, apontou os dois problemas.
  • O instrumento examinado é AFPUB-2019-V4-003-DRAFT02, apresentado em 13 de agosto de 2020. A data de 8 de outubro de 2021 pertence a AFPUB-2020-GEN-006-DRAFT02, uma proposta distinta, e não pode ser usada para recontar a história do Draft 2.
  • O texto foi proposto, debatido, avaliado e depois arquivado. Consenso aproximado condicional e last call foram etapas do processo privado de elaboração; não equivaleram a adoção no CPM, ratificação ou implementação operacional.
  • A AFRINIC podia autenticar registros sob sua guarda e coordenar uma mudança compatível. Não podia dispensar uma regra da ARIN, APNIC, RIPE NCC ou LACNIC, nem transformar discricionariedade administrativa em uma porta de saída para redes.
  • A alternativa prática seria um certificado de compatibilidade preso à versão: direção, tipo e situação do recurso, responsável por cada autenticação, ponto de início, mensagens, atualização atômica dos registros, serviços dependentes, reversão e confirmação datada de cada contraparte.

L3 — Quatro trilhos receptores que não se encaixavam

Uma tabela, quatro recusas de encaixe

Imagine uma faixa de transferência anunciada como bidirecional. Do lado da AFRINIC, o texto parece permitir a passagem. No encontro com os demais registros, porém, quatro peças não se acoplam. ARIN e APNIC leem a mesma frase e concluem que ela não é compatível com seus arranjos: o titular de origem seria obrigado a cumprir a política do registro receptor. RIPE NCC olha para a sequência operacional e encontra outro defeito: o Draft 2 manda a parte transferidora começar o pedido no registro receptor, enquanto o procedimento da RIPE começa no registro onde o recurso já está registrado.

LACNIC não exige reciprocidade, mas ainda assim considera sem sentido a obrigação dirigida à origem e observa que esse ponto de partida não coincide com os demais arranjos inter-RIR.

Essa tabela externa é a abertura adequada porque troca uma abstração sedutora — “permitir transferências” — por quatro testes de execução. Nenhuma dessas respostas afirma que uma autoridade pública proibiu uma transação. Nenhuma entrega à administração da AFRINIC o poder de abrir a passagem por exceção. Elas descrevem registros privados tentando saber se conseguem produzir, juntos, uma única alteração reconhecida, sem duplicar o recurso, perder a trilha de autenticação ou deixar duas bases em estados incompatíveis.

A conclusão precisa ficar vinculada ao objeto testado. Trata-se da proposta Resource Transfer Policy, versão 2.0, identificada como AFPUB-2019-V4-003-DRAFT02 e apresentada em 13 de agosto de 2020 para alterar a seção 5.7 do Consolidated Policy Manual. Há um erro de junção em um registro de planejamento que associa a esse identificador a data de 8 de outubro de 2021. Essa data pertence a AFPUB-2020-GEN-006-DRAFT02, de outra linhagem. A semelhança entre títulos não autoriza misturar identificadores, datas, cláusulas ou estados. A análise aqui é do Draft 2 de 2020, não da proposta de 2021.

O cuidado não é preciosismo documental. Compatibilidade é uma propriedade de textos e procedimentos exatos. Uma palavra trocada pode mudar qual registro autentica o titular; uma frase deslocada pode mudar onde o pedido começa; uma nova versão pode resolver ou criar um conflito. Se a data errada for colada ao identificador certo, a pergunta “compatível com o quê, quando?” deixa de ter resposta auditável. A portabilidade passa a parecer uma qualidade eterna de uma família de propostas, quando na verdade cada caminho depende de uma combinação particular de versões em vigor.

O que o Draft 2 de fato propunha

O problema de origem era real. A política então descrita não oferecia um mecanismo inter-RIR de mão dupla. Sob escassez de IPv4, impedir movimento entre regiões podia restringir a capacidade de uma rede reorganizar seus recursos e de duas partes formalizarem uma transferência reconhecida. O Draft 2 tentou abrir transferências dentro da região de serviços da AFRINIC, para dentro dela e para fora dela. Seu resumo mencionava endereços IPv4 e números de sistema autônomo.

O desenho eliminava as esperas de doze meses que existiam no arranjo anterior e propunha não fixar limite superior para a quantidade transferida, alocada ou designada quando origem e destinatário tivessem acordo mútuo, sempre sob a política aplicável. Para entradas na região AFRINIC, preservava uma avaliação baseada em necessidade: a AFRINIC teria de aprovar a necessidade de IPv4 do destinatário conforme as regras em vigor. Para saídas da região, declarava que a transferência deveria seguir a política do RIR receptor.

Até aí há uma ambição reconhecível: remover uma barreira quantitativa, manter verificações relevantes e permitir que o reconhecimento acompanhe uma transação legítima. O defeito decisivo aparecia na distribuição dos deveres. O texto dizia que a origem deveria ser o atual titular dos direitos sobre recursos IPv4 registrados em qualquer RIR e cumprir as políticas do RIR receptor. Dizia também que o destinatário poderia ser qualquer parte que alcançasse um acordo de transferência com a origem. Na leitura da equipe, contudo, um destinatário na região AFRINIC precisaria ser membro da AFRINIC e passar por avaliação de necessidade.

A avaliação apontou conflito entre as cláusulas de destinatário 5.7.4.1 e 5.7.4.2.

O procedimento proposto acrescentava uma dificuldade. A parte transferidora enviaria uma solicitação ao RIR receptor, usando um modelo padronizado e um acordo oficial de transferência. Depois de aprovar o pedido, o RIR receptor notificaria o RIR transferidor, a origem e o destinatário; então os recursos seriam transferidos. A sequência parece simples apenas enquanto se ignora onde reside a informação capaz de confirmar a origem. O registro receptor não mantém necessariamente a conta, os documentos e a história registral do titular que está do outro lado.

A equipe da AFRINIC fez a pergunta direta: por que uma origem deveria cumprir a política de um RIR receptor com o qual não tinha relação? E apontou a consequência operacional: não seria possível concluir a verificação do titular de origem se ele apresentasse o pedido diretamente ao RIR receptor, em vez de começar em seu próprio RIR. Não era uma disputa semântica. Autenticar quem controla o recurso é uma condição para retirar uma inscrição de um lado e reconhecê-la do outro sem criar dois estados concorrentes.

Outros pontos permaneciam abertos. A avaliação perguntou se o modelo dito padrão era de fato aceito globalmente. Não encontrou orientação para recursos em disputa. Alertou para o risco de abuso por alocações repetidas. Registrou a contradição entre as cláusulas de destinatário. E observou que o ASN aparecia na formulação do problema, mas não nas cláusulas operativas redigidas para IPv4. Portanto, a promessa de abranger números de sistema autônomo não vinha acompanhada do mesmo caminho normativo executável.

O tratamento de recursos legados também não podia ser presumido. O Draft 2 dizia que recursos IPv4 legados transferidos deixariam de ser considerados legados. Essa alteração de situação precisava ser compatível com o registro de destino e com a sequência de atualização. Não bastava dizer que a transferência ocorreria. Era necessário saber qual estado sairia de cada base, qual entraria, em que instante e por quais mensagens aceitas entre os registros.

O desencontro visto por cada contraparte

A posição da ARIN incidia sobre uma frase determinada do Draft 2: exigir que o titular de origem cumprisse a política inter-RIR do receptor tornava o texto incompatível com o arranjo da ARIN. A resposta não concedia à AFRINIC uma escolha entre obedecer e abrir exceção. Indicava que aquela formulação não podia ser usada como interface bilateral. A AFRINIC não tinha poder para reescrever a política da ARIN em uma decisão de caso, assim como a ARIN não poderia dispensar uma condição legítima da AFRINIC.

A APNIC chegou ao mesmo ponto central. A avaliação registrou que o Draft 2 e o Draft 3 compartilhavam, nessa parte, o texto relevante, e que a obrigação imposta à origem era incompatível. Para esta análise, o alcance deve permanecer estreito: a resposta comprova o juízo sobre a redação presente no Draft 2; não autoriza extrapolar a conclusão para toda versão posterior ou para qualquer política futura. O valor da evidência está justamente em sua amarração textual.

A RIPE NCC expôs a falha de sequência. Sua avaliação considerou a seção 5.7.5 incompatível e não implementável porque o Draft 2 mandava a parte transferidora se dirigir primeiro ao RIR receptor. O procedimento da RIPE, ao contrário, começava no RIR que mantinha o registro do recurso. Há uma lógica técnica nisso: o registro de origem é quem pode conferir, em sua própria base, se o solicitante corresponde ao titular reconhecido e se o recurso está em condição de sair. Começar no outro balcão não transfere essa capacidade de autenticação.

A resposta da LACNIC é especialmente útil porque separa reciprocidade de compatibilidade. Ela não exigia reciprocidade, mas ainda assim via pouco sentido em submeter a origem à política do outro RIR e considerava o início pelo receptor desalinhado dos demais arranjos inter-RIR. Logo, remover uma exigência formal de reciprocidade não curava automaticamente o fluxo. Duas instituições podem estar abertas a cooperar e, mesmo assim, não possuir procedimentos que formem uma passagem completa.

As quatro respostas não são idênticas, e isso importa. ARIN e APNIC se concentram na cláusula de cumprimento pela origem; RIPE NCC destaca o ponto inicial e a impossibilidade de implementar aquele fluxo; LACNIC combina a ausência de exigência de reciprocidade com críticas aos dois mecanismos. Lidas juntas, elas mostram que “compatibilidade” não era um selo político binário. Era uma matriz de obrigações, mensagens, atores e ordem de execução. Uma rota podia fracassar porque o sujeito errado recebia um dever; outra, porque o pedido chegava primeiro a quem não podia verificar o recurso.

Também não se deve transformar a tabela em prova de dano ocorrido. O registro disponível não demonstra transferência concluída sob o Draft 2, recusa individual, interrupção de serviço, prejuízo de preço quantificado ou perda de cliente. Ele mostra incompatibilidades declaradas e dependências operacionais. A consequência responsável é falar em diligência adicional, atraso potencial e exposição de continuidade ou transação, não inventar um incidente de produção.

Proposta não é operação

O Draft 2 foi apresentado, debatido, avaliado e depois arquivado. Em 17 de setembro de 2020, foi apresentado na AFRINIC-32 ao lado de propostas concorrentes sobre transferências. Em 21 de setembro, um resumo dos co-chairs anunciou consenso aproximado condicional e last call, apontou uma preocupação de reciprocidade relacionada à ARIN e exigiu alterações. Esses verbos descrevem estados de um processo privado. Não provam que o texto entrou no CPM, foi ratificado pelo Board ou virou regra operacional.

Manter as distinções evita um atalho comum. “Proposto” significa que havia texto submetido. “Debatido” significa que o texto circulou e recebeu objeções. “Consenso aproximado condicional” e “last call” descrevem um momento de deliberação, ainda sujeito a condições. “Arquivado” é o estado posterior do registro dessa proposta. “Adotado”, “ratificado” e “implementado” exigiriam atos e evidências diferentes, ausentes para este Draft 2. Uma indicação interna de apoio não faz os sistemas de dois registros passarem a conversar.

Drafts 3 e 4 foram versões posteriores e pertencem a investigações próprias. A cobertura da BTW sobre o Draft 4 ajuda a demarcar esse terreno vizinho, sobretudo o debate posterior sobre evidência de versão e recurso, mas não fornece uma ponte para preencher lacunas do Draft 2. Da mesma forma, a ratificação anunciada em 4 de fevereiro de 2026 para AFPUB-2020-GEN-006-DRAFT03 pertence à linhagem separada que começou com outro identificador. Ela não ratifica retroativamente AFPUB-2019-V4-003-DRAFT02.

É possível, portanto, sustentar duas coisas ao mesmo tempo. O Draft 2 reconheceu um obstáculo relevante e tentou desenhar uma saída. Mas a faixa que oferecia não se tornou operacional apenas porque um processo comunitário interno alcançou uma etapa favorável. A prova de portabilidade teria de aparecer no encaixe datado entre textos, procedimentos e sistemas de cada par de registros.