Resumo

  • O registro oficial identifica o texto como Resource Transfer Policy Draft 3, AFPUB-2019-V4-003-DRAFT03, versão 3.0, de Anthony Ikechukwu Ubah e Taiwo Oyewande, destinado a alterar a seção 5.7 do CPM. Há uma discrepância documental limitada, mas relevante: o campo de detalhes indica submissão em 22 de setembro de 2020, enquanto o histórico de revisões data a versão 3 de 21 de setembro. Nenhuma das duas datas deve ser apagada em favor de uma certeza que os documentos não oferecem.
  • A passagem do Draft 2 para o Draft 3 teve escopo preciso. Na cláusula 5.7.3.2, a elegibilidade imediata da fonte para novas alocações ou designações da AFRINIC foi substituída por uma inelegibilidade de doze meses depois de uma transferência aprovada. Na 5.7.4.3, a perda do status legado foi revertida: recursos IPv4 legados transferidos continuariam legados. O Draft 3 não alterou a obrigação de conformidade da fonte na 5.7.3.1 nem o teste de necessidade do destinatário na 5.7.4.1.
  • O defeito decisivo estava no encadeamento que permaneceu. A fonte deveria ser a detentora legítima registrada em algum RIR, não estar envolvida em disputa e cumprir as políticas do RIR receptor. O procedimento também mandava a parte transferente apresentar o pedido ao RIR receptor. Isso atribuía verificação e contato ao registro que talvez não tivesse contrato, cadastro próprio ou relação de serviço com a fonte estrangeira.
  • Na avaliação da equipe da AFRINIC, datada de 13 de outubro de 2020, ARIN e APNIC consideraram incompatível a cláusula de conformidade da fonte; LACNIC informou que sua política não exigia da fonte obediência ao outro RIR; e RIPE NCC considerou incompatível e não implementável o procedimento de início previsto na seção 5.7.5. O registro demonstra avaliações materiais de incompatibilidade, não um julgamento jurídico universal nem prova de resultado posterior.
  • A defesa mais forte do Draft 3 merece ser levada a sério. Uma espera de doze meses pode desestimular a devolução indireta ao espaço livre; a preservação do status legado evita uma penalidade categórica; verificações de necessidade, conflito e identidade podem reduzir fraude; e a coordenação entre RIRs pode impedir registros duplicados ou contraditórios. O problema aparece quando controles diferentes são tratados como uma única manifestação de poder do registro, sem perguntar qual instituição possui a relação, os dados e a competência contratual para executar cada verificação.
  • Uma ponte legítima de portabilidade é estreita. O RIR de origem confirma recurso, identidade, controle reconhecido, conflito conhecido e autorização da fonte; o RIR de destino confirma o destinatário e os requisitos do seu próprio serviço; ambos trocam mensagens autenticadas, fixam um instante efetivo e atualizam de forma coerente cadastro, DNS reverso, RPKI e histórico. AFRINIC atua aí como coordenadora técnica privada. Esse papel não lhe dá soberania, poder legislativo ou regulatório, domínio sobre recursos, jurisdição pública sobre o negócio, nem autoridade para decidir preço, geografia ou modelo empresarial.

Duas mudanças visíveis e uma ligação ainda defeituosa

Uma proposta de transferência entre registros pode parecer uma lista de requisitos. Na prática, ela é um desenho de liquidação. Duas organizações privadas mantêm cadastros distintos, atendem partes distintas e operam sistemas distintos; ainda assim, precisam representar a mesma mudança sem deixar duas fontes aparentes de controle, sem apagar prematuramente o registro anterior e sem permitir que dados de continuidade apontem para estados incompatíveis. A pergunta central, portanto, não é apenas se cada cláusula parece prudente isoladamente. É se as cláusulas distribuem as tarefas entre as instituições que realmente conseguem cumpri-las.

O Draft 3 da Resource Transfer Policy da AFRINIC oferece um caso particularmente instrutivo porque sua revisão foi pequena e seu problema de arquitetura permaneceu grande. O histórico oficial não autoriza uma narrativa expansiva de reforma. A versão alterou apenas as seções 5.7.3.2 e 5.7.4.3. A primeira mudança criou uma restrição temporal à fonte; a segunda preservou a classificação legado. Nenhuma delas reescreveu o circuito pelo qual uma fonte localizada no âmbito de um RIR e um destinatário ligado a outro deveriam ser verificados.

Quando se separa a tinta nova da estrutura herdada, fica claro por que duas respostas substantivas não bastaram para fazer a ponte funcionar.

