要約

  • IESGは8月27日、設置文書のRFC承認前にIANAがレジストリ全体を作れるようにする案をラストコールに付した。レジストリは作成日と失効日を公開し、当初2年間の暫定状態に置かれる。
  • レジストリと個々の登録は同じ時計で動かない。草案の版、WGの合意確認、議長とADの承認、暫定登録手続、方針変更、更新、閉鎖、恒久化を、レジストリ層と行層の状態遷移台帳に残す必要がある。

「期限切れ」と表示されたとき、何が期限切れなのか。表全体なのか、一つのコードポイントなのか、その値を説明する草案なのか。あるいは、新規登録を受け付ける権限だけなのか。

今回の提案は、この問いを抽象論ではなく運用設計の問題にする。IESGは8月27日、Early IANA Registry CreationをProposed Standard候補としてラストコールに付した。意見提出期限は9月10日である。現在の第02版はInternet-Draftであり、まだRFCでも承認済みの標準でもない。

背景には実装上の行き詰まりがある。新しいプロトコル用レジストリを定義する文書が完成する前に、別の草案がその表から値を必要とすることがある。IETF外の標準化団体が継続的な割当てを待つ場合もある。WG内の非公式な表は早く作れるが、後にIANAの正式表と併存する危険がある。すべてをRFC発行まで待てば、相互接続試験が遅れる。

提案は、定められた承認経路を通った場合に限り、IANAが先に公開レジストリを運用する道を設ける。既存の表から一つの値を暫定割当てする制度より射程が広い。新しい表、暫定的な入口、追跡責任を同時に立ち上げるからだ。

暫定表は誰か一人の判断では作れない

文書の著者がWG議長へ早期作成を依頼する。議長は要件を満たすかを確認し、WGに早期作成を適切とする合意があるかを判断する。その後、エリアディレクターの承認を求める。ADは、レジストリが恒久化されない可能性などを考慮できる。承認後、議長がIANAへ作成を依頼する。

IANAは所定の場所にレジストリを置き、暫定であること、作成日、失効日を公開する。有効期間は作成から2年。期限が近づけば、IANAはWG議長とADに2年間の更新を希望するか尋ねる。最初の延長後にさらに更新する場合は、IESGの承認、必要性の理由、仕様の計画も要る。

延長されなければ、IANAはレジストリを閉じ、その状態を表示する。WG議長は期限前でも閉鎖を求められる。一方、有効期間内に設置文書がIESG審査へ進んだ場合、審査中は失効しない。安全上などの問題があれば、IANAがIESGへ手続停止を求める経路もある。

この設計は、暫定表を黙って恒久化する仕組みではない。問題は、公開日付だけでは、作成を認めた合意と判断、更新理由、審査中の停止、閉鎖命令まで読み取れないことである。

表が暫定でも、すべての行が同じ暫定状態とは限らない

設置草案には、将来の恒久レジストリで使う登録方針が書かれる。しかし、その方針は恒久化まで直接適用されない。暫定期間は、将来方針に対応する別の手続が入口になる。

将来がFirst Come First ServedまたはExpert Reviewで、登録ごとにRFCを要求しない場合、WG文書では担当議長が登録を承認する。草案は、この経路で承認された登録には更新が不要だとする。ADスポンサー文書ならスポンサーADが承認者になる。

将来の方針がIETF ReviewやStandards ActionのようにRFCを要求する場合、登録は関連する早期割当て改訂案に従う。レジストリ自体が恒久化されても、その登録を定義する文書が承認されるまでは、行の暫定表示が残る。Specification Requiredでは、Internet-Draftを恒久登録の仕様として認めるかどうかで、さらに経路が分かれる。

したがって、一つの暫定レジストリの中に、更新不要とされる議長承認行、独自の期限を持つ早期割当て、設置草案から初期投入された行が共存し得る。後に表が恒久化されても、特定の行だけ暫定のままという状態も起こる。表の期限と行の期限は別の情報である。

現行のRFC 7120との違いもここにある。RFC 7120は、すでに存在するレジストリからコードポイントを早期に割り当てる。新提案は、設置RFCがない段階でレジストリ自体を運用可能にする。早める対象が一段上に移る。

草案の方針変更をIANAが自動で発見するわけではない

運用開始後も設置草案は更新される。将来方針がExpert ReviewからIETF Reviewへ変われば、暫定期間に使う登録手続も変わる。草案はIANAへの通知を求める一方、IANAはレジストリを作る文書の変更を追跡しないと明記する。

この線引きはIANAの役割を守る。IANAはIETFから受けた方針を実行するレジストリ運用者であり、草案差分から新しい政策を推測する主体ではない。変更を精査し、内容や構造の修正が必要か判断する責任は著者とWG議長に残る。

ただし通知の証拠が弱ければ、運用表だけが更新され、理由と適用範囲が失われる。通知には草案の版とハッシュ、旧方針と新方針、決定者、発効時刻、影響する行を結び付ける必要がある。後から値だけを見ても、どの入口を通ったかが分からない状態を避けるためだ。

現在値ではなく遷移を公開する

必要なのは、レジストリと登録行を分けた台帳である。

レジストリ側には、固定識別子、所属グループ、設置草案の名称・版・ハッシュ、WG合意記録、議長判断、AD承認、依頼日、作成日、現在の失効日、予定する恒久方針、現行の暫定手続を残す。構造や方針が変わるたびに、新しいイベントとして追加する。更新、IESG審査による時計停止、IANAの停止要請、閉鎖、恒久化も上書きせず履歴化する。

行側には、値、意味、参照文書、変更管理者、実際の承認経路、適用された方針版、暫定・失効などの状態を置く。別の草案に依存するなら、その依存関係と行固有の条件を示す。表の閉鎖または恒久化時には、各行について変わった点と変わらない点を記録する。

議論の全文や個人情報を公開する必要はない。職務、決定参照、文書ハッシュ、時刻、結論だけで、IANAがどの指示を実行したかは検証できる。

登録は技術の最終承認ではない

早期レジストリは衝突を減らすための共通座標である。WG議長による行の承認が、関連技術への最終的なIETF合意を意味するわけではない。ラストコールもIESGの決定ではない。IANA行は製品認証でも、運用者への導入命令でもない。

閉鎖についても同じ慎重さが要る。第02版は、延長されない表を閉じて表示すると定めるが、全行を直ちに削除、無効化、再利用可能にするとは書いていない。行ごとの根拠がなければ、その効果を推測してはならない。

今回確認した公開資料には、この手続で作成済みのレジストリ、依存する実装、悪用事例はない。状態遷移台帳は事故後の追認ではなく、最初の使用前に必要な設計である。値が実装へ移るなら、その値を正当化した暫定状態も追跡できなければならない。

情報源