Especificação Inicial Mínima, Decisão Futura Local e Adoção Voluntária para um sistema de coordenação da Internet

Chegar a um acordo sobre o encaixe e deixar espaço para desenhos diferentes. Lu Heng propõe limitar as regras compartilhadas ao que a interoperabilidade exige, deixando as escolhas posteriores a cargo dos próprios participantes.

Resumo

Este documento descreve um padrão de desenho 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 Local e Adoção Voluntária.

Nesse modelo, a Especificação Inicial define apenas as regras determinísticas e verificáveis localmente necessárias à unicidade, à interoperabilidade, à segurança operacional compartilhada e à segurança contra ameaças. Após a Especificação Inicial, mudanças futuras não são aprovadas por um órgão central. São adotadas, ignoradas, bifurcadas ou abandonadas pelos participantes que executam código.

A não adoção não é uma violação. 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 aceitas por outro participante pode ser ignorado localmente por esse outro participante. O efeito é seleção de compatibilidade, bifurcação, isolamento ou interoperação seletiva, e não punição institucional.

Este documento não define um protocolo de transmissão. Ele especifica uma Melhor Prática Atual para o desenho de protocolos, sistemas de registro, sistemas de identificadores 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 ou um registro semelhante ao de uma entidade de registro. Com o tempo, esses sistemas frequentemente acumulam uma autoridade que não era necessária à 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 condição tomadas por um órgão permanente.

Terceiro, a publicação, o registro, a recomendação ou a aprovação procedimental são tratados como suficientes para criar uma obrigação operacional, mesmo quando os participantes não adotaram a mudança em 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 desenho diferente:

– Especificação Inicial Mínima: especificar apenas as regras comuns determinísticas necessárias à interoperabilidade básica, à unicidade, à segurança operacional compartilhada e à segurança contra ameaças.
– Decisão Futura Local: após a Especificação Inicial, manter as escolhas futuras com os participantes que executam código. Um participante pode adotar, recusar, bifurcar, desconectar-se 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 da 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 insere antecipadamente o controle futuro na camada comum. Um sistema que mantém uma camada permanente de reconhecimento permite que a autoridade reapareça após a implantação. Um sistema que trata a publicação como realidade transforma documentação em comando.

A intuição por trás do desenho é simples: a validade deve ser determinada por regras determinísticas que os participantes possam verificar localmente. Um participante pode adotar uma mudança posterior, recusá-la, bifurcar, desconectar-se ou interoperar seletivamente. No máximo, pode retirar a si mesmo de um conjunto de compatibilidade. Ao recusar uma mudança, não pode interromper a interoperabilidade dos demais participantes que continuam executando código mutuamente compatível.

Essa é a mesma lição geral que se observa em sistemas como o Bitcoin: as regras de consenso são efetivadas por quem executa o código de validação, e não por uma instituição situada acima dessas pessoas.

2. Escopo

Este documento se aplica a sistemas de coordenação da Internet, incluindo, entre outros, registros compartilhados, sistemas de identificadores, estruturas de nomes e numeração, mecanismos de extensão de protocolos, sistemas de prova de controle, sistemas de portabilidade 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 determinísticas, mínimas, verificáveis localmente e limitadas ao que o sistema efetivamente precisa para funcionar.

Este documento não exige blockchain, livro-razão distribuído nem qualquer tecnologia específica. Exige uma propriedade do desenho: os participantes devem ser capazes de determinar a validade aplicando localmente a Especificação Inicial, sem pedir permissão ou uma decisão sobre sua condição a uma autoridade permanente.

3. Convenções e definições

3.1. Linguagem dos requisitos

Os termos de requisito escritos 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 e regras de transição necessários à 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.

Regra de Validação Determinística:
Uma regra que permite a um participante decidir, por computação local ou verificação local, se um estado, registro, transição, afirmaçã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 segurança operacional compartilhada ou a segurança contra ameaças.

