tag:www.rfcnews.jp,2007://1 2007-09-17T06:52:55Z RFCの日本語訳（概要部分）を随時掲載しています。 Movable Type 3.21-ja tag:www.rfcnews.jp,2007://1.2571 2007-09-15T00:24:26Z 2007-09-17T06:52:55Z

MIB Textual Conventions for Uniform Resource Identifiers (URIs)

Editor RFC 5017として勧告された。 　このMIBモジュールはURI（STD 66）を表現するための省略表記を定義している。独自の表記方法を持つMIBモジュールで導入される。]]> David McWalter（編集担当、Data Connection） tag:www.rfcnews.jp,2007://1.2573 2007-09-15T00:24:12Z 2007-09-17T07:18:27Z

Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)

Editor RFC 5008として承認された。 　RFC 5008は、RFC 3851で定義されているS/MIMEにおける米国国家安全保障庁のスイートBアルゴリズムを使うための方法について定義している。]]> Russell Housley（Vigil Security）、Jerome A. Solinas（米国家安全保障局国家情報保障研究所） tag:www.rfcnews.jp,2007://1.2572 2007-09-15T00:24:05Z 2007-09-17T07:04:04Z

DHCPv6 Leasequery

Editor RFC 5007として勧告された。 　RFC 5007はDHCPv6でリース期間を問い合わせるやりとりの仕様を定めて、DHCPv6クライアントがDHCPv6サーバーからリース期間の情報を取得できるようにする。RFC 5007は取得できるデータの範囲と、DHCPv6のリース期間問い合わせの要求とサーバー側の処理を定義している。]]> John Jason Brzozowski（Comcast Cable）、Kim Kinnear（シスコシステムズ）、Bernard Volz（シスコシステムズ）、Shengyou Zeng（シスコシステムズ） tag:www.rfcnews.jp,2007://1.2570 2007-09-08T00:41:00Z 2007-09-09T11:22:06Z

Feed Paging and Archiving

Editor RFC 5005として勧告された。 　RFC 5005は3つのタイプのWebフィードを定義して、1つ以上のフィード文書にまたがるエントリーを発行できるようにする。 　ページ化フィードは、フィードをページに分けた形態であり、アーカイブ化フィードはフィードの内容を再構成できる形態であり、完全フィードはすべてのエントリーを含む形態である。]]> Mark Nottingham tag:www.rfcnews.jp,2007://1.2569 2007-09-08T00:40:48Z 2007-09-09T11:05:33Z

Avoid BGP Best Path Transitions from One External to Another

Editor RFC 5004として勧告された。 　RFC 5004では、ある条件下における外部の経路間の不要な最良経路の遷移を回避するBGPの経路選択ルールの拡張が提案されている。この拡張により、ネットワーク全体の安定性が高まり、さらに重要なことに、1つのBGPスピーカーが引き起こされる外部経路の遷移が繰り返される現象をなくせる。]]> Enke Chen（シスコシステムズ）、Srihari R. Sangli（シスコシステムズ） tag:www.rfcnews.jp,2007://1.2568 2007-09-08T00:40:31Z 2007-09-09T10:56:09Z

Media Server Control Markup Language (MSCML) and Protocol

Editor RFC 5022として承認された。 　MSCMLとは、SIPとともに用いて、先進的なカンファレンスとIVR（Interactive Voice Response：音声自動応答）を実現するためのマークアップ言語である。MSCMLが表現するのは装置レベルの制御モデルではなく、アプリケーションレベルの制御モデルであり、IETFのSIPカンファレンスフレームワークにおいて、カンファレンスフォーカスとミキサー間の通信を実現するために利用できる。]]> Jeff Van Dyke（Cantata Technology）、Eric Burger（編集担当、BEA Systems）、Andy Spitzer（Bluesocket） tag:www.rfcnews.jp,2007://1.2567 2007-09-08T00:40:04Z 2007-09-09T08:55:13Z

The Dynamic Host Configuration Protocol Version 4 (DHCPv4) Relay Agent Flags Suboption

