要約

  • prop-167-v002 は、公開される時間別統計と、資源保有者が MyAPNIC で自分の資源への照会を確認する機能という二つの出力を求めた。
  • Resolution 2025-32 は公開統計を endorse した一方、MyAPNIC 機能については費用、人員・資源、潜在的な privacy concerns が当面の便益を上回るため、その時点では feasible ではないとした。
  • 公開側は実装を確認できる。2026年6月30日から時間別ファイルが残り、現在の JSON には RDAP と WHOIS の別々の集計がある。
  • 提案全体を Implemented とするだけでは、EC が設けた範囲を保存できない。必要なのは権限争いではなく、出力ごとの決定と実装物の対応である。

まず完成した側を見るべきだ。APNIC の 公開ディレクトリ には whois-rdap-stats.json、checksum、年別アーカイブが並ぶ。2026年6月のディレクトリでは、6月30日の03:00から23:00までの圧縮ファイルを確認できる。現在の JSON は RDAP と WHOIS を分け、一時間の期間、総照会数、ASN 数、query type、ASN ごとの照会数と distinct source IP count を持つ。

これは「透明性を高めたい」という抽象的な宣言ではない。運用中のデータ面である。APNIC の 提案ページ も、同じ6月30日を Implementation Complete と記録し、現状を Implemented と表示している。

それでも、prop-167-v002 の履歴は一行ではない。

提案に書かれた出力 2025年12月4日の EC 判断 2026年8月に確認できるもの
WHOIS/RDAP の公開・時間別・machine-readable 統計 Resolution 2025-32 が endorse 現行 JSON と6月30日以降の時間別アーカイブ
資源保有者向けの MyAPNIC 資源別照会表示 費用、resourcing、潜在的 privacy concerns を理由に、その時点では feasible ではない 後続決定または実装を示す公開証拠は確認できない

上の行は実装済みである。下の行は、沈黙から推測した「失敗」ではなく、公開決議が与えた時点付きの状態である。二つを一語に圧縮したとき、何が消えるのかが本稿の対象になる。

v002 が作った二種類の可視性

prop-167-v002 は2025年8月21日に公開された。提案は、4月1日から6月30日までに APNIC が約55億件の directory query に応答し、時間帯によっては RDAP だけで36万5千を超える unique IP address から照会を受けたと述べる。根拠は提案が参照する APNIC 内部データであり、本稿が再計算した数値ではない。

この規模から提案が導いたのは、利用者への断罪ではなく観測可能性だった。公開統計は一時間ごとに更新し、JSON または CSV で提供する。WHOIS と RDAP を区別し、少なくとも上位1000の source ASN、ASN ごとの source IP count、query type と method を含める設計だった。

v002 で加わった MyAPNIC の機能は性質が違う。資源保有者がログインし、自分に割り当てられた IP address や ASN が何回照会されたかを見る。query type と、可能なら source ASN でも分ける。公開集計に列を足すだけではなく、account、resource holding、query record の関係を認証された面で扱うことになる。

impact assessment も差を認識していた。公開側には抽出と公開の仕組みが必要で、データは best-effort、SLA なしとされた。MyAPNIC 側については、可能であれば underlying WHOIS systems に大規模な logging work が必要だとした。提案本文も公開系統と portal extension を別々の作業として挙げている。

APNIC 60 で v002 は2025年9月11日に consensus に達し、10月14日に final comment が終了した。ここまでの community state は二つの出力を含む。しかし APNIC の PDP では、それが自動的に production scope になるわけではない。

Resolution 2025-32 は省略できない

APNIC の PDP は、維持された consensus の後に EC endorsement を置き、その後に Secretariat implementation を置く。したがって EC の判断を community text に対する無権限な修正とみなすことはできない。

Resolution 2025-32 は real-time または near-real-time の public directory-service statistics について prop-167-v002 の adoption を endorse した。そのうえで MyAPNIC の一文を明示的に取り上げ、cost、resourcing、potential privacy concerns が immediate benefit を上回るため、その機能を当時 feasible とは考えないと記録した。決議は全会一致だった。

この文章は範囲と時間を同時に制御する。with respect to は endorse した部分を区切る。三つの理由は EC が公表した理由であり、外部の推測で置き換えてはならない。at this time は判断日を残すが、再検討の約束も永久放棄も意味しない。

