RFC3060 日本語訳
3060 Policy Core Information Model -- Version 1 Specification. B.Moore, E. Ellesson, J. Strassner, A. Westerinen. February 2001. (Format: TXT=240309 bytes) (Updated by RFC3460) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループB.ムーア要求をネットワークでつないでください: 3060年のIBMカテゴリ: 標準化過程E.EllessonロングボードInc.J.Strassner A.Westerinenシスコシステムズ2001年2月
Policy Core Information Model -- Version 1 Specification
方針コア情報モデル--バージョン1仕様
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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.
このドキュメントは、Distributed Management Task Force(DMTF)のCommon情報Model(CIM)活動にIETF Policy Framework WGと拡大として共同で開発された方針情報を表すためにオブジェクト指向情報モデルを提示します。 このモデルはオブジェクトのクラスの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
1. 序論… 4 2. モデル方針… 5 2.1. 方針範囲… 8 2.2. 手続き上のモデルに対して宣言的… 8 3. 方針コア情報モデルの概要… 10 4. 方針コア情報のための継承階層構造はモデル化されます。 13 4.1. CIM継承の含意… 15 5. モデルの細部… 15
Moore, et al. Standards Track [Page 1] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[1ページ]。
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
5.1. 規則特有の状態と動作に対して再利用できる… 15 5.2. 役割… 17 5.2.1. 役割と役割の組み合わせ… 17 5.2.2. PolicyRolesの特性… 21 5.3. PolicyTimePeriodConditionsの現地時間とUTC時間… 21 5.4. CIMデータ型… 23 5.5. CIMとLDAPクラス仕様での比較… 24 6. クラス定義… 25 6.1. 「方針」という抽象クラス… 25 6.1.1. 特性の「CommonName(CN)」… 26 6.1.2. マルチ評価された特性の「PolicyKeywords」… 26 6.1.3. 特性の「見出し。」(ManagedElementから、世襲します) 27 6.1.4. 特性の「記述」(ManagedElementから、世襲します)… 27 6.2. クラス"PolicyGroup"… 27 6.3. クラス"PolicyRule"… 29 6.3.1. 「可能にされた」特性… 31 6.3.2. 特性の"ConditionListType"… 31 6.3.3. 特性の"RuleUsage"… 31 6.3.4. 特性の「優先権」… 32 6.3.5. 「義務的特性の」… 32 6.3.6. 特性の「SequencedActions」… 33 6.3.7. マルチ評価された特性の「PolicyRoles」… 33 6.4. 抽象クラス"PolicyCondition"… 34 6.5. クラス"PolicyTimePeriodCondition"… 36 6.5.1. 特性の"TimePeriod"… 38 6.5.2. 特性の"MonthOfYearMask"… 39 6.5.3. 特性の"DayOfMonthMask"… 39 6.5.4. 特性の"DayOfWeekMask"… 40 6.5.5. 特性の"TimeOfDayMask"… 41 6.5.6. 特性の"LocalOrUtcTime"… 42 6.6. クラス"VendorPolicyCondition"… 42 6.6.1. マルチ評価された特性の「規制」… 43 6.6.2. 特性の"ConstraintEncoding"… 43 6.7. 抽象クラス"PolicyAction"… 44 6.8. クラス"VendorPolicyAction"… 45 6.8.1. マルチ評価された特性の"ActionData"… 45 6.8.2. 特性の"ActionEncoding"… 46 6.9. クラス"PolicyRepository"… 46 7. 協会と集合定義… 46 7.1. 協会… 47 7.2. 集合… 47 7.3. 抽象的な集合"PolicyComponent"… 47 7.4. 集合"PolicyGroupInPolicyGroup"… 47 7.4.1. 参照"GroupComponent"… 48 7.4.2. 参照"PartComponent"… 48 7.5. 集合"PolicyRuleInPolicyGroup"… 48 7.5.1. 参照"GroupComponent"… 49
Moore, et al. Standards Track [Page 2] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[2ページ]。
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
7.5.2. 参照"PartComponent"… 49 7.6. 集合"PolicyConditionInPolicyRule"… 49 7.6.1. 参照"GroupComponent"… 50 7.6.2. 参照"PartComponent"… 50 7.6.3. 特性の"GroupNumber"… 50 7.6.4. 特性の"ConditionNegated"… 51 7.7. 集合"PolicyRuleValidityPeriod"… 51 7.7.1. 参照"GroupComponent"… 52 7.7.2. 参照"PartComponent"… 52 7.8. 集合"PolicyActionInPolicyRule"… 52 7.8.1. 参照"GroupComponent"… 53 7.8.2. 参照"PartComponent"… 53 7.8.3. 特性の"ActionOrder"… 53 7.9. 抽象的な協会"PolicyInSystem"… 54 7.10. 弱い協会"PolicyGroupInSystem"… 55 7.10.1. 「前例」という参照… 55 7.10.2. 「扶養家族」という参照… 55 7.11. 弱い協会"PolicyRuleInSystem"… 56 7.11.1. 「前例」という参照… 56 7.11.2. 「扶養家族」という参照… 56 7.12. 協会"PolicyConditionInPolicyRepository"… 56 7.12.1. 「前例」という参照… 57 7.12.2. 「扶養家族」という参照… 57 7.13. 協会"PolicyActionInPolicyRepository"… 57 7.13.1. 「前例」という参照… 58 7.13.2. 「扶養家族」という参照… 58 7.14. 集合"PolicyRepositoryInPolicyRepository"… 58 7.14.1. 参照"GroupComponent"… 58 7.14.2. 参照"PartComponent"… 59 8. 知的所有権… 59 9. 承認… 59 10. セキュリティ問題… 60 11. 参照… 62 12. 作者のアドレス… 64 13. 付録A: ネイティブのCIM実装におけるクラス識別… 65 13.1. PolicyGroupとPolicyRuleのインスタンスを命名します… 65 13.1.1. PolicyGroupのCIMキー… 65 13.1.2. PolicyRuleのCIMキー… 66 13.2. PolicyConditionのインスタンスとそのサブクラスを命名します。 67 13.2.1. PolicyConditionのCIMキー… 69 13.3. PolicyActionのインスタンスとそのサブクラスを命名します。 71 13.4. PolicyRepositoryのインスタンスを命名します… 72 13.5. 命名におけるCreationClassNameの特性の役割… 73 13.6. オブジェクト参照… 73 14. 付録B: コア方針MOF… 75 15. 完全な著作権宣言文… 100
Moore, et al. Standards Track [Page 3] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[3ページ]。
1. Introduction
1. 序論
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 Policy Framework WGと拡大としてDistributed Management Task Force(DMTF)のCommon情報Model(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.
このモデルで定義された方針のクラスと協会による十分、彼らが方針を表すのを許容するジェネリックが何にでも関連したということです。 しかしながら、QoS(DiffServとIntServ)に関連する方針を表して、IPSecにIETFでの彼らの初期の利用があると予想されます。 これらなどのアプリケーション特有の領域への政策モデルはいくつかの方法でCore Modelを広げるかもしれません。 都合のよい道は直接PolicyGroup、PolicyRule、およびPolicyTimePeriodConditionのクラスを使用することです、方針情報を表して、伝える基礎として。 そして、PolicyConditionとPolicyActionから得られた特定のサブクラスは方針の状態と動作のアプリケーション特有の定義を得ることができます。
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つのサブクラス(VendorPolicyConditionとVendorPolicyAction)が、Policy Core情報Modelへのベンダー特有の拡大に標準の拡張機能を提供するために本書では含まれています。
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.
このドキュメントはPolicy Framework作業部会によって開発される方針を表して、配布して、管理するための総合的なフレームワークに収まります。 それは扱う元々ディレクトリで可能にされたNetworks(DEN)仕様のために行われた発生源、参照[5]をたどります。 DEN Ad-Hoc作業部会自体によるDEN仕様に対する仕事は終了しました。 それに含まれたモデルを標準化するさらなる仕事はDistributed Management Task Force(DMTF)のCIM取り組みの選択されたワーキンググループの責任になるでしょう。 コア政策モデルのDMTF規格化はDMTFのSLA Policyワーキンググループの責任です。
Moore, et al. Standards Track [Page 4] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[4ページ]。
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はPolicy Core情報Modelを包括するクラスと協会のハイレベルの概要を提示します。
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 ネイティブのCIM実装のための付録A概要命名。 LDAPv3などの他のマッピングで、それら自身のはメカニズムを命名するでしょう。
o Appendix B reproduces the DMTF's Core Policy MOF specification.
o 付録BはDMTFのCore Policy 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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTがRFC2119で説明されるように本書では解釈されることであるなら、[3]に参照をつけてくださいだろう。
2. Modeling Policies
2. モデル方針
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.
アプリケーション開発者、ネットワーク管理者、および方針管理者が異なったタイプの方針を表すのを可能にする政策目的を定義するためにPolicy Core情報Modelを包括するクラスが広げることができるクラス階層構造として機能することを意図します(専門化で)。
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つの方法は、最初に、州のマシンとしてネットワークをモデル化して、次に、どの状態には、方針で制御されたデバイスはあるべきであるか、またはその時々であることができるかを制御するのに方針を使用することです。 このアプローチを考えて、方針は、1セットの政策ルールを使用することで適用されています。 各政策ルールは1セットの状態と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セットのORedセットか声明のORedセットのANDedセットのどちらかとして状態のセットを急送できます。 また、個々の状態声明を否定できます。 これらの組み合わせは状態のためにそれぞれDisjunctive Normal Form(DNF)とConjunctive Normal Form(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、当時の1セットの機能に交際する状態でそれを評価するという条件では、オブジェクトか変遷の現状のときに新しい状態へのオブジェクトが実行されるかもしれないと主張してください。
Moore, et al. Standards Track [Page 5] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[5ページ]。
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政策ルールは、工学グループのメンバーから発するトラフィックがBronze Serviceを手に入れることであると指定するかもしれません。 2番目の政策ルールは例外を言い表すかもしれません: ジョンから発するトラフィック(工学グループの特定のメンバー)はGold Serviceを手に入れることです。 ジョンから発するトラフィックが両方の政策ルールの状態を満たして、2つの規則に関連している動作が両立しないので、優先は、設立される必要があります。 2番目の規則(例外)を優先させることによって、最初の規則(一般的なケース)より高い方針管理者は所期の効果を得ることができます: ジョンから発するトラフィックがGold Serviceを手に入れます、そして、工学グループの他のすべてのメンバーから発するトラフィックがBronze Serviceを手に入れます。
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
方針をスタンドアロンのファッションで使用するか、または、より入念な機能を実行するために方針グループに集めることができます。 スタンドアロンの方針は政策ルールと呼ばれます。 方針グループは、政策ルールの集合、または方針グループの集合ですが、ともに集合であるというわけではありません。 方針グループは複雑な相互依存性を持っているオブジェクトの間の複雑な相互作用をモデル化できます。 この例はアプリケーションアクセス、セキュリティをセットアップして、ユーザのアイデンティティの組み合わせに基づくネットワーク接続を再構成する高度なユーザログオン方針、ネットワークの位置、ログオンメソッド、および時刻を含んでいます。 管理は管理者の身元保証可能なグループによって扱われます、そして、政策ルールは一貫して当てはまられるでしょう、したがって、方針グループがリユーザビリティと管理可能性の単位を表します。
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課題と、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,
彼らの目的と意図は方針グループと規則を分類できます。 この分類は政策ルールを質問するか、または分類する際に役に立ちます。 それは、方針がいつか動作がどう起こるかを動機づけるか、またはサービスを特徴付けるのに使用されるかどうかを(次に、例えば、ネットワーク・サービスにクライアントを縛るのにそれを使用できます)示します。 さらに詳細にそれぞれのこれらの概念について説明します。
Moore, et al. Standards Track [Page 6] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[6ページ]。
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 動機づけのPoliciesが唯一狙う、優れているか、または方針の目標はどのように優れているか。 構成とUsage PoliciesはMotivational Policiesの特定の種類です。 別の例はM-F、ディスクに基づくファイルバックアップのスケジューリングが午前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 構成Policiesは管理された実体(例えば、ネットワーク・サービス)のデフォルト(または、ジェネリック)セットアップを定義します。 Configuration Policiesに関する例はネットワーク推進サービスかネットワークによって接待された印刷待ち行列のセットアップです。
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 インストールPoliciesは置くことができて、システムかコンポーネントに置くことができないものは定義します、インストールを実行するメカニズムの構成と同様に。 インストール方針は、特定の管理許容を通常表して、また、異なったコンポーネントの間の依存を表すことができます(例えばコンポーネント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時の間で失敗するなら、システム管理者に電話をしてください。さもなければ、Deskにヘルプに電話をしてください。
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 用法Policiesは特定の「用法」データに基づく実体の選択と構成を制御します。 構成Policiesは変更するかUsage Policiesが単に再び使うことができます。 Usage Policiesに関する例は、ユーザが「金」サービスグループのメンバーになるように確かめられた後にネットワーク転送サービスをアップグレードさせるか、またはプリンタが待ち行列における次の仕事を扱うことができるのを再構成するのを含んでいます。
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 クライアントがPoliciesがそれについて確かめるのを取扱うセキュリティはクライアントが、実際にだれを意味するかということです、リソースへのアクセスを可能にするか、または拒絶して、適切な認証機構を選択して、適用して、リソースの会計学と会計監査学を実行して。
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 サービスPoliciesはネットワークと他のサービス(それらを使用しない)を特徴付けます。 例えば、すべての広い領域のバックボーンインタフェースが特定のタイプの列を作りを使用するものとします。
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.
これらのカテゴリはPolicy Core情報Modelに抽象クラスPolicyのPolicyKeywordsの特性のために定義された特別な値によって表されます。
Moore, et al. Standards Track [Page 7] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[7ページ]。
2.1. Policy Scope
2.1. 方針範囲
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)と、目的と測定基準であるかもしれません(サービスLevel Objectives、またはSLOs)。 通常、SLAはハイレベルのビジネス用語で書かれるでしょう。 SLOsはSLAを支持して、より特定の測定基準を扱います。 そして、しかし、また、ネットワーク・サービスと測定基準のこれらのハイレベルの記述を低レベルに翻訳しなければならない、ベンダー、-、デバイスから独立している仕様。 Policy Core情報Modelのクラスがこれらの低レベル、ベンダー、およびデバイスから独立している仕様の基礎として機能することを意図します。
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.).
それは思い描かれます。Policy Core Informational Modelの定義は、本書では現実にジェネリックであり、Service(QoS)のQualityと、そして、非QoSネットワークアプリケーション(例えば、DHCPとIPSec)と、そして、非ネットワークアプリケーションに適切です(例えば、方針のバックアップをとってください、アクセスなどを監査して)。
2.2. Declarative versus Procedural Model
2.2. 手続き上のモデルに対して宣言的です。
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.
Policy Core情報Modelのデザインはa宣言的によって手続き上ではなく、影響を及ぼされて、アプローチしてください。 より正式に、宣言形言語が説明するのにおいて使用されている、関係、そして、関数型言語。 宣言形言語は機能か推論規則で変数の間の関係について説明します。(インタプリタかコンパイラが、結果を生むために固定アルゴリズムを推論規則に適用できます)。 必須の、そして、(手続き上)の言語は、結果を生むために続くようにステップの明白な系列を指定します。
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.
この情報モデルが手続き型言語の使用を除外しないことに注意するのは重要です。 むしろ、手続き型言語もともにまた、宣言的である場合がありますが、それはそれを認識します。 この情報モデルは宣言的な声明の処理をするためのステップの系列が、implementerに残される傾向があるので宣言的であるとして見なされるほうがよいです。 しかしながら、私たちはこの方針情報モデルと、オーダーが義務的であるかどうかと言い表すための動作実行の必要な注文を言い表すオプションを提供しました。 政策ルールがあとに続かなければならない指示か方法のアルゴリズムかセットを定義しようとするよりさらに、むしろ、私たちは代わりに、方針を定義するのに宣言的であるか手続き上のファッションで使用できる1セットのモジュールのブロックと関係を定義します。
Moore, et al. Standards Track [Page 8] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[8ページ]。
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.
厳密に手続き上のモデルとこれを比較してください。 そのようなアプローチを取るのは、私たちが状態テスト系列、および動作実行順序を指定するのを必要とするでしょう、方針倉庫自体で。 本当に、これはimplementerを抑制するでしょう。 これは政策モデルが宣言的なものとして描写される理由です。 すなわち、情報モデルは1セットの属性、およびこれらの属性を含む1セットの実体を定義します。 しかしながら、それは、結果を生むのにステップの属性か明白な系列を使用することで結果を生むためにアルゴリズムを定義しません。
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. 一方では、定義と病気の特徴の容易さには、方針定義言語は人間合理的にに優しくたいと思います。 他方では、政策決定が指すとき作動できた装置(彼らの処理能力に関する)の多様性を考えて、マシンいくらか好意的に言語を保ちたいと思います。 すなわち、ネットワーク要素における、言語の構文解析と処理を自動化するのは比較的簡単であるべきです。 取られたアプローチはネットワーク要素とサービスを管理する方針を言い表すために叙述的であるか手続き上のアプローチで合併できる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
3. 仕様の複雑さを制御するのは重要です、実現と使用の容易さのためにコア情報モデルにおける、データの表現の豊かを交換して。 その分野における集合的な経験の欠如を承認するのは重要です。
Moore, et al. Standards Track [Page 9] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[9ページ]。
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.
制御して、ネットワーク・サービスを管理して、したがって、「完全性」を目指す誘惑を避けるために方針を見なします。 私たちは顧客が今日必要とする1セットの共通政策(例えば、VPNとQoS)の定義を容易にして、経験に従って顧客の要望と私たちのこれらの方針の理解が発展するので複雑な方針を支持することに向かって移行パスを許容するように代わりに努力するべきです。 明確に、上で議論した叙述的なスタイル言語の文脈では、言語として花盛りの述語計算を持っているのを避けるのは重要です、一貫性などの多くの重大な問題をチェックしているのに表して、政策決定ポイントアルゴリズムを手に負えなく表すだろうというとき。 これらの見解から合理的に抑制された言語を考えるのは役に立ちます。
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.
Policy Core情報Modelは、簡単な保険約款をより複雑なものに結合するのにDisjunctive Normal FormとConjunctive Normal Formのよく理解されている論理的な概念を使用することによって、パワーの複雑さと不足の間のバランスをとります。
3. Overview of the Policy Core Information Model
3. 方針コア情報モデルの概観
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モデルでPolicy Core情報Model、互いにそれらの協会、および他のクラスへのそれらの協会を包括する5つの中央のクラスの概観を提供します。 2拡大のクラスの抽象クラスPolicy、VendorPolicyCondition、およびVendorPolicyActionが見せられないことに注意してください。
NOTE: For cardinalities, "*" is an abbreviation for "0..n".
以下に注意してください。 基数、「*」が「0」のための略語であるので。「n。」
Moore, et al. Standards Track [Page 10] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[10ページ]。
+-----------+
| 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 <.......
+-------------+ +--------------------+
+-----------+ | システム| ..... +--^-----^--+ ..... . . 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
図1。 コア方針のクラスと関係の概観
Moore, et al. Standards Track [Page 11] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[11ページ]。
In this figure the boxes represent the classes, and the dotted arrows represent the associations. The following associations appear:
この図では、箱はクラスを表します、そして、点を打たされた矢は協会を代表します。 以下の協会は現れます:
(a) PolicyGroupInPolicyGroup
(a) PolicyGroupInPolicyGroup
(b) PolicyGroupInSystem
(b) PolicyGroupInSystem
(c) PolicyRuleInSystem
(c) PolicyRuleInSystem
(d) PolicyRepositoryInPolicyRepository
(d) PolicyRepositoryInPolicyRepository
(e) PolicyRuleInPolicyGroup
(e) PolicyRuleInPolicyGroup
(f) PolicyConditionInPolicyRepository
(f) PolicyConditionInPolicyRepository
(g) PolicyActionInPolicyRepository
(g) PolicyActionInPolicyRepository
(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関係があるケースのように。(関係は他のPolicyGroupsにPolicyGroupsの再帰的な封じ込めを表します)。 同様に、PolicyRepositoryInPolicyRepository協会は再帰的です。
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:
協会はそれぞれの関連するクラスのための基数を含めます。 これらの基数は、それぞれのクラスのいくつの例がもう片方のクラスの例に関連するかもしれないかを示します。 '例えば、PolicyRuleInPolicyGroup協会には、PolicyGroupとPolicyRuleのクラスの両方のための基数範囲「*'(すなわち、"0..n")があります」。 これらの範囲は以下の通り解釈されます:
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 PolicyGroupの横で書かれた「*」は、PolicyRuleがどんなPolicyGroupsにも関連しないかもしれないのを1PolicyGroup、またはPolicyRuleInPolicyGroup協会を通した1PolicyGroupまで示します。 言い換えれば、PolicyRuleはPolicyGroupsがない、1PolicyGroups、または1PolicyGroupに含まれるかもしれません。
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の横で書かれた「*」は、PolicyGroupがどんなPolicyRulesにも関連しないかもしれないのを1PolicyRule、またはPolicyRuleInPolicyGroup協会を通した1PolicyRuleまで示します。 言い換えれば、PolicyGroupはPolicyRulesがない、1つPolicyRule、または1以上PolicyRuleを含むかもしれません。
Moore, et al. Standards Track [Page 12] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[12ページ]。
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」が、これらがどんなCIMが、より簡潔に「弱い参照がある集合」を呼ぶかということであることを示す、「弱い集合。」 弱い集合は単に命名範囲のしるしです。 したがって、これらの2つの集合が、PolicyGroupかPolicyRuleの例がSystem物の範囲の中で命名されるのを示します。 弱い集合には、基数1がそれとなくあります。1 'w'の反対側の終わりに。
The associations shown in Figure 1 are discussed in more detail in Section 7.
さらに詳細にセクション7で図1で見せられた協会について議論します。
4. Inheritance Hierarchies for the Policy Core Information Model
4. 方針コア情報モデルのための遺産階層構造
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
ManagedElement(抽象的な)| +--方針(要約)| | | +---PolicyGroup| | | +---PolicyRule| | | +---PolicyCondition(抽象的な)| | | | | +---PolicyTimePeriodCondition| | | | | +---VendorPolicyCondition| | | +---PolicyAction(抽象的な)| | | +---VendorPolicyAction| +--ManagedSystemElement(抽象的な)| +--LogicalElement(抽象的な)| +--システム(要約)| +--AdminDomain(抽象的な)| +---PolicyRepository
Figure 2. Inheritance Hierarchy for the Core Policy Classes
図2。 コア方針のクラスのための遺産階層構造
Moore, et al. Standards Track [Page 13] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[13ページ]。
ManagedElement, ManagedSystemElement, LogicalElement, System, and AdminDomain are defined in the CIM schema [1]. These classes are not discussed in detail in this document.
ManagedElement、ManagedSystemElement、LogicalElement、System、および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では、協会はクラスとしてモデル化されます。 Policy Core情報Modelに関しては、協会のための遺産階層構造は以下の通りです:
[unrooted]
|
+---PolicyComponent (abstract)
| |
| +---PolicyGroupInPolicyGroup
| |
| +---PolicyRuleInPolicyGroup
| |
| +---PolicyConditionInPolicyRule
| |
| +---PolicyRuleValidityPeriod
| |
| +---PolicyActionInPolicyRule
|
+---Dependency (abstract)
| |
| +---PolicyInSystem (abstract)
| |
| +---PolicyGroupInSystem
| |
| +---PolicyRuleInSystem
| |
| +---PolicyConditionInPolicyRepository
| |
| +---PolicyActionInPolicyRepository
|
+---Component (abstract)
|
+---SystemComponent
|
+---PolicyRepositoryInPolicyRepository
[「非-根づ」きました]| +---PolicyComponent(抽象的な)| | | +---PolicyGroupInPolicyGroup| | | +---PolicyRuleInPolicyGroup| | | +---PolicyConditionInPolicyRule| | | +---PolicyRuleValidityPeriod| | | +---PolicyActionInPolicyRule| +---依存(抽象的な)| | | +---PolicyInSystem(抽象的な)| | | +---PolicyGroupInSystem| | | +---PolicyRuleInSystem| | | +---PolicyConditionInPolicyRepository| | | +---PolicyActionInPolicyRepository| +---コンポーネント(要約)| +---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.
Dependency、Component、およびSystemComponent協会について、CIM図式[1]で定義されて、さらに本書では議論しません。
Moore, et al. Standards Track [Page 14] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[14ページ]。
4.1. Implications of CIM Inheritance
4.1. CIM遺産の含意
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図式から、特性と協会の両方がPolicyのクラスに引き継がれます。 例えば、クラスManagedElementは協会のDependency、Statistics、およびMemberOfCollectionで参照をつけられます。 そして、Dependency協会は順番にDependencyContext協会で参照をつけられます。 遺産階層構造のこの非常に抽象的で高いレベルでは、これらの協会の数は非常に少ないです、そして、それらの意味論はかなり一般的です。
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.
これらの引き継いでいる協会の多くがPolicy Core情報Modelを理解するのにおいて必要でない追加意味論を伝えます。 事実上、それらは、それらの基数が「0」であるので、CIM SchemaでOPTIONALと定義されます。すべての参照での「n。」 PCIMは、何が支持して、例示するのに必要であるかと明確に議論すると記録します。 例えば、Dependencyを副分類することで、協会、PCIMの正確なDependency意味論は説明されます。
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_StatisticalInformationのサブクラスで説明されるでしょう。) これらの場合では、ManagedElementからPolicyRuleまで引き継がれたStatistics協会は、それのためにPolicyRuleの例と統計のセットとの繋がりについて説明するのに使用されるかもしれません。
5. Details of the Model
5. モデルの細部
The following subsections discuss several specific issues related to the Policy Core Information Model.
以下の小区分はPolicy Core情報Modelに関連するいくつかの特定の問題について議論します。
5.1. Reusable versus Rule-Specific Conditions and Actions
5.1. 規則特有の状態と動作に対して再利用できます。
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つのグループに仕切ることができます: ただ一つの政策ルール、およびそれらが1つ以上の方針に関連しているかもしれないという意味で再利用できるものに関連しているものは統治されます。 最初のグループにおける状態と動作は「規則特有」の状態と動作と呼ばれます。 2番目のグループにおけるものは「再利用できる」として特徴付けられます。
Moore, et al. Standards Track [Page 15] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[15ページ]。
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つの集合があります。 PolicyConditionInPolicyRepositoryはPolicyConditionInPolicyRuleが両端に基数*を持っていて、PolicyConditionエンドのときに基数*を持っていて、PolicyRepositoryエンドのときに[0 .1]を持っています。
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.
これらの基数はグローバルに、正しいです。 しかしながら、さらに話には規則特有のPolicyConditionと再利用できるものに関するケースがあります。(私たちが2のために別々に基数を調べる場合にだけ、それは、明確になります)。
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の基数はこと[1 .1]です、状態が[0..n](*が[0..n]のための略語であると思い出す)むしろ1つの政策ルールにユニークであるので。 そして、状態が「再使用可能な」倉庫になくて、PolicyRepositoryエンドのPolicyConditionInPolicyRepositoryの基数はこと[0 .0]です。 これは、これらが指定された基数の両方の部分集合であるので、OKです。
Moore, et al. Standards Track [Page 16] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[16ページ]。
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に関しては、PolicyRepositoryエンドのPolicyConditionInPolicyRepositoryの基数はこと[1 .1]です、状態が倉庫にあるに違いないので。 そして、PolicyRuleエンドのPolicyConditionInPolicyRuleの基数は[0..n]です。 この最後のポイントは重要です: 再利用できるPolicyConditionは0、1、または1PolicyRulesに関連しているかもしれません、規則の特定の状態をPolicyRuleに縛るまさに同じ協会PolicyConditionInPolicyRuleを通して。
Currently the only way to document constraints of this type is textually. More formal methods for documenting complex constraints are needed.
このタイプの規制を記録する現在の、唯一の方法が原文です。 複雑な規制を記録するための、より正式な方法が必要です。
5.2. Roles
5.2. 役割
5.2.1. Roles and Role Combinations
5.2.1. 役割と役割の組み合わせ
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.
役割の概念は全体のPolicy Frameworkのデザインに主要です。 役割の後ろの考えは簡単なものです。 ネットワークにおける、リソースの構成をアップデートする構成していて、次に、後の有、数百または数千(さらに)よりむしろ、方針管理者は、各リソースを1つ以上の役割に割り当てて、次に、それぞれのこれらの役割に方針を指定します。 Policy Frameworkはその時、その役割に指定された方針によると、反応するような方法で役割に関連づけられたそれぞれに関するリソースを構成するのに責任があります。 ネットワークの振舞いを変えなければならないとき、方針管理者は役割のためにただ一つのアップデートを方針に実行できます、そして、Policy Frameworkは必要な構成アップデートがその役割を果たすすべてのリソースに実行されるのを確実にするでしょう。
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セットの実体、そして/または、部品のためにはるかに大きいセットの利用可能な方針から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セットの実体、そして/または、部品のためにはるかに大きいセットの利用可能な方針から1つ以上の方針を選択するのに使用される1セットの属性です。 以下の例が例証するように、役割の組み合わせのための選択の過程は組み合わせ自体に関連している方針を選びます、それぞれのサブ組み合わせ、および役割の組み合わせにおけるそれぞれの個々の役割に関連している方針に関連している方針。
Moore, et al. Standards Track [Page 17] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[17ページ]。
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。」 Policy Repositoryでは、役割の「イーサネット」にいくつかの政策ルールを関連づけることができました。 これらの規則はすべてのイーサネットインタフェースに適用されるでしょう、それらがキャンパス側かWAN側にあったことにかかわらず。 役割組み合わせ「キャンパス」+「イーサネット」に他の規則を関連づけることができました。 これらの規則は、WAN側ではキャンパスサイドイーサネットインタフェースに適用しますが、それらに適用されないでしょう。 最終的に、役割組み合わせ「イーサネット」+「WAN」に3番目の1セットの規則を関連づけることができました。 これらの規則は、キャンパス側では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があるなら、私たちは、それで政策ルールの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".
o 「支店」o「イーサネット」o「WAN」o「支店」+「イーサネット」o「支店」+「WAN」o「イーサネット」+「WAN」o「支店」+「イーサネット」+「青白いです」。
Moore, et al. Standards Track [Page 18] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[18ページ]。
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つの役割組み合わせのこのリストに広げて、次に、Policy Repositoryから対応する7つの政策ルールを検索しなければなりません。 もちろん、この例は異常に複雑にされます: 正常なケースは、3セットの政策ルールを特定する3つの値に2役割の組み合わせを広げることを伴うでしょう。
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.
また、役割組み合わせは、政策ルールの間の闘争を特定するという問題をいくらか簡素化するのを助けます。 役割組み合わせでは、方針管理者が1セットのキャンパスサイドイーサネットインタフェースへの政策ルール、および2番目の1セットの政策ルールをWANサイドイーサネットインタフェースに指定するのは、可能です、2セットの規則の間の闘争を心配する必要はなくて。 方針管理者は単にこれらの2セットの規則のための闘争検出を「オフにします」、役割の「キャンパス」と「WAN」が互いと非互換であると政策管理システムに言うことによって。 これは役割の組み合わせが決して起こらないで、またしたがって、闘争が決して起こらないのを示します。 いくつかの場合、技術自体は両立しない役割を特定するかもしれません: 「イーサネット」と例えば、"FrameRelay"。 しかし、「キャンパス」と「WAN」のようなそれほど正確でない用語のときに、方針管理者は、それらが両立しない役割を特定するかどうか言わなければなりません。
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. 政策管理システムが1つが役割の「キャンパス」(または役割の「キャンパス」を含んでいる役割組み合わせに)に結ばれて、もう片方が役割の「WAN」(または役割の「WAN」を含んでいる役割の組み合わせに)に結ばれる2つの政策ルールを見るなら、システムは2つの政策ルールの間の闘争を探す必要はありません: 両立しない役割のために、2つの規則は闘争できません。
Moore, et al. Standards Track [Page 19] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[19ページ]。
+-------------------+
| Policy Repository |
+-------------------+
V
V retrieval of policy
V
+---------+
| PDP/PEP |
+---------+
v
v application of policy
v
+----------------+
| Network Entity |
+----------------+
+-------------------+ | 方針倉庫| +-------------------+ 方針V+のV V検索---------+ | PDP/気力| +---------+ 方針対+のv適用に対して----------------+ | ネットワーク実体| +----------------+
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(Policy Frameworkがネットワーク要素の収集でどう実装されるかもしれないかに関する例だけとして紹介されます)は役割がPolicy Frameworkの中でどう作動するかを例証します。 それらの区別がこの議論に重要でないので、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:
役割は方針が適用されている機能特性かリソースの能力を表します。 役割に関する例はBackboneインタフェース、Frame Relayインタフェース、BGPできるルータ、ウェブサーバー、ファイアウォールなどを含んでいます。 ただ一つのリソースに割り当てられた複数の役割が、そのリソースの役割の組み合わせを形成するために結合されます。 役割の組み合わせはPCIMにPolicyRuleのクラスにおける、PolicyRolesの特性の値によって表されます。 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は何らかの方法でPEPsが果たす役割のリストを学びます。 この情報が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. それが例にみられるように上にPEPsから受け取った役割と役割組み合わせを使用して、PDPはそれに関連している政策ルールの、場所を見つけて、検索できます。
Moore, et al. Standards Track [Page 20] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[20ページ]。
5.2.2. The PolicyRoles Property
5.2.2. PolicyRolesの特性
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の特性を使用して、例えば、Frame Relayインタフェース、または、バックボーンATMインタフェースに適用するとして政策ルールをマークするのは可能です。 PolicyRolesの特性は形式のストリングを取ります:
<RoleName>[&&<RoleName>]*
<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つの役割だけを含む「組み合わせ」の特別なケースを含む役割の組み合わせを表します。 形式が示すように、役割の組み合わせにおける役割の名は単一のセレクタを形成するために一緒にいるANDedです。 PolicyRolesの特性の複数の値はORed、それを可能にするように、論理的に、方針に統治されるということです。複数のセレクタを持つために。
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キャラクタのための照合順序によると)現れなければなりません。 環境で使用される役割の名は方針管理者によって指定されます。
5.3. Local Time and UTC Time in PolicyTimePeriodConditions
5.3. PolicyTimePeriodConditionsの現地時間とUTC時間
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のインスタンスには、回を表す最大5つの特性があります: TimePeriod、MonthOfYearMask、DayOfMonthMask、DayOfWeekMask、およびTimeOfDayMask。 PolicyTimePeriodConditionのインスタンスにおける時間関連の特性のすべてが2つのタイプの倍の1つを表します: 政策ルールが適用されるかUTC時間である場所では、現地時間です。 特性の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時間まで写像する必要がある他の時間表現に備えるPolicy Management Tool)だけに提供します。 例はこのマッピングの本質を例証するでしょう。
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
政策ルールがヘルプDeskのために操作の数時間に結ばれると仮定してください: 米国東部標準時の0800年から2000月曜日から金曜日[米国。] PolicyTimePeriodConditionでこれらの回を言い表すために、管理ツールはUTC回にそれらを変換しなければなりません。 (それらが現地時間でない、参照するので、間隔までつながったのではなく、世界中の単一の時間間隔まで、どこが位置の地方の時計につながっていたか。
Moore, et al. Standards Track [Page 21] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[21ページ]。
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.
PolicyRuleは適用されています。) 参照[10]が指摘するように、UTC時間までの米国東部標準時の[米国]からのマッピングは単にオフセットを適用する問題ではありません: Daylight Savings Timeが米国で有効であるかどうかよる-0500と-0400の間の米国東部標準時の[米国]とUTCタイムスイッチの間のオフセット。
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.
方針アドミニストレータの目標が毎週月曜日に政策ルールが有効であることを0800年から米国東部標準時の1200年[米国]まで持つことであると仮定してください、2000年の始まりから2001年の終わりまでの全治療期間の期間中に。 米国東部標準時の[米国]が意味することに関する定義でPolicy Management Toolを構成できましたか、またはこの情報を得にどこに行くかに関する知識はそれを構成できました。 参照[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:
軍備されて、しかしながら、米国東部標準時の[米国]の周りでは、Policy Management ToolがPolicyTimePeriodConditionの多くのインスタンスを作成するだろうという知識で、それは、必要な間隔を表す必要がありました。 増強された数のPolicyTimePeriodConditionインスタンスがありますが、ちょうど1PolicyRuleがまだあることに注意してください。(PolicyRuleは集合PolicyRuleValidityPeriodを通してすべてのPolicyTimePeriodConditionインスタンスに結ばれます)。 ここに、これらの2つの最初のインスタンスがあります:
1. TimePeriod: 20000101T050000/20000402T070000
DayOfWeekMask: { Monday }
TimeOfDayMask: T130000/T170000
LocalOrUtcTime: UTC
1. TimePeriod: 20000101T050000/20000402T070000 DayOfWeekMask: 月曜日のTimeOfDayMask: T130000/T170000 LocalOrUtcTime: UTC
2. TimePeriod: 20000402T070000/20001029T070000
DayOfWeekMask: { Monday }
TimeOfDayMask: T120000/T160000
LocalOrUtcTime: UTC
2. TimePeriod: 20000402T070000/20001029T070000 DayOfWeekMask: 月曜日の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が2つのインスタンスに分けたインスタンス: 月曜日のT130000/T240000のUTC時間間隔がある1、および火曜日のT000000/T030000のUTC時間間隔がある別。 それで、結末は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
PolicyTimePeriodConditionを現地時間とUTC時間に制限することによって、PCIMは時間表現を「人間」からマシンに優しいものに写像する難しくて高価なタスクをPolicyに置きます。
Moore, et al. Standards Track [Page 22] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[22ページ]。
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.
管理ツール。 別のアプローチは[米国]などの米国東部標準時の命名された時間帯を表す手段をPolicyTimePeriodConditionに置くだろうことでした。 しかしながら、これは難しいマッピング責任をPDPsとPEPsまで通過したでしょう。 PolicyRuleを適用する必要があるそれぞれのPDPs(そして、ことによるとPEPs)でそれを再三させるよりPolicy Management Toolで上で一度むしろしていた状態で説明されたものなどのマッピングを持っているほうがよいです。
5.4. CIM Data Types
5.4. CIMデータ型
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 Schemaを広げているので、CIMとPCIMの両方で使用されるデータ型の間の通信が必要です。 以下のCIMデータ型はセクション6と7で続くクラス定義に使用されます:
o uint8 unsigned 8-bit integer
o uint8の未署名の8ビットの整数
o uint16 unsigned 16-bit integer
o uint16の未署名の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.
各キャラクタが2つの八重奏でコード化されるところにCIMにおけるストリングはUCS-2キャラクタとして保存されます。 したがって、ストリング値は、CIM環境と異なったストリングコード化を使用するものの間で移行するとき、変換される必要があるかもしれません。 例えば、LDAPアクセス可能なディレクトリでは、タイプDirectoryStringの属性はUTF-8形式で保存されます。 RFC2279[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>審判は強く参照をタイプしました。
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データ型のこのリストからの1つの明白な省略があります: 八重奏ストリング。 これはCIMが八重奏ストリングを導き出されるデータの形式として扱うからです。 CIMには2つの形式の八重奏ストリングがあります--単一に評価されたストリングのための命令されたuint8配列、およびマルチ評価された特性のための文字列配列。 両方が、"OctetString"資格を与える人(メタデータ)を特性に追加することによって、説明されます。 この資格を与える人はちょうどSMIv2(SNMP)の原文のConventionのように機能します、既存のCIMデータ型の構文と意味論を洗練して。
Moore, et al. Standards Track [Page 23] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[23ページ]。
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'.
"OctetString"表現の両方の最初の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'を使用するつもりである)、およびprependとして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構文を使用して、prepended長さの八重奏を省略するのははるかに当然でしょう。
5.5. Comparison between CIM and LDAP Class Specifications
5.5. CIMとLDAPクラス仕様での比較
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クラス仕様の間には、多くの違いがあります。 簡略化されたクラス仕様に関連しているものは以下に本書では記載されています。 これらの項目はCIMモデル、および拡大でIETF共同体を導入するのを助けるためにここに含まれています、一般に、モデル化される情報に。共同体は既にLDAPになじみ深いです。
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しかありません: 抽象的であって、instantiableです。 CIMのクラスのタイプはブール資格を与える人要約によって示されます。
o CIM uses the term "property" for what LDAP terms an "attribute".
o CIMはLDAPが「属性」を呼ぶことに「特性」という用語を使用します。
Moore, et al. Standards Track [Page 24] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[24ページ]。
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命名体系は、それが情報モデルを理解しているのに重要でないのでAppendix Aに記録されて、ネイティブのCIM実装で交信するときだけ、適用されます。
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では、特性はただ一つのクラス定義の範囲の中で定義されます。 特性はそれが定義されるクラスのサブクラスに引き継がれるかもしれませんが、さもなければ、それは他のクラスでは現れることができません。 この違いの半面効果は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_」で前に置かれています。 これらの接頭語はこのドキュメントと、ただ1つを例外としてAppendix Aに記録された命名に関して省略されました。
For the complete definition of the CIM specification language, see reference [2].
CIM仕様言語の完全な定義に関しては、参照[2]を見てください。
6. Class Definitions
6. クラス定義
The following sections contain the definitions of the PCIM classes.
以下のセクションはPCIMのクラスの定義を含みます。
6.1. The Abstract Class "Policy"
6.1. 「方針」という抽象クラス
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はCore Policyのクラス(または、それらのサブクラス)のどれかのインスタンスに含まれるかもしれない数個の特性を集めます。 また、便利において、PolicyがManagedElementからCIM図式で引き継ぐ2つの特性がここに示されます。
Moore, et al. Standards Track [Page 25] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[25ページ]。
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つの特性があるNAME Policy記述An抽象クラス。 ManagedElementの抽象的な本当の特性のCommonName(CN)PolicyKeywords[ ]//見出し(世襲する)//記述から、派生します。(引き継ぐ)です。
6.1.1. The Property "CommonName (CN)"
6.1.1. 特性の「CommonName(CN)」
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
方針関連のオブジェクトのNAME CN DESCRIPTIONのAユーザフレンドリーな名。 SYNTAXストリング
6.1.2. The Multi-valued Property "PolicyKeywords"
6.1.2. マルチ評価された特性の「PolicyKeywords」
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で、より早く定義されました。
Moore, et al. Standards Track [Page 26] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[26ページ]。
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.
Policy Core情報ModelクラスSHOULDのサブクラスを定義するドキュメントは、これらのサブクラスのインスタンスを特徴付けるために追加キーワードを定義します。 コンベンションで、大文字にはクラス定義に関連して定義されたキーワードがあります。 どんな場合にもインストールで定義されたキーワードがあることができます。
The property definition is as follows:
特性の定義は以下の通りです:
NAME PolicyKeywords
DESCRIPTION A set of keywords for characterizing /categorizing
policy objects.
SYNTAX string
記述Aが設定した方針を特徴付けるか、または分類するためのキーワードのNAME PolicyKeywordsは反対します。 SYNTAXストリング
6.1.3. The Property "Caption" (Inherited from ManagedElement)
6.1.3. 特性の「見出し」(ManagedElementから引き継ぐ)です。
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
この方針関連のオブジェクトのNAME Captionの記述のA1系列の記述。 SYNTAXストリング
6.1.4. The Property "Description" (Inherited from ManagedElement)
6.1.4. 特性の「記述」(ManagedElementから引き継ぐ)です。
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
この方針関連のオブジェクトのNAMEの記述の記述のA長い記述。 SYNTAXストリング
6.2. The Class "PolicyGroup"
6.2. クラス"PolicyGroup"
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かPolicyGroupsのどちらかが単一のコンテナで集められるのを可能にします。 PolicyGroupsが他のPolicyGroupsを含むとき、気持ちを抑えるPolicyGroupの堕落したケースを含む輪が許容されていません。
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.
PolicyGroupsと彼らの巣篭もり能力は以下の図5に示されます。 PolicyGroupが他のPolicyGroupsを入れ子にすることができることに注意してください。そうすれば、制限が全く兄弟PolicyGroupsの巣篭もりの深さにありません。
Moore, et al. Standards Track [Page 27] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[27ページ]。
+---------------------------------------------------+
| PolicyGroup |
| |
| +--------------------+ +-----------------+ |
| | PolicyGroup A | | PolicyGroup X | |
| | | | | |
| | +----------------+ | ooo | | |
| | | PolicyGroup A1 | | | | |
| | +----------------+ | | | |
| +--------------------+ +-----------------+ |
+---------------------------------------------------+
+---------------------------------------------------+ | PolicyGroup| | | | +--------------------+ +-----------------+ | | | PolicyGroup A| | PolicyGroup X| | | | | | | | | | +----------------+ | ooo| | | | | | PolicyGroup A1| | | | | | | +----------------+ | | | | | +--------------------+ +-----------------+ | +---------------------------------------------------+
Figure 5. Overview of the PolicyGroup class
図5。 PolicyGroupのクラスの概要
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で見せられた最高水準PolicyGroupを考えてください。 このPolicyGroupはUSEmployeeLogonPolicyと呼ばれて、1位置あたりの専門化している規則を提供する数個のPolicyGroupsに集めるかもしれません。 したがって、上の図5のPolicyGroup Aは従業員のために西海岸でログオン規則を定義するかもしれません、別のPolicyGroupが中西部(例えば、PolicyGroup 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.
また、それぞれのPolicyGroupの深さが同じである必要はないことに注意してください。 したがって、WestCoast PolicyGroupはいくつかの理由(異なった現場、サブネットの数など)のいずれによってもPolicyGroupsの数個の追加層を定義させるかもしれません。 したがって、PolicyRulesはUSEmployeeLogonPolicyGroupからのnレベルに含まれています。 中西部PolicyGroup(PolicyGroup X)とこれを比較してください。(直接、PolicyGroupはPolicyRulesを含むかもしれません)。
The class definition for PolicyGroup is as follows:
PolicyGroupのためのクラス定義は以下の通りです:
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
関連するPolicyRulesの1セットか関連するPolicyGroupsの1セットのどちらかのためのNAME PolicyGroup記述Aコンテナ。 方針の抽象的な偽の特性から派生していないなにも
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].
Policyからすべての特性を引き継ぐので、特性は全くこのクラスのために定義されません。 クラスは、PolicyRulesか他のPolicyGroupsに集めるために存在します。 それは直接instantiableです。 実装では、様々なキー/識別の特性を定義しなければなりません。 ネイティブのCIM実装のためのキーはAppendix A、セクション13.1.1で定義されます。 LDAP実装のためのキーはこの情報モデル[11]に関するLDAPマッピングで定義されるでしょう。
Moore, et al. Standards Track [Page 28] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[28ページ]。
6.3. The Class "PolicyRule"
6.3. クラス"PolicyRule"
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.
このクラスは「Conditionの当時のActionであるなら」方針に関連している意味論を表します。 ANDed条件(離接的なNormal Form、またはDNF)のORedセットかORedのANDedセットのどちらかが(接続語のNormal Form、またはCNF)を条件とさせるとき、最も一般的な意味で、PolicyRule状態は表されます。 個々の状態は、否定されたかもしれないか(Cでない)、または(C)を非否定しました。 PolicyRuleである場合にだけ(それはDNFに表されるか、そして、CNF)を条件とさせてください。そして、PolicyRuleによって指定された動作が実行されることである、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.
政策ルールに関連している状態と動作はクラスのPolicyConditionとPolicyActionのサブクラスでそれぞれモデル化されます。 これらの状態と動作オブジェクトはPolicyConditionInPolicyRuleとPolicyActionInPolicyRule集合によって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で上で例証されるように、政策ルールもより多くのある方針の期間に関連しているかもしれません、スケジュール通りに政策ルールがアクティブであって、不活発である簡単に述べて。 この場合、それはリンケージを供給するPolicyRuleValidityPeriod集合です。
A policy rule is illustrated conceptually in Figure 6. below.
政策ルールは以下の図6で概念的に例証されます。
+------------------------------------------------+
| PolicyRule |
| |
| +--------------------+ +-----------------+ |
| | PolicyCondition(s) | | PolicyAction(s) | |
| +--------------------+ +-----------------+ |
| |
| +------------------------------+ |
| | PolicyTimePeriodCondition(s) | |
| +------------------------------+ |
+------------------------------------------------+
+------------------------------------------------+ | 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
PolicyRuleのクラスは、規則のための状態がDNFかCNFにあるかを示すのに特性のConditionListTypeを使用します。 PolicyConditionInPolicyRule集合は、規則の条件式の表現を終了するために2つの追加特性を含んでいます。 これらの特性の1番目は参照をつけられた状態を1つ以上のグループに仕切る整数です、そして、2番目は参照をつけられた状態が否定されるかどうかを示すためにはブールのaです。 1
Moore, et al. Standards Track [Page 29] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[29ページ]。
example shows how ConditionListType and these two additional properties provide a unique representation of a set of conditions in either DNF or CNF.
例はConditionListTypeとこれらの2つの追加特性がどうDNFかCNFのどちらかの1セットの状態のユニークな表現を提供するかを示しています。
Suppose we have a PolicyRule that aggregates five PolicyConditions C1 through C5, with the following values in the properties of the five PolicyConditionInPolicyRule associations:
私たちがC5を通して5PolicyConditions C1に集めるPolicyRuleを持っていると仮定してください、以下の値が5つのPolicyConditionInPolicyRule協会の所有地にある状態で:
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
C1: GroupNumberは偽の1、ConditionNegated=C2と等しいです: GroupNumberは本当の1、ConditionNegated=C3と等しいです: GroupNumberは偽の1、ConditionNegated=C4と等しいです: GroupNumberは偽の2、ConditionNegated=C5と等しいです: GroupNumberは2、ConditionNegatedと= 虚偽で等しいです。
If ConditionListType = DNF, then the overall condition for the PolicyRule is:
ConditionListTypeがDNFと等しいなら、PolicyRuleのための概況は以下の通りです。
(C1 AND (NOT C2) AND C3) OR (C4 AND C5)
(C1、(NOT C2)、およびC3) OR(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、(NOT C2)またはC3) AND(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
「Conditionの当時のActionであるなら」意味論を表すための中央のクラスが政策ルールに関連づけたNAME PolicyRule記述。 方針の抽象的な偽の特性の可能にされたConditionListType RuleUsage優先権義務的なSequencedActions 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のクラスは直接instantiableです。 実現では、様々なキー/識別の特性を定義しなければなりません。 ネイティブのCIM実現のためのキーはAppendix A、セクション13.1.2で定義されます。 LDAP実現のためのキーはこの情報モデル[11]に関するLDAPマッピングで定義されるでしょう。
Moore, et al. Standards Track [Page 30] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[30ページ]。
6.3.1. The Property "Enabled"
6.3.1. 「可能にされた」特性
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.
また、特性は値の'enabledForDebug'を支持します。 状態であるなら(s)が動作を実行するのではなく、政策ルールのための状態を評価すると言われている方針状態を評価する実体は、いつ、この値が特性にあるかを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)
政策ルールが行政上可能にされるか、行政上無効にされるか、またはデバッグモードのために可能にされるかを示すNAME Enabled記述An列挙。 SYNTAX uint16 VALUESは(1)、身体障害者(2)、有効にされたenabledForDebug(3) DEFAULT VALUEを有効にしました。(1)
6.3.2. The Property "ConditionListType"
6.3.2. 特性の"ConditionListType"
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)
この政策ルールに関連している保険約款のリストが離接的な標準にあるか否かに関係なく、NAME ConditionListType記述Indicatesは(DNF)か論理積正規形(CNF)を形成します。 SYNTAX uint16 VALUES DNF(1)、CNF(2) DEFAULT VALUE DNF(1)
6.3.3. The Property "RuleUsage"
6.3.3. 特性の"RuleUsage"
This property is a free-form string that recommends how this policy should be used. The property definition is as follows:
この特性はこの方針がどう使用されるべきであるかを推薦する自由形式ストリングです。 特性の定義は以下の通りです:
Moore, et al. Standards Track [Page 31] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[31ページ]。
NAME RuleUsage
DESCRIPTION This property is used to provide guidelines on
how this policy should be used.
SYNTAX string
NAME RuleUsage記述Thisの特性は、この方針がどう使用されるべきであるかに関するガイドラインを提供するのに使用されます。 SYNTAXストリング
6.3.4. The Property "Priority"
6.3.4. 特性の「優先権」
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
他のPolicyRulesに比例してこのPolicyRuleを最優先させるための非負の整数のNAME Priority記述A。 より大きい値は、より高い優先度を示します。 SYNTAX uint16 DEFAULT VALUE0
6.3.5. The Property "Mandatory"
6.3.5. 「義務的特性の」
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.
Mandatory資産価値がTRUEであるならPolicyRuleの評価を試みなければなりません。 PolicyRuleのMandatory資産価値がFALSEであるなら、規則の評価は、「ベストエフォート型であり」、無視されるかもしれません。
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
それを示すNAME Mandatory記述A旗、PolicyConditionsの評価とPolicyActionsの実行、(状態リストがTRUEに評価する、)、必要です。 SYNTAX論理演算子DEFAULT VALUE TRUE
Moore, et al. Standards Track [Page 32] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[32ページ]。
6.3.6. The Property "SequencedActions"
6.3.6. 特性の「SequencedActions」
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:
義務的(そして、その結果、全く実行されなかった)として指定されたオーダーで1セットの機能を実行できなかったか、お勧めのオーダー(そして、そのうえ、順不同に実行できなかった)で1セットの機能を実行できなかったか、またはお勧めのオーダー(しかし、異なったオーダーでは、実行された)で1セットの機能を実行できなかったと報告しながら、適当なコードは誤り/イベント報告がいつPolicy Frameworkのために記述されるかが定義されるでしょう。 特性の定義は以下の通りです:
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)
PolicyActionInPolicyRule集合で示された動作注文を解釈する方法を示すNAME SequencedActions記述An列挙。 SYNTAX uint16 VALUES義務的な(1)、お勧めの(2)、dontCare(3) DEFAULT VALUE dontCare(3)
6.3.7. The Multi-valued Property "PolicyRoles"
6.3.7. マルチ評価された特性の「PolicyRoles」
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つの役割の組み合わせを表します。 これがマルチ評価された特性であるので、1つ以上の役割の組み合わせをただ一つの政策ルールに関連づけることができます。 各値は形式のストリングです。
<RoleName>[&&<RoleName>]*
<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のための照合順序によると)現れるところ。 特性の定義は以下の通りです:
Moore, et al. Standards Track [Page 33] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[33ページ]。
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
記述Aが設定した役割を表すストリングと役割の組み合わせのNAME PolicyRolesは政策ルールと交際しました。 各値は1つの役割の組み合わせを表します。 SYNTAXストリング
6.4. The Abstract Class "PolicyCondition"
6.4. 抽象クラス"PolicyCondition"
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では、集められる)のセットが実行されるべきであるかどうか決定することです。 個々のPolicyConditionに関して重要なすべてがPolicy Core情報Modelの目的のための、それです。それはTRUEかFALSEに評価します。 (PolicyRuleに関連している個々のPolicyConditionsがDNFかCNFのどちらかで複合式を形成するために結合されますが、以下のセクション7.6で、より詳しくこれについて、上で議論したConditionListTypeの特性を通してPolicyConditionInPolicyRule集合の特性で達成されて、上で導入されて、議論します。) また、個々の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 | | |
| | +-------------------+ | | +-----------------+ | |
| +-------------------------+ +-----------------------+ |
+---------------------------------------------------------------+
+---------------------------------------------------------------+ | DNFの保険約款| | +-------------------------+ +-----------------------+ | | | ANDリスト| | ANDリスト| | | | +-------------------+ | | +-----------------+ | | | | | PolicyCondition| | | | PolicyCondition| | | | | +-------------------+ | | +-----------------+ | | | | +-------------------+ | | +-----------------+ | | | | | PolicyCondition| | ... | | PolicyCondition| | | | | +-------------------+ | ORed| +-----------------+ | | | | ... | | ... | | | | ANDed| | ANDed| | | | +-------------------+ | | +-----------------+ | | | | | PolicyCondition| | | | PolicyCondition| | | | | +-------------------+ | | +-----------------+ | | | +-------------------------+ +-----------------------+ | +---------------------------------------------------------------+
Figure 7. Overview of Policy Conditions in DNF
図7。 DNFの保険約款の概観
Moore, et al. Standards Track [Page 34] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[34ページ]。
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にあるとき、ANDリストを形成するためにANDedである1セット以上の状態が一緒にあるのを例証します。 そして、ANDリストがTRUEに評価する、状態がTRUEに評価する成分のすべて場合にだけ。 ANDは少なくとも成分の1つである場合にだけ記載します。そして、次に、概況がTRUEに評価する、TRUEに評価します。
+---------------------------------------------------------------+
| Policy Conditions in CNF |
| +-------------------------+ +-----------------------+ |
| | OR list | | OR list | |
| | +-------------------+ | | +-----------------+ | |
| | | PolicyCondition | | | | PolicyCondition | | |
| | +-------------------+ | | +-----------------+ | |
| | +-------------------+ | | +-----------------+ | |
| | | PolicyCondition | | ... | | PolicyCondition | | |
| | +-------------------+ | ANDed | +-----------------+ | |
| | ... | | ... | |
| | ORed | | ORed | |
| | +-------------------+ | | +-----------------+ | |
| | | PolicyCondition | | | | PolicyCondition | | |
| | +-------------------+ | | +-----------------+ | |
| +-------------------------+ +-----------------------+ |
+---------------------------------------------------------------+
+---------------------------------------------------------------+ | CNFの保険約款| | +-------------------------+ +-----------------------+ | | | ORリスト| | ORリスト| | | | +-------------------+ | | +-----------------+ | | | | | PolicyCondition| | | | PolicyCondition| | | | | +-------------------+ | | +-----------------+ | | | | +-------------------+ | | +-----------------+ | | | | | PolicyCondition| | ... | | PolicyCondition| | | | | +-------------------+ | ANDed| +-----------------+ | | | | ... | | ... | | | | ORed| | ORed| | | | +-------------------+ | | +-----------------+ | | | | | PolicyCondition| | | | PolicyCondition| | | | | +-------------------+ | | +-----------------+ | | | +-------------------------+ +-----------------------+ | +---------------------------------------------------------------+
Figure 8. Overview of Policy Conditions in CNF
エイト環。 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にあります。 その結果、ORがどれについてそれぞれ記載する1つか以上がある、TRUEに関する評価、唯一、少なくとも構成している状態の1つはTRUEに評価します。 ORは成分のすべて場合にだけ記載します。そして、次に、概況が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
政策ルールに関連して評価されるべき規則特有の、または、再利用できる方針状態を表すNAME PolicyCondition記述Aのクラス。 方針の抽象的な本当の特性から派生していないなにも
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
Policyからすべての特性を引き継ぐので、特性は全くこのクラスのために定義されません。 クラスはサブクラスで定義されたドメイン特定保険証券状態のための抽象的な「スーパー-クラス」として存在します。 実現では、クラスかそのinstantiableサブクラスのために様々なキー/識別の特性を定義しなければなりません。 ネイティブのためのキー
Moore, et al. Standards Track [Page 35] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[35ページ]。
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実現はAppendix A、セクション13.2で定義されます。 LDAP実現のためのキーはこの情報モデル[11]に関するLDAPマッピングで定義されるでしょう。
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.
PolicyConditionのクラスを特定して、使用するとき、状態が規則特有であるか、または再利用できる場合があるのを覚えているのが必要です。 セクション5.1で上でこれについて議論しました。 方針の2つのタイプの区別は協会と例が参加できる、異なった例がどう命名されるかの偽りを条件とさせます。 概念的に、再利用できる方針状態は、方針倉庫に住んでいて、その倉庫の範囲の中で命名されます。 他方では、示唆という名前として、規則特有の方針状態はそれが関係づけられるただ一つの政策ルールの範囲の中で命名されます。
The distinction between rule-specific and reusable PolicyConditions affects the CIM naming, defined in Appendix A, and the LDAP mapping [11].
規則特有の、そして、再利用できるPolicyConditionsの区別はAppendix Aで定義されたCIM命名、および[11]を写像するLDAPに影響します。
6.5. The Class "PolicyTimePeriodCondition"
6.5. クラス"PolicyTimePeriodCondition"
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によって記述されないで、Policyの'ガイドライン'ドキュメント、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はPolicyConditionのサブクラスと定義されます。 これは、PolicyRuleのためのAND/OR状態定義での時間ベースの評価基準の包含を許容するためのものです。
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
このクラスの例で、最大5つの特性が異なったレベルで期間を特定するかもしれません。 例における現在のすべての特性の値は正当性を決定するために一緒にいるANDedです。
Moore, et al. Standards Track [Page 36] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[36ページ]。
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:
例のための期間。 例えば、総合的な正当性範囲の2000年12月31日までの2000年1月1日がある例。 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.
0800年から1600の2000年3月5日金曜日。 0800年から1600の2000年3月12日金曜日。 0800年から1600の2000年3月19日金曜日。 0800年から1600の2000年3月26日金曜日。 0800年から1600の2000年4月2日金曜日。 0800年から1600の2000年4月9日金曜日。 0800年から1600の2000年4月16日金曜日。 0800年から1600の2000年4月23日金曜日。 0800年から1600の2000年4月30日金曜日。
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.
特性のLocalOrUtcTimeは、政策ルールが適用されている位置か、UTC回としてPolicyTimePeriodConditionの例の他の5つの時間関連の所有地に表された回が現地時間として解釈されることになっているかどうかを示します。
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
方針を可能にするか、または無効にする能力を提供するNAME PolicyTimePeriodCondition記述Aのクラスが予定されたスケジュール通りに統治されます。 PolicyConditionの抽象的な偽の特性のTimePeriod MonthOfYearMask DayOfMonthMask DayOfWeekMask TimeOfDayMask LocalOrUtcTimeから、派生します。
Moore, et al. Standards Track [Page 37] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[37ページ]。
6.5.1. The Property "TimePeriod"
6.5.1. 特性の"TimePeriod"
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:
この特性は政策ルールが有効である総合的な範囲のカレンダ日付と倍を特定します。 それはRFC2445で定義された明白な期間、形式を再利用します。([10])に参照をつけてください: 'キャラクタ'T'が時間部分の始まりを示す始めの日時を表すストリングは終了日と時間を表す同様のストリングが支えたキャラクタ'/'というソリドゥスで続きました。 初デートは範囲の始まりを示しますが、2番目の日付は終わりを示します。 したがって、第2日時は1番目より遅いに違いありません。 日付/回はフォーム「yyyymmddThhmmss」に関するサブストリングとして言い表されます。 例えば:
20000101T080000/20000131T120000
20000101T080000/20000131T120000
January 1, 2000, 0800 through January 31, 2000, noon
2000年1月1日、2000年1月31日、正午による0800
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つがRFC2445で定義される特別なストリングに取り替えられる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.
RFC2445が明白な期間に関してこれらの2個のストリングを使用しないことに注意してください。 したがって、PCIMはRFC自身で結合されないRFC2445から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"
カレンダーの範囲が日付を入れる政策ルールが有効であるNAME TimePeriod記述。 SYNTAXストリングFORMAT yyyymmddThhmmss/yyyymmddThhmmss。(そこでは、初デート/時間をストリング"THISANDPRIOR"に取り替えるか、または2日付/回目をストリング"THISANDFUTURE"に取り替えるかもしれません)。
Moore, et al. Standards Track [Page 38] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[38ページ]。
6.5.2. The Property "MonthOfYearMask"
6.5.2. 特性の"MonthOfYearMask"
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.
この特性の目的はTimePeriodの特性によって定義される有効な期間の定義を洗練することです、明らかに、方針が有効である数カ月を指定することによって。 これらの特性は一緒に働いています、TimePeriodが方針が有効であるかもしれない全治療期間の期間を指定するのに使用されて、MonthOfYearMaskが方針が有効であるその期間中に特定の数カ月を選ぶのに使用されている状態で。
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月と共に始まって、1年の12カ月を特定する12ビットから成って、12月と共に終わって、いつも'0'に設定される4ビットに従ってサイズ2の八重奏ストリングが続いて、この特性はフォーマットされます。 毎月の間、値'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がどう1にこれなどの単一に評価された八重奏ストリングの特性を表すかに関する詳細に関してセクション5.4を見てください。 (基本的に八重奏への4八重奏の長さが結ぶCIM prepends。)
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'
政策ルールが有効である1年間の数カ月を特定するNAME MonthOfYearMask記述Aマスク。 SYNTAX八重奏ストリングFORMAT X'hh h0'
6.5.3. The Property "DayOfMonthMask"
6.5.3. 特性の"DayOfMonthMask"
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.
この特性の目的はTimePeriodの特性によって定義される有効な期間の定義を洗練することです、明らかに方針が有効である月の数日を指定することによって。 TimePeriodが方針が有効であるかもしれない全治療期間の期間を指定するのに使用されている状態で、これらの特性は一緒に働いています、そして、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ビットが支えた始めから数えながら月の数日を特定するいつも'0'に設定される2ビットが支えた31ビットから成って。 毎日の間、値'1'は、方針が当日有効であることを示します、そして、値'0'はそれが有効でないことを示します。
Moore, et al. Standards Track [Page 39] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[39ページ]。
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.
X80年00 00 01 00 00 00 00を評価してください。'、'例えば、政策ルールが1日と最後に月の日間有効であることを示します。
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.
八重奏ストリングにおける、重要な62ビットのコード化はDISMAN-SCHEDULE-MIBのschedDay物に使用されるそれに合っています。 この物に関するその他の詳細の参照[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がどう1にこれなどの単一に評価された八重奏ストリングの特性を表すかに関する詳細に関してセクション5.4を見てください。 (基本的に八重奏への4八重奏の長さが結ぶCIM prepends。)
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'
政策ルールが有効である月の数日を特定するNAME DayOfMonthMask記述Aマスク。 SYNTAX八重奏ストリングFORMAT X'hh hh hh hh hh hh hh hh'
6.5.4. The Property "DayOfWeekMask"
6.5.4. 特性の"DayOfWeekMask"
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.
この特性の目的はTimePeriodの特性によって明らかに方針が有効である1週間の数曜日を指定することによって定義される有効な期間の定義を洗練することです。 これらの特性は一緒に働いています、TimePeriodが方針が有効であるその時方針が有効であるかもしれなく、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曜日を特定する7ビットから成って、土曜日で終わって、いつも'0'に設定される1ビットに従ってサイズ1の八重奏ストリングが続いて、この特性はフォーマットされます。 1週間の毎日の間、値'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.)
CIMがどう1にこれなどの単一に評価された八重奏ストリングの特性を表すかに関する詳細に関してセクション5.4を見てください。 (基本的に八重奏への4八重奏の長さが結ぶCIM prepends。)
Moore, et al. Standards Track [Page 40] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[40ページ]。
The property definition is as follows:
特性の定義は以下の通りです:
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'
政策ルールが有効である1週間の数曜日を特定するNAME DayOfWeekMask記述Aマスク。 SYNTAX八重奏ストリングFORMAT B'bbbb bbb0'
6.5.5. The Property "TimeOfDayMask"
6.5.5. 特性の"TimeOfDayMask"
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.
この特性の目的はTimePeriodの特性によって方針が有効である1日後に明らかにさまざまな回を指定することによって定義される有効な期間の定義を洗練することです。 これらの特性は一緒に働いています、方針が有効であり、その期間の与えられた日のどの範囲の期間に方針を選ぶかに中古のTimeOfDayMaskが有効である全治療期間の期間を指定するのに使用されるTimePeriodと共に。
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".
この特性はRFC2445[10]のスタイルでフォーマットされます: 'キャラクタソリドゥスキャラクタによって後をつけられた'T'もう一度があとに続いた'/'ひもで始まる時間ストリング。 1回目は範囲の始まりを示しますが、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番目のサブストリングはいつも1時間最初のサブストリングより後半を特定します。 しかしながら、その長さの範囲に真夜中を許容するために、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日間の部品を含んでいます。 また、近いうちがMonthOfYearMask、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まで。
Moore, et al. Standards Track [Page 41] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[41ページ]。
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
NAME TimeOfDayMask記述、政策ルールが有効である回の範囲。 2回目が1番目より初期であるなら、間隔は真夜中にかかっています。 SYNTAXストリングFORMAT Thhmmss/Thhmmss
6.5.6. The Property "LocalOrUtcTime"
6.5.6. 特性の"LocalOrUtcTime"
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.
この特性は、TimePeriod所有地と様々なMask所有地に表された回が現地時間か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)
他の回がこの場合現地時間かUTC回を表すかどうかNAME LocalOrUtcTime記述Anしるし。 SYNTAX uint16 VALUES localTime(1)、utcTime(2) DEFAULT VALUE utcTime(2)
6.6. The Class "VendorPolicyCondition"
6.6. クラス"VendorPolicyCondition"
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の特性のConstraintとConstraintEncodingは状態の内容と書式を定義するのに使用されます、以下で説明されるように。
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.
名前が示すように、このクラスは業者特有の拡大のためにPolicy Core情報Modelに意図します。 標準化された拡大がこのクラスを使用しないと予想されます。
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
方針状態について説明する登録された手段を定義するNAME VendorPolicyCondition記述Aのクラス。 PolicyConditionの抽象的な偽の特性の規制[ ]ConstraintEncodingから、派生します。
Moore, et al. Standards Track [Page 42] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[42ページ]。
6.6.1. The Multi-valued Property "Constraint"
6.6.1. マルチ評価された特性の「規制」
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.
この特性は特定の性質でモデル化されていない保険約款を表すのに一般的な拡大メカニズムを提供します。 アレイの八重奏ストリングの形式はこの定義で不特定のままにされます。 値が所有地にConstraintEncodingを格納したのはOIDによって決定されます。 ConstraintEncodingが単一に評価されているので、Constraintのすべての値が同じ形式と意味論を共有します。
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.
政策決定ポイントは、それがConstraintの例にそれが認識するOIDsのセットに対してConstraintEncodingから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
特定の性質としてモデル化されていない規制を表すためのNAME Constraint記述Extensionメカニズム。 値の形式は特性のConstraintEncodingに格納されたOIDによって特定されます。 SYNTAX八重奏ストリング
6.6.2. The Property "ConstraintEncoding"
6.6.2. 特性の"ConstraintEncoding"
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.
この特性はこの場合Constraint特性の値のコード化と意味論を特定します。 独身の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
この例のConstraintの特性のために形式と意味論を特定して、ストリングとしてコード化されたNAME ConstraintEncoding記述An OID。 値が10進数字の点を打たされた系列である、(例えば、「1.2、.100、0.2インチ) OIDのアークを表す、」 ストリングのキャラクタは数字と期間の米国ASCII encodingsに対応するUCS-2キャラクタです。 SYNTAXストリング
Moore, et al. Standards Track [Page 43] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[43ページ]。
6.7. The Abstract Class "PolicyAction"
6.7. 抽象クラス"PolicyAction"
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に関連している動作にオーダーを割り当てることができます、推薦された追って指示する注文が義務的であるかどうかしるしかどんな意味でも、完全ではありません。 PolicyActionInPolicyRule集合の特性でPolicyRuleに関連している動作の注文を達成します。
The actions associated with a PolicyRule are executed if and only if the overall condition(s) of the PolicyRule evaluates to TRUE.
総合的である場合にだけPolicyRuleの(s)を条件とさせてください。そして、PolicyRuleに関連している動作が実行される、TRUEに評価します。
The class definition of PolicyAction is as follows:
PolicyActionのクラス定義は以下の通りです:
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
NAME PolicyAction記述Aは、政策ルールのための状態であるなら実行されるために規則特有の、または、再利用できる政策的措置を表しながら、属します。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].
Policyからすべての特性を引き継ぐので、特性は全くこのクラスのために定義されません。 クラスはサブクラスで定義されたドメイン特定保険証券動作のための抽象的な「スーパー-クラス」として存在します。 実現では、クラスかそのinstantiableサブクラスのために様々なキー/識別の特性を定義しなければなりません。 ネイティブのCIM実現のためのキーはAppendix A、セクション13.3で定義されます。 LDAP実現のためのキーはこの情報モデル[11]に関するLDAPマッピングで定義されるでしょう。
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.
PolicyActionのクラスを特定して、使用するとき、動作が規則特有であるか、または再利用できる場合があるのを覚えているのが必要です。 セクション5.1で上でこれについて議論しました。 協会と例が参加できる、異なった例がどう命名されるかの2つのタイプの政策的措置偽りの区別。 概念的に、再利用できる政策的措置は、方針倉庫に住んでいて、その倉庫の範囲の中で命名されます。 他方では、規則特有の方針動作はそれが関係づけられるただ一つの政策ルールの範囲の中で命名されます。
Moore, et al. Standards Track [Page 44] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[44ページ]。
The distinction between rule-specific and reusable PolicyActions affects the CIM naming, defined in Appendix A, and the LDAP mapping [11].
規則特有の、そして、再利用できるPolicyActionsの区別はAppendix Aで定義されたCIM命名、および[11]を写像するLDAPに影響します。
6.8. The Class "VendorPolicyAction"
6.8. クラス"VendorPolicyAction"
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.
このクラスの目的は特定の性質でモデル化されていない政策的措置を表すのに一般的な拡大メカニズムを提供することです。 代わりに、2の特性のActionDataとActionEncodingは動作の内容と書式を定義するのに使用されます、以下で説明されるように。
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.
名前が示すように、このクラスは業者特有の拡大のためにPolicy Core情報Modelに意図します。 標準化された拡大がこのクラスを使用しないと予想されます。
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
政策的措置について説明する登録された手段を定義するNAME VendorPolicyAction記述Aのクラス。 PolicyActionの抽象的な偽の特性のActionData[ ] ActionEncodingから、派生します。
6.8.1. The Multi-valued Property "ActionData"
6.8.1. マルチ評価された特性の"ActionData"
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.
この特性は特定の性質でモデル化されていない政策的措置を表すのに一般的な拡大メカニズムを提供します。 アレイの八重奏ストリングの形式はこの定義で不特定のままにされます。 値が所有地にActionEncodingを格納したのはOIDによって決定されます。 ActionEncodingが単一に評価されているので、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.
政策決定ポイントは、それがActionDataの例にそれが認識するOIDsのセットに対してActionEncodingからOID値をチェックすることによって格納された値を支持するかどうか容易に決定できます。 このデータの形式がそうすることができたと認めないといけないので政策決定ポイントが取る行動が政策ルールとしてモデル化されて、政策決定の振舞いを治めて、指してください。
Moore, et al. Standards Track [Page 45] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[45ページ]。
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
特定の性質としてモデル化されていない動作を表すためのNAME ActionData記述Extensionメカニズム。 値の形式は特性のActionEncodingに格納されたOIDによって特定されます。 SYNTAX八重奏ストリング
6.8.2. The Property "ActionEncoding"
6.8.2. 特性の"ActionEncoding"
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
この例のActionDataの特性のために形式と意味論を特定して、ストリングとしてコード化されたNAME ActionEncoding記述An OID。 値が10進数字の点を打たされた系列である、(例えば、「1.2、.100、0.2インチ) OIDのアークを表す、」 ストリングのキャラクタは数字と期間の米国ASCII encodingsに対応するUCS-2キャラクタです。 SYNTAXストリング
6.9. The Class "PolicyRepository"
6.9. クラス"PolicyRepository"
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
再利用できる方針関連の情報のために行政上定義された容器を表すNAME PolicyRepository記述Aのクラス。 このクラスはsuperclass AdminDomainのそれらを超えて少しの追加資産も紹介しません。 しかしながら、それは多くのユニークな協会に参加します。 AdminDomain要約から、虚偽で派生します。
7. Association and Aggregation Definitions
7. 協会と集合定義
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.
それらがCIMに使用されるとき、このセクションの最初の2つの小区分が協会と集合を導入します。 残っている小区分はPolicy Core情報Modelの一部である協会と集合のためのクラス定義を提示します。
Moore, et al. Standards Track [Page 46] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[46ページ]。
7.1. Associations
7.1. 協会
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つの物の参照箇所を通常含むクラスとしてモデル化されます。 関連するクラスのいずれにも影響しないで、クラスの間で協会を定義できます。 すなわち、協会の参加は関連するクラスのインタフェースに影響しません。
7.2. Aggregations
7.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は、システムを作るシステムとコンポーネントとの封じ込め関係を表すのに集合を使用します。 集合、しばしば含意しますが、a「全体の部分」関係は必要でないように、集合が反対するのにおいて、互いの依存があります。
7.3. The Abstract Aggregation "PolicyComponent
7.3. 抽象的な集合"PolicyComponent"
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.
この抽象的な集合は具体的な方針のクラスのPolicyGroup、PolicyRule、PolicyCondition、PolicyAction、およびPolicyTimePeriodConditionの参照になるようにそれぞれの5つのサブクラスで優越する2つの物の参照箇所を定義します。 抽象的な「スーパー-クラス」の値は、すべての5つのサブクラスには同じ「全体の部分」意味論があるのを運んで、質問の容易さがPolicyGroupか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]]
NAME PolicyComponent記述Aジェネリック集合は以前はよく'Policyのサブクラスの間の'関係の一部を確立していました。 例えば、PolicyConditionsをある集合が定義するPolicyConditionInPolicyRuleはPolicyRuleを離れさせます。 抽象的な本当の特性のGroupComponent[審判方針[0..n]]PartComponent[審判方針[0..n]]
7.4. The Aggregation "PolicyGroupInPolicyGroup"
7.4. 集合"PolicyGroupInPolicyGroup"
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
PolicyGroupInPolicyGroup集合は、方針グループが入れ子にされるのを可能にします。 複雑な方針が倍数から、より簡単な状態で構成されるのを可能にするので、スケーラビリティと管理可能性に、これは重要です。
Moore, et al. Standards Track [Page 47] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[47ページ]。
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.
管理便宜のための方針。 例えば、方針を米国に表す方針グループはそれの中で東の、そして、西の米国に方針グループを入れ子にしたかもしれません。
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:
PolicyGroupがこの集合で他のPolicyGroupsに集めるかもしれませんか、またはそれはPolicyRuleInPolicyGroup集合でPolicyRulesに集められるかもしれません。 この集合が集合のためのring structures.Theクラス定義ではなく、指示された非循環のグラフを形成するのに使用されると思われるというメモは以下の通りです:
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]]
よりハイレベルのPolicyGroupでPolicyGroupsの集合を表すNAME PolicyGroupInPolicyGroup記述Aのクラス。 PolicyComponentの抽象的な偽の特性のGroupComponent[審判PolicyGroup[0..n]]PartComponentから、派生します。[審判PolicyGroup[0..n]]
7.4.1. The Reference "GroupComponent"
7.4.1. 参照"GroupComponent"
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から引き継がれて、他の1PolicyGroupsを含むPolicyGroupの物の参照になるように無視されます。 集合のクラスPolicyGroupInPolicyGroupのどんなただ一つの例においても、この特性(すべてのReferenceの特性のような)が単一に評価されていることに注意してください。 [0..n]基数は、0、1、またはPolicyGroupを考えて、いずれも含む1PolicyGroupsがあるかもしれないのを示します。
7.4.2. The Reference "PartComponent"
7.4.2. 参照"PartComponent"
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から引き継がれて、他の1PolicyGroupsによって含まれたPolicyGroupの物の参照になるように無視されます。 集合のクラスPolicyGroupInPolicyGroupのどんなただ一つの例においても、この特性(すべてのReferenceの特性のような)が単一に評価されていることに注意してください。 [0..n]基数は、与えられたPolicyGroupが0、1、または他の1PolicyGroupsを含むかもしれないのを示します。
7.5. The Aggregation "PolicyRuleInPolicyGroup"
7.5. 集合"PolicyRuleInPolicyGroup"
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.
PolicyGroupがこの集合でPolicyRulesに集めるかもしれませんか、またはそれはPolicyGroupInPolicyGroup集合で他のPolicyGroupsに集められるかもしれません。
Moore, et al. Standards Track [Page 48] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[48ページ]。
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]]
PolicyGroupでPolicyRulesの集合を表すNAME PolicyRuleInPolicyGroup記述Aのクラス。 PolicyComponentの抽象的な偽の特性のGroupComponent[審判PolicyGroup[0..n]]PartComponentから、派生します。[審判PolicyRule[0..n]]
7.5.1. The Reference "GroupComponent"
7.5.1. 参照"GroupComponent"
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から引き継がれて、1PolicyRulesを含むPolicyGroupの物の参照になるように無視されます。 集合のクラスPolicyRuleInPolicyGroupのどんなただ一つの例においても、この特性(すべてのReferenceの特性のような)が単一に評価されていることに注意してください。 [0..n]基数は、0、1、またはPolicyRuleを考えて、いずれも含む1PolicyGroupsがあるかもしれないのを示します。
7.5.2. The Reference "PartComponent"
7.5.2. 参照"PartComponent"
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から引き継がれて、1PolicyGroupsによって含まれたPolicyRuleの物の参照になるように無視されます。 集合のクラスPolicyRuleInPolicyGroupのどんなただ一つの例においても、この特性(すべてのReferenceの特性のような)が単一に評価されていることに注意してください。 [0..n]基数は、与えられたPolicyGroupが0、1、または1PolicyRulesを含むかもしれないのを示します。
7.6. The Aggregation "PolicyConditionInPolicyRule"
7.6. 集合"PolicyConditionInPolicyRule"
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協会を通したPolicyConditionのクラスの政策ルール集合ゼロか、より多くの例。 集合が保険約款のゼロに合っているという政策ルールはクラス定義で動作の性能の「引き金となる」ことを示さなければなりません。 要するに、なにも明らかに関連づけられないので、それは内在しているPolicyConditionsについて説明しなければなりません。 例えば、クラス定義が規則の動作が実行される前に状態が「HTTP交通です」なら本当であると仮定する"HttpPolicyRule"というPolicyRuleのサブクラスがあるかもしれません。 それが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
政策ルールで集められた状態は2つのレベルのリストに分類されます: 状態のANDedセットのORedセット(DNF、デフォルト)か状態のORedセットのANDedセット(CNF)のどちらか。 これらのリストの個々の状態は否定されるかもしれません。 特性のConditionListType(PolicyRuleの)はこれらの2についてどれを指定するか。
Moore, et al. Standards Track [Page 49] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[49ページ]。
grouping schemes applies to a particular PolicyRule. The conditions are used to determine whether to perform the actions associated with the PolicyRule.
計画を分類するのは特定の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.
PolicyConditionInPolicyRule協会を通して政策ルールに関連している状態の中により多くのある方針の期間があるかもしれません。 この場合、期間は規則に指定されたいかなる他の状態と共にも評価されるべき単に追加している状態です。
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
PolicyRuleでPolicyConditionsの集合を表すNAME PolicyConditionInPolicyRule記述Aのクラス。 PolicyComponentの抽象的な偽の特性のGroupComponent[審判PolicyRule[0..n]]PartComponent[審判PolicyCondition[0..n]]GroupNumber ConditionNegatedから、派生します。
7.6.1. The Reference "GroupComponent"
7.6.1. 参照"GroupComponent"
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から引き継がれて、1PolicyConditionsを含むPolicyRuleの物の参照になるように無視されます。 集合のクラスPolicyConditionInPolicyRuleのどんなただ一つの例においても、この特性(すべてのReferenceの特性のような)が単一に評価されていることに注意してください。 [0..n]基数は、0、1、またはPolicyConditionを考えて、いずれも含む1PolicyRulesがあるかもしれないのを示します。
7.6.2. The Reference "PartComponent"
7.6.2. 参照"PartComponent"
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から引き継がれて、1PolicyRulesによって含まれたPolicyConditionの物の参照になるように無視されます。 集合のクラスPolicyConditionInPolicyRuleのどんなただ一つの例においても、この特性(すべてのReferenceの特性のような)が単一に評価されていることに注意してください。 [0..n]基数は、与えられたPolicyRuleが0、1、または1PolicyConditionsを含むかもしれないのを示します。
7.6.3. The Property "GroupNumber"
7.6.3. 特性の"GroupNumber"
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の特性によって参照をつけられる状態がGroupComponent参照で特定された政策ルールのために総合的な条件式を形成する際に配属されるグループを特定する整数を含んでいます。
Moore, et al. Standards Track [Page 50] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[50ページ]。
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
配属されるPartComponentの特性によって特定された状態がことであるグループを示すNAME GroupNumber記述Unsigned整数。 SYNTAX uint16 DEFAULT0
7.6.4. The Property "ConditionNegated"
7.6.4. 特性の"ConditionNegated"
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の特性によって参照をつけられる状態がGroupComponent参照で特定された政策ルールのために総合的な条件式を形成する際に否定されるかどうかを示して。
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
PartComponentの特性によって特定された状態が否定されるかどうかに関するNAME ConditionNegated記述Indication。 (TRUEは、状態が否定されるのを示して、FALSEは、それが否定されないのを示します。) SYNTAX論理演算子DEFAULT FALSE
7.7. The Aggregation "PolicyRuleValidityPeriod"
7.7. 集合"PolicyRuleValidityPeriod"
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より)との異なった関係はPolicyRuleValidityPeriod集合によって表されます。 後者は政策ルールの予定されている起動と非活性化について説明します。
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.
政策ルールがこの協会を通して複数の方針の期間に関連しているなら、少なくとも期間のひとりが、それがアクティブであることを示すなら、規則はアクティブです。 (言い換えれば、期間は規則がアクティブであるかどうか決定するORedです。) 方針の期間は複数の政策ルールで集められるかもしれません。 スケジューリングの観点から、この集合で方針の期間まで示されない規則はいつもアクティブです。 しかしながら、それは他の理由で不活発であるかもしれません。
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.
期間は他のアプリケーションで使用できる一般概念です。 しかしながら、それらは、方針アプリケーションで頻繁に使用されるので、ここ、この仕様で明らかに言及されます。
Moore, et al. Standards Track [Page 51] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[51ページ]。
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]]
PolicyRuleでPolicyTimePeriodConditionsの集合を表すNAME PolicyRuleValidityPeriod記述Aのクラス。 PolicyComponentの抽象的な偽の特性のGroupComponent[審判PolicyRule[0..n]]PartComponentから、派生します。[審判PolicyTimePeriodCondition[0..n]]
7.7.1. The Reference "GroupComponent"
7.7.1. 参照"GroupComponent"
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から引き継がれて、1PolicyTimePeriodConditionsを含むPolicyRuleの物の参照になるように無視されます。 集合のクラスPolicyRuleValidityPeriodのどんなただ一つの例においても、この特性(すべてのReferenceの特性のような)が単一に評価されていることに注意してください。 [0..n]基数は、0、1、またはPolicyTimePeriodConditionを考えて、いずれも含む1PolicyRulesがあるかもしれないのを示します。
7.7.2. The Reference "PartComponent"
7.7.2. 参照"PartComponent"
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から引き継がれて、1PolicyRulesによって含まれたPolicyTimePeriodConditionの物の参照になるように無視されます。 集合のクラスPolicyRuleValidityPeriodのどんなただ一つの例においても、この特性(すべてのReferenceの特性のような)が単一に評価されていることに注意してください。 [0..n]基数は、与えられたPolicyRuleが0、1、または1PolicyTimePeriodConditionsを含むかもしれないのを示します。
7.8. The Aggregation "PolicyActionInPolicyRule"
7.8. 集合"PolicyActionInPolicyRule"
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に評価します。 要するに、なにも明らかに関連づけられないので、それは内在しているPolicyActionsについて説明しなければなりません。 例えば、Diffservの絶対点滴器を表す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に関連している動作に全く与えないかもしれません。 別々の物として表された動作において、オーダーを言い表すのにPolicyActionInPolicyRule集合を使用できます。
Moore, et al. Standards Track [Page 52] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[52ページ]。
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の集合例における特性のSequencedActionsはこの指示を提供します。
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
PolicyConditionでPolicyActionsの集合を表すNAME PolicyActionInPolicyRule記述Aのクラス。 PolicyComponentの抽象的な偽の特性のGroupComponent[審判PolicyRule[0..n]]PartComponent[審判PolicyAction[0..n]]ActionOrderから、派生します。
7.8.1. The Reference "GroupComponent"
7.8.1. 参照"GroupComponent"
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から引き継がれて、1PolicyActionsを含むPolicyRuleの物の参照になるように無視されます。 集合のクラスPolicyActionInPolicyRuleのどんなただ一つの例においても、この特性(すべてのReferenceの特性のような)が単一に評価されていることに注意してください。 [0..n]基数は、0、1、またはPolicyActionを考えて、いずれも含む1PolicyRulesがあるかもしれないのを示します。
7.8.2. The Reference "PartComponent"
7.8.2. 参照"PartComponent"
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から引き継がれて、1PolicyRulesによって含まれたPolicyActionの物の参照になるように無視されます。 集合のクラスPolicyActionInPolicyRuleのどんなただ一つの例においても、この特性(すべてのReferenceの特性のような)が単一に評価されていることに注意してください。 [0..n]基数は、与えられたPolicyRuleが0、1、または1PolicyActionsを含むかもしれないのを示します。
7.8.3. The Property "ActionOrder"
7.8.3. 特性の"ActionOrder"
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.
''この特性は符号のない整数を提供します、そして、それは政策ルールに関連している動作の系列における動作の相対的な位置を示します。 'いつ、'、正の整数、動作の系列の実行されるべき場所を示します、よりわずかな整数が系列の以前の見解を示していて。 「気にかけないでください。」と、特別な値'0'は示します。 2つ以上の動作に同じ非ゼロ一連番号があるなら、それらは順不同に実行されるかもしれませんが、総合的な動作系列の適切な場所でそれらをすべて実行しなければなりません。
Moore, et al. Standards Track [Page 53] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[53ページ]。
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: 動作A2: 動作B1: 動作C3: 動作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.
2つの許容できる命令を示してください: オーダー、しかし、単に'1'位置でAかCかBかDかCと、Aと、Bと、A以来のDとCを実行できます。
o The values
o 値
0:ACTION A
2:ACTION B
3:ACTION C
3:ACTION D
0: 動作A2: 動作B3: 動作C3: 動作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.Thusに比例して見えるかもしれない動作は以下の通りです。 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
動作の系列における動作の相対的な位置を示すNAME ActionOrder記述Unsigned整数が政策ルールで集められました。 SYNTAX uint16
7.9. The Abstract Association "PolicyInSystem"
7.9. 抽象的な協会"PolicyInSystem"
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協会のクラス、Dependencyから2つの物の参照箇所を引き継ぎます。 それは、それらをクラスのSystemとPolicyの例の参照にするようにこれらの物の参照に優越します。 そして、PolicyInSystemのサブクラスは、それらを具体的な方針のクラスの参照にするように再びこれらの物の参照に優越します。
Moore, et al. Standards Track [Page 54] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[54ページ]。
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.
抽象的な「スーパー-クラス」の値は、すべてのサブクラスには同じ「依存」意味論があるのを運んで、質問の容易さがすべての方針「依存」のSystemに場所を見つけることです。 これらの依存は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]]
NAME PolicyInSystem記述Aジェネリック協会は以前はよく彼らを接待するPoliciesとSystemsとの依存関係を確立していました。 依存の抽象的な本当の特性の前例から派生している[審判システム[0 .1]]扶養家族[審判方針[0..n]]
7.10. The Weak Association "PolicyGroupInSystem"
7.10. 弱い協会"PolicyGroupInSystem"
This association links a PolicyGroup to the System in whose scope the PolicyGroup is defined.
この協会はPolicyGroupが範囲で定義されるSystemにPolicyGroupをリンクします。
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]]
PolicyGroupがSystemの範囲の中で定義されるという事実を表すNAME PolicyGroupInSystem記述Aのクラス。 PolicyInSystemの抽象的な誤った特性の前例から派生している[審判システム[1 .1]]扶養家族[審判PolicyGroup[弱い]]
7.10.1. The Reference "Antecedent"
7.10.1. 「前例」という参照
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から引き継がれて、基数を[1 .1]に制限するために無視されます。 それは1PolicyGroupsに範囲を供給するSystemの物の参照として機能します。 これが弱い協会であるので、いつもこの物の参照のための基数が1である、すなわち、PolicyGroupはちょうど1Systemの範囲の中でいつも定義されます。
7.10.2. The Reference "Dependent"
7.10.2. 「扶養家族」という参照
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
この特性は、PolicyInSystemから引き継がれて、Systemの範囲の中で定義されたPolicyGroupの物の参照になるように無視されます。 協会のクラスPolicyGroupInSystem、この特性のあらゆるただ一つの例によってそれに注意してください、(すべてのReferenceが好きです。
Moore, et al. Standards Track [Page 55] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[55ページ]。
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.
特性)、単一に評価されています。 [0..n]基数は、与えられたSystemが0、1、または範囲の中で定義された1PolicyGroupsを持っているかもしれないのを示します。
7.11. The Weak Association "PolicyRuleInSystem"
7.11. 弱い協会"PolicyRuleInSystem"
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.
PolicyGroup(または複数のPolicyGroupsに)に属すかどうかにかかわらず、PolicyRuleはSystemの範囲の中で定義されます。 この協会はPolicyRuleが範囲で定義されるSystemに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]]
PolicyRuleがSystemの範囲の中で定義されるという事実を表すNAME PolicyRuleInSystem記述Aのクラス。 PolicyInSystemの抽象的な誤った特性の前例から派生している[審判システム[1 .1]]扶養家族[審判PolicyRule[弱い]]
7.11.1. The Reference "Antecedent"
7.11.1. 「前例」という参照
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から引き継がれて、基数を[1 .1]に制限するために無視されます。 それは1PolicyRulesに範囲を供給するSystemの物の参照として機能します。 これが弱い協会であるので、いつもこの物の参照のための基数が1である、すなわち、PolicyRuleはちょうど1Systemの範囲の中でいつも定義されます。
7.11.2. The Reference "Dependent"
7.11.2. 「扶養家族」という参照
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から引き継がれて、Systemの範囲の中で定義されたPolicyRuleの物の参照になるように無視されます。 協会のクラスPolicyRuleInSystemのどんなただ一つの例においても、この特性(すべてのReferenceの特性のような)が単一に評価されていることに注意してください。 [0..n]基数は、与えられたSystemが0、1、または範囲の中で定義された1PolicyRulesを持っているかもしれないのを示します。
7.12. The Association "PolicyConditionInPolicyRepository"
7.12. 協会"PolicyConditionInPolicyRepository"
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協会を通していつも独身のPolicyRepositoryに関連します。 しかしながら、すべてのPolicyConditionsには、これは本当ではありません。規則特有の状態を表すPolicyConditionの例はこの協会を通してどんな方針倉庫にも関連しません。
Moore, et al. Standards Track [Page 56] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[56ページ]。
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]]
PolicyRepositoryでの再利用できるPolicyConditionの包含を表すNAME PolicyConditionInPolicyRepository記述Aのクラス。 PolicyInSystemの抽象的な誤った特性の前例から派生している[審判PolicyRepository[0 .1]]扶養家族[審判PolicyCondition[0..n]]
7.12.1. The Reference "Antecedent"
7.12.1. 「前例」という参照
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から引き継がれて、1PolicyConditionsを含むPolicyRepositoryの物の参照になるように無視されます。 再利用できるPolicyConditionはPolicyConditionInPolicyRepository協会を通していつもちょうど1PolicyRepositoryに関連します。 この特性のための[0 .1]基数はPolicyConditionsの2つのタイプをカバーしています: 0 規則特有のPolicyCondition、再利用できるもののための1のために。
7.12.2. The Reference "Dependent"
7.12.2. 「扶養家族」という参照
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にPolicyConditionを含んでいることの物の参照になるように無視されます。 協会のクラスPolicyConditionInPolicyRepositoryのどんなただ一つの例においても、この特性(すべてのReferenceの特性のような)が単一に評価されていることに注意してください。 [0..n]基数は、与えられたPolicyRepositoryが0、1、または1PolicyConditionsを含むかもしれないのを示します。
7.13. The Association "PolicyActionInPolicyRepository"
7.13. 協会"PolicyActionInPolicyRepository"
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.
再利用できる政策的措置はPolicyActionInPolicyRepository協会を通していつも独身のPolicyRepositoryに関連します。 しかしながら、すべてのPolicyActionsには、これは本当ではありません。規則特有の動作を表すPolicyActionの例はこの協会を通してどんな方針倉庫にも関連しません。
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]]
PolicyRepositoryでの再利用できるPolicyActionの包含を表すNAME PolicyActionInPolicyRepository記述Aのクラス。 PolicyInSystemの抽象的な誤った特性の前例から派生している[審判PolicyRepository[0 .1]]扶養家族[審判PolicyAction[0..n]]
Moore, et al. Standards Track [Page 57] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[57ページ]。
7.13.1. The Reference "Antecedent"
7.13.1. 「前例」という参照
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から引き継がれて、1PolicyActionsを含むPolicyRepositoryの物の参照になるように無視されます。 再利用できるPolicyActionはPolicyActionInPolicyRepository協会を通していつもちょうど1PolicyRepositoryに関連します。 この特性のための[0 .1]基数はPolicyActionsの2つのタイプをカバーしています: 0 規則特有のPolicyAction、再利用できるもののための1のために。
7.13.2. The Reference "Dependent"
7.13.2. 「扶養家族」という参照
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にPolicyActionを含んでいることの物の参照になるように無視されます。 協会のクラスPolicyActionInPolicyRepositoryのどんなただ一つの例においても、この特性(すべてのReferenceの特性のような)が単一に評価されていることに注意してください。 [0..n]基数は、与えられたPolicyRepositoryが0、1、または1PolicyActionsを含むかもしれないのを示します。
7.14. The Aggregation "PolicyRepositoryInPolicyRepository"
7.14. 集合"PolicyRepositoryInPolicyRepository"
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集合は、方針倉庫が入れ子にされるのを可能にします。 Systemsが他のManagedSystemElementsを含むと説明して、これが、より高い平らなCIM協会、CIM_SystemComponentに由来しています。 PoliciesがManagedSystemElementsではなく、ManagedElementsであるので、他のPolicy集合にこの「スーパー-クラス」を使用できませんでした。 この集合がリング構造ではなく、指示された非循環のグラフを形成するのに使用されると思われることに注意してください。
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"
よりハイレベルのPolicyRepositoryでPolicyRepositoriesの集合を表すNAME PolicyRepositoryInPolicyRepository記述Aのクラス。 SystemComponentの抽象的な偽の特性のGroupComponent[審判PolicyRepository[0..n]]PartComponent[審判PolicyRepository[0..n]]から派生する、7.14、.1 参照"GroupComponent"
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
この特性は、CIMのクラスSystemComponentから引き継がれて、他の1PolicyRepositoriesを含むPolicyRepositoryの物の参照になるように無視されます。 集合のクラスPolicyRepositoryInPolicyRepository、この特性のあらゆるただ一つの例によってそれに注意してください、(すべてのReferenceが好きです。
Moore, et al. Standards Track [Page 58] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[58ページ]。
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.
特性)、単一に評価されています。 [0..n]基数は、0、1、またはPolicyRepositoryを考えて、いずれも含む1PolicyRepositoriesがあるかもしれないのを示します。
7.14.2. The Reference "PartComponent"
7.14.2. 参照"PartComponent"
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から引き継がれて、他の1PolicyRepositoriesによって含まれたPolicyRepositoryの物の参照になるように無視されます。 集合のクラスPolicyRepositoryInPolicyRepositoryのどんなただ一つの例においても、この特性(すべてのReferenceの特性のような)が単一に評価されていることに注意してください。 [0..n]基数は、与えられたPolicyRepositoryが0、1、または他の1PolicyRepositoriesを含むかもしれないのを示します。
8. Intellectual Property
8. 知的所有権
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はどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。
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.
権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可がimplementersによるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、または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専務に情報を記述してください。
9. Acknowledgements
9. 承認
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
Policy Core情報Modelが本書では密接にDMTFのサービス・レベル・アグリーメントワーキンググループの仕事に基づいているので、感謝はそのワーキンググループのメンバーのためです。 このモデルのいくつかの方針のクラスが最初に、IPSec方針とQoS方針で早めの草稿に現れました。 これらの草稿の作者は、Parthaバッタチャリヤと、ロブ・アダムスと、ウィリアム・ディクソンと、ロイ・ペレイラと、ラジュRajanと、Jean-Christopheマーチンと、Sanjay Kamatと、マイケルSeeと、ラジブChaudhuryと、Dinesh Vermaと、ジョージ・パワーズと、Raj Yavatkarでした。 ある他の要素
Moore, et al. Standards Track [Page 59] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[59ページ]。
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.
ヨラムSnir、ヨラム・ランベルク、およびロンコーエンによって行われた仕事で溯源されたモデルについて。 このドキュメントの徹底的なレビューを行って、多くの役立つ提案を提供して頂いて、ハラルドAlvestrandに感謝します、そして、さらに、私たちは、ドキュメントのSecurity Considerationsとの彼らの助けのためにルイス・サンチェスとラス・マンディに感謝したいです。
10. Security Considerations
10. セキュリティ問題
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.
本書では寄贈されたPolicy Core情報Model(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は代わりにaとして概要で見られるべきです、どんな特定のモデル実装規制の如何にかかわらず。
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をこれらのドメインの1つまで広げる各ドキュメントがサブクラスに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に特定のタイプのデータモデル実装に述べられた拡張情報モデルを写像するでしょう。
Moore, et al. Standards Track [Page 60] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[60ページ]。
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 Gold Serviceをジョンに提供する実際の世界システムは、おそらく少なくとも以下のセキュリティ関連の能力とメカニズムを提供する必要があるでしょう(セキュリティの定義のための[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 そのジョンを指定する情報(例えば、特性の値と例示された関係)のためのデータの保全はQoS Gold Serviceを手に入れます、(s) ネットワーク要素が実際にそのServiceをどこに提供するかという情報が肝心のシステムに入力されるというポイントから。
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 認証とシステム管理者だけ(そして、ジョンでない他の技術者でない)がシステムの部品を離れて管理できるのを保証するAuthorizationメソッド。
Moore, et al. Standards Track [Page 61] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[61ページ]。
o An Authentication method to insure that John receives Gold
Service, and the other members of the engineering group receive
Bronze Service.
o そのジョンを保障するAuthenticationメソッドはGold Serviceを受けます、そして、工学グループの他のメンバーはBronze Serviceを受け取ります。
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.
これらはGold Serviceを提供する例の実際の世界システムに関連している要件の可能な1セットです、そして、これらを記録する適切な場所は情報モデルとQoS Policyの派生しているデータモデルの何らかの組み合わせ中でしょう。 また、データモデル各人は、これらの要件がどう満たされているかについて議論する必要があるでしょう、そのようなデータモデルに、通常利用可能なメカニズムを使用して、それが使うかもしれない特定の技術かセットの技術を考えて。
11. References
11. 参照
[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図式: 以下のDMTFウェブページのリンクを通して利用可能なバージョン2.4インチ: 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] 分配されたManagement Task Force Inc.、「一般的な情報Model(CIM)仕様、バージョン2.2、1999年6月。」 このドキュメントは以下のDMTFウェブページで利用可能です: 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] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[4] Hovey, R. and S. Bradner, "The Organizations Involved in the
IETF Standards Process", BCP 11, RFC 2028, October 1996.
[4] ハービとR.とS.ブラドナー、「IETF標準化過程にかかわる組織」、BCP11、RFC2028、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.ジャド、「ディレクトリで可能にされたネットワーク」、バージョン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プレゼンテーション、第42IETF Meeting、シカゴ(イリノイ)1998年10月。 このBOFの分は以下の位置で有効です: http://www.ietf.org/proceedings/98aug/index.html 。
[7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
[7]Yergeau、1998年1月のF.、「UTF-8、ISO10646の変換形式」RFC2279。
[8] Levi, D. and J. Schoenwaelder, "Definitions of Managed Objects
for Scheduling Management Operations", RFC 2591, May 1999.
[8]のレビ、D.、およびJ.Schoenwaelder(「スケジューリング管理操作のための管理オブジェクトの定義」、RFC2591)は1999がそうするかもしれません。
[9] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for
Policy-based Admission Control", RFC 2753, January 2000.
[9]YavatkarとR.とPendarakisとD.とR.ゲラン、「方針ベースの入場コントロールのためのフレームワーク」、RFC2753、2000年1月。
Moore, et al. Standards Track [Page 62] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[62ページ]。
[10] Dawson, F. and D. Stenerson, "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)", RFC 2445,
November 1998.
[10] ドーソンとF.とD.Stenerson、「インターネットCalendaringとスケジューリングはオブジェクト仕様(iCalendar)の芯を取る」RFC2445、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.ムーア、「方針コアLDAP図式」というR.堀は進行中で働いています。
[12] Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828, May
2000.
[12] Shirey(R.、「インターネットセキュリティ用語集」、FYI36、RFC2828)は2000がそうするかもしれません。
Note: the CIM 2.4 Schema specification is defined by the following set of MOF files, available from the following URL:
以下に注意してください。 CIM2.4Schema仕様は以下のセットの以下のURLから利用可能なMOFファイルによって定義されます:
http://www.dmtf.org/spec/CIM_Schema24/CIM_Schema24.zip
http://www.dmtf.org/spec/CIM_Schema24/CIM_Schema24.zip
Moore, et al. Standards Track [Page 63] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[63ページ]。
12. Authors' Addresses
12. 作者のアドレス
Ed Ellesson LongBoard, Inc. 2505 Meridian Pkwy, #100 Durham, NC 27713
Meridian Pkwy、エドEllessonロングボードInc.2505#100ダラム、NC 27713
Phone: +1 919-361-3230 Fax: +1 919-361-3299 EMail: eellesson@lboard.com
以下に電話をしてください。 +1 919-361-3230Fax: +1 919-361-3299 メールしてください: eellesson@lboard.com
Bob Moore IBM Corporation, BRQA/502 4205 S. Miami Blvd. Research Triangle Park, NC 27709
BRQA/5024205秒間ボブムーアIBM社、マイアミBlvd. NC リサーチトライアングル公園、27709
Phone: +1 919-254-4436 Fax: +1 919-254-6243 EMail: remoore@us.ibm.com
以下に電話をしてください。 +1 919-254-4436Fax: +1 919-254-6243 メールしてください: remoore@us.ibm.com
John Strassner Cisco Systems, Bldg 15 170 West Tasman Drive San Jose, CA 95134
ジョンStrassnerシスコシステムズ、Bldg15 170の西タスマンDriveサンノゼ、カリフォルニア 95134
Phone: +1 408-527-1069 Fax: +1 408-527-6351 EMail: johns@cisco.com
以下に電話をしてください。 +1 408-527-1069Fax: +1 408-527-6351 メールしてください: johns@cisco.com
Andrea Westerinen Cisco Systems 170 West Tasman Drive San Jose, CA 95134
アンドレアWesterinenシスコシステムズ170の西タスマン・Driveサンノゼ、カリフォルニア 95134
Phone: +1 408-853-8294 Fax: +1 408-527-6351 EMail: andreaw@cisco.com
以下に電話をしてください。 +1 408-853-8294Fax: +1 408-527-6351 メールしてください: andreaw@cisco.com
Moore, et al. Standards Track [Page 64] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[64ページ]。
13. Appendix A: Class Identification in a Native CIM Implementation
13. 付録A: ネイティブのCIM実装における階級帰属意識
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の特性が抽象的なsuperclass Policyに存在していて、その結果、instantiableサブクラスで全部で利用可能である間、CIMは、インスタンスを命名するのにこの特性を使用しません。 以下の小区分は命名がPolicy Core情報ModelのそれぞれのinstantiableのクラスのためにネイティブのCIM実装でどう扱われるかについて議論します。
Two things should be noted regarding CIM naming:
2つのことがCIM命名に関して注意されるべきです:
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]におけるAppendix F「ユニコード用法」を参照してください。
13.1. Naming Instances of PolicyGroup and PolicyRule
13.1. PolicyGroupとPolicyRuleのインスタンスを命名します。
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.
方針グループはシステムの文脈にいつも存在します。 Policy Core情報Modelでは、これはPolicyGroupとSystemの間の弱い集合PolicyGroupInSystemによってキャプチャされます。 Systemがネットワークデバイスと管理ドメインについて説明するための基底クラスとして機能することに注意してください。
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.
また、政策ルールはシステムの文脈に存在しています。 Policy Core情報Modelでは、これはPolicyRuleとSystemの間の弱い協会PolicyRuleInSystemによってキャプチャされます。
The following sections define the CIM keys for PolicyGroup and PolicyRule.
以下のセクションはPolicyGroupとPolicyRuleのためにCIMキーを定義します。
13.1.1. PolicyGroup's CIM Keys
13.1.1. PolicyGroupのCIMキー
The CIM keys of the PolicyGroup class are:
PolicyGroupのクラスのCIMキーは以下の通りです。
o SystemCreationClassName (A CIM_System key, propagated due to the
weak association, PolicyGroupInSystem)
o SystemCreationClassName(CIM_Systemキー弱い協会、PolicyGroupInSystemのため伝播されて、
Moore, et al. Standards Track [Page 65] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[65ページ]。
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] 以下のReferenceで定義されます:
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 SystemCreationClassName記述SystemCreationClassNameは命名範囲をPolicyGroupのインスタンスに提供するCIM Systemオブジェクトのクラス名を表します。 SYNTAXストリング[MaxLen256]QUALIFIERキー
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 SystemName記述SystemNameは特定のSystemオブジェクトの個人名を表します、命名範囲をPolicyGroupのインスタンスに提供して。 SYNTAXストリング[MaxLen256]QUALIFIERキー
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
PolicyGroupオブジェクトが直接例示されるなら、NAME CreationClassName記述Thisの特性は「CIM_PolicyGroup」に設定されます。 または、それは例示されるPolicyGroupサブクラスのクラス名と等しいです。 SYNTAXストリング[MaxLen256]QUALIFIERキー
NAME PolicyGroupName DESCRIPTION The identifying name of this policy group. SYNTAX string [MaxLen 256] QUALIFIER key
特定が命名するこの方針グループのNAME PolicyGroupName記述。 SYNTAXストリング[MaxLen256]QUALIFIERキー
13.1.2. PolicyRule's CIM Keys
13.1.2. PolicyRuleのCIMキー
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(主要で、弱い協会PolicyRuleInSystemによってため伝播されたCIM_System)o SystemName(主要で、弱い協会PolicyRuleInSystemによってため伝播されたCIM_System)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はクラスPolicyGroupのために定義されるように同じように働いています。 詳細に関してセクション13.1.1を見てください。
Moore, et al. Standards Track [Page 66] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[66ページ]。
The other two properties are defined in Reference [1] as follows:
他の2つの特性が[1] 以下のReferenceで定義されます:
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
PolicyRuleオブジェクトが直接例示されるなら、NAME CreationClassName記述Thisの特性は「CIM_PolicyRule」に設定されます。 または、それは例示されるPolicyRuleサブクラスのクラス名と等しいです。 SYNTAXストリング[MaxLen256]QUALIFIERキー
NAME PolicyRuleName
DESCRIPTION The identifying name of this policy rule.
SYNTAX string [MaxLen 256]
QUALIFIER key
特定が命名するこの政策ルールのNAME PolicyRuleName記述。 SYNTAXストリング[MaxLen256]QUALIFIERキー
13.2. Naming Instances of PolicyCondition and Its Subclasses
13.2. PolicyConditionのインスタンスとそのサブクラスを命名します。
The CIM keys of the PolicyCondition class are:
PolicyConditionのクラスの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つのクラス(すなわち、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との弱い協会を「シミュレートする」ために、私たちが、手動の主要な伝播と呼ぶつもりであるのが必要です。 厳密に言うと、手動の主要な伝播は全く主要な伝播ではありません。 しかし、同じくらいが(本当に同じくらい)それで主要な伝播に作用するので、名前は合います。
Moore, et al. Standards Track [Page 67] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[67ページ]。
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 |
+-----------------------------+
+------------------+ | システム| +------------------+ |CreationClassName| |名前| +------------------+ ^ P I PPPPPPPPPPPPPPPPPPPPPPPPPPPP I P +------------------+ +---------------v--------------+ | AdminDomain| | PolicyRule| +------------------+ +------------------------------+ |CreationClassName| | System.CreationClassName| |名前| | System.Name| +------------------+ | CreationClassName| ^ | PolicyRuleName| I+------------------------------+ I M I M+------------------+ M| PolicyRepository| M+------------------+ M|CreationClassName| M|名前| 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。 PolicyConditionsを命名するための手動の主要な伝播
Moore, et al. Standards Track [Page 68] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[68ページ]。
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とName)がSystemのクラスで定義されて、サブクラスのAdminDomainとPolicyRepositoryによって引き継がれるのがわかります。 PolicyRuleがSystemに弱いので、これらの2個のキーがそれに伝播されます。 また、それはそれ自身のキーのCreationClassNameとPolicyRuleNameを持っています。
A similar approach, though not automatic, is used in "manual key propagation". Here is the approach for rule-specific and reusable PolicyConditions:
自動ではありませんが、同様のアプローチは「手動の主要な伝播」に使用されます。 ここに、規則特有の、そして、再利用できる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までの伝播は、同様にPolicyConditionの基本性質という4へのPolicyRuleの4個の基本性質の値をコピーすることを伴います。 CIM仕様言語の観点から、PolicyConditionの特性のSystemNameは完全に新しい主要な特性です。 しかしながら、SystemのNameの特性との関係は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には、値が全くありません。 特別な値、「規則がありません」はこの場合これらの特性の両方に割り当てられます、PolicyConditionのこのインスタンスがどんな特定の政策ルールの範囲の中でも命名されないのを示して。
The following section defines the specific CIM keys for PolicyCondition.
以下のセクションはPolicyConditionのために特定のCIMキーを定義します。
13.2.1. PolicyCondition's CIM Keys
13.2.1. PolicyConditionのCIMキー
PolicyCondition's key properties are defined in Reference [1] as follows:
PolicyConditionの基本性質は[1] 以下のReferenceで定義されます:
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]
NAME SystemCreationClassName記述SystemCreationClassNameは命名範囲をPolicyConditionのインスタンスに提供するCIM Systemオブジェクトのクラス名を表します。 規則特有の方針状態に関しては、これは政策ルールが文脈で定義されるシステム(例えば、このインスタンスを作成したクラスの名前)のタイプです。 再利用できる方針状態において、PolicyRepositoryオブジェクトが直接例示されるなら、これは「CIM_PolicyRepository」に設定されます。 または、それは例示されるPolicyRepositoryサブクラスのクラス名と等しいです。 SYNTAXストリング[MaxLen256]
Moore, et al. Standards Track [Page 69] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[69ページ]。
QUALIFIER key
QUALIFIERキー
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
定義されて、Systemという名前がこの方針状態がだれの範囲であるかで反対させるNAME SystemName記述。 この特性はSystemオブジェクトの識別を終了します。 規則特有の方針状態に関しては、これは政策ルールが文脈で定義されるシステムのインスタンスの名前です。 再利用できる方針状態に関しては、これは方針状態を保持するPolicyRepositoryのインスタンスの名前です。 SYNTAXストリング[MaxLen256]QUALIFIERキー
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 PolicyRuleCreationClassName記述For a規則特有の方針状態、この特性は政策ルールインスタンスのクラス名を特定します。(インスタンスの範囲では、PolicyConditionのこのインスタンスが存在します)。 再利用できる方針状態において、この特性は特別な値、「規則がありません」に設定されます、PolicyConditionのこのインスタンスが1つの政策ルールにユニークでないことを示して。 SYNTAXストリング[MaxLen256]QUALIFIERキー
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 PolicyRuleName記述For a規則特有の方針状態、PolicyRuleNameはこの状態が関連しているPolicyRuleオブジェクトの識別を終了します。 再利用できる方針状態、特別な値において、「規則がありません」は、この状態が再利用できるのを示すのに使用されます。 SYNTAXストリング[MaxLen256]QUALIFIERキー
NAME CreationClassName
DESCRIPTION The class name of the PolicyCondition subclass
that is instantiated.
SYNTAX string [MaxLen 256]
QUALIFIER key
NAME CreationClassName記述、例示されるPolicyConditionサブクラスのクラス名。 SYNTAXストリング[MaxLen256]QUALIFIERキー
NAME PolicyConditionName DESCRIPTION The identifying name of this policy condition. SYNTAX string [MaxLen 256] QUALIFIER key
特定が命名するこの方針状態のNAME PolicyConditionName記述。 SYNTAXストリング[MaxLen256]QUALIFIERキー
Moore, et al. Standards Track [Page 70] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[70ページ]。
13.3. Naming Instances of PolicyAction and Its Subclasses
13.3. PolicyActionのインスタンスとそのサブクラスを命名します。
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.
命名の観点から、PolicyActionのクラスとそのサブクラスはちょうどPolicyConditionのクラスとそのサブクラスのように働いています。 詳細に関してセクション13.2と13.2.1を見てください。
Specifically, the CIM keys of PolicyAction are:
明確に、PolicyActionの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] 以下のReferenceで定義されます:
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 SystemCreationClassName記述SystemCreationClassNameは命名範囲をPolicyActionのインスタンスに提供するCIM Systemオブジェクトのクラス名を表します。 規則特有の方針動作のために、これは政策ルールが文脈で定義されるシステム(例えば、このインスタンスを作成したクラスの名前)のタイプです。 再利用できる政策的措置において、PolicyRepositoryオブジェクトが直接例示されるなら、これは「CIM_PolicyRepository」に設定されます。 または、それは例示されるPolicyRepositoryサブクラスのクラス名と等しいです。 SYNTAXストリング[MaxLen256]QUALIFIERキー
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
定義されて、Systemという名前がこの政策的措置がだれの範囲であるかで反対させるNAME SystemName記述。 この特性はSystemオブジェクトの識別を終了します。 規則特有の方針動作のために、これは政策ルールが文脈で定義されるシステムのインスタンスの名前です。 再利用できる政策的措置のために、これは政策的措置を保持するPolicyRepositoryのインスタンスの名前です。 SYNTAXストリング[MaxLen256]QUALIFIERキー
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
NAME PolicyRuleCreationClassName記述For a規則特有の方針動作、この特性は政策ルールインスタンスのクラス名を特定します、これが例証する範囲で
Moore, et al. Standards Track [Page 71] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[71ページ]。
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
PolicyActionは存在しています。 再利用できる政策的措置において、この特性は特別な値、「規則がありません」に設定されます、PolicyActionのこのインスタンスが1つの政策ルールにユニークでないことを示して。 SYNTAXストリング[MaxLen256]QUALIFIERキー
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 PolicyRuleName記述For a規則特有の方針動作、PolicyRuleNameはこの動作が関連しているPolicyRuleオブジェクトの識別を終了します。 再利用できる政策的措置、特別な値において、「規則がありません」は、この動作が再利用できるのを示すのに使用されます。 SYNTAXストリング[MaxLen256]QUALIFIERキー
NAME CreationClassName
DESCRIPTION The class name of the PolicyAction subclass that is
instantiated.
SYNTAX string [MaxLen 256]
QUALIFIER key
NAME CreationClassName記述、例示されるPolicyActionサブクラスのクラス名。 SYNTAXストリング[MaxLen256]QUALIFIERキー
NAME PolicyActionName DESCRIPTION The identifying name of this policy action. SYNTAX string [MaxLen 256] QUALIFIER key
特定が命名するこの政策的措置のNAME PolicyActionName記述。 SYNTAXストリング[MaxLen256]QUALIFIERキー
13.4. Naming Instances of PolicyRepository
13.4. PolicyRepositoryのインスタンスを命名します。
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 AdminDomainから引き継ぐ2の基本性質CreationClassNameとNameによって命名されます。 これらの特性は、実際にAdminDomainの「スーパー-クラス」、Systemで定義されて、次に、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」でなければなりません。 (読み易さにおいて、接頭語「シム_」がすべてのクラス名から本書では省略されたと思い出します。) PolicyRepository(恐らくQosPolicyRepository)のサブクラスが定義されて、例示されるなら、クラス名「CIM_QosPolicyRepository」はCreationClassNameで使用されます。
The Name property simply completes the identification of the instance of PolicyRepository.
Nameの特性は単にPolicyRepositoryのインスタンスの識別を終了します。
Moore, et al. Standards Track [Page 72] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[72ページ]。
13.5. Role of the CreationClassName Property in Naming
13.5. 命名におけるCreationClassNameの特性の役割
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=「PC1インチ」がある命名のインスタンスの両方から生じるでしょうに。 したがって、はなはだしく異なった規律からの方針管理者はこの文脈のために彼らのPolicyConditionsの命名を調整しなければならないでしょう。
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と共に、このタイプの衝突を排除できます。 それらのCreationClassNames異価を与えることによって、2つのインスタンスを区別できます。 1つのインスタンスが現在、2個のキーと同一視されています。
CreationClassName = "FrameRelayPolicyCondition" + PCName = "PC-1",
CreationClassName="FrameRelayPolicyCondition"+PCName=「PC1インチ」
while the other is identified with
もう片方が同一視されていますが
CreationClassName = "BgpPolicyCondition" + PCName = "PC-1".
CreationClassName="BgpPolicyCondition"+PCName=「PC1インチ。」
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.
Core Modelのそれぞれのinstantiableのクラスはキーとしてそれ自身のクラスの特定の主要な性質に加えてCreationClassNameの特性を含んでいます。
13.6. Object References
13.6. オブジェクト参照
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つの部品に分解します: オブジェクトマネージャと名前空間を特定する高位部分、および名前空間の中でオブジェクトインスタンスを特定するモデル道。 順番にオブジェクトクラス識別子にモデル道を分解できました、そして、1セットのキー値はそのクラスのインスタンスを特定する必要がありました。
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
オブジェクトクラス識別子がモデル道の一部であるので、CIMオブジェクト参照は強くタイプされます。 例えば、PolicyGroupInPolicyGroup協会におけるGroupComponentオブジェクト参照はPolicyGroupのインスタンス、または、aのインスタンスに示されることができるだけです。
Moore, et al. Standards Track [Page 73] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[73ページ]。
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).
PolicyGroupのサブクラス。 これをLDAPに対して対照してください:(そこでは、DN指針が完全に非タイプされます)。 それは、エントリーを特定しますが(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.
例えば、オブジェクト参照GroupComponentは、クラスPolicyのインスタンスの参照になるように抽象的な集合のクラスPolicyComponentで定義されます。 そして、PolicyComponentのサブクラスでGroupComponentのためのこのデータ型に優越します。 PolicyGroupInPolicyGroupでは、例えば、GroupComponentはPolicyGroupのインスタンスの参照になります。 しかし、PolicyConditionInPolicyRuleでは、それはPolicyRuleのインスタンスの参照になります。 もちろん、オブジェクト参照をこのくつがえすことで完全な自由がありません。 抽象的な「スーパー-クラス」と一致していたままで残っていて、PolicyComponentのサブクラスは、Policyのサブクラスの参照になるようにGroupComponentをくつがえすことができるだけです。 PolicyのクラスはPolicyComponentでのGroupComponent参照のためのジェネリック文脈です。
Moore, et al. Standards Track [Page 74] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[74ページ]。
14. Appendix B: The Core Policy MOF
14. 付録B: コア方針MOF
// ==================================================================
// 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")
// ================================================================== //タイトル: コア方針MOF仕様2.4//ファイル名: CIM_Policy24.MOF//バージョン: 2.4 //リリース: 0//記述: 以下のオブジェクトのクラスはオーダーに記載されていて、その//が前進の参照を避けるということです。 必要なオブジェクト(他のワーキンググループによる定義された//)は省略されます。 //日付: 06/27/2000//CIMCR516a--Policy//コンポーネントかPolicyInSystemの下にモデル協会を根づかせました。 //PolicyInSystem(GroupsとRoles'InSystem'と同様の)//からのサブクラスへの直っているPolicyCondition/ // PolicyActionInPolicyRepository================================================================== //作者: DMTF SLA(サービス・レベル・アグリーメント)作業部会//================================================================== // Pragmas //================================================================== #pragma Locale(「アン米国」)
// ==================================================================
// 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 "
// ================================================================== //方針//================================================================== [要約、記述( 「」 すべての「PolicyGroupなどのような方針の規則関連のサブクラスPolicy」「規則とPolicyCondition」の通有性について説明する抽象クラス。 「方針規則のすべてのインスタンス」「関連する実体はCIM_のサブクラスから作成される」「方針。」 この声明への例外、PolicyRepositoryは「「一種のCIM_Systemがどれですか?」」です。) ]、クラスCIM_Policy: CIM_ManagedElement、[記述(「この方針関連のオブジェクトのユーザフレンドリーな名前」)] CommonNameを結んでください;、[記述、(「」 分類している特殊化/「政策目的キーワードは1つの2つのタイプ: \nのものである」ための「これともう一方MOFs、またはDMTFで定義されたo Keywords」というキーワードの勢ぞろいが「. これらのキーワードがベンダーを供給する書類を空白にする」、「独立していて、」 ずっと「特徴付けている政策目的\n」でインストールから独立している「特殊化のためのoのInstallation依存するキーワード」
Moore, et al. Standards Track [Page 75] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[75ページ]。
" 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月のレビュー'」を含んでいます。 「\n、」 「このMOFは以下のキーワードを定義します」。 「」 「'構成'と、'用法'と、'セキュリティ'と、'サービス'と、「''動機づけ'、'インストール'、およびイベント'。」'未知であり'、 これら、「「概念、」 自明であり、一層の議論された「SLA/方針で、紙を空白にしてください。」です。 1つの追加キーワード、「「定義されます:、」 '方針'。 このキーワードの役割がある、「「いくつかの実装では、身元保証可能な」状態で「そうでなくないかもしれない方針関連のインスタンスを特定します」。 キーワード'POLICY'、「「NOTは互いに他のキーワードが排他的である」「指定された上」。)」 ]、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;
};
// ================================================================== // PolicyComponent //================================================================== [協会、要約、集合、記述( 「CIM_PolicyComponentは協会が以前はよくそうしていたジェネリックです」は」 「CIM_方針」のサブクラスの間の'関係の一部を「設立します'。 協会はそれを定義します。例えば、PolicyConditionInPolicyRule、「「PolicyConditionsが」 "PolicyRule"の一部である、」) ]、クラスCIM_PolicyComponent、[集合、Key、記述(「協会における親Policy」)]CIM_Policy REF GroupComponent([キー、記述(「協会における子供/パートPolicy」)]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 "
// ================================================================== // PolicyInSystem //================================================================== それらを接待してください。そして、[協会、要約、記述、(「CIM_PolicyInSystemは協会が以前はよくそうしていたジェネリックである」、「Policiesの間の依存関係を確立してください、」、「システム、これらのSystemsが」 ComputerSystemsが「Policiesが'稼働する予定である'か、または彼らが稼働しているかもしれないところのPolicyになってください」であったならそうしてもよい、「Policiesが保存される倉庫、この関係、」、「依存するCIM_Servicesの概念と同様です」。
Moore, et al. Standards Track [Page 76] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[76ページ]。
"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;
};
「HostedServiceによって定義されるCIM_Systems」「協会。」 「\n」「基数はAntecedent/システムのためのマックス(1)です」「高々1でPoliciesを接待できるだけであって以来の参照」「システムの背景。」 協会のいくつかのサブクラスがそうする、「「さらにこの定義を洗練して、」 Policies Weak「. PolicyInSystemの他のサブクラスがそうするSystems」を「任意の接待関係を定義してください。」にしてください。 それぞれに関する例、「「これらがPolicyRuleInSystemとPolicyConditionInである、」、「それぞれPolicyRepository協会、」、)、」 ]、クラスCIM_PolicyInSystem: CIM_Dependency、[(「前例」)をくつがえしてください、マックス(1)、記述(「接待しているSystem」)]CIM_System REF Antecedent([オーバーライド(「依存する」)、記述(「接待された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 "
// ================================================================== // PolicyGroup //================================================================== [記述( 「関連するPolicyGroupsの1セットのためのコンテナ」「両方ではなく、関連するPolicyRulesのセット。」 「方針」は「_CIM Systemに比例して定義されて、命名されて、分類され」て「それらの文脈を提供する」。) ]、クラスCIM_PolicyGroup: CIM_Policy、[(「CIM_System.CreationClassName」)、Key、MaxLen(256)、記述(「見ているSystemのCreationClassName」)を伝播します] ストリングSystemCreationClassName; [(「CIM_System.Name」)、Key、MaxLen(256)、記述(「見ているSystemのName」)を伝播します] ストリングSystemName; [主要なMaxLen(256)、記述、(「CreationClassNameは「このクラス、この特性の他の基本性質」で」 クラスか「サブクラスはインスタンスの作成に. 使用されるいつを使用した」名前を示します。
Moore, et al. Standards Track [Page 77] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[77ページ]。
"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;
};
「許容、」 「唯一特定されてください」へのこのクラスとそのサブクラスのすべてのインスタンス)。 ]、CreationClassNameを結んでください。 [主要なMaxLen(256)、記述(「このPolicyGroupというユーザフレンドリーな名前」) ]、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;
};
// ================================================================== // PolicyGroupInPolicyGroup //================================================================== [協会、集合、記述( 「」 1つの、または、より多くの低レベル「よりハイレベルのGroupへのPolicyGroups」に集められる関係。 「Policy、」 「グループはPolicyRulesかPolicyのどちらかに他の集めるかもしれないこと」が「分類しますが、ともに分類されるというわけではありません」。) ]、クラスCIM_PolicyGroupInPolicyGroup: CIM_PolicyComponent、[("GroupComponent")をくつがえしてください、Aggregate、記述(「他のGroupsに集めるPolicyGroup」)]CIM_PolicyGroup REF GroupComponent([("PartComponent")をくつがえしてください、記述(「PolicyGroupは別の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;
};
// ================================================================== // PolicyGroupInSystem //================================================================== それはPolicyGroupをSystemにリンクします。[協会、記述、(「協会、」 「範囲ではGroupが定義される」]、クラスCIM_PolicyGroupInSystem: CIM_PolicyInSystem、[(「前例」)をくつがえしてください、Min(1)、マックス(1)、記述(「PolicyGroupが範囲で定義されるSystem」)]CIM_System REF Antecedent([(「扶養家族」)をくつがえしてください、Weak、記述(「Systemの範囲の中で指定されたPolicyGroup」)]CIM_PolicyGroup REF Dependent)。
Moore, et al. Standards Track [Page 78] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[78ページ]。
// ==================================================================
// 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 "
// ================================================================== // PolicyRule //================================================================== 「状態は、否定されたかもしれないか(Cでない)、または(C)を非否定しました」。記述、(「最も一般的な意味には、PolicyRule状態があること」が、「'そしてConditionであるなら」「動作'意味論を表すための中央のクラスは政策ルールと交際しました」と「ORedが設定したANDed状態のどちらかとして、表した」、「(離接的なNormal Form、またはDNF)、」 ORedのANDedセット「条件(接続語のNormal Form、またはCNF)個人」、「PolicyRuleによって指定された動作は実行されることです」; 「PolicyRule状態だけである、(それがそうである、」、「DNFかCNFに表される、)、n円のn」をTRUE\に評価する、「「「PolicyRuleに関連している状態と動作」が「Policyのサブクラスでそれぞれモデル化される」、「状態とPolicyActionこれらの状態と動作」、「」 Policy「ConditionInPolicyRuleとPolicyActionInPolicyRule」によってオブジェクトがPolicyRuleのインスタンスに結ばれる、「集合\n\n」、「「「また、PolicyRuleも1つ以上の方針に関連しているかもしれない」「期間」; tスケジュールについて簡単に述べます。o CNF PolicyConditionInPolicyRule集合は」 「表現を終了する2つの追加特性」を含んでいます。または、どれ、「「政策ルールがアクティブであって、不活発であるか、この場合それ、」 「これを提供するPolicyRuleValidityPeriod集合」が「リンケージ\n\n」である、「「「PolicyRuleのクラスが特性のConditionListTypeを使用する、」、「規則のための状態がDNFにあるかを示してください、」、「「Ruleの条件式。」; これらの1番目、「「特性、」 参照箇所を仕切る整数が「参照をつけられたConditionがそうであるかどうかを示すためにはブール」の「1つか以上へのPolicyConditionsは分類します、そして、2番目はaです」である、「否定にされる」; 例がどのようにConditionListTypeとこれらを示しているか、「「CNF DNFか\n\nのどちらかのPolicyConditionsの1セット」について「2つの追加特性がユニークな表現を提供する」、「「「私たちが5に集めるPolicyRuleを持っていると仮定してください」、「以下の値」 「5PolicyConditionInPolicyRuleの特性」「協会: \n」"C1"があるPolicyConditions C1からC5; グループ数=1、誤ったConditionNegated=\n、「「C2: GroupNumber=1、本当のConditionNegated=\n」、「C3: GroupNumber=1、誤ったConditionNegated=\n、」 「C4: GroupNumber=2、誤ったConditionNegated=\n」」
Moore, et al. Standards Track [Page 79] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[79ページ]。
" 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
「C5:」 GroupNumber=2、FALSE\n ConditionNegated=\n、「「「「ConditionListTypeがDNF、当時の概況と等しい、」、「PolicyRule、: \n」が「(C1 AND(NOT C2)AND C3)か(C4 AND C5)\n\n」である、「「「他方では、ConditionListTypeがCNFと等しいなら」; 当時、「「PolicyRuleのための: \n」が「(C1 OR(NOT C2)OR C3)と(C4 OR C5)\n\n」であるという概況、「「「どちらの場合も、明白な仕様がある、」、「それが決定するためにテストされる概況、」、「働くために、PolicyActionsはPolicyRuleと交際しました」。)、」 ]、クラスCIM_PolicyRule: CIM_Policy、[(「CIM_System.CreationClassName」)、Key、MaxLen(256)、記述(「見ているSystemのCreationClassName」)を伝播します] ストリングSystemCreationClassName; [(「CIM_System.Name」)、Key、MaxLen(256)、記述(「見ているSystemのName」)を伝播します] SystemNameを結んでください。[主要なMaxLen(256)、記述( 「CreationClassNameは」 クラスか「インスタンスの作成に使用されるサブクラス」の名前を示します。 使用される、「「このクラス、この特性の他の基本性質」は「」 「唯一特定されてください。」] ストリングCreationClassNameにこのクラスとそのサブクラスのすべてのインスタンスを許容します」。 [主要なMaxLen(256)、記述(「このPolicyRuleというユーザフレンドリーな名前」)]はPolicyRuleNameを結びます。 [記述、(「このPolicyRuleが行政上そうであるかどうかを示す」、「」 「デバッグ」のために行政上可能にされるか、無効にされるか、または可能にされます。 特性に値3がある、(\"enabledFor"は「\をデバッグします」。), PolicyConditionsを評価する実体がそうである、「「しかし、Ruleのための状態を評価するよう命令される、」、「PolicyConditionsであるなら動作を実行する、評価、」、「」 「方針が事項で何を実行するか決定してください」に「状態を変えるためにどんな行動も取ることのないシナリオ」を試みるとき. これがデバッグ乗り物として役立つTRUEは「. デバッグの間のデフォルトが、評価する1です」。
Moore, et al. Standards Track [Page 80] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[80ページ]。
(\"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インチ、「可能にされ」て、「障害がある」"enabledForDebug"] uint16が可能にした値、」、。 [記述、(「表示、PolicyConditions」 「これに関連づけられて、PolicyRuleはコネ離接的である」「標準フォーム(DNF)か接続語の標準フォーム(CNF)」のリスト。 「デフォルト値は1(\「DNF\」)です」)、ValueMap、「1インチ、「2インチ、値"DNF"、"CNF"] uint16 ConditionListType;、」 [記述、(「」 「このPolicyRuleがどう使用されるべきであるかに関するガイドライン」を提供するのに使用できる自由形式ストリング)。 ]、RuleUsageを結んでください。 [記述( 「これを最優先させるための非負の整数Policy」は「他のRulesに比例して、統治します」。 より大きい値、「「より高い優先度を示す、」 「デフォルト値は0です」。) ]、uint16 Priority。 [記述( 「それを示す旗、Policyの評価、」、「PolicyActionsの状態と実行、(」、「状態はTRUEに評価します」。) 必要です。 「「」 「義務的な資産価値はTRUEである」ならa PolicyRuleの評価を試みなければなりません。 「当時、特性はFALSE、Ruleの評価です。」Mandatoryである、「「'ベストエフォート型であり'、無視されるかもしれない」、)、」 ]、論理演算子Mandatory。 [記述( 「この特性は方針管理者に道を与える」、「その方法を指定する、PolicyActionsの注文、」 「このPolicyRuleに関連しているのは、解釈されることです」。 「「3つの値が支持されます:、\n」、「o義務的である、(1インチ): 「注文しないでください、または. \nでそれらをしないでください。」表示で動作してください、「「oは(2)を推薦しました」。 表示で動作してください、「「注文できて、これでそれらができないなら、注文してください」、「注文してくださいといって、することができるなら別のオーダーでそれらをしてください、\n」、「o dontCare(3):」 「. \nを命令してください。」それらをしてください--私が気にかけない、「「デフォルト値は3(\「dontCare\」)である」、)、」
Moore, et al. Standards Track [Page 81] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[81ページ]。
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 [];
};
ValueMap、「1インチ、「2インチ、「3インチ、「義務的で」、「お勧め」の"dontCare"] 値のuint16 SequencedActions、」、。 [記述( 「この特性は役割と役割の組み合わせを表すこと」は「PolicyRuleと、交際しました」。 各値が1を表す、「「役割か役割の組み合わせ。」 「1つ以上の特性、役割または組み合わせが関連している場合があります」。これ、aがマルチ貴重である、「「シングルで、方針は統治します」。 各値がストリングである、「「フォーム: \n」、「<RoleName>、[<RoleName>] 「個々の役割の名はアルファベット順に現れる」*\n」、「(UCS-2のための照合順序によると)、」、」) ]、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;
};
// ================================================================== // PolicyRuleInPolicyGroup //================================================================== [協会、集合、記述( 「PolicyGroup」への「1つに集められる関係か、より多くのPolicyRules。」 PolicyGroupは「「両方ではなく、PolicyRulesか他のPolicyGroups。」」を集めるかもしれません。) ]、クラスCIM_PolicyRuleInPolicyGroup: CIM_PolicyComponent、[("GroupComponent")をくつがえしてください、Aggregate、記述(「1PolicyRulesに集めるPolicyGroup」)]CIM_PolicyGroup REF GroupComponent([("PartComponent")をくつがえしてください、記述(「PolicyRuleは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 (
// ================================================================== // PolicyRuleInSystem //================================================================== それはPolicyRuleをSystemにリンクします。[協会、記述、(「協会、」 「範囲ではRuleが定義される」]、クラスCIM_PolicyRuleInSystem: CIM_PolicyInSystem、[(「前例」)、分(1)、マックス(1)、記述をくつがえしてください、(
Moore, et al. Standards Track [Page 82] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[82ページ]。
"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;
};
「PolicyRuleが範囲で定義されるSystem」。) ]、CIM_システム審判前例。 [オーバーライド(「依存する」)、Weak、記述(「Systemの範囲の中で指定されたPolicyRule」) ]、CIM_PolicyRule審判の扶養家族。 };
// ==================================================================
// 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
{
};
// ================================================================== // PolicyRepository //================================================================== [記述( 「」 行政上定義された「再利用できる方針関連の情報のための容器」を表すクラス。 「「このクラスはどんな」 「「スーパー-クラス」のそれらを超えた特性」追加"AdminDomain"も導入しません。 しかしながら、それは「「ユニークな協会の数。」」に参加します。 n円n」、「このクラスの例はNameFormat値を使用します」。「\、「AdminDomainで定義される\「PolicyRepository\」」は「属します」。) ]、クラス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;
};
// ================================================================== // PolicyRepositoryInPolicyRepository //================================================================== [協会、Aggregation、記述、(「」 1つの、または、より多くの低レベル「よりハイレベルのRepositoryへのPolicyRepositories」に集められる関係] クラスCIM_PolicyRepositoryInPolicyRepository: CIM_SystemComponent、[("GroupComponent")をくつがえしてください、Aggregate、記述(「他のRepositoriesに集めるPolicyRepository」)]CIM_PolicyRepository REF GroupComponent([("PartComponent")をくつがえしてください、記述(「PolicyRepositoryは別のRepositoryで集めました」。)]CIM_PolicyRepository REF PartComponent)。
// ==================================================================
// ==================================================================
Moore, et al. Standards Track [Page 83] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[83ページ]。
// 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 (
// PolicyCondition //================================================================== [要約、記述( 「規則特有の、または、再利用できる方針を表すクラス」「Policyに関連して評価されるべき状態」「規則。」 PolicyConditionのすべての操作上の細部、「「この物、このクラスのサブクラスに、」 「要約」があるならである」) ]、クラスCIM_PolicyCondition: CIM_方針[主要なMaxLen(256)、記述( 「この特性は、中でSystem物を特定するのを助けます」。「クラスかサブクラスの名前が中で使用した、」、「Systemの創造が範囲で反対する、これ、」、「PolicyConditionが定義される. \n円n」、「「「これが例証するPolicyConditionの範囲は存在する」。 「規則特有のPolicyConditionに関して、これはSystemです。」「「だれの文脈に、PolicyRuleは定義されますか?」 a、「「再利用できるPolicyCondition、これが例である、」、「PolicyRepository、(Systemのサブクラスです) それ、」、「. 状態が\n\nであることを保持する」、「「「それに注意してください、この特性、および類似の特性、」、「SystemName、」 「クラスSystemの例」から伝播されたキーを表さないでください。 または、を通して代わりに、それらがそうである、「「このクラスの文脈で定義された特性、どれ、」、「Systemの例からの値を繰り返すか、どれ、」、「このPolicyConditionが直接関係づけられるか、」、「PolicyConditionInPolicyRepository集合、間接的に」、「PolicyConditionInPolicyRule集合で」、」) ]、SystemCreationClassNameを結んでください。[主要なMaxLen(256)、記述( 「Systemという名前が範囲で反対する、これ、」、「PolicyConditionが定義される. \n円n」、「「「この特性はSystemの識別を終了する」という「存在「中のこれが範囲を例証するPolicyConditionの物」」。 規則特有のPolicyConditionに関して、これがそうである、「「PolicyRuleが文脈で定義されるシステム。」 a、「「再利用できるPolicyCondition、これが例である、」、「PolicyRepository、(Systemのサブクラスです) それ、」、「状態を保持する、」、」) ]、ストリングSystemName; [主要なMaxLen(256)、記述、(
Moore, et al. Standards Track [Page 84] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[84ページ]。
"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;
};
「規則特有のPolicyConditionのために」、「PolicyRuleのCreationClassNameは」 どの「関連づけられたこのCondition」と共に反対するか。 「再利用できるPolicy」「'状態、特別な値、NO RULE'が使用されているべきである、」、「表示、このConditionが再利用できますが、」 「a独身のPolicyRuleに関連すること」は再利用できません)。 ]、PolicyRuleCreationClassNameを結んでください。 [主要なMaxLen(256)、記述( 「規則特有のPolicyCondition、」 「このConditionがそうであるPolicyRuleは反対する」「関連づけられた」名前のために。 再利用できるPolicyCondition、「「'特別な値、NO RULE'は示すのにおいて使用されているべきであること」に関しては、「このConditionは再利用できて関連していない」、「aで、PolicyRuleを選抜してください。」)、」 ]、PolicyRuleNameを結んでください。 [主要なMaxLen(256)、記述( 「CreationClassNameは」 クラスか「例の創造に使用されるサブクラス」の名前を示します。 使用される、「「このクラス、この特性の他の基本性質」、「許容、」 「唯一特定されてください。」へのこのクラスとそのサブクラスのすべての例)、」 ]、CreationClassNameを結んでください。 [主要なMaxLen(256)、記述(「このPolicyConditionというユーザフレンドリーな名前」) ]、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"
// ================================================================== // PolicyConditionInPolicyRule //================================================================== 協会、集合; 記述、(「A PolicyRule集合がゼロに合わせるか、「協会集合ゼロConditionsはRuleです」にもかかわらず、または以上が」 「PolicyConditionは属します、PolicyConditionInPolicyRuleを通して」例証する、「有効である、--、しかしながら、それがあるかもしれない」 「PolicyRepositoryかa System注意のために定義される」、あることの途中に入られた「それが有効になるまでPolicyRuleが効き目があるはずがない、\n円n」、「」; 「PolicyRuleによって集められたConditionsがそうである、」 「2つのレベルのリスト: ORedがANDedセットをセットしたどちらか」に分類された「条件(DNF、デフォルト)か1つのANDedセットのORedはセットする」「条件(CNF)これらの個々のPolicyConditions」、「リストが否定されるかもしれない、特性のConditionListType、」、「計画を分類するとこれらの2のどれが」 「特定のPolicyRule\n\n」に適用されるかを指定します。
Moore, et al. Standards Track [Page 85] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[85ページ]。
" "
"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;
};
「「「どちらかの場合PolicyConditionsが決定するのにおいて使用されている、」 「PolicyActionsを実行するのは. \n\nをPolicyRuleに関連づけた」、「「「」 「Policyを通してPolicyRuleに関連している状態」「ConditionInPolicyRule協会」の中に1PolicyTimePeriodConditionsがあるかもしれません。 「期間は評価されるべき単に追加しているConditionsです。」この場合時間、「「どんな他のものと共にも、それはRuleに指定されます」。 ") ]、クラスCIM_PolicyConditionInPolicyRule: CIM_PolicyComponent{ [("GroupComponent")をくつがえしてください、Aggregate、記述、(「この特性がPolicyRuleを表す、それ、」 「1PolicyConditionsを含んでいる」、]、CIM_PolicyRule REF GroupComponent。 [("PartComponent")をくつがえしてください、記述(「この特性はPolicyConditionという名前を保持します」「1PolicyRulesによって含まれていた」)] CIM_PolicyCondition REF PartComponent。 [記述( 「符号のない整数、」 どの「ContainedConditionによって特定されたPolicyCondition」にグループを示して、「特性は属します」。 この整数がConditionsを区分する、「「ANDedセット、(ConditionListTypeである、」 「\「DNF\」」です。) 「同様に、ORedがセットする、(Conditionである、」 「評価されて、その時、ListTypeは\です」] uint16 GroupNumber。[記述( 「指示、」 「ContainedConditionの特性は否定されること」によって特定されたCondition。 TRUE、「「PolicyConditionが否定されるのを示す、FALSE、」、「それが否定されないのを示す、」、]、論理演算子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, "
// ================================================================== // PolicyConditionInPolicyRepository //================================================================== Aは、接待を表しながら、属します。[協会、記述、(「」 再利用できる「PolicyRepository再利用できるPolicyによるPolicyConditions」では、「状態はいつも独身のPolicyRepositoryに関連します」。
Moore, et al. Standards Track [Page 86] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[86ページ]。
"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;
};
この集合を通して「. \n円n」、「「「」 PolicyCondition缶の例が「再利用できるか規則特有」であるというメモ。 「Conditionが規則であるときに」「特定であることで、いずれにもそれに関連しないものとする」「PolicyConditionInPolicyRepositoryを通したPolicyRepository」「集合」。) ]、クラスCIM_PolicyConditionInPolicyRepository: CIM_PolicyInSystem{ [オーバーライド(「前例」)、マックス(1)、記述( 「この特性はPolicyRepositoryを特定する」という「接待1PolicyConditions。」 再利用できるA、「「PolicyConditionはいつもちょうど1つに関連する」「PolicyConditionInPolicyRepositoryを通したPolicyRepository」「集合。」 [0。1] この特性のための基数、「「2つのタイプのカバーPolicyConditions:」 aのための0、「「規則特有のPolicyCondition、再利用できるもののための1」。]、CIM_PolicyRepository REF Antecedent、」、。 [オーバーライド(「依存する」)、記述( 「この特性はPolicyConditionという名前を保持すること」が「PolicyRepositoryでは、接待しました」。 「]、CIM_PolicyCondition審判の扶養家族、」、。 };
// ==================================================================
// 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 "
// ================================================================== // PolicyTimePeriodCondition //================================================================== 「このクラスは時間を表す手段を提供します」。PolicyRuleは効き目がありません。記述、(「PolicyRuleがどれであるか間、有効で、すなわち、アクティブな期間」、「いつも、それがこれらの期間をそらせる、」、「Ruleが」 有効な「そうしないなら、時に、aを指定してください」として扱われる、「PolicyTimePeriodCondition\n\n」、「「「Policy Consumerが働くために必要とするかもしれないいくつかのケース」では、「a PolicyRuleであるときに、確信しているセットアップ/クリーンアップ動作はなります」; Ruleが不活発になったら、降ろされてください。「アクティブであるか不活発である. 例えば、」 「Ruleがそうでしたが、設立されて、能動態は必要があったかもしれない」セッション、「」 他の「ケース、しかしながら、そのようなセッションは. コネへの左がこれであるならそうするでしょうに」の「ケース、PolicyRuleがそうする非活性化の効果」が「ただ、新しいセッション\n\nの設立を防ぐことであることになっている」、「「「有効期間のセットアップ/クリーンアップの振舞い」」
Moore, et al. Standards Track [Page 87] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[87ページ]。
"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 (
」 「変遷は現在、Policyによって記述されないこと」を「モデル化して、'ガイドラインで指定しなければならない'というドキュメントか「CIM_PolicyRule、CIM_PolicyTimePeriodのサブクラスを通して」が「CIM_Policyのサブクラスは条件とするか、または別、具体的です」。 「「そのような振舞いは、方針のコントロールの下にある必要がある」、「管理者、このコントロールを許す当時のaメカニズム」、「また、サブクラスで指定しなければならない、\n円n」、「「「PolicyTimePeriodConditionは」 "PolicyCondition"のサブクラスと定義されます。 「このクラスの例は5つの特性まで持っているかもしれません」。これが包含を許容するためのものである、「「PolicyRule\n\n」の「AND/OR状態定義における時間ベースの評価基準」、「「「異なったレベルで期間を特定すること」。 値、「「すべてでは、例における現在の特性はANDedである」、「」 「例」のために有効期間を決定するために一緒にいる。 例えば、例、総合的である、「「正当性は12月31日に2000年1月1日を通じて及ぶ」「2000」 3月、4月を選択する月のマスク。 「「金曜日を選択する曜日のマスク」 そして、時間、「「日では、0800年から1600年の範囲は表されるだろうこと」が「次の期間: \nを使用する」、「0800年から1600の2000年3月5日金曜日;、\n」、「0800年から1600の2000年3月12日金曜日;、\n」、「0800年から1600の2000年3月19日金曜日;、\n、」 「0800年から1600の2000年3月26日金曜日」; \n、「「0800年から1600の2000年4月2日金曜日;、\n」、「0800年から1600の2000年4月9日金曜日;、\n」、「0800年から1600の2000年4月16日金曜日;、\n」、「0800年から1600の2000年4月23日金曜日;、\n、」 「0800年から1600の2000年4月30日金曜日。」; 「\n\n」、「「「特性は」 「PolicyTimePeriodConditionはそれとなく有として扱われる」例でいつも可能にされた「それらの値'を提示'ではありません」。 このようにして、上記の例で「「月の日のマスクが存在していなくて、そのように、」、「例のための有効期間はそれとなく」 「月のすべての日を選択する月の日のマスク」を含んでいます。 「「この'なくなった特性であるなら'規則は十二分に適用された私たちです」は「そのa Policyを示す2番目の方法があるのがわかります」。「可能にされて、いつも規則はそうです」 それによる例を関連づける、「「PolicyTimePeriodCondition、」 「特定の値は基本性質であること」がある唯一の特性)、」 ]、クラスCIM_PolicyTimePeriodCondition: CIM_PolicyCondition、[記述、(
Moore, et al. Standards Track [Page 88] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[88ページ]。
" 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"
「この特性は総合的な範囲のカレンダーを特定します」。「PolicyRuleがどれであるかの上で有効な期日と回。」 'それが「「始めを表すストリングとしてフォーマットされて、デートしてください、そして、調節してください」は「どのキャラクタ't'で、」 「ソリドゥスキャラクタによって後をつけられた時間部分'/の始まりを示す'」である、「」 終了日を表す同様のストリングと「時間」までには、続かれています。 初デートが範囲の始まりを示す、「「2番目の日付が終わりを示しますが」 その結果、2番目、「「日時は1番目より遅いに違いありません」。 日付/回がそうである、「「フォームyyyymmddThhmmssに関するサブストリングとして言い表される」。 「「例:」 「\n」、「20000101T080000/20000131T120000が\nを定義する、」 「2000年1月1日、2000年1月31日までの0800、正午の\n\n」、「「「また、2つの特別なケースが」 「RFC2445」で「日付/時間ストリングを定義される特別なストリングに取り替える」どれにあるか; 指してください。'\n、「「1日付/回目の間のo Ifを」 ストリング「'THISANDPRIOR'に取り替えて、次に、特性はそのaを示す」、「日付/が調節されるまで、PolicyRuleは現在、有効である」「それが'/'の後に現れる、\n」、「2日付/回目の間のo Ifを」 ストリング「'THISANDFUTURE'に取り替えて、次に、特性が「PolicyRuleは/がそれを調節する日付に有効になること」が「'/'、およびそれから有効な残りの前に現れる」そのa」を示す、「オンである、」 「)、ModelCorrespondence、「CIM_PolicyTimePeriodCondition.MonthOfYearMask」、「CIM_PolicyTimePeriodCondition.DayOfMonthMask」「CIM_PolicyTimePeriodCondition.DayOfWeekMask」、「CIM_PolicyTimePeriodCondition.TimeOfDayMask」「CIM_PolicyTimePeriodCondition.LocalOrUtcTime」、]、TimePeriodを結んでください、」、。 [Octetstring、記述、(「この特性の目的は有効な時間を洗練することです」という「有効「TimePeriodの特性によって定義される期間」「明らかに、PolicyRuleがどの数カ月であるか、指定します」」。 これらの特性が一緒に働いている、「「TimePeriodは以前はよく全治療期間の期間を指定していた」、「どれ、PolicyRuleが有効であり、MonthOfYearMaskが」 「外では. \n\nをRuleが有効である数カ月に選ぶこと」を使用したか、「「「この特性は八重奏ストリングとしてフォーマットされます、構造化されて」「以下の通り、: \n」、「○ 」 「全体の八重奏ストリング」の長さを示す4八重奏の長さの分野 この分野はいつも「「この特性; 0×00000006\n」」に設定されます。
Moore, et al. Standards Track [Page 89] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[89ページ]。
" 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 "
「○ 12ビットの」 「1年の12カ月、」 1月と共に始まって、「いつもセットされ'て、「4ビットが支えた12月に伴う終わり」である0'を特定する2八重奏の分野の成ること。」 そして、毎月、値'1'、「「方針がその月に有効であることを示す、」、「値'0'が、それが有効でないことを示す、\n円n」、「「「例えば、値0x000000060830が」 その「PolicyRuleは単に何カ月もの5月に有効です、11月」と「12月\n\n」を示す、「「「この特性のための値は提供されないかどうか」; そして、当時、「「PolicyRuleが有効であるとしてすべての12カ月扱われる、」、「」 TimePeriod資産価値と「他のMaskの特性」によって制限されるだけである、)、ModelCorrespondence、「CIM_PolicyTimePeriodCondition.TimePeriod」、「CIM_PolicyTimePeriodCondition.LocalOrUtcTime」uint8 MonthOfYearMask、」、。 それはTimePeriodの特性によって定義されます。[Octetstring、記述、(「この特性の目的は有効な時間を洗練することである」、「以上、」 「明らかに、どの数日の月の間、Policyを指定し」て、「規則は有効です」。 これらの特性が一緒に働いている、「「PolicyRuleは有効であって、使用されるDayOfMonthMaskである」「全治療期間の期間を指定するのに使用されるTimePeriod」、「月が外で日を選ぶ、どれ、Rule、」、「有効であるか. \n円n」、「「「この特性は八重奏ストリングとしてフォーマットされます、構造化されて」「以下の通り、: \n」、「○ 」 「全体の八重奏ストリング」の長さを示す4八重奏の長さの分野 この分野がいつも設定される、「「この特性のための0x0000000C」 「\n、」 「始めから数える月の数日」「○ 8八重奏が31ビット特定の成ることをさばく」、「数日を特定するもう31ビットに従って続く、」、「月、終わりから数えて、」 2ビットに従ってその「'0'にはいつもセットがであること」に続きます。 毎日、値'1'、「「」 当日、「値'0'は、それが有効でないことを示すこと」に、方針が有効であることを示します。 「\n\n」、「「「例えば、0x0000000C8000000100000000を評価してください、」、「PolicyRuleが」 1番目と「月の最後の数日\n\n」で有効であることを示す、「「「31日間未満、ケタ対応がある何カ月も」」
Moore, et al. Standards Track [Page 90] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[90ページ]。
"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 "
そして、そして、「数カ月が持っていない何日も(両方で数える、」、「指示)、無視される. \n円n」、「「「次に、この特性のための値が提供されない、」、「PolicyRuleが有効であるとして月のすべての日間、扱われる、」、「TimePeriod資産価値によって制限されるだけである、」、「他のMaskの特性」)、ModelCorrespondence、「CIM_PolicyTimePeriodCondition.TimePeriod」、「CIM_PolicyTimePeriodCondition.LocalOrUtcTime」]、uint8 DayOfMonthMask[];、」 [Octetstring、記述( それはTimePeriodの特性によって定義されます。「この特性の目的は有効な時間を洗練することです」、「以上、」 「明らかに、どの数日の月の間、Policyを指定し」て、「規則は有効です」。 これらの特性が一緒に働いている、「「PolicyRuleは有効であって、使用されるDayOfWeekMaskである」「全治療期間の期間を指定するのに使用されるTimePeriod」、「1週間が外で日を選ぶ、どれ、Rule、」、「有効であるか. \n円n」、「「「この特性は八重奏ストリングとしてフォーマットされます、構造化されて」「以下の通り、: \n」、「○ 」 「全体の八重奏ストリング」の長さを示す4八重奏の長さの分野 「○ 1八重奏が7を特定する7ビットの成ることをさばきます」。この分野がいつも設定される、「「この特性; 0×00000005\n」、「1週間と日曜日で始まって、」 「それがいつも設定される1ビットが支えた土曜日'0がある結末のときに日'、」 「「1週間の毎日、値'1'はその」 「当日、および値に、方針は有効であり'0を示す」、「それが有効でないことを示す、」 「\n\n」、「「「例えば、値の0x000000057Cはそのaを示す」、「PolicyRule、有効な月曜日から金曜日\がn円のn」である、「「「」 この特性のための値がaであるなら提供されないで、その時が「PolicyRuleは有効であるとして週のすべての曜日間、扱われます」である、「そして、」 TimePeriod資産価値と「他のMaskの特性」によって制限されているだけである、)、ModelCorrespondence、「CIM_PolicyTimePeriodCondition.TimePeriod」、「CIM_PolicyTimePeriodCondition.LocalOrUtcTime」]、uint8 DayOfWeekMask[];、」 [記述、(「この特性の目的は有効な時間を洗練することです」。
Moore, et al. Standards Track [Page 91] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[91ページ]。
"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 "
「TimePeriodの特性によって定義される期間」、「1日後にさまざまな回明らかに指定する、どれ、」 「PolicyRuleは有効であるか」。 これらの特性が働いている、「「一緒にいTimePeriodが総合的を指定するのに使用されている状態で」、「」 PolicyRuleが有効である期間、「TimeOfDayMaskは以前は外でよく期間の範囲を選んでいた」、「有効のRuleがどのであるか与えられた日に」 「\n\n」、「「「この特性はRFC2445のスタイルでフォーマットされます」。 '「「時間は」 「ソリドゥスキャラクタ'/があとに続いたキャラクタ'T'を始めに通します'、もう一度があとに続いていてストリング。」 「「」 1回目は範囲の始まりを示しますが、「2回目は終わりを示すこと」。 回は「「フォーム'Thhmmssに関するサブストリング'」として言い表されます。 「\n\n」、「「「2番目のサブストリングはいつも1時間」 「最初のサブストリング」より後半を特定します。 その長さの範囲を考慮する、「「真夜中、しかしながら、2番目のストリングの値はそうです」、「最初のサブストリングの値より小さい」。 したがって、「'T210000/T080000です'の間、」 2100年から「0800年の次の日」まで「「'T080000/T210000'は0800年から2100年まで範囲を特定すること」を範囲を特定します。 「\n\n」、「「「定義上範囲がいつ真夜中にかかるかを含んでいること」は「連続した2日間離れています」。 近いうちがいつか、「「また、」 MonthOfYearMask、「DayOfMonthMask、そして/または、DayOfWeekMask、しかし、先日があること」が選択される、「その時、方針は」 「選択された日に当たる範囲」の部分だけの間アクティブです。 例えば、「「範囲が2100年から0800、および」 「次の3回の間隔: \nの間、アクティブな」「週のマスクは月曜日と火曜日を選択して、次に、方針がある」日まで広がっている、「0800年までの日曜日の月曜日の真夜中から;、」 「2100年の月曜日から0800年の火曜日」までの「\n」。 「2100年の火曜日から火曜日の23:59:59」までの「\n。」 「\n\n」、「「「」 この特性のための値がaであるなら提供されないで、その時が「PolicyRuleは1日の尋常でない時間に有効であるとして扱われます」である、「そして、」 TimePeriod資産価値と「他のMaskの特性」によって制限されているだけである、)、ModelCorrespondence、「CIM_PolicyTimePeriodCondition.TimePeriod」、「CIM_PolicyTimePeriodCondition.LocalOrUtcTime」] TimeOfDayMaskを結んでください;、」 [記述、(「この特性は、回が」 「TimePeriodの特性とさまざまなMask」を表したかどうかを示します。
Moore, et al. Standards Track [Page 92] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[92ページ]。
"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;
};
「特性は現地時間かUTC回を表します。」 ある、「「現地時間、UTC回を混合することへの支給がありません:」 「「この属性の価値はもう片方のすべてに適用される」「時間関連の特性」。)、ValueMap、「1インチ、「2インチ、値「ローカルタイム」、"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;
};
// ================================================================== // PolicyRuleValidityPeriod //================================================================== [協会、集合、記述( 「集合が表すPolicyRuleValidityPeriod」は「PolicyRuleの起動と非活性化の計画をしました」。 「「PolicyRuleは複数の方針回に関連している」、「この協会を通した期間、その時、Ruleが」 「少なくとも期間のひとりは、それがそうであることを示す」という「能動態」であるならアクティブです。 (言い換えれば、PolicyTimePeriodConditions、「「Ruleがアクティブであるかどうか決定するORed)、」 「Time、」 「期間は複数のPolicyRulesによって集められるかもしれません」。 Rule、「「それは」 この「協会は観点からのスケジューリングのものであること」を通して「いつも能動態」をPolicyTimePeriodConditionに指しません。 しかしながら、もう一方に、それが不活発であるかもしれない、「「理由。」 「例えば、RuleのEnabledの特性は「「」 \へのセットは障害がある\(値の=2)であった」」ならそうするかもしれません。) ]、クラスCIM_PolicyRuleValidityPeriod: CIM_PolicyComponent、[("GroupComponent")をくつがえしてください、Aggregate、記述、(「この特性がPolicyRuleという名前を含んでいる、それ、」 「1PolicyTimePeriodConditionsを含んでいる」、]、CIM_PolicyRule REF GroupComponent; [("PartComponent")をくつがえしてください、記述、(「この特性が「1PolicyRules」のために、」 「有効な期間を定義するPolicyTimePeriodCondition」という名前を含んでいる、]、CIM_PolicyTimePeriodCondition REF PartComponent;、。
Moore, et al. Standards Track [Page 93] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[93ページ]。
// ==================================================================
// 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;
};
// ================================================================== // VendorPolicyCondition //================================================================== [記述( 「」 「モデル化されていない表すPolicyConditions」のための一般的な拡大メカニズムを「特定の性質」に提供するクラス。 代わりに2つの特性、「「規制とConstraintEncodingが」 「説明された下\n\nとしてのConditionの内容と形式」を定義するのに使用される、「「「名前が示すように、VendorPolicyConditionは」 「Policy Core情報への業者特有の拡大」「モデル」のために意図します。 標準化された拡大が「「このクラス。」」を使用しないと予想されます。) ]、クラスCIM_VendorPolicyCondition: CIM_PolicyCondition{ [Octetstring、記述( 「この特性は「特定の性質で、モデル化されていた」状態で」 「PolicyConditionsを表して、それはそうではありません」のための一般的な拡大メカニズムを提供します。 形式、「「八重奏はアレイが不特定のままにされるコネを結ぶ」、「この定義。」 それがOID値で決定する、「「特性のConstraintEncodingで格納にされる」。 以来、「「ConstraintEncodingは単一に貴重であり、すべてが」 「規制は同じ形式と意味論を共有する」値です」。), ModelCorrespondence「CIM_VendorPolicyCondition.ConstraintEncoding」] Constraint[]を結んでください; [記述(「形式を特定して、ストリングとしてコード化されたOID」と「この例のConstraintの特性のための意味論」)、ModelCorrespondence「CIM_VendorPolicyCondition.Constraint」]ストリング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.")
// ================================================================== // PolicyAction //================================================================== [要約、記述( PolicyのためのPolicyConditionsであるなら実行されてください。「規則特有の、または、再利用できる方針を表すクラス」、「動作、」 「規則はTRUEに評価します」。 aのすべての操作上の詳細である、「「」 この物、「このクラスは抽象的であること」のサブクラスにPolicyActionを提供します」。)
Moore, et al. Standards Track [Page 94] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[94ページ]。
]
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;
]、クラスCIM_PolicyAction: CIM_方針[主要なMaxLen(256)、記述( これを見てください。「クラスかサブクラスの名前が中で使用した、」、「中のSystem物の創造、だれのもの、」 「PolicyActionは定義されます」。 「この特性は、中でSystem物を特定するのを助けます」。「\n\n」、「「「これが例証するPolicyActionの範囲は存在する」。 「規則特有のPolicyActionに関して、これはSystemです。」「「だれの文脈に、PolicyRuleは定義されますか?」 a、「「再利用できるPolicyAction、これが例である、」、「PolicyRepository、(Systemのサブクラスです) それ、」、「動作を保持する、」 「\n\n」、「「「それに注意してください、この特性、および類似の特性、」、「SystemName、」 「クラスSystemの例」から伝播されたキーを表さないでください。 または、を通して代わりに、それらがそうである、「「このクラスの文脈で定義された特性、どれ、」、「Systemの例からの値を繰り返すか、どれ、」、「このPolicyActionが直接関係づけられるか、」、「PolicyActionInPolicyRepository集合、間接的に」、「PolicyActionInPolicyRule集合で」、」) ]、SystemCreationClassNameを結んでください。[主要なMaxLen(256)、記述( 「範囲でSystem物について」 「PolicyActionは定義される」とこれを命名してください。 「\n\n」、「「「この特性はSystemの識別を終了する」という「存在「中のこれが範囲を例証するPolicyActionの物」」。 規則特有のPolicyActionに関して、これがそうである、「「PolicyRuleが文脈で定義されるシステム。」 「「再利用できるPolicyAction、これが例である、」、「PolicyRepository、(Systemのサブクラスです) それ、」、「動作を保持する、」、」) ]、SystemNameを結んでください。[主要なMaxLen(256)、記述( 「規則特有のPolicyAction、CreationClassName」「このActionがそうであるPolicyRule物」「関連」。 再利用できるPolicyAction、a、「「'特別な値、NO RULE'は」 「このActionが再利用できるのではなく、」 「aに関連づけられて、PolicyRuleを選抜してください。」がいずれ再利用できるのを示してください」に使用されるべきです。) ]、PolicyRuleCreationClassNameを結んでください。
Moore, et al. Standards Track [Page 95] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[95ページ]。
[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;
};
[主要なMaxLen(256)、記述( 「規則特有のPolicyAction、」 「このActionがそうであるPolicyRuleは反対する」「関連づけられた」名前のために。 再利用できるPolicyAction、a、「「'特別な値、NO RULE'は」 「このActionが再利用できるのではなく、」 「aに関連づけられて、PolicyRuleを選抜してください。」がいずれ再利用できるのを示してください」に使用されるべきです。) ]、PolicyRuleNameを結んでください。 [主要なMaxLen(256)、記述( 「CreationClassNameは」 クラスか「例の創造に使用されるサブクラス」の名前を示します。 使用される、「「このクラス、この特性の他の基本性質」は「このクラスとそのサブクラスのすべての例を」 「唯一特定されてください。」に許容します」。) ]、CreationClassNameを結んでください。 [主要なMaxLen(256)、記述(「このPolicyActionというユーザフレンドリーな名前」)]は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.")
]
// ================================================================== // PolicyActionInPolicyRepository //================================================================== [協会、記述( 「Aは再利用できることの接待を表しながら、属します」。「PolicyRepositoryによるPolicyActions。」 この集合を通して「再利用できるPolicy、」 「動作はいつも独身のPolicyRepositoryに関連する」、「. \n円n」、「「「」 PolicyAction缶の例が「再利用できるか規則特有」であるというメモ。 「Actionが規則であるときに」「特定であることで、いずれにもそれに関連しないものとする」「PolicyActionInPolicyRepositoryを通したPolicyRepository」「集合。」) ]、クラスCIM_PolicyActionInPolicyRepository: CIM_PolicyInSystem[オーバーライド(「前例」)、マックス(1)、記述( 「この特性はPolicyRepositoryを表す」という「接待1PolicyActions。」 再利用できるA、「「PolicyActionはいつもちょうど1つに関連する」「PolicyActionInPolicyRepositoryを通したPolicyRepository」「集合。」 [0。1] この特性のための基数、「「2つのタイプのカバーPolicyActions:」 「「規則特有のPolicyAction、再利用できるもののための1。」」のための0) ]
Moore, et al. Standards Track [Page 96] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[96ページ]。
CIM_PolicyRepository REF Antecedent;
[Override ("Dependent"), Description (
"This property holds the name of a PolicyAction"
"hosted in the PolicyRepository. ")
]
CIM_PolicyAction REF Dependent;
};
CIM_PolicyRepository審判前例。 [オーバーライド(「依存する」)、記述( 「この特性はPolicyActionという名前を保持すること」が「PolicyRepositoryでは、接待しました」。 ") ]、CIM_PolicyAction審判の扶養家族。 };
// ==================================================================
// 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 "
// ================================================================== // PolicyActionInPolicyRule //================================================================== [協会、集合、記述( 「」 「PolicyActionInPolicyRuleを通したPolicyActionのクラス」「協会」のPolicyRule集合ゼロか、より多くの例。 Actionsがないのに集めるRuleがそうでない、「「有効である、--、しかしながら、入られることの途中にそれがあるかもしれない」、「a SystemのためにPolicyRepositoryか存在と定義にされる」。 「交互に、方針の動作は中で明白であるかもしれません」。「「PolicyRuleの定義。」 そのa PolicyRuleに注意してください、「「それが有効になるまで効き目があるべきでない、\n円n」、「「「PolicyRuleに関連しているActionsは「お勧めのオーダーにもかかわらず、必要な注文、全くオーダーがありません」という当然のことa」であるかもしれない。 「「」 別々の状態で表された動作は反対して、PolicyActionInは「オーダーを言い表すのにPolicyRule集合を使用できます。」です。 「\n\n」、「「「動作が、命令する必要であって、お勧めである、またはどんな意味についてもそうしません」「この集合は、aが指定したかどうかを示さない」。 「「」 「PolicyRuleはこの指示を提供する」集合例における特性のSequencedActions」) ]、クラスCIM_PolicyActionInPolicyRule: CIM_PolicyComponent、("GroupComponent")をくつがえしてください、Aggregate、記述、(「この特性がPolicyRuleを表す、それ、」 「1PolicyActionsを含んでいる」、)、CIM_PolicyRule REF GroupComponent; ("PartComponent")(記述(「この特性はPolicyActionという名前を保持します」「1PolicyRulesによって含まれていた」)CIM_PolicyAction REF PartComponent)をくつがえしてください; '記述、(「この特性は'符号のない整数とそれを提供する」、「」 「PolicyRuleに関連している動作の系列」でPolicyActionの相対的な位置を示す、「いつ、'正の整数、場所を示すということであるか」。
Moore, et al. Standards Track [Page 97] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[97ページ]。
"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'は、'気にかけないでください'と示します。 「「2PolicyActionsがそうした、」 同じ非ゼロの「一連番号、彼らはしかしいずれも命令する実行されたコネであるかもしれない」、「」 「総合的な動作系列」の適切な場所で彼らを皆、実行しなければなりません。 「\n\n」、「「「一連の例がPolicyActionsの注文を作る」、「より明確:、」 「\n」、「o If、すべての動作には同じ一連番号がある、」、「それがいくらか'0'か非ゼロであることにかかわらず」、「オーダーが許容できる. \n」、「○ 値:、」 「\n」、「1、: 動作A\n」、「2、: 動作B\n」、「1、: 動作C\n」、「3: 動作D\n」は「許容できる2が以下を注文するのを示します」。 A、CかBかDかC、A、B、D、「「AとCを実行できるので、しかし、どちらかで注文してください」、「'1'位置だけで」 「\n」、「○ 値:、」 または、「\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.Thus」、「命令は以下の通りです」 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"
// ================================================================== // VendorPolicyAction //================================================================== [記述、(「」 「モデル化されていない表すPolicyActions」のための一般的な拡大メカニズムを「特定の性質代わりに2つの特性」に提供するクラス、「ActionDataとActionEncodingは、」 「説明された下\n\nとしてのActionの内容と形式」を定義するのに使用されます。
Moore, et al. Standards Track [Page 98] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[98ページ]。
" "
"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;
};
「「「名前が示すように、VendorPolicyActionは」 「Policy Core情報への業者特有の拡大」「モデル」のために意図します。 標準化された拡大が使用しないと予想される、「「これは属します」。)」 ]、クラスCIM_VendorPolicyAction: CIM_PolicyAction{ [Octetstring、記述( 「この特性は「特定の性質で、モデル化されていた」状態で」 「PolicyActionsを表して、それはそうではありません」のための一般的な拡大メカニズムを提供します。 形式、「「八重奏はアレイが不特定のままにされるコネを結ぶ」、「この定義。」 それがOID値で決定する、「「特性のActionEncodingで格納にされる」。 以来、「「ActionEncodingは単一に評価されています、」 「ActionDataは同じ形式と意味論を共有する」すべての値、)、ModelCorrespondence「CIM_VendorPolicyAction.ActionEncoding」] ストリングActionData[]、」、。 [記述(「形式を特定して、ストリングとしてコード化されたOID」と「この例のActionDataの特性のための意味論」)、ModelCorrespondence「CIM_VendorPolicyAction.ActionData」]はActionEncodingを結びます。 };
// =================================================================== // end of file // ===================================================================
// =================================================================== //ファイルの終り//===================================================================
Moore, et al. Standards Track [Page 99] RFC 3060 Policy Core Information Model February 2001
ムーア、他 規格は方針コア情報モデル2001年2月にRFC3060を追跡します[99ページ]。
15. Full Copyright Statement
15. 完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Moore, et al. Standards Track [Page 100]
ムーア、他 標準化過程[100ページ]
一覧
スポンサーリンク
