Nota 65

O que deve permanecer estável, e para quem?

Primazia do Código em Funcionamento: a correção necessária para preservar a concepção original da Internet

Que ajuste único restauraria o projeto original da internet na camada de registro?

Lu Heng · 7 de maio de 2026 · 52 min de leitura

Cada participante pode verificar por si mesmo. A proposta de Lu Heng faz a validade depender de regras verificáveis localmente e do uso efetivo, em vez da permissão de um registro permanente.

As sete notas anteriores do Heng.lu nesta sequência são:

Os sete ensaios anteriores não eram um programa de reforma dos Registros Regionais de Internet.

Eram uma autópsia.

Eles acompanharam a mesma patologia institucional em diferentes camadas: responsabilidade jurídica dissociada das consequências; recursos numéricos reclassificados como propriedade política; unicidade transformada em dupla extração; soberania invertida; pobreza tributada em nome da igualdade; consenso voltado contra as redes às quais deveria servir; e, por fim, mandato submetido a uma lavagem até que um escriturário começasse a falar como um soberano. A sequência importa porque a falha não se resumia a um conselho ruim, um registro ruim, um processo judicial ou um acontecimento incômodo no mercado. Era um defeito do sistema que aparecia sob diferentes disfarces. A página do autor no CircleID agora mostra essa sequência com clareza, incluindo A traição ao código em funcionamento e Lavagem de mandato. (circleid.com)

Este ensaio não trata de tornar os RIRs governantes melhores.

Trata de explicar por que a atual ordem dos registros não pode ser o ponto de chegada e por que a correção menos disruptiva é um complemento à concepção técnica original da Internet.

Esse complemento é a Primazia do Código em Funcionamento.

A necessidade dele já não é teórica. Em uma troca recente no CircleID, John Curran apresentou a versão mais forte da defesa do sistema estabelecido. Seu argumento é que a autoridade do sistema dos RIRs não é apenas um subproduto de uma coordenação técnica restrita, mas o resultado de uma cadeia histórica: o Livro Branco, a ICANN, a ASO, o ICP-2, a transição da supervisão da IANA e a continuidade da governança multissetorial do setor privado. Ele afirma que a autoridade do sistema dos RIRs resulta de sua atuação dentro do modelo multissetorial do setor privado determinado pelo governo dos Estados Unidos. (circleid.com)

Esse argumento é útil porque torna a divergência visível.

A questão já não é se houve delegação histórica. É claro que houve. A questão é se uma função de coordenação historicamente delegada pode, depois, ampliar a si mesma até se tornar um mandato permanente de governança por meio da mesma engrenagem processual que controla. A resposta do sistema estabelecido é sim: delegação, reconhecimento, continuidade institucional e procedimentos da comunidade se tornam um mandato que se renova por conta própria.

A resposta exigida pela concepção técnica original da Internet é não.

A tradição original da Internet era mais restrita, mais rigorosa e melhor. O RFC 3935 diz que o objetivo da IETF é “fazer a Internet funcionar melhor”; fundamenta esse trabalho na competência técnica, na implementação no mundo real e no “consenso aproximado e código em funcionamento”. Também afirma que, quando a IETF não é responsável por um protocolo ou uma função, não tenta exercer controle sobre eles. (rfc-editor.org) O RFC 7282 repete a antiga frase de David Clark: “Rejeitamos: reis, presidentes e votações” e “Acreditamos em: consenso aproximado e código em funcionamento”. (rfc-editor.org) O RFC 9592 explicita ainda mais esse princípio contrário à autoridade soberana: a IETF não opera, controla nem patrulha a Internet e não é “a polícia dos protocolos”. (rfc-editor.org)

Essa tradição nunca significou que documentos fossem mágicos. Significava que documentos importavam quando ajudavam os sistemas a funcionar. Significava que os procedimentos eram tolerados porque serviam à implantação. Significava que um espaço de discussão só era útil quando se disciplinava em torno da realidade operacional.

A camada dos registros tomou essa legitimidade emprestada.

Nunca aceitou plenamente essa disciplina.

Essa é a correção que falta.

O que significa a Primazia do Código em Funcionamento

A Primazia do Código em Funcionamento significa que os sistemas de coordenação da Internet devem ser interpretados de forma restrita, tendo como referência a função técnica mínima que as redes em funcionamento originalmente justificaram.

A camada dos recursos numéricos existe para proteger os sistemas em funcionamento: unicidade, interoperabilidade, continuidade ligada ao roteamento, declarações de segurança, prova de controle e a semântica comum mínima necessária para que redes independentes funcionem juntas.

Ela não existe para fabricar autoridade política.

Não existe para policiar a moralidade comercial.

Não existe para converter a geografia de atendimento em título de propriedade.

Não existe para transformar uma lista de discussão em um poder legislativo.

Não existe para permitir que um registro privado faça desaparecer ativos de redes já em funcionamento porque sua teoria interna de políticas mudou.

Um registro não é um Estado.

Um contato em um banco de dados não é uma procuração empresarial.

Uma região de atendimento não é um povo.

Um fórum de políticas não é um poder legislativo.

Uma entrada de registro pode descrever a realidade operacional. Não a cria.

Isso não é conservadorismo. A Primazia do Código em Funcionamento não diz que os sistemas implantados nunca podem mudar. Diz que o poder institucional sobre a mudança não deve ser justificado por delegação histórica, reconhecimento circular ou procedimentos ritualizados. Deve ser justificado por regras determinísticas que os operadores possam verificar localmente e pela adoção nos sistemas em funcionamento.

A ordem correta é: especificação inicial, estado do livro-razão distribuído, validação local, implementação em funcionamento, adoção voluntária, conjunto de compatibilidade e, só então, documentação.

A ordem errada é: fórum de políticas, declaração, obrigação alegada, rótulo de conformidade, conformidade operacional forçada.

O sistema dos RIRs falhou porque escolheu cada vez mais a segunda ordem.

A correção fundamental é esta: depois da especificação inicial, não existe uma instituição permanente à qual recorrer. Nenhum comitê decide se a não adoção constitui uma infração. Nenhum registro declara um participante inválido simplesmente porque ele se recusa a aceitar uma mudança posterior. Existem apenas código, estado do livro-razão, validação, adoção, compatibilidade, rejeição local, bifurcação e interoperação seletiva.

Um operador que se recusa a aceitar uma mudança posterior não quebra a Internet. Ele pode permanecer em um conjunto de compatibilidade mais antigo. Pode criar uma bifurcação. Pode se desconectar. Pode deixar de interoperar com participantes que adotaram regras incompatíveis. Mas não pode quebrar a interoperabilidade dos demais que continuam executando código mutuamente compatível.

A intuição de projeto é a mesma que torna úteis os livros-razão distribuídos: não é necessária uma instituição permanente para decidir a validade ordinária. Os participantes validam as transições de estado localmente, segundo regras determinísticas. Um estado inválido não é punido por uma instituição. É ignorado pelos participantes que não o aceitam.

Essa é a correção essencial que falta à coordenação dos recursos numéricos.

A falha de concepção estava presente desde o início

A primeira concepção dos RIRs pressupunha um mundo de baixo valor econômico.

Os recursos numéricos pareciam técnicos, abundantes, meramente administrativos e pouco sujeitos a conflitos. Naquele mundo, a informalidade parecia eficiente. Listas de discussão abertas pareciam representativas. A administração baseada em contatos parecia adequada. Contratos com limitação de responsabilidade pareciam inofensivos. Um registro regional podia parecer uma agenda de endereços.

A escassez do IPv4 destruiu essa premissa.

Os endereços IPv4 se tornaram escassos, transferíveis, passíveis de financiamento, alugados, capitalizados, objeto de litígios e sanções, e incorporados a redes em operação. A camada dos registros já não se situava acima de simples entradas administrativas. Situava-se acima de infraestrutura produtiva. Acima do valor dos ativos. Acima da continuidade do atendimento aos clientes, da implantação em nuvem, das operações de telecomunicações, da conectividade nacional, das ordens judiciais e da alocação de capital.

A forma institucional não se retraiu para se adequar a esse novo risco.

Ela se expandiu.

O resultado é um sistema que ainda fala a linguagem da coordenação técnica enquanto produz os efeitos da governança de infraestrutura. Ele pede aos operadores que tratem os procedimentos dos registros como neutros, enquanto as decisões dos registros afetam seu destino comercial. Chama seus participantes de “comunidade”, embora muitos dos que arcam com as consequências nunca tenham conferido poderes claros de representação jurídica às pessoas presentes no fórum.

A NRS expõe o problema estrutural com clareza: os registros de recursos numéricos da Internet foram concebidos como órgãos de coordenação técnica, mas, quando a escassez do IPv4 transformou os endereços em ativos valiosos, a discricionariedade dos registros se tornou poder econômico; quando sistemas de coordenação controlam capital, a centralização se torna um risco estrutural e a descentralização passa a ser engenharia de sistemas, em vez de ideologia. A NRS também apresenta a direção oposta de projeto: uma só Internet, infraestrutura aberta e autônoma e governança descentralizada com participação humana mínima em seu núcleo. (nrs.help)

Essa é a verdadeira questão. A camada dos registros nunca recebeu a correção necessária para o momento em que uma tabela de coordenação se tornou uma barreira de acesso aos ativos.

A Primazia do Código em Funcionamento é essa correção.