むしろ、二つの出力を分けたことは慎重な制度判断だった。公開集計と、認証された資源保有者向けの細粒度表示では、実装負荷も privacy boundary も異なる。その差を後の status page が保存できなければ、決議文の慎重さだけが失われる。

稼働するファイルは第一の結論を閉じる

APNIC 61 の update は prop-167 を In Implementation とし、Q2末までを見込んでいた。説明された成果は、WHOIS/RDAP 利用状況を machine-readable format で公開することだった。現在の Product Roadmap data も、endorsed policy proposal の要件を実装する作業として記録する。

計画より強いのは実ファイルである。6月30日の archive は completion date と production output を接続する。現行 JSON は両 protocol の区分と時間窓を示し、照会分布を構造化している。読者は APNIC の自己評価だけでなく、配布された bytes を確認できる。

ただし、そのことから完全性までは証明できない。すべての時間に欠損がなかったとは限らず、現在の sample だけで全 field の履歴を検証することもできない。best-effort の surface を SLA に読み替えてはならない。2026年の file は2025年の55億件を独立に再現するものでもない。

それでも、public output が存在するという結論には十分である。新しい記事が「実装物が見つからない」と書けば、最も強い証拠を無視することになる。

一つの proposal status が持てない情報

canonical page は v002 を link し、MyAPNIC requirement を含む impact assessment を載せ、12月4日に EC が endorse したと書く。そして6月30日の Implementation Complete と一つの Implemented status を示す。

この status が endorsed scope の完了を意味するなら、事実と整合する。だが reader が community text のすべてを production 済みと理解した場合、同じページには誤読を解く行がない。Resolution 2025-32 と FTP の所在を自分で結び直す必要がある。

問題は proposal が一つで output が複数という cardinality にある。proposal-level status は navigation に適している。だが、decision-level truth を保存する最小単位にはならない。複数の output がそれぞれ disposition を受けたなら、summary status はそれらから導出されるべきで、置き換えるべきではない。

MyAPNIC 行に Failed と書くのも不正確だ。permanently rejected ならなおさらである。公開記録に忠実なのは、2025-12-04: not endorsed / not feasible at that time とし、後続の reconsideration が public record にないことを別に示す形だ。

公開すべきなのは照会履歴ではなく対応関係

解決策は MyAPNIC の機能を今すぐ作ることではない。個々の source IP、resource holder の private view、内部 logging architecture を公表することでもない。そこには決議が認めた cost と privacy の論点がある。

必要なのは、すでに公開された decision chain の対応関係である。proposal page に output-level projection を付け、version、source passage、community state、EC resolution、disposition を一列ずつ結ぶ。endorse された row には artifact と schema を、されなかった row には時点付き reason class と後続決定の有無を置く。

保存する関係 後の読者が確認できること
version と fingerprint どの text が consensus と EC に入ったか
output ID と source passage proposal 全体を最小決定単位にしない
consensus と final-comment date community state と実装権限を混同しない
resolution と disposition 誰が何を advance させたか
artifact、format、first production time endorsement と実装結果をつなぐ
unendorsed output の dated state 当時の判断と永久判断を分ける
correction と supersession 新しい判断で過去を消さない
proposal status rule Implemented が何を要約するか

これは新しい PDP ではない。既存の PDP が生んだ record を、一つの public surface で追跡できるようにするだけである。詳細な engineering evidence は protected のままでもよい。

不明のまま残ること

APNIC がその後、MyAPNIC のより安価または privacy-preserving な案を検討したかは分からない。確認した資料には、資源別 query view を名指しする後続 EC resolution、roadmap item、release note はなかった。public evidence の不在は private work の不在を意味しない。

resource holder の実害、public feed による leak、SLA breach、security incident の証拠もない。proposal が挙げた data mining や bulk harvesting は可能性であり、特定の ASN や利用者への認定ではない。

APNIC が scoped endorsement の完了を慣行として proposal-level Implemented と表すのかも、確認した資料だけでは定義できない。その慣行が存在しても、二行の projection と矛盾しない。summary を残し、summary の根拠を見せればよい。

実装済みの feed は成功として記録されるべきだ。同時に、もう一つの output は、当時 feasible ではないと判断された事実として残るべきだ。二つを同じページに置くことは決議を争うことではない。決議が実際に引いた線を消さないことである。

出典