Resumo

  • Na RFC 2020, uma gravação de configuração registrava intenção; o treinamento separava o pedido do modo efetivamente aceito pelo enlace.
  • A distinção tinha consequências concretas: o enquadramento atual fixava a MTU em 1.500 ou 4.464 octetos, e apenas dot12Status=opened tornava ifOperStatus igual a up.

Escrever não concluía a mudança

dot12DesiredFramingType selecionava para o próximo treinamento uma forma compatível com IEEE 802.3, compatível com IEEE 802.5 ou qualquer uma das duas. dot12CurrentFramingType respondia a outra pergunta: qual forma está em uso agora? Mesmo quando a preferência aceitava ambas, o valor atual precisava indicar uma só.

Essa resolução governava ifMtu. Com enquadramento 802.3 atual, eram 1.500 octetos; com 802.5, 4.464. Alterar o valor desejado poderia mudar a MTU depois do próximo treinamento. Portanto, um SET aceito comprovava o pedido, não a transição ou a MTU resultante.

A aparência do quadro tampouco identificava o método de acesso. O IEEE 802.12 podia usar formatos Ethernet ou Token Ring, mas empregava seu próprio Demand Priority Access Method. Por isso a RFC dizia que as MIBs MAC de Ethernet e Token Ring não deveriam ser aplicadas por mera semelhança. Só a combinação mais estreita de enquadramento Token Ring e suporte a roteamento pela origem justificava a RFC 1749.

O treinamento produzia a prova intermediária

Quadros de treinamento eram usados apenas na inicialização. O escravo na extremidade inferior iniciava; o mestre respondia. A RFC exigia 24 quadros consecutivos sem erro para a conclusão, justamente para que enlaces marginais não passassem pelo processo.

dot12Status separava fechado, abrindo, aberto, falha de abertura e falha de enlace. ifOperStatus era up somente no estado aberto. Abrir, reiniciar, mudar o enquadramento desejado, o pedido promíscuo ou o modo de controle podia iniciar novo treinamento; iniciar não era concluir.

No modo promíscuo, dot12DesiredPromiscStatus levava a solicitação do próximo pacote de treinamento, que o mestre podia negar. Escrever ifPromiscuousMode atualizava a intenção e disparava uma tentativa; ao final, o objeto precisava refletir o modo em uso, não o solicitado. dot12LastTrainingConfig registrava os bits do último quadro de treinamento sem erro.

Mestre também era um papel limitado ao protocolo: o participante que concedia transmissão aos nós solicitantes. Não provava propriedade, autoridade institucional ou entrega de dados.

A conta não virava resultado

Contadores normais de transmissão foram omitidos porque podiam ser derivados dos totais menos a alta prioridade. Na recepção, erros e octetos ilegíveis exigiam observações adicionais. As fórmulas relacionavam medidas, mas não provavam chegada ao destino, conclusão de aplicativo ou cumprimento de serviço.

A seção de segurança foi direta: questões de segurança não eram discutidas. Estado aberto ou configuração aceita não forneciam autenticação, confidencialidade nem garantia de operação segura.

Dois ciclos documentais

Os registros atuais do RFC Editor e da IETF ainda classificam a RFC 2020 como Proposed Standard e não apontam RFC que a torne obsoleta. Em 11 de setembro de 2026, a busca de erratas não encontrou correspondências; isso é o resultado daquela consulta.

O IEEE registra hoje IEEE 802.12-1995 como Inactive-Withdrawn, retirado em 15 de janeiro de 2001, e inclui o grupo Demand Priority entre os grupos encerrados. Esse registro posterior não mede implantação, desempenho ou êxito comercial. Transformá-lo em fato operacional repetiria a confusão que a RFC evitava.

Fontes