Não é uma doutrina para melhorar os RIRs.

É uma disciplina pós-RIR.

As três regras da correção

A base construtiva é a versão revisada da Nota 64: Especificação Inicial Mínima, Decisão Futura Localizada e Adoção Voluntária para Sistemas de Coordenação da Internet: Especificação Inicial Mínima, Decisão Futura Localizada e Adoção Voluntária.

Os nomes permanecem os mesmos. A lógica precisa ser precisa.

Especificação Inicial Mínima significa que a camada comum contém apenas as regras determinísticas e verificáveis localmente necessárias à unicidade, à interoperabilidade, à prova de controle, à segurança operacional compartilhada e à segurança. Ela não contém preferências de modelo de negócios, teorias de precificação, sentimentos políticos regionais, poderes discricionários de imposição ou expansão da missão institucional.

Decisão Futura Localizada não significa que uma instituição decide quais decisões futuras são locais. Isso já reintroduziria a camada de autoridade. Significa que a especificação inicial estabelece os limites de antemão. Depois da implantação, as escolhas futuras ordinárias permanecem com os participantes que executam código. Um participante pode adotar, recusar, criar uma bifurcação, se desconectar ou interoperar seletivamente. Nenhum participante pode alterar a interoperabilidade dos demais que continuam executando regras mutuamente compatíveis.

Adoção Voluntária significa que uma mudança posterior só se torna real por meio de implementação, validação, implantação e uso. Publicação não é realidade. Recomendação não é realidade. Reconhecimento pelo sistema estabelecido não é realidade. A não adoção não cria uma condição de invalidade. Um participante que não adota uma mudança posterior permanece em seu conjunto de compatibilidade existente. Um participante que emite um estado inválido segundo as regras determinísticas de outro participante pode ser ignorado localmente. O efeito é a seleção de compatibilidade, não a punição institucional.

Essas três regras não reabilitam a soberania dos registros.

Impedem que ela reapareça com outro nome.

APNIC: a estrutura jurídica era o risco

A APNIC mostra a primeira falha: o mínimo nunca foi especificado com rigor suficiente no início.

Essa não é uma história sobre códigos de conduta. Não é uma história sobre etiqueta. Não é uma história sobre se um crítico foi suficientemente educado com uma instituição estabelecida.

É uma história sobre estrutura jurídica.

Em março de 2023, a LARUS publicou uma análise jurídica alertando que a estrutura de governança da APNIC criava riscos não apenas para uma empresa em Brisbane, mas para a governança da Internet em toda a região da Ásia-Pacífico. A análise dizia que o diretor-geral da APNIC detinha o poder jurídico final de encerrar a APNIC e destituir o Conselho Executivo eleito, e que eram necessárias alterações urgentes na governança. Também afirmava que a estrutura levantava questões sobre a segurança da governança da Internet para mais de um bilhão de usuários da Internet na Ásia-Pacífico. (larus.net)

O primeiro anexo, o extrato empresarial da ASIC, fornece a base societária. A APNIC Pty Ltd constava como uma sociedade privada australiana de responsabilidade limitada por ações, registrada em Queensland. Paul Byron Wilson constava como diretor e secretário. As informações sobre o capital mostravam uma única ação ordinária emitida, e Paul Byron Wilson constava como o sócio detentor dessa ação. (larus.net)

Essa não é uma forma normal de abrigar uma função regional crítica de coordenação da Internet.

O segundo anexo, o parecer jurídico do Dr. Peter Felter, formulou a conclusão sobre a governança. Ele descreveu a estrutura pública da APNIC — membros, eleições, Conselho Executivo, diretor-geral e Secretaria — como um comitê especial fundamentado no artigo 9.3 do estatuto da APNIC Pty Ltd. Afirmou que a APNIC Pty Ltd havia sido, durante 25 anos, uma sociedade privada controlada por um diretor, um acionista e um secretário, todos a mesma pessoa. (larus.net)

Essa distinção importa.

A instituição pública voltada à comunidade não era o invólucro jurídico final. Era uma construção assentada sobre a estrutura de uma empresa privada.

O parecer jurídico explicou, então, por que essa distinção importa. Segundo o parecer, as normas internas da APNIC estavam subordinadas ao estatuto e aos poderes da sociedade e de seus diretores, administradores e sócios. Nessa interpretação, a estrutura pública da APNIC poderia ser alterada por resolução do diretor da APNIC Pty Ltd; o parecer descreveu a APNIC como, na prática, um departamento da APNIC Pty Ltd. (larus.net)

O ponto mais contundente do parecer não era que a APNIC fosse tecnicamente ilegal. Era que legalidade e adequação não são a mesma coisa. O parecer argumentava que o arranjo de trust não resolvia o problema porque os poderes do Conselho Executivo ainda derivavam da resolução do diretor que estabelecia o comitê especial. Também observava que a APNIC Pty Ltd era uma sociedade privada por ações cuja estrutura e objetivos não se assemelhavam ao modelo sem ações e sem fins lucrativos que a maioria das pessoas associaria a um registro regional de interesse público. (larus.net)

Essa é a primeira falha de concepção em sua forma mais nítida.

Um sistema de coordenação de recursos numéricos em escala regional não deveria depender de uma estrutura que exige advogados para explicar por que uma sociedade privada com uma única ação, um comitê especial, um instrumento de trust e um conselho eleito, de algum modo, se combinam para conferir controle legítimo sobre o registro de recursos numéricos da Ásia-Pacífico.

Uma camada crítica de coordenação deveria ser compreensível para quem a observa de fora.

Não deveria exigir confiança em documentos por trás de outros documentos.

Não deveria obrigar os membros a descobrir, depois de anos de dependência institucional, que a camada eleita talvez não seja a instância jurídica final.

Não deveria dar a aparência de governança pelos membros enquanto deixa o poder formal em outro lugar.

É por isso que a Especificação Inicial Mínima deve incluir validade distribuída, não confiança institucional. Não porque uma futura instituição precise de governança melhor. Mas porque um futuro sistema pós-RIR deve evitar a necessidade dessa instituição por completo.

A camada comum não deveria depender da estrutura oculta de controle de uma sociedade privada. Deveria definir regras determinísticas de validação, estado da prova de controle, regras de transição de estado, regras de conflito, replicação do livro-razão, caminhos de saída, caminhos de bifurcação e conjuntos de compatibilidade. Se a APNIC desaparecer, se deixar capturar, mudar sua posição jurídica ou se recusar a reconhecer um estado válido, a rede em funcionamento não deveria depender do reconhecimento contínuo da APNIC para saber quem controla quais recursos numéricos.

O registro não deveria ser a fonte da validade.

O estado do livro-razão distribuído, validado segundo a especificação inicial, deveria ser.

ARIN: a política encontrou a realidade dos ativos

A ARIN mostra a segunda falha: a realidade jurídica e de mercado pode avançar mais rápido que a teoria dos registros.

O acontecimento decisivo foi a transação Nortel/Microsoft. Quando a Nortel pediu proteção judicial por insolvência, seus 666.624 endereços IPv4 se tornaram ativos valiosos no processo. Os endereços foram vendidos à Microsoft por US$ 7,5 milhões. A ARIN interveio com base na teoria de que os endereços não eram propriedade e não poderiam ser vendidos livres de ônus e das restrições impostas pelas políticas do registro. A Industry Canada apoiou essa posição. O tribunal de insolvência a rejeitou; a Microsoft posteriormente assinou um acordo para recursos legados; e o resultado prático ficou claro: as políticas dos registros não poderiam continuar sendo a única fonte da realidade quando tribunais e mercados passavam a tratar os recursos numéricos como ativos. (btw.media)

A lição importante não é que a ARIN fosse singularmente defeituosa.

A lição é que a camada dos registros havia entrado em uma nova categoria.

Uma entrada de registro é valiosa porque operadores, tribunais, compradores, vendedores, credores e redes se apoiam nela. Ela não se torna uma autoridade ao negar essa dependência. Só continua útil se acompanhar a realidade jurídica, de mercado e operacional de perto o suficiente para merecer confiança.

Quando o IPv4 se tornou escasso, os procedimentos dos registros se tornaram uma interface com o mercado. Regras de transferência, avaliações de necessidade, atrasos no reconhecimento e restrições regionais deixaram de ser detalhes administrativos. Tornaram-se entraves à movimentação dos ativos. Análises públicas hoje descrevem um conjunto fragmentado de regras dos RIRs, no qual cinco sistemas regionais governam um mercado com preços de aproximadamente US$ 18 a US$ 45 por endereço, com regras conflitantes capazes de imobilizar ativos, atrasar fusões e obrigar a criação de estruturas societárias separadas apenas para deter blocos de endereços. (btw.media)

Isso não é coordenação neutra.

É um efeito regulatório sem a correspondente responsabilização regulatória.

A ARIN demonstra por que a Adoção Voluntária importa. Uma política de registro só permanece crível enquanto descreve aquilo que os atores efetivamente implementam, negociam, financiam, submetem aos tribunais e usam como base para suas atividades. Ela se torna perigosa quando a publicação é tratada como suficiente para fabricar realidade.

Um registro que se recusa a aceitar a realidade não se torna soberano.

Torna-se um banco de dados desatualizado.

