Network Working Group A. Barbir
Request for Comments: 3897 Nortel Networks
Category: Informational September 2004
Open Pluggable Edge Services (OPES) Entities
and End Points Communication
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This memo documents tracing and non-blocking (bypass) requirements for Open Pluggable Edge Services (OPES).
このメモ文書はトレースとオープンプラグイン可能なエッジ・サービス（OPES）のために（バイパス）の要件を非ブロック。
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
11. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14
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.
[1]開きプラガブルエッジサービス（OPES）アーキテクチャは、データプロバイダ、データコンシューマ、およびゼロ以上OPESプロセッサ間の連携アプリケーションサービス（OPESサービス）を可能にします。検討中のアプリケーションサービスは、分析し、おそらくデータプロバイダとデータコンシューマの間でやり取りするアプリケーションレベルのメッセージを変換します。
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.
この作品は、OPESトレースおよびバイパス機能を指定します。 [1]アーキテクチャ文書は、トレースがインバンドに支持されていることを必要とします。この設計目標は、OPESがサポートできるアプリケーションプロトコルの種類を制限します。トレースレコードを伝えることができるものの詳細については、アプリケーションレベルのプロトコルの選択に依存しています。これらの理由から、この作品は文書のみトレースとバイパス機能をサポートするために必要なOPESエンティティのための要件を。符号追跡及びバイパス機能のタスクは、特定のアプリケーションプロトコルです。別々の文書は、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.
アーキテクチャは、トレースとバイパスに対処するために、アウトオブバンドプロトコルおよび技術の開発から実装を防ぐことはできません。このようなプロトコルは、現在の作業の範囲外です。
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"、 "MUST NOT"、 "REQUIRED" は、 "NOT SHALL" "ものと" この文書では、 "SHOULD"、 "推奨" "NOT SHOULD"、 "MAY"、 "OPTIONAL" はにありますBCP 14、RFC 2119に記載されているように[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.
このセクションでは、OPESシステムの定義を提供します。これは、OPESフローにトレーサブル（またはバイパス）であるかを定義するために必要とされています。
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.
定義：OPESシステムは、データプロバイダまたは指定されたアプリケーションメッセージを処理するためのデータコンシューマ・アプリケーションのいずれかによって認可すべてOPESエンティティのセットです。
The nature of the authorization agreement determines if authority delegation is transitive (meaning an authorized entity is authorized to include other entities).
権限委譲が推移（権限のある機関は、他のエンティティを含めることが許可されているという意味）である場合、認可契約の性質が決定されます。
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.
特定の権限の契約が再委任に対して許可している場合、OPESシステムは、誘導によって形成することができます。この場合、OPESシステムは、直接データプロバイダ（またはデータコンシューマ）アプリケーションによって認可実体から始まります。 OPESシステムは、次にOPESシステムにすでに存在するエンティティによって許可任意OPESエンティティを含みます。権限委譲は、常に与えられたアプリケーションメッセージのコンテキストで表示されます。
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.
OPESシステムは、アプリケーションメッセージに基づいて定義されます。メッセージ処理に関与している意味するものではありませんメッセージを処理する権限を有します。したがって、いくつかのOPESシステム・メンバーは、メッセージの処理に関与しなくてもよいです。同様に、いくつかのメンバーは、同じメッセージを複数回処理することができます。
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.
上記の定義は、所与の時間に同じメッセージを処理[同時に同じメッセージを処理することができるクライアント側およびサーバ側OPESシステム】なしつ以上のOPESシステムが存在し得ることを意味します。これは、単一のデータ・プロバイダとまで与えられたアプリケーションメッセージに関しては、単一のデータコンシューマが存在するという仮定に基づいています。
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).
例えば、忙しいウェブサイトに代わって画像を提供するコンテンツ配信ネットワーク（CDN）を検討してください。 CDNは適応して画像を配信するために使用OPESプロセッサ及びサービスは、OPESシステムを含みます。より複雑な例では、OPESシステム（例えば、画質を調整するために）CDNは、適応を実行するように係合する第三者OPESエンティティを含むであろう。
The definition of OPES trace and tracing are given next.
OPESトレースとトレースの定義は次の与えられています。
OPES trace: application message information about OPES entities that adapted the message.
OPESトレース：メッセージを適応OPESエンティティに関するアプリケーションメッセージ情報。
OPES tracing: the process of creating, manipulating, or interpreting an OPES trace.
OPESトレース：作成、操作、またはOPESトレースを解釈するプロセス。
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).
上記のトレース定義は、インバンドトレースを前提としています。必要に応じて、この依存性を除去することができます。トレースは、メッセージごとに行われます。トレースフォーマットが適合されているアプリケーション・プロトコルに依存しています。追跡可能なエンティティは、（例えば、すべての時間は、それがメッセージに作用する）トレースに複数回出現することができます。
This section focuses on identifying traceable entities in an OPES Flow.
このセクションでは、OPESフローで追跡可能なエンティティを特定することに焦点を当てています。
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).
トレース情報は、データを適応OPESエンティティに関する情報を「終了」を提供します。 OPESトレースの二つの異なる用途があります。まず、トレースがOPESシステムの存在を検出するために、「終わり」を可能にします。このような「終了」トレース項目を見ることができるはずですが、OPESシステムの識別および特定の必須OPES関連の開示（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.
第二に、OPESシステム管理者は、OPESトレースの内容を解釈することができると期待されます。トレースは、不透明なデータ（例えば、TCPパケットまたはHTTPメッセージスナップショット）として、解釈されずに「終了」によって管理者に中継することができます。管理者は、参加OPESエンティティを識別するために、トレース情報を使用することができます。管理者は、他のメッセージに固有の情報と一緒に適用される適応サービスを識別するために、トレースを使用することができます。
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.
様々なOPESシステムの管理者は、トレースに探してのさまざまな方法を持つことができるので、トレース・レコードに入れるに何で、どのようにそれらをフォーマットする自由が必要です。
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.
それについての情報がそのトレースに表示されている場合、実装レベルでは、与えられたトレースのために、対応するアプリケーションのメッセージの処理に関与OPESエンティティがトレーサブルまたはトレースさです。この作品は、その情報をどのような順序を指定しません。トレース内の情報の順序は、OPESシステムに特異的であり得るか、アプリケーションのバインディングの文書によって定義することができます。
OPES entities have different levels of traceability requirements. Specifically,
OPESエンティティは、トレーサビリティ要件の異なるレベルを持っています。具体的には、
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 OPESシステムは、トレースにそのエントリを追加する必要があります。 O OPESプロセッサは、トレースにそのエントリを追加する必要があります。 O OPESサービスは、トレースにそのエントリを追加するかもしれません。 O OPESエンティティは、別のOPESエンティティにそのトレース項目の追加を委任することができます。例えば、OPESシステムは、システムのエントリを追加するための専用のOPESプロセッサを有することができます。 OPESプロセッサは、（このような操作がOPES適応しているので）すべてOPESトレース操作を管理するためにコールアウトサービスを利用することができます。
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.
OPESの文脈では、優れたトレース・アプローチは、既知のアドレスに提出する準備ができてトラブルチケットに似ています。アドレスは、チケットに印刷されています。それ自体はトレースは必ずしも何が起こったのかの詳細な説明ではありません。これは、トレースの詳細をデコードすると、問題を解決するためのオペレータの責任です。
The following requirements document actions when forming an OPES System trace entry:
OPESシステムのトレースエントリを形成する場合は、以下の要件がアクションを文書化：
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 OPESシステムは、そのトレース項目に独自の識別情報を含まなければなりません。ここでは、一意性のスコープは、トレースされたメッセージを適合させることができることすべてOPESシステムです。 O OPESシステム間およびイントラ文書参照妥当性への影響を定義しなければなりません。 O OPESシステムが設定したポリシーを強制する責任者の識別を含む、そのプライバシーポリシーについての情報を含まなければなりません。 O OPESシステムは、技術的な連絡先に、メッセージの処理に関与するOPESプロセッサを識別する情報を含むべきです。必要な情報を提供する場合、O、OPESシステムは、いくつかの必要な項目を含むリソースを識別するために、単一のURIを使用するかもしれません。例えば、OPESシステムは、システムのプライバシーポリシーおよび技術的な連絡先情報を参照して、単一のWebページを指すことができます。
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.
この仕様は、規約プライバシーポリシー、ポリシー適用、または参照妥当性や技術的な接触の意味を定義し、エンコーディング、言語、形式、またはその情報の任意の他の側面に関していかなる要件が含まれていません。 「：// www.examplecompany.com/opes/?client=example.comのhttp」が特定のウェブページを動的に生成し、含まれるすべてのOPESシステム情報たとえば、URIは次のように見えるかもしれOPESシステムのトレース・エントリーのために使用さ上記必要。
The following requirements document actions when forming an OPES System trace entry:
OPESシステムのトレースエントリを形成する場合は、以下の要件がアクションを文書化：
o OPES processor SHOULD add its unique identification to the trace. Here, uniqueness scope is the OPES System containing the processor.
O OPESプロセッサは、トレースにその固有の識別を追加する必要があります。ここでは、一意性のスコープは、プロセッサを含むOPESシステムです。
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.
OPESシステムでは、アプリケーションメッセージにトレースレコードを追加するためOPESプロセッサの作業です。条件コールアウトサーバは、アプリケーション・メッセージにトレース情報を追加している場合、どのような下OPESシステム管理者が決定します。
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] OPESアーキテクチャは、非OPESコンテンツが存在することを条件とする、データ・プロバイダ・アプリケーションからのコンテンツの非OPESバージョンを取得からのデータ・コンシューマ・アプリケーションを妨げないことを必要とします。 IAB勧告（3.3）は、非ブロッキング機能（バイパス）は（彼らはいくつかの方法によって、同定された後）故障OPES仲介をバイパスするために使用することを示唆しています。
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）アドレッシングでは、一方が非OPESコンテンツを構成するものを指定する必要があります。この作品では、「非OPES」コンテンツの定義は、プロバイダに依存しています。いくつかのケースでは、「非OPES」コンテンツの利用可能性は、OPESプロバイダのサービスを契約している特定の組織の内部方針の関数とすることができます。例えば、A社は、すべての電子メールの添付ファイルにウイルスチェックを実行するためOPESプロバイダとの契約として持っています。 A社の従業員Xは、ウイルススキャンサービスのノンブロッキング要求を発行することができます。それはA社との契約と矛盾するので、リクエストはOPESプロバイダによって無視することができ
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).
非OPESコンテンツの利用可能性は、コンテンツプロバイダ（又は消費者あるいはその両方）、ポリシーおよび配備シナリオの関数とすることができる[5]。このため、この作業は非OPESコンテンツとは対照的に、OPESコンテンツであるかを定義しようとしません。非OPESコンテンツ対OPESの意味はOPESプロバイダ、データプロバイダ及び/又はデータコンシューマの間の様々な合意によって決定されているものとします。契約は、OPESサービスをバイパスし、どのような順序（該当する場合）にすることができるかを決定します。
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.
OPESサービスのこの仕様書のバイパスまたはURIで識別されるサービスのグループ。この文脈において、OPESフロー内の指定されたアプリケーション・メッセージは、「サービスをバイパス」することは、そのアプリケーション・メッセージは、「サービスを起動しない」ことを意味します。 OPESシステム（プロセッサ）を識別するバイパスURIは、OPESシステム（プロセッサ）に接続されているすべてのサービスを一致します。しかし、OPESプロセッサとOPESシステム自体のバイパスは、非OPES機構を必要とし、この仕様の範囲外です。命令はバイパスするバイパス要求は、通常、アプリケーション・メッセージに埋め込まれました。
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.
現在の仕様では、「バイパスこのサービスが、それはそのOPESシステムの一部である場合にのみ」ではなく、このOPESシステムのOPESシステムのあるいは「バイパス全てのサービスに指定することをお許可メカニズムと「終わり」のために提供されていません。 」。 OPESプロセッサがバイパスURIがそのサービスと一致しないことを確かに知っていない場合はさらに、それは、そのサービスをバイパスしなければなりません。
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.
何の非OPESコンテンツが指定されたサービスをせずに利用されていない場合は、そのサービスのためのバイパス要求は無視されなければなりません。この設計は、非OPESコンテンツの存在を検出するか、テスターが非OPESコンテンツが存在するかどうかを知らない環境でバイパスルールの違反を検出することができないかもしれないことを意味します。この設計では、ほとんどのバイパス要求が望ましくないOPESのコンテンツを提供することは一切好ましい非OPESコンテンツが存在しないエラーメッセージを提供するよりも優れている状況のために意図されていることを前提としています。
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キャッシュにあるようOPESサービスを誤動作することがあります。バイパスの主な目的は、サービス障害の存在下で使用可能なコンテンツを取得すると何が起こっているかについての詳細とコンテンツ消費者に提供することはありません。 OPESトレースではなく、後者のために使用すべきです。
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.
この作業は「バイパスサービス可能な場合」機能を定義しながら、適合され及び/又はアプリケーションプロトコルにOPESで実施することができる他の関連のバイパス機能があります。例えば、「バイパスサービスまたはエラー発生」又は「バイパスOPESエンティティまたはエラーを生成」。このようなサービスは壊れたOPESシステムをデバッグするために有用であろうと、他のOPES仕様で定義されてもよいです。この作品は、直接IABの懸念に対処するユーザレベルのバイパス機能を文書に集中します。
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.
この作品では、フォーカスは、ユーザーがそのサービスの一部または全てをバイパスするOPESシステムに指示することを可能にするバイパス機能を開発することにあります。バイパスすることができOPESサービスのコレクションは、コンテンツプロバイダまたはコンテンツのコンシューマ・アプリケーションのどちらか（あるいは両方）とOPESプロバイダの契約の関数です。一般的な場合では、バイパス要求はOPESエンティティまたはバイパスするサービス（又はサービス）を実行OPESエンティティのグループを識別するURIを含むバイパス命令と見なされます。命令は、複数のそのようなURIが含まれていてもよいです。特別なワイルドカード識別子は、すべての可能な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.
OPESフローでは、バイパス要求は、各関与OPESプロセッサによって処理されます。これは、OPESプロセッサは、バイパス命令を検査し、非OPESコンテンツが利用可能である場合、プロセッサは、次に示すサービスをバイパスすることを意味します。要求は、OPESフローの次のOPESプロセッサに転送されます。次OPESプロセッサは、その後にかかわらず、以前のプロセッサアクションの、すべてのバイパス要求を処理します。処理チェーンは、OPESフローに関与している全プロセッサ全体で続けています。
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.
OPESシステムでは、バイパス要求は、一般的に、クライアントの中心で（データコンシューマ・アプリケーションから発信）や要求をトレースの反対方向に行きます。この作業は、バイパス機能は、アプリケーション特定プロトコルの拡張としてインバンドで実行されることを必要とします。非OPESエンティティは、安全にこれらの拡張機能を無視することができるはずです。作業は、バンドのプロトコルのうち、自分自身を開発してからOPESシステムを防ぐことはできません。
The following requirements apply for bypass feature as related to an OPES System (the availability of a non-OPES content is a precondition):
以下の要件は、OPESシステム（非OPESコンテンツの利用可能性が前提条件である）に関連するように、バイパス機能のために適用されます。
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 OPESシステムは、バイパス機能をサポートしなければなりません。これは、OPESシステムは、そのURIをOPES「終わり」で識別されているサービスをバイパスすることを意味します。非OPESのバージョンが使用できない場合O OPESシステムは、コンテンツのOPESのバージョンを提供しなければなりません。
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.
非バイパスエンティティは、彼らがバイパス命令を無視する理由に関連する情報が含まれている場合OPESシステムにおけるバイパス機能のデバッグ（またはデータ、消費者のユーザーエクスペリエンス）を容易にするために、それは有益であろう。いくつかのケースでトレース機能自体が破損する可能性があることに注意することが重要であり、全体OPESシステム（またはその一部）のバイパス命令の発行によりバイパスされる必要があるかもしれません。
Bypass requirements for OPES processors are (the availability of a non-OPES content is a precondition):
OPESプロセッサのバイパス要件は（非OPESコンテンツの利用可能性が前提条件である）です。
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 OPESプロセッサは、バイパス命令を解釈して処理することができるべきです。この要件は、未知のツー受信者サービスを識別するものを含め、すべてのバイパス命令に適用されます。 O OPESプロセッサは次のホップがOPESバイパスをサポートしてアプリケーションプロトコルを話すことを条件とする次のアプリケーションホップへのバイパス要求を転送しなければなりません。 O OPESプロセッサは、それがサービス（複数可）の実行だバイパスすることができるべきです。
OPES processors that know how to process and interpret a bypass instruction have the following requirements:
バイパス命令を処理し、解釈する方法を知っているOPESプロセッサは、次の要件があります。
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任意の既知のツー受信者OPESエンティティを識別しないURIとバイパス命令の受信者は、URIがワイルドカード識別子として（バイパスに適用されるすべてのサービスを意味する）ことを扱わなければなりません。
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.
OPESシステムでは、バイパス要求を処理するOPESプロセッサのタスクです。場合、どのような条件のコールアウト・サーバ・プロセスのバイパス要求の下OPESシステム管理者が決定します。
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などのプロトコルに対応します。必要に応じてこれらの文書は、トレース情報の順序に対処しなければなりません。
This specification defines compliance for the following compliance subjects: OPES System, processors, entities and callout servers.
OPESシステム、プロセッサ、エンティティとコールアウトサーバ：この仕様は、次のコンプライアンス被験者に対するコンプライアンスを定義します。
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」レベルの要件は、要件によって規定として作用することを意味満足します。要件によって規定さまたは異なる動作をする理由を持っているとして満たすためには、「すべきである」レベルの要件は、行為のいずれかに意味します。それは（アドレス）対象を指示した場合の要件は、対象に適用されます。
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」違反が意識していることを意味します。言い換えれば、「満足しなければならないかに違反する理由がなければならない」を意味し、「すべきです」。有利な行動が選択されなかった理由を説明する、適切な形式で、コンプライアンスクレームはサポートされていない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.
この仕様書の規範的部分だけは、コンプライアンスに影響を与えます。規範的部分は、以下のとおりです。明示的に単語「規範」を使用してマーク部品、定義、およびRFC 2119から引用符で囲まれていない大文字のキーワードを含むフレーズ[2]。その結果、実施例およびイラストは規範的ではありません。
This specification contains no IANA considerations. Application bindings MAY contain application-specific IANA considerations.
この仕様にはIANAの考慮事項が含まれていません。アプリケーションのバインディングは、アプリケーション固有のIANAの考慮事項を含むかもしれません。
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.
OPESのためのセキュリティ上の考慮事項は、[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.
この文書では、トレースおよびバイパス機能の要件文書です。この文書に記載された要件は、これらの機能をサポートするために、アプリケーションレベルのプロトコルを拡張するために使用することができます。そのため、作業はセキュリティ対策を持っています。
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.
OPESアーキテクチャのトレース機能は、プロトコルの拡張として実装されます。トレース機能の不十分な実装では、OPESアーキテクチャに組み込まれた安全策を打ち負かすことがあります。それ自体でトレース機能は、悪意のある攻撃の対象やOPESシステム上の昼食攻撃に使用さになることができます。
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.
トレース機能によって、またはに対して引き起こされる脅威はOPESフローのアプリケーションレベルでの脅威と見なすことができます。この場合、脅威は、データコンシューマとデータプロバイダのアプリケーションに影響を与えることができます。
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.
情報を追跡することは、プロトコルの拡張機能であるため、これらのトレースは、非OPESエンティティによってデータフローに注入することができます。この場合、非OPESエンティティはその脅威OPESシステムの全体的な整合性と有効性の方法で妥協できることリスクがあります。例えば、非OPESプロキシは、トレースに偽のトレース情報を追加することができます。これは間違っている、または不要な、または非存在しないサービスの形で行うことができます。非OPESエンティティは、データ・コンシューマ・アプリケーションでバッファオーバーフローを引き起こす可能性が大型トレースを注入することができます。同じ脅威は妥協OPESエンティティから生じ得ます。攻撃者は、OPESエンティティを制御し、OPESフローで終了、または次OPESエンティティを圧倒することができ、間違った、または非常に大規模なトレース情報を注入することができます。同様の脅威は、信頼できるOPESエンティティにおけるトレース機能の悪い実装に起因することができます。
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.
妥協のトレース情報が不要なコンテンツ変換がデータに対して実行されたという印象を与えるOPESシステムへの攻撃を起動するために使用することができます。これは間違った実体（例えばOPESプロセッサ）識別子を挿入することによって達成することができます。妥協トレースは、全体的なメッセージの整合性の構造に影響を与えることができます。これは、会計、負荷分散、または参照ベースのサービスなどのサービスを実行するために、メッセージのヘッダー情報を使用するエンティティに影響を与えることができます。
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.
妥協トレース情報は、OPESフロー内のデータコンシューマ・アプリケーションやOPESエンティティを圧倒することができますDoS攻撃を起動するために使用することができます。間違ったトレース情報を挿入するOPESシステムの動作のトラブルシューティング時に、システム管理者が行うデバッグ作業を複雑にすることができます。
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].
予防措置として、OPESエンティティは挿入トレースが法的OPESエンティティによって実行されることを確認することが可能であるべきです。これは、認可および認証顔の一部として行うことができます。ポリシーは、ピアエンティティから期待できるものをトレース情報を示すために使用することができます。他のアプリケーション・レベルの関連するセキュリティ上の懸念は、[4]に見出すことができます。
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.
OPESアーキテクチャのバイパス機能は、プロトコルの拡張として実装されます。バイパス設備の不十分な実装では、OPESアーキテクチャに組み込まれた安全策を打ち負かすことがあります。それ自体でバイパス設備は、悪意のある攻撃の対象やOPESシステム上の昼食攻撃に使用さになることができます。
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.
バイパス機能によって、またはに対して引き起こされる脅威はOPESフローのアプリケーションレベルでの脅威と見なすことができます。この場合、脅威は、データコンシューマとデータプロバイダのアプリケーションに影響を与えることができます。
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.
これらのエンティティは、OPESフローにバイパス命令を挿入することができる、非OPESエンティティによるOPESシステムのリスクがあります。脅威は妥協非OPESエンティティから来ることができます。脅威はOPESシステムの全体的な整合性と有効性に影響する可能性があります。例えば、非OPESプロキシは、正当なOPESエンティティをバイパスするバイパス命令を追加することができます。攻撃は、本質的に任意の負荷分散技術をバイパスするので攻撃は、オリジナルのコンテンツプロバイダサーバを圧倒する可能性があります。加えて、このような攻撃はまた、DoS攻撃に相当し、それによって、正当なデータ・コンシューマ・アプリケーションは、コンテンツプロバイダまたはそのOPESバージョンからいくつかのコンテンツにアクセスすることができないかもしれません。
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.
OPESフローが非OPESエンティティを含むことができるので、侵入者はデータ経路にバイパス命令を注入することができることにより、それは、man-in-the-middle攻撃を受けやすいです。これらの攻撃は、コンテンツの可用性に影響を与えたり、ネットワークに負荷分散技術を妨害することがあります。
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).
上記の脅威にも妥協OPESエンティティによって発生する可能性があります。侵入者は、OPESエンティティを妥協して、コンテンツ・プロバイダ・サーバをデータコンシューマ・アプリケーションへのコンテンツの可用性を妨げたりオーバーロードするのman-in-the-middle手法を使用することができます（基本的に、DoS攻撃のいくつかの形式）。
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.
攻撃者は、OPESシステムの全体的な整合性に影響を与えるためにバイパス命令を使用することができます。データフローにバイパス命令を導入する能力は、OPESシステムの会計処理に影響を与え得ます。また、データコンシューマアプリケーションに配信されるコンテンツの品質に影響を与える可能性があります。同様の脅威はバイパス設備の悪い実装に起因することができます。
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.
一貫性のないまたは選択的バイパスも脅威です。ここでは、一方の端部は、得られたコンテンツは、そのコンテンツを処理（およびそのコンテンツが完全かつ有効であることを期待）不正な形式とクラッシュしたり、妥協のエンティティであるように、OPESエンティティのサブセットを迂回しようとすることができます。実装者は、処理ループから消えるために不可欠なサービスを期待していないので、このような例外は、多くの場合、テストされていません。
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.
その他の脅威はOPESエンティティのためのアクセス制御ポリシーの設定から生じ得ます。 OPESエンティティを介してアクセス制御を実現するシステムが誤ってバイパスを尊重し、従って、侵入者への不正アクセスを与えるように構成することができる可能性があります。
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.
タップバイパスも脅威となることがあります。 OPESエンティティを介して盗聴を実装するシステムが誤ってバイパスを尊重し、従って、タップ操作または記録されている必要があり、バイパス命令でトラフィック（未検出のまま）を無視するように構成することができるからです。一端が受信側でそのようなウイルススキャンなどのサービスをバイパスすることも可能です。この脅威は、ネットワーク全体にウイルスを注入するためにハッカーによって使用することができます。盗聴のIETFポリシー[7]に続き、OPES通信モデルは、盗聴の要件を考慮していません。それにもかかわらず、文書化の脅威は明らかではない、本物である、と盗聴または類似のロギング環境で動作OPES技術のユーザーはそれを認識する必要があります。
Other application level related security concerns can be found in [4].
他のアプリケーション・レベルの関連するセキュリティ上の懸念は、[4]に見出すことができます。
[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.、Penno、R.、陳、R.、ホフマン、M.、およびH.オーマン、 "オープン・プラグイン可能なエッジサービスのためのアーキテクチャ（OPES）"、RFC 3835、2004年8月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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.オーマン、 "政策、オープンプラグイン可能なエッジ・サービス（OPES）の認可、および施行の要件"、RFC 3838、8月2004。
[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.、スリニバス、B.、ホフマン、M.、およびH.オーマン、 "オープン・プラグイン可能なエッジサービスのセキュリティ脅威とリスク（OPES）"、RFC 3837、2004年8月。
[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.、オーマン、H.、およびR. Penno、 "オープン・プラグイン可能なエッジサービス（OPES）はケースと展開シナリオを使用する"、RFC 3752、 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氏、 "オープン・プラグイン可能なエッジサービスのためのIAB建築・ポリシーに関する注意事項"、RFC 3238、2002年1月。
[7] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000.
[7] IABとIESG、 "盗聴のIETF方針"、RFC 2804、2000年5月。
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、ヒラリーオーマン、オスカーBatuner、マーカス・ハフマン、マーティンStecher、マーシャルローズとレイナルドPenno：に感謝します。
Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada
アビーBarbir Nortel Networksの3500カーリングアベニューオタワ、オンタリオK2H 8E9カナダ
Phone: +1 613 763 5229 EMail: abbieb@nortelnetworks.com
電話：+1 613 763 5229 Eメール：abbieb@nortelnetworks.com
Copyright (C) The Internet Society (2004).
著作権（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とHEが表すCONTRIBUTOR、ORGANIZATION HE / S OR（もしあれば）後援されており、インターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示、「そのまま」で提供されていますOR情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証を含むがこれらに限定されないで、黙示。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 IETF文書の権利に関するIETFの手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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機能のための基金は現在、インターネット協会によって提供されます。