RFC2729 日本語訳
2729 Taxonomy of Communication Requirements for Large-scale MulticastApplications. P. Bagnall, R. Briscoe, A. Poppitt. December 1999. (Format: TXT=53322 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Bagnall
Request for Comments: 2729 R. Briscoe
Category: Informational A. Poppitt
BT
December 1999
Bagnallがコメントのために要求するワーキンググループP.をネットワークでつないでください: 2729年のR.ブリスコウカテゴリ: 情報のA.Poppitt BT1999年12月
Taxonomy of Communication Requirements
for Large-scale Multicast Applications
大規模なマルチキャストアプリケーションのためのコミュニケーション要件の分類学
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 (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
Abstract
要約
The intention of this memo is to define a classification system for the communication requirements of any large-scale multicast application (LSMA). It is very unlikely one protocol can achieve a compromise between the diverse requirements of all the parties involved in any LSMA. It is therefore necessary to understand the worst-case scenarios in order to minimize the range of protocols needed. Dynamic protocol adaptation is likely to be necessary which will require logic to map particular combinations of requirements to particular mechanisms. Standardizing the way that applications define their requirements is a necessary step towards this. Classification is a first step towards standardization.
このメモの意志はどんな大規模なマルチキャストアプリケーション(LSMA)のコミュニケーション要件の分類システムも定義することです。 1つのプロトコルがどんなLSMAにもかかわるすべてのパーティーのさまざまの要件の間の妥協を実現できるのは、非常にありそうもないです。 したがって、最悪の見通しを理解するのが、必要であるプロトコルの範囲を最小にするのに必要です。 ダイナミックなプロトコル適合はどれがアプリケーションがそれらの要件を定義する方法で特定のメカニズム標準化への要件の特定の組み合わせを写像するために論理を必要とするかが、必要なステップであることがこれに向かって必要である傾向があります。 分類は標準化に向かった第一歩です。
Bagnall, et al. Informational [Page 1] RFC 2729 Taxonomy of Communication Requirements December 1999
Bagnall、他 コミュニケーション要件1999年12月の情報[1ページ]のRFC2729分類学
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions of Sessions. . . . . . . . . . . . . . . . . 3
3. Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Summary of Communications Parameters . . . . . . . . 4
3.2. Definitions, types and strictest requirements. . . . 5
3.2.1. Types . . . . . . . . . . . . . . . . . . . . . 6
3.2.2. Reliability . . . . . . . . . . . . . . . . . . 7
3.2.2.1. Packet Loss . . . . . . . . . . . . . . . . 7
3.2.2.2. Component Reliability . . . . . . . . . . . 8
3.2.3. Ordering . . . . . . . . . . . . . . . . . . . . 9
3.2.4. Timeliness . . . . . . . . . . . . . . . . . . . 9
3.2.5. Session Control . . . . . . . . . . . . . . . .13
3.2.6. Session Topology . . . . . . . . . . . . . . . .16
3.2.7. Directory . . . . . . . . . . . . . . . . . . .17
3.2.8. Security . . . . . . . . . . . . . . . . . . . .17
3.2.8.1. Security Dynamics . . . . . . . . . . . . .23
3.2.9. Payment & Charging . . . . . . . . . . . . . . .24
4. Security Considerations . . . . . . . . . . . . . . . .25
5. References . . . . . . . . . . . . . . . . . . . . . .25
6. Authors' Addresses . . . . . . . . . . . . . . . . . . .26
7. Full Copyright Statement . . . . . . . . . . . . . . . .27
1. 序論. . . . . . . . . . . . . . . . . . . . . . 2 2。 セッションの定義。 . . . . . . . . . . . . . . . . 3 3. 分類学. . . . . . . . . . . . . . . . . . . . . . . . 4 3.1。 コミュニケーションパラメタ. . . . . . . . 4 3.2の概要 定義、タイプ、および最も厳しい要件。 . . . 5 3.2.1. .2に.63.2をタイプします。 信頼性、.73.2 .2 .1。 パケット損失. . . . . . . . . . . . . . . . 7 3.2.2.2。 コンポーネントの信頼性. . . . . . . . . . . 8 3.2.3。 注文. . . . . . . . . . . . . . . . . . . . 9 3.2.4。 タイムリー. . . . . . . . . . . . . . . . . . . 9 3.2.5。 セッション制御. . . . . . . . . . . . . . . .13 3.2.6。 セッショントポロジー. . . . . . . . . . . . . . . .16 3.2.7。 ディレクトリ. . . . . . . . . . . . . . . . . . .17 3.2.8。 セキュリティ、.3.2 .8 .1。 セキュリティ力学. . . . . . . . . . . . .23 3.2.9。 支払いと充電. . . . . . . . . . . . . . .24 4。 セキュリティ問題. . . . . . . . . . . . . . . .25 5。 参照. . . . . . . . . . . . . . . . . . . . . .25 6。 作者のアドレス. . . . . . . . . . . . . . . . . . .26 7。 完全な著作権宣言文.27……………
1. Introduction
1. 序論
This taxonomy consists of a large number of parameters that are considered useful for describing the communication requirements of LSMAs. To describe a particular application, each parameter would be assigned a value. Typical ranges of values are given wherever possible. Failing this, the type of any possible values is given. The parameters are collected into ten or so higher level categories, but this is purely for convenience.
この分類学はLSMAsのコミュニケーション要件について説明することの役に立つと考えられる多くのパラメタから成ります。 特定用途について説明するために、値は各パラメタに割り当てられるでしょう。 典型的な範囲の値をどこでも、可能であるところに与えます。 これに失敗して、どんな可能な値のタイプも与えます。 パラメタはおよそ10のより高い平らなカテゴリに集められますが、これは純粋に便宜のためのものです。
The parameters are pitched at a level considered meaningful to application programmers. However, they describe communications not applications - the terms '3D virtual world', or 'shared TV' might imply communications requirements, but they don't accurately describe them. Assumptions about the likely mechanism to achieve each requirement are avoided where possible.
パラメタはアプリケーション・プログラマーにとって重要であると考えられたレベルで調節されます。 しかしながら、彼らはアプリケーションではなく、コミュニケーションについて説明します--用語'3D仮想世界'、または'共有されたテレビ'はコミュニケーション要件を含意するかもしれませんが、それらは正確にそれらについて説明しません。 各要件を達成するありそうなメカニズムに関する仮定は可能であるところで避けられます。
While the parameters describe communications, it will be noticed that few requirements concerning routing etc. are apparent. This is because applications have few direct requirements on these second order aspects of communications. Requirements in these areas will have to be inferred from application requirements (e.g. latency).
パラメタがコミュニケーションについて説明している間、ルーティングなどに関するわずかな要件が明らかであるのに気付かれるでしょう。 これはアプリケーションにはコミュニケーションのこれらの2番目のオーダー局面に関するわずかなダイレクト要件しかないからです。 これらの領域の要件はアプリケーション要件(例えば、潜在)から推論されなければならないでしょう。
Bagnall, et al. Informational [Page 2] RFC 2729 Taxonomy of Communication Requirements December 1999
Bagnall、他 コミュニケーション要件1999年12月の情報[2ページ]のRFC2729分類学
The taxonomy is likely to be useful in a number of ways:
分類学は多くの方法で役に立つ傾向があります:
1. Most simply, it can be used as a checklist to create a
requirements statement for a particular LSMA. Example applications
will be classified [bagnall98] using the taxonomy in order to
exercise (and improve) it
1. 最も単に、特定のLSMAのために要件声明を作成するのにチェックリストとしてそれを使用できます。 例のアプリケーションは、それを運動させること(向上する)に分類学を使用することで分類されるでしょう[bagnall98]。
2. Because strictest requirement have been defined for many
parameters, it will be possible to identify worst case scenarios
for the design of protocols
2. 最も厳しい要件が多くのパラメタのために定義されたので、プロトコルのデザインのために最悪の場合を特定するのは可能でしょう。
3. Because the scope of each parameter has been defined (per session,
per receiver etc.), it will be possible to highlight where
heterogeneity is going to be most marked
3. それぞれのパラメタの範囲が定義されたので(受信機などあたりのセッション単位で)、それは異種性が最もマークされるところで強調するのにおいて可能になるでしょう。
4. It is a step towards standardization of the way LSMAs define their
communications requirements. This could lead to standard APIs
between applications and protocol adaptation middleware
4. それはLSMAsが彼らのコミュニケーション要件を定義する方法の標準化に向かったステップです。 これはアプリケーションとプロトコル適合ミドルウェアの間の標準のAPIに通じるかもしれません。
5. Identification of limitations in current Internet technology for
LSMAs to be added to the LSMA limitations memo [limitations]
5. LSMAsがLSMA制限メモに追加される現在のインターネット技術における、制限の識別[制限]
6. Identification of gaps in Internet Engineering Task Force (IETF)
working group coverage
6. インターネット・エンジニアリング・タスク・フォース(IETF)ワーキンググループ適用範囲でのギャップの識別
This approach is intended to complement that used where application scenarios for Distributed Interactive Simulation (DIS) are proposed in order to generate network design metrics (values of communications parameters). Instead of creating the communications parameters from the applications, we try to imagine applications that might be enabled by stretching communications parameters.
このアプローチがネットワークデザイン測定基準(コミュニケーションパラメタの値)を発生させるのにDistributed Interactive Simulation(DIS)のためのアプリケーションシナリオが提案されるところで使用されるそれの補足となることを意図します。 アプリケーションからコミュニケーションパラメタを作成することの代わりに、私たちはコミュニケーションパラメタを伸ばすことによって可能にされるかもしれないアプリケーションを想像しようとします。
2. Definition of Sessions
2. セッションの定義
The following terms have no agreed definition, so they will be defined for this document.
次の用語には同意された定義が全くないので、それらはこのドキュメントのために定義されるでしょう。
Session
a happening or gathering consisting of flows of information
related by a common description that persists for a non-trivial
time (more than a few seconds) such that the participants (be they
humans or applications) are involved and interested at
intermediate times. A session may be defined recursively as a
super-set of other sessions.
情報の流れから成る出来事か集会が関係者(人間かアプリケーションであることにかかわらず)が中間的時にかかわって、興味を持つように重要な時間(かなり多くの秒)持続する一般的な記述で関係したセッション。 セッションは他のセッションのスーパーセットと再帰的に定義されるかもしれません。
Secure session
a session with restricted access
制限されるとのセッションがアクセスする安全なセッション
Bagnall, et al. Informational [Page 3] RFC 2729 Taxonomy of Communication Requirements December 1999
Bagnall、他 コミュニケーション要件1999年12月の情報[3ページ]のRFC2729分類学
A session or secure session may be a sub and/or super set of a multicast group. A session can simultaneously be both a sub and a super-set of a multicast group by spanning a number of groups while time-sharing each group with other sessions.
セッションか安全なセッションが、マルチキャストグループの潜水艦、そして/または、最高のセットであるかもしれません。 同時に、セッションは潜水艦と他のセッションで各グループを時分割している間、多くのグループにかかるのによるマルチキャストグループのスーパーセットの両方であることができます。
3. Taxonomy
3. 分類学
3.1 Summary of Communications Parameters
3.1 コミュニケーションパラメタの概要
Before the communications parameters are defined, typed and given worst-case values, they are simply listed for convenience. Also for convenience they are collected under classification headings.
最悪の場合値をタイプされて、考えて、コミュニケーションパラメタが定義される前に、それらは便宜のために単に記載されます。 便利においても、それらは分類見出しの下で集められます。
Reliability . . . . . . . . . . . . . . . . . . . . . . 3.2.1
Packet loss . . . . . . . . . . . . . . . . . . . . 3.2.1.1
Transactional
Guaranteed
Tolerated loss
Semantic loss
Component reliability . . . . . . . . . . . . . . . 3.2.1.2
Setup fail-over time
Mean time between failures
Fail over time during a stream
Ordering . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2
Ordering type
Timeliness . . . . . . . . . . . . . . . . . . . . . . . 3.2.3
Hard Realtime
Synchronicity
Burstiness
Jitter
Expiry
Latency
Optimum bandwidth
Tolerable bandwidth
Required by time and tolerance
Host performance
Fair delay
Frame size
Content size
Session Control . . . . . . . . . . . . . . . . . . . . 3.2.4
Initiation
Start time
End time
Duration
Active time
Session Burstiness
Atomic join
Late join allowed ?
流れのOrdering. . . . . . . . . . . . . . . . . . . . . . . . 3.2.2Orderingの間の時間がたつにつれての失敗Failの間の信頼性. . . . . . . . . . . . . . . . . . . . . . 3.2の.1Packet損失.3.2.1.1Transactional Guaranteed Tolerated損失Semantic損失Component信頼性. . . . . . . . . . . . . . . 3.2の.1.2Setupフェイルオーバー時間Mean時間に、Timelinessをタイプしてください; . . . . . . . . . . . . . . . . . . . . . . 3.2.3 時間までに困難なRealtime Synchronicity Burstiness Jitter Expiry Latency Optimum帯域幅「トーラー-可能」帯域幅Requiredと時間Session Burstiness AtomicがLateを接合する時間Duration Activeが許容されていた状態で接合する寛容Host性能Fair遅れFrameサイズContentサイズSession Control. . . . . . . . . . . . . . . . . . . . 3.2.4Initiation Start時間End?
Bagnall, et al. Informational [Page 4] RFC 2729 Taxonomy of Communication Requirements December 1999
Bagnall、他 コミュニケーション要件1999年12月の情報[4ページ]のRFC2729分類学
Temporary leave allowed ?
Late join with catch-up allowed ?
Potential streams per session
Active streams per sessions
Session Topology . . . . . . . . . . . . . . . . . . . . 3.2.5
Number of senders
Number of receivers
Directory . . . . . . . . . . . . . . . . . . . . . . . 3.2.6
Fail-over time-out (see Reliability: fail-over time)
Mobility
Security . . . . . . . . . . . . . . . . . . . . . . . . 3.2.7
Authentication strength
Tamper-proofing
Non-repudiation strength
Denial of service
Action restriction
Privacy
Confidentiality
Retransmit prevention strength
Membership criteria
Membership principals
Collusion prevention
Fairness
Action on compromise
Security dynamics . . . . . . . . . . . . . . . . . . . 3.2.8
Mean time between compromises
Compromise detection time limit
compromise recovery time limit
Payment & Charging . . . . . . . . . . . . . . . . . . . 3.2.9
Total Cost
Cost per time
Cost per Mb
許容された一時的な休暇? 遅く、許容されているケチャップに接合しますか? セッションSession TopologyあたりのセッションActiveの流れあたりの潜在的流れ、.3.2、.5Number、受信機時間アウトの上のディレクトリ. . . . . . . . . . . . . . . . . . . . . . . 3.2.6Fail(Reliability:フェイルオーバー時間に遭遇する)の移動性Security. . . . . . . . . . . . . . . . . . . . . . . . 3.2の送付者Number; 妥協Security力学の7認証サービスAction制限Privacy Confidentiality Retransmit防止強さMembership評価基準Membership校長Collusion防止のTamperを検査している強さNon-拒否強さDenial Fairness Actionが間の.3.2.8Mean時間にCompromise検出タイムリミット妥協回復時間限界Payment&Chargingで妥協する、.3.2、.9Total Cost Cost、1Mbあたりの時間Cost
3.2 Definitions, types and strictest requirements
3.2 定義、タイプ、および最も厳しい要件
The terms used in the above table are now defined for the context of this document. Under each definition, the type of their value is given and where possible worst-case values and example applications that would exhibit this requirement.
上のテーブルで使用される用語は現在、このドキュメントの文脈のために定義されます。 各定義で、それらの価値のタイプを与えます、そして、可能であるところで最もひどくこの要件を示す値と例のアプリケーションをケースに入れてください。
There is no mention of whether a communication is a stream or a discrete interaction. An attempt to use this distinction as a way of characterizing communications proved to be remarkably unhelpful and was dropped.
コミュニケーションが流れかそれとも離散的な相互作用であるかに関する言及が全くありません。 コミュニケーションを特徴付ける方法としてこの区別を使用する試みは、著しく役に立たないと判明して、落とされました。
Bagnall, et al. Informational [Page 5] RFC 2729 Taxonomy of Communication Requirements December 1999
Bagnall、他 コミュニケーション要件1999年12月の情報[5ページ]のRFC2729分類学
3.2.1 Types
3.2.1 タイプ
Each requirement has a type. The following is a list of all the types used in the following definitions.
各要件には、タイプがあります。 ↓これは以下の定義に使用されるすべてのタイプのリストです。
Application Benchmark
アプリケーションベンチマーク
This is some measure of the processor load of an application, in
some architecture neutral unit. This is non-trivial since the
processing an application requires may change radically with
different hardware, for example, a video client with and without
hardware support.
これは何らかの構造の中立ユニットにおけるアプリケーションのプロセッサ荷重ですある程度の。 アプリケーションが必要とする処理がハードウェアサポートのあるなしにかかわらず例えば、異なったハードウェアでビデオクライアントを根本的に変えるかもしれないので、これは重要です。
Bandwidth Measured in bits per second, or a multiple of.
bps、または倍数における帯域幅Measured
Boolean
論理演算子
Abstract Currency
An abstract currency is one which is adjusted to take inflation
into account. The simplest way of doing this is to use the value
of a real currency on a specific date. It is effectively a way of
assessing the cost of something in "real terms". An example might
be 1970 US$. Another measure might be "average man hours".
抽象的なCurrency An抽象的な通貨はインフレーションを考慮に入れるように調整されるものです。 これをする最も簡単な方法は特定の期日に実際の通貨の値を使用することです。 事実上、それは「実物称呼」による何かの費用を査定する方法です。 例は1970USドルであるかもしれません。別の測定は「普通の人時間」であるかもしれません。
Currency - current local
通貨--現在のローカル
Data Size
データサイズ
Date (time since epoch)
日付(時代以来の時間)
Enumeration
列挙
Fraction
断片
Identifiers
A label used to distinguish different parts of a communication
識別子Aラベルは以前はよくコミュニケーションの異なった部分を区別していました。
Integer
整数
Membership list/rule
会員名簿/規則
Macro
A small piece of executable code used to describe policies
マクロのA小さい実行コードは以前はよく方針を説明していました。
Time
時間
Bagnall, et al. Informational [Page 6] RFC 2729 Taxonomy of Communication Requirements December 1999
Bagnall、他 コミュニケーション要件1999年12月の情報[6ページ]のRFC2729分類学
3.2.2 Reliability
3.2.2 信頼性
3.2.2.1 Packet Loss
3.2.2.1 パケット損失
Transactional
取引
When multiple operations must occur atomically, transactional
communications guarantee that either all occur or none occur and a
failure is flagged.
同時併行処理が原子論的に起こらなければならないと、取引のコミュニケーションは、すべてが起こるか、またはなにも起こらないのを保証します、そして、失敗は旗を揚げられます。
Type: Boolean
Meaning: Transactional or Not transaction
Strictest Requirement: Transactional
Scope: per stream
Example Application: Bank credit transfer, debit and credit must
be atomic.
NB: Transactions are potentially much more
complex, but it is believed this is
an application layer problem.
以下をタイプしてください。 ブール意味: 取引かNot取引Strictest Requirement: 取引の範囲: 流れのExample Application単位で: 銀行単位互換、借り方、およびクレジットは原子であるに違いありません。 ネブラスカ: 取引は潜在的にはるかに複雑ですが、これが応用層問題であると信じられています。
Guaranteed
保証されます。
Guarantees communications will succeed under certain conditions.
保証コミュニケーションは一定の条件の下で成功するでしょう。
Type: Enumerated
Meaning: Deferrable - if communication fails it will
be deferred until a time when it will be
successful.
Guaranteed - the communication will succeed
so long as all necessary components are
working.
No guarantee - failure will not be
reported.
Strictest Requirement: Deferrable
Example Application: Stock quote feed - Guaranteed
Scope: per stream
NB: The application will need to set parameters
to more fully define Guarantees, which the
middleware may translate into, for example,
queue lengths.
以下をタイプしてください。 列挙された意味: 延期できる、--コミュニケーションが失敗すると、それはうまくいく時まで延期されるでしょう。 保証されました--すべての必要なコンポーネントが機能している限り、コミュニケーションは成功するでしょう。 保証がありません--失敗は報告されないでしょう。 最も厳しい要件: 延期できる例のアプリケーション: 株価給送--Scopeは保証しました: 流れのネブラスカ単位で: アプリケーションは、パラメタにミドルウェアが例えば、待ち行列の長さに翻訳するかもしれないGuaranteesをより完全に定義するように設定する必要があるでしょう。
Tolerated loss
許容損失
This specifies the proportion of data from a communication that
can be lost before the application becomes completely unusable.
これはアプリケーションが完全に使用不可能になる前に失うことができるコミュニケーションからのデータの割合を指定します。
Bagnall, et al. Informational [Page 7] RFC 2729 Taxonomy of Communication Requirements December 1999
Bagnall、他 コミュニケーション要件1999年12月の情報[7ページ]のRFC2729分類学
Type: Fraction
Meaning: fraction of the stream that can be lost
Strictest Requirement: 0%
Scope: per stream
Example Application: Video - 20%
以下をタイプしてください。 断片意味: 無くなっているStrictest Requirementであるかもしれない流れの部分: 0%の範囲: 流れのExample Application単位で: ビデオ--20%
Semantic loss
意味損失
The application specifies how many and which parts of the
communication can be discarded if necessary.
アプリケーションは、必要なら、コミュニケーションのどの何、と部分を捨てることができるかを指定します。
Type: Identifiers, name disposable application
level frames
Meaning: List of the identifiers of application
frames which may be lost
Strictest Requirement: No loss allowed
Scope: per stream
以下をタイプしてください。 識別子、名前アプリケーションの使い捨てのレベルフレームMeaning: 無くなっているStrictest Requirementであるかもしれないアプリケーションフレームに関する識別子のリスト: どんな損失もScopeを許容しませんでした: 流れ単位で
Example Application: Video feed - P frames may be lost, I frames
not
例のアプリケーション: ビデオ給送--Pフレームはなくされるかもしれなくて、私はフレームです。
3.2.2.2. Component Reliability
3.2.2.2. コンポーネントの信頼性
Setup Fail-over time
時間がたつにつれてのセットアップFail
The time before a failure is detected and a replacement component
is invoked. From the applications point of view this is the time
it may take in exceptional circumstances for a channel to be set-
up. It is not the "normal" operating delay before a channel is
created.
失敗の前の時間は検出されます、そして、交換コンポーネントは呼び出されます。 アプリケーション観点から、これはそれがチャンネルが用意ができている例外的な事情を見て取るかもしれない時です。 チャンネルが創造される前にそれは「正常な」操作誤り遅延ではありません。
Type: Time
Strictest Requirement: Web server - 1 second
Scope: per stream
Example Application: Name lookup - 5 seconds
以下をタイプしてください。 時間の最も厳しい要件: ウェブサーバー--1 第2Scope: 流れのExample Application単位で: 名前ルックアップ--5秒
Mean time between failures
平均故障間隔
The mean time between two consecutive total failures of the
channel.
チャンネルの2つの連続した大失敗の間の平均時。
Type: Time
Strictest Requirement: Indefinite
Scope: per stream
Example Application: Telephony - 1000 hours
以下をタイプしてください。 時間の最も厳しい要件: 無期範囲: 流れのExample Application単位で: 電話--1000時間
Bagnall, et al. Informational [Page 8] RFC 2729 Taxonomy of Communication Requirements December 1999
Bagnall、他 コミュニケーション要件1999年12月の情報[8ページ]のRFC2729分類学
Fail over time during a stream
流れの間のフェイルオーバー時間
The time between a stream breaking and a replacement being set up.
流れの壊すのとセットアップされる交換の間の時間。
Type: Time
Strictest Requirement: Equal to latency requirement
Scope: per stream
Example Application: File Transfer - 10sec
以下をタイプしてください。 時間の最も厳しい要件: 潜在要件Scopeの同輩: 流れのExample Application単位で: ファイル転送--10秒
3.2.3. Ordering
3.2.3. 注文します。
Ordering type
タイプを注文します。
Specifies what ordering must be preserved for the application
アプリケーションのためにどんな注文を保存しなければならないかを指定します。
Type: {
Enumeration timing,
Enumeration sequencing,
Enumeration causality
}
以下をタイプしてください。 列挙タイミング、Enumeration配列、Enumeration因果関係
Meaning: Timing - the events are timestamped
Global
Per Sender
none
Sequencing - the events are sequenced in
order of occurrence
Global
Per Sender
none
Causality - the events form a graph
relating cause and effect
Global
Per Sender
none
Strictest Requirement: Global, Global, Global
Scope: per stream
Example Application: Game - { none, per sender, global } (to
make sure being hit by bullet occurs
after the shot is fired!)
意味: タイミング、--、出来事がなにもにtimestamped Global Per SenderであるSequencing、--、出来事が発生Global Per Senderの順になにもに配列されるCausality、--、出来事がなにもに因果Global Per Senderを関係づけながらグラフを形成するStrictest Requirement: グローバルで、グローバルで、グローバルな範囲: 流れのExample Application単位で: ゲーム--送付者単位でグローバルでないなにも(弾丸が撃たれた後に弾丸によって念のため打たれるのは起こります!)
3.2.4. Timeliness
3.2.4. タイムリー
Hard real- time
困難なリアルタイム
There is a meta-requirement on timeliness. If hard real-time is
required then the interpretation of all the other requirements
changes. Failures to achieve the required timeliness must be
タイムリーに関するメタ要件があります。 困難であるなら、リアルタイムでは、その時必要であることで、他のすべての要件の解釈が変化するということです。 必要なタイムリーさであるのを達成しないことはそうであるに違いありません。
Bagnall, et al. Informational [Page 9] RFC 2729 Taxonomy of Communication Requirements December 1999
Bagnall、他 コミュニケーション要件1999年12月の情報[9ページ]のRFC2729分類学
reported before the communication is made. By contrast soft real-
time means that there is no guarantee that an event will occur in
time. However statistical measures can be used to indicate the
probability of completion in the required time, and policies such
as making sure the probability is 95% or better could be used.
コミュニケーションが作られている前に報告されます。 対照的に、柔らかいリアルタイムは、出来事が時間内に起こるという保証が全くないことを意味します。 しかしながら、統計的な測定を必要な時間で完成の確率、および確率が95%であることを確実にすることなどの方針を示すのに使用できたほうがよいか、または使用できたほうがよいです。
Type: Boolean
Meaning: Hard or Soft realtime
Strictest Requirement: Hard
Scope: per stream
Example Application: Medical monitor - Hard
以下をタイプしてください。 ブール意味: 困難であるかSoftリアルタイムStrictest Requirement: 固い範囲: 流れのExample Application単位で: 医療のモニター--一生懸命
Synchronicity
共時性
To make sure that separate elements of a session are correctly
synchronized with respect to each other
セッションの別々の要素が互いに関して正しく同期するのを確実にするために
Type: Time
Meaning: The maximum time drift between streams
Strictest Requirement: 80ms for human perception
Scope: per stream pair/set
Example Application: TV lip-sync value 80ms
NB: the scope is not necessarily the same as
the session. Some streams may no need to be
sync'd, (say, a score ticker in a football
match
以下をタイプしてください。 時間意味: 流れのStrictest Requirementの間の最大の時間ドリフト: 人間の知覚Scopeのための80ms: 流れに従って、Example Applicationを対にするか、または設定してください: テレビの口パク価値の80msネブラスカ: 範囲は必ずセッションと同じであるというわけではありません。 いくつかの流れはそうするかもしれません。同時性であるどんな必要性もそうしないだろう、(たとえば、フットボールの試合のスコアチッカー
Burstiness
Burstiness
This is a measure of the variance of bandwidth requirements over
time.
時間がたつにつれて、これは帯域幅要件の変化の基準です。
Type: Fraction
Meaning: either:
Variation in b/w as fraction of b/w for
variable b/w communications
or
duty cycle (fraction of time at peak b/w)
for intermittent b/w communications.
Strictest Requirement: Variation = max b/w Duty cycle ~ 0
Scope: per stream
Example Application: Sharing video clips, with chat channel -
sudden bursts as clips are swapped.
Compressed Audio - difference between
silence and talking
NB: More detailed analysis of communication
flow (e.g. max rate of b/w change or
以下をタイプしてください。 断片意味: どちらか: 可変b/wコミュニケーションかデューティサイクルのためのb/wの部分としてのb/wの変化、(断片、間欠b/wコミュニケーションのためのピークb/w)の時間について。 最も厳しい要件: 変化は最大b/w Dutyサイクル~0Scopeと等しいです: 流れのExample Application単位で: --相談窓口とビデオクリップを共有して、クリップとしての突然の炸裂は交換されます。 圧縮されたAudio--、沈黙とネブラスカについて話すところの違い: または以上がコミュニケーション流動の分析を詳しく述べた、(例えば、b/w変化の率に最大限にしてください。
Bagnall, et al. Informational [Page 10] RFC 2729 Taxonomy of Communication Requirements December 1999
Bagnall、他 コミュニケーション要件1999年12月の情報[10ページ]のRFC2729分類学
Fourier Transform of the b/w requirement) is
possible but as complexity increases
usefulness and computability decrease.
b/w要件のフーリエ変換)、可能ですが有用性と計算可能性が静まらせる複雑さ増加として
Jitter
ジター
Jitter is a measure of variance in the time taken for
communications to traverse from the sender (application) to the
receiver, as seen from the application layer.
送付者(アプリケーション)から受信機まで横断するコミュニケーションにかかる時間、ジターは変化の基準です、応用層から見られるように。
Type: Time
Meaning: Maximum permissible time variance
Strictest Requirement: <1ms
Scope: per stream
Example Application: audio streaming - <1ms
NB: A jitter requirement implies that the
communication is a real-time stream. It
makes relatively little sense for a file
transfer for example.
以下をタイプしてください。 時間意味: 最大の許されている時間変化のStrictest Requirement: <1ms範囲: 流れのExample Application単位で: オーディオストリーミング--<1msネブラスカ: ジター要件は、コミュニケーションがリアルタイムの流れであることを含意します。 それは例えば、ファイル転送のために比較的小さい意味になります。
Expiry
満期
This specifies how long the information
being transferred remains valid for.
これは、移される情報がどれくらい長い間有効なままで残っているかを指定します。
Type: Date
Meaning: Date at which data expires
Strictest Requirement: For ever
Scope: per stream
Example Application: key distribution - now+3600 seconds (valid
for at least one hour)
以下をタイプしてください。 意味の日付を入れてください: どのデータがStrictest Requirementを吐き出すかでデートしてください: いつまでも、Scope: 流れのExample Application単位で: 主要な分配--現在+3600秒(有効少なくとも1時間)です。
Latency
潜在
Time between initiation and occurrence of
an action from application perspective.
アプリケーション見解からの動作の開始と発生の間の時間。
Type: Time
Strictest Requirement: Near zero for process control apps
Scope: per stream
Example Application: Audio conference 20ms
NB: Where an action consists of several
distinct sequential parts the latency
budget must be split over those parts. For
process control the requirement may take
any value.
以下をタイプしてください。 時間の最も厳しい要件: 工程管理アプリケーションScopeのための近いゼロ: 流れのExample Application単位で: オーディオ会議20msネブラスカ: 動作が数個の異なった連続した部品から成るところでは、それらの部品の上で潜在予算を分けなければなりません。 工程管理のために、要件はどんな値も取るかもしれません。
Bagnall, et al. Informational [Page 11] RFC 2729 Taxonomy of Communication Requirements December 1999
Bagnall、他 コミュニケーション要件1999年12月の情報[11ページ]のRFC2729分類学
Optimum Bandwidth
最適な帯域幅
Bandwidth required to complete communication in time
帯域幅が時間内にコミュニケーションを完成するのが必要です。
Type: Bandwidth
Strictest Requirement: No upper limit
Scope: per stream
Example Application: Internet Phone 8kb/s
以下をタイプしてください。 帯域幅の最も厳しい要件: 上限がないScope: 流れのExample Application単位で: インターネット電話8kb/s
Tolerable Bandwidth
許容できる帯域幅
Minimum bandwidth that application can tolerate
アプリケーションが許容できる最小の帯域幅
Type: Bandwidth
Strictest Requirement: No upper limit
Scope: per stream
Example Application: Internet phone 4kb/s
以下をタイプしてください。 帯域幅の最も厳しい要件: 上限がないScope: 流れのExample Application単位で: インターネット電話4kb/s
Required by time and tolerance
時間と寛容が必要です。
Time communication should complete by and time when failure to
complete renders communication useless (therefore abort).
コミュニケーションが完成するべきである時、完成する失敗がコミュニケーションを役に立たなく表す(したがって、中止になってください)時。
Type: {
Date - preferred complete time,
Date - essential complete time
}
Strictest Requirement: Both now.
Scope: per stream
Example Application: Email - Preferred 5 minutes & Essential in
1 day
NB: Bandwidth * Duration = Size; only two of
these parameters may be specified. An API
though could allow application authors to
think in terms of any two.
以下をタイプしてください。 日付--都合のよい完全な時間、Date--不可欠の完全な時間の最も厳しいRequirement: ともに、さあ。 範囲: 流れのExample Application単位で: メール--5数分とEssentialは1日のネブラスカで好みました: 帯域幅*持続時間はサイズと等しいです。 これらの2つのパラメタだけを指定してもよいです。 API、もっとも、アプリケーション作者がどんな2に関しても考えるのを許容できました。
Host performance
ホスト性能
Ability of host to create/consume communication
ホストがコミュニケーションを作成するか、または消費する能力
Type: Application benchmark
Meaning: Level of resources required by Application
Strictest Requirement: Full consumption
Scope: per stream
Example Application: Video - consume 15 frames a second
NB: Host performance is complex since load,
media type, media quality, h/w assistance,
and encoding scheme all affect the
以下をタイプしてください。 アプリケーションベンチマークMeaning: リソースのレベルがApplication Strictest Requirementが必要です: 完全な消費Scope: 流れのExample Application単位で: ビデオ--1秒あたり15個のフレームにネブラスカを消費してください: ホスト性能は、負荷以来の複合体と、メディアタイプと、メディア品質と、h/w支援と、すべてが影響する計画をコード化することです。
Bagnall, et al. Informational [Page 12] RFC 2729 Taxonomy of Communication Requirements December 1999
Bagnall、他 コミュニケーション要件1999年12月の情報[12ページ]のRFC2729分類学
processing load. These are difficult to
predict prior to a communication starting.
To some extent these will need to be
measured and modified as the communication
proceeds.
負荷を処理します。 これらはコミュニケーション始めの前に予測するのが難しいです。 ある程度これらは、コミュニケーションが続くので、測定されて、変更される必要があるでしょう。
Frame size
フレーム・サイズ
Size of logical data packets from application perspective
アプリケーション見解からの論理的なデータ・パケットのサイズ
Type: data size
Strictest Requirement: 6 bytes (gaming)
Scope: per stream
Example Application: video = data size of single frame update
以下をタイプしてください。 データサイズStrictest Requirement: 6バイト(勝負事をする)の範囲: 流れのExample Application単位で: シングルフレームアップデートのビデオ=データサイズ
Content size
満足しているサイズ
The total size of the content (not relevant for continuous media)
内容の総サイズ(連続したメディアにおいて関連しない)です。
Type: data size
Strictest Requirement: N/A
Scope: per stream
Example Application: document transfer, 4kbytes
以下をタイプしてください。 データサイズStrictest Requirement: なし、範囲: 流れのExample Application単位で: ドキュメント転送、4キロバイト
3.2.5. Session Control
3.2.5. セッション制御
Initiation
開始
Which initiation mechanism will be used.
どの開始メカニズムが使用されるでしょうか?
Type: Enumeration
Meaning: Announcement - session is publicly
announced via a mass distribution
system
Invitation - specific participants are
explicitly invited, e.g. my email
Directive - specific participants are
forced to join the session
Strictest Requirement: Directive
Scope: per stream
Example Application: Corporate s/w update - Directive
以下をタイプしてください。 列挙意味: 発表--セッションは大量流通システムInvitationを通して公的に発表されます--特定の関係者は明らかに招待されます、例えば、私のメールDirective--特定の関係者はやむを得ずセッションStrictest Requirementを接合します: 指向性の範囲: ストリームExample Application単位で: 法人のs/wアップデート--指示
Bagnall, et al. Informational [Page 13] RFC 2729 Taxonomy of Communication Requirements December 1999
Bagnall、他 コミュニケーション要件1999年12月の情報[13ページ]のRFC2729分類学
Start Time
開始時刻
Time sender starts sending!
時間送付者は発信し始めます!
Type: Date
Strictest Requirement: Now
Scope: per stream
Example Application: FTP - at 3am
以下をタイプしてください。 最も厳しい要件の日付を入れてください: 現在の範囲: ストリームExample Application単位で: FTP--午前3時に
End Time
終わりの時間
Type: Date
Strictest Requirement: Now
Scope: per stream
Example Application: FTP - Now+30mins
以下をタイプしてください。 最も厳しい要件の日付を入れてください: 現在の範囲: ストリームExample Application単位で: FTP--+ 現在の30mins
Duration
持続時間
(end time) - (start time) = (duration), therefore only two of
three should be specified.
(終わりの時間)--(開始時刻)は(持続時間)と等しく、したがって、3時2分唯一の前が指定されるべきです。
Type: Time
Strictest Requirement: - 0ms for discrete, indefinite for streams
Scope: per stream
Example Application: audio feed - 60mins
以下をタイプしてください。 時間の最も厳しい要件: - 0ms、ストリームScopeにおける離散的であるのと、無期: ストリームExample Application単位で: オーディオ給送--60mins
Active Time
アクティブな時間
Total time session is active, not including breaks
合計時セッションは中断を含んでいるのではなく、活発です。
Type: Time
Strictest Requirement: equals duration
Scope: per stream
Example Application: Spectator sport transmission
以下をタイプしてください。 時間の最も厳しい要件: 同輩持続時間Scope: ストリームExample Application単位で: 見るスポーツ送信
Session Burstiness
セッションBurstiness
Expected level of burstiness of the session
セッションのburstinessの予想水準
Type: Fraction
Meaning: Variance as a fraction of maximum bandwidth
Strictest Requirement: =bandwidth
Scope: per stream
Example Application: commentary & slide show: 90% of max
以下をタイプしてください。 断片意味: 最大の帯域幅Strictest Requirementの部分としての変化: =帯域幅Scope: ストリームExample Application単位で: 論評とスライドショー: 90%の最大
Bagnall, et al. Informational [Page 14] RFC 2729 Taxonomy of Communication Requirements December 1999
Bagnall、他 コミュニケーション要件1999年12月の情報[14ページ]のRFC2729分類学
Atomic join
原子、接合
Session fails unless a certain proportion of the potential
participants accept an invitation to join. Alternatively, may be
specified as a specific numeric quorum.
潜在的関係者のあるプロポーションが接合する招待状に応じないなら、セッションは失敗します。 あるいはまた、特定の数値定足数として指定されるかもしれません。
Type: Fraction (proportion required) or int
(quorum)
Strictest Requirement: 1.0 (proportion)
Example Application: price list update, committee meeting
Scope: per stream or session
NB: whether certain participants are essential
is application dependent.
以下をタイプしてください。 断片(割合が必要である)かint(定足数)の最も厳しいRequirement: 1.0 (割合)例のアプリケーション: 委員会のミーティングScope、リスト最新版に値を付けてください: ストリームかセッションネブラスカ単位で: 確信している関係者が不可欠であるかどうかが、アプリケーションに依存しています。
Late join allowed ?
遅く、許容されていた状態で接合しますか?
Does joining a session after it starts make sense
始まった後にセッションに参加するのは理解できますか?
Type: Boolean
Strictest Requirement: allowed
Scope: per stream or session
Example Application: game - not allowed
NB: An application may wish to define an
alternate session if late join is not
allowed
以下をタイプしてください。 ブール最も厳しい要件: Scopeは許容しました: ストリームかセッションExample Application単位で: ゲーム--ネブラスカは許容しませんでした: アプリケーションが、遅れているなら代替のセッションを定義するために、接合するように願うかもしれない、許容されていません。
Temporary leave allowed ?
許容された一時的な休暇?
Does leaving and then coming back make sense for session
いなくなって、次に、セッションのために理解できに来て戻って
Type: Boolean
Strictest Requirement: allowed
Scope: per stream or session
Example Application: FTP - not allowed
以下をタイプしてください。 ブール最も厳しい要件: Scopeは許容しました: ストリームかセッションExample Application単位で: FTP--許容されていません。
Late join with catch-up allowed ?
遅く、許容されているケチャップに接合しますか?
Is there a mechanism for a late joiner to see what they've missed
故joinerがそれらが逃したものを見るように、メカニズムはありますか?
Type: Boolean
Strictest Requirement: allowed
Scope: per stream or session
Example Application: sports event broadcast, allowed
NB: An application may wish to define an
alternate session if late join is not
allowed
以下をタイプしてください。 ブール最も厳しい要件: Scopeは許容しました: ストリームかセッションExample Application単位で: ネブラスカはスポーツ大会を放送させました: アプリケーションが、遅れているなら代替のセッションを定義するために、接合するように願うかもしれない、許容されていません。
Bagnall, et al. Informational [Page 15] RFC 2729 Taxonomy of Communication Requirements December 1999
Bagnall、他 コミュニケーション要件1999年12月の情報[15ページ]のRFC2729分類学
Potential streams per session
1セッションあたりの潜在的ストリーム
Total number of streams that are part of session, whether being
consumed or not
消費されるか否かに関係なく、セッションの一部である総数のストリーム
Type: Integer
Strictest Requirement: No upper limit
Scope: per session
Example Application: football match mcast - multiple camera's,
commentary, 15 streams
以下をタイプしてください。 整数の最も厳しい要件: 上限がないScope: セッションExample Application単位で: フットボールの試合mcast--複数のカメラ、論評、15ストリーム
Active streams per sessions (i.e. max app can handle)
1セッションあたりのアクティブなストリーム(すなわち、最大装置が扱うことができる)
Maximum number of streams that an application can consume
simultaneously
アプリケーションが同時に消費できる最大数のストリーム
Type: Integer
Strictest Requirement: No upper limit
Scope: per session
Example Application: football match mcast - 6, one main video,
four user selected, one audio commentary
以下をタイプしてください。 整数の最も厳しい要件: 上限がないScope: セッションExample Application単位で: フットボールの試合mcast--6、1個のメインビデオ、選ばれた4ユーザ、1つのオーディオ論評
3.2.6. Session Topology
3.2.6. セッショントポロジー
Note: topology may be dynamic. One of the challenges in designing adaptive protocol frameworks is to predict the topology before the first join.
以下に注意してください。 トポロジーはダイナミックであるかもしれません。 適応型のプロトコルフレームワークを設計することにおける挑戦の1つは1番目が接合する前にトポロジーを予測することです。
Number of senders
送付者の数
The number of senders is a result the middleware may pass up to
the application
送付者の数はミドルウェアがアプリケーションに無視するかもしれない結果です。
Type: Integer
Strictest Requirement: No upper limit
Scope: per stream
Example Application: network MUD - 100
以下をタイプしてください。 整数の最も厳しい要件: 上限がないScope: ストリームExample Application単位で: ネットワークMUD--100
Number of receivers
受信機の数
The number of receivers is a results the middleware may pass up to
the application
受信機の数はミドルウェアがアプリケーションに無視するかもしれない結果です。
Type: Integer
Strictest Requirement: No upper limit
Scope: per stream
Example Application: video mcast - 100,000
以下をタイプしてください。 整数の最も厳しい要件: 上限がないScope: ストリームExample Application単位で: ビデオmcast--10万
Bagnall, et al. Informational [Page 16] RFC 2729 Taxonomy of Communication Requirements December 1999
Bagnall、他 コミュニケーション要件1999年12月の情報[16ページ]のRFC2729分類学
3.2.7. Directory
3.2.7. ディレクトリ
Fail-over timeout (see Reliability: fail-over time)
フェイルオーバータイムアウト(Reliability:フェイルオーバー時間に遭遇します)
Mobility
移動性
Defines restrictions on when directory entries may be changed
ディレクトリエントリーが変えられるかもしれない時に関する制限を定義します。
Type: Enumeration
Meaning: while entry is in use
while entry in unused
never
Strictest Requirement: while entry is in use
Scope: per stream
Example Application: voice over mobile phone, while entry is in
use (as phone gets new address when
changing cell).
以下をタイプしてください。 列挙意味: エントリーである間、使用が未使用でエントリーをゆったり過ごすコネは決してStrictest Requirementではありません: 中にエントリーがある間、Scopeを使用してください: ストリームExample Application単位で: エントリーが使用中である間の(セルを変えるとき、電話が新しいアドレスを得るので)モバイル電話の上の声。
3.2.8. Security
3.2.8. セキュリティ
The strength of any security arrangement can be stated as the expected cost of mounting a successful attack. This allows mechanisms such as physical isolation to be considered alongside encryption mechanisms. The cost is measured in an abstract currency, such as 1970 UD$ (to inflation proof).
うまくいっている攻撃を仕掛ける期待原価としてどんなセキュリティアレンジメントの強さも述べることができます。 これは、物理的な分離などのメカニズムが暗号化メカニズムと並んで考えられるのを許容します。費用は抽象的な通貨で測定されます、1970UDドル(インフレーション証拠への)などのように。
Security is an orthogonal requirement. Many requirements can have a security requirement on them which mandates that the cost of causing the system to fail to meet that requirement is more than the specified amount. In terms of impact on other requirements though, security does potentially have a large impact so when a system is trying to determine which mechanisms to use and whether the requirements can be met security will clearly be a major influence.
セキュリティは直交した要件です。 多くの要件がシステムがその必要条件を満たさないことを引き起こす費用が一定金額以上であることを強制するそれらに関するセキュリティ要件を持つことができます。 もっとも、他の要件に関する影響に関して、セキュリティに大きい影響力が潜在的にあるので、システムが、いつどのメカニズムを使用したらよいかを決定しようとしているか、そして、要件が会われたセキュリティであるかもしれないかどうかが明確に主要な影響になるでしょう。
Authentication Strength
認証の強さ
Authentication aims to ensure that a principal is who they claim
to be. For each role in a communication, (e.g. sender, receiver)
there is a strength for the authentication of the principle who
has taken on that role. The principal could be a person,
organization or other legal entity. It could not be a process
since a process has no legal representation.
認証は、元本が彼らが、だれを主張するかということであることを保証することを目指します。 その役割で取って、コミュニケーションにおける各役割、そこの(例えば、送付者、受信機)が原則の認証のためのそうした力であるので。 主体は、人、組織または他の法人であるかもしれません。 プロセスにはどんな法的な表現もないので、それはプロセスであることができませんでした。
Type: Abstract Currency
Meaning: That the cost of hijacking a role is in
excess of the specified amount. Each role
is a different requirement.
以下をタイプしてください。 抽象的な通貨意味: 役割をハイジャックする費用は一定金額を超えています。 各役割は異なった要件です。
Bagnall, et al. Informational [Page 17] RFC 2729 Taxonomy of Communication Requirements December 1999
Bagnall、他 コミュニケーション要件1999年12月の情報[17ページ]のRFC2729分類学
Strictest Requirement: budget of largest attacker
Scope: per stream
Example Application: inter-governmental conference
最も厳しい要件: 最も大きい攻撃者Scopeの予算: ストリームExample Application単位で: 政府間協議
Tamper-proofing
タンパーを検査しています。
This allows the application to specify how much security will be
applied to ensuring that a communication is not tampered with.
This is specified as the minimum cost of successfully tampering
with the communication. Each non-security requirement has a
tamper-proofing requirement attached to it.
これで、アプリケーションは、コミュニケーションがいじられないのを確実にするのにどのくらいのセキュリティが適用されるかを指定できます。 これは首尾よくコミュニケーションをいじる最低費用として指定されます。 それぞれの非セキュリティ要件で、タンパーを検査する要件をそれに添付します。
Requirement: The cost of tampering with the communication is in
excess of the specified amount.
要件: コミュニケーションをいじる費用は一定金額を超えています。
Type: {
Abstract Currency,
Abstract Currency,
Abstract Currency
}
Meaning: cost to alter or destroy data,
cost to replay data (successfully),
cost to interfere with timeliness.
Scope: per stream
Strictest Requirement: Each budget of largest attacker
Example Application: stock price feed
以下をタイプしてください。 意味して、通貨を抜き取ってください、そして、通貨を抜き取ってください、そして、通貨を抜き取ってください: データ、データ(首尾よい)、タイムリーさであるのを妨げる費用を再演する費用を変更するか、または破壊するために、かかります。 範囲: ストリームStrictest Requirement単位で: 最も大きい攻撃者Example Applicationの各予算: 株価給送
Non-repudiation strength
非拒否の強さ
The non-repudiation strength defines how much care is taken to
make sure there is a reliable audit trail on all interactions. It
is measured as the cost of faking an audit trail, and therefore
being able to "prove" an untrue event. There are a number of
possible parameters of the event that need to be proved. The
following list is not exclusive but shows the typical set of
requirements.
非拒否の強さは、どのくらいの注意が信頼できる監査証跡がすべての相互作用にあるのを確実にするために払われるかを定義します。 それは監査証跡を見せかけて、したがって、虚偽のイベントの「立証」であることができる費用として測定されます。 立証される必要があるイベントの多くの可能なパラメタがあります。 以下のリストは、排他的ではありませんが、典型的なセットの要件を示しています。
1. Time 2. Ordering (when relative to other events) 3. Whom 4.
What (the event itself)
1. 時間2。 3を命令します(他のイベントに比例して)。 だれ、4 何(イベント自体)
There are a number of events that need to be provable. 1. sender
proved sent 2. receiver proves received 3. sender proves received.
証明可能である必要がある多くのイベントがあります。 1. 送付者は、送られた2受信機が、容認された3送付者が、受け取られていると判明すると立証すると立証しました。
Type: Abstract Currency
Meaning: minimum cost of faking or denying an event
Strictest Requirement: Budget of largest attacker
Scope: per stream
Example Application: Online shopping system
以下をタイプしてください。 抽象的な通貨意味: イベントStrictest Requirementを見せかけるか、または否定する最低費用: 最も大きい攻撃者Scopeの予算: ストリームExample Application単位で: オンラインショッピングシステム
Bagnall, et al. Informational [Page 18] RFC 2729 Taxonomy of Communication Requirements December 1999
Bagnall、他 コミュニケーション要件1999年12月の情報[18ページ]のRFC2729分類学
Denial of service
サービスの否定
There may be a requirement for some systems (999,911,112 emergency
services access for example) that denial of service attacks cannot
be launched. While this is difficult (maybe impossible) in many
systems at the moment it is still a requirement, just one that
can't be met.
いくつかのシステム(例えば、9億9991万1112緊急サービスアクセス)のためのサービス不能攻撃に着手できないという要件があるかもしれません。 これは多くのシステムで難しいのですが(多分不可能な)、現在、それはそれでも、要件、ただ会うことができないものです。
Type: Abstract Currency
Meaning: Cost of launching a denial of service
attack is greater than specified amount.
Strictest Requirement: budget of largest attacker
Scope: per stream
Example Application: web hosting, to prevent individual hackers
stalling system.
以下をタイプしてください。 抽象的な通貨意味: サービス不能攻撃に着手する費用は一定金額より大きいです。 最も厳しい要件: 最も大きい攻撃者Scopeの予算: ストリームExample Application単位で: 個々のハッカーがシステムを失速させるのを防ぐために接待するウェブ。
Action restriction
動作制限
For any given communication there are a two actions, send and
receive. Operations like adding to members to a group are done as
a send to the membership list. Examining the list is a request to
and receive from the list. Other actions can be generalized to
send and receive on some communication, or are application level
not comms level issues.
いずれも2つの動作をあるコミュニケーションに与えて、発信して、受信されるので。 aとしてグループをするとaのメンバーに言い足すような操作は会員名簿に発信します。 そして、リストを調べるのが、要求である、リストから、受信してください。 他の動作は、何らかのコミュニケーションで発信して、受信するために一般化できるか、またはcommsレベルではなく、レベルが支給するアプリケーションです。
Type: Membership list/rule for each action.
Meaning: predicate for determining permission for
role
Strictest Requirement: Send and receive have different policies.
Scope: per stream
Example Application: TV broadcast, sender policy defines
transmitter, receiver policy is null.
NB: Several actions may share the same
membership policy.
以下をタイプしてください。 各動作のための会員名簿/規則。 意味: 役割のStrictest Requirementのために許可を決定するための述部: 発信してください、そして、受信してください。異なった方針を持ってください。 範囲: ストリームExample Application単位で: テレビは放送されて、送付者方針は送信機を定義して、受信機方針はヌルです。 ネブラスカ: いくつかの動作が同じ会員資格方針を共有するかもしれません。
Privacy
プライバシー
Privacy defines how well obscured a principals identity is. This
could be for any interaction. A list of participants may be
obscured, a sender may obscure their identity when they send.
There are also different types of privacy. For example knowing two
messages were sent by the same person breaks the strongest type of
privacy even if the identity of that sender is still unknown. For
each "level" of privacy there is a cost associated with violating
it. The requirement is that this cost is excessive for the
attacker.
プライバシーは、あいまいにされて、主体のアイデンティティがどれくらいよくそうであるかを定義します。 これはどんな相互作用のためのものであるかもしれません。 関係者のリストは見えなくされるかもしれなくて、彼らが発信するとき、送付者は彼らのアイデンティティをあいまいにするかもしれません。 また、プライバシーの異なったタイプがあります。 その送付者のアイデンティティがまだ未知であっても、例えば、2つのメッセージが同じ人によって送られたのを知っているのが最も強いタイプのプライバシーを壊します。 それぞれの「レベル」のプライバシーのために、それに違反すると関連している費用があります。 要件は攻撃者にとって、この費用が過度であるということです。
Bagnall, et al. Informational [Page 19] RFC 2729 Taxonomy of Communication Requirements December 1999
Bagnall、他 コミュニケーション要件1999年12月の情報[19ページ]のRFC2729分類学
Type: {
Abstract Currency,
Abstract Currency,
Abstract Currency,
Abstract Currency
}
Meaning: Level of privacy, expected cost to violate
privacy level for:-
openly identified - this is the unprotected
case
anonymously identified - (messages from
the same sender can be linked)
unadvertised (but traceable) - meaning that
traffic can be detected and traced to
it's source or destination, this is a
breach if the very fact that two
specific principals are communicating
is sensitive.
undetectable
Strictest Requirement: All levels budget of attacker
Scope: per stream
Example Application: Secret ballot voting system
openly identified - budget of any
interested party
anonymously identified - zero
unadvertised - zero
undetectable - zero
以下をタイプしてください。 抽象的な通貨、抽象的な通貨、抽象的な通貨、抽象的な通貨は以下を意味します。 プライバシーのレベル、特定されて、以下のために-オープンにプライバシーレベルに違反するこれが匿名で特定された保護のないそうであるという「非-広告を出」していて(起因する)の期待している費用(同じ送付者からのメッセージをリンクできる)--トラフィックをそれに検出して、たどることができることを意味するのが、ソースか目的地である、2つの特定の主体が交信しているというまさしくその事実が機密であるならこれが不履行である、検知されないStrictest Requirement: すべてが攻撃者Scopeの予算を平らにします: ストリームExample Application単位で: オープンに特定された無記名投票投票制度--匿名で特定されたどんな利害関係者の予算も--「非-広告を出」される--検知されなくない--のゼロがありません。
Confidentiality
秘密性
Confidentiality defines how well protected the content of a
communication is from snooping.
秘密性は、保護されて、コミュニケーションの内容が詮索からどれくらいよく来ているかを定義します。
Type: Abstract Currency
Meaning: Level of Confidentiality, the cost of
gaining illicit access to the content of a
stream
Strictest Requirement: budget of attacker
Scope: per stream
Example Application: Secure email - value of transmitted
information
以下をタイプしてください。 抽象的な通貨意味: Confidentialityのレベル、ストリームStrictest Requirementの内容への不法なアクセスを得る費用: 攻撃者Scopeの予算: ストリームExample Application単位で: 安全なメール--伝達情報量の値
Retransmit prevention strength
防止の強さを再送してください。
This is extremely hard at the moment. This is not to say it's not
a requirement.
これは現在、非常に困難です。 これは、それが要件でないと言わないためのものです。
Bagnall, et al. Informational [Page 20] RFC 2729 Taxonomy of Communication Requirements December 1999
Bagnall、他 コミュニケーション要件1999年12月の情報[20ページ]のRFC2729分類学
Type: Abstract Currency
Meaning: The cost of retransmitting a secure piece
of information should exceed the specified
amount.
Strictest Requirement: Cost of retransmitting value of
information
Scope: per stream
以下をタイプしてください。 抽象的な通貨意味: 安全な情報を再送する費用は一定金額を超えるべきです。 最も厳しい要件: 情報価値Scopeを再送する費用: ストリーム単位で
Membership Criteria
加盟基準
If a principal attempts to participate in a communication then a
check will be made to see if it is allowed to do so. The
requirement is that certain principals will be allowed, and others
excluded. Given the application is being protected from network
details there are only two types of specification available, per
user, and per organization (where an organization may contain
other organizations, and each user may be a member of multiple
organizations). Rules could however be built on properties of a
user, for example does the user own a key? Host properties could
also be used, so users on slow hosts or hosts running the wrong OS
could be excluded.
元本が、コミュニケーションに参加するのを試みると、それがそうすることができるかどうかを見るのをチェックをするでしょう。 要件は主体が許容されるのをそんなに確信していて、他のものは除かれます。 考えて、アプリケーションはユーザ、および組織あたり利用可能な仕様(組織が他の組織を含むかもしれなくて、各ユーザが複数の組織のメンバーであるかもしれないところ)の2つのタイプしかないというネットワークの詳細から保護されています。 しかしながら、ユーザの所有地の上で規則を築き上げることができました、例えば、ユーザはキーを所有していますか? また、ホストの特性を使用できたので、間違ったOSを実行する遅いホストかホストの上のユーザを除くことができました。
Type: Macros
Meaning: Include or exclude
users (list)
organizations (list)
hosts (list)
user properties (rule)
org properties (rule)
hosts properties (rule)
Strictest Requirement: List of individual users
Scope: per stream
Example Application: Corporate video-conference - organization
membership
以下をタイプしてください。 マクロ意味: ユーザ(リスト)の組織の(リスト)ホスト(リスト)のユーザの特性(統治する)のorgの特性(統治する)のホストの特性(規則)の最も厳しいRequirementを含んでいるか、または除いてください: 個々のユーザScopeのリスト: ストリームExample Application単位で: 法人のテレビ会議--組織会員資格
Collusion prevention
共謀防止
Which aspects of collusion it is required to prevent. Collusion is
defined as malicious co-operation between members of a secure
session. Superficially, it would appear that collusion is not a
relevant threat in a multicast, because everyone has the same
information, however, wherever there is differentiation, it can be
exploited.
それが、防ぐのに共謀のどの局面に必要ですか? 共謀は安全なセッションのメンバーの間の悪意がある協力と定義されます。 表面的に、共謀がマルチキャストで関連脅威でないように見えるでしょう、しかしながら、どこで分化があり、それを利用できても皆には同じ情報があるので。
Type: {
Abstract Currency,
Abstract Currency,
Abstract Currency
以下をタイプしてください。 抽象的な通貨、抽象的な通貨、抽象的な通貨
Bagnall, et al. Informational [Page 21] RFC 2729 Taxonomy of Communication Requirements December 1999
Bagnall、他 コミュニケーション要件1999年12月の情報[21ページ]のRFC2729分類学
}
Meaning: time race collusion - cost of colluding
key encryption key (KEK) sharing - cost of
colluding
sharing of differential QoS (not strictly
collusion as across sessions not within
one) - cost of colluding
Strictest Requirement: For all threats cost attackers
combined resources
Scope: per stream
Example Application: A race where delay of the start signal may
be allowed for, but one participant may
fake packet delay while receiving the start
signal from another participant.
NB: Time race collusion is the most difficult
one to prevent. Also note that while these
may be requirements for some systems this
does not mean there are necessarily
solutions. Setting tough requirements may
result in the middleware being unable to
create a valid channel.
} 意味: タイム・レース共謀--馴れ合っている主要な暗号化キー(KEK)共有の費用--特異なQoSを共有しながら馴れ合う費用、(厳密でない、1の中のセッションのような共謀) --馴れ合うStrictest Requirementの費用: すべての脅威のために、費用攻撃者はリソースScopeを結合しました: ストリームExample Application単位で: スタート信号の遅れが考慮されるかもしれませんが、1人の関係者が別の関係者からスタート信号を受け取っている間にパケット遅れを見せかけるかもしれないレース。 ネブラスカ: タイム・レース共謀は防ぐ中で最も難しい1つです。 また、これらがいくつかのシステムのための要件であるかもしれませんが、これが、必ずソリューションがあることを意味しないことに注意してください。 厳しい要件を設定すると、有効なチャンネルを創造できないミドルウェアはもたらされるかもしれません。
Fairness
公正
Fairness is a meta-requirement of many other requirements. Of
particular interest are Reliability and Timeliness requirements.
When a communication is first created the creator may wish to
specify a set of requirements for these parameters. Principals
which join later may wish to set tighter limits. Fairness enforces
a policy that any improvement is requirement by one principal must
be matched by all others, in effect requirements can only be set
for the whole group. This increases the likelihood that
requirements of this kind will fail to be met. If fairness if not
an issue then some parts of the network can use more friendly
methods to achieve those simpler requirements.
公正は他の多くの要件のメタ要件です。 特別の関心は、ReliabilityとTimeliness要件です。 コミュニケーションが最初に作成されるとき、クリエイターはこれらのパラメタのための1セットの要件を指定したがっているかもしれません。 後で接合する校長は、よりきつい限界を設定したがっているかもしれません。 公正は政策を実行します。すべての他のものがどんな改良も1つの主体による要件であるのに匹敵しなければなりません、事実上、全体のグループに要件は設定できるだけです。 これはこの種類の要件が会われない可能性を広げます。 公正か問題であるなら、ネットワークのいくつかの部分がそれらのより簡単な要件を達成するより好意的なメソッドを使用できます。
Type: Level of variance of the requirement that
needs to be fair. For example, if the
latency requirement states within 2
seconds, the level of fairness required may
be that variations in latency are not more
than 0.1s. This has in fact become an issue
in online gaming (e.g. Quake)
Meaning: The variance of performance with respect to
any other requirement is less than the
specified amount.
Scope: per stream, per requirement
以下をタイプしてください。 公正である必要がある要件の変化のレベル。 例えば、2秒以内の潜在要件州、公正のレベルが必要であるなら、潜在の変化が0.1以上でないということであるかもしれません。 事実上、これはオンラインゲーム(例えば、Quake)意味における問題になりました: いかなる他の要件に関する性能の変化も一定金額以下です。 範囲: 1要件あたりのストリーム単位で
Bagnall, et al. Informational [Page 22] RFC 2729 Taxonomy of Communication Requirements December 1999
Bagnall、他 コミュニケーション要件1999年12月の情報[22ページ]のRFC2729分類学
Example Application: Networked game, latency to receive
positions of players must be within 5ms for
all players.
例のアプリケーション: ネットワークでつながれて、勝負事をしてください、そして、すべてのプレーヤーのための5msの中にプレーヤーの位置を取る潜在があるに違いありません。
Action on compromise
感染への動作
The action to take on detection of compromise (until security
reassured).
検出のときに取る行動は妥協します(セキュリティが再保証するまで)。
Type: Enumeration
Meaning: warn but continue
pause
abort
Scope: Per stream
Strictest Requirement: pause
Example Application: Secure video conference - if intruder
alert, everyone is warned, but they can
continue while knowing not to discuss
sensitive matters (cf. catering staff
during a meeting).
以下をタイプしてください。 列挙意味: 警告しますが、くぎりのアボートScopeは続けています: ストリームStrictest Requirement単位で: Example Applicationをポーズしてください: 侵入者警戒、皆が注意されますが、敏感な件(Cfミーティングの間の宴会係)について議論しないのを知っている間彼らが続くことができるなら、テレビ会議システムを保証してください。
3.2.8.1. Security Dynamics
3.2.8.1. セキュリティ力学
Security dynamics are the temporal properties of the security
mechanisms that are deployed. They may affect other requirements
such as latency or simply be a reflection of the security
limitations of the system. The requirements are often concerned
with abnormal circumstances (e.g. system violation).
セキュリティ力学は配布されるセキュリティー対策の時の特性です。 それらは、潜在などの他の要件に影響するか、単にシステムのセキュリティ限界の反射であるかもしれません。 要件はしばしば異常事態(例えば、システム違反)に関係があります。
Mean time between compromises
感染の間の平均時
This is not the same as the strength of a system. A fairly weak
system may have a very long time between compromises because it is
not worth breaking in to, or it is only worth it for very few
people. Mean time between compromises is a combination of
strength, incentive and scale.
これはシステムの強さと同じではありません。 押し入る価値がないか、またはそれはそれの価値があるだけであるので、かなり弱いシステムはほんのわずかな人々に感染の間で非常に長い時間を過すかもしれません。 感染の間の平均時は強さ、誘因、およびスケールの組み合わせです。
Type: Time
Scope: Per stream
Strictest Requirement: indefinite
Example Application: Secure Shell - 1500hrs
以下をタイプしてください。 時間範囲: ストリームStrictest Requirement単位で: 無期Example Application: セキュア・シェル--1500時間
Compromise detection time limit
感染検出時間限界
The average time it must take to detect a compromise (one
predicted in the design of the detection system, that is).
感染(すなわち、検出システムの設計で予測されたもの)を検出するのに要しなければならない平均時間。
Bagnall, et al. Informational [Page 23] RFC 2729 Taxonomy of Communication Requirements December 1999
Bagnall、他 コミュニケーション要件1999年12月の情報[23ページ]のRFC2729分類学
Type: Time
Scope: Per stream
Strictest Requirement: Round trip time
Example Application: Secure Shell - 2secs
以下をタイプしてください。 時間範囲: ストリームStrictest Requirement単位で: 旅行時間Example Applicationを一周させてください: セキュア・シェル--2secs
Compromise recovery time limit
感染回復時間限界
The maximum time it must take to re-seal the security after a
breach. This combined with the compromise detection time limit
defines how long the system must remain inactive to avoid more
security breaches. For example if a compromise is detected in one
minute, and recovery takes five, then one minute of traffic is now
insecure and the members of the communication must remain silent
for four minutes after detection while security is re-established.
わざわざそれが不履行の後にセキュリティの再封をしなければならない最大の。 感染検出タイムリミットに結合されたこれは、システムがどれくらい長い間より多くの機密保護違反を避けるために不活発なままで残らなければならないかを定義します。 例えば、感染が1分後に検出されて、回復が5分間休憩するなら、1分のトラフィックは現在不安定です、そして、セキュリティは復職しますが、コミュニケーションのメンバーは検出の後の4分間静かなままでいなければなりません。
Type: Time
Scope: Per stream
Strictest Requirement: 1 second
Example Application: Audio conference - 10 seconds
以下をタイプしてください。 時間範囲: ストリームStrictest Requirement単位で: 1 第2Example Application: オーディオ会議--10秒
3.2.9. Payment & Charging
3.2.9. 支払いと充電
Total Cost
総費用
The total cost of communication must be limited to this amount.
This would be useful for transfer as opposed to stream type
applications.
コミュニケーションの総費用をこの量に制限しなければなりません。 これはストリーム型アプリケーションと対照的に転送の役に立つでしょう。
Type: Currency
Meaning: Maximum charge allowed
Scope: Per user per stream
Strictest Requirement: Free
Example Application: File Transfer: comms cost must be < 1p/Mb
以下をタイプしてください。 通貨意味: 最大の充電はScopeを許容しました: ストリームStrictest Requirementあたりのユーザ単位で: 例のアプリケーションを解放してください: ファイル転送: comms費用は<1p/Mbでなければなりません。
Cost per Time
1時間あたりの費用
This is the cost per unit time. Some
applications may not be able to predict the
duration of a communication. It may be more
meaningful for those to be able to specify
price per time instead.
Type: Currency per timeS
ユニット時間あたりこれは費用です。 いくつかのアプリケーションはコミュニケーションの持続時間を予測できないかもしれません。 それらが代わりに1時間あたりの価格を指定できるのは、より重要であるかもしれません。 以下をタイプしてください。 1回あたりの通貨
Scope: Per user per stream
Strictest Requirement: Free
Example Application: Video Conference - 15p / minute
範囲: ストリームStrictest Requirementあたりのユーザ単位で: 例のアプリケーションを解放してください: ビデオコンファレンス--15p/分
Bagnall, et al. Informational [Page 24] RFC 2729 Taxonomy of Communication Requirements December 1999
Bagnall、他 コミュニケーション要件1999年12月の情報[24ページ]のRFC2729分類学
Cost per Mb
1Mbあたりの費用
This is the cost per unit of data. Some communications may be
charged by the amount of data transferred. Some applications may
prefer to specify requirements in this way.
データのユニットあたりこれは費用です。 いくつかのコミュニケーションが移されたデータ量によって請求されるかもしれません。 いくつかのアプリケーションが、このように要件を指定するのを好むかもしれません。
Type: Currency per data size
Scope: Per user per stream
Strictest Requirement: Free
Example Application: Email advertising - 15p / Mb
以下をタイプしてください。 データサイズScopeあたりの通貨: ストリームStrictest Requirementあたりのユーザ単位で: 例のアプリケーションを解放してください: メール広告--15p/Mb
4. Security Considerations
4. セキュリティ問題
See comprehensive security section of taxonomy.
包括的安全保障部の分類学を見てください。
5. References
5. 参照
[Bagnall98] Bagnall Peter, Poppitt Alan, Example LSMA
classifications, BT Tech report,
<URL:http://www.labs.bt.com/projects/mware/>
[Bagnall98]Bagnallピーター、Poppittアラン、Example LSMA分類、BT Techレポート、<URL: http://www.labs.bt.com/projects/mware/ >。
[limitations] Pullen, M., Myjak, M. and C. Bouwens, "Limitations of
Internet Protocol Suite for Distributed Simulation in
the Large Multicast Environment", RFC 2502, February
1999.
[制限]ピューレン、M.、Myjak、M.、およびC.Bouwens、「インターネットの制限は大きいマルチキャスト環境における分配されたシミュレーションのためにスイートについて議定書の中で述べます」、RFC2502、1999年2月。
[rmodp] Open Distributed Processing Reference Model (RM-ODP),
ISO/IEC 10746-1 to 10746-4 or ITU-T (formerly CCITT)
X.901 to X.904. Jan 1995.
[rmodp] X.904への10746-4かITU-T(以前CCITT)X.901にISO/IEC10746-1の分散処理規範モデル(RM-ODP)を開いてください。 1995年1月。
[blaze95] Blaze, Diffie, Rivest, Schneier, Shimomura, Thompson
and Wiener, Minimal Key Lengths for Symmetric Ciphers
to Provide Adequate Commercial Security, January 1996.
[blaze95] 左右対称の暗号が適切な商業セキュリティ、1996年1月に提供する炎とディフィーとRivestとシュナイアーとShimomuraとトンプソンとウインナソーセージ、最小量のキー長。
Bagnall, et al. Informational [Page 25] RFC 2729 Taxonomy of Communication Requirements December 1999
Bagnall、他 コミュニケーション要件1999年12月の情報[25ページ]のRFC2729分類学
6. Authors' Addresses
6. 作者のアドレス
Peter Bagnall c/o B54/77 BT Labs Martlesham Heath Ipswich, IP5 3RE England
ピーターBagnall気付B54/77BT研究室Martlesham Heath IP5 3REイプスウィッチ(イギリス)
EMail: pete@surfaceeffect.com Home page: http://www.surfaceeffect.com/people/pete/
メール: pete@surfaceeffect.com ホームページ: http://www.surfaceeffect.com/people/pete/
Bob Briscoe B54/74 BT Labs Martlesham Heath Ipswich, IP5 3RE England
ボブ・ブリスコウ・B54/74BT研究室Martlesham Heath IP5 3REイプスウィッチ(イギリス)
Phone: +44 1473 645196 Fax: +44 1473 640929 EMail: bob.briscoe@bt.com Home page: http://www.labs.bt.com/people/briscorj/
以下に電話をしてください。 +44 1473 645196、Fax: +44 1473 640929はメールされます: bob.briscoe@bt.com ホームページ: http://www.labs.bt.com/people/briscorj/
Alan Poppitt B54/77 BT Labs Martlesham Heath Ipswich, IP5 3RE England
アラン・Poppitt B54/77BT研究室Martlesham Heath IP5 3REイプスウィッチ(イギリス)
Phone: +44 1473 640889 Fax: +44 1473 640929 EMail: apoppitt@jungle.bt.co.uk Home page: http://www.labs.bt.com/people/poppitag/
以下に電話をしてください。 +44 1473 640889、Fax: +44 1473 640929はメールされます: apoppitt@jungle.bt.co.uk ホームページ: http://www.labs.bt.com/people/poppitag/
Bagnall, et al. Informational [Page 26] RFC 2729 Taxonomy of Communication Requirements December 1999
Bagnall、他 コミュニケーション要件1999年12月の情報[26ページ]のRFC2729分類学
7. Full Copyright Statement
7. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 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機能のための基金は現在、インターネット協会によって提供されます。
Bagnall, et al. Informational [Page 27]
Bagnall、他 情報[27ページ]
一覧
スポンサーリンク
