[要約] RFC 3689は、災害時や重大な公共の危機の際に、権限のあるユーザーに対して通信路を優先的に提供する「緊急通信サービス (ETS: Emergency Telecommunication Service)」に対する一般的な技術要件を整理しています。可用性、信頼性、セキュリティ、および異なるネットワーク間での優先制御の相互運用性に関する基本的な必要条件を定義しています。公衆ネットワークを活用して、緊急事態における重要な通信を確実に維持するためのプロトコル設計やシステム運用の指針を提供することを目的としています。
Network Working Group K. Carlberg
Request for Comments: 3689 UCL
Category: Informational R. Atkinson
Extreme Networks
February 2004
General Requirements for Emergency Telecommunication Service (ETS)
緊急通信サービス（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.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（c）The Internet Society（2004）。無断転載を禁じます。
Abstract
概要
This document presents a list of general requirements in support of Emergency Telecommunications Service (ETS). Solutions to these requirements are not presented in this document. Additional requirements pertaining to specific applications, or types of applications, are to be specified in separate document(s).
このドキュメントでは、緊急通信サービス（ETS）を支援する一般的な要件のリストを提示します。これらの要件の解決策は、このドキュメントには示されていません。特定のアプリケーションまたはアプリケーションの種類に関する追加要件は、個別のドキュメントで指定されます。
Effective telecommunications capabilities can be imperative to facilitate immediate recovery operations for serious disaster events, such as, hurricanes, floods, earthquakes, and terrorist attacks. Disasters can happen any time, any place, unexpectedly. Quick response for recovery operations requires immediate access to any public telecommunications capabilities at hand. These capabilities include: conventional telephone, cellular phones, and Internet access via online terminals, IP telephones, and wireless PDAs. The commercial telecommunications infrastructure is rapidly evolving to Internet-based technology. Therefore, the Internet community needs to consider how it can best support emergency management and recovery operations.
ハリケーン、洪水、地震、テロ攻撃などの深刻な災害イベントのための即時の回復作戦を促進するためには、効果的な通信能力が不可欠です。災害はいつでも、どこでも、予期せずに発生する可能性があります。回復操作の迅速な対応には、当面の公開通信機能に即座にアクセスする必要があります。これらの機能には、従来の電話、携帯電話、オンラインターミナル、IP電話、ワイヤレスPDAを介したインターネットアクセスが含まれます。商業的な通信インフラストラクチャは、インターネットベースのテクノロジーに急速に進化しています。したがって、インターネットコミュニティは、緊急管理と回復の運用をどのようにサポートするかを検討する必要があります。
The key words "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 [1].
このドキュメントのキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、および "OPTIONAL" は、BCP 14 で説明されているように解釈されるものとします。
Label: The term label has been used for a number of years in various IETF protocols. It is simply an identifier. It can be manifested in the form of a numeric, alphanumeric value, or a specific bit pattern, within a field of a packet header. The exact form is dependent on the protocol in which it is used.
ラベル：用語ラベルは、さまざまなIETFプロトコルで長年使用されてきました。それは単に識別子です。パケットヘッダーのフィールド内で、数値、英数字値、または特定のビットパターンの形で明らかにすることができます。正確なフォームは、使用されるプロトコルに依存します。
An example of a label can be found in RFC 3031; the Multiprotocol Label Switching Architecture. Another example can be found in RFC 2597 (and updated by RFC 3260); a bit pattern for the Assured Forwarding PHB group. This latter case is a type of label that does not involve routing. Note that specification of labels is outside the scope of this document. Further comments on labels are discussed below in section 3.
ラベルの例は、RFC 3031にあります。マルチプロトコルラベルスイッチングアーキテクチャ。別の例は、RFC 2597にあります（およびRFC 3260によって更新）。保証された転送PHBグループのビットパターン。この後者のケースは、ルーティングを伴わないラベルの一種です。ラベルの仕様は、このドキュメントの範囲外であることに注意してください。ラベルに関するさらなるコメントについては、セクション3で説明します。
The following are standards from other organizations that are specifically aimed at supporting emergency communications. Most of these standards specify telephony mechanisms or define telephony related labels.
以下は、緊急コミュニケーションをサポートすることを目的とした他の組織の基準です。これらの標準のほとんどは、テレフォニーメカニズムを指定するか、テレフォニー関連のラベルを定義します。
Standard / Organization
--------------------------
1) T1.631 / ANSI
2) E.106 / ITU
3) F.706 / ITU
4) H.460.4 / ITU
5) I.255.3 / ITU
The first specifies an indicator for SS7 networks that signals the need for a High Probability of Completion (HPC) service. This indicator is termed National Security / Emergency Preparedness (NS/EP) The T1.631 standard [2] is the basis for the U.S. Government Emergency Telecommunications Service (GETS) [7].
最初のものは、完了の高い確率（HPC）サービスの必要性を示すSS7ネットワークのインジケーターを指定します。この指標は国家安全保障 /緊急事態対策（NS/EP）と呼ばれます。T1.631標準[2]は、米国政府の緊急通信サービス（GETS）[7]の基礎です。
The second standard describes functional capabilities for the Public Switched Telephone Network (PSTN) to support International Emergency Preparedness System (IEPS) [3]. From the PSTN perspective, one can view NS/EP as a standard with national boundaries, while IEPS is an extension to international boundaries for telephony.
2番目の標準は、国際的な緊急時対応システム（IEP）をサポートするための公共スイッチド電話ネットワーク（PSTN）の機能機能を説明しています[3]。PSTNの観点からは、NS/EPを国境を備えた基準と見なすことができますが、IEPSはテレフォニーの国際境界の延長です。
The third standard extends IEPS beyond the scope of telephony into other forms that encompass multimedia [4].
3番目の標準は、IEPをテレフォニーの範囲を超えてマルチメディアを含む他の形式に拡張します[4]。
The fourth and fifth standard focuses on a multi-level labeling mechanism distinguishing emergency type traffic from that which is not. The former case focuses on call signaling for H.323 networks [5], while the latter has been applied for both SS7 [6] and data networks.
4番目と5番目の標準は、緊急タイプのトラフィックを区別していないマルチレベルのラベル付けメカニズムに焦点を当てています。前者のケースは、H.323ネットワークのコールシグナル伝達に焦点を当てており[5]、後者はSS7 [6]とデータネットワークの両方に適用されています。
While the above standards are outside the scope of the IETF, they do represent existing efforts in the area of emergency communications, as opposed to conceptual of potential possibilities. They act as example manifestations of Emergency Telecommunications Service (ETS).
上記の基準はIETFの範囲外ですが、潜在的な可能性の概念とは対照的に、緊急通信の分野での既存の努力を表しています。それらは、緊急時電子通信サービス（ETS）の症状の例として機能します。
One problem faced by the IEPREP working group entails how, and to what degree, support for these standards are to be realized within the Internet architecture and the existing suite of IETF standards and associated working groups. This support could be in the form of interoperability with corresponding IETF protocols.
IEPREPワーキンググループが直面する1つの問題には、インターネットアーキテクチャおよびIETF標準および関連ワーキンググループの既存のスイートで、これらの標準のサポートがどのように、どの程度サポートされるかが伴います。このサポートは、対応するIETFプロトコルとの相互運用性の形である可能性があります。
A subsequent problem is to ensure that requirements associated with potential support is not focused just on IP telephony applications. The I-Am-Alive (IAA) database system is an example of an ETS type application used in Japan that supports both signaled and non-signaled access by users [10]. It is a distributed database system that provides registration, querying, and reply primitives to participants during times of an emergency (e.g., an earthquake) so that others can make an after-the-event determination about the status of a person. In this case, a separate signaling protocol like SIP is not always required to establish or maintain a connection.
その後の問題は、潜在的なサポートに関連する要件がIPテレフォニーアプリケーションのみに焦点を合わせていないことを確認することです。I-AM-Alive（IAA）データベースシステムは、ユーザーによるシグナルと非シグナルのアクセスの両方をサポートする日本で使用されるETSタイプアプリケーションの例です[10]。これは、緊急時に登録、クエリ、およびプリミティブを参加者に提供し、応答したデータベースシステムであり、他の人が人の状態についてイベント後の決定を下すことができるようにします。この場合、接続を確立または維持するために、SIPのような個別のシグナルプロトコルが必ずしも必要ではありません。
Given the case where signaling is optional, requirements and subsequent solutions that address these problems must not assume the existence of signaling and must be able to support applications that only have labels in data packets. These label(s) may be in various places, such as the application or IP header.
シグナリングがオプションである場合を考えると、これらの問題に対処する要件とその後のソリューションは、シグナリングの存在を想定してはならず、データパケットにラベルのみを持つアプリケーションをサポートできる必要があります。これらのラベルは、アプリケーションやIPヘッダーなど、さまざまな場所にある場合があります。
This document defines a set of general system requirements to achieve support for ETS and addressing the problem space presented in Section 1.3. In defining these requirements, we consider known systems such as GETS and IAA that represent existing manifestations of emergency related systems. These two examples also represent a broad spectrum of characteristics that range from signaling & interactive non-elastic applications to non-signaled & elastic applications.
このドキュメントでは、ETSのサポートを達成し、セクション1.3で提示された問題スペースに対処するための一連の一般的なシステム要件を定義しています。これらの要件を定義する際に、緊急関連システムの既存の症状を表すGetやIAAなどの既知のシステムを検討します。これらの2つの例は、シグナル伝達およびインタラクティブな非弾力性アプリケーションから非シグナルおよび弾性アプリケーションに至るまでの幅広い特性を表しています。
We stress that ETS, and its associated requirements, is not the only means of supporting authorized emergency communications. It is simply an approach influenced by existing systems and standards.
ETSとそれに関連する要件が、承認された緊急コミュニケーションをサポートする唯一の手段ではないことを強調しています。これは、既存のシステムと標準の影響を受けるアプローチです。
Solutions to requirements are not defined. This document does not specify protocol enhancements or specifications. Requirements for specific types of applications that go beyond the general set stated in section 3 are to be specified in other document(s). At the current writing of this document, [9] has been written for the case of IP telephony.
要件の解決策は定義されていません。このドキュメントでは、プロトコルの強化や仕様を指定しません。セクション3に記載されている一般的なセットを超える特定のタイプのアプリケーションの要件は、他のドキュメントで指定されます。この文書の現在の執筆では、[9]はIPテレフォニーの場合のために書かれています。
The current IEPREP charter stipulates that any proposed solution to support ETS that responds to the requirements of this document are to be developed in other working groups. We note that other specific requirements (like that of IP telephony) may be defined as an extension of the general requirements presented in section 3 below.
現在のIEPREPチャーターは、このドキュメントの要件に対応するETSをサポートするための提案されたソリューションが他のワーキンググループで開発されることを規定しています。他の特定の要件（IPテレフォニーのような）は、以下のセクション3に示す一般的な要件の拡張として定義される場合があることに注意してください。
While the problem space stated in section 1.3 includes standards related to telephony, this document is meant to be broader in scope. Hence, emulation of specific architectures, like the PSTN, or focus on a specific application is out of scope. Further, the specifications of requirements that are aimed at adhering to regulations or laws of governments is also out of the scope of this document. The focus of the IETF and its working groups is technical positions that follow the architecture of the Internet.
セクション1.3に記載されている問題空間には、テレフォニーに関連する標準が含まれていますが、このドキュメントは範囲が広いことを意図しています。したがって、PSTNなどの特定のアーキテクチャのエミュレーション、または特定のアプリケーションに焦点を当てることは範囲外です。さらに、政府の規制または法律を順守することを目的とした要件の仕様も、この文書の範囲外です。IETFとそのワーキンググループの焦点は、インターネットのアーキテクチャに従う技術的なポジションです。
Another item that is not in scope of this document is mandating acceptance and support of the requirements presented in this document. There is an expectation that business contracts, (e.g., Service Level Agreements), will be used to satisfy those requirements that apply to service providers. Absence of an SLA implies best effort service is provided.
このドキュメントの範囲にない別の項目は、このドキュメントに示されている要件の受け入れとサポートを義務付けることです。サービスプロバイダーに適用される要件を満たすために、ビジネス契約（サービスレベル契約など）が使用されるという期待があります。SLAの不在は、ベストエフォートサービスが提供されることを意味します。
These are general requirements that apply to authorized emergency telecommunications service. The first requirement is presented as a conditional one since not all applications use or are reliant on signaling.
これらは、承認された緊急通信サービスに適用される一般的な要件です。最初の要件は、すべてのアプリケーションが使用されているわけではないか、シグナリングに依存しているわけではないため、条件付きの要件として提示されます。
1) Signaling
1) シグナリング
IF signaling is to be used to convey the state or existence of emergency, then signaling mechanism(s) MUST exist to carry applicable labels.
シグナリングを使用して緊急事態の状態または存在を伝える場合は、適用されるラベルを運ぶためにシグナリングメカニズムが存在しなければなりません (MUST)。
2) Labels
2) ラベル
Labels may exist in various forms at different layers. They might be carried as part of signaling, and/or as part of the header of a data packet. Labels from different layers are NOT required to be the same, but MAY be related to each other.
ラベルは、さまざまな層のさまざまな形で存在する場合があります。それらは、シグナリングの一部として、および/またはデータパケットのヘッダーの一部として運ばれる場合があります。異なるレイヤーのラベルは同じである必要はありませんが、互いに関連している場合があります。
3) Policy
3) ポリシー
Policy MUST be kept separate from label(s). This topic has generated a fair amount of debate, and so we provide additional guidance from the following:
ポリシーは、ラベルとは別に保持しなければなりません (MUST)。このトピックはかなりの量の議論を生み出しているため、以下から追加のガイダンスを提供します。
A set of labels may be defined as being related to each other. Characteristics (e.g., drop precedence) may also be attributed to these labels. [11] is an example of a related set of labels based on a specific characteristic.
一連のラベルは、互いに関連していると定義される場合があります。特性（例：ドロップの優先順位）も、これらのラベルに起因する場合があります。[11]は、特定の特性に基づいた関連ラベルのセットの例です。
However, the mechanisms used to achieve a stated characteristic MUST NOT be stated in the definition of a label. Local policy determines mechanism(s) used to achieve or support a specific characteristic. This allows for the possibility of different mechanisms to achieve the same stated characteristic.
ただし、指定された特性を実現するために使用されるメカニズムは、ラベルの定義に記載されてはなりません (MUST NOT)。ローカルポリシーは、特定の特性を達成またはサポートするために使用されるメカニズムを決定します。これにより、さまざまなメカニズムが同じ特性を達成できる可能性があります。
The interaction between unrelated labels MUST NOT be embedded within the definition of a label. Local policy states the actions (if any) to be taken if unrelated labeled traffic merges at a node.
無関係なラベル間の相互作用は、ラベルの定義に埋め込まれてはなりません (MUST NOT)。ローカルポリシーでは、無関係のラベル付きトラフィックがノードで合併した場合、アクション（ある場合）が取られるべきであると述べています。
Finally, labels may have additional characteristics added to them as a result of local policy.
最後に、ラベルには、ローカルポリシーの結果として追加の特性が追加される場合があります。
4) Network Functionality
4) ネットワーク機能
Functionality to support a better than best effort SHOULD focus on probability versus guarantees. Probability can be realized in terms of reduced probability of packet loss, and/or minimal jitter, and/or minimal end-to-end delay. There is NO requirement that a better than best effort functionality MUST exist. There is NO requirement that if a better than best effort functionality exists then it must be ubiquitous between end users.
より良い努力をサポートする機能は、確率と保証に焦点を当てる必要があります。確率は、パケット損失の確率の低下、および/または最小限のジッター、および/または最小限のエンドツーエンド遅延の観点から実現できます。ベスト努力よりも優れた機能が存在する必要があるという要件はありません。ベストエフェクションよりも優れた機能が存在する場合、エンドユーザー間でユビキタスでなければならないという要件はありません。
The following are security related requirements that emerge given the requirements 1 through 4 above.
以下は、上記の要件1〜4を考慮して、発生するセキュリティ関連の要件です。
5) Authorization
5) 許可
Authorization is a method of validating that a user or some traffic is allowed by policy to use a particular service offering.
承認は、特定のサービス提供を使用するために、ポリシーによってユーザーまたは一部のトラフィックが許可されていることを検証する方法です。
Mechanisms must be implemented so that only authorized users have access to emergency telecommunications services. Any mechanism for providing such authorization beyond closed private networks SHOULD meet IETF Security Area criterion (e.g., clear-text passwords would not generally be acceptable). Authorization protects network resources from excessive use, from abuse, and might also support billing and accounting for the offered service.
認可されたユーザーだけが緊急通信サービスにアクセスできるように、メカニズムを実装しなければなりません。閉じたプライベートネットワークの外でそのような認可を提供するメカニズムは、IETF Security Areaの基準を満たすべきです (SHOULD)（たとえば、平文のパスワードは一般に許容されません）。認可は、ネットワークリソースを過度の使用や濫用から保護し、提供されるサービスの課金や会計をサポートすることもあります。
Such authorization mechanisms SHOULD be flexible enough to provide various levels of restriction and authorization depending on the expectations of a particular service or customer.
このような承認メカニズムは、特定のサービスまたは顧客の期待に応じて、さまざまなレベルの制限と承認を提供するのに十分な柔軟性が必要です。
6) Integrity & Authentication
6) 整合性と認証
In practice, authentication and integrity for IP based communications are generally bound within a single mechanism, even though conceptually they are different. Authentication ensures that the user or traffic is who it claims to be. Integrity offers assurance that unauthorized modifications to objects can be detected.
実際には、IPベースの通信の認証と整合性は、概念的には異なる場合でも、単一のメカニズム内に結合されます。認証は、ユーザーまたはトラフィックが誰であるかを保証します。整合性は、オブジェクトの不正な変更を検出できるという保証を提供します。
Authorized emergency traffic needs to have reduced risk of adverse impact from denial of service. This implies a need to ensure integrity of the authorized emergency network traffic. It should be noted, though, that mechanisms used to ensure integrity can also be subject to Denial of Service attacks.
認可された緊急トラフィックは、サービス運用妨害（DoS）による悪影響のリスクを低減させる必要があります。これは、認可された緊急ネットワークトラフィックの整合性を確保する必要があることを意味します。ただし、整合性を確保するために使用されるメカニズム自体も、サービス運用妨害攻撃の対象となり得る点に注意する必要があります。
Users of emergency network services SHOULD consider deploying end-to-end integrity and authentication, rather than relying on services that might be offered by any single provider of emergency network services. Users SHOULD also carefully consider which application-layer security services might be appropriate to use.
緊急ネットワークサービスのユーザーは、緊急ネットワークサービスの単一プロバイダーが提供する可能性のあるサービスに依存するのではなく、エンドツーエンドの整合性と認証を展開することを検討すべきです (SHOULD)。また、ユーザーは、どのアプリケーションレイヤーセキュリティサービスが使用されるかを慎重に検討すべきです (SHOULD)。
7) Confidentiality
7) 機密性
Some emergency communications might have a requirement that they not be susceptible to interception or viewing by others, due to the sensitive and urgent nature of emergency response activities. An emergency telecommunications service MAY offer options to provide confidentiality for certain authorized user traffic.
一部の緊急コミュニケーションには、緊急対応活動の敏感で緊急の性質のために、他の人が傍受または視聴する影響を受けないことが要求されている場合があります。緊急通信サービスは、特定の許可されたユーザートラフィックに機密性を提供するオプションを提供する場合があります (MAY)。
Consistent with other IETF standards and the Internet Architecture, this document recommends that IEPREP users SHOULD deploy end-to-end security mechanisms, rather than rely on security services that might be offered by a single network operator. IEPREP users SHOULD carefully consider security alternatives (e.g., PGP, TLS, IPsec transport-mode) at different layers (e.g., Application Layer, Session Layer, Transport Layer) of the Internet Architecture before deployment.
他のIETF標準やインターネットアーキテクチャと一致して、このドキュメントは、IEPREPユーザーが単一のネットワークオペレーターが提供する可能性のあるセキュリティサービスに依存するのではなく、エンドツーエンドのセキュリティメカニズムを展開することを推奨しています。IEPREPユーザーは、展開前にインターネットアーキテクチャのさまざまなレイヤー（アプリケーションレイヤー、セッション層、輸送層など）で、セキュリティの代替（PGP、TLS、IPSECトランスポートモードなど）を慎重に検討する必要があります。
This section presents issues that arise in considering solutions for the requirements that have been defined for 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に対して定義されている要件のソリューションを検討する際に発生する問題を紹介します。このセクションでは、ソリューションを指定していませんし、要件と混同することもありません。特定のサービスのより具体的な一連の要件を明確にする後続のドキュメントは、次の問題について声明を出すことができます。
1) Accounting
1) 会計
Accounting represents a method of tracking actual usage of a service. We assume that the usage of any service better than best effort will be tracked and subsequently billed to the user. Accounting is not addressed as a general requirement for ETS. However, solutions used to realize ETS should not preclude an accounting mechanism.
会計は、サービスの実際の使用を追跡する方法を表します。最善の努力よりも優れたサービスの使用が追跡され、その後ユーザーに請求されると仮定します。会計は、ETSの一般的な要件として扱われていません。ただし、ETSを実現するために使用されるソリューションは、会計メカニズムを排除すべきではありません。
2) Admission Control
2) 入場管理
The requirements of section 3 discuss labels and security. Those developing solutions should understand that the ability labels provide to distinguish emergency flows does not create an ability to selectively admit flows. Admission control as it is commonly understood in circuit-switched networks is not present in IP-based networks, and schemes which presume the ability to selectively admit flows when resources are scarce will fail outside of very controlled environments. In cases where emergency related flows occur outside of controlled environments, the development of technologies based on admission control is not recommended as the foundation of emergency services.
セクション3の要件は、ラベルとセキュリティについて説明します。開発中のソリューションは、緊急フローを区別するための能力ラベルが、フローを選択的に認める能力を生み出さないことを理解する必要があります。回路で切り替えられたネットワークでよく理解されているアミズドリシャスコントロールは、IPベースのネットワークには存在しません。また、リソースが不足している場合に非常に制御された環境の外で失敗するフローを選択的に認める能力を推測するスキーム。制御された環境の外で緊急関連の流れが発生する場合、緊急サービスの基礎として入学制御に基づく技術の開発は推奨されません。
3) Digital Signatures
3) デジタル署名
Verification of digital signatures is computationally expensive. If an operator acts upon a label and hence needs to verify the authenticity of the label, then there is a potential denial-of-service attack on the entity performing the authentication. The DoS attack works by flooding the entity performing the authentication with invalid (i.e., not authentic) labelled information, causing the victim to spend excessive amounts of computing resources on signature validation. Even though the invalid information might get discarded after the signature validation fails, the adversary has already forced the victim to expend significant amounts of computing resource. Accordingly, any system requiring such validation SHOULD define operational and protocol measures to reduce the vulnerability to such a DoS attack.
デジタル署名の検証は計算コストが高くつきます。オペレーターがラベルに基づいて動作し、そのためにラベルの真正性を検証する必要がある場合、認証を行うエンティティに対するサービス拒否攻撃の可能性が生じます。このDoS攻撃は、認証を行うエンティティに無効な（つまり真正でない）ラベル付き情報を大量に送りつけ、被害者に署名検証のために過大な計算資源を費やさせることで成り立ちます。無効な情報は署名検証に失敗した後に破棄されるかもしれませんが、攻撃者はすでに被害者にかなりの計算資源を消費させています。したがって、そのような検証を必要とするシステムは、この種のDoS攻撃に対する脆弱性を低減するための運用上およびプロトコル上の対策を定義すべきです (SHOULD)。
RFC 3487 describes requirements for resource priority mechanisms for the Session Initiation Protocol [8]. The requirements specified in that RFC pertain to a specific application level protocol. In contrast, the requirements of this document are a generalization that are not application specific. From this blueprint (acting as a guideline), more specific requirements may be described in future documents.
RFC 3487は、セッション開始プロトコル[8]のリソース優先メカニズムの要件を説明しています。そのRFCで指定された要件は、特定のアプリケーションレベルのプロトコルに関係しています。対照的に、このドキュメントの要件は、アプリケーション固有ではない一般化です。この青写真（ガイドラインとして機能する）から、より具体的な要件が将来の文書で説明される場合があります。
Security in terms of requirements is discussed sections 3.1 and 4.
要件に関するセキュリティについては、セクション3.1および4について説明します。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner, S.、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] ANSI, "Signaling System No. 7(SS7) "High Probability of Completion (HPC) Network Capability" , ANSI T1.631-1993 (R1999).
[2] ANSI、「シグナリングシステムNo. 7（SS7）」完了の高い確率（HPC）ネットワーク機能」、ANSI T1.631-1993（R1999）。
[3] "Description of an International Emergency Preference Scheme (IEPS)", ITU-T Recommendation E.106 March, 2000.
[3] 「国際的な緊急選好スキーム（IEPS）の説明」、ITU-Tの推奨e.106 2000年3月。
[4] "Description for an International Emergency Multimedia Service", ITU Draft Recommendation F.706, February, 2002.
[4] 「国際緊急マルチメディアサービスの説明」、ITUドラフト推奨F.706、2002年2月。
[5] "Call Priority Designation for H.323 Calls", ITU Recommendation H.460.4, November, 2002.
[5] 「H.323コールのコール優先度指定」、ITU勧告H.460.4、2002年11月。
[6] ITU, "Multi-Level Precedence and Preemption Service, ITU, Recommendation, I.255.3, July, 1990.
[6] ITU、「マルチレベルの優先順位と先制サービス、ITU、推奨、I.255.3、1990年7月。
[7] U.S. National Communications System: http://www.ncs.gov
[7] 米国国立通信システム：http://www.ncs.gov
[8] Schulzrinne, H., "Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)", RFC 3487, February 2003.
[8] Schulzrinne, H.、「セッション開始プロトコル（SIP）のリソース優先メカニズムの要件」、RFC 3487、2003年2月。
[9] Carlberg, K. and R. Atkinson, "IP Telephony Requirements for Emergency Telecommunications Service", RFC 3690, February 2004.
[9] Carlberg, K. and R. Atkinson、「緊急通信サービスのIPテレフォニー要件」、RFC 3690、2004年2月。
[10] Tada, N., et. al., "IAA System (I Am Alive): The Experiences of the Internet Disaster Drills", Proceedings of INET-2000, June.
[10] Tada、N.、et。al。、「IAAシステム（私は生きている）：インターネット災害訓練の経験」、INET-2000の議事録、6月。
[11] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[11] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski、「Assured Forwarding PHB Group」、RFC 2597、1999年6月。
Ken Carlberg University College London Department of Computer Science Gower Street London, WC1E 6BT United Kingdom
ケンカールバーグユニバーシティカレッジロンドンコンピュータサイエンス科学部門ガワーストリートロンドン、WC1E 6BTイギリス
EMail: k.carlberg@cs.ucl.ac.uk
Ran Atkinson Extreme Networks 3585 Monroe Street Santa Clara, CA 95051 USA
ランアトキンソンエクストリームネットワーク3585モンローストリートサンタクララ、カリフォルニア95051 USA
EMail: rja@extremenetworks.com
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（c）The Internet Society（2004）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の限られた許可は永続的であり、インターネット社会やその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。