----------------------------------------------------------------------
第18回IPアドレス管理指定事業者連絡会
日時  ：2006年10月23日(月)13:30-17:30
場所  ：日本教育会館  中ホール
参加者：54名
----------------------------------------------------------------------
[議題]
1. APNIC22アップデート
2. APNICにおける料金体系見直しの検討状況について
3. 逆引きDNSの障害対策について
4. lame(機能しない)逆引きDNSへの対策
5. その他のお知らせ
----------------------------------------------------------------------
1. APNIC22アップデート(IP事業部 奥谷泉)

   [質疑応答]
    なし

2. APNICにおける料金体系見直しの検討状況について(IP事業部 穂坂俊之)

   [補足]
    IP分野担当理事およびAPNIC ECの立場から、前村昌紀より本件について以下
    の補足を行った。
    + この半年はAPNICの提案の背景、各NIRの事情への理解を深める作業を行っ
      てきた。
    + JPNICからも既存の会費モデルをベースに会費を青天井とし、NIR、LIRの
      区別なく料金を適用するモデルも提示してみたが、NIRによる負担額が相
      対的に小さくなることがこのモデルの問題点である。
    + スライドP.16で紹介しているモデルはミーティング開催中にAPNIC ECによ
      るコメントをベースとしており、概念の紹介が目的であったため、実装に
      あたっては今後よりしっかりした検討が必要である。また、これが絶対的
      な案ではなく、他の案の可能性も含めて検討を進めていく。
    + APNICの料金改訂にあたっての今後の意見集約の方法としては２つの案が
      出ており、APNICでは関係者からの具体的な意見をもとに進めことを検討
      している。
      ・APNIC会員および関係者を対象に定期的に実施しているAPNICのサービス
        に関する調査とあわせて意見を伺う
        または
      ・会員投票により特定の案に対する会員の意志を確認する

   [質疑応答]
    + APNICの料金改訂について、JPNICとしての今後の見通しを教えてほしい。
      →今後提出されるAPNICからの案をベースにコメントをしながら進めてい
        く。従って、議論のたたき台をなるモデルを早めに提示してほしいと依
        頼することになるだろう。(JPNIC)
      →JPNIC側での料金体系の見直しは、APNICでの見直しが完了してから進め
        るため、当初予定していた2008年よりも時期がずれこむ可能性がある。
        (JPNIC)

3.システム障害時の対応について

   [質疑応答]
    + 資源管理情報はどのような情報なのか教えてほしい。
      →契約に関する情報を契約者情報、指定事業者の管理している資源に関す
        る情報を資源管理者情報としてJPNICデータベースに登録されている。
        これらの情報はWHOISでは公開せずに、指定事業者向けのウェブから申
        請者パスワードを利用してアクセスすると参照可能である。(JPNIC)

    + FAX番号は複数の記述が可能か。
      →FAX番号はシステムの制約上、現時点ではひとつしか登録できないがも
        しご要望があれば今後、検討する可能性もある。なお、契約に関するお
        知らせとしてFAXを利用する場合は、資源管理者情報ではなく、契約者
        情報にご登録いただいているFAX番号情報を使うことになる。(JPNIC)

    + 資源管理者情報に登録されている連絡先は、そもそもシステム障害に関す
      る連絡先として収集された情報ではないので、新たにこのための連絡先を
      収集したほうがよいのではないか。そのつもりがなくて登録している場合
      に対応に困る。
      →実際の運用を開始する段階でいただいたご意見も含めて詳細に検討
        する。(JPNIC)

    + APNICの逆引きDNSサーバの障害は夏には立て続けに発生していたが、この
      ところ収束してきたのはなにか対策を行ったからなのか。また、APNIC自
      身で対策を実施すべきことをなぜNIRが対策を練って負担をしなければい
      けないのか、さきほどのAPNICの料金体系の件とあわせて考えると納得が
      いかない。
      →これまでAPNICに対して訴えてきたことが、効果として現れてきたので
        はないかと思う。APNICに対策を委ねればうまくいくのであればそれに
        こしたことはないが、JPNICのサービスにも関わることであるため、で
        きるだけ問題は発生しないようにしたい。一方、その対策にコストを
        かけすぎて指定事業者の料金が上がるのであれば、本末転倒であり、そ
        の辺りのバランスについては見極めていく必要があると考えている。今
        後はAPNICへJPNICの技術スタッフを派遣し、双方のシステム連携を強化
        していきたい。(JPNIC)

