JPNICJavaScriptが無効になっています。JavaScriptを有効にしてご利用いただくことで、より快適にご利用いただけます。2010年3月7日から12日にかけて、ケニアのナイロビで開催されたICANN会議のレポートをお届けします。アキバプラザで開催いたします。2010年3月7日から3月12日まで、ケニアの首都ナイロビで、第37回ICANN会議が開催されました。認されましたので、会合の焦点は、新gTLDに関する議論に向けられました。今回の開催地ナイロビは、外務省が発している海外安全情報によると、4段階ある危険度の1段階目である、「十分注意してください」とされていました。Centreが標的とされているとする情報を得たとして、2月中旬から頻繁にセキュリティ情報のアップデートを提供していました(*1)。http://nbo.icann.org/security/ICANNはこの状況の中で、現地当局やホストとの協力の下、会場と推奨ホテル、その間の交通手段などでセキュリティ確保対策を敷いた上で、ナイロビ会議を予定通り開催することを決めました。それでも、セキュリティ懸念から、渡航を自粛した参加者も少なくありませんでした。実際、日本からの参加者は10人に満たず、リモート参加で登壇する発表者も目立ちました。者は、概ね現地入りしていたような印象でした。一度だけ市中を歩いてみたときも、東アフリカで最も発展した国の首都ということで、街行く人々はビジネスマンが大半で、事前に提供されていた情報から想像されるような脅威を感じることはありませんでした。ApplicantGuidebook(以下DAG)第3版が発表され、これに基づいた議論が続いています。Procedure)について、議論が行われました。RPM以外の課題としては、IDNにおける3文字制限の問題が検討されました。IDN異体字については、2月にパブリックコメント募集がかかった状態でナイロビ会議を迎え、議論が持たれました。向の緩和策が決議されるとともに、その他の課題についても、4月初頭のパブリックコメント募集終了を待って、DAG第4版に盛り込むとしています。議が二つなされました。Interest:関心表明)提案の取り下げです。回ソウル会議の理事会で、事務局に検討を指示する決議がなされ(*2)、以降パブリックコメント募集も含めて検討中でした。断がなされたようです。一つは、レジストリ・レジストラ分離に関する問題です。今のところ、DAG第4版は2010年6月に開催される予定のブリュッセル会議前に公表されることになっていますが、RPMを中心にさまざまな課題がまだ解決していない現状から、どのような収束が図られるのか、注視が必要な状況です。今回のICANN会議は、アフリカ開催だからということか、現地の業界や参加者とICANNの主要メンバーとの交流が図られるイベントが目に付きました。ケニアICT協会とICANN理事・出席者との交流ディナーがアレンジされたり、GNSO恒例の朝食会合に現地業界団体の代表が参加したりしていました。無二な会合であることは確かです。ICANNの主要メンバーが、アフリカのインターネット振興に関しても積極的に取り組んでいる姿が印象的でした。次回ICANN会議は、2010年6月20日から25日まで、ベルギーのブリュッセルで開催される予定です。◇2010年4月20日(火)に開催予定の、第27回ICANN報告会(東京、富士ソフトアキバプラザ)でも、ICANNナイロビ会議の詳細についてご報告いたします。ご興味のある方はぜひご参加ください。クラウド分野においては、海外勢が先行しています。Service)の利用者分布に関しては、北米93%、欧州6%、アジア1%、と極端に偏っています。原因として、Amazon社とRackspaceHosting社などのIaaSを得意とするクラウドサービス事業者が北米に集中している点があげられます。アジア、そして、日本の事業者の苦戦が顕著となっています。総務省は、2010年2月10日に、「スマート・クラウド研究会中間取りまとめ(案)」(*1)を公表しました。上を図ることが必要であるとしています。2009年7月に、産官学によるグローバルクラウド基盤連携技術フォーラム(GICTF)(*2)が設立されました。クラウド間の連携インタフェースやネットワークプロトコルなどの標準化を推進し、より高信頼、高品質かつセキュアなクラウドサービスを提供するための研究開発を進めています。日本が、世界のクラウド市場での存在感を示していくためのさまざまなアプローチが、今後、さらに重要になっていくのではないかと感じています。2006年より、NTTコミュニケーションズ株式会社u-Japan推進部(ICTコンサルティング部)にて、情報通信政策の調査分析や、クラウドコンピューティング関連プロジェクトなどを担当。IPv6のアドレス長は、32ビットのアドレス長を持つIPv4に比べて、4倍となる128ビットになります。記するという方法とは異なる、新しい表記方法が採用されています。IPv6では以下の例のように、16ビットごとに「:(コロン)」で区切った上で、16進数で表記することが、RFC4291(*1)で定められています。2001:0db8:1234:5678:90ab:cdef:0000:0000また、上記以外にも、IPv6の表記方法に関するルールが二つあります。一つは、「:」で区切られた部分(フィールド)がすべて0となり、この条件を満たすフィールドが2個以上続く場合、以下の例のように、0を省略して「::」と表記することができるというものです。そのようなフィールドが2箇所以上ある場合は、どちらを省略しても構いません。このルールは一つのアドレス内で一度しか使うことができません。2度以上省略してしまうと、どのフィールドを省略したのかが、わからなくなるからです。~~もう一つは、以下の例のように、「:」で区切られたフィールドの中で、先頭から連続する0を省略して表記することができるというものです。最低一つ以上の数値が表記される必要があります。~これらのルールを併用することにより、IPv6アドレスをより短く表記することが可能になっています。「::」と表記できる場合の例で示したように、同じIPv6アドレスでも、複数の異なる表記が可能となります。IPv6アドレスの利用者からは、この表記に揺らぎが生じる問題点が指摘されています。IETF(*2)では、この問題を解決するために、IPv6アドレスの推奨表記について、議論が行われています。わからない用語については、【JPNIC用語集】をご参照ください。トピックスとお知らせ一覧SNS2020年2019年2018年2017年2016年2015年2014年2013年2012年2011年2010年2009年2008年2007年2006年2005年2004年2003年2002年2001年2000年1999年1998年1997年Web更新履歴一覧2020年の更新履歴2019年の更新履歴2018年の更新履歴2017年の更新履歴2016年の更新履歴2015年の更新履歴2014年の更新履歴2013年の更新履歴2012年の更新履歴2011年の更新履歴2010年の更新履歴2009年の更新履歴2008年の更新履歴2007年の更新履歴2006年の更新履歴2005年の更新履歴2004年の更新履歴2003年の更新履歴2002年の更新履歴Q&AIPアドレスWHOIS/DBJPNIC認証局ドメイン名ニュースレター/メールマガジン会員JPNICについて統計よくある質問イベントカレンダー2020年2019年2018年2017年2016年2015年2014年2013年2012年2011年2010年2009年2008年2007年2006年2005年2004年2003年2002年2001年2000年1999年1998年1997年1996年1995年1994年1993年WHOISGateway表示例このページを評価してくださいこのWebページは役に立ちましたか?役に立った役に立たなかったどちらとも言えないページの改良点等がございましたら自由にご記入ください。回答を差し上げられません。回答が必要な場合は、お問い合わせ先をご利用ください。Views)登録パスワードが記載された確認メールが発送されます。再度ご登録手続きを行ってください。Views)登録パスワードが記載された確認メールが発送されます。再度ご登録手続きを行ってください。