Summary

  • IANABIS 草案の10月26日版は、IETF ストリームの RFC を登録条件としない新規登録簿に Change Controller 欄を設けるよう IANA に指示する。既存の該当登録簿に欄がなければ、後日まず空欄を追加する案だ。文書はまだ Internet-Draft である。
  • 現行 RFC 8126 も変更管理者の明示を勧めていた。IANA の JSONPath 関数拡張登録簿では、審査専門家 Glyn Normington と、五つの項目の変更管理者 IETF が別々に記録されている。

作った人と直せる人

新しい割当てを受けるとき、関係者は番号の重複や仕様の整合性を調べる。しかし登録簿の寿命はその一回の審査より長い。数年後に説明文や参照先を直す依頼が届いたら、以前の執筆者に連絡できるとは限らない。連絡先が返事をしても、その人に承認権限があるとは限らない。審査の専門家と変更の管理者を同じ人物だと思い込むのも危うい。登録簿の一行に何を書くかだけでなく、その一行を書き換える鍵を誰が持つかが問われる。

現行 RFC 8126 は、IETF ストリームの RFC に由来する登録簿と登録項目の変更管理を、原則として IESG を通じた IETF に置く。IETF 外から登録を受ける仕組みには管理者を明示するよう勧め、新しい First Come First Served と Expert Review の登録簿には管理者欄を設けるべきだとする。したがって今回の草案は、存在しなかった役割を発明するものではない。既にある勧告を IANA の表作成作業へ踏み込ませる。

IANABIS 草案の -04 版 の第11.2節は、IETF ストリームの RFC を要求しない登録手続きを使う新しい登録簿すべてに欄を作るよう求める。First Come First Served、Expert Review、Specification Required、RFC Required を列挙している。第2.5節では、IETF ストリームの登録で通常記す名称は IESG ではなく IETF とする。IESG は IETF を代表して動くからだ。元の RFC が IESG を指定していれば、その例外を尊重する。書式上の細部に見えるが、組織の権限と、それを行使する機関を取り違えないための区別である。

空欄を埋める前に所有者を作らない

旧い表の扱いはさらに率直だ。草案は、該当する既存の登録簿に管理者欄がなければ、将来空の欄を追加すると書く。過去の著者や現在の専門家を自動的に管理者に指名しない。欠けている情報を見える場所に移すだけだ。対象となる表の数も、空欄に正当な名前を入れる期限も草案にはない。その二つが公表されれば、移行作業の規模を評価できる。

既に記入済みの例は IANA の JSONPath 登録簿 にある。Function Extensions の登録方法は Expert Review で、Glyn Normington が専門家として記載される。同じページで length、count、match、search、value の五行は Change Controller を IETF と記す。専門家が技術審査を担うことと、IETF が変更管理者であることは別の欄で読める。この既存の表は草案が実施済みである証拠ではなく、区別を公開できる実例である。

管理者自身の名前を変える場合も手続きが要る。草案第3.1.2節は、別の規定がなければ登録手続きを変更手続きにも使うとする。RFC によらない登録では IANA が連絡先や管理者情報の更新を確認・承認し、必要なら専門家やエリアディレクターに助言を求められる。欄が正しく埋まっていても、欄を書き換える権限が曖昧なら統制は完成しない。

RFC 8126 が現在の規範で、IANABIS 文書は作業部会の草案だ。今後の改訂、IESG での扱い、IANA の実際の表の更新を別々に追う必要がある。