Em uma arquitetura de Primazia do Código em Funcionamento, a lição é ainda mais clara. Tribunais e mercados não precisam de um registro estabelecido para decidir se existe valor. Operadores não precisam de um comitê para saber se um bloco é roteado. Os participantes precisam de regras determinísticas que permitam prova de controle, resolução de conflitos, transições de estado visíveis no livro-razão e compatibilidade. O antigo registro pode publicar uma visão. Um cliente de software pode exibir uma visão. Um explorador de livro-razão pode exibir uma visão. Nenhum deles é a fonte da validade.

Não existe um registro para o qual migrar.

Não existe um registro ao qual perguntar.

Existe apenas um estado distribuído que os participantes validam, aceitam, rejeitam, a partir do qual criam bifurcações ou com o qual interoperam.

AFRINIC: quando a teoria dos registros ameaçou ativos em operação

A AFRINIC é o caso central porque reduziu o problema aos seus elementos essenciais.

A narrativa errada é a de que um membro problemático paralisou um registro regional.

Essa é a fábula moral do sistema estabelecido.

A história estrutural é diferente. A AFRINIC tentou converter o uso comercial, a localização dos clientes, o aluguel de endereços, a relação com o membro e a interpretação interna de políticas em um suposto poder de cancelar o registro de recursos numéricos já em operação. Depois que essa pretensão foi apresentada, o conflito já não podia permanecer uma divergência em um fórum de políticas. Tornou-se um teste de se um registro privado poderia usar a retórica regional e o silêncio das políticas para ameaçar ativos incorporados às operações.

Os fatos não exigem exagero teatral. Reportagens públicas descreveram a disputa da AFRINIC como uma simples controvérsia comercial sobre endereços IP que se tornou a maior história de governança da Internet na África. Também relataram que a Cloud Innovation havia sido frequentemente retratada como a vilã, enquanto documentos posteriores apontavam para forças destrutivas dentro da própria AFRINIC e para processos judiciais adiados, prolongados e mantidos por representantes da AFRINIC às custas da AFRINIC. (btw.media)

Isso importa porque inverte a narrativa habitual.

Os processos judiciais não criaram a falha estrutural.

Eles a expuseram.

A falha relevante já estava presente quando um registro privado tratou a ausência de permissão expressa como fundamento para o controle coercitivo. O aluguel de endereços não era uma ameaça à unicidade. A localização dos clientes não era uma atribuição duplicada. O uso comercial não era uma falha de segurança do roteamento. Um modelo de negócios de que um registro não gostava não era um invariante global.

Ainda assim, a pretensão do registro colocou essas questões sob a lógica da revogação.

Esse é o momento em que a coordenação se torna governança.

As reportagens registram que a AFRINIC enviou à Cloud Innovation uma carta em março de 2021 alegando violações de políticas e ameaçando encerrar sua condição de membro; que, em julho de 2021, a Suprema Corte de Maurício proibiu a AFRINIC de encerrar a condição de membro da Cloud Innovation; e que uma nova tentativa da AFRINIC de cancelar essa condição foi bloqueada em dezembro de 2021. (btw.media) Essa sequência não é a história de um registro protegendo serenamente a Internet. É a história da autoridade de um registro encontrando a lei comum.

Tampouco o colapso institucional mais amplo foi causado por falta de poder do registro. O problema mais profundo era o aprisionamento institucional. Se um único registro detém o monopólio do reconhecimento de ativos valiosos em operação, toda falha interna se torna um risco à continuidade da Internet. Se os membros não podem deixar o sistema de reconhecimento, a falha do registro se transforma em poder de manter reféns.

Um registro pode corrigir fraudes demonstráveis em seus próprios registros cadastrais.

Pode impedir atribuições duplicadas enquanto o modelo de registros ainda existir.

Pode manter declarações de segurança enquanto os participantes ainda dependerem dele.

Mas essas são funções transitórias de uma arquitetura antiga.

Em uma arquitetura pós-RIR, essas funções não são desempenhadas por um registro. São codificadas no estado de um livro-razão distribuído, em regras de prova de controle, em regras de conflito e em transições verificáveis localmente.

Uma entidade privada não deveria transformar o aluguel de endereços em traição à região.

Não deveria transformar a localização dos clientes em um gatilho de revogação.

Não deveria tratar uma divergência comercial como invalidade técnica.

Não deveria converter a continuidade dos ativos em uma questão de permissão.

A AFRINIC demonstra a necessidade da Decisão Futura Localizada corretamente compreendida. Não existe uma entidade central decidindo que uma decisão comercial futura “pertence ao âmbito local”. Em vez disso, a especificação inicial deve assegurar que essas decisões nunca entrem na camada comum. Aluguel, localização dos clientes, uso comercial, precificação, financiamento, composição da clientela e estratégia de implantação permanecem fora das regras determinísticas de validade, a menos que afetem diretamente a unicidade, a segurança, a prova de controle ou a interoperabilidade.

Um operador não pode quebrar a interoperabilidade dos demais operadores ao alugar endereços.

Um operador não pode quebrar a interoperabilidade dos demais operadores ao atender clientes fora de uma região histórica de registro.

Um operador não pode quebrar a interoperabilidade dos demais operadores ao usar um modelo de negócios de que um registro não gosta.

No máximo, um operador pode deixar de satisfazer as regras determinísticas que os outros participantes executam. Nesse caso, os demais participantes rejeitam localmente o estado inválido. Não há uma camada de punição. Não há um tribunal de conformidade. Não há um soberano regional.

Essa linha divisória não é ideológica.

É operacional.

O problema da representação por procuração não é um detalhe

A controvérsia eleitoral da AFRINIC tornou visível um segundo defeito: a representação.

A NRS apresenta a base de sua representação em termos jurídicos diretos. Diz que os membros relacionados lhe confiaram a representação em assuntos de governança dos RIRs e que cada membro relacionado forneceu uma procuração. (nrs.help) Durante a disputa eleitoral da AFRINIC, a NRS pediu aos membros que informassem se seus nomes apareciam nos registros de eleitores ou se votos haviam sido registrados sem sua participação, e disse que esses relatos factuais seriam tratados pelos canais legais. (nrs.help)

Isso importa porque mostra a diferença entre representação jurídica e retórica comunitária.

O sistema dos RIRs frequentemente funde várias categorias em uma só: representante empresarial, contato de banco de dados, contato técnico, funcionário, consultor, procurador, participante de políticas, frequentador assíduo de lista de discussão. Essas categorias não são a mesma coisa.

Um contato de banco de dados pode ajudar a administrar registros.

Uma procuração pode autorizar a representação, se for válida e dentro de seu escopo.

Um participante de políticas pode contribuir com conhecimento especializado.

Uma pessoa que se manifesta em uma lista de discussão pode expressar uma opinião.

Nenhuma dessas condições transforma automaticamente essa pessoa em titular jurídico dos interesses de toda empresa, cliente, Estado, credor, financiador, comprador, locatário ou rede que arca com as consequências de uma decisão do registro.

Essa distinção só pode ser ignorada enquanto a camada comum permanece enxuta. Quando o registro reivindica poder sobre revogação, transferência, aluguel, acesso ao mercado, tratamento de sanções, continuidade dos ativos ou risco à infraestrutura nacional, a representação se torna uma questão constitucional.

Um fórum não é um mandato.

Uma lista de discussão não é um povo.

Um cadastro de contato não é uma procuração empresarial.

Uma região de atendimento não é uma coletividade soberana representada.

Isso não é preciosismo processual.

É a diferença entre coordenação e domínio.

Um sistema de Primazia do Código em Funcionamento evita essa armadilha ao reduzir o número de decisões que sequer exigem representação. Se a validade é determinística e local, há menos sobre o que votar. Se a mudança futura é voluntária, não é necessário decidir se quem não a adota está em situação irregular. Se o estado é representado em um livro-razão distribuído, não é necessário implorar a um registro estabelecido que reconheça a continuidade da própria existência. Se os conjuntos de compatibilidade são explícitos, os participantes sabem com quem podem interoperar sem consultar um fórum político.

O melhor problema de governança é aquele que a concepção do sistema elimina.

RIPE NCC e LACNIC: o clube e o ponto de estrangulamento

O RIPE NCC e o LACNIC não demonstram que alguns RIRs são mais civilizados do que outros. Demonstram que o modelo dos RIRs tem duas camadas de imposição além da função técnica: o clube e o ponto de estrangulamento.

O clube decide quem é respeitável. O ponto de estrangulamento decide quem pode movimentar sua situação registral.

A recusa do RIPE NCC em aceitar o patrocínio da LARUS para o RIPE 90 mostrou claramente a camada do clube. Um membro ofereceu patrocínio. O ecossistema ligado ao registro o rejeitou por causa de uma disputa sem relação com o evento em outra região. Não foi uma decisão de segurança do roteamento. Não foi uma decisão de unicidade. Não foi uma regra determinística de validação. Foi uma lista negra privada aplicada por meio do acesso a uma conferência. O LACNIC também recusou meu patrocínio. Outra região, o mesmo impulso: o clube dos registros se protege controlando espaços, visibilidade, patrocínio, reputação e legitimidade social.

Isso não é comunidade. É controle de acesso.

A camada das sanções é pior porque mostra o ponto central de estrangulamento em sua forma jurídica. O RIPE NCC afirma que, por estar sediado nos Países Baixos, deve cumprir as sanções da União Europeia; quando as sanções se aplicam, ele congela os registros no Banco de Dados RIPE, bloqueia aquisições e transferências e pode tratar casos como congelados quando uma parte não consegue fornecer documentação suficiente. Também verifica listas da OFAC porque as relações bancárias afetam os pagamentos. (Transparência do RIPE NCC sobre sanções)