Editor RFC 5010として勧告された。 　RFC 5010はDHCPリレーエージェント情報オプションの新しいサブオプションを定義して、DHCPリレーで転送されたパケット用に2つのフラグを付けられるようにする。 　1つのフラグは、DHCPリレーがパケットをユニキャストパケットで受信したか、ブロードキャストパケットで受信したのかを示すためにある。DHCPサーバーがこのフラグを使って、クライアントからの要求が元々ブロードキャストなのかユニキャストなのかで扱いを変えられるようになる。]]> Kim Kinnear（シスコシステムズ）、Marie Normoyle（シスコシステムズ）、Mark Stapp（シスコシステムズ） tag:www.rfcnews.jp,2007://1.2566 2007-09-08T00:39:48Z 2007-09-09T08:43:33Z

Survey of Research towards Robust Peer-to-Peer Networks: Search Methods

Editor RFC 4981として承認された。 　最近5年間のP2Pネットワークに関する研究の進歩は、P2Pを重要視した調査が真実であったことがわかる。P2Pは破壊的な技術となる可能性を秘めており、導入コストや拡大コストをなるべく抑えながら、膨大な量のストレージや処理能力を集約しうる。ただ、従来型アーキテクチャに比べれば個々のエラーの影響はずっと少ないとはいえ、分散された膨大な数のピア間ではエラーが日常茶飯事であり、すでにあるファイル共有以上のアプリケーションをP2Pで実現する鍵となるのは頑強さである。 　RFC 4981ではまず、P2Pに分類されるあらゆる技術における検索方式を調べている。Plaxtonツリーやリング、tori、バタフライ、de Bruijnダイグラフ、スキップグラフに基づく、簡単なキー検索用P2Pインデックスを評価し、同様にキーワード検索や情報取得、データ管理用のP2Pインデックスについても調べている。最後に、検索範囲の最適化やマルチ属性、参加、P2Pインデックスの問い合わせの集約に関する初期の模索についても評価している。 　検索方式について基本文献で言及されている限りにおいて、RFC 4981では頑強さのメカニズムとその指標に重きを置いているが、文献中では頑強さにもっとも影響を与える低レベルメカニズムが上位のメカニズムきちんと分離していない。RFC 4981には将来の研究用の推奨仕様も含まれる。]]> John Risson（ニューサウスウェールズ大学電子工学通信学部）、Tim Moors（ニューサウスウェールズ大学電子工学通信学部） tag:www.rfcnews.jp,2007://1.2565 2007-09-06T15:56:19Z 2007-09-09T07:49:31Z

WITHIN Search Extension to the IMAP Protocol

Editor RFC 5032として勧告された。 　RFC 5032はIMAPのSEARCHコマンドに対するWITHIN拡張について述べている。IMAPのSEARCHは日時が指定された範囲内あるいは範囲外にあるメッセージを応答するコマンドである。SEARCHコマンドの既存のオプションであるBEFOREおよびSINCEでは、クライアントが指定した日時を基準に検索するのに対して、RFC 5032で定義されたOLDERおよびYOUNGERでは、クライアントが指定した間隔（秒）を基準にメッセージを検索する。 　WITHIN拡張は常時検索するクライアントで、一定間隔で検索処理を実行する性能がなかったり、ネットワークの帯域幅が不足していたりして、何度も同じ要求を送りたくない場合や、同じ応答を受け取りたくない場合に有用である。]]> Eric W. Burger（編集担当、BEA Systems） tag:www.rfcnews.jp,2007://1.2562 2007-09-06T15:56:07Z 2007-09-09T06:52:40Z

Automated Updates of DNS Security (DNSSEC) Trust Anchors

Editor RFC 5011として勧告された。 　RFC 5011はDNSSECのトラストアンカーの更新の自動化と認証、証明方法について述べている。この方法は、トラストポイントのキーセットにおけるN個の鍵のうちのN-1個の鍵の危殆化に対する保護になる。現行アンカーの存在によって確立された信頼に基づいて、他のアンカーを階層構造内に追加（究極的には置き換え）してもよい。 　このメカニズムにはリゾルバー管理のやり方を変更（リゾルバーの解決時のやり方ではない）し、DNSKEYレコードのフラグを1ビット追加する必要がある。]]> Michael StJohns tag:www.rfcnews.jp,2007://1.2561 2007-09-06T15:55:50Z 2007-09-09T06:29:55Z

