Resumo

  • A obra publicada de Rekhter conecta três problemas operacionais: registrar quem pode anunciar alcançabilidade, trocar estado entre domínios sem apagar os limites de política e conservar endereços IPv4 globalmente únicos sem ocultar o custo de uma futura renumeração.
  • O retrato mais fiel é documental e colaborativo: os RFCs revelam decisões, restrições, estados e possibilidades de erro, mas não sustentam alegações de invenção individual, função atual, autoridade presente sobre operadores ou resultados universais de implantação.

Um perfil construído a partir de decisões verificáveis

É possível compreender a relevância de Yakov Rekhter sem transformar a história da Internet em uma sequência de feitos individuais. O caminho mais sólido começa nos documentos técnicos e pergunta, em cada etapa, qual dificuldade operacional foi delimitada, quais informações precisavam permanecer visíveis e que tipo de mudança futura foi reconhecida desde o início. Nesse enquadramento, o protagonismo não substitui a colaboração. Ele aparece na autoria e na edição de registros que definem mecanismos compartilhados, com responsabilidades distribuídas entre autores, implementadores, operadores e instituições.

O primeiro eixo está no RFC 1092, publicado em fevereiro de 1989. O texto registra uma implementação de roteamento baseado em política para o backbone NSFNET. Ali, anúncios autorizados, números de sistemas autônomos, uma base de políticas e alarmes de divergência formavam uma cadeia observável. O segundo eixo surge no RFC 1105, de junho de 1989, no qual Rekhter aparece como coautor da primeira especificação do Border Gateway Protocol. A troca de alcançabilidade entre sistemas autônomos passa a ser descrita por mensagens, caminhos e estados explícitos.

O terceiro eixo combina o RFC 4271, no qual Rekhter figura como editor da especificação do BGP-4, e o RFC 1918, do qual é coautor. Um documento organiza anúncios de prefixos, agregação, caminhos de sistemas autônomos e processo decisório; o outro delimita o uso de endereços privados e reconhece a troca entre conservação e custo de transição. Juntos, eles permitem ler sua trajetória pública como uma investigação contínua sobre escopo, identidade e continuidade operacional.

Fevereiro de 1989: a permissão de roteamento vira registro operacional

O valor do RFC 1092 está em seu caráter concreto. Ele não oferece uma retrospectiva abstrata sobre governança de redes; registra como uma operação de backbone procurava aplicar política às informações de alcançabilidade recebidas de redes regionais. Em um ambiente com caminhos diferentes, autonomia administrativa e dependência de confiança mútua, não bastava presumir que cada anúncio correspondia à relação esperada. Era necessário representar a permissão de modo que a operação pudesse compará-la com aquilo que chegava pelo protocolo.

A decisão descrita foi manter uma base de políticas de roteamento com anúncios regionais autorizados. Essa escolha tratava a autorização como dado operacional consultável. Números de sistemas autônomos e relações previstas deixavam de ser apenas conhecimento informal entre equipes e passavam a integrar uma referência contra a qual o comportamento observado podia ser examinado. O registro não encaminhava pacotes por si só, nem substituía o protocolo em execução. Sua função era estabelecer uma expectativa explícita e verificável.

Essa distinção conserva importância porque evita atribuir soberania ao banco de dados. Um registro de política diz o que foi autorizado segundo um processo definido; ele não torna verdadeira qualquer informação apenas por armazená-la. A rota efetiva depende do comportamento dos sistemas, das mensagens recebidas e das decisões tomadas em execução. O documento mostra a utilidade do registro justamente quando há comparação: se anúncio e autorização divergem, a diferença pode ser detectada.

A legitimidade operacional nasce da correspondência verificável entre identidade, política registrada e estado observado, não de um rótulo institucional isolado.

Alarmes de divergência ligam política e operação

O RFC 1092 não se limita a descrever uma lista de anúncios aceitáveis. Ele também inclui a possibilidade de alarmes quando há incompatibilidade entre a política registrada e o que a operação observa. Esse detalhe transforma um conjunto estático de permissões em parte de um processo de acompanhamento. A divergência deixa de ser uma suspeita difusa e passa a ser um evento que pode chamar a atenção do centro de operações de rede.