Isso não é uma crítica ao RIPE NCC por cumprir a lei. Uma entidade neerlandesa deve obedecer às leis dos Países Baixos e da União Europeia. O problema é de arquitetura: por que uma única entidade privada neerlandesa deveria ser o ponto central de reconhecimento para a mobilidade de recursos numéricos entre tantos países, operadores e sistemas jurídicos?

Sanções podem vincular um banco. Sanções podem vincular uma entidade neerlandesa. Sanções podem vincular uma contraparte que decide não realizar uma transação. Não deveriam se tornar uma condição global de validade técnica para todos os demais.

Essa é a falha de concepção.

A mesma centralidade que permite a um clube excluir um crítico também permite a uma jurisdição congelar a mobilidade registral. Uma é imposição social. A outra é imposição jurídica. Ambas só funcionam porque o registro ocupa o lugar em que a validade não deveria estar.

Isso se conecta diretamente aos três princípios.

Especificação Inicial Mínima: respeitabilidade no clube, elegibilidade para patrocínio, política regional, classificação de sanções e reputação nunca devem entrar na camada comum. A camada comum deveria conter apenas regras determinísticas para unicidade, prova de controle, tratamento de conflitos, transição de estado e segurança.

Decisão Futura Localizada: risco jurídico, escolha de contraparte, patrocínio, confiança comercial e exposição a sanções pertencem aos atores que arcam com eles. Uma entidade neerlandesa pode recusar uma transação. Um banco pode recusar um pagamento. Uma contraparte pode recusar uma relação comercial. Nada disso deveria se tornar uma verdade registral universal.

Adoção Voluntária: os participantes aceitam contrapartes executando código, validando estados e escolhendo com quem interoperar. Não adotar não é má conduta. Recusa local não é invalidade global. A recusa de um clube não deveria apagar um estado válido. Uma obrigação relativa a sanções deveria restringir o ator sujeito a ela, não reescrever o livro-razão mundial dos recursos numéricos.

É por isso que a arquitetura de livro-razão distribuído é necessária. Em um sistema pós-RIR, a validade ordinária não é decidida pelo RIPE NCC, pelo LACNIC, por um setor de sanções, por um comitê de reuniões ou por um departamento de patrocínio. Os participantes validam o estado localmente. As contrapartes aceitam ou rejeitam voluntariamente. As bifurcações são visíveis. Os conjuntos de compatibilidade são explícitos. O registro central desaparece como fonte da verdade.

A solução não é melhorar a etiqueta.

A solução não é tornar mais transparente a fila de análise de sanções.

A solução é retirar a validade tanto do clube quanto do ponto de estrangulamento.

Estado distribuído. Validação local. Aceitação voluntária de contrapartes. Nenhum registro como fonte da validade.

A carta da NRO: a fuga para cima

A evidência mais grave não é a tentativa de extrapolação da AFRINIC.

É a resposta coletiva do sistema.

Em 2022, a Number Resource Organization escreveu ao governo de Maurício. A carta descrevia a NRO como o órgão de coordenação dos RIRs do mundo e dizia que os RIRs administram recursos numéricos em suas respectivas regiões. Afirmava que todos os cinco registros exercem a função de administrar recursos numéricos segundo regras adotadas regionalmente ou políticas globais adotadas por unanimidade. (nro.net)

A mesma carta criticava os processos movidos pela Cloud Innovation, dizia que mais de 25 ações judiciais haviam sido ajuizadas, reclamava de ordens judiciais que congelaram as contas da AFRINIC e interromperam eleições, e afirmava que a AFRINIC havia solicitado repetidamente a Maurício que a reconhecesse como uma organização internacional. A NRO instava o governo a adotar medidas para preservar a independência da AFRINIC e a estabilidade da Internet na África. (nro.net)

Esse é o documento mais revelador de toda a história.

Quando um registro privado entrou em conflito com os tribunais comuns, o reflexo do sistema não foi restringir o mandato.

Não foi eliminar o aprisionamento ao registro.

Não foi separar a manutenção de registros da imposição de regras.

Não foi definir a validação distribuída.

Não foi perguntar se o poder unilateral de cancelar o registro de ativos em funcionamento era ilegítimo desde o início.

O reflexo foi fugir para cima.

Um órgão privado de coordenação não pode ser técnico quando quer discricionariedade, comunitário quando quer legitimidade, contratual quando quer cobrar taxas, contrário à noção de propriedade quando quer evitar a responsabilidade jurídica ligada à titularidade e quase internacional quando quer se proteger dos tribunais.

Esse pacote não é governança.

É lavagem de mandato no nível do sistema.

Se os RIRs querem privilégios de direito público, devem aceitar a responsabilização de direito público. Se querem a flexibilidade do direito privado, devem aceitar os litígios de direito privado. O que não podem exigir racionalmente é discricionariedade privada, importância de infraestrutura pública, responsabilidade reduzida, representação frágil, condição de monopólio e proteção quase diplomática ao mesmo tempo.

Esse é o caminho para o desastre.

A Primazia do Código em Funcionamento o rejeita.

Quando um registro encontra resistência jurídica, não deve fugir para cima em busca de imunidade. A arquitetura deve se contrair para baixo, até a função restrita do código em funcionamento que a justificou.

Menos soberania.

Nenhum registro como fonte da validade.

Menos imposição.

Mais validação distribuída.

A revisão do ICP-2 não basta

O sistema atual sabe que algo se rompeu.

A página de comentários públicos da ICANN sobre a segunda versão preliminar do Documento de Governança dos RIRs diz que a proposta estabeleceria regras e critérios para o reconhecimento de novos RIRs, obrigações e requisitos operacionais dos RIRs e regras para a retirada de reconhecimento; se adotada, substituiria o ICP-2. A mesma página diz que o processo foi iniciado depois que a NRO pediu à ASO que propusesse atualizações para tornar o sistema dos RIRs mais responsável perante a comunidade da Internet. (icann.org)

Isso pode ser necessário como medida de continuidade.

Não é suficiente como teoria de legitimidade.

Regras de reconhecimento e retirada de reconhecimento respondem a uma pergunta tardia: quando um registro falhou gravemente o suficiente para ser removido?

A pergunta anterior é mais importante: por que um registro deveria ter, desde o início, poder suficiente para falhar de maneira catastrófica?

Um sucessor do ICP-2 que apenas torne mais rigorosos o reconhecimento, a auditoria, a transferência de responsabilidades e a retirada de reconhecimento pode melhorar a higiene institucional enquanto preserva o erro de categoria. Ainda pressupõe que o RIR é a principal forma soberana de coordenação dos recursos numéricos.

A Primazia do Código em Funcionamento faz outro conjunto de perguntas.

Como a Internet continua se um RIR entrar em colapso?

Como as reivindicações sobre recursos numéricos permanecem verificáveis sem a permissão do registro estabelecido?

Como a unicidade sobrevive sem a discricionariedade de um monopólio?

Como impedir que os registros cadastrais se tornem armas de imposição?

Como manter as decisões comerciais fora da validade determinística, a menos que um verdadeiro invariante global esteja em risco?

Como a coordenação permanece utilizável sem nenhum registro dotado de autoridade?

Como um operador valida o estado ordinário sem pedir a uma entidade permanente que determine sua situação?

Como evitar que a recusa se torne um rótulo de infração?

Essas não são perguntas de reforma.

São perguntas pós-RIR.

Por que esta é a correção da concepção original

A questão não é gostar ou deixar de gostar dos registros estabelecidos.

A questão é se a camada dos recursos numéricos ainda segue a disciplina de projeto que fez a Internet funcionar: regras comuns mínimas, validação local, adoção voluntária e código em funcionamento.

A Primazia do Código em Funcionamento não é uma estratégia de relações públicas nem uma acomodação institucional. É a correção técnica implícita na concepção original. Se a Internet foi construída para rejeitar reis, presidentes e votações como fontes da verdade técnica, a camada dos recursos numéricos não pode recriar essas formas por meio dos procedimentos dos registros, da delegação histórica ou do teatro comunitário.

O consenso, sozinho, pode ser ritualizado. O código em funcionamento, sozinho, pode ser subordinado se a camada dos registros estiver a montante do reconhecimento. A regra que falta é interpretativa e arquitetural: quando os procedimentos institucionais entram em conflito com a função técnica mínima exigida pelos sistemas em funcionamento, o código em funcionamento tem prioridade; e, quando se propõe uma mudança posterior, ela só se torna real por meio da adoção voluntária pelos participantes que executam regras de validação.

É assim que se preserva a concepção original, em vez de abandoná-la.

A Internet foi importante porque se tornou o primeiro sistema global de comunicação que não exigia permissão prévia de um único soberano, ministério, igreja, empresa ou controlador de acesso. Se essa conquista ainda merece ser defendida, a camada dos registros não pode se tornar a exceção que engole a regra.

Um sistema construído para evitar reis não pode permitir que um escriturário se candidate a ser um.

A correção restaura a hierarquia original: código primeiro, operadores primeiro, validação determinística primeiro, estado distribuído primeiro; instituições, se alguma permanecer durante a transição, apenas como artefatos sem autoridade, nunca como fontes da validade.

