[要約] RFC 3897は、OPESエンティティとエンドポイントの通信に関する仕様です。その目的は、OPESアーキテクチャの実装と相互運用性を向上させることです。
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
プラグ可能なエッジサービス（OPES）エンティティを開き、エンドポイント通信
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）The Internet Society（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.
Open Pluggable Edge Services（OPES）アーキテクチャ[1]により、データプロバイダー、データ消費者、およびゼロ以上の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.
キーワードは「必要」、「必要」、「必須」、「shall」、「shall "、" sulld "、" nove "、" becommended "、" "、" 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.
上記の定義は、2つのOPESシステム[クライアント側とサーバー側のOPESシステムが同時に同じメッセージを処理できる]を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).
たとえば、忙しいWebサイトに代わって画像を配信するコンテンツ配信ネットワーク（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 Trace：メッセージを適応させた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トレースには2つの異なる用途があります。まず、トレースにより、「終了」が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エンティティを識別できます。管理者は、トレースを使用して、他のメッセージ固有の情報とともにApplied Adaptation Servicesを識別できます。
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プロセッサは、Callout Serviceを使用してすべての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.
この仕様は、プライバシーポリシー、ポリシー執行、または参照有効性または技術的連絡という用語の意味を定義せず、その情報のエンコード、言語、形式、またはその他の側面に関する要件は含まれていません。たとえば、OPESシステムトレースエントリに使用されるURIは、「http：// www.examplecompany.com/opes/?client=example.com」のように見える場合があります。上記が必要です。
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システム管理者は、Callout Serversがアプリケーションメッセージにトレース情報を追加できるかどうか、およびどの条件下で決定します。
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コンテンツが存在する場合、データ消費者アプリケーションがデータプロバイダーアプリケーションからコンテンツの非OPEバージョンを取得できないことを要求しています。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）に対処する際には、非OPEコンテンツを構成するものを指定する必要があります。この作業では、「非オープ」コンテンツの定義はプロバイダーに依存しています。場合によっては、「非オープ」コンテンツの可用性は、OPESプロバイダーのサービスを契約した特定の組織の内部ポリシーの関数になります。たとえば、A Company Aは、すべての電子メール添付ファイルでウイルスチェックを実行するためにOPESプロバイダーと契約を結んでいます。会社Aの従業員Xは、ウイルススキャンサービスの非ブロッキングリクエストを発行できます。OPESプロバイダーは、Company 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).
非OPEコンテンツの可用性は、コンテンツプロバイダー（または消費者またはその両方）ポリシーと展開シナリオの関数になります[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システム自体のバイパスには、非OPEメカニズムが必要であり、この仕様範囲外です。バイパスは、通常、アプリケーションメッセージに埋め込まれたバイパスの命令を要求します。
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プロセッサがバイパス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コンテンツが利用できない場合、そのサービスのバイパス要求は無視する必要があります。この設計は、非OPEのコンテンツの存在を検出したり、テスターが非OPEのコンテンツが存在するかどうかを知らない環境でバイパスルールの違反を検出することが不可能であることを意味します。このデザインは、ほとんどのバイパスリクエストが、望ましくない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仕様で定義される場合があります。この作業は、直接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システムがOPESの「終了」によって識別されるサービスをバイパスすることを意味します。o OPESシステムは、非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システムでのバイパス機能のデバッグ（またはデータ消費者ユーザーエクスペリエンス）を容易にするために、バイパス型のエンティティがバイパス命令を無視した理由に関連する情報が含まれている場合、有益です。場合によっては、追跡施設自体が壊れており、オペスシステム全体（または一部）をバイパス命令の問題を通じてバイパスする必要がある場合があることに注意することが重要です。
Bypass requirements for OPES processors are (the availability of a non-OPES content is a precondition):
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 既知の通信から既知のオペスエンティティを識別しない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およびその他のプロトコルに対応します。これらのドキュメントは、必要に応じてTRACE情報の順序に対処する必要があります。
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.
コンプライアンスの主題は、適用されるすべての「必須」および「必要な」レベル要件を満たしている場合、準拠しています。定義上、「マスト」レベルの要件を満たすことは、要件で規定されているとおりに行動することを意味します。「必要な」レベルの要件を満たすことは、要件によって規定されているように行動するか、異なる行動をとる理由を持つことを意味します。主題が主題に指示（アドレス）を指示する場合、主題に要件が適用されます。
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.
非公式には、このドキュメントへのコンプライアンスは、「既知の「必須」違反がなく、「すべての」違反が意識していることを意味します。言い換えれば、「すべき」は、「違反する理由を満たすか、または違反する理由がなければならない」という意味です。コンプライアンスのクレームには、適切な形式でサポートされていない肩（もしあれば）のリストが添付され、好みの動作が選択されなかった理由を説明することが期待されています。
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]の引用されていない大文字のキーワードを含む「規範」、定義、およびフレーズを使用して明示的にマークされた部分。その結果、例とイラストは規範的ではありません。
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.
OPEのセキュリティ上の考慮事項は[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.
トレース情報はプロトコル拡張であるため、これらのトレースは、非OPEエンティティによってデータフローに注入できます。この場合、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.
侵害されたTRACE情報を使用して、DOS攻撃を起動することができます。DOS攻撃は、OPESフローでデータコンシューマーアプリケーションまたはOPESエンティティを圧倒する可能性があります。間違ったトレース情報を挿入すると、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エンティティをバイパスすることができます。攻撃は、攻撃が本質的に負荷分散技術をバイパスするため、元のコンテンツプロバイダーサーバーを圧倒する可能性があります。さらに、このような攻撃は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エンティティが含まれる場合があるため、侵入者がデータパスにバイパス命令を注入することができます。これらの攻撃は、コンテンツの可用性に影響を与えるか、ネットワーク内の負荷分散技術を妨害する可能性があります。
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エンティティを妥協し、中間のテクニックを使用して、データ消費者アプリケーションへのコンテンツの可用性を乱すか、コンテンツプロバイダーサーバー（基本的には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.、Chen、R.、Hofmann、M。、およびH. Orman、「Open Pluggable Edge Services（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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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.、Beck、A.、Chan、T。、およびH. Orman、「Open Pluggable Edge Services（OPES）のポリシー、承認、および執行要件」、RFC 3838、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.、Hofmann、M。、およびH. Orman、「Open Pluggable Edge Services（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.、Burger、E.、Chen、R.、Mchenry、S.、Orman、H。、およびR. Penno、「Open Pluggable Edge Services（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] Floyd、S。and L. Daigle、「Open Pluggable Edge Servicesの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.
この作業に何人かの人々が貢献しています。Alex Rousskov、Hilarie Orman、Oscar Batuner、Markus Huffman、Martin Stecher、Marshall Rose、Reinaldo Pennoに感謝します。
Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada
Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean、オンタリオK2H 8E9カナダ
Phone: +1 613 763 5229
EMail: abbieb@nortelnetworks.com
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」と貢献者、彼が代表する組織（もしあれば）が後援する組織、インターネット社会、インターネットエンジニアリングタスクフォースがすべての保証を拒否し、表明または、ここでの情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。