A primazia do código em execução: o ajuste necessário para preservar o desenho original da Internet

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

Nota:52 Sobre quando o poder do registo se desliga da responsabilidade: por que razão o atual modelo de coordenação dos RIR não pode sobreviver na sua forma atual
Nota:53 Sobre os recursos numéricos da Internet não serem propriedade política
Nota:56 A governação densa dos registos regionais da Internet transforma a unicidade em dupla extração
Nota:58 Da dupla extração à inversão da soberania: como as nações perdem o controlo soberano para os RIR por US$100
Nota:59 A penalização da pobreza: como o modelo RIR tributa os pobres enquanto lhe chama igualdade
Nota:61 A traição do código em execução: como o sistema RIR virou o consenso contra a comunidade técnica
Nota:62 Lavagem de mandato: da fantasia RIR à arquitetura de transição

Os sete ensaios anteriores não eram um programa de reforma para os Registos Regionais da Internet.

Eram uma autópsia.

Rastreavam a mesma patologia institucional através de diferentes camadas: responsabilidade desligada das consequências; recursos numéricos rebatizados como propriedade política; unicidade convertida em dupla extração; soberania invertida; pobreza tributada em nome da igualdade; consenso virado contra as redes que deveria servir; e, por fim, um mandato lavado até que um funcionário administrativo começasse a soar como um soberano. A sequência importa porque o fracasso não foi um conselho de administração inadequado, um registo inadequado, uma ação judicial ou um acontecimento de mercado incómodo. Foi um defeito sistémico a surgir sob diferentes disfarces. A página de autor do CircleID mostra agora claramente essa sequência, incluindo Running-Code Betrayal e Mandate Laundering. (circleid.com)

Este ensaio não procura transformar os RIR em governantes melhores.

Procura explicar por que razão a atual ordem de registo não pode ser o ponto final e por que razão a reparação menos disruptiva é um suplemento ao desenho técnico original da Internet.

Esse suplemento é a Primazia do Código em Execução (Running-Code Primacy).

A necessidade já não é teórica. Numa troca recente no CircleID, John Curran apresentou a forma mais sólida do argumento do incumbente. A sua tese é que a autoridade do sistema RIR não é simplesmente um subproduto de uma coordenação técnica limitada, mas o resultado de uma cadeia histórica: o White Paper, a ICANN, a ASO, o ICP-2, a transição da supervisão da IANA e a governação multilateral contínua do setor privado. Afirma que a autoridade do sistema RIR resulta de operar dentro do modelo multilateral do setor privado que o Governo dos Estados Unidos promoveu. (circleid.com)

Esse argumento é útil porque torna o conflito visível.

A questão já não é saber se existiu uma delegação histórica. É evidente que existiu. A questão é saber se uma função de coordenação historicamente delegada pode depois expandir-se até se tornar um mandato permanente de governação através da mesma maquinaria processual que controla. A resposta do incumbente é sim: delegação, reconhecimento, continuidade institucional e procedimento comunitário transformam-se num mandato autorrenovável.

A resposta exigida pelo desenho técnico original da Internet é não.

A tradição original da Internet era mais estreita, mais dura e melhor. A RFC 3935 afirma que o objetivo do IETF é «fazer com que a Internet funcione melhor»; fundamenta o trabalho na competência técnica, na implementação no mundo real e em «consenso aproximado e código em execução». Estabelece também que, quando o IETF não é responsável por um protocolo ou função, não tenta exercer controlo sobre ela. (rfc-editor.org) A RFC 7282 repete a velha frase de David Clark: «Rejeitamos: reis, presidentes e votações» e «Acreditamos em: consenso aproximado e código em execução». (rfc-editor.org) A RFC 9592 torna ainda mais claro o ponto antissoberano: o IETF não dirige, controla nem patrulha a Internet e não é «a polícia dos protocolos». (rfc-editor.org)

Essa tradição nunca significou que os documentos fossem mágicos. Significava que os documentos importavam quando ajudavam os sistemas a funcionar. Significava que o processo era tolerado porque servia a implementação. Significava que uma sala só era útil quando se disciplinava a si própria em torno da realidade operacional.

A camada de registo tomou emprestada essa legitimidade.

Nunca aceitou plenamente essa disciplina.

Esse é o remendo que falta.

O que significa a primazia do código em execução.

A Primazia do Código em Execução significa que os sistemas de coordenação da Internet devem ser interpretados de forma estrita, tomando como referência a função técnica mínima que originalmente justificou a existência das redes em funcionamento.

A camada de recursos numéricos existe para proteger sistemas em funcionamento: unicidade, interoperabilidade, continuidade relacionada com o encaminhamento, afirmações de segurança, prova de controlo e a semântica comum mínima necessária para que redes independentes possam trabalhar em conjunto.

Não existe para fabricar autoridade política.

Não existe para vigiar a moralidade comercial.

Não existe para transformar a geografia de um serviço num título de propriedade.

Não existe para transformar uma lista de correio numa legislatura.

Não existe para permitir que um registo privado faça desaparecer ativos de rede já operacionais porque mudou a sua teoria interna de políticas.

Um registo não é um Estado.

Um contacto numa base de dados não é uma procuração societária notarial.

Uma região de serviço não é um povo.

Uma sala de políticas não é uma legislatura.

Um registo pode descrever a realidade operacional. Não a cria.

Isto não é conservadorismo. A Primazia do Código em Execução não diz que os sistemas implementados nunca possam mudar. Diz que o poder institucional sobre a mudança não deve ser justificado por delegação histórica, reconhecimento circular ou procedimentos rituais. Deve ser justificado por regras deterministas que os operadores possam verificar localmente e pela adoção em sistemas em funcionamento.

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

A ordem incorreta é: sala de políticas, declaração, obrigação reivindicada, etiqueta de conformidade e cumprimento operacional forçado.

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

A correção essencial é esta: depois da especificação inicial, não existe uma instituição contínua a quem pedir autorização. Nenhum comité decide se a não adoção constitui uma infração. Nenhum registo declara inválido um participante simplesmente porque este se recusa a aceitar uma alteração posterior. Existem apenas o código, o estado do livro-razão, a validação, a adoção, a compatibilidade, a rejeição local, a bifurcação e a interoperabilidade seletiva.

Um operador que rejeite uma alteração posterior não quebra a Internet. Pode permanecer num conjunto de compatibilidade mais antigo. Pode bifurcar-se. Pode desligar-se. Pode deixar de interoperar com participantes que tenham adotado regras incompatíveis. Mas não pode quebrar a interoperabilidade de outros que continuam a executar código mutuamente compatível.

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

Esse é o remendo essencial que falta na coordenação de recursos numéricos.

A falha de desenho esteve presente desde o início.

A primeira arquitetura dos RIR pressupunha um mundo de baixo valor.

Os recursos numéricos pareciam técnicos, abundantes, administrativos e pouco conflituosos. Nesse mundo, a informalidade parecia eficiente. As listas de correio abertas pareciam representativas. A administração baseada em contactos parecia suficiente. Os contratos de responsabilidade limitada pareciam inofensivos. Um registo regional podia parecer uma simples agenda de endereços.

A escassez de IPv4 destruiu essa premissa.

Os endereços IPv4 tornaram-se escassos, transferíveis, financiáveis, arrendáveis, capitalizáveis, objeto de litígios, sujeitos a sanções e integrados em redes ativas. A camada de registo deixou de estar acima de entradas administrativas. Passou a estar acima de infraestruturas produtivas. Passou a estar acima do valor dos ativos. Passou a estar acima da continuidade dos clientes, da implementação na 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 ajustou para corresponder a esse novo risco.

Expandiu-se.

O resultado é um sistema que continua a falar a linguagem da coordenação técnica enquanto exerce os efeitos de uma governação de infraestruturas. Pede aos operadores que tratem o processo de registo como neutro, enquanto as decisões do registo afetam o destino comercial. Chama «comunidade» aos seus participantes, embora muitos dos que suportam as consequências nunca tenham conferido uma representação legal clara às pessoas presentes na sala.

A NRS expõe claramente o problema estrutural: os registos numéricos da Internet foram concebidos como organismos de coordenação técnica, mas, quando a escassez de IPv4 transformou os endereços em ativos valiosos, a discricionariedade do registo transformou-se em poder económico; quando os sistemas de coordenação controlam capital, a centralização torna-se um risco estrutural e a descentralização passa a ser uma questão de engenharia de sistemas mais do que de ideologia. A NRS também propõe a direção oposta de desenho: uma única Internet, infraestrutura aberta e autónoma e, como núcleo, governação descentralizada com participação humana mínima. (nrs.help)