Participante:
Um operador, implementação, nó, rede, organização ou outro ator que executa, verifica, implanta ou utiliza o sistema como base para sua operação.

Conjunto de Compatibilidade:
Um grupo de participantes cujas regras de validação implementadas permitem que interoperem. 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.

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 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, entrada de registro, recomendação, nota de implementação, perfil, implementação de referência ou outro artefato que ajuda 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 responsáveis pelo desenho frequentemente tentam reduzir a incerteza futura inserindo conteúdo demais na camada fundadora ou mantendo um órgão permanente para interpretar questões futuras. Isso parece prudente. Muitas vezes é perigoso.

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

Primeiro, desloca escolhas futuras para uma camada comum na qual a mudança é mais difícil e a captura tem maior efeito.

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

Terceiro, incentiva um órgão que mantém registros, publica documentos ou reúne participantes a tratar esses atos como autoridade sobre a realidade futura.

O mesmo problema aparece após a implantação. Se um sistema exige um órgão permanente para aprovar mudanças, determinar a condição dos participantes ou interpretar a operação comum, 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 desenho deste documento não é melhorar a discricionariedade institucional. É evitar a necessidade dessa discricionariedade.

Um sistema de coordenação da Internet bem desenhado deve definir, desde o início, regras de validade determinísticas e verificáveis localmente; deve deixar fora da camada comum as escolhas que não dizem respeito a invariantes; e deve permitir que mudanças posteriores se tornem reais apenas 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 necessárias à interoperabilidade básica, à unicidade, à segurança operacional compartilhada e à segurança contra ameaças.

5.2. Requisitos

Um desenho que utiliza este princípio:

1. DEVE identificar explicitamente seus Invariantes Globais.
2. DEVE definir regras de validação determinísticas para cada Invariante Global.
3. NÃO DEVE inserir uma regra na Especificação Inicial, a menos que ela seja necessária para preservar um Invariante Global declarado ou viabilizar a primeira implantação.
4. DEVE separar as regras de validação das preferências de política, dos arranjos comerciais, dos papéis institucionais, das aspirações de governança e do julgamento discricionário.
5. DEVE permitir que os participantes verifiquem localmente a validade ordinária sem consultar qualquer instituição, entidade de registro, comitê, órgão de políticas ou outra autoridade.
6. DEVERIA definir estruturas de dados, assinaturas, provas, regras de transição de estado, regras de conflito ou outros mecanismos necessários à verificação local.
7. DEVERIA definir sinalização de extensões, versionamento, identificação de compatibilidade ou identificação de bifurcações quando for possível prever variações futuras.
8. DEVE garantir que os artefatos de coordenação exigidos sejam portáveis, auditáveis, reproduzíveis e substituíveis.
9. DEVERIA preferir condições objetivas verificáveis por máquina a julgamentos subjetivos de mérito.
10. 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 para o desenho

Especificação Inicial Mínima não significa especificação vaga. Significa especificar rigorosamente apenas aquilo 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 garantir a unicidade, a interoperabilidade, a segurança operacional compartilhada e a segurança contra ameaças; e
– o que pode permanecer fora da camada comum por dizer respeito à preferência do operador, à prática comercial, ao momento da implantação ou à escolha de adoção posterior.

Um desenho que não consiga enunciar claramente seus Invariantes Globais e suas regras de validação determinísticas deve presumir que especificou discricionariedade demais e substância verificável de menos.

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

6.1. Enunciado

Após a 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. Não é necessária uma autoridade permanente para aprová-la, e a não adoção não cria uma condição de invalidade.

6.2. Requisitos

Um desenho que utiliza este princípio:

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

6.3. Implicações para o desenho

Decisão Futura Local não significa que uma autoridade central distribua decisões futuras a atores locais. Significa que o sistema é desenhado de modo que, após a Especificação Inicial, as escolhas futuras comuns não precisem dessa distribuição.

