RFC3096 日本語訳

Network Working Group                               M. Degermark, Editor
Request for Comments: 3096                         University of Arizona
Category: Informational                                        July 2001

ワーキンググループのM.デーゲルマルク、コメントを求めるエディタ要求をネットワークでつないでください: 3096年のアリゾナ大学カテゴリ: 情報の2001年7月

         Requirements for robust IP/UDP/RTP header compression

強健なIP/UDP/RTPヘッダー圧縮のための要件

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Copyright(C)インターネット協会(2001)。 All rights reserved。

Abstract

要約

   This document contains requirements for robust IP/UDP/RTP (Internet
   Protocol/User Datagram Protocol/Real-Time Transport Protocol) header
   compression to be developed by the ROHC (Robust Header Compression)
   WG.  It is based on the ROHC charter, discussions in the WG, the 3GPP
   document "3GPP TR 23.922", version 1.0.0 of October 1999, as well as
   contributions from 3G.IP.

このドキュメントは強健なIP/UDP/RTP(インターネットのリアルプロトコル/ユーザー・データグラム・プロトコル/タイムのTransportプロトコル)ヘッダー圧縮がROHC(強健なHeader Compression)WGによって開発されるという要件を含んでいます。 それはROHC特許に基づいています、WGでの議論、「1999年の.0回のバージョン1.0 10月、また、23.922インチと、3G.IPからの貢献としての3GPP TR」という3GPPドキュメント。

1.  Introduction

1. 序論

   The goal of the ROHC WG is to develop header compression schemes that
   perform well over links with high error rates and long link round
   trip times.  The schemes must perform well for cellular links built
   using technologies such as WCDMA, EDGE, and CDMA-2000.  However, the
   schemes should also be applicable to other future link technologies
   with high loss and long round trip times.

ROHC WGの目標は高い誤り率と長いリンク周遊旅行回数とのリンクの上によく振る舞うヘッダー圧縮技術を開発することです。 計画はWCDMAや、EDGEや、CDMA-2000などの技術を使用することで造られたセルリンクによく振る舞わなければなりません。 しかしながら、また、計画も高い損失と長い周遊旅行時間で他の将来のリンク技術に適切であるべきです。

   The following requirements have, more or less arbitrarily, been
   divided into three groups.  The first group deals with requirements
   concerning the impact of an header compression scheme on the rest of
   the Internet infrastructure.  The second group concerns what kind of
   headers that must be compressed efficiently.  The final group
   concerns efficiency requirements and requirements which stem from the
   properties of the anticipated link technologies.

以下の要件、多少任意に持って、分割される、3つのグループ。 最初のグループはインターネット基盤の残りに関するヘッダー圧縮技術の影響に関して要件に対処します。 2番目のグループは効率的に圧縮しなければならないどういうヘッダーに関係があるか。 最終的なグループは予期されたリンク技術の特性による効率要件と要件に関係があります。

2. Header compression requirements

2. ヘッダー圧縮要件

   Several current standardization efforts in the cellular arena aim at
   supporting voice over IP and other real-time services over IP, e.g.,
   GERAN (specified by the ETSI SMG2 standards group), and UTRAN

セルアリーナでのいくつかの現在の標準化の努力がIP、例えば、IP、GERANの上の他のリアルタイムのサービス(ETSI SMG2規格グループによって指定される)、およびUTRANの上で声を支持するのを目的とします。

Degermark                    Informational                      [Page 1]

RFC 3096            Requirements for IP/UDP/RTP ROHC           July 2001

IP/UDP/RTP ROHC2001年7月のためのデーゲルマルク情報[1ページ]のRFC3096Requirements

   (specified by the 3GPP standards organization).  It is critical for
   these standardization efforts that a suitable header compression
   scheme is developed before completion of the Release 2000 standards.
   Therefore, it is imperative that the ROHC WG keeps its schedule.

(3GPP規格組織によって指定されます。) それは、適当なヘッダー圧縮技術が2000年のRelease規格の完成の前に開発されるのがこれらの標準化の努力に重要です。 したがって、ROHC WGがスケジュールを保つのは、必須です。

