ICANNリスボン会合報告（第1回）

第28回ICANN会合が2007年3月26日から3月30日にかけて、ポルトガルのリスボンで開催されました。ICANNの発表によると今回の会合には81の国と地域から830名以上が参加し、様々な課題に関する活発な議論が行われました。

FROM JPRSでは今回のICANN会合の報告を3回に分けてお伝えすることとし、本号ではその第1回目として、GNSO（Generic Names Supporting Organization）におけるgTLDのWHOIS情報公開のあり方に関する議論、およびRegisterFly事件を受けたICANNの対応についてお伝えします。

gTLDのWHOIS情報公開のあり方に関する議論

gTLDのWHOIS情報公開のあり方については、GNSOの場で6年近くにわたり議論が重ねられてきました。これまでの議論では、ネットワーク運用上の問題解決やドメイン名に関する権利侵害の防止・解決のために登録者の連絡先を特定可能にしておく必要性と、個人情報保護の間でのバランスをいかにとるかという点が模索されてきました。

しかしながら上記の2つは互いに矛盾する側面をはらんでいます。このため、WHOISによる適切な情報提供と個人情報保護のバランスを取るべく、WHOISに関する問題を専門に扱うタスクフォースがGNSO内に設置されました。このタスクフォースでは、WHOISの目的を明確化したうえで、WHOISへのアクセス可否を変更すべきか、もしアクセスを限定する場合には、ドメイン名に関する連絡先に連絡を取りたい場合、それをどのように行えるようにするかについての検討を進めてきました。

今回の会合直前の2007年3月12日、GNSOのWHOISタスクフォースは、WHOISサービスに関する最終報告書をGNSOに提出しました。しかしこの最終報告書は、タスクフォースの場で賛成7、反対6という僅差で決議されたものであり、タスクフォースとしての統一的な提案としてまとめられたものではありませんでした。

こうした背景もあり、今回まとめられた最終報告書には、対立する2つの提案として「Operational Point of Contact（OPOC）」と「特殊事情（Special Circumstances）」が併記されています。

ここでは、今回特に集中的な議論が行われたOPOC案について、その概要と議論の内容についてお伝えします。

OPOC（Operational Point of Contact）

OPOC案の概要は以下の通りです。

• 登録者の住所をWHOISの公開情報項目から除外する
• 登録担当者（Administrative Contact）と、技術連絡担当者（Technical Contact）はレジストラ、レジストリいずれのレベルのWHOISにおいても公開しない
• .comおよび.netにおいては、レジストリは現状と同様の情報をレジストリWHOISで公開する
• レジストラWHOISにおいて新たに「Operational Point of Contact（OPOC）」という項目を設け、公開する
• レジストラは、登録されたOPOC情報が最新のものでないと思われる場合、それを検証しなければならないものとする

この提案を策定する過程で、また、今回のICANN会合においても、反フィッシング団体、警察等の法執行機関、知的財産権の関係者、ISP等から、OPOCのような代理の連絡先ではなく、登録者本人の連絡先へ確実にアクセスできる必要性が訴えられました。

また、OPOCの役割および責任が不明確であるという指摘も、企業の知的財産権の関係者等から出ました。OPOCによって登録者の連絡先がWHOISで割り出せなくなるうえ、OPOCの位置づけの不明確さからドメイン名登録の責任の所在が曖昧となり、従ってフィッシングやドメイン名紛争への対策が阻害されるという指摘です。

こうしたコメントを受け、GNSOとしては、今回のGNSO Council会合で関係するあらゆる利害関係者とさらに議論を深め、内容を検討していく必要があることを認識することとなりました。

新ワーキンググループの創設へ

今回の最終報告書提出で、WHOISタスクフォースはその役割を終えました。GNSO Councilはこの問題に関する検討を進めるべく、新たに「GNSO workinggroup of affected stakeholders（影響される利害関係者に関するワーキンググループ）」を発足させました。

このワーキンググループには、GNSOのメンバー、および警察をはじめとする法執行機関の関係者等の関心あるメンバーが参加できます。検討期間は120日間に限定されており、この期間中にWHOISタスクフォースが提案したポリシー案によって生じる課題を検討し、ポリシーの改善に関してGNSO Councilに勧告を出すことになっています。このワーキンググループの検討課題は以下の通りです。

• OPOCの役割、責任および要件
• 上記の責任および要件が満たされなかった場合にどうするか
• 正当な権利を持つ主体が、どのようにしてWHOISで公開されなくなった登録情報にアクセスできるものとするか
• 登録者の性質またはそのドメイン名の用途によって、公開される登録者情報に何らかの区別を設けるべきか

