RFC 3299 - Request for Comments Summary RFC Numbers 3200-3299 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc3299
タイトル : RFC 3299 - コメントの概要RFC番号3200から3299の要求
翻訳編集 : 自動生成

[要約] RFC 3299は、RFC番号3200-3299の要約を提供します。このRFCの目的は、この範囲のRFC文書の概要を提供することです。

Network Working Group                                          S. Ginoza
Request for Comments: 3299                                           ISI
Category: Informational                                    December 2003

                      Request for Comments Summary

                         RFC Numbers 3200-3299

Status of This Memo

このメモのステータス

This RFC is a slightly annotated list of the 100 RFCs from RFC 3200 through RFC 3299. This is a status report on these RFCs. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

このRFCは、これは、これらのRFCのステータスレポートであるRFC 3299によってRFC 3200から100のRFCのわずか注釈付きリストです。このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。

著作権表示

著作権（C）インターネット協会（2003）。全著作権所有。

Note

注意

Many RFCs, but not all, are Proposed Standards, Draft Standards, or Standards. Since the status of these RFCs may change during the standards processing, we note here only that they are on the standards track. Please see the latest edition of "Internet Official Protocol Standards" for the current state and status of these RFCs. In the following, RFCs on the standards track are marked [STANDARDS TRACK].

多くのRFCは、すべてではなく、標準、ドラフト規格、または規格を提案しています。これらのRFCの状態が標準処理中に変更されることがありますので、我々は、彼らが標準軌道に乗っていることをここにしか注意してください。これらのRFCの現在の状態と状態のための「インターネット公式プロトコル標準」の最新版を参照してください。以下では、標準トラック上のRFCは[STANDARDS TRACK]とマークされています。

RFC     Author          Date            Title
---     ------          ----            -----

3299 Ginoza Dec 2003 Request for Comments Summary

コメント概要について3299宜野座2003年12月のリクエスト

This memo.

このメモ。

3298 Faynberg Aug 2002 Service in the Public Switched Telephone Network/Intelligent Network (PSTN/IN) Requesting InTernet Service (SPIRITS) Protocol Requirements

公共の場で3298 Faynberg 2002年8月サービス交換電話網/インテリジェントネットワーク（PSTN / IN）の要求インターネットサービス（SPIRITS）プロトコル要件

This document describes the SPIRITS protocol requirements, based on the architecture presented in RFC 3136. (SPIRITS stands for "Service in the PSTN/IN Requesting InTernet Service".) The purpose of the protocol is to support services that originate in the Public Switched Telephone Network (PSTN) and necessitate the interactions between the PSTN and the Internet. Similarly, such services are called SPIRITS services. (Internet Call Waiting, Internet Caller-ID Delivery, and Internet Call Forwarding are examples of SPIRIT services, but the protocol is to define the building blocks from which many other services can be built.) On the PSTN side, the SPIRITS services are initiated from the Intelligent Network (IN) entities; the earlier IETF work on the PSTN/Internet Interworking (PINT) resulted in the protocol (RFC 2848) in support of the services initiated the other way around--from the Internet to PSTN.

この文書は、（「インターネットサービスを要求する際に/ PSTNにサービス」の略です。SPIRITS）プロトコルの目的は、公衆に発信サービスは電話を交換サポートすることであるRFC 3136で提示アーキテクチャに基づいSPIRITSプロトコル要件について説明しネットワーク（PSTN）とPSTNとインターネットの間の相互作用を必要とします。同様に、このようなサービスはSPIRITSサービスと呼ばれます。（インターネットキャッチホン、インターネット発信者ID配達、及びインターネット電話転送は、SPIRITサービスの例ですが、プロトコルは、他の多くのサービスを構築することができ、そこからのビルディングブロックを定義することです。）PSTN側では、SPIRITSサービスが開始されていますインテリジェントネットワーク（IN）エンティティから。 PSTN /インターネットインターワーキング（PINT）の以前のIETF仕事はサービスのサポートにプロトコル（RFC 2848）の結果の周りに他の方法で開始 - インターネットからPSTNへの。

To this end, this document lists general requirements for the SPIRITS protocol as well as those pertinent to IN, Wireless IN, and PINT building blocks. The document also presents the SPIRITS WG consensus on the choice of the SPIRITS signaling protocol. This memo provides information for the Internet community.

このため、このドキュメントはSPIRITSプロトコルのための一般的な要件と同様に、無線では、およびPINTビルディングブロックに関連するものをを示しています。文書はまた、シグナリングプロトコルSPIRITSの選択にSPIRITS WGコンセンサスを提示します。このメモはインターネットコミュニティのための情報を提供します。

3297 Klyne Jul 2002 Content Negotiation for Messaging Services based on Email

メールに基づくメッセージングサービスのために3297 Klyne 2002年7月コンテントネゴシエーション

This memo describes a content negotiation mechanism for facsimile, voice and other messaging services that use Internet email. [STANDARDS TRACK]

このメモは、ファクシミリ、音声およびインターネット電子メールを使用する他のメッセージングサービスのためのコンテンツネゴシエーションメカニズムを説明しています。 [STANDARDS TRACK]

3296 Zeilenga Jul 2002 Named Subordinate References in Lightweight Directory Access Protocol (LDAP) Directories

LDAP（Lightweight Directory Access Protocol）ディレクトリで3296のZeilenga 2002年7月指名下位参照

This document details schema and protocol elements for representing and managing named subordinate references in Lightweight Directory Access Protocol (LDAP) Directories. [STANDARDS TRACK]

この文書では、代表とのLDAP（Lightweight Directory Access Protocol）ディレクトリ内の名前付きの下位参照を管理するためのスキーマとプロトコルの要素を詳述します。 [STANDARDS TRACK]

3295 Sjostrand Jun 2002 Definitions of Managed Objects for the General Switch Management Protocol (GSMP)

一般用管理オブジェクトの3295のSjostrand 2002の6月の定義スイッチ管理プロトコル（GSMP）

This memo defines a portion of the Management Information Base (MIB) for the use with the network management protocols in the Internet community. In particular, it describes managed objects for the General Switch Management Protocol (GSMP). [STANDARDS TRACK]

このメモは、インターネットコミュニティでのネットワーク管理プロトコルで使用するための管理情報ベース（MIB）の一部を定義します。特に、それは一般的なスイッチ管理プロトコル（GSMP）のための管理オブジェクトについて説明します。 [STANDARDS TRACK]

3294 Doria Jun 2002 General Switch Management Protocol (GSMP) Applicability

3294ドリア2002年6月一般的なスイッチ管理プロトコル（GSMP）の適用

This memo provides an overview of the GSMP (General Switch Management Protocol) and includes information relating to its deployment in a IP network in an MPLS environment. It does not discuss deployment in an ATM (Asynchronous Transfer Mode) network or in a raw ethernet configuration. This memo provides information for the Internet community.

このメモはGSMPの概要（一般的なスイッチ管理プロトコル）を提供し、MPLS環境でIPネットワークでの展開に関連する情報を含んでいます。これは、ATM（非同期転送モード）ネットワーク内または生のイーサネット構成の展開については説明しません。このメモはインターネットコミュニティのための情報を提供します。

3293 Doria Jun 2002 General Switch Management Protocol (GSMP) Packet Encapsulations for Asynchronous Transfer Mode (ATM), Ethernet and Transmission Control Protocol (TCP)

3293ドリア2002年6月一般的なスイッチ管理プロトコル（GSMP）非同期転送モード（ATM）のパケットカプセル化、イーサネットおよび伝送制御プロトコル（TCP）

This memo specifies the encapsulation of GSMP (General Switch Management Protocol) packets in ATM (Asynchronous Transfer Mode), Ethernet and TCP (Transmission Control Protocol). [STANDARDS TRACK]

このメモはATMでのGSMPのカプセル化（一般的にはスイッチ管理プロトコル）パケット（非同期転送モード）、イーサネットとTCP（Transmission Control Protocol）を指定します。 [STANDARDS TRACK]

3292 Doria Jun 2002 General Switch Management Protocol (GSMP) V3

3292ドリア2002年6月一般的なスイッチ管理プロトコル（GSMP）V3

This document describes the General Switch Management Protocol Version 3 (GSMPv3). The GSMPv3 is an asymmetric protocol that allows one or more external switch controllers to establish and maintain the state of a label switch such as, an ATM, frame relay or MPLS switch. The GSMPv3 allows control of both unicast and multicast switch connection state as well as control of switch system resources and QoS features. [STANDARDS TRACK]

この文書では、一般的なスイッチ管理プロトコルバージョン3（GSMPv3）について説明します。 GSMPv3は、1つまたは複数の外部スイッチ・コントローラは、ATM、フレームリレーまたはMPLSスイッチとしてラベルスイッチの状態を確立し、維持することを可能にする非対称プロトコルです。 GSMPv3は、ユニキャストとマルチキャストの両方のスイッチ接続状態の制御、ならびにスイッチ・システム・リソースおよびQoS機能の制御を可能にします。 [STANDARDS TRACK]

3291 Daniele May 2002 Textual Conventions for Internet Network Addresses

インターネットネットワークアドレスのための3291のダニエル2002年5月テキストの表記法

This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these textual conventions (TCs) will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS TRACK]

このMIBモジュールはテキストの表記法は、一般的に使用されるインターネットのネットワーク層アドレス情報を表現するために定義されています。意図は、これらのテキストの表記法は（TC）がインポートされ、そうでない場合は、独自の表現を定義するMIBモジュールで使用されるということです。 [STANDARDS TRACK]

3290 Bernet May 2002 An Informal Management Model for Diffserv Routers

Diffservのルータの3290 Bernet 2002年5月アン非公式の管理モデル

This document proposes an informal management model of Differentiated Services (Diffserv) routers for use in their management and configuration. This model defines functional datapath elements (e.g., classifiers, meters, actions, marking, absolute dropping, counting, multiplexing), algorithmic droppers, queues and schedulers. It describes possible configuration parameters for these elements and how they might be interconnected to realize the range of traffic conditioning and per-hop behavior (PHB) functionalities described in the Diffserv Architecture. This memo provides information for the Internet community.

この文書では、彼らの管理と構成で使用するための差別化サービス（DiffServ）のルータの非公式の管理モデルを提案しています。このモデルは、機能的なデータ経路要素（例えば、分類、メートル、アクション、マーキング、絶対滴下、カウント、多重化）、アルゴリズム点滴、キューおよびスケジューラを定義します。それは、これらの要素のための可能な設定パラメータを記述し、それらはトラフィック調整の範囲とホップ単位動作（PHB）はDiffservアーキテクチャで説明の機能を実現するために相互接続されることがありますか。このメモはインターネットコミュニティのための情報を提供します。

