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

Acordar a ligação, deixar espaço para conceções diferentes. Lu Heng propõe limitar as regras comuns ao que a interoperabilidade exige, deixando as escolhas posteriores aos próprios participantes.

Resumo

Este documento descreve um padrão de conceção para sistemas de coordenação da Internet destinados a fornecer pontos de referência técnicos comuns sem criar uma autoridade permanente acima dos participantes que fazem funcionar o sistema. Define três princípios interligados: Especificação Inicial Mínima, Decisão Futura Local e Adoção Voluntária.

Neste modelo, a Especificação Inicial define apenas as regras determinísticas, verificáveis localmente, necessárias à unicidade, à interoperabilidade, à segurança operacional partilhada e à segurança informática. Depois da Especificação Inicial, as alterações futuras não são aprovadas por um órgão central. São adotadas, ignoradas, bifurcadas ou abandonadas pelos participantes que executam o código.

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

Este documento não define um protocolo de comunicação ao nível da transmissão. Especifica uma Melhor Prática Atual para a conceção de protocolos, registos, sistemas de identificadores e mecanismos de coordenação que não devem tornar-se instituições permanentes de governação.

1. Introdução

Muitos sistemas da Internet começam com uma finalidade técnica limitada: permitir que agentes independentes interoperem através de um ponto de referência comum, de um espaço de identificadores, de uma regra de validação ou de um registo de natureza semelhante ao de uma entidade de registo. Com o tempo, esses sistemas acumulam frequentemente uma autoridade que não era necessária à interoperabilidade inicial.

Isto acontece habitualmente em três etapas.

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

Segundo, escolhas que deveriam caber aos participantes que fazem funcionar os seus próprios sistemas passam a depender de decisões de reconhecimento, interpretação ou estatuto tomadas por um órgão permanente.

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

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

Este documento propõe uma disciplina de conceção diferente:

– Especificação Inicial Mínima: especificar apenas as regras comuns determinísticas necessárias à interoperabilidade de base, à unicidade, à segurança operacional partilhada e à segurança informática.
– Decisão Futura Local: depois da Especificação Inicial, manter as escolhas futuras nas mãos dos participantes que executam o código. Um participante pode adotar, recusar, bifurcar, desligar-se ou interoperar seletivamente. Nenhum participante pode alterar a interoperabilidade de outros participantes que continuem a executar regras mutuamente compatíveis.
– Adoção Voluntária: tornar uma alteração posterior real apenas através da implementação, da operação, da validação e da adoção pelos participantes que executam o código.

Estes princípios estão relacionados. Um sistema que especifica demasiado no início incorpora antecipadamente controlo futuro na camada comum. Um sistema que mantém uma camada permanente de reconhecimento permite que a autoridade reapareça depois da entrada em funcionamento. Um sistema que trata a publicação como realidade converte a documentação em comando.

A intuição subjacente à conceção é simples: a validade tem de ser determinada por regras determinísticas que os participantes possam verificar localmente. Um participante pode adotar uma alteração posterior, recusá-la, bifurcar, desligar-se ou interoperar seletivamente. No máximo, pode retirar-se de um conjunto de compatibilidade. Ao recusar uma alteração, não pode quebrar a interoperabilidade dos outros participantes que continuem a executar código mutuamente compatível.

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

2. Âmbito

Este documento aplica-se a sistemas de coordenação da Internet, incluindo, entre outros, registos partilhados, sistemas de identificadores, estruturas de atribuição de nomes e números, mecanismos de extensão de protocolos, sistemas de prova de controlo, sistemas de portabilidade e outras arquiteturas em que agentes independentes dependem de um ponto de referência técnico comum.

Este documento não se opõe à existência de regras comuns. Defende que as regras comuns devem ser determinísticas, mínimas, verificáveis localmente e limitadas ao que o sistema realmente precisa para funcionar.

Este documento não exige uma cadeia de blocos, um livro de registos distribuído ou qualquer tecnologia específica. Exige uma propriedade de conceção: os participantes devem poder determinar a validade aplicando localmente a Especificação Inicial, sem pedir autorização ou uma decisão sobre o seu estatuto 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ário à primeira entrada em funcionamento de um sistema.

