要約

  • RFC 2051のAdmin表は既定値や期待値を読み取り専用で示し、Oper表は現在値や交渉値を示す。modeのAdmin行が削除されても、そのmodeを使う活動中sessionとOper行は存続できる。
  • session、conversation、任意の統計、異常終了履歴には、それぞれ異なる生成・削除・保持条件がある。どれ一つとして、設定、相手側の同意、アプリケーション成功、完全性、安全性を単独では証明しない。

RFC 2051を特徴づけるのは、残っているオブジェクトより、消えたオブジェクトである。仕様は、活動中のsessionがmodeを利用していてもappcModeAdminEntryを削除でき、その間appcModeOperEntryは存在し続けると明記した。上段に設定がなく、下段に稼働状態がある画面は、不整合とは限らない。

Admin表は、既定または期待される設定を表す。ただしMIBは、その設定を作成・変更する手段ではなく、オブジェクトは読み取り専用だった。Oper表は現在または交渉済みの状態を表す。動的な対象はAdmin行を雛形にして生まれても、その後は独自の寿命を持つ。

ここから「設定された」「要求された」「agentが受け付けた」「相手と交渉された」「実際に動いている」という五つの主張が分かれる。Admin行の削除は将来の雛形が見えなくなったことを示すが、既存sessionの巻き戻しは示さない。Oper行の存続も、旧設定が今後も承認されていることを示さない。

RFC 2051はglobal、LU、transaction program、session、conversation、CPI-Cの各groupを扱うため、APPC全体を操作するMIBに見えやすい。しかし境界は狭い。partner LU、mode、transaction program、CPI-Cを一般的に作成・削除したり、LUやprogramを有効化したり、conversationやsessionを開始したりするものではない。

書き込み可能な制御も限定的だった。統計やtracingの選択、CNOS命令、session停止の要求などである。書き込みは制御面に要求が置かれた証拠であり、結果の領収書ではない。

CNOSでは差が見えやすい。Admin側は希望値、Oper側は交渉後の実値を持つ。IBMの現行資料はCNOSをChange Number Of Sessionsと展開し、modeごとのsession数を交渉すると説明する。ただしこれは用語の背景であり、特定製品がRFC 2051を実装した証拠でも、交渉成功の証拠でもない。

活動中session表には固有の時間軸がある。状態はunbound、pendingBind、bound、pendingUnbind。agentは仕様に従って行を作成・削除する。boundなsessionにunboundを書けば停止を開始できるが、書き込みが示すのは要求である。agentが何をしたかは、その後のOper状態で確認する必要がある。

boundも限定された事実にすぎない。conversationが割り当てられたか、transaction programが完了したか、相手が正しいデータを返したか、業務処理が成功したかは示さない。peerの状態とapplicationの結果は別の証拠面にある。

conversationはさらに短命である。開始時にagentが活動行を作り、終了時に消す。sessionに関連づけられていても、sessionそのものではない。一つのsessionは、その前後を通じて複数のconversationを運べる。

統計も任意の別レイヤーである。収集がactiveなときだけ、agentは活動中sessionごとに統計行を作る。counterはRFC 1902のCounter32で、計測期間を示すuptimeが付く。期間、wrap、収集状態を失った数値は、完全な履歴にならない。

さらに、統計収集のAdmin状態をinactiveにすると、session統計表の全行が削除される。RFCは、それで活動中sessionが終了するとは述べていない。空の統計表は、無活動ではなく、計測停止を意味し得る。

履歴表も網羅的ではない。session履歴は異常終了を、conversation履歴はerror終了を保持する。件数や期間は実装依存である。空の履歴から、通常動作がなかったとも、過去の異常がすべて保存されているとも言えない。

RFC 1666はSNA管理モデルの系譜を示す。APPC MIBの位置づけには役立つが、仕様を導入実績へ変換しない。標準はobjectを精密に定義できても、運用者が設置、有効化、保護、正しい解釈をしたことまでは証明しない。

文書のstatusも慎重に扱う必要がある。IETF DatatrackerとRFC Editorの情報ページは、1996年10月公開のStandards Track、Proposed Standardと記録する。凍結したRFC status changesにRFC 2051の変更はなく、公式記録に更新・廃止RFCも示されない。古いlegacy技術の文書であっても、公式statusをHistoricと書く根拠はない。

RFC Editorのerrata検索は該当なしだった。これは文書上の訂正についての不確実性を一つ減らすだけで、実装、相互運用、完全性、現在性を保証しない。

securityについて、RFC 2051は議論しないと明記した。Standards Trackという属性から、access control、安全なmanagement write、counterの信頼性を導くことはできない。稼働中のsessionが安全とは限らず、management objectの存在は変更権限者を示さない。

したがって、表は管轄の異なる証人として読む。Adminは提示された設定、writable controlは要求、agentの遷移は受理と実行、CNOS Operは交渉結果、session行は稼働関係、conversation行は一回のinteraction、統計は収集期間の計測、履歴は保持された異常終了を示す。peerとapplicationは自分の領収書を必要とする。

設定行の消失が今も重要なのは、設定を権威、稼働を成功と読み替える近道を断つからだ。RFC 2051では、sessionは生成時の雛形より長く生き、稼働の事実はそれを数えた証拠より長く生きる。

出典