RFC 4375 - Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain 日本語訳

URL : https://tools.ietf.org/html/rfc4375
タイトル : RFC 4375 - 緊急通信サービス（ETS）単一の管理ドメインのための要件
翻訳編集 : 自動生成

Network Working Group                                        K. Carlberg
Request for Comments: 4375                                           G11
Category: Informational                                     January 2006

       Emergency Telecommunications Services (ETS) Requirements
                   for a Single Administrative Domain

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.

このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。

著作権表示

著作権（C）インターネット協会（2006）。

Abstract

抽象

This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within a single administrative domain. This document focuses on a specific set of administrative constraints and scope. Solutions to these requirements are not presented in this document.

この文書では、単一の管理ドメイン内の緊急通信サービス（ETS）をサポートする要件のリストを提示します。この文書では、管理制約と範囲の特定のセットに焦点を当てています。これらの要件に対する解決策は、この文書で提示されていません。

1. Introduction

1. はじめに

The objective of this document is to define a set of requirements that support ETS within a single domain. There have been a number of discussions in the IEPREP mailing list, as well as working group meetings, that have questioned the utility of a given mechanism to support ETS. Many have advocated over-provisioning, while others have favored specific schemas to provide a quantifiable measure of service. One constant in these discussions is that the administrative control of the resources plays a significant role in the effectiveness of any proposed solution. Specifically, if one administers a set of resources, a wide variety of approaches can be deployed upon that set. However, once the approach crosses an administrative boundary, its effectiveness comes into question, and at a minimum requires cooperation and trust from other administrative domains. To avoid this question, we constrain our scenario to the resources within a single domain.

このドキュメントの目的は、単一のドメイン内でETSをサポートする一連の要件を定義することです。 ETSをサポートするために与えられたメカニズムの有用性を疑問視しているIEPREPメーリングリストでの議論の数だけでなく、ワーキンググループ会議、ありました。他の人がサービスの定量化指標を提供するために、特定のスキーマを支持しているが、多くは、オーバープロビジョニング提唱しています。これらの議論における一つの定数は、リソースの管理制御は、任意の提案された解決策の有効性に重要な役割を果たしていることです。 1は、一連のリソースを管理する場合は具体的に、アプローチの多種多様なそのセットに展開することができます。アプローチは行政境界を越えるしかし、一度、その有効性が問題となると、最低でも、他の管理ドメインからの協力と信頼が必要です。この質問を避けるために、我々は、単一のドメイン内のリソースへの私たちのシナリオを制約します。

The following provides an explanation of some key terms used in this document.

以下は、このドキュメントで使用されるいくつかの主要な用語の説明を提供します。

Resource: A resource can be a viewed from the general level as IP nodes such as a router or host as well as the physical media (e.g., fiber) used to connect them. A host can also be referred to in more specific terms as a client, server, or proxy. Resources can also be viewed more specifically in terms of the elements within a node (e.g., CPU, buffer, memory). However, this document shall focus its attention at the node level.

リソース：例えばルータやホスト、ならびに物理的媒体（例えば、ファイバ）としてIPノードは、それらを接続するために使用されるリソースは、一般的なレベルから見ることができます。ホストは、クライアント、サーバー、またはプロキシとしてより具体的に参照することができます。リソースは、ノード内の要素（例えば、CPU、バッファ、メモリ）の点で、より具体的に見ることができます。しかし、この文書は、ノード・レベルでその注意を集中しなければなりません。

Domain: This term has been used in many ways. We constrain its usage in this document to the perspective of the network layer, and view it as being synonymous with an administrative domain. A domain may span large geographic regions and may consist of many types of physical subnetworks.

ドメイン：この用語は、多くの方法で使用されてきました。私たちは、ネットワーク層の観点にこの文書に記載されているその使用を制限し、管理ドメインと同義であるとして、それを表示します。ドメインは、大きな地理的領域にまたがることができ、物理的サブネットワークの多くの種類から成ってもよいです。

Administrative Domain: The collection of resources under the control of a single administrative authority. This authority establishes the design and operation of a set of resources (i.e., the network).

管理ドメイン：単一の管理権限の制御下にあるリソースのコレクション。この権限は、リソースの集合（すなわち、ネットワーク）の設計および動作を確立します。

Transit Domain: This is an administrative domain used to forward traffic from one domain to another. An Internet Service Provider (ISP) is an example of a transit domain.

トランジットドメイン：これは、別のドメインからのトラフィックを転送するために使用される管理ドメインです。インターネットサービスプロバイダ（ISP）がトランジットドメインの一例です。

