要約

  • APNICの現行ポリシーはIRT連絡先に到達できるかを確認する。prop-171が問うのは別の点だ。資源を下流に渡した後、報告は登録窓口から調査可能な担当者まで届くのか。
  • APNIC 62では合意に至らず、提案はメーリングリストでの再検討に戻った。「信頼できる運用経路」の定義、転送を示す証拠、事務局が担う検証の範囲が未解決である。

メールが届いても、対応につながらないことがある

メールが配信され、受信確認まで返ってきても、受信者が対象ネットワークにアクセスできず、変更を求める権限も、下流の運用者へ連絡する経路も持っていない場合がある。登録情報では窓口は稼働中に見える。それでも運用上の責任連鎖は、対応できる人に届く前に止まっているかもしれない。

APNICのprop-171「Operational Accountability for Abuse Contacts in Sub-Allocated Address Space」は、この違いを出発点にしている。APNIC-127は各資源レコードにIncident Response Team（IRT）オブジェクトを求め、登録連絡先を定期的に検証する。検証メールへの応答はアドレスの到達性を示すが、報告が届いた後、該当する顧客、プレフィックス、ルーター、サービスを調べられる組織に渡ることまでは示さない。

資源の保有者がアドレス空間や接続サービスを別組織に提供すると、この差が現れる。上流の事業者が登録オブジェクトと集中型abuse窓口を管理し、下流の組織がネットワークそのものを動かすこともある。間に複数の事業者が入る場合もある。公開レジストリは入口として役立つが、入口の先にある運用境界までは説明しない。

提案者は、運用データによればAPNICが受ける一部のIRT連絡先不応答・機能不全の報告で、相当数がサブアロケーション空間に関係していると述べる。ただし提案本文には件数、分母、対象期間、抽出方法、独立検証可能なデータが示されていない。これは提案者の問題認識として帰属を明記すべき主張であり、地域全体やすべてのabuse報告の定量的な結論ではない。

提案が求めるものと、求めないもの

prop-171が示す原則は、下流組織が資源を使う場合、上流の保有者が登録済みabuse/IRT窓口から、その資源に関する報告を扱う当事者までの信頼できる運用経路を確保することだ。実装を一つに限定しない。下流運用者が窓口を運営しても、上流の中央窓口が顧客を特定して転送してもよい。正当な報告が不当な遅延なく担当者に届くなら、別の方法も成立し得る。

柔軟性には意味がある。ホスティング、卸売、企業ネットワーク、マネージドサービスは同じ体制ではない。また、下流顧客の連絡先をすべて公開する提案でもない。セキュリティチームを見つけられるようにしながら、個人のメールアドレスや内部のエスカレーション構造をインターネットへ公開しない設計は可能だ。

提案は既存の検証周期を変更せず、新しい監査・コンプライアンス制度も設けないとしている。APNICをabuseの調査機関にはせず、事務局にも新たな執行権限を与えない。だが、その境界を示しても実装の問題は残る。報告本文を読まず、事業者も監査しないなら、上流保有者は何をもって経路の信頼性を示せるのか。メールボックスから担当チームへの試験、エスカレーション記録、受領確認、責任分担の明示はいずれも候補になるが、費用、プライバシー、形式的な適合のリスクが異なる。連絡先フィールドだけでは次の引継ぎは見えない。

事務局の評価が示した定義の欠落

事務局の影響評価が指摘する中心課題は、Whoisの項目追加ではない。「信頼できる運用経路」の意味と、その定義・検証方法が不明確なことだ。提案はサブデリゲーションの最小単位も定めていない。大規模組織では小さなネットワーク区分ごとに運用者や窓口が異なり、同じアドレスに複数の窓口が対応する場合もある。義務を細分化するほど、上流保有者が何を維持すべきかを明確にする必要がある。

評価には二つの緊張関係もある。第一に、現行方針が既に対象とする運用形態がある。保有者は顧客別IRTを作れるし、自ら責任を負うなら自社IRTを使える。prop-125は下流窓口が無効または無応答のときも上流保有者に検証責任を残す。第二に、現在の規則は、有効な窓口に報告が届いた後の責任を明確にしていない。prop-171はその隙間に対処する一方、新たな執行期待を生むと解釈される可能性がある。提案自身が執行制度の新設を否定していても、この読み方は残る。

これは言葉の整理だけではない。APNICが報告を対応可能な運用者まで追跡するなら、レジストリは転送手順、下流責任、遅延苦情を評価するよう求められかねない。上流保有者だけが責任を負うなら、どの証拠を保管し、引継ぎ失敗にどう対応するかが必要になる。下流運用者が処理するなら、報告者に責任所在を伝えつつエスカレーション経路を保たなければならない。

APNIC 62のPolicy SIGは合意に至らず、prop-171をメーリングリストでの議論に戻した。これは採択でも、提起された懸念が誤りだとの判定でもない。個別の提案ページには現在も「APNIC62 OPMで議論」と残り、提案一覧には未合意・メーリングリストで再検討と掲載されている。この古い会議表示は記録の更新差であり、隠れた決定の証拠ではない。状態確認には会議結果報告と現行一覧を使うべきだ。

改訂案では、資源レコード上の保有者、影響を受けるネットワークの運用者、報告を受けて転送する者、引継ぎを示す証拠、という四点を分けると検証しやすい。「不当な遅延なく」という表現をどう適用するかも説明が要る。あらゆる事案に同じ応答時間を当てはめる必要はないが、検討できる手順は必要だ。

受信と解決は別の状態である。レジストリは連絡先を見つけやすくし、情報の有効性を保てる。しかし、報告の真偽や要求された措置の妥当性を判断したり、調査内容の開示範囲を決めたりはできない。引継ぎ確認は責任ある当事者への到達を示しつつ、APNICを事実認定機関にせず、顧客情報もさらさない形が望ましい。

APNIC-127には、監視対象の窓口と半年ごとの検証という基準が既にある。空のルールではない。prop-171は、その基準を運用上有効にする責任が、次の転送まで含むのかを問う。APNIC 62で合意がなかった以上、「連絡可能」と「責任を果たせる」はなお別々の主張だ。

参考資料

  • APNIC、prop-171ページと掲載状況。ページ
  • APNIC、prop-171 v001本文と事務局評価。本文
  • APNIC 62公式報告。報告
  • APNIC Blog、APNIC 62 Policy SIGの提案結果、2026年9月25日。記事
  • APNIC-127現行方針。方針
  • APNIC、prop-125記録。ページ
  • APNIC、現行の方針提案一覧。一覧
  • APNIC、ポリシー策定プロセス。プロセス
  • Heng Lu Note 65「Running-Code Primacy」（編集上の視点のみ）。記事