[要約] RFC 3198は、ポリシーベースの管理に関する用語とその目的を定義している。ポリシーベースの管理は、ネットワークやシステムの設定や制御を効率的に行うための手法である。
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.
Copyright（c）The Internet Society（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のアプローチと形式を取得します。意図は、ネットワークポリシー、特にインターネット標準ドキュメント（ISD）を扱う書き込みの包括性と一貫性を改善することです。
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]:
意図は、インターネット標準ドキュメント（ISD）の包括性と一貫性を改善することです。つまり、RFC、インターネットドラフト、およびインターネット標準プロセスの一部として生成されたその他の資料[RFC2026]です。ISD全体の利点は、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 「明確で簡潔で、簡単に理解されたドキュメント」 - 一連の用語と定義が、すべてのISDにわたって一貫性があり、自立し、均一であることが必要です。
o Technical Excellence - Where all ISDs use terminology accurately, precisely, and unambiguously.
o 技術的な卓越性 - すべてのISDが用語を正確に、正確に、そして明確に使用する場合。
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:
可能な限り、このドキュメントは既存のISDから定義を取得します。注意すべきこと：
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 ISD全体に複数の定義が存在する場合があります。各定義は、そのソースとともにリストされています。
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とMIBSは別のものです。
- "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.
- 「A」は、特定のワークグループと一般的な「使用領域」をポリシーの識別します。たとえば、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は、システムの管理者とユーザーが設定したポリシーに基づいて、システムおよび環境の制御、認証、承認、および会計を扱います。ポリシーの使用は、半径[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のコアモデルと共通モデルを表し、「エンタープライズ」の情報モデルを定義します - 一般的な概念（コア）、およびシステム、デバイス、ユーザー、ソフトウェア分布、物理環境、ネットワーク、ポリシー（一般的なモデル）。（「情報モデル」も参照してください。）
$ 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）とそのクライアント（ポリシー執行ポイント、PEPS）[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.
- ネットワーク要素の静的セットアップ。顧客に出荷する前に行われ、顧客が変更できません。1つ目は、インターネットコミュニティで受け入れられている使用法です。
$ COPS See "Common Open Policy Service".
$ 警官は「一般的なオープンポリシーサービス」を参照してください。
$ 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-Fieldと呼ばれるIPヘッダーフィールドを差別化したサービス（DS）（T）。IPv4では、TOS（サービスのタイプ）Octetのレイアウトを定義します。IPv6では、トラフィッククラスのOctet [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".)
$ Directory Enabled Networks（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.)
$ MPLには「マルチプロトコルラベルスイッチング」を参照してください。（また、MPLは光ネットワークでのマルチプロトコルLambdaスイッチングを指す場合があります。しかし、これはポリシーとは無関係であり、このドキュメントではこれ以上議論されていません。）
$ 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は、COPS-RSVPを使用してPDPにクエリを送信し、ポリシー決定[RFC2205、RFC2748]を要求する場合があります。「アウトソーシングされたポリシー」は「プロビジョニングされたポリシー」とは対照的ですが、相互に排他的なものではなく、運用システムは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".)
個々のルールはビジネス目標をサポートするために定義される可能性があるため、これらの2つの見解は矛盾していないことに注意してください。（「ポリシー目標」、「ポリシー抽象化」、「ポリシールール」も参照してください。）
$ 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]では、ルールの条件は、ステートメントのandedセット（偏見のある形式）のセット、またはステートメントのoredセットのandedセット（接続詞正規形式）のいずれかとして表現できます。個々の状態ステートメントも否定できます。
$ 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つの視点が存在します。ルールは真です
$ 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]。このポリシードメインの定義は、組織内の複数のポリシー作成ソースを排除するものではなく、結果のポリシーを調整する必要があります。 - 1つのドメインのコンテキストで定義されているポリシーは、そのドメインの外で通信または交渉する必要がある場合があります。（「政策交渉」も参照してください。）
$ 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）モジュールとして定義される関連プロビジョニングクラス（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）ポリシー関連サービスを要求するメッセージ。これは、特定の一連のポリシールールを取得し、実施するアクションまたはその他のポリシーリクエストを決定するリクエストを指す場合があります。PEPによってPDPに送信されると、「ポリシー決定要求」[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.
$ ポリシーグループ（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）ポリシーデータの種類を表す順序付きの属性セット。PRCは、PIBモジュール（SPPIを使用してエンコード）で定義され、オブジェクト識別子ツリーに登録されています。各PRCのインスタンスは、SMIV2の概念テーブルと同様に、表に編成されています。（「ポリシープロビジョニング情報の構造」および「ポリシー情報ベース」も参照してください。）頭字語PRCは、「ポリシールールクラス」から「プロビジョニングクラス」に進化しました。変更の理由は、PCIMおよび業界での他の使用と比較して、PRCコンテキストでの「政策ルール」という言葉の使用との間に矛盾が存在したためです。後者では、ルールはIF/thenステートメントであり、アクションへの条件の拘束力です。PRCは、この定義による「ルール」ではなく、デバイスの（ネットワーク全体の）構成情報のエンコードです。
$ PRovisioning Instance (PRI) (T) An instantiation of a PRovisioning Class. (See also "PRovisioning Class".)
$ プロビジョニングインスタンス（PRI）（t）プロビジョニングクラスのインスタンス化。（「プロビジョニングクラス」も参照してください。）
$ 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）高レベルの抽象化では、「サービス品質」とは、サービスレベル契約で指定されたパラメーターに従ってネットワークサービスを提供する機能を指します。「品質」とは、サービスの可用性、遅延、ジッター、スループット、パケット損失率によって特徴付けられます。ネットワークリソースレベルでは、「サービス品質」とは、サービスプロバイダーがトラフィック、制御帯域幅、およびネットワークレイテンシを優先できるようにする一連の機能を指します。IPネットワークには「サービス品質」には2つの異なるアプローチがあります。統合サービス[RFC1633]と差別化されたサービス[RFC2475]です。統合されたサービスには、信号留置の作成に対するポリシー管理が必要であり、フローのセットに対して特定の定量的エンドツーエンドの動作を提供します。対照的に、差別化されたサービスには、パケットのDS-Fieldのコードポイントと個々のホップごとの動作の対応を定義するポリシーが必要です（指定されたドメインごとの動作を実現するため）。最大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]。また、差別化されたサービスネットワークでアプリケーショントラフィックのQOを管理するためのシグナル伝達メカニズム。
$ 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を使用してクラス階層を描写します。モデルでは関係/関連性が重要です。 - 管理された要素の管理的に指定された特性（たとえば、インターフェイス）。これは、ポリシールールとプロビジョニングクラス（PRC）のセレクターであり、特定の管理された要素[RFC3060]へのルール/PRCの適用性を決定します。3番目の定義（ポリシーのセレクターとしての役割）のみが、ネットワークポリシーの管理に直接関連しています。ただし、最初の定義（ビジネスポジションと機能としての役割）は、ポリシー条件とアクションで参照される場合があります。
$ 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.
$ 役割の組み合わせ（P）管理された要素を特徴付け、ポリシールールとプロビジョニングクラス（PRC）の適用性を示す辞書編成的に順序付けられた役割のセット。ポリシーシステムは、管理された要素によって報告された一連の役割を使用して、執行のために送信される正しいルール/PRCを決定します。その決定は、役割の組み合わせ、そのサブコンビネーション、および組み合わせの個々の役割によって特定されたすべての適用可能なポリシールールを調べることができます[RFC3060]。PRCSの場合、PRCは、適用および/または施行されるために、管理された要素の役割の組み合わせと明示的に一致する必要があります。（通常、比較はケースに敏感です。）施行のためのルール/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）スキーマの2つの異なる視点が定義されています。-データベースまたはディレクトリサービス[dirservs]に保存できるデータを決定する一連のルール - それぞれ同じタイプのリポジトリにバインドされているデータモデルのコレクション。後者は、インターネット標準のドキュメントに推奨され、推奨されるものです。（「データモデル」も参照してください。）
$ 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「Simple Network Management Protocol」を参照してください。
$ 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".)
$ ポリシープロビジョニング情報の構造（SPPI）（t）関連するプロビジョニングクラスのコレクションをPIB [RFC3159]としてエンコードするために使用される、SNMPの管理情報構造（SMIV2）の適応されたサブセット[RFC3159]。（「ポリシー情報ベース」および「プロビジョニングクラス」も参照してください。）
$ 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.
このドキュメントは、以前の用語ドラフトの作業に基づいています。これらの文書の著者は、Fran Reichmeyer、Dan Grossman、John Strassner、Ed Ellesson、Matthew Condellでした。また、ポリシーと政策の規則の一般的な概念の定義には、Predrag Spasicからの入力が含まれます。Juergen Schoenwaelder、Joe Salowey、Jon Saperia、Ravi Sahita、Bob Moore、Guus Sliepen、T.H。ジョナタンとデイブパーキンス。
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. Sprague、および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。グッド。Macmillan Technical Publications、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.Distributed Management Task Force、Inc。CIM V2.Xスキーマのコンポーネントは、次のDMTF Webページのリンクを介して入手できます：http：//www.dmtf.org/standards/standard_cim.php。
[RFC1633] Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: An Overview", RFC 1633, June 1994.
[RFC1633] Braden、R.、Clark、D。、およびS. Shenker、「インターネットアーキテクチャにおける統合サービス：概要」、RFC 1633、1994年6月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner、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.、Rubens、A.、Simpson、W。およびS. Willens、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2138、1997年4月。
[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] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（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] Nichols、K.、Blake、S.、Baker、F。およびD. Black、「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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスの建築」、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] Case、J.、Mundy、R.、Partain、D。、およびB. Stewart、「インターネット標準ネットワーク管理フレームワークのバージョン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.、Perkins、D.、Schoenwaelder、J.、Case、J.、Rose、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.、Malcolm、J.、Agogbua、J.、O'dell、M.、J。McManus、「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。
[RFC2749] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R. and A. Sastry, "COPS Usage for RSVP", RFC 2749, January 2000.
[RFC2749] Herzog、S.、Boyle、J.、Cohen、R.、Durham、D.、Rajan、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. Guerin、「政策ベースの入場管理の枠組み」、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] Moore、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] Chan、K.、Seligson、J.、Durham、D.、Gai、S.、McCloghrie、K.、Herzog、S.、Reichmeyer、F.、Yavatkar、R。ポリシープロビジョニング（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.、Fine、M.、Seligson、J.、Chan、K.、Hahn、S.、Sahita、R.、Smith、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.ブーチ、J。ランバウ、およびI.ジェイコブソン。Addison-Wesley、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、Volume VIII -Faccle VIII.8。Ccitt、Ixth Plenary Assembly、メルボルン。1988年11月。
Andrea Westerinen Cisco Systems, Bldg 20 725 Alder Drive Milpitas, CA 95035
Andrea Westerinen Cisco Systems、Bldg 20 725 Alder Drive Milpitas、CA 95035
EMail: andreaw@cisco.com
John Schnizlein Cisco Systems 9123 Loughran Road Fort Washington, MD 20744
ジョン・シュニズレイン・シスコ・システム9123ラフラン・ロード・フォート・ワシントン、メリーランド州20744
EMail: john.schnizlein@cisco.com
John Strassner Intelliden Corporation 90 South Cascade Avenue Colorado Springs, CO 80903 Phone: +1-719-785-0648
John Strassner Intelliden Corporation 90サウスカスケードアベニューコロラドスプリングス、CO 80903電話：1-719-785-0648
EMail: john.strassner@intelliden.com
Mark Scherling Xcert International Inc. Suite 300 505 Burrard Street Vancouver, BC V7X 1M3
Mark Scherling Xcert International Inc. Suite 300 505 Burrard Street Vancouver、BC V7X 1M3
EMail: mscherling@xcert.com
Bob Quinn
Celox Networks
2 Park Central Drive
Southborough, MA 01772
EMail: bquinn@celoxnetworks.com
Jay Perry Network Appliance 495 East Java Drive Sunnyvale, CA 94089
Jay Perry Networkアプライアンス495 East Java Drive Sunnyvale、CA 94089
EMail: jay.perry@netapp.com
Shai Herzog PolicyConsulting.com 200 Clove Rd. New Rochelle, NY 10801
Shai Herzog PolicyConsulting.com 200 Clove Rd。ニューロシェル、ニューヨーク10801
EMail: herzog@PolicyConsulting.com
An-Ni Huynh Lucent Technologies 2139 Route 35 Holmdel, NJ 07733
AN-NI Huynh Lucent Technologies 2139 Route 35 Holmdel、NJ 07733
Mark Carlson Sun Microsystems, Inc. 500 Eldorado Boulevard Broomfield, CO 80021
Mark Carlson Sun Systems、Inc。500 Eldorado Boulevard Broomfield、Co 80021
EMail: mark.carlson@sun.com
Steve Waldbusser
スティーブ・ウォルドバッサー
Phone: +1-650-948-6500
Fax: +1-650-745-0671
EMail: waldbusser@nextbeacon.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。