A Especificação Inicial faz antecipadamente o trabalho de delimitação. Define os invariantes mínimos necessários à unicidade, à interoperabilidade, à segurança operacional compartilhada e à segurança contra ameaças. Todo o restante permanece fora da camada comum.

Uma 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 bifurcar. Pode interoperar seletivamente. Mas não pode interromper 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, e 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

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

7.2. Requisitos

Um desenho que utiliza este princípio:

1. NÃO DEVE tratar a publicação, o registro, a recomendação, a aprovação em reunião ou a aprovação procedimental como suficientes para criar uma obrigação operacional universal.
2. DEVE permitir que novas regras, extensões, perfis ou procedimentos sejam implantados gradualmente pelos participantes que decidirem executá-los.
3. 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 de validação determinísticas de seu conjunto de compatibilidade.
4. DEVE permitir que os participantes continuem utilizando um conjunto de compatibilidade mais antigo quando a Especificação Inicial permitir essa continuidade.
5. DEVE permitir que os participantes que operam em um conjunto de compatibilidade rejeitem ou ignorem localmente estados de outro conjunto de compatibilidade quando as regras forem incompatíveis.
6. DEVERIA definir caminhos de adoção para mudanças de grande porte, incluindo sinalização de versões, identificação de compatibilidade, orientações de transição e vetores de teste.
7. DEVERIA definir caminhos de recusa para mudanças de grande porte, incluindo como os participantes que não as adotam continuam operando, identificam seu conjunto de compatibilidade e evitam uma interoperação ambígua.
8. DEVE garantir que seja possível deixar de utilizar os artefatos de coordenação exigidos, portá-los, espelhá-los, reimplementá-los ou substituí-los sem um custo de transição inviável.
9. DEVERIA fazer com que entidades de registro, registros, recomendações e artefatos de coordenação descrevam a realidade adotada, em vez de declarar a existência de uma realidade futura ainda não adotada.
10. DEVE evitar o desenho de um sistema no qual o único modo de uma mudança se tornar real seja o reconhecimento prévio por um órgão estabelecido.

7.3. Implicações para o desenho

A Adoção Voluntária é o teste operacional para avaliar 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. Uma atualização de registro não é realidade. Um documento não é realidade. A realidade aparece quando os participantes implementam, validam, implantam e passam a depender da mudança.

A não adoção não cria uma condição de violaçã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, entidades de registro, documentação 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, por mera 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 garante que a camada comum contenha regras de validação determinísticas, em vez de autoridade discricionária.

A Decisão Futura Local garante 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 garante que uma mudança posterior tenha de sobreviver ao contato com a implementação 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 Local ainda pode permitir que a autoridade se acumule após a implantação.
– A Decisão Futura Local 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 saída, portabilidade ou possibilidade de substituição ainda pode produzir aprisionamento se os artefatos de manutenção de registros se tornarem impossíveis de abandonar.

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

9. Padrão de desenho recomendado

9.1. Camada comum determinística

A camada comum DEVERIA se limitar a:

– semântica estável dos identificadores;
– regras de validade determinísticas;
– regras de resolução de conflitos necessárias para preservar a unicidade;
– requisitos de interoperabilidade no nível da transmissão ou do protocolo;
– invariantes de segurança compartilhados;
– mecanismos de prova de controle, quando necessários;
– formatos de registro portáveis e auditáveis, quando os registros forem necessários;
– sinalização de extensões e identificação do conjunto de compatibilidade.

A camada comum NÃO DEVERIA conter:

– regras de modelo de negócio;
– 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 de regras;
– avaliações subjetivas de mérito;
– expansão da missão institucional;
– qualquer regra cuja função principal seja preservar a autoridade de um órgão estabelecido.

9.2. Âmbito de decisão dos operadores

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

