[要約] RFC 3060は、ポリシーコア情報モデルの仕様書であり、ポリシー管理に関する共通のデータモデルを提供します。このRFCの目的は、異なるポリシーシステム間での相互運用性を向上させることです。
Network Working Group B. Moore
Request for Comments: 3060 IBM
Category: Standards Track E. Ellesson
LongBoard, Inc.
J. Strassner
A. Westerinen
Cisco Systems
February 2001
Policy Core Information Model -- Version 1 Specification
ポリシーコア情報モデル - バージョン1仕様
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
Abstract
概要
This document presents the object-oriented information model for representing policy information developed jointly in the IETF Policy Framework WG and as extensions to the Common Information Model (CIM) activity in the Distributed Management Task Force (DMTF). This model defines two hierarchies of object classes: structural classes representing policy information and control of policies, and association classes that indicate how instances of the structural classes are related to each other. Subsequent documents will define mappings of this information model to various concrete implementations, for example, to a directory that uses LDAPv3 as its access protocol.
このドキュメントでは、IETFポリシーフレームワークWGで共同で開発されたポリシー情報を表現するためのオブジェクト指向の情報モデルと、分散管理タスクフォース（DMTF）の共通情報モデル（CIM）アクティビティへの拡張として提示されます。このモデルは、オブジェクトクラスの2つの階層を定義します。ポリシー情報とポリシーの制御を表す構造クラス、および構造クラスのインスタンスが互いにどのように関連しているかを示す関連クラスです。後続のドキュメントでは、この情報モデルのマッピングを、たとえば、LDAPV3をアクセスプロトコルとして使用するディレクトリなど、さまざまな具体的な実装に定義します。
Table of Contents
目次
1. Introduction.................................................... 4
2. Modeling Policies............................................... 5
2.1. Policy Scope............................................... 8
2.2. Declarative versus Procedural Model........................ 8
3. Overview of the Policy Core Information Model.................. 10
4. Inheritance Hierarchies for the Policy Core Information Model.. 13
4.1. Implications of CIM Inheritance........................... 15
5. Details of the Model........................................... 15
5.1. Reusable versus Rule-Specific Conditions and Actions...... 15
5.2. Roles..................................................... 17
5.2.1. Roles and Role Combinations............................. 17
5.2.2. The PolicyRoles Property................................ 21
5.3. Local Time and UTC Time in PolicyTimePeriodConditions..... 21
5.4. CIM Data Types............................................ 23
5.5. Comparison between CIM and LDAP Class Specifications...... 24
6. Class Definitions.............................................. 25
6.1. The Abstract Class "Policy"............................... 25
6.1.1. The Property "CommonName (CN)".......................... 26
6.1.2. The Multi-valued Property "PolicyKeywords".............. 26
6.1.3. The Property "Caption" (Inherited from ManagedElement).. 27
6.1.4. The Property "Description" (Inherited from
ManagedElement)......................................... 27
6.2. The Class "PolicyGroup"................................... 27
6.3. The Class "PolicyRule".................................... 29
6.3.1. The Property "Enabled".................................. 31
6.3.2. The Property "ConditionListType"........................ 31
6.3.3. The Property "RuleUsage"................................ 31
6.3.4. The Property "Priority"................................. 32
6.3.5. The Property "Mandatory"................................ 32
6.3.6. The Property "SequencedActions"......................... 33
6.3.7. The Multi-valued Property "PolicyRoles"................. 33
6.4. The Abstract Class "PolicyCondition"...................... 34
6.5. The Class "PolicyTimePeriodCondition"..................... 36
6.5.1. The Property "TimePeriod"............................... 38
6.5.2. The Property "MonthOfYearMask".......................... 39
6.5.3. The Property "DayOfMonthMask"........................... 39
6.5.4. The Property "DayOfWeekMask"............................ 40
6.5.5. The Property "TimeOfDayMask"............................ 41
6.5.6. The Property "LocalOrUtcTime"........................... 42
6.6. The Class "VendorPolicyCondition"......................... 42
6.6.1. The Multi-valued Property "Constraint".................. 43
6.6.2. The Property "ConstraintEncoding"....................... 43
6.7. The Abstract Class "PolicyAction"......................... 44
6.8. The Class "VendorPolicyAction"............................ 45
6.8.1. The Multi-valued Property "ActionData".................. 45
6.8.2. The Property "ActionEncoding"........................... 46
6.9. The Class "PolicyRepository".............................. 46
7. Association and Aggregation Definitions........................ 46
7.1. Associations.............................................. 47
7.2. Aggregations.............................................. 47
7.3. The Abstract Aggregation "PolicyComponent................. 47
7.4. The Aggregation "PolicyGroupInPolicyGroup"................ 47
7.4.1. The Reference "GroupComponent".......................... 48
7.4.2. The Reference "PartComponent"........................... 48
7.5. The Aggregation "PolicyRuleInPolicyGroup"................. 48
7.5.1. The Reference "GroupComponent".......................... 49
7.5.2. The Reference "PartComponent"........................... 49
7.6. The Aggregation "PolicyConditionInPolicyRule"............. 49
7.6.1. The Reference "GroupComponent".......................... 50
7.6.2. The Reference "PartComponent"........................... 50
7.6.3. The Property "GroupNumber".............................. 50
7.6.4. The Property "ConditionNegated"......................... 51
7.7. The Aggregation "PolicyRuleValidityPeriod"................ 51
7.7.1. The Reference "GroupComponent".......................... 52
7.7.2. The Reference "PartComponent"........................... 52
7.8. The Aggregation "PolicyActionInPolicyRule"................ 52
7.8.1. The Reference "GroupComponent".......................... 53
7.8.2. The Reference "PartComponent"........................... 53
7.8.3. The Property "ActionOrder".............................. 53
7.9. The Abstract Association "PolicyInSystem"................. 54
7.10. The Weak Association "PolicyGroupInSystem"............... 55
7.10.1. The Reference "Antecedent"............................. 55
7.10.2. The Reference "Dependent".............................. 55
7.11. The Weak Association "PolicyRuleInSystem"................ 56
7.11.1. The Reference "Antecedent"............................. 56
7.11.2. The Reference "Dependent".............................. 56
7.12. The Association "PolicyConditionInPolicyRepository"...... 56
7.12.1. The Reference "Antecedent"............................. 57
7.12.2. The Reference "Dependent".............................. 57
7.13. The Association "PolicyActionInPolicyRepository"......... 57
7.13.1. The Reference "Antecedent"............................. 58
7.13.2. The Reference "Dependent".............................. 58
7.14. The Aggregation "PolicyRepositoryInPolicyRepository"..... 58
7.14.1. The Reference "GroupComponent"......................... 58
7.14.2. The Reference "PartComponent".......................... 59
8. Intellectual Property.......................................... 59
9. Acknowledgements............................................... 59
10. Security Considerations....................................... 60
11. References.................................................... 62
12. Authors' Addresses............................................ 64
13. Appendix A: Class Identification in a Native CIM
Implementation................................................ 65
13.1. Naming Instances of PolicyGroup and PolicyRule........... 65
13.1.1. PolicyGroup's CIM Keys................................. 65
13.1.2. PolicyRule's CIM Keys.................................. 66
13.2. Naming Instances of PolicyCondition and Its Subclasses... 67
13.2.1. PolicyCondition's CIM Keys............................. 69
13.3. Naming Instances of PolicyAction and Its Subclasses...... 71
13.4. Naming Instances of PolicyRepository..................... 72
13.5. Role of the CreationClassName Property in Naming......... 73
13.6. Object References........................................ 73
14. Appendix B: The Core Policy MOF.............................. 75
15. Full Copyright Statement..................................... 100
This document presents the object-oriented information model for representing policy information currently under joint development in the IETF Policy Framework WG and as extensions to the Common Information Model (CIM) activity in the Distributed Management Task Force (DMTF). This model defines two hierarchies of object classes: structural classes representing policy information and control of policies, and association classes that indicate how instances of the structural classes are related to each other. Subsequent documents will define mappings of this information model to various concrete implementations, for example, to a directory that uses LDAPv3 as its access protocol. The components of the CIM schema are available via the following URL: http://www.dmtf.org/spec/cims.html [1].
このドキュメントでは、IETFポリシーフレームワークWGの共同開発中に現在共同開発中のポリシー情報を表すためのオブジェクト指向の情報モデルと、分散管理タスクフォース（DMTF）の共通情報モデル（CIM）アクティビティへの拡張として提示されます。このモデルは、オブジェクトクラスの2つの階層を定義します。ポリシー情報とポリシーの制御を表す構造クラス、および構造クラスのインスタンスが互いにどのように関連しているかを示す関連クラスです。後続のドキュメントでは、この情報モデルのマッピングを、たとえば、LDAPV3をアクセスプロトコルとして使用するディレクトリなど、さまざまな具体的な実装に定義します。CIMスキーマのコンポーネントは、次のURLから入手できます。http：//www.dmtf.org/spec/cims.html [1]。
The policy classes and associations defined in this model are sufficiently generic to allow them to represent policies related to anything. However, it is expected that their initial application in the IETF will be for representing policies related to QoS (DiffServ and IntServ) and to IPSec. Policy models for application-specific areas such as these may extend the Core Model in several ways. The preferred way is to use the PolicyGroup, PolicyRule, and PolicyTimePeriodCondition classes directly, as a foundation for representing and communicating policy information. Then, specific subclasses derived from PolicyCondition and PolicyAction can capture application-specific definitions of conditions and actions of policies.
このモデルで定義されているポリシークラスと協会は、あらゆるものに関連するポリシーを表すことができるほど十分に汎用的です。ただし、IETFでの最初のアプリケーションは、QoS（DiffServおよびIntServ）およびIPSECに関連するポリシーを表すためのものであると予想されます。これらのようなアプリケーション固有の領域のポリシーモデルは、いくつかの方法でコアモデルを拡張する場合があります。好ましい方法は、ポリシー情報を表現および伝達するための基盤として、ポリシーグループ、PolicyRule、およびPolicyTimeperiodConditionクラスを直接使用することです。次に、PolicyconditionとPolicationから派生した特定のサブクラスは、ポリシーの条件とアクションのアプリケーション固有の定義をキャプチャできます。
Two subclasses, VendorPolicyCondition and VendorPolicyAction, are also included in this document, to provide a standard extension mechanism for vendor-specific extensions to the Policy Core Information Model.
ベンダーポールコンディションとベンダーポリティク症の2つのサブクラスもこのドキュメントに含まれており、ベンダー固有の拡張の標準的な拡張メカニズムをポリシーコア情報モデルに提供します。
This document fits into the overall framework for representing, deploying, and managing policies being developed by the Policy Framework Working Group. It traces its origins to work that was originally done for the Directory-enabled Networks (DEN) specification, reference [5]. Work on the DEN specification by the DEN Ad-Hoc Working Group itself has been completed. Further work to standardize the models contained in it will be the responsibility of selected working groups of the CIM effort in the Distributed Management Task Force (DMTF). DMTF standardization of the core policy model is the responsibility of the SLA Policy working group in the DMTF.
このドキュメントは、ポリシーフレームワークワーキンググループによって開発されているポリシーを表現、展開、および管理するための全体的なフレームワークに適合します。それは、もともとディレクトリ対応ネットワーク（den）仕様、参照[5]で行われた作業に起源を追跡します。Den Ad-Hocワーキンググループ自体によるDEN仕様の作業が完了しました。その中に含まれるモデルを標準化するためのさらなる作業は、分散管理タスクフォース（DMTF）におけるCIM努力の選択されたワーキンググループの責任となります。DMTFコアポリシーモデルの標準化は、DMTFのSLAポリシーワーキンググループの責任です。
This document is organized in the following manner:
このドキュメントは、次の方法で編成されています。
o Section 2 provides a general overview of policies and how they are modeled.
o セクション2では、ポリシーの一般的な概要とそのモデル化方法を示します。
o Section 3 presents a high-level overview of the classes and associations comprising the Policy Core Information Model.
o セクション3では、ポリシーコア情報モデルで構成されるクラスと協会の高レベルの概要を示します。
o The remainder of the document presents the detailed specifications for each of the classes and associations.
o ドキュメントの残りの部分は、各クラスと協会の詳細な仕様を示しています。
o Appendix A overviews naming for native CIM implementations. Other mappings, such as LDAPv3, will have their own naming mechanisms.
o 付録AネイティブCIM実装の義務の概要。LDAPV3などの他のマッピングには、独自の命名メカニズムがあります。
o Appendix B reproduces the DMTF's Core Policy MOF specification.
o 付録Bでは、DMTFのコアポリシーMOF仕様を再現しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119, reference [3].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119、参照[3]に記載されているように解釈される。
The classes comprising the Policy Core Information Model are intended to serve as an extensible class hierarchy (through specialization) for defining policy objects that enable application developers, network administrators, and policy administrators to represent policies of different types.
ポリシーコア情報モデルを含むクラスは、アプリケーション開発者、ネットワーク管理者、ポリシー管理者がさまざまなタイプのポリシーを表すことができるポリシーオブジェクトを定義するための拡張可能なクラス階層（専門化を通じて）として機能することを目的としています。
One way to think of a policy-controlled network is to first model the network as a state machine and then use policy to control which state a policy-controlled device should be in or is allowed to be in at any given time. Given this approach, policy is applied using a set of policy rules. Each policy rule consists of a set of conditions and a set of actions. Policy rules may be aggregated into policy groups. These groups may be nested, to represent a hierarchy of policies.
ポリシー管理されているネットワークを考える1つの方法は、最初にネットワークを状態マシンとしてモデル化し、次にポリシーを使用して、どの状態がいつでも入力されるか、いつでも入力できるかを制御することです。このアプローチを考慮して、ポリシーは一連のポリシールールを使用して適用されます。各ポリシールールは、一連の条件と一連のアクションで構成されています。ポリシールールは、ポリシーグループに集約される場合があります。これらのグループは、ポリシーの階層を表すためにネストされる場合があります。
The set of conditions associated with a policy rule specifies when the policy rule is applicable. The set of conditions can be expressed as either an ORed set of ANDed sets of condition statements or an ANDed set of ORed sets of statements. Individual condition statements can also be negated. These combinations are termed, respectively, Disjunctive Normal Form (DNF) and Conjunctive Normal Form (CNF) for the conditions.
ポリシールールに関連する一連の条件は、ポリシールールが適用される場合に指定されます。一連の条件は、条件ステートメントのandedセットのセットまたはandedの声明のセットのいずれかとして表現できます。個々の状態ステートメントも否定できます。これらの組み合わせは、それぞれ条件に対して分離法の正常形態（DNF）と接続詞正常形式（CNF）と呼ばれます。
If the set of conditions associated with a policy rule evaluates to TRUE, then a set of actions that either maintain the current state of the object or transition the object to a new state may be executed.
ポリシールールに関連付けられた条件のセットがTrueに評価される場合、オブジェクトの現在の状態を維持するか、オブジェクトを新しい状態に遷移させる一連のアクションが実行される場合があります。
For the set of actions associated with a policy rule, it is possible to specify an order of execution, as well as an indication of whether the order is required or merely recommended. It is also possible to indicate that the order in which the actions are executed does not matter.
ポリシールールに関連付けられた一連のアクションの場合、実行命令を指定すること、および注文が必要かどうかを示すことができます。また、アクションが実行される順序が重要ではないことを示すことも可能です。
Policy rules themselves can be prioritized. One common reason for doing this is to express an overall policy that has a general case with a few specific exceptions.
ポリシールール自体に優先順位を付けることができます。これを行う一般的な理由の1つは、いくつかの特定の例外を除いて、一般的なケースを持つ全体的なポリシーを表現することです。
For example, a general QoS policy rule might specify that traffic originating from members of the engineering group is to get Bronze Service. A second policy rule might express an exception: traffic originating from John, a specific member of the engineering group, is to get Gold Service. Since traffic originating from John satisfies the conditions of both policy rules, and since the actions associated with the two rules are incompatible, a priority needs to be established. By giving the second rule (the exception) a higher priority than the first rule (the general case), a policy administrator can get the desired effect: traffic originating from John gets Gold Service, and traffic originating from all the other members of the engineering group gets Bronze Service.
たとえば、一般的なQoSポリシールールでは、エンジニアリンググループのメンバーから発信されるトラフィックがブロンズサービスを受けることであることを指定する場合があります。2番目のポリシールールは例外を表す場合があります。エンジニアリンググループの特定のメンバーであるジョンから発信されたトラフィックは、ゴールドサービスを取得することです。ジョンからのトラフィックは、両方のポリシールールの条件を満たしているため、2つのルールに関連するアクションは互換性がないため、優先事項を確立する必要があります。2番目のルール（例外）に最初のルール（一般的なケース）よりも優先度が高いことにより、ポリシー管理者は望ましい効果を得ることができます。ジョンからのトラフィックはゴールドサービスを獲得し、エンジニアリングの他のすべてのメンバーから発信されるトラフィックを得ることができます。グループはブロンズサービスを取得します。
Policies can either be used in a stand-alone fashion or aggregated into policy groups to perform more elaborate functions. Stand-alone policies are called policy rules. Policy groups are aggregations of policy rules, or aggregations of policy groups, but not both. Policy groups can model intricate interactions between objects that have complex interdependencies. Examples of this include a sophisticated user logon policy that sets up application access, security, and reconfigures network connections based on a combination of user identity, network location, logon method and time of day. A policy group represents a unit of reusability and manageability in that its management is handled by an identifiable group of administrators and its policy rules would be consistently applied
ポリシーは、スタンドアロンで使用するか、より精巧な機能を実行するためにポリシーグループに集約されます。スタンドアロンポリシーはポリシールールと呼ばれます。ポリシーグループは、ポリシールールの集約、またはポリシーグループの集約ですが、両方ではありません。ポリシーグループは、複雑な相互依存性を持つオブジェクト間の複雑な相互作用をモデル化できます。この例には、アプリケーションアクセス、セキュリティ、およびユーザーID、ネットワークの場所、ログオン方法、時刻の組み合わせに基づいてネットワーク接続を再構成する洗練されたユーザーログオンポリシーが含まれます。ポリシーグループは、その管理が管理者の識別可能なグループによって処理され、そのポリシールールが一貫して適用されるという点で、再利用性と管理性の単位を表します
Stand-alone policies are those that can be expressed in a simple statement. They can be represented effectively in schemata or MIBs. Examples of this are VLAN assignments, simple YES/NO QoS requests, and IP address allocations. A specific design goal of this model is to support both stand-alone and aggregated policies.
スタンドアロンのポリシーは、簡単な声明で表現できるポリシーです。それらはスキーマまたはMIBSで効果的に表現できます。この例は、VLANの割り当て、単純なYES/NO QOSリクエスト、およびIPアドレスの割り当てです。このモデルの特定の設計目標は、スタンドアロンと集約されたポリシーの両方をサポートすることです。
Policy groups and rules can be classified by their purpose and intent. This classification is useful in querying or grouping policy rules. It indicates whether the policy is used to motivate when or how an action occurs, or to characterize services (that can then be used, for example, to bind clients to network services). Describing each of these concepts in more detail, o Motivational Policies are solely targeted at whether or how a policy's goal is accomplished. Configuration and Usage Policies are specific kinds of Motivational Policies. Another example is the scheduling of file backup based on disk write activity from 8am to 3pm, M-F.
ポリシーグループとルールは、その目的と意図によって分類できます。この分類は、ポリシールールのクエリまたはグループ化に役立ちます。これは、ポリシーがいつまたはアクションが発生するかを動機付けるか、またはサービスを特徴付けるために使用されるかどうかを示します（たとえば、クライアントをネットワークサービスに結合するために使用できます）。これらの概念のそれぞれをより詳細に説明すると、o動機付けポリシーは、ポリシーの目標が達成されるかどうか、またはどのように達成されるかのみを対象としています。構成と使用ポリシーは、特定の種類の動機付けポリシーです。別の例は、午前8時から午後3時までのディスク書き込みアクティビティに基づくファイルバックアップのスケジューリングです。
o Configuration Policies define the default (or generic) setup of a managed entity (for example, a network service). Examples of Configuration Policies are the setup of a network forwarding service or a network-hosted print queue.
o 構成ポリシーマネージドエンティティ（たとえば、ネットワークサービス）のデフォルト（または汎用）セットアップを定義します。構成ポリシーの例は、ネットワーク転送サービスまたはネットワークホストの印刷キューのセットアップです。
o Installation Policies define what can and cannot be put on a system or component, as well as the configuration of the mechanisms that perform the install. Installation policies typically represent specific administrative permissions, and can also represent dependencies between different components (e.g., to complete the installation of component A, components B and C must be previously successfully installed or uninstalled).
o インストールポリシーは、システムまたはコンポーネントに配置できるものとできないものと、インストールを実行するメカニズムの構成を定義します。インストールポリシーは通常、特定の管理権限を表し、異なるコンポーネント間の依存関係を表すこともできます（たとえば、コンポーネントA、コンポーネントB、Cのインストールを完了するには、以前に正常にインストールまたはアンインストールする必要があります）。
o Error and Event Policies. For example, if a device fails between 8am and 9pm, call the system administrator, otherwise call the Help Desk.
o エラーとイベントポリシー。たとえば、デバイスが午前8時から午後9時まで故障した場合、システム管理者に電話して、それ以外の場合はヘルプデスクを呼び出します。
o Usage Policies control the selection and configuration of entities based on specific "usage" data. Configuration Policies can be modified or simply re-applied by Usage Policies. Examples of Usage Policies include upgrading network forwarding services after a user is verified to be a member of a "gold" service group, or reconfiguring a printer to be able to handle the next job in its queue.
o 使用ポリシーは、特定の「使用」データに基づいてエンティティの選択と構成を制御します。構成ポリシーは、使用ポリシーによって変更されたり、単に再適用されたりできます。使用ポリシーの例には、ユーザーが「ゴールド」サービスグループのメンバーであることが確認された後のネットワーク転送サービスのアップグレード、またはキューで次のジョブを処理できるようにプリンターを再構成することが含まれます。
o Security Policies deal with verifying that the client is actually who the client purports to be, permitting or denying access to resources, selecting and applying appropriate authentication mechanisms, and performing accounting and auditing of resources.
o セキュリティポリシーは、クライアントが実際にクライアントが誰であるかを証明し、リソースへのアクセスを許可または拒否し、適切な認証メカニズムの選択と適用、およびリソースの会計と監査の実行を確認することを扱っています。
o Service Policies characterize network and other services (not use them). For example, all wide-area backbone interfaces shall use a specific type of queuing.
o サービスポリシーは、ネットワークやその他のサービスを特徴付けます（使用しないでください）。たとえば、すべての広い地域のバックボーンインターフェイスは、特定のタイプのキューイングを使用するものとします。
Service policies describe services available in the network. Usage policies describe the particular binding of a client of the network to services available in the network.
サービスポリシーは、ネットワークで利用可能なサービスを説明しています。使用ポリシーは、ネットワークのクライアントがネットワークで利用可能なサービスに特定の拘束力を与えていることを説明しています。
These categories are represented in the Policy Core Information Model by special values defined for the PolicyKeywords property of the abstract class Policy.
これらのカテゴリは、抽象クラスポリシーのPolicyKeyWordsプロパティに対して定義された特別な価値によってポリシーコア情報モデルで表されます。
Policies represent business goals and objectives. A translation must be made between these goals and objectives and their realization in the network. An example of this could be a Service Level Agreement (SLA), and its objectives and metrics (Service Level Objectives, or SLOs), that are used to specify services that the network will provide for a given client. The SLA will usually be written in high-level business terminology. SLOs address more specific metrics in support of the SLA. These high-level descriptions of network services and metrics must be translated into lower-level, but also vendor-and device-independent specifications. The Policy Core Information Model classes are intended to serve as the foundation for these lower-level, vendor- and device-independent specifications.
ポリシーは、ビジネスの目標と目標を表します。これらの目標と目的と、ネットワークでのそれらの実現との間に翻訳を行う必要があります。この例は、サービスレベル契約（SLA）と、ネットワークが特定のクライアントに提供するサービスを指定するために使用されるその目的とメトリック（サービスレベルの目標、またはSLO）です。SLAは通常、高レベルのビジネス用語で記述されます。SLOSは、SLAをサポートするより具体的なメトリックに対処します。ネットワークサービスとメトリックのこれらの高レベルの説明は、低レベルだけでなく、ベンダーとデバイスに依存しない仕様に翻訳する必要があります。ポリシーコア情報モデルクラスは、これらの低レベルのベンダーおよびデバイスに依存しない仕様の基礎として機能することを目的としています。
It is envisioned that the definition of the Policy Core Informational Model in this document is generic in nature and is applicable to Quality of Service (QoS), to non-QoS networking applications (e.g., DHCP and IPSec), and to non-networking applications (e.g., backup policies, auditing access, etc.).
このドキュメントのポリシーコア情報モデルの定義は本質的に一般的であり、サービス品質（QOS）、非QOSネットワーキングアプリケーション（DHCPおよびIPSECなど）、および非ネットワーキングアプリケーションに適用できることを想定しています。（例えば、バックアップポリシー、監査アクセスなど）。
The design of the Policy Core Information Model is influenced by a declarative, not procedural, approach. More formally, a declarative language is used to describe relational and functional languages. Declarative languages describe relationships between variables in terms of functions or inference rules, to which the interpreter or compiler can apply a fixed algorithm in order to produce a result. An imperative (or procedural) language specifies an explicit sequence of steps to follow in order to produce a result.
ポリシーコア情報モデルの設計は、手続き上のアプローチではなく、宣言的なアプローチの影響を受けます。より正式には、関係言語と機能的言語を記述するために宣言言語が使用されます。宣言言語は、関数または推論ルールの観点から変数間の関係を説明します。これにより、インタープリターまたはコンパイラが結果を生成するために固定アルゴリズムを適用できます。命令的な（または手続き上の）言語は、結果を生み出すために従うべき一連のステップを明示的に指定します。
It is important to note that this information model does not rule out the use of procedural languages. Rather, it recognizes that both declarative as well as procedural languages can be used to implement policy. This information model is better viewed as being declarative because the sequence of steps for doing the processing of declarative statements tends to be left to the implementer. However, we have provided the option of expressing the desired order of action execution in this policy information model, and for expressing whether the order is mandatory or not. In addition, rather than trying to define algorithms or sets of instructions or steps that must be followed by a policy rule, we instead define a set of modular building blocks and relationships that can be used in a declarative or procedural fashion to define policies.
この情報モデルは、手続き言語の使用を除外していないことに注意することが重要です。むしろ、宣言的言語と手続き的言語の両方を使用してポリシーを実装できることを認識しています。この情報モデルは、宣言的なステートメントの処理を行うための一連の手順が実装者に委ねられる傾向があるため、宣言的であると見なされます。ただし、このポリシー情報モデルで希望する順序の実行実行を表現するオプションと、注文が必須かどうかを表現するオプションを提供しました。さらに、ポリシールールが続く必要があるアルゴリズムまたは一連の命令または手順を定義しようとするのではなく、代わりに、ポリシーを定義するために宣言的または手続き的な方法で使用できるモジュラービルディングブロックと関係のセットを定義します。
Compare this to a strictly procedural model. Taking such an approach would require that we specify the condition testing sequence, and the action execution sequence, in the policy repository itself. This would, indeed, constrain the implementer. This is why the policy model is characterized as a declarative one. That is, the information model defines a set of attributes, and a set of entities that contain these attributes. However, it does NOT define either the algorithm to produce a result using the attributes or an explicit sequence of steps to produce a result.
これを厳密な手続きモデルと比較してください。このようなアプローチをとるには、ポリシーリポジトリ自体で条件テストシーケンスとアクション実行シーケンスを指定する必要があります。実際、これは実装者を制約します。これが、ポリシーモデルが宣言的なものとして特徴付けられる理由です。つまり、情報モデルは、一連の属性と、これらの属性を含むエンティティのセットを定義します。ただし、属性を使用して結果を生成するアルゴリズムのいずれも定義したり、一連のステップを使用して結果を生成したりしません。
There are several design considerations and trade-offs to make in this respect.
この点で行うには、いくつかの設計上の考慮事項とトレードオフがあります。
1. On the one hand, we would like a policy definition language to be reasonably human-friendly for ease of definitions and diagnostics. On the other hand, given the diversity of devices (in terms of their processing capabilities) which could act as policy decision points, we would like to keep the language somewhat machine-friendly. That is, it should be relatively simple to automate the parsing and processing of the language in network elements. The approach taken is to provide a set of classes and attributes that can be combined in either a declarative or procedural approach to express policies that manage network elements and services. The key point is to avoid trying to standardize rules or sets of steps to be followed in defining a policy. These must be left up to an implementation. Interoperability is achieved by standardizing the building blocks that are used to represent policy data and information.
1. 一方では、定義と診断を容易にするために、ポリシー定義言語を合理的に人間に優しいものにしたいと考えています。一方、ポリシー決定ポイントとして機能する可能性のあるデバイスの多様性（処理能力の観点から）を考えると、言語を多少機械に優しいものにしたいと思います。つまり、ネットワーク要素の言語の解析と処理を自動化するのは比較的簡単なはずです。取られたアプローチは、ネットワーク要素とサービスを管理するポリシーを表現するための宣言的または手続き的アプローチのいずれかで組み合わせることができる一連のクラスと属性を提供することです。重要なポイントは、ポリシーを定義する際に従うべきルールまたは一連の手順を標準化しようとすることを避けることです。これらは実装に任される必要があります。相互運用性は、ポリシーデータと情報を表すために使用されるビルディングブロックを標準化することにより達成されます。
2. An important decision to make is the semantic style of the representation of the information.
2. 重要な決定は、情報の表現のセマンティックスタイルです。
The declarative approach that we are describing falls short of being a "true" declarative model. Such a model would also specify the algorithms used to combine the information and policy rules to achieve particular behavior. We avoid specifying algorithms for the same reason that we avoid specifying sets of steps to be followed in a policy rule. However, the design of the information model more closely follows that of a declarative language, and may be easier to understand if such a conceptual model is used. This leads to our third point, acknowledging a lack of "completeness" and instead relying on presenting information that the policy processing entity will work with.
私たちが説明している宣言的アプローチは、「真の」宣言モデルであることには至りません。このようなモデルは、情報とポリシーのルールを組み合わせて特定の動作を実現するために使用されるアルゴリズムも指定します。ポリシールールで従うべきステップのセットを指定しないようにするのと同じ理由で、アルゴリズムを指定しないようにします。ただし、情報モデルの設計は、宣言的言語の設計に従うものであり、そのような概念モデルが使用されるかどうかを理解しやすい場合があります。これは私たちの3番目のポイントにつながり、「完全性」の欠如を認め、代わりにポリシー処理エンティティが機能する情報を提示することに依存します。
3. It is important to control the complexity of the specification, trading off richness of expression of data in the core information model for ease of implementation and use. It is important to acknowledge the collective lack of experience in the field regarding policies to control and manage network services and hence avoid the temptation of aiming for "completeness". We should instead strive to facilitate definition of a set of common policies that customers require today (e.g., VPN and QoS) and allow migration paths towards supporting complex policies as customer needs and our understanding of these policies evolve with experience. Specifically, in the context of the declarative style language discussed above, it is important to avoid having full blown predicate calculus as the language, as it would render many important problems such as consistency checking and policy decision point algorithms intractable. It is useful to consider a reasonably constrained language from these perspectives.
3. 仕様の複雑さを制御し、実装と使用を容易にするために、コア情報モデルのデータの豊富さを取引することが重要です。ネットワークサービスを制御および管理するためのポリシーに関する分野での集合的な経験の欠如を認め、したがって「完全性」を目指す誘惑を避けることが重要です。代わりに、顧客が今日必要とする一連の一般的なポリシー（VPNやQOなど）の定義を促進し、顧客のニーズに応じて複雑なポリシーをサポートし、これらのポリシーの理解が経験とともに進化するように移行するように努力する必要があります。具体的には、上記の宣言スタイルの言語の文脈では、一貫性チェックやポリシー決定ポイントアルゴリズムなどの多くの重要な問題を扱いやすいものにするため、言語として完全に吹き込まれた述語計算を避けることが重要です。これらの視点から合理的に制約された言語を考慮すると便利です。
The Policy Core Information Model strikes a balance between complexity and lack of power by using the well understood logical concepts of Disjunctive Normal Form and Conjunctive Normal Form for combining simple policy conditions into more complex ones.
ポリシーコア情報モデルは、単純なポリシー条件をより複雑な条件に組み合わせるために、分離法の正常形態のよく理解されている論理概念と接続的な正常形式を使用することにより、複雑さと力の欠如のバランスを取ります。
The following diagram provides an overview of the five central classes comprising the Policy Core Information Model, their associations to each other, and their associations to other classes in the overall CIM model. Note that the abstract class Policy and the two extension classes VendorPolicyCondition and VendorPolicyAction are not shown.
次の図は、ポリシーコア情報モデル、相互の関連性、およびCIMモデル全体の他のクラスとの関連付けを含む5つの中央クラスの概要を示しています。抽象クラスのポリシーと2つの拡張クラスのベンダーポールコンディションとベンダーポリクリ症は表示されていないことに注意してください。
NOTE: For cardinalities, "*" is an abbreviation for "0..n".
注：枢機inalの場合、「*」は「0..N」の略語です。
+-----------+
| System |
..... +--^-----^--+ .....
. . 1. 1. . .
*.(a).* .(b) .(c) *.(d).*
+--v---v---------+ . . +-v---v------------+
| PolicyGroup <........ . | PolicyRepository |
| | w * . | |
+------^---------+ . +-----^---------^--+
*. . 0..1 . 0..1 .
.(e) . .(f) .(g)
*. . . .
+------v------+ w * . . .
| <................. . .
| PolicyRule | . .
| | . .
| | . .
| <........................ . .
| |* (h) . . .
| | . . .
| | . . .
| | . . .
| | . . .
| | . . .
| | . . .
| | .* .* .
| | +---------v-------v--+ .
| | | PolicyCondition | .
| | *+--------------------+ .
| | (i) ^ .
| <.............. I .
| |* . I .
| | .* ^ .
| | +----v----------------------+ .
| | | PolicyTimePeriodCondition | .
| | +---------------------------+ .
| | (j) .
| <......................... .
| |* . .
| | .* .
| | +----------v---------+* .
| | | PolicyAction <.......
+-------------+ +--------------------+
Figure 1. Overview of the Core Policy Classes and Relationships In this figure the boxes represent the classes, and the dotted arrows represent the associations. The following associations appear:
図1.コアポリシークラスと関係の概要この図のボックスはクラスを表し、点線の矢印は関連性を表します。次の関連付けが表示されます。
(a) PolicyGroupInPolicyGroup
(a) PolicyGroupinPolicyGroup
(b) PolicyGroupInSystem
(b) PolicyGroupInsystem
(c) PolicyRuleInSystem
(c) Policyruleinsystem
(d) PolicyRepositoryInPolicyRepository
(e) PolicyRuleInPolicyGroup
(e) policyruleinpolicygroup
(f) PolicyConditionInPolicyRepository
(g) PolicyActionInPolicyRepository
(g) policycationinpolicyrepository
(h) PolicyConditionInPolicyRule
(h) policyconditioninpolicyrule
(i) PolicyRuleValidityPeriod
(i) PolicyrulevalidityPeriod
(j) PolicyActionInPolicyRule
(j) PolicyactionInPolicyrule
An association always connects two classes. The "two" classes may, however, be the same class, as is the case with the PolicyGroupInPolicyGroup association, which represents the recursive containment of PolicyGroups in other PolicyGroups. The PolicyRepositoryInPolicyRepository association is recursive in the same way.
協会は常に2つのクラスを接続します。ただし、「2つの」クラスは、他のポリシーグループのポリシーグループの再帰的封じ込めを表すPolicyGroupinPolicyGroup Associationの場合と同じクラスである場合があります。PolicyRepositoryInpolicyrepository Associationも同じように再帰的です。
An association includes cardinalities for each of the related classes. These cardinalities indicate how many instances of each class may be related to an instance of the other class. For example, the PolicyRuleInPolicyGroup association has the cardinality range "*' (that is, "0..n") for both the PolicyGroup and PolicyRule classes. These ranges are interpreted as follows:
協会には、関連する各クラスの枢機inalが含まれます。これらの枢機inalは、各クラスのインスタンスが他のクラスのインスタンスに関連している可能性があることを示しています。たとえば、PolicyruleinPolicyGroup Associationには、PolicyGroupクラスとPolicyRuleクラスの両方に枢機inalの範囲があります。
o The "*" written next to PolicyGroup indicates that a PolicyRule may be related to no PolicyGroups, to one PolicyGroup, or to more than one PolicyGroup via the PolicyRuleInPolicyGroup association. In other words, a PolicyRule may be contained in no PolicyGroups, in one PolicyGroups, or in more than one PolicyGroup.
o ポリシーグループの隣に書かれた「*」は、Policyruleがポリシーグループ、1つのポリシーグループ、またはPolicyruleinpolicyGroup Associationを介して複数のポリシーグループに関連している可能性があることを示しています。言い換えれば、Policyruleは、ポリシーグループなし、1つのポリシーグループ、または複数のポリシーグループに含まれる場合があります。
o The "*" written next to PolicyRule indicates that a PolicyGroup may be related to no PolicyRules, to one PolicyRule, or to more than one PolicyRule via the PolicyRuleInPolicyGroup association. In other words, a PolicyGroup may contain no PolicyRules, one PolicyRule, or more than one PolicyRule.
o Policyruleの隣に書かれた「*」は、政策グループがPolicyruleinpolicygroup Associationを介してPolicyrule、1つのPolicyrule、または複数のPolicyruleに関連している可能性があることを示しています。言い換えれば、政策グループには、1つの政策、または複数の政策が含まれていない場合があります。
The "w" written next to the PolicyGroupInSystem and PolicyRuleInSystem indicates that these are what CIM terms "aggregations with weak references", or more briefly, "weak aggregations". A weak aggregation is simply an indication of a naming scope. Thus these two aggregations indicate that an instance of a PolicyGroup or PolicyRule is named within the scope of a System object. A weak aggregation implicitly has the cardinality 1..1 at the end opposite the 'w'.
PolicyGroupInsystemおよびPolicyruleinsystemの隣に書かれた「W」は、これらが「参照を弱い」、またはより簡単に「弱い集計」というものであることを示しています。凝集が弱いことは、単に命名範囲の兆候です。したがって、これらの2つの集計は、ポリシーグループまたはPolicyruleのインスタンスがシステムオブジェクトの範囲内で命名されていることを示しています。弱い集約は、「W」の反対側の最後にカーディナリティ1..1を暗黙的に持っています。
The associations shown in Figure 1 are discussed in more detail in Section 7.
図1に示す関連については、セクション7で詳しく説明します。
The following diagram illustrates the inheritance hierarchy for the core policy classes:
次の図は、コアポリシークラスの継承階層を示しています。
ManagedElement (abstract)
|
+--Policy (abstract)
| |
| +---PolicyGroup
| |
| +---PolicyRule
| |
| +---PolicyCondition (abstract)
| | |
| | +---PolicyTimePeriodCondition
| | |
| | +---VendorPolicyCondition
| |
| +---PolicyAction (abstract)
| |
| +---VendorPolicyAction
|
+--ManagedSystemElement (abstract)
|
+--LogicalElement (abstract)
|
+--System (abstract)
|
+--AdminDomain (abstract)
|
+---PolicyRepository
Figure 2. Inheritance Hierarchy for the Core Policy Classes ManagedElement, ManagedSystemElement, LogicalElement, System, and AdminDomain are defined in the CIM schema [1]. These classes are not discussed in detail in this document.
図2.コアポリシークラスの継承階層ManagedElement、ManagedsystemElement、論理、システム、およびAdmindomainの継承は、CIMスキーマで定義されています[1]。これらのクラスについては、このドキュメントで詳しく説明していません。
In CIM, associations are also modeled as classes. For the Policy Core Information Model, the inheritance hierarchy for the associations is as follows:
CIMでは、協会もクラスとしてモデル化されています。ポリシーコア情報モデルの場合、協会の継承階層は次のとおりです。
[unrooted]
|
+---PolicyComponent (abstract)
| |
| +---PolicyGroupInPolicyGroup
| |
| +---PolicyRuleInPolicyGroup
| |
| +---PolicyConditionInPolicyRule
| |
| +---PolicyRuleValidityPeriod
| |
| +---PolicyActionInPolicyRule
|
+---Dependency (abstract)
| |
| +---PolicyInSystem (abstract)
| |
| +---PolicyGroupInSystem
| |
| +---PolicyRuleInSystem
| |
| +---PolicyConditionInPolicyRepository
| |
| +---PolicyActionInPolicyRepository
|
+---Component (abstract)
|
+---SystemComponent
|
+---PolicyRepositoryInPolicyRepository
Figure 3. Inheritance Hierarchy for the Core Policy Associations
図3.コアポリシー協会の継承階層
The Dependency, Component, and SystemComponent associations are defined in the CIM schema [1], and are not discussed further in this document.
依存関係、コンポーネント、およびシステムコンポーネントの関連付けは、CIMスキーマ[1]で定義されており、このドキュメントではこれ以上説明されていません。
From the CIM schema, both properties and associations are inherited to the Policy classes. For example, the class ManagedElement is referenced in the associations Dependency, Statistics and MemberOfCollection. And, the Dependency association is in turn referenced in the DependencyContext association. At this very abstract and high level in the inheritance hierarchy, the number of these associations is very small and their semantics are quite general.
CIMスキーマから、プロパティと関連付けの両方がポリシークラスに継承されます。たとえば、クラスのマネージデリメントは、協会の依存、統計、およびメンバーオフコレクションで参照されます。また、依存関係協会は、依存関係コンテキスト協会で参照されます。継承階層のこの非常に抽象的で高いレベルでは、これらの関連性の数は非常に少なく、それらのセマンティクスは非常に一般的です。
Many of these inherited associations convey additional semantics that are not needed in understanding the Policy Core Information Model. In fact, they are defined as OPTIONAL in the CIM Schema - since their cardinality is "0..n" on all references. The PCIM document specifically discusses what is necessary to support and instantiate. For example, through subclassing of the Dependency association, the exact Dependency semantics in PCIM are described.
これらの継承された協会の多くは、ポリシーコア情報モデルを理解するために必要ではない追加のセマンティクスを伝えます。実際、CIMスキーマではオプションとして定義されています。これは、すべての参照でカーディナリティが「0..n」であるためです。PCIMドキュメントでは、サポートとインスタンス化に必要なものについて具体的に説明します。たとえば、依存関係のサブクラス化により、PCIMの正確な依存セマンティクスが説明されています。
So, one may wonder what to do with these other inherited associations. The answer is "ignore them unless you need them". You would need them to describe additional information and semantics for policy data. For example, it may be necessary to capture statistical data for a PolicyRule (either for the rule in a repository or for when it is executing in a policy system). Some examples of statistical data for a rule are the number of times it was downloaded, the number of times its conditions were evaluated, and the number of times its actions were executed. (These types of data would be described in a subclass of CIM_StatisticalInformation.) In these cases, the Statistics association inherited from ManagedElement to PolicyRule may be used to describe the tie between an instance of a PolicyRule and the set of statistics for it.
したがって、これらの他の継承された関連付けをどうするか疑問に思うかもしれません。答えは、「あなたがそれらを必要としない限りそれらを無視する」です。ポリシーデータの追加情報とセマンティクスを説明する必要があります。たとえば、Policyruleの統計データをキャプチャする必要がある場合があります（リポジトリのルールのいずれか、またはポリシーシステムで実行されている場合）。ルールの統計データのいくつかの例は、ダウンロードされた回数、その条件が評価された回数、およびそのアクションが実行された回数です。（これらのタイプのデータは、CIM_STATISTISTISINFOLMATIONのサブクラスで説明されます。）これらの場合、ManageDelementからPolicyruleに継承された統計協会を使用して、Policyruleのインスタンスとその統計のセットとの間のタイを記述することができます。
The following subsections discuss several specific issues related to the Policy Core Information Model.
次のサブセクションでは、ポリシーコア情報モデルに関連するいくつかの特定の問題について説明します。
Policy conditions and policy actions can be partitioned into two groups: ones associated with a single policy rule, and ones that are reusable, in the sense that they may be associated with more than one policy rule. Conditions and actions in the first group are termed "rule-specific" conditions and actions; those in the second group are characterized as "reusable".
ポリシー条件とポリシーアクションは、複数のポリシールールに関連付けられる可能性があるという意味で、単一のポリシールールに関連するものと再利用可能な2つのグループに分割できます。最初のグループの条件とアクションは、「ルール固有の」条件とアクションと呼ばれます。2番目のグループのものは、「再利用可能」として特徴付けられます。
It is important to understand that the difference between a rule-specific condition or action and a reusable one is based on the intent of the policy administrator for the condition or action, rather than on the current associations in which the condition or action participates. Thus a reusable condition or action (that is, one that a policy administrator has created to be reusable) may at some point in time be associated with exactly one policy rule, without thereby becoming rule-specific.
ルール固有の条件または行動と再利用可能な条件の違いは、条件またはアクションが参加する現在の関連付けではなく、条件または行動のポリシー管理者の意図に基づいていることを理解することが重要です。したがって、再利用可能な条件またはアクション（つまり、ポリシー管理者が再利用可能にするために作成されたもの）は、ある時点で正確に1つのポリシールールに関連付けられ、それによってルール固有のものになることはありません。
There is no inherent difference between a rule-specific condition or action and a reusable one. There are, however, differences in how they are treated in a policy repository. For example, it's natural to make the access permissions for a rule-specific condition or action identical to those for the rule itself. It's also natural for a rule-specific condition or action to be removed from the policy repository at the same time the rule is. With reusable conditions and actions, on the other hand, access permissions and existence criteria must be expressible without reference to a policy rule.
ルール固有の条件またはアクションと再利用可能な条件には固有の違いはありません。ただし、ポリシーリポジトリでどのように扱われるかには違いがあります。たとえば、ルール固有の条件またはアクションのアクセス権限を、ルール自体と同一のアクションとすることは自然です。また、ルール固有の条件またはアクションがポリシーリポジトリから同時に削除されることも自然です。一方、再利用可能な条件とアクションでは、アクセス許可と存在基準をポリシールールに関連することなく表現する必要があります。
The preceding paragraph does not contain an exhaustive list of the ways in which reusable and rule-specific conditions should be treated differently. Its purpose is merely to justify making a semantic distinction between rule-specific and reusable, and then reflecting this distinction in the policy model itself.
前の段落には、再利用可能なルール固有の条件を異なる方法で扱うべき方法の徹底的なリストは含まれていません。その目的は、ルール固有と再利用可能なものを意味的に区別することを正当化し、ポリシーモデル自体にこの区別を反映することを正当化することです。
An issue is highlighted by reusable and rule-specific policy conditions and policy actions: the lack of a programmatic capability for expressing complex constraints involving multiple associations. Taking PolicyCondition as an example, there are two aggregations to look at. PolicyConditionInPolicyRule has the cardinality * at both ends, and PolicyConditionInPolicyRepository has the cardinality * at the PolicyCondition end, and [0..1] at the PolicyRepository end.
問題は、再利用可能な規則固有の政策条件と政策訴訟によって強調されています。複数の関連性を含む複雑な制約を表現するためのプログラム能力の欠如です。Policyconditionを例にとると、見るべき2つの集約があります。PolicyConditionInpolicyruleは両端にカーディナリティ *を持ち、PolicyConditionInpolicyrePositoryはPolicycondition Endでカーディナリティ *を持ち、[0..1]がPolicyRepository Endにあります。
Globally, these cardinalities are correct. However, there's more to the story, which only becomes clear if we examine the cardinalities separately for the two cases of a rule-specific PolicyCondition and a reusable one.
世界的には、これらの枢機inalは正しいです。ただし、ストーリーにはさらに多くのことがあります。これは、ルール固有の政策条件と再利用可能な政策の2つのケースについて、枢機inalを個別に調べる場合にのみ明らかになります。
For a rule-specific PolicyCondition, the cardinality of PolicyConditionInPolicyRule at the PolicyRule end is [1..1], rather than [0..n] (recall that * is an abbreviation for [0..n]), since the condition is unique to one policy rule. And the cardinality of PolicyConditionInPolicyRepository at the PolicyRepository end is [0..0], since the condition is not in the "re-usable" repository. This is OK, since these are both subsets of the specified cardinalities.
ルール固有のPolicyconditionの場合、Policyrule端でのPolicyconditioninpolicyruleの枢機inalは[0..n]ではなく[1..1]です（ *は[0..n]の略語であることを思い出してください）。1つのポリシールールに固有のものです。そして、条件が「再利用可能な」リポジトリにないため、PolicyRepository EndのPolicyConditionInpolicyrepositoryのカーディナリティは[0..0]です。これらは両方とも指定された枢機inalのサブセットであるため、これは問題です。
For a reusable PolicyCondition, however, the cardinality of PolicyConditionInPolicyRepository at the PolicyRepository end is [1..1], since the condition must be in the repository. And, the cardinality of PolicyConditionInPolicyRule at the PolicyRule end is [0..n]. This last point is important: a reusable PolicyCondition may be associated with 0, 1, or more than 1 PolicyRules, via exactly the same association PolicyConditionInPolicyRule that binds a rule-specific condition to its PolicyRule.
ただし、再利用可能なPolicyconditionの場合、Policyyrpository EndのPolicyConditionInpolicyrepositoryのカーディナリティは[1..1]です。そして、Policyrule端でのPolicyconditioninpolicyruleの枢機inalは[0..n]です。この最後のポイントは重要です。再利用可能な政策条件は、ルール固有の条件をその政策に結合するまったく同じ関連性のPolicyconditioninpolicyruleを介して、0、1、または1つ以上の政策に関連付けられている可能性があります。
Currently the only way to document constraints of this type is textually. More formal methods for documenting complex constraints are needed.
現在、このタイプの制約を文書化する唯一の方法はテキストです。複雑な制約を文書化するためのより正式な方法が必要です。
The concept of role is central to the design of the entire Policy Framework. The idea behind roles is a simple one. Rather than configuring, and then later having to update the configuration of, hundreds or thousands (or more) of resources in a network, a policy administrator assigns each resource to one or more roles, and then specifies the policies for each of these roles. The Policy Framework is then responsible for configuring each of the resources associated with a role in such a way that it behaves according to the policies specified for that role. When network behavior must be changed, the policy administrator can perform a single update to the policy for a role, and the Policy Framework will ensure that the necessary configuration updates are performed on all the resources playing that role.
役割の概念は、ポリシーフレームワーク全体の設計の中心です。役割の背後にあるアイデアは単純なものです。ネットワーク内の数百または数千（またはそれ以上）のリソースの構成を構成してから更新するのではなく、ポリシー管理者は各リソースを1つ以上のロールに割り当て、これらのロールのそれぞれのポリシーを指定します。ポリシーフレームワークは、その役割について指定されたポリシーに従って動作するように、役割に関連する各リソースを構成する責任があります。ネットワークの動作を変更する必要がある場合、ポリシー管理者は役割のポリシーの単一の更新を実行でき、ポリシーフレームワークは、その役割を演じるすべてのリソースで必要な構成更新が実行されるようにします。
A more formal definition of a role is as follows:
役割のより正式な定義は次のとおりです。
A role is a type of attribute that is used to select one or more policies for a set of entities and/or components from among a much larger set of available policies.
役割とは、利用可能なポリシーのセットの中から、エンティティおよび/またはコンポーネントのセットの1つ以上のポリシーを選択するために使用される属性の一種です。
Roles can be combined together. Here is a formal definition of a "role- combination":
役割を組み合わせることができます。「ロールの組み合わせ」の正式な定義は次のとおりです。
A role-combination is a set of attributes that are used to select one or more policies for a set of entities and/or components from among a much larger set of available policies. As the examples below illustrate, the selection process for a role combination chooses policies associated with the combination itself, policies associated with each of its sub-combinations, and policies associated with each of the individual roles in the role-combination.
ロールコンビネーションとは、利用可能なポリシーのはるかに大きいセットの中から、エンティティおよび/またはコンポーネントのセットの1つ以上のポリシーを選択するために使用される属性のセットです。以下の例が示すように、役割の組み合わせの選択プロセスは、組み合わせ自体に関連するポリシー、各サブコンビネーションに関連するポリシー、およびロールコンビネーションの個々の役割のそれぞれに関連するポリシーを選択します。
It is important to note that a role is more than an attribute. A role defines a particular function of an entity or component that can be used to identify particular behavior associated with that entity or component. This difference is critical, and is most easily understood by thinking of a role as a selector. When used in this manner, one role (or role-combination) selects a different set of policies than a different role (or role-combination) does.
役割は属性以上のものであることに注意することが重要です。役割は、そのエンティティまたはコンポーネントに関連する特定の動作を特定するために使用できるエンティティまたはコンポーネントの特定の機能を定義します。この違いは重要であり、セレクターとしての役割を考えることで最も簡単に理解できます。この方法で使用する場合、1つの役割（またはロールコンビネーション）は、異なるロール（またはロールコンベインネーション）とは異なるポリシーセットを選択します。
Roles and role-combinations are especially useful in selecting which policies are applicable to a particular set of entities or components when the policy repository can store thousands or hundreds of thousands of policies. This use emphasizes the ability of the role (or role- combination) to select the small subset of policies that are applicable from a huge set of policies that are available.
ロールとロールコンビネーションは、ポリシーリポジトリが数千または数万のポリシーを保存できる場合、特定のエンティティまたはコンポーネントに適用できるポリシーを選択するのに特に役立ちます。この使用は、利用可能な膨大な一連のポリシーから適用されるポリシーの小さなサブセットを選択する役割（またはロールの組み合わせ）の能力を強調しています。
An example will illustrate how role-combinations actually work. Suppose an installation has three roles defined for interfaces: "Ethernet", "Campus", and "WAN". In the Policy Repository, some policy rules could be associated with the role "Ethernet"; these rules would apply to all Ethernet interfaces, regardless of whether they were on the campus side or the WAN side. Other rules could be associated with the role-combination "Campus"+"Ethernet"; these rules would apply to the campus-side Ethernet interfaces, but not to those on the WAN side. Finally, a third set of rules could be associated with the role-combination "Ethernet"+"WAN"; these rules would apply to the WAN-side Ethernet interfaces, but not to those on the campus side. (The roles in a role-combination appear in alphabetical order in these examples, because that is how they appear in the information model.)
例は、ロールコンビネーションが実際にどのように機能するかを示しています。インストールには、インターフェイスの3つの役割が定義されているとします：「イーサネット」、「キャンパス」、および「WAN」。ポリシーリポジトリでは、一部のポリシールールが「イーサネット」の役割に関連付けられている可能性があります。これらのルールは、キャンパス側またはWAN側にいたかどうかに関係なく、すべてのイーサネットインターフェイスに適用されます。他のルールは、ロールコンビネーション「キャンパス」「イーサネット」に関連付けられている可能性があります。これらのルールは、キャンパス側のイーサネットインターフェイスに適用されますが、WAN側のルールには適用されません。最後に、3番目のルールセットは、ロールコンビネーション「イーサネット」「WAN」に関連付けられている可能性があります。これらのルールは、WANサイドのイーサネットインターフェイスに適用されますが、キャンパス側のルールには適用されません。（これらの例では、ロールコンビネーションの役割はアルファベット順に表示されます。これが情報モデルに表示される方法だからです。）
If we have a specific interface A that's associated with the role-combination "Ethernet"+"WAN", we see that it should have three categories of policy rules applied to it: those for the "Ethernet" role, those for the "WAN" role, and those for the role-combination "Ethernet"+"WAN". Going one step further, if interface B is associated with the role- combination "branch-office"+"Ethernet"+"WAN", then B should have seven categories of policy rules applied to it - those associated with the following role-combinations:
ロールコンビネーション「イーサネット」「WAN」に関連付けられている特定のインターフェイスAがある場合、「イーサネット」の役割、「WAN」の3つのカテゴリのポリシールールが適用される必要があることがわかります。役割、およびロールコンビネーション「イーサネット」「WAN」の役割。さらに一歩進んで、インターフェイスBがロールの組み合わせ「ブランチオフィス」「イーサネット」「WAN」に関連付けられている場合、Bには7つのカテゴリのポリシールールが適用される必要があります。
o "branch-office"
o "Ethernet"
o "WAN"
o "branch-office"+"Ethernet"
o "branch-office"+"WAN"
o "Ethernet"+"WAN"
o "branch-office"+"Ethernet"+"WAN".
In order to get all of the right policy rules for a resource like interface B, a PDP must expand the single role-combination it receives for B into this list of seven role-combinations, and then retrieve from the Policy Repository the corresponding seven sets of policy rules. Of course this example is unusually complicated: the normal case will involve expanding a two-role combination into three values identifying three sets of policy rules.
インターフェイスBなどのリソースのすべての適切なポリシールールをすべて取得するには、PDPがBに対して受け取る単一のロールコンビネーションをこの7つのロールコンビネーションのリストに拡張し、ポリシーリポジトリから対応する7セットを取得する必要があります。ポリシールールの。もちろん、この例は異常に複雑です。通常のケースには、2ロールの組み合わせを3つのポリシールールセットを識別する3つの値に拡張することが含まれます。
Role-combinations also help to simplify somewhat the problem of identifying conflicts between policy rules. With role-combinations, it is possible for a policy administrator to specify one set of policy rules for campus-side Ethernet interfaces, and a second set of policy rules for WAN-side Ethernet interfaces, without having to worry about conflicts between the two sets of rules. The policy administrator simply "turns off" conflict detection for these two sets of rules, by telling the policy management system that the roles "Campus" and "WAN" are incompatible with each other. This indicates that the role combination will never occur, and therefore conflicts will never occur. In some cases the technology itself might identify incompatible roles: "Ethernet" and "FrameRelay", for example. But for less precise terms like "Campus" and "WAN", the policy administrator must say whether they identify incompatible roles.
また、役割の結合は、ポリシールール間の競合を特定するという問題をいくらか単純化するのに役立ちます。ロールコンビネーションにより、ポリシー管理者は、2つのセット間の競合を心配することなく、キャンパスサイドイーサネットインターフェイスの1つのセットのポリシールールと、WAN側イーサネットインターフェイスの2番目のポリシールールを指定することができます。ルールの。ポリシー管理者は、ポリシー管理システムに「キャンパス」と「WAN」が互いに矛盾していることをポリシー管理システムに伝えることにより、これら2つのルールセットの競合検出を単純に「オフ」します。これは、役割の組み合わせが決して起こらないことを示しているため、競合は発生しないことを示しています。場合によっては、テクノロジー自体が、たとえば「イーサネット」と「Framerelay」という互換性のない役割を特定することがあります。しかし、「キャンパス」や「ワン」などのあまり正確ではない用語では、ポリシー管理者は、互換性のない役割を特定するかどうかを言わなければなりません。
When the policy administrator does this, there are three effects:
ポリシー管理者がこれを行うとき、3つの効果があります。
1. If an interface has assigned to it a role-combination involving both "Campus" and "WAN", then the policy management system can flag it as an error.
1. インターフェイスが「キャンパス」と「WAN」の両方を含むロールコンビネーションを割り当てた場合、ポリシー管理システムはエラーとしてフラグを立てることができます。
2. If a policy rule is associated with a role-combination involving both "Campus" and "WAN", then the policy management system can flag it as an error.
2. ポリシールールが「キャンパス」と「WAN」の両方を含むロールコンビネーションに関連付けられている場合、ポリシー管理システムはエラーとしてフラグを立てることができます。
3. If the policy management system sees two policy rules, where one is tied to the role "Campus" (or to a role-combination that includes the role "Campus") and the other is tied to the role "WAN" (or to a role- combination that includes the role "WAN"), then the system does not need to look for conflicts between the two policy rules: because of the incompatible roles, the two rules cannot possibly conflict.
3. ポリシー管理システムが2つのポリシールールを見ている場合、1つは「キャンパス」の役割（または「キャンパス」を含むロールコンビネーション）に結び付けられ、もう1つは「WAN」の役割（または）に結び付けられています。役割「WAN」を含むロールの組み合わせ）、システムは、2つのポリシールール間の競合を探す必要はありません。互換性のない役割のため、2つのルールは矛盾する可能性があります。
+-------------------+
| Policy Repository |
+-------------------+
V
V retrieval of policy
V
+---------+
| PDP/PEP |
+---------+
v
v application of policy
v
+----------------+
| Network Entity |
+----------------+
Figure 4. Retrieval and Application of a Policy
図4.ポリシーの検索と適用
Figure 4, which is introduced only as an example of how the Policy Framework might be implemented by a collection of network components, illustrates how roles operate within the Policy Framework. Because the distinction between them is not important to this discussion, the PDP and the PEP are combined in one box. The points illustrated here apply equally well, though, to an environment where the PDP and the PEP are implemented separately.
図4は、ネットワークコンポーネントのコレクションによってポリシーフレームワークがどのように実装されるかの例としてのみ紹介され、ポリシーフレームワーク内で役割がどのように機能するかを示しています。それらの区別はこの議論にとって重要ではないため、PDPとPEPは1つのボックスに組み合わされています。ただし、ここに示されているポイントは、PDPとPEPが個別に実装される環境にも同様に適用されます。
A role represents a functional characteristic or capability of a resource to which policies are applied. Examples of roles include Backbone interface, Frame Relay interface, BGP-capable router, web server, firewall, etc. The multiple roles assigned to a single resource are combined to form that resource's role combination. Role combinations are represented in the PCIM by values of the PolicyRoles property in the PolicyRule class. A PDP uses policy roles as follows to identify the policies it needs to be aware of:
役割は、ポリシーが適用されるリソースの機能的特性または能力を表します。役割の例には、バックボーンインターフェイス、フレームリレーインターフェイス、BGP対応ルーター、Webサーバー、ファイアウォールなどが含まれます。単一のリソースに割り当てられた複数のロールが組み合わさって、そのリソースの役割の組み合わせを形成します。役割の組み合わせは、PolyyruleクラスのPolicyrolesプロパティの値によってPCIMで表されます。PDPは、次のようにポリシーの役割を使用して、次のことを認識する必要があるポリシーを特定します。
1. The PDP learns in some way the list of roles that its PEPs play. This information might be configured at the PDP, the PEPs might supply it to the PDP, or the PDP might retrieve it from a repository.
1. PDPは、何らかの形で、そのペップが演じる役割のリストを学びます。この情報はPDPで構成されている可能性があります。PEPSはPDPに供給されるか、PDPがリポジトリから取得する場合があります。
2. Using repository-specific means, the PDP determines where to look for policy rules that might apply to it.
2. リポジトリ固有の手段を使用して、PDPは、適用される可能性のあるポリシールールを探す場所を決定します。
3. Using the roles and role-combinations it received from its PEPs as indicated in the examples above, the PDP is able to locate and retrieve the policy rules that are relevant to it.
3. 上記の例に示されているように、PEPから受け取った役割とロールコンビネーションを使用して、PDPはそれに関連するポリシールールを見つけて取得できます。
As indicated earlier, PolicyRoles is a property associated with a policy rule. It is an array holding "role combinations" for the policy rule, and correlates with the roles defined for a network resource. Using the PolicyRoles property, it is possible to mark a policy rule as applying, for example, to a Frame Relay interface or to a backbone ATM interface. The PolicyRoles property take strings of the form:
前述のように、Policyrolesは政策ルールに関連するプロパティです。これは、ポリシールールの「役割の組み合わせ」を保持する配列であり、ネットワークリソースで定義された役割と相関しています。PolicyRolesプロパティを使用すると、ポリシールールを、たとえば、フレームリレーインターフェイスまたはバックボーンATMインターフェイスに適用するものとしてマークすることができます。Policyrolesプロパティは、フォームの文字列を取得します。
<RoleName>[&&<RoleName>]*
Each value of this property represents a role combination, including the special case of a "combination" containing only one role. As the format indicates, the role names in a role combination are ANDed together to form a single selector. The multiple values of the PolicyRoles property are logically ORed, to make it possible for a policy rule to have multiple selectors.
このプロパティの各値は、1つの役割のみを含む「組み合わせ」の特別なケースを含む、役割の組み合わせを表します。形式が示すように、ロールの組み合わせにおけるロール名は一緒にアンドエッドであり、単一のセレクターを形成します。PolicyRolesプロパティの複数の値は、論理的にオレッドであり、ポリシールールが複数のセレクターを持つことを可能にします。
The individual role names in a role combination must appear in alphabetical order (according to the collating sequence for UCS-2 characters), to make the string matches work correctly. The role names used in an environment are specified by the policy administrator.
ロールの組み合わせにおける個々の役割名は、文字列の一致を正しく動作させるために、アルファベット順に（UCS-2文字の照合シーケンスに従って）表示する必要があります。環境で使用されるロール名は、ポリシー管理者によって指定されます。
An instance of PolicyTimePeriodCondition has up to five properties that represent times: TimePeriod, MonthOfYearMask, DayOfMonthMask, DayOfWeekMask, and TimeOfDayMask. All of the time-related properties in an instance of PolicyTimePeriodCondition represent one of two types of times: local time at the place where a policy rule is applied, or UTC time. The property LocalOrUtcTime indicates which time representation applies to an instance of PolicyTimePeriodCondition.
PolicyTimeperiodConditionのインスタンスには、TimePeriod、MonthofyearMask、Dayofmonthmask、DayofweekMask、およびTimeofdaymaskの時間を表す最大5つのプロパティがあります。PolicyTimeperiodConditionの例のすべての時間関連プロパティは、2つのタイプの1つのいずれかを表しています。これは、ポリシールールが適用される場所、またはUTC時間の現地時間です。Property Localorutctimeは、PolicyTimeperiodConditionのインスタンスに適用される時間表現を示します。
Since the PCIM provides only for local time and UTC time, a Policy Management Tool that provides for other time representations (for example, a fixed time at a particular location) will need to map from these other representations to either local time or UTC time. An example will illustrate the nature of this mapping.
PCIMは現地時間とUTC時間のみを提供するため、他の時間表現（特定の場所での固定時間など）を提供するポリシー管理ツールは、これらの他の表現から現地時間またはUTC時間のいずれかにマッピングする必要があります。この例では、このマッピングの性質を示します。
Suppose a policy rule is tied to the hours of operation for a Help Desk: 0800 to 2000 Monday through Friday [US] Eastern Time. In order to express these times in PolicyTimePeriodCondition, a management tool must convert them to UTC times. (They are not local times, because they refer to a single time interval worldwide, not to intervals tied to the local clocks at the locations where the PolicyRule is being applied.) As reference [10] points out, mapping from [US] Eastern Time to UTC time is not simply a matter of applying an offset: the offset between [US] Eastern Time and UTC time switches between -0500 and -0400 depending on whether Daylight Savings Time is in effect in the US.
ポリシールールがヘルプデスクの営業時間に関連しているとします：月曜日から金曜日[米国]東部時間の0800〜2000。これらの時間をPolicyTimeperiodConditionで表現するために、管理ツールはそれらをUTC時間に変換する必要があります。（現地時間ではありません。なぜなら、それらは世界中の1回の時間間隔を指し、Policyruleが適用されている場所のローカル時計に結び付けられた間隔ではないためです。）参照[10]が指摘するように、[米国] EasternからのマッピングUTC時間までの時間は、単にオフセットを適用することではありません。米国では、夏時間が有効かどうかに応じて、[米国]東部時間とUTC時間の間のオフセットは-0500と-0400の間に切り替えます。
Suppose the policy administrator's goal is to have a policy rule be valid from 0800 until 1200 [US] Eastern Time on every Monday, within the overall time period from the beginning of 2000 until the end of 2001. The Policy Management Tool could either be configured with the definition of what [US] Eastern Time means, or it could be configured with knowledge of where to go to get this information. Reference [10] contains further discussion of time zone definitions and where they might reside.
ポリシー管理者の目標は、2000年の初めから2001年の終わりまで、毎週月曜日に0800から1200 [米国]東部時間まで有効にすることであると仮定します。ポリシー管理ツールは、どちらかを構成できます。[米国]東部時間の意味の定義、またはこの情報を取得するためにどこに行くべきかについての知識で構成される可能性があります。参照[10]には、タイムゾーンの定義とそれらが存在する可能性のある場所のさらなる議論が含まれています。
Armed with knowledge about [US] Eastern Time, the Policy Management Tool would create however many instances of PolicyTimePeriodCondition it needed to represent the desired intervals. Note that while there is an increased number of PolicyTimePeriodCondition instances, there is still just one PolicyRule, which is tied to all the PolicyTimePeriodCondition instances via the aggregation PolicyRuleValidityPeriod. Here are the first two of these instances:
[米国]東部時間に関する知識を備えたものであるポリシー管理ツールは、希望する間隔を表すために必要なPolicyTimeperiodConditionの多くのインスタンスを作成します。PolicyTimeperiodConditionインスタンスの数は増えていますが、まだ1つのPolicyruleしかないことに注意してください。これは、集約Policy -ulevalidityPeriodを介してすべてのPolicyTimeperiodConditionインスタンスに関連付けられています。これらのインスタンスの最初の2つは次のとおりです。
1. TimePeriod: 20000101T050000/20000402T070000 DayOfWeekMask: { Monday } TimeOfDayMask: T130000/T170000 LocalOrUtcTime: UTC
1. TimePeriod：20000101T050000/20000402T070000 DayOfWeekMask：{Monday} TimeOfDayMask：T130000/T170000 Localorutctime：UTC
2. TimePeriod: 20000402T070000/20001029T070000 DayOfWeekMask: { Monday } TimeOfDayMask: T120000/T160000 LocalOrUtcTime: UTC
2. TimePeriod：20000402T070000/20001029T070000 DayOfWeekMask：{Monday} TimeOfDayMask：T120000/T160000 Localorutctime：UTC
There would be three more similar instances, for winter 2000-2001, summer 2001, and winter 2001 up through December 31.
2000年から2001年の冬、2001年夏、2001年冬には12月31日まで、さらに3つの同様のインスタンスがあります。
Had the example been chosen differently, there could have been even more instances of PolicyTimePeriodCondition. If, for example, the
例が異なって選択されていれば、PolicyTimeperiodConditionのさらに多くのインスタンスがあったかもしれません。たとえば、
time interval had been from 0800 - 2200 [US] Eastern Time on Mondays, instance 1 above would have split into two instances: one with a UTC time interval of T130000/T240000 on Mondays, and another with a UTC time interval of T000000/T030000 on Tuesdays. So the end result would have been ten instances of PolicyTimePeriodCondition, not five.
時間間隔は月曜日の0800-2200 [私たち]東部時間でした。上記のインスタンス1は、月曜日にT130000/T240000のUTC時間間隔を持つ2つのインスタンスに分かれていました。毎週火曜日に。したがって、最終結果は、5つではなく、PolicyTimeperiodConditionの10のインスタンスでした。
By restricting PolicyTimePeriodCondition to local time and UTC time, the PCIM places the difficult and expensive task of mapping from "human" time representations to machine-friendly ones in the Policy Management Tool. Another approach would have been to place in PolicyTimePeriodCondition a means of representing a named time zone, such as [US] Eastern Time. This, however, would have passed the difficult mapping responsibility down to the PDPs and PEPs. It is better to have a mapping such as the one described above done once in a Policy Management Tool, rather than having it done over and over in each of the PDPs (and possibly PEPs) that need to apply a PolicyRule.
PCIMは、PolicyTimeperiodConditionを現地時間とUTC時間に制限することにより、ポリシー管理ツールに「人間」の時間表現から機械に優しいものにマッピングする困難で高価なタスクを配置します。別のアプローチは、[米国]東部時間など、指名されたタイムゾーンを表す手段をPolicyTimeperiodConditionに配置することでした。ただし、これは、困難なマッピング責任をPDPとPEPに渡したでしょう。PolicyRuleを適用する必要がある各PDP（および場合によってはPEP）で何度も何度も実行するよりも、上記のような上記のようなマッピングをポリシー管理ツールで一度行ったようなマッピングを持っている方が良いです。
Since PCIM extends the CIM Schema, a correspondence between data types used in both CIM and PCIM is needed. The following CIM data types are used in the class definitions that follow in Sections 6 and 7:
PCIMはCIMスキーマを拡張するため、CIMとPCIMの両方で使用されるデータ型間の対応が必要です。次のCIMデータ型は、セクション6および7に次のようなクラス定義で使用されています。
o uint8 unsigned 8-bit integer
o UINT8 unsigned 8ビット整数
o uint16 unsigned 16-bit integer
o UINT16 unsigned 16ビット整数
o boolean Boolean
o ブールブール
o string UCS-2 string.
o 文字列UCS-2文字列。
Strings in CIM are stored as UCS-2 characters, where each character is encoded in two octets. Thus string values may need to be converted when moving between a CIM environment and one that uses a different string encoding. For example, in an LDAP-accessible directory, attributes of type DirectoryString are stored in UTF-8 format. RFC 2279 [7] explains how to convert between these two formats.
CIMの文字列はUCS-2文字として保存され、各文字は2オクテットでエンコードされます。したがって、CIM環境と異なる文字列エンコーディングを使用する環境間を移動するときに、文字列値を変換する必要があります。たとえば、LDAPアクセス可能なディレクトリでは、型directoryStringの属性がUTF-8形式で保存されます。RFC 2279 [7]は、これら2つの形式間で変換する方法を説明しています。
When it is applied to a CIM string, a MaxLen value refers to the maximum number of characters in the string, rather than to the maximum number of octets.
CIM文字列に適用される場合、Maxlen値とは、オクテットの最大数ではなく、文字列内の最大文字数を指します。
In addition to the CIM data types listed above, the association classes in Section 7 use the following type:
上記のCIMデータ型に加えて、セクション7の協会クラスは次のタイプを使用します。
o <classname> ref strongly typed reference.
o <ClassName> REFは強く入力されたリファレンスを参照してください。
There is one obvious omission from this list of CIM data types: octet strings. This is because CIM treats octet strings as a derived data type. There are two forms of octet strings in CIM - an ordered uint8 array for single-valued strings, and a string array for multi-valued properties. Both are described by adding an "OctetString" qualifier (meta-data) to the property. This qualifier functions exactly like an SMIv2 (SNMP) Textual Convention, refining the syntax and semantics of the existing CIM data type.
CIMデータ型のこのリストから、Octet文字列の1つの明らかな省略があります。これは、CIMがOctet文字列を派生データ型として扱うためです。CIMには2つの形式のオクテット文字列があります。単一値文字列用の順序付けられたUINT8アレイと、多値プロパティ用の文字列アレイです。どちらも、プロパティに「オクターストリング」予選（Meta-Data）を追加することで説明されています。この予選は、SMIV2（SNMP）テキスト条約とまったく同じように機能し、既存のCIMデータ型の構文とセマンティクスを改良します。
The first four numeric elements of both of the "OctetString" representations are a length field. (The reason that the "numeric" adjective is added to the previous sentence is that the string property also includes '0' and 'x', as its first characters.) In both cases, these 4 numeric elements (octets) are included in calculating the length. For example, a single-valued octet string property having the value X'7C' would be represented by the uint8 array, X'00 00 00 05 7C'.
「オクテットストリング」表現の両方の最初の4つの数値要素は、長さフィールドです。（「数値」形容詞が前の文に追加される理由は、文字列プロパティには最初の文字として「0」と「X」も含まれるためです。）どちらの場合も、これらの4つの数値要素（オクテット）が含まれています。長さの計算。たとえば、値x'7C 'を持つ単一値のオクテット文字列プロパティは、UINT8アレイx'00 00 00 05 7C'で表されます。
The strings representing the individual values of a multi-valued property qualified with the "OctetString" qualifier are constructed similarly:
「OctetString」予選で資格のある複数の値のプロパティの個々の値を表す文字列も同様に構築されます。
1. Take a value to be encoded as an octet string (we'll use X'7C' as above), and prepend to it a four-octet length. The result is the same, X'00 00 00 05 7C'.
1. 値をオクテット文字列としてエンコードする値（上記のようにx'7c 'を使用します）を使用し、4オクテットの長さを準備します。結果は同じです、x'00 00 00 05 7c '。
2. Convert this to a character string by introducing '0' and 'x' at the front, and removing all white space. Thus we have the 12- character string "0x000000057C". This string is the value of one of the array elements in the CIM string array. Since CIM uses the UCS-2 character set, it will require 24 octets to encode this 12- character string.
2. これを、前面に「0」と「X」を導入し、すべての空白を削除して、文字列に変換します。したがって、12文字の文字列「0x000000057c」があります。この文字列は、CIM文字列アレイ内の配列要素の1つの値です。CIMはUCS-2文字セットを使用するため、この12文字の文字列をエンコードするには24オクテットが必要です。
Mappings of the PCIM to particular data models are not required to follow this CIM technique of representing multi-valued octet strings as length- prefixed character strings. In an LDAP mapping, for example, it would be much more natural to simply use the Octet String syntax, and omit the prepended length octets.
PCIMから特定のデータモデルへのマッピングは、長さのプレフィックス文字列として多値のオクテット文字列を表すこのCIM技術に従う必要はありません。たとえば、LDAPマッピングでは、Octet Stringの構文を単純に使用して、準備された長さのオクテットを省略する方がはるかに自然です。
There are a number of differences between CIM and LDAP class specifications. The ones that are relevant to the abbreviated class specifications in this document are listed below. These items are included here to help introduce the IETF community, which is already familiar with LDAP, to CIM modeling, and by extension, to information modeling in general.
CIMとLDAPクラスの仕様には多くの違いがあります。このドキュメントの短縮クラス仕様に関連するものを以下に示します。これらの項目は、LDAPにすでに精通しているIETFコミュニティを導入するのに役立つために、CIMモデリング、さらには一般的な情報モデリングへの導入を支援します。
o Instead of LDAP's three class types (abstract, auxiliary, structural), CIM has only two: abstract and instantiable. The type of a CIM class is indicated by the Boolean qualifier ABSTRACT.
o LDAPの3つのクラスタイプ（要約、補助、構造）の代わりに、CIMには2つしかありません。CIMクラスのタイプは、ブール予選抽象によって示されます。
o CIM uses the term "property" for what LDAP terms an "attribute".
o CIMは、LDAPが「属性」と呼ぶものに対して「プロパティ」という用語を使用します。
o CIM uses the array notation "[ ]" to indicate that a property is multi-valued. CIM defines three types of arrays: bags (contents are unordered, duplicates allowed), ordered bags (contents are ordered but duplicates are allowed) and indexed arrays (contents are ordered and no duplicates are allowed).
o CIMは、配列表記「[]」を使用して、プロパティが多値であることを示します。CIMは、3つのタイプの配列を定義します。バッグ（コンテンツは順序付けられていない、重複が許可されていません）、順序付けされたバッグ（コンテンツが注文されますが、重複が許可されます）、インデックス付き配列（内容が順序付けられ、重複は許可されません）。
o CIM classes and properties are identified by name, not by OID.
o CIMクラスとプロパティは、OIDではなく名前で識別されます。
o CIM classes use a different naming scheme for native implementations, than LDAP. The CIM naming scheme is documented in Appendix A since it is not critical to understanding the information model, and only applies when communicating with a native CIM implementation.
o CIMクラスは、LDAPとは異なるネーミングスキームをネイティブ実装に使用します。CIMネーミングスキームは、情報モデルを理解するために重要ではなく、ネイティブCIM実装と通信するときにのみ適用されるため、付録Aに文書化されています。
o In LDAP, attribute definitions are global, and the same attribute may appear in multiple classes. In CIM, a property is defined within the scope of a single class definition. The property may be inherited into subclasses of the class in which it is defined, but otherwise it cannot appear in other classes. One side effect of this difference is that CIM property names tend to be much shorter than LDAP attribute names, since they are implicitly scoped by the name of the class in which they are defined.
o LDAPでは、属性定義はグローバルであり、複数のクラスで同じ属性が表示される場合があります。CIMでは、単一のクラス定義の範囲内でプロパティが定義されます。プロパティは、定義されているクラスのサブクラスに継承される場合がありますが、それ以外の場合は他のクラスでは表示できません。この違いの副作用の1つは、CIMプロパティ名がLDAP属性名よりもはるかに短くなる傾向があることです。これは、それらが定義されているクラスの名前によって暗黙的にスコープされるためです。
There is also a notational convention that this document follows, to improve readability. In CIM, all class and property names are prefixed with the characters "CIM_". These prefixes have been omitted throughout this document, with one exception regarding naming, documented in Appendix A.
また、読みやすさを向上させるために、この文書が続く表記規則もあります。CIMでは、すべてのクラスとプロパティ名に文字「CIM_」が付いています。これらのプレフィックスは、このドキュメント全体で省略されており、付録Aに文書化された命名に関する1つの例外があります。
For the complete definition of the CIM specification language, see reference [2].
CIM仕様言語の完全な定義については、参照[2]を参照してください。
The following sections contain the definitions of the PCIM classes.
次のセクションには、PCIMクラスの定義が含まれています。
The abstract class Policy collects several properties that may be included in instances of any of the Core Policy classes (or their subclasses). For convenience, the two properties that Policy inherits from ManagedElement in the CIM schema are shown here as well.
抽象クラスポリシーは、コアポリシークラス（またはそのサブクラス）のいずれかのインスタンスに含まれる可能性のあるいくつかのプロパティを収集します。便利なため、PolicyがCIMスキーマのマネージデリメントから継承する2つのプロパティもここに示されています。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME Policy DESCRIPTION An abstract class with four properties for describing a policy-related instance. DERIVED FROM ManagedElement ABSTRACT TRUE PROPERTIES CommonName (CN) PolicyKeywords[ ] // Caption (inherited) // Description (inherited)
名前ポリシー説明ポリシー関連のインスタンスを説明するための4つのプロパティを備えた抽象クラス。ManagedElement Abstract True Properties CommonName（CN）PolicyKeyWords [] // Caption（Genestion）//説明（継承）から派生
The CN, or CommonName, property corresponds to the X.500 attribute commonName (cn). In X.500 this property specifies one or more user-friendly names (typically only one name) by which an object is commonly known, names that conform to the naming conventions of the country or culture with which the object is associated. In the CIM model, however, the CommonName property is single-valued.
CN、またはCommonNameのプロパティは、X.500属性CommonName（CN）に対応します。X.500では、このプロパティは、オブジェクトが一般的に知られている1つ以上のユーザーフレンドリーな名前（通常1つの名前のみ）を指定します。これは、オブジェクトが関連付けられている国または文化の命名規則に準拠する名前です。ただし、CIMモデルでは、CommonNameプロパティは単一値です。
NAME CN
DESCRIPTION A user-friendly name of a policy-related object.
SYNTAX string
This property provides a set of one or more keywords that a policy administrator may use to assist in characterizing or categorizing a policy object. Keywords are of one of two types:
このプロパティは、ポリシー管理者がポリシーオブジェクトの特性評価または分類を支援するために使用できる1つ以上のキーワードのセットを提供します。キーワードは、2つのタイプのいずれかです。
o Keywords defined in this document, or in documents that define subclasses of the classes defined in this document. These keywords provide a vendor-independent, installation-independent way of characterizing policy objects.
o このドキュメントで定義されているキーワード、またはこのドキュメントで定義されているクラスのサブクラスを定義するドキュメントで。これらのキーワードは、ポリシーオブジェクトを特徴付けるベンダーに依存しないインストールに依存しない方法を提供します。
o Installation-dependent keywords for characterizing policy objects. Examples include "Engineering", "Billing", and "Review in December 2000".
o ポリシーオブジェクトを特徴付けるためのインストール依存のキーワード。例には、「エンジニアリング」、「請求」、「2000年12月のレビュー」が含まれます。
This document defines the following keywords: "UNKNOWN", "CONFIGURATION", "USAGE", "SECURITY", "SERVICE", "MOTIVATIONAL", "INSTALLATION", and "EVENT". These concepts were defined earlier in Section 2.
このドキュメントでは、次のキーワードを定義します。「不明」、「構成」、「使用法」、「セキュリティ」、「サービス」、「動機付け」、「インストール」、「イベント」。これらの概念は、セクション2の前半で定義されました。
One additional keyword is defined: "POLICY". The role of this keyword is to identify policy-related instances that would not otherwise be identifiable as being related to policy. It may be needed in some repository implementations.
1つの追加のキーワードが定義されています：「ポリシー」。このキーワードの役割は、ポリシーに関連していると特定できないポリシー関連のインスタンスを特定することです。一部のリポジトリの実装では必要になる場合があります。
Documents that define subclasses of the Policy Core Information Model classes SHOULD define additional keywords to characterize instances of these subclasses. By convention, keywords defined in conjunction with class definitions are in uppercase. Installation-defined keywords can be in any case.
ポリシーコア情報モデルクラスのサブクラスを定義するドキュメントは、これらのサブクラスのインスタンスを特徴付けるために追加のキーワードを定義する必要があります。慣習により、クラスの定義と組み合わせて定義されたキーワードは大文字になります。いずれにせよ、インストール定義のキーワードは可能です。
The property definition is as follows:
プロパティ定義は次のとおりです。
NAME PolicyKeywords
DESCRIPTION A set of keywords for characterizing /categorizing
policy objects.
SYNTAX string
This property provides a one-line description of a policy-related object.
このプロパティは、ポリシー関連のオブジェクトの1行の説明を提供します。
NAME Caption
DESCRIPTION A one-line description of this policy-related object.
SYNTAX string
This property provides a longer description than that provided by the caption property.
このプロパティは、キャプションプロパティが提供する説明よりも長い説明を提供します。
NAME Description
DESCRIPTION A long description of this policy-related object.
SYNTAX string
This class is a generalized aggregation container. It enables either PolicyRules or PolicyGroups to be aggregated in a single container. Loops, including the degenerate case of a PolicyGroup that contains itself, are not allowed when PolicyGroups contain other PolicyGroups.
このクラスは、一般化された集約容器です。これにより、PolicyrulesまたはPolicy -Groupを単一の容器に集約できます。ポリシーグループに他のポリシーグループが含まれている場合、それ自体を含むポリシーグループの退化したケースを含むループは許可されません。
PolicyGroups and their nesting capabilities are shown in Figure 5 below. Note that a PolicyGroup can nest other PolicyGroups, and there is no restriction on the depth of the nesting in sibling PolicyGroups.
ポリシーグループとそのネスティング機能を以下の図5に示します。ポリシーグループは他のポリシーグループをネストすることができ、兄弟のポリシーグループの営巣の深さに制限がないことに注意してください。
+---------------------------------------------------+
| PolicyGroup |
| |
| +--------------------+ +-----------------+ |
| | PolicyGroup A | | PolicyGroup X | |
| | | | | |
| | +----------------+ | ooo | | |
| | | PolicyGroup A1 | | | | |
| | +----------------+ | | | |
| +--------------------+ +-----------------+ |
+---------------------------------------------------+
Figure 5. Overview of the PolicyGroup class
図5.ポリシーグループクラスの概要
As a simple example, think of the highest level PolicyGroup shown in Figure 5 above as a logon policy for US employees of a company. This PolicyGroup may be called USEmployeeLogonPolicy, and may aggregate several PolicyGroups that provide specialized rules per location. Hence, PolicyGroup A in Figure 5 above may define logon rules for employees on the West Coast, while another PolicyGroup might define logon rules for the Midwest (e.g., PolicyGroup X), and so forth.
簡単な例として、上記の図5に示す最高レベルのポリシーグループを、会社の米国従業員のログオンポリシーとして考えてください。このポリシーグループは、usemployeelogonpolicyと呼ばれる場合があり、場所ごとに特殊なルールを提供するいくつかのポリシーグループを集約することができます。したがって、上記の図5のポリシーグループAは、西海岸の従業員のログオンルールを定義する場合がありますが、別のポリシーグループは、中西部（ポリシーグループXなど）のログオンルールを定義する場合があります。
Note also that the depth of each PolicyGroup does not need to be the same. Thus, the WestCoast PolicyGroup might have several additional layers of PolicyGroups defined for any of several reasons (different locales, number of subnets, etc..). The PolicyRules are therefore contained at n levels from the USEmployeeLogonPolicyGroup. Compare this to the Midwest PolicyGroup (PolicyGroup X), which might directly contain PolicyRules.
また、各ポリシーグループの深さは同じである必要はないことに注意してください。したがって、Westcoast PolicyGroupには、いくつかの理由で定義されたいくつかの追加のポリシーグループがある場合があります（異なる場所、サブネットの数など）。したがって、政策は、usemployeelogonpolicygroupのnレベルに含まれています。これを中西部のポリシーグループ（ポリシーグループX）と比較してください。
The class definition for PolicyGroup is as follows:
ポリシーグループのクラス定義は次のとおりです。
NAME PolicyGroup DESCRIPTION A container for either a set of related PolicyRules or a set of related PolicyGroups. DERIVED FROM Policy ABSTRACT FALSE PROPERTIES NONE
名前ポリシーグループの説明関連するポリシャルのセットまたは関連するポリシーグループのセットのいずれかのコンテナ。ポリシーから派生した抽象的な偽のプロパティなし
No properties are defined for this class since it inherits all its properties from Policy. The class exists to aggregate PolicyRules or other PolicyGroups. It is directly instantiable. In an implementation, various key/identification properties MUST be defined. The keys for a native CIM implementation are defined in Appendix A, Section 13.1.1. Keys for an LDAP implementation will be defined in the LDAP mapping of this information model [11].
ポリシーからすべてのプロパティを継承するため、このクラスのプロパティは定義されていません。このクラスは、政策またはその他の政策グループを集約するために存在します。直接瞬時です。実装では、さまざまなキー/識別プロパティを定義する必要があります。ネイティブCIM実装のキーは、付録A、セクション13.1.1に定義されています。LDAP実装のキーは、この情報モデルのLDAPマッピングで定義されます[11]。
This class represents the "If Condition then Action" semantics associated with a policy. A PolicyRule condition, in the most general sense, is represented as either an ORed set of ANDed conditions (Disjunctive Normal Form, or DNF) or an ANDed set of ORed conditions (Conjunctive Normal Form, or CNF). Individual conditions may either be negated (NOT C) or unnegated (C). The actions specified by a PolicyRule are to be performed if and only if the PolicyRule condition (whether it is represented in DNF or CNF) evaluates to TRUE.
このクラスは、ポリシーに関連付けられた「条件とアクション」セマンティクスを表します。最も一般的な意味での政策条件は、anded条件（分離法の正常形態、またはDNF）またはandedのORED条件（接続詞正常形態、またはCNF）のいずれかとして表されます。個々の条件は、否定され（cではない）、または否定されていない（c）。Policyruleによって指定されたアクションは、Policyrule条件（DNFまたはCNFで表されているかどうか）がTrueに評価された場合にのみ実行されます。
The conditions and actions associated with a policy rule are modeled, respectively, with subclasses of the classes PolicyCondition and PolicyAction. These condition and action objects are tied to instances of PolicyRule by the PolicyConditionInPolicyRule and PolicyActionInPolicyRule aggregations.
ポリシールールに関連する条件とアクションは、それぞれ、クラスのポリシーコンディションとポリシーアクセスのサブクラスを使用してモデル化されています。これらの条件と作用オブジェクトは、PolicyconditioninpolicyruleおよびPolication inpolicyrule凝集によりPolicyruleのインスタンスに関連付けられています。
As illustrated above in Section 3, a policy rule may also be associated with one or more policy time periods, indicating the schedule according to which the policy rule is active and inactive. In this case it is the PolicyRuleValidityPeriod aggregation that provides the linkage.
上記のセクション3に示すように、ポリシールールは1つ以上のポリシー期間に関連付けられている可能性があり、ポリシールールがアクティブで非アクティブであるスケジュールを示しています。この場合、リンケージを提供するのはPolicyrulevalisityperiodperiod凝集です。
A policy rule is illustrated conceptually in Figure 6. below.
ポリシールールを概念的に図6に示します。以下。
+------------------------------------------------+
| PolicyRule |
| |
| +--------------------+ +-----------------+ |
| | PolicyCondition(s) | | PolicyAction(s) | |
| +--------------------+ +-----------------+ |
| |
| +------------------------------+ |
| | PolicyTimePeriodCondition(s) | |
| +------------------------------+ |
+------------------------------------------------+
Figure 6. Overview of the PolicyRule Class
図6. Policyruleクラスの概要
The PolicyRule class uses the property ConditionListType, to indicate whether the conditions for the rule are in DNF or CNF. The PolicyConditionInPolicyRule aggregation contains two additional properties to complete the representation of the rule's conditional expression. The first of these properties is an integer to partition the referenced conditions into one or more groups, and the second is a Boolean to indicate whether a referenced condition is negated. An example shows how ConditionListType and these two additional properties provide a unique representation of a set of conditions in either DNF or CNF.
Policyyruleクラスは、プロパティConditionListTypeを使用して、ルールの条件がDNFまたはCNFであるかどうかを示します。PolicyConditionInpolicyruleの凝集には、ルールの条件付き式の表現を完了するための2つの追加の特性が含まれています。これらのプロパティの最初は、参照された条件を1つ以上のグループに分割する整数であり、2つ目は参照される条件が否定されるかどうかを示すためのブール値です。例は、条件リストとこれら2つの追加の特性が、DNFまたはCNFのいずれかの条件セットの独自の表現をどのように提供するかを示しています。
Suppose we have a PolicyRule that aggregates five PolicyConditions C1 through C5, with the following values in the properties of the five PolicyConditionInPolicyRule associations:
5つのPolicyconditionsInpolicyrule関連の特性に次の値がある5つのPolicyconditions C1を〜C5を集約するPolicyruleがあるとします。
C1: GroupNumber = 1, ConditionNegated = FALSE
C2: GroupNumber = 1, ConditionNegated = TRUE
C3: GroupNumber = 1, ConditionNegated = FALSE
C4: GroupNumber = 2, ConditionNegated = FALSE
C5: GroupNumber = 2, ConditionNegated = FALSE
If ConditionListType = DNF, then the overall condition for the PolicyRule is:
条件リスト= dnfの場合、policyruleの全体的な条件は次のとおりです。
(C1 AND (NOT C2) AND C3) OR (C4 AND C5)
（C1および（C2ではない）およびC3）または（C4およびC5）
On the other hand, if ConditionListType = CNF, then the overall condition for the PolicyRule is:
一方、conditionListtype = cnfの場合、Policyruleの全体的な条件は次のとおりです。
(C1 OR (NOT C2) OR C3) AND (C4 OR C5)
（C1または（C2ではない）またはC3）および（C4またはC5）
In both cases, there is an unambiguous specification of the overall condition that is tested to determine whether to perform the actions associated with the PolicyRule.
どちらの場合も、Policyruleに関連するアクションを実行するかどうかを判断するためにテストされた全体的な条件の明確な仕様があります。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME PolicyRule DESCRIPTION The central class for representing the "If Condition then Action" semantics associated with a policy rule. DERIVED FROM Policy ABSTRACT FALSE PROPERTIES Enabled ConditionListType RuleUsage Priority Mandatory SequencedActions PolicyRoles
名前policyrule説明「if条件Then action」セマンティクスをポリシールールに関連付ける中央クラス。ポリシーから導出された抽象的な虚偽のプロパティ有効化条件リストのルールジェット優先順位を強制シーケンス操作PolicyROLES
The PolicyRule class is directly instantiable. In an implementation, various key/identification properties MUST be defined. The keys for a native CIM implementation are defined in Appendix A, Section 13.1.2. Keys for an LDAP implementation will be defined in the LDAP mapping of this information model [11].
PolicyRuleクラスは直接瞬時にあります。実装では、さまざまなキー/識別プロパティを定義する必要があります。ネイティブCIM実装のキーは、付録A、セクション13.1.2に定義されています。LDAP実装のキーは、この情報モデルのLDAPマッピングで定義されます[11]。
This property indicates whether a policy rule is currently enabled, from an administrative point of view. Its purpose is to allow a policy administrator to enable or disable a policy rule without having to add it to, or remove it from, the policy repository.
このプロパティは、管理の観点から、ポリシールールが現在有効になっているかどうかを示します。その目的は、ポリシー管理者がポリシーリポジトリから追加または削除することなく、ポリシールールを有効または無効にできるようにすることです。
The property also supports the value 'enabledForDebug'. When the property has this value, the entity evaluating the policy condition(s) is being told to evaluate the conditions for the policy rule, but not to perform the actions if the conditions evaluate to TRUE. This value serves as a debug vehicle when attempting to determine what policies would execute in a particular scenario, without taking any actions to change state during the debugging.
プロパティは、値「InabledFordeBug」もサポートしています。プロパティにこの値がある場合、ポリシー条件を評価するエンティティは、ポリシールールの条件を評価するように指示されていますが、条件がTrueに評価された場合はアクションを実行しません。この値は、デバッグ中に状態を変更するためのアクションを実行することなく、特定のシナリオでどのポリシーが実行されるかを決定しようとするときにデバッグ車として機能します。
The property definition is as follows:
プロパティ定義は次のとおりです。
NAME Enabled
DESCRIPTION An enumeration indicating whether a policy rule is
administratively enabled, administratively disabled,
or enabled for debug mode.
SYNTAX uint16
VALUES enabled(1), disabled(2), enabledForDebug(3)
DEFAULT VALUE enabled(1)
This property is used to specify whether the list of policy conditions associated with this policy rule is in disjunctive normal form (DNF) or conjunctive normal form (CNF). If this property is not present, the list type defaults to DNF. The property definition is as follows:
このプロパティは、このポリシールールに関連するポリシー条件のリストが、分離法の正常形式（DNF）または接続詞正常形式（CNF）であるかどうかを指定するために使用されます。このプロパティが存在しない場合、リストタイプはDNFにデフォルトです。プロパティ定義は次のとおりです。
NAME ConditionListType
DESCRIPTION Indicates whether the list of policy conditions
associated with this policy rule is in disjunctive
normal form (DNF) or conjunctive normal form (CNF).
SYNTAX uint16
VALUES DNF(1), CNF(2)
DEFAULT VALUE DNF(1)
This property is a free-form string that recommends how this policy should be used. The property definition is as follows:
このプロパティは、このポリシーの使用方法を推奨する自由形式の文字列です。プロパティ定義は次のとおりです。
NAME RuleUsage
DESCRIPTION This property is used to provide guidelines on
how this policy should be used.
SYNTAX string
This property provides a non-negative integer for prioritizing policy rules relative to each other. Larger integer values indicate higher priority. Since one purpose of this property is to allow specific, ad hoc policy rules to temporarily override established policy rules, an instance that has this property set has a higher priority than all instances that use or set the default value of zero.
このプロパティは、互いに比べてポリシールールを優先するための非陰性整数を提供します。整数値が大きいほど優先度が高いことを示します。このプロパティの1つの目的は、特定のアドホックなポリシールールが確立されたポリシールールを一時的にオーバーライドすることを許可することであるため、このプロパティセットを持つインスタンスは、デフォルト値をゼロのデフォルト値を使用または設定するすべてのインスタンスよりも優先度が高くなります。
Prioritization among policy rules provides a basic mechanism for resolving policy conflicts.
ポリシールール間の優先順位付けは、ポリシーの競合を解決するための基本的なメカニズムを提供します。
The property definition is as follows:
プロパティ定義は次のとおりです。
NAME Priority
DESCRIPTION A non-negative integer for prioritizing this
PolicyRule relative to other PolicyRules. A larger
value indicates a higher priority.
SYNTAX uint16
DEFAULT VALUE 0
This property indicates whether evaluation (and possibly action execution) of a PolicyRule is mandatory or not. Its concept is similar to the ability to mark packets for delivery or possible discard, based on network traffic and device load.
このプロパティは、Policyruleの評価（およびアクション実行）が必須かどうかを示します。その概念は、ネットワークトラフィックとデバイスの負荷に基づいて、配信または廃棄の可能性のあるパケットをマークする機能に似ています。
The evaluation of a PolicyRule MUST be attempted if the Mandatory property value is TRUE. If the Mandatory property value of a PolicyRule is FALSE, then the evaluation of the rule is "best effort" and MAY be ignored.
必須のプロパティ値が真である場合、Policyruleの評価を試みる必要があります。Policyruleの強制的なプロパティ値が誤っている場合、ルールの評価は「最良の努力」であり、無視される場合があります。
The property definition is as follows:
プロパティ定義は次のとおりです。
NAME Mandatory
DESCRIPTION A flag indicating that the evaluation of the
PolicyConditions and execution of PolicyActions
(if the condition list evaluates to TRUE) is
required.
SYNTAX boolean
DEFAULT VALUE TRUE
This property gives a policy administrator a way of specifying how the ordering of the policy actions associated with this PolicyRule is to be interpreted. Three values are supported:
このプロパティは、ポリシー管理者に、このPolicyruleに関連するポリシーアクションの順序付けがどのように解釈されるかを指定する方法を提供します。3つの値がサポートされています。
o mandatory(1): Do the actions in the indicated order, or don't do them at all.
o 必須（1）：指定された順序でアクションを実行するか、まったく実行しないでください。
o recommended(2): Do the actions in the indicated order if you can, but if you can't do them in this order, do them in another order if you can.
o 推奨（2）：可能であれば、指定された順序でアクションを実行しますが、この順序で実行できない場合は、可能であれば別の順序で実行してください。
o dontCare(3): Do them -- I don't care about the order.
o dontcare（3）：それらを行う - 私は注文を気にしません。
When error / event reporting is addressed for the Policy Framework, suitable codes will be defined for reporting that a set of actions could not be performed in an order specified as mandatory (and thus were not performed at all), that a set of actions could not be performed in a recommended order (and moreover could not be performed in any order), or that a set of actions could not be performed in a recommended order (but were performed in a different order). The property definition is as follows:
ポリシーフレームワークに対してエラー /イベントの報告が扱われると、適切なコードが定義され、一連のアクションを必須として指定された順序で実行できない（したがってまったく実行されなかった）、一連のアクションが可能であると定義されます。推奨される順序で実行されることはありません（さらに、いかなる順序でも実行できません）、または一連のアクションを推奨順序で実行できませんでした（ただし、別の順序で実行されました）。プロパティ定義は次のとおりです。
NAME SequencedActions
DESCRIPTION An enumeration indicating how to interpret the
action ordering indicated via the
PolicyActionInPolicyRule aggregation.
SYNTAX uint16
VALUES mandatory(1), recommended(2), dontCare(3)
DEFAULT VALUE dontCare(3)
This property represents the roles and role combinations associated with a policy rule. Each value represents one role combination. Since this is a multi-valued property, more than one role combination can be associated with a single policy rule. Each value is a string of the form
このプロパティは、ポリシールールに関連する役割と役割の組み合わせを表します。各値は、1つの役割の組み合わせを表します。これは多値のプロパティであるため、複数の役割の組み合わせを単一のポリシールールに関連付けることができます。各値はフォームの文字列です
<RoleName>[&&<RoleName>]*
where the individual role names appear in alphabetical order (according to the collating sequence for UCS-2). The property definition is as follows:
個々のロール名がアルファベット順に表示される場合（UCS-2の照合シーケンスに従って）。プロパティ定義は次のとおりです。
NAME PolicyRoles
DESCRIPTION A set of strings representing the roles and role
combinations associated with a policy rule. Each
value represents one role combination.
SYNTAX string
The purpose of a policy condition is to determine whether or not the set of actions (aggregated in the PolicyRule that the condition applies to) should be executed or not. For the purposes of the Policy Core Information Model, all that matters about an individual PolicyCondition is that it evaluates to TRUE or FALSE. (The individual PolicyConditions associated with a PolicyRule are combined to form a compound expression in either DNF or CNF, but this is accomplished via the ConditionListType property, discussed above, and by the properties of the PolicyConditionInPolicyRule aggregation, introduced above and discussed further in Section 7.6 below.) A logical structure within an individual PolicyCondition may also be introduced, but this would have to be done in a subclass of PolicyCondition.
政策条件の目的は、一連のアクション（条件が適用される政策に集約されている）を実行するかどうかを判断することです。ポリシーコア情報モデルの目的のために、個々の政策条件について重要なのは、それが真または虚偽と評価することです。（Policyruleに関連付けられた個々の政策条件を組み合わせてDNFまたはCNFのいずれかで化合物式を形成しますが、これは上記の条件リスト型特性を介して、および上記のPolicyconditionInpolicyrule凝集の特性によって達成され、上記で説明され、セクション7.6でさらに説明されています。以下。）個々のPolicycondition内の論理構造も導入される場合がありますが、これはPolicyconditionのサブクラスで行う必要があります。
Because it is general, the PolicyCondition class does not itself contain any "real" conditions. These will be represented by properties of the domain-specific subclasses of PolicyCondition.
それは一般的であるため、PolicyConditionクラスには「実際の」条件は含まれていません。これらは、Policyconditionのドメイン固有のサブクラスのプロパティで表されます。
+---------------------------------------------------------------+
| Policy Conditions in DNF |
| +-------------------------+ +-----------------------+ |
| | AND list | | AND list | |
| | +-------------------+ | | +-----------------+ | |
| | | PolicyCondition | | | | PolicyCondition | | |
| | +-------------------+ | | +-----------------+ | |
| | +-------------------+ | | +-----------------+ | |
| | | PolicyCondition | | ... | | PolicyCondition | | |
| | +-------------------+ | ORed | +-----------------+ | |
| | ... | | ... | |
| | ANDed | | ANDed | |
| | +-------------------+ | | +-----------------+ | |
| | | PolicyCondition | | | | PolicyCondition | | |
| | +-------------------+ | | +-----------------+ | |
| +-------------------------+ +-----------------------+ |
+---------------------------------------------------------------+
Figure 7. Overview of Policy Conditions in DNF
図7. DNFのポリシー条件の概要
This figure illustrates that when policy conditions are in DNF, there are one or more sets of conditions that are ANDed together to form AND lists. An AND list evaluates to TRUE if and only if all of its constituent conditions evaluate to TRUE. The overall condition then evaluates to TRUE if and only if at least one of its constituent AND lists evaluates to TRUE.
この図は、政策条件がDNFにある場合、1つ以上の条件があり、結合して形成され、リストする条件が1つ以上あることを示しています。ANおよびリストは、そのすべての構成要素条件がTRUEに評価された場合にのみ、真実に評価されます。その後、全体的な条件は、その構成要素の少なくとも1つとリストがTrueに評価された場合にのみTrueに評価します。
+---------------------------------------------------------------+
| Policy Conditions in CNF |
| +-------------------------+ +-----------------------+ |
| | OR list | | OR list | |
| | +-------------------+ | | +-----------------+ | |
| | | PolicyCondition | | | | PolicyCondition | | |
| | +-------------------+ | | +-----------------+ | |
| | +-------------------+ | | +-----------------+ | |
| | | PolicyCondition | | ... | | PolicyCondition | | |
| | +-------------------+ | ANDed | +-----------------+ | |
| | ... | | ... | |
| | ORed | | ORed | |
| | +-------------------+ | | +-----------------+ | |
| | | PolicyCondition | | | | PolicyCondition | | |
| | +-------------------+ | | +-----------------+ | |
| +-------------------------+ +-----------------------+ |
+---------------------------------------------------------------+
Figure 8. Overview of Policy Conditions in CNF
図8. CNFのポリシー条件の概要
In this figure, the policy conditions are in CNF. Consequently, there are one or more OR lists, each of which evaluates to TRUE if and only if at least one of its constituent conditions evaluates to TRUE. The overall condition then evaluates to TRUE if and only if ALL of its constituent OR lists evaluate to TRUE.
この図では、ポリシー条件はCNFにあります。その結果、1つ以上のリストがあり、それぞれがその構成条件の少なくとも1つがTrueに評価された場合にのみ、Trueに評価されます。全体的な条件は、そのすべての構成要素またはリストがtrueに評価された場合にのみ、Trueに評価されます。
The class definition of PolicyCondition is as follows:
Policyconditionのクラス定義は次のとおりです。
NAME PolicyCondition DESCRIPTION A class representing a rule-specific or reusable policy condition to be evaluated in conjunction with a policy rule. DERIVED FROM Policy ABSTRACT TRUE PROPERTIES NONE
名前Policycondition説明ポリシールールと併せて評価されるルール固有または再利用可能なポリシー条件を表すクラス。ポリシー抽象的な真のプロパティから導出されていません
No properties are defined for this class since it inherits all its properties from Policy. The class exists as an abstract superclass for domain-specific policy conditions, defined in subclasses. In an implementation, various key/identification properties MUST be defined for the class or its instantiable subclasses. The keys for a native CIM implementation are defined in Appendix A, Section 13.2. Keys for an LDAP implementation will be defined in the LDAP mapping of this information model [11].
ポリシーからすべてのプロパティを継承するため、このクラスのプロパティは定義されていません。このクラスは、サブクラスで定義されたドメイン固有のポリシー条件の抽象的なスーパークラスとして存在します。実装では、クラスまたはその瞬時のサブクラスに対して、さまざまなキー/識別プロパティを定義する必要があります。ネイティブCIM実装のキーは、付録A、セクション13.2に定義されています。LDAP実装のキーは、この情報モデルのLDAPマッピングで定義されます[11]。
When identifying and using the PolicyCondition class, it is necessary to remember that a condition can be rule-specific or reusable. This was discussed above in Section 5.1. The distinction between the two types of policy conditions lies in the associations in which an instance can participate, and in how the different instances are named. Conceptually, a reusable policy condition resides in a policy repository, and is named within the scope of that repository. On the other hand, a rule-specific policy condition is, as the name suggests, named within the scope of the single policy rule to which it is related.
Policy-Conditionクラスを識別して使用する場合、条件がルール固有または再利用可能である可能性があることを覚えておく必要があります。これは、セクション5.1で上記で説明しました。2種類のポリシー条件の区別は、インスタンスが参加できる関連付けと、さまざまなインスタンスの名前の姿にあります。概念的には、再利用可能なポリシー条件はポリシーリポジトリにあり、そのリポジトリの範囲内で命名されています。一方、ルール固有のポリシー条件は、名前が示唆するように、それが関連している単一のポリシールールの範囲内で名前が付けられています。
The distinction between rule-specific and reusable PolicyConditions affects the CIM naming, defined in Appendix A, and the LDAP mapping [11].
ルール固有のポリシー条件と再利用可能なポリシー条件の区別は、付録Aで定義されているCIMネーミングとLDAPマッピング[11]に影響します。
This class provides a means of representing the time periods during which a policy rule is valid, i.e., active. At all times that fall outside these time periods, the policy rule has no effect. A policy rule is treated as valid at all times if it does not specify a PolicyTimePeriodCondition.
このクラスは、ポリシールールが有効な期間、つまりアクティブな期間を表す手段を提供します。これらの期間の外にある常に、ポリシールールは効果がありません。ポリシールールは、PolicyTimeperiodConditionを指定しない場合、常に有効であると扱われます。
In some cases a PDP may need to perform certain setup / cleanup actions when a policy rule becomes active / inactive. For example, sessions that were established while a policy rule was active might need to be taken down when the rule becomes inactive. In other cases, however, such sessions might be left up: in this case, the effect of deactivating the policy rule would just be to prevent the establishment of new sessions. Setup / cleanup behaviors on validity period transitions are not currently addressed by the PCIM, and must be specified in 'guideline' documents, or via subclasses of PolicyRule, PolicyTimePeriodCondition or other concrete subclasses of Policy. If such behaviors need to be under the control of the policy administrator, then a mechanism to allow this control must also be specified in the subclass.
場合によっては、ポリシールールがアクティブ /非アクティブになったときに、PDPが特定のセットアップ /クリーンアップアクションを実行する必要がある場合があります。たとえば、ポリシールールがアクティブになっている間に確立されたセッションは、ルールが非アクティブになったときに削除する必要がある場合があります。ただし、他のケースでは、そのようなセッションが残される可能性があります。この場合、ポリシールールを非アクティブ化する効果は、新しいセッションの確立を防ぐためだけです。有効期間の遷移に関するセットアップ /クリーンアップ動作は現在PCIMによって対処されておらず、「ガイドライン」ドキュメント、またはPolicyRule、PolicyTimeperiodCondition、またはその他のコンクリートサブクラスのサブクラスを介して指定する必要があります。そのような動作がポリシー管理者の制御下にある必要がある場合、この制御を許可するメカニズムもサブクラスで指定する必要があります。
PolicyTimePeriodCondition is defined as a subclass of PolicyCondition. This is to allow the inclusion of time-based criteria in the AND/OR condition definitions for a PolicyRule.
PolicyTimeperiodConditionは、Policy -Conditionのサブクラスとして定義されます。これは、Policyruleのおよび/または条件定義に時間ベースの基準を含めることを可能にするためです。
Instances of this class may have up to five properties identifying time periods at different levels. The values of all the properties present in an instance are ANDed together to determine the validity period(s) for the instance. For example, an instance with an overall validity range of January 1, 2000 through December 31, 2000; a month mask that selects March and April; a day-of-the-week mask that selects Fridays; and a time of day range of 0800 through 1600 would represent the following time periods:
このクラスのインスタンスには、異なるレベルでの期間を識別する最大5つのプロパティがある場合があります。インスタンスに存在するすべてのプロパティの値は、インスタンスの有効期間を決定するために一緒にandedされています。たとえば、2000年1月1日から2000年12月31日までの全体的な妥当性範囲のインスタンス。3月と4月を選択する月マスク。金曜日を選択する週のマスク。0800〜1600の時刻範囲は、次の期間を表します。
Friday, March 5, 2000, from 0800 through 1600;
Friday, March 12, 2000, from 0800 through 1600;
Friday, March 19, 2000, from 0800 through 1600;
Friday, March 26, 2000, from 0800 through 1600;
Friday, April 2, 2000, from 0800 through 1600;
Friday, April 9, 2000, from 0800 through 1600;
Friday, April 16, 2000, from 0800 through 1600;
Friday, April 23, 2000, from 0800 through 1600;
Friday, April 30, 2000, from 0800 through 1600.
Properties not present in an instance of PolicyTimePeriodCondition are implicitly treated as having their value "always enabled". Thus, in the example above, the day-of-the-month mask is not present, and so the validity period for the instance implicitly includes a day-of-the-month mask that selects all days of the month. If we apply this "missing property" rule to its fullest, we see that there is a second way to indicate that a policy rule is always enabled: have it point to an instance of PolicyTimePeriodCondition whose only properties are its naming properties.
PolicyTimeperiodConditionのインスタンスに存在しないプロパティは、その価値を「常に有効にする」と暗黙的に扱われます。したがって、上記の例では、月のマスクは存在しないため、インスタンスの有効期間には、月のすべての日を選択する月のマスクを暗黙的に含めます。この「不動産プロパティ」ルールを最大限に適用すると、ポリシールールが常に有効になっていることを示す2番目の方法があることがわかります。それは、その命名プロパティであるプロパティのみがその唯一のプロパティを持つPolicyTimeperiodConditionのインスタンスを指し示します。
The property LocalOrUtcTime indicates whether the times represented in the other five time-related properties of an instance of PolicyTimePeriodCondition are to be interpreted as local times for the location where a policy rule is being applied, or as UTC times.
Property Localorutctimeは、PolicyTimeperiodConditionのインスタンスの他の5つの時間関連プロパティに表される時間が、ポリシールールが適用されている場所の現地時間として解釈されるのか、それともUTC時間として解釈されるかを示します。
The class definition is as follows.
クラスの定義は次のとおりです。
NAME PolicyTimePeriodCondition DESCRIPTION A class that provides the capability of enabling / disabling a policy rule according to a pre-determined schedule. DERIVED FROM PolicyCondition ABSTRACT FALSE PROPERTIES TimePeriod MonthOfYearMask DayOfMonthMask DayOfWeekMask TimeOfDayMask LocalOrUtcTime
名前PolicyTimeperiodConditionの説明は、事前に決定されたスケジュールに従ってポリシールールを有効 /無効にする機能を提供するクラス。Policycondition Abstractから導出された誤ったプロパティTimeperiod Monthofyearmask dayofmonthmask dayofweekmask timeofdaymask localorutctime
This property identifies an overall range of calendar dates and times over which a policy rule is valid. It reuses the format for an explicit time period defined in RFC 2445 (reference [10]): a string representing a starting date and time, in which the character 'T' indicates the beginning of the time portion, followed by the solidus character '/', followed by a similar string representing an end date and time. The first date indicates the beginning of the range, while the second date indicates the end. Thus, the second date and time must be later than the first. Date/times are expressed as substrings of the form "yyyymmddThhmmss". For example:
このプロパティは、ポリシールールが有効なカレンダーの日付と時間の全体的な範囲を特定します。RFC 2445（参照[10]）で定義されている明示的な期間の形式を再利用します：開始日と時刻を表す文字列。文字「t」は時間の部分の始まりを示し、その後にソリッドキャラクターが続きます。/'、その後、終了日と時間を表す同様の文字列が続きます。最初の日付は範囲の始まりを示し、2番目の日付は終了を示します。したがって、2番目の日付と時刻は、最初の日付よりも遅くなければなりません。日付/時間は、「yyyymmddthhmmss」という形式のサブストリングとして表されます。例えば：
20000101T080000/20000131T120000
20000101T080000/20000131T120000
January 1, 2000, 0800 through January 31, 2000, noon
2000年1月1日、0800年から2000年1月31日、正午
There are also two special cases in which one of the date/time strings is replaced with a special string defined in RFC 2445.
また、日付/時刻の文字列の1つがRFC 2445で定義された特別な文字列に置き換えられる2つの特別なケースもあります。
o If the first date/time is replaced with the string "THISANDPRIOR", then the property indicates that a policy rule is valid [from now] until the date/time that appears after the '/'.
o 最初の日付/時間が文字列「thisandprior」に置き換えられている場合、プロパティは、「/」の後に表示される日付/時刻まで、ポリシールールが[今後]有効であることを示します。
o If the second date/time is replaced with the string "THISANDFUTURE", then the property indicates that a policy rule becomes valid on the date/time that appears before the '/', and remains valid from that point on.
o 2番目の日付/時間が文字列「thisandfuture」に置き換えられている場合、プロパティは、ポリシールールが「/」の前に表示される日付/時刻に有効になり、その時点から有効なままであることを示します。
Note that RFC 2445 does not use these two strings in connection with explicit time periods. Thus the PCIM is combining two elements from RFC 2445 that are not combined in the RFC itself.
RFC 2445は、明示的な期間に関連してこれら2つの文字列を使用しないことに注意してください。したがって、PCIMは、RFC自体に組み合わされていないRFC 2445の2つの要素を組み合わせています。
The property definition is as follows:
プロパティ定義は次のとおりです。
NAME TimePeriod
DESCRIPTION The range of calendar dates on which a policy
rule is valid.
SYNTAX string
FORMAT yyyymmddThhmmss/yyyymmddThhmmss, where the first
date/time may be replaced with the string
"THISANDPRIOR" or the second date/time may be
replaced with the string "THISANDFUTURE"
The purpose of this property is to refine the definition of the valid time period that is defined by the TimePeriod property, by explicitly specifying the months when the policy is valid. These properties work together, with the TimePeriod used to specify the overall time period during which the policy might be valid, and the MonthOfYearMask used to pick out the specific months within that time period when the policy is valid.
このプロパティの目的は、ポリシーが有効な月を明示的に指定することにより、時計プロパティによって定義される有効な期間の定義を改良することです。これらのプロパティは、ポリシーが有効である可能性のある全体的な期間を指定するためにタイムペリオードと、ポリシーが有効な期間内に特定の月を選択するために使用される全体的な期間を指定するために使用されます。
This property is formatted as an octet string of size 2, consisting of 12 bits identifying the 12 months of the year, beginning with January and ending with December, followed by 4 bits that are always set to '0'. For each month, the value '1' indicates that the policy is valid for that month, and the value '0' indicates that it is not valid. The value X'08 30', for example, indicates that a policy rule is valid only in the months May, November, and December.
このプロパティは、1月から12か月の12か月を識別する12ビットで構成されるサイズ2のオクテット文字列としてフォーマットされており、12月で終了し、その後は常に「0」に設定されている4ビットが続きます。各月の値「1」は、ポリシーがその月に有効であることを示し、値「0」はそれが有効でないことを示します。たとえば、値x'08 30 'は、ポリシールールが5月、11月、12月にのみ有効であることを示しています。
See section 5.4 for details of how CIM represents a single-valued octet string property such as this one. (Basically, CIM prepends a 4-octet length to the octet string.)
CIMがこのような単一値のOctet Stringプロパティを表す方法の詳細については、セクション5.4を参照してください。（基本的に、CIMはオクテットの文字列に4-OCTETの長さを準備します。）
If this property is omitted, then the policy rule is treated as valid for all twelve months. The property definition is as follows:
このプロパティが省略されている場合、ポリシールールは12か月すべての間有効として扱われます。プロパティ定義は次のとおりです。
NAME MonthOfYearMask
DESCRIPTION A mask identifying the months of the year in
which a policy rule is valid.
SYNTAX octet string
FORMAT X'hh h0'
The purpose of this property is to refine the definition of the valid time period that is defined by the TimePeriod property, by explicitly specifying the days of the month when the policy is valid. These properties work together, with the TimePeriod used to specify the overall time period during which the policy might be valid, and the DayOfMonthMask used to pick out the specific days of the month within that time period when the policy is valid.
このプロパティの目的は、ポリシーが有効な月の日を明示的に指定することにより、時計プロパティによって定義される有効な期間の定義を改良することです。これらのプロパティは、ポリシーが有効である可能性のある全体的な期間を指定するために時計が使用され、ポリシーが有効な期間内に月の特定の日を選択するために使用されるdayofmonthmaskを指定するために使用されます。
This property is formatted as an octet string of size 8, consisting of 31 bits identifying the days of the month counting from the beginning, followed by 31 more bits identifying the days of the month counting from the end, followed by 2 bits that are always set to '0'. For each day, the value '1' indicates that the policy is valid for that day, and the value '0' indicates that it is not valid.
このプロパティはサイズ8のオクテット文字列としてフォーマットされており、31ビットで構成され、最初からカウントされる月の日を識別し、その後31ビットが最後から数えられ、その後は常に2ビットが続きます。「0」に設定します。毎日の値「1」は、ポリシーがその日に有効であることを示し、値「0」は有効でないことを示します。
The value X'80 00 00 01 00 00 00 00', for example, indicates that a policy rule is valid on the first and last days of the month.
たとえば、値x'80 00 00 01 00 00 00 00 'は、ポリシールールが月の最初と最後の日に有効であることを示しています。
For months with fewer than 31 days, the digits corresponding to days that the months do not have (counting in both directions) are ignored.
31日未満の数ヶ月の間、数ヶ月が持っていない日（両方向にカウント）に対応する数字は無視されます。
The encoding of the 62 significant bits in the octet string matches that used for the schedDay object in the DISMAN-SCHEDULE-MIB. See reference [8] for more details on this object.
Disman-Schedule-MibのShadedayオブジェクトに使用されたOctet Stringマッチの62ビットのエンコード。このオブジェクトの詳細については、参照[8]を参照してください。
See section 5.4 for details of how CIM represents a single-valued octet string property such as this one. (Basically, CIM prepends a 4-octet length to the octet string.)
CIMがこのような単一値のOctet Stringプロパティを表す方法の詳細については、セクション5.4を参照してください。（基本的に、CIMはオクテットの文字列に4-OCTETの長さを準備します。）
The property definition is as follows:
プロパティ定義は次のとおりです。
NAME DayOfMonthMask
DESCRIPTION A mask identifying the days of the month on
which a policy rule is valid.
SYNTAX octet string
FORMAT X'hh hh hh hh hh hh hh hh'
The purpose of this property is to refine the definition of the valid time period that is defined by the TimePeriod property by explicitly specifying the days of the week when the policy is valid. These properties work together, with the TimePeriod used to specify the overall time period when the policy might be valid, and the DayOfWeekMask used to pick out the specific days of the week in that time period when the policy is valid.
このプロパティの目的は、ポリシーが有効な週の日を明示的に指定することにより、時計プロパティによって定義される有効な期間の定義を改良することです。これらのプロパティは、ポリシーが有効である可能性のある全体的な期間を指定するために時計が使用され、ポリシーが有効なその期間の特定の曜日を選択するために使用されるDayofWeekMaskが使用されます。
This property is formatted as an octet string of size 1, consisting of 7 bits identifying the 7 days of the week, beginning with Sunday and ending with Saturday, followed by 1 bit that is always set to '0'. For each day of the week, the value '1' indicates that the policy is valid for that day, and the value '0' indicates that it is not valid.
このプロパティは、7ビットで構成されるサイズ1のオクテット文字列としてフォーマットされています。週7日間を識別し、日曜日から土曜日に終了し、その後は常に「0」に設定されています。曜日ごとに、値「1」はその日にポリシーが有効であることを示し、値「0」はそれが有効でないことを示します。
The value X'7C', for example, indicates that a policy rule is valid Monday through Friday.
たとえば、値x'7c 'は、政策ルールが月曜日から金曜日まで有効であることを示しています。
See section 5.4 for details of how CIM represents a single-valued octet string property such as this one. (Basically, CIM prepends a 4-octet length to the octet string.) The property definition is as follows:
CIMがこのような単一値のOctet Stringプロパティを表す方法の詳細については、セクション5.4を参照してください。（基本的に、CIMはOctet Stringに4オクテットの長さを準備します。）プロパティ定義は次のとおりです。
NAME DayOfWeekMask
DESCRIPTION A mask identifying the days of the week on which
a policy rule is valid.
SYNTAX octet string
FORMAT B'bbbb bbb0'
The purpose of this property is to refine the definition of the valid time period that is defined by the TimePeriod property by explicitly specifying a range of times in a day the policy is valid for. These properties work together, with the TimePeriod used to specify the overall time period that the policy is valid for, and the TimeOfDayMask used to pick out which range of time periods in a given day of that time period the policy is valid for.
このプロパティの目的は、ポリシーが有効である1日の範囲を明示的に指定することにより、時計プロパティによって定義される有効な期間の定義を改良することです。これらのプロパティは、ポリシーが有効な全体の期間を指定するために時計が使用され、その期間が有効なその期間の特定の日にどの範囲の期間を選択するために使用されるタイムペリオードとともに連携します。
This property is formatted in the style of RFC 2445 [10]: a time string beginning with the character 'T', followed by the solidus character '/', followed by a second time string. The first time indicates the beginning of the range, while the second time indicates the end. Times are expressed as substrings of the form "Thhmmss".
このプロパティは、RFC 2445 [10]のスタイルでフォーマットされています。文字列「T」から始まり、その後にSolidus Character '/'が続き、2回目の文字列が続きます。初めて範囲の始まりを示し、2回目は終了を示します。時間は、「thhmmss」という形式のサブストリングとして表されます。
The second substring always identifies a later time than the first substring. To allow for ranges that span midnight, however, the value of the second string may be smaller than the value of the first substring. Thus, "T080000/T210000" identifies the range from 0800 until 2100, while "T210000/T080000" identifies the range from 2100 until 0800 of the following day.
2番目のサブストリングは、常に最初のサブストリングよりも後の時間を識別します。ただし、真夜中に及ぶ範囲を可能にするために、2番目の文字列の値は、最初のサブストリングの値よりも小さくなる場合があります。したがって、「T080000/T210000」は0800から2100までの範囲を識別し、「T210000/T080000」は翌日の2100から0800までの範囲を識別します。
When a range spans midnight, it by definition includes parts of two successive days. When one of these days is also selected by either the MonthOfYearMask, DayOfMonthMask, and/or DayOfWeekMask, but the other day is not, then the policy is active only during the portion of the range that falls on the selected day. For example, if the range extends from 2100 until 0800, and the day of week mask selects Monday and Tuesday, then the policy is active during the following three intervals:
範囲が真夜中に広がる場合、定義上、2日間の連続した一部が含まれます。これらの日のいずれかが月のいずれかで選択されている場合、dayofmonthmask、および/またはdayofweekmaskのいずれかによって選択されますが、先日はそうではありませんが、ポリシーは選択された日に落ちる範囲の部分でのみアクティブです。たとえば、範囲が2100から0800まで拡張され、毎週のマスクが月曜日と火曜日を選択する場合、次の3つの間隔でポリシーがアクティブになります。
From midnight Sunday until 0800 Monday; From 2100 Monday until 0800 Tuesday; From 2100 Tuesday until 23:59:59 Tuesday.
日曜日の真夜中から月曜日0800まで。2100年の月曜日から火曜日0800まで。2100年から火曜日から23:59:59火曜日まで。
The property definition is as follows:
プロパティ定義は次のとおりです。
NAME TimeOfDayMask
DESCRIPTION The range of times at which a policy rule is
valid. If the second time is earlier than the
first, then the interval spans midnight.
SYNTAX string
FORMAT Thhmmss/Thhmmss
This property indicates whether the times represented in the TimePeriod property and in the various Mask properties represent local times or UTC times. There is no provision for mixing of local times and UTC times: the value of this property applies to all of the other time-related properties.
このプロパティは、時計のプロパティやさまざまなマスクプロパティで表される時間が、ローカル時間またはUTC時間を表すかどうかを示します。現地時間とUTC時間の混合に関する規定はありません。このプロパティの価値は、他のすべての時間関連プロパティに適用されます。
The property definition is as follows:
プロパティ定義は次のとおりです。
NAME LocalOrUtcTime
DESCRIPTION An indication of whether the other times in this
instance represent local times or UTC times.
SYNTAX uint16
VALUES localTime(1), utcTime(2)
DEFAULT VALUE utcTime(2)
The purpose of this class is to provide a general extension mechanism for representing policy conditions that have not been modeled with specific properties. Instead, the two properties Constraint and ConstraintEncoding are used to define the content and format of the condition, as explained below.
このクラスの目的は、特定の特性でモデル化されていないポリシー条件を表すための一般的な拡張メカニズムを提供することです。代わりに、以下で説明するように、条件のコンテンツと形式を定義するために、2つのプロパティの制約と制約が使用されます。
As its name suggests, this class is intended for vendor-specific extensions to the Policy Core Information Model. Standardized extensions are not expected to use this class.
その名前が示すように、このクラスは、ポリシーコア情報モデルへのベンダー固有の拡張を目的としています。標準化された拡張機能は、このクラスを使用することは期待されていません。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME VendorPolicyCondition DESCRIPTION A class that defines a registered means to describe a policy condition. DERIVED FROM PolicyCondition ABSTRACT FALSE PROPERTIES Constraint[ ] ConstraintEncoding
名前vendorpolicycondition説明ポリシー条件を記述するための登録手段を定義するクラス。policycondition抽象的な誤ったプロパティ制約[]制約から派生
This property provides a general extension mechanism for representing policy conditions that have not been modeled with specific properties. The format of the octet strings in the array is left unspecified in this definition. It is determined by the OID value stored in the property ConstraintEncoding. Since ConstraintEncoding is single-valued, all the values of Constraint share the same format and semantics.
このプロパティは、特定の特性でモデル化されていないポリシー条件を表すための一般的な拡張メカニズムを提供します。この定義では、配列内のオクテット文字列の形式は不特定のままになります。プロパティの制約に保存されているOID値によって決定されます。制約は単一値であるため、制約のすべての値は同じ形式とセマンティクスを共有します。
See Section 5.4 for a description of how CIM encodes an array of octet strings like this one.
CIMがこのようなオクテット文字列の配列をエンコードする方法の説明については、セクション5.4を参照してください。
A policy decision point can readily determine whether it supports the values stored in an instance of Constraint by checking the OID value from ConstraintEncoding against the set of OIDs it recognizes. The action for the policy decision point to take in case it does not recognize the format of this data could itself be modeled as a policy rule, governing the behavior of the policy decision point.
ポリシーの決定ポイントは、認識するOIDのセットに対する制約からOID値をチェックすることにより、制約の例に保存された値をサポートするかどうかを容易に決定できます。このデータの形式自体がポリシールールとしてモデル化され、ポリシー決定ポイントの動作を管理することができる場合に、ポリシー決定ポイントの訴訟は、それ自体がポリシールールとしてモデル化される可能性があります。
The property is defined as follows:
プロパティは次のように定義されています。
NAME Constraint
DESCRIPTION Extension mechanism for representing constraints
that have not been modeled as specific
properties. The format of the values is
identified by the OID stored in the property
ConstraintEncoding.
SYNTAX octet string
This property identifies the encoding and semantics of the Constraint property values in this instance. The value of this property is a single string, representing a single OID.
このプロパティは、この場合の制約プロパティ値のエンコーディングとセマンティクスを識別します。このプロパティの値は、単一のOIDを表す単一の文字列です。
The property is defined as follows:
プロパティは次のように定義されています。
NAME ConstraintEncoding
DESCRIPTION An OID encoded as a string, identifying the format
and semantics for this instance's Constraint
property. The value is a dotted sequence of
decimal digits (for example, "1.2.100.200")
representing the arcs of the OID. The characters
in the string are the UCS-2 characters
corresponding to the US ASCII encodings of the
numeric characters and the period.
SYNTAX string
The purpose of a policy action is to execute one or more operations that will affect network traffic and/or systems, devices, etc., in order to achieve a desired state. This (new) state provides one or more (new) behaviors. A policy action ordinarily changes the configuration of one or more elements.
ポリシーアクションの目的は、目的の状態を達成するために、ネットワークトラフィックおよび/またはシステム、デバイスなどに影響を与える1つ以上の操作を実行することです。この（新しい）状態は、1つ以上の（新しい）動作を提供します。ポリシーアクションは、通常、1つ以上の要素の構成を変更します。
A PolicyRule contains one or more policy actions. A policy administrator can assign an order to the actions associated with a PolicyRule, complete with an indication of whether the indicated order is mandatory, recommended, or of no significance. Ordering of the actions associated with a PolicyRule is accomplished via a property in the PolicyActionInPolicyRule aggregation.
Policyruleには、1つ以上のポリシーアクションが含まれています。ポリシー管理者は、指定された順序が必須であるか、推奨されているか、または重要でないかを示している、Policyruleに関連するアクションに注文を割り当てることができます。Policyruleに関連付けられたアクションの順序付けは、PolicationPolicyruleの凝集のプロパティを介して達成されます。
The actions associated with a PolicyRule are executed if and only if the overall condition(s) of the PolicyRule evaluates to TRUE.
Policyruleに関連するアクションは、Policyruleの全体的な条件がTrueに評価された場合にのみ実行されます。
The class definition of PolicyAction is as follows:
ポリシーのクラス定義は次のとおりです。
NAME PolicyAction DESCRIPTION A class representing a rule-specific or reusable policy action to be performed if the condition for a policy rule evaluates to TRUE. DERIVED FROM Policy ABSTRACT TRUE PROPERTIES NONE
名前のポリシーアクションの説明ポリシールールの条件がTRUEを評価する場合、実行されるルール固有または再利用可能なポリシーアクションを表すクラス。ポリシー抽象的な真のプロパティから導出されていません
No properties are defined for this class since it inherits all its properties from Policy. The class exists as an abstract superclass for domain-specific policy actions, defined in subclasses. In an implementation, various key/identification properties MUST be defined for the class or its instantiable subclasses. The keys for a native CIM implementation are defined in Appendix A, Section 13.3. Keys for an LDAP implementation will be defined in the LDAP mapping of this information model [11].
ポリシーからすべてのプロパティを継承するため、このクラスのプロパティは定義されていません。このクラスは、サブクラスで定義されたドメイン固有のポリシーアクションの抽象的なスーパークラスとして存在します。実装では、クラスまたはその瞬時のサブクラスに対して、さまざまなキー/識別プロパティを定義する必要があります。ネイティブCIM実装のキーは、付録A、セクション13.3に定義されています。LDAP実装のキーは、この情報モデルのLDAPマッピングで定義されます[11]。
When identifying and using the PolicyAction class, it is necessary to remember that an action can be rule-specific or reusable. This was discussed above in Section 5.1. The distinction between the two types of policy actions lies in the associations in which an instance can participate, and in how the different instances are named. Conceptually, a reusable policy action resides in a policy repository, and is named within the scope of that repository. On the other hand, a rule-specific policy action is named within the scope of the single policy rule to which it is related.
ポリシークラスを特定して使用する場合、アクションがルール固有または再利用可能である可能性があることを覚えておく必要があります。これは、セクション5.1で上記で説明しました。2種類のポリシーアクションの区別は、インスタンスが参加できる協会と、さまざまなインスタンスの名前のどのようにあるかにあります。概念的には、再利用可能なポリシーアクションはポリシーリポジトリにあり、そのリポジトリの範囲内で命名されます。一方、ルール固有のポリシーアクションは、それが関連している単一のポリシールールの範囲内で命名されます。
The distinction between rule-specific and reusable PolicyActions affects the CIM naming, defined in Appendix A, and the LDAP mapping [11].
ルール固有のポリシーアクションと再利用可能なポリシーアクションの区別は、付録AとLDAPマッピング[11]で定義されているCIMネーミングに影響します。
The purpose of this class is to provide a general extension mechanism for representing policy actions that have not been modeled with specific properties. Instead, the two properties ActionData and ActionEncoding are used to define the content and format of the action, as explained below.
このクラスの目的は、特定のプロパティでモデル化されていないポリシーアクションを表すための一般的な拡張メカニズムを提供することです。代わりに、以下で説明するように、アクションのコンテンツと形式を定義するために、ActionDataとActionEncodingの2つのプロパティが使用されます。
As its name suggests, this class is intended for vendor-specific extensions to the Policy Core Information Model. Standardized extensions are not expected to use this class.
その名前が示すように、このクラスは、ポリシーコア情報モデルへのベンダー固有の拡張を目的としています。標準化された拡張機能は、このクラスを使用することは期待されていません。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME VendorPolicyAction DESCRIPTION A class that defines a registered means to describe a policy action. DERIVED FROM PolicyAction ABSTRACT FALSE PROPERTIES ActionData[ ] ActionEncoding
名前vendorpolicyaction説明ポリシーアクションを説明するための登録手段を定義するクラス。Policyaction Abstract False Properties ActionData [] ActionEncodingから派生
This property provides a general extension mechanism for representing policy actions that have not been modeled with specific properties. The format of the octet strings in the array is left unspecified in this definition. It is determined by the OID value stored in the property ActionEncoding. Since ActionEncoding is single-valued, all the values of ActionData share the same format and semantics. See Section 5.4 for a discussion of how CIM encodes an array of octet strings like this one.
このプロパティは、特定のプロパティでモデル化されていないポリシーアクションを表すための一般的な拡張メカニズムを提供します。この定義では、配列内のオクテット文字列の形式は不特定のままになります。これは、プロパティアクションエンコードに保存されているOID値によって決定されます。アクションエンコードは単一値であるため、ActionDataのすべての値は同じ形式とセマンティクスを共有します。CIMがこのようなオクテット文字列の配列をエンコードする方法についての議論については、セクション5.4を参照してください。
A policy decision point can readily determine whether it supports the values stored in an instance of ActionData by checking the OID value from ActionEncoding against the set of OIDs it recognizes. The action for the policy decision point to take in case it does not recognize the format of this data could itself be modeled as a policy rule, governing the behavior of the policy decision point.
ポリシーの決定ポイントは、認識するOIDのセットに対するアクションエンコードからOID値をチェックすることにより、ActionDataのインスタンスに保存された値をサポートするかどうかを容易に判断できます。このデータの形式自体がポリシールールとしてモデル化され、ポリシー決定ポイントの動作を管理することができる場合に、ポリシー決定ポイントの訴訟は、それ自体がポリシールールとしてモデル化される可能性があります。
The property is defined as follows:
プロパティは次のように定義されています。
NAME ActionData
DESCRIPTION Extension mechanism for representing actions that
have not been modeled as specific properties. The
format of the values is identified by the OID
stored in the property ActionEncoding.
SYNTAX octet string
This property identifies the encoding and semantics of the ActionData property values in this instance. The value of this property is a single string, representing a single OID.
このプロパティは、このインスタンスでActionDataプロパティ値のエンコーディングとセマンティクスを識別します。このプロパティの値は、単一のOIDを表す単一の文字列です。
The property is defined as follows:
プロパティは次のように定義されています。
NAME ActionEncoding
DESCRIPTION An OID encoded as a string, identifying the format
and semantics for this instance's ActionData
property. The value is a dotted sequence of
decimal digits (for example, "1.2.100.200")
representing the arcs of the OID. The characters
in the string are the UCS-2 characters
corresponding to the US ASCII encodings of the
numeric characters and the period.
SYNTAX string
The class definition of PolicyRepository is as follows:
PolicyRepositoryのクラス定義は次のとおりです。
NAME PolicyRepository DESCRIPTION A class representing an administratively defined container for reusable policy-related information. This class does not introduce any additional properties beyond those in its superclass AdminDomain. It does, however, participate in a number of unique associations. DERIVED FROM AdminDomain ABSTRACT FALSE
名前PolicyRepository説明再利用可能なポリシー関連情報の管理上定義されたコンテナを表すクラス。このクラスでは、スーパークラスのアドマイン型の特性を超えて追加の特性を導入していません。ただし、多くのユニークな協会に参加しています。admindomain抽象FALSEから派生した
The first two subsections of this section introduce associations and aggregations as they are used in CIM. The remaining subsections present the class definitions for the associations and aggregations that are part of the Policy Core Information Model.
このセクションの最初の2つのサブセクションでは、CIMで使用されているアソシエーションと集約を紹介します。残りのサブセクションは、ポリシーコア情報モデルの一部であるアソシエーションと集約のクラス定義を示しています。
An association is a CIM construct representing a relationship between two (or theoretically more) objects. It is modeled as a class containing typically two object references. Associations can be defined between classes without affecting any of the related classes. That is, addition of an association does not affect the interface of the related classes.
関連は、2つの（または理論的には）オブジェクト間の関係を表すCIM構造です。通常、2つのオブジェクト参照を含むクラスとしてモデル化されています。関連するクラス間で関連することは、関連するクラスに影響を与えることなく定義できます。つまり、関連性を追加しても、関連するクラスのインターフェイスには影響しません。
An aggregation is a strong form of an association, which usually represents a "whole-part" or a "collection" relationship. For example, CIM uses an aggregation to represent the containment relationship between a system and the components that make up the system. Aggregation as a "whole-part" relationship often implies, but does not require, that the aggregated objects have mutual dependencies.
集約は、関連性の強力な形式であり、通常は「全体的な」または「コレクション」関係を表します。たとえば、CIMは集約を使用して、システムとシステムを構成するコンポーネントとの封じ込め関係を表します。「全体的な」関係としての集約は、しばしば集約されたオブジェクトに相互依存関係があることを意味しますが、必要としません。
This abstract aggregation defines two object references that will be overridden in each of five subclasses, to become references to the concrete policy classes PolicyGroup, PolicyRule, PolicyCondition, PolicyAction, and PolicyTimePeriodCondition. The value of the abstract superclass is to convey that all five subclasses have the same "whole- part" semantics, and for ease of query to locate all "components" of a PolicyGroup or PolicyRule.
この抽象集計は、5つのサブクラスのそれぞれでオーバーライドされる2つのオブジェクト参照を定義し、具体的なポリシークラスのポリシーグループ、Policyrule、Policycondition、Polication、およびPolicyTimeperiodConditionへの参照となります。抽象的なスーパークラスの価値は、5つのサブクラスすべてが同じ「全部」セマンティクスを持っていることを伝え、ポリシーグループまたはPolicyruleのすべての「コンポーネント」を見つけるためのクエリを容易にすることです。
The class definition for the aggregation is as follows:
集約のクラス定義は次のとおりです。
NAME PolicyComponent DESCRIPTION A generic aggregation used to establish 'part of' relationships between the subclasses of Policy. For example, the PolicyConditionInPolicyRule aggregation defines that PolicyConditions are part of a PolicyRule. ABSTRACT TRUE PROPERTIES GroupComponent[ref Policy[0..n]] PartComponent[ref Policy[0..n]]
名前PolicyComponentの説明ポリシーのサブクラス間の「「」関係の一部を確立するために使用される一般的な集約。たとえば、PolicyConditionInpolicyruleの凝集は、PolicyconditionがPolicyruleの一部であることを定義しています。要約真のプロパティグループコンポーネント[Ref Policy [0..N]] PartComponent [Ref Policy [0..N]]
The PolicyGroupInPolicyGroup aggregation enables policy groups to be nested. This is critical for scalability and manageability, as it enables complex policies to be constructed from multiple simpler policies for administrative convenience. For example, a policy group representing policies for the US might have nested within it policy groups for the Eastern and Western US.
PolicyGroupinPolicyGroupの集約により、ポリシーグループをネストすることができます。これは、スケーラビリティと管理性にとって重要です。これは、管理上の利便性のための複数の単純なポリシーから複雑なポリシーを構築できるためです。たとえば、米国のポリシーを表す政策グループは、米国東部および西部のIT政策グループ内にネストされている可能性があります。
A PolicyGroup may aggregate other PolicyGroups via this aggregation, or it may aggregate PolicyRules via the PolicyRuleInPolicyGroup aggregation. Note that it is assumed that this aggregation is used to form directed acyclic graphs and NOT ring structures.The class definition for the aggregation is as follows:
ポリシーグループは、この集合体を介して他のポリシーグループを集約するか、Policyruleinpolicygroup凝集を介してPolicyrulesを集約する場合があります。この集合体は、指示された非環式グラフを形成し、リング構造ではなく形成するために使用されると想定されていることに注意してください。集約のクラス定義は次のとおりです。
NAME PolicyGroupInPolicyGroup DESCRIPTION A class representing the aggregation of PolicyGroups by a higher-level PolicyGroup. DERIVED FROM PolicyComponent ABSTRACT FALSE PROPERTIES GroupComponent[ref PolicyGroup[0..n]] PartComponent[ref PolicyGroup[0..n]]
名前PolicyGroupinPolicyGroup説明高レベルのポリシーグループによるポリシーグループの集約を表すクラス。PolicyComponent Abstract False Properties GroupComponent [Ref PolicyGroup [0..N]] PartComponent [Ref PolicyGroup [0..N]]から派生
This property is inherited from PolicyComponent, and overridden to become an object reference to a PolicyGroup that contains one or more other PolicyGroups. Note that for any single instance of the aggregation class PolicyGroupInPolicyGroup, this property (like all Reference properties) is single-valued. The [0..n] cardinality indicates that there may be 0, 1, or more than one PolicyGroups that contain any given PolicyGroup.
このプロパティは、PolicyComponentから継承されており、1つ以上の他のポリシーグループを含むポリシーグループへのオブジェクト参照になります。Aggregation Class PolicyGroupInPolicyGroupの単一のインスタンスでは、このプロパティ（すべての参照プロパティと同様）が単一値であることに注意してください。[0..n]カーディナリティは、特定のポリシーグループを含む0、1、または複数のポリシーグループがある可能性があることを示しています。
This property is inherited from PolicyComponent, and overridden to become an object reference to a PolicyGroup contained by one or more other PolicyGroups. Note that for any single instance of the aggregation class PolicyGroupInPolicyGroup, this property (like all Reference properties) is single-valued. The [0..n] cardinality indicates that a given PolicyGroup may contain 0, 1, or more than one other PolicyGroups.
このプロパティは、PolicyComponentから継承されており、1つ以上の他のポリシーグループが含まれるポリシーグループへのオブジェクト参照となるようにオーバーライドされています。Aggregation Class PolicyGroupInPolicyGroupの単一のインスタンスでは、このプロパティ（すべての参照プロパティと同様）が単一値であることに注意してください。[0..n]カーディナリティは、特定のポリシーグループに0、1、または複数の他のポリシーグループが含まれている可能性があることを示しています。
A policy group may aggregate one or more policy rules, via the PolicyRuleInPolicyGroup aggregation. Grouping of policy rules into a policy group is again for administrative convenience; a policy rule may also be used by itself, without belonging to a policy group.
ポリシーグループは、PolicyRuleinPolicyGroup集合体を介して、1つ以上のポリシールールを集約することができます。ポリシールールをポリシーグループにグループ化することは、再び管理上の利便性のためです。ポリシールールは、ポリシーグループに属さずに、単独で使用することもできます。
A PolicyGroup may aggregate PolicyRules via this aggregation, or it may aggregate other PolicyGroups via the PolicyGroupInPolicyGroup aggregation.
ポリシーグループは、この集合体を介して政策を凝集させることができます。または、ポリシーグループのポリシーグループをPolicyGroupinPolicyGroupの集約を介して集約する場合があります。
The class definition for the aggregation is as follows:
集約のクラス定義は次のとおりです。
NAME PolicyRuleInPolicyGroup DESCRIPTION A class representing the aggregation of PolicyRules by a PolicyGroup. DERIVED FROM PolicyComponent ABSTRACT FALSE PROPERTIES GroupComponent[ref PolicyGroup[0..n]] PartComponent[ref PolicyRule[0..n]]
名前policyruleinpolicygroup説明ポリシーグループによる政策の集約を表すクラス。PolicyComponent Abstract False Properties GroupComponent [Ref PolicyGroup [0..N]] PartComponent [Ref Policyrule [0..N]]から派生
This property is inherited from PolicyComponent, and overridden to become an object reference to a PolicyGroup that contains one or more PolicyRules. Note that for any single instance of the aggregation class PolicyRuleInPolicyGroup, this property (like all Reference properties) is single-valued. The [0..n] cardinality indicates that there may be 0, 1, or more than one PolicyGroups that contain any given PolicyRule.
このプロパティは、PolicyComponentから継承されており、1つ以上の政策を含むポリシーグループへのオブジェクト参照になるようにオーバーライドされています。集約クラスPolicyRuleinPolicyGroupの単一のインスタンスでは、このプロパティ（すべての参照プロパティと同様）は単一値であることに注意してください。[0..n]カーディナリティは、特定のPolicyruleを含む0、1、または複数のポリシーグループがある可能性があることを示しています。
This property is inherited from PolicyComponent, and overridden to become an object reference to a PolicyRule contained by one or more PolicyGroups. Note that for any single instance of the aggregation class PolicyRuleInPolicyGroup, this property (like all Reference properties) is single-valued. The [0..n] cardinality indicates that a given PolicyGroup may contain 0, 1, or more than one PolicyRules.
このプロパティは、PolicyComponentから継承されており、1つ以上のポリシーグループに含まれるPolicyruleへのオブジェクト参照になります。集約クラスPolicyRuleinPolicyGroupの単一のインスタンスでは、このプロパティ（すべての参照プロパティと同様）は単一値であることに注意してください。[0..n]カーディナリティは、特定のポリシーグループに0、1、または複数の政策を含むことができることを示しています。
A policy rule aggregates zero or more instances of the PolicyCondition class, via the PolicyConditionInPolicyRule association. A policy rule that aggregates zero policy conditions must indicate in its class definition what "triggers" the performance of its actions. In short, it must describe its implicit PolicyConditions, since none are explicitly associated. For example, there might be a subclass of PolicyRule named "HttpPolicyRule", where the class definition assumes that the condition, "If HTTP traffic," is true before the rule's actions would be performed. There is no need to formalize and instantiate this condition, since it is obvious in the semantics of the PolicyRule.
ポリシールールは、PolicyConditionInpolicyrule Associationを介して、PolicyConditionクラスのゼロ以上のインスタンスを集約します。ゼロのポリシー条件を集約するポリシールールは、クラスの定義で、アクションのパフォーマンスを「トリガー」するものを示す必要があります。要するに、誰も明示的に関連付けられていないため、その暗黙の政策条件を説明する必要があります。たとえば、「httppolicyrule」という名前のpolicyruleのサブクラスがあるかもしれません。クラス定義は、「httpトラフィックの場合」がルールのアクションが実行される前に真実であると想定しています。Policyruleのセマンティクスでは明らかであるため、この状態を形式化してインスタンス化する必要はありません。
The conditions aggregated by a policy rule are grouped into two levels of lists: either an ORed set of ANDed sets of conditions (DNF, the default) or an ANDed set of ORed sets of conditions (CNF). Individual conditions in these lists may be negated. The property ConditionListType (in PolicyRule) specifies which of these two grouping schemes applies to a particular PolicyRule. The conditions are used to determine whether to perform the actions associated with the PolicyRule.
ポリシールールによって集約された条件は、2つのレベルのリストにグループ化されます。これらのリストの個々の条件は否定される場合があります。プロパティコンディスタイプ（Policyrule）は、これら2つのグループ化スキームのどれが特定のPolicyruleに適用されるかを指定します。条件は、Policyruleに関連するアクションを実行するかどうかを決定するために使用されます。
One or more policy time periods may be among the conditions associated with a policy rule via the PolicyConditionInPolicyRule association. In this case, the time periods are simply additional conditions to be evaluated along with any other conditions specified for the rule.
1つ以上のポリシー期間は、PolicyConditionInpolicyrule Associationを介してポリシールールに関連する条件の1つである可能性があります。この場合、期間は、ルールに指定された他の条件とともに評価される追加の条件です。
The class definition for the aggregation is as follows:
集約のクラス定義は次のとおりです。
NAME PolicyConditionInPolicyRule DESCRIPTION A class representing the aggregation of PolicyConditions by a PolicyRule. DERIVED FROM PolicyComponent ABSTRACT FALSE PROPERTIES GroupComponent[ref PolicyRule[0..n]] PartComponent[ref PolicyCondition[0..n]] GroupNumber ConditionNegated
名前policyconditioninpolicyrule説明Policyruleによる政策条件の集合を表すクラス。Policycomponentから派生誤った誤ったプロパティグループコンポーネント[Ref Policyrule [0..N]] PartComponent [Ref PolicyCondition [0..N]] GroupNumber condition -negated
This property is inherited from PolicyComponent, and overridden to become an object reference to a PolicyRule that contains one or more PolicyConditions. Note that for any single instance of the aggregation class PolicyConditionInPolicyRule, this property (like all Reference properties) is single-valued. The [0..n] cardinality indicates that there may be 0, 1, or more than one PolicyRules that contain any given PolicyCondition.
このプロパティは、PolicyComponentから継承され、1つ以上のPolicyconditionを含むPolicyruleへのオブジェクト参照になるように無効にされます。集約クラスPolicyConditionInPolicyruleの単一のインスタンスでは、このプロパティ（すべての参照プロパティと同様）は単一値であることに注意してください。[0..n]カーディナリティは、特定の政策条件を含む0、1、または複数の政策が存在する可能性があることを示しています。
This property is inherited from PolicyComponent, and overridden to become an object reference to a PolicyCondition contained by one or more PolicyRules. Note that for any single instance of the aggregation class PolicyConditionInPolicyRule, this property (like all Reference properties) is single-valued. The [0..n] cardinality indicates that a given PolicyRule may contain 0, 1, or more than one PolicyConditions.
このプロパティは、PolicyComponentから継承されており、1つ以上のPolicyrulesが含まれるPolicyconditionへのオブジェクト参照になるためにオーバーライドされています。集約クラスPolicyConditionInPolicyruleの単一のインスタンスでは、このプロパティ（すべての参照プロパティと同様）は単一値であることに注意してください。[0..n]カーディナリティは、特定のPolicyruleに0、1、または複数のPolicyconditionが含まれている可能性があることを示しています。
This property contains an integer identifying the group to which the condition referenced by the PartComponent property is assigned in forming the overall conditional expression for the policy rule identified by the GroupComponent reference.
このプロパティには、PartComponentプロパティによって参照される条件がグループを識別する整数が含まれています。これは、グループコンポーネント参照によって識別されるポリシールールの全体的な条件式を形成することに割り当てられています。
The property is defined as follows:
プロパティは次のように定義されています。
NAME GroupNumber
DESCRIPTION Unsigned integer indicating the group to which
the condition identified by the PartComponent
property is to be assigned.
SYNTAX uint16
DEFAULT 0
This property is a boolean, indicating whether the condition referenced by the PartComponent property is negated in forming the overall conditional expression for the policy rule identified by the GroupComponent reference.
このプロパティはブール値であり、PartComponentプロパティによって参照される条件が、グループコンポーネント参照によって識別されるポリシールールの全体的な条件付き式を形成する際に否定されるかどうかを示します。
The property is defined as follows:
プロパティは次のように定義されています。
NAME ConditionNegated
DESCRIPTION Indication of whether the condition identified by
the PartComponent property is negated. (TRUE
indicates that the condition is negated, FALSE
indicates that it is not negated.)
SYNTAX boolean
DEFAULT FALSE
A different relationship between a policy rule and a policy time period (than PolicyConditionInPolicyRule) is represented by the PolicyRuleValidityPeriod aggregation. The latter describes scheduled activation and deactivation of the policy rule.
ポリシールールとポリシー期間（Policyconditioninpolicyruleよりも）の異なる関係は、Policyrulevalidityperidideperiodの集約によって表されます。後者は、ポリシールールのスケジュールされたアクティベーションと非アクティブ化について説明しています。
If a policy rule is associated with multiple policy time periods via this association, then the rule is active if at least one of the time periods indicates that it is active. (In other words, the time periods are ORed to determine whether the rule is active.) A policy time period may be aggregated by multiple policy rules. A rule that does not point to a policy time period via this aggregation is, from the point of view of scheduling, always active. It may, however, be inactive for other reasons.
ポリシールールがこの協会を介して複数のポリシー期間に関連付けられている場合、少なくとも1つの期間がアクティブであることを示している場合、ルールはアクティブです。（言い換えれば、期間はルールがアクティブであるかどうかを判断するために設定されています。）ポリシー期間は、複数のポリシールールによって集約される可能性があります。この集約を介したポリシー期間を指し示していないルールは、スケジューリングの観点からは常にアクティブです。ただし、他の理由では非アクティブである場合があります。
Time periods are a general concept that can be used in other applications. However, they are mentioned explicitly here in this specification since they are frequently used in policy applications.
期間は、他のアプリケーションで使用できる一般的な概念です。ただし、ポリシーアプリケーションで頻繁に使用されるため、この仕様では明示的に言及されています。
The class definition for the aggregation is as follows:
集約のクラス定義は次のとおりです。
NAME PolicyRuleValidityPeriod DESCRIPTION A class representing the aggregation of PolicyTimePeriodConditions by a PolicyRule. DERIVED FROM PolicyComponent ABSTRACT FALSE PROPERTIES GroupComponent[ref PolicyRule[0..n]] PartComponent[ref PolicyTimePeriodCondition[0..n]]
名前PolicyRulevalidityPeriod説明PolicyRuleによるPolicyTimeperiodConditionsの集約を表すクラス。PolicyComponentから導出されたAbstract False Propertiesグループコンポーネント[Ref Policyrule [0..N]] PartComponent [Ref PolicyTimeperiodCondition [0..N]]
This property is inherited from PolicyComponent, and overridden to become an object reference to a PolicyRule that contains one or more PolicyTimePeriodConditions. Note that for any single instance of the aggregation class PolicyRuleValidityPeriod, this property (like all Reference properties) is single-valued. The [0..n] cardinality indicates that there may be 0, 1, or more than one PolicyRules that contain any given PolicyTimePeriodCondition.
このプロパティは、PolicyComponentから継承されており、1つ以上のPolicyTimeperiodConditionsを含むPolicyruleへのオブジェクト参照になるようにオーバーライドされています。集約クラスPolicyrulevalidityPeriodの単一のインスタンスでは、このプロパティ（すべての参照プロパティと同様）は単一値であることに注意してください。[0..n]カーディナリティは、特定のPolicyTimeperiodConditionを含む0、1、または複数の政策が存在する可能性があることを示しています。
This property is inherited from PolicyComponent, and overridden to become an object reference to a PolicyTimePeriodCondition contained by one or more PolicyRules. Note that for any single instance of the aggregation class PolicyRuleValidityPeriod, this property (like all Reference properties) is single-valued. The [0..n] cardinality indicates that a given PolicyRule may contain 0, 1, or more than one PolicyTimePeriodConditions.
このプロパティは、PolicyComponentから継承され、1つ以上のPolicyrulesが含まれるPolicyTimeperiodConditionへのオブジェクト参照になるようにオーバーライドされています。集約クラスPolicyrulevalidityPeriodの単一のインスタンスでは、このプロパティ（すべての参照プロパティと同様）は単一値であることに注意してください。[0..n]カーディナリティは、特定のPolicyruleに0、1、または複数のPolicyTimeperiodConditionsが含まれていることを示しています。
A policy rule may aggregate zero or more policy actions. A policy rule that aggregates zero policy actions must indicate in its class definition what actions are taken when the rule's conditions evaluate to TRUE. In short, it must describe its implicit PolicyActions, since none are explicitly associated. For example, there might be a subclass of PolicyRule representing a Diffserv absolute dropper, where the subclass itself indicates the action to be taken. There is no need to formalize and instantiate this action, since it is obvious in the semantics of the PolicyRule.
ポリシールールは、ゼロ以上のポリシーアクションを集約する場合があります。ゼロのポリシーアクションを集約するポリシールールは、クラスの定義で、ルールの条件がTrueに評価されたときにどのようなアクションが実行されるかを示す必要があります。要するに、誰も明示的に関連付けられていないため、暗黙の政策を説明する必要があります。たとえば、Diffserv Absolute Dropperを表すPolicyruleのサブクラスがある場合があり、サブクラス自体が実行されるアクションを示しています。Policyruleのセマンティクスでは明らかであるため、このアクションを形式化してインスタンス化する必要はありません。
The actions associated with a PolicyRule may be given a required order, a recommended order, or no order at all. For actions represented as separate objects, the PolicyActionInPolicyRule aggregation can be used to express an order.
Policyruleに関連するアクションには、必要な順序、推奨順序、またはまったく順序が与えられない場合があります。別々のオブジェクトとして表されるアクションの場合、ポリシーインチングインポリルールの凝集を使用して順序を表すことができます。
This aggregation does not indicate whether a specified action order is required, recommended, or of no significance; the property SequencedActions in the aggregating instance of PolicyRule provides this indication.
この集約は、指定されたアクションオーダーが必要であるか、推奨されているか、または重要でないかを示していません。Policyruleの集約インスタンスにおけるプロパティシーケンス編集は、この兆候を提供します。
The class definition for the aggregation is as follows:
集約のクラス定義は次のとおりです。
NAME PolicyActionInPolicyRule DESCRIPTION A class representing the aggregation of PolicyActions by a PolicyCondition. DERIVED FROM PolicyComponent ABSTRACT FALSE PROPERTIES GroupComponent[ref PolicyRule[0..n]] PartComponent[ref PolicyAction[0..n]] ActionOrder
名前PolicyActionInPolicyrule説明PolicyConditionによる政策の集約を表すクラス。PolicyComponentから派生誤った誤プロパティグループコンポーネント[Ref PolicyRule [0..N]] PartComponent [Ref Policycaction [0..N]] ActionOrder
This property is inherited from PolicyComponent, and overridden to become an object reference to a PolicyRule that contains one or more PolicyActions. Note that for any single instance of the aggregation class PolicyActionInPolicyRule, this property (like all Reference properties) is single-valued. The [0..n] cardinality indicates that there may be 0, 1, or more than one PolicyRules that contain any given PolicyAction.
このプロパティは、PolicyComponentから継承されており、1つ以上のポリシーを含むPolicyruleへのオブジェクト参照になるようにオーバーライドされています。集約クラスPolicycactionInPolicyruleの単一のインスタンスでは、このプロパティ（すべての参照プロパティと同様）が単一値であることに注意してください。[0..n]カーディナリティは、特定のポリシーを含む0、1、または複数の政策がある可能性があることを示しています。
This property is inherited from PolicyComponent, and overridden to become an object reference to a PolicyAction contained by one or more PolicyRules. Note that for any single instance of the aggregation class PolicyActionInPolicyRule, this property (like all Reference properties) is single-valued. The [0..n] cardinality indicates that a given PolicyRule may contain 0, 1, or more than one PolicyActions.
このプロパティは、PolicyComponentから継承されており、1つ以上のPolicyrulesが含まれるポリシーアクションへのオブジェクト参照となるようにオーバーライドされています。集約クラスPolicycactionInPolicyruleの単一のインスタンスでは、このプロパティ（すべての参照プロパティと同様）が単一値であることに注意してください。[0..n]カーディナリティは、特定のPolicyruleに0、1、または複数の政策が含まれている可能性があることを示しています。
This property provides an unsigned integer 'n' that indicates the relative position of an action in the sequence of actions associated with a policy rule. When 'n' is a positive integer, it indicates a place in the sequence of actions to be performed, with smaller integers indicating earlier positions in the sequence. The special value '0' indicates "don't care". If two or more actions have the same non-zero sequence number, they may be performed in any order, but they must all be performed at the appropriate place in the overall action sequence.
このプロパティは、ポリシールールに関連付けられた一連のアクションにおけるアクションの相対的な位置を示す署名されていない整数「n」を提供します。「n」が正の整数である場合、それは実行される一連のアクションのシーケンス内の場所を示します。特別な値「0」は「気にしない」を示します。2つ以上のアクションが同じ非ゼロシーケンス番号を持っている場合、それらは任意の順序で実行される場合がありますが、それらはすべて全体的なアクションシーケンスの適切な場所で実行する必要があります。
A series of examples will make ordering of actions clearer:
一連の例により、アクションの順序付けがより明確になります。
o If all actions have the same sequence number, regardless of whether it is '0' or non-zero, any order is acceptable.
o すべてのアクションが「0」か非ゼロかに関係なく、同じシーケンス番号を持っている場合、順序は許容されます。
o The values
o その価値
1:ACTION A 2:ACTION B 1:ACTION C 3:ACTION D
1：アクションA 2：アクションB 1：アクションC 3：アクションD
indicate two acceptable orders: A,C,B,D or C,A,B,D, since A and C can be performed in either order, but only at the '1' position.
A、C、B、DまたはC、A、B、Dの2つの許容順序を示します。AおよびCはどちらの順序でも、「1」位置でのみ実行できるためです。
o The values
o その価値
0:ACTION A 2:ACTION B 3:ACTION C 3:ACTION D
0：アクションA 2：アクションB 3：アクションC 3：アクションD
require that B,C, and D occur either as B,C,D or as B,D,C. Action A may appear at any point relative to B,C, and D. Thus the complete set of acceptable orders is: A,B,C,D; B,A,C,D; B,C,A,D; B,C,D,A; A,B,D,C; B,A,D,C; B,D,A,C; B,D,C,A.
B、C、およびDがB、C、D、またはB、D、Cとして発生することを要求します。アクションAは、b、c、およびDに比べて任意のポイントで表示される場合があります。したがって、許容順序の完全なセットは次のとおりです。B、A、C、D;B、C、A、D;B、C、D、A;A、B、D、C;B、A、D、C;B、D、A、C;b、d、c、a。
Note that the non-zero sequence numbers need not start with '1', and they need not be consecutive. All that matters is their relative magnitude.
ゼロ以外のシーケンス番号は「1」で始まる必要はなく、連続する必要はないことに注意してください。重要なのは、相対的な大きさだけです。
The property is defined as follows:
プロパティは次のように定義されています。
NAME ActionOrder
DESCRIPTION Unsigned integer indicating the relative position
of an action in the sequence of actions aggregated
by a policy rule.
SYNTAX uint16
This abstract association inherits two object references from a higher- level CIM association class, Dependency. It overrides these object references to make them references to instances of the classes System and Policy. Subclasses of PolicyInSystem then override these object references again, to make them references to concrete policy classes.
この抽象的なアソシエーションは、高レベルのCIMアソシエーションクラス、依存関係から2つのオブジェクト参照を継承します。これらのオブジェクトの参照をオーバーライドして、クラスシステムとポリシーのインスタンスへの参照を作成します。PolicyInsystemのサブクラスは、これらのオブジェクト参照を再度上書きし、具体的なポリシークラスへの参照を作成します。
The value of the abstract superclass is to convey that all subclasses have the same "dependency" semantics, and for ease of query to locate all policy "dependencies" on a System. These dependencies are related to scoping or hosting of the Policy.
抽象スーパークラスの価値は、すべてのサブクラスに同じ「依存関係」セマンティクスを持ち、システムのすべてのポリシー「依存関係」を見つけるためのクエリを容易にすることです。これらの依存関係は、ポリシーのスコーピングまたはホスティングに関連しています。
The class definition for the association is as follows:
協会のクラス定義は次のとおりです。
NAME PolicyInSystem DESCRIPTION A generic association used to establish dependency relationships between Policies and the Systems that host them. DERIVED FROM Dependency ABSTRACT TRUE PROPERTIES Antecedent[ref System[0..1]] Dependent[ref Policy[0..n]]
名前PolicyInsystemの説明ポリシーとそれらをホストするシステムとの間の依存関係を確立するために使用される一般的な関連付け。依存関係から導出された抽象的な真のプロパティアンティデント[Ref System [0..1]]依存[Ref Policy [0..N]]
This association links a PolicyGroup to the System in whose scope the PolicyGroup is defined.
この協会は、ポリシーグループをポリシーグループが定義されているシステムにリンクしています。
The class definition for the association is as follows:
協会のクラス定義は次のとおりです。
NAME PolicyGroupInSystem DESCRIPTION A class representing the fact that a PolicyGroup is defined within the scope of a System. DERIVED FROM PolicyInSystem ABSTRACT FALSE PROPERTIES Antecedent[ref System[1..1]] Dependent[ref PolicyGroup[weak]]
名前PolicyGroupInsystemの説明システムの範囲内でポリシーグループが定義されているという事実を表すクラス。PolicyInsystemから派生した抽象的な虚偽のプロパティアンティデント[Ref System [1..1]]依存[Ref PolicyGroup [weak]]
This property is inherited from PolicyInSystem, and overridden to restrict its cardinality to [1..1]. It serves as an object reference to a System that provides a scope for one or more PolicyGroups. Since this is a weak association, the cardinality for this object reference is always 1, that is, a PolicyGroup is always defined within the scope of exactly one System.
この特性は、PolicyInsystemから継承されており、その枢機inalを[1..1]に制限するために無効にされています。これは、1つ以上のポリシーグループの範囲を提供するシステムへのオブジェクト参照として機能します。これは弱い関連であるため、このオブジェクト参照のカーディナリティは常に1です。つまり、ポリシーグループは常に1つのシステムの範囲内で定義されます。
This property is inherited from PolicyInSystem, and overridden to become an object reference to a PolicyGroup defined within the scope of a System. Note that for any single instance of the association class PolicyGroupInSystem, this property (like all Reference properties) is single-valued. The [0..n] cardinality indicates that a given System may have 0, 1, or more than one PolicyGroups defined within its scope.
このプロパティは、PolicyInsystemから継承されており、システムの範囲内で定義されているポリシーグループへのオブジェクト参照になるようにオーバーライドされています。Association Class PolicyGroupInsystemの単一のインスタンスでは、このプロパティ（すべての参照プロパティと同様）が単一値であることに注意してください。[0..n]カーディナリティは、特定のシステムに、その範囲内で定義されている0、1、または複数のポリシーグループがあることを示しています。
Regardless of whether it belongs to a PolicyGroup (or to multiple PolicyGroups), a PolicyRule is itself defined within the scope of a System. This association links a PolicyRule to the System in whose scope the PolicyRule is defined.
ポリシーグループ（または複数のポリシーグループ）に属しているかどうかに関係なく、Policyrule自体はシステムの範囲内で定義されます。この関連付けは、Policyruleをシステムにリンクしており、その範囲がPolicyruleが定義されています。
The class definition for the association is as follows:
協会のクラス定義は次のとおりです。
NAME PolicyRuleInSystem DESCRIPTION A class representing the fact that a PolicyRule is defined within the scope of a System. DERIVED FROM PolicyInSystem ABSTRACT FALSE PROPERTIES Antecedent[ref System[1..1]] Dependent[ref PolicyRule[weak]]
名前PolicyRuleInsystemの説明システムの範囲内でPolicyruleが定義されているという事実を表すクラス。PolicyInsystemから派生抽象的な偽のプロパティアンティデント[Ref System [1..1]]依存[Ref Policyrule [weak]]
This property is inherited from PolicyInSystem, and overridden to restrict its cardinality to [1..1]. It serves as an object reference to a System that provides a scope for one or more PolicyRules. Since this is a weak association, the cardinality for this object reference is always 1, that is, a PolicyRule is always defined within the scope of exactly one System.
この特性は、PolicyInsystemから継承されており、その枢機inalを[1..1]に制限するために無効にされています。これは、1つ以上の政策の範囲を提供するシステムへのオブジェクト参照として機能します。これは弱い関連であるため、このオブジェクト参照のカーディナリティは常に1です。つまり、Policyruleは常に1つのシステムの範囲内で定義されます。
This property is inherited from PolicyInSystem, and overridden to become an object reference to a PolicyRule defined within the scope of a System. Note that for any single instance of the association class PolicyRuleInSystem, this property (like all Reference properties) is single-valued. The [0..n] cardinality indicates that a given System may have 0, 1, or more than one PolicyRules defined within its scope.
このプロパティは、PolicyInsystemから継承されており、システムの範囲内で定義されているPolicyruleへのオブジェクト参照になるようにオーバーライドされています。Association Class PolicyruleInsystemの単一のインスタンスでは、このプロパティ（すべての参照プロパティと同様）が単一値であることに注意してください。[0..n]カーディナリティは、特定のシステムがその範囲内で定義されている0、1、または複数の政策を持っていることを示しています。
A reusable policy condition is always related to a single PolicyRepository, via the PolicyConditionInPolicyRepository association. This is not true for all PolicyConditions, however. An instance of PolicyCondition that represents a rule-specific condition is not related to any policy repository via this association.
再利用可能な政策条件は、PolicyConditionInpolicyrepository Associationを介して、常に単一のPolicyRepositoryに関連しています。ただし、これはすべてのPolicyConditionsに当てはまりません。ルール固有の条件を表すPolicy-Conditionのインスタンスは、この協会を介してポリシーリポジトリとは関係ありません。
The class definition for the association is as follows:
協会のクラス定義は次のとおりです。
NAME PolicyConditionInPolicyRepository DESCRIPTION A class representing the inclusion of a reusable PolicyCondition in a PolicyRepository. DERIVED FROM PolicyInSystem ABSTRACT FALSE PROPERTIES Antecedent[ref PolicyRepository[0..1]] Dependent[ref PolicyCondition[0..n]]
名前PolicyConditionInpolicyrepository説明Policy -repositoryに再利用可能なPolicyconditionを含めることを表すクラス。PolicyInsystemから派生した誤った誤ったプロパティアンティデント[Ref PolicyRepository [0..1]]依存[Ref Policycondition [0..N]]
This property is inherited from PolicyInSystem, and overridden to become an object reference to a PolicyRepository containing one or more PolicyConditions. A reusable PolicyCondition is always related to exactly one PolicyRepository via the PolicyConditionInPolicyRepository association. The [0..1] cardinality for this property covers the two types of PolicyConditions: 0 for a rule-specific PolicyCondition, 1 for a reusable one.
このプロパティは、PolicyInsystemから継承されており、1つ以上のPolicyconditionを含むPolicyyrepositoryへのオブジェクト参照になります。再利用可能なPolicyconditionは、PolicyConditionInpolicyrepository Associationを介して常に1つのPolicyRepositoryに常に関連しています。[0..1]このプロパティのカーディナリティは、2種類の政策条件をカバーしています。0ルール固有の政策条件の場合は、再利用可能なものについては1。
This property is inherited from PolicyInSystem, and overridden to become an object reference to a PolicyCondition included in a PolicyRepository. Note that for any single instance of the association class PolicyConditionInPolicyRepository, this property (like all Reference properties) is single-valued. The [0..n] cardinality indicates that a given PolicyRepository may contain 0, 1, or more than one PolicyConditions.
このプロパティは、PolicyInsystemから継承されており、PolicyRepositoryに含まれるPolicycoonditionへのオブジェクト参照になるようにオーバーライドされています。Association Class PolicyConditionInPolicyRepositoryの単一のインスタンスでは、このプロパティ（すべての参照プロパティと同様）が単一値であることに注意してください。[0..n]カーディナリティは、特定のPolicyRepositoryに0、1、または複数のPolicycodthictionが含まれている可能性があることを示しています。
A reusable policy action is always related to a single PolicyRepository, via the PolicyActionInPolicyRepository association. This is not true for all PolicyActions, however. An instance of PolicyAction that represents a rule-specific action is not related to any policy repository via this association.
再利用可能な政策措置は、PolicycationInPolicyRepository Associationを介して、常に単一のPolicyRepositoryに関連しています。ただし、これはすべてのポリシーに当てはまりません。ルール固有のアクションを表すポリシーのインスタンスは、この協会を介してどのポリシーリポジトリにも関連していません。
The class definition for the association is as follows:
協会のクラス定義は次のとおりです。
NAME PolicyActionInPolicyRepository DESCRIPTION A class representing the inclusion of a reusable PolicyAction in a PolicyRepository. DERIVED FROM PolicyInSystem ABSTRACT FALSE PROPERTIES Antecedent[ref PolicyRepository[0..1]] Dependent[ref PolicyAction[0..n]]
名前policycactioninpolicyrepository説明Policyyrepositoryに再利用可能なポリシーを含めることを表すクラス。PolicyInsystemから派生した誤った誤ったプロパティアンティデント[Ref PolicyRepository [0..1]]依存[Ref Policycaction [0..N]]
This property is inherited from PolicyInSystem, and overridden to become an object reference to a PolicyRepository containing one or more PolicyActions. A reusable PolicyAction is always related to exactly one PolicyRepository via the PolicyActionInPolicyRepository association. The [0..1] cardinality for this property covers the two types of PolicyActions: 0 for a rule-specific PolicyAction, 1 for a reusable one.
このプロパティは、PolicyInsystemから継承されており、1つ以上のポリシーを含むPolicyyrepositoryのオブジェクト参照になります。再利用可能なポリシーは、常にPolicyactionInPolicyRepository Associationを介して1つのPolicyRepositoryに関連しています。このプロパティの[0..1]カーディナリティは、2種類のポリシーをカバーしています。0ルール固有のポリシーの場合は、再利用可能なポリシーの場合は1です。
This property is inherited from PolicyInSystem, and overridden to become an object reference to a PolicyAction included in a PolicyRepository. Note that for any single instance of the association class PolicyActionInPolicyRepository, this property (like all Reference properties) is single-valued. The [0..n] cardinality indicates that a given PolicyRepository may contain 0, 1, or more than one PolicyActions.
このプロパティは、PolicyInsystemから継承されており、PolicyRepositoryに含まれるポリシーアクションへのオブジェクト参照になるようにオーバーライドされています。Association Class PolicyActionInPolicyRepositoryの単一のインスタンスでは、このプロパティ（すべての参照プロパティと同様）が単一値であることに注意してください。[0..n]カーディナリティは、特定のPolicyRepositoryに0、1、または複数の政策が含まれている可能性があることを示しています。
The PolicyRepositoryInPolicyRepository aggregation enables policy repositories to be nested. This derives from the higher level CIM association, CIM_SystemComponent, describing that Systems contain other ManagedSystemElements. This superclass could not be used for the other Policy aggregations, since Policies are not ManagedSystemElements, but ManagedElements. Note that it is assumed that this aggregation is used to form directed acyclic graphs and NOT ring structures.
PolicyRepositoryInpolicyrepositoryの集約により、ポリシーリポジトリをネストすることができます。これは、システムが他のManagedsystemelementsに含まれていることを説明する、高レベルのCIM AssociationであるCIM_SystemComponentから派生しています。このスーパークラスは、他のポリシーの集計には使用できませんでした。これは、ポリシーは管理されたシステムセレメントではなく、マネージデリメントであるためです。この集合体は、指示された非環式グラフを形成し、リング構造ではなく形成するために使用されると想定されていることに注意してください。
The class definition for the aggregation is as follows:
集約のクラス定義は次のとおりです。
NAME PolicyRepositoryInPolicyRepository DESCRIPTION A class representing the aggregation of PolicyRepositories by a higher-level PolicyRepository. DERIVED FROM SystemComponent ABSTRACT FALSE PROPERTIES GroupComponent[ref PolicyRepository[0..n]] PartComponent[ref PolicyRepository[0..n]] 7.14.1. The Reference "GroupComponent"
名前PolicyRepositoryInpolicyrepository説明高レベルのPolicyRepositoryによるPolicyRepositoriesの集約を表すクラス。SystemComponent Abstractから導出されたFalse Propertiesグループコンポーネント[Ref PolicyRepository [0..N]] PartComponent [Ref PolicyRepository [0..N]] 7.14.1。参照「グループコンポーネント」
This property is inherited from the CIM class SystemComponent, and overridden to become an object reference to a PolicyRepository that contains one or more other PolicyRepositories. Note that for any single instance of the aggregation class PolicyRepositoryInPolicyRepository, this property (like all Reference properties) is single-valued. The [0..n] cardinality indicates that there may be 0, 1, or more than one PolicyRepositories that contain any given PolicyRepository.
このプロパティは、CIMクラスSystemComponentから継承されており、1つ以上の他のPolicyrepositoriesを含むPolicyRepositoryへのオブジェクト参照になります。集約クラスPolicyRepositoryInpolicyrepositoryの単一のインスタンスでは、このプロパティ（すべての参照プロパティと同様）が単一値であることに注意してください。[0..n]カーディナリティは、特定のPolicyRepositoryを含む0、1、または複数のPolicyRepositoriesがあることを示しています。
This property is inherited from the CIM class SystemComponent, and overridden to become an object reference to a PolicyRepository contained by one or more other PolicyRepositories. Note that for any single instance of the aggregation class PolicyRepositoryInPolicyRepository, this property (like all Reference properties) is single-valued. The [0..n] cardinality indicates that a given PolicyRepository may contain 0, 1, or more than one other PolicyRepositories.
このプロパティは、CIMクラスSystemComponentから継承されており、1つ以上の他のPolicyRepositoriesが含まれるPolicyRepositoryへのオブジェクト参照に過剰に記載されています。集約クラスPolicyRepositoryInpolicyrepositoryの単一のインスタンスでは、このプロパティ（すべての参照プロパティと同様）が単一値であることに注意してください。[0..n]カーディナリティは、特定のPolicyrepositoryが0、1、または他の複数のPolicyRepositoriesを含むことを示しています。
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エグゼクティブディレクターに宛ててください。
The Policy Core Information Model in this document is closely based on the work of the DMTF's Service Level Agreements working group, so thanks are due to the members of that working group. Several of the policy classes in this model first appeared in early drafts on IPSec policy and QoS policy. The authors of these drafts were Partha Bhattacharya, Rob Adams, William Dixon, Roy Pereira, Raju Rajan, Jean-Christophe Martin, Sanjay Kamat, Michael See, Rajiv Chaudhury, Dinesh Verma, George Powers, and Raj Yavatkar. Some other elements of the model originated in work done by Yoram Snir, Yoram Ramberg, and Ron Cohen. In addition, we would like to thank Harald Alvestrand for conducting a thorough review of this document and providing many helpful suggestions, and Luis Sanchez and Russ Mundy for their help with the document's Security Considerations.
このドキュメントのポリシーコア情報モデルは、DMTFのサービスレベル契約ワーキンググループの作業に密接に基づいているため、そのワーキンググループのメンバーに感謝します。このモデルのポリシークラスのいくつかは、IPSECポリシーとQoSポリシーに関する初期ドラフトに最初に登場しました。これらのドラフトの著者は、パルタ・バタチャリヤ、ロブ・アダムス、ウィリアム・ディクソン、ロイ・ペレイラ、ラジュ・ラジャン、ジャン・キリストフ・マーティン、サンジェイ・カマット、マイケル・シー、ラジフ・チョードゥリー、ダージフ・ヴェルマ、ジョージ・パワーズ、ラジ・ヤバトカルでした。モデルの他のいくつかの要素は、Yoram Snir、Yoram Ramberg、およびRon Cohenによって行われた作業に由来しました。さらに、この文書の徹底的なレビューを実施し、多くの有益な提案を提供してくれたHarald Alvestrandと、Luis SanchezとRuss Mundyが文書のセキュリティに関する考慮事項を支援してくれたことに感謝します。
The Policy Core Information Model (PCIM) presented in this document provides an object-oriented model for describing policy information. It provides a basic framework for describing the structure of policy information, in a form independent of any specific repository or access protocol, for use by an operational system. PCIM is not intended to represent any particular system design or implementation, nor does it define a protocol, and as such it does not have any specific security requirements.
このドキュメントで提示されたポリシーコア情報モデル（PCIM）は、ポリシー情報を説明するためのオブジェクト指向モデルを提供します。これは、運用システムで使用するために、特定のリポジトリまたはアクセスプロトコルに依存しない形式で、ポリシー情報の構造を説明するための基本的なフレームワークを提供します。PCIMは、特定のシステムの設計または実装を表すことも、プロトコルを定義することも、特定のセキュリティ要件がないためです。
However, it should also be noted that certain derivative documents, which use PCIM as a base, will need to convey more specific security considerations. In order to communicate the nature of what will be expected in these follow-on derivative documents, it is necessary to review the reasons that PCIM, as defined in this document, is neither implementable, nor representative of any real-world system, as well as the nature of the expected follow-on extensions and mappings.
ただし、PCIMをベースとして使用する特定のデリバティブドキュメントは、より具体的なセキュリティに関する考慮事項を伝える必要があることにも注意する必要があります。これらのフォローオンデリバティブドキュメントで予想されるものの性質を伝えるために、このドキュメントで定義されているPCIMが実装可能でも、現実世界のシステムの代表でもない理由を確認する必要があります。予想されるフォローオン拡張機能とマッピングの性質として。
There are three independent reasons that PCIM, as defined here, is neither implementable nor representative of any real-world system:
ここで定義されているように、PCIMが実装可能でも代表的でもない3つの独立した理由があります。
1. Its classes are independent of any specific repository that uses any specific access protocol. Therefore, its classes are designed not to be implemented directly. PCIM should instead be viewed as a schematic that directs how information should be represented, independent of any specific model implementation constraints.
1. そのクラスは、特定のアクセスプロトコルを使用する特定のリポジトリから独立しています。したがって、そのクラスは直接実装されないように設計されています。代わりに、PCIMは、特定のモデルの実装の制約とは無関係に、情報をどのように表現すべきかを指示する概略図と見なす必要があります。
2. Its classes were designed to be independent of any specific policy domain. For example, DiffServ and IPSec represent two different policy domains. Each document which extends PCIM to one of these domains will derive subclasses from the classes and relationships defined in PCIM, in order to represent extensions of a generic model to cover specific technical domains.
2. そのクラスは、特定のポリシードメインから独立するように設計されています。たとえば、diffservとipsecは2つの異なるポリシードメインを表します。PCIMをこれらのドメインのいずれかに拡張する各ドキュメントは、特定の技術ドメインをカバーする一般的なモデルの拡張を表すために、PCIMで定義されたクラスと関係からサブクラスを導き出します。
3. It's an information model, which must be mapped to a specific data model (native CIM schema, LDAP schema, MIB, whatever) before it can be implemented. Derivative documents will map the extended information models noted in item 2, above, to specific types of data model implementations.
3. これは、実装する前に特定のデータモデル（ネイティブCIMスキーマ、LDAPスキーマ、MIBなど）にマッピングする必要がある情報モデルです。デリバティブドキュメントは、上記の項目2に記載されている拡張情報モデルを、特定のタイプのデータモデルの実装にマッピングします。
Even though specific security requirements are not appropriate for PCIM, specific security requirements MUST be defined for each operational real- world application of PCIM. Just as there will be a wide range of operational, real-world systems using PCIM, there will also be a wide range of security requirements for these systems. Some operational, real-world systems that are deployed using PCIM may have extensive security requirements that impact nearly all classes and subclasses utilized by such a system, while other systems' security requirements might have very little impact.
特定のセキュリティ要件はPCIMには適していませんが、PCIMの運用上の現実世界アプリケーションごとに特定のセキュリティ要件を定義する必要があります。PCIMを使用して幅広い運用上の実世界のシステムがあるように、これらのシステムには幅広いセキュリティ要件もあります。PCIMを使用して展開されている運用上の現実世界のシステムには、そのようなシステムが利用するほぼすべてのクラスとサブクラスに影響を与える広範なセキュリティ要件がありますが、他のシステムのセキュリティ要件はほとんど影響を与えない可能性があります。
The derivative documents, discussed above, will create the context for applying operational, real-world, system-level security requirements against the various models which derive from PCIM.
上記のデリバティブドキュメントは、PCIMに由来するさまざまなモデルに対して、運用上の実世界のシステムレベルのセキュリティ要件を適用するためのコンテキストを作成します。
For example, in some real-world scenarios, the values associated with certain properties, within certain instantiated classes, may represent information associated with scarce, and/or costly (and therefore valuable) resources. It may be the case that these values must not be disclosed to, or manipulated by, unauthorized parties. As long as the derived model remains an information model (as opposed to a data model), it is not possible to discuss the data model-specific tools and mechanisms that are available for achieving the authentication and authorization implicit in a requirement that restricts read and/or read- write access to these values. Therefore, these mechanisms will need to be discussed in each of the data models to which the derived information models are mapped. If there are any general security requirements that can be identified and can be applied across multiple types of data models, it would be appropriate to discuss those at the information model level, rather than the data model level. In any case, any identified security requirements that are not dealt with in the information model document, MUST be dealt with in the derivative data model documents.
たとえば、いくつかの実際のシナリオでは、特定のインスタンス化されたクラス内の特定のプロパティに関連付けられた値は、希少および/または費用のかかる（したがって価値のある）リソースに関連する情報を表す場合があります。これらの値を不正な当事者に開示したり、操作したりしてはならない場合があります。派生モデルが（データモデルとは対照的に）情報モデルのままである限り、読み取りと読み取りを制限する要件で暗黙の認証と承認を達成するために利用可能なデータモデル固有のツールとメカニズムを議論することはできません。/または読み取り - これらの値への書き込みアクセス。したがって、これらのメカニズムは、派生情報モデルがマッピングされている各データモデルで議論する必要があります。特定できる一般的なセキュリティ要件があり、複数のタイプのデータモデルに適用できる一般的なセキュリティ要件がある場合、データモデルレベルではなく、情報モデルレベルでそれらを議論することが適切です。いずれにせよ、情報モデルドキュメントで扱われない特定されたセキュリティ要件は、デリバティブデータモデルドキュメントで扱う必要があります。
We can illustrate these points by extending the example from Section 2. A real-world system that provides QoS Gold Service to John would likely need to provide at least the following security-related capabilities and mechanisms (see [12] for definitions of security related terms):
セクション2から例を拡張することでこれらのポイントを説明できます。ジョンにQoSゴールドサービスを提供する現実世界のシステムは、少なくとも次のセキュリティ関連の機能とメカニズムを提供する必要があるでしょう（セキュリティ関連の定義については[12]を参照してください。条項）：
o Data integrity for the information (e.g., property values and instantiated relationships) that specify that John gets QoS Gold Service, from the point(s) that the information is entered into the system to the point(s) where network components actually provide that Service.
o JohnがQoSゴールドサービスを取得することを指定する情報（例：プロパティ値やインスタンス化された関係）のデータの整合性（情報がシステムに入力されたポイントから、ネットワークコンポーネントが実際にそのサービスを提供するポイントまで」。
o Authentication and Authorization methods to ensure that only system administrators (and not John or other engineers) can remotely administer components of the system.
o システム管理者のみがシステムのコンポーネントをリモートで管理できるようにするための認証および承認方法。
o An Authentication method to insure that John receives Gold Service, and the other members of the engineering group receive Bronze Service.
o ジョンがゴールドサービスを受け、エンジニアリンググループの他のメンバーがブロンズサービスを受けることを保証する認証方法。
These are one possible set of requirements associated with an example real-world system which delivers Gold Service, and the appropriate place to document these would be in some combination of the information model and the derivative data models for QoS Policy. Each of the data models would also need to discuss how these requirements are satisfied, using the mechanisms typically available to such a data model, given the particular technology or set of technologies which it may employ.
これらは、ゴールドサービスを提供する実世界システムの例に関連付けられた一連の要件の1つであり、これらを文書化するのに適切な場所は、QoSポリシーの情報モデルとデリバティブデータモデルの組み合わせになります。また、各データモデルは、特定のテクノロジーまたは採用されるテクノロジーのセットを考えると、このようなデータモデルが通常利用できるメカニズムを使用して、これらの要件がどのように満たされるかを議論する必要があります。
[1] Distributed Management Task Force, Inc., "DMTF Technologies: CIM Standards << CIM Schema: Version 2.4", available via links on the following DMTF web page: http://www.dmtf.org/spec/cim_schema_v24.html.
[1] 分散管理タスクフォース、Inc。、「DMTFテクノロジー：CIM標準<< CIMスキーマ：バージョン2.4」、次のDMTF Webページでリンクを介して入手可能：http：//www.dmtf.org/spec/cim_schema_v24.html。
[2] Distributed Management Task Force, Inc., "Common Information Model (CIM) Specification, version 2.2, June 1999. This document is available on the following DMTF web page: http://www.dmtf.org/spec/cims.html.
[2] 分散管理タスクフォース、「Common Information Model（CIM）仕様、バージョン2.2、1999年6月。このドキュメントは、次のDMTF Webページ（http://www.dmtf.org/spec/cims.html）で入手できます。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[4] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996.
[4] Hovey、R。およびS. Bradner、「IETF標準プロセスに関与する組織」、BCP 11、RFC 2028、1996年10月。
[5] J. Strassner and S. Judd, "Directory-Enabled Networks", version 3.0c5 (August 1998). A PDF file is available at http://www.murchiso.com/den/#denspec.
[5] J. StrassnerおよびS. Judd、「ディレクトリ対応ネットワーク」、バージョン3.0C5（1998年8月）。PDFファイルはhttp://www.murchiso.com/den/#denspecで入手できます。
[6] J. Strassner, policy architecture BOF presentation, 42nd IETF Meeting, Chicago, Illinois, October, 1998. Minutes of this BOF are available at the following location: http://www.ietf.org/proceedings/98aug/index.html.
[6] J. Strassner、ポリシーアーキテクチャBOFプレゼンテーション、第42回IETFミーティング、イリノイ州シカゴ、イリノイ州、1998年10月。
[7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[7] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、RFC 2279、1998年1月。
[8] Levi, D. and J. Schoenwaelder, "Definitions of Managed Objects for Scheduling Management Operations", RFC 2591, May 1999.
[8] Levi、D。およびJ. Schoenwaelder、「管理操作のための管理オブジェクトの定義」、RFC 2591、1999年5月。
[9] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000.
[9] Yavatkar、R.、Pendarakis、D。and R. Guerin、「政策ベースの入場管理の枠組み」、RFC 2753、2000年1月。
[10] Dawson, F. and D. Stenerson, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 2445, November 1998.
[10] Dawson、F。and D. Stenerson、「インターネットカレンダーとスケジューリングコアオブジェクト仕様（ICALENDAR）」、RFC 2445、1998年11月。
[11] Strassner, J., and E. Ellesson, B. Moore, R. Moats, "Policy Core LDAP Schema", Work in Progress.
[11] Strassner、J。、およびE. Ellesson、B。Moore、R。Moats、「ポリシーコアLDAPスキーマ」、進行中の作業。
[12] Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828, May 2000.
[12] Shirey、R。、「インターネットセキュリティ用語集」、FYI 36、RFC 2828、2000年5月。
Note: the CIM 2.4 Schema specification is defined by the following set of MOF files, available from the following URL:
注：CIM 2.4スキーマ仕様は、次のURLから入手できます。
http://www.dmtf.org/spec/CIM_Schema24/CIM_Schema24.zip
http://www.dmtf.org/spec/CIM_Schema24/CIM_Schema24.zip
Ed Ellesson LongBoard, Inc. 2505 Meridian Pkwy, #100 Durham, NC 27713
Ed Ellesson Longboard、Inc。2505 Meridian Pkwy、＃100 Durham、NC 27713
Phone: +1 919-361-3230
Fax: +1 919-361-3299
EMail: eellesson@lboard.com
Bob Moore IBM Corporation, BRQA/502 4205 S. Miami Blvd. Research Triangle Park, NC 27709
Bob Moore IBM Corporation、BRQA/502 4205 S. Miami Blvd.研究トライアングルパーク、ノースカロライナ州27709
Phone: +1 919-254-4436
Fax: +1 919-254-6243
EMail: remoore@us.ibm.com
John Strassner Cisco Systems, Bldg 15 170 West Tasman Drive San Jose, CA 95134
ジョン・ストラスナー・シスコ・システム、BLDG 15 170ウェスト・タスマン・ドライブ・サンノゼ、カリフォルニア95134
Phone: +1 408-527-1069
Fax: +1 408-527-6351
EMail: johns@cisco.com
Andrea Westerinen Cisco Systems 170 West Tasman Drive San Jose, CA 95134
Andrea Westerinen Cisco Systems 170 West Tasman Drive San Jose、CA 95134
Phone: +1 408-853-8294
Fax: +1 408-527-6351
EMail: andreaw@cisco.com
While the CommonName property is present in the abstract superclass Policy, and is thus available in all of its instantiable subclasses, CIM does not use this property for naming instances. The following subsections discuss how naming is handled in a native CIM implementation for each of the instantiable classes in the Policy Core Information Model.
CommonNameプロパティは抽象スーパークラスポリシーに存在するため、その瞬時可能なサブクラスのすべてで利用可能ですが、CIMはこのプロパティを命名に使用しません。次のサブセクションでは、ポリシーコア情報モデルのインスタンス可能なクラスごとにネイティブCIM実装で命名がどのように処理されるかについて説明します。
Two things should be noted regarding CIM naming:
CIMネーミングに関して2つのことに注意する必要があります。
o When a CIM association is specified as "weak", this is a statement about naming scopes: an instance of the class at the weak end of the association is named within the scope of an instance of the class at the other end of the association. This is accomplished by propagation of keys from the instance of the scoping class to the instance of the weak class. Thus the weak class has, via key propagation, all the keys from the scoping class, and it also has one or more additional keys for distinguishing instances of the weak class, within the context of the scoping class.
o CIMアソシエーションが「弱い」として指定されている場合、これはスコープの命名に関する声明です。協会の弱点でのクラスのインスタンスは、協会の反対側のクラスのインスタンスの範囲内で命名されます。これは、スコーピングクラスのインスタンスから弱いクラスのインスタンスへのキーの伝播によって達成されます。したがって、弱いクラスには、キー伝播を介してスコーピングクラスのすべてのキーがあり、スコーピングクラスのコンテキスト内で、弱いクラスのインスタンスを区別するための1つ以上の追加キーもあります。
o All class names in CIM are limited to alphabetic and numeric characters plus the underscore, with the restriction that the first character cannot be numeric. Refer to Appendix F "Unicode Usage" in reference [2] for an exact specification of how CIM class names are encoded in CIM strings.
o CIMのすべてのクラス名は、アルファベットと数値の文字とアンダースコアに限定されており、最初の文字が数値ではないという制限があります。CIMクラス名がCIM文字列でエンコードされる方法の正確な指定については、参照[2]の付録F「ユニコード使用」を参照してください。
A policy group always exists in the context of a system. In the Policy Core Information Model, this is captured by the weak aggregation PolicyGroupInSystem between a PolicyGroup and a System. Note that System serves as the base class for describing network devices and administrative domains.
ポリシーグループは常にシステムのコンテキストで存在します。ポリシーコア情報モデルでは、これはポリシーグループとシステム間の弱い集約ポリシーグループシステムによってキャプチャされます。システムは、ネットワークデバイスと管理ドメインを説明するための基本クラスとして機能することに注意してください。
A policy rule also exists in the context of a system. In the Policy Core Information Model, this is captured by the weak association PolicyRuleInSystem between a PolicyRule and a System.
システムのコンテキストにもポリシールールが存在します。ポリシーコア情報モデルでは、これはPolicyruleとシステムの間の弱い関連性Policyruleinsystemによってキャプチャされます。
The following sections define the CIM keys for PolicyGroup and PolicyRule.
次のセクションでは、ポリシーグループとPolicyruleのCIMキーを定義します。
The CIM keys of the PolicyGroup class are:
ポリシーグループクラスのCIMキーは次のとおりです。
o SystemCreationClassName (A CIM_System key, propagated due to the weak association, PolicyGroupInSystem)
o SystemCreationClassName（CIM_SYSTEMキー、弱い関連性、PolicyGroupInsystemのために伝播）
o SystemName (A CIM_System key, propagated due to the weak association, PolicyGroupInSystem) o CreationClassName o PolicyGroupName
o SystemName（CIM_SYSTEMキー、弱い関連性、PolicyGroupInsystemのために伝播する）o CreationClassName O PolicyGroupName
They are defined in Reference [1] as follows:
これらは参照[1]で次のように定義されています。
NAME SystemCreationClassName
DESCRIPTION SystemCreationClassName represents the class name of
the CIM System object providing the naming scope for
the instance of PolicyGroup.
SYNTAX string [MaxLen 256]
QUALIFIER key
NAME SystemName
DESCRIPTION SystemName represent the individual name of the
particular System object, providing the naming scope
for the instance of PolicyGroup.
SYNTAX string [MaxLen 256]
QUALIFIER key
NAME CreationClassName
DESCRIPTION This property is set to "CIM_PolicyGroup", if the
PolicyGroup object is directly instantiated. Or, it
is equal to the class name of the PolicyGroup
subclass that is instantiated.
SYNTAX string [MaxLen 256]
QUALIFIER key
NAME PolicyGroupName
DESCRIPTION The identifying name of this policy group.
SYNTAX string [MaxLen 256]
QUALIFIER key
The CIM keys of the PolicyRule class are:
PolicyRuleクラスのCIMキーは次のとおりです。
o SystemCreationClassName (A CIM_System key, propagated due to the weak association PolicyRuleInSystem) o SystemName (A CIM_System key, propagated due to the weak association PolicyRuleInSystem) o CreationClassName o PolicyRuleName
o SystemCreationClassName（CIM_SYSTEMキー、弱い関連付けPOLICYRULEINSYSTEMのために伝播）o SystemName（CIM_SYSTEMキー、弱い関連性PolicyRuleInsystemのために伝播）o CreationClassName o PolicyRuleName
SystemCreationClassName and SystemName work the same as defined for the class PolicyGroup. See Section 13.1.1 for details.
SystemCreationClassNameとSystemNameは、クラスポリシーグループで定義されたものと同じように動作します。詳細については、セクション13.1.1を参照してください。
The other two properties are defined in Reference [1] as follows:
他の2つのプロパティは、参照[1]で次のように定義されています。
NAME CreationClassName
DESCRIPTION This property is set to "CIM_PolicyRule", if the
PolicyRule object is directly instantiated. Or,
it is equal to the class name of the PolicyRule
subclass that is instantiated.
SYNTAX string [MaxLen 256]
QUALIFIER key
NAME PolicyRuleName
DESCRIPTION The identifying name of this policy rule.
SYNTAX string [MaxLen 256]
QUALIFIER key
The CIM keys of the PolicyCondition class are:
ポリシー条件クラスのCIMキーは次のとおりです。
o SystemCreationClassName o SystemName o PolicyRuleCreationClassName o PolicyRuleName o CreationClassName o PolicyConditionName
o SystemCreationClassName o SystemName o PolicyRuleCreationClassName o PolicyRulename o CreationClassName o PolicyConditionName
Note that none of the keys are defined as propagated, although they appear to fit this convention. The reason for this difference is because (as indicated in Sections 5.1 and 6.4) the PolicyCondition class is used to represent both reusable and rule-specific conditions. This, in turn, affects what associations are valid for an instance of PolicyCondition, and how that instance is named.
この慣習に合っているように見えるが、キーは伝播として定義されていないことに注意してください。この違いの理由は、（セクション5.1および6.4で示されているように）Policyconditionクラスが再利用可能な条件とルール固有の条件の両方を表すために使用されるためです。これは、PolicyConditionのインスタンスに対してどの関連付けが有効であるか、およびそのインスタンスの名前がどのように命名されるかに影響します。
In an ideal world, an instance of the PolicyCondition class would be scoped either by its PolicyRepository (for a reusable condition) or by its PolicyRule (for a rule-specific condition). However, CIM has the restriction that a given class can only be "weak" to one other class (i.e., defined by one weak association).
理想的な世界では、Policyconditionクラスのインスタンスは、そのPolicyRepository（再利用可能な状態の場合）またはPolicyrule（ルール固有の条件の場合）のいずれかによってスコープされます。ただし、CIMには、特定のクラスが他のクラスに対してしか「弱い」という制限があります（つまり、1つの弱い関連付けによって定義されます）。
To work within the restrictions of CIM naming, it is necessary to "simulate" weak associations between PolicyCondition and PolicyRule, and between PolicyCondition and PolicyRepository, through a technique we'll call manual key propagation. Strictly speaking, manual key propagation isn't key propagation at all. But it has the same effect as (true) key propagation, so the name fits.
CIMネーミングの制限内で動作するには、PolicyconditionとPolicyruleの間、およびPolicyconditionとPolicyrepositoryの間の弱い関連性を「シミュレート」する必要があります。厳密に言えば、手動の重要な伝播は重要な伝播ではありません。しかし、それは（真の）主要な伝播と同じ効果があるため、名前は適合します。
Figure 9 illustrates how manual propagation works in the case of PolicyCondition. (Note that only the key properties are shown for each of the classes.) In the figure, the line composed of 'I's indicates class inheritance, the one composed of 'P's indicates (true) key propagation via the weak aggregation PolicyRuleInSystem, and the ones composed of 'M's indicate manual key propagation.
図9は、Policyconditionの場合の手動伝播がどのように機能するかを示しています。（各クラスに重要なプロパティのみが表示されていることに注意してください。）図では、「Iはクラスの継承を示します」で構成されている行、「P」で構成されるものは、弱い凝集PolicyRuleinsystemを介した（真の）重要な伝播、および「M」で構成されるものは、手動のキー伝播を示しています。
+------------------+
| System |
+------------------+
|CreationClassName |
|Name |
+------------------+
^ P
I PPPPPPPPPPPPPPPPPPPPPPPPPPPP
I P
+------------------+ +---------------v--------------+
| AdminDomain | | PolicyRule |
+------------------+ +------------------------------+
|CreationClassName | | System.CreationClassName |
|Name | | System.Name |
+------------------+ | CreationClassName |
^ | PolicyRuleName |
I +------------------------------+
I M
I M
+------------------+ M
| PolicyRepository | M
+------------------+ M
|CreationClassName | M
|Name | M
+------------------+ M
M M
M M
M M
+----v-------------------v----+
| PolicyCondition |
+-----------------------------+
| SystemCreationClassName |
| SystemName |
| PolicyRuleCreationClassName |
| PolicyRuleName |
| CreationClassName |
| PolicyConditionName |
+-----------------------------+
Figure 9. Manual Key Propagation for Naming PolicyConditions
図9.ポリシーコンディションの命名のための手動の重要な伝播
Looking at Figure 9, we see that two key properties, CreationClassName and Name, are defined in the System class, and inherited by its subclasses AdminDomain and PolicyRepository. Since PolicyRule is weak to System, these two keys are propagated to it; it also has its own keys CreationClassName and PolicyRuleName.
図9を見ると、2つの重要なプロパティ、CreationClassNameと名前がシステムクラスで定義されており、サブクラスAdmindomainとPolicyRepositoryによって継承されていることがわかります。Policyruleはシステムにとって弱いため、これらの2つのキーはそれに伝播されます。また、独自のKeys CreationClassNameとPolicyRulenameもあります。
A similar approach, though not automatic, is used in "manual key propagation". Here is the approach for rule-specific and reusable PolicyConditions:
同様のアプローチは、自動ではありませんが、「マニュアルキー伝播」で使用されます。ルール固有の再利用可能な政策条件のアプローチは次のとおりです。
o The manual propagation of keys from PolicyRule to PolicyCondition involves copying the values of PolicyRule's four key properties into four similarly named key properties in PolicyCondition. From the point of view of the CIM specification language, the property SystemName in PolicyCondition is a completely new key property. However, the relationship to the Name property in System is defined in the description of SystemName.
o PolicyruleからPolicyconditionへのキーの手動伝播には、Policyruleの4つのキープロパティの値を、Policyconditionの4つの同様の名前のキープロパティにコピーすることが含まれます。CIM仕様言語の観点から見ると、Policy -Conditionのプロパティシステム名はまったく新しい重要なプロパティです。ただし、システム内の名前プロパティとの関係は、SystemNameの説明で定義されています。
o The manual propagation of keys from PolicyRepository to PolicyCondition works in exactly the same way for the first two key properties. However, since PolicyRepository doesn't include PolicyRule properties, the PolicyRuleCreationClassName and PolicyRuleName have no values. A special value, "No Rule", is assigned to both of these properties in this case, indicating that this instance of PolicyCondition is not named within the scope of any particular policy rule.
o PolicyRepositoryからPolicyconditionへのキーの手動伝播は、最初の2つのキープロパティでまったく同じ方法で機能します。ただし、PolicyRepositoryにはPolicyRuleプロパティが含まれていないため、PolicyruleCreationClassNameとPolicyRulenameには値がありません。この場合、これらのプロパティの両方に特別な価値が割り当てられており、このポリシーコンディショニングのインスタンスは特定のポリシールールの範囲内で命名されていないことを示しています。
The following section defines the specific CIM keys for PolicyCondition.
次のセクションでは、ポリシー条件の特定のCIMキーを定義します。
PolicyCondition's key properties are defined in Reference [1] as follows:
PolicyConditionの重要なプロパティは、参照[1]で次のように定義されています。
NAME SystemCreationClassName
DESCRIPTION SystemCreationClassName represents the class
name of the CIM System object providing the
naming scope for the instance of PolicyCondition.
For a rule-specific policy condition, this is the
type of system (e.g., the name of the class that
created this instance) in whose context the policy
rule is defined. For a reusable policy condition,
this is set to "CIM_PolicyRepository", if the
PolicyRepository object is directly instantiated.
Or, it is equal to the class name of the
PolicyRepository subclass that is instantiated.
SYNTAX string [MaxLen 256]
QUALIFIER key
NAME SystemName
DESCRIPTION The name of the System object in whose scope this
policy condition is defined. This property
completes the identification of the System object.
For a rule-specific policy condition, this is the
name of the instance of the system in whose
context the policy rule is defined. For a
reusable policy condition, this is name of the
instance of PolicyRepository that holds the policy
condition.
SYNTAX string [MaxLen 256]
QUALIFIER key
NAME PolicyRuleCreationClassName
DESCRIPTION For a rule-specific policy condition, this
property identifies the class name of the policy
rule instance, in whose scope this instance of
PolicyCondition exists. For a reusable policy
condition, this property is set to a special
value, "No Rule", indicating that this instance
of PolicyCondition is not unique to one policy
rule.
SYNTAX string [MaxLen 256]
QUALIFIER key
NAME PolicyRuleName
DESCRIPTION For a rule-specific policy condition,
PolicyRuleName completes the identification of
the PolicyRule object with which this condition
is associated. For a reusable policy condition,
a special value, "No Rule", is used to indicate
that this condition is reusable.
SYNTAX string [MaxLen 256]
QUALIFIER key
NAME CreationClassName
DESCRIPTION The class name of the PolicyCondition subclass
that is instantiated.
SYNTAX string [MaxLen 256]
QUALIFIER key
NAME PolicyConditionName
DESCRIPTION The identifying name of this policy condition.
SYNTAX string [MaxLen 256]
QUALIFIER key
From the point of view of naming, the PolicyAction class and its subclasses work exactly like the PolicyCondition class and its subclasses. See Section 13.2 and 13.2.1 for details.
ネーミングの観点から見ると、ポリシーコンディションクラスとそのサブクラスは、Policyconditionクラスやそのサブクラスとまったく同じように機能します。詳細については、セクション13.2および13.2.1を参照してください。
Specifically, the CIM keys of PolicyAction are:
具体的には、ポリシーのCIMキーは次のとおりです。
o SystemCreationClassName o SystemName o PolicyRuleCreationClassName o PolicyRuleName o CreationClassName o PolicyActionName
o SystemCreationClassName o SystemName o PolicyRuleCreationClassName o PolicyRulename o CreationClassName O PolicyActionName
They are defined in Reference [1] as follows:
これらは参照[1]で次のように定義されています。
NAME SystemCreationClassName
DESCRIPTION SystemCreationClassName represents the class name
of the CIM System object providing the naming
scope for the instance of PolicyAction. For a
rule-specific policy action, this is the type of
system (e.g., the name of the class that created
this instance) in whose context the policy rule
is defined. For a reusable policy action, this
is set to "CIM_PolicyRepository", if the
PolicyRepository object is directly instantiated.
Or, it is equal to the class name of the
PolicyRepository subclass that is instantiated.
SYNTAX string [MaxLen 256]
QUALIFIER key
NAME SystemName
DESCRIPTION The name of the System object in whose scope this
policy action is defined. This property completes
the identification of the System object. For a
rule-specific policy action, this is the name of
the instance of the system in whose context the
policy rule is defined. For a reusable policy
action, this is name of the instance of
PolicyRepository that holds the policy action.
SYNTAX string [MaxLen 256]
QUALIFIER key
NAME PolicyRuleCreationClassName
DESCRIPTION For a rule-specific policy action, this property
identifies the class name of the policy rule
instance, in whose scope this instance of
PolicyAction exists. For a reusable policy
action, this property is set to a special value,
"No Rule", indicating that this instance of
PolicyAction is not unique to one policy rule.
SYNTAX string [MaxLen 256]
QUALIFIER key
NAME PolicyRuleName
DESCRIPTION For a rule-specific policy action, PolicyRuleName
completes the identification of the PolicyRule
object with which this action is associated. For
a reusable policy action, a special value, "No
Rule", is used to indicate that this action is
reusable.
SYNTAX string [MaxLen 256]
QUALIFIER key
NAME CreationClassName
DESCRIPTION The class name of the PolicyAction subclass that is
instantiated.
SYNTAX string [MaxLen 256]
QUALIFIER key
NAME PolicyActionName
DESCRIPTION The identifying name of this policy action.
SYNTAX string [MaxLen 256]
QUALIFIER key
An instance of PolicyRepository is named by the two key properties CreationClassName and Name that it inherits from its superclass AdminDomain. These properties are actually defined in AdminDomain's superclass, System, and then inherited by AdminDomain.
PolicyRepositoryのインスタンスは、SuperClass Ammindomainから継承する2つの重要なプロパティCreationClassNameと名前によって命名されています。これらの特性は、実際にはAdmindomainのスーパークラスであるシステムで定義され、Admindomainによって継承されます。
For instances of PolicyRepository itself, the value of CreationClassName must be "CIM_PolicyRepository". (Recall that for readability the prefix "CIM_" has been omitted from all class names in this document). If a subclass of PolicyRepository (perhaps QosPolicyRepository) is defined and instantiated, then the class name "CIM_QosPolicyRepository" is used in CreationClassName.
PolicyRepository自体の場合、CreationClassNameの価値は「cim_policyrepository」でなければなりません。（読みやすさのために、このドキュメントのすべてのクラス名から接頭辞「CIM_」が省略されていることを思い出してください）。PolicyRepositoryのサブクラス（おそらくQospolicyrepository）が定義され、インスタンス化されている場合、クラス名「cim_qospolicyrepository」がCreationClassNameで使用されます。
The Name property simply completes the identification of the instance of PolicyRepository.
名前プロパティは、PolicyRepositoryのインスタンスの識別を単に完了します。
To provide for more flexibility in instance naming, CIM makes use of a property called CreationClassName. The idea of CreationClassName is to provide another dimension that can be used to avoid naming collisions, in the specific case of instances belonging to two different subclasses of a common superclass. An example will illustrate how CreationClassName works.
命名の柔軟性を高めるために、CIMはCreationClassNameと呼ばれるプロパティを使用します。CreationClassNameのアイデアは、共通のスーパークラスの2つの異なるサブクラスに属するインスタンスの特定の場合に、衝突の名前を避けるために使用できる別の次元を提供することです。例では、CreationClassNameの仕組みを示します。
Suppose we have instances of two different subclasses of PolicyCondition, FrameRelayPolicyCondition and BgpPolicyCondition, and that these instances apply to the same context. If we had only the single key property PolicyConditionName available for distinguishing the two instances, then a collision would result from naming both of the instances with the key value PCName = "PC-1". Thus policy administrators from widely different disciplines would have to coordinate their naming of PolicyConditions for this context.
Policycondition、Framerelaypolicycondition、およびBGppolicyconditionの2つの異なるサブクラスのインスタンスがあり、これらのインスタンスが同じコンテキストに適用されるとします。2つのインスタンスを区別できる単一のキープロパティPolicyConditionNameのみがある場合、衝突は、両方のインスタンスをキー値PCName = "PC-1"と名前を付けることから生じます。したがって、大きく異なる分野のポリシー管理者は、このコンテキストのために政策条件の命名を調整する必要があります。
With CreationClassName, collisions of this type can be eliminated, without requiring coordination among the policy administrators. The two instances can be distinguished by giving their CreationClassNames different values. One instance is now identified with the two keys
CreationClassNameを使用すると、ポリシー管理者間の調整を必要とせずに、このタイプの衝突を排除できます。2つのインスタンスは、CreationClassNamesに異なる値を与えることで区別できます。1つのインスタンスが2つのキーで識別されます
CreationClassName = "FrameRelayPolicyCondition" + PCName = "PC-1",
CreationClassName = "framerelaypolicycondition" pcname = "pc-1"、
while the other is identified with
一方、もう一方は識別されます
CreationClassName = "BgpPolicyCondition" + PCName = "PC-1".
creationClassName = "bgppolicycondition" pcname = "pc-1"。
Each of the instantiable classes in the Core Model includes the CreationClassName property as a key in addition to its own class-specific key property.
コアモデルのインスタンス可能なクラスのそれぞれには、独自のクラス固有のキープロパティに加えて、キーとしてCreationClassNameプロパティが含まれています。
Today, all CIM associations involve two object references. CIM decomposes an object reference into two parts: a high-order part that identifies an object manager and namespace, and a model path that identifies an object instance within a namespace. The model path, in turn, can be decomposed into an object class identifier and a set of key values needed to identify an instance of that class.
今日、すべてのCIMアソシエーションには2つのオブジェクト参照が含まれています。CIMは、オブジェクトの参照を2つの部分に分解します。オブジェクトマネージャーと名前空間を識別する高次部と、名前空間内のオブジェクトインスタンスを識別するモデルパスです。次に、モデルパスは、そのクラスのインスタンスを識別するために必要なオブジェクトクラス識別子と一連のキー値に分解できます。
Because the object class identifier is part of the model path, a CIM object reference is strongly typed. The GroupComponent object reference in the PolicyGroupInPolicyGroup association, for example, can only point to an instance of PolicyGroup, or to an instance of a subclass of PolicyGroup. Contrast this with LDAP, where a DN pointer is completely untyped: it identifies (by DN) an entry, but places no restriction on that entry's object class(es).
オブジェクトクラス識別子はモデルパスの一部であるため、CIMオブジェクト参照が強く入力されます。たとえば、PolicyGroupinPolicyGroup Associationのグループコンポーネントオブジェクトリファレンスは、ポリシーグループのインスタンス、またはポリシーグループのサブクラスのインスタンスのみを指すことができます。これをLDAPとは対照的に、DNポインターは完全に無タイプ化されていません。エントリを識別しますが、そのエントリのオブジェクトクラス（ES）に制限はありません。
An important difference between CIM property definitions and LDAP attribute type definitions was identified earlier in Section 6: while an LDAP attribute type definition has global scope, a CIM property definition applies only to the class in which it is defined. Thus properties having the same name in two different classes are free to have different data types. CIM takes advantage of this flexibility by allowing the data type of an object reference to be overridden in a subclass of the association class in which it was initially defined.
CIMプロパティ定義とLDAP属性タイプ定義の重要な違いは、セクション6の前半で特定されました。LDAP属性タイプ定義にはグローバルスコープがありますが、CIMプロパティ定義は定義されているクラスにのみ適用されます。したがって、2つの異なるクラスで同じ名前を持つプロパティは、異なるデータ型を自由に持つことができます。CIMは、オブジェクト参照のデータ型を最初に定義されていた協会クラスのサブクラスでオーバーライドできるようにすることにより、この柔軟性を活用します。
For example, the object reference GroupComponent is defined in the abstract aggregation class PolicyComponent to be a reference to an instance of the class Policy. This data type for GroupComponent is then overridden in subclasses of PolicyComponent. In PolicyGroupInPolicyGroup, for example, GroupComponent becomes a reference to an instance of PolicyGroup. But in PolicyConditionInPolicyRule it becomes a reference to an instance of PolicyRule. Of course there is not total freedom in this overriding of object references. In order to remain consistent with its abstract superclass, a subclass of PolicyComponent can only override GroupComponent to be a reference to a subclass of Policy. A Policy class is the generic context for the GroupComponent reference in PolicyComponent.
たとえば、オブジェクト参照グループコンポーネントは、クラスポリシーのインスタンスへの参照となるように、抽象集約クラスのポリシーコンポーネントで定義されます。グループコンポーネントのこのデータ型は、PolicyComponentのサブクラスでオーバーライドされます。たとえば、PolicyGroupinPolicyGroupでは、グループコンポーネントがポリシーグループのインスタンスへの参照になります。しかし、PolicyConditionInpolicyruleでは、Policyruleのインスタンスへの参照になります。もちろん、このオブジェクトの参照の最優先には完全な自由はありません。抽象的なスーパークラスと一致し続けるために、PolicyComponentのサブクラスは、グループコンポーネントをオーバーライドして、ポリシーのサブクラスへの参照としてのみオーバーライドできます。ポリシークラスは、PolicyComponentのグループコンポーネントリファレンスの一般的なコンテキストです。
// ==================================================================
// Title: Core Policy MOF Specification 2.4
// Filename: CIM_Policy24.MOF
// Version: 2.4
// Release: 0
// Description: The object classes below are listed in an order that
// avoids forward references. Required objects, defined
// by other working groups, are omitted.
// Date: 06/27/2000
// CIMCR516a - Rooted the model associations under Policy
// Component or PolicyInSystem. Corrected PolicyCondition/
// PolicyActionInPolicyRepository to subclass from
// PolicyInSystem (similar to Groups and Roles 'InSystem')
// ==================================================================
// Author: DMTF SLA (Service Level Agreement) Working Group
// ==================================================================
// Pragmas
// ==================================================================
#pragma Locale ("en-US")
// ==================================================================
// Policy
// ==================================================================
[Abstract, Description (
"An abstract class describing common properties of all "
"policy rule-related subclasses, such as PolicyGroup, Policy"
"Rule and PolicyCondition. All instances of policy rule-"
"related entities will be created from subclasses of CIM_"
"Policy. The exception to this statement is PolicyRepository "
"which is a type of CIM_System.")
]
class CIM_Policy : CIM_ManagedElement
{
[Description (
"A user-friendly name of this policy-related object.")
]
string CommonName;
[Description (
"An array of keywords for characterizing / categorizing "
"policy objects. Keywords are of one of two types: \n"
" o Keywords defined in this and other MOFs, or in DMTF "
" white papers. These keywords provide a vendor-"
" independent, installation-independent way of "
" characterizing policy objects. \n"
" o Installation-dependent keywords for characterizing "
" policy objects. Examples include 'Engineering', " " 'Billing', and 'Review in December 2000'. \n" "This MOF defines the following keywords: 'UNKNOWN', " "'CONFIGURATION', 'USAGE', 'SECURITY', 'SERVICE', " "'MOTIVATIONAL', 'INSTALLATION', and 'EVENT'. These " "concepts are self-explanatory and are further discussed " "in the SLA/Policy White Paper. One additional keyword " "is defined: 'POLICY'. The role of this keyword is to " "identify policy-related instances that may not be otherwise " "identifiable, in some implementations. The keyword 'POLICY' " "is NOT mutually exclusive of the other keywords " "specified above.") ] string PolicyKeywords []; };
「ポリシーオブジェクト。例には、「エンジニアリング」、「請求」、「2000年12月のレビュー」が含まれます。セキュリティ、「サービス」、「「動機付け」、「インストール」、および「イベント」。これらの「概念は自明であり、SLA/ポリシーのホワイトペーパーでさらに議論されています。定義：「ポリシー」。このキーワードの役割は、「「特定のポリシー関連のインスタンス」を「特定できない可能性のあるポリシー関連のインスタンスを特定する」ことです。「いくつかの実装」。キーワード「ポリシー」「他のキーワードは相互に排他的ではありません」」上記で指定されています。 "）]文字列PolicyKeyWords [];};
// ==================================================================
// PolicyComponent
// ==================================================================
[Association, Abstract, Aggregation, Description (
"CIM_PolicyComponent is a generic association used to "
"establish 'part of' relationships between the subclasses of "
"CIM_Policy. For example, the PolicyConditionInPolicyRule "
"association defines that PolicyConditions are part of a "
"PolicyRule.")
]
class CIM_PolicyComponent
{
[Aggregate, Key, Description (
"The parent Policy in the association.")
]
CIM_Policy REF GroupComponent;
[Key, Description (
"The child/part Policy in the association.")
]
CIM_Policy REF PartComponent;
};
// ==================================================================
// PolicyInSystem
// ==================================================================
[Association, Abstract, Description (
" CIM_PolicyInSystem is a generic association used to "
"establish dependency relationships between Policies and the "
"Systems that host them. These Systems may be ComputerSystems "
"where Policies are 'running' or they may be Policy"
"Repositories where Policies are stored. This relationship "
"is similar to the concept of CIM_Services being dependent "
"on CIM_Systems as defined by the HostedService "
"association. \n"
" Cardinality is Max(1) for the Antecedent/System "
"reference since Policies can only be hosted in at most one "
"System context. Some subclasses of the association will "
"further refine this definition to make the Policies Weak "
"to Systems. Other subclasses of PolicyInSystem will "
"define an optional hosting relationship. Examples of each "
"of these are the PolicyRuleInSystem and PolicyConditionIn"
"PolicyRepository associations, respectively.")
]
class CIM_PolicyInSystem : CIM_Dependency
{
[Override ("Antecedent"), Max (1), Description (
"The hosting System.")
]
CIM_System REF Antecedent;
[Override ("Dependent"), Description (
"The hosted Policy.")
]
CIM_Policy REF Dependent;
};
// ==================================================================
// PolicyGroup
// ==================================================================
[Description (
"A container for either a set of related PolicyGroups "
"or a set of related PolicyRules, but not both. Policy"
"Groups are defined and named relative to the CIM_System "
"which provides their context.")
]
class CIM_PolicyGroup : CIM_Policy
{
[Propagated("CIM_System.CreationClassName"),
Key, MaxLen (256),
Description ("The scoping System's CreationClassName.")
]
string SystemCreationClassName;
[Propagated("CIM_System.Name"),
Key, MaxLen (256),
Description ("The scoping System's Name.")
]
string SystemName;
[Key, MaxLen (256), Description (
"CreationClassName indicates the name of the class or the "
"subclass used in the creation of an instance. When used "
"with the other key properties of this class, this property "
"allows all instances of this class and its subclasses to "
"be uniquely identified.") ]
string CreationClassName;
[Key, MaxLen (256), Description (
"A user-friendly name of this PolicyGroup.")
]
string PolicyGroupName;
};
// ==================================================================
// PolicyGroupInPolicyGroup
// ==================================================================
[Association, Aggregation, Description (
"A relationship that aggregates one or more lower-level "
"PolicyGroups into a higher-level Group. A Policy"
"Group may aggregate either PolicyRules or other Policy"
"Groups, but not both.")
]
class CIM_PolicyGroupInPolicyGroup : CIM_PolicyComponent
{
[Override ("GroupComponent"), Aggregate, Description (
"A PolicyGroup that aggregates other Groups.")
]
CIM_PolicyGroup REF GroupComponent;
[Override ("PartComponent"), Description (
"A PolicyGroup aggregated by another Group.")
]
CIM_PolicyGroup REF PartComponent;
};
// ==================================================================
// PolicyGroupInSystem
// ==================================================================
[Association, Description (
"An association that links a PolicyGroup to the System "
"in whose scope the Group is defined.")
]
class CIM_PolicyGroupInSystem : CIM_PolicyInSystem
{
[Override ("Antecedent"), Min(1), Max(1), Description (
"The System in whose scope a PolicyGroup is defined.")
]
CIM_System REF Antecedent;
[Override ("Dependent"), Weak, Description (
"A PolicyGroup named within the scope of a System.")
]
CIM_PolicyGroup REF Dependent;
};
// ==================================================================
// PolicyRule
// ==================================================================
[Description (
" The central class for representing the 'If Condition then "
"Action' semantics associated with a policy rule. "
"A PolicyRule condition, in the most general sense, is "
"represented as either an ORed set of ANDed conditions "
"(Disjunctive Normal Form, or DNF) or an ANDed set of ORed "
"conditions (Conjunctive Normal Form, or CNF). Individual "
"conditions may either be negated (NOT C) or unnegated (C). "
"The actions specified by a PolicyRule are to be performed "
"if and only if the PolicyRule condition (whether it is "
"represented in DNF or CNF) evaluates to TRUE.\n\n"
" "
"The conditions and actions associated with a PolicyRule "
"are modeled, respectively, with subclasses of Policy"
"Condition and PolicyAction. These condition and action "
"objects are tied to instances of PolicyRule by the Policy"
"ConditionInPolicyRule and PolicyActionInPolicyRule "
"aggregations.\n\n"
" "
"A PolicyRule may also be associated with one or more policy "
"time periods, indicating the schedule according to which the "
"policy rule is active and inactive. In this case it is the "
"PolicyRuleValidityPeriod aggregation that provides this "
"linkage.\n\n"
" "
"The PolicyRule class uses the property ConditionListType, to "
"indicate whether the conditions for the rule are in DNF or "
"CNF. The PolicyConditionInPolicyRule aggregation contains "
"two additional properties to complete the representation of "
"the Rule's conditional expression. The first of these "
"properties is an integer to partition the referenced "
"PolicyConditions into one or more groups, and the second is a "
"Boolean to indicate whether a referenced Condition is "
"negated. An example shows how ConditionListType and these "
"two additional properties provide a unique representation "
"of a set of PolicyConditions in either DNF or CNF.\n\n"
" "
"Suppose we have a PolicyRule that aggregates five "
"PolicyConditions C1 through C5, with the following values "
"in the properties of the five PolicyConditionInPolicyRule "
"associations:\n"
" C1: GroupNumber = 1, ConditionNegated = FALSE\n "
" C2: GroupNumber = 1, ConditionNegated = TRUE\n "
" C3: GroupNumber = 1, ConditionNegated = FALSE\n "
" C4: GroupNumber = 2, ConditionNegated = FALSE\n "
" C5: GroupNumber = 2, ConditionNegated = FALSE\n\n "
" "
"If ConditionListType = DNF, then the overall condition for "
"the PolicyRule is:\n"
" (C1 AND (NOT C2) AND C3) OR (C4 AND C5)\n\n"
" "
"On the other hand, if ConditionListType = CNF, then the "
"overall condition for the PolicyRule is:\n"
" (C1 OR (NOT C2) OR C3) AND (C4 OR C5)\n\n"
" "
"In both cases, there is an unambiguous specification of "
"the overall condition that is tested to determine whether "
"to perform the PolicyActions associated with the PolicyRule.")
]
class CIM_PolicyRule : CIM_Policy
{
[Propagated("CIM_System.CreationClassName"),
Key, MaxLen (256),
Description ("The scoping System's CreationClassName.")
]
string SystemCreationClassName;
[Propagated("CIM_System.Name"),
Key, MaxLen (256),
Description ("The scoping System's Name.")
]
string SystemName;
[Key, MaxLen (256), Description (
"CreationClassName indicates the name of the class or the "
"subclass used in the creation of an instance. When used "
"with the other key properties of this class, this property "
"allows all instances of this class and its subclasses to "
"be uniquely identified.") ]
string CreationClassName;
[Key, MaxLen (256), Description (
"A user-friendly name of this PolicyRule.")
]
string PolicyRuleName;
[Description (
"Indicates whether this PolicyRule is administratively "
"enabled, administratively disabled, or enabled for "
"debug. When the property has the value 3 (\"enabledFor"
"Debug\"), the entity evaluating the PolicyConditions is "
"instructed to evaluate the conditions for the Rule, but not "
"to perform the actions if the PolicyConditions evaluate to "
"TRUE. This serves as a debug vehicle when attempting to "
"determine what policies would execute in a particular "
"scenario, without taking any actions to change state "
"during the debugging. The default value is 1
(\"enabled\")."),
ValueMap { "1", "2", "3" },
Values { "enabled", "disabled", "enabledForDebug" }
]
uint16 Enabled;
[Description (
"Indicates whether the list of PolicyConditions "
"associated with this PolicyRule is in disjunctive "
"normal form (DNF) or conjunctive normal form (CNF)."
"The default value is 1 (\"DNF\")."),
ValueMap { "1", "2" },
Values { "DNF", "CNF" }
]
uint16 ConditionListType;
[Description (
"A free-form string that can be used to provide "
"guidelines on how this PolicyRule should be used.")
]
string RuleUsage;
[Description (
"A non-negative integer for prioritizing this Policy"
"Rule relative to other Rules. A larger value "
"indicates a higher priority. The default value is 0.")
]
uint16 Priority;
[Description (
"A flag indicating that the evaluation of the Policy"
"Conditions and execution of PolicyActions (if the "
"Conditions evaluate to TRUE) is required. The "
"evaluation of a PolicyRule MUST be attempted if the "
"Mandatory property value is TRUE. If the Mandatory "
"property is FALSE, then the evaluation of the Rule "
"is 'best effort' and MAY be ignored.")
]
boolean Mandatory;
[Description (
"This property gives a policy administrator a way "
"of specifying how the ordering of the PolicyActions "
"associated with this PolicyRule is to be interpreted. "
"Three values are supported:\n"
" o mandatory(1): Do the actions in the indicated "
" order, or don't do them at all.\n"
" o recommended(2): Do the actions in the indicated "
" order if you can, but if you can't do them in this "
" order, do them in another order if you can.\n"
" o dontCare(3): Do them -- I don't care about the "
" order.\n"
"The default value is 3 (\"dontCare\")."),
ValueMap { "1", "2", "3" },
Values { "mandatory", "recommended", "dontCare" }
]
uint16 SequencedActions;
[Description (
"This property represents the roles and role combinations "
"associated with a PolicyRule. Each value represents one "
"role or role combination. Since this is a multi-valued "
"property, more than one role or combination can be associated "
"with a single policy rule. Each value is a string of the "
"form:\n"
" <RoleName>[&&<RoleName>]*\n"
"where the individual role names appear in alphabetical order "
"(according to the collating sequence for UCS-2).")
]
string PolicyRoles [];
};
// ==================================================================
// PolicyRuleInPolicyGroup
// ==================================================================
[Association, Aggregation, Description (
"A relationship that aggregates one or more PolicyRules "
"into a PolicyGroup. A PolicyGroup may aggregate either "
"PolicyRules or other PolicyGroups, but not both.")
]
class CIM_PolicyRuleInPolicyGroup : CIM_PolicyComponent
{
[Override ("GroupComponent"), Aggregate, Description (
"A PolicyGroup that aggregates one or more PolicyRules.")
]
CIM_PolicyGroup REF GroupComponent;
[Override ("PartComponent"), Description (
"A PolicyRule aggregated by a PolicyGroup.")
]
CIM_PolicyRule REF PartComponent;
};
// ==================================================================
// PolicyRuleInSystem
// ==================================================================
[Association, Description (
"An association that links a PolicyRule to the System "
"in whose scope the Rule is defined.")
]
class CIM_PolicyRuleInSystem : CIM_PolicyInSystem
{
[Override ("Antecedent"), Min(1), Max(1), Description (
"The System in whose scope a PolicyRule is defined.")
]
CIM_System REF Antecedent;
[Override ("Dependent"), Weak, Description (
"A PolicyRule named within the scope of a System.")
]
CIM_PolicyRule REF Dependent;
};
// ==================================================================
// PolicyRepository
// ==================================================================
[Description (
"A class representing an administratively defined "
"container for reusable policy-related information. "
"This class does not introduce any additional "
"properties beyond those in its superclass "
"AdminDomain. It does, however, participate in a "
"number of unique associations."
"\n\n"
"An instance of this class uses the NameFormat value"
"\"PolicyRepository\", which is defined in the AdminDomain"
"class.")
]
class CIM_PolicyRepository : CIM_AdminDomain
{
};
// ==================================================================
// PolicyRepositoryInPolicyRepository
// ==================================================================
[Association, Aggregation, Description (
"A relationship that aggregates one or more lower-level "
"PolicyRepositories into a higher-level Repository.")
]
class CIM_PolicyRepositoryInPolicyRepository : CIM_SystemComponent
{
[Override ("GroupComponent"), Aggregate, Description (
"A PolicyRepository that aggregates other Repositories.")
]
CIM_PolicyRepository REF GroupComponent;
[Override ("PartComponent"), Description (
"A PolicyRepository aggregated by another Repository.")
]
CIM_PolicyRepository REF PartComponent;
};
// ==================================================================
// PolicyCondition
// ==================================================================
[Abstract, Description (
"A class representing a rule-specific or reusable policy "
"condition to be evaluated in conjunction with a Policy"
"Rule. Since all operational details of a PolicyCondition "
"are provided in subclasses of this object, this class is "
"abstract.")
]
class CIM_PolicyCondition : CIM_Policy
{
[Key, MaxLen (256), Description (
" The name of the class or the subclass used in the "
"creation of the System object in whose scope this "
"PolicyCondition is defined.\n\n"
" "
"This property helps to identify the System object in "
"whose scope this instance of PolicyCondition exists. "
"For a rule-specific PolicyCondition, this is the System "
"in whose context the PolicyRule is defined. For a "
"reusable PolicyCondition, this is the instance of "
"PolicyRepository (which is a subclass of System) that "
"holds the Condition.\n\n"
" "
"Note that this property, and the analogous property "
"SystemName, do not represent propagated keys from an "
"instance of the class System. Instead, they are "
"properties defined in the context of this class, which "
"repeat the values from the instance of System to which "
"this PolicyCondition is related, either directly via the "
"PolicyConditionInPolicyRepository aggregation or indirectly "
"via the PolicyConditionInPolicyRule aggregation.")
]
string SystemCreationClassName;
[Key, MaxLen (256), Description (
" The name of the System object in whose scope this "
"PolicyCondition is defined.\n\n"
" "
"This property completes the identification of the System "
"object in whose scope this instance of PolicyCondition "
"exists. For a rule-specific PolicyCondition, this is the "
"System in whose context the PolicyRule is defined. For a "
"reusable PolicyCondition, this is the instance of "
"PolicyRepository (which is a subclass of System) that "
"holds the Condition.")
]
string SystemName;
[Key, MaxLen (256), Description (
"For a rule-specific PolicyCondition, the "
"CreationClassName of the PolicyRule object with which "
"this Condition is associated. For a reusable Policy"
"Condition, a special value, 'NO RULE', should be used to "
"indicate that this Condition is reusable and not "
"associated with a single PolicyRule.")
]
string PolicyRuleCreationClassName;
[Key, MaxLen (256), Description (
"For a rule-specific PolicyCondition, the name of "
"the PolicyRule object with which this Condition is "
"associated. For a reusable PolicyCondition, a "
"special value, 'NO RULE', should be used to indicate "
"that this Condition is reusable and not associated "
"with a single PolicyRule.")
]
string PolicyRuleName;
[Key, MaxLen (256), Description (
"CreationClassName indicates the name of the class or the "
"subclass used in the creation of an instance. When used "
"with the other key properties of this class, this property "
"allows all instances of this class and its subclasses to "
"be uniquely identified.") ]
string CreationClassName;
[Key, MaxLen (256), Description (
"A user-friendly name of this PolicyCondition.")
]
string PolicyConditionName;
};
// ==================================================================
// PolicyConditionInPolicyRule
// ==================================================================
[Association, Aggregation, Description (
" A PolicyRule aggregates zero or more instances of the "
"PolicyCondition class, via the PolicyConditionInPolicyRule "
"association. A Rule that aggregates zero Conditions is not "
"valid -- it may, however, be in the process of being entered "
"into a PolicyRepository or being defined for a System. Note "
"that a PolicyRule should have no effect until it is valid.\n\n"
" "
"The Conditions aggregated by a PolicyRule are grouped into "
"two levels of lists: either an ORed set of ANDed sets of "
"conditions (DNF, the default) or an ANDed set of ORed sets "
"of conditions (CNF). Individual PolicyConditions in these "
"lists may be negated. The property ConditionListType "
"specifies which of these two grouping schemes applies to a "
"particular PolicyRule.\n\n"
" "
"In either case, PolicyConditions are used to determine whether "
"to perform the PolicyActions associated with the
PolicyRule.\n\n"
" "
"One or more PolicyTimePeriodConditions may be among the "
"conditions associated with a PolicyRule via the Policy"
"ConditionInPolicyRule association. In this case, the time "
"periods are simply additional Conditions to be evaluated "
"along with any others that are specified for the Rule. ")
]
class CIM_PolicyConditionInPolicyRule : CIM_PolicyComponent
{
[Override ("GroupComponent"), Aggregate, Description (
"This property represents the PolicyRule that "
"contains one or more PolicyConditions.")
]
CIM_PolicyRule REF GroupComponent;
[Override ("PartComponent"), Description (
"This property holds the name of a PolicyCondition "
"contained by one or more PolicyRules.")
]
CIM_PolicyCondition REF PartComponent;
[Description (
"Unsigned integer indicating the group to which the "
"PolicyCondition identified by the ContainedCondition "
"property belongs. This integer segments the Conditions "
"into the ANDed sets (when the ConditionListType is "
"\"DNF\") or similarly the ORed sets (when the Condition"
"ListType is \"CNF\") that are then evaluated.")
]
uint16 GroupNumber;
[Description (
"Indication of whether the Condition identified by "
"the ContainedCondition property is negated. TRUE "
"indicates that the PolicyCondition IS negated, FALSE "
"indicates that it IS NOT negated.")
]
boolean ConditionNegated;
};
// ==================================================================
// PolicyConditionInPolicyRepository
// ==================================================================
[Association, Description (
" A class representing the hosting of reusable "
"PolicyConditions by a PolicyRepository. A reusable Policy"
"Condition is always related to a single PolicyRepository, "
"via this aggregation.\n\n"
" "
"Note, that an instance of PolicyCondition can be either "
"reusable or rule-specific. When the Condition is rule-"
"specific, it shall not be related to any "
"PolicyRepository via the PolicyConditionInPolicyRepository "
"aggregation.")
]
class CIM_PolicyConditionInPolicyRepository : CIM_PolicyInSystem
{
[Override ("Antecedent"), Max(1), Description (
"This property identifies a PolicyRepository "
"hosting one or more PolicyConditions. A reusable "
"PolicyCondition is always related to exactly one "
"PolicyRepository via the PolicyConditionInPolicyRepository "
"aggregation. The [0..1] cardinality for this property "
"covers the two types of PolicyConditions: 0 for a "
"rule-specific PolicyCondition, 1 for a reusable one.")
]
CIM_PolicyRepository REF Antecedent;
[Override ("Dependent"), Description (
"This property holds the name of a PolicyCondition"
"hosted in the PolicyRepository. ")
]
CIM_PolicyCondition REF Dependent;
};
// ==================================================================
// PolicyTimePeriodCondition
// ==================================================================
[Description (
" This class provides a means of representing the time "
"periods during which a PolicyRule is valid, i.e., active. "
"At all times that fall outside these time periods, the "
"PolicyRule has no effect. A Rule is treated as valid "
"at ALL times, if it does not specify a "
"PolicyTimePeriodCondition.\n\n"
" "
"In some cases a Policy Consumer may need to perform "
"certain setup / cleanup actions when a PolicyRule becomes "
"active / inactive. For example, sessions that were "
"established while a Rule was active might need to "
"be taken down when the Rule becomes inactive. In other "
"cases, however, such sessions might be left up. In this "
"case, the effect of deactivating the PolicyRule would "
"just be to prevent the establishment of new sessions. \n\n"
" "
"Setup / cleanup behaviors on validity period "
"transitions are not currently addressed by the Policy " "Model, and must be specified in 'guideline' documents or " "via subclasses of CIM_PolicyRule, CIM_PolicyTimePeriod" "Condition or other concrete subclasses of CIM_Policy. If " "such behaviors need to be under the control of the policy " "administrator, then a mechanism to allow this control " "must also be specified in the subclasses.\n\n" " " "PolicyTimePeriodCondition is defined as a subclass of " "PolicyCondition. This is to allow the inclusion of " "time-based criteria in the AND/OR condition definitions " "for a PolicyRule.\n\n" " " "Instances of this class may have up to five properties " "identifying time periods at different levels. The values " "of all the properties present in an instance are ANDed " "together to determine the validity period(s) for the " "instance. For example, an instance with an overall " "validity range of January 1, 2000 through December 31, " "2000; a month mask that selects March and April; a " "day-of-the-week mask that selects Fridays; and a time " "of day range of 0800 through 1600 would be represented " "using the following time periods:\n" " Friday, March 5, 2000, from 0800 through 1600;\n " " Friday, March 12, 2000, from 0800 through 1600;\n " " Friday, March 19, 2000, from 0800 through 1600;\n " " Friday, March 26, 2000, from 0800 through 1600;\n " " Friday, April 2, 2000, from 0800 through 1600;\n " " Friday, April 9, 2000, from 0800 through 1600;\n " " Friday, April 16, 2000, from 0800 through 1600;\n " " Friday, April 23, 2000, from 0800 through 1600;\n " " Friday, April 30, 2000, from 0800 through 1600.\n\n" " " "Properties not present in an instance of " "PolicyTimePeriodCondition are implicitly treated as having " "their value 'always enabled'. Thus, in the example above, " "the day-of-the-month mask is not present, and so the " "validity period for the instance implicitly includes a " "day-of-the-month mask that selects all days of the month. " "If this 'missing property' rule is applied to its fullest, we " "see that there is a second way to indicate that a Policy" "Rule is always enabled: associate with it an instance of " "PolicyTimePeriodCondition whose only properties with " "specific values are its key properties.") ] class CIM_PolicyTimePeriodCondition : CIM_PolicyCondition { [Description (
「トランジションは現在ポリシーによって対処されていない」「モデルでは扱われておらず、cim_policyrule、cim_policytimeperiod」 "cim_policyの他のコンクリートサブクレースの「ガイドライン」ドキュメントまたは「」で指定する必要があります。ポリシーの制御 ""管理者、次にこの制御を許可するメカニズムもサブクラスで指定する必要があります。Policyruleに「および/または条件定義に時間ベースの基準」を含める。\ n \ n "" ""このクラスのインスタンスは、最大5つのプロパティ ""異なるレベルでの期間を識別します。""インスタンスに存在するすべてのプロパティの中で、「 ""インスタンスの妥当性期間を決定するために一緒になっています。たとえば、2000年1月1日から12月31日までの全体的な「有効性範囲のインスタンス」"" 2000; 3月と4月を選択する月のマスク。2000年3月5日金曜日、2000年から1600年3月5日まで、次の期間を使用して、0800〜1600の日範囲の時間を表します。2000年から2000年3月19日金曜日、2000年から1600年まで金曜日、2000年3月26日金曜日、2000年3月26日、2000年から1600年まで、2000年4月2日金曜日、0800から0800年から\ n ""1600; \ n "" 2000年4月9日金曜日、2000年から1600年まで、\ n "" 2000年4月16日金曜日、0800年から1600年まで、\ n "" 2000年4月23日金曜日、0800年から1600年まで; \ n "" 2000年4月30日金曜日、0800年から1600年まで。したがって、上記の例では、 ""月のマスクは存在しないため、インスタンスの「」の有効期間には、すべての日を選択する月のマスクを暗黙的に含む。月。「「この「不動産」ルールが最大限に適用されている場合、「ポリシー」ルールが常に有効になっていることを示す2番目の方法があることを確認します。""特定の値はその重要なプロパティです。 "）]クラスcim_policytimeperiodcondition：cim_policycondition {[description（
" This property identifies an overall range of calendar "
"dates and times over which a PolicyRule is valid. It is "
"formatted as a string representing a start date and time, "
"in which the character 'T' indicates the beginning of the "
"time portion, followed by the solidus character '/', "
"followed by a similar string representing an end date and "
"time. The first date indicates the beginning of the range, "
"while the second date indicates the end. Thus, the second "
"date and time must be later than the first. Date/times are "
"expressed as substrings of the form yyyymmddThhmmss. For "
"example: \n"
" 20000101T080000/20000131T120000 defines \n"
" January 1, 2000, 0800 through January 31, 2000, noon\n\n"
" "
"There are also two special cases in which one of the "
"date/time strings is replaced with a special string defined "
"in RFC 2445.\n "
" o If the first date/time is replaced with the string "
" 'THISANDPRIOR', then the property indicates that a "
" PolicyRule is valid [from now] until the date/time "
" that appears after the '/'.\n"
" o If the second date/time is replaced with the string "
" 'THISANDFUTURE', then the property indicates that a "
" PolicyRule becomes valid on the date/time that "
" appears before the '/', and remains valid from that "
" point on. "),
ModelCorrespondence {
"CIM_PolicyTimePeriodCondition.MonthOfYearMask",
"CIM_PolicyTimePeriodCondition.DayOfMonthMask",
"CIM_PolicyTimePeriodCondition.DayOfWeekMask",
"CIM_PolicyTimePeriodCondition.TimeOfDayMask",
"CIM_PolicyTimePeriodCondition.LocalOrUtcTime"}
]
string TimePeriod;
[Octetstring, Description (
" The purpose of this property is to refine the valid time "
"period that is defined by the TimePeriod property, by "
"explicitly specifying in which months the PolicyRule is "
"valid. These properties work together, with the "
"TimePeriod used to specify the overall time period in "
"which the PolicyRule is valid, and the MonthOfYearMask used "
"to pick out the months during which the Rule is valid.\n\n"
" "
"This property is formatted as an octet string, structured "
"as follows:\n"
" o a 4-octet length field, indicating the length of the "
" entire octet string; this field is always set to "
" 0x00000006 for this property;\n"
" o a 2-octet field consisting of 12 bits identifying the "
" 12 months of the year, beginning with January and "
" ending with December, followed by 4 bits that are "
" always set to '0'. For each month, the value '1' "
" indicates that the policy is valid for that month, "
" and the value '0' indicates that it is not valid.\n\n"
" "
"The value 0x000000060830, for example, indicates that a "
"PolicyRule is valid only in the months May, November, "
"and December.\n\n"
" "
"If a value for this property is not provided, then the "
"PolicyRule is treated as valid for all twelve months, and "
"only restricted by its TimePeriod property value and the "
"other Mask properties."),
ModelCorrespondence {
"CIM_PolicyTimePeriodCondition.TimePeriod",
"CIM_PolicyTimePeriodCondition.LocalOrUtcTime"}
]
uint8 MonthOfYearMask[];
[Octetstring, Description (
" The purpose of this property is to refine the valid time "
"period that is defined by the TimePeriod property, by "
"explicitly specifying in which days of the month the Policy"
"Rule is valid. These properties work together, "
"with the TimePeriod used to specify the overall time period "
"in which the PolicyRule is valid, and the DayOfMonthMask used "
"to pick out the days of the month during which the Rule "
"is valid.\n\n "
" "
"This property is formatted as an octet string, structured "
"as follows:\n"
" o a 4-octet length field, indicating the length of the "
" entire octet string; this field is always set to "
" 0x0000000C for this property; \n"
" o an 8-octet field consisting of 31 bits identifying "
" the days of the month counting from the beginning, "
" followed by 31 more bits identifying the days of the "
" month counting from the end, followed by 2 bits that "
" are always set to '0'. For each day, the value '1' "
" indicates that the policy is valid for that day, and "
" the value '0' indicates that it is not valid. \n\n"
" "
"The value 0x0000000C8000000100000000, for example, "
"indicates that a PolicyRule is valid on the first and "
"last days of the month.\n\n "
" "
"For months with fewer than 31 days, the digits corresponding "
"to days that the months do not have (counting in both "
"directions) are ignored.\n\n"
" "
"If a value for this property is not provided, then the "
"PolicyRule is treated as valid for all days of the month, and "
"only restricted by its TimePeriod property value and the "
"other Mask properties."),
ModelCorrespondence {
"CIM_PolicyTimePeriodCondition.TimePeriod",
"CIM_PolicyTimePeriodCondition.LocalOrUtcTime"}
]
uint8 DayOfMonthMask[];
[Octetstring, Description (
" The purpose of this property is to refine the valid time "
"period that is defined by the TimePeriod property, by "
"explicitly specifying in which days of the month the Policy"
"Rule is valid. These properties work together, "
"with the TimePeriod used to specify the overall time period "
"in which the PolicyRule is valid, and the DayOfWeekMask used "
"to pick out the days of the week during which the Rule "
"is valid.\n\n "
" "
"This property is formatted as an octet string, structured "
"as follows:\n "
" o a 4-octet length field, indicating the length of the "
" entire octet string; this field is always set to "
" 0x00000005 for this property;\n"
" o a 1-octet field consisting of 7 bits identifying the 7 "
" days of the week, beginning with Sunday and ending with "
" Saturday, followed by 1 bit that is always set to '0'. "
" For each day of the week, the value '1' indicates that "
" the policy is valid for that day, and the value '0' "
" indicates that it is not valid. \n\n"
" "
"The value 0x000000057C, for example, indicates that a "
"PolicyRule is valid Monday through Friday.\n\n"
" "
"If a value for this property is not provided, then the "
"PolicyRule is treated as valid for all days of the week, "
"and only restricted by its TimePeriod property value and "
"the other Mask properties."),
ModelCorrespondence {
"CIM_PolicyTimePeriodCondition.TimePeriod",
"CIM_PolicyTimePeriodCondition.LocalOrUtcTime"}
]
uint8 DayOfWeekMask[];
[Description (
" The purpose of this property is to refine the valid time "
"period that is defined by the TimePeriod property, by "
"explicitly specifying a range of times in a day during which "
"the PolicyRule is valid. These properties work "
"together, with the TimePeriod used to specify the overall "
"time period in which the PolicyRule is valid, and the "
"TimeOfDayMask used to pick out the range of time periods "
"in a given day of during which the Rule is valid. \n\n"
" "
"This property is formatted in the style of RFC 2445: a "
"time string beginning with the character 'T', followed by "
"the solidus character '/', followed by a second time string. "
"The first time indicates the beginning of the range, while "
"the second time indicates the end. Times are expressed as "
"substrings of the form 'Thhmmss'. \n\n"
" "
"The second substring always identifies a later time than "
"the first substring. To allow for ranges that span "
"midnight, however, the value of the second string may be "
"smaller than the value of the first substring. Thus, "
"'T080000/T210000' identifies the range from 0800 until 2100, "
"while 'T210000/T080000' identifies the range from 2100 until "
"0800 of the following day. \n\n"
" "
"When a range spans midnight, it by definition includes "
"parts of two successive days. When one of these days is "
"also selected by either the MonthOfYearMask, "
"DayOfMonthMask, and/or DayOfWeekMask, but the other day is "
"not, then the policy is active only during the portion of "
"the range that falls on the selected day. For example, if "
"the range extends from 2100 until 0800, and the day of "
"week mask selects Monday and Tuesday, then the policy is "
"active during the following three intervals:\n"
" From midnight Sunday until 0800 Monday; \n"
" From 2100 Monday until 0800 Tuesday; \n"
" From 2100 Tuesday until 23:59:59 Tuesday. \n\n"
" "
"If a value for this property is not provided, then the "
"PolicyRule is treated as valid for all hours of the day, "
"and only restricted by its TimePeriod property value and "
"the other Mask properties."),
ModelCorrespondence {
"CIM_PolicyTimePeriodCondition.TimePeriod",
"CIM_PolicyTimePeriodCondition.LocalOrUtcTime"}
]
string TimeOfDayMask;
[Description (
" This property indicates whether the times represented "
"in the TimePeriod property and in the various Mask "
"properties represent local times or UTC times. There is "
"no provision for mixing of local times and UTC times: the "
"value of this property applies to all of the other "
"time-related properties."),
ValueMap { "1", "2" },
Values { "localTime", "utcTime" },
ModelCorrespondence {
"CIM_PolicyTimePeriodCondition.TimePeriod",
"CIM_PolicyTimePeriodCondition.MonthOfYearMask",
"CIM_PolicyTimePeriodCondition.DayOfMonthMask",
"CIM_PolicyTimePeriodCondition.DayOfWeekMask",
"CIM_PolicyTimePeriodCondition.TimeOfDayMask"}
]
uint16 LocalOrUtcTime;
};
// ==================================================================
// PolicyRuleValidityPeriod
// ==================================================================
[Association, Aggregation, Description (
"The PolicyRuleValidityPeriod aggregation represents "
"scheduled activation and deactivation of a PolicyRule. "
"If a PolicyRule is associated with multiple policy time "
"periods via this association, then the Rule is active if "
"at least one of the time periods indicates that it is "
"active. (In other words, the PolicyTimePeriodConditions "
"are ORed to determine whether the Rule is active.) A Time"
"Period may be aggregated by multiple PolicyRules. A Rule "
"that does not point to a PolicyTimePeriodCondition via this "
"association is, from the point of view of scheduling, "
"always active. It may, however, be inactive for other "
"reasons. For example, the Rule's Enabled property may "
"be set to \"disabled\" (value=2).")
]
class CIM_PolicyRuleValidityPeriod : CIM_PolicyComponent
{
[Override ("GroupComponent"), Aggregate, Description (
"This property contains the name of a PolicyRule that "
"contains one or more PolicyTimePeriodConditions.")
]
CIM_PolicyRule REF GroupComponent;
[Override ("PartComponent"), Description (
"This property contains the name of a "
"PolicyTimePeriodCondition defining the valid time periods "
"for one or more PolicyRules.")
]
CIM_PolicyTimePeriodCondition REF PartComponent;
};
// ==================================================================
// VendorPolicyCondition
// ==================================================================
[Description (
" A class that provides a general extension mechanism for "
"representing PolicyConditions that have not been modeled "
"with specific properties. Instead, the two properties "
"Constraint and ConstraintEncoding are used to define the "
"content and format of the Condition, as explained below.\n\n"
" "
"As its name suggests, VendorPolicyCondition is intended for "
"vendor-specific extensions to the Policy Core Information "
"Model. Standardized extensions are not expected to use "
"this class.")
]
class CIM_VendorPolicyCondition : CIM_PolicyCondition
{
[Octetstring, Description (
"This property provides a general extension mechanism for "
"representing PolicyConditions that have not been "
"modeled with specific properties. The format of the "
"octet strings in the array is left unspecified in "
"this definition. It is determined by the OID value "
"stored in the property ConstraintEncoding. Since "
"ConstraintEncoding is single-valued, all the values of "
"Constraint share the same format and semantics."),
ModelCorrespondence {
"CIM_VendorPolicyCondition.ConstraintEncoding"}
]
string Constraint [];
[Description (
"An OID encoded as a string, identifying the format "
"and semantics for this instance's Constraint property."),
ModelCorrespondence {
"CIM_VendorPolicyCondition.Constraint"}
]
string ConstraintEncoding;
};
// ==================================================================
// PolicyAction
// ==================================================================
[Abstract, Description (
"A class representing a rule-specific or reusable policy "
"action to be performed if the PolicyConditions for a Policy"
"Rule evaluate to TRUE. Since all operational details of a "
"PolicyAction are provided in subclasses of this object, "
"this class is abstract.")
]
class CIM_PolicyAction : CIM_Policy
{
[Key, MaxLen (256), Description (
" The name of the class or the subclass used in the "
"creation of the System object in whose scope this "
"PolicyAction is defined. \n\n"
" "
"This property helps to identify the System object in "
"whose scope this instance of PolicyAction exists. "
"For a rule-specific PolicyAction, this is the System "
"in whose context the PolicyRule is defined. For a "
"reusable PolicyAction, this is the instance of "
"PolicyRepository (which is a subclass of System) that "
"holds the Action. \n\n"
" "
"Note that this property, and the analogous property "
"SystemName, do not represent propagated keys from an "
"instance of the class System. Instead, they are "
"properties defined in the context of this class, which "
"repeat the values from the instance of System to which "
"this PolicyAction is related, either directly via the "
"PolicyActionInPolicyRepository aggregation or indirectly "
"via the PolicyActionInPolicyRule aggregation.")
]
string SystemCreationClassName;
[Key, MaxLen (256), Description (
" The name of the System object in whose scope this "
"PolicyAction is defined. \n\n"
" "
"This property completes the identification of the System "
"object in whose scope this instance of PolicyAction "
"exists. For a rule-specific PolicyAction, this is the "
"System in whose context the PolicyRule is defined. For "
"a reusable PolicyAction, this is the instance of "
"PolicyRepository (which is a subclass of System) that "
"holds the Action.")
]
string SystemName;
[Key, MaxLen (256), Description (
"For a rule-specific PolicyAction, the CreationClassName "
"of the PolicyRule object with which this Action is "
"associated. For a reusable PolicyAction, a "
"special value, 'NO RULE', should be used to "
"indicate that this Action is reusable and not "
"associated with a single PolicyRule.")
]
string PolicyRuleCreationClassName;
[Key, MaxLen (256), Description (
"For a rule-specific PolicyAction, the name of "
"the PolicyRule object with which this Action is "
"associated. For a reusable PolicyAction, a "
"special value, 'NO RULE', should be used to "
"indicate that this Action is reusable and not "
"associated with a single PolicyRule.")
]
string PolicyRuleName;
[Key, MaxLen (256), Description (
"CreationClassName indicates the name of the class or the "
"subclass used in the creation of an instance. When used "
"with the other key properties of this class, this property "
"allows all instances of this class and its subclasses to "
"be uniquely identified.") ]
string CreationClassName;
[Key, MaxLen (256), Description (
"A user-friendly name of this PolicyAction.")
]
string PolicyActionName;
};
// ==================================================================
// PolicyActionInPolicyRepository
// ==================================================================
[Association, Description (
" A class representing the hosting of reusable "
"PolicyActions by a PolicyRepository. A reusable Policy"
"Action is always related to a single PolicyRepository, "
"via this aggregation.\n\n"
" "
"Note, that an instance of PolicyAction can be either "
"reusable or rule-specific. When the Action is rule-"
"specific, it shall not be related to any "
"PolicyRepository via the PolicyActionInPolicyRepository "
"aggregation.")
]
class CIM_PolicyActionInPolicyRepository : CIM_PolicyInSystem
{
[Override ("Antecedent"), Max(1), Description (
"This property represents a PolicyRepository "
"hosting one or more PolicyActions. A reusable "
"PolicyAction is always related to exactly one "
"PolicyRepository via the PolicyActionInPolicyRepository "
"aggregation. The [0..1] cardinality for this property "
"covers the two types of PolicyActions: 0 for a "
"rule-specific PolicyAction, 1 for a reusable one.")
]
CIM_PolicyRepository REF Antecedent;
[Override ("Dependent"), Description (
"This property holds the name of a PolicyAction"
"hosted in the PolicyRepository. ")
]
CIM_PolicyAction REF Dependent;
};
// ==================================================================
// PolicyActionInPolicyRule
// ==================================================================
[Association, Aggregation, Description (
" A PolicyRule aggregates zero or more instances of the "
"PolicyAction class, via the PolicyActionInPolicyRule "
"association. A Rule that aggregates zero Actions is not "
"valid -- it may, however, be in the process of being entered "
"into a PolicyRepository or being defined for a System. "
"Alternately, the actions of the policy may be explicit in "
"the definition of the PolicyRule. Note that a PolicyRule "
"should have no effect until it is valid.\n\n"
" "
"The Actions associated with a PolicyRule may be given a "
"required order, a recommended order, or no order at all. For "
"Actions represented as separate objects, the PolicyActionIn"
"PolicyRule aggregation can be used to express an order. \n\n"
" "
"This aggregation does not indicate whether a specified "
"action order is required, recommended, or of no significance; "
"the property SequencedActions in the aggregating instance of "
"PolicyRule provides this indication.")
]
class CIM_PolicyActionInPolicyRule : CIM_PolicyComponent
{
[Override ("GroupComponent"), Aggregate, Description (
"This property represents the PolicyRule that "
"contains one or more PolicyActions.")
]
CIM_PolicyRule REF GroupComponent;
[Override ("PartComponent"), Description (
"This property holds the name of a PolicyAction "
"contained by one or more PolicyRules.")
]
CIM_PolicyAction REF PartComponent;
[Description (
" This property provides an unsigned integer 'n' that"
"indicates the relative position of a PolicyAction in the "
"sequence of actions associated with a PolicyRule. "
"When 'n' is a positive integer, it indicates a place "
"in the sequence of actions to be performed, with " "smaller integers indicating earlier positions in the " "sequence. The special value '0' indicates 'don't care'. " "If two or more PolicyActions have the same non-zero " "sequence number, they may be performed in any order, but " "they must all be performed at the appropriate place in the " "overall action sequence. \n\n" " " "A series of examples will make ordering of PolicyActions " "clearer: \n" " o If all actions have the same sequence number, " " regardless of whether it is '0' or non-zero, any " " order is acceptable.\n " " o The values: \n" " 1:ACTION A \n" " 2:ACTION B \n" " 1:ACTION C \n" " 3:ACTION D \n" " indicate two acceptable orders: A,C,B,D or C,A,B,D, " " since A and C can be performed in either order, but " " only at the '1' position. \n" " o The values: \n" " 0:ACTION A \n" " 2:ACTION B \n" " 3:ACTION C \n" " 3:ACTION D \n" " require that B,C, and D occur either as B,C,D or as " " B,D,C. Action A may appear at any point relative to " " B, C, and D. Thus the complete set of acceptable " " orders is: A,B,C,D; B,A,C,D; B,C,A,D; B,C,D,A; " " A,B,D,C; B,A,D,C; B,D,A,C; B,D,C,A. \n\n" " " "Note that the non-zero sequence numbers need not start " "with '1', and they need not be consecutive. All that " "matters is their relative magnitude.") ] uint16 ActionOrder; };
「実行される一連のアクションで、「「シーケンス」の以前の位置を示す「より小さな整数」で、特別な値「0」は「気にしない」を示します。」zero ""シーケンス番号、それらは任意の順序で実行できますが、 ""それらはすべて「全体的なアクションシーケンス」の適切な場所で実行する必要があります。\ n \ n "" ""ポリシー ""より明確：\ n "" oすべてのアクションが同じシーケンス番号を持っている場合、 ""「0」か非ゼロかに関係なく、任意の ""順序は受け入れられます。\ n "o値：\n "" 1：アクションa \ n "" 2：アクションb \ n "" 1：アクションc \ n "" 3：アクションd \ n "" 2つの許容命令を示します：a、c、b、d or c、a、b、d、 "" aとcはいずれかの順序で実行できるが、 "" "1 '位置でのみ。\ n" o値：\ n "" 0：アクションa \ n ""2：アクションb \ n "" 3：アクションc \ n "" 3：アクションd \ n ""は、b、c、dがb、c、dまたは "b、d、cとして発生することを要求します。アクションAは、 "" b、c、およびDに比べて任意のポイントで表示される場合があります。B、A、C、D;B、C、A、D;B、C、D、A;"" a、b、d、c;B、A、D、C;B、D、A、C;b、d、c、a。\ n \ n "" ""ゼロ以外のシーケンス番号は「1」で「開始する必要はない」ことに注意してください。また、連続する必要はありません。そのすべてが「重要なのは相対的な大きさです。 "）] uint16 actionorder;};
// ==================================================================
// VendorPolicyAction
// ==================================================================
[Description (
" A class that provides a general extension mechanism for "
"representing PolicyActions that have not been modeled "
"with specific properties. Instead, the two properties "
"ActionData and ActionEncoding are used to define the "
"content and format of the Action, as explained below.\n\n"
" "
"As its name suggests, VendorPolicyAction is intended for "
"vendor-specific extensions to the Policy Core Information "
"Model. Standardized extensions are not expected to use "
"this class.") ]
class CIM_VendorPolicyAction : CIM_PolicyAction
{
[Octetstring, Description (
"This property provides a general extension mechanism for "
"representing PolicyActions that have not been "
"modeled with specific properties. The format of the "
"octet strings in the array is left unspecified in "
"this definition. It is determined by the OID value "
"stored in the property ActionEncoding. Since "
"ActionEncoding is single-valued, all the values of "
"ActionData share the same format and semantics."),
ModelCorrespondence {
"CIM_VendorPolicyAction.ActionEncoding"}
]
string ActionData [];
[Description (
"An OID encoded as a string, identifying the format "
"and semantics for this instance's ActionData property."),
ModelCorrespondence {
"CIM_VendorPolicyAction.ActionData"}
]
string ActionEncoding;
};
// ===================================================================
// end of file
// ===================================================================
15. Full Copyright Statement
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エディター機能の資金は現在、インターネット協会によって提供されています。