Network Working Group A. Westerinen
Request for Comments: 3198 J. Schnizlein
Category: Informational Cisco Systems
J. Strassner
Intelliden Corporation
M. Scherling
xCert
B. Quinn
Celox Networks
S. Herzog
PolicyConsulting
A. Huynh
Lucent Technologies
M. Carlson
Sun Microsystems
J. Perry
Network Appliance
S. Waldbusser
November 2001
Terminology for Policy-Based Management
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 (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
This document is a glossary of policy-related terms. It provides abbreviations, explanations, and recommendations for use of these terms. The document takes the approach and format of RFC 2828, which defines an Internet Security Glossary. The intent is to improve the comprehensibility and consistency of writing that deals with network policy, particularly Internet Standards documents (ISDs).
この文書では、ポリシー関連の用語集です。これは、これらの用語の使用のための略語、説明、および推奨事項を提供します。文書は、インターネットセキュリティ用語集を定義するRFC 2828のアプローチと形式を取ります。その意図は、ネットワークポリシー、特にインターネット標準文書（ISDS）を扱う書き込みのわかりやすさと一貫性を改善することです。
Table of Contents
目次
1. Introduction................................................... 2
2. Explanation of Paragraph Markings.............................. 3
3. Terms.......................................................... 3
4. Intellectual Property.......................................... 16
5. Acknowledgements............................................... 17
6. Security Considerations........................................ 17
7. References..................................................... 17
8. Authors' Addresses............................................. 19
9. Full Copyright Statement....................................... 21
This document provides abbreviations, definitions, and explanations of terms related to network policy. All definitions are provided in Section 3, with the terms listed in alphabetical order.
この文書では、略語、定義、およびポリシーをネットワークに関連する用語の解説を提供します。すべての定義は、アルファベット順にリストされている用語で、第3節で提供されています。
The intent is to improve the comprehensibility and consistency of Internet Standards documents (ISDs) -- i.e., RFCs, Internet-Drafts, and other material produced as part of the Internet Standards Process [RFC2026]. Benefits across the ISDs are well-stated in the Introduction to RFC 2828 [RFC2828]:
即ち、RFCは、インターネットドラフト、およびインターネット標準化過程[RFC2026]の一部として生成される他の物質 - 目的は、インターネット標準文書（ISDS）の理解度及び一貫性を改善することです。 ISDS全体のメリットはRFC 2828の概要[RFC2828]でよく述べています：
o "Clear, Concise, and Easily Understood Documentation" - Requires that the set of terms and definitions be consistent, self-supporting and uniform across all ISDs.
「クリア、簡潔、かつ容易に理解ドキュメンテーションの」o - すべてのISDS間で自立性と均一、用語と定義のセットが一貫している必要があります。
o Technical Excellence - Where all ISDs use terminology accurately, precisely, and unambiguously.
Oのテクニカル・エクセレンス - すべてのISDSは正確に、正確に、かつ明確に専門用語を使用しています。
o Prior Implementation and Testing - Requires that terms are used in their plainest form, that private and "made-up" terms are avoided in ISDs, and that new definitions are not created that conflict with established ones.
O前の実装とテスト - プライベートと「作られたアップ」の用語はISDSに回避される、用語はその最も明瞭形で使用されていることを必要とし、設立されたものとの競合という新しい定義が作成されません。
o "Openness, Fairness, and Timeliness" - Where ISDs avoid terms that are proprietary or otherwise favor a particular vendor, or that create a bias toward a particular technology or mechanism.
O「オープン性、公正性、および適時性」 - ISDSは独自のものか、そうでない場合は、特定のベンダーを好む、またはそれは、特定の技術やメカニズムへのバイアスを作成する用語を避けます。
Common and/or controversial policy terms are defined. These terms are directly related and specific to network policy.
共通および/または論争のポリシーの用語が定義されています。これらの用語は直接関係し、ネットワークポリシーに固有のものです。
Wherever possible, this document takes definitions from existing ISDs. It should be noted that:
可能な限り、このドキュメントは、既存のISDSから定義を取ります。注意すべきこと：
o Expired Internet-Drafts are not referenced, nor are their terminology and definitions used in this document.
O期限切れのインターネットドラフトは、参照され、またその用語とこのドキュメントで使用される定義されていません。
o Multiple definitions may exist across the ISDs. Each definition is listed, with its source.
O複数の定義はISDSを横切って存在してもよいです。それぞれの定義は、そのソースに、リストされています。
Section 3 marks terms and definitions as follows:
次のように第3章では、用語と定義をマーク：
o Capitalization: Only terms that are proper nouns are capitalized.
O資本金：のみ固有名詞ある用語は資産計上されます。
o Paragraph Marking: Definitions and explanations are stated in paragraphs that are marked as follows:
O段落マーキング：定義および説明は、次のようにマークされている段落に記載されています。
- "P" identifies basic policy-related terms.
- 「P」を基本方針に関連する用語を識別します。
- "T" identifies various techniques to create or convey policy-related information in a network. For example, COPS and an "Information Model" are two techniques for communicating and describing policy-related data. SNMP and MIBs are another.
- 「T」は、作成したり、ネットワーク内のポリシー関連情報を伝達するために様々な技術を識別する。例えば、COPSおよび「情報モデル」は、ポリシー関連のデータを通信し、記述するための2つの技術です。 SNMPとMIBは別です。
- "A" identifies specific Work Groups and general "areas of use" of policy. For example, AAA and QoS are two "areas of use" where policy concepts are extremely important to their function and operation.
- 「」特定の作業グループとポリシーの一般的な「使用領域」を特定します。例えば、AAAおよびQoSポリシーの概念は、その機能や操作に非常に重要な2つの「使用領域」です。
Note: In providing policy definitions, other "technology specific" terms (for example, related to Differentiated Services) may be used and referenced. These non-policy terms will not be defined in this document, and the reader is requested to go to the referenced ISD for additional detail.
注：ポリシー定義を提供する際に、他の「技術特異的」という用語は、（例えば、差別化サービスに関連する）を使用し、参照することができます。これらの非ポリシーの用語は、本文書で定義されていないだろう、と読者は追加の詳細のために参照ISDに行くために要求されています。
$ AAA See "Authentication, Authorization, Accounting".
$のAAAは、 "認証、認可、アカウンティング" を参照してください。
$ abstraction levels See "policy abstraction".
$抽象化レベルは、「ポリシーの抽象化」を参照してください。
$ action See "policy action".
$アクションは、「ポリシーのアクション」を参照してください。
$ Authentication, Authorization, Accounting (AAA) (A) AAA deals with control, authentication, authorization and accounting of systems and environments based on policies set by the administrators and users of the systems. The use of policy may be implicit - as defined by RADIUS [RFC2138]. In RADIUS, a network access server sends dial-user credentials to an AAA server, and receives authentication that the user is who he/she claims, along with a set of attribute-value pairs authorizing various service features. Policy is implied in both the authentication, which can be restricted by time of day, number of sessions, calling number, etc., and the attribute-values authorized.
$認証、許可、アカウンティング（AAA）（A）制御、認証、許可、および管理者とシステムのユーザが設定したポリシーに基づいて、システムや環境の会計とAAAのお得な情報。ポリシーの使用は、暗黙的であってもよい - RADIUS [RFC2138]によって定義されます。 RADIUSでは、ネットワークアクセスサーバーは、ダイヤルユーザーの資格情報をAAAサーバに送信し、ユーザーは、彼/彼女は、さまざまなサービス機能を許可属性と値のペアのセットと一緒に、主張している本人であることの認証を受けました。ポリシーはなど、番号を呼び出して、その日の時間によって制限することができ、認証、セッション数の両方で暗示され、属性値が許可されています。
$ CIM See "Common Information Model".
$ CIMは、「共通情報モデル」を参照してください。
$ Common Information Model (CIM) (T) An object-oriented information model published by the DMTF (Distributed Management Task Force) [DMTF]. It consists of a Specification detailing the abstract modeling constructs and principles of the Information Model, and a textual language definition to represent the Model. CIM's schemas are defined as a set of files, written in the language of the Specification, with graphical renderings using UML [UML]. Sets of classes and associations represent CIM's Core and Common Models, defining an information model for the "enterprise" - addressing general concepts (in Core), and systems, devices, users, software distribution, the physical environment, networks and policy (in the Common Models). (See also "information model".)
$共通情報モデル（CIM）（T）DMTF（分散管理タスクフォース）によって公表されたオブジェクト指向の情報モデル[DMTF]。これは、情報モデルの抽象モデリング構造と原則を詳述仕様、およびモデルを表現するためのテキスト言語の定義で構成されています。 CIMのスキーマは、UML [UML]を使用して、グラフィカルレンダリングで、仕様の言語で書かれたファイルのセットとして定義されています。クラスと関連のセットは、「企業」のための情報モデルを定義し、CIMのCoreと共通モデルを表す - （コアで）一般的な概念に対処し、システム、デバイス、ユーザー、ソフトウェア配布、物理的環境、ネットワークや政策（中共通モデル）。 （また、「情報モデル」を参照してください。）
$ Common Open Policy Service (COPS) (T) A simple query and response TCP-based protocol that can be used to exchange policy information between a Policy Decision Point (PDP) and its clients (Policy Enforcement Points, PEPs) [RFC2748]. The COPS protocol is used to provide for the outsourcing of policy decisions for RSVP [RFC2749]. Another usage is for the provisioning of policy [RFC3084]. (See also "Policy Decision Point" and "Policy Enforcement Point".)
$一般的なオープンポリシーサービス（COPS）（T）ポリシー決定ポイント（PDP）とそのクライアント（ポリシー実行ポイント、のPEP）[RFC2748]の間でポリシー情報を交換するために使用することができ、単純なクエリと応答TCPベースのプロトコル。 COPSプロトコルはRSVP [RFC2749]のための政策決定のアウトソーシングを提供するために使用されます。別の使用方法は、ポリシーのプロビジョニング[RFC3084]のためのものです。 （また、「ポリシー決定ポイント」と「ポリシー実行ポイント」を参照してください。）
$ condition See "policy condition".
$条件は、「ポリシー条件」を参照してください。
$ configuration (P) "Configuration" can be defined from two perspectives: - The set of parameters in network elements and other systems that determine their function and operation. Some parameters are static, such as packet queue assignment and can be predefined and downloaded to a network element. Others are more dynamic, such as the actions taken by a network device upon the occurrence of some event. The distinction between static (predefined) "configuration" and the dynamic state of network elements blurs as setting parameters becomes more responsive, and signaling controls greater degrees of a network device's behavior.
ネットワーク要素及びそれらの機能及び動作を決定する他のシステムのパラメータのセット - ：$構成（P）「構成」は、2つの観点から定義することができます。いくつかのパラメータは、このようなパケットキューの割り当てなど、静的であり、ネットワーク要素に事前に定義してダウンロードすることができます。他のものはそのようないくつかのイベントの発生時にネットワークデバイスによって実行されたアクションとして、より動的です。パラメータを設定すると、より敏感になり、ネットワーク装置の動作のシグナリングを制御大きい度と静的（事前定義）「構成」およびネットワーク要素の動的状態の区別があいまい。
- A static setup of a network element, done before shipment
to a customer and which cannot be modified by the customer.
The first is the accepted usage in the Internet community.
$ COPS See "Common Open Policy Service".
$のCOPSは、「一般的なオープンポリシーサービス」を参照してください。
$ data model (T) A mapping of the contents of an information model into a form that is specific to a particular type of data store or repository. A "data model" is basically the rendering of an information model according to a specific set of mechanisms for representing, organizing, storing and handling data. It has three parts [DecSupp]: - A collection of data structures such as lists, tables, relations, etc. - A collection of operations that can be applied to the structures such as retrieval, update, summation, etc. - A collection of integrity rules that define the legal states (set of values) or changes of state (operations on values). (See also "information model".)
$データモデル（T）データストアまたはリポジトリの特定のタイプに固有の形式への情報モデルの内容のマッピング。 「データモデル」は、基本的に表す整理、格納したデータを処理するためのメカニズムの特定のセットに応じて情報モデルのレンダリングです。等検索、更新、加算、などの構造に適用することができる操作のコレクション - - そのようなリスト、表、関係、等のようなデータ構造の集合 - のコレクション：それは、3つの部分[DecSupp]を有します法的状態（値のセット）、または状態の変化（値の操作）を定義する整合性規則。 （また、「情報モデル」を参照してください。）
$ DEN See "Directory Enabled Networks".
$ DENは、「ディレクトリ対応ネットワーク」を参照してください。
$ Differentiated Services (DS) (T) The IP header field, called the DS-field. In IPv4, it defines the layout of the ToS (Type of Service) octet; in IPv6, it is the Traffic Class octet [RFC2474]. (A) "Differentiated Services" is also an "area of use" for QoS policies. It requires policy to define the correspondence between codepoints in the packet's DS-field and individual per-hop behaviors (to achieve a specified per-domain behavior). In addition, policy can be used to specify the routing of packets based on various classification criteria. (See also "Quality of Service" and "filter".)
$差別化サービス（DS）（T）IPヘッダフィールドは、DS-フィールドと呼ばれます。 IPv4では、それのToS（サービスのタイプ）オクテットのレイアウトを定義します。 IPv6では、それは、トラフィッククラスオクテット[RFC2474]です。 （A）「差別化サービス」も、QoSポリシーのための「使用領域」です。これは、（指定されたドメインごとの動作を実現するために）、パケットのDSフィールドでコードポイントの対応関係を定義するための政策と、個々のホップ単位の動作を必要とします。また、ポリシーは、様々な分類基準に基づいてパケットのルーティングを指定するために使用することができます。 （「サービスの品質」と「フィルタ」も参照してください。）
$ diffserv See "Differentiated Services".
$ DiffServは「差別化サービス」を参照してください。
$ Directory Enabled Networks (DEN) (T) A data model that is the LDAP mapping of CIM (the Common Information Model). Its goals are to enable the deployment and use of policy by starting with common service and user concepts (defined in the information model), specifying their mapping/storage in an LDAP-based repository, and using these concepts in vendor/device-independent policy rules [DMTF]. (See also "Common Information Model" and "data model".)
$ディレクトリ対応のネットワーク（DEN）（T）CIM（共通情報モデル）のLDAPマッピングであるデータモデル。その目標は、共通のサービスおよびユーザ概念（情報モデルで定義される）から始まるLDAPベースのリポジトリ内のマッピング/ストレージを指定し、ベンダ/デバイス非依存ポリシーでこれらの概念を使用して、ポリシーの展開および使用を可能にするためでありますルール[DMTF]。 （また、「共通情報モデル」と「データモデル」を参照してください。）
$ domain (P) A collection of elements and services, administered in a coordinated fashion. (See also "policy domain".)
$ドメイン（P）協調様式で投与要素とサービスのコレクション、。 （また、「ポリシードメイン」を参照してください。）
$ DS See "Differentiated Services".
$ DSは「差別化サービス」を参照してください。
$ filter (T) A set of terms and/or criteria used for the purpose of separating or categorizing. This is accomplished via single-or multi-field matching of traffic header and/or payload data. "Filters" are often manipulated and used in network operation and policy. For example, packet filters specify the criteria for matching a pattern (for example, IP or 802 criteria) to distinguish separable classes of traffic.
$フィルタ（T）を分離または分類する目的で使用される用語および/または基準のセット。これは、トラフィックのヘッダ及び/又はペイロードデータのシングルまたはマルチフィールドマッチングを介して達成されます。 「フィルタ」は、多くの場合、操作およびネットワークの動作とポリシーで使用されています。例えば、パケットフィルタは、トラフィックの分離クラスを区別するためのパターン（例えば、IPまたは802基準）を合わせるための基準を指定します。
$ goal See "policy goal".
$目標は、「政策目標」を参照してください。
$ information model (T) An abstraction and representation of the entities in a managed environment, their properties, attributes and operations, and the way that they relate to each other. It is independent of any specific repository, software usage, protocol, or platform.
$情報モデル（T）の抽象化と表現管理された環境でのエンティティの、そのプロパティ、属性と操作、そして、彼らはお互いに関係する方法。これは、任意の特定のリポジトリ、ソフトウェアの使用状況、プロトコル、またはプラットフォームとは無関係です。
$ Management Information Base (MIB) (T) A collection of information that can be accessed via the Simple Network Management Protocol. Management information is defined in MIB modules using the rules contained in SNMP's Structure of Management Information (SMI) specifications [RFC2570]. Management information is an abstract concept, and definitions can be created for high level policy specifications, low level policy, as well as technology and vendor specific configurations, status and statistics. (See also "Simple Network Management Protocol" and "Structure of Management Information".)
$管理情報ベース（MIB）（T）簡易ネットワーク管理プロトコルを介してアクセスすることができる情報の収集。管理情報は、管理情報のSNMPの構造（SMI）の仕様[RFC2570]に含まれている規則を使用してMIBモジュールで定義されています。管理情報は抽象的な概念であり、定義は、高レベルのポリシー仕様、低レベルの政策だけでなく、技術やベンダー固有の設定、ステータスと統計のために作成することができます。 （また、「簡易ネットワーク管理プロトコル」と「経営情報の構造」を参照してください。）
$ MIB See "Management Information Base".
$ MIBは「管理情報ベース」を参照してください。
$ MPLS See "Multiprotocol Label Switching". (Also, MPLS may refer to Multi-Protocol Lambda Switching in optical networks. But, this is unrelated to policy and not discussed further in this document.)
$ MPLSを参照してください「マルチプロトコルラベルスイッチング」。 （また、MPLSは、光ネットワークに切り替え、マルチプロトコル・ラムダを指すことができる。しかし、これは本書でさらに議論方針としないとは無関係です。）
$ Multiprotocol Label Switching (MPLS) (T) Integrates a label swapping and switching framework with network layer routing [RFC2702]. The basic idea involves assigning short fixed length labels to packets at the ingress to an MPLS cloud. Throughout the interior of the MPLS domain, the labels attached to packets are used to make forwarding decisions (usually without recourse to the original packet headers).
$のマルチプロトコルラベルスイッチング（MPLS）（T）ネットワーク層ルーティングとフレームワークを交換し、ラベルスイッチングを統合[RFC2702]。基本的な考え方は、MPLSクラウドへの入力でのパケットに短い固定長ラベルを割り当てることを含みます。 MPLSドメインの内部を通して、パケットに添付ラベルは（通常、元のパケットヘッダに頼ることなく）転送決定を行うために使用されています。
$ outsourced policy (P) An execution model where a policy enforcement device issues a query to delegate a decision for a specific policy event to another component, external to it. For example, in RSVP, the arrival of a new RSVP message to a PEP requires a fast policy decision (not to delay the end-to-end setup). The PEP may use COPS-RSVP to send a query to the PDP, asking for a policy decision [RFC2205, RFC2748]. "Outsourced policy" is contrasted with "provisioned policy", but they are not mutually exclusive and operational systems may combine the two.
$外部委託されたポリシー（P）ポリシーの施行デバイスは外部の、別のコンポーネントに特定のポリシーイベントの決定を委任するためにクエリを発行し、実行モデル。例えば、RSVPに、PEPへの新しいRSVPメッセージの到着が速い政策決定を（エンド・ツー・エンドのセットアップを遅延させない）が必要です。 PEPは、政策決定[RFC2205、RFC2748]を求め、PDPにクエリを送信するためにCOPS-RSVPを使用することができます。 「外注政策は」「プロビジョニングポリシー」と対比されるが、それらは相互に排他的ではなく、運用システムは、2を組み合わせてもよいです。
$ PCIM See "Policy Core Information Model".
$のPCIMは、「ポリシーコア情報モデル」を参照してください。
$ PDP See "Policy Decision Point".
$ PDPは、「ポリシー決定ポイント」を参照してください。
$ PEP See "Policy Enforcement Point".
$ PEPは、「ポリシー実行ポイント」を参照してください。
$ PIB See "Policy Information Base".
$ PIBは、「ポリシー情報ベース」を参照してください。
$ policy (P) "Policy" can be defined from two perspectives: - A definite goal, course or method of action to guide and determine present and future decisions. "Policies" are implemented or executed within a particular context (such as policies defined within a business unit). - Policies as a set of rules to administer, manage, and control access to network resources [RFC3060].
現在および将来の決定を導くと決定するために、アクションの明確な目標、コースまたはメソッド - ：$方針（P）「ポリシー」は、2つの視点から定義することができます。 「ポリシー」は、（例えば、ビジネスユニット内で定義されたポリシーなど）、特定のコンテキスト内で実施または実行されます。 - 、管理、管理、およびネットワーク資源[RFC3060]へのアクセスを制御するルールのセットとして政策。
Note that these two views are not contradictory since
individual rules may be defined in support of business goals.
(See also "policy goal", "policy abstraction" and "policy
rule".)
$ policy abstraction (P) Policy can be represented at different levels, ranging from business goals to device-specific configuration parameters. Translation between different levels of "abstraction" may require information other than policy, such as network and host parameter configuration and capabilities. Various documents and implementations may specify explicit levels of abstraction. However, these do not necessarily correspond to distinct processing entities or the complete set of levels in all environments. (See also "configuration" and "policy translation".)
$ポリシーの抽象化（P）方針は、ビジネス目標からデバイス固有の設定パラメータに至るまで、さまざまなレベルで表現することができます。 「抽象」の異なるレベル間の変換は、ネットワークおよびホストパラメータ設定と機能として、ポリシー以外の情報を必要とするかもしれません。種々のドキュメントと実装は、抽象化の明示的なレベルを指定することができます。しかし、これらは必ずしも別個の処理エンティティまたはすべての環境でのレベルの完全なセットに対応していません。 （また、「設定」と「政策翻訳」を参照してください。）
$ policy action (P) Definition of what is to be done to enforce a policy rule, when the conditions of the rule are met. Policy actions may result in the execution of one or more operations to affect and/or configure network traffic and network resources. - In [RFC3060], a rule's actions may be ordered.
ルールの条件が満たされた場合、ポリシールールを強制するためにどう処理するかの$ポリシーアクション（P）の定義。ポリシーアクションは、影響を与え、および/またはネットワークトラフィックとネットワークリソースを設定するには、1つ以上の操作の実行をもたらすことができます。 - [RFC3060]では、ルールのアクションを注文することができます。
$ policy condition (P) A representation of the necessary state and/or prerequisites that define whether a policy rule's actions should be performed. This representation need not be completely specified, but may be implicitly provided in an implementation or protocol. When the policy condition(s) associated with a policy rule evaluate to TRUE, then (subject to other considerations such as rule priorities and decision strategies) the rule should be enforced. (T) In [RFC3060], a rule's conditions can be expressed as either an ORed set of ANDed sets of statements (disjunctive normal form), or an ANDed set of ORed sets of statements (conjunctive normal form). Individual condition statements can also be negated.
$ポリシー条件（P）ポリシールールのアクションを実行すべきかどうかを定義する必要な状態および/または前提条件の表現。この表現は完全に指定する必要はなく、暗黙的に実装またはプロトコルで提供されてもよいです。ポリシールールに関連付けられたポリシーの条件（複数可）はTRUE、次いで、（例えば、ルールの優先順位と決定戦略などの他の考慮事項に従う）を評価するとルールが適用されるべきです。 （T）は、[RFC3060]は、ルールの条件ステートメント（選言標準形）のAND演算セットの論理和集合、または文（連言標準形）の論理和集合の論理積集合のいずれかとして表すことができます。個々の条件文も否定することができます。
$ policy conflict (P) Occurs when the actions of two rules (that are both satisfied simultaneously) contradict each other. The entity implementing the policy would not be able to determine which action to perform. The implementers of policy systems must provide conflict detection and avoidance or resolution mechanisms to prevent this situation. "Policy conflict" is contrasted with "policy error".
$ポリシー競合（P）は（同時に満たされている）は、2つのルールのアクションが互いに矛盾したときに発生します。ポリシーを実装するエンティティが実行するアクションを決定することができないであろう。政策システムの実装者は、このような状況を防ぐために、競合の検出と回避または解決のメカニズムを提供しなければなりません。 「ポリシーの競合」は、「ポリシー・エラー」と対比されます。
$ policy conversion See "policy translation".
$の方針転換は、「ポリシーの翻訳」を参照してください。
$ Policy Core Information Model (PCIM) [RFC3060] (T) An information model describing the basic concepts of policy groups, rules, conditions, actions, repositories and their relationships. This model is described as a "core" model since it cannot be applied without domain-specific extensions (for example, extensions for QoS or IPsec). PCIM is "core" with respect to the area of policy. However, it is a "Common Model," with respect to CIM - in that it extends the basic CIM concepts for policy. (See also "Common Information Model".)
$方針コア情報モデル（PCIM）[RFC3060]（T）ポリシー・グループ、ルール、条件、アクション、リポジトリとその関係の基本的な概念を説明する情報モデル。それは、ドメイン固有の拡張機能（QOSまたはIPsecのための例えば、拡張）することなく適用することができないので、このモデルは、「コア」モデルとして記載されています。 PCIMは、ポリシーの面積に対する「コア」です。それは政策のための基本的なCIMの概念を拡張することで - しかし、それはCIMに関する「共通モデル」です。 （また、「共通情報モデル」を参照してください。）
$ policy decision (P) Two perspectives of "policy decision" exist: - A "process" perspective that deals with the evaluation of a policy rule's conditions - A "result" perspective that deals with the actions for enforcement, when the conditions of a policy rule are TRUE
$の政策決定（P）、「政策決定」存在の2つの視点： - 政策ルールの条件の評価を扱うA「プロセス」の視点 - 執行のための措置を扱う「結果」の視点、の条件ポリシールールはTRUEです
$ Policy Decision Point (PDP) (P) A logical entity that makes policy decisions for itself or for other network elements that request such decisions [RFC2753]. (See also "policy decision".)
$のポリシー決定ポイント（PDP）（P）自体、またはそのような決定を要求する他のネットワーク要素のポリシー決定を行う論理エンティティ[RFC2753]。 （また、「政策決定」を参照してください。）
$ policy domain (P) A collection of elements and services, and/or a portion of an Internet over which a common and consistent set of policies are administered in a coordinated fashion [RFC2474]. This definition of a policy domain does not preclude multiple sources of policy creation within an organization, but does require that the resultant policies be coordinated. - Policies defined in the context of one domain may need to be communicated or negotiated outside of that domain. (See also "policy negotiation".)
$ポリシードメイン（P）の要素とサービスのコレクション、および/またはポリシーの共通かつ一貫性のあるセットが協調して投与され、その上、インターネットの一部[RFC2474]。ポリシードメインのこの定義は、組織内のポリシー作成の複数のソースを排除するものではありませんが、結果として得られる政策を協調する必要がありません。 - 一つのドメインのコンテキストで定義されたポリシーは、そのドメインの外側に連通またはネゴシエートする必要があるかもしれません。 （また、「政策交渉」を参照してください。）
$ policy enforcement (P) The execution of a policy decision.
$のポリシーの施行（P）政策決定の実行。
$ Policy Enforcement Point (PEP) (P) A logical entity that enforces policy decisions [RFC2753]. (See also "policy enforcement".)
$ポリシー実行ポイント（PEP）（P）政策決定を施行する論理エンティティ[RFC2753]。 （また、「ポリシーの適用」を参照してください。）
$ policy error (P) "Policy errors" occur when attempts to enforce policy actions fail, whether due to temporary state or permanent mismatch between the policy actions and the device enforcement capabilities. This is contrasted with "policy conflict".
強制しようとする試み政策行動が原因政策行動とデバイス執行機能との間の一時的な状態または永久的な不整合か、失敗したときに（P）「政策の誤りは、」発生$ポリシーエラー。これは、「ポリシーの競合」と対比されます。
$ policy goal (P) Goals are the business objectives or desired state intended to be maintained by a policy system. As the highest level of abstraction of policy, these goals are most directly described in business rather than technical terms. For example, a goal might state that a particular application operate on a network as though it had its own dedicated network, despite using a shared infrastructure. 'Policy goals' can include the objectives of a service level agreement, as well as the assignment of resources to applications or individuals. A policy system may be created that automatically strives to achieve a goal through feedback regarding whether the goal (such as a service level) is being met.
$の政策目標（P）の目標政策システムによって維持されることを意図し、ビジネス目標や望ましい状態です。ポリシーの抽象化の最高レベルとしては、これらの目標は、最も直接的ではなく技術的な観点よりも、ビジネスで記載されています。例えば、目標はそれが共有インフラストラクチャを使用しているにもかかわらず、独自の専用ネットワークを持っていたかのように、特定のアプリケーションがネットワーク上で動作することを述べるかもしれません。 「政策の目標は、」サービスレベル契約の目的だけでなく、アプリケーションや個人へのリソースの割り当てを含めることができます。ポリシーシステムは自動的に（例えば、サービスレベルなど）目標が満たされているか否かに関するフィードバックを介して、目標を達成するために努力し、その作成されてもよいです。
$ Policy Information Base (PIB) (T) Collections of related PRovisioning Classes (PRCs), defined as a module. (See also "PRovisioning Class".)
$ポリシー情報ベース（PIB）（T）のモジュールとして定義され、関連のPRovisioningクラス（のPRCs）のコレクション。 （また、「プロビジョニング・クラス」を参照してください。）
$ policy mapping See "policy translation".
$ポリシーマッピング「政策翻訳」を参照してください。
$ policy negotiation (P) Exposing the desired or appropriate part of a policy to another domain. This is necessary to support partial interconnection between domains, which are operating with different sets of policies.
$ポリシー交渉（P）別のドメインへのポリシーの所望の又は適切な一部を露出させます。これは、ポリシーの異なるセットで動作しているドメインとの間の部分的な相互接続をサポートする必要があります。
$ policy repository (P) "Policy repository" can be defined from three perspectives: - A specific data store that holds policy rules, their conditions and actions, and related policy data. A database or directory would be an example of such a store. - A logical container representing the administrative scope and naming of policy rules, their conditions and actions, and related policy data. A "QoS policy" domain would be an example of such a container. - In [RFC3060], a more restrictive definition than the prior one exists. A PolicyRepository is a model abstraction representing an administratively defined, logical container for reusable policy elements.
ポリシールールを保持している特定のデータストア、その条件とアクション、および関連するポリシーデータ - ：$ポリシーリポジトリ（P）「ポリシーリポジトリは、」3つの視点から定義することができます。データベースまたはディレクトリには、店舗の例であろう。 - ポリシールール、それらの条件およびアクション、および関連するポリシーデータの管理範囲と命名を表す論理コンテナ。 「QoSポリシー」ドメインは、このような容器の例になります。 - [RFC3060]は、前のものよりもより制限定義が存在します。 PolicyRepositoryは、再利用可能なポリシー要素の管理者が定義し、論理コンテナを表すモデルの抽象化です。
$ policy request (P) A message requesting a policy-related service. This may refer to a request to retrieve a specific set of policy rules, to determine the actions to enforce, or other policy requests. When sent by a PEP to a PDP, it is more accurately qualified as a "policy decision request" [RFC2753]. (See also "policy decision".)
$政策要求（P）ポリシー関連のサービスを要求するメッセージ。これは、または他のポリシー要求を強制するアクションを決定するために、ポリシールールの特定のセットを取得するための要求を参照してもよいです。 PDPにPEPにより送信された場合は、より正確に、「政策決定の要求」[RFC2753]として認定されます。 （また、「政策決定」を参照してください。）
$ policy rule (P) A basic building block of a policy-based system. It is the binding of a set of actions to a set of conditions - where the conditions are evaluated to determine whether the actions are performed [RFC3060].
$ポリシールール（P）、ポリシー・ベースのシステムの基本的なビルディング・ブロック。条件は、アクションが実行されているかどうかを決定するために評価された[RFC3060] - これは、条件のセットに対する一連のアクションの結合です。
$ policy server (P) A marketing term whose definition is imprecise. Originally, [RFC2753] referenced a "policy server". As the RFC evolved, this term became more precise and known as the Policy Decision Point (PDP). Today, the term is used in marketing and other literature to refer specifically to a PDP, or for any entity that uses/services policy.
$ポリシーサーバ（P）その定義が不明確であるマーケティング用語。もともとは、[RFC2753]は、「ポリシーサーバ」を参照しました。 RFCが進化するにつれて、この用語は、より正確なとポリシー決定ポイント（PDP）として知られるようになりました。今日では、この用語は、PDPに、または/サービスポリシーを使用して任意のエンティティのために特別に参照するために、マーケティングおよび他の文献で使用されています。
$ policy translation (P) The transformation of a policy from a representation and/or level of abstraction, to another representation or level of abstraction. For example, it may be necessary to convert PIB data to a command line format. In this "conversion," the translation to the new representation is likely to require a change in the level of abstraction (becoming more or less specific). Although these are logically distinct tasks, they are (in most cases) blurred in the act of translating/converting/mapping. Therefore, this is also known as "policy conversion" or "policy mapping".
$ポリシー変換（P）表現及び/又は抽象化のレベルから、抽象化の別の表現またはレベルにポリシーの変換。例えば、コマンドライン形式にPIBデータを変換する必要があるかもしれません。この中で、「変換」、新しい表現への変換は、（多かれ少なかれ特定になること）の抽象化のレベルの変化を必要とする可能性が高いです。これらは論理的に明確なタスクですが、それらは（ほとんどの場合）翻訳/変換/マッピングの行為にぼやけています。したがって、これはまた、「ポリシー変換」または「ポリシーマッピング」として知られています。
$ PolicyGroup (T) An abstraction in the Policy Core Information Model [RFC3060]. It is a class representing a container, aggregating either policy rules or other policy groups. It allows the grouping of rules into a Policy, and the refinement of high-level Policies to lower-level or different (i.e., converted or translated) peer groups.
$のPolicyGroup（T）方針コア情報モデル[RFC3060]で抽象化。これは、ポリシールールまたは他のポリシーグループのいずれかを凝集、容器を表すクラスです。これは、ポリシーにルールのグループ化、および低レベルまたは異なる（すなわち、変換または翻訳）ピアグループにハイレベルのポリシーの改善を可能にします。
$ PRC See "PRovisioning Class".
$ PRCは、「プロビジョニング・クラス」を参照してください。
$ PRI See "PRovisioning Instance".
$ PRIは、「プロビジョニングインスタンス」を参照してください。
$ provisioned policy (P) An execution model where network elements are pre-configured, based on policy, prior to processing events. Configuration is pushed to the network device, e.g., based on time of day or at initial booting of the device. The focus of this model is on the distribution of configuration information, and is exemplified by Differentiated Services [RFC2475]. Based on events received, devices use downloaded (pre-provisioned) mechanisms to implement policy. "Provisioned policy" is contrasted with "outsourced policy".
$前処理イベントのポリシーポリシーに基づいて（P）のネットワーク要素が事前に設定された実行モデルを、プロビジョニング。コンフィギュレーションは、一日の時間に、またはデバイスの初期起動時に基づき、例えば、ネットワークデバイスにプッシュされます。このモデルの焦点は、コンフィギュレーション情報の分布にあり、差別化サービス[RFC2475]が挙げられます。イベントが受信に基づいて、デバイスがポリシーを実装するために（事前プロビジョニング）のメカニズムをダウンロードし使用します。 「プロビジョニングポリシーは」「外部委託されたポリシー」と対比されます。
$ PRovisioning Class (PRC) (T) An ordered set of attributes representing a type of policy data. PRCs are defined in PIB modules (encoded using SPPI) and registered in the Object Identifier tree. Instances of each PRC are organized in tables, similar to conceptual tables in SMIv2. (See also "Structure of Policy Provisioning Information" and "Policy Information Base".) The acronym, PRC, has evolved from "policy rule class" to "provisioning class". The reason for the change is that a discrepancy existed between the use of the words, "policy rule" in the PRC context versus other uses in PCIM and the industry. In the latter, rules are If/Then statements - a binding of conditions to actions. PRCs are not "rules" by this definition, but the encoding of (network-wide) configuration information for a device.
$食糧を供給クラス（PRC）は（T）アンは、ポリシーデータの種類を表す属性のセットを注文しました。位相応答曲線は、PIBモジュール（SPPIを使用して符号化）で定義され、オブジェクト識別子ツリーに登録されています。各PRCのインスタンスはSMIv2の概念テーブルと同様のテーブルに編成されます。 （「ポリシープロビジョニング情報の構造」と「ポリシー情報ベース」も参照してください。）頭字語、PRCは、「ポリシールール・クラス」に「プロビジョニング・クラス」から進化してきました。変更の理由は、矛盾がPCIMや業界の他の用途に対して、PRCコンテキスト内の単語、「ポリシールール」の使用の間に存在していることです。アクションへの条件の結合 - 後者では、ルールは、IF / then文です。位相応答曲線は、この定義による「ルール」ではなく、デバイスのための（ネットワーク全体）の構成情報の符号化。
$ PRovisioning Instance (PRI) (T) An instantiation of a PRovisioning Class. (See also "PRovisioning Class".)
$食糧を供給インスタンス（PRI）（T）のPRovisioningクラスのインスタンス化。 （また、「プロビジョニング・クラス」を参照してください。）
$ QoS See "Quality of Service".
$のQoSを参照してください「サービス品質」。
$ Quality of Service (QoS) (A) At a high level of abstraction, "Quality of Service" refers to the ability to deliver network services according to the parameters specified in a Service Level Agreement. "Quality" is characterized by service availability, delay, jitter, throughput and packet loss ratio. At a network resource level, "Quality of Service" refers to a set of capabilities that allow a service provider to prioritize traffic, control bandwidth, and network latency. There are two different approaches to "Quality of Service" on IP networks: Integrated Services [RFC1633], and Differentiated Service [RFC2475]. Integrated Services require policy control over the creation of signaled reservations, which provide specific quantitative end-to-end behavior for a (set of) flow(s). In contrast, Differentiated Services require policy to define the correspondence between codepoints in the packet's DS-field and individual per-hop behaviors (to achieve a specified per-domain behavior). A maximum of 64 per-hop behaviors limit the number of classes of service traffic that can be marked at any point in a domain. These classes of service signal the treatment of the packets with respect to various QoS aspects, such as flow priority and packet drop precedence. In addition, policy can be used to specify the routing of packets based on various classification criteria. Policy controls the set of configuration parameters and routing for each class in Differentiated Service, and the admission conditions for reservations in Integrated Services. (See also "policy abstraction" and "Service Level Agreement".)
抽象度の高いレベルでサービスの$品質（QoS）（A）は、「サービスの品質は、」サービスレベル契約で指定されたパラメータに応じてネットワークサービスを提供する能力を指します。 「品質」は、サービスの可用性、遅延、ジッタ、スループットおよびパケット損失率によって特徴付けられます。ネットワークリソースレベルでは、「サービスの質は、」サービスプロバイダは、トラフィック、制御帯域幅、およびネットワーク遅延の優先順位を決定できるようにする機能のセットを指します。統合サービス[RFC1633]、および差別化サービス[RFC2475]：2つのIPネットワーク上で、「サービスの質」への異なるアプローチがあります。統合サービスは、フロー（複数可）（のセット）に特異的な定量的なエンド・ツー・エンド動作を提供シグナリング予約の作成上のポリシー制御を必要とします。これとは対照的に、差別化サービスは、パケットのDSフィールドでコードポイントと個々のホップごとの挙動（指定したドメインごとの動作を実現するために）との間の対応を定義するポリシーを必要としています。 64ホップごとの挙動の最大値は、ドメイン内の任意の時点でマークすることができるサービストラフィックのクラスの数を制限します。サービスのこれらのクラスは、フローの優先度及びパケットのような種々のQoS側面に対してパケットの処理は、優先度をドロップ信号。また、ポリシーは、様々な分類基準に基づいてパケットのルーティングを指定するために使用することができます。ポリシーは、設定パラメータと差別化されたサービスでは、各クラスのルーティング、および統合サービスでの予約のための入学条件のセットを制御します。 （また、「政策の抽象化」と「サービスレベル契約」を参照してください。）
$ Resource reSerVation Protocol (RSVP) (T) A setup protocol designed for an Integrated Services Internet, to reserve network resources for a path [RFC2205]. And, a signaling mechanism for managing application traffic's QoS in a Differentiated Service network.
$リソース予約プロトコル（RSVP）（T）統合サービス、インターネットのために設計されたセットアッププロトコルは、パス[RFC2205]のためのネットワークリソースを予約します。そして、差別化サービスネットワークにおけるアプリケーショントラフィックのQoSを管理するためのシグナリングメカニズム。
$ role (P) "Role" is defined from three perspectives: - A business position or function, to which people and logical entities are assigned [X.500] - The labeled endpoints of a UML (Unified Modeling Language) association. Quoting from [UML], "When a class participates in an association, it has a specific role that it plays in that relationship; a role is just the face the class at the near end of the association presents to the class at the other end of the association". The Policy Core Information Model [RFC3060] uses UML to depict its class hierarchy. Relationships/associations are significant in the model. - An administratively specified characteristic of a managed element (for example, an interface). It is a selector for policy rules and PRovisioning Classes (PRCs), to determine the applicability of the rule/PRC to a particular managed element [RFC3060]. Only the third definition (roles as selectors of policy) is directly related to the management of network policy. However, the first definition (roles as business positions and functions) may be referenced in policy conditions and actions.
$の役割（P）「の役割は、」3つの視点から定義される： - 人との論理エンティティは[X.500]割り当てられているビジネスの位置や機能を、 - UML（統一モデリング言語）関連のラベルされたエンドポイントを。クラスが協会に参加したとき」、[UML]から引用すると、それはその関係で果たす特定の役割を持っています。役割は、関連の近端で顔だけのクラスです他端のクラスに提示します「協会の。方針コア情報モデル[RFC3060]はそのクラス階層を描くためにUMLを使用しています。関係/団体は、モデルで重要です。 - 管理対象要素（例えば、インタフェース）の管理指定特性。これは、特定の管理対象要素[RFC3060]のルール/ PRCの適用性を決定するために、ポリシールールおよびプロビジョニングクラス（位相応答曲線）するセレクタです。唯一の第三の定義（ポリシーのセレクタとしての役割）は、ネットワークポリシーの管理に直接関連しています。しかし、最初の定義（ビジネス位置や機能などの役割）はポリシー条件とアクションで参照されてもよいです。
$ role combination (P) A lexicographically ordered set of roles that characterize managed elements and indicate the applicability of policy rules and PRovisioning Classes (PRCs). A policy system uses the set of roles reported by the managed element to determine the correct rules/PRCs to be sent for enforcement. That determination may examine all applicable policy rules identified by the role combination, its sub-combinations and the individual roles in the combination [RFC3060]. In the case of PRCs, a PRC must explicitly match the role combination of the managed element in order to be applicable and/or enforced. (The comparison is typically case-sensitive.) The final set of rules/PRCs for enforcement are defined by the policy system, as appropriate for the specified role combination of the managed element.
$役割の組み合わせ管理対象要素を特徴付け、ポリシールールとプロビジョニングクラス（のPRCs）の適用性を示す役割（P）A、辞書式順序集合。政策システムは、執行のために送られるべき正しいルール/のPRCsを決定するために、管理要素によって報告されたロールのセットを使用しています。その決意は、ロールの組み合わせ、そのサブコンビネーションと組み合わせて、個々の役割[RFC3060]によって識別されるすべての適用可能なポリシールールを調べることができます。 PRCsの場合は、PRCは、明示的に適用および/または施行されるために、管理対象要素の役割の組み合わせと一致する必要があります。 （比較は、典型的には、大文字と小文字が区別される。）施行するためのルール/位相応答曲線の最終セットは、管理対象要素の指定された役割の組み合わせに応じて、ポリシーシステムによって定義されます。
$ RSVP See "Resource reSerVation Protocol".
$のRSVPは、「リソース予約プロトコル」を参照してください。
$ rule See "policy rule".
$ルールは、「ポリシールール」を参照してください。
$ rule based engine (T) A rule based engine is able to evaluate policy condition(s) and trigger appropriate policy actions. A particular rule based engine may only be capable of acting upon policy rules that are formatted in a specified way or adhere to a specific language.
$ルールベースエンジン（T）は、ルールベースのエンジンは、ポリシー条件（複数可）を評価し、適切なポリシーアクションをトリガーすることができます。特定のルールベースのエンジンは、指定された方法でフォーマットされた、または特定の言語に付着されているポリシールールに作用することが可能であってもよいです。
$ schema (T) Two different perspectives of schema are defined: - A set of rules that determines what data can be stored in a database or directory service [DirServs] - A collection of data models that are each bound to the same type of repository. The latter is the preferred and recommended one for Internet Standards documents. (See also "data model".)
$スキーマ（T）スキーマの二つの異なる視点が定義されている： - [DirServs]データは、データベースまたはディレクトリサービスに格納することができるかを決定する一連の規則 - 各リポジトリの同じタイプにバインドされたデータモデルのコレクション。後者が好ましく、インターネット標準文書のための1つをお勧めします。 （また、「データモデル」を参照してください。）
$ service (P) The behavior or functionality provided by a network, network element or host [DMTF, RFC2216]. Quoting from RFC 2216 [RFC2216], in order to completely specify a "service", one must define the "functions to be performed ..., the information required ... to perform these functions, and the information made available by the element to other elements of the system". Policy can be used to configure a "service" in a network or on a network element/host, invoke its functionality, and/or coordinate services in an interdomain or end-to-end environment.
$サービス（P）ネットワークによって提供される動作や機能、ネットワーク要素またはホスト[DMTF、RFC2216]。必要な情報は、これらの機能を実行するために...、...完全に「サービス」を指定するために、一方が実行される」関数を定義する必要があり、RFC 2216 [RFC2216]から引用、および要素によって利用可能な情報システムの他の要素に」。ポリシーは、ネットワークまたはネットワーク要素/ホスト上の「サービス」を設定し、その機能を呼び出す、および/またはドメイン間またはエンド・ツー・エンドの環境でサービスを調整するために使用することができます。
$ Service Level Agreement (SLA) (P) The documented result of a negotiation between a customer/consumer and a provider of a service, that specifies the levels of availability, serviceability, performance, operation or other attributes of the service [RFC2475]. (See also "Service Level Objective".)
$サービスレベル契約（SLA）の可用性、保守性、パフォーマンス、操作またはサービスの他の属性のレベルを指定する（P）顧客/消費者とサービス提供者の間の交渉の文書化された結果、[RFC2475]。 （「サービスレベル目標」も参照してください。）
$ Service Level Objective (SLO) (P) Partitions an SLA into individual metrics and operational information to enforce and/or monitor the SLA. "Service Level Objectives" may be defined as part of an SLA, an SLS, or in a separate document. It is a set of parameters and their values. The actions of enforcing and reporting monitored compliance can be implemented as one or more policies. (See also "Service Level Agreement".)
$サービスレベル目標（SLO）（P）が施行及び/またはSLAを監視するために、個々の指標や運用情報にSLAを分割します。 「サービスレベル目標は、」SLA、SLS、又は別の文書中の一部として定義することができます。これは、パラメータとその値のセットです。監視対象のコンプライアンスを徹底し、報告のアクションは、1つまたは複数のポリシーとして実装することができます。 （また、「サービスレベルアグリーメント」を参照してください。）
$ Service Level Specification (SLS) (P) Specifies handling of customer's traffic by a network provider. It is negotiated between a customer and the provider, and (for example) in a DiffServ environment, defines parameters such as specific Code Points and the Per-Hop-Behavior, profile characteristics and treatment of the traffic for those Code Points. An SLS is a specific SLA (a negotiated agreement) and its SLOs (the individual metrics and operational data to enforce) to guarantee quality of service for network traffic. (See also "Service Level Agreement" and "Service Level Objective".)
$サービスレベル仕様（SLS）（P）は、ネットワークプロバイダによって、顧客のトラフィックの処理を指定します。これは、顧客とプロバイダとの間でネゴシエートされ、（例えば）のDiffServ環境において、そのような特定のコードポイント当たりホップ挙動、プロファイル特性およびそれらのコードポイントのためのトラフィックの治療などのパラメータを定義しています。 SLSは、ネットワークトラフィックのサービスの質を保証するために、特定のSLA（交渉し契約）とそのSLOを（個別の指標や運用データを強制すること）です。 （また、「サービスレベル契約」と「サービスレベル目標」を参照してください。）
$ Simple Network Management Protocol (SNMP) (T) SNMP is a framework (including a protocol) for managing systems in a network environment [RFC2570]. It can be used for policy-based configuration and control using a specific MIB Module designed to execute policies on managed elements via scripts. The elements (instances) in a network device are evaluated using a policy filter, to determine where policy will be applied.
$簡易ネットワーク管理プロトコル（SNMP）（T）SNMPは、ネットワーク環境でシステムを管理するための（プロトコルを含む）フレームワーク[RFC2570]です。これは、スクリプト経由で管理対象要素に関する政策を実行するために設計された特定のMIBモジュールを使用して、ポリシーベースの構成および制御のために使用することができます。ネットワーク装置の要素（インスタンス）は、ポリシーが適用される場所を決定するために、ポリシー・フィルタを使用して評価されます。
$ SLA See "Service Level Agreement".
$ SLAを参照してください「サービスレベルアグリーメント」。
$ SLO See "Service Level Objective".
$ SLOは、「サービスレベル目標」を参照してください。
$ SLS See "Service Level Specification".
$は、「サービスレベル仕様」を参照してくださいSLS。
$ SMIv2 See "Structure of Management Information".
$ SMIv2の参照「経営情報の構造」。
$ SNMP See "Simple Network Management Protocol".
$のSNMPは、「簡易ネットワーク管理プロトコル」を参照してください。
$ SPPI See "Structure of Policy Provisioning Information".
$ SPPIは、「ポリシーのプロビジョニング情報の構造」を参照してください。
$ Structure of Policy Provisioning Information (SPPI) (T) An adapted subset of SNMP's Structure of Management Information (SMIv2) that is used to encode collections of related PRovisioning Classes as a PIB [RFC3159]. (See also "Policy Information Base" and "PRovisioning Class".)
PIB [RFC3159]などの関連のPRovisioningクラスのコレクションをエンコードするために使用されるポリシープロビジョニング情報（SPPI）（T）管理情報（SMIv2の）のSNMPの構造の適応サブセットの$構造。 （また、「ポリシー情報ベース」と「プロビジョニング・クラス」を参照してください。）
$ Structure of Management Information, version 2 (SMIv2) (T) An adapted subset of OSI's Abstract Syntax Notation One, ASN.1 (1988) used to encode collections of related objects as SNMP Management Information Base (MIB) modules [RFC2578].
管理情報の$構造、バージョン2（SMIv2の）（T）OSIの抽象構文記法1、ASN.1（1988）の適合サブセットは、SNMP管理情報ベース（MIB）モジュール[RFC2578]と関連オブジェクトの集合を符号化するために使用されます。
$ subject (P) An entity, or collection of entities, which originates a request, and is verified as authorized/not authorized to perform that request.
$件名（P）要求を発信し、許可/その要求を実行する権限がありませんと確認されたエンティティ、またはエンティティのコレクション、。
$ target (P) An entity, or collection of entities, which is affected by a policy. For example, the "targets" of a policy to reconfigure a network device are the individual services that are updated and configured.
$ターゲット（P）政策の影響を受けているエンティティ、またはエンティティのコレクション、。たとえば、ポリシーの「ターゲット」は、ネットワークデバイスを再構成するように更新され、設定されている個々のサービスがあります。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11.
IETFは、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。
Copies of claims of rights made available for publication 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 Secretariat.
権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、あるいは本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、その注意にこの標準を実践するために必要な場合があり技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 IETF専務に情報を扱ってください。
This document builds on the work of previous terminology drafts. The authors of these documents were Fran Reichmeyer, Dan Grossman, John Strassner, Ed Ellesson and Matthew Condell. Also, definitions for the general concepts of policy and policy rule include input from Predrag Spasic. Very helpful comments and suggestions were received from Juergen Schoenwaelder, Joe Salowey, Jon Saperia, Ravi Sahita, Bob Moore, Guus Sliepen, T.H. Jonatan and Dave Perkins.
この文書は、以前の用語のドラフトの作業に基づいています。これらの文書の著者は、フランReichmeyer、ダン・グロスマン、ジョンStrassner、エドEllessonとマシューCondellました。また、ポリシーおよびポリシールールの一般的な概念の定義はプレドラッグ・スパジックからの入力を含みます。非常に有益なコメントや提案はユルゲンSchoenwaelder、ジョーSalowey、ジョンSaperia、ラヴィSahita、ボブ・ムーア、フースSliepen、T.H.から受け取りましたJonatanとDaveパーキンス。
This document only defines policy-related terms. It does not describe in detail the vulnerabilities of, threats to, or mechanisms that protect specific policy implementations or policy-related Internet protocols.
この文書では、唯一のポリシー関連の用語を定義します。これは、詳細にへの脅威、脆弱性の、または特定のポリシーの実装やポリシー関連のインターネット・プロトコルを保護するメカニズムを説明していません。
[DecSupp] Building Effective Decision Support Systems. R. Sprague, and E. Carleson. Prentice Hall, 1982.
[DecSupp]効果的な意思決定支援システムの構築。 R.スプラーグ、およびE. Carleson。プレンティス・ホール、1982。
[DirServs] Understanding and Deploying LDAP Directory Services. T. Howes, M. Smith, and G. Good. MacMillan Technical Publications, 1999.
[DirServs]の理解と展開LDAPディレクトリサービス。 T.ハウズ、M.スミス、およびG.グッド。マクミラン技術出版、1999。
[DMTF] Common Information Model (CIM) Schema, version 2.x. Distributed Management Task Force, Inc. The components of the CIM v2.x schema are available via links on the following DMTF web page: http://www.dmtf.org/standards/standard_cim.php.
[DMTF]共通情報モデル（CIM）スキーマ、バージョン2.xのhttp://www.dmtf.org/standards/standard_cim.php：分散管理タスクフォース社は、CIMのバージョン2.xスキーマのコンポーネントには、次のDMTFのWebページ上のリンクからダウンロードできます。
[RFC1633] Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: An Overview", RFC 1633, June 1994.
[RFC1633]ブレーデン、R.、クラーク、D.とS. Shenker、 "インターネットアーキテクチャにおける統合サービス：概要"、RFC 1633、1994年6月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[RFC2138] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.
[RFC2138] Rigney、C.、ルーベンス、A.、シンプソン、W.及びS. Willens、RFC 2138、1997年4月 "ユーザーサービス（RADIUS）においてリモート認証ダイヤル"。
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.とS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"、RFC 2205、1997年9月。
[RFC2216] Shenker, S. and J. Wroclawski, "Network Element Service Specification Template", September 1997.
[RFC2216] Shenker、S.およびJ. Wroclawski、 "ネットワーク要素サービス仕様テンプレート"、1997年9月。
[RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]ニコルズ、K.、ブレイク、S.、ベイカー、F.とD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[RFC2475]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.とW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999.
[RFC2570]ケース、J.、マンディ、R.、パーテイン、D.とB.スチュワート、 "インターネット標準ネットワーク管理フレームワークのバージョン3への序論"、RFC 2570、1999年4月。
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S.Waldbusser, "Structure of Management Information Version 2 (SMIv2)", RFC 2578, April 1999.
[RFC2578] McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、M.及びS.Waldbusser、 "経営情報バージョン2（SMIv2）の構造"、RFC 2578、1999年4月。
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[RFC2702] Awduche、D.、マルコム、J.、Agogbua、J.、オデル、M.とJ.マクマナス、 "トラフィックエンジニアリングオーバーMPLSのための要件"、RFC 2702、1999年9月。
[RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.
[RFC2748]ダラム、D.、ボイル、J.、コーエン、R.、ヘルツォーク、S.、ラジャン、R.とA. Sastry、 "COPS（コモンオープンポリシーサービス）プロトコル"、RFC 2748、2000年1月。
[RFC2749] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R. and A. Sastry, "COPS Usage for RSVP", RFC 2749, January 2000.
[RFC2749]ヘルツォーク、S.、ボイル、J.、コーエン、R.、ダラム、D.、ラジャン、R.およびA. Sastry、 "RSVPの使用をCOPS"、RFC 2749、2000年1月。
[RFC2753] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000.
[RFC2753] Yavatkar、R.、Pendarakis、D.とR.ゲラン、 "ポリシーベースのアドミッション制御のためのフレームワーク"、RFC 2753、2000年1月。
[RFC2828] Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828, May 2000.
[RFC2828] Shirey、R.、 "インターネットセキュリティ用語集"、FYI 36、RFC 2828、2000年5月。
[RFC3060] Moore, B., Ellesson, E., Strassner, J. and A. Westerinen, "Policy Core Information Model -- Version 1 Specification", RFC 3060, February 2001.
[RFC3060]ムーア、B.、Ellesson、E.、Strassner、J.およびA. Westerinen、 "方針コア情報モデル - バージョン1つの仕"、RFC 3060、2001年2月。
[RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, R. and A. Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084, February 2001.
[RFC3084]チャン、K.、Seligson、J.、ダラム、D.、ガイ、S.、McCloghrie、K.、ヘルツォーク、S.、Reichmeyer、F.、Yavatkar、R.およびA.スミスは、「使用をCOPSポリシープロビジョニング（COPS-PR）」、RFC 3084、2001年2月のため。
[RFC3159] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn, S., Sahita, R., Smith, A. and F. Reichmeyer, "Structure of Policy Provisioning Information," RFC 3159, August 2001.
[RFC3159] McCloghrie、K.、ファイン、M.、Seligson、J.、チャン、K.、ハーン、S.、Sahita、R.、スミス、A.及びF. Reichmeyer、 "ポリシーのプロビジョニング情報の構造、" RFC 3159、2001年8月。
[UML] The Unified Modeling Language User Guide. G. Booch, J. Rumbaugh, and I. Jacobson. Addison-Wesley, 1999.
[UML]統一モデリング言語ユーザガイド。 G. Booch法、J. Rumbaugh、およびI.ヤコブソン。アディソン・ウェズリー、1999。
[X.500] Data Communications Networks Directory, Recommendations X.500-X.521, Volume VIII - Fascicle VIII.8. CCITT, IXth Plenary Assembly, Melbourne. November 1988.
[X.500]データ通信ネットワークディレクトリ、勧告X.500-X.521、ボリュームVIII - 分冊VIII.8。 CCITT、IXth総会、メルボルン。 1988年11月。
Andrea Westerinen Cisco Systems, Bldg 20 725 Alder Drive Milpitas, CA 95035
アンドレアWesterinenシスコシステムズ、ビル20 725アルダードライブミルピタス、CA 95035
EMail: andreaw@cisco.com
メールアドレス：andreaw@cisco.com
John Schnizlein Cisco Systems 9123 Loughran Road Fort Washington, MD 20744
ジョンSchnizleinシスコシステムズ9123ローラン・ロードフォートワシントン、MD 20744
EMail: john.schnizlein@cisco.com
メールアドレス：john.schnizlein@cisco.com
John Strassner Intelliden Corporation 90 South Cascade Avenue Colorado Springs, CO 80903 Phone: +1-719-785-0648
ジョンStrassner Intelliden株式会社90南カスケード・アベニューコロラドスプリングス、CO 80903電話：+ 1-719-785-0648
EMail: john.strassner@intelliden.com
メールアドレス：john.strassner@intelliden.com
Mark Scherling Xcert International Inc. Suite 300 505 Burrard Street Vancouver, BC V7X 1M3
マークScherling Xcertインターナショナル株式会社スイート300 505バラードストリートバンクーバー、BC V7X 1M3
EMail: mscherling@xcert.com
メールアドレス：mscherling@xcert.com
Bob Quinn Celox Networks 2 Park Central Drive Southborough, MA 01772
ボブ・クインCelox Networksの2パークセントラルドライブサウスボロ、MA 01772
EMail: bquinn@celoxnetworks.com
メールアドレス：bquinn@celoxnetworks.com
Jay Perry Network Appliance 495 East Java Drive Sunnyvale, CA 94089
ジェイ・ペリーネットワーク・アプライアンス495東ジャワドライブサニーベール、CA 94089
EMail: jay.perry@netapp.com
メールアドレス：jay.perry@netapp.com
Shai Herzog PolicyConsulting.com 200 Clove Rd. New Rochelle, NY 10801
シャイヘルツォークPolicyConsulting.com 200クローブRdを。ニューロシェル、NY 10801
EMail: herzog@PolicyConsulting.com
メールアドレス：herzog@PolicyConsulting.com
An-Ni Huynh Lucent Technologies 2139 Route 35 Holmdel, NJ 07733
そして、Niフイン・ルーセント・テクノロジーズ2139国道35ホルムデル、NJ 07733
Mark Carlson Sun Microsystems, Inc. 500 Eldorado Boulevard Broomfield, CO 80021
マーク・カールソンサン・マイクロシステムズ株式会社500エルドラド大通りブルームフィールド、CO 80021
EMail: mark.carlson@sun.com
メールアドレス：mark.carlson@sun.com
Steve Waldbusser
スティーブWaldbusser
Phone: +1-650-948-6500 Fax: +1-650-745-0671 EMail: waldbusser@nextbeacon.com
電話：+ 1-650-948-6500ファックス：+ 1-650-745-0671 Eメール：waldbusser@nextbeacon.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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 assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
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機能のための基金は現在、インターネット協会によって提供されます。