1996/03/26
                                                                資料2-3-2
                DB WG からの作業報告 (追加)

＊JPNIC DB フォームの改訂ならびに処理方法の改善作業に関して、下に添付
するメイルを 1月30日付で各会員の技術連絡担当者宛に送付したところ、会員
からの意見が 1件あった。現在、その意見も考慮しながらシステムの改造スケ
ジュールを策定している。

＊参考資料

1月30日付で各会員の技術連絡担当者宛に送付したメイル
========================================================================
JPNIC会員
技術連絡担当者 各位

JPNIC DB WG (データベース作業部会) では、データベース登録作業の改善や
サービスの向上を図るため JPNIC DB フォームの改訂ならびに処理方法の改善
作業を進めております。以下のリストは、現在改訂を予定している項目です。
これらの項目について、御意見・御質問等ございましたら、2月15日までに
JPNIC DB WG (db-wg@nic.ad.jp) までお送り頂けると幸いです。反対意見のな
かった項目については、システムの改造ができたものから順次実施していく予
定です。実施前には、再度変更内容をお知らせします。

JPNIC DB フォームの改訂は、会員各位の作業内容にも影響を及ぼすため、フォ
ームの改訂に際しては、今後とも、会員各位の御意見をお伺いする機会を設け
ていきたいと思います。また、会員各位からの改善項目の提案も、随時受け付
けたいと思います。

以上、よろしくお願いいたします。

JPNIC DB WG
------------------------------------------------------------------------
JPNIC DB システム改善項目案 (96年1月30日)

1. ドメイン情報, ネットワーク情報の [組織概要] を [組織種別] に、
[Description] を [Type] にする。

理由: これらのレコードには、「株式会社」といった組織の種別を書いてもら
うことを想定しているが、[組織概要] というレコード名からの連想で、会社
の業務内容等を書いてくるケースが多いため。

2. プロジェクト情報を接続情報 (Connection Information) と改名し、[会員
略称], [接続ドメイン名], [接続IPネットワーク] 以外のレコードを廃止する。

理由: プロジェクト情報に含まれるその他のレコードは、会員情報に登録する
ことにしたため。将来的には、接続情報の差分登録 (追加分、削除分のみの登
録) もサポートしたい。

3. NOC情報を廃止する。

理由: すでに意味を失っているため。

4. ホスト情報の [CPUタイプ/OSタイプ] のレコードを廃止する。

理由: InterNIC への登録の際に、これらのレコードが不要になったため。

5. JPドメイン以外のホスト情報の登録を不要にする。

理由: ３系列管理をやめた時点で、JPドメイン以外のホスト情報は、DNS の設
定に必要なくなったため (極めて例外的なケースとして、ループさせるとネー
ムサーバが引けなくなるという問題がある)。

☆ 逆引きネームサーバのホスト情報の登録を不要にするという案も検討した
が、今回は実施しない。これは、
 (1) InterNIC に逆引きを登録する場合には、逆引きネームサーバの IPアドレ
     スが必要である。
 (2) 多くの場合、逆引きネームサーバは正引きネームサーバも兼ねており、こ
     れを不要としても手間はほとんど減らないものと思われる。
の２つの理由による。

6. アドレスブロックの一部分にのみネームサーバを定義する下のような記法
を導入し、アドレスブロックの分割は許さないことにする (統合は許す)。

Network Information: [ネットワーク情報]
a. [IPネットワークアドレス]     202.250.0.0-202.250.3.0
(中略)
p. [ネームサーバ]               ns.nc.u-tokyo.ac.jp/202.250.0.0
p. [ネームサーバ]               utsun.s.u-tokyo.ac.jp/202.250.0.0

この例は、202.250.0.0-202.250.3.0 のクラスC 4つの内、202.250.0.0 のみ
にネームサーバを設定する場合の記述を示す。

理由: アドレスブロックの分割を許すと、元来の割当単位がわからなくなるた
め。また、アドレスブロックの分割は複雑な作業であり、作業ミスが起こりや
すい。

7. 各情報の内容更新が行われた場合に、登録内容の確認を関係者に Cc: する。
実現方法としては、「関係者」の決め方により次の２通りが考えられる。

(a) 各情報に、「関係者」を定義するレコードを追加する。具体的には、各情
報に [通知アドレス] レコードを追加し、内容更新時には、通知アドレスレコ
ードに記述された電子メイルアドレスに対して登録内容を Cc: により送付す
る。

(b) 例えばドメイン情報であれば、運用責任者と技術連絡担当者を「関係者」
とする。具体的には、運用責任者と技術連絡担当者の個人情報から電子メイル
アドレスを取り出し、そのアドレスに対して登録内容を Cc: により送付する。
個人情報の電子メイルアドレスが未定義の場合は、送付されない。

なお、いずれの場合も、「関係者」に関する情報が更新された場合には、更新
される前後両方の「関係者」に Cc: する。また、JPNIC は、Cc: したメイル
がフェイルした場合の責任は負わない。

理由: 組織の担当者と NSP と担当者が一貫性のない更新をするのを防ぐ効果
が期待できる (組織の担当者が間違ってネームサーバを消してしまうケースが
ある)。

8. 個人情報に非公開フラグを導入する。非公開フラグがたっている個人情報
は、[名前], [組織名], [部署] (およびそれらの英語) 以外のレコードを
whois で検索できなくする。ただし、非公開フラグがたっている個人情報は、
各情報の技術連絡担当者には登録できない。逆に、各情報の技術連絡担当者と
して登録されている個人情報の非公開フラグをたてることはできない。

非公開フラグの登録フォームは次の通り。

Personal Information: [個人情報]
a. [JPNICハンドル]              HT001JP
(中略)
x. [非公開]                     1

☆ 非公開フラグは、あくまで、簡単に検索することを許さなくするだけで、
JPNIC から外に出さないことを約束するものではない。

理由: プライバシの保護に対する要望がある。技術連絡担当者に NSP の担当
者を登録することで、組織の担当者に関するプライバシを保護できる。

9. 会員略称に使える文字を、アルファベット(大文字/小文字)、数字、"-"、
"/" のみに制限する。

理由: システム側の事情。実質的には問題ないと思われる。
========================================================================