3289 Baker May 2002 Management Information Base for the Differentiated Services Architecture

差別化サービスアーキテクチャのための3289ベーカー2002年5月の管理情報ベース

This memo describes an SMIv2 (Structure of Management Information version 2) MIB for a device implementing the Differentiated Services Architecture. It may be used both for monitoring and configuration of a router or switch capable of Differentiated Services functionality. [STANDARDS TRACK]

このメモは、差別化サービスアーキテクチャを実装するデバイスのためのMIBのSMIv2（経営情報バージョン2の構造）について説明します。これは、ルータの監視および構成の両方を使用するか、または差別化サービス機能することが可能なスイッチであってもよいです。 [STANDARDS TRACK]

3288 O'Tuathail Jun 2002 Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)

ブロック拡張可能交換プロトコルでのSOAP（Simple Object Access Protocol）を使用してO'Tuathail 2002年6月3288（BEEP）

This memo specifies a Simple Object Access Protocol (SOAP) binding to the Blocks Extensible Exchange Protocol core (BEEP). A SOAP binding describes how SOAP messages are transmitted in the network. [STANDARDS TRACK]

このメモは、Simple Object Access Protocol（SOAP）ブロック拡張可能交換プロトコルコア（BEEP）への結合を指定します。 SOAPバインディングは、SOAPメッセージがネットワークに送信されている方法を説明します。 [STANDARDS TRACK]

3287 Bierman Jul 2002 Remote Monitoring MIB Extensions for Differentiated Services

差別化サービスのための3287のBierman 2002年7月リモートモニタリングMIB拡張

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for monitoring Differentiated Services (DS) Codepoint usage in packets which contain a DS field, utilizing the monitoring framework defined in the RMON-2 (Remote Network Monitoring Management Version 2) MIB. [STANDARDS TRACK]

このメモは、インターネットコミュニティでのネットワーク管理プロトコルで使用するための管理情報ベース（MIB）の一部を定義します。特に、それは、DSフィールドを含むパケットで差別化サービス（DS）コードポイントの使用状況を監視RMON-2で定義された監視フレームワーク（リモートネットワークが管理バージョン2のモニタリング）MIBを利用するのに使用される管理オブジェクトについて説明します。 [STANDARDS TRACK]

3286 Ong May 2002 An Introduction to the Stream Control Transmission Protocol (SCTP)

ストリーム制御伝送プロトコルに3286オング2002年5月入門（SCTP）

This document provides a high level introduction to the capabilities supported by the Stream Control Transmission Protocol (SCTP). It is intended as a guide for potential users of SCTP as a general purpose transport protocol. This memo provides information for the Internet community.

この文書では、ストリーム制御伝送プロトコル（SCTP）によってサポートされる機能への高レベルの概要を提供します。これは、汎用トランスポートプロトコルとしてSCTPの潜在的なユーザのためのガイドとして意図されています。このメモはインターネットコミュニティのための情報を提供します。

3285 Gahrns May 2002 Using Microsoft Word to create Internet Drafts and RFCs

インターネットドラフトやRFCを作成するために、Microsoft Wordを使用して3285 Gahrns 2002年5月

This document describes the steps to configure the Microsoft Word application to produce documents in Internet Draft and RFC format. This memo provides information for the Internet community.

このドキュメントはインターネットドラフトやRFC形式で文書を作成するには、Microsoft Wordアプリケーションを設定する手順を説明します。このメモはインターネットコミュニティのための情報を提供します。

3284 Korn Jun 2002 The VCDIFF Generic Differencing and Compression Data Format

3284コーン2002年6月VCDIFFジェネリック差分と圧縮データフォーマット

This memo describes VCDIFF, a general, efficient and portable data format suitable for encoding compressed and/or differencing data so that they can be easily transported among computers. [STANDARDS TRACK]

このメモはVCDIFF、それらは容易にコンピュータ間で搬送することができるように、圧縮及び/又は差分データを符号化するのに適した一般的な、効率的でポータブルデータフォーマットを記述する。 [STANDARDS TRACK]

3283 Mahoney Jun 2002 Guide to Internet Calendaring

インターネット予定表に3283マホーニー2002年6月ガイド

This document describes the various Internet calendaring and scheduling standards and works in progress, and the relationships between them. Its intent is to provide a context for these documents, assist in their understanding, and potentially aid in the design of standards-based calendaring and scheduling systems. The standards addressed are RFC 2445 (iCalendar), (iTIP), and (iMIP). The work in progress addressed is "Calendar Access Protocol" (CAP). This document also describes issues and problems that are not solved by these protocols, and that could be targets for future work. This memo provides information for the Internet community.

この文書では、さまざまなインターネットカレンダーとスケジューリング基準や進行中の作品、およびそれらの間の関係を記述する。その意図は、これらの文書のためのコンテキストを提供し、その理解を助ける、そして潜在的に標準ベースのカレンダーおよびスケジューリングシステムの設計を支援することです。対処の規格は、RFC 2445（iCalendar形式）、（のiTIP）、および（iMIPの）です。進行中の作業は、「カレンダーアクセスプロトコル」（CAP）で対処しました。この文書はまた、これらのプロトコルによって解決されていない課題や問題を説明し、それは今後の作業のためのターゲットである可能性があります。このメモはインターネットコミュニティのための情報を提供します。

3282 Alvestrand May 2002 Content Language Headers

3282のAlvestrand 2002年5月のコンテンツ言語ヘッダ

This document defines a "Content-language:" header, for use in cases where one desires to indicate the language of something that has RFC 822-like headers, like MIME body parts or Web documents, and an "Accept-Language:" header for use in cases where one wishes to indicate one's preferences with regard to language. [STANDARDS TRACK]

1は、MIMEボディ部分やウェブドキュメントのようなRFC 822のようなヘッダを、持っているものの言語を示すことを望む場合に使用するため、ヘッダ、および「受け入れ言語：」：この文書では、「コンテンツ言語」を定義するヘッダ1は、言語に関して自分の好みを示すために、希望する場合に使用します。 [STANDARDS TRACK]

3281 Farrell Apr 2002 An Internet Attribute Certificate Profile for Authorization

3281ファレル2002年4月認可のためのインターネット属性証明書プロフィール

This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPSec, and WWW security applications. [STANDARDS TRACK]

この仕様は、インターネットプロトコルにおけるX.509属性証明書を使用するためのプロファイルを定義します。属性証明書は、相互運用性目標の広いスペクトルおよび運用と保証要件の広範囲をカバーするアプリケーションや環境の広い範囲で使用することができます。このドキュメントの目標は、幅広い相互運用性を必要とする一般的なアプリケーションだけでなく、限られた特別な目的の要件のための共通のベースラインを確立することです。インターネット、電子メール、IPSecの、およびWWWのセキュリティアプリケーションのための属性証明書のサポート上のプロファイルの場所を強調。 [STANDARDS TRACK]

3280 Housley Apr 2002 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

3280 Housleyの2002年4月のインターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）のプロフィール

This memo profiles the X.509 v3 certificate and X.509 v2 Certificate Revocation List (CRL) for use in the Internet. [STANDARDS TRACK]

このメモは、インターネットでの使用のためのX.509 v3証明書とX.509 v2の証明書失効リスト（CRL）をプロファイル。 [STANDARDS TRACK]

3279 Polk Apr 2002 Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

3279ポーク2002年4月のアルゴリズムとインターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィールの識別子

This document specifies algorithm identifiers and ASN.1 encoding formats for digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKI). Digital signatures are used to sign certificates and certificate revocation list (CRLs). Certificates include the public key of the named subject. [STANDARDS TRACK]

このドキュメントはインターネットX.509公開鍵基盤（PKI）で使用されるデジタル署名と対象の公開鍵のためのアルゴリズム識別子とASN.1のエンコード形式を指定します。デジタル署名は証明書と証明書失効リスト（CRL）の署名に使用されています。証明書は、指定されたサブジェクトの公開鍵が含まれます。 [STANDARDS TRACK]

3278 Blake-Wilson Apr 2002 Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)

楕円曲線暗号暗号メッセージ構文中（ECC）アルゴリズム（CMS）の3278ブレイク・ウィルソン2002年4月の使用

This document describes how to use Elliptic Curve Cryptography (ECC) public-key algorithms in the Cryptographic Message Syntax (CMS). The ECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate content. The definition of the algorithm processing is based on the ANSI X9.62 standard, developed by the ANSI X9F1 working group, the IEEE 1363 standard, and the SEC 1 standard. This memo provides information for the Internet community.

この文書は、暗号メッセージ構文（CMS）に楕円曲線暗号（ECC）公開鍵アルゴリズムを使用する方法について説明します。 ECCアルゴリズムは、デジタル署名の作成と内容を暗号化または認証する鍵の交換をサポートしています。アルゴリズム処理の定義は、ANSI X9F1ワーキンググループ、IEEE 1363規格、およびSEC 1標準によって開発されたANSI X9.62規格に基づいています。このメモはインターネットコミュニティのための情報を提供します。

3277 McPherson Apr 2002 Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance

3277マクファーソン2002年4月中間システム（IS-IS）過渡ブラックホールの回避に中間システム

This document describes a simple, interoperable mechanism that can be employed in Intermediate System to Intermediate System (IS-IS) networks in order to decrease the data loss associated with deterministic blackholing of packets during transient network conditions. The mechanism proposed here requires no IS-IS protocol changes and is completely interoperable with the existing IS-IS specification. This memo provides information for the Internet community.

この文書は、一時的なネットワーク状態の間のパケットの決定論ブラックホールに関連するデータの損失を低減するために、中間システム（IS-IS）のネットワークに中間システムに使用することができる簡単な、相互運用可能な機構が記載されています。ここで提案されたメカニズムには、プロトコルの変更IS-ISはなく、既存の仕様IS-ISと完全に相互運用可能である必要があり。このメモはインターネットコミュニティのための情報を提供します。

3276 Ray May 2002 Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines

3276高ビットレートのDSLのための管理オブジェクトのレイ2002の5月の定義 - 第2世代（HDSL2）とシングルペア高速デジタル加入者線（SHDSL）行

This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) interfaces. [STANDARDS TRACK]

この文書は、インターネットコミュニティでのネットワーク管理プロトコルで使用するための管理情報ベース（MIB）モジュールの一部を定義します。第2世代（HDSL2）とシングルペア高速デジタル加入者線（SHDSL）インターフェース - 特に、高ビットレートのDSLを管理するために使用されるオブジェクトについて説明します。 [STANDARDS TRACK]

3275 Eastlake 3rd Mar 2002 (Extensible Markup Language) XML-Signature Syntax and Processing

3275イーストレイク2002年3月3日、XML（Extensible Markup Language）に-署名構文と処理

