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

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

[要約] 要約：RFC 4375は、単一の管理ドメインにおける緊急通信サービス（ETS）の要件について説明しています。目的：このRFCの目的は、緊急通信サービスの要件を定義し、単一の管理ドメイン内での効果的な緊急通信を確保することです。

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

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

単一の管理ドメインの緊急通信サービス（ETS）要件

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.

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

著作権表示

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をサポートする一連の要件を定義することです。IEPREPメーリングリストと、ETSをサポートする特定のメカニズムの有用性に疑問を呈しているワーキンググループミーティングでは、多くの議論がありました。多くの人が過剰な視力を提唱していますが、他の人は定量化可能なサービスの尺度を提供するために特定のスキーマを支持しています。これらの議論の一定の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]に示されています。このドキュメントは、インターネット上でETをサポートする幅広いケースを考慮する際に要件を明確にします。そのドキュメントは特定のアプリケーション、管理境界、またはシナリオに制約されていないため、その中に含まれる要件は、その説明と範囲が非常に一般的である傾向があります。これは、一般的な要件が、より狭い範囲に関連するより具体的な要件が従うベースラインであることを意図しているという点で、その創業の背後にある哲学に従います。

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 NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

「必須」、「必須」、「「しなければならない」、「そうではない」、「そうすべき」、「そうでない」、「推奨」、「5月」、および「オプション」は[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標準は、このドキュメントの範囲内にあります。これには、ドメイン内に配置および管理されるゲートウェイ、ルーター、サーバーなどが含まれます。また、このドキュメントは、Voice over 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.

他の管理当局が所有または運営するリソースは、この文書の範囲外です。1つの例は、他のドメインで動作する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に使用されるアプリケーションまたはトランスポートレイヤーラベルメカニズムは、複数のラベルをサポートできるように拡張可能でなければなりません。これらのメカニズムは、1つのオフ/オンラベルのタイプ（たとえば、単一のビット）を避ける必要があります。さらに、このようなメカニズムの設計者は、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および非ET）ユーザーをサポートするために使用されるメカニズムのリソースの割合を決定する必要があります。特定の条件下では、特定のユーザーセットでこの割合が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をサポートするために使用されるドメイン内のメカニズムに転送する手段があるはずです。発見メカニズムを使用して、ETESのラベル付きフロー（データまたはコントロールのいずれか）を転送する場所を決定する必要があります。

3.7. MIB

3.7. ミブ

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:

MIBSに関するセクション3.8の「予定」声明を考えると、読者に注意を払う必要がある関連するセキュリティ上の考慮事項がいくつかあります。具体的には、次のとおりです。

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

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

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 Atkinson、James Polk、Scott Bradner、Jon Peterson、Ian Brownに感謝します。

7. Informative References

7. 参考引用

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

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

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

[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。

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

[RFC3689] Carlberg、K。およびR. Atkinson、「緊急通信サービス（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] Carlberg、K。、「単一の管理ドメイン内で緊急通信サービス（ETS）をサポートするためのフレームワーク」、2005年12月、進行中の作業。

Author's Address

著者の連絡先

Ken Carlberg G11 123a Versailles Circle Baltimore, MD USA

Ken Carlberg G11 123a Versailles Circle Baltimore、MD USA

   EMail: carlberg@g11.org.uk

Full Copyright Statement

完全な著作権声明

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.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。

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.

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 provided by the IETF Administrative Support Activity (IASA).

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