Essa distinção também protege a cronologia. O encontro AFRINIC-32, realizado em 16 e 17 de setembro de 2020, discutiu o Draft 2. Suas atas registram a explicação dos autores de que a reciprocidade era necessária e registram objeções sobre conformidade com um RIR estrangeiro, contato direto com o registro receptor, teste de necessidade, recursos em disputa, alcance sobre ASN, status legado e a existência de um suposto modelo padronizado. As atas são importantes porque mostram que o desencontro operacional já estava exposto antes da versão seguinte.

Elas não são, porém, a ata de uma discussão do Draft 3, nem permitem atribuir uma das duas mudanças a uma fala específica.

Poucos dias depois veio a versão 3. O arquivo da AFRINIC preserva uma diferença de um dia: 21 de setembro no histórico de revisão, 22 de setembro no campo de detalhes. Essa divergência não muda a substância, mas ensina uma regra básica de precisão institucional: quando o próprio arquivo contém duas datas, a análise deve conservar a incerteza. O que se pode afirmar com segurança é que a versão foi publicada depois da discussão do Draft 2 e que o histórico atribui a ela somente as duas alterações mencionadas. A proximidade temporal estabelece sequência, não causalidade.

Em 13 de outubro, a avaliação da equipe vinculada ao Draft 3 registrou pedidos de esclarecimento, problemas de implementação e respostas dos quatro outros RIRs. É esse documento, e não as atas de setembro, que permite avaliar a compatibilidade da versão 3 como versão 3. A sequência documental é curta: questionamentos sobre a arquitetura do Draft 2; revisão de duas cláusulas; constatação de que o circuito restante não se encaixava nos procedimentos das contrapartes. O valor do caso está justamente nessa nitidez.

O que a cláusula 5.7.3.2 passou a fazer

No Draft 2, a proposta de 5.7.3.2 permitia que a fonte continuasse elegível a novas alocações ou designações IPv4 da AFRINIC, desde que permanecesse em conformidade com a política vigente. O Draft 3 substituiu essa elegibilidade imediata por uma espera de doze meses depois de uma transferência aprovada. Em termos funcionais, a cláusula separava dois movimentos: transferir recursos para outra parte e voltar a solicitar espaço ao serviço de alocação da AFRINIC.

Há uma justificativa benigna evidente. Se uma organização pudesse transferir recursos e imediatamente buscar novo espaço do estoque administrado pela AFRINIC, o mecanismo poderia incentivar ciclos oportunistas ou a conversão indireta de alocação escassa em valor de mercado. Uma espera prospectiva reduz essa possibilidade. Ela também torna o custo da decisão mais previsível: quem transfere sabe que não poderá retornar de imediato à fila de alocação da AFRINIC.

Mas o registro disponível não mede o comportamento que a regra procurava alterar. Não há quantidade documentada de ciclos, economia de estoque, pedidos evitados ou efeito de dissuasão atribuível ao Draft 3. Também não há base para afirmar que a cláusula tenha sido aplicada a alguém. A formulação responsável é, portanto, condicional: doze meses podem funcionar como instrumento anticiclagem; a proporcionalidade desse prazo dependeria de dados sobre o risco, de clareza quanto ao evento que inicia a contagem e de um caminho para corrigir erros de processamento.

É igualmente importante definir o objeto da restrição. A regra dizia respeito à elegibilidade para novas alocações ou designações da AFRINIC após uma transferência aprovada. Isso não equivale a uma proibição geral de comerciar, operar redes ou movimentar recursos. Tampouco transforma a organização em proprietária do espaço transferido. Trata-se, no máximo, de uma condição prospectiva para voltar a um serviço privado específico. Mesmo uma condição privada precisa ser inteligível e não arbitrária, mas sua natureza não deve ser inflada até parecer sanção pública.

O ganho da mudança é, assim, estreito e identificável. Ela responde ao risco de reentrada imediata no estoque administrado pela AFRINIC. Não autentica a fonte perante outro RIR, não resolve quem recebe o pedido, não cria um canal seguro entre registros e não sincroniza sistemas. É uma regra de tempo, não um protocolo de interoperabilidade.

O que a cláusula 5.7.4.3 deixou de retirar

A segunda mudança também é clara quando comparada com o Draft 2. A versão anterior dizia que recursos IPv4 legados deixariam de ser legados quando transferidos. O Draft 3 inverteu essa consequência: os recursos legados transferidos permaneceriam legados. Em vez de transformar a transferência em gatilho automático para perda de uma classificação histórica, o texto conservaria essa classificação.