Esse é o verdadeiro problema. A camada de registo nunca foi adaptada ao momento em que uma tabela de coordenação se transformou numa porta de acesso a ativos.

A Primazia do Código em Execução é essa adaptação.

Não é uma doutrina de «RIR melhor».

É uma disciplina pós-RIR.

As três regras do remendo

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

Os nomes permanecem inalterados. A lógica tem de ser precisa.

Especificação Inicial Mínima significa que a camada comum contém apenas regras deterministas e verificáveis localmente, necessárias para a unicidade, a interoperabilidade, a prova de controlo, a segurança partilhada e as afirmações de segurança. Não contém preferências de modelos de negócio, teorias de preços, sentimentos políticos regionais, poderes discricionários de execução nem expansão da missão institucional.

Decisão Futura Localizada não significa que uma instituição decida quais as decisões futuras que são locais. Isso reintroduziria a camada de autoridade. Significa que a especificação inicial realiza antecipadamente o trabalho de limitação. Após a implementação, as decisões futuras ordinárias permanecem nas mãos dos participantes que executam o código. Um participante pode adotar, rejeitar, bifurcar-se, desligar-se ou interoperar seletivamente. Nenhum participante pode alterar a interoperabilidade de outros que continuam a executar regras mutuamente compatíveis.

Adoção Voluntária significa que a mudança posterior só se torna real através da implementação, validação, disponibilização e utilização. A publicação não é realidade. A recomendação não é realidade. O reconhecimento institucional não é realidade. A não adoção não cria um estado de invalidez. Um participante que não adote uma mudança posterior permanece no seu conjunto de compatibilidade existente. Um participante que emita estados inválidos segundo as regras deterministas de outro pode ser ignorado localmente. O efeito é seleção de compatibilidade, não punição institucional.

Estas três regras não reabilitam a soberania do registo.

Evitam que ela reapareça com outro nome.

APNIC: a estrutura legal era o risco

A APNIC mostra a primeira falha: o mínimo nunca foi especificado de forma suficientemente estrita desde o início.

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

É uma história de estrutura legal.

Em março de 2023, a LARUS publicou uma revisão jurídica advertindo que a estrutura de governação da APNIC criava riscos não apenas para uma empresa em Brisbane, mas para a governação da Internet em toda a região Ásia-Pacífico. A revisão afirmava que o Diretor-Geral da APNIC tinha poder legal último para encerrar a APNIC e destituir o Conselho Executivo eleito, e que eram necessárias reformas urgentes de governação. Indicava também que a estrutura levantava dúvidas sobre a segurança da governação da Internet para mais de mil milhões de utilizadores na região Ásia-Pacífico. (larus.net)

O primeiro anexo, o extrato da ASIC, fornece a base societária. A APNIC Pty Ltd estava registada como uma empresa privada australiana limitada por ações, registada em Queensland. Paul Byron Wilson figurava como diretor e secretário. A informação sobre ações mostrava uma única ação ordinária emitida e Paul Byron Wilson como titular dessa ação. (larus.net)

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

O segundo anexo, o parecer jurídico do Dr. Peter Felter, extrai a conclusão sobre a governação. Descreve a estrutura pública da APNIC — membros, eleições, Conselho Executivo, Diretor-Geral e Secretaria — como um comité especial baseado no artigo 9.3 dos Estatutos da APNIC Pty Ltd. Afirma que a APNIC Pty Ltd é, há 25 anos, uma empresa privada controlada por um diretor, um acionista e um secretário, todos a mesma pessoa. (larus.net)

Essa distinção é importante.

A instituição pública orientada para a comunidade não era a entidade jurídica final. Era uma estrutura construída sobre uma empresa privada.

O parecer jurídico explica então por que razão essa distinção é importante. Afirma que os estatutos da APNIC estão sujeitos aos estatutos sociais e aos poderes da sociedade e dos seus diretores, administradores e membros. Segundo essa interpretação, a estrutura pública da APNIC poderia ser alterada por resolução do diretor da APNIC Pty Ltd; o parecer descreve a APNIC como, na prática, um departamento da APNIC Pty Ltd. (larus.net)

O ponto mais grave do parecer não era que a APNIC fosse tecnicamente ilegal. Era que legalidade e legitimidade não são a mesma coisa. O parecer argumenta que o mecanismo fiduciário não resolve o problema porque os poderes do Conselho Executivo continuam a derivar da resolução do diretor que estabelece o comité especial. Observa também que a APNIC Pty Ltd é uma empresa privada com ações cuja estrutura e objeto não correspondem ao modelo de organização sem ações e sem fins lucrativos normalmente associado a um registo regional de interesse público. (larus.net)

Essa é a primeira falha de desenho na sua forma mais pura.

Um sistema de coordenação de números à escala regional não deveria depender de uma estrutura que obrigue advogados a explicar por que razão uma empresa privada com uma única ação, um comité especial, um fideicomisso e um conselho eleito se combinam de alguma forma no controlo legítimo do registo da Internet da Ásia-Pacífico.

Uma camada de coordenação crítica deveria ser legível do exterior.

Não deveria exigir confiança em documentos atrás de documentos.

Não deveria exigir que os membros descobrissem, depois de anos de dependência institucional, que a camada eleita pode não ser a camada legal final.

Não deveria dar a aparência de governação pelos membros enquanto o poder formal reside noutro lugar.

Por isso, a Especificação Inicial Mínima deve incluir validade distribuída, não confiança institucional. Não porque uma instituição futura precise de melhor governação, mas porque um sistema futuro pós-RIR não deve precisar dessa instituição de todo.

A camada comum não deveria depender da estrutura oculta de controlo de uma empresa privada. Deveria definir regras deterministas de validação, estados de prova de controlo, regras de transição de estado, regras de conflito, replicação de livros-razões, vias de saída, vias de bifurcação e conjuntos de compatibilidade. Se a APNIC desaparecer, se se capturar a si própria, se alterar a sua posição jurídica ou se recusar reconhecer um estado válido, a rede em funcionamento não deveria depender do reconhecimento da APNIC para saber quem controla determinados recursos numéricos.

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

Deveria sê-lo o estado do livro-razão distribuído, validado ao abrigo da especificação inicial.

ARIN: a política encontrou a realidade dos ativos

A ARIN mostra a segunda falha: a realidade jurídica e de mercado pode ultrapassar a teoria do registo.

O acontecimento decisivo foi a transação Nortel/Microsoft. Quando a Nortel entrou em falência, os seus 666.624 endereços IPv4 tornaram-se ativos valiosos no processo. Os endereços foram vendidos à Microsoft por 7,5 milhões de dólares. A ARIN interveio segundo a teoria de que os endereços não eram propriedade e não podiam ser vendidos livres da política do registo. A Industry Canada apoiou essa posição. O tribunal de falências rejeitou-a; a Microsoft assinou mais tarde um acordo «legacy»; e o resultado prático foi claro: a política do registo não podia continuar a ser a única fonte de realidade quando os tribunais e os mercados tratavam os recursos numéricos como ativos. (btw.media)

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

A lição é que a camada de registo tinha entrado numa nova categoria.

Um registo é valioso porque operadores, tribunais, compradores, vendedores, credores e redes confiam nele. Não se torna autoritativo negando essa dependência. Só permanece útil se refletir com precisão suficiente a realidade jurídica, de mercado e operacional.

Quando o IPv4 se tornou escasso, o processo de registo transformou-se numa interface de mercado. As regras de transferência, as avaliações de necessidade, os atrasos no reconhecimento e as restrições regionais deixaram de ser pormenores administrativos. Tornaram-se fricções de ativos. A análise pública descreve hoje um livro de regras fragmentado dos RIR, no qual cinco sistemas regionais governam um mercado que negoceia entre aproximadamente 18 e 45 dólares por endereço, com regras conflituantes capazes de imobilizar ativos, atrasar fusões e obrigar a estruturas societárias separadas apenas para manter blocos de endereços. (btw.media)

Isso não é coordenação neutra.

É um efeito regulatório sem responsabilidade regulatória.