Camada Comum:
O conjunto mínimo de regras partilhadas ou a estrutura de referência 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, através de cálculo local ou de verificação local, se um estado, registo, transição, asserção ou mensagem é válido segundo um conjunto de regras especificado.

Invariante Global:
Uma propriedade que tem de permanecer comum dentro de um conjunto de compatibilidade para preservar a unicidade, a interoperabilidade de base, a segurança operacional partilhada ou a segurança informática.

Participante:
Um operador, implementação, nó, rede, organização ou outro agente que faça funcionar, verifique, coloque em funcionamento ou utilize o sistema como base da sua atividade.

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

Adoção:
A implementação, a entrada em funcionamento, a validação e a utilização efetivas pelos participantes que fazem funcionar o sistema.

Não Adoção:
A escolha de um participante de não implementar nem utilizar uma alteração proposta. A não adoção não cria um estatuto de invalidade. Significa apenas que o participante não aderiu ao conjunto de compatibilidade criado por essa alteração.

Rejeição Local:
A 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:
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:
Um documento, entrada de registo, recomendação, nota de implementação, perfil, implementação de referência ou outro artefacto que ajude os participantes a coordenarem-se. Um artefacto de coordenação não cria uma realidade operacional vinculativa, a menos que os participantes o adotem em sistemas em funcionamento.

4. Formulação do problema

Quem concebe sistemas tenta frequentemente reduzir a incerteza futura escrevendo demasiado na camada fundadora ou deixando um órgão permanente encarregado de interpretar questões futuras. Isto parece prudente. Muitas vezes, é perigoso.

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

Primeiro, desloca escolhas 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 órgão que mantém registos, publica documentos ou reúne participantes a tratar esses atos como autoridade sobre a realidade futura.

O mesmo problema surge depois da entrada em funcionamento. Se um sistema exige um órgão permanente para aprovar alterações, determinar estatutos ou interpretar o funcionamento normal, criou uma camada de controlo posterior à fundação. Essa camada pode começar como administração. Pode tornar-se governação. Pode depois tornar-se um ponto de estrangulamento.

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

Um sistema de coordenação da Internet bem concebido deve definir de 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 as alterações posteriores só se tornem reais quando os participantes as adotarem voluntariamente em sistemas em funcionamento.

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

5.1. Enunciado

Uma Especificação Inicial DEVERIA definir apenas o mínimo de regras comuns determinísticas necessário à interoperabilidade de base, à unicidade, à segurança operacional partilhada e à segurança informática.

5.2. Requisitos

Uma conceção que aplique este princípio:

1. DEVE identificar explicitamente os seus Invariantes Globais.
2. DEVE definir regras de validação determinísticas para cada Invariante Global.
3. NÃO DEVE incluir uma regra na Especificação Inicial, a menos que essa regra seja necessária para preservar um Invariante Global enunciado ou para permitir a primeira entrada em funcionamento.
4. DEVE separar as regras de validação das preferências de política, dos acordos comerciais, dos papéis institucionais, das aspirações de governação e do juízo discricionário.
5. DEVE permitir que os participantes verifiquem localmente a validade no funcionamento normal, sem consultar qualquer instituição, entidade de registo, comissão, órgão de definição de políticas ou outra autoridade.
6. DEVERIA definir estruturas de dados, assinaturas, provas, regras de transição de estado, regras para conflitos ou outros mecanismos necessários à verificação local.
7. DEVERIA definir a sinalização de extensões, a gestão de versões, a identificação da compatibilidade ou a identificação de bifurcações quando seja previsível uma variação futura.
8. DEVE garantir que os artefactos de coordenação necessários sejam portáveis, auditáveis, reproduzíveis e substituíveis.
9. DEVERIA dar preferência a condições objetivas verificáveis por máquina em vez de juízos subjetivos de mérito.
10. 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 para a conceção

Especificação Inicial Mínima não significa especificação vaga. Significa especificar rigorosamente apenas aquilo que tem de ser comum.

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

– o que tem de ser comum para garantir a unicidade, a interoperabilidade, a segurança operacional partilhada e a segurança informática; e
– o que pode permanecer fora da camada comum por dizer respeito às preferências do operador, à prática comercial, ao momento da entrada em funcionamento ou à escolha de adoção posterior.

