要約

  • RFC 8126はIANA管理のプロトコル登録簿に十種類の登録ポリシーを定める。うちPrivate UseとExperimental Useについては、IANAは値を一切記録しない。
  • 異議申立て側の時計は固定されている。決定の公知から二か月以内に上訴を開始しなければならない。決定側の時計は固定されていない。「合理的な期間」であり統一的な期限はなく、予見可能性とは予定外の手順を踏まないことと定義され、日数での約束ではない。
  • IABはIESGの決定を取り消して元の状態に戻せるが、IESGの権限に属する決定は下せず、検討した条項が登録を命じる権限を明示しているわけでもない。そしてIESGこそが、判断を争われている専門家を任命し、自らの裁量で解任できる機関である。

原則からではなく、一通の申請から始めよう。誰かがIANA管理のプロトコル登録簿に値を書き込んでほしいと考えている。登録簿、フィールド名、適用されるポリシーは別物であり、IANA自身の指針がそれを明言している。2026年7月13日改訂と表示されたそのページは、同じ登録簿の中でも範囲ごとに登録手続が異なりうるため、登録簿の名前だけでは適用ルールを特定できないと述べる（IANA, Guidance for RFC Authors）。同じページは、正確な登録簿を特定し要求されるフィールド情報を提出するよう求め、登録簿の参照RFCが登録簿の表示には現れないフィールドを含むテンプレートを要求することがあると警告している。

誰が実際に決めるのかは、慣行ではなく文書が定める。2020年2月公表のIAB情報文書RFC 8722は、登録簿運営者の職務を、RFCで定義された基準と手続、および適用される登録簿ポリシーに従ってパラメータを登録することに置き、曖昧さは明確化のために照会すべきものとする（RFC 8722, §2.1）。同じ文書は技術的判断を運営者の肩から外す。「the Registry Operator will seek and follow technical guidance exclusively from the IESG」と述べ、技術的評価は一般に運営者の責任ではないとする（RFC 8722, §2.3）。登録簿運営組織の任命や終了はIETF LLCと協働するIABに属し、個々の専門家の任命とは別の行為である（RFC 8722, §2.2）。

ポリシーの一覧は十項目の閉じた集合である。2017年6月公表のRFC 8126は、Private Use、Experimental Use、Hierarchical Allocation、First Come First Served、Expert Review、Specification Required、RFC Required、IETF Review、Standards Action、IESG Approvalを列挙する（RFC 8126, §§4.1–4.10）。このうち二つは設計上、沈黙している。Private UseとExperimental Useの値はIANAがまったく記録しない。Specification RequiredはExpert Reviewに文書要件を加える。恒久的で公に取得可能、明確かつ技術的に妥当で、独立した相互運用を可能にするに足る仕様であり、RFCである必要はない（RFC 8126, §4.6）。

登録簿が公表された基準を持つなら、専門家はそれに従う。持たないなら、RFC 8126は文書の完全性、相互運用性、衝突の有無を評価し、説得力ある異議がない限り登録を推定すべきものとする（RFC 8126, §§5.1–5.3）。拒否には名指しされた根拠がある。資源の希少性、不明瞭な文書、有害なアーキテクチャ上または配備上の影響、IETFの作業との有害な衝突であり、それ以外は挙げられていない（RFC 8126, §5.3）。

次に時計である。1996年10月公表でいまも手続上の最後の拠り所であるRFC 2026は、こう書いてそのとおりに扱う。「All appeals must be initiated within two months of the public knowledge of the action or decision to be challenged」（RFC 2026, §6.5.4）。同じ節は決定者に手続を守ることを求め、合理的な期間内に決定し伝達することを課し、統一的な固定期限は与えていない。IANA登録簿の運用に関するIABの原則は、同じことを別の調子で述べる。予見可能な処理とは予定外の手順を避けることであり、専門家の決定が所定の日数内に下されることを保証することではない（RFC 8720, §3.1）。この二つの条項を並べて読むと、見かけ上の非対称が浮かび上がる。不服を持つ側は時間で測られ、筆を持つ側には数字が与えられていない。起草が意図的かどうかは、ここでは確認していない。

梯子は拒否が起きた場所から始まる。RFC 8126は登録決定への異議をまずIESGへ、次にIABへ導き、専門家チームを巻き込む争いにはRFC 2026 §6.5.1の紛争手続を適用する（RFC 8126, §10）。この取り込まれた手続は、ワーキンググループ議長、担当エリアディレクター、IESG全体、そしてIABへと進み、各機関は審査して解決を試みることを求められ、IABは手続遵守と技術的妥当性について最終である（RFC 2026, §6.5.1）。手続上の失敗が認められると、IESGは自らの行為を再検討してIETFに報告し、IABはIESGの決定を取り消して元の状態に戻すか、行為を勧告することができるが、IESGの権限に属する決定を下すことはできない（RFC 2026, §6.5.2）。