This document specifies XML (Extensible Markup Language) digital signature processing rules and syntax. [STANDARDS TRACK]

この文書は、XML（Extensible Markup Language）のデジタル署名処理ルールと構文を指定します。 [STANDARDS TRACK]

3274 Gutmann Jun 2002 Compressed Data Content Type for Cryptographic Message Syntax (CMS)

3274 Gutmann氏6月暗号メッセージ構文のための2002の圧縮されたデータcontent type（CMS）

This document defines a format for using compressed data as a Cryptographic Message Syntax (CMS) content type. Compressing data before transmission provides a number of advantages, including the elimination of data redundancy which could help an attacker, speeding up processing by reducing the amount of data to be processed by later steps (such as signing or encryption), and reducing overall message size. Although there have been proposals for adding compression at other levels (for example at the MIME or SSL level), these don't address the problem of compression of CMS content unless the compression is supplied by an external means (for example by intermixing MIME and CMS). [STANDARDS TRACK]

この文書は、暗号メッセージ構文（CMS）コンテンツタイプとして圧縮されたデータを使用するためのフォーマットを定義します。送信が（例えば、署名または暗号化など）後のステップで処理されるデータの量を低減し、全体的なメッセージサイズを低減することにより処理の高速化、攻撃者を助けることができるデータの冗長性の除去を含む、多くの利点を提供する前にデータを圧縮。（MIMEまたはSSLレベルで例えば）他のレベルで圧縮を追加するための提案がなされているものの、圧縮はMIMEとを混ぜることにより（例えば、外部手段によって供給されていない限り、これらは、CMSコンテンツの圧縮の問題に対処していませんCMS）。 [STANDARDS TRACK]

3273 Waldbusser Jul 2002 Remote Network Monitoring Management Information Base for High Capacity Networks

大容量ネットワークのための3273 Waldbusser 2002年7月のリモートネットワーク監視管理情報ベース

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring (RMON) devices for use on high speed networks. This document contains a MIB Module that defines these new objects and also contains definitions of some updated objects from the RMON-MIB in RFC 2819 and the RMON2-MIB in RFC 2021. [PROPOSED STANDARD]

このメモは、TCP / IPベースのインターネットでネットワーク管理プロトコルと共に使用するための管理情報ベース（MIB）の一部を画定します。特に、高速ネットワーク上で使用するためにリモートネットワークモニタリング（RMON）デバイスを管理するためにオブジェクトを定義します。この文書では、これらの新しいオブジェクトを定義し、また、RFC 2021でRFC 2819でRMON-MIBおよびRMON2-MIBからいくつか更新されたオブジェクトの定義が含まれているMIBモジュール[提案された標準]を含んでいます

3272 Awduche May 2002 Overview and Principles of Internet Traffic Engineering

3272 Awduche 2002年5月概要とインターネットトラフィックエンジニアリングの原則

This memo describes the principles of Traffic Engineering (TE) in the Internet. The document is intended to promote better understanding of the issues surrounding traffic engineering in IP networks, and to provide a common basis for the development of traffic engineering capabilities for the Internet. The principles, architectures, and methodologies for performance evaluation and performance optimization of operational IP networks are discussed throughout this document. This memo provides information for the Internet community.

このメモは、インターネットにトラフィックエンジニアリング（TE）の原則を説明しています。文書は、IPネットワーク内のトラフィックエンジニアリングを取り巻く問題のより良い理解を促進するため、およびインターネットのトラフィックエンジニアリング機能の開発のための共通基盤を提供することを意図しています。原則、アーキテクチャ、および運用IPネットワークの性能評価と性能の最適化のための方法論は、この文書を通して議論されています。このメモはインターネットコミュニティのための情報を提供します。

3271 Cerf Apr 2002 The Internet is for Everyone

インターネットはみんなのためにある3271サーフ2002年4月

This document expresses the Internet Society's ideology that the Internet really is for everyone. However, it will only be such if we make it so. This memo provides information for the Internet community.

このドキュメントはインターネットが本当に皆のためであることを、インターネット社会のイデオロギーを表現しています。我々はそれを作る場合は、それが唯一のようなものであろう。このメモはインターネットコミュニティのための情報を提供します。

3270 Le Faucheur May 2002 Multi-Protocol Label Switching (MPLS) Support of Differentiated Services

差別化サービスの3270ルFaucheur 2002年5月マルチプロトコルラベルスイッチング（MPLS）をサポート

This document defines a flexible solution for support of Differentiated Services (Diff-Serv) over Multi-Protocol Label Switching (MPLS) networks. [STANDARDS TRACK]

この文書は（MPLS）ネットワークをマルチプロトコルラベルスイッチングオーバー差別化サービス（差分-SERV）をサポートするための柔軟なソリューションを定義します。 [STANDARDS TRACK]

3269 Kermode Apr 2002 Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents

リライアブルマルチキャストトランスポート（RMT）ビルディングブロックとプロトコルのインスタンス文書のための3269のKermode 2002年4月著者のガイドライン

This document provides general guidelines to assist the authors of Reliable Multicast Transport (RMT) building block and protocol instantiation definitions. The purpose of these guidelines is to ensure that any building block and protocol instantiation definitions produced contain sufficient information to fully explain their operation and use. In addition these guidelines provide directions to specify modular and clearly defined RMT building blocks and protocol instantiations that can be refined and augmented to safely create new protocols for use in new scenarios for which any existing protocols were not designed. This memo provides information for the Internet community.

この文書では、信頼できるマルチキャストトランスポート（RMT）ビルディングブロックとプロトコルのインスタンス定義の作成者を支援するための一般的なガイドラインを提供します。これらのガイドラインの目的は、生成される任意のビルディングブロックとプロトコルのインスタンス化の定義は完全に彼らの操作と使用を説明するために十分な情報が含まれていることを確認することです。また、これらのガイドラインは、洗練かつ安全に任意の既存のプロトコルが設計されなかったため、新たなシナリオで使用するための新しいプロトコルを作成するように拡張することができるモジュラーと明確に定義されRMTビルディングブロックとプロトコルのインスタンスを指定するための方向性を提供します。このメモはインターネットコミュニティのための情報を提供します。

3268 Chown Jun 2002 Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)

トランスポート層セキュリティのための3268のchown 2002年6月のAdvanced Encryption Standard（AES）暗号の組み合わせ（TLS）

This document proposes several new ciphersuites. At present, the symmetric ciphers supported by Transport Layer Security (TLS) are RC2, RC4, International Data Encryption Algorithm (IDEA), Data Encryption Standard (DES), and triple DES. The protocol would be enhanced by the addition of Advanced Encryption Standard (AES) ciphersuites. [STANDARDS TRACK]

この文書では、いくつかの新しい暗号スイートを提案しています。現時点では、トランスポート層セキュリティ（TLS）でサポートされている対称暗号はRC2、RC4、国際データ暗号化アルゴリズム（IDEA）、データ暗号化規格（DES）、トリプルDESです。プロトコルは、AES（Advanced Encryption Standard）暗号スイートの追加によって強化されるだろう。 [STANDARDS TRACK]

3267 Sjoberg Jun 2002 Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs

3267 Sjoberg 2002年6月リアルタイムトランスポートプロトコル（RTP）ペイロードフォーマットと適応マルチレート（AMR）と適応マルチレート広帯域（AMR-WB）オーディオコーデックのためのストレージのファイル形式

This document specifies a real-time transport protocol (RTP) payload format to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) encoded speech signals. The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of AMR and AMR-WB speech data in storage mode applications such as email. Two separate MIME type registrations are included, one for AMR and one for AMR-WB, specifying use of both the RTP payload format and the storage format. [STANDARDS TRACK]

この文書では、適応マルチレート（AMR）と適応マルチレート広帯域（AMR-WB）符号化された音声信号のために使用されるリアルタイム転送プロトコル（RTP）ペイロード・フォーマットを指定します。ペイロードフォーマットは、非IPネットワーク上の既存のAMRとAMR-WBトランスポートフォーマットと相互運用できるように設計されています。また、ファイル形式は、電子メールなどのストレージモードアプリケーションにおけるAMRとAMR-WB音声データを搬送するために指定されています。二つの別々のMIMEタイプの登録は、RTPペイロードフォーマットとストレージフォーマットの両方の使用を指定して、AMRのための1つおよびAMR-WBのための1つ含まれています。 [STANDARDS TRACK]

3266 Olson Jun 2002 Support for IPv6 in Session Description Protocol (SDP)

セッション記述プロトコルにおけるIPv6の3266オルソン2002年6月サポート（SDP）

This document describes the use of Internet Protocol Version 6 (IPv6) addresses in conjunction with the Session Description Protocol (SDP). Specifically, this document clarifies existing text in SDP with regards to the syntax of IPv6 addresses. [STANDARDS TRACK]

この文書では、セッション記述プロトコル（SDP）と連携してインターネットプロトコルバージョン6（IPv6）アドレスの使用を記載しています。具体的には、この文書では、IPv6アドレスの構文に関してSDP内の既存のテキストを明確にしています。 [STANDARDS TRACK]

3265 Roach Jun 2002 Session Initiation Protocol (SIP)-Specific Event Notification

3265ローチ2002年6月のセッション開始プロトコル（SIP）特異的イベント通知

This document describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. [STANDARDS TRACK]

この文書では、セッション開始プロトコル（SIP）の拡張について説明します。この拡張の目的は、SIPノードは、特定のイベントが発生したことを示すリモートノードからの通知を要求することが可能な拡張可能なフレームワークを提供することです。 [STANDARDS TRACK]

3264 Rosenberg Jun 2002 An Offer/Answer Model with the Session Description Protocol (SDP)

3264ローゼンバーグ2002年6月セッション記述プロトコル（SDP）とのオファー/アンサーモデル

This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP). [STANDARDS TRACK]

この文書では、2つのエンティティは、セッション記述プロトコル（SDP）の使用は、それらの間のマルチメディアセッションの共通のビューに到達するようにすることができるメカニズムを定義します。モデルでは、一人の参加者は、彼らの視点から希望のセッションの他の記述、及びその観点から目的のセッションで他の参加者の回答を提供しています。このオファー/アンサーモデルは、両方の参加者からの情報は、セッションの完全なビューのために必要とされるユニキャストセッションで最も有用です。オファー/アンサーモデルは、セッション開始プロトコル（SIP）のようなプロトコルで使用されます。 [STANDARDS TRACK]

3263 Rosenberg Jun 2002 Session Initiation Protocol (SIP): Locating SIP Servers

3263ローゼンバーグ2002年6月のセッション開始プロトコル（SIP）：SIPサーバーの検索