4.lame(機能しない)逆引きDNSへの対策(JPNIC 技術部  小山裕司)

   [質疑応答]
    + 第10回JPNICオープンポリシーミーティング(JPOPM10)でこの提案が行われ
      たときに議論が紛糾したが、連絡会にはその場で意見を表明されていた方
      があまり出席していない。本件の実装についてはJPOPM10の出席者にまず
      はご意見を伺ったほうがよいのではないか。
      →今後、ip-usersやdns-ops等のメーリングリストにも意見をお伺いする
        予定だが、その前に一番影響を受ける指定事業者のみなさんに確認をお
        願いしたいと考え、この度ご意見を伺いすることにした。(JPNIC)

    + 技術連絡担当者に登録されている連絡先の担当者は連絡がつかない人が多
      く、連絡を受けないまま逆引きの委譲が切られてしまうケースも発生する
      と思われる。それを避けるためには実際にどの程度到達するのかを検証す
      る必要があるのではないか。また、歴史的PIアドレスの割当先組織は事情
      がわかっていない方も多いと思うが、指定事業者以外の人への配慮はどう
      考えているのか。
    + なお、到達性向上のためには連絡を受ける先が複数になっても構わない。
      →DNSサーバを管理している人に一番到達しやすい窓口として技術連絡担
        当者を想定していたが、もし他の窓口にも送ったほうがよければその点
        についても検討したい。(JPNIC)
      →割当先だけではなく、上位の指定事業者にも通知を送ることで、到達し
        ない可能性もケアしていると考えているが、割り当て先に対しても連絡
        先を正しく登録してくださいというお願いは必要となるだろう。
        (JPNIC)
      →技術連絡担当者への連絡の到達性はlame対策とはまた別の問題として取
        り組みが必要であるだろう。lame対策の実装にあたって、もし90%以上
        の連絡先が不到達として返ってくるようであれば、この実装は機能しな
        い。レジストリとしては連絡先担当者へ連絡がつかないことは望ましく
        ない状態であると考えており、そのような事態が発生するのであれば、
        指定事業者、ユーザにも登録情報の更新が必要であることをより一層ご
        理解いただく等、なんらかの改善が必要となる。いずれにしてもこの度
        の実装にあたっては指定事業者のみなさんに負荷をかける方向になるこ
        とが予測され、JPNICでも充分な周知や説明が必要と考えている。(JPNIC)

    + 次回12月に開催されるJPOPMで参加者のコンセンサス(賛同)が得られたと
      しても、それから準備を初めて年度末の実装に間に合うものなのか疑問で
      ある。

    + 指定事業者に、ユーザに送信したメールのコピーが送られることは望まし
      くない。Webページ等で連絡の進捗状況やLameの状況を確認できるように
      してほしい。そのような対応をしてもらえれば、例えば状況に応じてユー
      ザに必要事項を伝える程度であれば、なにかご協力できることはあるかも
      しれない。
      →どの程度の粒度で情報を提供できるかも含めて今後調査結果を参照でき
        るページを用意できないか検討中である。(JPNIC)

    + 逆引きがlameとなっていることについて想定される原因と影響についても
      事前にJPNICからユーザへ知らせてもらえれば、問い合わせ対応の負荷が
      軽減するので検討してほしい。

    + どのようなタイミングでWHOISにLameとして表示されるのか。
      →実際にJPNICにより逆引きゾーンの委譲が停止された時点である。対応
        されない限りはこのlame表記はずっと表示される。(JPNIC)

    + lameの通知を受け、ゾーンの設定を正しく直したときには、JPNICに連絡
      する必要はあるか
      →その必要はない。ご連絡いただかなくとも、逆引きネームサーバが正し
        く設定されると自動的にその翌日からlameの表示は消え、ゾーン委譲の
        設定が復活する。(JPNIC)

    + 正しく設定ができているかを確認したいが、そのような手段はあるのか。
      こちらで正しく設定したつもりになっていたのに実はlameと判断されるこ
      とは避けたい。
      →そのようなケースに対応するためにチェックツールがあるとよいと思う
        が今回は精度面で課題があるため、見送ることにした。しかし、ニーズ
        については理解できるため、今後提供に向けて検討していきたい。
        (JPNIC)
    + 了解した。現在指定事業者向けに公開されている設定が正しくないゾーン
      の一覧ページを利用して当面は確認を行うが、設定が正しくなったとき
      に、正しくなった旨の通知があるとうれしい。(参加者)

    + 新規の割り当て報告申請の提出にあたって、ネームサーバの設定が完了し
      てないものを登録したい場合に、申請は受理されるのか。
      →申請とは独立して適用されるものであり、申請時には設定が行われてい
        なくとも問題なく受理される。ただし、データベース登録後、今回説明
        したプロセスが適用され、最初の15日間の猶予はそのようなことも意識
        している。(JPNIC)

    + 登録されている技術連絡担当者が、逆引きの設定について直接関わってい
      ないこともあるため、これ以外にも通知を送るような仕組みも検討して
      ほしい。
      →それぞれの連絡情報がどのような形で利用されるべきかもあわせて
        JPNICで検討を行っていきたい。(JPNIC)

    + 逆引きがlameと判断されるまでの期間として15日は短いと思う。小規模な
      割り当てあれば充分な期間だと思うが、2次ISP等にとっては割り当てから
      稼動まで1,2か月というケースも珍しくない。
      →15日の期間は仮に決めているため、短すぎるようであれば延長する方向
        で検討する。また、参考までに、割り当て報告申請においてネームサー
        バの項目は必須項目ではないので、実際に設定が終わってから改めて登
        録することも可能である。(JPNIC)

    + "Lame"という名称は一般の方には通じないかもしれないので見直してほし
      い。また、送信するメールの内容も通知を受け取った人がわかりやすいよ
      う十分に精査したうえで送信してほしい。
      →この度の資料の文面は参考として仮のものを掲載している。実際の送信
        にあたっては見直していきたい。(JPNIC)

    + 技術連絡担当者が今回の連絡先として本当に適切であるのか。また、到達
      性の向上も必要なのではないか。
    + 特に割り当てについては登録されているメールアドレス宛に、今回検討を
      進めている実装についてお知らせを送信し、どれだけの返信があるか確か
      めてみてもよいのでは。
      →トラブル時に対応する窓口という意味では今回の目的に沿っているよう
        に思うが、到達性の向上については検討していきたい。(JPNIC)

    + ある程度軌道に乗ってからは提案されている期間でよいかもしれないが、
      実装段階では、新たな対応としてある程度の猶予を必要とする可能性があ
      るため、逆引きの委譲停止までの期間を、もう少し長くとることも検討し
      てもよいと思う。
    →了解した。いただいたご意見も踏まえて検討していきたい。(JPNIC)

  +  割り振り先がネームサーバの設定を行っている場合であっても、本件に関
     する連絡は割り振り先と割り当て先の両方に送信されるのか。
    →その通りである。(JPNIC)

  + トラブルや技術的な問い合わせについての窓口として技術連絡担当者を利用
    しているが、24時間対応できていない場合もある。24時間対応できている部
    署や窓口も別途用意している場合もあるため、技術連絡担当者以外にもほか
    の連絡先に通知するなど柔軟に対応してほしい。トラブルについてはできる
    だけ早く対応をしていきたいと思うのでご検討いただきたい。
    →技術連絡担当者は複数登録が可能であるため、基本的にはこの方向で対応
      していきたい。ただ、FAXについて現在は項目が一つしかないため、シス
      テム的に対応必要となる。いずれにしても用途に応じて窓口を細分化する
      ニーズがあると理解した。ご要望にお応えできるか検討をしてみたい。
      (JPNIC)

  + gTLDのドメインでは、ユーザへの通知後、一定期間返事がない場合に、レジ
    ストラに通知するような仕組みになっているケースもある。このように、末
    端のユーザに連絡をとってから上位のレジストリへさかのぼる仕組みも
    検討してほしい。

  + 通知文の中にQ&Aへのリンクが含まれるという理解しているが、そこにLame
    の解消に必要な作業もあわせて掲載をしてほしい。特に初回は指定事業者に
    も多くの問い合わせがくると思うので、そのようなページを参照すること
    で、指定事業者の負荷があまりかからないようにしてほしい。
    →Q&Aにはconfigなどの簡単なサンプル例を掲載する予定。(JPNIC)

5. その他のお知らせ

   [質疑応答]
    なし

以上