Essa correção retirava um obstáculo imediato. Uma organização que avaliasse uma transferência não teria de aceitar, apenas por realizar a operação, uma mudança automática de status prevista no texto anterior. A preservação também evitava que a ponte entre regiões fosse usada para reescrever silenciosamente a história administrativa do bloco. Como princípio de cadastro, há valor em não fazer uma classificação desaparecer sem necessidade técnica demonstrada.

Ainda assim, “permanecer legado” não responde a todas as perguntas de serviço. O rótulo pode ter consequências diferentes em contratos, serviços oferecidos e práticas dos registros envolvidos. O Draft 3 não prova como outra instituição trataria um caso concluído, e não há no conjunto documental um caso concluído a examinar. A mudança preservava o status na formulação da proposta; não assegurava, sozinha, compatibilidade de todos os serviços associados.

Também aqui o efeito sobre a ponte é limitado. A cláusula impede uma alteração categórica de status, mas não diz qual RIR valida a fonte, como o pedido atravessa a fronteira institucional ou como duas bases confirmam o mesmo instante de mudança. Ela resolve uma consequência do Draft 2 sem remapear as relações que tornavam o procedimento difícil de executar.

As duas alterações pertencem, portanto, a classes diferentes. A espera de doze meses é uma condição de acesso futuro ao serviço de alocação. A preservação do legado é uma regra de continuidade classificatória. Uma proposta pode acertar em ambas e ainda errar no transporte da transação entre cadastros. Confundi-las com uma reforma completa faz a versão parecer mais abrangente do que o histórico oficial permite.

A arquitetura herdada: a fonte perante o registro errado

O problema central estava no que não mudou. A cláusula 5.7.3.1, cuja revisão o arquivo atribui ao Draft 2, permaneceu no Draft 3. Ela exigia que a fonte fosse a detentora legítima registrada em qualquer RIR, que não estivesse envolvida em disputa sobre os recursos e que cumprisse as políticas do RIR receptor. Os três elementos parecem, à primeira vista, uma única verificação de regularidade. Institucionalmente, porém, eles pedem dados e relações distintas.

Confirmar quem aparece como detentor reconhecido e se há um conflito assinalado é tarefa para o registro que mantém a relação com a fonte e possui o histórico daquele recurso. O RIR de origem conhece o cadastro de seu cliente ou usuário de serviço, pode conferir autoridades de representação e consegue identificar alertas nos seus próprios sistemas. Já o RIR de destino conhece o destinatário e pode verificar as informações necessárias para prestar seus serviços a essa parte. Pedir ao segundo que julgue diretamente a fonte estrangeira troca o local da evidência pelo local de chegada.

A exigência de que a fonte cumpra a política do RIR receptor acentua essa troca. Uma organização não passa a manter relação contratual com uma entidade privada estrangeira só porque a outra ponta de um negócio utiliza os serviços dela. O destino pode exigir dados de seu destinatário; pode também pedir ao registro de origem uma confirmação autenticada sobre a fonte. O que não decorre tecnicamente da reciprocidade é uma jurisdição privada transversal, na qual o RIR receptor passa a aplicar seu conjunto de regras à parte estrangeira como condição geral de reconhecimento.

Esse não é um argumento contra cooperação. É um argumento a favor de uma cooperação desenhada conforme as relações existentes. O RIR de origem não precisa aceitar uma mensagem não verificada do vendedor; ele autentica a sua parte. O RIR de destino não precisa aceitar cegamente o comprador; ele autentica a sua parte. Os registros trocam apenas as confirmações necessárias para que nenhum deles represente um estado contraditório. Segurança aumenta quando cada verificação fica com quem detém os melhores dados e quando as mensagens entre instituições são autenticadas.

O procedimento de início agravava o problema. O Draft 3 orientava a parte transferente a enviar a solicitação ao RIR receptor. Depois da aprovação, o RIR receptor notificaria o RIR transferente e as partes. Essa sequência faz o processo começar onde a relação com a fonte pode não existir. Ela obriga o registro de destino a receber documentos de uma parte que não atende e deixa o registro de origem numa posição reativa, embora seja ele quem deve confirmar o recurso, a pessoa autorizada e eventuais sinais de conflito.

A avaliação da equipe descreveu a prática oposta: cada RIR lida com a parte transferente situada em sua própria região, e os RIRs se comunicam entre si. A AFRINIC não verificaria diretamente uma fonte externa com a qual não tivesse relação. Isso não é mero detalhe administrativo. É o princípio que organiza a cadeia de confiança. A mensagem confiável para o RIR de destino não é uma declaração solta da fonte estrangeira, mas a confirmação emitida pelo RIR que conhece essa fonte.