A ARIN demonstra por que razão a Adoção Voluntária é importante. A política do registo só mantém credibilidade enquanto descreve o que os atores realmente implementam, negoceiam, financiam, litigam e utilizam. Torna-se perigosa quando a publicação é tratada como suficiente para fabricar a realidade.

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

Transforma-se numa base de dados obsoleta.

Num desenho de Primazia do Código em Execução, a lição é ainda mais clara. Os tribunais e os mercados não precisam de um registo incumbente para decidir se existe valor. Os operadores não precisam de um comité para saber se um bloco é encaminhado. Os participantes precisam de regras deterministas que permitam prova de controlo, resolução de conflitos, transições de estado visíveis num livro-razão e compatibilidade. O antigo registo pode publicar uma vista. Um cliente de software pode mostrar uma vista. Um explorador de livro-razão pode mostrar uma vista. Nenhum é a fonte da validade.

Não há registo para o qual migrar.

Não há registo a que perguntar.

Existe apenas um estado distribuído que os participantes validam, aceitam, rejeitam, bifurcam ou com o qual interoperam.

AFRINIC: quando a teoria do registo ameaçou ativos em funcionamento

A AFRINIC é o caso central porque reduziu o problema à sua essência.

A história errada é que um membro problemático paralisou um registo regional.

Esse é o relato moral do incumbente.

A história estrutural é diferente. A AFRINIC tentou transformar o uso comercial, a geografia dos clientes, o arrendamento, a relação com os membros e a interpretação interna das políticas num poder declarado para cancelar o registo de recursos numéricos já em funcionamento. Uma vez feita essa afirmação, o conflito deixou de poder permanecer como um desacordo numa sala de políticas. Tornou-se um teste para saber se um registo privado podia usar a retórica regional e o silêncio normativo para ameaçar ativos operacionalmente integrados.

Os factos não exigem exagero teatral. Relatórios públicos descreveram o litígio da AFRINIC como um simples conflito comercial sobre endereços IP que se transformou na maior história de governação da Internet em África. Indicaram também que a Cloud Innovation era frequentemente apresentada como a vilã, enquanto material documental posterior apontava para forças destrutivas dentro da própria AFRINIC e para litígios atrasados, prolongados e continuados por representantes da AFRINIC a expensas desta. (btw.media)

Isso é importante porque inverte a narrativa habitual.

O litígio não criou a falha estrutural.

Expôs-a.

A falha relevante já estava presente quando um registo privado tratou a ausência de autorização explícita como fundamento para controlo coercivo. O arrendamento não era uma ameaça à unicidade. A geografia dos clientes não era uma atribuição duplicada. O uso comercial não era uma falha de segurança de encaminhamento. Um modelo de negócio desaprovado por um registo não era um invariante global.

No entanto, a interpretação do registo colocou esses elementos dentro de um quadro de revogação.

Esse é o momento em que a coordenação se transforma em governação.

Os relatórios registam que a AFRINIC enviou à Cloud Innovation uma carta em março de 2021 alegando violações de políticas e ameaçando terminar a sua filiação; que, em julho de 2021, o Supremo Tribunal das Maurícias proibiu a AFRINIC de cancelar a filiação da Cloud Innovation; e que uma nova tentativa de cancelamento foi bloqueada em dezembro de 2021. (btw.media) Essa sequência não é a história de um registo que protege calmamente a Internet. É a história da autoridade do registo a encontrar o direito comum.

O colapso institucional também não foi causado por excesso de poder do registo. O problema mais profundo foi o bloqueio estrutural. Se um registo detém o monopólio do reconhecimento sobre ativos vivos de elevado valor, qualquer falha interna transforma-se num risco para a continuidade da Internet. Se os membros não podem abandonar o sistema de reconhecimento, a falha do registo transforma-se em poder para os manter reféns.

Um registo pode corrigir fraude de registo demonstrável nos seus próprios dados.

Pode evitar atribuições duplicadas enquanto o modelo de registo existir.

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

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

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

Um organismo privado não deveria transformar o arrendamento em traição regional.

Não deveria transformar a geografia dos clientes num gatilho de revogação.

Não deveria tratar o desacordo comercial como invalidez técnica.

Não deveria transformar a continuidade dos ativos em autorização.

A AFRINIC demonstra a necessidade de uma Decisão Futura Localizada corretamente entendida. Não existe um órgão central que decida que uma futura decisão comercial «pertence localmente». Em vez disso, a especificação inicial deve garantir que essas decisões nunca entrem na camada comum em primeiro lugar. O arrendamento, a geografia dos clientes, o uso comercial, a fixação de preços, o financiamento, a composição dos clientes e a estratégia de implementação ficam fora das regras de validade deterministas, salvo quando afetam diretamente a unicidade, a segurança, a prova de controlo ou a interoperabilidade.

Um operador não pode quebrar a interoperabilidade de outros operadores ao arrendar endereços.

Não pode quebrá-la servindo clientes fora de uma região histórica do registo.

Não pode quebrá-la utilizando um modelo de negócio que o registo desaprova.

Em qualquer caso, um operador pode não cumprir regras deterministas que outros participantes executam. Nesse caso, os restantes rejeitam localmente o estado inválido. Não há camada de punição. Não há tribunal de conformidade. Não há soberano regional.

Essa linha não é ideológica.

É operacional.

O problema do proxy não é um pormenor

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

A NRS expõe a sua base de representação em termos jurídicos diretos. Afirma que os membros listados confiaram à NRS a representação em matérias de governação dos RIR e que cada membro listado concedeu uma procuração notarial (power of attorney). (nrs.help) Durante a disputa eleitoral da AFRINIC, a NRS pediu aos membros que informassem se os seus nomes apareciam nos registos de votação ou se os seus votos tinham sido registados sem a sua participação, e indicou que esses relatos factuais seriam tratados por vias legais. (nrs.help)

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

O sistema RIR frequentemente colapsa várias categorias numa só: representante corporativo, contacto de base de dados, contacto técnico, empregado, consultor, titular de procuração, participante em políticas, utilizador habitual de listas de correio. Não são a mesma coisa.

Um contacto numa base de dados pode ajudar a administrar registos.

Uma procuração notarial pode autorizar a representação se for válida e se a representação estiver abrangida pelo seu âmbito.

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

Um participante numa lista de correio pode expressar uma opinião.

Nenhum destes elementos se transforma automaticamente num principal legal para todas as empresas, clientes, Estados, credores, financiadores, compradores, arrendatários ou redes que suportam as consequências de uma decisão do registo.

Esta distinção só pode ser ignorada enquanto a camada comum permanecer fina. Quando o registo reivindica poder sobre revogação, transferência, arrendamento, acesso ao mercado, sanções, continuidade dos ativos ou risco de infraestrutura nacional, a representação torna-se constitucional.

Uma sala não é um mandato.

Uma lista de correio não é um povo.

Um registo de contactos não é uma procuração societária notarial.

Uma região de serviço não é um círculo eleitoral soberano.

Isto não é uma questão de rigor processual.

É a diferença entre coordenação e autoridade normativa.

Um sistema de Primazia do Código em Execução evita este problema reduzindo, desde logo, o número de decisões que exigem representação. Se a validade for determinista e local, há menos coisas para votar. Se a mudança futura for voluntária, não é necessário decidir se um não adotante está em falta. Se o estado for representado num livro-razão distribuído, não é necessário pedir a um registo incumbente que reconheça a existência continuada de um participante. Se os conjuntos de compatibilidade forem explícitos, os participantes sabem com quem podem interoperar sem consultar uma sala de políticas.

O melhor problema de governação é aquele que o desenho do sistema elimina.

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

A RIPE NCC e a LACNIC não demonstram que alguns RIR sejam mais «civilizados» do que outros. Demonstram que o modelo RIR tem duas camadas de execução para 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 o movimento do estatuto do registo.

A recusa da RIPE NCC em aceitar o patrocínio da LARUS para a RIPE 90 mostrou claramente a camada do clube. Um membro ofereceu patrocínio. O ecossistema do registo rejeitou-o devido a uma disputa não relacionada noutra região. Isso não foi uma decisão de segurança de encaminhamento. Não foi uma decisão de unicidade. Não foi uma regra determinista de validação. Foi uma forma de exclusão privada através do controlo de acesso a espaços, visibilidade, patrocínio e legitimidade social.