Um alarme não prova, sozinho, a causa nem determina automaticamente a resposta correta. Pode indicar erro de identificação, configuração imprecisa, mudança não refletida no registro ou outro desacordo entre expectativa e execução. Sua contribuição é mais básica e mais útil: localizar uma fronteira na qual os dois lados não coincidem. Isso dá à equipe um ponto de partida para verificar registros, mensagens e configuração. A observabilidade não elimina a necessidade de julgamento; ela torna o julgamento possível sobre evidências concretas.

Esse padrão reaparece em infraestruturas maduras. Uma política que não pode ser comparada ao comportamento em execução corre o risco de se tornar apenas declaração. Um sistema que produz estado sem referências atribuíveis dificulta a responsabilização técnica. Um alarme sem escopo pode gerar ruído. No registro do NSFNET, os três elementos aparecem conectados: uma permissão delimitada, uma identidade de sistema autônomo e uma divergência detectável. O resultado não é controle absoluto, mas uma forma prática de manter continuidade entre a intenção documentada e o tráfego de informações que sustenta o roteamento.

Junho de 1989: a alcançabilidade entre domínios ganha estado explícito

Quatro meses depois do RFC 1092, o RFC 1105 apresentou a primeira especificação do BGP. Rekhter é um dos coautores, e essa atribuição compartilhada é essencial para ler o documento com precisão. O texto não deve ser usado para sustentar uma narrativa de invenção solitária. Ele registra um trabalho coletivo sobre como sistemas autônomos poderiam trocar informações de alcançabilidade e como uma sessão do protocolo poderia progredir entre estados definidos.

A mudança conceitual é profunda. Em vez de tratar a relação entre domínios como uma transferência opaca de rotas, a especificação descreve mensagens, informações de caminho e condições de sessão. O protocolo cria um vocabulário comum para dizer o que os pares estão fazendo. Essa explicitação não decide toda política para o operador. Ela oferece os elementos necessários para que cada domínio aplique suas decisões sem perder a capacidade de interpretar o que recebeu.

O BGP inicial era um documento histórico que seria sucedido por versões posteriores. Portanto, seus detalhes não podem ser apresentados como descrição de toda prática atual. Sua importância, dentro do recorte público disponível, está na formalização de uma fronteira. Sistemas administrativos distintos precisam trocar alcançabilidade, mas não precisam abandonar sua autonomia. O protocolo define como a informação circula e como a sessão muda de estado; as políticas permanecem nas decisões de cada participante. Ao tornar a interface explícita, ele permite cooperação sem transformar a cooperação em uma autoridade única sobre todos os domínios.

Uma máquina de estados torna as falhas legíveis

Quando um protocolo descreve estados e transições, ele fornece mais do que uma sequência ideal para estabelecer comunicação. Também define lugares nos quais a tentativa pode parar, reiniciar ou falhar. Essa visibilidade é relevante no RFC 1105 porque a troca de alcançabilidade depende de uma sessão cujo comportamento precisa ser entendido pelos dois lados. Sem estados nomeados, uma interrupção pode ser percebida apenas como ausência de resultado. Com estados e eventos, a investigação ganha pontos de referência.

A máquina de estados não garante que toda implementação se comporte corretamente, nem evita por si mesma erros de operação. Ela estabelece um contrato observável. Implementadores podem organizar seu código de maneiras diferentes, mas precisam produzir comportamento compatível com as transições previstas. Operadores podem relacionar sinais da sessão a etapas conhecidas. O documento, por sua vez, permanece como descrição do comportamento esperado, não como substituto daquilo que o sistema realmente executa.

Essa separação entre registro e execução é uma das linhas mais consistentes do conjunto documental. A especificação conserva nomes, mensagens e condições; a implementação realiza esses elementos; a rede revela o resultado em funcionamento. Se os três níveis divergem, a solução não é declarar que o texto tem soberania sobre a realidade. É investigar a diferença. A contribuição da explicitação está justamente em oferecer termos comuns para essa comparação. Assim como os alarmes do RFC 1092 aproximavam política e anúncio, os estados do BGP aproximam a descrição protocolar e o comportamento da sessão sem confundir um com o outro.

Caminhos de AS registram propagação, não propriedade

As informações de caminho associadas ao BGP ajudam a representar por quais sistemas autônomos uma informação de alcançabilidade passou. Elas apoiam a detecção de ciclos e fornecem contexto para decisões de roteamento. Esse registro é operacional: descreve uma sequência relevante para a propagação e para a aplicação de política. Não deve ser interpretado como escritura de propriedade sobre endereços, redes ou territórios.

