Resumo

  • No relato de John Day, o modelo de referência OSI servia para organizar o trabalho de normalização que viria depois; não mandava implementar uma pilha fixa.
  • RINA propôs uma arquitetura recursiva baseada em comunicação entre processos, e ProtoRINA testou uma implementação limitada. As fontes citadas não demonstram adoção ampla em produção nem provam que ninguém a tenha usado.

O que a figura não consegue decidir

Uma figura com sete caixas pode sugerir uma sequência inevitável: construir a camada inferior, seguir para a próxima e, ao final, ter uma rede pronta. O relato de John Day desloca essa leitura. Na história oral gravada pelo Computer History Museum em 2010, ele descreveu o modelo de referência OSI como uma estrutura para orientar o trabalho de normalização, não como um documento de implementação. É a lembrança retrospectiva de Day, não uma citação do padrão nem a ata de uma reunião.

Ainda assim, ela evidencia uma distinção duradoura: um modelo comum pode nomear funções e permitir que comitês coordenem discussões sem determinar o desenho de cada produto ou o calendário de implantação de uma operadora.

Day participou desse esforço. Em entrevista à Boston University, ele relembrou ter sido relator do modelo de referência OSI e presidente do comitê de arquitetura OSI da ANSI. O depoimento do museu registra também sua versão sobre a delegação norte-americana e as discussões iniciais. Esses relatos situam Day no trabalho coletivo; não fazem dele o autor exclusivo do OSI nem transformam o modelo em uma ordem universal para as redes.

Essa separação impede que se atribua à normalização uma autoridade automática. Um modelo de referência pode criar um vocabulário compartilhado, dividir um problema em funções discutíveis e ajudar organizações diferentes a coordenar propostas. Não oferece orçamento, rota de migração, compatibilidade com equipamentos instalados ou justificativa comercial para a mudança. Essas decisões ficam com quem implementa e opera. Confundir descrição com instrução faz a normalização parecer mais coercitiva do que foi e a adoção parecer consequência automática de um diagrama.

RINA como proposta, ProtoRINA como experiência

O trabalho posterior de Day não consistiu em acrescentar uma oitava caixa ao OSI. No artigo de 2008 “Networking is IPC”, escrito em conjunto com Ibrahim Matta e Karim Mattar, os autores propuseram tratar a comunicação como comunicação entre processos (IPC). Uma aplicação usa uma facilidade IPC, que pode por sua vez solicitar serviços de outra facilidade abaixo. A repetição é a ideia central da arquitetura. O artigo apresenta uma proposta, não um levantamento de redes que já a adotaram.

O projeto RINA da Boston University descreve a Distributed IPC Facility (DIF) como unidade recorrente e explica que políticas configuráveis orientam seu comportamento. É a descrição do grupo que desenvolve o sistema. Ela esclarece o modelo pretendido, mas não é uma avaliação independente de desempenho nem demonstra que RINA substituiu outras arquiteturas.

ProtoRINA permite observar a passagem da ideia para o código sem exagerar o resultado. Um artigo de 2014 assinado por Wang, Matta, Esposito e Day apresenta um protótipo em espaço de usuário e relata testes no campus da Boston University e no testbed de pesquisa GENI. O texto se define como nota editorial não revisada por pares; também descreve uma implementação incompleta e o uso de um shim TCP para conectividade de nível zero. Isso delimita, em vez de apagar, a contribuição: parte da arquitetura foi codificada e exercitada em ambientes identificados.

O trabalho não comprova implantação comercial ampla, substituição da Internet pública ou superioridade comparativa.

São três perguntas diferentes: o que o modelo define; o que uma implementação particular chegou a executar; e quais redes independentes adotaram a tecnologia, por quanto tempo e em que escala. A história oral de Day ajuda a responder à primeira; o artigo de RINA formula uma arquitetura; o ProtoRINA documenta um experimento restrito. As fontes examinadas neste perfil não oferecem um censo completo da terceira. Portanto, não sustentam nem “RINA está em toda parte” nem “RINA nunca foi usado”.

A decisão continua com quem opera

A contribuição mais útil dessa trajetória não é eleger um mapa definitivo de redes. É manter nítida a fronteira entre especificação compartilhada e escolha local. A normalização pode tornar interfaces inteligíveis entre organizações. Ainda cabe à operadora decidir se o modelo serve a seus equipamentos, serviços, equipes, tolerância a risco e janela de renovação. Um protótipo reduz a incerteza sobre o código em um testbed; evidência de adoção é que revela quem assumiu o custo operacional e o que permaneceu confiável em produção.

Para quem avalia infraestrutura, cada tipo de alegação exige sua própria comprovação. Um modelo precisa declarar alcance e finalidade. Um protótipo deve registrar estado do código, ambiente, condições de teste e partes inacabadas. Uma alegação de implantação deve identificar redes, datas e funções, distinguindo um piloto de um serviço mantido. Sem essa documentação, o desenho de uma apresentação pode ganhar uma autoridade que nenhum comitê, artigo ou teste lhe conferiu.

Fontes