Stub Domain: This is an administrative domain that is either the source or the destination of a flow of IP packets. As a general rule, it does not forward traffic that is destined for other domains. The odd exception to this statement is the case of Mobile IP and its use of "dog-leg" routing to visiting hosts located in foreign networks. An enterprise network is an example of a stub domain.

スタブドメイン：これは、ソースまたはIPパケットのフローの宛先のいずれかである管理ドメインです。一般的なルールとして、それは他のドメイン宛のトラフィックを転送しません。この文の奇妙な例外は、モバイルIPおよび外部ネットワークにあるホストを訪問する「ドッグレッグ」ルーティングの使用の場合です。企業ネットワークは、スタブ領域の一例です。

1.1. Previous Work

1.1. 前作

A list of general requirements for support of ETS is presented in [RFC3689]. The document articulates requirements when considering the broad case of supporting ETS over the Internet. Since that document is not constrained to specific applications, administrative boundaries, or scenarios, the requirements contained within it tend to be quite general in their description and scope. This follows the philosophy behind its inception in that the general requirements are meant to be a baseline followed (if necessary) by more specific requirements that pertain to a more narrow scope.

ETSをサポートするための一般的な要件のリストは、[RFC3689]に提示されています。インターネット上でETSをサポートする広範なケースを検討する際の文書には、要件を明確に表現します。その文書は、特定のアプリケーション、管理境界、またはシナリオに制約されないので、その中に含まれる要件は、その説明と範囲ではかなり一般的になりがち。これは一般的な要件は、（必要な場合）、ベースラインは、より狭い範囲に関係するより具体的な要件が続くことを意味することを創業の背後にある考え方を以下に。

The requirements presented below in Section 3 are representative of the more narrow scope of a single administrative domain. As in the case of [RFC3689], the requirements articulated in this document represent aspects to be taken into consideration when solutions are being designed, specified, and deployed. Key words such as "MUST",

第3節では、以下に提示の要件は、単一の管理ドメインのより狭い範囲の代表的なものです。 [RFC3689]の場合と同様に、本書では、多関節の要件は、溶液は、設計指定され、展開されているときに考慮すべき側面を表します。こうした「MUST」などのキーワード、

"MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

に記載されているように、 "必須"、 "NOT MUST"、 "NOT SHALL"、 "べきではない"、 "推奨"、 "SHOULD" "SHALL"、 "MAY"、及び "OPTIONAL" 本書では[解釈されるべきですRFC2119]。

2. Scope

2.適用範囲

IETF standards that cover the resources within an administrative domain are within the scope of this document. This includes gateways, routers, servers, etc., that are located and administered within the domain. This document also does not restrict itself to a specific type of application such as Voice over IP.

管理ドメイン内のリソースをカバーするIETF標準規格は、この文書の範囲内です。これは、ドメイン内に位置して投与されるゲートウェイ、ルータ、サーバなどが含まれます。この文書はまた、ボイスオーバーIPなどのアプリケーションの特定のタイプに自分自身を制限するものではありません。

Quality of Service (QoS) mechanisms are also within the scope of this document. These mechanisms may reside at the application, transport, or IP network layer. While QoS mechanisms may exist at the link/physical layer, this document only considers potential mappings of labels or code points.

サービス品質（QoS）のメカニズムはこの文書の範囲内です。これらのメカニズムは、アプリケーション、輸送、またはIPネットワーク層に常駐してもよいです。 QoSメカニズムはリンク/物理層に存在し得るが、この文書は、ラベルまたはコードポイントの潜在的なマッピングを考慮する。

Finally, since this document focuses on a single administrative domain, we do not make any further distinction between transit and stub domains within this document.

このドキュメントは、単一の管理ドメインに焦点を当てているので最後に、私たちは、この文書内のトランジットとスタッブドメイン間の任意の更なる区別をしないでください。

2.1. Out of Scope

2.1. 範囲外

Resources owned or operated by other administrative authorities are outside the scope of this document. One example is a SIP server that operates in other domains. Another example is an access link connecting the stub domain and its provider. Controlling only 1/2 of a link (the egress traffic from the stub) is considered insufficient for including inter-domain access links as a subject for this document.

他の行政機関が所有または運営リソースは、このドキュメントの範囲外です。一例では、他のドメインで動作するSIPサーバです。別の例は、スタブドメインとそのプロバイダに接続するアクセスリンクです。リンクのみの1/2（スタブからの出力トラフィック）を制御することは、この文書の主題として、ドメイン間のアクセスリンクを含むためには不十分と考えられています。

