要約

  • Jari ArkkoとTed Hardieが共同執筆したRFC 8602は、TRIP AttributesとITAD番号の登録でIANAが郵便住所を集める必要をなくし、以前に集めた住所を該当登録簿から除いたと記す。文書は住所の用途を特定できず、除外にはプライバシー上の利点があるとする。
  • これは特定の登録簿に対する項目の規則である。全ての履歴コピーが消えたこと、TRIPの経路・対向接続・導入・認可・通話成功が存在することを示すものではない。公開項目は、現在どの登録行為を支えるのかを説明できなければならない。

表の列は、事実より先に読まれやすい

登録簿の読者は、値そのものより先に表の形から意味を読み取る。住所の列があれば、そこに表示される場所が連絡先として有効で、割当てと関係があり、今も保守されているのだろうと想像する。空欄であれば、データが欠けているのだろうと考える。だが、その推論は列の目的が今も生きている場合にしか成り立たない。

RFC 8602は、この種の見かけの権威を一項目ずつ点検した例である。TRIP AttributesとIP Telephony Administrative Domain、すなわちITAD番号の二つの登録手続について、郵便住所を連絡情報として求めないようIANAの規則を更新した。さらに、以前集めた郵便住所を登録簿から削除したと記録する。理由は限定されている。住所の使用目的が見いだされず、収集しないことにはプライバシーの利点がある。

ここから「登録簿は情報を少なくすべきだ」と一般化するのは早い。識別子、参照文書、適用方針、形式などは、同じ値を衝突させずに扱い、後から意味を調べるために必要になり得る。必要なのは削減のスローガンではない。各列について、登録のどの判断を支えるのかを言える状態である。

RFCが直したのはTRIPの動作ではない

RFC 3219はTRIPを、位置サーバ間で電話宛先の到達可能性と経路属性を広告する、方針駆動の管理ドメイン間プロトコルとして説明する。そこで扱われるのは経路、対向者、管理ドメイン、更新とメッセージである。RFC 8602はその経路選択やピアリング、通知を変えない。IANAが二つの登録簿で何を受け取るかを変える。

この区別を崩すと、登録簿に過大な発言をさせてしまう。ITAD番号が公開され、RFCへの参照が付いていても、特定の位置サーバが応答していること、対向者が認可されていること、宛先が現在使えること、通話が完了したことは分からない。同様に、対象登録簿から住所を除いたことは、私的なアーカイブ、古いダウンロード、検索索引、組織内データベースに残る全ての情報を制御した証拠ではない。

IANAのプロトコル登録簿索引は、TRIP ITAD番号についてRFC 3219とRFC 8602を示し、First Come First Servedの方針を掲げる。これは登録簿の系譜と手続を確認するための公開根拠である。TRIPの導入件数、稼働中の電話網、第三者の保管実務を表す計測ではない。

最小の共通表面を説明可能にする

RFC 8126は、登録簿を作成・変更する仕様に対し、名称、適用方針、必要情報、項目形式を明確に書くよう求める。IANAが実行すべき作業を理解できるようにするためである。プロトコルの技術説明を登録手続の表へ押し込むのではなく、IANA Considerationsは登録に必要な簡潔な指示面として置かれる。

この考え方を項目に当てはめると、六つの問いになる。誰が使うのか。どの判断を支えるのか。どこで公開されるのか。誰が訂正できるのか。いつ見直すのか。欠ければ何が壊れるのか。古い様式からコピーされたという答えは、いずれにも答えない。

Heng Luの最小初期仕様という考えは、ここで運用上の意味を持つ。共通の登録簿には、名前空間を協調させるための安定した最小面だけを置く。事業者が私的な連絡先、契約、障害対応簿を持つ必要はあり得る。それらには別の保管根拠、アクセス制御、訂正権限がある。公共表へ移しても、ローカルな情報がより正確になるわけではなく、閲覧と複製の面が広がるだけである。

削除は範囲を伴う記録である

「以前に集めた住所を除いた」という記述は、狭く読めば有用である。良い削除記録は、対象登録簿、対象項目、規則版、実行した変更、分かっている対象範囲、残した割当て識別子を結ぶ。後の読者は、それによって、方針に基づく削除と、画面だけでの非表示、偶発的な欠落を区別できる。

その記録を全世界の消去証明に変えてはならない。かつてのエクスポート、バックアップ、メール、別組織のファイルがどこにあるかをRFC 8602は列挙しない。しかし、この限界を明示することはプライバシーの主張を弱めない。検証できない全面消去を約束せず、登録簿自身が何を変えたかを検証可能にするからである。

将来の収集も同じ形で説明できる。項目台帳に用途、方針根拠、公開・制限の区別、スキーマ責任者、訂正窓口、削除条件を記せばよい。用途を監査可能にするために、値そのものを公表する必要はない。

貢献の署名と現在の権限を分ける

RFC EditorはRFC 8602の著者としてJari ArkkoとTed Hardieを記す。ArkkoのIETF Datatrackerプロフィールには、公開された職業経歴、IETFでの役割、RFC活動が載る。人物記事が記録できるのは、このような追跡可能な貢献である。

それはArkkoがTRIPを所有し、IANAを運営し、現在のネットワークを決めることを意味しない。RFCはIETFの記録であり、IANAは記載された方針の下で登録簿を保つ。事業者とデータ管理者は、自分たちの稼働状態と保管実務を別の証拠で示さなければならない。この更新の強さは、不要な要求を外しながら、文書だけで全ての複製や運用を支配したとは言わない点にある。

証拠の限界

出典は、過去にあった全住所、全履歴コピー、IANA外の保管規則を示さない。現在稼働するTRIP実装、活発なITAD、利用可能な経路、成功した通話も示さない。全ての登録簿に通用するプライバシー規則も定めない。

ここで提案する項目目的の記録は、文書の境界から得た限定的な運用上の推論である。公開項目を、それが支える登録行為へ戻して説明する。それはローカルな導入、認可、完全消去の証明の代わりにはならない。

Sources