2.1 Impact on Internet infrastructure

2.1 インターネット基盤への影響

   1. Transparency: When a header is compressed and then decompressed,
   the resulting header must be semantically identical to the original
   header.  If this cannot be achieved, the packet containing the
   erroneous header must be discarded.

1. 透明: ヘッダーが圧縮されて、次に、減圧されるとき、オリジナルのヘッダーに、結果として起こるヘッダーは意味的に同じでなければなりません。 これを達成できないなら、誤ったヘッダーを含むパケットを捨てなければなりません。

   Justification: The header compression process must not produce
   headers that might cause problems for any current or future part of
   the Internet infrastructure.

正当化: ヘッダー圧縮の過程はインターネット基盤のどんな現在の、または、将来の部分にも問題を起こすかもしれないヘッダーを作り出してはいけません。

   2. Ubiquity: Must not require modifications to existing IP (v4 or
   v6), UDP, or RTP implementations.

2. 偏在: 既存のIP(v4かv6)、UDP、またはRTP実現への変更を必要としてはいけません。

   Justification: Ease of deployment.

正当化: 展開の容易さ。

   Note: The ROHC WG may recommend changes that would increase the
   compression efficiency for the RTP streams emitted by
   implementations.  However, ROHC cannot rely on such recommendations
   being followed.

以下に注意してください。 ROHC WGは実現で放たれたRTPの流れのために圧縮効率を増加させる変化を推薦するかもしれません。 しかしながら、ROHCは続かれているそのような推薦に依存できません。

2.2 Supported headers and kinds of RTP streams

2.2 支持されたヘッダーと種類のRTPの流れ

   1. IPv4 and IPv6: Must support both IPv4 and IPv6.

1. IPv4とIPv6: IPv4とIPv6の両方を支持しなければなりません。

   Justification: IPv4 and IPv6 will both be around during the
   foreseeable future.

正当化: IPv4とIPv6が予見できる未来に周囲にともにあるでしょう。

   2. Mobile IP: The kinds of headers used by Mobile IP{v4,v6} should be
   compressed efficiently.  For IPv4 these include headers of tunneled
   packets.  For IPv6 these include headers containing the Routing
   Header, the Binding Update Destination Option, and the Home Address
   option.

2. モバイルIP: ヘッダーの種類はモバイルでIPを使用しました。v4、v6は効率的に圧縮されるべきです。 IPv4に関しては、これらはトンネルを堀られたパケットのヘッダーを含んでいます。 IPv6に関しては、これらはルート設定Header、Binding Update Destination Option、およびホームAddressオプションを含むヘッダーを含んでいます。

   Justification: It is very likely that Mobile IP will be used by
   cellular devices.

正当化: モバイルIPはセル装置によって非常に使用されそうでしょう。

   3. Genericity: Must support compression of headers of arbitrary RTP
   streams.

3. Genericity: 任意のRTPの流れのヘッダーの圧縮を支持しなければなりません。

Degermark                    Informational                      [Page 2]

RFC 3096            Requirements for IP/UDP/RTP ROHC           July 2001

IP/UDP/RTP ROHC2001年7月のためのデーゲルマルク情報[2ページ]のRFC3096Requirements

   Justification: There must be a generic scheme which can compress
   reasonably well for any payload type and traffic pattern.  This does
   not preclude optimizations for certain media types where the traffic
   pattern is known, e.g., for low-bandwidth voice and low-bandwidth
   video.

正当化: どんなペイロードタイプとトラフィック・パターンのためにも合理的に井戸を圧縮できる一般的な計画があるに違いありません。 これはトラフィック・パターンが知られているあるメディアタイプのために最適化を排除しません、例えば、低バンド幅声と低バンド幅ビデオのために。

   Note: This applies to the RTP stream before as well as after it has
   passed through an internet.

以下に注意してください。 以前、インターネットを通り抜けた後にこれはRTPの流れに適用されます。

   4. IPSEC: ROHC should be able to compress headers containing IPSEC
   subheaders.

4. IPSEC: ROHCはIPSEC subheadersを含むヘッダーを圧縮するはずであることができます。

   Note: It is of course not possible to compress the encrypted part of
   an ESP header, nor the cryptographic data in an AH header.

