要約

  • RFC 1700は、継続中の割り当て作業を1994年10月に切り取ったスナップショットだった。値が不完全となり誤りも含むようになったため、RFC 3232は同文書をHistoricへ移した。
  • 現行の割り当てを立証するには、レジストリ名とURI、取得時刻、行・状態・参照、登録方針、原データのハッシュを残す。RFCは来歴と手続きを語るが、現在値の観測にはならない。

あるコードポイントについて、「事件当時は何に割り当てられていたのか」と問われたとする。手元のRFCには一つの名前がある。IANAのページには別の状態がある。どちらかを最新版として上書きすれば表はきれいになるが、事件時点の判断根拠は消える。

この問題をわずかな文章で制度上の決着に導いたのが、Joyce K. Reynoldsによる RFC 3232 である。2002年1月、同文書はAssigned Numbersの定期RFCがオンライン・データベースに置き換わっている事実を確認した。1994年10月のRFC 1700は、すでに不完全で、ときに誤った値を含んでいた。そこで状態をHistoricとした。

「古いので捨てる」という話ではない。何を証明できる資料なのかを正確に言い直したのである。

出版物の中にあった更新装置

ReynoldsとJon Postelが編集した RFC 1700 は、自らを進行中の割り当て過程のスナップショットと記していた。現行の割り当てはオンラインのテキストファイルで保守され、RFCはそれらを連結し、体裁を加えて作られた。申請や訂正の窓口はIANAであり、Reynoldsの連絡先も掲げられていた。

RFC 900 まで遡ると、表の内部にも時間が見える。変更前のネットワーク番号を移行期間中だけ残す扱いや、状態を示す印、参照先が存在した。Assigned Numbersは静的な一覧であると同時に、変化を処理する運用の断面だった。

RFC化には大きな利点がある。ある時点の編集結果に恒久的な識別子を与え、後から同じ内容を参照できる。一方、次の割り当ては刊行日を待たない。オンラインの原簿が一件進むたびに、刊行版との差が広がる。訂正の場合、その差は単なる不足ではなく誤情報になる。

RFC 3232は二つの問いを別々の資料に戻した。1994年に何が公開されていたかを知るならRFC 1700を見る。現在何が登録されているかを知るなら、その時点のオンライン・レジストリを見る。この使い分けによって、古いRFCは歴史資料としての価値を失わずに済んだ。

レジストリは判断の終点である

オンラインに載っていることだけで権威が生まれるわけではない。RFC 2860 は、IETFの範囲にある技術パラメータについて役割を分ける。IANAはRFCに定められた基準と手続きに従って割り当て・登録を行う。曖昧さや技術的な争いがあればIESGの助言を受け、必要ならIABが裁定する。

同じ合意は、現在の割り当て情報を無償でオンライン公開し、申請のための仕組みを設けることも求める。つまりレジストリの一行は、単なるデータ入力ではなく、規則から審査、実施、公表までを経た結果だ。

RFC 8126 は、新しいレジストリに必要な設計を具体化する。名称と用途、登録に必要な項目、初期値、変更管理、将来の登録方針を明確にする。First Come First Servedなら形式と重複が主な確認点になる。Expert Reviewでは指定専門家の承認が要る。Specification Required、RFC Required、IETF Review、Standards Actionは、それぞれ異なる公開文書や合意の強さを要求する。

したがって、隣り合う二つの値が同じ形で表示されても、成立過程は同じとは限らない。Reserved、Unassigned、Deprecatedといった状態、参照RFC、変更を制御する主体、適用された方針を落としたコピーは、番号を保存しても意味の一部を失っている。

「現在」を再現できる形にする

IANAの説明は、世界で共有される識別子の一貫性を保つ権威ある公開レジストリを運営すると述べ、現在のIANA機能はICANN傘下のPublic Technical Identifiersが担うとしている。これは2026年9月10日に確認した現在の説明であり、過去にも未来にも自動で延長できない。

レジストリのURLも同様だ。アドレスが安定していても、表示内容は更新される。「現在値」という表現は、本来なら必ず観測時刻を含む。

調査記録には、レジストリの正式名称とURI、タイムゾーン付き取得時刻、対象の行または範囲、表示上の状態と参照を入れる。さらに取得したHTMLや構造化応答をそのまま保存し、ハッシュを計算する。加工後の表は便利だが、原資料への逆参照を切ってはならない。

状態と意思決定も別々に持つ。申請、専門家の評価、IETFでの合意、IANAの登録作業、後日の訂正は、それぞれ別の出来事である。単一の「source」欄に押し込むと、誰がどの規則の下で変更したかが追えなくなる。

再取得時に差が出たら、以前の値を消さず両方を保管する。値の変更、状態変更、参照追加、方針改定、あるいは収集プログラムの誤差を区別する。こうして初めて、データの変化を出来事として説明できる。

Reynoldsが残した境界線

Internet Hall of Fame は2025年、Joyce Reynoldsを死後に顕彰した。同紹介はUSC Information Sciences InstituteでPostelと働いたこと、のちにRFC Editorを共同で率いたことを記す。Reynoldsは2015年に死去しており、これらは歴史上の貢献を裏づける資料であって、現在の役職や見解を示すものではない。

継続的に変わる割り当て情報を、長く残るRFCへ整える仕事を知っていた人物だからこそ、RFC 3232の判断は重い。アーカイブと現用サービスのどちらが優れているかを競わせず、それぞれに答えられる問いを割り当てた。

実務の証拠も三層に分けるとよい。第一層は時刻付きのレジストリ状態。第二層は登録方針、申請、審査、実施の経路。第三層は名前空間や手続きを作ったRFCと過去のスナップショットである。三層を個別に版管理し、識別子で結ぶ。

そうすれば、現在を更新しても過去を壊さない。RFCの方針だけが変わった場合はガバナンスの出来事、レジストリの行だけが変わった場合は運用上の出来事として残せる。長く残る文書を、動き続ける現在の代用品にしない。それがReynoldsの短いRFCから引き出せる、最も実務的な教訓である。

出典