1996/05/24 運営委員会
							資料6-3-2
			DB WG Meeting Minute

日時: 1996年5月8日 10:00～18:00
場所: JPNIC事務局

出席者(順不同): 水越, 奥山, 高田, 平原, 石黒, 菊池, 藤長
		真鍋, 本村, 小島, 深野, 斉藤, 志々目

報告作成: 高田広章

１. DB WG の体制について

・正式な決定は次の運営委員会での決定を受けてになるが、DNS WG とマージ
する方向と、WG の体制 (chair, vice-chair, 外部メンバ) について確認を行っ
た。

・DNS WG とマージした場合、メイリングリストを次のように再構成する。
	dns-wg@nic.ad.jp	... db-wg とマージする
	apply@dns.nic.ad.jp	... なくす
	query@dns.nic.ad.jp	... query@db.nic.ad.jp とマージする
	info@dns.nic.ad.jp	... 残す
	staff@dns.nic.ad.jp	... bind-admin と同じにする
					(JPNIC の DNS の管理者)
	info@whois.nic.ad.jp	... whois の使い方を返送する

・WG で使っている学生アルバイトは、事務局ではなく、運営委員が管理を行
うことを確認した (事務局からは、運営委員に対して作業委託していると考え
たい)。また従来、アルバイトなのかボランティアなのか位置付けが明らかで
ないという問題があったが、今後はアルバイトという位置付けで扱うことにし
た。今年度該当するのは、中垣, 真鍋, 本村 の３名である。

２. whois の高速化について

・dbms-whois をある条件で使った場合の性能を、50倍程度向上させることが
できることが報告された。急いで、そのような改造を行うこととする。

・高速な whois サーバを構築するプラットフォームについて議論を行った。
リレーショナル DBMS の中では Sybase が良さそうなこと、オブジェクト指向 
DBMS は現状では性能が悪いこと、Sybase を用いてもソフトウェアをチューニ
ング (多くのインデックスを張るなど) することで 100万件程度までは十分に
扱えると思われることから、プラットフォームを変更する必要は指摘されなかっ
た。

・Sybase のソフトウェアのチューニングは外注可能であるという指摘があり、
外注する前提となる作業として、現在の whois の外部仕様 (検索条件など) 
を明確化する作業を急ぐことになった。さらに、現在の検索条件が妥当か、あ
まり使われていない検索条件はないかなどを、InterNIC の whois の仕様も参
考にしながら検討する。

・ハウジングサービスを借りるのを機会に、whoisサーバ専用機を新たに 1台
購入し、今の whoisサーバ機 (SONY NEWS) は開発用兼バックアップ機とする。
新たに購入するサーバ機は以下の条件を満たすものとしたい。

	- Sybase がマルチスレッドで動作するマシン/OS とする。
	  (i.e. Sun Solaris 2.X, HP, IBM)
	- マルチプロセッサタイプで、後でプロセッサを追加できる拡張性の
	  あるものが望ましい。
	- ディスクは、やはり RAID か。

３. データベース変更登録者の認証の問題について

・現在のデータベース変更登録者の認証方法は不十分で、何らかの認証機構の
導入が急がれる。また、認証機構の導入で、事務局の作業手数が減らせるとい
う効果もある。

・Routing Registry で採用されている認証の仕組みをサーベイ。Maintainer
Object という形で、変更登録できる権限と認証方法 (NON, MAIL-FROM,
PASSWORD, PGP) を登録する。PGP はサポートされているがあまり使われてお
らず、多く使われているのは MAIL-FROM。

・Maintainer Object に加えて notify (変更登録があった時の通知先) を登
録する仕組みもある。JPNIC DB でもこちらは早急に導入する。

・JPNIC でも、PEM (FJPEM) ないしは PGP の導入に向けて検討を開始する。
基本的な枠組みとしては、以下のような形を考える。
	- 認証情報 (公開鍵) は、個人情報に付ける
	- 各情報に変更登録権を示すレコードを追加する
		レコードには個人ハンドルまたは管理者ハンドルを記述する
	- 管理者ハンドルを primary key とする管理者情報を新設する
		NSP の担当者が変わった時に管理者情報の変更だけで済ませたい
		管理者 (の個人ハンドル) のリストを管理する

・まずは、会員の担当者を認証するところから始めたい。ソフトウェアの設定、
開発などの実作業を誰が担当するかが問題。

・運営委員会の承認を得て、JPNIC で認証局 (CA) を動かす方向で考える。認
証実用化実験協議会 (ICAT) が CA 立ち上げキットを配布し、CA の立ち上げ
のプロモーションを始めるということで、それに乗る方法が有力。

４. 当面のシステムの改善項目

・今年の始め頃に会員に提案した改善項目に対してもらった意見を検討。

・提案した改善項目の内、プライバシの問題を扱った項目については、次の理
由で施行を保留し、継続的に審議することとする。
	- 新しいトップレベルドメインの引き受け先を募集する Internet Draft 
	  中に、割り当てたドメインに関してどのような情報を whois で公開す
	  べきかというガイドラインがあったが、そこでは、従来公開してきた
	  ほぼすべての情報を公開すべきこととなっている。このことから、一
	  部の情報を非公開にすることに対して、国際的なコンセンサスはまだ
	  ないものと判断できる。
	- 会員から、これだけでは中途半端で意味がないという意見があった。

・アドレスブロックの分割を出来ないようにする修正については、逆引き DNS 
の登録をネットワーク情報と分離してはどうかという意見も出たが、原案で進
めることになった。

・変更登録時の通知先は、通知先の電子メイルアドレスを登録するための新た
なレコードを設ける方法を採る。

・他の項目については、なるべく早く施行に移す (運営委員会に承認を求める)。

５. 会員情報の改訂

・tレコードの名前を [認証アドレス] とする変更は見送る。他の提案につい
ては、施行に移す (運営委員会に承認を求める)。

６. AS情報の新設

・AS情報を新設する方向で検討する。IP+AS WG にどのようなレコードが必要
かの検討を依頼する。

７. プライバシ問題の抜本的な検討

・JPNIC データベースとプライバシ問題に関しての抜本的な検討を行う。特に、
他の NIC の情報公開ポリシーとのすりあわせが重要である。

８. 情報の更新履歴管理

・リレーショナルデータベースでは困難。今後の検討課題として意識する。

９. Routing Registry (RR) との関係

・RR の現状についてサーベイ。RR との連携や、JPNIC が RR を行う可能性に
ついて検討を続ける。

10. JPNIC の他の業務との連携

・データベースシステムを拡張して、JPNIC の他の業務をサポートする可能性
についても検討を続ける。申請中 (= 割当作業中) の情報もデータベースで管
理する可能性や、手数料請求業務の効率化などが考えられる。

11. その他

・DB 更新申請を WWW 経由で行えるようにする方法は、認証の問題が解決すれ
ば、エンドユーザに対しては有効である (NSP はバッチ的な処理方法を採るの
で、嬉しくないだろう)。継続的に検討する。

・このミーティングの結果を、1996年度の新 WG に引き継ぐ。

								以上