Uma conceção que não consiga enunciar claramente os seus Invariantes Globais e as suas regras de validação determinísticas deve partir do princípio de que especificou demasiada discricionariedade e demasiado pouca substância verificável.

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

6.1. Enunciado

Depois da Especificação Inicial, as Decisões Futuras DEVERIAM permanecer locais, nas mãos dos participantes que executam o código. Uma Decisão Futura só produz efeitos no conjunto de compatibilidade cujos participantes a adotam. Não é necessária uma autoridade permanente para a aprovar, e a não adoção não cria um estatuto de invalidade.

6.2. Requisitos

Uma conceção que aplique este princípio:

1. NÃO DEVE exigir que os participantes obtenham autorização de uma instituição estabelecida, entidade de registo, comissão, direção, órgão de definição de políticas ou outra autoridade para escolhas que não alterem as regras de validação determinísticas do conjunto de compatibilidade em que participam.
2. NÃO DEVE criar um órgão permanente cujo reconhecimento seja a única via pela qual uma alteração posterior possa tornar-se uma realidade operacional.
3. DEVE distinguir a validade segundo a Especificação Inicial da compatibilidade com uma alteração opcional posterior.
4. NÃO DEVE tratar a não adoção de uma alteração posterior como invalidade.
5. DEVE permitir que os participantes permaneçam num conjunto de compatibilidade existente quando não adotam uma alteração posterior.
6. DEVE permitir que os participantes adiram a um novo conjunto de compatibilidade adotando novas regras de validação ou novos perfis operacionais.
7. DEVE permitir que os participantes rejeitem localmente estados, registos, transições ou mensagens que sejam inválidos ou incompatíveis segundo as regras de validação que executam.
8. NÃO DEVE autorizar qualquer instituição, entidade de registo, comissão, órgão de definição de políticas ou outro agente a declarar um participante inválido apenas por ter recusado uma alteração posterior.
9. DEVERIA tornar explícitas as bifurcações, versões, perfis ou conjuntos de compatibilidade, para que os participantes saibam que regras estão a executar e com que outros participantes podem interoperar.
10. DEVERIA evitar qualquer conceção em que um responsável pelos registos já estabelecido possa impedir participantes que, de outro modo, seriam válidos de continuarem a interoperar.

6.3. Implicações para a conceção

Decisão Futura Local não significa que uma autoridade central atribua decisões futuras a agentes locais. Significa que o sistema é concebido de modo a que, depois da Especificação Inicial, as escolhas futuras correntes não necessitem dessa atribuição.

A Especificação Inicial faz antecipadamente o trabalho de delimitação. Define os invariantes mínimos necessários à unicidade, à interoperabilidade, à segurança operacional partilhada e à segurança informática. 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 o código.

Um participante que recuse 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 mais antigo. Pode bifurcar. Pode interoperar seletivamente. Mas não pode quebrar a interoperabilidade de outros participantes que continuem 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. Ninguém precisa de decidir que um participante se encontra em situação irregular. 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. Enunciado

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

7.2. Requisitos

Uma conceção que aplique este princípio:

1. NÃO DEVE tratar a publicação, o registo, a recomendação, a aprovação numa reunião ou a aprovação processual como suficientes para criar uma obrigação operacional universal.
2. DEVE permitir que novas regras, extensões, perfis ou procedimentos sejam colocados em funcionamento de forma incremental pelos participantes que escolham executá-los.
3. DEVE permitir que os participantes recusem uma alteração posterior sem adquirirem um estatuto de invalidade, desde que as suas próprias transições de estado satisfaçam as regras de validação determinísticas do seu conjunto de compatibilidade.
4. DEVE permitir que os participantes continuem a utilizar um conjunto de compatibilidade mais antigo quando a Especificação Inicial permita essa continuidade.
5. DEVE permitir que os participantes que executam as regras de um conjunto de compatibilidade rejeitem ou ignorem localmente estados provenientes de outro conjunto de compatibilidade quando as regras forem incompatíveis.
6. DEVERIA definir vias de adoção para alterações importantes, incluindo sinalização de versões, identificação da compatibilidade, orientações de transição e vetores de teste.
7. DEVERIA definir vias de recusa para alterações importantes, incluindo a forma como os participantes que não as adotam continuam a operar, identificam o seu conjunto de compatibilidade e evitam uma interoperabilidade ambígua.
8. DEVE garantir que seja possível abandonar, portar, espelhar, reimplementar ou substituir os artefactos de coordenação necessários sem custos de transição incomportáveis.
9. DEVERIA fazer com que os sistemas de registo, os registos, as recomendações e os artefactos de coordenação descrevam a realidade adotada, em vez de declararem a existência de uma realidade futura ainda não adotada.
10. DEVE evitar a conceção de um sistema em que a única forma de uma alteração se tornar real seja o reconhecimento prévio por um órgão já estabelecido.