The Session Initiation Protocol (SIP) uses DNS procedures to allow a client to resolve a SIP Uniform Resource Identifier (URI) into the IP address, port, and transport protocol of the next hop to contact. It also uses DNS to allow a server to send a response to a backup client if the primary client has failed. This document describes those DNS procedures in detail. [STANDARDS TRACK]

セッション開始プロトコル（SIP）は、クライアントが連絡するネクストホップのIPアドレス、ポート、およびトランスポートプロトコルにSIP URI（Uniform Resource Identifier）を解決できるようにDNSの手順を使用しています。また、プライマリクライアントが失敗した場合、サーバーは、バックアップクライアントに応答を送信できるようにDNSを使用しています。この文書は詳細にこれらのDNS手順を説明します。 [STANDARDS TRACK]

3262 Rosenberg Jun 2002 Reliability of Provisional Responses in the Session Initiation Protocol (SIP)

3262セッション開始プロトコル（SIP）における暫定応答のローゼンバーグ2002年6月の信頼性に

This document specifies an extension to the Session Initiation Protocol (SIP) providing reliable provisional response messages. This extension uses the option tag 100rel and defines the Provisional Response ACKnowledgement (PRACK) method. [STANDARDS TRACK]

この文書では、信頼性のある暫定応答メッセージを提供するセッション開始プロトコル（SIP）に拡張子を指定します。この拡張は、オプションタグ100relを使用し、暫定応答確認（PRACK）メソッドを定義します。 [STANDARDS TRACK]

3261 Rosenberg Jun 2002 SIP: Session Initiation Protocol

3261ローゼンバーグ2002年6月SIP：セッション開始プロトコル

This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS TRACK]

この文書では、セッション開始プロトコル（SIP）、1人以上の参加者とのセッションを作成、変更、および終了するためのアプリケーション層制御（シグナリング）プロトコルを記載しています。これらのセッションは、インターネット電話、マルチメディア配信、およびマルチメディア会議が含まれます。 [STANDARDS TRACK]

3260 Grossman Apr 2002 New Terminology and Clarifications for Diffserv

3260グロスマン2002年4月の新用語とDiffservのための明確化

This memo captures Diffserv working group agreements concerning new and improved terminology, and provides minor technical clarifications. It is intended to update RFC 2474, RFC 2475 and RFC 2597. When RFCs 2474 and 2597 advance on the standards track, and RFC 2475 is updated, it is intended that the revisions in this memo will be incorporated, and that this memo will be obsoleted by the new RFCs. This memo provides information for the Internet community.

このメモは、新しい改良用語についてのDiffservワーキンググループ協定を取り込み、そしてマイナーな技術的な明確化を提供します。標準トラック上のRFC 2474、RFC 2475およびRFC 2597ときのRFC 2474および2597の前進を更新するためのものであり、RFC 2475が更新され、それがこのメモでリビジョンが組み込まれることを意図しており、このメモはなること新しいRFCで廃止。このメモはインターネットコミュニティのための情報を提供します。

3259 Ott Apr 2002 A Message Bus for Local Coordination

現地調整のための3259台のオット2002年4月Aメッセージバス

The local Message Bus (Mbus) is a light-weight message-oriented coordination protocol for group communication between application components. The Mbus provides automatic location of communication peers, subject based addressing, reliable message transfer and different types of communication schemes. The protocol is layered on top of IP multicast and is specified for IPv4 and IPv6. The IP multicast scope is limited to link-local multicast. This document specifies the Mbus protocol, i.e., message syntax, addressing and transport mechanisms. This memo provides information for the Internet community.

ローカル・メッセージ・バス（Mバス）は、アプリケーションのコンポーネント間のグループ通信のための軽量メッセージ指向協調プロトコルです。 Mバスは、通信ピア、アドレッシング基づいて被写体、信頼性の高いメッセージ転送及び通信方式の異なるタイプの自動場所を提供します。プロトコルは、IPマルチキャストの上部に積層され、IPv4およびIPv6のために指定されます。 IPマルチキャストスコープはリンクローカルマルチキャストに制限されています。この文書では、Mバス・プロトコル、即ち、メッセージ構文、アドレッシング及び搬送機構を指定します。このメモはインターネットコミュニティのための情報を提供します。

3258 Hardie Apr 2002 Distributing Authoritative Name Servers via Shared Unicast Addresses

共有ユニキャストアドレスを経由して権威ネームサーバの配布3258ハーディ2002年4月

This memo describes a set of practices intended to enable an authoritative name server operator to provide access to a single named server in multiple locations. The primary motivation for the development and deployment of these practices is to increase the distribution of Domain Name System (DNS) servers to previously under-served areas of the network topology and to reduce the latency for DNS query responses in those areas. This memo provides information for the Internet community.

このメモは、複数の場所でのシングルという名前のサーバーへのアクセスを提供するために、権威ネームサーバのオペレータを有効にすることを目的と慣行のセットについて説明します。これらのプラクティスの開発と配備のための主な動機は、ネットワークトポロジの以前の下で、役立った地域にドメインネームシステム（DNS）サーバーの分布を高めるために、これらの分野でのDNSクエリ応答のための待ち時間を減らすことです。このメモはインターネットコミュニティのための情報を提供します。

3257 Coene Apr 2002 Stream Control Transmission Protocol Applicability Statement

3257 Coene 2002年4月ストリーム制御伝送プロトコル適用性に関する声明

This document describes the applicability of the Stream Control Transmission Protocol (SCTP). It also contrasts SCTP with the two dominant transport protocols, User Datagram Protocol (UDP) & Transmission Control Protocol (TCP), and gives some guidelines for when best to use SCTP and when not best to use SCTP. This memo provides information for the Internet community.

この文書では、ストリーム制御伝送プロトコル（SCTP）の適用性を説明しています。また、2つの支配的なトランスポートプロトコル、ユーザーデータグラムプロトコル（UDP）＆伝送制御プロトコル（TCP）とのSCTPを対比し、最高のSCTPとするときSCTPを使用するのが最善ではないを使用するときのために、いくつかのガイドラインを示します。このメモはインターネットコミュニティのための情報を提供します。

3256 Jones Apr 2002 The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option

3256ジョーンズ2002年4月DOCSIS（データオーバーケーブルサービスインターフェイス仕様）デバイスクラスDHCP（動的ホスト構成プロトコル）リレーエージェント情報サブオプション

This document proposes a new sub-option to the DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Option. [STANDARDS TRACK]

この文書では、DHCP（動的ホスト構成プロトコル）リレーエージェント情報オプションに新しいサブオプションを提案しています。 [STANDARDS TRACK]

3255 Jones Apr 2002 Extending Point-to-Point Protocol (PPP) over Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) with virtual concatenation, high order and low order payloads

仮想連結、上位と下位のペイロードでポイントツーポイント同期光ネットワーク/同期デジタル階層（SONET / SDH）上のプロトコル（PPP）を拡張3255ジョーンズ2002年4月

This document describes an extension to the mapping of Point-to-Point Protocol (PPP) into Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) to include the use of SONET/SDH SPE/VC virtual concatenation and the use of both high order and low order payloads. [STANDARDS TRACK]

この文書では、SONET / SDH SPE / VC仮想連結と高の両方の使用の使用を含めるために同期光ネットワーク/同期デジタル階層（SONET / SDH）へのポイントツーポイントプロトコル（PPP）のマッピングに拡張子を記述します順序と下位ペイロード。 [STANDARDS TRACK]

3254 Alvestrand Apr 2002 Definitions for talking about directories

ディレクトリの話のために3254のAlvestrand 2002の4月の定義

When discussing systems for making information accessible through the Internet in standardized ways, it may be useful if the people who are discussing it have a common understanding of the terms they use. For example, a reference to this document would give one the power to agree that the DNS (Domain Name System) is a global lookup repository with perimeter integrity and loose, converging consistency. On the other hand, a LDAP (Lightweight Directory Access Protocol) directory server is a local, centralized repository with both lookup and search capability. This document discusses one group of such systems which is known under the term, "directories". This memo provides information for the Internet community.

標準化された方法で、インターネットを介してアクセス可能な情報を作成するためのシステムを議論するとき、それを議論している人々は、彼らが使用する用語の共通理解を持っている場合、それが有用である可能性があります。たとえば、このドキュメントを参照するには、1にDNS（ドメインネームシステム）は、境界の整合性と緩い、収束一貫性を持つグローバル・ルックアップリポジトリがあることに同意する力を与えるだろう。一方、LDAP（ライトウェイトディレクトリアクセスプロトコル）ディレクトリ・サーバーは、検索と検索機能の両方を持つローカル、中央リポジトリです。この文書では、用語、「ディレクトリ」で知られているようなシステムの一つのグループについて説明します。このメモはインターネットコミュニティのための情報を提供します。

3253 Clemm Mar 2002 Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)

3253のWebDAVへClemm 2002年3月バージョニング機能拡張（Web分散オーサリングとバージョン管理）

This document specifies a set of methods, headers, and resource types that define the WebDAV (Web Distributed Authoring and Versioning) versioning extensions to the HTTP/1.1 protocol. [STANDARDS TRACK]

この文書では、HTTP / 1.1プロトコルの拡張バージョン管理方法、ヘッダ、およびWebDAV（Web分散オーサリングとバージョン）を定義するリソース・タイプのセットを指定します。 [STANDARDS TRACK]

3252 Kennedy 1 April 2002 Binary Lexical Octet Ad-hoc Transport

3252ケネディ2002年4月1日バイナリ字句オクテットのアドホック交通

This document defines a reformulation of IP and two transport layer protocols (TCP and UDP) as XML applications. This memo provides information for the Internet community.

この文書は、XMLアプリケーションとしてIPおよび2つのトランスポート層プロトコル（TCPおよびUDP）の再定式化を定義します。このメモはインターネットコミュニティのための情報を提供します。

3251 Rajagopalan 1 April 2002 Electricity over IP

IP上の電気3251 Rajagopalan 2002年4月1日

Mostly Pointless Lamp Switching (MPLampS) is an architecture for carrying electricity over IP (with an MPLS control plane). According to our marketing department, MPLampS has the potential to dramatically lower the price, ease the distribution and usage, and improve the manageability of delivering electricity. This document is motivated by such work as SONET/SDH over IP/MPLS (with apologies to the authors). Readers of the previous work have been observed scratching their heads and muttering, "What next?". This document answers that question. This memo provides information for the Internet community.

ほとんど無意味なランプ切り換えは、（MPLampS）は（MPLSコントロールプレーンを用いて）IP上で電気を運ぶためのアーキテクチャです。当社のマーケティング部門によると、MPLampSは劇的に、価格を下げる配布と使用を容易にし、電気を提供する管理性を向上させる可能性があります。この文書は、（著者への謝罪と）IP / MPLSオーバーSONET / SDHなどの作業が動機とされます。前作の読者は、彼らの頭を悩まとつぶやいて観察されている「次は何？」。この文書では、その質問に答えます。このメモはインターネットコミュニティのための情報を提供します。