この最後の一節は、その長さが示す以上の重みを持つ。そしてここから引き出す結論は本稿の読みであり、どちらの文書も書いていない文である。検討した梯子で確認できる最も強い結果が、元の状態に戻す取消しであり、しかも頂点がIESGの権限に属する決定を下せないのなら、検討した条項は登録を命じる権限を明示してはいない。そこには勧告、取消しの後の再検討、あるいは事案ごとの別経路で後に登録に至る可能性が残る。取り消すことは命じることではない。申請者は論を制しても、上訴そのものが値を記録するわけではない。

もう一つ構造的な事実があり、これは机の上に留めておく価値がある。RFC 8126 §5.2.1は逐語的にこう述べる。「The IESG may remove any designated expert that it appointed, at its discretion」。同じ節は、IESGがIETF登録簿の専門家を任命し交代させ、通常はエリアディレクターの推薦による、と記す（RFC 8126, §5.2.1）。第10節は異議をまず同じ機関へ送る。どちらの文書も任命の役割と上訴の役割を調和させておらず、検討した条項に両者の分離は述べられていない。連鎖で最初に名指しされる機関段階は、その専門家を任命する機関である。第10節の経路は、IESG全体の前にワーキンググループ議長と担当エリアディレクターを通る。個別の上訴を誰が審理するのか、同じ人々が関与するのかは、ここでは確認していない。

他の条項は縁を和らげるが、形は変えない。IESGは例外的に登録手続を事案ごとに越えることができる（RFC 8126, §3.3）。専門家の審査に説明のない遅延が繰り返されれば、IANAはIESGへエスカレーションする義務を負い、IESGは状況を是正するか専門家を交代させるべきものとされる（RFC 8126, §5.3）。これは遅延に向けた救済であって、申請者が求める値に向けたものではない。透明性の原則は明示されている。「the recommendations by designated experts must be visible to the public to the maximum extent possible and subject to challenge or appeal」（RFC 8720, §3.3）。可視性は約束されている。決定日は約束されていない。

文書をめぐる記録は動いており、その動きは続いている。2026年3月のRFC 9907はRFC 8126を更新しRFC 8407を廃止した。権威ある登録簿の変更を、対応するIANA維持のYANGモジュールの保守に結びつける説明を求め、新しい値はモジュールに直接足すのではなく登録簿に置かれるべきものとする（RFC 9907）。正誤表は、コミュニティがすでに何を試したかを示している。技術的正誤表6522は2021年4月8日に却下された。特定のバージョンのInternet-Draftが§4.6の仕様要件を満たすと明示的に認めるものだったが、検証者はこれを誤りの訂正ではなく、コミュニティの議論と合意を要する政策提案として扱った。編集上の正誤表5772は2019年7月3日に文書更新のため保留とされ、謝辞の参照に関するものであってそれ以上ではない（RFC 8126 正誤表）。この却下が記録するのは、ある提案された文言が受け入れられなかったことである。どの登録簿の規則の下でもInternet-Draftが実際に受け入れられたことが一度もない、ということを示すものではない。§4.6の現行の文言も、Internet-Draftを許容される形式として挙げていない。

置換文書は存在するが、効力を持っていない。draft-ietf-ianabis-rfc8126bis-05は2026年11月2日に公表された。その概要はRFC 8126を廃止すると述べるが、文書自身のヘッダーはそれを承認にかからせており、状態はInternet-Draft、すなわち進行中の作業であると示している（draft-ietf-ianabis-rfc8126bis-05）。したがって本稿はRFC 8126を現行の文言として読み、置換は条件付きのものとして記録し、すでに成立した代替とはみなさない。

三つの限界は、文末ではなく該当する主張のそばに置く。実際の登録申請、拒否、上訴の提出、処分は一切検討していないため、以上の記述は公表された枠組みについてであり、特定の申請がどう扱われたかではない。どの登録簿にどのポリシーが拘束力を持つかは確定していない。一つの登録簿が複数の手続を抱えることがある。IESG内部の上訴処理、および公表されていない過去の上訴の記録は取得していない。

検索上の限界を一度だけ述べる。IANAの命名機能に関する文書群への調査は三度プロバイダ側で失敗し、その線は閉じた。命名機能契約、Customer Standing Committeeの憲章、Naming Function Reviewの報告書は本稿の調査では未読のままである。これは当デスクの取得の欠落であり、それらの文書についての結論ではない。

何がこの読みを変えるのか。上訴の処分が公表され、その結論がIESGではなくIABの指示で値を登録するものだった場合。あるいは、ある登録簿が自らの基準を書き下し、推定登録を検証可能な試験に変えた場合。そのどちらかが現れるまで、IANA登録簿の項目に依拠する人にとって正直な要約は、見た目より狭い。枠組みは基準を公表し、透明性の約束を公表し、時間割と最後の言葉を同じ少数の人々に委ねている。