Resumo

  • O RFC 1503 propôs um «context resolver» para poupar o usuário de informar manualmente party e context ao aplicativo de gestão SNMPv2.
  • Para um host sem configuração prévia, o resolvedor podia criar um par noAuth/noPriv, um contexto e uma ACL voláteis para get, get-next e get-bulk. A operação ainda dependia das exigências de segurança informadas pelo aplicativo.

O problema descrito por Keith McCloghrie e Marshall Rose era prosaico: alguém queria consultar um equipamento, mas a arquitetura exigia detalhes administrativos que não cabiam bem na conversa entre pessoa e programa. A proposta de agosto de 1993 deslocava esse trabalho para o gerente. Um resolvedor consultaria a base local de partes antes de montar a requisição.

Ele começava pelo que o administrador já havia cadastrado. O identificador exato router.xyz.com-public selecionava um contexto. A forma mais curta router.xyz.com podia corresponder a dois, -public e -all. No exemplo, o primeiro permitia consultas; o segundo tinha acesso autenticado e incluía set. A redução de texto digitado não reduzia as alternativas. O aplicativo ainda precisava dizer que operação queria e qual segurança exigia.

Sem correspondência local, o nome era resolvido para endereço IP. O gerente então criava duas partes noAuth/noPriv, um contexto e uma ACL temporários, com permissões de get, get-next e get-bulk. Vários endereços produziam vários contextos. Os identificadores seguiam initialPartyId e initialContextId, convenções do Party MIB. Esses registros nasciam no gerente; nenhum deles comprovava que o agente remoto havia respondido.

O mesmo mecanismo aceitava um segundo tipo de atalho: após uma barra no nome ou endereço, o sufixo virava uma comunidade SNMPv1. Nesse caso também surgia um contexto de consulta volátil. Uma única caixa de entrada passou a carregar destino, possível versão e até material de acesso.

Na hora da requisição, o gerente procurava uma ACL que aceitasse a operação e satisfizesse o mínimo de segurança pedido. Preferia uma opção SNMPv2 adequada; se a autenticação fosse exigida e não houvesse entrada que a atendesse, não executava a operação. O host encaminhava a seleção, mas a permissão vinha da ACL.

O registro oficial classifica o texto como Informational. O modelo é uma proposta, sem produto ou operação bem-sucedida identificados. A seção de segurança declara que não discute essas questões. Ainda assim, o documento mostra o custo invisível da facilidade de uso: o gerente não eliminou a administração. Passou a fazê-la em nome do usuário.