3250 McIntyre Sep 2002 Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration

マッキンタイア2002年9月タグイメージファイル形式のファックス（TIFF-FX）を延長し3250 - 画像/ TIFF-FX MIMEサブタイプ登録

This document describes the registration of the MIME sub-type image/tiff-fx. The encodings are defined by File Format for Internet Fax and its extensions. [STANDARDS TRACK]

この文書は、MIMEサブタイプイメージ/ TIFF-FXの登録が記載されています。エンコーディングは、インターネットFAXとその拡張子のファイル形式で定義されています。 [STANDARDS TRACK]

3249 Cancio Sep 2002 Implementers Guide for Facsimile Using Internet Mail

インターネットメールを使用したファクシミリのための3249 Cancio 2002年9月インプリメンターズ・ガイド

This document is intended for the implementers of software that use email to send to facsimiles using RFC 2305 and 2532. This is an informational document and its guidelines do not supersede the referenced documents. This memo provides information for the Internet community.

この文書は、これは情報の文書であり、そのガイドラインは、参照文書に取って代わるいないRFC 2305および2532を使用してファクシミリに送信する電子メールを使用するソフトウェアの実装者を対象としています。このメモはインターネットコミュニティのための情報を提供します。

3248 Armitage Mar 2002 A Delay Bound alternative revision of RFC 2598

RFC 2598の3248アーミテージ2002年3月A遅延限界代替リビジョン

For historical interest, this document captures the EF Design Team's proposed solution, preferred by the original authors of RFC 2598 but not adopted by the working group in December 2000. The original definition of EF was based on comparison of forwarding on an unloaded network. This experimental Delay Bound (DB) PHB requires a bound on the delay of packets due to other traffic in the network. At the Pittsburgh IETF meeting in August 2000, the Differentiated Services working group faced serious questions regarding RFC 2598 - the group's standards track definition of the Expedited Forwarding (EF) Per Hop Behavior (PHB). An 'EF Design Team' volunteered to develop a re-expression of RFC 2598, bearing in mind the issues raised in the DiffServ group. At the San Diego IETF meeting in December 2000 the DiffServ working group decided to pursue an alternative re-expression of the EF PHB. This memo provides information for the Internet community.

歴史的な関心のために、この文書は、RFC 2598の原作者で好ましいが、EFの本来の定義はアンロードされたネットワーク上の転送の比較に基づいた2000年12月にワーキンググループによって採用されていない、EFデザインチームの提案したソリューションをキャプチャします。この実験的な遅延限界（DB）PHBは、ネットワーク内の他のトラフィックへのパケットの遅延のバウンドが必要です。 2000年8月のピッツバーグIETF会議で、差別化サービスワーキンググループは、RFC 2598に関する深刻な問題に直面した - グループの基準は緊急転送（EF）毎のホップの挙動（PHB）の定義を追跡します。「EF設計チームは、」心の中のDiffServグループで提起された問題を担持し、RFC 2598の再発現を開発するために志願しました。 2000年12月、サンディエゴIETFミーティングでのDiffServワーキンググループが再発現EF PHBの代替を追求することを決めました。このメモはインターネットコミュニティのための情報を提供します。

3247 Charny Mar 2002 Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior)

EFのPHBの新しい定義のための3247 Charny 2002年3月補足情報（優先転送ホップ単位動作）

This document was written during the process of clarification of RFC2598 "An Expedited Forwarding PHB" that led to the publication of revised specification of EF "An Expedited Forwarding PHB". Its primary motivation is providing additional explanation to the revised EF definition and its properties. The document also provides additional implementation examples and gives some guidance for computation of the numerical parameters of the new definition for several well known schedulers and router architectures. This memo provides information for the Internet community.

この文書は、EFの改訂仕様「緊急転送PHB」の出版につながった「緊急転送PHB」RFC2598の明確化のプロセスの間に書かれました。その主な動機は、改訂されたEFの定義とそのプロパティに追加説明を提供しています。文書はまた、追加の実装例を提供し、いくつかのよく知られたスケジューラとルータ・アーキテクチャのための新しい定義の数値パラメータを計算するためのいくつかのガイダンスを提供します。このメモはインターネットコミュニティのための情報を提供します。

3246 Davie Mar 2002 An Expedited Forwarding PHB (Per-Hop Behavior)

3246デイビー2002年3月アン緊急転送PHB（ホップ単位動作）

This document defines a PHB (per-hop behavior) called Expedited Forwarding (EF). The PHB is a basic building block in the Differentiated Services architecture. EF is intended to provide a building block for low delay, low jitter and low loss services by ensuring that the EF aggregate is served at a certain configured rate. This document obsoletes RFC 2598. [STANDARDS TRACK]

この文書は、緊急転送（EF）と呼ばれるPHB（ホップ単位動作）を規定します。 PHBは、差別化サービスアーキテクチャの基本的なビルディングブロックです。 EFはEFの集合体は、ある設定されたレートで提供していることを保証することにより、低遅延、低ジッタ、低損失サービスのためのビルディングブロックを提供することを意図しています。この文書では、[STANDARDS TRACK] RFC 2598を廃止します

3245 Klensin, Ed. Mar 2002 The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational Documents Contributed to ITU-T Study Group 2 (SG2)

3245 Klensin、エド。 2002年3月の歴史と電話番号マッピング（ENUM）操作上の意思決定の文脈：ITU-T研究グループ2（SG2）に貢献情報提供文書

RFC 2916 assigned responsibility for a number of administrative and operational details of Telephone Number Mapping (ENUM) to the IAB. It also anticipated that ITU would take responsibility for determining the legitimacy and appropriateness of applicants for delegation of "country code"-level subdomains of the top-level ENUM domain. Recently, three memos have been prepared for the ITU-T Study Group 2 (SG2) to explain the background of, and reasoning for, the relevant decisions. The IAB has also supplied a set of procedural instructions to the RIPE NCC for implementation of their part of the model. The content of the three memos is provided in this document for the information of the IETF community.

RFC 2916は、IABの電話番号マッピング（ENUM）の管理および動作の詳細の数の責任を割り当てます。また、ITUがトップレベルのENUMドメインの「国コード」レベルのサブドメインの委譲のために応募者の正当性と妥当性を判断するための責任を取るだろうと予想しました。最近、3個のメモは、関連する意思決定のための背景、と推論を説明するために、ITU-T研究グループ2（SG2）のために用意されています。 IABは、モデルのその部分の実装のためにRIPE NCCに手続き命令のセットを提供してきました。 3つのメモの内容は、IETFコミュニティの情報については、このドキュメントで提供されています。

3244 Swift Feb 2002 Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols

3244のスウィフト2002年2月のMicrosoft Windows 2000のKerberosパスワード変更やパスワードの設定プロトコル

This memo specifies Microsoft's Windows 2000 Kerberos change password and set password protocols. The Windows 2000 Kerberos change password protocol interoperates with the original Kerberos change password protocol. Change password is a request reply protocol that includes a KRB_PRIV message that contains the new password for the user. This memo provides information for the Internet community.

このメモは、MicrosoftのWindows 2000のKerberosパスワード変更と設定したパスワードプロトコルを指定します。 Windows 2000のKerberosの変更パスワードプロトコルは、元のKerberosパスワード変更プロトコルと相互運用できます。パスワード変更は、ユーザーの新しいパスワードが含まれているKRB_PRIVメッセージを含む要求応答プロトコルです。このメモはインターネットコミュニティのための情報を提供します。

3243 Jonsson Apr 2002 RObust Header Compression (ROHC): Requirements and Assumptions for 0-byte IP/UDP/RTP Compression

3243ヨンソン2002年4月ロバストヘッダ圧縮（ROHC）：0バイトのIP / UDP / RTP圧縮のための要件と仮定

This document contains requirements for the 0-byte IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) header compression scheme to be developed by the Robust Header Compression (ROHC) Working Group. It also includes the basic assumptions for the typical link layers over which 0-byte compression may be implemented, and assumptions about its usage in general.

この文書では、ロバストヘッダ圧縮（ROHC）ワーキンググループによって開発される0バイトのIP / UDP / RTP（インターネット・プロトコル/ユーザ・データグラム・プロトコル/リアルタイムトランスポートプロトコル）のヘッダ圧縮方式のための要件が含まれています。それはまた、一般的にその使用についての基本的な0バイトの圧縮を実施することができる上に、典型的なリンク層のための前提条件、および仮定を含みます。

3242 Jonsson Apr 2002 RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP

3242ヨンソン2002年4月ロバストヘッダ圧縮（ROHC）：IP / UDP / RTPのためのリンク層支援のプロフィール

This document defines a ROHC (Robust Header Compression) profile for compression of IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) packets, utilizing functionality provided by the lower layers to increase compression efficiency by completely eliminating the header for most packets during optimal operation. The profile is built as an extension to the ROHC RTP profile. It defines additional mechanisms needed in ROHC, states requirements on the assisting layer to guarantee transparency, and specifies general logic for compression and decompression making use of this header-free packet. [STANDARDS TRACK]

この文書では、完全に排除することにより、圧縮効率を高めるために下位層によって提供される機能を利用し、IP / UDP / RTP（インターネット・プロトコル/ユーザ・データグラム・プロトコル/リアルタイムトランスポートプロトコル）パケットの圧縮のためのROHC（ロバストヘッダ圧縮）プロファイルを定義します最適動作中のほとんどのパケットのためのヘッダ。プロファイルはROHC RTPプロファイルの拡張として構築されています。これは、ROHCに必要な追加のメカニズムを定義し、透明性を保証するために、補助層上の要件を述べており、このヘッダを含まないパケットの圧縮および解凍作る使用のための一般的なロジックを指定します。 [STANDARDS TRACK]

3241 Bormann Apr 2002 Robust Header Compression (ROHC) over PPP

PPPを超える3241ボルマン2002年4月ロバストヘッダ圧縮（ROHC）

This document describes an option for negotiating the use of robust header compression (ROHC) on IP datagrams transmitted over the Point-to-Point Protocol (PPP). It defines extensions to the PPP Control Protocols for IPv4 and IPv6. [STANDARDS TRACK]

この文書では、ポイントツーポイントプロトコル（PPP）を介して送信されるIPデータグラムに強固なヘッダ圧縮（ROHC）の使用を交渉するためのオプションについて説明します。これは、IPv4とIPv6のPPP制御プロトコルの拡張機能を定義します。 [STANDARDS TRACK]

3240 Clunie Feb 2002 Digital Imaging and Communications in Medicine (DICOM) - Application/dicom MIME Sub-type Registration

