Summary

  • RFC 5237 は、非開示情報を扱う Expert Review による割当を廃止した。IPv4 Protocol と IPv6 Next Header は、公開して検討できる仕様を伴う IESG Approval または Standards Action によって割り当てる。
  • 登録は意味の衝突を防ぐが、実装、相互運用性、安全性、導入、通信量を証明しない。公開性は番号を消費するための証拠であり、稼働の証明ではない。

見えない理由が見える実装を拘束する

RFC 2780 の旧規則は、IPv4 Protocol 値に Expert Review、IESG Approval、Standards Action の三つを認めていた。Expert Review は非開示情報を含む特別な場合に限り、IESG が専門家を指名する想定だった。

申請者にとっては合理的に見える。研究や製品計画を競合に知らせず、必要な番号だけを確保できる。しかし割当の効果は秘密契約の内側にとどまらない。

OS、ルータ、ファイアウォール、解析器、将来のプロトコル設計者は、その値を使用済みとして扱わなければならない。理由を読めなくても、衝突を避け、未知の例外を保守する責任を負う。

RFC 5237 はこの非対称を解消した。秘密の開発を禁止したのではない。秘密のまま、この有限な共有欄を恒久的に一枠減らす権利を否定した。

256 枠では必要性が政策になる

Protocol フィールドは 256 値しか持たない。RFC 5237 は執筆当時の 2008 年に 55% が使用中だったと記す。これは現在の利用率ではなく、その時点の判断材料である。

限界があるため、申請には健全性確認が要る。安定した仕様があるか。実際に利用しようとする集団があるか。同じ目的の割当が既にないか。そもそも IP Protocol 値が必要か、それとも TCP や UDP のポートで表現すべきか。

Standards Action は標準化のために残った。IESG Approval も、正当な非 IETF または非 Standards Track の用途のために残った。閉じたのは、理由が公に検証できない入口だけである。

公開仕様と IETF 標準は同じではない

公開すれば、重複、層の選択、安定性を第三者が検討できる。しかし公開文書が自動的に IETF 標準になるわけではない。IESG Approval が残ったこと自体が、Standards Action 以外の適切な割当を認めている。

公開は特許、ライセンス、所有権を一挙に解決するものでもない。共通番号の意味を検証可能にする要求であり、設計をめぐる法的関係すべてを変更する規則ではない。

証拠は段階ごとに分けるべきだ。仕様は提案内容を示す。承認は番号使用の判断を示す。IANA の表は割当を記録する。動くコードと相互接続は、その後に別途証明される。

IANA の行は品質証明書ではない

IANA Protocol Numbers レジストリは値と参照先を管理する権威ある台帳である。だが IANA がプロトコルを設計した、事業価値を認定した、安全性を試験したという意味ではない。

この境界は管理者の権限を限定する。唯一性を維持する役割は、技術の所有権にならない。同時に申請者の宣伝も限定する。登録された事実を、採用や性能の証明に昇格させてはならない。

行が証明するのは、公開された根拠の下でその値に調整済みの意味があることだけだ。製品、導入、利用者、通信量、運用成果は別の記録を要する。

実験値は不確実性を隔離する

RFC 4727 は実験と試験のために 253 と 254 を予約した。永久的な意味を主張する前に、限定環境で設計を動かせる。

実験値に万能性はない。複数の実験が衝突し得る。中間装置が通さないこともある。研究室の成功はインターネット全体での到達性を示さない。

それでも順序は重要だ。不確実性を明示した場所で試し、仕様と必要性が公開審査に耐えた時点で恒久割当を求める。秘密を永久予約に変えるより、失敗の範囲を正直に保てる。

他のレジストリへ自動適用しない

RFC 5237 は、他のパラメータ空間における秘密保持付き割当について立場を取らないと明記する。容量、委任構造、衝突の影響が異なるためである。

具体的な規則は IPv4 Protocol と、RFC 2780 の参照を介した IPv6 Next Header に属する。ただしインセンティブの問いは広く使える。秘密の利益は申請者に、共有値の減少は全員に帰属する。政策はそのずれを隠してはならない。

RFC 8126 は後に IANA 登録政策の用語を更新した。現行語彙を理解する助けにはなるが、2008 年の BCP 37 が RFC 2780 の一選択肢を除いたという歴史を置き換えない。

番号から稼働までを一段ずつ測る

提案受領、公開仕様、権限ある判断、IANA 登録、実装、相互運用試験、導入、観測通信はそれぞれ別の出来事である。

公開文書が不適切な設計を示すこともある。割当後にコードが現れないこともある。二実装が一致しないこともある。動く製品が導入されず、導入された通信が目的を果たさないこともある。

Lu Heng の running-code 優先は、この昇格を防ぐ。公開は秘密の保証より強いが、文書はコードではない。レジストリの行は唯一性の受領証であって、運用成績表ではない。

Sources

Additional standards record

  1. RFC 5237 プレーンテキスト
  2. RFC 5237 情報ページ
  3. Datatracker の RFC 5237
  4. RFC 5237 の履歴
  5. RFC 5237 の正誤情報
  6. RFC 5237 を参照する文書