WHOISによる情報公開とプライバシーに関する問題はインターネットにおいて長年に渡って議論されているものであり、今後ICANNの場でどのような方針が打ち出されるかは、gTLDのみならず、ccTLDにおいても大きな影響を及ぼすものと予想されます。今後の動きに注目しておくべきでしょう。

なお、参考までに、OPOCに似たものとして汎用JPドメイン名の公開連絡窓口情報をあげることができます。汎用JPドメイン名のWHOISでは登録者の住所等は非公開としており、登録者への連絡が可能な窓口として公開連絡窓口情報を提供しています。OPOCの議論の中で、登録者本人に確実に連絡できる必要性が要求されていますが、JPドメイン名ではWhoisとは別に書面による情報開示手続を用意することでこのような要求に応じています。

RegisterFly事件を受けたICANNの対応

RegisterFlyという米国の企業が、2007年3月末でレジストラ契約を終了することとなりました。英国の著名ITニュースサイト「The Register」の記事（*1）によれば、RegisterFlyは90万ユーザの約200万ドメイン名を取り扱っていたとのことで、ここ数ヶ月の間、関係者の間でドメイン名に関する大きな事件として取りざたされてきました。

今回のICANN会合でもRegisterFly事件の問題は主要議題の一つとして取り上げられ、問題点の認識と現在のレジストリ‐レジストラ間の契約の枠組み改善に向けた議論が行われました。



なお、ICANN会合後、RegisterFlyはICANNに対して法的訴えを起こしたため、レジストリ契約の解約日が最低30日延長された模様です。

事実関係

RegisterFly事件の事実関係は以下の通りです。

• RegisterFly経営者同士の対立が同社サービスに悪影響。ドメイン名の更新に失敗する事例多発。顧客の苦情がRegisterFlyの顧客サポートを圧迫、さらに事態が悪化。
• ICANNは2006年6月から関係者との面談等により是正を試みていたが、状況は改善せず
• RegisterFlyの経営者が共同経営者を提訴。
• 提訴を受け、ICANNは専任職員2名による強制介入を開始。同社オフィスに出向いて登録情報の監査およびコピー、訴訟および認定取消しの警告、レジストリおよび登録者との調整を始めた。また、事実関係の公表に踏み切った。

今回の事件の問題点として、会合の場で以下が指摘されました。

• 訴訟により、RegisterFlyの最終責任者が不明になった。これが登録情報の引き渡しを難しくした。
• RegisterFlyは、レジストラ契約の条件を盾にICANNへのデータ引渡しを再三にわたり拒否。
• また、相前後して発生したRegisterFlyのシステム上の問題により、顧客がレジストラを変更することができなくなった。
• RegisterFlyが提供していたプロキシ（代理）登録の利用顧客については、RegisterFlyがサービス停止状態になると共に顧客データの回復ができなくなった。
• RegisterFlyのレジストラ認定の経緯に問題がある。RegisterFlyは2004年末頃にICANNがレジストラ認定したTop Class Names, Inc.が2ヶ月後に買収され、経営者が入れ替わったもの。これは非認定企業が認定レジストラを買収する「裏口認定（back-door accreditation）」の典型的な事例。

レジストラの枠組み改善に向けた課題

ICANNが3月26日付で公開したFact Sheet（事実関係を報告としてまとめたもの、関連URIを参照）においていくつかの課題が挙げられ、さらに3月30日の理事会で長時間にわたり議論されました。以下にその一部をご紹介します。

理事会では、今後GNSOレジストラ部会のチームとICANNスタッフで検討、さらに次回開催のICANNサンフアン会合の理事会にて議論し、レジストラ契約の改正やエスクロー（*2）の強化等、再発防止に向けた活動を行うこととなりました。

• 登録者の保護を強化すべく、認定ポリシーと認定契約の目的の見直し
• レジストラ破綻に迅速に対応するための、コンプライアンスツールの追加や開発の検討
• 登録者のレジストラ変更の円滑化に向けたポリシーの改善
• レジストラのスキルテスト、訓練の枠組み作り
• 裏口認定の防止策の検討
• リセラーの責任を保証させる仕組み作り
• レジストラのデータエスクロー（どのデータを対象とすべきか）の再定義

次回は、ccNSO（Country Code Names Supporting Organization）における話題と、IDNに関する動向についてお伝えします。




本会議報告は、JPRSのメールマガジン「FROM JPRS」の増刊号として発行した情報に写真などを交えてWebページ化したものです。
「FROM JPRS」にご登録いただいた皆さまには、いち早く情報をお届けしております。ぜひご登録ください。