3. Requirements

3.要件

It must be understood that all of the following requirements pertain to mechanisms chosen by a domain's administrative authority to specifically support ETS. If that authority chooses not to support ETS or if these mechanisms exist within the domain exclusively for a different purpose, then the associated requirement does not apply.

次の要件のすべてが、具体的ETSをサポートするために、ドメインの管理権限によって選ばれたメカニズムに関係することを理解しなければなりません。その権限は、ETSをサポートしないことを選択したか、これらのメカニズムは異なる目的のために専用のドメイン内に存在する場合、関連する要件は適用されません。場合

3.1. Label Mechanisms

3.1. ラベルのメカニズム

Application or transport layer label mechanisms used for ETS MUST be extensible such that they can support more than one label. These mechanism MUST avoid a single off/on type of label (e.g., a single bit). In addition, designers of such a mechanism MUST assume that there may be more than one set of ETS users.

ETSのために使用されるアプリケーション又はトランスポートレイヤラベルメカニズムは、それらが複数のラベルをサポートすることができる拡張可能なものでなければなりません。これらの機構は、ラベル（例えば、単一ビット）の種類/単一オフを避けなければなりません。加えて、そのような機構の設計者は、ETSのユーザの複数の組が存在する可能性があることを前提としなければなりません。

Network layer label mechanisms used for ETS SHOULD be extensible such that they can support more than one label. We make this distinction in requirements because there may be fewer bits (a smaller field) available at the network layer than in the transport or application layer.

ETSのために使用するネットワーク層ラベルのメカニズムは、彼らが複数のラベルをサポートすることができる拡張可能なものでなければなりません。輸送またはアプリケーション層に比べてネットワーク層で利用可能な、より少ないビット（小さなフィールド）が存在し得るので、我々は必要条件でこの区別を行います。

3.2. Proxies

3.2. プロキシ

Proxies MAY set ETS labels on behalf of the source of a flow. This may involve removing labels that have been set by upstream node(s).

プロキシは、フローのソースに代わってETSラベルを設定することができます。これは、上流のノード（複数可）によって設定されたラベルを除去することを含むことができます。

If proxies take such action, then the security measures discussed in [RFC3689] MUST be considered. More information about security in the single-domain context is found below in Section 5.

プロキシは、そのような行動を取る場合は、[RFC3689]で説明したセキュリティ対策を考えなければなりません。単一ドメインコンテキスト内のセキュリティについての詳細は、5章で以下発見されました。

3.3. QoS mechanisms

3.3. QoSメカニズム

[RFC3689] defines a label as an identifier, and the set of characteristics associated with the label as policy. However, QoS in the traditional sense of delay or bandwidth is not automatically bound to a label. MPLS [RFC3031] is an example of a labeling mechanism that can provide specific QoS or simply traffic engineering of labeled flows.

[RFC3689]は、識別子、およびポリシーなどのラベルに関連付けられた特性のセットとしてラベルを定義します。しかし、遅延や帯域幅の伝統的な意味でのQoSは自動的にラベルにバインドされていません。 MPLS [RFC3031]標識されたフローの特定のQoSまたは単にトラフィックエンジニアリングを提供することができるラベル付け機構の一例です。

In the context of ETS, QoS mechanisms, at either the network or application layer, SHOULD be used when networks cannot be over-provisioned to satisfy high bursts of traffic load. Examples can involve bridging fiber networks to wireless subnetworks, or remote subnetworks connected over expensive bandwidth-constrained wide area links.

ネットワークトラフィック負荷の高いバーストを満たすために上にプロビジョニングすることができない場合ETSの文脈では、QoSメカニズムは、ネットワークまたはアプリケーション層のいずれかで、使用されるべきです。例としては、無線サブネットワーク、あるいは高価な帯域幅に制約の広域リンクを介して接続されたリモートサブネットワークにファイバネットワークをブリッジすることを含むことができます。

Note well. Over-provisioning is a normal cost-effective practice amongst network administrators/engineers. The amount of over-provisioning can be a topic of debate. More in-depth discussion on this topic is presented in the companion Framework document [FRAME].

十分に注意してください。オーバープロビジョニング、ネットワーク管理者/エンジニアの間で、通常の費用対効果の高い方法です。オーバープロビジョニングの量は議論の話題することができます。このトピックに関するより詳細な議論はコンパニオンのフレームワークドキュメント[FRAME]に提示されています。

3.4. Users

3.4. ユーザー

