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)
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）インターネット協会（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"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[1]。
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.
第二の標準は公共のための機能的能力は、[3]国際防災システム（IEPS）をサポートするために、交換電話網（PSTN）について説明します。 IEPSは、テレフォニーのための国際的な境界への拡張である一方、PSTNの観点から、一つは、国境を標準としてNS / EPを表示することができます。
The third standard extends IEPS beyond the scope of telephony into other forms that encompass multimedia [4].
第三の標準は、マルチメディアを包含する他の形態への電話の範囲を超えてIEPSを拡張する[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.
第四及び第五の標準ではないことから、多値ラベリング機構区別緊急タイプのトラフィックに焦点を当てています。後者は両方SS7 [6]とデータネットワークに適用されているが、前者の場合は、H.323ネットワーク[5]のための呼シグナリングに焦点を当てています。
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ワーキンググループが直面する問題の一つは、これらの標準のサポートは、インターネットアーキテクチャと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-アライブ（IAA）データベース・システムは、両方のシグナリングとユーザ[10]による非シグナリングアクセスサポート日本で使用ETS型アプリケーションの一例です。これは、照会、登録を提供し、他の人が人の状態に関するアフターイベント決意を行うことができるように、緊急時（例えば、地震）の時間帯に参加者にプリミティブを返信分散データベースシステムです。この場合には、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節で提示問題空間に対処するためのサポートを達成するために、一般的なシステム要件のセットを定義します。これらの要件を定義する際に、我々は緊急事態に関連するシステムの既存の症状を表すように取得し、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.
シグナリングは緊急の状態または存在を伝えるために使用される場合、機構（単数または複数）をシグナリング適用ラベルを運ぶために存在しなければなりません。
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:
ポリシーは、ラベル（複数可）から分離して保持されなければなりません。このトピックでは、議論のかなりの量を生成した、と私たちは、次の追加のガイダンスを提供します。
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.
しかし、述べた特性を達成するために使用されるメカニズムは、ラベルの定義に記載されてはなりません。ローカルポリシーは、達成または特定の特性をサポートするために使用される機構（複数可）を決定します。これは、同じ述べた特性を達成するために、異なるメカニズムの可能性を可能にします。
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.
無関係なラベル間の相互作用は、ラベルの定義の中に埋め込まれてはなりません。ローカルポリシーは無関係なラベルされたトラフィックがノードにマージした場合にとるべき措置（もしあれば）を述べています。
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セキュリティエリアの基準を（例えば、クリアテキストのパスワードは、一般的に受け入れられない）満たさなければなりません。認可は、虐待から、過度の使用からネットワークリソースを保護し、また、提供するサービスのための課金および会計処理をサポートする場合があります。
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.
緊急ネットワークサービスのユーザーは、エンドツーエンドの整合性と認証を導入するのではなく、緊急ネットワークサービスのいずれかの単一のプロバイダによって提供されるかもしれないサービスに頼って検討すべきです。また、ユーザーは慎重にアプリケーション層のセキュリティサービスを使用するのが適切であるかもしれない考慮すべきです。
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.
いくつかの緊急通信は、彼らが原因緊急対応活動の敏感かつ緊急性のために、他人によって傍受や鑑賞の影響を受けやすいことがない要件がある場合があります。緊急通信サービスは、特定の許可されたユーザトラフィックに機密性を提供するためのオプションを提供することがあります。
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攻撃に対する脆弱性を低減する動作とプロトコル措置を定義する必要があります。
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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] ANSI, "Signaling System No. 7(SS7) "High Probability of Completion (HPC) Network Capability" , ANSI T1.631-1993 (R1999).
[2] ANSI、「信号システム第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]、ITU-T勧告E.106 2000年3月 "国際緊急優先スキーム（IEPS）の説明を"。
[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]、ITU勧告H.460.4、2002年11月の "H.323のためのコールの優先順位の指定コール"。
[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.、RFC 3487 "セッション開始プロトコル（SIP）のためのリソースプライオリティメカニズムのための要件"、2003年2月を。
[9] Carlberg, K. and R. Atkinson, "IP Telephony Requirements for Emergency Telecommunications Service", RFC 3690, February 2004.
[9]カールバーグ氏、K.とR.アトキンソン、 "緊急通信サービスのための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]ただ、N.、ら。ら、「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.、ベーカー、F.、ワイス、W.及びJ. Wroclawski、 "保証転送PHBグループ"、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
メールアドレス：k.carlberg@cs.ucl.ac.uk
Ran Atkinson Extreme Networks 3585 Monroe Street Santa Clara, CA 95051 USA
アトキンソンエクストリームネットワークを走った3585モンローストリートサンタクララ、CA 95051 USA
EMail: rja@extremenetworks.com
メールアドレス：rja@extremenetworks.com
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。