7.3. Implicações para a conceção

A Adoção Voluntária é o teste operacional que permite saber se uma alteração é útil, tolerável e compatível com a entrada efetiva em funcionamento.

Uma proposta não é realidade. Uma recomendação não é realidade. Uma atualização de registo não é realidade. Um documento não é realidade. A realidade surge quando os participantes implementam, validam, colocam em funcionamento e passam a apoiar a sua atividade na alteração.

A não adoção não cria qualquer estatuto de infração. Cria apenas um facto: o participante não aderiu ao conjunto de compatibilidade criado pela alteração.

Isto não elimina os processos de normalização, os registos, a documentação ou a revisão. Limita a sua pretensão. Podem ajudar os participantes a coordenarem-se. Podem publicar material de referência. Podem descrever a adoção. Podem recomendar. Não podem, por mera declaração, tornar uma realidade futura ainda não adotada vinculativa para 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 de forma isolada.

A Especificação Inicial Mínima garante que a camada comum contém regras de validação determinísticas em vez de autoridade discricionária.

A Decisão Futura Local garante que as escolhas futuras permanecem nas mãos dos participantes que executam o código, em vez de serem recapturadas por uma camada central de aprovação.

A Adoção Voluntária garante que uma alteração posterior tem de resistir ao contacto com a implementação 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 Local pode ainda permitir a acumulação de autoridade depois da entrada em funcionamento.
– A Decisão Futura Local 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 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 possibilidade de saída, portabilidade ou substituição pode ainda produzir dependência forçada se se tornar impossível abandonar os artefactos de manutenção de registos.

Em conjunto, os princípios produzem um sistema em que a camada comum é reduzida, a validade é verificável localmente, a alteração futura é voluntária e não é necessária uma instituição permanente para decidir sobre o funcionamento normal.

9. Padrão de conceção recomendado

9.1. Camada comum determinística

A camada comum DEVERIA limitar-se 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 ao nível da transmissão ou do protocolo;
– invariantes partilhados de segurança informática;
– mecanismos de prova de controlo, quando necessários;
– formatos de registo portáveis e auditáveis, quando forem necessários registos;
– sinalização de extensões e identificação do conjunto de compatibilidade.

A camada comum NÃO DEVERIA conter:

– regras sobre modelos de negócio;
– regras de preços;
– preferências políticas regionais;
– uma ideologia de elegibilidade sem relação com invariantes técnicos;
– poderes discricionários de imposição do cumprimento;
– avaliações subjetivas de mérito;
– alargamento da missão institucional;
– qualquer regra cuja função principal seja preservar a autoridade de um órgão já estabelecido.

9.2. Âmbito de decisão do operador

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

– momento da entrada em funcionamento;
– utilização comercial;
– localização geográfica dos clientes;
– acordos de locação, financiamento ou transferência;
– preferências locais de elegibilidade;
– sequência das operações;
– práticas de encaminhamento não necessárias à validade partilhada;
– modelo de negócio;
– estrutura organizacional;
– momento da migração voluntária;
– perfis ou extensões opcionais.

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

9.3. Ciclo de adoção

Quando viável, a ordem preferível para uma alteração substancial do sistema é:

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

Um artefacto de coordenação DEVERIA acompanhar a adoção, em vez de tentar antecipar-se-lhe.

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

Uma conceção conforme a este documento DEVERIA tratar a saída, a bifurcação e a portabilidade como requisitos normais de conceção, e não como falhas.

O sistema DEVERIA definir como um participante pode:

