Resumo

  • RFC 2366 permitia excluir a linha pai de um cliente, MARS ou MCS mesmo com linhas de VC associadas existentes ou em uso; limpar as dependências era uma etapa posterior e condicional.
  • read-create indicava o acesso máximo previsto pelo modelo, não a capacidade garantida de todo agente compatível. Linha ativa, contador, trap e SET aceito eram recibos distintos do desligamento e da entrega.

A tela administrativa fica mais limpa quando uma linha é removida. A rede, porém, não é obrigada a acompanhar a estética da tela. RFC 2366 registrou essa diferença de maneira incomum para um documento de gerenciamento.

marsClientRowStatus criava, alterava ou removia a linha de um cliente. Para ativá-la, os campos necessários e uma linha estatística correspondente precisavam existir. Para excluí-la, não havia exigência equivalente de esvaziar primeiro as tabelas dependentes: o texto aceitava a remoção mesmo quando marsClientVcTable ainda continha linhas ou estas estavam em uso.

Depois, o agente ou a estação de gerenciamento deveria, se possível, usar SET para eliminar linhas obsoletas. A expressão “se possível” separava dois compromissos. A remoção do pai era uma mudança no modelo. A reconciliação dos filhos dependia de outra capacidade, outra operação e outra confirmação.

Uma linha VC sobrevivente podia refletir um circuito real, um circuito já liberado cuja representação não foi limpa ou um estado intermediário. Sua presença não provava vida. A ausência do pai não provava morte.

O padrão aparecia de novo nas linhas principais do MARS e do MCS. Ambas podiam ser apagadas enquanto as respectivas tabelas de VC ainda existiam ou eram usadas. A repetição nos três papéis revela o argumento próprio deste RFC: o ciclo de vida do inventário de gerenciamento não era atomicamente igual ao ciclo de vida da infraestrutura ATM.

RFC 2022 havia descrito a arquitetura. O MARS distribuía informações de associação a grupos em um cluster ATM. Um emissor podia montar um VC ponto-multiponto para os receptores ou encaminhar dados a um MCS. RFC 2366 não transferiu esse controle integral à estação SNMP; apenas expôs uma projeção organizada do sistema.

No cliente, a projeção incluía endereço ATM, MARS padrão, registro, identificadores, temporizadores, blocos de grupos, servidores de reserva, VCs e estatísticas. O servidor MARS tinha estado, prioridade, mapas de hosts e MCS, membros registrados, VCs e contadores. O MCS tinha suas próprias tabelas de registro, reserva, circuitos e atividade.

Essas tabelas eram relacionadas, mas não equivalentes. Um registro de membro não era toda a configuração do cliente. Um mapa de grupo para endereço não era um circuito. Uma linha VC podia trazer VPI/VCI, grupo, parte remota, PVC ou SVC, função de controle, tempo ocioso, revalidação, encapsulamento e MTU negociado. Ainda faltavam o estado do comutador, o tráfego efetivo e a recepção em cada folha.

A origem também determinava a autoridade sobre a linha. Mapas configurados podiam ser administrados; mapas aprendidos dinamicamente não podiam ser modificados ou apagados pelo mesmo RowStatus. Alguns campos de um VC ativo podiam mudar, mas uma linha SVC não podia ser alterada ou excluída por esse caminho. A estação via mais do que necessariamente controlava.

Outro limite surgia entre sintaxe e conformidade. Muitos objetos eram MAX-ACCESS read-create. O módulo admitia uma implementação que criasse e modificasse esses valores. Mas suas declarações de conformidade reduziam o mínimo a read-only e diziam repetidamente que acesso de escrita não era exigido.

Um agente apenas observador podia, portanto, estar correto. RFC 1904 esclarecia que um objeto realmente gravável deveria permitir que o SET influenciasse razoavelmente a entidade gerenciada. A permissão máxima do esquema não funcionava como inventário de recursos de um equipamento específico.

Mesmo num agente gravável, capacidade não significava autorização. Era preciso conservar a identidade autenticada, a visão VACM, a operação permitida, o valor pedido, a resposta, a persistência e o efeito posterior. Só então vinham sinalização ATM, estado do comutador, pacotes e resultado no receptor. O sucesso SNMP não assinava essas etapas futuras.

Os contadores tinham escopo igualmente estrito. Somavam solicitações, JOINs, LEAVEs, respostas multipartes, NAKs, migrações e timeouts pelo último MARS_MULTI. MARS e MCS mantinham conjuntos próprios. Sem horário, base, reinício e identidade da instância, um número era difícil de interpretar. Com esse contexto, ele continuava sendo uma observação do plano de controle, não um comprovante de entrega.

O MTU padrão de cliente ou MCS podia divergir do MTU negociado por VC. HSN, CSN e SSN ajudavam a detectar mensagens perdidas e mudanças de associação, não o caminho dos dados. marsFaultTrap dizia que o agente detectara uma condição de falha; transmissão da notificação, recebimento pelo gerente, diagnóstico, reparo e recuperação eram fatos posteriores.

A seção de segurança tratou os objetos graváveis como superfície operacional sensível. SETs sem proteção podiam prejudicar a rede. SNMPv1, mesmo sobre uma rede protegida, não estabelecia quem podia criar, alterar ou apagar. O RFC recomendava os modelos de usuário e de controle por visão do SNMPv3 e acrescentava que até a leitura poderia exigir restrição.

Fazia sentido: uma visão somente leitura podia revelar endereços ATM, associação, mapas, prioridade de reserva, extremos de VC, MTU, temporizadores e falhas. Criptografia, autenticação, autorização da visão e finalidade legítima eram quatro controles.

O próprio módulo logo mostrou como identificação e conteúdo se separam. RFC 2366 o enraizou sob snmpModules. Dois meses depois, RFC 2417 corrigiu esse erro de atribuição, mudou a raiz para mib-2 57 e tornou o documento anterior obsoleto, preservando a semântica essencial. O significado podia continuar; a coordenada pública precisava ser reparada.

RFC 2366 não entregou uma réplica perfeita da rede. Entregou um vocabulário comum com limites visíveis. Uma linha ausente, um filho residual, um contador, uma permissão e um circuito eram proposições diferentes. A operação confiável começava quando o gerente aceitava essa diferença.

Fontes