Resumo

  • A RFC 1264 dividiu a maturidade de um protocolo de roteamento entre especificação reproduzível, gestão, arquitetura de segurança, implementações independentes, testes completos, experiência operacional e limites de escala.
  • A RFC 4794 eliminou em 2006 a exigência adicional para todos os documentos de roteamento por prejudicar a rapidez, mas manteve o poder do IESG de pedir experiência e a escolha dos grupos de trabalho de conservar processos próprios.
  • Textos posteriores continuaram separando status e execução: a RFC 6410 ligou Internet Standard a interoperabilidade independente, implantação ampla e operação bem-sucedida; a RFC 7942 tornou o registro de implementação útil, voluntário e possivelmente não verificado.

O protocolo chegava com um armário de provas

A RFC 1264 partia de uma característica do roteamento: algoritmos distribuídos e em tempo real podem funcionar numa implementação e topologia, mas falhar diante de outro código ou de um limite inesperado. A aparência estável do documento não resumia esse risco.

Por isso havia registros separados. A especificação e o uso deveriam permitir que terceiros criassem implementações interoperáveis sem consultar os autores. A MIB definia estado administrável. A arquitetura de segurança descrevia autenticação. Origem do código, cenários, resultados, ambiente operacional e análise de escala tratavam da execução.

Um campo não completava o outro. Descrever autenticação não provava seu funcionamento entre implementações; publicar uma MIB não provava monitoramento; uma especificação clara não provava implantação.

Independência era uma questão de procedência

A regra geral exigia várias implementações interoperáveis, com pelo menos duas escritas de forma independente. Dois produtos derivados do mesmo código podem repetir a mesma interpretação e o mesmo defeito. Origens distintas testam melhor se o documento coordena sem ajuda privada de seus criadores.

A lista precisava registrar a origem do código. O relatório precisava nomear cenários e resultados. Para Draft Standard, todas as funções, inclusive as de segurança, tinham de operar entre pelo menos duas implementações e entregar a proteção pretendida. Contar produtos não substituía uma matriz de cobertura.

Mesmo a interoperabilidade comprovada tinha escopo: versões, entradas e condições. Ela não demonstrava automaticamente escala multivendedor, resistência a toda ameaça nem resultado de serviço.

Experiência operacional precisava de coordenadas

O relatório deveria informar topologia, ambiente, momento, duração, implementações, resultados e conclusões. Funções significativas tinham de ser exercitadas. Um EGP devia carregar o conjunto de rotas externas; um IGP tratava rotas internas e externas, salvo mecanismo separado.

O peso crescia por estágio. Proposed Standard exigia uma implementação e testes das funções principais, sem operação obrigatória. Draft Standard pedia experiência significativa com quantidade e complexidade moderadas no Internet operacional. Standard elevava a exigência a muitos roteadores, topologia complexa e operação multivendedor.

Eram condições, não constatações de que qualquer protocolo específico as cumprira. A ação de padronização e o relatório subjacente continuavam sendo objetos distintos.

O segundo relatório perguntava onde quebraria

Além do relatório de implementação, havia uma análise dos algoritmos e do consumo normal de banda, memória e CPU. Ela devia projetar o crescimento em ambientes pelo menos dez vezes maiores e identificar limites e contextos inadequados.

“Escalável” deixava de ser adjetivo solto e passava a depender de premissas, recursos e fronteiras. Comparar com protocolos existentes tornava a melhoria examinável.

Ainda assim, modelo não era observação. O limite previsto, o aproximado em laboratório e o encontrado em produção podiam divergir. Separá-los impedia que uma curva virasse recibo de implantação.

Em 2006, o controle mudou de lugar

A RFC 4794 classificou a RFC 1264 como Historic. Seu argumento era de governança: impor sempre um processo extra a uma classe de protocolos atrasava a publicação, e o processo geral já oferecia controles. Ela não disse que roteamento se tornara simples nem que experiência deixara de valer.

Saiu a exigência ampla para todos os documentos. Diretores da Routing Area ainda podiam exigir implementação ou operação sob a RFC 2026. Grupos de trabalho podiam continuar processos derivados da RFC 1264. Gestão e segurança permaneceram em políticas gerais.

A autoridade passou de uma lista universal ao julgamento do IESG e dos grupos. A flexibilidade aumentou, mas a decisão precisava explicar qual risco justificou qual evidência e por que o conjunto bastava.

Dois níveis mantiveram a diferença material

A RFC 2026 tratava Proposed Standard como estágio ainda imaturo. Em regra não exigia implementação ou operação, mas o IESG podia exigi-las para protocolos centrais ou de impacto operacional significativo.

A RFC 6410 reduziu depois a trilha a Proposed Standard e Internet Standard. Para o nível superior, manteve pelo menos duas implementações independentes interoperando, implantação ampla e experiência operacional bem-sucedida, além de verificações sobre erratas, funções não usadas e licenças.

Implantação ampla ainda não descreve a situação de uma rede específica. Sem versão, população, período e observação, não prova que um operador ativou algo ou obteve resultado.

O registro leve declarou sua própria fronteira

A RFC 7942 propôs uma seção voluntária de Implementation Status para Internet-Drafts. Ela poderia registrar maturidade, licença, experiência, contatos e relatórios de interoperabilidade, levando feedback de código real à discussão.

O texto padrão avisava que a informação de contribuidores não era endosso do IETF, podia não ter verificação independente e não formava catálogo completo. A seção auxiliava uma decisão, mas não substituía artefatos de teste, telemetria operacional ou prova de implantação.

Fontes e limites

Os critérios de 1991 vêm da RFC 1264, o processo geral da RFC 2026, e a retirada da RFC 4794. Os dois níveis estão na RFC 6410, e o estado voluntário das implementações na RFC 7942.

Essas fontes estabelecem regras e motivos. Não provam que um protocolo nomeado cumpriu a lista, que uma implementação declarada foi verificada, que um operador a implantou nem que usuários receberam um resultado. Historic não apaga evidência antiga nem torna uma afirmação falsa por si só.