1998/07/13 運営委員会
                                                         資料 3-3
		データベース管理検討部会報告


[データベース作業報告]

WWWによる鍵発行実験の開始

[会議記録]

6月23日（火）	15:00-18;45 ca-tf Meeting
7月 1日（水）	15:00-17:00 JPNIC事務連絡担当者会議
7月 8日（水）	15:00-21:00 データベース管理検討部会
               (18:00-20:30 dbpi-tf Meeting)

[主な検討事項]

---------------------------------------------------------------------------
ca-tf での検討事項

■　CA 証明書発行サーバの現状報告

  CA 証明書発行実験サーバによる鍵発行実験
    - サーバのセットアップは終了
    - Firewall 外部からの検証が残っている
    - JPNIC CA 評価用ドキュメントを作成した
    - ca-tf メンバーにて実際に鍵を発行する実験を継続中
    - どのような項目について実験するかを検討中

■　DBの登録に関する業務分析、および実際の業務への適用の考察

  各種申請メールの「流れ図」を作成する

  「個人情報を新規登録する」案の検討
    - 現在のデータを何とかすることはあきらめて、すべて新規登録する
      * 既にハンドルを持っている人も、認証機構の導入と同時にすべて再登録
　　　　してもらう

  JPNIC DB の必須情報の検討
    - 「ネットワーク管理上必要な情報を収集し、公開できる形にしておく」
      * International NIC が求められている機能(国際的な合意)
    - すべての情報が「ネットワーク管理上必要」であるかどうかは未検証
    - 現状では、ネットワーク管理上必要な情報と、必ずしも公開する必然性が
      ないものが混在している
    - どのレコードが必須になっているのか、どのレコードがどのタイミングで
      書き換わるのかといった情報がまとまっていない
    - これらがまとまらないと、メンテナオブジェクト等、さまざまな設計等を
      行う場合にも差し支える

■　運営委員会からの TODO

    申請フォームと同じ内容を持つフォームを生成する I/F を作成する
    - 現在の form の受け口とは、別の宛先にした方がよいのではないか
    - 「きれいな」メールと「きれいでない」メールを混ぜないほうが良い
    - CGI から、DB の「スプール」に直接通す

■　大手プロバイダ(例えば5大プロバイダ)での登録作業の実態調査の実施
    - 実際の認証局の運営のために実態を調査する必要あり
    - 会員の業務実態調査になるので慎重に行う
    - 守秘義務等が関係する可能性があるため、主査から事務局長に別途進
      め方等を相談する
    - 場合によっては JPNIC が直接調査せず、外部に調査を業務委託する
      可能性も模索する必要ありか

■　事務局担当者会議での説明内容について

　7月1日の事務連絡担当者会議において認証問題についての話を行う

■　メンテナオブジェクトを含むDBシステムの設計

  業務分析が終了した時点で行う

---------------------------------------------------------------------------
db-wg での検討事項

■ データベースに関する業務フローの検討

　問題点
  - 認証問題：申請者の認証はしていない。作業者の認証はメイルヘッダを見て
　　行なっている。
  - アクセスコントロール：メールのFromに応じてアクセス権限をコントロール
　　している。
  - 障害からの回復：システマティックに再現する仕組みは実装されていない。
　　過去には「手作業」で申請メイルから登録情報を再現させたことが度々ある。
  - 排他制御：全く排他制御は行なっていない。このため、同一情報に対し複数
    申請者が異なる内容を同時に申請した場合、先に登録された内容は上書きさ
    れて無効になってしまうような問題が発生を未然に防止できない。
  - 業務用インハウスデータベース：現在は、対外用 whois データベースと完全
    に一体化されているため、業務用データベースを分離したくてもできない。

  検討事項
　- 安全性：データベースの安全性を確保するための方策の検討→認証局の導入
　　に併せてデータベースの登録・更新の方法を変更する。
  - 省力化：情報の管理責任を業務委任会員などに移し、登録内容の正当性確認
    については先方にまかせることができれば、更新を自動化できる。また、認
　　証を導入した会員からの申請については更新を自動化できる。


■ データベースに関する業務分析の検討

　公開文書の更新
  - 現在の内容は、明らかに古いものになっている。
  - すぐに whois 公開目的をドキュメントに盛り込むのは困難な部分はURL
　　を参照するようにして、変更があった場合にも随時対応可能にする。

　- 結論：公開文書の変更案を運営委員会にて審議する

　個人情報のエクスパイア問題
   - [個人情報] 中に sticky flag のようなものを設ける
   - 現在は「必ず参照されるもの」という前提がある。
   - どこから参照されているか機械的に識別できる情報を埋め込む

   - 結論：継続審議	

