Resumo

  • RFC 1474 mantinha uma linha por enlace PPP e tipo MAC. O accept local descrevia o processamento da própria máquina; o remoto descrevia a crença local sobre a capacidade do vizinho.
  • Em RFC 1220, a ausência de anúncio permitia presumir suporte amplo, embora tipos desconhecidos pudessem ser descartados. Até uma rejeição podia coexistir com o envio de tráfego ao receptor que dissera que o descartaria.

Em junho de 1993, RFC 1474 transformou partes do Bridge Network Control Protocol de PPP em objetos gerenciáveis. Havia estado do NCP, opções, configuração e uma tabela de tipos de mídia. Não havia uma coluna que provasse o percurso completo de um quadro.

O limite aparece na gramática. Para a capacidade local, o documento afirmava um comportamento. Para a capacidade remota, registrava quem formara a conclusão.

O mesmo rótulo tinha duas fontes

pppBridgeMediaTable era indexada por ifIndex e pppBridgeMediaMacType. Uma entrada não dizia “a ponte funciona”. Dizia algo sobre um tipo MAC específico em um enlace específico.

Se pppBridgeMediaLocalStatus fosse accept, a entidade local receberia e processaria corretamente pacotes daquele tipo. Em dont-accept, os pacotes recebidos não seriam processados de forma adequada. Era uma declaração sobre o próprio sistema.

Já pppBridgeMediaRemoteStatus mostrava se a entidade local acreditava que a entidade remota aceitaria o tipo. A linha mencionava o vizinho, mas continuava sendo produzida pelo lado de cá.

Essa diferença desaparece quando o painel aplica o mesmo verde às duas colunas. Configuração e execução locais podem sustentar a primeira. Mensagens de negociação, omissões interpretadas e estado em cache sustentam a segunda.

Não anunciar nada podia parecer aceitação total

RFC 1220 criou MAC Type Selection para anunciar que tráfego um nó estava preparado para receber e atender. Vários tipos exigiam várias opções no Configure-Request.

Quando um sistema não anunciava seus tipos, o par podia supor que todos eram suportados. Mesmo assim, o receptor descartaria os tipos que não entendesse. A presunção mantinha a interoperabilidade com uma ponta silenciosa; não instalava capacidade nela.

Ao anunciar uma lista, o nó avisava que descartaria os tipos ausentes. E uma rejeição não fornecia garantia negativa limpa: RFC 1220 explicava que o tráfego podia continuar sendo encaminhado pelo enlace embora o receptor tivesse indicado que o descartaria.

Logo, remoteStatus dependia da história da sessão. Sem opção, resposta, tipo e enlace, o booleano perdia sua origem.

A revisão de 1994 preservou o caráter consultivo

RFC 1638 recomendou fortemente negociar MAC-Support. Um anúncio permitia que o par deixasse de enviar tipos incompatíveis, economizando largura de banda. O texto, porém, chamou a opção de advisory only.

Para tipos com número superior a 4, surgiu uma restrição adicional: não transmitir sem receber uma opção do par indicando disposição para aceitar. A mudança protegeu extensões novas, mas não transformou a disposição anunciada em prova de processamento.

O protocolo precisava equilibrar compatibilidade antiga, eficiência e expansão. Cada objetivo alterava a regra de decisão do emissor. Nenhum entregava uma observação do destino.

Suportar a mídia ainda não escolhia a porta

Entender um formato de quadro e saber para onde encaminhar um endereço são funções distintas. RFC 1493 colocou a segunda numa base de forwarding/filtering para endereços MAC unicast específicos e portas aprendidas ou configuradas.

RFC 1474 tratava de capacidade por tipo de mídia no enlace PPP. A FDB tratava de uma decisão para determinado endereço. Nenhuma das duas era um recibo do host final.

Uma trilha suficiente separaria: política local, geração aplicada no reinício, troca BNCP, base da crença sobre o remoto, quadro transmitido, processamento do par, escolha de encaminhamento e resultado no destino. RFC 1661 ainda exigia que o NCP estivesse em Opened antes de PPP transportar os pacotes correspondentes. A porta aberta continuava sem provar a passagem de um quadro.

Mostrar uma crença exige mostrar sua testemunha

RFC 1474 isolava a configuração gravável e tratava o controle do enlace como risco de segurança. Uma MIB view protegida decidia quem podia ler ou escrever. Ela não aumentava o alcance probatório do valor.

Em automação atual, “suporte remoto” deveria vir com interface, tipo MAC, geração, reinício, estado NCP, opção, regra para omissão, resposta e horário. Sem contexto, “meu modelo do par indica sim” vira “o par recebeu” depois de algumas integrações.

Inferências são parte normal de sistemas distribuídos. O erro é apagar seu autor e conservar apenas a aparência de fato.

RFC 1474 deixou o autor à vista.

Fontes