A LACNIC também rejeitou o patrocínio. Região diferente, mesmo padrão: o clube do registo protege-se controlando salas, visibilidade e reputação.

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

A camada de sanções é mais grave porque mostra o ponto de estrangulamento em forma jurídica. A RIPE NCC estabelece que, por estar sediada nos Países Baixos, deve cumprir as sanções da UE; quando estas se aplicam, congela registos na base de dados RIPE, bloqueia aquisições e transferências e pode tratar casos como congelados se uma parte não conseguir fornecer documentação suficiente. Também efetua verificações contra listas da OFAC devido a requisitos bancários. (transparência de sanções da RIPE NCC)

Isto não é uma crítica à RIPE NCC por cumprir a lei. Uma entidade neerlandesa tem de cumprir a lei neerlandesa e da UE. O problema é arquitetónico: por que razão deveria uma entidade privada nos Países Baixos ser o ponto central de reconhecimento da mobilidade de recursos numéricos entre vários países, operadores e sistemas jurídicos?

As sanções podem obrigar um banco. Podem obrigar uma entidade neerlandesa. Podem obrigar uma contraparte que decida não comerciar. Mas não deveriam transformar-se numa condição global de validade técnica para todos os demais.

Essa é a falha de desenho.

A mesma centralidade que permite ao clube excluir um crítico também permite a uma jurisdição congelar a mobilidade do registo. Uma é execução social. A outra é execução jurídica. Ambas funcionam apenas porque o registo ocupa um lugar onde a validade não deveria residir.

Isto liga-se diretamente aos três princípios.

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

Decisão Futura Localizada: o risco jurídico, a escolha da contraparte, o patrocínio, a confiança comercial e a exposição a sanções pertencem aos atores que os assumem. Uma entidade neerlandesa pode rejeitar uma transação. Um banco pode rejeitar um pagamento. Uma contraparte pode recusar-se a interagir. Nada disso deve transformar-se em verdade global do registo.

Adoção Voluntária: os participantes aceitam contrapartes executando código, validando estados e escolhendo com quem interoperar. A não adoção não é conduta indevida. A rejeição local não é invalidez global. A rejeição de um clube não deveria apagar um estado válido. Uma obrigação de sanções deve limitar o ator afetado, não reescrever o livro-razão global de recursos numéricos.

É por isso que é necessária uma arquitetura de livro-razão distribuído. Num sistema pós-RIR, a validade ordinária não é decidida pela RIPE NCC, pela LACNIC, por uma mesa de sanções, por um comité de reuniões ou por um gabinete 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 registo central desaparece como fonte de verdade.

A solução não é uma etiqueta melhor.

Não é uma fila de sanções mais transparente.

A solução é eliminar a validade tanto do clube como do ponto de estrangulamento.

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

A carta da NRO: a via de fuga para cima

A evidência mais séria não é a tentativa de extralimitação da AFRINIC.

É a resposta coletiva do sistema.

Em 2022, a Number Resource Organization escreveu ao Governo das Maurícias. A carta descrevia a NRO como o organismo de coordenação dos RIR do mundo e afirmava que os RIR gerem os recursos numéricos nas respetivas regiões. Indicava que os cinco registos desempenham 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 o litígio da Cloud Innovation, afirmava que tinham sido apresentadas mais de 25 ações, queixava-se de ordens judiciais que congelaram as contas da AFRINIC e suspenderam eleições e sustentava que a AFRINIC tinha solicitado repetidamente às Maurícias que a reconhecessem como organização internacional. A NRO instava o governo a tomar medidas para preservar a independência da AFRINIC e a estabilidade da Internet em África. (nro.net)

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

Quando um registo privado entrou em conflito com tribunais comuns, o reflexo do sistema não foi reduzir o alcance do mandato.

Não foi eliminar o bloqueio dos registos.

Não foi separar a administração de registos da execução.

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

Não foi questionar se o poder unilateral de cancelar o registo de ativos em funcionamento tinha sido ilegítimo desde o início.

O reflexo foi uma via de fuga para cima.

Um organismo privado de coordenação não pode ser técnico quando quer discricionariedade, comunitário quando quer legitimidade, contratual quando quer tarifas, não proprietário quando quer evitar responsabilidade e quase internacional quando quer imunidade perante os tribunais.

Esse conjunto não é governação.

É uma forma sistémica de «lavagem de mandato».

Se os RIR querem privilégios de direito público, devem aceitar responsabilidade de direito público. Se querem flexibilidade de direito privado, devem aceitar litigância de direito privado. O que não podem exigir coerentemente é discricionariedade privada, importância de infraestrutura pública, baixa responsabilidade, representação fraca, estatuto monopolista e imunidade quase diplomática ao mesmo tempo.

Esse é o caminho para o colapso.

A Primazia do Código em Execução rejeita-o.

Quando um registo enfrenta resistência jurídica, não deve escapar para cima em busca de imunidade. A arquitetura deve contrair-se para baixo, reduzindo-se à função estrita de código em execução que originalmente a justificou.

Menos soberania.

Nenhum registo como fonte de validade.

Menos execução.

Mais validação distribuída.

A revisão do ICP-2 não é suficiente

O sistema atual reconhece que algo se partiu.

A página de comentários públicos da ICANN sobre o segundo projeto do documento de governação dos RIR indica que a proposta estabeleceria regras e critérios para reconhecer novos RIR, obrigações operacionais e requisitos para os RIR existentes, bem como regras de desreconhecimento; se adotada, substituiria o ICP-2. A mesma página indica que o processo foi iniciado depois de a NRO ter solicitado à ASO que propusesse atualizações para dotar o sistema RIR de maior responsabilização perante a comunidade da Internet. (icann.org)

Isso pode ser necessário como medida de continuidade.

Não é suficiente como teoria de legitimidade.

As regras de reconhecimento e desreconhecimento respondem a uma pergunta tardia: quando é que um registo falhou o suficiente para ser eliminado?

A pergunta anterior é mais importante: por que razão deveria um registo ter poder suficiente para falhar catastroficamente em primeiro lugar?

Um sucessor do ICP-2 que apenas torne mais rigorosos o reconhecimento, a auditoria, a transição e o desreconhecimento pode melhorar a higiene institucional preservando o erro de categoria. Continua a assumir que o RIR é a forma soberana primária de coordenação de recursos numéricos.

A Primazia do Código em Execução coloca um conjunto diferente de perguntas.

Como continua a Internet se um RIR colapsar?

Como se mantêm verificáveis as atribuições de recursos numéricos sem a autorização de uma entidade incumbente?

Como sobrevive a unicidade sem discricionariedade monopolista?

Como se evita que os registos se tornem ferramentas de execução coerciva?

Como se mantêm as decisões comerciais fora da validade determinista, exceto quando existe um verdadeiro invariante global em risco?

Como permanece a coordenação utilizável sem um registo autoritativo?

Como valida um operador o estado ordinário sem consultar um organismo permanente?

Como se evita que a rejeição se transforme numa etiqueta de infração?

Estas não são perguntas de reforma.

São perguntas pós-RIR.

Por que razão este é o remendo do desenho original

O problema não é saber se alguém gosta ou não dos registos incumbentes.

O problema é saber se a camada de recursos numéricos continua a obedecer à disciplina de desenho que tornou a Internet possível: regras comuns mínimas, validação local, adoção voluntária e código em execução.

A Primazia do Código em Execução não é uma estratégia de relações públicas nem um compromisso institucional. É a reparação técnica implícita no desenho original. Se a Internet foi construída para rejeitar reis, presidentes e votações como fontes de verdade técnica, então a camada de recursos numéricos não pode recriar essas formas através de processos de registo, delegação histórica ou teatro comunitário.

O consenso, por si só, pode transformar-se em ritual. O código em execução, por si só, pode ser subordinado se a camada de registo for colocada acima dele como fonte de reconhecimento. A regra que falta é interpretativa e arquitetónica: quando o processo institucional entra em conflito com a função técnica mínima exigida pelos sistemas em funcionamento, o código em execução tem prioridade; e, quando é proposta uma mudança posterior, esta só se torna real através da adoção voluntária dos participantes que executam as regras de validação.

É assim que se preserva o desenho original, e não que se abandona.

A Internet foi importante porque se tornou o primeiro sistema global de comunicações que não exigia autorização prévia de um único soberano, ministério, igreja, corporação ou guardião. Se essa conquista continua a merecer defesa, a camada de recursos numéricos não pode tornar-se a exceção que invalida a regra.

