1995/09/29
								資料 2-3-1
		DB WG + SOC WG Meeting Minute

日時: 1995年9月28日 13:30頃～18:30頃
場所: 大型計算機センター 小会議室

出席者(順不同): 平原, 高田, 奥山, 小島, 深野
		中山(途中から), 小西(後半のみ)
報告作成: 高田広章

--------------------
13:30-	DB WG		「whoisサーバについてなど」

1. whoisサーバの構築方法

・whoisサーバの構築方法以前に、DB+DOM+IP のシステムを、DBMS ベースで実
現するのが良いか、UNIXファイル上に perl を使って実現するのが良いかが問
題になる。この問題について検討したが、結論には至らなかった。

# この議論に 1時間半程度の時間がかかった。

当面、プログラム担当の事務局員 (小島, 深野) が、時間を見つけて DBMS の
勉強を始める。また、DBMS に対して perl からアクセスする方法の開発を検
討する。

・現在動作中の perlスクリプト, DBMS 併用式の whois サーバの動作状況に
ついて報告があった。半数弱の検索が DBMS で処理されており、残りは perl
スクリプトで処理できている。まだ、改良の余地はありそう。perlスクリプト
と DBMS で仕様が違う箇所があるので、改善する。

・whoisサーバの DBMS を Sybase へ移行する作業を急ぐ。

2. 会員情報, プロジェクト情報, NOC情報の取り扱い

・会員情報を whois で提供するようにする。それによって、プロジェクト情
報から重複するフィールドを除いて、「承認情報」という位置付けにする。 
DB WG としては、NOC情報は意味を失っているので廃止したいと考えているが、
利用している人がいないか確認が必要という意見が出された。フォームを変更
するに先立ち、会員に対して意見を求める方向で進める。

・NOC情報を廃止することに関して、コネクティビティに関する情報を JPNIC 
が管理するべきかどうかについての意見交換があった。

3. その他

・DOM WG から、「組織概要」を「組織区分」ないしは「組織種別」に変更し
て欲しいという要望があり、その方向で改訂を考えることとなった。同時に、
「部局名」を「部署」に変更することも考える。

・whois サーバの仕様がはっきりしていない問題が指摘され、今後、仕様を明
確化する作業を行うこととなった。それが完成した以降は、whois サーバの仕
様が変更になる場合は、あらかじめ周知を行い、新旧両仕様のサーバを動作さ
せる併用期間を設けるなどの配慮が必要となることが確認された。

--------------------
16:00-	DB WG + SOC WG	「JPNIC DB のプライバシ問題」

議題: 「JPNIC DB のプライバシ問題」

・将来的には JPNIC DB に登録されている情報の一部を非公開としていく方向
性については、合意が得られた。そこへ到達するまでに、国際的なコンセンサ
ス作りが重要であり、時期的な問題については結論に至らなかった。

理由: インターネットが社会に浸透するにつれて、今までのような「仲良しネッ
トワーク」的な考え方は通用しなくなっている。電話番号を電話帳に載せない
自由が認められているのと同様に、JPNIC DB についても、個人のプライバシ
の保護に配慮する必要がある。ただし、現時点では、このような考え方が国際
的なコンセンサスになっているとは判断できない。

・従来、個人情報を JPNIC DB に登録し公開していたのは、ネットワークトラ
ブル (例えば、UDP パケットのストーム) が起こった場合に連絡先を調べられ
るようにすることが最大の目的であった。実際、AUSCERT が InterNIC の 
whois を使ってコンタクト先を特定している例がある。非公開システムの導入
にあたっては、この目的を損なわないことが前提になることが確認された。

・上の方向性を前提として、何を非公開にするかについて議論した。以下に述
べる (高田の記憶が正しければ) 以前吉村運営委員から提案のあった方法をベ
ースに議論を行った結果、基本線では合意が得られた。

原案:
 - 運用責任者の個人情報は、名前などの少数のレコードを除いて非公開とする
 - 技術連絡担当者には、NSP の担当者を記述することができる

・ドメイン情報およびネットワーク情報の住所欄も非公開にできないと意味が
ないという指摘があり、その線で合意が得られた。

・ネットワーク利用上や法的なトラブルの際には、運用責任者が非公開になっ
ていると JPNIC に対して問い合わせが来ることを覚悟しなければならないと
いう指摘があった。

・非公開の対象にするのは、個人ドメイン (ないしは個人に割り当てられたネッ
トワークアドレス) に対する運用責任者の個人情報のみか、組織ドメイン (な
いしは組織に割り当てられたネットワークアドレス) にも適用されるかが問題
になる。議論の結果、組織と個人を区別するのは適当ではないという合意が得
られた。

理由: 組織の中には、家族会社や任意団体といった、個人と大差ないものも含
まれているため、区別する意義は低いと考えられる。

・上の原則にかかわらず、国際的なコンセンサスが得られるまでの間に非公開
システムを開始する場合には、徐々に非公開部分を増やしていく方法が無難で、
その過程において個人ドメインの運用責任者の個人情報は非公開にできるが、
組織ドメインについては許さないという時期があっても良いという意見が出さ
れた。

理由: 一度非公開部分を設けると、それを公開に戻すのは困難であるため。

・個人情報を非公開にする場合に、具体的に個人情報のどのフィールドを非公
開にするかを検討した。基本方針として、名前と所属 (組織, 部署) 以外は非
公開にして良いことが合意された。それ以外のフィールドを一括非公開とする
か、フィールド毎に公開/非公開を選べることにするかは合意には至らなかっ
たが、少なくともスタート時は前者の方法で良いという方針となった。

・NSP の担当者を技術連絡担当者に記述する場合には、NSP の許可を必要とす
る旨が確認された。

理由: NSP が技術連絡担当者を引き受けるというサービスに対して課金する可
能性を許すため。

・マルチホームしている組織の場合は、すべての接続相手先の NSP を登録す
ることが望ましい。

・非公開システムを施行する場合には、「その情報を JPNIC外に出さないこと
を保証するものではない」という断りを入れることが確認された。

理由: 何らかの理由で、本来非公開の情報を JPNIC 外に出す可能性はある。
また、事故などによって、意図せずに出てしまう可能性もあるため、保証して
いるかのように思われるのは危険である。

・InterNIC, APNIC への登録をどうするかについて議論があった。InterNIC 
は、ネットワーク情報に対しては技術担当者の登録しか要求していないため問
題ないが、APNIC は運用責任者 (Administrative Contact) の登録も要求して
いる。運用責任者の個人情報が非公開の場合に、JPNIC を運用責任者として登
録する、技術連絡担当者 (NSP の担当者かもしれない) を運用責任者として登
録するなどの案が出されたが、APNIC 側との交渉が必要ということもあり、結
論を保留した。

・技術的な問題として、本人が自分の登録状況を見たい場合にどうするかとい
う問題があることが指摘された。これについても、いくつかの案は出されたが、
結論には至らなかった。

・技術連絡担当者は複数登録できるが、いずれの個人情報も非公開とすること
を許さない方針とすることが確認された。

・以上の方針の実装方針について検討を行った。個人情報に非公開を示すフラ
グを導入し、技術連絡担当者で指定されている個人情報に非公開フラグが立っ
ていればエラーとする。エラーのチェックが面倒であるが、システムの問題と
して、解決するしかないという結論になった。ドメイン情報、ネットワーク情
報中の住所フィールドを非公開にするために、ドメイン情報、ネットワーク情
報にも非公開フラグが必要となる。

								以上