Resumo

  • RowStatus separa estados legíveis — active, notInService, notReady — de ações apenas graváveis — createAndGo, createAndWait, destroy. O que o gerente solicita não é apresentado como aquilo que o agente já comprovou.
  • createAndWait permite uma linha incompleta e recuperável, mas não reserva o índice com exclusividade nem garante ativação. A simultaneidade e o rollback de um SetRequest não cobrem várias trocas nem vários equipamentos.

O formulário termina antes do equipamento

Uma ferramenta de gestão pode reunir índice, destino, limites e outras colunas de uma nova entrada. Mesmo quando todos esses valores cabem numa tela, o dispositivo ainda precisa decidir se a combinação faz sentido e se há recursos para usá-la. Confundir a conclusão do formulário com a conclusão do equipamento produz um sucesso maior do que a interface realmente prometeu.

RFC 2579 trata essa diferença com seis valores de RowStatus, mas eles não são seis estados equivalentes. active e notInService podem ser lidos e gravados. notReady pode ser lido, porém não gravado. createAndGo, createAndWait e destroy são ações que podem ser gravadas, mas nunca aparecem numa leitura.

Quando o gerente escreve createAndWait, não está selecionando uma etiqueta duradoura. Está pedindo a criação. Se o agente aceitar, ele passa a expor notReady quando faltam informações ou notInService quando já há o suficiente para tentar ativar a linha.

notReady não significa que nada foi criado. A linha pode existir, ter um índice e consumir recursos. notInService tampouco significa que a configuração foi aprovada. A expressão preserva uma condição mais estreita: o agente dispõe das peças necessárias para avaliar uma tentativa de colocá-la em serviço.

Uma requisição pode ser atômica sem tornar o processo atômico

Há uma garantia mais forte para colunas agrupadas numa única operação. RFC 3416 determina que o agente valide os variable bindings de um SetRequest antes da atribuição. As atribuições da mesma requisição ocorrem como se fossem simultâneas umas em relação às outras. Se uma falhar depois das validações, as demais são desfeitas e a resposta usa commitFailed. Se nem todas puderem ser desfeitas, o status é undoFailed.

Esse limite permite incluir várias colunas e uma ação de criação num PDU com tratamento conjunto. Ele não abraça a sequência inteira de createAndWait, leitura, preenchimento adicional e ativação. Cada resposta encerra uma requisição; acontecimentos entre elas não fazem parte do commit anterior.

O rollback da última operação não desfaz automaticamente as primeiras. Tampouco alcança outro agente em outro equipamento. “Como se fossem simultâneas” compara atribuições no mesmo SetRequest, não cria uma transação distribuída.

Até o erro undoFailed recomenda humildade: se o agente não conseguiu restaurar tudo, o gerente precisa reler o estado efetivo. Traduzir qualquer falha em “nada mudou” seria inventar uma garantia que a própria resposta negou.

A ausência de um campo vira evidência

createAndWait atende ao caso em que o gerente ainda não conhece todos os valores obrigatórios. Depois de ler notReady, ele consulta as colunas da linha. Uma instância necessária que não existe retorna noSuchInstance; o gerente pode então inicializá-la. Quando a informação chega ao limiar exigido, o status muda para notInService.

O trabalho parcial passa a existir na interface gerenciada. Se a aplicação cair, um operador pode reler a linha. Outro sistema consegue distinguir ausência de incompletude. O progresso não depende exclusivamente da memória temporária do cliente que iniciou a operação.

Ainda assim, a transição para notInService não valida o resultado. Uma solicitação posterior de active pode receber inconsistentValue. Valores presentes podem ser mutuamente incompatíveis; recursos podem faltar; o estado local pode ter mudado. O agente mantém a decisão final sobre o que consegue pôr em uso.

As regras de edição também pertencem a cada definição de objeto. A DESCRIPTION da tabela pode permitir certas alterações em active, exigir uma passagem por notInService ou rejeitar uma suspensão. Não se deve inferir uma política universal a partir do esqueleto comum de RowStatus.

Quem guarda o recurso precisa encerrar a espera