以下に注意してください。 超能力ヘッダーのコード化された一部、およびAHヘッダーの暗号のデータを圧縮するのはもちろん可能ではありません。

2.3 Efficiency

2.3 効率

   1. Performance/Spectral Efficiency: Must provide low relative
   overhead under expected operating conditions; compression efficiency
   should be better than for RFC 2508 under equivalent operating
   conditions.  The error rate should only marginally increase the
   overhead under expected operating conditions.

1. パフォーマンス/スペクトル効率: 頭上の予想された運転条件の低い親類は提供しなければなりません。 圧縮効率はRFC2508より同等な運転条件の下で良いはずです。 誤り率は予想された運転条件の下でオーバーヘッドをわずかに上げるだけであるべきです。

   Justification: Spectrum efficiency is a primary goal.  RFC 2508 does
   not perform well enough.

正当化: スペクトル効率は第一の目標です。 RFC2508は十分よく働きません。

   Note: The relative overhead is the average header overhead relative
   to the payload.  Any auxiliary (e.g., control or feedback) channels
   used by the scheme should be taken into account when calculating the
   header overhead.

以下に注意してください。 相対的なオーバーヘッドはペイロードに比例した平均したヘッダーオーバーヘッドです。 ヘッダーオーバーヘッドについて計算するとき、計画によって使用されるどんな補助(例えば、コントロールかフィードバック)のチャンネルも考慮に入れられるべきです。

   2. Error propagation: Error propagation due to header compression
   should be kept at an absolute minimum.  Error propagation is defined
   as the loss or damage of headers subsequent to headers lost or
   damaged by the link, even if those subsequent headers are not lost or
   damaged.

2. 誤り伝播: ヘッダー圧縮による誤り伝播は絶対最小値で保たれるべきです。 誤り伝播はリンクによってなくされているか、または破損させられるヘッダーにおける、その後のヘッダーの滅失毀損と定義されます、それらのその後のヘッダーがなくされてもいませんし、破損もしないでも。

   Justification: Error propagation reduces spectral efficiency and
   reduces quality.  CRTP suffers severely from error propagation.

正当化: 誤り伝播は、スペクトル効率を減少させて、品質を減少させます。 CRTPは誤り伝播から呻吟します。

   Note: There are at least two kinds of error propagation; loss
   propagation, where an error causes subsequent headers to be lost, and
   damage propagation, where an error causes subsequent headers to be
   damaged.

以下に注意してください。 少なくとも2種類の誤り伝播があります。 損失伝播。(そこでは、誤りが、誤りでその後のヘッダーを破損させるところでその後のヘッダーが失われていて、伝播を破損することを引き起こします)。

Degermark                    Informational                      [Page 3]

RFC 3096            Requirements for IP/UDP/RTP ROHC           July 2001

IP/UDP/RTP ROHC2001年7月のためのデーゲルマルク情報[3ページ]のRFC3096Requirements

   3a. Handover loss events: There must be a way to run ROHC where loss
   events of length 150 milliseconds are handled efficiently and where
   loss or damage propagation is not introduced by ROHC during such
   events.

3a。 引き渡し損失出来事: 150ミリセカンドの長さの損失出来事が効率的に扱われて、滅失毀損伝播がそのような出来事の間にROHCによって導入されないROHCを走らせる方法があるに違いありません。

   Justification: Such loss events can be introduced by handover
   operations in a (radio) network between compressor and decompressor.
   Handover operations can be frequent in cellular systems.  Failure to
   handle handover well can adversely impact spectrum efficiency and
   quality.

正当化: (ラジオ)ネットワークでコンプレッサーと減圧装置に引き渡し操作でそのような損失出来事を取り入れられることができます。 引き渡し操作はセルラ方式で頻繁である場合があります。引き渡しをよく扱わない場合、逆にスペクトル効率と品質に影響を与えることができます。

   3b. Handover context recreation: There must be a way to run ROHC that
   deals well with events where the route of an RTP conversation changes
   such that either the compressor or the decompressor of the
   conversation is relocated to another node, where the context needs to
   be recreated.  ROHC must not introduce erroneous headers during such
   events, and should not introduce packet loss during such events.