Regarding existing IETF-specified applications, augmentations in the form of labeling mechanisms to support ETS MUST NOT adversely affect its legacy usage by non-ETS users. With respect to future applications, such labeling mechanisms SHOULD allow the application to support a "normal" (non-emergency) condition.

既存のIETF指定のアプリケーションについては、ETSをサポートするためのラベリングメカニズムの形での拡張製品に悪影響を非ETSのユーザーがそのレガシーの利用に影響してはいけません。将来のアプリケーションに関しては、例えば標識メカニズムは、アプリケーションが「通常の」（非緊急）条件をサポートできるようにする必要があります。

3.5. Policy

3.5. ポリシー

Policy MUST be used to determine the percentage of resources of a mechanism used to support the various (ETS and non-ETS) users. Under certain conditions, this percentage MAY reach 100% for a specific set of users. However, we recommend that this "all-or-nothing" approach be considered with great care.

ポリシーは、さまざまな（ETSと非ETS）のユーザーをサポートするために使用されるメカニズムのリソースの割合を決定するために使用しなければなりません。特定の条件下では、この割合は、ユーザーの特定のセットのために100％に達する可能性があります。しかし、私たちは、この「オール・オア・ナッシング」のアプローチは、細心の注意を払って考慮されることをお勧めします。

3.6. Discovery

3.6. 発見

There should be a means of forwarding ETS labeled flows to those mechanisms within the domain used to support ETS. Discovery mechanisms SHOULD be used to determine where ETS labeled flows (either data or control) are to be forwarded.

ETSをサポートするために使用されるドメイン内のそれらのメカニズムにETSラベルされたフローを転送する手段があるはずです。発見メカニズムは、ETS標識フロー（データまたは制御のいずれか）が転送されるべき場所を決定するために使用されるべきです。

3.7. MIB

Management Information Bases (MIBs) SHOULD be defined for mechanisms specifically in place to support ETS. These MIBs MAY include objects representing accounting, policy, and authorization.

管理情報ベース（MIB）ETSをサポートするために、具体的な場所にメカニズムを定義する必要があります。これらのMIBは、会計、ポリシー、および承認を表すオブジェクトを含むかもしれません。

4. Issues

4.問題

This section presents issues that arise in considering solutions for the requirements that have been defined for stub domains that support ETS. This section does not specify solutions nor is it to be confused with requirements. Subsequent documents that articulate a more specific set of requirements for a particular service may make a statement about the following issues.

このセクションでは、ETSをサポートするスタブドメインのために定義されている要件のためのソリューションを検討する中で発生する問題を提示しています。このセクションでは、ソリューションを指定しておらず、要件と混同されることです。特定のサービスのための要件のより具体的なセットを明確以降の文書は、次の問題について声明を発表することがあります。

4.1. Alternative Services

4.1. 代替サービス

The form of the service provided to ETS users and articulated in the form of policies may be realized in one of several forms. Better than best effort is probably the service that most ETS users would expect when the communication system is stressed and overall quality has degraded. However, the concept of best available service should also be considered under such stressed conditions. Further, a measure of degraded service may also be desirable to ensure a measure of communication versus none. These services may be made available at the network or application layer.

サービスETSのユーザに提供し、政策の形での関節の形は、いくつかのいずれかの形式で実現することができます。ベストエフォートよりも良いが、おそらく通信システムが強調され、全体的な品質が劣化した場合に最もETSのユーザーが期待するサービスです。しかし、利用可能な最善のサービスの概念は、そのようなストレスを受けた条件で考慮されるべきです。さらに、劣化したサービスの尺度もなし対通信の測定値を確保することが望ましい場合があります。これらのサービスは、ネットワークやアプリケーション層で利用できるようにすることができます。

4.2. Redundancy

4.2. 冗長性

The issue of making networks fault tolerant is important and yet not one that can be easily articulated in terms of requirements of protocols. Redundancy in connectivity and nodes (be it routers or servers) is probably the most common approach taken by network administrators, and it can be assumed that administrative domains apply this approach in various degrees to their own resources.

ネットワークのフォールトトレラントを作るの問題は、まだ簡単なプロトコルの要件の観点での関節できるものではないが重要であると。接続ノード（それはルータやサーバのこと）での冗長性は、おそらく、ネットワーク管理者が撮影した最も一般的なアプローチであり、管理ドメインは、独自のリソースに様々な程度で、この手法を適用することを想定することができます。

5. Security Considerations

5.セキュリティについての考慮事項

