|
+
|
JPNIC の最小割り振りサイズは/22だと思うが、/23や/24と言った単位ではJPNICから割り振りを行っていないのではないか。 |
|
|
- 確実なことは言えないが、歴史的な経緯を含む古い情報であると思う。(IRR-Plan 長橋) |
|
|
|
|
+
|
sourceは RADB だけか？ |
|
|
- そうである(以上、IRR-Plan 長橋) |
|
|
|
|
+
|
Best Match だと整合が取れているのに、Exact Match だとそれほどない、というのは問題ではないか。 |
|
|
- /20でBest Matchされた、というのが、考察の結果である。 |
|
|
- なぜ、Exact Match だとこのような結果になるのかは、JPNICの管理ポリシーが関わっている。 |
|
|
- 最小割り振りサイズが/22だった時代には、その/22を含む/20分を将来追加割り振りのためにリザーブをしていた、という経緯がある。 |
|
|
- 割り振りを受けた/22を含む/20分を経路広告してよいことになっていた。 |
|
→
|
そのため/20で経路広告をしており、RADBにも登録をしていたと考えられる。(以上、IRR-Plan 長橋) |
|
|
|
|
+
|
JPNIC では過去に、/22を最小割り振り単位として割り振りを行っていた。
経路広告に関しては、リザーブ分を含めた/20を経路広告してよいということになっていたと思う。解放割り振りに伴って、指定事業者にはそれぞれ/20単位で割り振られていると思っている。(IRR-Plan
近藤) |
|
|
- 指定事業者向けのリストには割り振りを行った単位で登録されている。
現在のデータベースにも、割り振りを行った単位で登録するため、リザーブ分を登録することはしていない。(JPNIC) |
|
|
|
|
+
|
解放割り振りを行ったので、それぞれの指定事業者は/20単位でデータベースに登録されていると思う。だとすると、/22という情報はデータベース上に存在しないのではないか。この調査では、どのデータを参照するか、という問題があるのだが、JPNIC側のデータベースも実態に合わせてアップデートした方がよいという問題もあると思う。(IRR-Plan
近藤) |
|
|
- 解放割り振りの前後で/20単位に書き換えをしたわけではなくて、リザーブ分のうち未割り振り分の空間を追加してデータベースに登録することで対応を行った。そのため、実際は/20の空間を割り振られている指定事業者でも、データベース上は、/21と/22*2という形となっている。
(JPNIC) |
|
|
|
|
+
|
/16の割り振りを受けているISPが、追加で/16をの割り振りを受けており、複数回の割り振りをまとめれば/13程度の空間を持っているとする。BGP
のルーティング上で、ある回線は/16のprefixを割り当てて流したい、というようなことを、割り振りを受けた段階でやってしまうと、まとめることは難しいと思う。このようなケースは結構あると思っている。(IRR-Plan
吉田) |
|
|
- 実際流れている情報と割り振りを受けた情報が一緒になっている、ということもあると思う。(IRR-Plan 吉田) |
|
|
- オペレーション上は、/13の割り振りを受けた場合、/13をIRR に登録しているのではなく、分割したものを登録しているのか？(IRR-Plan
近藤) |
|
|
→/13で登録している。(IRR-Plan 吉田) |
|
|
|
|
+
|
/13という大きな単位ではなく、/20といった空間を/21*2に区切って使うような場合、どこかのExit Pointでは/20で流しているというケースもあると思う。その場合、IRR
には重複して登録することになると思うが、統計上、そのようなデータはどのように考えているか。 |
|
|
- つまり、/20と/21*2 の３つのルートオブジェクトを重複して登録している場合、それはどのように見ていて、統計上、どのようにカウントするのか、ということである。(以上、IRR-Plan
近藤) |
|
|
- Best Matchで見ている。Best Match では/20で/21以下をカバーすることでカウントしている。カテゴリとしてはBest
MatchとExact Matchのandなのだが、それはBest Matchの定義に当てはめて考えることは可能なので、Best
Matchで見ている。(IRR-Plan 長橋) |
|
|
- リクエストだが、どれぐらい重複しているケースがあるか調べて欲しい。(IRR-Plan 近藤) |
|
|
- できれば、アドレスブロックを見てみて、Best Match になっている原因を解析してみるともう少し考察を加えることができると思う。(以下のような点を検証してみればよいと思う)
|
|
|
- 集約できるはずだが、分けて経路広告をしている
- JPNIC からは集約した状態で割り振られているか、あるいは、ばらばらに割り振られたものだが、結果的に集約できる状態になっている。
|
|
|
- JPNICのデータベースとの比較と言う意味では、その点を検証してみると、データとしての意味付けがもう少し変わってくるのではないかと思う。 |
|
|
|
|
+
|
割り振りを受けているが、インターネット上に経路広告していないアドレスブロックについては、どのように取り扱えばよいと思うか。VPNサービスなどに使われていると、社内ではグローバルアドレスは使っているけど、経路広告はされていないケースがある。 |
|
|
- プライベートアドレスを利用してJPNICに返却することも考えられるが、MPLS-VPNサービス等ではプライベートでの運用は難しい。 |
|
|
- 逆にインターネット上のデータベースである、と考えているのであれば、経路情報を登録しない、というのが正しい姿なのかもしれない。
あるいは、全体としては使っていないが、一部分(メールサーバなど)には使っている(しかし、経路広告はしていない)ので、登録すべきであるかもしれない。 |
|
|
- ここで扱う議題ではないかもしれないが、統計情報を考える上での参考にして欲しい(以上、IRR-Plan 松本) |
|
|
- ブロック単位で流しているのであれば経路広告をすべきだと思う。流しているものを登録するのがよい思う。そもそもIRRはその情報を元にフィルタを書いている人もいるので。内部で使っているものは登録しなくてもよいと思う。(IRR-Plan
近藤) |
|
|
|
|
+
|
こういう統計情報を取った方がよいと言う意見はあるか(IRR-Plan 吉田) |
|
|
- 今回の項目に関して言えば、内容としては、以下の３パターンがあると思う。
- JPNICが割り振ったアドレスとIRRに登録されている情報との比較
- 実際に世の中に流れている経路情報とIRRに登録されている情報との比較
- 実際に世の中に流れている経路とJPNICが割り振ったアドレスとの比較
|
|
|
- JPNICが割り振りを行ったアドレスと、IRRに登録されている情報や実際に流れている経路との比較は、運用上あまり意味がないと思っている。 |
|
|
- 実際に世の中に流れている経路情報とIRRに登録されている情報との比較は、運用上は有用な情報になるのではないかと思っている。 |
|
|
- 以前にも問題になったと認識しているのだが、何をもって、どの情報を参照してインターネットの経路とするのか、まだクリアではない。 |
|
|
- 2,3箇所のISPとpeerをしてフルルートをもらっているが、全ての経路数を把握できる、と言うわけではないと思っている。(以上、IRR-Plan
長橋) |
|
|
- それぞれ経路数は違うのだが、経路数の違いはなぜ起きるのか、調べていくのもよいと思う。(IRR-Plan 吉田) |
|
|
- 本質的に観測場所によって経路数は違う。１箇所だけでサンプリングしても、世の中の全体の雰囲気はわからないので、協力してもらって複数の観測点でサンプリングするとより参考になると思う。また、調査項目も大事だが、ある程度継続的に観測する必要があると思う。 |
|
|
|
|
+
|
IRだと自分が割り当てたアドレスをIRRに載せたがるのだが、IRRには実際に経路広告する情報を載せる方がよいと思っている。 |
|
|
- RIPEのデータベースはinetnum(割り振り情報) とルートオブジェクトは一緒に扱える構造になっている。ルートオブジェクトは、任意で登録する項目となっているが、実際に経路広告する情報を載せましょう、という方針で運用をしている。それが一番よい方向なのかなと考えている。 |
|
|
- IRRdにはその機能がなく、またwhois のデータベースと連携していないという状況である。どのように連携させるかについても将来的に考えなければいけないと考えている。(以上、IRR-Plan
近藤) |
--------------------------------------------------------------------------
|
+
|
inet6numオブジェクトで確認できるので、ルートオブジェクトを登録する ことは必要なのか。 |
|
|
- Origin-ASを確認するためだけであれば、inet6num オブジェクトにオプショナルにそういうフィールドをつければ足りると考えている。 |
|
|
- 割り振りを受けたブロックサイズをそのまま経路広告する、ということが今後もずっと続くのか、ということについては疑問を感じている。 |
|
|
- なぜなら、今のルーティングシステムだと、prefixコントロールができないと考えている。 |
|
|
- 普通に考えると、たぶんinet6numオブジェクトでは足りないかもれない。経路として２つ目の大項目でどう守っていくか、と考えると、別の何らかのデータベースを持つ必要があると思う。今ある方法としてはIRRでやるべきなのかと思う。(以上
IRR-Plan 近藤) |
|
|
|
|
+
|
現状では、割り振りを受けたアドレス空間を分割しないで経路広告しているのか。 |
|
|
- 調べた範囲の結果では、分けて流しているケースは少ない。 |
|
|
- whois のデータと比較しても、割り振りを受けたアドレスブロックのサイズ同じ大きさの経路広告をしているものがほとんどである。(IRR-Plan
外山) |
|
|
- IPv6においては、まだマルチホームする余裕がない実態を表しているのだと思う。 |
|
|
|
|
+
|
「経路を流すべきでない」と書いてあったが、これは、レジストリなどから指導されているものか。 |
|
|
- 調べてみたところ、割り振りのポリシーによれば、「経路はできるだけ集成して広告しよう」という感じの記述があるが、割り振りを受けたサイズ以外で経路広告してはいけない、といった内容は、ポリシ以外にも特には見当たらなかった。(IRR-Plan
外山) |
|
|
|
|
+
|
レジストリとしては、集成できるように考えた割り振りサイズとなっているが、分割して経路広告したいという運用上の要望もあると思う。 |
|
|
- 実際にIPv6が普及してくると、運用する側では、かなりそれなりの使い方が出てくると思う。もともとIPv6を設計した人々にも、経路表の増大を防ぐことが必要という認識はあったと思う。そのポリシーとどのように折り合わせていくのか、についても気になっている点である。(IRR-Plan
外山) |
|
|
- /48 でも相当大きいサイズであると認識している。このサイズで経路広告したいと考えている人は多いと思う。(IRR-Plan
近藤) |
|
|
|
|
+
|
10枚目のスライドで、/35が28個との記述があるが、これは昔に/35で割り振りが行われていたもので/32に移行したものであると認識している。
inet6numオブジェクトは/32だが、現在も/35で経路広告し続けているものが28個あるという意味か。それとも、敢えて/35で流しているものか。個人的には前者であると考えているのだが。(IRR-Plan
吉田) |
|
|
- そこに関しては、本来の意図に関しては判断できる材料が少ないが、descr:の欄に/35から/32に移行する旨のコメントが入っているものが多かったと思う。それが28個全部であったかどうかについてはわからない。(IRR-Plan
外山) |
|
|
- /35から/32への移行は申し込み制だが、その割には大部分が移行したような印象をもっている。 |
|
|
- /35から/32への移行したときに、どこかのルータが調整がうまくいかず、/35の経路を流しつづけるという現象が起きた。そのため、カウンターを当てるという意味で、/35を流しつづけたということもある。 |
|
|
- 割り振りブロックだけを経路広告する、ということは少ないのではないか。(IRR-Plan 近藤) |
|
|
- ただやはり、今は必要ではなくても、なんらかの方法を考えていく必要があると考えている。どうせやるなら早いうちにやる必要があると考えている。(IRR-Plan
近藤) |
|
|
- どこがIRR をやるべきかという話にもなると思うが、IPv6の現在の状況もふまえて、私はレジストリがやるべきであると考えている。IRRとwhoisを一緒に運用するかはさておき、レジストリがこれらを運用して、両方見てちゃんとチェックが入る機構が動いているのが望ましいと思う。(IRR-Plan
近藤) |
|
|
- ミラーについては、(IETFドラフト的には)CRISP 等が動いていると思うが、ちゃんと最初からワールドワイドでミラー出来るものを考えて、パブリックな経路情報とプライベートな経路情報を共存させていくような仕組みを考えていかないと、IPv4と同じような状況になってしまうと思う。現在はまだクリーンな状態なので、検討していけば良いのではないかと思っている。(IRR-Plan
近藤) |
|
+
|
IRRの情報はエンドユーザが登録することが少なくて、ISP が登録していると思う。そうすると、ISPは登録するオブジェクトのリストを持っていると想像する。通知が来ると(あるいは来る前に)、changedを更新をしてしまうと思う。そうすると更新を促すメールはこなくなる、ということにならないか。 |
|
|
- この仕組みのそもそもの目的は、長期間更新されないのであれば、オブジェクトを消してしまおうというところにある。ISP
が持っているファイルファイルを元にして、上のようなことがされていれば、それなりに更新されていれば、IRR の健全性は保てると考えている。(IRR-Plan
近藤) |
|
|
- 上の質問の意図は、オブジェクトの中身については全然更新せず、changedフィールドのみを機械的に更新してしまえば、このシステムをすり抜けることはできるのではないか、という意図だと思う。(IRR-Plan
吉田) |
|
|
- 例えば、100 個のルートオブジェクトのリストを持っていて、それをいちいち有効かについて調べたりすることはないと思う。(IRR-Plan
松本) |
|
|
- 本当は変更の必要のあるオブジェクトなのだが、情報変更が面倒なのでchangedフィールドのみを書き換えるようなケースが当てはまると思う。確かに100
個もあれば面倒だと思うが、この仕組みを使うと更新されていないものだけが届くと思うので、５件ぐらいであれば調べると思う。(IRR-Plan
松本) |
|
|
- 自動的に対応できるようにされてしまうと打つ手はないが、最初は多く通知が来るかもしれないが、こまめに情報が更新されていれば、通知も少なくなるだろうし、結構見てくれるかなと考えている。(IRR-Plan
松本) |
|
|
- 確かに、そのような状況になることは否めないが、期待として言えば、JPIRR 側でフォーマットや通知される情報を示しておくことが必要であると思う。また、通知がきた時点で情報と照らし合わせて、欠けている情報を埋めてくれるようなスクリプトを作ってもらえると嬉しい。
ISP側でもちゃんと管理をして欲しいと考えている。(IRR-Plan 近藤) |
|
|
- しかし、効果については実装してみないとわからない面もある。(IRR-Plan 近藤) |
|
|
- 正しい日付で登録するのであるから、当然、登録に対して責任が生ずると考えている。なので、あまりいいかげんなことはできないと考えている。ただし、顧客管理の部門と運用の部門は必ずしも同じというわけではなく、運用の部門が忙しかったりすると顧客管理まで手を回せないということもあると思う。 |
|
|
|
|
+
|
実際の経路情報と比較して、異なっているものだけを取り上げて通知する、といったこともできるのではないかと考えている。そうすると、日付だけ眺めていっせいに書き換える、ということもなく、実際に変更があったものだけを書き換えるようになるのではないかとも考えている。(IRR-Plan
衛藤) |
|
|
- それも良い考え方だとは思うが、JPIRR では経路を全部見ているわけではないので、見えない経路についてはどうするか、ということを考えなければいけないと思う。 |
|
|
- RIPEでは、RIS というのを使っていて、AS番号とルーティングテーブルを見てチェックしてメールを出してくれる仕組みがある。ある程度の地域(例:JP)を区切ってみれば、ある程度できるのではないかと思う。 |
|
|
- そのときに問題になるのが、先ほども出てきた、経路広告をしていないのにも関わらず、IRRに登録してしまっているケースである。IRRには登録しない方が良い、というスタンスに立てば、そのオブジェクト自体を消してもらう方向を考えるのしかない、とも思う。(IRR-Plan
近藤) |
|
|
- ルーティングテーブルは、どこで見るかによって見え方が変わってくるので、(たまたま)見えていない経路情報に対して通知が行ってしまう、というケースも考えられる。(件数は多くないと考えている) |
|
|
|
|
+
|
長期間更新されないと、ステータスがExpireからDisposalへと変化していくが、メンテナーオブジェクトの場合もこの方針で運用するのか。メンテナーオブジェクトがなくなってしまうとルートオブジェクトも何もなくなってしまうのだが。(IRR-Plan
吉田) |
|
|
- まだ設計段階なので何ともいえないが、あるメンテナについて、あるメンテナが持っているオブジェクトを全部チェックするような仕組みにしようと思っている。なので、そこは対処の仕方があるのではないかと考えている。(IRR-Plan
衛藤) |
|
|
- 仕組みを実装する前に、ルーティングテーブルに載っていない経路と更新期間の相関については調べておいた方が良いと思う。 |
|
|
- 今すぐはないかもしれないが、メンテナーオブジェクトに登録されているnotificationのアドレスと、受け取るべきメールアドレスがExpireしている場合には、どう対処するか考えておいた方がよい。 |
|
|
- IRR のオペレーション的な負担はできるだけ少なくしておきたい、と考えている。もし届かなければ、自己責任としても良いのだろうか。
それについては、みなさまからの意見を聞きたいと考えている。メールが届かないときのことを考えて、住所や電話番号を聞くのであれば、それだけ重たいものになってしまうし、運用する側のオペレーションも煩雑になってしまう。(IRR-Plan
近藤) |
|
|
- メールが届かないのであれば届かないのでも良いと思う。
しかし、メールが届かないのであれば、返事がないものとしてメンテナーオブジェクトが消されてしまうことを、あらかじめ示されておく必要があると思う。 |
|
|
- ルーティングテーブルに載っている情報は、最新の情報に更新しておかないと、パケットがはじかれるという意味で、アクティブな情報であると考えている。しかし、IRR
の情報に余計なものが載っていても基本的にネットワークの運用には悪さをしないので、どうして残しておいて悪いのかという疑問に突き当たる。もちろん不要なものは残さないという原則については異論はない。 |
|
|
- ルーティングテーブルに余計な情報がある、ということを比較すると、常に緊急性は低くなってしまう。という根本的な性質があると思う。
また、他人の経路(アドレス)を登録するときは、他人のものは自分のものだと主張している面もあるので、若干見識を問われてしまう。そうでない限り、種類を多く登録してしまった結果、ごみが残る、といったこともあると思う。なので、IRR
の緊急性については個人的には疑問に思っているところである。 |
|
|
- 正直なところ、それほど緊急性は高くないと考えている。RIPEやRADB等では、古いIRR の情報が残っており、しかも実在しない経路で、情報が他人のものであるというケースもあると聞いている。
データベースに新たな情報を追加してもらうようにお願いしたときに、連絡が取れないオブジェクトが多くあり、そのオブジェクトを削除してもよいのかもわからないという状態になっている。このような状況は古いIRRでは現実のものとなっている。古いIRRでは、そのようなデータも多く、データの総量もどんどん増えている。オペレーション上も現実問題として、どんどん煩雑になってきているらしい。(IRR-Plan
近藤) |
|
|
- JPIRR としては、それほどの緊急性はないと考えているが、あらかじめ考えておく必要はあると考えている。そこでポイントになるのが、Expireまでの期間(t)である。１年なのか２年なのか、あるいは半年なのは考えどころだと思っている。(IRR-Plan
近藤) |
|
|
- ルーティングテーブルに載ってしまうということは、アクティブになっているということである。本来なら流れてはいけない経路が流れてしまうということもあるかと思うが、そもそも、そういう状態を作らないようにしたいと運用側は考えていて、そのためにIRRというものがあって、IRRの情報を参照すれば、BGPのルーティングテーブルに載せない、ということもできると思っている。そういう意味では、データベースを正しいものに作っていくということが必要で、例えば、一つの解としてこれまで述べてきたような仕組みがあると思う。(IRR-Plan
吉田) |
|
|
- 緊急性と登録の方針というのは鶏卵問題と同じで、古いから使えない、使えないから登録しない、という感じで悪循環になっていると思う。情報をシャープにして使いやすい形に切り替えるとアクティブな使い方をする人も出てくると思っている。(IRR-Plan
衛藤) |
|
|
- IRRにゴミ情報を多く登録しておくと、IRRの信頼性を失うことになってしまう。ゴミ情報が入っているからIRRはだめだ、という人も多いので、そういう意味で、努力をして示していかないと、IRRのブランドイメージも落ちると思う。 |
|
|
- そもそもこの活動を始めたのは、RADB(Merit)が有料化され、IRRを取り巻く情勢が変化してきた、というのがきっかけなのだが、いろいろと調べているうちに、最初の頃はBest
Matchを調べても100%にもならないし、Exact Matchにしても4%ぐらいにしかならなかった。APNICがIRRサービスを開始した頃には、50%ぐらいがゴミデータであった。
どこのIRRでも、ゴミ対策に力を入れていて、IRRの信頼性確保というのは非常に大事であると考えている。(IRR-Plan
近藤)
|
|
|
- 2年前に比べれば、ゴミオブジェクトもかなり減ってきているので、良い環境になりつつあると認識している。(IRR-Plan
近藤) |
|
|
|
|
+
|
IRRを使っている人は、IRRに対するモチベーションは高くないように感じている。使っている人にとってわかりやすいメリットがあれば、もっとIRRが使われるだろうし、それについて何かアイデアがあれば教えて欲しい。(IRR-Plan
衛藤) |
|
|
- RADBに登録をしていないと、あるサイトに接続できないという話を聞いたことがある。そういうのよりは、JPIRR
の価値が上がって、日本の人たちはJPIRRにさえ登録しておけばRADBに登録しなくてよい、という方向に進んでいけば、RADBを重視している人たちも自然にJPIRRを重視するようになると考えている。(IRR-Plan
松本) |
|
|
- ネガティブに、「JPIRRに登録していないとだめだ」という感じにならないか。(IRR-Plan 外山) |
|
|
- 現実問題として、メリットを与えるのは非常に難しいと考えている。
「適切にオペレーションする」ということもそれほどメリットではないと思う。日本人的な気質から考えると、登録することがルールである、といえば、登録してもらえるので、そこには期待している。日本でできるだけで、モチベーションはあがってくるだろうと期待している。(IRR-Plan
近藤) |
|
|
- AS lookupみたいなIRRを積極的に利用するツールが増えてくると、正しい情報が登録されていないと面白くないと思う。そのあたりにも、IRRにデータを正しく登録することによるメリットがあると思う。なので、あのようなツールを普及させるのもよいと思う。 |
|
|
|
|
+
|
JPIRRに情報を登録したら、RADBには登録をしなくてもよいのか、という質問を良く受ける。明快な回答はないと思うのだが、明快な回答を作る、もしくは参考となるような情報を考えるとすれば、どのような候補(項目)があるか。(IRR-Plan
松本) |
|
|
- サービスが確実に停止しない状況になれば、RADBなどへの登録が不要になるという見方をしてよいのか。(IRR-Plan
松本) |
|
|
- 例えば、CWなどではRADBのデータを参照しているが、RADBにあるJPIRRの情報を参照しているかどうかははっきりとわからない。情報を確実に参照できる等といった、「JPIRRで大丈夫である」といわれるための課題などがあれば教えて欲しい。(IRR-Plan
松本) |
|
|
- 私が運営しているIRRでは、ミラーした情報は提供するが、データベース自体を参照してもらっても、自分が持つ情報とRADBの情報ぐらいしか提供していない。基本的にも我々もRADBの情報を参照している。本来の分散データベースという意味では間違っているかもしれないが、
全てのIRRをミラーリングすることは困難なので、RADBに頼っているのが現状である。 |
|
|
- one-pathでそのサーバが持っている情報を渡すことを検討している、ということを前回のBoFで話した。JPIRRとミラーをすれば、RADBが持っているLIRの情報を参照できるような仕組みを作れば、先ほどの話のような障害はなくなるのではないかと思っている。(IRR-Plan
松本) |
|
|
- いくつかのIRRとPeerを張って冗長性をもたせれば、自分の持つデータベースを参照できるようになれば文句ないと思う。ただ、ニュースグループのリストみたいに、IRRのリストはメンテナンスしなければいけないということになるのだろうか。 |
|
|
- リストをメンテナンスする形式であれば、現在でも機能的に実現可能である。そうではなくて今考えているのは、ここのIRRから情報をもらうという設定をすると、全てのIRRの情報が参照できる、というものである。 |
|
|
- ただし、いろいろなハードルがあって、まだ難しい状況にある。まず、AUPの関係で、RIPEはAPNICを経由せずに直接ミラーリングすることを希望している。とりあえず、直接ミラーリングすることにして、今後我々が希望する形式でミラーリングが行えないかどうかを打診している。今後のRIPEのミーティングにおいて提案を行う予定をしている。(IRR-Plan
近藤) |
|
|
- ミラーリングの問題が解決すれば、実装の問題なので、うまく動くようにしたいと考えている。(IRR-Plan 近藤) |
|
|
- RIPEでは、ミラーリング先に情報を渡す際に、個人情報を削除して参照させる仕様を検討している。RIPEの考えは、データベースの個人情報の(責任から見た)重さを軽くして提供しようというものである。これが進めは、ハードルはだいぶ低くなると考えている(IRR-Plan
松本) |
|
|
- 現状は実験ベースなので、あまり考えていないが、IRRが正式サービスになれば、個人情報の公開については、JPNICの情報公開ポリシーに則って実装していきたいと考えている。(IRR-Plan
近藤) |
|
|
- 個人情報の公開については、IRRコミュニティの共通の問題にもなって |