3b。 引き渡し文脈レクリエーション: 出来事によく対処するROHCを走らせる方法がRTPの会話のルートが変化するので会話のコンプレッサーか減圧装置のどちらかが別のノードに移動するところにあるに違いありません。そこでは、文脈が、休養させられる必要があります。 ROHCはそのような出来事の間、誤ったヘッダーを紹介してはいけなくて、そのような出来事の間、パケット損失を導入するはずがありません。

   Justification: Such events can be frequent in cellular systems where
   the compressor/decompressor on the network side is close to the radio
   base stations.

正当化: ラジオ基地局の近くにネットワーク側の上のコンプレッサー/減圧装置があるところでそのような出来事はセルラ方式で頻繁である場合があります。

   Note: In order to aid developers of context recreation schemes where
   context is transfered to the new node, the specification shall
   outline what parts of the context is to be transfered, as well as
   conditions for its use.  Procedures for context recreation (and
   discard) without such context transfer will also be provided.

以下に注意してください。 文脈が新しいノードにtransferedされるところで文脈レクリエーション計画の開発者を支援するために、仕様は文脈のどんな部分がtransferedされることになっていたらよいか、そして、使用のための状態について概説するものとします。 また、そのような文脈転送のない文脈レクリエーション(捨てる)のための手順を提供するでしょう。

   4. Link delay: Must operate under all expected link delay conditions.

4. 遅れをリンクしてください: すべての予想されたリンク遅れ条件のもとで作動しなければなりません。

   5. Processing delay: The scheme must not contribute significantly to
   system delay budget.

5. 処理遅れ: 計画はシステム遅れ予算にかなり貢献してはいけません。

   6. Multiple links: The scheme must perform well when there are two or
   more cellular links in the end-to-end path.

6. 複数のリンク: 終わらせる終わりの2以上のセルリンク経路があるとき、計画はよく振る舞わなければなりません。

   Justification: Such paths will occur.

正当化: そのような経路は起こるでしょう。

   Note: loss on previous links will cause irregularities in the RTP
   stream reaching the compressor.  Such irregularities should only
   marginally affect performance.

以下に注意してください。 前のリンクにおける損失はコンプレッサーに達するRTPの流れで不規則を引き起こすでしょう。 そのような不規則は性能にわずかに影響するだけであるべきです。

   7a. Packet Misordering: The scheme should be able to compress when
   there are misordered packets in the RTP stream reaching the
   compressor.  No misordering is expected on the link between
   compressor and decompressor.

7a。 パケットMisordering: 計画はそこであるのに圧縮できるのが、コンプレッサーに達するRTPの流れのmisorderedパケットであるということであるべきです。 misorderingはコンプレッサーと減圧装置とのリンクの上に予想されません。

Degermark                    Informational                      [Page 4]

RFC 3096            Requirements for IP/UDP/RTP ROHC           July 2001

IP/UDP/RTP ROHC2001年7月のためのデーゲルマルク情報[4ページ]のRFC3096Requirements

   Justification: Misordering happens regularly in the Internet.
   However, since the Internet is engineered to run TCP reasonably well,
   excessive misordering will not be common and need not be handled with
   optimum efficiently.

正当化: Misorderingはインターネットで定期的に起こります。 しかしながら、インターネットが合理的にTCPをよく動かすために設計されるので、過度のmisorderingは一般的でなく、最適条件で効率的に扱われる必要はありません。

   7b. Moderate Packet Misordering: The scheme should efficiently handle
   moderate misordering (2-3 packets) in the packet stream reaching the
   compressor.

7b。 パケットMisorderingを加減してください: 計画は、コンプレッサーに達しながら、効率的に、パケットの流れにおける適度のmisordering(2-3 パケット)を扱うべきです。

   Note: This kind of reordering is common.

以下に注意してください。 この種類の再命令は一般的です。

   8. Unidirectional links/multicast: Must operate (possibly with less
   efficiency) over links where there is no feedback channel or where
   there are several receivers.

