Resumo

  • As tabelas Admin da RFC 2051 mostravam valores esperados em modo somente leitura; as tabelas Oper mostravam o estado atual ou negociado. Uma linha Admin de modo podia ser apagada enquanto a sessão ativa e a linha Oper continuavam.
  • Sessão, conversa, contadores opcionais e histórico anormal tinham ciclos próprios. Nenhum provava sozinho configuração, concordância do par, êxito da aplicação, completude ou segurança.

A cena decisiva da RFC 2051 contém uma ausência. Uma appcModeAdminEntry pode ser removida enquanto uma sessão ativa ainda usa o modo; a appcModeOperEntry correspondente permanece. Não é necessariamente inconsistência: a intenção administrativa terminou, o fato operacional ainda não.

Admin representava padrões ou expectativas, mas o MIB não criava nem alterava aquela configuração. Os objetos eram de leitura. Oper representava valores atuais ou negociados. Um objeto dinâmico podia nascer de um modelo administrativo e depois seguir vida própria.

Isso separa configurar, solicitar, aceitar, negociar e operar. Retirar o modelo não volta no tempo para desfazer uma sessão. Ver a linha Oper tampouco prova que o modelo antigo ainda está autorizado para o futuro.

O MIB cobria grupos globais, LU, programas de transação, sessões, conversas e CPI-C. Essa amplitude não o tornava um controle remoto completo. Em geral ele não criava nem apagava LUs parceiras, modos ou programas, nem ativava LUs, iniciava conversas ou ativava sessões.

Havia controles específicos: selecionar estatísticas e tracing, emitir CNOS e solicitar desativação. Uma escrita comprovava o pedido; o estado seguinte mostraria o que o agente fez.

Em CNOS, Admin guardava valores desejados e Oper, valores efetivamente negociados. A documentação atual da IBM sobre início de sessões expande CNOS como Change Number Of Sessions. É contexto de vocabulário, não prova de que um produto implementou a RFC ou de que uma negociação teve sucesso.

A tabela de sessões ativas usava unbound, pendingBind, bound e pendingUnbind. O agente criava e removia linhas conforme o ciclo. Escrever unbound numa sessão vinculada podia iniciar a desativação; a escrita era uma solicitação, não sua confirmação.

Mesmo bound tinha alcance limitado. Não dizia que uma conversa foi alocada, que um programa terminou, que o par respondeu corretamente ou que o processo de negócio funcionou. O par e a aplicação tinham de fornecer evidências próprias.

A conversa era mais curta que a sessão. Sua linha surgia no início e sumia no fim. Várias conversas podiam passar pela mesma sessão ainda viva.

As estatísticas eram outra camada, opcional. Com a coleta ativa, surgia uma linha por sessão. Os contadores eram Counter32 da RFC 1902 e tinham uptime. Sem janela, tratamento de volta e estado da coleta, o número não era histórico completo.

Ao colocar a coleta administrativa em inactive, todas as linhas estatísticas eram removidas. As sessões não precisavam terminar. Tabela vazia podia significar medição desligada, não ausência de atividade.

O histórico também era seletivo: sessões terminadas de modo anormal e conversas encerradas com erro. Quantidade e duração dependiam da implementação. Um arquivo vazio não demonstrava falta de atividade nem preservação integral do passado.

A RFC 1666 localiza o MIB na gestão SNA. A referência não é evidência de implantação. Uma norma define objetos, mas não prova que o operador os instalou, habilitou, protegeu ou leu corretamente.

O status exige precisão. O IETF Datatracker e a página do RFC Editor registram Proposed Standard no Standards Track, de outubro de 1996. O índice de mudanças congelado não inclui a RFC 2051, e não há sucessora indicada. É um texto antigo sobre tecnologia legada, mas a evidência oficial não sustenta status formal Historic.

A consulta de errata não trouxe correspondências. Isso reduz uma dúvida documental; não certifica implementação, interoperabilidade ou atualidade.

Segurança é o limite mais explícito: a RFC diz que o tema não é discutido. Standards Track não prova controle de acesso, segurança das escritas nem confiabilidade dos contadores. Uma sessão operacional pode ser insegura.

Cada tabela é um depoimento com jurisdição restrita. Admin mostra configuração apresentada; o controle mostra pedido; o agente mostra transição; CNOS Oper mostra negociação; sessão mostra vínculo ativo; conversa mostra uma interação; estatística mostra uma janela medida; histórico mostra alguns finais anormais. O par e a aplicação continuam responsáveis pelo restante.

Fontes