RFC3897 日本語訳
3897 Open Pluggable Edge Services (OPES) Entities and End PointsCommunication. A. Barbir. September 2004. (Format: TXT=33890 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group A. Barbir Request for Comments: 3897 Nortel Networks Category: Informational September 2004
Barbirがコメントのために要求するワーキンググループA.をネットワークでつないでください: 3897 ノーテルはカテゴリをネットワークでつなぎます: 情報の2004年9月
Open Pluggable Edge Services (OPES) Entities
and End Points Communication
開いているPluggable縁のサービス(作品)実体とエンドポイントコミュニケーション
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 (2004).
Copyright(C)インターネット協会(2004)。
Abstract
要約
This memo documents tracing and non-blocking (bypass) requirements for Open Pluggable Edge Services (OPES).
このメモはオープンPluggable Edge Services(作品)のためのたどるのと非ブロッキング(迂回)要件を記録します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . 2
2. OPES System . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Tracing Requirements . . . . . . . . . . . . . . . . . . . . . 3
3.1. Traceable entities . . . . . . . . . . . . . . . . . . . 3
3.2. System requirements . . . . . . . . . . . . . . . . . . 5
3.3. Processor requirements . . . . . . . . . . . . . . . . . 5
3.4. Callout server requirements . . . . . . . . . . . . . . 5
4. Bypass (Non-blocking feature) Requirements . . . . . . . . . . 6
4.1. Bypassable entities . . . . . . . . . . . . . . . . . . 7
4.2. System requirements . . . . . . . . . . . . . . . . . . 8
4.3. Processor requirements . . . . . . . . . . . . . . . . . 8
4.4. Callout server requirements . . . . . . . . . . . . . . 9
5. Protocol Binding . . . . . . . . . . . . . . . . . . . . . . . 9
6. Compliance Considerations . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8.1. Tracing security considerations . . . . . . . . . . . . 10
8.2. Bypass security considerations . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 用語. . . . . . . . . . . . . . . . . . . . . . 2 2。 作品システム. . . . . . . . . . . . . . . . . . . . . . . . . 2 3。 要件. . . . . . . . . . . . . . . . . . . . . 3 3.1をたどります。 起因している実体. . . . . . . . . . . . . . . . . . . 3 3.2。 システム要求. . . . . . . . . . . . . . . . . . 5 3.3。 プロセッサ要件. . . . . . . . . . . . . . . . . 5 3.4。 Calloutサーバ要件. . . . . . . . . . . . . . 5 4。 要件. . . . . . . . . . 6 4.1を迂回させてください(非妨げている特徴)。 Bypassable実体. . . . . . . . . . . . . . . . . . 7 4.2。 システム要求. . . . . . . . . . . . . . . . . . 8 4.3。 プロセッサ要件. . . . . . . . . . . . . . . . . 8 4.4。 Calloutサーバ要件. . . . . . . . . . . . . . 9 5。 結合. . . . . . . . . . . . . . . . . . . . . . . 9 6について議定書の中で述べてください。 承諾問題. . . . . . . . . . . . . . . . . . 9 7。 IANA問題. . . . . . . . . . . . . . . . . . . . . 9 8。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 10 8.1。 セキュリティ問題. . . . . . . . . . . . 10 8.2をたどります。 セキュリティ問題. . . . . . . . . . . . . 11 9を迂回させてください。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1。 引用規格. . . . . . . . . . . . . . . . . . 12 9.2。 有益な参照. . . . . . . . . . . . . . . . . 13 10。 承認. . . . . . . . . . . . . . . . . . . . . . . 13
Barbir Informational [Page 1] RFC 3897 OPES Entities & End Points Communication September 2004
Barbirの情報[1ページ]のRFC3897作品実体とエンドポイントコミュニケーション2004年9月
11. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13 12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14
11. 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . 13 12。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 14
1. Introduction
1. 序論
The Open Pluggable Edge Services (OPES) architecture [1] enables cooperative application services (OPES services) between a data provider, a data consumer, and zero or more OPES processors. The application services under consideration analyze and possibly transform application-level messages exchanged between the data provider and the data consumer.
オープンPluggable Edge Services(作品)構造[1]は情報提供業者と、データ消費者と、ゼロの間のアプリケーション・サービス(作品サービス)か、より多くの作品プロセッサを協力して可能にします。 考慮しているアプリケーション・サービスは、情報提供業者とデータ消費者の間で交換されたアプリケーションレベルメッセージを、分析して、ことによると変えます。
This work specifies OPES tracing and bypass functionality. The architecture document [1] requires that tracing is supported in-band. This design goal limits the type of application protocols that OPES can support. The details of what a trace record can convey are also dependent on the choice of the application level protocol. For these reasons, this work only documents requirements for OPES entities that are needed to support traces and bypass functionality. The task of encoding tracing and bypass features is application protocol specific. Separate documents will address HTTP and other protocols.
この仕事は作品のたどるのと迂回の機能性を指定します。 構造ドキュメント[1]は、たどることがバンドで支持されるのを必要とします。 このデザイン目標は作品がサポートできるアプリケーション・プロトコルのタイプを制限します。 また、跡の記録が伝えることができることに関する詳細もアプリケーションレベルプロトコルの選択に依存しています。 これらの理由で、この仕事は跡を支持して、機能性を迂回させるのに必要である作品実体のための要件を記録するだけです。 たどるのと迂回の特徴をコード化するタスクはアプリケーション・プロトコル特有です。 別々のドキュメントはHTTPと他のプロトコルを記述するでしょう。
The architecture does not prevent implementers from developing out- of-band protocols and techniques to address tracing and bypass. Such protocols are out of scope of the current work.
構造は、implementersがたどるのと迂回を記述するためにバンドの出ているプロトコルと技術を見いだすのを防ぎません。 執筆中の作品の範囲の外にそのようなプロトコルがあります。
1.1. Terminology
1.1. 用語
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2]. When used with the normative meanings, these keywords will be all uppercase. Occurrences of these words in lowercase comprise normal prose usage, with no normative implications.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[2])で説明されるように本書では解釈されることであるべきです。 標準の意味と共に使用されると、これらのキーワードはすべて大文字するようになるでしょう。 コネが小文字で印刷するこれらの単語の発生は標準の含意なしで正常な散文用法を包括します。
2. OPES System
2. 作品システム
This section provides a definition of OPES System. This is needed in order to define what is traceable (or bypassable) in an OPES Flow.
このセクションは作品Systemの定義を提供します。 これが、作品Flowで起因していて(迂回可能)であることを定義するのに必要です。
Definition: An OPES System is a set of all OPES entities authorized by either the data provider or the data consumer application to process a given application message.
定義: 作品Systemは実体が与えられたアプリケーションメッセージを処理するのを情報提供業者かデータ消費者アプリケーションのどちらかで認可したすべての作品の1セットです。
The nature of the authorization agreement determines if authority delegation is transitive (meaning an authorized entity is authorized to include other entities).
認可協定の本質は、権威代表団が他動であるかどうか(権限のある機関を意味すると他の実体が包含するのが認可されます)決定します。
Barbir Informational [Page 2] RFC 3897 OPES Entities & End Points Communication September 2004
Barbirの情報[2ページ]のRFC3897作品実体とエンドポイントコミュニケーション2004年9月
If specific authority agreements allow for re-delegation, an OPES system can be formed by induction. In this case, an OPES system starts with entities directly authorized by a data provider (or a data consumer) application. The OPES system then includes any OPES entity authorized by an entity that is already in the OPES system. The authority delegation is always viewed in the context of a given application message.
特定の権威協定が再代表団を考慮するなら、誘導で作品システムを形成できます。 この場合、作品システムは情報提供業者(または、データ消費者)アプリケーションで直接認可された実体から始まります。 そして、作品システムは作品システムに既にある実体によって認可されたどんな作品実体も含んでいます。 権威代表団は与えられたアプリケーションメッセージの文脈でいつも見られます。
An OPES System is defined on an application message basis. Having an authority to process a message does not imply being involved in message processing. Thus, some OPES system members may not participate in processing of a message. Similarly, some members may process the same message several times.
作品Systemはアプリケーションメッセージベースで定義されます。 メッセージを処理する権威を持っているのはメッセージ処理にかかわった存在を含意しません。 したがって、何人かの作品システムメンバーはメッセージの処理に参加しないかもしれません。 同様に、何度か同じメッセージを処理するメンバーもいるかもしれません。
The above definition implies that there can be no more than two OPES systems [Client-side and server-side OPES systems can process the same message at the same time] processing the same message at a given time. This is based on the assumption that there is a single data provider and a single data consumer as far as a given application message is concerned.
上の定義は、一時に同じメッセージを処理する2台未満の作品システム[クライアント側とサーバサイド作品システムは同時に、同じメッセージを処理できる]があることができるのを含意します。 これは与えられたアプリケーションメッセージに関する限り、ただ一つの情報提供業者と独身のデータ消費者がいるという仮定に基づいています。
For example, consider a Content Delivery Network (CDN) delivering an image on behalf of a busy web site. OPES processors and services, which the CDN uses to adapt and deliver the image, comprise an OPES System. In a more complex example, an OPES System would contain third party OPES entities that the CDN engages to perform adaptations (e.g., to adjust image quality).
例えば、忙しいウェブサイトを代表してイメージを送りながら、Content Delivery Network(CDN)を考えてください。 作品プロセッサとサービス(CDNはイメージを適合させて、送るのに利用する)は作品Systemを包括します。 より複雑な例では、作品Systemは、適合(例えば画質を調整する)を実行するために、CDNが従事させる第三者作品実体を含んでいるでしょう。
3. Tracing Requirements
3. 追跡要件
The definition of OPES trace and tracing are given next.
次に、作品跡の定義とたどることを与えます。
OPES trace: application message information about OPES entities
that adapted the message.
作品跡: メッセージを適合させた作品実体に関するアプリケーションメッセージ情報。
OPES tracing: the process of creating, manipulating, or
interpreting an OPES trace.
作品のたどること: 作品跡を作成するか、操るか、または解釈する過程。
Note that the above trace definition assumes in-band tracing. This dependency can be removed if desired. Tracing is performed on per message basis. Trace format is dependent on the application protocol that is being adapted. A traceable entity can appear multiple times in a trace (for example, every time it acts on a message).
上の跡の定義がバンドにおけるたどることを仮定することに注意してください。 望んでいるなら、この依存を取り除くことができます。 メッセージ基礎単位でたどるのに実行されます。 跡の形式は適合させられているアプリケーション・プロトコルに依存しています。 起因している実体は跡に複数の回現れることができます(例えば、毎回、それはメッセージに影響します)。
3.1. Traceable entities
3.1. 起因している実体
This section focuses on identifying traceable entities in an OPES Flow.
このセクションは、作品Flowで起因している実体を特定するのは焦点を合わせます。
Barbir Informational [Page 3] RFC 3897 OPES Entities & End Points Communication September 2004
Barbirの情報[3ページ]のRFC3897作品実体とエンドポイントコミュニケーション2004年9月
Tracing information provides an "end" with information about OPES entities that adapted the data. There are two distinct uses of OPES traces. First, a trace enables an "end" to detect the presence of OPES System. Such "end" should be able to see a trace entry, but does not need to be able to interpret it beyond identification of the OPES System and location of certain required OPES-related disclosures (see Section 3.2).
追跡情報はデータを適合させた作品実体の情報を「終わり」に提供します。 作品跡の2つの異なった用途があります。 まず最初に、跡は、「終わり」が作品Systemの存在を検出するのを可能にします。 そのような「終わり」は、跡のエントリーを見ることができるべきですが、作品Systemの識別とある必要な作品関連の公開の位置を超えてそれを解釈する必要はないことができます(セクション3.2を見てください)。
Second, the OPES System administrator is expected to be able to interpret the contents of an OPES trace. The trace can be relayed to the administrator by an "end" without interpretation, as opaque data (e.g., a TCP packet or an HTTP message snapshot). The administrator can use the trace information to identify the participating OPES entities. The administrator can use the trace to identify the applied adaptation services along with other message-specific information.
2番目に、作品System管理者が作品跡のコンテンツを解釈できると予想されます。 「終わり」までに解釈なしで管理者に跡をリレーできます、不明瞭なデータ(例えば、TCPパケットかHTTPメッセージスナップ)として。 管理者は、参加している作品実体を特定するのにトレース情報を使用できます。 管理者は、他のメッセージ特殊情報に伴う適用された適合サービスを特定するのに跡を使用できます。
Since the administrators of various OPES Systems can have various ways of looking into tracing, they require the freedom in what to put in trace records and how to format them.
様々な作品Systemsの管理者がたどることを調べる様々な方法を持つことができるので、彼らは跡の記録に何を置くか、そして、どのようにそれらをフォーマットするかで自由を必要とします。
At the implementation level, for a given trace, an OPES entity involved in handling the corresponding application message is traceable or traced if information about it appears in that trace. This work does not specify any order to that information. The order of information in a trace can be OPES System specific or can be defined by application bindings documents.
実現レベルでは、それの情報がその跡に現れるなら、与えられた跡に関して、対応するアプリケーションメッセージを扱うのにかかわる作品実体は、起因するかたどられます。 この仕事はその情報に少しのオーダーも指定しません。 跡での情報の注文を作品System特有である場合があるか、またはアプリケーション結合ドキュメントは定義できます。
OPES entities have different levels of traceability requirements. Specifically,
作品実体には、異なったレベルの追随性要件があります。 明確に
o An OPES System MUST add its entry to the trace.
o An OPES processor SHOULD add its entry to the trace.
o An OPES service MAY add its entry to the trace.
o An OPES entity MAY delegate addition of its trace entry to another
OPES entity. For example, an OPES System can have a dedicated
OPES processor for adding System entries; an OPES processor can
use a callout service to manage all OPES trace manipulations
(since such manipulations are OPES adaptations).
o 作品Systemは跡にエントリーを加えなければなりません。o An作品プロセッサSHOULDは跡にエントリーを加えます。o An作品サービスは跡にエントリーを加えるかもしれません。o An作品実体は別の作品実体への跡のエントリーの添加を代表として派遣するかもしれません。 例えば、作品SystemはSystemエントリーを加えるための専用作品プロセッサを持つことができます。 作品プロセッサは、すべての作品跡の操作を管理するのにcalloutサービスを利用できます(そのような操作が作品適合であるので)。
In an OPES context, a good tracing approach is similar to a trouble ticket ready for submission to a known address. The address is printed on the ticket. The trace in itself is not necessarily a detailed description of what has happened. It is the responsibility of the operator to decode trace details and to resolve the problems.
作品文脈では、良い追跡アプローチは知られているアドレスへの提出の準備ができる問題チケットと同様です。 アドレスはチケットに印刷されます。 それ自体の跡は必ず何が起こったかに関する詳述であるというわけではありません。 オペレータは跡の詳細を解読して、問題を解決する責任です。
Barbir Informational [Page 4] RFC 3897 OPES Entities & End Points Communication September 2004
Barbirの情報[4ページ]のRFC3897作品実体とエンドポイントコミュニケーション2004年9月
3.2 System requirements
3.2 システム要件
The following requirements document actions when forming an OPES System trace entry:
作品System跡のエントリーを形成するとき、以下の要件は動作を記録します:
o OPES system MUST include its unique identification in its trace
entry. Here, uniqueness scope is all OPES Systems that may adapt
the message being traced.
o An OPES System MUST define its impact on inter- and intra-document
reference validity.
o An OPES System MUST include information about its privacy policy,
including identity of the party responsible for setting and
enforcing the policy.
o An OPES System SHOULD include information that identifies, to the
technical contact, the OPES processors involved in processing the
message.
o When providing required information, an OPES System MAY use a
single URI to identify a resource containing several required
items. For example, an OPES System can point to a single web page
with a reference to System privacy policy and technical contact
information.
o 作品システムは跡のエントリーにおけるユニークな識別を含まなければなりません。 そして、ユニークさの範囲がすべて、ここの、それがあって、たどられて. o An作品Systemが衝撃を定義しなければならないというメッセージを適合させるかもしれない作品Systemsである、相互、イントラドキュメント参照の正当性o An作品Systemはプライバシーに関する方針の情報を含まなければなりません、方針を設定して、実施するのに責任があるパーティーのアイデンティティを含んでいて; 必須情報、o An作品System SHOULDは技術連絡担当者(メッセージを処理するのにかかわる作品プロセッサ)にo When提供を特定する情報を含んで、作品Systemは数個の必要な項目を含むリソースを特定するのにただ一つのURIを使用するかもしれません。例えば、作品SystemはSystemプライバシーに関する方針と技術連絡担当者情報の参照がある1ウェブページを示すことができます。
This specification does not define the meaning of the terms privacy policy, policy enforcement, or reference validity or technical contact and contains no requirements regarding encoding, language, format, or any other aspects of that information. For example, a URI used for an OPES System trace entry may look like "http:// www.examplecompany.com/opes/?client=example.com" where the identified web page is dynamically generated and contains the all OPES System information required above.
この仕様は、用語プライバシーに関する方針、方針実施、参照の正当性または技術連絡担当者の意味を定義しないで、またその情報のどんなコード化に関する要件も、言語、形式、またはいかなる他の局面も含んでいません。 例えば、作品System跡のエントリーに使用されるURIは、特定されたウェブページがダイナミックに発生する「http://www.examplecompany.com/opes/?クライアント=example.com」に似るかもしれなくて、上の作品System情報必要を含んでいます。
3.3. Processor requirements
3.3. プロセッサ要件
The following requirements document actions when forming an OPES System trace entry:
作品System跡のエントリーを形成するとき、以下の要件は動作を記録します:
o OPES processor SHOULD add its unique identification to the trace.
Here, uniqueness scope is the OPES System containing the
processor.
o 作品プロセッサSHOULDはユニークな識別を跡に加えます。 ここで、ユニークさの範囲はプロセッサを含む作品Systemです。
3.4. Callout server requirements
3.4. Calloutサーバ要件
In an OPES system, it is the task of an OPES processor to add trace records to application messages. The OPES System administrator decides if and under what conditions callout servers may add trace information to application messages.
作品システムでは、それは跡の記録をアプリケーションメッセージに追加する作品プロセッサに関するタスクです。 作品System管理者が決める、そして、calloutサーバはどんな条件のもとでアプリケーションメッセージにトレース情報を追加するかもしれませんか?
Barbir Informational [Page 5] RFC 3897 OPES Entities & End Points Communication September 2004
Barbirの情報[5ページ]のRFC3897作品実体とエンドポイントコミュニケーション2004年9月
4. Bypass (Non-blocking feature) Requirements
4. 迂回(非ブロッキング機能)要件
IAB recommendation (3.3) [6] requires that the OPES architecture does not prevent a data consumer application from retrieving non-OPES version of content from a data provider application, provided that the non-OPES content exists. IAB recommendation (3.3) suggests that the Non-blocking feature (bypass) be used to bypass faulty OPES intermediaries (once they have been identified, by some method).
IAB推薦(3.3)[6]は、作品構造が、データ消費者アプリケーションが情報提供業者アプリケーションから内容の非作品バージョンを検索するのを防がないのを必要とします、非作品内容が存在していれば。 IAB推薦(3.3)は、Nonを妨げている特徴(迂回)が不完全な作品仲介者を迂回させるのに使用されるのを示します(彼らが何らかの方法でいったん特定されると)。
In addressing IAB consideration (3.3), one need to specify what constitutes non-OPES content. In this work the definition of "non- OPES" content is provider dependent. In some cases, the availability of "non-OPES" content can be a function of the internal policy of a given organization that has contracted the services of an OPES provider. For example, Company A has as contract with an OPES provider to perform virus checking on all e-mail attachments. An employee X of Company A can issue a non-blocking request for the virus scanning service. The request could be ignored by the OPES provider since it contradicts its agreement with Company A.
IABの考慮(3.3)を記述する際に、人は、非作品内容を構成することを指定する必要があります。 この仕事では、「非作品」の内容の定義はプロバイダーに依存しています。 いくつかの場合、「非作品」内容の有用性は作品プロバイダーのサービスを契約した与えられた組織の内部の方針の機能であるかもしれません。 例えば、A社はすべての電子メールの添付ファイルについて検査して、ウイルスを実行する作品プロバイダーとの契約としてそうしました。 A社の従業員Xはウイルススキャンサービスを求める非ブロッキング要求を出すことができます。 A社との協定に矛盾するので、作品プロバイダーは要求を無視できました。
The availability of non-OPES content can be a function of content providers (or consumers or both) policy and deployment scenarios [5]. For this reason, this work does not attempt to define what is an OPES content as opposed to non-OPES content. The meaning of OPES versus non-OPES content is assumed to be determined through various agreements between the OPES provider, data provider and/or data consumer. The agreement determines what OPES services can be bypassed and in what order (if applicable).
非作品内容の有用性はコンテンツプロバイダー方針と展開シナリオ[5](または、消費者か両方)の機能であるかもしれません。 この理由で、この仕事は、非作品内容と対照的に作品内容であることを定義するのを試みません。 作品対内容が作品プロバイダー、情報提供業者、そして/または、データの間の様々な協定で決定すると思われる非作品消費者の意味。 協定はどんな作品サービスが迂回して、何で注文されることができるかを決定します(適切であるなら)。
This specification documents bypassing of an OPES service or a group of services identified by a URI. In this context, to "bypass the service" for a given application message in an OPES Flow means to "not invoke the service" for that application message. A bypass URI that identifies an OPES system (processor) matches all services attached to that OPES system (processor). However, bypassing of OPES processors and OPES Systems themselves requires non-OPES mechanisms and is out of this specification scope. A bypass request an instruction to bypass, usually embedded in an application message.
この仕様はURIによって特定されたサービスの作品サービスかグループの迂回を記録します。 このような関係においては、作品Flowの与えられたアプリケーションメッセージのために「サービスを迂回すること」は、そのアプリケーションメッセージのために「サービスを呼び出さないこと」を意味します。 作品システム(プロセッサ)を特定する迂回URIはその作品システム(プロセッサ)に取り付けられたすべてのサービスに合っています。 しかしながら、作品プロセッサと作品Systems自身の迂回は、非作品メカニズムを必要として、この仕様範囲の外にあります。 迂回は通常、アプリケーションメッセージに埋め込まれた迂回への指示を要求します。
The current specification does not provide for a good mechanism that allow and "end" to specify to "bypass this service but only if it is a part of that OPES system" or "bypass all services of that OPES system but not of this OPES system". Furthermore, if an OPES processor does not know for sure that a bypass URI does not match its service, it must bypass that service.
現在の仕様は、それが「このサービスを迂回させなさい、ただし、それである場合にだけ、その作品システムは部分があること」に指定するために許容して、「終わらせる」良いメカニズムに備えませんし、また「その作品システムのすべてのサービスを迂回させますが、この作品システムについて迂回しないというわけではありません」。 その上、作品プロセッサが、迂回URIがサービスに合っていないのを確かに知らないなら、それはそのサービスを迂回させなければなりません。
Barbir Informational [Page 6] RFC 3897 OPES Entities & End Points Communication September 2004
Barbirの情報[6ページ]のRFC3897作品実体とエンドポイントコミュニケーション2004年9月
If no non-OPES content is available without the specified service, the bypass request for that service must be ignored. This design implies that it may not be possible to detect non-OPES content existence or to detect violations of bypass rules in the environments where the tester does not know whether non-OPES content exists. This design assumes that most bypass requests are intended for situations where serving undesirable OPES content is better than serving an error message that no preferred non-OPES content exists.
どんな非作品内容も指定されたサービスなしで利用可能でないなら、そのサービスを求める迂回要求を無視しなければなりません。 このデザインは、非作品の満足している存在を検出するか、またはテスターが非作品内容が存在するかどうかを知らない環境における、迂回規則の違反を検出するのが可能でないかもしれないことを含意します。 このデザインは、ほとんどの迂回要求が望ましくない作品内容に役立つのがエラーメッセージにそれに役立って、どんな都合のよい非作品内容も存在していないより良い状況のために意図すると仮定します。
Bypass feature is to malfunctioning OPES services as HTTP "reload" request is to malfunctioning HTTP caches. The primary purpose of the bypass is to get usable content in the presence of service failures and not to provide the content consumer with more information on what is going on. OPES trace should be used for the latter instead.
HTTPがキャッシュする誤動作にはHTTP「再ロード」要求があるように作品が修理する誤動作には迂回の特徴があります。 迂回のプライマリ目的は、サービス失敗があるとき使用可能な内容を届けて、起こっていることに関する詳しい情報を満足している消費者に提供しないことです。 作品跡は後者に代わりに使用されるべきです。
While this work defines a "bypass service if possible" feature, there are other related bypass features that can be implemented in OPES and/or in application protocols being adapted. For example, a "bypass service or generate an error" or "bypass OPES entity or generate an error". Such services would be useful for debugging broken OPES systems and may be defined in other OPES specifications. This work concentrates on documenting a user-level bypass feature addressing direct IAB concerns.
この仕事は「できれば、サービスを迂回させてください」という特徴を定義しますが、作品アプリケーション・プロトコルで実装することができる適合させられる他の関連する迂回の特徴があります。 例えば、「サービスを迂回させるか、またはエラーを起こしてください」、または「作品実体を迂回させるか、またはエラーを起こしてください。」 そのようなサービスは、壊れている作品システムをデバッグすることの役に立って、他の作品仕様に基づき定義されるかもしれません。 この仕事はダイレクトIAB関心を扱うユーザレベル迂回機能を記録するのに集中します。
4.1. Bypassable entities
4.1. Bypassable実体
In this work, the focus is on developing a bypass feature that allows a user to instruct the OPES System to bypass some or all of its services. The collection of OPES services that can be bypassed is a function of the agreement of the OPES provider with either (or both) the content provider or the content consumer applications. In the general case, a bypass request is viewed as a bypass instruction that contains a URI that identifies an OPES entity or a group of OPES entities that perform a service (or services) to be bypassed. An instruction may contain more than one such URI. A special wildcard identifier can be used to represent all possible URIs.
この仕事、焦点はユーザがサービスのいくつかかすべてを迂回させるよう作品Systemに命令できる迂回の特徴を発生するところで中です。 迂回できる作品サービスの収集は(ともに)コンテンツプロバイダーか満足している消費者アプリケーションのどちらかとの作品プロバイダーの協定の機能です。 一般的な場合では、迂回要求は、作品実体を特定するURIを含む迂回指示として見なされて迂回するために事業を行う(または、サービス)作品実体のグループです。 指示はそのようなURIの1つ以上を含むかもしれません。 すべての可能なURIを表すのに特別なワイルドカード識別子を使用できます。
In an OPES Flow, a bypass request is processed by each involved OPES processor. This means that an OPES processor examines the bypass instruction and if non-OPES content is available, the processor then bypasses the indicated services. The request is then forwarded to the next OPES processor in the OPES Flow. The next OPES processor would then handle all bypass requests, regardless of the previous processor actions. The processing chain continues throughout the whole processors that are involved in the OPES Flow.
作品Flowでは、迂回要求はそれぞれのかかわった作品プロセッサによって処理されます。 これは、作品プロセッサが迂回指示を調べることを意味します、そして、非作品内容が利用可能であるなら、次に、プロセッサは示されたサービスを迂回させます。 そして、作品Flowの次の作品プロセッサに要求を転送します。 そして、次の作品プロセッサは前のプロセッサ動作にかかわらずすべての迂回要求を扱うでしょう。 処理チェーンは作品Flowにかかわる全体のプロセッサ中で続きます。
Barbir Informational [Page 7] RFC 3897 OPES Entities & End Points Communication September 2004
Barbirの情報[7ページ]のRFC3897作品実体とエンドポイントコミュニケーション2004年9月
4.2. System requirements
4.2. システム要求
In an OPES System, bypass requests are generally client centric (originated by the data consumer application) and go in the opposite direction of tracing requests. This work requires that the bypass feature be performed in-band as an extension to an application specific protocol. Non-OPES entities should be able to safely ignore these extensions. The work does not prevent OPES Systems from developing their own out of band protocols.
作品Systemでは、迂回要求は、一般に、クライアント中心であり(データ消費者アプリケーションで、溯源されます)、追跡要求の逆方向に入ります。 この仕事は、迂回の特徴が実行されたアプリケーションへの拡大としてのバンドの特定のプロトコルであることを必要とします。 非作品実体は安全にこれらの拡大を無視できるべきです。 仕事は、作品Systemsがバンドプロトコルからそれら自身のを開発するのを防ぎません。
The following requirements apply for bypass feature as related to an OPES System (the availability of a non-OPES content is a precondition):
以下の要件は作品Systemに関連されるように迂回の特徴に申し込みます(非作品内容の有用性は前提条件です):
o An OPES System MUST support a bypass feature. This means that the
OPES System bypasses services whose URIs are identified by an OPES
"end".
o An OPES System MUST provide OPES version of the content if non-
OPES version is not available.
o 作品Systemは迂回の特徴をサポートしなければなりません。 これは、作品SystemがURIが作品「終わり」までに特定されるサービスを迂回させることを意味します。非作品のバージョンが利用可能でないなら、o An作品Systemは内容の作品バージョンを前提としなければなりません。
In order to facilitate the debugging (or data consumer user experience) of the bypass feature in an OPES System, it would be beneficial if non-bypassed entities included information related to why they ignored the bypass instruction. It is important to note that in some cases the tracing facility itself may be broken and the whole OPES System (or part) may need to be bypassed through the issue of a bypass instruction.
作品Systemでの迂回の特徴のデバッグ(または、データ消費者ユーザー・エクスペリエンス)を容易にするために、非迂回している実体が彼らが迂回指示を無視した理由に話された情報を含んでいるなら、有益でしょうに。 そんなにいくつかの場合、追跡施設自体に注意するのが壊れるかもしれなくて、全体の作品System(または、部分)が、迂回指示の問題を通して迂回する必要があるのは、重要です。
4.3. Processor requirements
4.3. プロセッサ要件
Bypass requirements for OPES processors are (the availability of a non-OPES content is a precondition):
作品プロセッサのための迂回要件はこと(非作品内容の有用性は前提条件である)です:
o OPES processor SHOULD be able to interpret and process a bypass
instruction. This requirement applies to all bypass instructions,
including those that identify unknown-to-recipient services.
o OPES processors MUST forward bypass request to the next
application hop provided that the next hop speaks application
protocol with OPES bypass support.
o OPES processor SHOULD be able to bypass it's service(s) execution.
o 作品プロセッサSHOULDは解釈できて、迂回指示を処理します。 この要件は、指示をすべて迂回させるのに申し込んで、それを迂回させることができるのが、サービス実行であるということになってください次のホップが作品迂回サポートo作品プロセッサSHOULDでアプリケーション・プロトコルを話せばサービスo作品プロセッサが進めなければならない未知から受取人への迂回要求を次のアプリケーションホップに特定するものを含んでいて。
OPES processors that know how to process and interpret a bypass instruction have the following requirements:
どのように迂回指示を処理して、解釈するかを知っている作品プロセッサが以下の要件を持っています:
o The recipient of a bypass instruction with a URI that does not
identify any known-to-recipient OPES entity MUST treat that URI as
a wildcard identifier (meaning bypass all applicable services).
o どんな受取人にとって、知られている作品実体も特定しないURIとの迂回指示の受取人はワイルドカード識別子としてそのURIを扱わなければなりません(すべての適用されるサービスを迂回させることを意味して)。
Barbir Informational [Page 8] RFC 3897 OPES Entities & End Points Communication September 2004
Barbirの情報[8ページ]のRFC3897作品実体とエンドポイントコミュニケーション2004年9月
4.4. Callout server requirements
4.4. Calloutサーバ要件
In an OPES system, it is the task of an OPES processor to process bypass requests. The OPES System administrator decides if and under what conditions callout servers process bypass requests.
作品システムでは、それは迂回要求を処理する作品プロセッサに関するタスクです。 作品System管理者が決める、そして、calloutサーバはどんな条件のもとで迂回要求を処理しますか?
5. Protocol Binding
5. プロトコル結合
The task of encoding tracing and bypass features is application protocol specific. Separate documents will address HTTP and other protocols. These documents must address the ordering of trace information as needed.
たどるのと迂回の特徴をコード化するタスクはアプリケーション・プロトコル特有です。 別々のドキュメントはHTTPと他のプロトコルを扱うでしょう。 これらのドキュメントは必要に応じてトレース情報の注文を扱わなければなりません。
6. Compliance Considerations
6. 承諾問題
This specification defines compliance for the following compliance subjects: OPES System, processors, entities and callout servers.
この仕様は以下の承諾対象のためのコンプライアンスを定義します: 作品System、プロセッサ、実体、およびcalloutサーバ。
A compliance subject is compliant if it satisfies all applicable "MUST" and "SHOULD" level requirements. By definition, to satisfy a "MUST" level requirement means to act as prescribed by the requirement; to satisfy a "SHOULD" level requirement means to either act as prescribed by the requirement or have a reason to act differently. A requirement is applicable to the subject if it instructs (addresses) the subject.
すべての適切な“MUST"を満たすなら、承諾対象は対応します、そして、“SHOULD"は要件を平らにします。 定義上、“MUST"の平らな要件を満たすのは、要件によって処方されるように行動することを意味します。 “SHOULD"の平らな要件を満たすのは、要件によって処方されるように行動するか、または行動する理由を異なって持っていることを意味します。 命令するなら、要件は対象に適切です。(アドレス)対象。
Informally, compliance with this document means that there are no known "MUST" violations, and all "SHOULD" violations are conscious. In other words, a "SHOULD" means "MUST satisfy or MUST have a reason to violate". It is expected that compliance claims are accompanied by a list of unsupported SHOULDs (if any), in an appropriate format, explaining why preferred behavior was not chosen.
非公式に、このドキュメントへの承諾は、“MUST"違反が知られていないことを意味します、そして、すべての“SHOULD"違反が意識的です。 言い換えれば、“SHOULD"手段は「満足させなければならないか、または違反する理由を持たなければなりません」。 承諾クレームがサポートされないSHOULDs(もしあれば)のリストによって伴われると予想されます、適切な形式で、都合のよい振舞いがなぜ選ばれなかったかを説明して。
Only normative parts of this specification affect compliance. Normative parts are: parts explicitly marked using the word "normative", definitions, and phrases containing unquoted capitalized keywords from RFC 2119 [2]. Consequently, examples and illustrations are not normative.
この仕様の標準の部分だけがコンプライアンスに影響します。 標準の部品は以下の通りです。 部品は、使用がRFC2119[2]からの引用を終わっている大文字で書かれたキーワードを含む「標準」という言葉と、定義と、句であると明らかにマークしました。 その結果、例とイラストは規範的ではありません。
7. IANA Considerations
7. IANA問題
This specification contains no IANA considerations. Application bindings MAY contain application-specific IANA considerations.
この仕様はIANA問題を全く含んでいません。 アプリケーション結合はアプリケーション特有のIANA問題を含むかもしれません。
Barbir Informational [Page 9] RFC 3897 OPES Entities & End Points Communication September 2004
Barbirの情報[9ページ]のRFC3897作品実体とエンドポイントコミュニケーション2004年9月
8. Security Considerations
8. セキュリティ問題
Security considerations for OPES are documented in [4]. Policy and authorization issues are documented in [3]. It is recommended that designers consult these documents before reading this section.
作品のためのセキュリティ問題は[4]に記録されます。 方針と承認問題は[3]に記録されます。 このセクションを読む前にデザイナーがこれらのドキュメントを参照するのは、お勧めです。
This document is a requirement document for tracing and bypass feature. The requirements that are stated in this document can be used to extend an application level protocol to support these features. As such, the work has security precautions.
このドキュメントはたどるのと迂回の特徴のための要件ドキュメントです。 これらの特徴をサポートするためにアプリケーションレベルプロトコルを広げるのに本書では述べられている要件は使用できます。 そういうものとして、仕事には、安全対策があります。
8.1. Tracing security considerations
8.1. 追跡セキュリティ問題
The tracing facility for OPES architecture is implemented as a protocol extension. Inadequate implementations of the tracing facility may defeat safeguards built into the OPES architecture. The tracing facility by itself can become a target of malicious attacks or used to lunch attacks on an OPES System.
作品アーキテクチャのための追跡施設はプロトコル拡大として実装されます。 追跡施設の不十分な実装は作品アーキテクチャが組み込まれた安全装置を破るかもしれません。 それ自体で追跡施設は作品Systemに対する昼食攻撃に悪意ある攻撃か中古の目標になることができます。
Threats caused by or against the tracing facility can be viewed as threats at the application level in an OPES Flow. In this case, the threats can affect the data consumer and the data provider application.
アプリケーションにおける脅威が作品でFlowを平らにするとき、施設か追跡施設に対して引き起こされた脅威は見ることができます。 この場合、脅威はデータ消費者と情報提供業者アプリケーションに影響できます。
Since tracing information is a protocol extension, these traces can be injected in the data flow by non-OPES entities. In this case, there are risks that non-OPES entities can be compromised in a fashion that threat the overall integrity and effectiveness of an OPES System. For example, a non-OPES proxy can add fake tracing information into a trace. This can be done in the form of wrong, or unwanted, or non existent services. A non-OPES entity can inject large size traces that may cause buffer overflow in a data consumer application. The same threats can arise from compromised OPES entities. An attacker can control an OPES entity and inject wrong, or very large trace information that can overwhelm an end or the next OPES entity in an OPES flow. Similar threats can result from bad implementations of the tracing facility in trusted OPES entities.
追跡情報がプロトコル拡大であるので、データフローで非作品実体でこれらの跡を注入できます。 この場合、ファッションによるその脅威であると非作品実体に感染することができるというリスクがあります。作品Systemの総合的な保全と有効性。 例えば、非作品プロキシはにせの追跡情報を跡に加えることができます。 間違ったか、求められていないか、または非目下のサービスの形でこれができます。 非作品実体はデータ消費者アプリケーションにおけるバッファオーバーフローを引き起こすかもしれない大判跡を注入できます。 同じ脅威は感染している作品実体から起こることができます。 攻撃者は、作品実体を制御して、作品流動で終わりか次の作品実体を圧倒できる間違ったか、非常に大きいトレース情報を注入できます。 同様の脅威は信じられた作品実体で追跡施設の悪い実装から生じることができます。
Compromised tracing information can be used to launch attacks on an OPES System that give the impression that unwanted content transformation was performed on the data. This can be achieved by inserting wrong entity (such OPES processor) identifiers. A compromised trace can affect the overall message integrity structure. This can affect entities that use message header information to perform services such as accounting, load balancing, or reference- based services.
作品Systemに対する求められていない満足している変換がデータに実行されたという印象を与える攻撃に着手するのに感染している追跡情報を使用できます。 間違った実体(そのような作品プロセッサ)識別子を挿入することによって、これを達成できます。 感染している跡は総合的なメッセージの保全構造に影響できます。 これは会計などのサービスを実行するのにメッセージヘッダー情報を使用する実体に影響できます、ロードバランシング、または、参照がサービスを基礎づけました。
Barbir Informational [Page 10] RFC 3897 OPES Entities & End Points Communication September 2004
Barbirの情報[10ページ]のRFC3897作品実体とエンドポイントコミュニケーション2004年9月
Compromised trace information can be used to launch DoS attacks that can overwhelm a data consumer application or an OPES entity in an OPES Flow. Inserting wrong tracing information can complicate the debugging tasks performed by system administrator during trouble shooting of OPES System behavior.
作品Flowでデータ消費者アプリケーションか作品実体を圧倒できるDoS攻撃に着手するのに感染しているトレース情報を使用できます。 間違った追跡情報を挿入すると、作品Systemの振舞いのトラブルシューティングの間にシステム管理者によって実行されたデバッグタスクは複雑にすることができます。
As a precaution, OPES entities ought to be capable of verifying that the inserted traces are performed by legal OPES entities. This can be done as part of the authorization and authentication face. Policy can be used to indicate what trace information can be expected from a peer entity. Other application level related security concerns can be found in [4].
注意として、作品実体は、挿入された跡が法的な作品実体によって実行されることを確かめることができるべきです。 承認と認証表面の一部としてこれができます。 同輩実体からどんなトレース情報を予想できるかを示すのに方針を使用できます。 [4]で他のアプリケーションの平らな関連する安全上の配慮を見つけることができます。
8.2. Bypass security considerations
8.2. 迂回セキュリティ問題
The bypass facility for OPES architecture is implemented as a protocol extension. Inadequate implementations of the bypass facility may defeat safeguards built into the OPES architecture. The bypass facility by itself can become a target of malicious attacks or used to lunch attacks on an OPES System.
作品アーキテクチャのための迂回施設はプロトコル拡大として実装されます。 迂回施設の不十分な実装は作品アーキテクチャが組み込まれた安全装置を破るかもしれません。 それ自体で迂回施設は作品Systemに対する昼食攻撃に悪意ある攻撃か中古の目標になることができます。
Threats caused by or against the bypass facility can be viewed as threats at the application level in an OPES Flow. In this case, the threats can affect the data consumer and the data provider application.
アプリケーションにおける脅威が作品でFlowを平らにするとき、施設か迂回施設に対して引き起こされた脅威は見ることができます。 この場合、脅威はデータ消費者と情報提供業者アプリケーションに影響できます。
There are risks for the OPES System by non-OPES entities, whereby, these entities can insert bypass instructions into the OPES Flow. The threat can come from compromised non-OPES entities. The threat might affect the overall integrity and effectiveness of an OPES System. For example, a non-OPES proxy can add bypass instruction to bypass legitimate OPES entities. The attack might result in overwhelming the original content provider servers, since the attack essentially bypass any load balancing techniques. In addition, such an attack is also equivalent to a DoS attack, whereby, a legitimate data consumer application may not be able to access some content from a content provider or its OPES version.
非作品実体による作品Systemのためのリスクがある、どうして、これらの実体は作品Flowへの差し込み迂回指示をそうすることができます。 脅威は感染している非作品実体から来ることができます。 脅威は作品Systemの総合的な保全と有効性に影響するかもしれません。 例えば、非作品プロキシは、正統の作品実体を迂回させるために迂回指示を加えることができます。 攻撃は攻撃がどんなロードバランシングのテクニックも本質的には迂回させるのでオリジナルコンテンツプロバイダーサーバを圧倒するのに結果として生じるかもしれません。 また、さらに、そのような攻撃もDoS攻撃に同等である、どうして、正統のデータ消費者アプリケーションはコンテンツプロバイダーかその作品バージョンから何らかの内容にアクセスできないかもしれません。
Since an OPES Flow may include non-OPES entities, it is susceptible to man-in-the-middle attacks, whereby an intruder may inject bypass instructions into the data path. These attacks may affect content availability or disturb load balancing techniques in the network.
作品Flowが非作品実体を含むかもしれないので、それは介入者攻撃に影響されやすいです。(侵入者は介入者攻撃で迂回指示をデータ経路に注ぐかもしれません)。 これらの攻撃は、満足している有用性に影響するか、またはネットワークでロードバランシングのテクニックを擾乱するかもしれません。
The above threats can also arise by compromised OPES entities. An intruder can compromise an OPES entities and then use man-in-the- middle techniques to disturb content availability to a data consumer application or overload a content provider server (essentially, some form of a DoS attack).
また、上の脅威は感染している作品実体で起こることができます。 侵入者が作品実体に感染して、次に、中の男性を使用できる、-、-擾乱する中央テクニックは、データ消費者アプリケーションに有用性を満足させるか、またはコンテンツプロバイダーサーバ(本質的にはDoS攻撃の何らかのフォーム)を積みすぎます。
Barbir Informational [Page 11] RFC 3897 OPES Entities & End Points Communication September 2004
Barbirの情報[11ページ]のRFC3897作品実体とエンドポイントコミュニケーション2004年9月
Attackers can use the bypass instruction to affect the overall integrity of the OPES System. The ability to introduce bypass instructions into a data flow may effect the accounting of the OPES System. It may also affect the quality of content that is delivered to the data consumer applications. Similar threats can arise from bad implementations of the bypass facility.
攻撃者は、作品Systemの総合的な保全に影響するのに迂回指示を使用できます。 迂回指示をデータフローに取り入れる能力は作品Systemの会計に作用するかもしれません。 また、それはデータ消費者アプリケーションに提供される内容の品質に影響するかもしれません。 同様の脅威は迂回施設の悪い実装から起こることができます。
Inconsistent or selective bypass is also a threat. Here, one end can try to bypass a subset of OPES entities so that the resulting content is malformed and crashes or compromises entities that process that content (and expect that content to be complete and valid). Such exceptions are often not tested because implementers do not expect a vital service to disappear from the processing loop.
また、矛盾したか選択している迂回は脅威です。 ここで、片端が作品実体の部分集合を迂回させようとすることができるので、結果として起こる内容は、その内容を処理する実体を、奇形であり、墜落するか、または感染します(その内容が完全であって、有効であると予想してください)。 implementersが、重大なサービスが処理ループから見えなくなると予想しないので、そのような例外はしばしばテストされるというわけではありません。
Other threats can arise from configuring access control policies for OPES entities. It is possible that systems implementing access controls via OPES entities may be incorrectly configured to honor bypass and, hence, give unauthorized access to intruders.
他の脅威は、作品実体のためにアクセス制御方針を構成しながら、起こることができます。 アクセスがコントロールであると作品実体で実装するシステムが迂回を光栄に思って、したがって、侵入者への不正アクセスを与えるために不当に構成されるのは、可能です。
Tap bypass can also be a threat. This is because systems implementing wiretaps via OPES entities may be incorrectly configured to honor bypass and, hence, ignore (leave undetected) traffic with bypass instructions that should have been tapped or logged. It is also possible for one end to bypass services such as virus scanning at the receiving end. This threat can be used by hackers to inject viruses throughout the network. Following an IETF policy on Wiretapping [7], OPES communication model does not consider wiretapping requirements. Nevertheless, the documented threat is real, not obvious, and OPES technology users operating in wiretapping or similar logging environments should be aware of it.
また、蛇口迂回は脅威であるかもしれません。 これは作品実体で盗聴を実行するシステムが迂回を光栄に思って、したがって、開発されるべきであったか、または登録されるべきであった迂回指示による交通を無視する(休暇は非検出された)ために不当に構成されるかもしれないからです。 また、片端が犠牲者にスキャンされるウイルスなどのサービスを迂回させるのも、可能です。 ハッカーは、ネットワーク中でウイルスを注入するのにこの脅威を使用できます。 Wiretapping[7]に関するIETF方針に従って、作品コミュニケーションモデルは、要件を盗聴すると考えません。 それにもかかわらず、記録された脅威は明白であるのではなく、本当です、そして、盗聴しているか同様の伐採環境で働いている作品技術ユーザはそれを意識しているべきです。
Other application level related security concerns can be found in [4].
[4]で他のアプリケーションの平らな関連する安全上の配慮を見つけることができます。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[1] Barbir, A., Penno, R., Chen, R., Hofmann, M., and H. Orman, "An
Architecture for Open Pluggable Edge Services (OPES)", RFC 3835,
August 2004.
[1]Barbir、A.、ペンノ、R.、チェン、R.、ホフマン、M.、およびH.Orman、「開いているPluggable縁のサービスのための構造(作品)」、RFC3835(2004年8月)。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Barbir Informational [Page 12] RFC 3897 OPES Entities & End Points Communication September 2004
Barbirの情報[12ページ]のRFC3897作品実体とエンドポイントコミュニケーション2004年9月
[3] Barbir, A., Batuner, O., Beck, A., Chan, T., and H. Orman,
"Policy, Authorization, and Enforcement Requirements of Open
Pluggable Edge Services (OPES)", RFC 3838, August 2004.
[3]Barbir、A.、Batuner、O.、べック、A.、チェン、T.、およびH.Orman、「オープンPluggableの方針、認可、および実施要件はサービス(作品)を斜めに進む」RFC3838(2004年8月)。
[4] Barbir, A., Batuner, O., Srinivas, B., Hofmann, M., and H.
Orman, "Security Threats and Risks for Open Pluggable Edge
Services (OPES)", RFC 3837, August 2004.
[4] Barbir、A.、Batuner、O.、Srinivas、B.、ホフマン、M.、およびH.Orman、「開いているPluggableのための軍事的脅威とリスクはサービス(作品)を斜めに進みます」、RFC3837、2004年8月。
9.2 Informative References
9.2 有益な参照
[5] Barbir A., Burger, E., Chen, R., McHenry, S., Orman, H., and R.
Penno, "Open Pluggable Edge Services (OPES) Use Cases and
Deployment Scenarios", RFC 3752, April 2004.
[5] Barbir A.、バーガー、E.、チェン、R.、マクヘンリー、S.、Orman、H.、およびR.ペンノ、「開いているPluggable縁のサービス(作品)はケースと展開シナリオを使用します」、RFC3752、2004年4月。
[6] Floyd, S. and L. Daigle, "IAB Architectural and Policy
Considerations for Open Pluggable Edge Services", RFC 3238,
January 2002.
[6] フロイドとS.とL.Daigle、「開いているPluggable縁のサービスのためのIAB建築するのと方針問題」、RFC3238、2002年1月。
[7] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000.
[7] IABとIESG(「盗聴に関するIETF方針」、RFC2804)は2000がそうするかもしれません。
10. Acknowledgements
10. 承認
Several people has contributed to this work. Many thanks to: Alex Rousskov, Hilarie Orman, Oscar Batuner, Markus Huffman, Martin Stecher, Marshall Rose and Reinaldo Penno.
数人はこの仕事に貢献しました。 以下のことのためにありがとうございます。 アレックスRousskov、Hilarie Orman、オスカーBatuner、マーカス・ハフマン、マーチン・ステッチャー、マーシャル・ローズ、およびレイナルド・ペンノ。
11. Author's Address
11. 作者のアドレス
Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada
アビーBarbirノーテルは3500縦梁アベニューネピアン、オンタリオのK2H8の9Eのカナダをネットワークでつなぎます。
Phone: +1 613 763 5229 EMail: abbieb@nortelnetworks.com
以下に電話をしてください。 +1 5229年の613 763メール: abbieb@nortelnetworks.com
Barbir Informational [Page 13] RFC 3897 OPES Entities & End Points Communication September 2004
Barbirの情報[13ページ]のRFC3897作品実体とエンドポイントコミュニケーション2004年9月
12. Full Copyright Statement
12. 完全な著作権宣言文
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
彼が代理をするか、または(もしあれば)後援される/S、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄して、急行か暗示していて、含んでいる他はあらゆる保証です。「そのままで」という基礎と貢献者の上でこのドキュメントとここに含まれた情報を提供して、組織が彼である、情報の使用はここにどんな権利か市場性のどんな黙示的な保証か特定目的への適合性も侵害しないでしょう。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Barbir Informational [Page 14]
Barbir情報です。[14ページ]
一覧
スポンサーリンク