– momento da implantação;
– uso comercial;
– localização geográfica dos clientes;
– arranjos de locação, financiamento ou transferência;
– preferência local de elegibilidade;
– sequenciamento operacional;
– prática de roteamento que não seja necessária à validade compartilhada;
– modelo de negócio;
– estrutura organizacional;
– momento da migração voluntária;
– perfis ou extensões opcionais.

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

9.3. Ciclo de adoção

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

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

Um artefato de coordenação DEVERIA vir depois da adoção, em vez de tentar antecipar-se a ela.

9.4. Saída, bifurcação e portabilidade

Um desenho conforme a este documento DEVERIA tratar a saída, a bifurcação e a portabilidade como requisitos normais de desenho, 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;
– bifurcar para um conjunto de compatibilidade diferente;
– portar registros, identificadores, provas ou estado operacional;
– verificar a validade dos registros sem depender de um responsável estabelecido pela manutenção dos registros;
– interoperar seletivamente quando a compatibilidade permitir.

Um sistema do qual não seja possível sair ou bifurcar sem destruir a operação válida provavelmente escondeu poder de governança em sua função de manutenção de registros.

10. Aplicabilidade e limites

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

– o sistema envolve múltiplos atores e múltiplas jurisdições;
– a implantação independente importa;
– pretende-se que a camada de coordenação permaneça enxuta;
– variações futuras são prováveis, mas não podem ser previstas em detalhe;
– o aprisionamento criaria um risco de governança;
– a validade pode ser tornada determinística ou verificável localmente.

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;
– questões de proteção da vida humana exigem uniformidade global imediata;
– a validade não pode ser verificada localmente por nenhum mecanismo viável.

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

11. O que não constitui objetivo

Este documento não:

– proíbe toda coordenação;
– proíbe todos os registros compartilhados;
– exige tecnologia de blockchain ou de livro-razão distribuído;
– garante consenso;
– garante neutralidade política;
– exige que todos os participantes adotem todas as mudanças posteriores;
– trata a recusa em adotar como invalidade;
– legitima comportamento local incompatível que alegue ser compatível;
– 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 facilitar a substituição. Entretanto, uma maior discricionariedade local também pode criar posturas de segurança inconsistentes, caminhos para rebaixamento do nível de segurança, pressão por fragmentação, alegações ambíguas de compatibilidade e bifurcações inseguras.

Os responsáveis pelo desenho 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;
– 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 ao risco de abuso e de 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;
– NÃO DEVE ser permitido que uma variação local alegue falsamente ser compatível 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 de segurança determinísticas 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 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 murmúrios na IETF, RFC 7282.

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

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

1. Quais são os Invariantes Globais?
2. Quais regras de validação determinísticas preservam esses Invariantes Globais?
3. Quais regras da Especificação Inicial são estritamente necessárias à primeira implantação?
4. Quais questões futuras são intencionalmente deixadas fora da camada comum?
5. Quais escolhas futuras podem ser feitas pelos participantes sem alterar o conjunto de compatibilidade em que estão?
6. Como um participante adota uma mudança posterior?
7. Como um participante recusa uma mudança posterior sem que lhe seja atribuída uma condição de invalidade?
8. Como os conjuntos de compatibilidade são identificados ou descobertos?
9. Como funciona a rejeição local quando um estado é inválido ou incompatível segundo as regras que um participante executa?
10. Qual é o caminho de bifurcação?
11. Qual é o caminho de portabilidade?
12. Qual é o caminho para deixar de utilizar qualquer artefato de coordenação exigido?
13. Os participantes conseguem verificar a validade ordinária sem depender de um responsável estabelecido pela manutenção dos registros?
14. Os registros e artefatos de coordenação descrevem a realidade adotada ou tentam declarar a existência de uma realidade futura ainda não adotada?
15. O sistema minimizou o número de decisões incorporadas à camada comum?
16. O sistema evitou qualquer autoridade permanente que determine a condição ordinária dos participantes?

Endereço do autor

H. Lu