This document recommends that readers review and follow the comments and requirements about security presented in [RFC3689]. Having said that, there tend to be many instances where intra-domain security is held at a lower standard (i.e., less stringent) that inter-domain security. For example, while administrators may allow telnet service between resources within an administrative domain, they would only allow SSH access from other domains.

この文書では、読者のレビューとコメントし、[RFC3689]に提示セキュリティに関する要件に従うことをお勧めします。ドメイン内のセキュリティは低い標準（すなわち、より厳しくない）はドメイン間セキュリティに保持されている多くの例があるように傾向がある、と述べました。たとえば、管理者は、管理ドメイン内のリソース間のtelnetサービスを許可するかもしれないが、彼らは他のドメインからのSSHアクセスを可能にします。

The disparity in security policy can be problematic when domains offer services other than best effort for ETS users. Therefore, any support within a domain for ETS should be accompanied by a detailed security policy for users and administrators.

ドメインはETSのユーザーのための最善の努力以外のサービスを提供する際のセキュリティポリシーの格差が問題となる可能性があります。したがって、ETSのドメイン内の任意のサポートは、ユーザーと管理者のための詳細なセキュリティポリシーを伴うべきです。

Given the "SHOULD" statement in Section 3.8 concerning MIBs, there are a number of related security considerations that need to be brought to attention to the reader. Specifically, the following:

3.8に関するMIBのセクションで「SHOULD」文を考えると、読者に注意を喚起するする必要が関連するセキュリティ上の考慮事項がいくつかあります。具体的には、以下：

- Most current deployments of Simple Network Management Protocol (SNMP) are of versions prior to SNMPv3, even though there are well-known security vulnerabilities in those versions of SNMP.

- 簡易ネットワーク管理プロトコル（SNMP）の現在のほとんどの展開では、SNMPのこれらのバージョンではよく知られたセキュリティ上の脆弱性があるにもかかわらず、SNMPv3の前のバージョンです。

- SNMP versions prior to SNMPv3 cannot support cryptographic security mechanisms. Hence, any use of SNMP prior to version 3 to write or modify MIB objects do so in a non-secure manner. As a result, it may be best to constrain the use of these objects to read-only by MIB managers.

- SNMPv3の前のSNMPバージョンは、暗号化セキュリティ・メカニズムをサポートすることはできません。したがって、MIBオブジェクトを記述または変更する前に、バージョン3へのSNMPの使用は非セキュアな方法でそれを行います。その結果、それは読み取り専用MIB管理することにより、これらのオブジェクトの使用を制限するのが最善かもしれません。

- Finally, any MIB defining writable objects should carefully consider the security implications of an SNMP compromise on the mechanism(s) being controlled by those writable MIB objects.

- 最後に、慎重メカニズム（s）は上のSNMPの妥協のセキュリティへの影響を考慮すべきである任意のMIB定義する書き込み可能なオブジェクトは、それらの書き込み可能なMIBオブジェクトによって制御されています。

6. Acknowledgements

6.謝辞

Thanks to Ran Atkinson, James Polk, Scott Bradner, Jon Peterson, and Ian Brown for comments on previous versions of this document.

おかげで、このドキュメントの以前のバージョンのコメントをアトキンソン、ジェームスポーク、スコット・ブラッドナー、ジョンピーターソン、そしてイアン・ブラウンをRANに。

7. Informative References

7.参考文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.

[RFC3031]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。

[RFC3689] Carlberg, K. and R. Atkinson, "General Requirements for Emergency Telecommunication Service (ETS)", RFC 3689, February 2004.

[RFC3689]カールバーグ氏、K.とR.アトキンソン、 "緊急通信サービスの一般的な要件（ETS）"、RFC 3689、2004年2月。

[FRAME] Carlberg, K., "A Framework for Supporting Emergency Telecommunications Services (ETS) Within a Single Administrative Domain", Work in Progress, December 2005.

[FRAME]カールバーグ氏、K.、「単一の管理ドメイン内での緊急通信サービス（ETS）をサポートするためのフレームワーク」、進歩、2005年12月に作業。

Author's Address

著者のアドレス

Ken Carlberg G11 123a Versailles Circle Baltimore, MD USA

ケン・カールバーグG11 123Aベルサイユサークルボルチモア、MD USA

EMail: carlberg@g11.org.uk

メールアドレス：carlberg@g11.org.uk

Full Copyright Statement

完全な著作権声明

著作権（C）インターネット協会（2006）。

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/SHE 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.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。

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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、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 provided by the IETF Administrative Support Activity (IASA).

RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。