Um sistema construído para evitar reis não pode permitir que um contabilista aspire a ser um.

O remendo restaura a hierarquia original: código primeiro, operadores primeiro, validação determinista primeiro, estado distribuído primeiro; as instituições, se chegarem a existir durante a transição, apenas como artefactos não autoritativos, nunca como fontes de validade.

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

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

Significa que a camada comum se torna mais fina, mais objetiva, mais determinista e mais distribuída do que o atual monopólio dos RIR.

Não há registo para o qual migrar.

Não há novo registo para coroar.

Não há novo sacerdócio.

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

A camada comum deve preservar a unicidade dos identificadores, a prova de controlo, o estado de transferência, o estado de delegação, as afirmações de segurança relacionadas com o encaminhamento, a auditabilidade, os metadados de conflito e a visibilidade das bifurcações.

A camada dos operadores deve controlar o uso comercial, o arrendamento, a geografia dos clientes, as práticas de encaminhamento, o financiamento, a seleção de contrapartes e as regras de negócio que não sejam invariantes.

A camada de adoção deve determinar o que se torna real. Uma regra de coordenação só importa se os operadores puderem implementá-la, as contrapartes aceitá-la, os mercados confiar nela, os tribunais compreendê-la e a interoperabilidade se mantiver sem transformar o reconhecimento do incumbente na única fonte de realidade.

A camada de execução não deve fundir-se com a camada de estado. Um livro-razão distribuído pode registar o estado. Pode validar transições. Pode expor conflitos. Pode tornar a prova portátil. Não deve transformar-se simultaneamente em procurador, juiz, autoridade sancionatória, regulador de mercado, moralista comercial e guardião de ativos.

O mais importante é compreender corretamente a portabilidade.

Num mundo de livros-razões distribuídos, portabilidade não significa passar de um registo para outro. Isso continua a ser pensamento de registo. Não há registo para o qual migrar. A prova de controlo do titular, o histórico de estado e a capacidade de transferência não estão presos numa base de dados incumbente. Existem num estado partilhado verificável que os participantes validam localmente e que as contrapartes aceitam voluntariamente.

Sem isso, cada registo é um ponto de bloqueio.

Com isso, o registo deixa de ser fonte de validade.

Por conseguinte, a coordenação pós-RIR precisa de quatro propriedades de desenho.

Primeiro, validade determinista. Um participante deve conseguir saber se uma transição de estado, prova, delegação, transferência ou afirmação é válida aplicando localmente a especificação.

Segundo, conjuntos de compatibilidade. Se os participantes adotarem regras futuras diferentes, o sistema deve descrever claramente os limites de compatibilidade, em vez de tratar a dissidência como infração.

Terceiro, prova distribuída de controlo. Um titular não deve «mover» os seus recursos para outro registo; deve demonstrar controlo através de um estado válido no livro-razão que qualquer contraparte possa verificar sem aprovação do incumbente.

Quarto, visibilidade das bifurcações. Se os conjuntos de regras divergirem, a divergência deve ser explícita. Os participantes decidem qual conjunto de compatibilidade executar e com que contrapartes interagir. Uma bifurcação pode isolar participantes, mas não confere a uma das partes poder institucional para apagar a outra.

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

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

Por que razão o caminho de falha é previsível

Se nada mudar, o caminho de falha é claro.

Primeiro, mais disputas passarão das salas de políticas para os tribunais. Os ativos escassos atraem escrutínio jurídico. Será pedido aos tribunais que congelem contas, preservem registos, bloqueiem eleições irregulares, nomeiem administradores judiciais, reconheçam transferências ou determinem quem pode agir em nome de um registo.

Segundo, os Estados deixarão de tratar os RIR como associações técnicas inofensivas. A continuidade do endereçamento afeta a conectividade nacional, as sanções, a aplicação da lei, a resiliência das telecomunicações, a infraestrutura de nuvem e a segurança económica. Nenhum Estado aceitará indefinidamente uma entidade privada estrangeira como ponto ascendente não questionado da continuidade das comunicações nacionais.

Terceiro, os operadores contornarão a autoridade do registo sempre que possível. Se os registos se tornarem políticos, inseguros, não representativos ou desligados da realidade dos ativos, os operadores recorrerão a contratos privados, transferências apoiadas por litígios, certificações alternativas, reconhecimento nacional ou à realidade de encaminhamento de facto.

Quarto, as camadas da ICANN e da NRO serão tentadas a centralizar. Isso produziria uma versão mais densa do mesmo problema, salvo se o próprio mandato for reduzido.

Quinto, os governos serão tentados a nacionalizar. Isso seria previsível e perigoso. Se os registos privados reivindicarem autoridade quase soberana sem responsabilidade pública, os Estados acabarão por reivindicar soberania. O resultado poderá ser fragmentação, retaliações, registos em conflito e pressão política sobre o encaminhamento.

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

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

Um livro-razão distribuído não resolve todos os problemas políticos. Mas faz algo mais importante: elimina o registo permanente como fonte ordinária de validade. Isso reduz a superfície de ataque. Reduz o poder das instituições de manter terceiros reféns. Converte desacordos futuros em seleção de compatibilidade, em vez de guerra administrativa.

A pergunta muda

O sistema antigo pergunta: quem tem o mandato?

Essa é a pergunta errada.

A melhor pergunta é: o que exige realmente o código em execução?

Esta regra protege a unicidade?

Preserva a interoperabilidade?

Corrige fraude de registo demonstrável através de evidência determinista?

Protege a segurança relacionada com o encaminhamento?

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

Permite a validação local?

Elimina a dependência de um único incumbente?

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

Pode um participante rejeitá-la sem ser rotulado como inválido?

Pode um participante verificar a validade ordinária sem pedir a um registo um estado?

Pode uma contraparte aceitar ou rejeitar o estado voluntariamente?

Pode ocorrer uma bifurcação sem que uma das partes seja eliminada por uma instituição?

Se a resposta não estiver ligada à necessidade determinista do código em execução, esse poder não deveria residir na camada comum.

Isto é a Primazia do Código em Execução.

Para discussão

Esta proposta destina-se a discussão. Não é uma solução final.

O passo seguinte deveria ser um Internet-Draft sério ou um documento do tipo BCP que defina a Primazia do Código em Execução para os sistemas de coordenação da Internet, começando pelos recursos numéricos. O projeto não deveria perguntar como reabilitar o monopólio dos RIR. Deveria perguntar como construir uma coordenação pós-RIR através de estado num livro-razão distribuído, validação determinista, adoção voluntária, aceitação por contrapartes e conjuntos de compatibilidade explícitos.

Deveria ser avaliado por operadores, advogados, economistas, engenheiros de protocolos, especialistas em segurança de encaminhamento, participantes de mercado, governos e críticos.

O projeto deveria colocar perguntas difíceis.

Quais são os invariantes globais?

Que regras de validação são deterministas?

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

Que poderes antigos do registo são resíduos históricos?

Que decisões pertencem aos operadores?

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

Qual é a via de rejeição?

Qual é a via de bifurcação?

Qual é a via de rejeição local?

Como demonstra um titular o controlo sem um registo incumbente?

Como verifica uma contraparte o estado sem um registo?

Pode a Internet continuar se um RIR colapsar?

Podem os recursos numéricos continuar únicos sem a autorização de um incumbente?

Pode um participante validar o estado ordinário sem uma instituição permanente?

Pode um processo de políticas distinguir entre um invariante do código em execução e a vontade institucional?

Pode a antiga camada de registos desaparecer sem perder o estado verificável?

Pode um registo descrever a realidade sem se tornar soberano sobre ela?

Qualquer pessoa interessada pode contactar-me através do LinkedIn. Investigadores sérios, autores técnicos, instituições ou especialistas em políticas que queiram ajudar a transformar isto num primeiro Internet-Draft e, eventualmente, numa RFC ou numa discussão BCP, se a comunidade considerar útil, podem contactar-me. A LARUS Foundation e eu estamos disponíveis para apoiar e financiar investigação séria nesta direção.

O sistema RIR falhou no seu desenho inicial porque nunca perguntou o que o código em execução realmente exigia.

Perguntou quem podia falar na sala.

O sistema seguinte deve inverter essa ordem.

Não é lavagem de mandatos.

Não é traição ao código em execução.

