1998/03/19 運営委員会 資料 3-3 データベース管理検討部会報告 [データベース作業報告] 2月28日〜3月1日 ドメイン情報の新フォームへの対応 - バックアップ - Sybaseのテーブル変更 - 検索・更新プログラムの入れ換え - 状態レコードの変換 - 入力プログラムの入れ換え [会議記録] 3月11日(水) 13:30〜15:00 JPNIC事務局 A会議室 CA関係打ち合せ会議 3月11日(水) 15:00〜19:00 JPNIC事務局 A会議室 検討部会 [主な検討事項] ■認証局に関する検討 ・認証局の立ち上げに関するスケジュールの確認 第0段階 (3月中) 仕様確定 - 3/20午前10:00 に CA 関係者が集まり最終仕様を作成 第1段階 (4月から5月) 事務局内部での利用 - 鍵発行システムを作る - 鍵発行手順を定める - JPNIC 関係者に鍵を発行する 実際に (内部的に) 運用を行なう - メイリングリストへの投稿制限等から始める 最初から DB に適用するのは難しいと思われる - 事務局内部用の Web サーバ/クライアントを作り実験する 第2段階 (6月から7月) 外部への拡大(第一ステージ) - 第1段階の結果を見ながら提供範囲を決定 ・クライアントソフトウェアの開発 - 電子メールへの適用(含むPGPでの認証) - whois クライアントへの適用 - Webクライアントへの適用 ・全ての JPNIC ハンドル所持者に対して鍵を発行する - 現状ではむしろここからはじめるべき - 全登録者に対して発行するとケアが大変 ■DB 使用基準 (個人ドメイン名設計の際に抽出した氏名/電子メイル一覧) - 基準作りが必要。内部も外部も同じ基準でなければならない。 - 原理原則は同一だが、運用条件は内外で異なる。 - 運用については歯止めが必要。 [原理原則:ネットワーク運用/インターネットの健全な発展] - ロンドン大学の件で合意した基準 (1) JPNICの目的に合致している。 (2) IPアドレスの利用者に個別の問い合わせは行かない。 (3) 結果に個別名が出ない。 (4) 結果がきちんと公表される。 (5) 成果物をJPNICにも出せる(利用できる)ようにする。 - whois データベースの位置づけについて (1) 調査のための基礎データ → 接続性、管理者、ドメイン名、権利関係等 (2) 運用に関する問題の把握 → Routing、DNS登録等 (3) JPNIC 業務の外部監査  → 公平な割り当て (4) JPNIC の業務補助    → in house データベースとしての役割 (5) 新しい情報提供空間のための基礎データ → ディレクトリサービス ↑5番目については疑問 - 以上の審議結果を元に使用基準を作成する - どのような使われ方は許されるか、あるいはどのような使い方をしたい  かを調査し、それを元にデータを集める時点からそれにたいして合意を  求めるようにすべき → 検討部会継続審議 ■ 個別審議 ○ DB の情報使用許諾 (ロンドン大学) □ 結論 -> 白橋さん (RESAERCH-WG) に確認 ○ 住所/電話番号非開示請求 (co.jpのドメイン情報に登録されている住所) □ 結論 -> 個人情報は連絡がとれる住所であれば良い旨を説明する -> ドメイン情報 (CO.JP) の住所は非開示にできない -> 以上 2 点を連絡する 主な意見 - ドメイン情報内の住所は割当の公平さ証明のため非開示にはできない - 会社組織の情報は whois 以外でも公開されているため非開示にする 意味がない 付帯事項 - 現在の『個人情報』という言い方は誤解を与える。『担当者情報』等に 改めるほうが良い。→検討部会で継続審議 ○ DB 不正使用 (営業連絡にJPNICデータベースを使用) - まず、問い合わせが JPNIC に寄せられた旨を先方に連絡する - 事務局の総務が担当する □ 次回までの宿題 -> これまでの事例も踏まえて対応手順を明文化する ○ 個人情報の住所に対する問題提起 (中山(db-wg外部メンバ)提案) - 郵便番号7桁化により住所レコードを null とすることが出来るのでは □ 結論 -> レコード設計の議論の中で扱うべき問題である → 次期設計に反映させるかと検討 ■その他 ○ データベース著作権 - データベースの著作権が認められたケースは皆無 - 専門家を交えた検討が必要 ○ whois の認証 - 形式的にせよ、検索時に使用許諾に同意を求める - 使用許諾条件を明確にする - whois の認証方法 → 検討部会継続審議 ○ 個人情報の電子メイルアドレスレコード 現在は1つしか登録できない。 実際に "," (カンマ) を使って無理矢理複数登録している人がいる。 (案1) RFC822 で定められたアドレスリストの記述を許す。 (案2) レコードを複数登録可能にする。(上限は 2 つまで?) □ 次回までの宿題 -> これらの案が可能かどうか結論を出す [今後の予定] ○ CA関係者打ち合せ 3月20日(金) 10:00〜 JPNIC事務局 A会議室 ○ 次回 DB-WGミーティング 4月20日前後?要調整