Também permaneceu a regra de necessidade para uma transferência que entrasse na AFRINIC, enquanto uma transferência de saída seguiria a política do RIR receptor. A mesma versão dizia que o destinatário poderia ser qualquer parte com acordo com o remetente, e a equipe observou que, em alguns casos, essa abertura entrava em tensão prática com a disposição anterior baseada em necessidade. A tensão ilustra outro risco de misturar camadas: liberdade para escolher a contraparte, elegibilidade para um serviço e requisitos de registro não são frases intercambiáveis.

Um teste de necessidade pode ser defendido como forma de reservar oferta escassa a uso demonstrado. Mas, numa transferência entre partes privadas, ele vai além do núcleo indispensável à unicidade e à correção do cadastro. A existência do destinatário, sua identidade, sua capacidade de receber o recurso e os dados necessários à continuidade são questões operacionais. A avaliação do quanto ele “precisa” do recurso envolve planejamento empresarial, horizonte de crescimento e juízo sobre utilização.

Esse exame pode fazer parte de um serviço voluntário claramente contratado; não deve ser tratado como atributo natural de uma autoridade pública que o RIR não possui.

Quatro respostas de incompatibilidade, cada uma apontando para a mesma emenda estrutural

A avaliação de 13 de outubro é decisiva porque registra consultas às contrapartes e especifica onde o encaixe falhava. Ela não diz simplesmente que os regimes eram “diferentes”, formulação ampla que poderia esconder qualquer coisa. As respostas relatadas se concentram na atribuição de conformidade e no ponto de entrada do pedido.

ARIN e APNIC consideraram incompatível a cláusula pela qual a fonte teria de cumprir a política do RIR receptor. LACNIC informou que sua política não exigia que a fonte cumprisse as regras do outro RIR. RIPE NCC identificou incompatibilidade no procedimento de início da seção 5.7.5 e o considerou não implementável. As formulações não são idênticas, mas convergem na mesma pergunta: quem fala com quem e com base em qual relação?

Não se deve transformar essas respostas em algo que elas não são. Elas não constituem decisão de um tribunal, não definem direitos de propriedade e não provam que toda combinação possível de regras seria inviável. O que demonstram é mais concreto: segundo o registro da equipe da AFRINIC, os procedimentos existentes das quatro contrapartes não acomodavam elementos materiais do texto do Draft 3. Para uma proposta fundada em reciprocidade, incompatibilidade com cada uma das quatro rotas potenciais é um problema de implementação de primeira ordem.

Reciprocidade, nesse contexto, não significa que dois RIRs precisem copiar todas as regras um do outro. Se isso fosse exigido, qualquer diferença local poderia bloquear a portabilidade. A reciprocidade útil é mais fina: ambos reconhecem que o outro verificou a parte sob sua relação; ambos aceitam um conjunto comum de dados sobre o recurso e a transferência; ambos confirmam um momento efetivo; ambos atualizam suas bases sem duplicidade. Regras adicionais podem existir na prestação de serviço de cada lado, mas não precisam converter-se automaticamente em poder de veto extraterritorial.

É por isso que a noção de “modelo padrão” levantada no debate do Draft 2 merecia cautela. Um formulário comum pode padronizar campos, assinaturas e mensagens. Ele não cria, por si só, uma relação entre a fonte e o RIR de destino. Padronização de documento é diferente de atribuição de competência. Se a primeira mascara a segunda, o processo parece uniforme no papel enquanto continua impossível na prática.

O Draft 3 corrigiu resultados específicos, mas não essa atribuição. A fonte continuava submetida à política do receptor; a parte transferente continuava orientada a iniciar ali. A incompatibilidade não era uma falha estética que pudesse ser compensada pela espera de doze meses ou pela preservação do legado. Era um erro de endereçamento.

Liquidação reconhecida: onde o cadastro encontra a operação

Recursos IPv4 não deixam de ser roteáveis porque dois RIRs discordam sobre um formulário. Uma rede pode anunciar rotas, e partes privadas podem mudar o controle operacional por instrumentos contratuais. Mas a realidade operacional e a realidade registrada precisam convergir. Quando não convergem, cresce o custo de provar quem deve aparecer nos dados públicos, quem pode pedir alterações, quais objetos de rota são válidos e como terceiros devem avaliar o bloco.