3240 Clunie 2002年2月医療におけるデジタル画像と通信（DICOM） - アプリケーション/ DICOMのMIMEサブタイプ登録

This document describes the registration of the MIME sub-type application/dicom (Digital Imaging and Communications in Medicine). The baseline encoding is defined by the DICOM Standards Committee in "Digital Imaging and Communications in Medicine". This memo provides information for the Internet community.

この文書は、MIMEサブタイプapplication / DICOM（医学におけるデジタル画像と通信）の登録を記述する。ベースライン符号化は、「医療におけるデジタル画像と通信」のDICOM規格委員会によって定義されています。このメモはインターネットコミュニティのための情報を提供します。

3239 Kugler Feb 2002 Internet Printing Protocol (IPP): Requirements for Job, Printer, and Device Administrative Operations

3239クーグラー2002年2月、インターネット印刷プロトコル（IPP）：仕事、プリンタ、およびデバイスの管理操作のための要件

This document specifies the requirements and uses cases for some optional administrative operations for use with the Internet Printing Protocol (IPP) version 1.0 and version 1.1. Some of these administrative operations operate on the IPP Job and Printer objects. The remaining operations operate on a new Device object that more closely models a single output device. This memo provides information for the Internet community.

この文書では、要件を指定し、インターネット印刷プロトコル（IPP）バージョン1.0とバージョン1.1で使用するために、いくつかのオプションの管理操作のための例を使用しています。これらの管理操作のいくつかはIPP仕事とプリンタオブジェクトを操作します。残りの動作は、新しいデバイスオブジェクトより密接モデル単一の出力デバイス上で動作します。このメモはインターネットコミュニティのための情報を提供します。

3238 IAB Jan 2002 IAB Architectural and Policy Considerations for Open Pluggable Edge Services

3238オープンプラグイン可能なエッジサービスのためのIAB 2002年1月IAB建築・ポリシーの考慮事項

This document includes comments and recommendations by the IAB on some architectural and policy issues related to the chartering of Open Pluggable Edge Services (OPES) in the IETF. OPES are services that would be deployed at application-level intermediaries in the network, for example, at a web proxy cache between the origin server and the client. These intermediaries would transform or filter content, with the explicit consent of either the content provider or the end user. This memo provides information for the Internet community.

このドキュメントは、IETFで開くプラグイン可能なエッジサービス（OPES）のチャーターに関連するいくつかの建築や政策問題に関するIABのコメントや提言が含まれています。 OPESは、オリジンサーバとクライアントの間のウェブプロキシキャッシュで、例えば、ネットワーク内のアプリケーション・レベルの仲介で展開されるだろうサービスです。これらの仲介者は、コンテンツプロバイダまたはエンドユーザーのいずれかの明示的な同意を得て、変換またはコンテンツをフィルタリングします。このメモはインターネットコミュニティのための情報を提供します。

3237 Tuexen Jan 2002 Requirements for Reliable Server Pooling

信頼性の高いサーバーのプーリングの3237のTuexen 2002の1月要件

This document defines a basic set of requirements for reliable server pooling. This memo provides information for the Internet community.

この文書では、信頼性の高いサーバー・プーリングの要件の基本セットを定義します。このメモはインターネットコミュニティのための情報を提供します。

3236 Baker Feb 2002 The 'application/xhtml+xml' Media Type

3236ベイカー2002年2月「アプリケーション/ XHTML + xmlの」メディアの種類

This document defines the 'application/xhtml+xml' MIME media type for XHTML based markup languages; it is not intended to obsolete any previous IETF documents, in particular RFC 2854 which registers 'text/html'. This memo provides information for the Internet community.

この文書は、XHTMLベースのマークアップ言語の「アプリケーション/ XHTML + XML」MIMEメディアタイプを定義します。それは「text / htmlで」を登録し、特定のRFC 2854で、廃止された以前のIETFのドキュメントに意図されていません。このメモはインターネットコミュニティのための情報を提供します。

3235 Senie Jan 2002 Network Address Translator (NAT)-Friendly Application Design Guidelines

3235 Senie 2002年1月ネットワークアドレス変換（NAT）フレンドリアプリケーションの設計ガイドライン

This document discusses those things that application designers might wish to consider when designing new protocols. While many common Internet applications will operate cleanly in the presence of Network Address Translators, others suffer from a variety of problems when crossing these devices. Guidelines are presented herein to help ensure new protocols and applications will, to the extent possible, be compatible with NAT (Network Address Translation). This memo provides information for the Internet community.

この文書では、アプリケーション設計者は、新しいプロトコルを設計する際に考慮することを望むかもしれないそれらの事を説明します。多くの一般的なインターネットアプリケーションは、ネットワークアドレス変換の存在下できれいに動作しますが、これらのデバイスを横断するとき、他の人が様々な問題に苦しんでいます。ガイドラインは、可能な限り、NAT（ネットワークアドレス変換）との互換性があります新しいプロトコルやアプリケーションを確保するために、本明細書に提示されています。このメモはインターネットコミュニティのための情報を提供します。

3234 Carpenter Feb 2002 Middleboxes: Taxonomy and Issues

3234カーペンター2002年2月のMiddleboxes：分類と課題

This document is intended as part of an IETF discussion about "middleboxes" - defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host. This document establishes a catalogue or taxonomy of middleboxes, cites previous and current IETF work concerning middleboxes, and attempts to identify some preliminary conclusions. It does not, however, claim to be definitive. This memo provides information for the Internet community.

ソースホストと宛先ホストとの間のデータ経路上のIPルータの通常の、標準的な機能とは別に機能を実行する任意の中間のボックスとして定義 - 本文書は、「中間装置」についてのIETF議論の一部として意図されます。この文書は、ミドルボックスのカタログまたは分類法を確立し、以前と現在のIETF仕事に関する中間箱を引き合いに出して、そしていくつかの予備の結論を識別しようとします。それは、しかし、決定的であることを主張しません。このメモはインターネットコミュニティのための情報を提供します。

3233 Hoffman Feb 2002 Defining the IETF

3233ホフマン2002年2月IETFの定義

This document gives a more concrete definition of "the IETF" as it understood today. Many RFCs refer to "the IETF". Many important IETF documents speak of the IETF as if it were an already-defined entity. However, no IETF document correctly defines what the IETF is. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

この文書では、それが今日理解されるような「IETF」のより具体的な定義を与えます。多くのRFCは、「IETF」を参照してください。それは、すでに定義されたエンティティであるかのように多くの重要なIETF文書は、IETFの話します。しかし、IETF文書が正しくIETFが何であるかを定義しません。このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。

3232 Reynolds Jan 2002 Assigned Numbers: RFC 1700 is Replaced by an On-line Database

3232のレイノルズ2002年1月割り当て番号：RFC 1700は、オンラインデータベースで置き換えられます

This memo obsoletes RFC 1700 (STD 2) "Assigned Numbers", which contained an October 1994 snapshot of assigned Internet protocol parameters. This memo provides information for the Internet community.

このメモは、割り当てられたインターネットプロトコルパラメータの1994年10月スナップショットを含んでいたRFC 1700（STD 2）「割り当て番号」、時代遅れ。このメモはインターネットコミュニティのための情報を提供します。

3231 Levi Jan 2002 Definitions of Managed Objects for Scheduling Management Operations

スケジュール管理操作のための管理オブジェクトの3231のレビ2002の1月の定義

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to schedule management operations periodically or at specified dates and times. [STANDARDS TRACK]

このメモは、インターネットコミュニティでのネットワーク管理プロトコルで使用するための管理情報ベース（MIB）の一部を定義します。特に、それは定期的に、または指定した日時に管理操作をスケジュールするために使用されている管理対象オブジェクトの集合を記述する。 [STANDARDS TRACK]

3230 Mogul Jan 2002 Instance Digests in HTTP

HTTPで3230回のモーグル2002年1月のインスタンスダイジェスト

HTTP/1.1 defines a Content-MD5 header that allows a server to include a digest of the response body. However, this is specifically defined to cover the body of the actual message, not the contents of the full file (which might be quite different, if the response is a Content-Range, or uses a delta encoding). Also, the Content-MD5 is limited to one specific digest algorithm; other algorithms, such as SHA-1 (Secure Hash Standard), may be more appropriate in some circumstances. Finally, HTTP/1.1 provides no explicit mechanism by which a client may request a digest. This document proposes HTTP extensions that solve these problems. [STANDARDS TRACK]

HTTP / 1.1は、サーバがレスポンスボディのダイジェストを含むことができ、コンテンツ-MD5ヘッダを定義します。しかし、これは具体的には、実際のメッセージではない（応答がContent-範囲である、またはデルタ符号化を使用する場合、全く異なるかもしれない）完全なファイルの内容の体を覆うように定義されています。また、コンテンツ-MD5は、一つの特定のダイジェストアルゴリズムに限定されています。そのようなSHA-1などの他のアルゴリズムは、（ハッシュスタンダードセキュア）、いくつかの状況においてより適切であるかもしれません。最後に、HTTP / 1.1は、クライアントがダイジェストを要求する可能性があることにより、明示的なメカニズムを提供しません。この文書では、これらの問題を解決するためのHTTP拡張を提案しています。 [STANDARDS TRACK]

3229 Mogul Jan 2002 Delta encoding in HTTP

HTTPで3229モーグル2002年1月デルタエンコーディング

This document describes how delta encoding can be supported as a compatible extension to HTTP/1.1. [STANDARDS TRACK]

この文書は、デルタ符号化は、HTTP / 1.1と互換性拡張機能としてサポートすることができる方法について説明します。 [STANDARDS TRACK]

3228 Fenner Feb 2002 IANA Considerations for IPv4 Internet Group Management Protocol (IGMP)

IPv4インターネットグループ管理プロトコル（IGMP）のための3228のフェナー2002年2月IANAの考慮事項

This memo requests that the IANA create a registry for fields in the IGMP (Internet Group Management Protocol) protocol header, and provides guidance for the IANA to use in assigning parameters for those fields. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

このメモはIANAがIGMP（インターネットグループ管理プロトコル）プロトコルヘッダー内のフィールドのためのレジストリを作成することを要求し、IANAは、これらのフィールドのパラメータを割り当てる際に使用するためのガイダンスを提供します。このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。

3227 Brezinski Feb 2002 Guidelines for Evidence Collection and Archiving

証拠収集とアーカイブのために3227のBrezinski 2002年2月のガイドライン

A "security incident" as defined in the "Internet Security Glossary", RFC 2828, is a security-relevant system event in which the system's security policy is disobeyed or otherwise breached. The purpose of this document is to provide System Administrators with guidelines on the collection and archiving of evidence relevant to such a security incident. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