– continuar num conjunto de compatibilidade mais antigo;
– adotar um conjunto de compatibilidade mais recente;
– bifurcar para um conjunto de compatibilidade diferente;
– portar registos, identificadores, provas ou estado operacional;
– verificar a validade de registos sem depender de um responsável pelos registos já estabelecido;
– interoperar seletivamente quando a compatibilidade o permita.

Um sistema que não possa ser abandonado ou bifurcado sem destruir o funcionamento válido provavelmente escondeu poder de governação dentro da sua função de manutenção de registos.

10. Aplicabilidade e limites

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

– o sistema envolve múltiplos agentes e múltiplas jurisdições;
– a entrada em funcionamento independente é importante;
– se pretende que a camada de coordenação permaneça reduzida;
– é provável que haja variação futura, mas não é possível prevê-la em pormenor;
– a dependência forçada criaria um risco de governação;
– a validade pode ser tornada determinística ou verificável localmente.

Pode ser menos diretamente aplicável quando:

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

Mesmo nesses casos, quem concebe o sistema DEVERIA continuar a minimizar a camada comum e a evitar o controlo discricionário futuro sempre que possível.

11. O que não constitui objetivo

Este documento não:

– proíbe toda a coordenação;
– proíbe todos os registos partilhados;
– exige tecnologia de cadeia de blocos ou de livro de registos distribuído;
– garante consenso;
– garante neutralidade política;
– exige que todos os participantes adotem todas as alterações posteriores;
– trata a recusa de adoção como invalidade;
– legitima um comportamento local incompatível que alegue ser compatível;
– elimina a necessidade de regras comuns essenciais à segurança informática.

12. Considerações de segurança informática

Uma camada de coordenação mais reduzida pode diminuir o risco de captura, limitar o alcance dos danos causados por um erro institucional e melhorar a possibilidade de substituição. Contudo, uma maior discricionariedade local pode também criar posturas de segurança inconsistentes, vias de redução do nível de segurança, pressão para a fragmentação, alegações ambíguas de compatibilidade e bifurcações inseguras.

Quem aplicar este documento à conceção de um sistema DEVE, por isso, especificar explicitamente os invariantes de segurança informática. Em particular:

– os requisitos de autenticação e autorização necessários à validade partilhada DEVEM ser determinísticos e verificáveis localmente;
– a negociação de versões e o tratamento de extensões DEVEM evitar reduções silenciosas do nível de segurança quando a segurança informática seja afetada;
– as vias de recusa, 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 impedir a interoperabilidade acidental entre conjuntos de regras incompatíveis;
– NÃO DEVE ser permitido que uma variação local alegue falsamente compatibilidade com um conjunto de regras que não satisfaz.

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

13. Considerações relativas à IANA

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

14. Referências

14.1. Referências normativas

– RFC 2119 — Bradner, S., Palavras-chave a utilizar em RFC 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 conceção para extensões de protocolos, RFC 6709.
– RFC 7282 — Resnick, P., Sobre o consenso e o murmúrio na IETF, RFC 7282.

Apêndice A. Lista de verificação da conceção

Uma conceção que alegue conformidade com este documento DEVERIA ser capaz de responder claramente às seguintes perguntas:

1. Quais são os Invariantes Globais?
2. Que regras de validação determinísticas preservam esses Invariantes Globais?
3. Que regras da Especificação Inicial são estritamente necessárias à primeira entrada em funcionamento?
4. Que questões futuras são intencionalmente deixadas fora da camada comum?
5. Que escolhas futuras podem ser feitas pelos participantes sem alterar o conjunto de compatibilidade em que se encontram?
6. Como adota um participante uma alteração posterior?
7. Como recusa um participante uma alteração posterior sem que lhe seja atribuído um estatuto de invalidade?
8. Como são identificados ou descobertos os conjuntos de compatibilidade?
9. Como funciona a rejeição local quando um estado é inválido ou incompatível segundo as regras que um participante executa?
10. Qual é a via de bifurcação?
11. Qual é a via de portabilidade?
12. Qual é a via de saída de qualquer artefacto de coordenação necessário?
13. Podem os participantes verificar a validade no funcionamento normal sem depender de um responsável pelos registos já estabelecido?
14. Os registos e os artefactos 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 na camada comum?
16. O sistema evitou qualquer autoridade permanente que determine o estatuto dos participantes no funcionamento normal?

Morada do autor

H. Lu