Essa convergência é o sentido econômico de compatibilidade. Não se trata de dar ao cadastro poder para criar o negócio, e sim de evitar que a dependência do cadastro torne o negócio incerto. Se o RIR de origem ainda mostra a fonte anterior, enquanto o RIR de destino não consegue aceitar o destinatário, o mercado passa a precificar uma lacuna. Advogados, intermediários e serviços de custódia precisam gastar mais tempo definindo condições suspensivas. Operadores precisam planejar uma janela de migração com risco de dados desencontrados. Terceiros encontram sinais contraditórios sobre controle reconhecido.

O impacto pode aparecer em vários sistemas. A avaliação da equipe mencionou mudanças potenciais no MyAFRINIC, em DNS reverso, em ROAs de RPKI, em registros de transferência e em sistemas de atendimento. Também apontou revisão de processos, coordenação entre RIRs, contratos, pessoal e recursos de engenharia de software. A lista mostra que “aprovar uma transferência” não é um único clique. É uma transição de estado distribuída.

No cadastro principal, a identidade e os contatos associados ao recurso precisam refletir o destinatário no momento combinado. No DNS reverso, a delegação deve permanecer controlável durante a transição. No RPKI, a capacidade de emitir ou ajustar ROAs precisa evitar um intervalo desnecessário de invalidez ou uma sobreposição ambígua. No histórico de transferências, a operação deve aparecer de forma consistente e rastreável. No atendimento, os chamados de ambas as partes devem apontar para o mesmo evento, sem que uma equipe trate como pendente o que a outra já efetivou.

Não há evidência de que o Draft 3 tenha causado uma demora, uma falha de RPKI, um desconto de preço ou uma perda concreta. Esses são mecanismos plausíveis, não acontecimentos atribuídos à versão. A prudência factual não reduz a importância do desenho. Um protocolo é avaliado antes de falhar justamente pela sua capacidade de impedir estados contraditórios. O registro de incompatibilidade permite identificar o risco, mesmo sem quantificar um dano consumado.

Para compradores, vendedores e operadores, previsibilidade de liquidação afeta liquidez. Quanto mais incerto o reconhecimento, maior a margem que cada parte reserva para documentos adicionais, prazo, custódia e contingência. Um recurso cujo controle registrado pode ser atualizado por uma ponte previsível tende a ser mais fácil de diligenciar do que um recurso preso numa fronteira procedimental. A diferença não autoriza afirmar um efeito de preço específico, mas explica por que a arquitetura institucional influencia a disposição de transacionar.

Há também uma dimensão de saída. Se um detentor depende de um registro para que terceiros reconheçam dados essenciais, mas não consegue transferir para fora por incompatibilidade procedimental, a fronteira do registro funciona como bloqueio econômico. Portabilidade reduz esse bloqueio quando permite mudar a relação de serviço sem quebrar continuidade ou unicidade. Ela disciplina o escriturador por meio da possibilidade de saída; não o transforma em concedente soberano da mobilidade.

A melhor defesa do texto — e por que ela precisa ser desagregada

Uma análise séria não deve tratar cautela como pretexto. Havia motivos razoáveis para evitar uma abertura descuidada. Espaço IPv4 disponível era escasso. Uma fonte poderia tentar transferir recursos e voltar rapidamente ao estoque administrado pela AFRINIC. Documentos falsos ou representantes sem poderes poderiam procurar alterar um cadastro. Recursos poderiam estar sob reivindicações conflitantes. Uma transição mal coordenada poderia deixar duas bases divergentes. Um bloco legado poderia exigir tratamento cuidadoso. E nenhum RIR poderia obrigar a contraparte a reconhecer um processo que não se ajustasse aos seus sistemas.

Vista desse ângulo, a versão 3 continha duas melhorias defensáveis. A espera de doze meses oferecia uma resposta simples à reciclagem imediata. A preservação do legado evitava que a transferência carregasse uma perda automática de status. O teste de necessidade para entradas poderia ser defendido como proteção de oferta. A reciprocidade poderia ser defendida como garantia de que os dois lados registrariam a mesma mudança. Verificação de titular reconhecido e ausência de disputa poderia reduzir fraude.

O ponto crítico não é rejeitar esses objetivos em bloco, mas separá-los. Anticiclagem pergunta quando uma fonte pode voltar a pedir espaço à AFRINIC. Necessidade pergunta se um destinatário atende a um critério de serviço. Status legado pergunta como conservar uma classificação histórica. Autenticação pergunta se a pessoa que instrui a operação está autorizada. Conflito pergunta se existem reivindicações concorrentes conhecidas. Interoperabilidade pergunta como dois registros trocam confirmações e atualizam seus estados. Cada controle tem evidência, risco e remédio próprios.