8. 単方向のリンク/マルチキャスト: フィードバックチャンネルが全くないか、または数台の受信機があるリンクの上に作動しなければなりません(ことによるとより少ない効率で)。

   9. Configurable frame size fluctuation: It should be possible to
   restrict the number of different frame sizes used by the scheme.

9. 構成可能なフレーム・サイズ変動: 計画によって使用される異なったフレーム・サイズの数を制限するのは可能であるべきです。

   Justification: Some radio technologies support only a limited number
   of frame sizes efficiently.

正当化: いくつかのラジオ技術が効率的に限られた数のフレーム・サイズだけを支持します。

   Note: Somewhat degraded performance is to be expected when such
   restrictions are applied.

以下に注意してください。 いくらか降格している性能はそのような制限が適用されているとき、予想されることです。

   Note: This implies that a list of "good" frame sizes must be made
   available and that ROHC may pick a suitable header format to utilize
   available space as well as possible.

以下に注意してください。 これは、ROHCが「良い」フレーム・サイズのリストを利用可能にしなければならなくて、利用可能なスペースをできるだけよく利用するために適当なヘッダー形式を選ぶかもしれないのを含意します。

   10. Delay: ROHC should not noticeably add to the end-to-end delay.

10. 遅れ: ROHCは終わりから終わりへの遅れに顕著に加えるはずがありません。

   Justification: RTP packets carrying data for interactive voice or
   video have a limited end-to-end delay budget.

正当化: 対話的な声かビデオのためのデータを運ぶRTPパケットが終わりから終わりへの遅れ限られた予算を持っています。

   Note: This requirement is intended to prevent schemes that achieve
   robustness at the expense of delay, for example schemes that require
   that header i+x, x>0, is received before header i can be
   decompressed.

以下に注意してください。 この要件が遅れ(例えば、ヘッダーiを減圧できる前にヘッダーi+x(x>0)が受け取られているのを必要とする計画)を犠牲にして丈夫さを実現する計画を防ぐことを意図します。

   Note: Together with 2.3.5, this requirement implies that ROHC will
   not noticeably add to the jitter of the RTP stream, other than what
   is caused by variations in header size.

以下に注意してください。 2.3、.5、この要件は、ROHCがRTPの流れのジターに顕著に加えないのを含意します、ヘッダーサイズの変化によって引き起こされることを除いて。

   Note: This requirement does not prevent a queue from forming upstream
   a bottleneck link.  Nor does it prevent a compressor from utilizing
   information from more than one header in such a queue.

以下に注意してください。 この要件は、待ち行列が上流へボトルネックリンクを形成するのを防ぎません。 また、それは、1個以上のヘッダーからそのような待ち行列でコンプレッサーが情報を利用するのを防ぎません。

   11. Residual errors: For a residual bit-error rate of at most 1e-5,
   the ROHC scheme must not increase the error rate.

11. 見逃し誤り: 高々1e-5の残りのビット誤り率のために、ROHC計画は誤り率を増加させてはいけません。

Degermark                    Informational                      [Page 5]

RFC 3096            Requirements for IP/UDP/RTP ROHC           July 2001

IP/UDP/RTP ROHC2001年7月のためのデーゲルマルク情報[5ページ]のRFC3096Requirements

   Justification: Some target links have a residual error rate, i.e,
   rate of undetected errors, of this magnitude.

正当化: いくつかの目標リンクには、見逃し誤りレート、i.e、非検出された誤り、この大きさのレートがあります。

   Note: In the presence of residual bit-errors, ROHC will need error
   detection mechanisms to prevent damage propagation.  These mechanisms
   will catch some residual errors, but those not caught might cause
   damage propagation.  This requirement states that the reduction of
   the damage rate due to the error detection mechanisms must not be
   less than the increase in error rate due to damage propagation.

以下に注意してください。 残りのビット誤りがあるとき、ROHCは、損害伝播を防ぐために誤り検出メカニズムを必要とするでしょう。 これらのメカニズムはいくつかの見逃し誤りを捕らえるでしょうが、捕らえられなかったものは損害伝播を引き起こすかもしれません。 この要件は、損害の減少が、間違い増加以下が伝播を破損するのにおいて当然のレートであったに違いないなら誤りのため検出がメカニズムであると評定すると述べます。