A diferença é importante porque identificadores técnicos podem adquirir significados exagerados quando retirados de sua função. Um caminho de AS explica parte da história de um anúncio dentro do protocolo. Ele não prova relação jurídica, não determina autoridade política e não torna qualquer anúncio correto por definição. Sua utilidade depende da exatidão dos identificadores, da consistência das mensagens e da comparação com outras expectativas operacionais. O dado ganha força por ser específico e verificável, não por representar domínio soberano.

Essa leitura também preserva a autonomia dos participantes. Cada sistema autônomo pode avaliar informações e aplicar política dentro dos limites do protocolo. O caminho transporta contexto suficiente para decisões e prevenção de ciclos, mas não substitui a responsabilidade local por configuração e avaliação. A arquitetura permite coordenação porque registra uma parte necessária da realidade de propagação. Ao mesmo tempo, mantém uma fronteira: o registro do caminho é uma evidência protocolar, não uma resposta completa sobre intenção, direito ou desempenho. Liderar infraestrutura com rigor exige respeitar exatamente esse alcance.

Janeiro de 2006: o BGP-4 consolida fronteiras de comportamento

O RFC 4271, publicado em janeiro de 2006, reúne a especificação do BGP-4 e identifica Rekhter como editor ao lado de autoria compartilhada. O texto documenta anúncios de prefixos CIDR, agregação, informações de caminho de AS, bases conceituais de informações de roteamento e um processo de decisão. Cada componente reduz uma ambiguidade diferente: qual bloco está sendo anunciado, que alcance pode ser resumido, que caminho acompanha a alcançabilidade e em que etapas as informações são recebidas, avaliadas e anunciadas.

O documento não prescreve uma única organização interna para todos os equipamentos. Em vez disso, define comportamento e estruturas conceituais que uma implementação pode realizar de formas equivalentes. Essa escolha é uma fronteira de engenharia. Ela impede que a interoperabilidade dependa de um arranjo específico de memória ou software e concentra o compromisso no que os pares podem observar. O código em funcionamento tem liberdade interna, desde que preserve os efeitos exigidos pelo protocolo.

Essa independência não significa ausência de rigor. Quanto menos a especificação determina a estrutura interna, mais importante se torna a clareza sobre entradas, saídas, estados e resultados. O registro técnico precisa dizer o suficiente para permitir interoperabilidade e investigação, sem transformar uma solução interna em regra universal. A edição do RFC 4271 participa, portanto, de uma forma disciplinada de governança técnica: delimitar comportamentos comuns, deixar escolhas internas abertas e manter as interfaces observáveis. O texto coordena sistemas diversos sem afirmar que todos devam ser construídos da mesma maneira.

Prefixos CIDR tornam o escopo anunciável

No BGP-4, a alcançabilidade é associada a prefixos, e o comprimento do prefixo expressa um escopo de endereços. Essa representação permite anunciar conjuntos contíguos e trabalhar com agregação. Ela também torna explícito que uma rota não é uma afirmação vaga sobre “a Internet”, mas uma informação relacionada a um bloco delimitado. O prefixo informa quais endereços estão incluídos; o caminho e os demais atributos oferecem contexto para o tratamento do anúncio.

CIDR e BGP-4, nesse sentido, aproximam economia de escala e precisão. A agregação pode reduzir a quantidade de informações propagadas ao representar vários blocos por um anúncio mais abrangente. Porém, o resumo só é operacionalmente útil quando seu escopo corresponde à alcançabilidade que pode ser sustentada. Uma agregação imprecisa esconderia diferenças importantes. O ganho não vem de apagar detalhes indiscriminadamente, mas de combinar blocos sob uma afirmação que continue verdadeira para o conjunto anunciado.

O registro de prefixos também ilustra por que recursos numéricos exigem unicidade e atribuição adequada em seu domínio relevante. O protocolo precisa distinguir blocos e compará-los. Isso não transforma o registro de endereços em autoridade sobre o comportamento da rede. A delegação ou a anotação de um bloco não cria uma rota; o anúncio não garante entrega; a agregação não prova capacidade. Cada elemento contribui com uma parte. A continuidade depende da correspondência entre o escopo registrado, o anúncio propagado e o comportamento que os sistemas conseguem manter.

As bases de informação são contratos conceituais