「インターネットセキュリティ用語集」で定義されている「セキュリティインシデント」、RFC 2828は、システムのセキュリティポリシーが従わなかっあるいは破られたセキュリティ関連のシステムイベントです。このドキュメントの目的は、このようなセキュリティインシデントに関連する証拠の収集及び保管上のガイドラインにシステム管理者に提供することです。このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。

3226 Gudmundsson Dec 2001 DNSSEC and IPv6 A6 aware server/resolver message size requirements

3226グドムンソン2001年12月DNSSECとIPv6 A6意識し、サーバ/リゾルバのメッセージサイズ要件

This document mandates support for EDNS0 (Extension Mechanisms for DNS) in DNS entities claiming to support either DNS Security Extensions or A6 records. This requirement is necessary because these new features increase the size of DNS messages. If EDNS0 is not supported fall back to TCP will happen, having a detrimental impact on query latency and DNS server load. This document updates RFC 2535 and RFC 2874, by adding new requirements. [STANDARDS TRACK]

このドキュメントの義務は、DNSセキュリティ拡張機能またはA6レコードのいずれかをサポートするために主張DNSエンティティにEDNS0（DNS用拡張メカニズム）をサポート。これらの新機能は、DNSメッセージのサイズを増やすため、この要件が必要です。 EDNS0がサポートされていない場合は、バックTCPの秋には、クエリの待機時間およびDNSサーバーの負荷に有害な影響を与えて、起こります。新しい要件を追加することによって、このドキュメントの更新RFC 2535およびRFC 2874、。 [STANDARDS TRACK]

3225 Conrad Dec 2001 Indicating Resolver Support of DNSSEC

DNSSECのレゾルバサポートを示す3225コンラッド2001年12月

In order to deploy DNSSEC (Domain Name System Security Extensions) operationally, DNSSEC aware servers should only perform automatic inclusion of DNSSEC RRs when there is an explicit indication that the resolver can understand those RRs. This document proposes the use of a bit in the EDNS0 header to provide that explicit indication and describes the necessary protocol changes to implement that notification. [STANDARDS TRACK]

リゾルバがこれらのRRを理解できることを明示がある場合に運用DNSSEC（ドメインネームシステムセキュリティ拡張）を展開するためには、DNSSEC対応サーバはDNSSEC RRの自動含めることを実行する必要があります。この文書は、明示的な指示を提供するEDNS0ヘッダ内のビットの使用を提案し、その通知を実装するために必要なプロトコルの変更を記載しています。 [STANDARDS TRACK]

3224 Guttman Jan 2002 Vendor Extensions for Service Location Protocol, Version 2

サービスロケーションプロトコル、バージョン2のための3224のグットマン2002年1月ベンダ拡張機能

This document specifies how the features of the Service Location Protocol, Version 2 allow for vendor extensibility safely, with no possibility of collisions. The specification introduces a new SLPv2 extension: The Vendor Opaque Extension. While proprietary protocol extensions are not encouraged by IETF standards, it is important that they not hinder interoperability of compliant implementations when they are undertaken. This document udpates RFC 2608, "The Service Location Protocol." [STANDARDS TRACK]

このドキュメントでは、サービスロケーションプロトコル、バージョン2の特徴は、衝突の可能性なしで、安全にベンダーの拡張を可能とする方法を指定します。ベンダー不透明拡張子：仕様は、新しいSLPv2の拡張を導入しています。独自のプロトコル拡張がIETF標準で奨励されていませんが、彼らが行われたときに、彼らが準拠する実装の相互運用性を妨げないことが重要です。このドキュメントのudpatesのRFC 2608、「サービスロケーションプロトコル。」 [STANDARDS TRACK]

3223 Never Issued

3223は、発行されたことはありません

RFC 3223 was never issued.

RFC 3223が発行されていませんでした。

3222 Trotter Dec 2001 Terminology for Forwarding Information Base (FIB) based Router Performance

転送情報ベース（FIB）ベースのルータのパフォーマンスのために3222トロッター2001年12月の用語

This document describes the terms to be used in a methodology that determines the IP packet forwarding performance of IP routers as a function of the forwarding information base installed within a router. The forwarding performance of an IP router may be dependent upon or may be linked to the composition and size of the forwarding information base installed within a router. This memo provides information for the Internet community.

この文書では、ルータ内に設置転送情報ベースの機能として、IPルータのIPパケット転送性能を決定する方法において使用される用語を説明しています。 IPルータの転送性能に依存し得るまたはルータ内に設置転送情報ベースの組成およびサイズに連結することができます。このメモはインターネットコミュニティのための情報を提供します。

3221 Huston Dec 2001 Commentary on Inter-Domain Routing in the Internet

インターネットにおけるドメイン間ルーティングに3221ヒューストン2001年12月解説

This document examines the various longer term trends visible within the characteristics of the Internet's BGP table and identifies a number of operational practices and protocol factors that contribute to these trends. The potential impacts of these practices and protocol properties on the scaling properties of the inter-domain routing space are examined. This memo provides information for the Internet community.

このドキュメントはインターネットのBGPテーブルの特性内に見える様々な長期的な傾向を調べて、これらの傾向に貢献する業務慣行およびプロトコルの多くの要因を特定します。ドメイン間ルーティング空間のスケール特性上のこれらの慣行とプロトコル特性の潜在的な影響について検討されています。このメモはインターネットコミュニティのための情報を提供します。

3220 Perkins Jan 2002 IP Mobility Support for IPv4

IPv4の3220パーキンス2002年1月IPモビリティサポート

This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. [STANDARDS TRACK]

この文書は、インターネットでのモバイルノードへIPデータグラムの透過的なルーティングを許可するプロトコルの拡張機能を指定します。各モバイルノードは関係なく、常にインターネットへの接続の現在のポイントの、そのホームアドレスによって識別されます。その家から離れて位置している間、モバイルノードは、気付アドレス、インターネットへの接続の現在のポイントに関する情報を提供して関連付けられています。プロトコルは、ホームエージェントに気付アドレスを登録するために用意されています。ホームエージェントは気付アドレスへのトンネルを介してモバイルノード宛てのデータグラムを送信します。トンネルの端に到達した後、各データグラムは、移動ノードに配信されます。 [STANDARDS TRACK]

3219 Rosenberg Jan 2002 Telephony Routing over IP (TRIP)

3219ローゼンバーグ2002年1月テレフォニールーティングオーバーIP（TRIP）

This document presents the Telephony Routing over IP (TRIP). TRIP is a policy driven inter-administrative domain protocol for advertising the reachability of telephony destinations between location servers, and for advertising attributes of the routes to those destinations. TRIP's operation is independent of any signaling protocol, hence TRIP can serve as the telephony routing protocol for any signaling protocol. [STANDARDS TRACK]

この文書では、IP（TRIP）上テレフォニールーティングを提示します。 TRIPは、ロケーションサーバ間のテレフォニーの目的地の到達可能性を広告するためのポリシー駆動間管理ドメインのプロトコルであり、そしてそれらの目的地へのルートの広告属性の。 TRIPの操作は、任意のシグナリングプロトコルとは無関係であり、したがってTRIPは、任意のシグナリングプロトコルのための電話ルーティングプロトコルとして機能することができます。 [STANDARDS TRACK]

3218 Rescorla Jan 2002 Preventing the Million Message Attack on Cryptographic Message Syntax

暗号メッセージ構文上の百万メッセージ攻撃を防ぐレスコラ3218 2002年1月

This memo describes a strategy for resisting the Million Message Attack. This memo provides information for the Internet community.

このメモは百万メッセージ攻撃に抵抗するための戦略を説明します。このメモはインターネットコミュニティのための情報を提供します。

3217 Housley Dec 2001 Triple-DES and RC2 Key Wrapping

3217 Housleyの2001年12月トリプルDESとRC2キーラッピング

This document specifies the algorithm for wrapping one Triple-DES key with another Triple-DES key and the algorithm for wrapping one RC2 key with another RC2 key. This memo provides information for the Internet community.

この文書では、別のトリプルDESのキーと別のRC2キーで1つのRC2キーを包むためのアルゴリズムと1トリプルDESキーを包むためのアルゴリズムを指定します。このメモはインターネットコミュニティのための情報を提供します。

3216 Elliott Dec 2001 SMIng Objectives

3216のエリオット2001年12月SMIng目的

This document describes the objectives for a new data definition language, suitable for the modeling of network management constructs, that can be directly mapped into SNMP and COPS-PR protocol operations. This memo provides information for the Internet community.

この文書では、直接SNMPとCOPS - PRプロトコル動作にマッピングすることができるネットワーク管理構造のモデリングに適した新しいデータ定義言語、のための目的を説明しています。このメモはインターネットコミュニティのための情報を提供します。

3215 Boscher Jan 2002 LDP State Machine

3215 Boscher 2002年1月LDPステートマシン

This document provides state machine tables for ATM (Asynchronous Transfer Mode) switch LSRs. In the current LDP specification, there is no state machine specified for processing LDP messages. We think that defining a common state machine is very important for interoperability between different LDP and CR-LDP implementations. This memo provides information for the Internet community.

この文書では、ATM（非同期転送モード）スイッチのLSRのためのステートマシンのテーブルを提供します。現在のLDP仕様で、LDPメッセージを処理するために指定されていない状態マシンは存在しません。私たちは、共通の状態マシンを定義する別のLDPやCR-LDP実装間の相互運用性のために非常に重要であると思います。このメモはインターネットコミュニティのための情報を提供します。

3214 Ash Jan 2002 LSP Modification Using CR-LDP

CR-LDPを使用して3214アッシュ2002年1月LSP変更

This document presents an approach to modify the bandwidth and possibly other parameters of an established CR-LSP (Constraint-based Routed Label Switched Paths) using CR-LDP (Constraint-based Routed Label Distribution Protocol) without service interruption. [STANDARDS TRACK]

この文書では、帯域幅を変更するためのアプローチを提示し、確立されたCR-LSPの可能性が他のパラメータは、サービスを中断することなくCR-LDP（制約ベースルーティングラベル配布プロトコル）を使用して、（制約ベースルーティングラベルは、パスの交換しました）。 [STANDARDS TRACK]

3213 Ash Jan 2002 Applicability Statement for CR-LDP

CR-LDPのための3213アッシュ2002年1月適用性に関する声明

This document discusses the applicability of Constraint-Based LSP Setup using LDP. It discusses possible network applications, extensions to Label Distribution Protocol (LDP) required to implement constraint-based routing, guidelines for deployment and known limitations of the protocol. This document is a prerequisite to advancing CR-LDP on the standards track. This memo provides information for the Internet community.