3.  IANA Considerations

3. IANA問題

   A protocol which meets these requirements, e.g., [ROHC], will require
   the IANA to assign various numbers.  This document by itself,
   however, does not require any IANA involvement.

これらの必要条件を満たすプロトコル例えば、[ROHC]は、IANAが様々な数を割り当てるのを必要とするでしょう。 しかしながら、それ自体でこのドキュメントは少しのIANAかかわり合いも必要としません。

4.  Security Considerations

4. セキュリティ問題

   A protocol specified to meet these requirements, e.g., [ROHC], must
   be able to compress packets containing IPSEC headers according to the
   IPSEC requirement, 2.2.4.  There may be other security aspects to
   consider in such protocols.  This document by itself, however, does
   not add any security risks.

これらの必要条件を満たすために指定されたプロトコル例えば、[ROHC]がIPSEC要件に従ってIPSECヘッダーを含むパケットを圧縮できなければならない、2.2、.4 そのようなプロトコルで考える他のセキュリティ局面があるかもしれません。 しかしながら、それ自体でこのドキュメントは少しのセキュリティ危険も加えません。

5.  Editor's Address

5. エディタのアドレス

   Mikael Degermark
   Dept. of Computer Science
   University of Arizona
   P.O. Box 210077
   Tucson, AZ 85721-0077
   USA

コンピュータサイエンスアリゾナ大学私書箱210077ツーソン、アリゾナ85721-0077米国のマイケルデーゲルマルク部

   Phone: (May-July): +46 70 833-8933
   Phone: +1 520 621-3489
   Fax:   +1 520 621-4246
   EMail: micke@cs.arizona.edu

以下に電話をしてください。 (5月-7月): +46 70 833-8933電話: +1 520 621-3489Fax: +1 520 621-4246 メールしてください: micke@cs.arizona.edu

Degermark                    Informational                      [Page 6]

RFC 3096            Requirements for IP/UDP/RTP ROHC           July 2001

IP/UDP/RTP ROHC2001年7月のためのデーゲルマルク情報[6ページ]のRFC3096Requirements

6.  References

6. 参照

   [TR]      3GPP TR 23.922 version 1.0.0, 3rd Generation partnership
             Project; Technical Specification Group Services and Systems
             Aspects; Architecture for an All IP network.

[TR]3GPP TR23.922バージョン1.0.0、3番目のGenerationパートナーシップProject。 仕様書グループサービスとシステム局面。 All IPネットワークのための構造。

   [TS]      TS 22.101 version 3.6.0: Service Principles

[TS]TS22.101バージョン3.6.0: サービス原則

   [RFC768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
             August 1980.

[RFC768] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、1980年8月。

   [RFC791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
             1981.

[RFC791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。

   [RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed
             Serial Links", RFC 1144, February 1990.

1990年2月の[RFC1144]ジェーコブソン対「低速連続のリンクへのTCP/IPヘッダーを圧縮すること」でのRFC1144

   [CRTP]    Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers
             for Low-Speed Serial Links", RFC 2508, February 1999.

[CRTP]Casner、S.、およびRFC2508、1999年2月対「低速連続のリンクへのIP/UDP/RTPヘッダーを圧縮する」ジェーコブソン

   [OHC]    Bormann, C., Editor, "Robust Header Compression (ROHC)", RFC
             3095, June 2001.

[OHC] ボルマン、C.、エディタ、「体力を要しているヘッダー圧縮(ROHC)」、RFC3095、2001年6月。

Degermark                    Informational                      [Page 7]

RFC 3096            Requirements for IP/UDP/RTP ROHC           July 2001

IP/UDP/RTP ROHC2001年7月のためのデーゲルマルク情報[7ページ]のRFC3096Requirements

7.  Full Copyright Statement

7. 完全な著作権宣言文

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Copyright(C)インターネット協会(2001)。 All rights reserved。

   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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   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機能のための基金は現在、インターネット協会によって提供されます。

Degermark                    Informational                      [Page 8]

デーゲルマルクInformationalです。[8ページ]