■ 事務連絡者担当者会議の報告

  質問はメンテナーオブジェクトよりも "y. [通知アドレス]" 問題に集中した。

  会議の際に行なった背景説明
  - 主査からは、抽象的な説明にとどめ、具体的な説明は避けた。質問が集中した
    ため、会議の最後に東田事務局長から実際にあったということを匂わすニュア
    ンスの説明をした。

  代用通知先決定のアルゴリズム
  - JPNIC からは、登録担当者を優先する提案を行なった。
  - これに対し、技術連絡担当者を優先して欲しいとの要望があった。

  - 結論：アルゴリズム：提案通り登録担当者を優先する。
　　　　　先方への説明："y. [通知アドレス]" を適切に登録してもらう。
  - 宿題： 7/15 から、ほぼ提案通り(※)の内容で施行するとして通知する
	※ 処理結果の通知については差分と変更後の内容を返すことにする。
	※ [個人情報] から代用する際には"y. [通知アドレス]"を優先する。
	→ システムを↑に対応/修正する

  - 派生議題：
    * "y. [通知アドレス]" 削除を許すか？
      ・原則としては受けないことにし、どうしてもといわれたら個別審議する？
      ・いっそのこと、新レコードを設けてそちらを登録してもらうようにする？
      → 継続審議
　　* DOM/IP/DB の申請書式の整合性
      ・DB, IP には "y. [通知アドレス]" レコードが存在するが、DOM の申請書
        式にはない。申請書式の変更には周知期間として 3 ヶ月必要。
      → DOM/IP/DB 合同で調整する必要がある。


■ プロバイダ実地調査の計画

  プロバイダ関係者（規模にはとらわれない）の方に打診し、可能性を検討する。
　　→　林副主査にとりまとめを一任

■ セカンダリネームサーバ問題

  設置場所や帯域、海外到達性その他全てをまとめてハウジングサービスを利
  用するという方法もある。
  → それしかないのでは、という意見多数

  その他の意見：
　- NSPIXP3 にも打診する？
　- 設置数は？
　- .JP のセカンダリを海外に置く？
	  → 以前検討したことはある。
　- JPNIC 会員に募集する？
　→ 継続審議

■ 技術連絡担当者電子メイルアドレス未登録問題

  - 公開文書には、必須と明記している。
  - 大手会員に対して個別にお願いしていくという方法もある。
  - 取り組むには時間をかける必要がある。
  → 継続審議

---------------------------------------------------------------------------
dbpi-tf での検討事項

■ 個人情報問題についてのJPNICの公式見解

  - 先方にはこの回答で終りにしようとしていると思われてしまうかもしれな
    いが、これでいきたい。
  - 回答文の著者を dbpi-tf として、JPNIC は個人情報問題について考えてい
    ることをアピールする。
  - 公開目的を説明する部分は「あくまでも現時点の」ということを強調すべき。
  - 過去の不正使用の事例を逐一書くのは行き過ぎではないか。事情通にはそれ
    ぞれ具体的にどの事例か分かってしまう。「これこれの期間に何件あってい
    ずれも適切に対処した」的な記述がよいのでは。

  - 結論：運営委員会にて審議

■ domain-list.txt と DNSのゾーン転送問題

　以前行なわれた議論：
  - 以下の目的のためにも公開は必要である、とした。
    * ネットワーク運用目的：
 	 申請時に希望ドメイン名は存在するかを調べたい
    * 研究目的：
	  (学術的に)ドメイン名の統計などをとるときに利用したい

  今後どうすべきかの議論：
  - 現在はデメリットの方が大きい、と考えられる。
  - プライバシー情報保護とも関連する。保護のためには使用を禁止すべき。
  - 完全に禁止することは可能か？ 難しいのでは？
    → 条件付けと理論武装が必要。

  - 結論：domain-list.txt を原則公開から「許可した人にのみ公開」へ変更す
　　ることの提案文を作成し運営委員会に提案する。

■ 個人情報問題 (個別審議)

  ３件。いずれも理由不明確につき相手側に確認する。

■ 個人情報問題 (非開示請求の対応手順)

　- 既登録情報への非開示請求に対する手順：
	(1) 事由が明らかでない場合、事務局から問い合わせる。
	(2) 明らかになった時点で↓の作業を行なう。
	  (2-a) DB-WG に審議依頼を行なう。
	  (2-b) 先方に、DB-WG で審議しその間の暫定措置として一時的に非
		開示とする旨を連絡。
	  (2-c) JPNIC データベースから一時的に隠す。
	(3) 審議結果を先方に連絡した上で、然るべき作業を行なう。
　- 新規ドメイン名登録申請などと同時に非開示請求があった場合の手順：
	DOM/IP から DB に上げて、DB が可否を考え、理事会で承認する。
　- 手順を文書にする。（前書きと後書きは、佐野さんが書く）
    * JPNIC 内部で手順を調整する。
    * 過去の事例を蓄積する仕組みを作り、事務局で判断できるものは事務
      局内で判断する。
    * 8月の運営委員会までに手順案を文書にまとめて出す。

---------------------------------------------------------------------------

[次回予定]

ca-tf Meeting

7月24日(金) 10:00～12:00 JPNIC 会議室A

データベース管理検討部会

8月31(月) 15:00～17:00  JPNIC 事務局会議室A