Ao tratar bases de informações de roteamento de modo conceitual, o RFC 4271 evita amarrar o protocolo a uma arquitetura interna específica. Essa decisão favorece diversidade de implementação. Um fornecedor pode organizar dados de uma maneira e outro pode escolher estrutura diferente, desde que o comportamento externamente relevante permaneça compatível. A interoperabilidade é construída na fronteira observável, não na exigência de que todos os sistemas compartilhem o mesmo desenho interno.

O termo “base”, contudo, pode sugerir uma autoridade que o texto não lhe concede. As estruturas conceituais ajudam a explicar em que conjunto uma rota recebida, escolhida ou anunciada pode ser compreendida. Elas não fazem com que uma informação seja alcançável no plano de encaminhamento. Tampouco substituem verificações sobre sessões, políticas e estado efetivo. São mapas para raciocinar sobre comportamento, não o território da execução.

Essa distinção protege tanto a flexibilidade quanto a responsabilização. Se a especificação impusesse detalhes internos desnecessários, dificultaria evolução. Se fosse vaga sobre efeitos observáveis, dificultaria interoperabilidade e diagnóstico. A solução documentada fixa uma fronteira: liberdade de organização interna e obrigação de preservar comportamento protocolar. Esse equilíbrio ajuda a explicar por que o trabalho público de Rekhter pode ser lido como engenharia de limites.

Não se trata de concentrar todas as decisões num registro, mas de definir registros suficientes para que sistemas diferentes possam coordenar e para que divergências possam ser localizadas.

Fevereiro de 1996: o endereço privado formaliza uma troca de escopo

O RFC 1918, publicado em fevereiro de 1996, identifica Rekhter como um de seus coautores e reserva blocos de endereços para uso em redes privadas. A orientação responde a um problema diferente daquele tratado pelo BGP, embora ambos envolvam escopo. Organizações sem necessidade de conectividade externa para todos os dispositivos poderiam usar endereços internos sem consumir, para cada elemento, um endereço IPv4 globalmente único.

A decisão conserva um recurso público e permite repetição dos mesmos endereços em redes privadas separadas. Essa repetição funciona porque o escopo é limitado. Os endereços não adquirem unicidade global; são significativos dentro da rede que os administra. O benefício depende, portanto, de manter clara a fronteira entre uso local e conectividade pública. Quando dois espaços privados se encontram, sobreposições podem surgir. Quando um dispositivo precisa de relação diferente com a Internet pública, o plano original pode precisar mudar.

O RFC 1918 é especialmente valioso por não apresentar conservação como benefício sem custo. Ele reconhece a possibilidade de renumeração quando as necessidades de conectividade mudam. A economia inicial transfere parte do esforço para uma transição futura possível. Isso não torna o endereçamento privado inadequado; torna a decisão honesta. A engenharia responsável registra tanto o ganho presente quanto a obrigação potencial. O escopo local é uma ferramenta, não uma declaração de independência em relação ao sistema global de endereçamento.

Conservação não cancela o custo de renumeração

O uso de endereços privados reduz a demanda por endereços públicos em determinados cenários. Porém, a economia não elimina a necessidade de unicidade quando uma rede amplia sua conectividade ou combina ambientes antes separados. O RFC 1918 torna esse custo parte da decisão. Uma organização pode obter flexibilidade interna no presente e, mais tarde, enfrentar renumeração, tradução ou reorganização para lidar com novas relações externas e sobreposições.

Esse custo não deve ser inflado em uma previsão universal. O documento não prova que toda rede privada será renumerada, nem mede resultados de implantação. Ele apenas estabelece que a mudança de escopo pode exigir trabalho. A afirmação é limitada e poderosa: uma escolha de endereçamento cria condições operacionais que persistem. Inventários, dependências e configurações precisam acompanhar a realidade para que uma transição futura seja possível sem depender de memória informal.

A ligação com os registros de roteamento aparece na disciplina de manter fronteiras visíveis. Uma autorização de anúncio precisa ser comparável ao estado recebido. Um prefixo precisa ter escopo identificável. Um endereço privado precisa ser reconhecido como local, e não confundido com identidade global. Em todos os casos, a continuidade é prejudicada quando um identificador carrega mais significado do que sua função permite. Lideranças técnicas ganham clareza quando tratam renumeração como parte do ciclo de vida: não como falha moral da escolha inicial, mas como custo que deve ser registrado, preparado e atribuído.

Escopo privado não equivale a propriedade privada