Primazia do Código em Execução.

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 desenho para sistemas de coordenação da Internet cujo objetivo é fornecer pontos de referência técnicos partilhados sem criar uma autoridade contínua acima dos participantes que executam o sistema. Define três princípios ligados: Especificação Inicial Mínima, Decisão Futura Localizada e Adoção Voluntária.

Neste modelo, a Especificação Inicial define apenas as regras deterministas e verificáveis localmente necessárias para a unicidade, a interoperabilidade, a prova de controlo, a segurança partilhada e a segurança. Depois da Especificação Inicial, as alterações futuras não são aprovadas por um organismo central. São adotadas, ignoradas, bifurcadas ou abandonadas pelos participantes que executam código.

O padrão de desenho previsto é um livro-razão distribuído de estado válido, ou um mecanismo equivalente de estado distribuído verificável, e não uma hierarquia de registos. Não existe um registo permanente que decida a validade ordinária. Os participantes validam o estado localmente, aceitam contrapartes voluntariamente e decidem que conjuntos de compatibilidade executam.

A não adoção não é uma infração. Um participante que não adote uma alteração posterior permanece no seu conjunto de compatibilidade existente. Um participante que emita estados inválidos segundo as regras deterministas aceites por outro participante pode ser ignorado localmente por esse participante. O efeito é seleção de compatibilidade, bifurcação, isolamento ou interoperabilidade seletiva, não punição institucional.

Este documento não define um protocolo de rede (wire protocol). Especifica uma Melhor Prática Atual (BCP) para o desenho de protocolos, sistemas de identificadores, livros-razões distribuídos e mecanismos de coordenação que não devem transformar-se em instituições permanentes de governação.

1. Introdução

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

Isto acontece normalmente em três passos.

Primeiro, as questões futuras são incorporadas na camada fundacional antes de serem tecnicamente necessárias.

Segundo, decisões que deveriam ser tomadas pelos participantes que executam os seus próprios sistemas passam a depender do reconhecimento, da interpretação ou das decisões de estatuto de um organismo permanente.

Terceiro, a publicação, o registo, a recomendação ou a aprovação processual são tratados como suficientes para criar obrigações operacionais, mesmo quando os participantes não adotaram a alteração nos sistemas em execução.

O resultado é um sistema frágil. Uma camada de referência técnica transforma-se numa camada de governação. Um registo transforma-se num ponto de controlo. Um artefacto de coordenação transforma-se numa fonte de controlo futuro.

Este documento propõe uma disciplina de desenho diferente:

Especificação Inicial Mínima: definir apenas as regras deterministas comuns necessárias para a interoperabilidade básica, a unicidade, a prova de controlo, a segurança partilhada e a segurança.

Decisão Futura Localizada: depois da Especificação Inicial, manter as decisões futuras nos participantes que executam código. Um participante pode adotar, rejeitar, bifurcar-se, desligar-se ou interoperar seletivamente. Nenhum participante pode alterar a interoperabilidade de outros participantes que continuam a executar regras mutuamente compatíveis.

Adoção Voluntária: fazer com que as alterações posteriores só se tornem reais através da implementação, operação, validação e adoção pelos participantes que executam código.

Estes princípios estão relacionados. Um sistema que especifique demasiado desde o início carrega antecipadamente o controlo futuro para a camada comum. Um sistema que mantenha uma camada de reconhecimento contínuo permite que a autoridade reapareça depois da implementação. Um sistema que trate a publicação como realidade transforma a documentação em mandato.

A intuição de desenho é simples: a validade deve ser determinada por regras deterministas que os participantes possam verificar localmente contra um estado partilhado. Um participante pode adotar uma alteração posterior, rejeitá-la, bifurcar-se, desligar-se ou interoperar seletivamente. No máximo, pode retirar-se de um conjunto de compatibilidade. Não pode, ao rejeitar uma alteração, quebrar a interoperabilidade de outros participantes que continuam a executar regras mutuamente compatíveis.

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

2. Âmbito

Este documento aplica-se 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 controlo, sistemas de portabilidade, livros-razões 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 devem ser deterministas, mínimas, verificáveis localmente e limitadas ao que o sistema realmente necessita para funcionar.

Este documento não exige uma implementação específica de livro-razão distribuído. Exige uma propriedade de desenho: os participantes devem conseguir determinar a validade aplicando localmente a Especificação Inicial a um estado partilhado ou replicável, sem pedir autorização ou estatuto a uma autoridade permanente.

3. Convenções e definições

3.1. Linguagem de requisitos

Os termos de requisito em maiúsculas neste documento devem ser interpretados no sentido definido pela BCP 14, especificamente pelas RFC 2119 e RFC 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 necessários para a primeira implementação de um sistema.

Camada comum (Common Layer):
O conjunto mínimo de regras partilhadas ou de estrutura de referência necessário 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 (Distributed Ledger):
Um registo replicado ou de outro modo distribuído de transições de estado que permite aos participantes verificar a validade ordinária sem depender de um registo permanente, comité ou outra autoridade. O termo não exige qualquer algoritmo de consenso ou implementação específica.

Regra de validação determinista (Deterministic Validation Rule):
Uma regra que permite a um participante decidir, através de computação local ou verificação local, se um estado, registo, transição, afirmação ou mensagem é válido ao abrigo de um conjunto de regras especificado.

Invariante global (Global Invariant):
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 controlo, a segurança partilhada ou a segurança.

Participante (Participant):
Um operador, implementação, nó, rede, organização ou outro ator que executa o sistema, o verifica, o coloca em produção ou dele depende.

Conjunto de compatibilidade (Compatibility Set):
Um grupo de participantes cujas regras de validação implementadas lhes permitem interoperar entre si. Uma alteração posterior pode criar um novo conjunto de compatibilidade se alguns participantes a adotarem e outros não.

Adoção (Adoption):
Implementação, disponibilização, validação e utilização reais pelos participantes que executam o sistema.

Aceitação de contraparte (Counterparty Acceptance):
Decisão voluntária de um participante de aceitar, realizar transações, interoperar ou confiar no estado de outro participante segundo as regras de validação que executa.

Não adoção (Non-Adoption):
Decisão de um participante de não implementar ou não utilizar uma alteração proposta. A não adoção não cria um estado de invalidez. Significa apenas que o participante não entrou no conjunto de compatibilidade criado por essa alteração.

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

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

Artefacto de coordenação (Coordination Artifact):
Um documento, recomendação, nota de implementação, perfil, implementação de referência, explorador de livro-razão, réplica ou outro artefacto que ajude os participantes a coordenar-se. Um artefacto de coordenação não cria uma realidade operacional vinculativa a menos que os participantes o adotem em sistemas em execução.

4. Formulação do problema

Os designers tentam frequentemente reduzir a incerteza futura escrevendo demasiado na camada fundacional ou deixando a interpretação de questões futuras a um organismo permanente. Isso parece prudente. Muitas vezes é perigoso.

A sobre-especificação na camada fundacional tem três custos.

Primeiro, transfere decisões futuras para uma camada comum onde a mudança é mais difícil e onde a captura tem maior efeito.

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

Terceiro, incentiva um organismo que mantém registos, publica documentos ou convoca participantes a tratar esses atos como autoridade sobre a realidade futura.

O mesmo problema aparece depois da implementação. Se um sistema exigir um organismo permanente para aprovar alterações, determinar estatutos ou interpretar a operação ordinária, criou uma camada de controlo pós-fundacional. Essa camada pode começar como administração. Pode transformar-se em governação. E pode transformar-se num ponto de estrangulamento.

O objetivo de desenho deste documento não é uma melhor discricionariedade institucional. É evitar a necessidade dessa discricionariedade.

Um sistema de coordenação da Internet bem desenhado deveria definir desde o início regras de validade deterministas e verificáveis localmente; representar o estado válido de forma distribuída ou replicável; manter as decisões não invariantes fora da camada comum; e permitir que as alterações posteriores só se tornem reais quando os participantes as adotarem voluntariamente em sistemas em execução.

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

5.1. Declaração

Uma Especificação Inicial DEVERIA definir apenas as regras comuns deterministas mínimas necessárias para a interoperabilidade básica, a unicidade, a prova de controlo, a segurança partilhada e a segurança.

5.2. Requisitos

Um desenho que utilize este princípio:

