要約

  • RFC 1503は、利用者がSNMPv2のpartyやcontextを列挙せず、文字列を管理アプリに渡す仕組みを示した。
  • 未登録のホストでは、noAuth/noPrivのparty対、context、get系操作だけを認めるACLを揮発性の記録として作れる。実行時にはアプリが求める安全条件も照合する。

機器を調べたいだけなのに、管理者が内部のparty構成まで毎回指定するのは面倒だ。Keith McCloghrieとMarshall Roseは、その面倒を「context resolver」に引き受けさせた。管理アプリとローカルのpartyデータベースの間に置き、入力された文字列から対象を探す。1993年8月の文書が描いたのは、操作を減らすための裏方の手順である。

まず、既存の設定を調べる。router.xyz.com-publicという正確なハンドルなら、そのcontextを返す。router.xyz.comだけなら、前方一致する-publicと-allの両方が候補になる。例では前者が照会用、後者は認証付きでsetも可能だ。同じ短い入力が複数の設定を呼び出すため、操作の種類と安全要件による選別が欠かせない。

一致がなければ、IPアドレスまたはDNSで解決した名前として扱う。単一アドレスにはnoAuth/noPrivのparty対、context、get・get-next・get-bulk用ACLを一時的に作る。複数のアドレスに解決されれば、それぞれに作る。識別子には先行するParty MIBのinitialPartyIdとinitialContextIdの約束を使う。これは管理側の帳簿を増やす手順であり、相手の機器から認証済みの証明を受け取る手順ではない。

さらに、名前の後ろにスラッシュと文字列を付ければ、その文字列をSNMPv1のコミュニティとして使う別の一時コンテキストも作れる。入力欄の短さと引き換えに、管理側が読み取る意味は増えていく。

要求を送る段階では、アプリがcontextのハンドルと最低限の安全条件を渡す。管理側は操作を許し条件を満たすACLを探し、適切ならSNMPv2を優先する。認証が必要なのに該当する設定がなければ実行しない。名前は入口、許可の判定はACLに残る。

RFC Editorの書誌は、この文書をInformationalとしている。実装例や成功した照会の記録はない。安全上の論点は本文末で扱わないと明記された。残るのは、使いやすさの費用をどこに計上したかという設計図だ。入力から消えた項目は、管理側のローカル記録に移った。