O que a coordenação pós-RIR exige

Coordenação pós-RIR não significa caos.

Significa que a camada comum se torna mais enxuta, mais objetiva, mais determinística e mais distribuída do que o atual monopólio dos RIRs.

Não existe um registro para o qual migrar.

Não existe um novo registro a coroar.

Não existe um sacerdócio substituto.

Existe um livro-razão distribuído do estado dos recursos numéricos, com regras determinísticas de validação, mecanismos de prova de controle, tratamento de conflitos, conjuntos de compatibilidade, histórico de transições de estado e verificação local pelos participantes.

A camada comum deveria preservar a unicidade dos identificadores, a prova de controle, o estado das transferências, o estado das delegações, as declarações de segurança ligadas ao roteamento, a auditabilidade, os metadados de conflitos e a visibilidade das bifurcações.

A camada dos operadores deveria controlar o uso comercial, o aluguel, a localização dos clientes, as práticas de roteamento, o financiamento, a seleção de contrapartes e as regras de negócios que não constituem invariantes.

A camada de adoção deveria determinar o que se torna real. Uma regra de coordenação só importa se os operadores puderem implementá-la, as contrapartes puderem aceitá-la, os mercados puderem se apoiar nela, os tribunais puderem compreendê-la e a interoperabilidade for preservada sem fazer do reconhecimento pelo registro estabelecido a única fonte da realidade.

A camada de imposição não deve ser fundida com a camada de estado. Um livro-razão distribuído pode registrar o estado. Pode validar transições. Pode expor conflitos. Pode tornar a prova portátil. Não deve se tornar, ao mesmo tempo, acusador, juiz, autoridade sancionadora, regulador de mercado, moralista comercial e custodiante de ativos.

Acima de tudo, a portabilidade precisa ser compreendida corretamente.

Em um mundo de livros-razão distribuídos, portabilidade não significa migrar de um registro para outro. Isso ainda é pensar segundo a lógica dos registros. Não existe um registro para o qual migrar. A prova de controle, o histórico de estado e a capacidade de transferência do detentor não estão presos dentro do banco de dados de uma instituição estabelecida. Existem em um estado compartilhado verificável que os participantes validam localmente e as contrapartes aceitam voluntariamente.

Sem isso, todo registro é um ponto de aprisionamento.

Com isso, o registro desaparece como fonte da validade.

A coordenação pós-RIR, portanto, precisa de quatro propriedades de projeto.

Primeiro, validade determinística. Um participante deveria saber se uma transição de estado, uma prova, uma delegação, uma transferência ou uma declaração é válida aplicando a especificação localmente.

Segundo, conjuntos de compatibilidade. Se os participantes adotarem regras futuras diferentes, o sistema deveria descrever claramente o limite de compatibilidade, em vez de tratar a divergência como má conduta.

Terceiro, prova de controle distribuída. Um detentor não deveria “migrar” seus recursos para outro registro; deveria demonstrar o controle por meio de um estado válido no livro-razão que qualquer contraparte possa verificar sem a bênção do registro estabelecido.

Quarto, visibilidade das bifurcações. Se os conjuntos de regras divergirem, a divergência deveria ser explícita. Os participantes decidem qual conjunto de compatibilidade executar e quais contrapartes aceitar. Uma bifurcação pode isolar participantes. Não confere a um lado poder institucional para apagar o outro.

Esse não é um argumento a favor de cinco monopólios melhores.

É um argumento contra o monopólio como fonte da validade.

Por que o caminho da falha é previsível

Se nada mudar, o caminho da falha é claro.

Primeiro, mais disputas sairão dos fóruns de políticas e chegarão aos tribunais. Ativos escassos atraem escrutínio jurídico. Os tribunais serão chamados a congelar contas, preservar registros, bloquear eleições irregulares, nomear administradores judiciais, reconhecer transferências ou determinar quem pode agir em nome de um registro.

Segundo, os Estados deixarão de tratar os RIRs como associações técnicas inofensivas. A continuidade dos recursos numéricos envolve conectividade nacional, sanções, aplicação da lei, resiliência das telecomunicações, infraestrutura de nuvem e segurança econômica. Nenhum Estado aceitará para sempre uma estrutura jurídica privada estrangeira de registro como ponto a montante da continuidade das comunicações nacionais sem submetê-la a exame.

Terceiro, os operadores contornarão a autoridade dos registros sempre que possível. Se os registros cadastrais se tornarem políticos, inseguros, não representativos ou dissociados da realidade dos ativos, os operadores recorrerão a contratos privados, transferências respaldadas por decisões judiciais, atestações alternativas, reconhecimento nacional ou à realidade do roteamento de fato.

Quarto, a ICANN e a camada da NRO serão tentadas a centralizar. Isso produziria uma versão mais pesada do mesmo problema, a menos que o próprio mandato fosse restringido.

Quinto, os governos serão tentados a nacionalizar. Isso seria previsível e perigoso. Se registros privados reivindicam autoridade quase soberana sem responsabilização pública, os Estados acabarão por retomar a soberania. O resultado pode ser fragmentação, retaliação, registros conflitantes e pressão política sobre o roteamento.

A Internet não falha apenas quando os pacotes param de circular.

Também falha quando as instituições que descrevem quem pode usar os identificadores perdem a confiança dos operadores que fazem os pacotes circular.

Um livro-razão distribuído não resolve todos os problemas políticos. Faz algo mais importante: elimina o registro permanente como fonte ordinária da validade. Isso restringe a superfície de ataque. Reduz o poder institucional de manter reféns. Transforma as divergências futuras em seleção de compatibilidade, em vez de guerra administrativa.

A pergunta muda

O antigo sistema pergunta: quem tem o mandato?

Essa é a pergunta errada.

A pergunta melhor é: o que o código em funcionamento realmente exige?

Esta regra protege a unicidade?

Preserva a interoperabilidade?

Corrige fraudes demonstráveis de registro por meio de evidências determinísticas?

Protege a segurança ligada ao roteamento?

Mantém a precisão da prova de controle?

Permite a validação local?

Elimina a dependência de uma única instituição estabelecida?

Descreve a realidade adotada ou declara uma obrigação não adotada?

Um participante pode recusá-la sem receber uma condição de invalidade?

Um participante pode verificar a validade ordinária sem pedir a um registro que determine sua situação?

Uma contraparte pode aceitar ou rejeitar o estado voluntariamente?

Uma bifurcação pode ocorrer sem que um dos lados seja apagado por uma instituição?

Se a resposta não estiver ligada a uma necessidade determinística do código em funcionamento, esse poder não deveria estar na camada comum.

Isso é a Primazia do Código em Funcionamento.

Para discussão

Esta proposta é para discussão. Não é uma solução definitiva.

O próximo passo deveria ser um documento sério no formato Internet-Draft ou no estilo BCP que defina a Primazia do Código em Funcionamento para sistemas de coordenação da Internet, começando pelos recursos numéricos. A minuta não deveria perguntar como reabilitar o monopólio dos RIRs. Deveria perguntar como construir a coordenação pós-RIR por meio do estado de um livro-razão distribuído, de validação determinística, de adoção voluntária, da aceitação de contrapartes e de conjuntos explícitos de compatibilidade.

Ela deveria ser testada por operadores, advogados, economistas, engenheiros de protocolos, especialistas em segurança do roteamento, participantes do mercado, governos e críticos.

A minuta deveria fazer perguntas difíceis.

Quais são os invariantes globais?

Quais regras de validação são determinísticas?

Quais transições de estado devem ser globalmente visíveis?

Quais poderes dos antigos registros são resíduos históricos?

Quais decisões pertencem aos operadores?

Quais decisões não exigem representação porque nunca deveriam entrar na camada comum?

Qual é o caminho de recusa?

Qual é o caminho de bifurcação?

Qual é o caminho de rejeição local?

Como um detentor prova o controle sem um registro estabelecido?

Como uma contraparte verifica o estado sem um registro?

A Internet pode continuar se um RIR entrar em colapso?

Os recursos numéricos podem permanecer únicos sem a permissão do registro estabelecido?

Um participante pode validar o estado ordinário sem uma instituição permanente?

Um processo de políticas pode distinguir um invariante do código em funcionamento do apetite institucional?

A antiga camada dos registros pode desaparecer sem que se perca o estado verificável?

Um registro cadastral pode descrever a realidade sem se tornar soberano sobre ela?

Quem tiver interesse pode entrar em contato comigo pelo LinkedIn. Pesquisadores sérios, autores técnicos, instituições ou especialistas em políticas que queiram ajudar a transformar isso em um primeiro Internet-Draft e, futuramente, em uma discussão de RFC ou BCP, caso a comunidade considere útil, devem entrar em contato comigo. A LARUS Foundation e eu estamos dispostos a apoiar e financiar pesquisas sérias nessa direção.

A primeira concepção do sistema dos RIRs falhou porque nunca perguntou o que o código em funcionamento realmente exigia.

Perguntou quem podia falar no fórum.

O próximo sistema precisa inverter essa ordem.

Sem lavagem de mandato.

Sem traição ao código em funcionamento.

Primazia do Código em Funcionamento.

Apêndice: Especificação Inicial Mínima, Decisão Futura Localizada e Adoção Voluntária para Sistemas de Coordenação da Internet

Nota 64

Resumo