Uma criação em etapas pode parar porque o processo caiu, a rede falhou ou um operador desistiu. A linha fora de serviço continua capaz de consumir memória, uma posição de tabela ou recursos de medição.

RFC 2579 exige que o agente detecte linhas mantidas por tempo anormalmente longo em notReady ou notInService e as remova. A DESCRIPTION da coluna de status deve definir esse período. Somente quando ela não o faz o texto sugere aproximadamente cinco minutos.

Cinco minutos, portanto, não são um timeout universal. O período é uma escolha ligada ao tipo de recurso e ao modo normal de trabalho. Uma janela curta recupera capacidade rapidamente, mas pode interromper uma configuração legítima. Uma janela longa permite retomada, mas amplia o custo imposto a outros gerentes.

O descarte também pode atingir uma linha antes ativa que permaneceu parada por tempo excessivo. A política não distingue o abandono apenas pela idade da criação. Ela limita qualquer ocupação intermediária que deixou de avançar.

O ciclo de vida veio de um problema de operação

O SNMP de maio de 1990, definido em RFC 1157, modelava funções de gestão como acesso e alteração de variáveis nomeadas. Essa escolha evitava transformar o protocolo num catálogo crescente de comandos específicos de cada fabricante.

Uma linha conceitual, no entanto, conecta várias instâncias. Pode exigir um índice disponível, colunas sem valor padrão, relações de consistência e uma alocação de capacidade. Mais de um gerente pode operar a mesma tabela. O equipamento também pode criar entradas. Escrever variáveis era necessário, mas não dizia como uma criação parcial seria compartilhada, retomada ou descartada.

O problema apareceu de forma concreta em RMON. RFC 1271, de novembro de 1991, discutiu tabelas de controle que dividiam recursos de monitoramento entre vários gerentes. Seu EntryStatus tinha createRequest, underCreation, valid e invalid. O documento tratava de colisões, falha do gerente, entradas abandonadas e uma string de proprietário que ajudava participantes a entender quem configurara algo.

A string de proprietário não era autenticação nem autorização. Ela fornecia contexto operacional, não autoridade. O passo durável foi admitir que criação tinha duração e podia deixar um objeto intermediário visível.

RFC 1443, em abril de 1993, generalizou esse padrão como RowStatus e declarou sua origem em EntryStatus. RFC 1903 revisou a convenção em 1996. A formulação detalhada de 1999, em RFC 2579, consolidou as transições usadas neste artigo. Uma necessidade localizada de tabelas de controle tornou-se uma gramática reutilizável de ciclo de vida.

A pausa continua aberta à concorrência

O gerente que criou uma linha pode sentir que reservou o lugar. RFC 2579 recusa essa conclusão. Entre o createAndWait e a escrita posterior de active, o dispositivo gerenciado pode criar a própria instância. Nesse caso, valores mantidos pelo agente podem substituir os valores enviados pelo gerente.

A sequência em várias trocas abre uma janela de concorrência. A linha fica visível, mas o primeiro escritor não recebe um lock. Reler as colunas decisivas antes da ativação é a maneira de verificar se a intenção original ainda corresponde ao estado real.

destroy também não é uma condição persistente. É uma ação, permitida quando a linha está active, notInService ou notReady. Se for bem-sucedida, todas as instâncias associadas à linha desaparecem. A leitura posterior não devolve destroy porque já não há linha para manter esse valor.

Cada etapa sustenta uma afirmação diferente

RowStatus não transforma configuração em certeza. O gerente solicita a criação, fornece colunas e escolhe quando pedir ativação. O agente decide se pode criar, se há informação suficiente, se os valores são consistentes, se existem recursos e quando limpar trabalho abandonado. A definição da tabela estabelece sua política específica de edição e expiração.

Isso separa afirmações que uma interface apressada juntaria: a ação foi enviada; a linha existe; os campos necessários estão presentes; o agente aceitou active; o efeito pretendido aconteceu. Uma resposta em cada etapa não prova a seguinte.

A linha que existia antes de estar pronta não era um vazamento de implementação. Era a forma padronizada de preservar uma configuração composta sem esconder o meio do caminho. A simplicidade do SNMP foi mantida não por apagar a complexidade, mas por expor apenas a parte que cada lado podia verificar.

Fontes