• DEVE identificar explicitamente os seus Invariantes Globais.
• DEVE definir regras de validação deterministas 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 essa regra seja necessária para preservar um Invariante Global declarado ou permitir a implementação inicial.
• DEVE separar as regras de validação das preferências de política, acordos comerciais, papéis institucionais, aspirações de governação e juízo discricionário.
• DEVE permitir aos participantes verificar localmente a validade ordinária sem solicitar informação a qualquer instituição, registo, comité, organismo 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 para a verificação local.
• DEVERIA definir sinalização de extensões, versionamento, etiquetagem de compatibilidade ou identificação de bifurcações quando for previsível uma variação futura.
• DEVE garantir que os artefactos de coordenação necessários sejam portáteis, auditáveis, reproduzíveis e substituíveis.
• DEVERIA preferir condições objetivas verificáveis por máquina a juízos subjetivos de mérito.
• NÃO DEVE fazer do reconhecimento institucional futuro a única via pela qual um estado válido possa ser conhecido, registado ou utilizado.

5.3. Implicações de desenho

A Especificação Inicial Mínima não significa uma especificação vaga. Significa uma especificação estrita apenas daquilo que deve ser comum.

Um sistema continua a precisar de estrutura comum suficiente para funcionar. A disciplina consiste em distinguir entre:

• o que deve ser comum para a unicidade, a interoperabilidade, a prova de controlo, a segurança partilhada e a segurança; e
• o que pode permanecer fora da camada comum porque pertence à preferência do operador, à prática comercial, à escolha da contraparte, ao momento da implementação ou a decisões posteriores de adoção.

Um desenho que não consiga expressar claramente os seus Invariantes Globais e as suas regras de validação deterministas deveria assumir que especificou discricionariedade a mais e substância verificável a menos.

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

6.1. Declaração

Depois da Especificação Inicial, as Decisões Futuras DEVERIAM permanecer locais aos participantes que executam código. Uma Decisão Futura torna-se efetiva apenas para o conjunto de compatibilidade cujos participantes a adotem. Não é necessária qualquer autoridade permanente para a aprovar, e a não adoção não cria um estado de invalidez.

6.2. Requisitos

Um desenho que utilize este princípio:

• NÃO DEVE exigir que os participantes obtenham autorização de uma instituição incumbente, registo, comité, conselho, organismo de políticas ou outra autoridade para decisões que não alterem as regras de validação deterministas do conjunto de compatibilidade a que pertencem.
• NÃO DEVE criar um organismo permanente cujo reconhecimento seja a única via pela qual uma alteração posterior possa tornar-se realidade operacional.
• DEVE distinguir entre a validade ao abrigo da Especificação Inicial e a compatibilidade com uma alteração opcional posterior.
• NÃO DEVE tratar a não adoção de uma alteração posterior como invalidez.
• DEVE permitir aos participantes permanecer num conjunto de compatibilidade existente quando não adotarem uma alteração posterior.
• DEVE permitir aos participantes aderir a um novo conjunto de compatibilidade mediante a adoção de novas regras de validação ou perfis operacionais.
• DEVE permitir aos participantes rejeitar localmente estados, registos, transições ou mensagens inválidos ou incompatíveis segundo as regras de validação que executam.
• DEVE permitir aos participantes escolher voluntariamente contrapartes segundo as regras de validação e os conjuntos de compatibilidade que aceitam.
• NÃO DEVE autorizar qualquer instituição, registo, comité, organismo de políticas ou outro ator a declarar inválido um participante unicamente porque rejeitou uma alteração posterior.
• DEVERIA tornar explícitas as bifurcações, versões, perfis ou conjuntos de compatibilidade, para que os participantes saibam que regras executam e com que outros participantes podem interoperar.
• DEVERIA evitar qualquer desenho no qual um registo incumbente possa impedir que participantes que continuam válidos continuem a interoperar.

6.3. Implicações de desenho

A Decisão Futura Localizada não significa que uma autoridade central atribua decisões futuras a atores locais. Significa que o sistema é desenhado de modo que, depois da Especificação Inicial, as decisões futuras ordinárias não exijam essa atribuição.

A Especificação Inicial realiza antecipadamente o trabalho de limitação. Define os invariantes mínimos necessários para a unicidade, a interoperabilidade, a prova de controlo, a segurança partilhada e a segurança. Tudo o resto permanece fora da camada comum.

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

Um participante que rejeite uma alteração pode permanecer fora do conjunto de compatibilidade criado por essa alteração. Pode desligar-se dos outros. Pode continuar num conjunto de compatibilidade anterior. Pode bifurcar-se. Pode interoperar seletivamente. Mas não pode quebrar a interoperabilidade dos outros participantes que continuam a executar regras mutuamente compatíveis.

O efeito de um estado inválido ou incompatível é a rejeição local, não a punição. Não é necessário que alguém determine que um participante está em falta. Um participante que execute 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. Declaração

As alterações num sistema de coordenação da Internet DEVERIAM tornar-se realidade operacional através da implementação, validação, disponibilização, aceitação por contrapartes e adoção pelos participantes, e não apenas através de publicação ou declaração.

7.2. Requisitos

Um desenho que utilize este princípio:

• NÃO DEVE considerar a publicação, recomendação, aprovação em reuniões ou aprovação processual como suficiente para criar uma obrigação operacional universal.
• DEVE permitir que novas regras, extensões, perfis ou procedimentos sejam implementados incrementalmente pelos participantes que decidam executá-los.
• DEVE permitir aos participantes rejeitar uma alteração posterior sem adquirir um estado de invalidez, desde que as suas próprias transições de estado cumpram as regras deterministas do seu conjunto de compatibilidade.
• DEVE permitir aos participantes continuar a utilizar um conjunto de compatibilidade anterior quando a Especificação Inicial permitir essa continuidade.
• DEVE permitir aos participantes que operam num conjunto de compatibilidade rejeitar ou ignorar localmente estados de outro conjunto quando as regras forem incompatíveis.
• DEVERIA definir vias de adoção para alterações importantes, incluindo sinalização de versões, etiquetagem de compatibilidade, orientações de transição e vetores de teste.
• DEVERIA definir vias de rejeição para alterações importantes, incluindo a forma como os participantes não adotantes continuam a operar, identificam o seu conjunto de compatibilidade e evitam interoperabilidade ambígua.
• DEVE garantir que os artefactos de coordenação necessários possam ser abandonados, replicados, reimplementados ou substituídos sem custos de transição impossíveis.
• DEVERIA fazer com que os registos, recomendações e artefactos de coordenação descrevam a realidade adotada, em vez de tentarem declarar existente uma realidade futura não adotada.
• NÃO DEVE desenhar um sistema em que a única forma de uma alteração se tornar real seja o reconhecimento prévio por um organismo incumbente.

7.3. Implicações de desenho

A Adoção Voluntária é o teste operacional para saber se uma alteração é útil, tolerável e compatível com a implementação real.

Uma proposta não é a realidade. Uma recomendação não é a realidade. Um documento não é a realidade. A realidade surge quando os participantes implementam, validam, disponibilizam, aceitam contrapartes e dependem da alteração.

A não adoção não cria qualquer estado de infração. Cria apenas um facto: o participante não entrou no conjunto de compatibilidade criado pela alteração.

Isto não elimina processos de normalização, documentação, notas de implementação, exploradores, réplicas ou revisões. Limita o seu alcance. Podem ajudar os participantes a coordenar-se. Podem publicar material de referência. Podem descrever a adoção. Podem recomendar. Mas não podem, por si só e através de declaração, tornar vinculativa uma realidade futura não adotada para os participantes que não a executam.

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

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

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

A Decisão Futura Localizada garante que as decisões futuras permaneçam nos participantes que executam código, em vez de serem recapturadas por uma camada central de aprovação.

A Adoção Voluntária garante que as alterações posteriores tenham de sobreviver ao contacto com a implementação, a verificação, a aceitação por contrapartes e a utilização.

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

A Especificação Inicial Mínima sem Decisão Futura Localizada ainda pode permitir que a autoridade se acumule depois da implementação.
A Decisão Futura Localizada sem Especificação Inicial Mínima pode produzir ambiguidade, porque os participantes não conseguem determinar localmente a validade.
A Adoção Voluntária sem validação determinista pode produzir confusão, porque os participantes não conseguem distinguir variações compatíveis de estados inválidos.
A validação determinista sem estado distribuído pode continuar a deixar os participantes dependentes de um registo privilegiado.
O estado distribuído sem visibilidade de bifurcações pode ocultar o desacordo até à falha operacional.
O estado distribuído sem aceitação voluntária de contrapartes pode recriar a coerção através de outra interface.