Este documento descreve um padrão de projeto para sistemas de coordenação da Internet cujo propósito é fornecer pontos de referência técnicos compartilhados sem criar uma autoridade permanente acima dos participantes que operam o sistema. Ele define três princípios interligados: Especificação Inicial Mínima, Decisão Futura Localizada e Adoção Voluntária.

Nesse modelo, a Especificação Inicial define apenas as regras determinísticas e verificáveis localmente exigidas para unicidade, interoperabilidade, prova de controle, segurança operacional compartilhada e segurança. Depois da Especificação Inicial, as mudanças futuras não são aprovadas por uma entidade central. São adotadas, ignoradas, bifurcadas ou abandonadas pelos participantes que executam código.

O padrão de projeto pretendido é um livro-razão distribuído de estados válidos, ou um mecanismo distribuído equivalente de estado verificável, não uma hierarquia de registros. Não existe um registro permanente que decida a validade ordinária. Os participantes validam o estado localmente, aceitam contrapartes voluntariamente e decidem quais conjuntos de compatibilidade executam.

A não adoção não é uma infração. Um participante que não adota uma mudança posterior permanece em seu conjunto de compatibilidade existente. Um participante que emite um estado não válido segundo as regras determinísticas aceitas por outro participante pode ser ignorado localmente por esse participante. O efeito é seleção de compatibilidade, bifurcação, isolamento ou interoperação seletiva, não punição institucional.

Este documento não define um protocolo de comunicação. Ele especifica uma Melhor Prática Atual para o projeto de protocolos, sistemas de identificadores, livros-razão distribuídos e mecanismos de coordenação que não devem se tornar instituições permanentes de governança.

1. Introdução

Muitos sistemas da Internet começam com um propósito técnico restrito: permitir que atores independentes interoperem compartilhando um ponto de referência comum, um espaço de identificadores, uma regra de validação, um estado de livro-razão ou um registro de prova de controle. Com o tempo, esses sistemas frequentemente acumulam autoridade que não era necessária para a interoperabilidade inicial.

Isso costuma acontecer em três etapas.

Primeiro, questões futuras são inseridas na camada fundadora antes de serem tecnicamente necessárias.

Segundo, escolhas que deveriam ser feitas pelos participantes que operam seus próprios sistemas passam a depender de decisões de reconhecimento, interpretação ou situação tomadas por uma entidade permanente.

Terceiro, publicação, registro, recomendação ou aprovação processual são tratados como suficientes para criar uma obrigação operacional, mesmo quando os participantes não adotaram a mudança nos sistemas em funcionamento.

O resultado é um sistema frágil. Uma camada de referência técnica se torna uma camada de governança. Um responsável pela manutenção de registros se torna um controlador de acesso. Um artefato de coordenação se torna uma fonte de controle futuro.

Este documento propõe uma disciplina de projeto diferente:

Especificação Inicial Mínima: especificar apenas as regras comuns determinísticas exigidas para interoperabilidade básica, unicidade, prova de controle, segurança operacional compartilhada e segurança.
Decisão Futura Localizada: depois da Especificação Inicial, manter as escolhas futuras com os participantes que executam código. Um participante pode adotar, recusar, criar uma bifurcação, se desconectar ou interoperar seletivamente. Nenhum participante pode alterar a interoperabilidade dos demais participantes que continuam executando regras mutuamente compatíveis.
Adoção Voluntária: tornar uma mudança posterior real apenas por meio de implementação, operação, validação e adoção pelos participantes que executam código.

Esses princípios estão relacionados. Um sistema que especifica demais no início embute controle futuro na camada comum. Um sistema que mantém uma camada permanente de reconhecimento permite que a autoridade reapareça depois da implantação. Um sistema que trata a publicação como realidade converte documentação em comando.

A intuição de projeto é simples: a validade deve ser determinada por regras determinísticas que os participantes possam verificar localmente em relação ao estado compartilhado. Um participante pode adotar uma mudança posterior, recusá-la, criar uma bifurcação, se desconectar ou interoperar seletivamente. No máximo, pode retirar a si mesmo de um conjunto de compatibilidade. Não pode, ao recusar uma mudança, quebrar a interoperabilidade dos demais participantes que continuam executando código mutuamente compatível.

Essa é a lição geral do projeto de livros-razão distribuídos: as regras de consenso são aplicadas pelos participantes que executam código de validação e decidem quais estados aceitam, não por uma instituição situada acima deles.

2. Escopo

Este documento se aplica a sistemas de coordenação da Internet, incluindo, entre outros, sistemas de identificadores, estruturas de nomes e numeração, mecanismos de extensão de protocolos, sistemas de prova de controle, sistemas de portabilidade, livros-razão distribuídos e outras arquiteturas nas quais atores independentes dependem de um ponto de referência técnico comum.

Este documento não argumenta contra regras comuns. Argumenta que as regras comuns deveriam ser determinísticas, mínimas, verificáveis localmente e limitadas ao que o sistema realmente precisa para funcionar.

Este documento não exige nenhuma implementação específica de livro-razão distribuído. Exige uma propriedade de projeto: os participantes deveriam ser capazes de determinar a validade aplicando localmente a Especificação Inicial ao estado compartilhado ou replicável, sem pedir permissão ou uma determinação de situação a uma autoridade permanente.

3. Convenções e definições

3.1. Linguagem de requisitos

Os termos de requisito em letras maiúsculas neste documento devem ser interpretados no sentido definido pelo BCP 14, especificamente pelos RFCs 2119 e 8174.

3.2. Terminologia

Especificação Inicial:
O conjunto de regras, estruturas de dados, formatos, invariantes, procedimentos de validação, regras de transição de estado e regras de conflito exigidos para a primeira implantação de um sistema.

Camada Comum:
O conjunto mínimo de regras compartilhadas ou a estrutura de referência mínima necessária para que participantes independentes interoperem. A camada comum não é uma instituição. É a substância técnica que os participantes implementam e verificam.

Livro-Razão Distribuído:
Um registro replicado ou distribuído de outra forma das transições de estado que permite aos participantes verificar a validade ordinária sem depender de um registro, comitê ou outra autoridade permanente. O termo não exige nenhum algoritmo de consenso ou implementação em particular.

Regra Determinística de Validação:
Uma regra que permite a um participante decidir, por cálculo local ou verificação local, se um estado, registro, transição, declaração ou mensagem é válido segundo um conjunto de regras especificado.

Invariante Global:
Uma propriedade que deve permanecer comum dentro de um conjunto de compatibilidade para preservar a unicidade, a interoperabilidade básica, a integridade da prova de controle, a segurança operacional compartilhada ou a segurança.

Participante:
Um operador, implementação, nó, rede, organização ou outro ator que opera, verifica, implanta ou se apoia no sistema.

Conjunto de Compatibilidade:
Um grupo de participantes cujas regras de validação implementadas lhes permitem interoperar. Uma mudança posterior pode criar um novo conjunto de compatibilidade se alguns participantes a adotarem e outros não.

Adoção:
Implementação, implantação, validação e uso efetivos pelos participantes que operam o sistema.

Aceitação de Contraparte:
A decisão voluntária de um participante de aceitar o estado de outro participante, transacionar ou interoperar com ele, ou se apoiar nesse estado segundo as regras de validação que executa.

Não Adoção:
A escolha de um participante de não implementar ou usar uma mudança proposta. A não adoção não cria uma condição de invalidade. Significa apenas que o participante não ingressou no conjunto de compatibilidade criado por essa mudança.

Rejeição Local:
A decisão local de um participante de ignorar, rejeitar ou não interoperar com um estado, mensagem, registro ou transição que seja inválido ou incompatível segundo as regras de validação que executa.

Bifurcação:
Uma divergência nas regras de validação ou na prática operacional que cria dois ou mais conjuntos de compatibilidade.

Artefato de Coordenação:
Um documento, recomendação, nota de implementação, perfil, implementação de referência, explorador de livro-razão, espelho ou outro artefato que ajude os participantes a se coordenar. Um artefato de coordenação não cria uma realidade operacional vinculante a menos que os participantes o adotem em sistemas em funcionamento.

4. Definição do problema

Os projetistas frequentemente tentam reduzir a incerteza futura incluindo conteúdo demais na camada fundadora ou mantendo uma entidade permanente para interpretar questões futuras. Isso parece prudente. Muitas vezes, é perigoso.

A especificação excessiva na camada fundadora tem três custos.

Primeiro, transfere escolhas futuras para uma camada comum em que mudar é mais difícil e a captura tem maior efeito.

Segundo, cria ambiguidade entre validade técnica e reconhecimento institucional.

Terceiro, incentiva uma entidade que mantém registros, publica documentos ou reúne participantes a tratar esses atos como autoridade sobre a realidade futura.

O mesmo problema aparece depois da implantação. Se um sistema exige uma entidade permanente para aprovar mudanças, determinar situações ou interpretar a operação ordinária, o sistema criou uma camada de controle posterior à fundação. Essa camada pode começar como administração. Pode se tornar governança. E pode, então, se tornar um ponto de estrangulamento.

O objetivo de projeto deste documento não é melhorar a discricionariedade institucional. O objetivo é evitar a necessidade dessa discricionariedade.

Um sistema de coordenação da Internet bem projetado deveria definir, desde o início, regras de validade determinísticas e verificáveis localmente; representar o estado válido de forma distribuída ou de outra forma replicável; manter as escolhas que não constituem invariantes fora da camada comum; e permitir que mudanças posteriores só se tornem reais quando os participantes as adotarem voluntariamente em sistemas em funcionamento.

