RFC4375 日本語訳

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

Carlbergがコメントのために要求するワーキンググループK.をネットワークでつないでください: 4375年のG11カテゴリ: 情報の2006年1月

       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.

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

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2006).

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

このドキュメントはただ一つの管理ドメインの中のEmergency Telecommunications Service(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をサポートする1セットの要件を定義することです。 ワーキンググループミーティングと同様にIEPREPメーリングリストにおけるETSをサポートするために与えられたメカニズムに関するユーティリティに質問した多くの議論がありました。 多くが、食糧を供給し過ぎると提唱しましたが、他のものは、定量化可能なサービスの手段を提供するために特定のschemasを支持しました。 これらの議論における1つの定数はリソースの運営管理コントロールがどんな提案されたソリューションの有効性における重要な役割もプレーするということです。 明確に、人が1セットのリソースを管理するなら、そのセットでさまざまなアプローチを配布することができます。 しかしながら、アプローチがいったん管理境界に交差していると、有効性は、他の管理ドメインから問題になって、最小限で協力と信頼を必要とします。 この質問を避けるために、私たちは単一領域の中のリソースにシナリオを抑制します。

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

以下は本書では使用されるいくつかの主要な用語に関する説明を提供します。

Carlberg                     Informational                      [Page 1]

RFC 4375                ETS Domain Requirements             January 2006

[1ページ]RFC4375ETSドメイン要求性2006年1月の情報のCarlberg

   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ノードがそれらを接続していたので一般的なレベルから見られたaであることができます。 また、より特定の用語でクライアント、サーバ、またはプロキシにホストを差し向けることができます。 また、ノード(例えば、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).

管理ドメイン: ただ一つの職務権限のコントロールの下におけるリソースの収集。 この権威は1セットのリソース(すなわち、ネットワーク)のデザインと操作を確立します。

   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.

トランジットドメイン: これは1つのドメインから別のドメインまでトラフィックを進めるのに使用される管理ドメインです。 インターネットサービスプロバイダ(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"などのキーワード

Carlberg                     Informational                      [Page 2]

RFC 4375                ETS Domain Requirements             January 2006

[2ページ]RFC4375ETSドメイン要求性2006年1月の情報のCarlberg

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

「」 “SHALL"でない、「必要であること」で、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[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.

このドキュメントの範囲の中にもService(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.

アプリケーションかエッツに使用されるトランスポート層ラベルメカニズムが、1個以上のラベルを支えることができるように、広げることができなければなりません。 これらのメカニズムはラベル(例えば、1ビット)のタイプの上で/でシングルを避けなければなりません。 さらに、そのようなメカニズムのデザイナーは、1セット以上のETSユーザがいるかもしれないと仮定しなければなりません。

Carlberg                     Informational                      [Page 3]

RFC 4375                ETS Domain Requirements             January 2006

[3ページ]RFC4375ETSドメイン要求性2006年1月の情報のCarlberg

   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.

それらがサポートすることができる広げることができるそのようなものが1個以上のラベルであったならETS SHOULDに使用されるネットワーク層ラベルメカニズム。 私たちは、ネットワーク層で利用可能な(より小さい分野)が輸送か応用層よりさらに少ないビットあるかもしれないので、要件におけるこの区別をします。

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、ネットワークか応用層、SHOULDのどちらかの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].

井戸に注意してください。 食糧を供給し過ぎるのはネットワーク管理者/技術者の中の正常な費用対効果に優れた習慣です。 食糧を供給し過ぎることの量は議論の的であるかもしれません。 この話題についての、より徹底的な議論は仲間Frameworkドキュメント[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ユーザでレガシー用法に悪影響を与えてはいけません。 将来のアプリケーションに関して、そのようなラベリングメカニズムSHOULDはアプリケーションに「正常な」(非非常時の)状態をサポートさせます。

Carlberg                     Informational                      [Page 4]

RFC 4375                ETS Domain Requirements             January 2006

[4ページ]RFC4375ETSドメイン要求性2006年1月の情報のCarlberg

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をそれらのメカニズムに送る手段があるべきです。 発見メカニズムSHOULD、使用されて、流れ(データかコントロールのどちらか)とラベルされたETSがどこに送られることになっているか決定してください。

3.7.  MIB

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.

管理Information基地(MIBs)のSHOULD、定義されて、明確に適所にあるメカニズムはETSをサポートしてください。 これらのMIBsは会計、方針、および承認を表すオブジェクトを含むかもしれません。

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ユーザに提供されて、方針の形で明確に話されたサービスのフォームはいくつかのフォームの1つに実現されるかもしれません。たぶん通信系が強調されるときETSユーザが予想する大部分と総合的な品質にあるサービスはベストエフォート型であるよりよく、降格していますか? しかしながら、また、利用可能に最も良いサービスの概念はそのような圧力を加えられた条件のもとで考えられるべきです。 また、さらに、降格しているサービスの手段もなにもに対してコミュニケーションの測定を確実にするのにおいて望ましいかもしれません。 これらのサービスをネットワークか応用層で利用可能にするかもしれません。

Carlberg                     Informational                      [Page 5]

RFC 4375                ETS Domain Requirements             January 2006

[5ページ]RFC4375ETSドメイン要求性2006年1月の情報のCarlberg

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]に提示されたセキュリティに関するコメントと要件を再検討して、後をつけることを勧めます。 それを言ったので、多くのインスタンスがイントラドメインセキュリティが保持されて、aでは、その相互ドメインセキュリティが標準で(すなわち、それほど厳しくない)下げられているということであるところである傾向があります。 例えば、管理者が管理ドメインの中のリソースの間の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でのMIBsに関する“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.

- Simple Network Managementプロトコル(SNMP)のほとんどの現在の展開がSNMPv3の前のバージョンのものです、SNMPのそれらのバージョンにはよく知られるセキュリティの脆弱性がありますが。

     - 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アトキンソン、ジェイムズ・ポーク、スコット・ブラドナー、ジョン・ピーターソン、およびイアン・ブラウンをありがとうございます。

Carlberg                     Informational                      [Page 6]

RFC 4375                ETS Domain Requirements             January 2006

[6ページ]RFC4375ETSドメイン要求性2006年1月の情報のCarlberg

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.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

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

[RFC3031] ローゼンとE.とViswanathan、A.とR.Callon、「Multiprotocolラベル切り換えアーキテクチャ」、RFC3031、2001年1月。

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

[RFC3689] CarlbergとK.とR.アトキンソン、「非常時の電気通信サービス(ETS)のための一般要件」、RFC3689、2004年2月。

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

K.、「ただ一つの管理ドメインの中で非常時のテレコミュニケーションがサービス(ETS)であるとサポートするためのフレームワーク」という[フレーム]Carlbergは進行中(2005年12月)で働いています。

Author's Address

作者のアドレス

   Ken Carlberg
   G11
   123a Versailles Circle
   Baltimore, MD
   USA

ケン・Carlberg G11 123aベルサイユ円のMDボルチモア(米国)

   EMail: carlberg@g11.org.uk

メール: carlberg@g11.org.uk

Carlberg                     Informational                      [Page 7]

RFC 4375                ETS Domain Requirements             January 2006

[7ページ]RFC4375ETSドメイン要求性2006年1月の情報のCarlberg

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

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

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Carlberg                     Informational                      [Page 8]

Carlberg情報です。[8ページ]