この文書では、LDPを使用して制約ベースのLSP設定の適用可能性を論じています。これは、可能なネットワークアプリケーション、展開およびプロトコルの既知の制限のため、制約ベースのルーティング、ガイドラインを実装するために必要なラベル配布プロトコル（LDP）の拡張機能について説明します。この文書では、標準化過程の上CR-LDPを進めるための前提条件です。このメモはインターネットコミュニティのための情報を提供します。

3212 Jamoussi Jan 2002 Constraint-Based LSP Setup using LDP

LDPを使用して3212 Jamoussi 2002年1月制約ベースのLSPのセットアップ

This document specifies mechanisms and TLVs (Type/Length/Value) for support of CR-LSPs (constraint-based routed Label Switched Path) using LDP (Label Distribution Protocol). [STANDARDS TRACK]

この文書はLDP（ラベル配布プロトコル）を使用して、CR-LSPを（制約ベースのルーティングされたラベルスイッチパス）のサポートのためのメカニズムとのTLV（タイプ/長さ/値）を指定します。 [STANDARDS TRACK]

3211 Gutmann Dec 2001 Password-based Encryption for CMS

CMSのための3211 Gutmann氏2001年12月パスワードベースの暗号化

This document provides a method of encrypting data using user-supplied passwords and, by extension, any form of variable-length keying material which is not necessarily an algorithm-specific fixed-format key. The Cryptographic Message Syntax data format does not currently contain any provisions for password-based data encryption. [STANDARDS TRACK]

このドキュメントは、拡張により、必ずしもアルゴリズム固有の固定フォーマットのキーではない可変長鍵材料の任意の形式をユーザが提供するパスワードを使用してデータを暗号化する方法を提供します。暗号メッセージ構文のデータ・フォーマットは、現在、パスワードベースのデータ暗号化のためのいずれかの条項が含まれていません。 [STANDARDS TRACK]

3210 Awduche Dec 2001 Applicability Statement for Extensions to RSVP for LSP-Tunnels

LSP-トンネルのためのRSVPへの拡張のための3210 Awduche 2001年12月適用性に関する声明

This memo discusses the applicability of "Extensions to RSVP (Resource ReSerVation Protocol) for LSP Tunnels". It highlights the protocol's principles of operation and describes the network context for which it was designed. Guidelines for deployment are offered and known protocol limitations are indicated. This document is intended to accompany the submission of "Extensions to RSVP for LSP Tunnels" onto the Internet standards track. This memo provides information for the Internet community.

このメモは、「LSPトンネルのためのRSVPへの拡張（リソース予約プロトコル）」の適用可能性を論じています。これは、操作のプロトコルの原則を強調し、それが設計されたネットワークの状況を説明しています。展開のためのガイドラインが提供され、既知のプロトコルの制限が示されています。この文書は、インターネット標準トラックに「LSPトンネルのためのRSVPへの拡張」の提出を同行することを意図しています。このメモはインターネットコミュニティのための情報を提供します。

3209 Awduche Dec 2001 RSVP-TE: Extensions to RSVP for LSP Tunnels

3209 Awduche 2001年12月RSVP-TE：拡張機能は、LSPトンネルのためのRSVPに

This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS TRACK]

この文書では、MPLS（マルチプロトコルラベルスイッチング）でラベルスイッチパス（LSPを）確立すること、必要なすべての拡張を含むRSVP（リソース予約プロトコル）の使用を記載しています。 LSPに沿った流れが完全パスの入口ノードで適用されたラベルによって識別されるので、これらの経路は、トンネルのように処理することができます。 RFC 2702で指定されるようにLSPトンネルの主要なアプリケーションは、MPLSとトラフィック・エンジニアリングである[STANDARDS TRACK]

3208 Speakman Dec 2001 PGM Reliable Transport Protocol Specification

3208スピークマン2001年12月PGM信頼できるトランスポートプロトコル仕様

Pragmatic General Multicast (PGM) is a reliable multicast transport protocol for applications that require ordered or unordered, duplicate-free, multicast data delivery from multiple sources to multiple receivers. PGM guarantees that a receiver in the group either receives all data packets from transmissions and repairs, or is able to detect unrecoverable data packet loss. PGM is specifically intended as a workable solution for multicast applications with basic reliability requirements. Its central design goal is simplicity of operation with due regard for scalability and network efficiency. This memo defines an Experimental Protocol for the Internet community.

実用的な一般的なマルチキャスト（PGM）は、順序、または複数の受信機に複数のソースから順不同、重複のない、マルチキャストデータ配信を必要とするアプリケーションのための信頼性の高いマルチキャストトランスポートプロトコルです。 PGMは、グループ内の受信機は、送信及び修理からすべてのデータパケットを受信し、又は回復不能なデータパケット損失を検出することができるいずれかのことを保証します。 PGMは、具体的には、基本的な信頼性が要求されるマルチキャストアプリケーションのための実行可能な解決策として意図されています。その中央の設計目標は、拡張性とネットワーク効率のために考慮した操作の簡便です。このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。

3207 Hoffman Feb 2002 SMTP Service Extension for Secure SMTP over Transport Layer Security

トランスポート層セキュリティの安全なSMTPのための3207ホフマン2002年2月のSMTPサービス拡張

This document describes an extension to the SMTP (Simple Mail Transfer Protocol) service that allows an SMTP server and client to use TLS (Transport Layer Security) to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers. [STANDARDS TRACK]

この文書では、SMTPサーバとクライアントがインターネット経由でプライベート、認証された通信を提供するために、TLS（トランスポート層セキュリティ）を使用することを可能にするSMTP（簡易メール転送プロトコル）サービスの拡張について説明します。これは、SMTP用薬盗聴や攻撃から自分のコミュニケーションの一部または全てを保護することができます。 [STANDARDS TRACK]

3206 Gellens Feb 2002 The SYS and AUTH POP Response Codes

3206 Gellens 2002年2月SYSとAUTH POP応答コード

This memo proposes two response codes: SYS and AUTH, which enable clients to unambiguously determine an optimal response to an authentication failure. In addition, a new capability (AUTH-RESP-CODE) is defined. [STANDARDS TRACK]

SYSとAUTH、明確に認証失敗に最適な応答を決定するために、クライアントを有効にする：このメモは、2つの応答コードを提案しています。また、新機能（AUTH-RESP-CODE）が定義されます。 [STANDARDS TRACK]

3205 Moore Feb 2002 On the use of HTTP as a Substrate

基質としてHTTPを使用するには3205ムーア2002年2月

Recently there has been widespread interest in using Hypertext Transfer Protocol (HTTP) as a substrate for other applications-level protocols. This document recommends technical particulars of such use, including use of default ports, URL schemes, and HTTP security mechanisms. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

最近、他のアプリケーションレベルのプロトコルのための基質としてハイパーテキスト転送プロトコル（HTTP）を使用してで広く関心がありました。このドキュメントでは、デフォルトポート、URLスキーム、およびHTTPのセキュリティメカニズムの使用を含め、このような使用の技術的な詳細を、お勧めします。このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。

3204 Zimmerer Dec 2001 MIME media types for ISUP and QSIG Objects

ISUPとQSIGオブジェクトの3204のZimmerer 2001年12月MIMEメディアタイプ

This document describes MIME types for application/ISUP and application/QSIG objects for use in SIP applications, according to the rules defined in RFC 2048. These types can be used to identify ISUP and QSIG objects within a SIP message such as INVITE or INFO, as might be implemented when using SIP in an environment where part of the call involves interworking to the PSTN. [STANDARDS TRACK]

この文書は、これらのタイプは、INVITEまたはINFOなどのSIPメッセージ内ISUPとQSIGオブジェクトを識別するために使用することができるRFC 2048で定義された規則に従って、SIPアプリケーションで使用するためのアプリケーション/ ISUPとアプリケーション/ QSIGオブジェクトのMIMEタイプを記述する呼び出しの一部は、PSTNへの相互動作を必要とする環境でSIPを使用したときのように実装される可能性があります。 [STANDARDS TRACK]

3203 T'Joens Dec 2001 DHCP reconfigure extension

3203 T'Joens 2001年12月DHCPの再設定の拡張機能

This document defines extensions to DHCP (Dynamic Host Configuration Protocol) to allow dynamic reconfiguration of a single host triggered by the DHCP server (e.g., a new IP address and/or local configuration parameters). [STANDARDS TRACK]

この文書では、DHCPサーバ（例えば、新しいIPアドレスおよび/またはローカル設定パラメータ）によってトリガ単一のホストの動的な再構成を可能にするために、DHCP（動的ホスト構成プロトコル）の拡張機能を定義します。 [STANDARDS TRACK]

3202 Steinberger Jan 2002 Definitions of Managed Objects for Frame Relay Service Level Definitions

フレームリレーサービスレベルの定義のための管理オブジェクトの3202のシュタイン2002の1月の定義

このメモはTCP / IPベースのインターネットでネットワーク管理プロトコルで使用するための管理情報ベース（MIB）の拡張を定義します。特に、それはフレームリレーサービスレベルの定義を管理するためのオブジェクトを定義します。 [STANDARDS TRACK]

3201 Steinberger Jan 2002 Definitions of Managed Objects for Circuit to Interface Translation

インタフェース変換するための回路のための管理オブジェクトの3201のシュタイン2002の1月の定義

This memo defines an extension of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the insertion of interesting Circuit Interfaces into the ifTable. This is important for circuits that must be used within other MIB modules which require an ifEntry. It allows for integrated monitoring of circuits as well as routing to circuits using unaltered, pre-existing MIB modules. [STANDARDS TRACK]

このメモはTCP / IPベースのインターネットでネットワーク管理プロトコルで使用するための管理情報ベース（MIB）の拡張を定義します。特に、それはifTableのに面白いサーキットインタフェースの挿入を管理するためにオブジェクトを定義します。これはifEntryのを必要とする他のMIBモジュール内で使用しなければならない回路のために重要です。これは不変、既存のMIBモジュールを使用して、回路への集積回路の監視ならびにルーティングを可能にします。 [STANDARDS TRACK]

3200 Never Issued

3200は、発行されたことはありません

RFC 3200 was never issued.

RFC 3200が発行されていませんでした。

Security Considerations

セキュリティの考慮事項

Security issues are not discussed in this memo.

セキュリティ問題はこのメモでは議論しません。

Author's Address

著者のアドレス

Sandy Ginoza University of Southern California Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292

南カリフォルニア情報科学研究所のサンディ・宜野座大学4676アドミラルティWayマリナデルレイ、CA 90292

Phone: (310) 822-1511 EMail: ginoza@isi.edu

電話：（310）822-1511 Eメール：ginoza@isi.edu

Full Copyright Statement

完全な著作権声明

著作権（C）インターネット協会（2003）。全著作権所有。

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。