5. Princípio 1: Especificação Inicial Mínima

5.1. Enunciado

Uma Especificação Inicial DEVERIA definir apenas as regras comuns determinísticas mínimas exigidas para interoperabilidade básica, unicidade, prova de controle, segurança operacional compartilhada e segurança.

5.2. Requisitos

Um projeto que use este princípio:

DEVE identificar explicitamente seus Invariantes Globais.
DEVE definir regras determinísticas de validação para cada Invariante Global.
DEVE definir como o estado válido é representado, replicado, verificado e atualizado.
NÃO DEVE incluir uma regra na Especificação Inicial a menos que ela seja necessária para preservar um Invariante Global declarado ou para permitir a primeira implantação.
DEVE separar as regras de validação das preferências de políticas, dos arranjos de negócios, dos papéis institucionais, das aspirações de governança e do julgamento discricionário.
DEVE permitir que os participantes verifiquem a validade ordinária localmente, sem consultar nenhuma instituição, registro, comitê, órgão de políticas ou outra autoridade.
DEVERIA definir estruturas de dados, assinaturas, provas, regras de transição de estado, regras de conflito ou outros mecanismos necessários à verificação local.
DEVERIA definir sinalização de extensões, versionamento, identificação de compatibilidade ou identificação de bifurcações quando variações futuras forem previsíveis.
DEVE assegurar que os artefatos de coordenação exigidos sejam portáteis, auditáveis, reproduzíveis e substituíveis.
DEVERIA preferir condições objetivas verificáveis por máquina ao julgamento subjetivo de mérito.
NÃO DEVE fazer do reconhecimento institucional futuro o único caminho pelo qual um estado válido possa ser conhecido, registrado ou utilizado.

5.3. Implicações de projeto

Especificação Inicial Mínima não significa especificação vaga. Significa especificação rigorosa apenas daquilo que precisa ser comum.

Um sistema ainda precisa de estrutura comum suficiente para funcionar. A disciplina consiste em distinguir entre:

o que precisa ser comum para unicidade, interoperabilidade, prova de controle, segurança operacional compartilhada e segurança; e
o que pode permanecer fora da camada comum porque diz respeito à preferência do operador, à prática de negócios, à escolha de contraparte, ao momento de implantação ou à escolha posterior de adoção.

Um projeto que não consegue apresentar com clareza seus Invariantes Globais e suas regras determinísticas de validação deveria presumir que especificou discricionariedade demais e substância verificável de menos.

6. Princípio 2: Decisão Futura Localizada

6.1. Enunciado

Depois da Especificação Inicial, as Decisões Futuras DEVERIAM permanecer no âmbito local dos participantes que executam código. Uma Decisão Futura só se torna efetiva para o conjunto de compatibilidade cujos participantes a adotam. Nenhuma autoridade permanente é necessária para aprová-la, e a não adoção não cria uma condição de invalidade.

6.2. Requisitos

Um projeto que use este princípio:

NÃO DEVE exigir que os participantes obtenham permissão de uma instituição estabelecida, registro, comitê, conselho, órgão de políticas ou outra autoridade para escolhas que não alterem as regras determinísticas de validação do conjunto de compatibilidade do qual participam.
NÃO DEVE criar uma entidade permanente cujo reconhecimento seja o único caminho pelo qual uma mudança posterior possa se tornar operacionalmente real.
DEVE distinguir a validade segundo a Especificação Inicial da compatibilidade com uma mudança opcional posterior.
NÃO DEVE tratar a não adoção de uma mudança posterior como invalidade.
DEVE permitir que os participantes permaneçam em um conjunto de compatibilidade existente quando não adotarem uma mudança posterior.
DEVE permitir que os participantes ingressem em um novo conjunto de compatibilidade ao adotar novas regras de validação ou perfis operacionais.
DEVE permitir que os participantes rejeitem localmente estados, registros, transições ou mensagens que sejam inválidos ou incompatíveis segundo as regras de validação que executam.
DEVE permitir que os participantes escolham contrapartes voluntariamente, de acordo com as regras de validação e os conjuntos de compatibilidade que aceitam.
NÃO DEVE autorizar nenhuma instituição, registro, comitê, órgão de políticas ou outro ator a declarar um participante inválido simplesmente porque ele recusou uma mudança posterior.
DEVERIA tornar explícitos as bifurcações, as versões, os perfis ou os conjuntos de compatibilidade, para que os participantes saibam quais regras estão executando e com quais outros participantes podem interoperar.
DEVERIA evitar qualquer projeto no qual um responsável estabelecido pela manutenção de registros possa impedir participantes, de resto válidos, de continuar interoperando.

6.3. Implicações de projeto

Decisão Futura Localizada não significa que uma autoridade central atribui decisões futuras a atores locais. Significa que o sistema é projetado para que, depois da Especificação Inicial, as escolhas futuras ordinárias não precisem dessa atribuição.

A Especificação Inicial estabelece os limites de antemão. Define os invariantes mínimos exigidos para unicidade, interoperabilidade, prova de controle, segurança operacional compartilhada e segurança. Todo o restante permanece fora da camada comum.

A mudança futura não é aprovada centralmente. É adotada, ignorada, bifurcada ou abandonada pelos participantes que executam código.

Um participante que recusa uma mudança pode permanecer fora do conjunto de compatibilidade criado por ela. Pode se desconectar dos demais. Pode continuar em um conjunto de compatibilidade mais antigo. Pode criar uma bifurcação. Pode interoperar seletivamente. Mas não pode quebrar a interoperabilidade dos demais participantes que continuam executando regras mutuamente compatíveis.

O efeito de um estado inválido ou incompatível é a rejeição local, não a punição. Ninguém precisa decidir que um participante está em situação irregular. Um participante que executa regras de validação compatíveis simplesmente não aceita o estado inválido ou incompatível.

7. Princípio 3: Adoção Voluntária

7.1. Enunciado

As mudanças em um sistema de coordenação da Internet DEVERIAM se tornar operacionalmente reais por meio de implementação, validação, implantação, aceitação de contrapartes e adoção pelos participantes, não apenas por publicação ou declaração.

7.2. Requisitos

Um projeto que use este princípio:

NÃO DEVE tratar publicação, recomendação, aprovação em reunião ou aprovação processual como suficientes para criar uma obrigação operacional universal.
DEVE permitir que novas regras, extensões, perfis ou procedimentos sejam implantados de forma incremental pelos participantes que escolhem executá-los.
DEVE permitir que os participantes recusem uma mudança posterior sem adquirir uma condição de invalidade, desde que suas próprias transições de estado satisfaçam as regras determinísticas de validação de seu conjunto de compatibilidade.
DEVE permitir que os participantes continuem usando um conjunto de compatibilidade mais antigo quando a Especificação Inicial permitir essa continuidade.
DEVE permitir que participantes que executam um conjunto de compatibilidade rejeitem ou ignorem localmente o estado de outro conjunto de compatibilidade quando as regras forem incompatíveis.
DEVERIA definir caminhos de adoção para mudanças importantes, incluindo sinalização de versão, identificação de compatibilidade, orientações de transição e vetores de teste.
DEVERIA definir caminhos de recusa para mudanças importantes, incluindo como os participantes que não as adotam continuam operando, identificam seu conjunto de compatibilidade e evitam interoperação ambígua.
DEVE assegurar que os artefatos de coordenação exigidos possam deixar de ser usados, ser espelhados, reimplementados ou substituídos sem um custo de transição inviável.
DEVERIA fazer com que registros, recomendações e artefatos de coordenação descrevam a realidade adotada, em vez de tentar fazer existir por declaração uma realidade futura não adotada.
DEVE evitar projetar um sistema no qual a única maneira de uma mudança se tornar real seja o reconhecimento prévio por uma entidade estabelecida.

7.3. Implicações de projeto

A Adoção Voluntária é o teste operacional de se uma mudança é útil, tolerável e compatível com a implantação real.

Uma proposta não é realidade. Uma recomendação não é realidade. Um documento não é realidade. A realidade surge quando os participantes implementam, validam, implantam, aceitam contrapartes e se apoiam na mudança.

A não adoção não cria uma condição de infração. Cria apenas um fato: o participante não ingressou no conjunto de compatibilidade criado pela mudança.

Isso não elimina processos de padronização, documentação, notas de implementação, exploradores, espelhos ou revisão. Limita sua pretensão. Eles podem ajudar os participantes a se coordenar. Podem publicar material de referência. Podem descrever a adoção. Podem recomendar. Não podem, apenas por declaração, tornar uma realidade futura não adotada vinculante para participantes que não a executam.

8. Relação entre os três princípios

Os três princípios se reforçam mutuamente e não são eficazes isoladamente.

A Especificação Inicial Mínima assegura que a camada comum contenha regras determinísticas de validação, em vez de autoridade discricionária.

A Decisão Futura Localizada assegura que as escolhas futuras permaneçam com os participantes que executam código, em vez de serem recapturadas por uma camada central de aprovação.

A Adoção Voluntária assegura que uma mudança posterior precise sobreviver ao contato com a implementação, a verificação, a aceitação de contrapartes e o uso.

Um sistema que adote apenas um ou dois desses princípios pode reproduzir a mesma centralização por outros meios.

