Resumo

  • active, notInService e notReady são condições que o agente pode devolver; createAndGo, createAndWait e destroy são ações solicitadas pelo gerente e nunca aparecem como estado numa leitura.
  • A existência da linha, a presença das informações exigidas e sua disponibilidade para o dispositivo são fatos independentes. O gerente declara intenção, enquanto o agente aplica as regras da MIB.

A aparência de tabela escondia uma convenção

As primeiras MIBs apresentavam objetos em colunas, identificados por índices. Para um operador, pareciam tabelas comuns. O RFC 1212, porém, chamava suas linhas de conceituais: a relação entre os objetos era uma convenção das aplicações, não uma garantia relacional oferecida pelo SNMP.

Uma MIB podia escolher um inteiro como invalid para apagar uma linha. A criação podia ocorrer quando um SetRequest se referia a instâncias ainda inexistentes e o agente decidia aceitá-las. Valores DEFVAL completavam alguns campos ausentes. Continuava faltando uma linguagem uniforme para dizer quando a linha estava completa e quando o dispositivo poderia usá-la.

Com vários sistemas de gerência, a lacuna virava disputa. Escolher um índice, ocupar esse índice, preencher os dados e ativar a função são atos diferentes. Se todos forem resumidos como “a linha existe”, duas estações podem atribuir significados incompatíveis ao mesmo conteúdo.

RMON mostrou a fase de construção

O RFC 1271 definiu na MIB RMON um precursor chamado EntryStatus. Seus valores incluíam createRequest, underCreation, valid e invalid. O primeiro gerente a criar com sucesso uma linha em determinado índice a obtinha; concorrentes recebiam erro. Depois, a entrada podia ser preenchida e validada.

RMON também associou um OwnerString à entrada. A indicação ajudava gerentes cooperativos a saber quem havia criado um recurso, mas o texto deixava claro que isso não era controle de acesso. Um gerente não cooperativo ainda podia alterar ou excluir a linha. Autoria era evidência de coordenação, não autoridade exclusiva.

Essa experiência preparou o problema que RowStatus resolveria: separar o verbo enviado pelo gerente da condição que o agente podia afirmar.

Seis valores formavam dois conjuntos

O RFC 1443 padronizou RowStatus no SNMPv2. O RFC 2579 contém a definição atual.

Uma leitura de linha existente devolve apenas três estados. active(1) significa que a linha está disponível para uso pelo dispositivo gerenciado. notInService(2) significa que ela existe, está indisponível e contém informação suficiente para o agente tentar ativá-la. Não é uma garantia de consistência, de recursos disponíveis nem de sucesso. notReady(3) significa que faltam instâncias de colunas necessárias.

Os demais valores são ações de escrita. createAndGo(4) pede criação e ativação imediata. createAndWait(5) pede criação sem entrada em serviço. destroy(6) pede a remoção de todas as instâncias associadas à linha conceitual.

Um GET jamais devolve esses três verbos. O gerente também não pode escrever notReady; somente o agente relata que os dados estão incompletos. Assim, a mesma coluna aceita intenção num sentido e entrega estado no outro, sem transformar a ordem em prova do resultado.

createAndGo não salvava uma tentativa pela metade

Na criação imediata, o gerente escolhe um identificador de instância livre e envia as colunas necessárias junto com RowStatus=createAndGo. Padrões do agente podem suprir outros valores.

Se houver informação suficiente para colocar a linha em uso, o agente a cria e seu estado observável passa diretamente a active. Se faltar algo essencial, o SetRequest falha com inconsistentValue e a linha não é criada. Uma falha não equivale a “rascunho salvo”. O gerente precisa corrigir os dados e repetir ou adotar criação gradual, quando suportada.

A operação única só é simples porque sua fronteira também é simples: criação e ativação acontecem juntas, ou a linha continua inexistente.

createAndWait deu existência controlada ao incompleto

Quando createAndWait é aceito, a linha passa a existir, mas permanece indisponível para o equipamento. Se faltam colunas obrigatórias, a leitura mostra notReady. Ao preencher essas colunas, o agente pode movê-la para notInService: há informação suficiente para tentar ativar, mas o serviço ainda não começou.

O gerente então solicita active. O agente pode aceitar ou devolver inconsistentValue por causa dos valores, dos recursos ou do estado atual. Estar pronto para a tentativa não garante admissão.

Nem todo agente precisa aceitar o caminho gradual. Ele pode responder wrongValue a createAndWait e exigir todos os valores em uma única criação. Também pode recusar tirar de serviço ou destruir uma linha em uso.

Uma linha parada continua consumindo recursos. O RFC 2579 exige que o agente detecte linhas deixadas tempo demais em notReady ou notInService e as remova. A DESCRIPTION da MIB deveria definir o período; sem definição, o RFC sugere aproximadamente cinco minutos, incluindo tempo humano de decisão. Isso não prova o temporizador de nenhum fabricante.

A DESCRIPTION ainda decidia os detalhes

RowStatus não determina se outras colunas podem mudar enquanto a linha está ativa. Algumas MIBs permitem certas alterações; outras exigem primeiro notInService. A descrição da coluna de estado deve listar o que precisa ter valor válido antes da ativação e explicar as regras de modificação.

O RFC 4181 consolidou essas obrigações. Uma tabela com criação dinâmica por aplicações deve, em geral, ter uma coluna RowStatus read-create. A MIB precisa informar persistência ou StorageType, condições nas quais o próprio agente cria ou exclui linhas e quais mudanças são permitidas durante a atividade.

O padrão oferece uma gramática comum, não uma política universal. A definição específica da MIB continua sendo a fonte que torna cada transição interoperável.

A atomicidade terminava no SetRequest

É comum enviar as colunas e a mudança de RowStatus no mesmo pedido. O RFC 3416 descreve duas fases conceituais: validar todos os variable bindings e, somente se todos passarem, alterar os valores. As atribuições ocorrem como se fossem simultâneas em relação às demais atribuições do mesmo pedido.

Se uma alteração falhar, a entidade tenta desfazer as outras e responde commitFailed. Se não conseguir desfazer tudo, responde undoFailed. O segundo código mostra que nem a abstração local deve ser transformada em promessa absoluta.

Essa semântica pertence a um pedido recebido por uma entidade SNMP. Não é uma transação entre equipamentos, um bloqueio distribuído nem uma prova de armazenamento durável ou efeito no plano de dados. Uma resposta bem-sucedida estabelece um fato de gerência limitado; a operação real exige verificação separada.

O avanço foi admitir que existir não é operar

RowStatus distribui as funções. O gerente declara a configuração desejada. A MIB publica o contrato. O agente valida acesso, valores e transições. O equipamento em execução revela o resultado.

Uma linha visível pode continuar incompleta. Uma linha completa pode ficar fora de serviço. Um pedido de ativação pode ser recusado. Até active não demonstra persistência, segurança ou tráfego correto. Cada estado é útil porque não tenta responder pela camada seguinte.

Fontes e limites

RFC 1212 e RFC 1271 documentam as convenções iniciais e o precursor RMON. RFC 1443 e RFC 2579 definem RowStatus. RFC 3416 limita SetRequest, e RFC 4181 orienta autores de MIB. As fontes não medem adoção atual, conformidade de produtos, política de segurança, prazo universal de limpeza nem efeito operacional. A separação entre intenção, preparo e serviço é uma interpretação do desenho.