O adjetivo “privado” no RFC 1918 descreve o âmbito de uso dos endereços reservados. Ele não cria propriedade global sobre uma sequência numérica usada internamente. Redes distintas podem empregar os mesmos blocos porque esses valores não são destinados a funcionar como identificadores globalmente únicos na Internet pública. A utilidade decorre da separação dos domínios, não de um direito exclusivo sobre os números.

Essa distinção ajuda a evitar conflitos conceituais. Dentro de uma organização, uma equipe pode administrar a atribuição local e exigir unicidade em seu próprio ambiente. Fora desse limite, outra rede pode usar a mesma faixa. Se as duas redes forem interligadas, a sobreposição precisa ser tratada como condição técnica. Nenhum dos registros locais, por si só, resolve a colisão no novo domínio compartilhado. A expansão do escopo exige nova coordenação.

O mesmo cuidado vale para registros públicos. Uma base de recursos numéricos preserva atribuições e mudanças necessárias à coordenação, mas não deve ser confundida com soberania sobre a operação. Um registro pode indicar qual entidade recebeu determinado recurso segundo uma cadeia administrativa. O protocolo e o encaminhamento revelam como anúncios e pacotes se comportam. A governança confiável mantém essas camadas conectadas e distintas. Ao reconhecer que o endereço privado é deliberadamente não global, o RFC 1918 oferece um exemplo claro de como limitar uma identidade pode ser mais útil do que atribuir a ela um alcance que não possui.

BGP e endereçamento privado resolvem problemas de escopo diferentes

BGP-4 e endereçamento privado são frequentemente encontrados na mesma infraestrutura, mas não realizam o mesmo trabalho. O BGP troca informações de alcançabilidade entre sistemas autônomos, carrega caminhos e permite decisões de política sobre prefixos anunciados. O RFC 1918 delimita endereços reutilizáveis em redes privadas e reconhece a troca entre conservação de endereços públicos e custo de mudança futura. Um mecanismo organiza relações interdomínio; o outro define um âmbito em que a unicidade global é dispensada.

Confundir os dois pode levar a expectativas erradas. Um endereço privado não se torna globalmente alcançável por aparecer numa configuração. Uma rota BGP não transforma o bloco anunciado em propriedade do anunciante. Um prefixo agrega endereços, mas não prova que o encaminhamento funciona. Cada registro responde a uma pergunta específica: qual bloco, qual caminho, qual política, qual escopo, qual identidade. A resposta completa depende da combinação, não da elevação de um único elemento à condição de autoridade total.

O conjunto dos RFCs associados a Rekhter deixa esse desenho especialmente visível. A política do NSFNET registra anúncios autorizados. O BGP formaliza estado e caminho entre domínios. O BGP-4 trabalha com prefixos CIDR e separa comportamento de armazenamento. O endereçamento privado conserva recursos ao limitar escopo. Essa sequência não é uma marcha para centralização. É uma expansão da capacidade de coordenação por meio de limites bem descritos, interfaces comparáveis e custos reconhecidos.

O registro de recursos e o protocolo exercem funções distintas

Registros de números, bases de política e protocolos se complementam, mas não são intercambiáveis. O registro pode conservar uma atribuição, uma autorização ou uma mudança. O protocolo transporta estado e atributos entre sistemas. A implementação executa decisões e produz comportamento. A operação observa resultados e investiga divergências. Quando uma camada tenta substituir as demais, a explicação se enfraquece.

Uma autorização registrada sem correspondência com o anúncio atual pode estar desatualizada. Um anúncio recebido sem referência a uma identidade e a uma política pode ser difícil de avaliar. Uma implementação que organiza dados de modo particular não pode exigir que toda a Internet use a mesma estrutura interna. Uma rota selecionada não garante que cada pacote seguirá o resultado esperado em todas as condições. O funcionamento depende de uma cadeia, e cada elo precisa expor o suficiente para ser conferido.

Essa visão recusa dois extremos. O primeiro é tratar o registro como soberano, como se a anotação produzisse realidade operacional. O segundo é desprezar o registro e confiar apenas no comportamento momentâneo, perdendo histórico, atribuição e intenção. A abordagem mais robusta usa o registro como memória responsável e a execução como teste contínuo. O RFC 1092 mostra a comparação entre autorização e anúncio; os RFCs do BGP descrevem estado e decisão; o RFC 1918 explicita o limite da identidade local. A coerência nasce do diálogo entre essas evidências.

Autoria compartilhada também é um controle de atribuição

