<?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>JPOPM27minute</title><revhistory><revision><revnumber>2</revnumber><date>2014-11-27 05:50:47</date><authorinitials>proxy3.nic.ad.jp</authorinitials></revision><revision><revnumber>1</revnumber><date>2014-11-27 04:36:01</date><authorinitials>proxy3.nic.ad.jp</authorinitials></revision></revhistory></articleinfo><section><title>第27回JPNICオープンポリシーミーティング議事録</title><para><anchor id="1"/> </para><section><title>1. [I] JPOPM27オープニング</title><section><title>橘俊男(ポリシーWG)</title><screen><![CDATA[[質疑応答]
]]><![CDATA[
・特になし]]></screen><para><anchor id="2"/> </para></section></section><section><title>2. [I] アクションアイテム 橘俊男(ポリシーWG)</title><section><title>橘俊男(ポリシーWG)</title><screen><![CDATA[[質疑応答]
]]><![CDATA[
・特になし]]></screen><para><anchor id="3"/> </para></section></section><section><title>3. [I] JP PDP(Policy Development process)について</title><section><title>橘俊男(ポリシーWG)</title><screen><![CDATA[[質疑応答]
]]><![CDATA[
Q. ポリシーの実装はドキュメントに記述することになると思うが、記述され
   たドキュメントを評価する手段はあるのか。
]]><![CDATA[
A. 勧告済みのアイテムについては、JPNICから報告をしてもらっている。勧
   告通り実装されていないものについては、JPNICからその理由が報告され
   る。実装勧告と根本的に異なっているものについては、JPNICに対してそ
   の理由を問うことになると思うが、そのようなケースはまだない。
   (ポリシーWG/橘)]]></screen><para><anchor id="4"/> </para></section></section><section><title>4. [I] JPNICにおけるポリシー実装状況報告</title><section><title>川端宏生(JPNIC)</title><screen><![CDATA[[質疑応答]
]]><![CDATA[
・特になし]]></screen><para><anchor id="5"/> </para></section></section><section><title>5. [I] APNIC38レポート</title><section><title>奥谷泉(JPNIC)</title><screen><![CDATA[[質疑応答]
]]><![CDATA[
・特になし]]></screen><para><anchor id="6"/> </para></section></section><section><title>6. [P] JPNICにおけるアドレス移転支援について(027-01)</title><section><title>百崎知、藤崎智宏</title><screen><![CDATA[[質疑応答]
]]><![CDATA[
Q. 今回の提案内容はリスティングサービスを作れるかどうかを検討してほし
   いということなのか。それともサービスを作ることが前提なのか。
]]><![CDATA[
A. サービスを作ることが前提。すでに移転可能アドレスサイズの通知を行っ
   ているので、それを国内移転にも流用することを想定している。国内移転
   しか考えていない人はケアできていない。理由としては国内移転だけを考
   えていてアドレスがほしい人は、国内移転にとどまらないのではないかと
   考えているため。海外からの移転も含めて準備が整っていることを表明し
   ておかないと移転の手続きが進まないのではないか。(百崎氏)
]]><![CDATA[
Q. それであればAPNICのリストで十分ではないか。
]]><![CDATA[
A. 自分も当初そう考えていたが、APNICのリストは、APNICのメンバーに対し
   て行ったものなので、その内容でJPNICの移転可能アドレスサイズの通知
   を受けたことにはできない。(百崎氏)
]]><![CDATA[
Q. JPNICとAPNICで調整して、移転可能アドレスサイズの通知を受けたものと
   してもらってはどうか。国内だけで移転したいという人がいた時に、リス
   トに載らず、不公平なのではないか。
]]><![CDATA[
A. 国内なら審査もないので、希望サイズを自由に宣言することができてしま
   う。それを許可してしまうと、膨大なリストができてしまい、リスティン
   グサービスの意味がなくなるので、リストに載るためには一手間必要、と
   いう状態が望ましいと考えた。(百崎氏)
]]><![CDATA[
C. APNICとJPNICのリストの共有がされるようにすればよいのではないか。(橘)
]]><![CDATA[
C. JPNICは今、pre-approvalのリストを公開していないので、JPNICでもして
   ほしい。また、相互のリンクをしてほしい。
]]><![CDATA[
Q. リストが二つあるのがおかしいのではないか。
]]><![CDATA[
A. APNICとJPNICのpre-approvalは異なるので、リストが分かれること自体は
   仕方ないと思う。
]]><![CDATA[
C. 申請の窓口が違うが、効力は同じであると理解している。
   (KDDIウェブコミュニケーションズ/森川氏)
]]><![CDATA[
C. 承認している主体がJPNICなので、JPNICでリストを提供してほしいという
   理解である。APNICでの判断次第だが、JPNICでのpre-approvalの結果を
   APNICのリストに追加してほしい、というのでも提案の内容を逸脱しない
   か。(JPNIC/奥谷)
]]><![CDATA[
A. その理解で問題ない。
]]><![CDATA[
Q. APNICがJPNICでのpre-approvalの結果をリストに掲載した場合、JPNICは
   取り次ぐだけで問題ないのか。
]]><![CDATA[
A. JPNICできちんと誘導するページを入れてほしいとは思うが、個別のやり
   取りについては基本的には各自でがんばってもらうことを想定している。
   (百崎氏)
]]><![CDATA[
C. 現状は国際移転をしたいからpre-approvalをしているが、国内移転を希望
   する場合にもリストに掲載されたいためにpre-approvalを受けるケースが
   出てきそうであり、悩ましい。
]]><![CDATA[
C. 国内で流通するアドレスを移転する場合には需要確認が不要。過去に国際
   移転されたアドレスについては国内移転であっても需要確認が必要になる。
   (橘)
]]><![CDATA[
Q. 国内でもAPNICから割り振りを受けている組織もあるが、その場合も対象
   になるのか。
]]><![CDATA[
A. APNICからアドレスの割り振りを受けている場合には、APNICのルールが適
   用される。JPNICから割り振りを受けているアドレスには、JPNICのルール
   が適用される。(橘)
]]><![CDATA[
C. 返却されるアドレスを活用するということも考えたほうがよいのでは。
   (JPNIC/佐藤晋)
]]><![CDATA[
C. IPアドレスを返却するのが簡単すぎるので、返却する前に、移転が可能で
   あることの案内を挟むようにして欲しい。(百崎氏)
]]><![CDATA[
C. 不要となったアドレスは返却するのが基本である。(橘)
]]><![CDATA[
C. 現在も返却の問い合わせはある。問い合わせの際には移転があることを説
   明した上で、返却の手続きを案内している。返却を案内する際にどういう
   ように移転に誘導するかも悩みのポイントではある。(JPNIC/川端)
]]><![CDATA[
C. 前回、3年くらい前の議論の際には、JPNICはこんなことはしないで、通常
   のアドレス分配をしっかりして欲しい、という声が大きかった。また当時
   はAPNICもリスティングサービスは行っていなかったが、現在はすでに始
   めている、といった状況変化もある。そのため、再度この場で意見を聞い
   てみたかった。
]]><![CDATA[
C. 返却されたアドレスが/22で細切れになって再分配されるのも、運用者は
   困るのではないか。JPNICに本当に返すのか、と確認させるのは本末転倒
   なのかもしれない。返却を希望する組織からは返却を受け、一方で、基準
   を満たした人のリストを公開することとは両立出来ることだと思う。
]]><![CDATA[
C. 厳密に言えば、この内容はポリシーではない。しかし番号資源を有効利用
   するために議論をすることを目的として、今回は提案として議論を実施し
   ている。(橘)
]]><![CDATA[
[挙手]
]]><![CDATA[
  総数：53
  賛成：24
  反対： 0
]]><![CDATA[
→一旦コンセンサスとして判断して、具体的な進め方については提案者と
  JPNICで検討の上、次回ミーティングで報告をすることとする。(橘)
  
Q. 今後の具体的な進め方が不明である。(川端)
]]><![CDATA[
A. 検討の結果に対して再度提案等をすることは想定していない。(橘)
]]><![CDATA[
C. 何が望まれているのか、ニーズが掴みきれていない。(川端)
 
→今後の進め方について、提案者・ポリシーWG・JPNICで相談し、クロージン
  グで再度明確にする。(橘)]]></screen><para><anchor id="7"/> </para></section></section><section><title>7. [P] エンドユーザIPアドレス割り振り・割り当てサイズの明確化(027-02)</title><section><title>廣海緑里、藤崎智宏</title><screen><![CDATA[[質疑応答]
]]><![CDATA[
C. /24で登録していても、/16でブロックしてくるISPがあるので、どこまで
   意味があるのかと、懐疑的に思ってしまう。
]]><![CDATA[
Q. その辺りの認識はあまりなかった。どうしてそうなってしまうのか。
   (廣海氏)
]]><![CDATA[
A. あまりWhoisを引いて登録しないからではないか。
]]><![CDATA[
Q. JPNICだけでやって意味があるのか。IETFで検討をするのはなるほどと思っ
   たが。
]]><![CDATA[
A. ひとまずは、どこのレジストリでも情報提供していないと思うので、こう
   いう仕組みをやってみて効果があるなら推奨していく、というように、
   JPNICからボトムアップでやっていくのは意味があるのでは。(廣海氏)
]]><![CDATA[
Q. 提案の主旨がいま一つ分からない。サイズを登録したいと言っているのか、
   1件1件のデータを登録したいのか。
]]><![CDATA[
A. スライドではインフラの単位でフィルタをしてしまうとダメという例を書
   いている。割り当てサイズを登録させたい。v6だと/48か/56かはサービス
   で違うと思う。個別でユーザが使っている単位が分かるといいと思う。
   (廣海氏)
]]><![CDATA[
Q. インフラで登録すると困る、というのは、なぜなのか分からない。
]]><![CDATA[
A. 個々のユーザが使っている最小の単位を登録したい。(廣海氏)
]]><![CDATA[
C. アドレスの素性をはっきりしたいという問題意識は理解できるが、レジス
   トリがレジストリデータベースでやる話かどうかが疑問。
]]><![CDATA[
C. レジストリ以外にどこがそいういう情報を管理できるのか、というとやっ
   ぱりない。レジストリの配下のISPになるのか。(廣海氏)
]]><![CDATA[
Q. v4は動的な割り当てを多くしている。/28や/29は、その単位で登録してい
   る。動的な割り当ては/24のような形でまとめて登録している。動的な割
   り当てについて、/32単位で割り当てているということを把握したいのか。
]]><![CDATA[
A. はい。(廣海氏)
]]><![CDATA[
C. きちんと登録されていないv6の情報を登録しよう、というなら分かるが、
   v4は動的な割り当てを多く行っており、v6は半固定のようになっている状
   況が想像され、v4とv6を同列に議論するのは、ちょっと難しいと思う。
]]><![CDATA[
Q. 違っていたら指摘していただきたいが、v4を動的に割り当てていても、実
   際にはあまりアドレスが変わらないといった状況があるのではないか。
   (廣海氏)
]]><![CDATA[
A. フレッツの網終端装置に依存するが、変わるときは変わるので、そこは何
   とも言えないのではないか。
]]><![CDATA[
Q. 確認だが、提案内容としては、アドレスを利用に応じてDBに厳密に登録す
   るべきとポリシーに明記する、ということになるか。(橘)
]]><![CDATA[
A. アドレスの利用単位がバラバラになっているのを、何らかの手段でわかる
   ようにしたい。Whoisに登録するのもひとつの手段であるが、データベー
   スの破綻なども懸念されるので、方法は検討をして欲しい。結果としてポ
   リシー変更に関わって来るかもしれない。(藤崎氏)
]]><![CDATA[
C. 大きさの単位を登録したいものと理解している。スマホ・携帯とかは、
   v6で/128とか割り当てる可能性もある。何の意味があるのか。また事業の
   内容に関わってくるので、事業者は出したくないのでは。
]]><![CDATA[
Q. アドレス共有の場合はどうするのか。
]]><![CDATA[
A. 提案ではポート単位で登録せよとまでは踏み込んでいないが、アドレス共
   有している範囲だということが分かるだけでもフィルタ等に使えるかもし
   れない。どのくらいの単位でポートを割り当てているか等も外に出したく
   ない情報なはずなので、今後の検討としてもよいのでは。(廣海氏)
]]><![CDATA[
C. 以前、IPv6でPPPoEでフレッツのケースで、とあるISPに割り当てサイズを
   尋ねたが、 窓口の人は絶対に教えてくれなかった。サービス仕様として
   は決まっているが、サイズは公表したくないのでは。(ポリシーWG/谷崎)
]]><![CDATA[
C. お客さんの情報を出したくないのと、割り当てサイズが変更する可能性が
   あるという状況なのか。この辺りの状況を教えていただけるとありがたい。
]]><![CDATA[
C. 何が問題なのか、何を解決しようとしているのかが、分からない。
]]><![CDATA[
Q. 逆に質問させていただきたいが、ザルでフィルタされて困ったこと案外少
   ないのか。(廣海氏)
]]><![CDATA[
A. それはあるが、この方法で解決できるかは疑問。
]]><![CDATA[
Q. 他によい解決方法はあるか。(廣海氏)
]]><![CDATA[
A. フィルターされて困っている、ということであればそれを議論点にするべ
   きでは。自分も/64のIPv6の登録はしていない。したほうがわかりやすい
   がDB維持できるかなどの課題もある。実際にはv6は/56、/64の登録もした
   方がいいのではないかと思うところもある。一方でv4の/32の登録は必要
   ないと思う。もう少し問題点を分割して検討した方が良いのではないか。
   v4とv6を分けた方がよいかまでは、現時点では何とも言えない。
]]><![CDATA[
C. 割り当て単位を登録して公開した場合、逆に悪意の利用者にスプーフされ
   てしまうような懸念があるのではないか。誰にでも見せるのは、よくない
   ように思った。見せ方を考える必要もあるのでは。
]]><![CDATA[
C. 何らかのDB登録はすでに行われているはずなので、範囲が狭まるだけのこ
   となのでそれほど影響ないのではないか。(廣海氏)
]]><![CDATA[
C. 最終的にはレプテーションDBを作りたいように見え、それは目指すところ
   がtoo muchだと思うので、あまり賛同できない。(水越氏)
]]><![CDATA[
Q. ISPを主にターゲットにしているが、サーバ事業者の場合はどうするのか。
   サーバセグメントの単位で登録するのか、1IPごとを割り当てているユー
   ザ単位か。サーバをのっとられているケースが多いので。
   (KDDIウェブコミュニケーションズ/森川氏)
]]><![CDATA[
A. サーバ系についてはあまり考えていなかった。(廣海氏)
]]><![CDATA[
C. オペレータコミュニティから、本当にこの問題解決が望まれているのかが
   分からなかった。(橘)
]]><![CDATA[
C. フィルタをするために、使われている最小サイズを知りたい。ポリシーの
   実装を含めて検討したいけれど、どのくらい同意が得られるか知りたい。
   この提案に意味があるなら、何らかのグループを作って検討するなどした
   い。(藤崎氏)
]]><![CDATA[
C. ポリシーではないので、一連の議論を通じて、検討活動をやってみること
   について、賛成もしくは反対を確認することにしたい。(橘)
]]><![CDATA[
[挙手]
]]><![CDATA[
  総数：51
  賛成： 8
  反対： 1
]]><![CDATA[
C. (反対の理由として、)技術的課題は理解するが、このポリシーミーティン
   グの畑ではない。]]></screen><para><anchor id="8"/> </para></section></section><section><title>8. [P] レガシーIPv6アドレス空間の有効利用に関する提案(027-03)</title><section><title>藤崎智宏</title><screen><![CDATA[[質疑応答]
]]><![CDATA[
Q. 前回の提案から、一部分を再定義しての提案と考えてよいか。(橘)
]]><![CDATA[
A. 奥谷さんからAPNICで提案があったものでコンセンサスに至らなかったもの
   のうちの半分の提案。今回合意が得られれば、もう一度APNIC持っていくつ
   もり。(藤崎氏)
]]><![CDATA[
C. もったいないのは分からなくはないが、ポリシーを変更する必要性までは
   ないのでは。変えなくても不幸なことはないと思う。
]]><![CDATA[
C. /32より大きいサイズを取るのはすごく大変。なので、簡単に拡張できる
   のは意味があることだと思う。(藤崎氏)
]]><![CDATA[
Q. APNICで大きなサイズをとりにくくしていることがある一方、この提案で
   簡単に取れるようにするのは、方針が一致していないのではないか。
   (ポリシーWG/中川)
]]><![CDATA[
A. APNICで厳しくなったものを緩くしよう、という提案なので、コンフリク
   トはないと考えている。また、死蔵してしまう空間の活用もこの提案のモ
   チベーションの一つ。(藤崎氏)
]]><![CDATA[
Q. 自分はこの提案に賛成の立場である。2006年までにアドレスの割り振りを
   受けていた組織は、追加で割り振りを受けることができ、これから割り振
   りを受けようとしている人にこのポリシー変更の結果は適応されない、と
   いう理解でよいか。
]]><![CDATA[
A. APNIC38で提案をした際には、今回の提案以外の部分で非常にめたので、
   今回は、まず範囲を区切って提案している。(藤崎氏)
]]><![CDATA[
Q. 格差が生じる、条件に差が生じるという理解でよいか。(奥谷)
]]><![CDATA[
A. その通りである。(藤崎氏)
]]><![CDATA[
C. 404件のうちの230件ほどの指定事業者がv6の割り振りを受けている。この
   うち60強、4分の1くらいはこのポリシー提案の適用対象となり、それ以外
   のそれ以外の事業者は、追加割り振りの条件を満たして追加割り振りを受
   けることになる。(川端)
]]><![CDATA[
C. 残りの事業者にも同様のアドレス割り振りを受けられるようにしようとす
   ると、スパースアロケーションにより新たな無駄が発生する等という意見
   があり、拡大するサイズ自体の議論になってしまうので、この提案だけ切
   り出している。公平性という意味では微妙なところがある。(藤崎氏)
]]><![CDATA[
C. 公平性と資源の有効活用という二つの側面がある。個人的にはv6はアドレ
   スがあるうちに　きちんと管理していくのがよいと思う。
]]><![CDATA[
C. アドレスを拡張すれば維持料は高くなるので、無駄に広げることはある程
   度防げると思っている。(藤崎氏)
]]><![CDATA[
C. コンセンサスになったとしてもAPNICのポリシーSIGに持っていく必要があ
   る。ここでは、日本のアドレスコミュニティがこの提案をサポートするか
   の確認となる。(橘)
]]><![CDATA[
[挙手]
]]><![CDATA[
  総数：46
  賛成：17
  反対： 2
]]><![CDATA[
C. 提案の内容は不公平。拡張を受ける空間分、今後割り振りを受ける人が損
   である。]]></screen><para><anchor id="9"/> </para></section></section><section><title>9. VNNIC Update</title><section><title>Phan Thi Nhung (VNNIC)</title><screen><![CDATA[[質疑応答]
]]><![CDATA[
Q. 日本との違いは興味深かった。IPアドレスの移転が自由にできないという
   ことで、アドレスがないにもかかわらずメンバーが急激に増え続けている
   理由は。
]]><![CDATA[
A. メンバーになれば/22の割り振りを受けることができるため。少数ではあ
   るが、一部の会員はアドレスが足りないためにライセンスをもう一つ取っ
   て/22の割り振りを受けており、調べると同じASから異なるレンジのアド
   レスが流れていることがある。(Nhung氏)
]]><![CDATA[
Q. 金融機関のメンバーが多いが、なにか理由はあるのか。(奥谷)
]]><![CDATA[
A. 特定のISPのポリシーに依存しない、セキュアなネットワークを運用した
   いということで4～5年くらい前から金融機関などの会員が増えている。
   (Nhung氏)
]]><![CDATA[
C. JPOPMの活発な議論に驚きつつ、この場に参加できて嬉しく思う。また
   VNNICとJPNICの相互協力について、とても素晴らしいと感じている。]]></screen><para><anchor id="10"/> </para></section></section><section><title>10. [I]IPv4アドレスの国際移転をやってみた</title><section><title>川端宏生(JPNIC)、有沢怜士那(北電情報システムサービス株式会社)、百崎 知(ソネット株式会社)</title><screen><![CDATA[[補足事項]
]]><![CDATA[
・国際移転のきっかけについて
  - 顧客のサービス拡充によるアドレス需要のため。(有沢氏)
  - 営業の努力により、ユーザが増加し、それに伴ってアドレスの需要が増
    したため。新サービスの開始に伴う需要増もあった。サービスの終了は
    新サービス開始後のタイミングになるため、どうしても新サービス開始
    時には需要が急に増えることになる。(百崎氏)
]]><![CDATA[
・国内ではなく国際移転となったきっかけについて
  - 一番はタイミング。(有沢氏)
  - 国際移転の方が早く大量に確保できそうだったため、初めから国内移転
    は考えず国際移転を選んだ。(百崎氏)
]]><![CDATA[
・相手先探しについて
  - たまたまブローカーさんと会う機会があり、話が進んだ。(有沢氏)
  - APNICのページにあるブローカーに当たった。なんとなく雰囲気の良さそ
    うなところを選んだが、決め手に欠ける状況だった。アドレス量と希望
    金額を聞かれて、考えた末ブローカーに伝えたところ、ブローカーが数
    日で相手先を見つけてきてくれた。(百崎氏)
]]><![CDATA[
・交渉、手続きに際して
  - ブローカーを2社挟んでのやり取りとなったため、スピード感がなく苦労
    した。契約までは2ヶ月だったが、実際に移転が完了するまでに7ヶ月か
    かってしまった。(有沢氏)
  - 英語でのやり取りに苦労した。また、商習慣の違い、速度感の違いを感
    じた。弊社のケースでは契約までは3ヶ月だったが、その後、移転の完了
    までは半月しかかからなかった。しかし、移転を行う方には余裕を見て
    移転を進められることをお勧めしたい。(百崎氏)
]]><![CDATA[
・移転後のアドレス利用について
  - 過去のアドレス利用の経緯等については可能な範囲で調べた。
    (有沢氏、百崎氏)
  - 早めに経路広告を始めるなど、従来の割り振りアドレスに比べ、より手
    厚くケアしている。(百崎氏)
]]><![CDATA[
・移転を考えてている方へ
  - 社内で価値を説明するのに非常に苦労する。CGNやv6との比較も必ず出て
    くる。ほかにアドレスを入手する手段がない以上、必要なことではある
    が、移転はあくまでも一つの選択肢とすべき。(百崎氏)
]]><![CDATA[
[質疑応答]
]]><![CDATA[
Q. 支払いは外貨建てだと思うが、どういう名目で支払ったのか。
　
A. 固定資産として「アドレス購入」という費目を立てた。(百崎氏)
]]><![CDATA[
Q. ブローカーとの契約の際、社内で稟議を通すのはた大変だったか。どのよ
   うにリスクヘッジをしたのか。(佐藤晋)
]]><![CDATA[
A. 与信調査をして、ブローカーを信頼できるかどうかを見極めた上、契約を
   進めた。また、リスク分散として移転を2回に分けた。(有沢氏)
]]><![CDATA[
A. アドレスが来ない可能性をリスクと考え、リスクヘッジのために銀行を間
   に入れて信頼を担保させた。(百崎氏)]]></screen><para><anchor id="11"/> </para></section></section><section><title>11. [I] 番号資源におけるIANA機能の監督権限移管の状況アップデート</title><section><title>奥谷泉(JPNIC)</title><screen><![CDATA[[質疑応答]
]]><![CDATA[
Q. 今回、NTIAが移管の意向を表明したきっかけとして、状況の変化があった
   というのは分かるが、政府主導であったために何か問題があったのか。
]]><![CDATA[
A. 特にない。(奥谷)
]]><![CDATA[
Q. そこが問題だと思う。ビジネスサイドから見ると、問題なく機能している
   のなら従来通りでよいのではないかという意見が出てくるのは当然だと思
   う。変更自体が何らかの混乱を招くが、それを上回るメリットがあるのか。
]]><![CDATA[
A. 技術コミュニティからも、現状維持を望む声が多かった。APNICも変更は
   最低限に留めることを望む意見としている。(奥谷)
]]><![CDATA[
C. 米国の一国支配を問題視する声もあり、一方、米国企業の人たちは現状維
   持を望んでいる。(橘)
]]><![CDATA[
C. 米国の一国支配を問題視する人たちが、スノーデン事件をきっかけに声を
   上げた。NTIAも、これを契機として動き出したような状況である。
]]><![CDATA[
C. この動きは当初の予定にあった動きでもある。
]]><![CDATA[
Q. ITUなど、これに便乗して声を上げる人たちはいないのか。
   (ポリシーWG/豊野)
]]><![CDATA[
A. 人権等に関する問題を取り上げているという話は聞かない。ICANNは来年
   9月までに議論が進むよう、WGが設立されるなどしている。(奥谷)
]]><![CDATA[
C. 補足として、プロトコルパラメータ、名前、番号の3つがあるが、プロト
   コルパラメータは単純なので確実に終了する。番号については12月までに
   収束させるのには難航する可能性がある。名前は本当に大変だが、週次で
   ミーティングを行いつつ精力的に進められている模様。]]></screen><para><anchor id="12"/> </para></section></section><section><title>12. Open Mic</title><section><title>橘俊男(ポリシーWG)</title><screen><![CDATA[・実施せず]]></screen><para><anchor id="13"/> </para></section></section><section><title>13. JPOPM27クロージング</title><section><title>橘俊男(ポリシーWG)</title><screen><![CDATA[・提案の今後の取り扱いについて
  - 027-01についてはコンセンサスとする。ただし、ポリシー提案ではない
    ので、勧告等は行わず、JPNICでの検討、対応を期待する。
  - 027-02についてはコンセンサスとはせず、今後の活動を提案者に委ねた
    い。
  - 027-03については、次の場での提案を、提案者にて進めていただき、活
    動をサポートする。]]></screen></section></section></section></article>