要約

  • 2015年、Alain Durandは5年分のIANA利用統計を、ドメイン名、番号資源、プロトコルパラメーターの三つに分けて示した。
  • 新gTLDの導入後には委任の申請が増え、番号資源の申請は概ね横ばいだった。プロトコルパラメーターではPENの件数が特に多く、他の系列を読めるよう別に描かれた。
  • 申請件数は活動の量を示す一方、処理の難しさ、所要時間、正確さ、誤りの影響や、ルールを決める権限を単独では測れない。

利用者の視点から運用の範囲を知る

Alain Durandが2015年5月27日に公開した記事は、本人の経験の境界から始まる。彼は20年以上IETFに関わり、ワーキンググループの議長を務め、RFCの作成にも参加していた。技術コミュニティの一員としてIANA登録簿を使ってきたが、ICANNに加わった後、登録簿の利用経験だけでは内部の運用が見えていないと気づいた。彼の役割にはIANA監督権移管の支援も含まれていた。

そこでDurandは、入手できる5年間の利用統計をまとめた。これは独立監査でも、需要予測でも、将来の統治構造を提案する文書でもない。問いはより実務的だった。三つのコミュニティはどんなサービスを使い、申請の構成はどう変化したのか。機関を一語で表すと消えてしまう違いを、分類によって観察できるようにした。

記事によれば、IANA部門は三つの運用コミュニティ向けに2,800を超える登録簿を維持していた。対象はドメイン名、番号資源、IETFなどが使うプロトコルパラメーターである。この数は管理対象の幅を表し、同じ稼働率や負荷を持つ2,800のサービスを意味しない。変更頻度が低くても継続性が重要な登録簿はある。反対に、件数が多くても定型的な更新が中心の系列もあり得る。登録簿の数から人員やリスクを直接推定することはできない。

三つの業務には異なる規則と依存先がある。ドメイン名の処理には連絡先の更新も、委任・再委任も含まれる。番号資源の割り当てでは、地域インターネットレジストリやそのコミュニティが合意した方針が適用される。プロトコルパラメーターは対応する技術手続きに従う。同じ運用者が扱うからといって、一件当たりの判断、責任、失敗の影響が同じになるわけではない。

三つの系列が示したこと

ドメイン名の系列では、DurandはccTLDとgTLDの委任・再委任を、担当者情報、ネームサーバー、DSレコードなどの変更から分けた。新gTLDが導入された後、gTLD委任・再委任の申請が増えた様子が見える。制度やプログラムの変化が運用サービスへの需要に反映された例だが、そのプログラムをIANAが作ったことや、件数が社会的価値を表すことを示すものではない。

番号資源の系列では、2010年以前に大規模なIPv6ユニキャストブロックの申請があった。IANAの未割り当てIPv4ユニキャストアドレスプールは2011年に枯渇し、その後、返却された少数のブロックが世界共通の方針に基づきRIRへ再配分された。こうした背景があっても、5年間のグラフ上でIANAに届いた番号資源の申請は概ね安定していた。これは運用者への申請を示すもので、インターネット全体のアドレス利用、通信量、IPv4不足の程度を表すものではない。

IANAが扱う登録簿の多くは、IETFが定めるプロトコルパラメーターだった。なかでも利用が多かったのはPrivate Enterprise Number（PEN）で、主にSNMP MIBの設定に使われる。PENだけを他の項目と同じ軸に置くと、小さな系列が読み取りにくくなるため、Durandは別に描いた。見やすさを保つ判断であると同時に、分類や尺度を誰が選ぶかが読み手の理解を左右することも示している。

総合図では三コミュニティの系列を並べ、ccTLDとgTLDの委任には副軸を設けた。Durandは、新gTLDの影響を除けば全体の活動は予測可能で、番号資源の申請は横ばい、プロトコルパラメーターは2012年半ばの小休止後に増加したと読んだ。これは傾向の説明として有用だが、三系列を同じ単位に換算できることや、総件数を能力評価に使えることを証明しない。

件数が測らないもの

月間の申請数から分かるのは、一定期間に記録されたイベントの数である。個々の案件に必要だった検証ややり取り、運用者の作業時間、申請者からの回答待ち、修正後の記録への影響は分からない。処理が正確だったか、エラーがどのシステムに波及するか、誰が判断を再審査できるかも、このグラフだけでは判断できない。

同じ2015年5月の契約上の業績報告は、別の質問を測っていた。委任済みTLDの通常変更では、21日以内に80%を完了する目標に対し、実績は期限内86.1%、正確性100%だった。番号資源の指標は、方針の正確な実施、登録簿更新までの時間、確認の往復、完了時間、公開性などを別々に扱っていた。その月に完了した番号資源申請はなかった。利用件数とサービス水準は競合する数字ではなく、異なる側面の測定値である。

権限の所在も別の記録で確認できる。IETFの範囲にあるプロトコルパラメーターについて、RFC 2860はRFCに定められた基準と手続きを適用し、技術的な疑問がある場合はIANAがIESGの助言を求めるとしている。運用者の処理はルールの実施であり、件数自体がルールを作るわけではない。RFC 3901、3363、4472は、DurandがDNSやIPv6の運用課題に他の著者・編集者と取り組んだ記録でもある。これらを彼一人の著作とみなすことはできない。

2016年3月10日に公表されたICGの最終提案は、ドメイン名、番号、プロトコルパラメーターの政策と監督をそれぞれの運用コミュニティに位置づけた。同日、ICANN理事会が提案を承認した。確認した資料に、Durandの2015年分析がその構造を生んだ、あるいは決定したという記述はない。彼の貢献を正しく評価するには、共同で進められた移管と因果関係を混同しないことが必要だ。

地図の先にある問い

観察できる行動は明快である。Durandは利用者としての知識と運用を知る必要性の間にある差を認め、利用可能な5年分の統計をコミュニティと申請種別ごとに整理した。結果として「IANAの仕事」を一つの抽象概念として語る必要がなくなった。反面、元データの収集方法や内部の意思決定、各案件の工数、研究が予算や提案に与えた影響は、確認した資料からは分からない。

サービスを評価するには、何を一件と数えるのか、分類の定義を誰が変えるのか、どの方針が適用されるのかを問う必要がある。時計のうち運用者が制御できた時間はどれだけか。申請者や専門家の返答待ちはどう区別されたのか。結果は正確で、公開され、必要なら修正できたのか。異議を審査し、改善を求める権限を持つのはどの機関か。これらは件数とは分けて報告されるべきだ。

現在のIANA業績指標ページも、ドメイン名のSLA、番号資源、IETFパラメーター割り当て、ルートゾーン保守者の項目を別に掲載している。この構成がDurandの研究に由来するとは確認できない。ただ、サービスの約束や利用者が違うなら、指標も分けて読むべきだという点を示している。

件数が増えれば、能力、手続き、外部プログラムのどれが変わったのか調べるきっかけになる。それだけで方針変更を意味するわけではない。横ばいも低リスクの証明ではない。頻度は低くても、失敗時の影響が大きい申請には別の備えが要る。どの数字が意味を持つかは、組織がどんな判断をするかで決まる。

Durandの図表は、仕事がどこから来て、構成がどう動いたかを示す運用の地図である。地図は最初の議論を具体化するが、最多の申請を出す社群に余分な権限を与えず、サービス品質や監督の妥当性を単独で判定もしない。見えるようになった活動を、適用ルール、処理結果、是正できる機関につなげることが次の仕事になる。

参考資料