Os documentos precisam ser lidos com a mesma disciplina de identidade que recomendam para a infraestrutura. Rekhter é autor do RFC 1092, coautor do RFC 1105, editor do RFC 4271 e coautor do RFC 1918. Essas funções são documentadas e suficientes para estabelecer sua participação. Elas não autorizam atribuir a ele, sozinho, todos os mecanismos descritos, toda a evolução posterior do BGP, toda a história do CIDR ou qualquer resultado produzido por implementações de terceiros.

Preservar a autoria compartilhada não diminui a relevância individual. Ao contrário, torna o perfil verificável. A contribuição aparece em registros específicos, com datas e escopos definidos. O perfil do IETF Datatracker, capturado em 30 de maio de 2026, lista 78 RFCs e não mostra função ativa no IETF nessa fotografia datada. O perfil do Internet Hall of Fame oferece reconhecimento institucional independente por contribuições ligadas ao roteamento do NSFNET e à evolução do BGP e do CIDR.

Esses registros ampliam a atribuição pessoal, mas mantêm limites. O perfil institucional resume impacto; os RFCs sustentam as afirmações técnicas específicas. A fotografia do Datatracker documenta histórico de autoria e uma ausência de função ativa naquela data; não informa emprego presente nem autoridade operacional. Usar cada fonte para a função que pode cumprir é uma forma de controle de qualidade. Assim como um caminho de AS não é escritura de propriedade, um reconhecimento não é procuração para alegar controle atual.

O que o registro público não demonstra

Os seis documentos aceitos permitem afirmar que Rekhter participou de registros centrais sobre política de roteamento do NSFNET, a primeira especificação do BGP, a especificação do BGP-4 e o endereçamento privado. Permitem também reconhecer uma produção extensa de RFCs na fotografia datada do IETF e um reconhecimento público pelo Internet Hall of Fame. Não permitem preencher as lacunas com suposições biográficas.

Não há base, nesse conjunto, para declarar empregador atual, função atual em padronização, autoridade presente sobre uma rede de operador ou responsabilidade por decisões contemporâneas. Também não há base para alegar adoção universal, prevalência de uma implementação, desempenho medido, prevenção de interrupções, resultados para clientes ou efeitos comerciais. Os RFCs descrevem mecanismos e limites; não são estudos abrangentes de resultados em todas as redes que os utilizaram.

A restrição melhora o artigo. Em vez de depender de elogios amplos, ela concentra a análise naquilo que pode ser examinado: datas, papéis documentais, decisões técnicas, restrições e consequências reconhecidas pelos próprios textos. O perfil se torna uma leitura de engenharia, não uma biografia total. Essa disciplina é particularmente adequada ao tema. Infraestrutura confiável depende de atribuição exata e escopo explícito. Um artigo sobre esses princípios perderia coerência se atribuísse ao indivíduo mais do que os registros permitem.

Três décadas documentais, um padrão de limites visíveis

Entre o registro de política de fevereiro de 1989, a primeira especificação do BGP em junho do mesmo ano, o endereçamento privado em 1996 e a especificação do BGP-4 em 2006, aparece um padrão. Sistemas distribuídos não eliminam fronteiras; precisam torná-las operáveis. Uma rede regional conserva autonomia, mas seu anúncio deve ser atribuível. Uma sessão entre domínios troca estado, mas precisa de transições compreensíveis. Um prefixo pode ser agregado, mas seu escopo precisa continuar verdadeiro. Um endereço pode ser reutilizado localmente, mas sua falta de unicidade global precisa ser reconhecida.

Esse padrão não depende de considerar os documentos como uma única obra planejada. Cada RFC responde a um contexto e tem coautores ou editores próprios. A conexão é analítica e limitada: todos mostram decisões que ganham força quando identidade, escopo, estado e custo de mudança são explícitos. A documentação não toma o lugar da operação. Ela fornece referências para que a operação possa ser comparada, explicada e corrigida.

Por isso, a contribuição pública de Rekhter pode ser descrita como atenção recorrente aos limites operacionais incorporados à infraestrutura. A palavra “limite” não significa apenas restrição. Também significa interface: o ponto no qual dois domínios trocam informação, uma política encontra um anúncio, um prefixo encontra uma decisão e um espaço local encontra a necessidade de conectividade global. Definir essas interfaces é parte do que torna possível ampliar uma rede sem apagar a responsabilidade por seu comportamento.