RFC2379 日本語訳
2379 RSVP over ATM Implementation Guidelines. L. Berger. August 1998. (Format: TXT=15174 bytes) (Also BCP0024) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group L. Berger Request for Comments: 2379 FORE Systems BCP: 24 August 1998 Category: Best Current Practice
コメントを求めるワーキンググループL.バーガー要求をネットワークでつないでください: 2379前面システムBCP: 1998年8月24日のカテゴリ: 最も良い現在の習慣
RSVP over ATM Implementation Guidelines
気圧実施要綱の上のRSVP
Status of this Memo
このMemoの状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Abstract
要約
This memo presents specific implementation guidelines for running RSVP over ATM switched virtual circuits (SVCs). The general problem is discussed in [6]. Implementation requirements are discussed in [2]. Integrated Services to ATM service mappings are covered in [3]. The full set of documents present the background and information needed to implement Integrated Services and RSVP over ATM.
このメモはATM交換仮想回路(SVCs)の上に走行RSVPのための特定の実施要綱を提示します。 [6]で一般的問題について議論します。 [2]で実現要件について議論します。 ATMサービス対応表への統合Servicesは[3]で覆われています。 ATMの上のドキュメントプレゼントのバックグラウンド、Integrated Servicesを実行するのに必要である情報、およびRSVPのフルセット。
1. Introduction
1. 序論
This memo discusses running IP over ATM in an environment where SVCs are used to support QoS flows and RSVP is used as the internet level QoS signaling protocol. It applies when using CLIP/ION, LANE2.0 and MPOA methods for supporting IP over ATM. The general issues related to running RSVP[4] over ATM have been covered in several papers including [6] and other earlier work. This document is intended as a companion to [6,2] and as a guide to implementers. The reader should be familiar with both documents.
このメモは、SVCsがQoS流れを支持するのに使用されるところでATMで環境でIPを経営しているのを議論します、そして、インターネットレベルQoSシグナリングが議定書を作るとき、RSVPは使用されています。 ATMの上でIPを支持するのにCLIP/ION、LANE2.0、およびMPOA方法を使用するとき、それは適用されます。 [6]と他の以前の仕事を含んでいて、数個の書類でATMの上でRSVP[4]を走らせると関連する一般答弁をカバーしています。 このドキュメントは[6、2]への仲間としてimplementersのガイドとして意図します。 読者は両方のドキュメントに詳しいはずです。
This document provides a recommended set of functionality for implementations using ATM UNI3.x and 4.0, while allowing for more sophisticated approaches. We expect some vendors to additionally provide some of the more sophisticated approaches described in [6], and some networks to only make use of such approaches. The recommended set of functionality is defined to ensure predictability and interoperability between different implementations. Requirements for RSVP over ATM implementations are provided in [2].
このドキュメントは、より洗練されたアプローチを考慮している間、ATM UNI3.xと4.0を使用することで実現のためのお勧めの機能性を提供します。 私たちは、いくつかの業者がそのようなアプローチを利用するだけであるためにさらに、[6]で説明された、より精巧なアプローチ、およびいくつかのネットワークをいくつか提供すると予想します。 お勧めの機能性は、異なった実現の間の予見性と相互運用性を確実にするために定義されます。 ATM実現の上のRSVPのための要件を[2]に提供します。
Berger Best Current Practice [Page 1] RFC 2379 RSVP over ATM Implementation Guidelines August 1998
気圧実施要綱1998年8月の間のバーガー最も良い現在の習慣[1ページ]RFC2379RSVP
This document uses the same terms and assumption stated in [2]. Additionally, 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 RFC 2119 [5].
このドキュメントは同じ用語と[2]に述べられた仮定を使用します。 さらに、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[5]で説明されるように本書では解釈されることであるべきですか?
2. Implementation Recommendations
2. 実現推薦
This section provides implementation guidelines for implementation of RSVP over ATM. Several recommendations are common for all, RSVP sessions, both unicast and multicast. There are also recommendations that are unique to unicast and multicast session types.
このセクションはRSVPの実現のための実施要綱をATMの上に供給します。 RSVPセッション、ユニキャストとマルチキャストの両方に、いくつかの推薦が一般的です。 また、ユニキャストにユニークな推薦とマルチキャストセッションタイプがあります。
2.1 RSVP Message VC Usage
2.1 RSVPメッセージVC用法
The general issues related to which VC should be used for RSVP messages is covered in [6]. It discussed several implementation options including: mixed control and data, single control VC per session, single control VC multiplexed among sessions, and multiple VCs multiplexed among sessions. QoS for control VCs was also discussed. The general discussion is not repeated here and [6] should be reviewed for detailed information.
どのVCがRSVPメッセージに使用されるべきであるかと関係づけられた一般答弁は[6]でカバーされています。 議論して、:それはいくつかの実現オプションについて議論しました。 複雑なコントロールとデータ、1セッションあたりの単一管理VC、単一管理VCはセッションのときに多重送信しました、そして、複数のVCsがセッションのときに多重送信しました。 また、コントロールVCsのためのQoSについて議論しました。 一般的な議論はここで繰り返されません、そして、[6]は詳細な情報のために見直されるべきです。
RSVP over ATM implementations SHOULD send RSVP control (messages) over the best effort data path, see figure 1. It is permissible to allow a user to override this behavior. The stated approach minimizes VC requirements since the best effort data path will need to exist in order for RSVP sessions to be established and in order for RSVP reservations to be initiated. The specific best effort paths that will be used by RSVP are: for unicast, the same VC used to reach the unicast destination; and for multicast, the same VC that is used for best effort traffic destined to the IP multicast group. Note that for multicast there may be another best effort VC that is used to carry session data traffic, i.e., for data that is both in the multicast group and matching a sessions protocol and port.
図1は、ATM実現SHOULDの上のRSVPがベストエフォート型データ経路の上で(メッセージ)をRSVPコントロールに送るのを見ます。 ユーザがこの振舞いをくつがえすのを許容するのは許されています。 述べられたアプローチは、ベストエフォート型データ経路が、RSVPセッションが証明されるために存在する必要があって、RSVPの予約が開始されるためにVC要件を最小にします。 RSVPによって使用される特定のベストエフォート型経路は以下の通りです。 ユニキャストのために、同じVCは以前はよくユニキャストの目的地に達していました。 そして、マルチキャストのために、ベストエフォート型交通に使用されるのと同じVCはIPマルチキャストグループに運命づけました。 そこのマルチキャストのためのそれがすなわち、マルチキャストグループには両方の、あるデータのためのセッションデータ通信量を運ぶのに使用されて、セッションプロトコルとポートに合っている別のベストエフォート型VCであるかもしれないことに注意してください。
Berger Best Current Practice [Page 2] RFC 2379 RSVP over ATM Implementation Guidelines August 1998
気圧実施要綱1998年8月の間のバーガー最も良い現在の習慣[2ページ]RFC2379RSVP
Data Flow ==========>
データフロー==========>。
QoS VCs
+-----+ --------------> +----+
| | --------------> | |
| Src | | R1 |
| | Best Effort VC(s) | |
+-----+ <-----------------> +----+
/\
||
||
RSVP Control
Messages
QoS VCs+-----+ -------------->+----+ | | -------------->|、|、| Src| | R1| | | ベストエフォート型VC(s)| | +-----+ <。----------------->+----+ /\ || || RSVPコントロールメッセージ
Figure 1: RSVP Control Message VC Usage
図1: RSVPコントロールメッセージVC用法
The disadvantage of this approach is that best effort VCs may not provide the reliability that RSVP needs. However the best effort path is expected to satisfy RSVP reliability requirements in most networks. Especially since RSVP allows for a certain amount of packet loss without any loss of state synchronization.
このアプローチの不都合はベストエフォート型VCsがRSVPが必要とする信頼性を提供しないかもしれないということです。 しかしながら、ベストエフォート型経路がほとんどのネットワークでRSVP信頼度要求事項を満たすと予想されます。 特にRSVPが州の同期の少しも損失なしである量のパケット損失を考慮するので。
2.2 Aggregation
2.2 集合
As discussed in [6], data associated with multiple RSVP sessions can be sent using the same shared VCs. Implementation of such "aggregation" models is still a matter for research. Therefore, RSVP over ATM implementations SHOULD use independent VCs for each RSVP reservation.
[6]で議論するように、複数のRSVPセッションに関連しているデータに同じ共有されたVCsを使用させることができます。 それでも、そのような「集合」モデルの実現は調査のための問題です。 したがって、ATM実現SHOULDの上のRSVPはそれぞれのRSVPの予約に独立しているVCsを使用します。
2.3 Short-Cuts
2.3 短いカット
Short-cuts allow ATM attached routers and hosts to directly establish point-to-point VCs across LIS boundaries, i.e., the VC end-points are on different IP subnets. Short-cut support for unicast traffic has been defined in [7] and [1]. The ability for short-cuts and RSVP to interoperate has been raised as a general question. The area of concern is the ability to handle asymmetric short-cuts. Specifically how RSVP can handle the case where a downstream short-cut may not have a matching upstream short-cut. In this case, which is shown in figure 2, PATH and RESV messages following different paths.
ショートカットはLIS境界の向こう側に直接ポイントツーポイントVCsを証明するために添付のATMにルータとホストを許容します、すなわち、VCエンドポイントが異なったIPサブネットにあります。 ユニキャスト交通のショートカットサポートは[7]と[1]で定義されました。 ショートカットとRSVPが共同利用する能力は一般疑問として上げられました。 気になる所は非対称のショートカットを扱う能力です。 RSVPは明確に、どう、川下のショートカットが合っている上流のショートカットを持っていないかもしれないケースを扱うことができるか。 この場合異なった経路に続く2が中でどれが計算するのが示されるか、そして、PATHとRESVメッセージ。
Berger Best Current Practice [Page 3] RFC 2379 RSVP over ATM Implementation Guidelines August 1998
気圧実施要綱1998年8月の間のバーガー最も良い現在の習慣[3ページ]RFC2379RSVP
______
/ \
+-------- / Router \ <-------+
| \ / | <....... RESVs Follow
| \______/ | Hop-by-hop Path
| |
| |
V QoS VCs |
+-----+ ==============> +----+
| | ==============> | |
| Src | | R1 |
| | Best Effort VC(s) | |
+-----+ <=================> +----+
______ / \ +-------- /ルータ\<。-------+ | \ / | <… RESVsは続きます。| \______/ | ホップごとの経路| | | | V QoS VCs| +-----+ ==============>+----+ | | ==============>|| | Src| | R1| | | ベストエフォート型VC(s)| | +-----+ <。=================>+----+
/\
:: Data Paths:
:: ----> Hop-by-hop (routed)
PATHs and Data ====> Short-cut
Follow Short-cut
Path
/\ :: データ経路: :: ---->ホップ(掘る)ごとの経路とデータ====>ショートカットはショートカット経路に続きます。
Figure 2: Asymmetric RSVP Message Forwarding With ATM Short-Cuts
図2: 気圧ショートカットとの非対称のRSVPメッセージ推進
Examination of RSVP shows that the protocol already includes mechanisms that allows support of the asymmetric paths. The mechanism is the same one used to support RESV messages arriving at the wrong router and the wrong interface. RSVP messages are only processed when they arrive at the proper interface. When messages arrive on the wrong interface, they are forwarded by RSVP. The proper interface is indicated in the NHOP object of the message. So, existing RSVP mechanisms will support the asymmetric paths that can occur when using short-cuts.
RSVPの試験は、プロトコルが既にそれが非対称の経路のサポートを許すメカニズムを含むのを示します。 メカニズムは間違ったルータと間違ったインタフェースに到着するRESVメッセージを支持するのに使用される同じ1つです。 適切なインタフェースに到着するときだけ、RSVPメッセージは処理されます。 メッセージが間違ったインタフェースで到着するとき、それらはRSVPによって進められます。 適切なインタフェースはメッセージのNHOP物で示されます。 それで、既存のRSVPメカニズムはショートカットを使用するとき起こることができる非対称の経路を支持するでしょう。
The short-cut model of VC establishment still poses several issues when running with RSVP. The major issues are dealing with established best effort short-cuts, when to establish short-cuts, and QoS only short-cuts. These issues will need to be addressed by RSVP implementations.
RSVPと共に走るとき、VC設立のショートカットモデルはまだいくつかの問題を引き起こしています。 大変な問題は短いカットであるだけであることで確立したベストエフォート型ショートカット、いつショートカットを確立するか、そして、およびQoSに対処しています。 これらの問題は、RSVP実現で記述される必要があるでしょう。
The key issue to be addressed by RSVP over ATM implementations is when to establish a short-cut for a QoS data flow. RSVP over ATM implementations SHOULD simply follow best effort traffic. When a short-cut has been established for best effort traffic to a destination or next-hop, that same end-point SHOULD be used when setting up RSVP triggered VCs for QoS traffic to the same destination or next-hop. This will happen naturally when PATH messages are forwarded over the best effort short-cut. Note that in this
ATM実現の上にRSVPによって記述されるべき主要な問題はQoSデータフローのためにいつショートカットを確立するかということです。 ATM実現SHOULDの上のRSVPは単にベストエフォート型交通に続きます。 ショートカットが目的地か次のホップへのベストエフォート型交通に確立されたとき、RSVPをセットアップするとき、同じエンドポイントSHOULDが使用されるのが同じ目的地へのQoS交通へのVCsか次のホップの引き金となりました。 ベストエフォート型ショートカットについてPATHメッセージを転送するとき、これは自然に起こるでしょう。 これでそれに注意してください。
Berger Best Current Practice [Page 4] RFC 2379 RSVP over ATM Implementation Guidelines August 1998
気圧実施要綱1998年8月の間のバーガー最も良い現在の習慣[4ページ]RFC2379RSVP
approach, when best effort short-cuts are never established, RSVP triggered QoS short-cuts will also never be established.
RSVPはショートカットが引き金となるQoSの引き金となりました、ベストエフォート型ショートカットが決して確立されないとき、アプローチしてください、そして、また、決して設立されないでください。
2.4 Data VC Management for Heterogeneous Sessions
2.4 異種のセッションのためのデータVC管理
Heterogeneous sessions can only occur with multicast RSVP sessions. The issues relating to data VC management of heterogeneous sessions are covered in detail in [6] and are not repeated in this document. In summary, heterogeneity occurs when receivers request different levels of QoS within a single session and also when some receivers do not request any QoS. Both types of heterogeneity are shown in figure 3.
異種のセッションはマルチキャストRSVPセッションで起こることができるだけです。 異種のセッションのデータVC管理に関連する問題は、[6]で詳細にカバーされていて、本書では繰り返されません。 ただ一つのセッションといくつかの受信機がいつQoSを少しの要求しないかの中にも受信機がQoSの異なったレベルを要求するとき、概要では、異種性は起こります。 異種性の両方のタイプは3が中で計算するのが示されます。
+----+
+------> | R1 |
| +----+
|
| +----+
+-----+ -----+ +--> | R2 |
| | ---------+ +----+ Receiver Request Types:
| Src | ----> QoS 1 and QoS 2
| | .........+ +----+ ....> Best-Effort
+-----+ .....+ +..> | R3 |
: +----+
/\ :
|| : +----+
|| +......> | R4 |
|| +----+
Single
IP Mulicast
Group
+----+ +------>| R1| | +----+ | | +----+ +-----+ -----+ +-->。| R2| | | ---------+ +----+ 受信機要求タイプ: | Src| ---->QoS1とQoS2| | .........+ +----+ ....>のベストエフォート型+-----+ .....+ +..>| R3| : +----+ /\ : || : +----+ || +......>| R4| || +----+ ただ一つのIP Mulicastグループ
Figure 3: Types of Multicast Receivers
図3: マルチキャスト受信機のタイプ
[6] provides four models for dealing with heterogeneity: full heterogeneity, limited heterogeneity, homogeneous, and modified homogeneous models. The key issue to be addressed by an implementation is providing requested QoS downstream. One of, or some combination of, the discussed models [6] may be used to provide the requested QoS. Unfortunately, none of the described models is the right answer for all cases. For some networks, e.g. public WANs, it is likely that the limited heterogeneous model or a hybrid limited- full heterogeneous model will be desired. In other networks, e.g. LANs, it is likely that a the modified homogeneous model will be desired.
[6]は4つのモデルを異種性に対処するのに提供します: 完全な異種性、限られた異種性、均質の、そして、変更された均質モデル。 実現で記述されるべき主要な問題は要求されたQoSを川下に提供しています。 1つ、何らかの組み合わせ、議論されたモデル[6]は、要求されたQoSを提供するのに使用されるかもしれません。 残念ながら、説明されたモデルのだれもすべてのケースのための正しい答ではありません。 いくつかのネットワーク、例えば、公共のWANにおいて、限られた異種のモデルかハイブリッド限られた完全な異種のモデルが望まれそうでしょう。 他のネットワーク、例えば、LANでは、変更された均質モデルのaは望まれそうでしょう。
Berger Best Current Practice [Page 5] RFC 2379 RSVP over ATM Implementation Guidelines August 1998
気圧実施要綱1998年8月の間のバーガー最も良い現在の習慣[5ページ]RFC2379RSVP
Since there is not one model that satisfies all cases, implementations SHOULD implement one of either the limited heterogeneity model or the modified homogeneous model. Implementations SHOULD support both approaches and provide the ability to select which method is actually used, but are not required to do so.
すべてのケースを満たす1つのモデルがないので、実現SHOULDは限られた異種性モデルか変更された均質モデルのどちらかのひとりを実行します。 実現SHOULDは両方のアプローチを支持して、どの方法が実際に使用されるかを選択する能力を提供しますが、そうする必要はありません。
3. Security Considerations
3. セキュリティ問題
The same considerations stated in [4] and [8] apply to this document. There are no additional security issues raised in this document.
[4]と[8]に述べられた同じ問題はこのドキュメントに適用されます。 本書では提起された追加担保問題が全くありません。
4. Acknowledgments
4. 承認
This work is based on earlier drafts and comments from the ISSLL working group. The author would like to acknowledge their contribution, most notably Steve Berson who coauthored one of the drafts.
この仕事はISSLLワーキンググループからの以前の草稿とコメントに基づいています。 作者は彼らの貢献、最も著しく草稿の1つについて共同執筆したスティーブBersonを承認したがっています。
5. Author's Address
5. 作者のアドレス
Lou Berger FORE Systems 1595 Spring Hill Road 5th Floor Vienna, VA 22182
ルウバーガー前面のシステム1595スプリングヒル道路第5Floorウィーン、ヴァージニア 22182
Phone: +1 703-245-4527 EMail: lberger@fore.com
以下に電話をしてください。 +1 703-245-4527 メールしてください: lberger@fore.com
Berger Best Current Practice [Page 6] RFC 2379 RSVP over ATM Implementation Guidelines August 1998
気圧実施要綱1998年8月の間のバーガー最も良い現在の習慣[6ページ]RFC2379RSVP
REFERENCES
参照
[1] The ATM Forum, "MPOA Baseline Version 1", May 1997.
[1] 気圧フォーラム、「MPOA、基線バージョン1インチと、1997インチ年5月。
[2] Berger, L., "RSVP over ATM Implementation Requirements",
RFC 2380, August 1998.
[2] バーガー、L.、「気圧実現要件の上のRSVP」、RFC2380、1998年8月。
[3] Borden, M., and M. Garrett, "Interoperation of Controlled-Load
and Guaranteed-Service with ATM", RFC 2381, August 1998.
[3]ボーデン、M.、およびM.ギャレット、「気圧がある制御負荷と保証されたサービスのInteroperation」、RFC2381、1998年8月。
[4] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
[4] ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[6] Crawley, E., Berger, L., Berson, S., Baker, F., Borden, M., and
J. Krawczyk, "A Framework for Integrated Services and RSVP over
ATM", RFC 2382, August 1998.
[6] クローリー、E.、バーガー、L.、Berson、S.、ベイカー、F.、ボーデン、M.、およびJ.Krawczyk、「気圧での統合サービスとRSVPのための枠組み」、RFC2382(1998年8月)。
[7] Luciani, J., Katz, D., Piscitello, D., and B. Cole, "NBMA Next
Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.
[7]Luciani、J.、キャッツ、D.、Piscitello、D.、およびB.コール、「次のNBMAは解決プロトコル(NHRP)を飛び越す」RFC2332、1998年4月。
[8] Perez, M., Liaw, F., Grossman, D., Mankin, A., Hoffman, E., and
A. Malis, "ATM Signalling Support for IP over ATM", RFC 1755,
February 1995.
[8] ペレス、M.、Liaw、F.、グロースマン、D.、マンキン、A.、ホフマン、E.、およびA.Malis、「気圧でのIPの気圧合図サポート」、RFC1755(1995年2月)。
Berger Best Current Practice [Page 7] RFC 2379 RSVP over ATM Implementation Guidelines August 1998
気圧実施要綱1998年8月の間のバーガー最も良い現在の習慣[7ページ]RFC2379RSVP
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Berger Best Current Practice [Page 8]
バーガーBest現在の習慣[8ページ]
一覧
スポンサーリンク