Attachment Individual Identifier (AII) Types for Aggregation

Editor RFC 5003として勧告された。 　AIIとは、疑似有線（Pseudowire）エンドポイントを識別するTLV（Type Length Value）フィールドを含むポイント間疑似有線を確立するために用いるシグナリングプロトコルのことである。RFC 5003は、AII TLVフィールドの新形態となるAII構造体を定義して、スケーラビリティを改善し、VPN（Virtual Private Network）の自動発見用のAII集約に対応する。 　AII集約は、顧客のニーズに基づいて、選択されたローカルPE（Provider Edge）とリモートPE間で疑似有線が確立されている大規模なドメイン間の仮想専用線サービスネットワークで利用する場合に有用である。]]> Luca Martini（シスコシステムズ）、Chris Metz（シスコシステムズ）、Florin Balus（アルカテル・ルーセント）、Jeff Sugimoto（ノーテルネットワークス） tag:www.rfcnews.jp,2007://1.2564 2007-09-06T15:55:27Z 2007-09-09T07:18:48Z

Use of Addresses in Generalized Multiprotocol Label Switching (GMPLS) Networks

Editor RFC 4990として承認された。 　RFC 4990はGMPLSネットワークにおけるアドレスの使用について明らかにし、GMPLS対応のLSR（Label Switching Router）の互換性を高めることが目的である。RFC 4990は、実装や互換性のテスト、実運用での経験に基づいている。 　RFC 4990はGMPLSプロトコルでアドレスや識別子フィールドをどのように解釈すべきか、また、どのアドレスを特定の制御プレーンユーゼージモデルに当てはめるかについても述べている。さらに、IPv6の送信元と宛先アドレスをMPLS/GMPLSのトラフィックエンジニアリングMIB（Management Information Base）でどのように扱うかについても議論している。 　なお、RFC 4990は新しい手続きや処理は定義していない。要件の提示や推奨を示している部分は、規範となる参照先RFCから引用されたものである。]]> 塩本公平（NTTネットワークサービスシステム研究所）、Richard Rabbat（グーグル）、Rajiv Papneja（Isocore） tag:www.rfcnews.jp,2007://1.2563 2007-09-06T15:55:17Z 2007-09-09T07:02:41Z

The P-Answer-State Header Extension to the Session Initiation Protocol for the Open Mobile Alliance Push to Talk over Cellular

Editor RFC 4964として承認された。 　RFC 4964はOMAのPoCアプリケーションに限定される、SIPのプライベートヘッダー（Pヘッダー）について述べている。Pアンサー状態ヘッダーは特定のPoCアプリケーションがハンドセットの応答モードを示すために用いる。]]> Andrew Allen（編集担当、RIM）、Jan Holm（エリクソン）、Tom Hallin（モトローラ） tag:www.rfcnews.jp,2007://1.2560 2007-08-29T21:10:18Z 2007-09-08T12:23:38Z

Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name

Editor RFC 4985として勧告された。 　RFC 4985はX.509所有者代替名拡張に新しい名前を格納できるようにして、サービス名およびDNSのサービス資源レコードのドメイン名コンポーネントと証明書の所有者を関連付けられるようにする。]]> Stefan Santesson（マイクロソフト） tag:www.rfcnews.jp,2007://1.2558 2007-08-29T21:10:08Z 2007-09-08T11:58:33Z

Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover

Editor RFC 4986として承認された。 　DNSセキュリティに対応するすべてのリゾルバーは、DNS署名ゾーンからの応答を検証するために、少なくとも1つのトラストアンカーを持たなければならない。また、さまざまな理由により、DNSセキュリティに対応したほとんどのリゾルバーは、複数のトラストアンカーを持つことになっている。 　運用形態によっては、トラストアンカーの手動による監視と更新も可能だが、多くの場合はDNSセキュリティに対応したリゾルバーによる自動化されたトラストアンカーの更新が必要である。そこでRFC 4986は、DNSセキュリティに対応したリゾルバー用に、DNSトラストアンカーのロールオーバーを自動化するための要件を述べている。]]> Howard Eland（Afilias Limited）、Russ Mundy（SPARTA）、Steve Crocker（Shinkuro）、Suresh Krishnaswamy（SPARTA）