<?xml version="1.0" encoding="utf-8"?><!DOCTYPE article  PUBLIC '-//OASIS//DTD DocBook XML V4.4//EN'  'http://www.docbook.org/xml/4.4/docbookx.dtd'><article><articleinfo><title>JPOPM34minute</title><revhistory><revision><revnumber>3</revnumber><date>2018-07-19 02:38:27</date><authorinitials>proxy4.nic.ad.jp</authorinitials></revision><revision><revnumber>2</revnumber><date>2018-06-29 07:20:06</date><authorinitials>proxy4.nic.ad.jp</authorinitials></revision><revision><revnumber>1</revnumber><date>2018-06-29 07:18:06</date><authorinitials>proxy4.nic.ad.jp</authorinitials></revision></revhistory></articleinfo><section><title>第34回JPNICオープンポリシーミーティング議事録</title><section><title>第1部</title><para><anchor id="1"/> </para></section><section><title>1. JPOPM34オープニング</title><section><title>鶴巻 悟(JPOPF運営チーム)</title><screen><![CDATA[[質疑応答]
]]><![CDATA[
なし      ]]></screen><para><anchor id="2"/> </para></section></section><section><title>2. [I]JP PDP (JPNICにおけるPolicy Development Process)解説</title><section><title>中川 あきら(JPOPF運営チーム)</title><screen><![CDATA[[質疑応答]
]]><![CDATA[
なし      ]]></screen><para><anchor id="3"/> </para></section></section><section><title>3. [I]知らないと損するIPアドレスの話</title><section><title>谷崎 文義(JPOPF運営チーム)</title><screen><![CDATA[[質疑応答]
]]><![CDATA[
C. IPv6の割り振り要件から「2年に200件の割り当て計画」は既に削除されて
   いる。更新しておいたほうが良い
]]><![CDATA[
C. 指摘ありがとうございます(谷崎)]]></screen><para><anchor id="4"/> </para></section></section><section><title>4. [I]インターネット番号資源ホットトピックス</title><section><title>谷崎 文義(JPOPF運営チーム)</title><screen><![CDATA[[質疑応答]
]]><![CDATA[
C. 1.2.3.0/24 をAPNICで検索すると「APNIC Debogon Project」、RADBで検
   索すると香港への組織への登録、になっている。どちらが消し忘れたのか
   不思議な感じである(鶴巻)
]]><![CDATA[
C. 日本のレートが低い理由。記者クラブによる報道の自由の制限とLGBTへの
   対応が遅れている点が含まれているようだ(藤崎)]]></screen><para><anchor id="5"/> </para></section></section><section><title>5. [I]JPNICアップデート</title><section><title>角倉 教義(JPNIC)</title><screen><![CDATA[[質疑応答]
]]><![CDATA[
なし]]></screen></section></section><section><title>第二部</title><para><anchor id="6"/> </para></section><section><title>6. [I]JPOPM33で提案されたポリシーについて</title><section><title>佐藤 晋(JPNIC)</title><screen><![CDATA[[質疑応答]
]]><![CDATA[
なし]]></screen><para><anchor id="7"/> </para></section></section><section><title>7. [P] [034-01] Final /8 (103/8) ブロック枯渇対応</title><section><title>藤崎 智宏(日本電信電話株式会社)</title><screen><![CDATA[[質疑応答]
]]><![CDATA[
C. 103/8がなくなった時に、どう配るかという議論をしたい(藤崎)
]]><![CDATA[
Q. 他のRIRの状況は(豊野)
]]><![CDATA[
A. ARIN、RIPEはもう分配は終了している。LACNICは不明。AFRINICは、まだ
   枯渇までしばらくかかる。他の地域はそれぞれにやっているので、あまり
   本件の参考にならないと思う(藤崎)
  
Q. 既存で/22の分配を受けるためにwaiting listに並んでいる人も、103/8が
   なくなったら/24しかもらえなくなる想定か(鶴巻)
]]><![CDATA[
A. 現在はそのように想定しているが、この点についてもご意見をいただきた
   い(藤崎)
]]><![CDATA[
C. すでにWaiting Listに並んでいる人には、サイズが24になるけれども引き
   続き待つか、という確認が必要だと思う(鶴巻)
]]><![CDATA[
C. もらえる可能性は増えるがサイズは小さくなる、ということで、割り振り
   を受けていないIPアドレス管理指定事業者の方には影響がある。意見をう
   かがいたい(川端)
]]><![CDATA[
C. 日本の状況とアジアの日本以外の状況は少し違う。日本だけはまだ在庫が
   ある状況で、配り続けてよいのか、という議論も出てくるかも知れない
   (藤崎)
 
C. 本日参加している方は、すでに両プールからの割り振りを受けられている
   のか(藤崎)
]]><![CDATA[
C. 返却済みプールからの割り振りは受けていない
]]><![CDATA[
Q. 103/8はIPv4からIPv6への移行のためという位置付けなのか(豊野)
]]><![CDATA[
A. APNICでは「新規参入するユーザのため」と言っていて、IPv6へのトラン
   ジションのため、という位置付けではない。ARINではIPv6へのトランジショ
   ンのためにもらえるプールがある(藤崎)
]]><![CDATA[
Q. APNICで実施されたらJPNICでも実施することが必須となるか(豊野)
]]><![CDATA[
A. 必須とならざるを得ないと考えている(藤崎)
]]><![CDATA[
Q. 終了後のことを決めておかない場合、どうなるのか
]]><![CDATA[
A. どうなるか分からないが、おそらく本日の提案と同様の運用が、APNIC事
   務局の裁量でなされることとなる。ただし、サイズが/24となるかどうか
   は不明。現行のwaiting listの運用についても、ポリシー提案を経て決め
   られていたわけではなく、APNIC事務局からの確認があった上で開始され
   た経緯がある(藤崎)
]]><![CDATA[
Q. これをやらなければ/8の返却プールがないというだけではないか
]]><![CDATA[
A. 分からないが、私はこうなると思う(藤崎)
]]><![CDATA[
Q. この提案が否決されたらどうなるのか
]]><![CDATA[
A. この場で反対多数だった場合にも、APNICで提案できないわけではないが、
   提案するかどうかは未定。提案をした場合には、JPOPF-STから、日本のコ
   ミュニティでは反対多数だった旨が伝えられることになると思う(藤崎)
]]><![CDATA[
Q. プールは二つのまま、割り振りサイズも/22のままで分配する、と言う案
   は過去に検討されていたか(豊野)
]]><![CDATA[
A. Ver.2がそれに当たる。その時にAPNICで受けた意見は、「プールを一つに
   した方がよい」「もっとシンプルにした方がよい」「割り振りサイズを
   /24にした方がよい」など。その時、確かに割り振りサイズについては、
   皆がもらえるよう/24にした方がよいのかな、とも思った(藤崎)
]]><![CDATA[
C. ちなみに、これまでも「/22まで(up to /22)」ということで、より小さい
   サイズでの割り振りを受けることもできた。例えばリストの最上位にいる
   人が/22を待っていたけれど在庫が/23+/24しかない、という場合、/22の
   在庫ができるまで待つか、/23でいいからもらうと言うか、選ぶことがで
   きるなら、それでいいのではないか
]]><![CDATA[
C. Ver.2とVer.3の違いは、Ver.2であればサイズの上限を/22までの間で選ぶ
   ことができ、Ver.3の場合は/24で強制される。Ver.2の場合、/22より小さ
   いサイズで割り振りを受けた場合、再度リストに並び直すことができる
   (藤崎)
]]><![CDATA[
Q. プール一つでサイズは/22まで(Ver.1)の方がいいと思うが、この案は反対
   されたのか
]]><![CDATA[
A. この案がいいという意見もあり、何も決まっていない。また、Ver.1にし
   たとき、既存のwaiting listをどうするか、クリアするか残すか……とい
   う問題もある。また、103/8の移転禁止との関係を整理する必要もある。
   リストを一つにすることに起因する問題を避けるため、Ver.2でプールを
   二つにした(藤崎)
]]><![CDATA[
C. 論点は以下三つに絞られている(川端)
   ・アドレスプールを一つにするか、二つにするか
   ・サイズを現状の/22までとするか、/24とするか
   ・現在あるwaiting listをどうするか
]]><![CDATA[
C. 上記3点に、
   - 103/8枯渇後のポリシーを明確化しておくべきか
   を加えた4点について意思確認をする(豊野)
]]><![CDATA[
C. waiting listについてはプールを一つにするか二つにするかと依存関係が
   ある(藤崎)
]]><![CDATA[
Q. APNICのミーティングでは、103/8が枯渇してその後のことが決まっていな
   いのは良くないという認識は共有されているのか(谷崎)
]]><![CDATA[
A. 103/8枯渇後の対応を決めておいた方がよい、という点については支持さ
   れている(藤崎)
   
   (意思確認)
   ----------------------------------------------
   ・103/8枯渇後のポリシーを明確化しておくべきか
      賛成 … 17
      反対 … なし
   ----------------------------------------------
   ・アドレスプールを一つにするか、二つにするか(1回目)
      一つ … 9
      二つ … 6
      その他 … 0
   ----------------------------------------------
]]><![CDATA[
Q. 返却済みプールはどのくらいあるのか
]]><![CDATA[
A. APNIC地域では、現状、返却済みプールはない。返却されるものの量も多
   くない。今後どのくらい返ってくるかも分からないので、ほとんどないと
   理解していただくのがよい(藤崎)
]]><![CDATA[
C. APNICにはIANAから再分配された分があるが、他にAPNICに返却されたアド
   レスは1年くらい寝かせてから再分配をしている。現在waiting listには
   500組織くらいが載っていて、リストの先頭は2016年から掲載されている。
   仮に/22を500組織に割り振るとすると、大まかには/12相当が必要(川端)
]]><![CDATA[
Q. 日本国内には返却済みアドレスの在庫があり、状況は少し違うと理解して
   いる。JPNICでプールをマージする場合には、どのような扱いになるのか
   (鶴巻)
]]><![CDATA[
A. 現段階では個人的な見解になるが、APNICのリストにJPNIC管理下の組織も
   並ぶことになるのではないかと思う。その上で、順番が来たらJPNICの在
   庫から分配することになるのではないか。APNICとの調整が必要である
   (川端)
]]><![CDATA[
C. プールを一つにしたときに、誰がリストに並ぶことができるのか。103/8
   から割り振り済みの組織はリストに並ぶことができなくなると思う(藤崎)
]]><![CDATA[
C. 基本的には、JPNICはAPNICと違うことをするつもりはないので、もし、
   APNICで103/8からの割り振りを受けてない組織しかリストに並ぶことがで
   きなくなるのなら、JPNICでもそれに合わせることになる(川端)
]]><![CDATA[
C. 今のポリシー文書では、まず初めに103/8から配り、次に返却在庫から配
   る、となっている。マージしたときにはどう変わるかはよく分からない
   (川端)
]]><![CDATA[
C. waiting listを全部なくせ、と言っているような人は、プールは今の
   103/8と同じ扱いにすることを主張してくるのではないかと思う。自分は
   そうしたいわけではない。プールを一つにするのは一つの解だが、考えな
   ければいけないことが増えるのは事実(藤崎)
]]><![CDATA[
Q. IPv4アドレスを延命しようという方向性に変わってきているのか。それと
   もあるものは配ってしまってよい、という考え方なのか、どちらなのか
   (風間)
]]><![CDATA[
A. 返却プールができた経緯は、103/8以外にも、もう少し使いたい人が使え
   るとよい、という発想から。103/8は、元々新規参入者やどうしても必要
   な人が使えるように、という発想で分配ルールを決めており、その概念を
   あまり変えないようにという意識が現在もある。あまり延命という考え方
   はないように思うが、「/24にサイズを変更する」ことについては、なる
   べく多くの人に配ることができた方がいいという観点からなのではないか
   と思う(藤崎)
]]><![CDATA[
   (意思確認)
   ----------------------------------------------
   ・アドレスプールを一つにするか、二つにするか(2回目)
      一つ … 1
      二つ … 10
   ----------------------------------------------
]]><![CDATA[
C. 「一つにしたときにリストをどうするか」は「一つにしたときにだれに配
   るか」という話と同じで、今までAPNICであまり議論がなされていない(藤
   崎)
]]><![CDATA[
C. APNICでは、意思確認の時、五つの選択肢「強く反対する」「反対する」
   「中立」「賛成する」「強く賛成する」に分けられる(川端)
]]><![CDATA[
C. そういう(選択肢を細かく分ける)のは、日本人は不得意。選択肢は三つ
   「賛成」「反対」「中立」とさせてください。どちらでもいい。関係ない
   という方は「中立」へ(豊野)
]]><![CDATA[
C. 「どっちでもいい」と「関係ない」は違うので、分けていただいた方が良
   い(藤崎)
]]><![CDATA[
C. APNICでもそこは分かれていない(小林)
]]><![CDATA[
C. 「中立」に挙手しなければ「関係ない」となるのでは(藤崎)
]]><![CDATA[
   (意思確認)
   ----------------------------------------------
   ・現在あるwaiting listをどうするか
      引き継ぐ … 8
      リセットする … 14
   ----------------------------------------------
]]><![CDATA[
Q. 二つのプールは全く性質が異なる。103/8は新規参入者のためで、もう一
   方は「あるなら欲しい」に対応するもの。一つにする場合は、どちらに寄
   せるということになるのか(豊野)
]]><![CDATA[
A. 現行の103/8の方になるのではないか(藤崎)
]]><![CDATA[
C. 一つにするか分けるのかが決まってから、一つにする場合には誰にどう配
   るのかを決めるべきなのではないか(小林)
]]><![CDATA[
   (意思確認)
   ----------------------------------------------
   ・サイズをどうするか
      今のまま(up to /22) … 6
      小さくする … 3
      意見なし … 6
   ----------------------------------------------
]]><![CDATA[
C. リストを二つにする前提で、103/8はなるべく多く配れるように/24にし、
   返却済みプールは、もし返ってきたら配る、というくらいの感覚で現状
   (up to /22)のままでよいと思う(鶴巻・谷崎)]]></screen><para><anchor id="8"/> </para></section></section><section><title>8. [P] [034-02] 割振・割当 IPv6アドレスの広告</title><section><title>藤崎 智宏(日本電信電話株式会社)</title><screen><![CDATA[[質疑応答]
]]><![CDATA[
Q. メリットがよく分からない。これを行うことによって誰が嬉しいのか。素
   直に見ると経路が増える(鶴巻)
]]><![CDATA[
A. エッジの方にいて、シングルリンクだけれどBGPを運用していて、集約さ
   れた経路だけを受け取りたい人からの需要がある。現在は一生懸命whois
   を引きながらフィルタを書いている(藤崎)
]]><![CDATA[
Q. 受け取る経路を減らしたいので、集約された経路が流れてきた方が嬉しい
   ということか(豊野)
]]><![CDATA[
A. ルータによってはそれを勝手にやってくれる機能がある(藤崎)
]]><![CDATA[
Q. このポリシーが実施された場合は、設定に1行足せばいいということか(豊
   野)
]]><![CDATA[
A. 設定にもよるが、1行以上足さなければいけない(藤崎)
]]><![CDATA[
Q. 割り振りサイズの経路をBGPに流す。ちぎっても大きいサイズで流してほ
   しい(注：割り振りサイズより小さいサイズで割り当てを行っても、割り
   振りサイズで経路広告をしてほしい)。数的にはそういうケースが多いが、
   そうでないところもたくさんあるので、そうしてほしいと思っている(藤
   崎)
]]><![CDATA[
Q. 必ず割り振りサイズは流した上でちぎれ、とういことか(豊野)
]]><![CDATA[
A. その通りである(藤崎)
]]><![CDATA[
C. ちぎって投げている人にはそれ相応の理由があると想像する。例えば地理
   的にネットワークが違うとか、他の地域からの経路が戻って来て欲しくな
   いなど。それをまとめることは無理なのではないか。そのような状況も考
   慮して「推奨」と言っているのだと理解するが、除外するケースを例示す
   るなどした方がいいのではないか(鶴巻)
]]><![CDATA[
Q. 例えば、ガイドラインに「やるのが難しい例」書いてを書くなど?(豊野)
]]><![CDATA[
C. 以前は「ちぎって投げてはいけない」という主旨の記述があり、それを削
   除した経緯がある(藤崎)
        
Q. RADB参照すればよい、という意見はないのか(豊野)
]]><![CDATA[
A. それをするのが大変なので、経路上にあった方が良いという考えで本提案
   をしている(藤崎)
]]><![CDATA[
   (意思確認)
   ----------------------------------------------
   ・本提案に、
      賛成 … 6
      反対 … 5
      意見なし … 5
   ----------------------------------------------
]]><![CDATA[
C. (反対の理由として、)RIRが経路制御にどこまで関わるかが把握できていな
   いので、そこを整理してからの方がよいのではないか(★1)
]]><![CDATA[
C. どちらかというと厳しくする方向なので、JPNICローカルのポリシーとし
   て実装してもよいのではないか(藤崎)
]]><![CDATA[
C.「推奨＝できれば」ということで、厳しくはしていないと理解している
]]><![CDATA[
C. 確かに「厳しく」とはいえないかも知れないが、「推奨を増やす方向」な
   のでJPNICのみで実装できるのではないか(藤崎)
]]><![CDATA[
C. 個人的な感想だが、IPv6のポリシーについては経路の集成を重視している
   ので、その方向性と合うか合わないか、というところがあるかと思う。
   APNIC全体としてやらないとだめなのではないか(川端)
]]><![CDATA[
C. そういう意味ではAPNICだけでもだめで、全世界的にやらないとだめなの
   ではないか(藤崎)
]]><![CDATA[
C. アドレスの管理コミュニティの中で話すものなのか、IETFやNOGのような
   ところで議論すべきものなのかは、議論になるのではないか。それを意識
   して議論した方が意味があるのではないか(川端)
]]><![CDATA[
C. 日本のポリシーにしれっと入れてもよいと思う。日本の事業者がすべて
   JPNIC管理下にあるわけではないし、JPNICでやって効果が出たのなら、そ
   れを事例としてAPNICに提案してもよいのではないか。必須ではないが、
   JANOGに持って行って啓蒙はしたらいいのではないか(小林)
]]><![CDATA[
C. ポリシーはあくまでもアドレス管理に関するものなので、運用に関する推
   奨はガイドラインに書いて啓発していくのが適切であり、ポリシーという、
   ルールに書くのは適切ではないと思う(佐藤晋)(★2)
]]><![CDATA[
C. (★1)と(★2)の意見は近い。運用に関することにどれだけ踏み込むか、と
   いう話である。事務局としては上位ルールに逸脱しない範囲でのルール追
   加はありなので、運営チームとしてはJPNICだけの規定策定もありうると
   判断する(豊野)]]></screen><para><anchor id="9"/> </para></section></section><section><title>9．[P] [034-03] IPv6の逆引き設定</title><section><title>藤崎 智宏(日本電信電話株式会社)</title><screen><![CDATA[[質疑応答]
]]><![CDATA[
Q. 「*.」 という登録でよいのか(豊野)
]]><![CDATA[
A. ワイルドカードを使うならそのような形になると思う(藤崎)
]]><![CDATA[
Q. 動的アドレス帯も登録するということか(豊野)
]]><![CDATA[
A. 今、半固定アドレスがほとんどだと認識している。半固定アドレスとして
   使用する時点でアドレスを割り当てた、ということで、割り当てたら
   delegationする、というのが今のポリシーなので、その時点での登録が必
   要(藤崎)
]]><![CDATA[
Q. 割り当てを受けた人がやらないのなら親がやるべきということか(豊野)
]]><![CDATA[
A. その通りである(藤崎)
]]><![CDATA[
Q. 期限は設けるか。割り当て先で登録をするかどうかは、事業者は待つこと
   になるのか(豊野)
]]><![CDATA[
A. ISPに/32が割り当てられて、そのうちの/56をユーザに割り当てるので、
   /56を割り当てられた人は登録をしなければならない。さらにその/56の中
   をどうするかは、与り知らない。だから、ISPは/56を割り当てた時に、
   delegationするかしないか、ということ(藤崎)
]]><![CDATA[
Q. 何が返ってくることを想定しているのか。ノード名? 割り当て者?(豊野)
]]><![CDATA[
A. PTRレコードを引いたらFQDNが返ってくること。できるのならdelegation
   してエンドノードまで全部やってもいいし実際そのようにしているところ
   もある。それは理想だが、mustにしても、特にコンシューマー系では不可
   能だと思うので、妥当と思う案を提案している(藤崎)
]]><![CDATA[
   (意思確認)
   ----------------------------------------------
   ・この提案に、
      賛成 … 4
      反対 … 3
      中立 … 9
   ----------------------------------------------
]]><![CDATA[
Q. JPNICに訊きたい。提案者としては現状に問題があると思っているが、
   「しょうがないからこの状態でいいよね」と理解されていると思っていい
   のか(藤崎)
]]><![CDATA[
A. 現状は「必要であれば登録をしよう」というポリシーだと理解しているの
   で、現状でさほど問題がないと理解している。多くの場合は/32の割り振
   りを受けた事業者は/32でネームサーバの登録をされるケースを多いよう
   に見受けられる(川端)
]]><![CDATA[
C. コンシューマーはお願いしてもやってくれないので気になっている(藤崎)
]]><![CDATA[
Q. 確認だが、今回提案のルールはmandatoryなのか(豊野)
]]><![CDATA[
A. 言われたらやらなくてはいけないし、言われなくてもやる。という意味で
   は厳しくなる方の提案である(藤崎)
]]><![CDATA[
C. lame delegationのチェックをしているので、そことの関係を整理してお
  くべき(川端)
]]><![CDATA[
C. lameにならないようにエントリを書くようにすればよいので、今の話は大
   丈夫打と思った。/32で丸投げの場合は、下の階層でlameが発生する可能
   性はある(藤崎)]]></screen><para><anchor id="10"/> </para></section></section><section><title>10. [I] APNIC45・RIPE76他ミーティングレポート</title><section><title>川端 宏生(JPNIC)</title><screen><![CDATA[[質疑応答]
]]><![CDATA[
なし]]></screen><para><anchor id="11"/> </para></section></section><section><title>11．[I] APNIC45以降に提案されたポリシーについて</title><section><title>鶴巻 悟(JPOPF運営チーム)</title><screen><![CDATA[[質疑応答]
]]><![CDATA[
C. ここまで書き直す必要はないと思った。今のままでよい気がする。APNIC
   のポリシーは、assignmentとallocationの定義がIPv4、IPv6の両方のポリ
   シーに書かれている。P to Pのアドレスは割り当てと見なさないと言って
   いる。PPPoEは割り当てと見なされないのはまずいのではないか。細かく
   言い過ぎてしまって、逆につらくなってしまっているのではないか(藤崎)
]]><![CDATA[
C. 意図は理解できなくはないが、細かく書くのは切りがないので、難しいの
   ではないか(鶴巻)
]]><![CDATA[
C. 現行で問題ないのではないか。新しいサービスが追加されたら書き直すの
   か。書き直すのも大変だし書き直さないのも問題である(藤崎)
]]><![CDATA[
Q. RIPEではどのような感じだったのか。先ほど、あまり練られていないので
   継続議論、という話ではあったが(藤巻)
]]><![CDATA[
A. RIPEでは、一回で変えるのではなく、一度書いた上で再度提案する、とい
   うイレギュラーな対応がされている。一度変えようとした時にRFCが出た
   ため。個別のケースをどのようにするかは、運用されているかたのコメン
   トの方が有用だと思う。割り当てと見なさない個別のケースをどう考える
   かが、一つ議論のポイントだと思う(川端)
]]><![CDATA[
C. Jordi氏が例に挙げているIPv6のprefix per hostのRFCは、流行っている
   わけでもないし今後どうなるかも分からない。一つづつ例として挙げてい
   くのは全体が崩壊してしまうような気がする(藤崎)
]]><![CDATA[
C. 割り当ての定義が変わる以外に、オペレーション上の影響は発生するのか。
   あまり影響はない気がしている(鶴巻)
]]><![CDATA[
C. 読めば読むほどまずい気がしてきた。半固定は割り当てではないから/48
   からやっていいのか、という風にも読めてきてしまう(藤崎)
]]><![CDATA[
C. ここはブロードバンド割り当てだけど半固定の場合はどちらか(鶴巻)
]]><![CDATA[
C. 国によってもサービスは違う。例を挙げすぎてしまって破綻する気がする
   (藤崎)
]]><![CDATA[
C. RIPE76の前にRIPE74でも本件は議論された。RIPEではPIアドレスの再割り
   当ての定義にこの内容が入っている。PIアドレスは割り当てられているも
   のなので、再割り当てできないが、hot spotやVPNを再割り当てとしてし
   まうとPIアドレスの割り当てが受けられないので、そういう場合にもPIア
   ドレスの割り当てを受けられるようにしたい、というのが、別の提案者か
   らの提案であったが、問題意識の一つだったように記憶している(川端)
]]><![CDATA[
Q. 現状、PIアドレスとして割り当てられたものを再割り当てすることが可能
   となるということか(鶴巻)
]]><![CDATA[
A. それが元の提案で、それを現在のRIPEでの提案者が修正して、RFCの内容
   も加味して提案し直したという経緯がある(川端)
]]><![CDATA[
C. 一文目をもう少しクリアに書く方向にして目的を達成して、具体例をこと
   細かに書かない方がよい。目的が割り振りと割り当ての境目を明確にする
   こととか、/128で割り当てる人なんていない、という主旨は理解する。例
   は時代の変遷によって変わっていく。ここで技術的な例示はせず、ポリシ
   というくらいなので思想を書くべき(豊野)
]]><![CDATA[
   (意思確認)
   ----------------------------------------------
   ・この提案に、
      賛成 … 1
      反対 … 3
      中立 … 12
   ----------------------------------------------
]]><![CDATA[
(結論として)
C. 日本のコミュニティからは強い賛成、反対はなかったが、例示を増やすこ
   との問題点等について意見があったことをAPNICで伝える(鶴巻)]]></screen><para><anchor id="12"/> </para></section></section><section><title>12. [I] IPv4アドレスの枯渇・移転制度開始前後で経路はどう変わった?</title><section><title>吉田 友哉(エヌ・ティ・ティ・コミュニケーションズ株式会社)</title><screen><![CDATA[[質疑応答]
]]><![CDATA[
Q. 103/8レンジで/24の経路が増えているとあった。103/8からは/22で分配を
   受けるイメージが強いが、ちぎって経路広告しているということか(藤崎)
]]><![CDATA[
A. ちぎっている(吉田)
]]><![CDATA[
Q. IPv4の移転で経路が増える一員であるが、主たる要因ではないとのことだ
   と思ったが、もし仮にIPv6で移転を許した時にどうなると予想するか(藤
   崎)
]]><![CDATA[
A. IPv4とあまり変わらないと思う。アドレスをもらうところがどこかが変わ
   るだけで、使い方が変わるわけではないので。IPv6アドレスが枯渇したら
   状況が変わるかも知れないが、経路情報に関するインパクトとしては、
   v4と変わらないのではないかと、IPv4のケースを見て推測している(吉田)
]]><![CDATA[
C. 逆に、把握している情報を共有していただけるとありがたい(吉田)
]]><![CDATA[
Q. 移転されたアドレスによって経路はあまり増えない、ということは分かっ
   たが、移転する前に元のアドレスをちぎって移転したというケースもある
   と思うが、そこはどうなのか(中川)
]]><![CDATA[
A. 広義にはそれも含めて移転のために増えた経路に入っていると思う。見て
   いる限りでは、それほど大幅な増え方をしているものはなさそうだ(吉田)]]></screen><para><anchor id="13"/> </para></section></section><section><title>13. JPOPM34クロージング</title><section><title>豊野 剛(JPOPF運営チーム)</title><screen><![CDATA[[質疑応答]
]]><![CDATA[
なし]]></screen></section></section></section></article>