要約

  • RFC 2020では、設定の書き込みは意図を示すだけであり、希望するモードとリンクが実際に採用したモードの間に訓練が置かれていた。
  • 現在のフレーム形式がMTUを1,500または4,464オクテットに決め、訓練状態がopenedになったときだけifOperStatusはupになった。

書き込まれた値は結果ではない

dot12DesiredFramingTypeは次回の訓練でIEEE 802.3互換、IEEE 802.5互換、またはどちらでもよいという希望を指定した。dot12CurrentFramingTypeは別の問い、すなわち今どの形式が使われているかに答えた。「どちらでもよい」が選ばれても、現在値は一つの実形式に確定しなければならない。

この差はifMtuに直結した。現在が802.3形式なら1,500、802.5形式なら4,464である。希望値の変更は次回訓練後にMTUを変える可能性があるが、SETの受理だけでは形式もMTUも変わったとはいえない。

外見の似たフレームからアクセス方式を推定することもRFCは退けた。802.12はEthernet形式やToken Ring形式を使えても、媒体アクセスには独自のDemand Priority Access Methodを使った。したがって、形が似ているだけでEthernet-like MIBやToken Ring MAC MIBを適用すべきではなかった。Token Ring形式に加えて実際にソースルーティングを支える場合だけ、RFC 1749という狭い例外が生じた。

訓練が証拠の境界を作った

訓練フレームはリンク初期化だけに使われ、下側のスレーブが開始し、上側のマスターが応答した。RFC 2020は、限界品質のリンクが訓練を通過しないよう、誤りのない訓練フレームを24個連続で受信する条件を示した。

dot12Statusはclosed、opening、opened、openFailure、linkFailureを区別した。ifOperStatusがupになるのはopenedだけである。openやresetの指示、希望フレーム形式、希望プロミスキャス状態、制御モードの変更は再訓練を始め得るが、開始は完了の証拠ではない。

プロミスキャスモードも同じ構造を持った。dot12DesiredPromiscStatusは次の訓練パケットで要求する状態で、マスターが許可するとは限らない。ifPromiscuousModeへの書き込みは希望値を更新して再訓練を起こす一方、訓練後の同オブジェクトは要求ではなく実使用モードを示さなければならない。dot12LastTrainingConfigは最後の無誤り訓練フレームから設定ビットを残した。

ここでいうマスターもプロトコル上の役割にすぎない。送信を要求する端末に許可を出す参加者を指し、装置の所有、組織上の権限、パケット配送を証明しない。

計算可能性には上限がある

通常優先度の送信カウンターは、総送信量から高優先度分を引けば得られるため省略された。受信側では、エラーフレームや読めないオクテットの扱いが異なり、追加観測が必要だった。式は観測値同士の関係を定めるが、宛先への到達、アプリケーション成功、サービス履行までは証明しない。

セキュリティにも同じ上限がある。RFCの該当節はセキュリティ問題を論じないと明記した。opened、受理済み設定、交通量はいずれも認証や安全性の証拠ではない。

二つの文書時計

現在のRFC EditorとIETFはRFC 2020をProposed Standardとしており、後継RFCを示していない。2026年9月11日のRFC Editor検索では該当する正誤表がなかったが、これはその日のデータベース結果である。

一方、IEEEはIEEE 802.12-1995をInactive-Withdrawnとし、2001年1月15日の撤回を記録している。Demand Priority Working Groupも解散済み一覧にある。これは後年の別の文書ライフサイクルであり、普及率、性能、市場結果を測るものではない。文書状態を稼働実態に読み替えれば、RFCが避けた混同を繰り返すことになる。

出典