Quando todos são reunidos sob palavras como “gestão”, “comunidade” ou “mandato”, a avaliação perde precisão. Uma reunião aberta pode produzir informação valiosa, mas não é uma legislatura e seus participantes não são proprietários coletivos dos endereços de uma região. Uma política privada pode organizar um serviço, mas não cria poder policial ou regulatório. Uma base de dados pode ser indispensável à coordenação, mas sua indispensabilidade não transforma reconhecimento em criação do direito privado subjacente.

A defesa benigna continua válida onde corresponde ao risco. O RIR de origem deve confirmar a identidade do recurso e da fonte. Um conflito genuíno pode justificar uma pausa transparente, com razões e caminho independente para resolução. Mensagens autenticadas evitam falsificação. Um instante efetivo evita dupla representação. A continuidade do DNS reverso e do RPKI precisa ser planejada. O histórico deve registrar a mudança. Nada disso exige que o RIR de destino julgue uma fonte estrangeira segundo todas as suas políticas.

O mesmo raciocínio limita a regra de doze meses. Se justificada como condição estreita do serviço de alocação, ela pode ser avaliada por dados sobre reentrada e estoque. Se usada como punição genérica contra quem transferiu, muda de natureza. Clareza sobre início, término e evento qualificador impede discricionariedade. Uma organização que contesta erro de data deve receber explicação e correção, não ser tratada como alvo de sanção pública.

Preservar o legado também precisa ser entendido com precisão. A mudança evita uma perda prevista no Draft 2, mas não converte “legado” em escudo contra toda regra de serviço nem em título de propriedade concedido pelo registro. O cadastro conserva um atributo histórico; não decide sozinho todas as consequências jurídicas de uma relação privada.

O limite institucional: escriturar não é governar

AFRINIC presta serviços concretos de coordenação e registro. Mantém informações relacionadas a recursos numéricos, apoia funções operacionais e interage com outros registros. Essas atividades podem ser essenciais para que redes e terceiros encontrem dados coerentes. A melhor descrição de seu papel, porém, é a de uma escrituradora e coordenadora técnica privada.

Um escriturador confiável precisa dizer o que reconhece, com base em quais evidências e em que momento atualizou o registro. Precisa proteger credenciais, resolver defeitos ordinários e lidar de maneira transparente com conflitos reais. Precisa também conversar com outro escriturador quando uma mudança atravessa os limites de suas bases. O valor está na fidelidade entre registro e realidade, não na pretensão de ter criado essa realidade.

Esse limite afasta várias confusões. Publicar uma proposta não é legislar. Discuti-la numa reunião não é exercer soberania popular. Avaliar compatibilidade não é emitir sentença. Atualizar um cadastro não é confiscar nem conceder propriedade. Recusar um formato incompatível pode ser uma consequência operacional legítima; usar a dependência do registro para controlar preço, geografia, modelo de negócio ou moralidade regional seria uma expansão sem base na necessidade técnica.

O núcleo comum de uma transferência é pequeno. O recurso deve ser identificado sem ambiguidade. A parte de origem deve demonstrar controle reconhecido e autorização. Conflitos conhecidos precisam ser sinalizados. O destinatário deve ser identificável. Dados de continuidade precisam estar prontos. A transferência deve ter um instante efetivo e um histórico verificável. Essas condições sustentam unicidade, segurança e coerência.

Necessidade, localização, preço e estratégia empresarial não pertencem automaticamente a esse núcleo. Podem aparecer em contratos voluntários ou em regras específicas de serviço, mas não são invariantes técnicas. Um bloco não se torna duplicado porque o preço foi alto; o DNS reverso não deixa de funcionar porque o destinatário opera em outra geografia; um ROA não é tecnicamente inválido porque um registro desaprova o modelo de negócios. Confundir preferências institucionais com requisitos de unicidade permite que o controle de uma base vire poder de mercado.

O Draft 3 torna esse risco visível sem que seja necessário atribuir intenção imprópria a seus autores ou à equipe. O texto procurava reciprocidade, mas usava uma fórmula que estendia a política do receptor à fonte e enviava a fonte ao interlocutor errado. O resultado registrado foi incompatibilidade. Corrigir o circuito exigia diminuir a pretensão relacional, não ampliar a autoridade de um dos lados.