Em conjunto, os princípios produzem um sistema no qual a camada comum é fina, a validade é verificável localmente, a alteração futura é voluntária, o estado é distribuído e não é necessária uma instituição permanente para decidir a operação ordinária.

9. Padrão de desenho recomendado

9.1. Camada comum distribuída determinista

A camada comum DEVERIA limitar-se a:

• semântica estável dos identificadores;
• regras de validade deterministas;
• regras de resolução de conflitos necessárias para preservar a unicidade;
• mecanismos de prova de controlo;
• regras de transição de estado;
• requisitos de interoperabilidade ao nível da rede ou do protocolo;
• invariantes de segurança partilhados;
• 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 modelos de negócio;
• regras de preços;
• preferências políticas regionais;
• ideologia de elegibilidade não relacionada com invariantes técnicos;
• poderes discricionários de execução;
• avaliações subjetivas de mérito;
• expansão da missão institucional;
• qualquer regra cuja função principal seja preservar a autoridade de um organismo incumbente.

9.2. Superfície de decisão do operador

Os seguintes elementos DEVERIAM permanecer fora da camada comum, salvo se alterarem diretamente um Invariante Global declarado:

• momento de implementação;
• uso comercial;
• geografia dos clientes;
• acordos de arrendamento, financiamento ou transferência;
• preferência local de elegibilidade;
• sequenciação operacional;
• prática de encaminhamento não exigida para a validade partilhada;
• modelo de negócio;
• estrutura organizacional;
• momento da migração voluntária;
• perfis ou extensões opcionais;
• escolha de contrapartes.

Os participantes PODEM adotar decisões diferentes nestas áreas. Essas decisões podem produzir diferentes conjuntos de compatibilidade, relações comerciais, acordos de peering ou comunidades operacionais. Não geram invalidez, salvo se violarem regras de validação deterministas dentro de um conjunto de compatibilidade.

9.3. Ciclo de adoção

Quando possível, a ordem preferida para alterações substanciais do sistema é:

• proposta;
• implementação;
• vetores de teste ou método de verificação determinista;
• colocação em produção em escala limitada por participantes que o desejem;
• observação dos efeitos de interoperabilidade e segurança;
• etiquetagem de conjuntos de compatibilidade;
• documentação ou recomendação que descreva a realidade adotada.

Um artefacto de coordenação DEVERIA seguir-se à adoção, em vez de tentar antecipá-la.

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

Um desenho conforme DEVERIA tratar a bifurcação, a rejeição local e a aceitação de contrapartes como requisitos normais de desenho, e não como falhas.

O sistema DEVERIA definir como um participante pode:

• continuar num conjunto de compatibilidade anterior;
• adotar um novo conjunto de compatibilidade;
• bifurcar-se para um conjunto de compatibilidade diferente;
• verificar o estado sem depender de um registo incumbente;
• aceitar contrapartes voluntariamente;
• rejeitar localmente estados inválidos ou incompatíveis;
• interoperar seletivamente quando a compatibilidade o permitir.

Um sistema que não possa ser bifurcado ou verificado localmente, nem permitir interoperabilidade seletiva sem destruir a operação válida, provavelmente ocultou poder de governação na sua função de registo.

10. Aplicabilidade e limites

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

• o sistema é multiator e multijurisdicional;
• a implementação independente é importante;
• a camada de coordenação se destina a permanecer fina;
• é provável que exista variação futura, mas esta não possa ser prevista em pormenor;
• o bloqueio ou a dependência (lock-in) criariam risco de governação;
• a validade pode ser tornada determinista ou verificável localmente;
• o estado distribuído pode reduzir o risco de captura institucional.

Pode ser menos diretamente aplicável quando:

• se trata de um único domínio administrativo como arquitetura prevista;
• um acoplamento forte em tempo real exige comportamento uniforme em todos os momentos;
• considerações de segurança vital exigem uniformidade global imediata;
• a validade não pode ser verificada localmente através de qualquer mecanismo prático.

Mesmo nesses casos, os designers DEVERIAM continuar a minimizar a camada comum e evitar, tanto quanto possível, o controlo discricionário futuro.

11. Não objetivos

Este documento não:

• proíbe toda a coordenação;
• exige qualquer implementação específica de livro-razão distribuído;
• garante consenso;
• garante neutralidade política;
• exige que todos os participantes adotem cada alteração posterior;
• trata a recusa de adoção como invalidez;
• legitima comportamento local incompatível sob a alegação de 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 fina pode reduzir o risco de captura, diminuir o raio de impacto de erros institucionais e melhorar a capacidade de substituição. No entanto, uma maior discricionariedade local e um estado distribuído também podem gerar posturas de segurança inconsistentes, vias de degradação, pressão de fragmentação, afirmações ambíguas de compatibilidade, bifurcações inseguras, disputas sobre o estado do livro-razão e tentativas de falsificação de provas.

Por conseguinte, os designers que apliquem este documento DEVEM especificar explicitamente os invariantes de segurança. Em particular:

• os requisitos de autenticação e autorização necessários para a validade partilhada DEVEM ser deterministas e verificáveis localmente;
• os mecanismos de prova de controlo DEVEM resistir à falsificação, à repetição e à transferência não autorizada;
• a negociação de versões e o tratamento de extensões DEVEM evitar degradações silenciosas quando a segurança for afetada;
• as vias de rejeição, bifurcação e substituição DEVEM ser analisadas quanto ao risco de abuso e de negação de serviço;
• as etiquetas de compatibilidade DEVERIAM ser suficientemente claras para evitar a interoperabilidade acidental entre conjuntos de regras incompatíveis;
• o estado distribuído DEVERIA ser auditável e reproduzível para detetar vistas inconsistentes;
• a variação local NÃO DEVE poder declarar falsamente compatibilidade com um conjunto de regras que não cumpre.

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

13. Considerações da IANA

Este documento não requer ações por parte da IANA.

14. Referências

14.1. Referências normativas

• RFC 2119 — Bradner, S., Palavras-chave para utilização em RFC para indicar níveis de requisitos, BCP 14, RFC 2119.
• RFC 8174 — Leiba, B., Ambiguidade entre maiúsculas e minúsculas nas palavras-chave da RFC 2119, BCP 14, RFC 8174.

14.2. Referências informativas

• RFC 6709 — Carpenter, B. e B. Aboba, Considerações de desenho para extensões de protocolos, RFC 6709.
• RFC 7282 — Resnick, P., Sobre consenso e zumbidos no IETF, RFC 7282.

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

Um desenho que afirme conformidade com este documento DEVERIA conseguir responder claramente às seguintes perguntas:

• Quais são os Invariantes Globais?
• Que regras de validação deterministas preservam esses Invariantes Globais?
• Que regras da Especificação Inicial são estritamente necessárias para a primeira implementação?
• Como é representado e verificado o estado válido?
• O estado é distribuído, replicado ou de outro modo verificável independentemente?
• Que questões futuras são intencionalmente deixadas fora da camada comum?
• Que decisões futuras podem os participantes tomar sem alterar o conjunto de compatibilidade em que se encontram?
• Como adota um participante uma alteração posterior?
• Como rejeita um participante uma alteração posterior sem lhe ser atribuído um estado de invalidez?
• Como são etiquetados ou descobertos os conjuntos de compatibilidade?
• Como funciona a rejeição local quando um estado é inválido ou incompatível segundo as regras que um participante executa?
• Qual é a via de bifurcação?
• Como demonstra um titular o controlo sem um registo incumbente?
• Como verifica uma contraparte o estado sem um registo?
• Podem os participantes verificar a validade ordinária sem depender de um registo incumbente?
• Os registos e artefactos de coordenação descrevem a realidade adotada ou tentam declarar existente uma realidade futura não adotada?
• O sistema minimizou o número de decisões incorporadas na camada comum?
• O sistema evitou qualquer autoridade permanente que determine o estado ordinário dos participantes?
• Podem os participantes aceitar ou rejeitar contrapartes voluntariamente?
• Pode o sistema continuar se todos os registos incumbentes desaparecerem?

Endereço do autor

Lu
[TBD]