RFC2988 日本語訳
2988 Computing TCP's Retransmission Timer. V. Paxson, M. Allman. November 2000. (Format: TXT=15280 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group V. Paxson
Request for Comments: 2988 ACIRI
Category: Standards Track M. Allman
NASA GRC/BBN
November 2000
コメントを求めるワーキンググループV.パクソンの要求をネットワークでつないでください: 2988年のACIRIカテゴリ: 標準化過程M.オールマンNASA GRC/BBN2000年11月
Computing TCP's Retransmission Timer
TCPの再送信タイマーを計算します。
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
This document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer. It expands on the discussion in section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST.
このドキュメントは通信制御プロトコル(TCP)送付者が彼らの再送信タイマーを計算して、管理するのに使用しなければならない標準のアルゴリズムを定義します。 それは、議論のときにセクション4.2.3で.1RFC1122を広げて、SHOULDからaまでのアルゴリズムがそうしなければならない支持の要件をアップグレードさせます。
1 Introduction
1つの序論
The Transmission Control Protocol (TCP) [Pos81] uses a retransmission timer to ensure data delivery in the absence of any feedback from the remote data receiver. The duration of this timer is referred to as RTO (retransmission timeout). RFC 1122 [Bra89] specifies that the RTO should be calculated as outlined in [Jac88].
通信制御プロトコル(TCP)[Pos81]は、リモートデータ受信装置からのどんなフィードバックがないときデータ配送を確実にするのに再送信タイマーを使用します。このタイマの持続時間はRTO(再送タイムアウト)と呼ばれます。 RFC1122[Bra89]は、RTOが[Jac88]に概説されているように計算されるべきであると指定します。
This document codifies the algorithm for setting the RTO. In addition, this document expands on the discussion in section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST. RFC 2581 [APS99] outlines the algorithm TCP uses to begin sending after the RTO expires and a retransmission is sent. This document does not alter the behavior outlined in RFC 2581 [APS99].
このドキュメントはRTOを設定するためのアルゴリズムを成文化します。 さらに、このドキュメントは、議論のときにセクション4.2.3で.1RFC1122を広げて、SHOULDからaまでのアルゴリズムがそうしなければならない支持の要件をアップグレードさせます。RFC2581[APS99]はTCPがRTOが期限が切れて、「再-トランスミッション」を送った後に発信し始めるために使用するアルゴリズムを概説します。 このドキュメントはRFC2581[APS99]に概説された振舞いを変更しません。
Paxson & Allman Standards Track [Page 1] RFC 2988 Computing TCP's Retransmission Timer November 2000
TCPの再送信タイマー2000年11月に計算するパクソンとオールマン標準化過程[1ページ]RFC2988
In some situations it may be beneficial for a TCP sender to be more conservative than the algorithms detailed in this document allow. However, a TCP MUST NOT be more aggressive than the following algorithms allow.
いくつかの状況で、TCP送付者がこのドキュメントで詳細なアルゴリズムが許容するより保守的であることは、有益であるかもしれません。 しかしながら、TCP MUST NOT、以下のアルゴリズムが許容するより攻撃的であってください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [Bra97].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[Bra97]で説明されるように本書では解釈されることであるべきですか?
2 The Basic Algorithm
2 基本的なアルゴリズム
To compute the current RTO, a TCP sender maintains two state variables, SRTT (smoothed round-trip time) and RTTVAR (round-trip time variation). In addition, we assume a clock granularity of G seconds.
現在のRTOを計算するために、TCP送付者は2つの州の変数、SRTT(往復の時間を整える)、およびRTTVAR(往復の時間変化)を維持します。 さらに、私たちはG秒の時計粒状を仮定します。
The rules governing the computation of SRTT, RTTVAR, and RTO are as follows:
SRTT、RTTVAR、およびRTOの計算を治める規則は以下の通りです:
(2.1) Until a round-trip time (RTT) measurement has been made for a
segment sent between the sender and receiver, the sender SHOULD
set RTO <- 3 seconds (per RFC 1122 [Bra89]), though the
"backing off" on repeated retransmission discussed in (5.5)
still applies.
(2.1) 送付者SHOULDはRTO<を3秒(RFC1122[Bra89]単位で)送付者と受信機の間に送られたセグメントのために往復の時間(RTT)測定をするまで設定します、(5.5)で議論した繰り返された「再-トランスミッション」に「譲歩」であることはまだ適用されていますが。
Note that some implementations may use a "heartbeat" timer
that in fact yield a value between 2.5 seconds and 3
seconds. Accordingly, a lower bound of 2.5 seconds is also
acceptable, providing that the timer will never expire
faster than 2.5 seconds. Implementations using a heartbeat
timer with a granularity of G SHOULD not set the timer below
2.5 + G seconds.
いくつかの実現が事実上、値を2.5秒と3秒の間もたらす「鼓動」タイマを使用するかもしれないことに注意してください。 また、それに従って、2.5秒の下界も許容できます、タイマが決して2.5秒より速く期限が切れないなら。 G SHOULDの粒状がある鼓動タイマを使用する実現が2.5+G秒でタイマを設定しません。
(2.2) When the first RTT measurement R is made, the host MUST set
(2.2) 最初のRTT測定Rをするとき、ホストはセットしなければなりません。
SRTT <- R
RTTVAR <- R/2
RTO <- SRTT + max (G, K*RTTVAR)
SRTT<R RTTVAR<R/2RTO<SRTT+最大(G、K*RTTVAR)
where K = 4.
Kが4と等しいところ。
(2.3) When a subsequent RTT measurement R' is made, a host MUST set
'(2.3) その後のRTT測定R'をするとき、ホストはセットしなければなりません。
RTTVAR <- (1 - beta) * RTTVAR + beta * |SRTT - R'|
SRTT <- (1 - alpha) * SRTT + alpha * R'
RTTVAR<(1--ベータ)*RTTVAR+ベータ*|'SRTT--R'| 'SRTT<(1--アルファ)*SRTT+アルファ*R'
Paxson & Allman Standards Track [Page 2] RFC 2988 Computing TCP's Retransmission Timer November 2000
TCPの再送信タイマー2000年11月に計算するパクソンとオールマン標準化過程[2ページ]RFC2988
The value of SRTT used in the update to RTTVAR is its value
before updating SRTT itself using the second assignment. That
is, updating RTTVAR and SRTT MUST be computed in the above
order.
アップデートにRTTVARに使用されるSRTTの値は2番目の課題を使用することでSRTT自身をアップデートする前のその値です。 すなわち、RTTVARとSRTT MUSTをアップデートして、上記のオーダーで計算されてください。
The above SHOULD be computed using alpha=1/8 and beta=1/4 (as
suggested in [JK88]).
SHOULDの上では、1/8とアルファ=ベータ=1/4を使用することで([JK88]に示されるように)計算されてください。
After the computation, a host MUST update
RTO <- SRTT + max (G, K*RTTVAR)
計算の後に、ホストはRTO<SRTT+最大をアップデートしなければなりません。(G、K*RTTVAR)
(2.4) Whenever RTO is computed, if it is less than 1 second then the
RTO SHOULD be rounded up to 1 second.
(2.4) RTOがそれであるなら計算されるときはいつも、最大丸い1が2番目であったなら、そして、1秒未満はRTO SHOULDですか?
Traditionally, TCP implementations use coarse grain clocks to
measure the RTT and trigger the RTO, which imposes a large
minimum value on the RTO. Research suggests that a large
minimum RTO is needed to keep TCP conservative and avoid
spurious retransmissions [AP99]. Therefore, this
specification requires a large minimum RTO as a conservative
approach, while at the same time acknowledging that at some
future point, research may show that a smaller minimum RTO is
acceptable or superior.
TCP実現は、伝統的に、RTTを測定するのに粗粉時計を使用して、RTOの引き金となります。(RTOは大きい最小値をRTOに課します)。 研究は、大きい最小のRTOがTCPを保守的に保って、偽物の「再-トランスミッション」[AP99]を避けるのに必要であることを示します。 したがって、同時に何らかの将来のポイントに、研究が、より小さい最小のRTOが許容できるか、優れているのを示すかもしれないと認める間、この仕様は保守的なアプローチとして大きい最小のRTOを必要とします。
(2.5) A maximum value MAY be placed on RTO provided it is at least 60
seconds.
(2.5) 最大値は少なくとも60秒であるならRTOに置かれるかもしれません。
3 Taking RTT Samples
3 RTTのサンプルを取ること。
TCP MUST use Karn's algorithm [KP87] for taking RTT samples. That is, RTT samples MUST NOT be made using segments that were retransmitted (and thus for which it is ambiguous whether the reply was for the first instance of the packet or a later instance). The only case when TCP can safely take RTT samples from retransmitted segments is when the TCP timestamp option [JBB92] is employed, since the timestamp option removes the ambiguity regarding which instance of the data segment triggered the acknowledgment.
TCP MUSTは、RTTのサンプルを取るのに、Karnのアルゴリズム[KP87]を使用します。 再送されたセグメントを使用して、すなわち、RTTのサンプルを作ってはいけない、(このようにして、回答がパケットの最初の例か後の例のためのものであったかがあいまいである、) TCPが再送されたセグメントからRTTのサンプルを安全に取ることができるとき、唯一のケースがTCPタイムスタンプオプション[JBB92]が採用している時です、タイムスタンプオプションがデータ・セグメントの例が承認の引き金となったあいまいさを取り除くので。
Traditionally, TCP implementations have taken one RTT measurement at a time (typically once per RTT). However, when using the timestamp option, each ACK can be used as an RTT sample. RFC 1323 [JBB92] suggests that TCP connections utilizing large congestion windows should take many RTT samples per window of data to avoid aliasing effects in the estimated RTT. A TCP implementation MUST take at least one RTT measurement per RTT (unless that is not possible per Karn's algorithm).
伝統的に、測定が一度に1RTTによるTCP実現のために取った、(通常、一度1RTTあたり) しかしながら、タイムスタンプオプションを使用するとき、RTTのサンプルとして各ACKを使用できます。 RFC1323[JBB92]は、大きい混雑ウィンドウを利用しているTCP接続がおよそRTTのエイリアシング効果を避けるために多くのデータの窓あたりのRTTのサンプルを取るべきであると示唆します。 TCP実現は1RTTあたり少なくとも1つのRTT測定を取らなければなりません(それがKarnのアルゴリズム単位で可能である場合)。
Paxson & Allman Standards Track [Page 3] RFC 2988 Computing TCP's Retransmission Timer November 2000
TCPの再送信タイマー2000年11月に計算するパクソンとオールマン標準化過程[3ページ]RFC2988
For fairly modest congestion window sizes research suggests that timing each segment does not lead to a better RTT estimator [AP99]. Additionally, when multiple samples are taken per RTT the alpha and beta defined in section 2 may keep an inadequate RTT history. A method for changing these constants is currently an open research question.
かなり穏やかな混雑のために、ウィンドウサイズ研究は、各セグメントを調節するのが、より良いRTT見積り人[AP99]に通じないのを示します。 RTT単位で複数のサンプルを取るとき、さらに、セクション2で定義されたアルファとベータは不十分なRTT歴史を保管するかもしれません。 現在、これらの定数を変えるための方法は未解決の研究問題です。
4 Clock Granularity
4時計粒状
There is no requirement for the clock granularity G used for computing RTT measurements and the different state variables. However, if the K*RTTVAR term in the RTO calculation equals zero, the variance term MUST be rounded to G seconds (i.e., use the equation given in step 2.3).
RTT測定と異なった州の変数を計算するのに使用される時計粒状Gのための要件が全くありません。 しかしながら、RTO計算におけるK*RTTVAR用語がゼロと等しいなら、変化の用語をG秒まで一周させなければなりません(すなわち、ステップ2.3で与えられた方程式を使用してください)。
RTO <- SRTT + max (G, K*RTTVAR)
RTO<SRTT+最大(G、K*RTTVAR)
Experience has shown that finer clock granularities (<= 100 msec) perform somewhat better than more coarse granularities.
経験は、より粗い粒状よりさらにすばらしい時計粒状(<は100msecと等しい)がいくらかよく振る舞うのを示しました。
Note that [Jac88] outlines several clever tricks that can be used to obtain better precision from coarse granularity timers. These changes are widely implemented in current TCP implementations.
[Jac88]が粗い粒状タイマから、より良い精度を得るのに使用できるいくつかの賢明なトリックを概説することに注意してください。 これらの変化は現在のTCP実現で広く実行されます。
5 Managing the RTO Timer
5 RTOタイマを管理すること。
An implementation MUST manage the retransmission timer(s) in such a way that a segment is never retransmitted too early, i.e. less than one RTO after the previous transmission of that segment.
実現はセグメントがあまりに早く決して再送されないような方法で再送信タイマーを管理しなければなりません、すなわち、そのセグメントの前の送信の後の1RTO。
The following is the RECOMMENDED algorithm for managing the retransmission timer:
↓これは再送信タイマーを管理するためのRECOMMENDEDアルゴリズムです:
(5.1) Every time a packet containing data is sent (including a
retransmission), if the timer is not running, start it running
so that it will expire after RTO seconds (for the current value
of RTO).
(5.1) タイマが動いていないならデータを含むパケットを送る(「再-トランスミッション」を含んでいます)ときはいつも、RTO秒(RTOの現行価値のための)以降期限が切れるようにそれを走らせ始めてください。
(5.2) When all outstanding data has been acknowledged, turn off the
retransmission timer.
(5.2) すべての傑出しているデータが承認されたときには、再送信タイマーをオフにしてください。
(5.3) When an ACK is received that acknowledges new data, restart the
retransmission timer so that it will expire after RTO seconds
(for the current value of RTO).
(5.3) ACKが受け取られているとき、それは新しいデータを承認して、RTO秒(RTOの現行価値のための)以降期限が切れるように再送信タイマーを再開してください。
Paxson & Allman Standards Track [Page 4] RFC 2988 Computing TCP's Retransmission Timer November 2000
TCPの再送信タイマー2000年11月に計算するパクソンとオールマン標準化過程[4ページ]RFC2988
When the retransmission timer expires, do the following:
再送信タイマーが期限が切れるときには、以下をしてください:
(5.4) Retransmit the earliest segment that has not been acknowledged
by the TCP receiver.
(5.4) TCP受信機によって承認されていない中で最も早いセグメントを再送してください。
(5.5) The host MUST set RTO <- RTO * 2 ("back off the timer"). The
maximum value discussed in (2.5) above may be used to provide an
upper bound to this doubling operation.
(5.5) ホストはRTO<RTO*2(「タイマを戻す」)を設定しなければなりません。 上で(2.5)で議論した最大値は、操作を倍にしながら上限をこれに提供するのに使用されるかもしれません。
(5.6) Start the retransmission timer, such that it expires after RTO
seconds (for the value of RTO after the doubling operation
outlined in 5.5).
(5.6) 再送信タイマーを始動してください、RTO秒(操作が5.5に概説した倍増の後のRTOの値のための)以降期限が切れるように。
Note that after retransmitting, once a new RTT measurement is obtained (which can only happen when new data has been sent and acknowledged), the computations outlined in section 2 are performed, including the computation of RTO, which may result in "collapsing" RTO back down after it has been subject to exponential backoff (rule 5.5).
いったん新しいRTT測定を得ると(新しいデータが送られて、承認されたときだけ起こることができます)再送した後にセクション2で概説された計算が実行されることに注意してください、それの逆後のRTOを条件としていた「微片」の指数のbackoff(規則5.5)をもたらすかもしれないRTOの計算を含んでいて。
Note that a TCP implementation MAY clear SRTT and RTTVAR after backing off the timer multiple times as it is likely that the current SRTT and RTTVAR are bogus in this situation. Once SRTT and RTTVAR are cleared they should be initialized with the next RTT sample taken per (2.2) rather than using (2.3).
現在のSRTTとRTTVARがこの状況でにせであることが、ありそうであるので複数の回タイマを戻した後にTCP実現がSRTTとRTTVARをきれいにするかもしれないことに注意してください。 SRTTとRTTVARがいったんきれいにされると、それらは(2.3)を使用するより(2.2)単位で次のRTTのサンプルをむしろ取っていて初期化されるべきです。
6 Security Considerations
6 セキュリティ問題
This document requires a TCP to wait for a given interval before retransmitting an unacknowledged segment. An attacker could cause a TCP sender to compute a large value of RTO by adding delay to a timed packet's latency, or that of its acknowledgment. However, the ability to add delay to a packet's latency often coincides with the ability to cause the packet to be lost, so it is difficult to see what an attacker might gain from such an attack that could cause more damage than simply discarding some of the TCP connection's packets.
このドキュメントは、不承認のセグメントを再送する前にTCPが与えられた間隔の間、待つのを必要とします。 攻撃者は、TCP送付者に調節されたパケットの潜在への遅れ、または承認のものを加えることによって、RTOの大きい値を計算させることができるでしょう。 しかしながら、パケットの潜在に遅れを加える能力がしばしばパケットが失われることを引き起こす能力と同時に起こるので、攻撃者が単にTCP接続のいくつかのパケットを捨てるより多くの損害をもたらすことができたそのような攻撃から獲得するかもしれないものを見るのは難しいです。
The Internet to a considerable degree relies on the correct implementation of the RTO algorithm (as well as those described in RFC 2581) in order to preserve network stability and avoid congestion collapse. An attacker could cause TCP endpoints to respond more aggressively in the face of congestion by forging acknowledgments for segments before the receiver has actually received the data, thus lowering RTO to an unsafe value. But to do so requires spoofing the acknowledgments correctly, which is difficult unless the attacker can monitor traffic along the path between the sender and the receiver. In addition, even if the
インターネットは、ネットワークの安定性を保存して、混雑崩壊を避けるためにかなりRTOアルゴリズム(RFC2581で説明されたものと同様に)の正しい実現に依存します。 受信機が実際にデータを受信する前に攻撃者はセグメントのための鍛造物承認による混雑に直面してTCP終点をより積極的に応じさせることができました、その結果、危険な値にRTOを下ろします。 しかし、そうをするのは、正しく承認をだますのを必要とします(攻撃者は送付者と受信機の間の経路に沿ったモニター交通を難しいことができないなら、さらに、難しいです)。
Paxson & Allman Standards Track [Page 5] RFC 2988 Computing TCP's Retransmission Timer November 2000
TCPの再送信タイマー2000年11月に計算するパクソンとオールマン標準化過程[5ページ]RFC2988
attacker can cause the sender's RTO to reach too small a value, it appears the attacker cannot leverage this into much of an attack (compared to the other damage they can do if they can spoof packets belonging to the connection), since the sending TCP will still back off its timer in the face of an incorrectly transmitted packet's loss due to actual congestion.
攻撃者は送付者のRTOを小さ過ぎる値に達させることができて、攻撃者が攻撃の多くにこれに投機できないように(彼らが接続のものであるパケットをだますことができるならそれらが与えることができるもう片方の損害と比べて)見えます、発信しているTCPがそれでも、実際の混雑による不当に伝えられたパケットの損失に直面してタイマを戻すので。
Acknowledgments
承認
The RTO algorithm described in this memo was originated by Van Jacobson in [Jac88].
このメモで説明されたRTOアルゴリズムは[Jac88]でヴァン・ジェーコブソンによって溯源されました。
References
参照
[AP99] Allman, M. and V. Paxson, "On Estimating End-to-End Network
Path Properties", SIGCOMM 99.
[AP99] オールマン、M.、および「終わりから端へのネットワーク経路が土地であると見積もっている」SIGCOMM99対パクソン
[APS99] Allman, M., Paxson V. and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[APS99] オールマンとM.とパクソンV.とW.スティーブンス、「TCP輻輳制御」、RFC2581、1999年4月。
[Bra89] Braden, R., "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, October 1989.
[Bra89]ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[Bra97] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[Jac88] Jacobson, V., "Congestion Avoidance and Control", Computer
Communication Review, vol. 18, no. 4, pp. 314-329, Aug. 1988.
[Jac88] ジェーコブソンと、V.と、「輻輳回避とコントロール」、コンピュータCommunication Review、vol.18、No.4、ページ 314-329と、1988年8月。
[JK88] Jacobson, V. and M. Karels, "Congestion Avoidance and
Control", ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z.
[JK88] ジェーコブソン、V.、M.Karels、および「輻輳回避とコントロール」、 ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z 。
[KP87] Karn, P. and C. Partridge, "Improving Round-Trip Time
Estimates in Reliable Transport Protocols", SIGCOMM 87.
[KP87] KarnとP.とC.ヤマウズラ、「信頼できるトランスポート・プロトコルにおける往復の時間見積りを改良します」、SIGCOMM87
[Pos81] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[Pos81] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
Paxson & Allman Standards Track [Page 6] RFC 2988 Computing TCP's Retransmission Timer November 2000
TCPの再送信タイマー2000年11月に計算するパクソンとオールマン標準化過程[6ページ]RFC2988
Author's Addresses
作者のアドレス
Vern Paxson ACIRI / ICSI 1947 Center Street Suite 600 Berkeley, CA 94704-1198
通りSuite600バークレー、バーンパクソンACIRI / ICSI1947センターカリフォルニア94704-1198
Phone: 510-666-2882 Fax: 510-643-7684 EMail: vern@aciri.org http://www.aciri.org/vern/
以下に電話をしてください。 510-666-2882 Fax: 510-643-7684 メールしてください: vern@aciri.org http://www.aciri.org/vern/
Mark Allman NASA Glenn Research Center/BBN Technologies Lewis Field 21000 Brookpark Rd. MS 54-2 Cleveland, OH 44135
オールマンNASAグレンリサーチセンタ/BBN技術がルイス分野21000Brookpark通りであるとマークしてください。 MS54-2クリーブランド、OH 44135
Phone: 216-433-6586 Fax: 216-433-8705 EMail: mallman@grc.nasa.gov http://roland.grc.nasa.gov/~mallman
以下に電話をしてください。 216-433-6586 Fax: 216-433-8705 メールしてください: mallman@grc.nasa.gov http://roland.grc.nasa.gov/~mallman
Paxson & Allman Standards Track [Page 7] RFC 2988 Computing TCP's Retransmission Timer November 2000
TCPの再送信タイマー2000年11月に計算するパクソンとオールマン標準化過程[7ページ]RFC2988
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 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機能のための基金は現在、インターネット協会によって提供されます。
Paxson & Allman Standards Track [Page 8]
パクソンとオールマン標準化過程[8ページ]
一覧
スポンサーリンク
