Network Working Group R. Finlayson
Request for Comments: 2771 LIVE.COM
Category: Informational February 2000
An Abstract API for Multicast Address Allocation
Status of this 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 (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
This document describes the "abstract service interface" for the dynamic multicast address allocation service, as seen by applications. While it does not describe a concrete API (i.e., for a specific programming language), it describes - in abstract terms - the semantics of this service, including the guarantees that it makes to applications.
アプリケーションによって見られるようにこの文書では、動的なマルチキャストアドレス割り当てサービスの「抽象サービスインタフェース」を説明しています。それは（すなわち、特定のプログラミング言語のための）具体的なAPIを説明していませんが、それは説明 - 抽象的に - それはアプリケーションに対して行う保証を含む本サービスのセマンティクスを、。
Additional documents (not necessarily products of the IETF) would describe concrete APIs for this service.
追加の書類（必ずしもIETFの製品）は、このサービスのための具体的なAPIを説明します。
Applications are the customers of a multicast address allocation service, so a definition of this service should include not only the inter-node network protocols that are used to implement it, but also the 'protocol' that applications use to access the service. While APIs ("application programming interfaces") for specific programming languages (or operating systems) are outside the domain of the IETF, it is appropriate for us to define - in abstract terms - the semantic interface that this service presents to applications. Specific APIs would then be based upon this abstract service interface.
アプリケーションは、マルチキャストアドレス割り当てサービスの顧客であるので、このサービスの定義は、それを実装するために使用されているノード間のネットワークプロトコル、だけでなく、アプリケーションがサービスにアクセスするために使用する「プロトコル」ではないだけを含める必要があります。抽象的に - - 特定のプログラミング言語（またはオペレーティングシステム）のためのAPI（「アプリケーション・プログラミング・インターフェース」）はIETFのドメイン外にあるが、私たちが定義するために適切であるこのサービスは、アプリケーションに提示セマンティックインタフェース。固有のAPIは、この抽象サービスインタフェースに基づいてされるだろう。
Note that it is possible to implement the multicast address allocation service in at least two different ways. The first (and perhaps most common) way is for end nodes to allocate addresses by communicating with a separate "Address Allocation Server" node, using the "Host to Address Allocation Server" network protocol (MADCAP) [1][7]. Alternatively, an "Address Allocation Server" implementation
少なくとも2つの異なる方法でマルチキャストアドレス割り当てサービスを実装することが可能であることに注意してください。エンドノードがネットワーク・プロトコル（MADCAP）「割り当てサーバアドレスへのホスト」を使用して、別個の「アドレス割り当てサーバ」ノードと通信することによって、アドレスを割り当てるための第1の（そして、おそらく最も一般的な）方法である[1]〜[7]。また、「アドレス割当サーバ」実装
might be co-located (along with one or more applications) on an end node, in which case some other, internal, mechanism might be used to access the server. In either case, however, the abstract service interface (and, presumably, any specific APIs) would remain the same.
いくつかの他の、内部、機構は、サーバにアクセスするために使用されるかもしれない、その場合、エンドノードに、（1つまたは複数のアプリケーションと一緒に）同じ場所に配置されるかもしれません。しかしながら、いずれの場合も、抽象サービスインタフェース（および、おそらく、任意の特定のAPI）が同じままであろう。
The remainder of this document describes the abstract interface.
このドキュメントの残りの部分は抽象インタフェースを記述します。
Note that this interface is intended only for the allocation of dynamic multicast addresses, as used by the traditional multicast service model [2]. Future multicast service models might allocate or assign multicast addresses in other ways, but this is outside the scope of this document.
従来のマルチキャスト・サービス・モデルで使用されるように、このインターフェイスは、唯一の動的マルチキャストアドレスの割り当てのために意図されていることに注意してください[2]。将来のマルチキャストサービスモデルを割り当てるか、他の方法でのマルチキャストアドレスを割り当てるが、これはこの文書の範囲外である可能性があります。
The interface described below uses the following abstract data types:
以下で説明するインタフェースは、次の抽象データ型を使用します。
- AddressFamily: e.g., IPv4 or IPv6
- AddressFamily：例えば、IPv4またはIPv6
- MulticastAddress: An actual multicast address (i.e., that could subsequently be used as the destination of a datagram)
- MulticastAddress：実際のマルチキャスト・アドレス（即ち、その後のデータグラムの宛先として使用することができること）
- MulticastAddressSet: A set of "MulticastAddress"es
- MulticastAddressSet： "MulticastAddress" ESのセット
- LanguageTag: The code for a (human) language, as defined in [4]
- LanguageTag：（人間の）言語のコードで定義されるように[4]
- Scope: An "administrative scope" [3] from which multicast addresses are to be allocated. Each scope is a "MulticastAddressSet", with an associated set of (character-string) names - indexed by "LanguageTag". (Each language tag has at most one corresponding name, per scope.) For each scope, a (language tag, name) pair may be defined to be the 'default' name for this scope. (See the section "Querying the name of a scope" below.)
- 範囲：「管理範囲」[3]のマルチキャストアドレスが割り当てされるべきです。各スコープは、（文字列）名の関連セットと、「MulticastAddressSet」である - 「LanguageTag」によって索引付け。各スコープについて（各言語タグ。スコープごとに、最大1つの対応する名前を持つ）（言語タグ、名前）のペアは、この範囲のための「デフォルト」の名前であると定義することができます。 （セクションでは、以下の「スコープの名前のクエリー」を参照してください。）
(An implementation of this abstract data type might also
include other information, such as a default TTL for the
scope.)
- Time: An (absolute) event time. This is used for specifying the "lifetime" of multicast addresses: the period of time during which allocated multicast addresses are guaranteed to be available. (It is also used to specify the desired start time for an "advance allocation".)
- 時間：（絶対）イベント時間。これは、マルチキャストアドレスの「寿命」を指定するために使用されます。マルチキャストアドレスを割り当てられている期間は、利用可能であることが保証されています。 （また、「予め割り当て」のための所望の開始時間を指定するために使用されます。）
Note that a concrete API might prefer to specify some of
these times as relative times (i.e., relative to the current
time-of-day), rather than absolute time. (Relative times
have the advantage of not requiring clock synchronization.)
- Lease: A compound data type that describes the result of a (successful) multicast address allocation. It consists of:
- リース：（成功した）マルチキャストアドレス割り当ての結果を記述する複合データ型。これは、で構成されています。
- [MulticastAddressSet] The set of addresses that were
allocated;
- [AddressFamily] The address family of these addresses
- これらのアドレスの[AddressFamily]アドレスファミリ
- [Time] The lifetime of these addresses (the same for each address)
- [時間]（アドレスごとに同じ）これらのアドレスの寿命
- [Time] The "start time" of the allocation. (See the discussion of "advance allocation" below.) (A concrete API would likely also include a MADCAP "Lease Identifier" [1].)
- [時間]は割り当ての「開始時刻」。 （以下「事前割当て」の説明を参照してください。）（具体的APIは、おそらくまた、MADCAP「リース識別子」[1]を含むであろう。）
- NestingRelationship: A binary data type that describes whether or not two scopes nest. Two scopes nest if traffic sent sent to a multicast group within one scope could be seen by all hosts present within the other scope were they to join the multicast group within the first scope. This value would be "False" for overlapping scopes where only some (or none) of the hosts within the second scope could see traffic sent to an address due to the presence of an administratively scoped boundary. In cases where the first and second scopes are topologically identical this value would be "True."
- NestingRelationship：かどうかを2つのスコープの巣を記述するバイナリデータ型。 2つのスコープ巣トラフィックが送信される場合は、1つのスコープ内のマルチキャストグループに送られたが、他の範囲内に存在するすべてのホストで見ることができたが、彼らは最初の範囲内でのマルチキャストグループに参加していました。この値は、どこのアドレスに送信されたトラフィックを見ることができる第二範囲内のホストの一部だけ（またはnone）による管理用スコープの境界の存在にスコープを重ねるための「偽」になります。第一及び第二のスコープが、この値は次のようになりトポロジー的に同一である場合に「真」。
- Status: A result code.
- ステータス：結果コード。
alloc_multicast_addr(in AddressFamily family, in Scope scope, in Integer minDesiredAddresses, in Integer maxDesiredAddresses, in Time minDesiredStartTime, in Time maxDesiredStartTime, in Time minDesiredLifetime, in Time maxDesiredLifetime, out Lease multicastAddressSetLease, out Status status)
alloc_multicast_addr（AddressFamilyファミリーで、スコープ範囲で、整数minDesiredAddressesで、整数maxDesiredAddressesで、時間minDesiredStartTimeで、時間maxDesiredStartTimeで、時間minDesiredLifetimeで、時間maxDesiredLifetimeで、リースmulticastAddressSetLeaseうち、ステータスステータスアウト）
This operation attempts to allocate a set of multicast addresses (the size of this set is in the range [minDesiredAddresses, maxDesiredAddresses]) within the given address family and scope, and within a given range of desired lifetimes. ("minDesiredStartTime" and "maxDesiredStartTime" are used to specify "advance allocation"; this is described in more detail below.)
この操作は、所望の寿命の所定の範囲内で与えられたアドレスファミリおよび範囲内でのマルチキャストアドレスのセット（このセットのサイズは、[、minDesiredAddresses maxDesiredAddresses]の範囲内である）割り当てよう。 （「minDesiredStartTime」および「maxDesiredStartTime」は、「事前割り当て」を指定するために使用され、これは以下により詳細に記載されています。）
If the address allocation succeeds, the result is returned in "multicastAddressSetLease" (with "status" = OK).
アドレス割り当てが成功した場合、結果は（「ステータス」で= OK）「multicastAddressSetLease」で返されます。
During the lifetime of this lease, the allocation service will make a "best-effort" attempt to not allocate any of these addresses to others. (However, once the lease's lifetime has expired, any of its addresses can be allocated to others.)
このリースの有効期間中は、割り当てサービスは、他の人にこれらのアドレスのいずれかを割り当てられないために、「ベストエフォート」の試行を行います。 （リースの有効期間が満了した後しかし、そのアドレスのいずれかが他の人に割り当てることができます。）
Multicast addresses are allocated for a limited lifetime. An application may attempt to extend this lifetime, but this operation may fail. Therefore, an application must be prepared for the possibility it will not be able to use the same addresses for as long as it desires. In particular, the application must be prepared to either quit early (because its original multicast address assignments have expired), or, alternatively, to occasionally 'renumber' its multicast addresses (in some application or higher-level-protocol dependent way), by making a new allocation. However, if an application needs to consider 'renumbering', it will always know this in advance, at the time it acquired its current address(es) - by checking the lifetime in the returned lease. An application will never need to be notified asynchronously of the need to 'renumber'.
マルチキャストアドレスは、限られた寿命のために割り当てられています。アプリケーションは、この寿命を延長しようとするかもしれませんが、この操作は失敗することがあります。したがって、アプリケーションは、ある限り、それが望むように同じアドレスを使用することはできません可能性のために準備する必要があります。具体的には、アプリケーションは、時々によって、（いくつかのアプリケーションまたは上位プロトコルに依存するように）、そのマルチキャストアドレスを「再番号付け」するために、代替的に、（元のマルチキャストアドレス割り当ての有効期限が切れたため）早期終了のいずれかに調製し、またはされなければなりません新しい割り当てを行います。返されたリースでの寿命をチェックして - アプリケーションは「リナンバリング」を検討する必要がある場合しかし、それは常に、それが現在のアドレスを取得した時刻に、事前にこのことを知っています。アプリケーションは、「番号変更」する必要性を非同期に通知する必要はありません。
Possible errors:
発生する可能性のあるエラー：
- bad address family
- bad scope
- bad desired number of addresses (e.g., max < min)
- bad desired lifetimes (e.g., max < min)
- errors with the two "start time" parameters (see
"Advance allocation" below)
- no addresses can be allocated (for the requested parameters)
An allocation attempt can also fail with a result "status" code of TRY_LATER, indicating that the requested allocation cannot be made at this time, but that it might succeed if the caller retries the attempt at some future time. (This future time is returned in the "start time" field of the
割り当ての試みも、要求された割り当ては、この時点で行われますが、呼び出し側は、いくつかの将来の時点での試みを再試行する場合、それは成功するかもしれないとできないことを示す、TRY_LATERの結果、「状態」のコードで失敗することができます。 （これは将来の時間は、の「開始時刻」フィールドに戻されます
"multicastAddressSetLease"; the other parts of this lease are undefined.)
「multicastAddressSetLease」。このリースの他の部分は未定義です。）
Note that a concrete (i.e., programming language-specific) API for multicast address allocation will probably include additional, specialized variants of this general allocation operation. For instance, it may include separate operations for:
具体的な（すなわち、プログラミング言語固有の）マルチキャストアドレス割り当てのためのAPIは、おそらく、この一般的な割り当て操作の追加、専門的な変異体が含まれることに注意してください。例えば、それはのために別々の操作を含むことができます。
- allocating only a single address
(i.e., minDesiredAddresses = maxDesiredAddresses = 1);
- (attempting to) allocate an address with a single, fixed
lifetime (i.e., minDesiredLifetime = maxDesiredLifetime);
- (attempting to) allocate an address for immediate use
(i.e., minDesiredStartTime = maxDesiredStartTime = 'now')
change_multicast_addr_lifetime(in Lease multicastAddressSetLease,
in Time minDesiredLifetime,
in Time maxDesiredLifetime,
out Time lifetime)
This operation attempts to change the lifetime of previously allocated multicast addresses. Unless an error occurs, it returns the new lifetime (which might remain unchanged).
この操作は、以前に割り当てられたマルチキャストアドレスの寿命を変更しようとします。エラーが発生しない限り、それは新しい寿命を（変わらないかもしれない）を返します。
Possible errors:
発生する可能性のあるエラー：
- bad address family
- bad durations (e.g., max < min)
- the addresses' lifetime could not be changed (and the existing lifetime was not in the requested range [minDesiredLifetime,maxDesiredLifetime]) - the addresses were not ones that we had allocated (see section 5.9) - or they have already expired
- アドレスライフタイムは変更することができませんでした（と既存の寿命が要求された範囲[minDesiredLifetime、maxDesiredLifetime]ではありませんでした） - アドレスは（セクション5.9を参照してください）私たちが割り当てられていたものではありませんでした - または彼らはすでに有効期限が切れています
deallocate_multicast_addr(in Lease multicastAddressSetLease) This operation attempts to deallocate previously allocated multicast addresses.
（リースmulticastAddressSetLeaseで）deallocate_multicast_addrこの操作は、以前に割り当てられたマルチキャストアドレスの割り当てを解除しようとします。
Possible errors:
発生する可能性のあるエラー：
- bad address family
- the addresses were not ones that we had allocated
(or they have already expired)
get_multicast_addr_scopes(in AddressFamily family,
out "set of" Scope)
This operation returns the set of administrative multicast address scopes that are defined for this node.
この操作は、このノードのために定義されている管理マルチキャストアドレススコープのセットを返します。
Possible errors:
発生する可能性のあるエラー：
- bad address family
- 悪いアドレスファミリ
get_scope_name(in Scope scope,
in LanguageTag language,
out String name,
out LanguageTag languageForName)
This operation returns a character-string name for a given scope. If the scope has a name in the specified "language", then this name (and language) is returned. Otherwise, the scope's default (language, name) pair is returned.
この操作は、指定した範囲の文字列名を返します。スコープが指定された「言語」の名前を持っている場合は、この名前（および言語）が返されます。それ以外の場合は、スコープのデフォルト（言語、名前）のペアが返されます。
Possible errors:
発生する可能性のあるエラー：
- bad scope.
- 悪いスコープ。
get_scope_nesting_state(in "set of" Scope,
out "matrix of" NestingRelationship)
Possible errors:
発生する可能性のあるエラー：
- bad scope.
- nesting state undetermined at this time.
This operation would return a matrix that shows the current nesting relationships between the supplied set of scopes which would have previously been supplied via the get_multicast_addr_scopes(...) function.
この操作は、以前get_multicast_addr_scopes（...）関数を介して供給されていたスコープの供給セットとの間の現在の入れ子関係を示す行列を返します。
get_larger_scopes(in Scope,
out "set of" Scope)
This operation returns the set of administrative multicast address scopes that are known to encompass the supplied Scope.
この操作は、付属のスコープを包含することが知られている管理マルチキャストアドレススコープのセットを返します。
Possible errors:
発生する可能性のあるエラー：
- bad scope.
- nesting state undetermined at this time.
get_smaller_scopes(in Scope,
out "set of" Scope)
This operation returns the set of administrative multicast address scopes that are known to nest inside the supplied Scope (NB this would include those scopes that are topologically identical to the supplied scope).
この操作は、供給されたスコープの内部に入れ子に知られている管理マルチキャストアドレススコープのセットを（NBこれは供給範囲にトポロジー的に同一であるものスコープを含むことになる）を返します。
Possible errors:
発生する可能性のあるエラー：
- bad scope.
- nesting state undetermined at this time.
3.9 Note: The decision as to who is allowed to deallocate (or change the lifetime of) a previously allocated multicast address set lease is implementation-specific, and depends upon the security policy of the host system. Thus it is not specified in this abstract API. One possible starting point, however, is the following:
3.9注：解放（または寿命を変化）させている人のような意思決定以前に割り当てられたマルチキャストアドレスセットリースは実装固有であり、ホストシステムのセキュリティポリシーに依存します。したがって、それは、この抽象APIで指定されていません。一つの可能な出発点は、しかし、次のとおりです。
A previously allocated multicast address can be deallocated (or
have its lifetime queried or changed) by the same "principal", and
on the same node, as that which originally allocated it.
("principal" might, for example, be a "user" in the host operating
system.)
By specifying "minDesiredStartTime = maxDesiredStartTime = 'now'",
the address allocation operation - "alloc_multicast_addr" -
described above can be used to request a set of multicast
addresses that can be used *immediately* (and until their lifetime
expires). During this whole time, the addresses are not available
for allocation to others.
It is also possible - using the "minDesiredStartTime" and "maxDesiredStartTime" parameters - to allocate multicast addresses *in advance* - i.e., so that they have a future "start time" as well as an expiration time. Before the start time, the multicast addresses may be allocated to others.
ことも可能である - 「minDesiredStartTime」と「maxDesiredStartTime」パラメータを使用して - 彼らは未来がだけでなく、有効期限「開始時間」しているように、すなわち - マルチキャストアドレスを割り当てる*事前に*。開始時刻の前に、マルチキャストアドレスは、他の人に割り当てることができます。
Advance allocation is convenient for allocating addresses for events that begin far in the future - e.g., several weeks or months away. Without advance allocation, it would be necessary to allocate addresses for a long period of time - even when it will not be used. Such a request would not only be a wasteful use of the multicast address space, but it may also be difficult to implement (especially since address allocations are expected to remain valid in spite of topology changes).
離れ例えば、数週間または数ヶ月 - 事前割り当ては、将来的にはるかに始まるイベントにアドレスを割り当てるために便利です。事前割り当てなければ、長時間のアドレスを割り当てることが必要であろう - それは使用されません場合でも。このような要求は、マルチキャストアドレス空間の無駄使いになるだけでなく、（アドレス割り当てがトポロジの変更にもかかわらず、有効なままと予想され、特に以来）を実装するのが難しいかもしれません。
Advance allocation requests can produce the following errors (in addition to those defined earlier):
予め割り当て要求が（先に定義されたものに加えて）次のエラーを生成することができます。
- bad start time durations (e.g., max < min) - requested start times conflict with requested lifetimes (i.e., min start time > max lifetime)
- 悪い開始時間期間（例えば、最大< - （最大寿命分）要求された開始時刻要求寿命との競合、すなわち、分開始時刻>）
The following operation is also defined:
以下の動作が定義されています：
change_multicast_addr_start_time(in Lease multicastAddressSetLease, in Time minDesiredStartTime, in Time maxDesiredStartTime, out Time startTime)
（リースmulticastAddressSetLeaseで、時間minDesiredStartTimeで、時間maxDesiredStartTimeで、時間のstartTimeアウト）change_multicast_addr_start_time
This operation attempts to change the start time of previously allocated multicast addresses. Unless an error occurs, it returns the new start time (which might remain unchanged).
この操作は、以前に割り当てられたマルチキャストアドレスの開始時間を変更しようとします。エラーが発生しない限り、それは（変更されないままかもしれない）新しい開始時間を返します。
Possible errors: the same as "change_multicast_addr_lifetime"
発生する可能性のあるエラー：「change_multicast_addr_lifetime」と同じ
As noted in section 5.9 above, each implementation of this abstract API should define a security policy that specifies when (and by whom) previously allocated multicast addresses can be deallocated (or queried, or have their lifetime changed).
上記のセクション5.9で述べたように、この抽象APIの各実装では、（誰によって）以前に割り当てられたマルチキャストアドレスが割り当て解除（または照会、またはその寿命が変化している）ことができたときに指定したセキュリティポリシーを定義する必要があります。
Because multicast addresses are a finite resource, there is a potential for a "denial of service" attack by allocating a large number of multicast addresses without deallocating them. Preventing such an attack, however, is not the role of the API, but rather by the underlying MAAS ("Multicast Address Allocation Server(s)" [6]).
マルチキャストアドレスは有限の資源であるため、それらを割り当て解除することなく、マルチキャストアドレスの多数を割り当てることにより、「サービス拒否の」攻撃の可能性があります。このような攻撃を防ぐこと、しかし、APIの役割ではなく、根本的なMAASによって（「マルチキャストアドレス割り当てサーバ（S）」[6]）。
Many thanks to other participants in the "MALLOC" working group - in particular Steve Hanna, Dave Thaler, Roger Kermode, and Pavlin Radoslavov - for their valuable comments.
彼らの貴重なコメントについて - 特にスティーブ・ハンナ、デーブターラー、ロジャーKermode、およびPavlin Radoslavov - 「MALLOC」ワーキンググループの他の参加者に感謝します。
[1] Hanna, S., Patel, B. and M. Shah, "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.
[1]ハンナ、S.、パテル、B.及びM.シャー、 "マルチキャストアドレス動的クライアント割り当てプロトコル（MADCAP）"、RFC 2730、1999年12月。
[2] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[2]デアリング、S.、 "IPマルチキャスティングのためのホスト拡大"、STD 5、RFC 1112、1989年8月。
[3] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July, 1998.
[3]マイヤー、D.、 "管理用スコープのIPマルチキャスト"、BCP 23、RFC 2365、1998年7月。
[4] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.
[4] Alvestrand、H.、 "言語識別のためのタグ"、RFC 1766、1995年3月。
[5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[5]ハンドリー、M.およびV. Jacobson氏、 "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[6] Estrin, D., Handley, M. and D. Thaler, "The Internet Multicast Address Allocation Architecture", Work in Progress.
[6] Estrin、D.、ハンドリー、M.とD.ターラー、 "インターネットマルチキャストアドレス配分アーキテクチャ" が進行中で働いて。
[7] Kermode, R., "MADCAP Multicast Scope Nesting State Option", Work in Progress.
[7] Kermode、R.、 "MADCAPマルチキャストスコープネストstateオプション" が進行中で働いています。
Ross Finlayson, Live Networks, Inc. (LIVE.COM)
ロス・フィンレイソン、ライブネットワークス株式会社（LIVE.COM）
EMail: finlayson@live.com WWW: http://www.live.com/
電子メール：finlayson@live.com WWW：http://www.live.com/
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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機能のための基金は現在、インターネット協会によって提供されます。