要約

  • OBJECT-GROUPは語彙、MODULE-COMPLIANCEは最低契約、AGENT-CAPABILITIESは製品リリースが主張する実装内容を表した。
  • いずれも実装時の定義であり、稼働中の各オブジェクトを動的に検証する仕組みではなかった。
  • 実装済みなら合理的に正確な値を返し、書込み可能なら管理対象へ実際に影響し、未実装なら偽値ではなく例外を返す必要があった。

一枚の対応表を三層へ分ける

RFC 1444は「このMIBに対応」という大きな言葉を認めたままにはしなかった。OBJECT-GROUPで関連オブジェクトを適合単位にまとめ、MODULE-COMPLIANCEで適合を主張する最低線を定め、AGENT-CAPABILITIESで特定リリースが主張する支援範囲と差異を記述した。

グループには無条件必須、あるプロトコルなどが存在するときだけ必須、任意という違いがあった。個別オブジェクトには読取り構文、書込み構文、最低アクセスの精密化も置けた。

RFC Editorの記録によれば、文書は1993年4月のProposed Standardで、後にRFC 1904が置き換えた。歴史的な価値は、適合という札をオブジェクトまで分解可能にした点にある。

最低条件は脈拍ではない

三つのmacroは、概念上、run-timeではなくimplementation時に展開されると説明された。何を作るべきか、何を作ったと主張するかを記す。宣言を読む行為が、生きたprocessへの問い合わせに変わるわけではない。

ただしMANDATORY-GROUPSの契約は厳しい。適合を主張するagentは、列挙された各groupの全objectを実装しなければならない。必須objectがすべてのMIB viewでnoSuchObjectを返すなら、そのmoduleに適合しない。GROUP clauseでは、特定protocolを実装する場合だけ必須、といった条件をDESCRIPTIONに書けた。

契約は検査点を特定する。しかし、その装置で条件が成立するか、現在のprincipalにどのviewが与えられたか、objectを供給するprocessが今動くかは観測事項である。

OIDは主張への索引だった

AGENT-CAPABILITIESは、製品ごとの細かな違いを管理applicationが毎回手探りしないための仕組みだった。能力記述をsysObjectIDまたはsnmpORID instanceに結び、management stationがidentifierを読み、databaseから対応する記述を探し、操作を最適化できた。

未対応groupを避ける、read-only variationへ書かない、制限されたsyntaxに従う、row作成時の必須cellを用意する、といった最適化が可能になる。動的にobject resourceを学ぶagentではsysObjectIDだけで足りず、operational-resource identifierが現在の表明を補った。

それでもidentifierが開くのは実装者の宣言である。機能が有効か、viewに見えるか、processが壊れていないか、値が正しいかを測定しない。案内図は歩行距離を短くするが、目的地への到着証明にはならない。

variationは部分的な真実を明示した

RFCの例には、未実装object、制限されたsyntax、read-only object、読取りと書込みで異なる許容値、row作成に必要な追加cellが並ぶ。完全対応を装わず、どこがどう違うかを機械と人へ示せた。

意味の更新にも境界があった。object group、compliance definition、capabilities definitionへ非編集的変更を加えるなら、新しいdescriptorとOIDが必要だった。同じidentifierが異なる契約を指せば、過去の宣言を再現できないからだ。

現在の判定はオブジェクトが行う

RFC 1444が定めた「implement」は行動である。取得要求には合理的に正確な値を返す。書込み可能なら、set operationが基礎にあるmanaged entityへ合理的に影響できる。実装できないならnoSuchObjectなどのexceptionかerrorを返し、偽の値を返してはならない。

証拠は少なくとも四つに分かれる。releaseの能力表明、principalとviewが許す範囲、今回のprotocol result、そして値の正確性やwriteの効果・永続性を確かめる独立観測である。

数値が返っただけではcounterの正確性は証明されない。Set成功だけではinterfaceが変化したことも再起動後の維持も証明されない。例外をzeroへ置換すれば、故障していないように見える代わりに最重要の観測を失う。

後継も宣言と実行を分けた

RFC 1904の記録は1996年の置換を、RFC 2580の記録は1999年の次の置換を示す。RFC 2580でも、groupを主張すれば全objectまたはnotificationが必要で、製品releaseのcapabilityとsysORID databaseが管理を最適化した。しかしそれは動的attestationにはならなかった。

securityも別の証明面である。RFC 1444はsecurity問題を扱わないと明記した。RFC 3410は後に、従来のSNMPv2 frameworkがauthentication、privacy、authorization、access control、remote administrationの当初目標を満たさず、SNMPv3が重大な不足へ対処したと整理した。

Lu HengのRunning-Code Primacyは、publication、implementation、validation、deployment、useを順番のある別々の行為として読む。Reality Layersは、象徴的な主張と実行可能な結果を混同しないための枠を与える。

RFC 1444は宣言を否定しなかった。宣言を精密にし、その効力を限定した。設計表は検査を助ける。それでも現場の針は自分で動かなければならない。

情報源