要約

  • RFC 1283 は SNMP を OSI の connectionless な CLTS と connection-oriented な COTS に載せる実験仕様だった。COTS は接続を確立し、一つ以上の message を送り、接続を解放する。
  • initiator は response が同じ接続に戻ることを要求できず、接続に SNMP の信頼性を帰属させてもならなかった。timeout、再送、中止は application の責任だった。
  • RFC 1418 は後に COTS mapping を削り、UDP がない環境向けに CLTS だけを残した。仕様の交代は全実装が同時に消えた証拠ではない。

実験の記録は成功証明ではない

1990 年 6 月の RFC 1161 は、OSI transport 上で SNMP を動かす experimental な手段を示した。Internet standard ではなく、実験と十分な consensus の後に将来の改訂が標準になり得ると述べるにとどまった。

1991 年 12 月、RFC 1283 がこれを obsolete にしたが、地位は Experimental のままだった。編集者は初版後の operational experience を反映したと記した。これは文書が学習した証拠であり、特定 network の成否ではない。

SNMP は TCP/IP network で広く使われ、OSI capability を導入する site は管理投資を再利用したかった。RFC 1283 は SNMP を OSI application layer に作り直さず、transport service に直接対応させた。

CLTS は packet の形を保った

CLTS の手順は UDP に近く、どちらも完全な addressing information を持つ packet を送った。transport address は network address と selector の組合せだった。

OSI はここで Internet の well-known port を使わない。destination だけで意味を持つ opaque octets が demultiplexing を行う。RFC 1283 は CLNP 上で通常 message に snmp、trap に snmp-trap を割り当てた。

selector が示すのは local service の入口である。manager を認証せず、Set を許可せず、variable の真実を証明しない。配送の label と管理 authority は別だった。

COTS は association を加えただけだった

SNMP 自体は既存接続を必要としない。そこで COTS mapping は transport connection を確立し、一つ以上の SNMP message を送り、解放する手順を置いた。

接続は開く前に失敗できる。開いても完全な request が届かないことがある。transport が bytes を受理した後、application response より前に閉じることもある。established は transport 自身の状態だけを証明し、decode、access decision、object read、Set、結果を証明しない。

response は同じ接続に縛られなかった

RFC 1283 は initiator に、request の接続で response が戻ることを要求させなかった。一方 responder がその接続で SNMP message を送るなら、そこで受けた request への response でなければならない。

接続は条件付きの correlation を与えたが、唯一の返信路ではない。接続上の沈黙から response 不在を結論できず、接続そのものも durable operation ID ではなかった。

寿命の決定も分かれていた。理想的には initiator が解放するが、responder は resource limit で閉じられる。継続時間は implementation-specific な dynamic algorithm によった。close は policy、pressure、idle、failure のどれでもあり得て、SNMP outcome を単独では語らない。

transport ACK は application に届いた証明ではない

RFC 1283 の核心は、initiator が接続に reliability を結び付けてはならないという規則である。SNMP message の retransmission は transport ではなく SNMP application に残った。

RFC 1270 は理由を明確にした。connection-oriented transport の ACK は destination application process への delivery を必ずしも示さない。SNMP software が packet を受けたか確かめるには、SNMP 自身の timeout と retry がまだ必要だった。

transport の信頼性は bytes の契約を守れる。しかし bytes の到着と management operation の完了は同じではない。correlated response が次の証拠になる。それでも agent が返した値は report であり、物理 network の真実を自動的に確定しない。

接続維持には三つの負担があった

RFC 1270 は、全 managed object に常時接続、operation ごとの開閉、固定 pool と LRU 等による置換を比較した。常時接続は多数の record と無益な keepalive を生む。毎回接続は establish、close、TIME-WAIT を重ねる。pool は usage ledger と置換判断が必要で、agent 数が pool を超えると毎回接続に近づく。

どの接続を誰が閉じるか、late response をどう扱うかが新しい control surface になった。stateful transport は帳簿をなくさず、別の帳簿を作った。

1993 年の改訂は CLTS だけを残した

1993 年 3 月の RFC 1418 は RFC 1161 と RFC 1283 を obsolete にした。UDP が利用できない環境向けに connectionless OSI mapping だけを残し、agent が複数 mapping を持つべきだという意味ではないとした。

CLTS は connectionless network service にも connection-oriented network service にも載り、別々の selector を使えた。下の network が connection-oriented でも、SNMP に見える transport contract は connectionless である。connection という語は layer を外して読めない。

出典と限界

本稿の資料は RFC 1161、RFC 1270、RFC 1283、RFC 1418 である。歴史的な規則、議論、文書交代を支えるが、現在の実装、本人性、権限、実接続、request、response、retry、障害、結果は証明しない。四文書とも security issue を論じていない。