A Especificação Inicial Mínima sem a Decisão Futura Localizada ainda pode permitir que a autoridade se acumule depois da implantação.
A Decisão Futura Localizada sem a Especificação Inicial Mínima pode produzir ambiguidade, porque os participantes não conseguem determinar a validade localmente.
A Adoção Voluntária sem validação determinística pode produzir confusão, porque os participantes não conseguem distinguir uma variação compatível de um estado inválido.
A validação determinística sem estado distribuído ainda pode deixar os participantes dependentes de um responsável privilegiado pela manutenção de registros.
O estado distribuído sem visibilidade das bifurcações pode ocultar divergências até ocorrer uma falha operacional.
O estado distribuído sem aceitação voluntária de contrapartes pode recriar a coerção por outra interface.

Juntos, os princípios produzem um sistema no qual a camada comum é enxuta, a validade é verificável localmente, a mudança futura é voluntária, o estado é distribuído e nenhuma instituição permanente é necessária para decidir a operação ordinária.

9. Padrão de projeto recomendado

9.1. Camada comum determinística e distribuída

A camada comum DEVERIA se limitar a:

semântica estável dos identificadores;
regras determinísticas de validade;
regras de resolução de conflitos necessárias à preservação da unicidade;
mecanismos de prova de controle;
regras de transição de estado;
requisitos de interoperabilidade no nível da transmissão ou do protocolo;
invariantes de segurança compartilhados;
formatos de estado portáteis e auditáveis;
visibilidade do estado distribuído ou replicado;
sinalização de extensões e identificação de conjuntos de compatibilidade.

A camada comum NÃO DEVERIA conter:

regras de modelo de negócios;
regras de precificação;
preferências políticas regionais;
ideologia de elegibilidade sem relação com invariantes técnicos;
poderes discricionários de imposição;
avaliações subjetivas de mérito;
expansão da missão institucional;
qualquer regra cuja função principal seja preservar a autoridade de uma entidade estabelecida.

9.2. Âmbito de decisão do operador

Os seguintes aspectos DEVERIAM permanecer fora da camada comum, a menos que alterem diretamente um Invariante Global declarado:

momento de implantação;
uso comercial;
localização dos clientes;
arranjos de aluguel, financiamento ou transferência;
preferências locais de elegibilidade;
sequenciamento operacional;
práticas de roteamento não exigidas para a validade compartilhada;
modelo de negócios;
estrutura organizacional;
momento da migração voluntária;
perfis ou extensões opcionais;
escolha de contraparte.

Os participantes PODEM fazer escolhas diferentes nessas áreas. Essas escolhas podem produzir diferentes conjuntos de compatibilidade, relações de negócios, acordos de interconexão ou comunidades operacionais. Não criam invalidade a menos que violem regras determinísticas de validação em um conjunto de compatibilidade.

9.3. Ciclo de adoção

Quando viável, a ordem preferencial para uma mudança substancial no sistema é:

proposta;
implementação;
vetores de teste ou método determinístico de verificação;
implantação limitada por participantes dispostos a adotá-la;
observação dos efeitos sobre a interoperabilidade e a segurança;
identificação do conjunto de compatibilidade;
documentação ou recomendação que descreva a realidade adotada.

Um artefato de coordenação DEVERIA acompanhar a adoção, em vez de tentar se antecipar a ela e determiná-la.

9.4. Bifurcação, rejeição local e aceitação de contrapartes

Um projeto em conformidade DEVERIA tratar a bifurcação, a rejeição local e a aceitação de contrapartes como requisitos normais de projeto, em vez de falhas.

O sistema DEVERIA definir como um participante pode:

continuar em um conjunto de compatibilidade mais antigo;
adotar um conjunto de compatibilidade mais novo;
criar uma bifurcação para um conjunto de compatibilidade diferente;
verificar o estado sem depender de um responsável estabelecido pela manutenção de registros;
aceitar contrapartes voluntariamente;
rejeitar localmente um estado inválido ou incompatível;
interoperar seletivamente quando a compatibilidade permitir.

Um sistema que não possa ser bifurcado, verificado localmente ou aceito seletivamente sem destruir a operação válida provavelmente escondeu poder de governança dentro de sua função de manutenção de registros.

10. Aplicabilidade e limites

Este padrão de projeto é particularmente aplicável quando:

o sistema envolve múltiplos atores e múltiplas jurisdições;
a implantação independente importa;
a camada de coordenação deve permanecer enxuta;
a variação futura é provável, mas não pode ser prevista em detalhe;
o aprisionamento institucional criaria risco de governança;
a validade pode ser tornada determinística ou verificável localmente;
o estado distribuído pode reduzir o risco de captura institucional.

Ele pode ser menos diretamente aplicável quando:

a arquitetura pretendida é um único domínio administrativo;
um forte acoplamento em tempo real exige comportamento uniforme em todos os momentos;
a proteção da vida humana exige uniformidade global imediata;
a validade não pode ser verificada localmente por nenhum mecanismo viável.

Mesmo nesses casos, os projetistas ainda DEVERIAM minimizar a camada comum e evitar o controle discricionário futuro sempre que possível.

11. Não objetivos

Este documento não:

proíbe toda coordenação;
exige nenhuma implementação específica de livro-razão distribuído;
garante consenso;
garante neutralidade política;
exige que todos os participantes adotem toda mudança posterior;
trata a recusa em adotar como invalidade;
legitima um comportamento local incompatível que alegue compatibilidade;
elimina a necessidade de regras comuns críticas para a segurança.

12. Considerações de segurança

Uma camada de coordenação mais enxuta pode reduzir o risco de captura, limitar o alcance dos danos de um erro institucional e melhorar a capacidade de substituição. No entanto, o aumento da discricionariedade local e o estado distribuído também podem criar posturas de segurança inconsistentes, caminhos de rebaixamento, pressão por fragmentação, alegações ambíguas de compatibilidade, bifurcações inseguras, disputas sobre o estado do livro-razão e tentativas de falsificação de provas.

Os projetistas que aplicarem este documento DEVEM, portanto, especificar explicitamente os invariantes de segurança. Em particular:

os requisitos de autenticação e autorização necessários à validade compartilhada DEVEM ser determinísticos e verificáveis localmente;
os mecanismos de prova de controle DEVEM resistir a falsificação, repetição de mensagens e transferência não autorizada;
a negociação de versões e o tratamento de extensões DEVEM evitar rebaixamentos silenciosos quando a segurança for afetada;
os caminhos de recusa, bifurcação e substituição DEVEM ser analisados quanto aos riscos de abuso e negação de serviço;
as identificações de compatibilidade DEVERIAM ser claras o suficiente para impedir a interoperação acidental entre conjuntos de regras incompatíveis;
o estado distribuído DEVERIA ser suficientemente auditável e reproduzível para permitir a detecção de visões inconsistentes;
NÃO DEVE ser permitido que uma variação local alegue falsamente compatibilidade com um conjunto de regras que não satisfaz.

A existência de exceções de segurança não justifica uma camada geral de permissão. Justifica apenas as regras determinísticas de segurança necessárias para preservar os Invariantes Globais declarados.

13. Considerações sobre a IANA

Este documento não prevê ações da IANA.

14. Referências

14.1. Referências normativas

RFC 2119 — Bradner, S., Palavras-chave para uso em RFCs para indicar níveis de requisito, BCP 14, RFC 2119.
RFC 8174 — Leiba, B., Ambiguidade entre maiúsculas e minúsculas nas palavras-chave do RFC 2119, BCP 14, RFC 8174.

14.2. Referências informativas

RFC 6709 — Carpenter, B. e B. Aboba, Considerações de projeto para extensões de protocolos, RFC 6709.
RFC 7282 — Resnick, P., Sobre consenso e manifestações por murmúrio na IETF, RFC 7282.

Apêndice A. Lista de verificação de projeto

Um projeto que alegue conformidade com este documento DEVERIA ser capaz de responder com clareza às seguintes perguntas:

Quais são os Invariantes Globais?
Quais regras determinísticas de validação preservam esses Invariantes Globais?
Quais regras da Especificação Inicial são estritamente necessárias para a primeira implantação?
Como o estado válido é representado e verificado?
O estado é distribuído, replicado ou verificável de forma independente por outro meio?
Quais questões futuras são intencionalmente deixadas fora da camada comum?
Quais escolhas futuras podem ser feitas pelos participantes sem alterar o conjunto de compatibilidade em que estão?
Como um participante adota uma mudança posterior?
Como um participante recusa uma mudança posterior sem receber uma condição de invalidade?
Como os conjuntos de compatibilidade são identificados ou descobertos?
Como funciona a rejeição local quando o estado é inválido ou incompatível segundo as regras que um participante executa?
Qual é o caminho de bifurcação?
Como um detentor prova o controle sem um responsável estabelecido pela manutenção de registros?
Como uma contraparte verifica o estado sem um registro?
Os participantes podem verificar a validade ordinária sem depender de um responsável estabelecido pela manutenção de registros?
Os registros e artefatos de coordenação descrevem a realidade adotada ou tentam fazer existir por declaração uma realidade futura não adotada?
O sistema minimizou o número de decisões embutidas na camada comum?
O sistema evitou qualquer autoridade permanente que determine a situação ordinária dos participantes?
Os participantes podem aceitar ou rejeitar contrapartes voluntariamente?
O sistema pode continuar se todos os registros estabelecidos desaparecerem?

Autor: Lu Heng