要約

  • Datatrackerは2026年9月11日、draft-ietf-intarea-legacy-registries-00の作業部会版を承認したと記録した。現時点ではInternet-Draftであり、RFCではない。
  • 草案は一つのレジストリを閉鎖し、一つをIESG Approvalにし、二つをFirst Come First Servedにし、TTLのレジストリを削除または注記変更するよう求めている。
  • IANAの五つの公開箇所は従来の状態を保っている。文書の段階と実施結果を結ぶには、操作ごとの記録が必要だ。

採用で変わったのは管理主体

現在のDatatrackerでは「Updates to Legacy IANA Registries」がINTAREAの文書として掲載されている。履歴を見ると、9月11日に作業部会版-00が承認され、従来の個人草案を置き換えたことが分かる。

この置き換えには意味がある。個人の提案だった課題を、作業部会が共同で検討し、今後の修正に責任を持つと決めたからだ。しかし、文書の冒頭にdraft-ietfが付いただけで、Proposed Standardが承認されたことにはならない。IANA Considerationsに書かれた依頼も、まだ実施済みの命令ではない。

個人草案側の履歴には、8月27日に採用への合意が記録されている。同時に、反対意見が提示され、十分に聞かれ議論されたとの判断も残る。議長は、この文書がIPv4の将来を決めるものではなく、レジストリ維持手順を扱うものだと説明した。採用は「この課題を引き受ける」という判断であり、すべての根拠文に異論がなくなったという宣言ではない。

個人版03とINTAREA版00を比べても、求める操作は変わっていない。違いはSecurity Considerationsの文法修正と謝辞への一名追加である。文書名の変更は手続きの証拠であって、IANAの実施証明ではない。

「整理」では区別できない四種類の操作

草案は古いレジストリを一括して扱うが、処置は一様ではない。

NetWare/IP Option Type 63 Sub-Option Codesには閉鎖を求める。NetWareが拡張されなくなったため、新規登録を止めるという考え方だ。ただし既存値は有効なままで、更新もできる。RFC 8126も、閉鎖とは新規受付の停止であり、情報を消すことではないと定義している。

IP Option Numbersは閉じない。登録手続きをIESG Approvalにする。RFC 8126によれば、これは日常的な方法ではなく、例外的で利用例の少ない経路である。IESGはRFCを必須とせずに個別承認できる一方、資料提出やコミュニティへの意見照会を求められる。草案は判断主体を明確にしようとしているのであって、IPv4オプション番号を全面禁止しているわけではない。

Machine NamesとTerminal Type NamesにはFirst Come First Servedを設定する。これは審査を伴わず、最低限の文書で受け付ける方式だ。長年新規登録がない二つの一覧に、初めて明示的な入口を設けることになる。閉鎖とは逆向きの制度変更である。

IP Time to Live Parameterは削除が第一案だ。TTLはOSやアプリケーションが選べるため、そもそもレジストリ化すべきでなかったという理由である。完全削除が難しい場合には注記を書き換える。ページの撤去、注記の差し替え、受付停止は、それぞれ保存される情報も将来の見つけやすさも異なる。

IANAページはまだ変更前を示す

IANAのDHCP・BOOTP Parametersでは、NetWareの各値が今も掲載され、登録手続きはNot definedのままだ。閉鎖表示はない。

IPv4 Parametersでも、IP Option NumbersはNot definedである。IP Time to Live Parameterも残り、推奨デフォルトTTLを64とする注記が表示される。実験用オプション値は別に保持されているが、IESG Approvalという新しい手続きはまだ見えない。

Machine Namesの手続きはNot defined、Terminal Type Namesは疑問符付きのNot defined?である。First Come First Servedへの変更はどちらにも反映されていない。

これは遅延や怠慢の証拠ではない。RFC 8126では、IANAの操作は通常、文書が発行承認された段階で行われる。現文書はまだ作業中だ。INTAREAの文書一覧は標準化手続きの状態を示し、IANAページは現行の登録状態を示す。前者だけで後者を推測してはいけない。

反対意見も作業部会に引き継がれた

IETF 126のINTAREA議事録には、IPv4オプション番号を将来使えなくすれば限定ドメインでの用途を妨げるのではないか、古い情報を失わないようにすべきだ、という二つの論点が残っている。作者は実験用の値と既存登録の保存を挙げて応じた。

採用に関するメール議論では、IPv4オプションの信頼性に関する表現や、理由付けが後に広すぎる主張として引用される危険も指摘された。支持表明もある。採用決定は議論を無効にするのではなく、その解決責任を作業部会に移す。

したがって、現時点の結論は控えめでなければならない。INTAREAは文書を扱うと決めた。各操作を最終承認したわけでも、IANAに反映したわけでもない。

一操作につき一つの実施記録を

この後の経過を確認しやすくするため、操作ごとのレジストリ実施記録を公開するとよい。これは編集上の提案であり、IETFやIANAの既存要件ではない。

記録には、正確なレジストリ名とURL、変更前の日付付き状態、草案の版とハッシュ、要求された動詞、作業部会・IETF・IESGでの判断、IANAによる実施確認、有効な参照文書、変更後の状態、既存値の保存方法を含める。

Machine NamesとTerminal Type Namesは同じ方式になっても別々に記録する。NetWareは「閉鎖、既存値は保存」と書き、削除とは呼ばない。TTLはページ削除か代替注記かを区別する。後の版でIP Option Numbersの方針が変われば、古い依頼も履歴に残す。

五つの小さなレジストリだからこそ、曖昧な一括表示を避けられる。新しい文書名が証明するのは作業の所属だ。将来のRFCが証明するのは承認された指示である。実際の変更を証明するのは更新後のIANAページだ。この三つを同じ日付にしてはならない。

情報源

  1. IETF Datatracker — 現在の作業部会文書
  2. 作業部会文書の履歴
  3. 作業部会版00
  4. 置き換えられた個人草案の履歴
  5. 個人版03
  6. IETF 126 INTAREA議事録
  7. INTAREAの採用議論
  8. IANA — DHCP・BOOTP Parameters
  9. IANA — IPv4 Parameters
  10. IANA — Machine Names
  11. IANA — Terminal Type Names
  12. RFC 8126 — IANA登録手続きの指針
  13. INTAREA文書一覧