要約

  • RFC 7120は、条件を満たすIETF作業に対し、通常ならRFC公開時に行われるコードポイント割り当てを前倒しできるようにした。IANAの行にはTemporary、初回登録日、通常1年後の期限が表示される。
  • その行が証明するのは、試験用の共通座標が手続きに従って確保されたことだけだ。設計の承認、最終合意、実装品質、普及、恒久性は別の証拠を要する。
  • 期限切れは消去ではない。更新、失効、非推奨化、再び未割り当てに戻す判断を分けることで、出荷済みパーサーとの衝突履歴を残す。

草案の数字を誰かが先に選んでしまう

プロトコルの長い説明は、通信路では小さな整数に圧縮される。メッセージ種別や拡張を示す値が一つ違えば、同じパケットを受け取った二つの実装は別の処理へ進む。IANAレジストリは、その整数語彙を共有するための台帳である。

ところが、実装は文書の完成を待たない。独立したコードを書かなければ、草案の曖昧さも運用上の欠陥も見つけにくい。正式な割り当てがまだなら、開発者は空いて見える値を仮に選び、テストや製品へ組み込むことがある。

RFC 7120は二つの失敗を描く。最終的に別の値が割り当てられれば、初期実装と標準準拠実装が通じない。仮に選んだ値が別の拡張へ正式配分されれば、同じ番号に異なるwire meaningが重なる。

表の空欄を埋めるだけの話ではない。整数はファームウェア、パケット解析器、設定例、テストベクトルに複製される。後のRFCは、それらを遠隔で書き換えられない。

「公開まで実装しない」では足りない

最も簡単な規則は、RFCになるまでコードを書かないことだ。Cottonの文書は、その整然さより実装経験の価値を選んだ。標準化には時間がかかり、複数実装や初期運用は、文面だけでは見えない状態遷移や互換性の問題を返す。ルーティング分野では、そうした経験が強く求められる場合もある。

したがって比較すべきなのは、早期実装の有無ではない。公開された同一番号で試すか、各社が別々に番号を推測するかである。早期割り当てはrunning codeの価値を認める一方、その存在を標準承認の代わりにはしない。

ここでTemporaryという表示が効く。番号だけがソースコードへ転記されると、期限と条件が落ち、暫定的な便宜が恒久的権利のように見え始める。

申請できる草案には条件がある

一般手続きはIETF Streamの文書に限られ、RFC化を予定するSpecification Required、RFC Required、IETF Review、Standards Actionの空間を対象とする。より開放的なレジストリには、それぞれ別の登録経路がある。

草案は、フォーマット、意味、処理規則を十分に記述していなければならない。さらに、前後の版で作られた実装が継ぎ目なく相互運用できる程度に安定している必要がある。ワーキンググループ議長とエリアディレクターは、RFC前の実装に十分な関心があるか、予約しなければ現場で値の競合が起きるかを判断する。

これはプロトコル全体の合格判定ではない。「限られた番号を今押さえる危険」と「実装者が勝手に選ぶ危険」のどちらが小さいかを問う審査だ。

意味がまだ非互換に変わるなら、共通番号は実験をまとめるより、古い解釈を広く残す装置になる。

一つの組織が全てを承認しない

著者は必要な値と草案を示して議長へ依頼する。議長は安定性と実装需要を確認し、グループの合意を測る。その後、エリアディレクターの承認を求める。小さな空間なら、枯渇の危険も判断材料になる。承認後に初めて、議長がIANAへ登録を依頼する。

IANAは適切な値を割り当て、Temporaryと初回日、期限を公開する。この処理が終わる前に草案へ具体値を書いてはいけない。台帳に載るまでは、他の申請へ渡らない保証がないからだ。

著者は意味を提案し、議長はグループの判断を束ね、エリアディレクターは制度上の危険を見て、IANAは状態を正確に記録する。実装者はどこまでコードを走らせるかを決める。IANAの行は技術的推薦ではなく、エリアディレクターの同意も最終規格の承認ではない。

Michelle Cottonの重要性は、この境界をレジストリ運用の側から明文化した点にある。個人が番号を選び、規格を決めたという物語ではない。むしろ、誰も全権を持たないように責任を分けた文書である。

一時行を承認印として読まない

一時行は、申請が定められた経路を通り、表示期間中は他の用途に渡さないことを示す。複数実装に同じ値を与え、後続申請者へ衝突を警告する。

その行は、草案がRFCになること、IESGが設計を認めたこと、セキュリティ検討が完了したこと、製品が相互運用することを示さない。レジストリは名前を調整する。動作を確認するのは試験である。

2026年9月8日時点のDNSKEY RR Flagsレジストリには、この状態の具体例があった。値14のAuthoritative Delegation Typesは、2026年7月20日に登録され、2027年7月20日に期限を迎える一時割り当てとして、進行中のDNSOP草案を参照していた。ここから分かるのは予約と期限だけであり、草案の結末や普及率ではない。

数字だけをコピーすれば、最も大切な列が失われる。参照文書、状態、期限まで含めて初めて、現在の意味が読める。

期限後にも記憶を残す

文書が通常の割り当て段階へ到達すれば、著者と議長は早期値の存在をIANAへ知らせる。互換性が保たれていれば、番号を変えず一時表示を外し、恒久状態へ移せる。

先に1年が過ぎれば、手続きを繰り返して通常一度の更新を申請できる。それを超える更新は例外で、IESGへ理由と計画を示す。更新は自動延長ではなく、新しい判断記録だ。

更新もRFC進展もなければ、行は期限切れとして残る。議長は非推奨化を求められる。非推奨値は有効な文書用途に割り当てられてはいないが、新しい用途にも配れない。完全に解放するかは、古い実装の可能性と残り空間を見て後から決める。

この中間状態が、パーサーの記憶を守る。すぐ消せば過去の利用を発見できず、すぐ再利用すれば新旧の意味が衝突する。「現在は使わないが、忘れてもいけない」という行が必要なのである。

既成事実化を防ぐブレーキ

RFC 7120は、早期割り当てがIETF手続きの抜け道になる危険を隠さない。後の審査に通らない提案でも、具体的番号を得れば承認済みに見せられる。申請が増えれば、狭い空間やIANAの作業も消費する。

エリアディレクターの同意、必要時のIESG全体への提起、IANAが手続き停止を求められる仕組みは、その既成事実化を抑える。running codeには証拠を作る場所を与えるが、running code自身に判決を書かせない。

出典