RFC3460 日本語訳
3460 Policy Core Information Model (PCIM) Extensions. B. Moore, Ed.. January 2003. (Format: TXT=212453 bytes) (Updates RFC3060) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Moore, Ed. Request for Comments: 3460 IBM Updates: 3060 January 2003 Category: Standards Track
ワーキンググループのB.ムーア、エドをネットワークでつないでください。コメントのために以下を要求してください。 3460のIBMアップデート: 3060 2003年1月のカテゴリ: 標準化過程
Policy Core Information Model (PCIM) Extensions
方針コア情報モデル(PCIM)拡大
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 (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
This document specifies a number of changes to the Policy Core Information Model (PCIM, RFC 3060). Two types of changes are included. First, several completely new elements are introduced, for example, classes for header filtering, that extend PCIM into areas that it did not previously cover. Second, there are cases where elements of PCIM (for example, policy rule priorities) are deprecated, and replacement elements are defined (in this case, priorities tied to associations that refer to policy rules). Both types of changes are done in such a way that, to the extent possible, interoperability with implementations of the original PCIM model is preserved. This document updates RFC 3060.
このドキュメントはPolicy Core情報Model(PCIM、RFC3060)への多くの変化を指定します。 2つのタイプの変化は含まれています。 まず最初に、ヘッダーのための例えばクラスがフィルターにかけられて、それが以前にカバーしなかった領域にPCIMを広げる数個の完全に新しい要素が紹介されます。2番目に、ケースがPCIM(例えば、政策ルールプライオリティ)の要素が推奨しなく、交換要素が定義される(この場合、プライオリティは政策ルールを示す協会につながりました)ところにあります。 両方のタイプの変化は可能な範囲内でオリジナルのPCIMモデルの実装がある相互運用性が保存されるような方法で完了しています。 このドキュメントはRFC3060をアップデートします。
Table of Contents
目次
1. Introduction....................................................5
2. Changes since RFC 3060..........................................5
3. Overview of the Changes.........................................6
3.1. How to Change an Information Model.........................6
3.2. List of Changes to the Model...............................6
3.2.1. Changes to PolicyRepository.........................6
3.2.2. Additional Associations and Additional Reusable
Elements............................................7
3.2.3. Priorities and Decision Strategies..................7
3.2.4. Policy Roles........................................8
3.2.5. CompoundPolicyConditions and
CompoundPolicyActions...............................8
1. 序論…5 2. RFC3060以来の変化…5 3. 変化の概要…6 3.1. どう情報モデルを変えるか…6 3.2. モデルへの変化のリスト…6 3.2.1. PolicyRepositoryへの変化…6 3.2.2. 追加協会と追加再利用できるElements…7 3.2.3. プライオリティと決定戦略…7 3.2.4. 方針の役割…8 3.2.5. CompoundPolicyConditionsとCompoundPolicyActions…8
Moore Standards Track [Page 1] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[1ページ]。
3.2.6. Variables and Values................................9
3.2.7. Domain-Level Packet Filtering.......................9
3.2.8. Device-Level Packet Filtering.......................9
4. The Updated Class and Association Class Hierarchies............10
5. Areas of Extension to PCIM.....................................13
5.1. Policy Scope..............................................13
5.1.1. Levels of Abstraction: Domain- and Device-Level
Policies...........................................13
5.1.2. Administrative and Functional Scopes...............14
5.2. Reusable Policy Elements..................................15
5.3. Policy Sets...............................................16
5.4. Nested Policy Rules.......................................16
5.4.1. Usage Rules for Nested Rules.......................17
5.4.2. Motivation.........................................17
5.5. Priorities and Decision Strategies........................18
5.5.1. Structuring Decision Strategies....................19
5.5.2. Side Effects.......................................21
5.5.3. Multiple PolicySet Trees For a Resource............21
5.5.4. Deterministic Decisions............................22
5.6. Policy Roles..............................................23
5.6.1. Comparison of Roles in PCIM with Roles in
snmpconf...........................................23
5.6.2. Addition of PolicyRoleCollection to PCIMe..........24
5.6.3. Roles for PolicyGroups.............................25
5.7. Compound Policy Conditions and Compound Policy Actions....27
5.7.1. Compound Policy Conditions.........................27
5.7.2. Compound Policy Actions............................27
5.8. Variables and Values......................................28
5.8.1. Simple Policy Conditions...........................29
5.8.2. Using Simple Policy Conditions.....................29
5.8.3. The Simple Condition Operator......................31
5.8.4. SimplePolicyActions................................33
5.8.5. Policy Variables...................................35
5.8.6. Explicitly Bound Policy Variables..................36
5.8.7. Implicitly Bound Policy Variables..................37
5.8.8. Structure and Usage of Pre-Defined Variables.......38
5.8.9. Rationale for Modeling Implicit Variables
as Classes.........................................39
5.8.10. Policy Values.....................................40
5.9. Packet Filtering..........................................41
5.9.1. Domain-Level Packet Filters........................41
5.9.2. Device-Level Packet Filters........................42
5.10. Conformance to PCIM and PCIMe............................43
6. Class Definitions..............................................44
6.1. The Abstract Class "PolicySet"............................44
6.2. Update PCIM's Class "PolicyGroup".........................45
6.3. Update PCIM's Class "PolicyRule"..........................45
6.4. The Class "SimplePolicyCondition".........................46
3.2.6. 変数と値…9 3.2.7. ドメインレベルパケットフィルタリング…9 3.2.8. デバイスレベルパケットフィルタリング…9 4. アップデートされたクラスと協会クラス階層構造…10 5. PCIMへの拡大の領域…13 5.1. 方針範囲…13 5.1.1. 抽象化のレベル: ドメインとデバイスレベル方針…13 5.1.2. 管理的、そして、機能的な範囲…14 5.2. 再利用できるPolicy Elements…15 5.3. 方針はセットします…16 5.4. 入れ子にされた方針は統治されます…16 5.4.1. 用法は入れ子にされた規則のために統治されます…17 5.4.2. 動機…17 5.5. プライオリティと決定戦略…18 5.5.1. 決定戦略を構造化します…19 5.5.2. 副作用…21 5.5.3. リソースのための複数のPolicySet木…21 5.5.4. 決定論的な決定…22 5.6. 方針の役割…23 5.6.1. RolesがsnmpconfにあるPCIMでのRolesの比較…23 5.6.2. PCIMeへのPolicyRoleCollectionの追加…24 5.6.3. PolicyGroupsのための役割…25 5.7. 保険約款と合成政策的措置を合成してください…27 5.7.1. 保険約款を合成してください…27 5.7.2. 政策的措置を合成してください…27 5.8. 変数と値…28 5.8.1. 簡単な保険約款…29 5.8.2. 簡単な保険約款を使用します…29 5.8.3. 単純条件オペレータ…31 5.8.4. SimplePolicyActions…33 5.8.5. 方針変数…35 5.8.6. 明らかに制限された政策変数…36 5.8.7. それとなく制限された政策変数…37 5.8.8. 事前に定義された変数の構造と用法…38 5.8.9. クラスとして暗黙の変数をモデル化するための原理…39 5.8.10. 方針値…40 5.9. パケットフィルタリング…41 5.9.1. ドメインレベルパケットフィルタ…41 5.9.2. デバイスレベルパケットフィルタ…42 5.10. PCIMとPCIMeへの順応…43 6. クラス定義…44 6.1. 抽象クラス"PolicySet"…44 6.2. PCIMのクラス"PolicyGroup"をアップデートしてください…45 6.3. PCIMのクラス"PolicyRule"をアップデートしてください…45 6.4. クラス"SimplePolicyCondition"…46
Moore Standards Track [Page 2] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[2ページ]。
6.5. The Class "CompoundPolicyCondition".......................47
6.6. The Class "CompoundFilterCondition".......................47
6.7. The Class "SimplePolicyAction"............................48
6.8. The Class "CompoundPolicyAction"..........................48
6.9. The Abstract Class "PolicyVariable".......................50
6.10. The Class "PolicyExplicitVariable".......................50
6.10.1. The Single-Valued Property "ModelClass"...........51
6.10.2. The Single-Valued Property ModelProperty..........51
6.11. The Abstract Class "PolicyImplicitVariable"..............51
6.11.1. The Multi-Valued Property "ValueTypes"............52
6.12. Subclasses of "PolicyImplicitVariable" Specified
in PCIMe.................................................52
6.12.1. The Class "PolicySourceIPv4Variable"..............52
6.12.2. The Class "PolicySourceIPv6Variable"..............52
6.12.3. The Class "PolicyDestinationIPv4Variable".........53
6.12.4. The Class "PolicyDestinationIPv6Variable".........53
6.12.5. The Class "PolicySourcePortVariable"..............54
6.12.6. The Class "PolicyDestinationPortVariable".........54
6.12.7. The Class "PolicyIPProtocolVariable"..............54
6.12.8. The Class "PolicyIPVersionVariable"...............55
6.12.9. The Class "PolicyIPToSVariable"...................55
6.12.10. The Class "PolicyDSCPVariable"...................55
6.12.11. The Class "PolicyFlowIdVariable".................56
6.12.12. The Class "PolicySourceMACVariable"..............56
6.12.13. The Class "PolicyDestinationMACVariable".........56
6.12.14. The Class "PolicyVLANVariable"...................56
6.12.15. The Class "PolicyCoSVariable"....................57
6.12.16. The Class "PolicyEthertypeVariable"..............57
6.12.17. The Class "PolicySourceSAPVariable"..............57
6.12.18. The Class "PolicyDestinationSAPVariable".........58
6.12.19. The Class "PolicySNAPOUIVariable"................58
6.12.20. The Class "PolicySNAPTypeVariable"...............59
6.12.21. The Class "PolicyFlowDirectionVariable"..........59
6.13. The Abstract Class "PolicyValue".........................59
6.14. Subclasses of "PolicyValue" Specified in PCIMe...........60
6.14.1. The Class "PolicyIPv4AddrValue"...................60
6.14.2. The Class "PolicyIPv6AddrValue....................61
6.14.3. The Class "PolicyMACAddrValue"....................62
6.14.4. The Class "PolicyStringValue".....................63
6.14.5. The Class "PolicyBitStringValue"..................63
6.14.6. The Class "PolicyIntegerValue"....................64
6.14.7. The Class "PolicyBooleanValue"....................65
6.15. The Class "PolicyRoleCollection".........................65
6.15.1. The Single-Valued Property "PolicyRole"...........66
6.16. The Class "ReusablePolicyContainer".................66
6.17. Deprecate PCIM's Class "PolicyRepository"................66
6.18. The Abstract Class "FilterEntryBase".....................67
6.19. The Class "IpHeadersFilter"..............................67
6.5. クラス"CompoundPolicyCondition"…47 6.6. クラス"CompoundFilterCondition"…47 6.7. クラス"SimplePolicyAction"…48 6.8. クラス"CompoundPolicyAction"…48 6.9. 抽象クラス"PolicyVariable"…50 6.10. クラス"PolicyExplicitVariable"…50 6.10.1. 単一に評価された特性の「ModelClass」…51 6.10.2. 単一に評価された特性のModelProperty…51 6.11. 抽象クラス"PolicyImplicitVariable"…51 6.11.1. マルチ評価された特性の「ValueTypes」…52 6.12. "PolicyImplicitVariable"のサブクラスはPCIMeで指定しました…52 6.12.1. クラス"PolicySourceIPv4Variable"…52 6.12.2. クラス"PolicySourceIPv6Variable"…52 6.12.3. クラス"PolicyDestinationIPv4Variable"…53 6.12.4. クラス"PolicyDestinationIPv6Variable"…53 6.12.5. クラス"PolicySourcePortVariable"…54 6.12.6. クラス"PolicyDestinationPortVariable"…54 6.12.7. クラス"PolicyIPProtocolVariable"…54 6.12.8. クラス"PolicyIPVersionVariable"…55 6.12.9. クラス"PolicyIPToSVariable"…55 6.12.10. クラス"PolicyDSCPVariable"…55 6.12.11. クラス"PolicyFlowIdVariable"…56 6.12.12. クラス"PolicySourceMACVariable"…56 6.12.13. クラス"PolicyDestinationMACVariable"…56 6.12.14. クラス"PolicyVLANVariable"…56 6.12.15. クラス"PolicyCoSVariable"…57 6.12.16. クラス"PolicyEthertypeVariable"…57 6.12.17. クラス"PolicySourceSAPVariable"…57 6.12.18. クラス"PolicyDestinationSAPVariable"…58 6.12.19. クラス"PolicySNAPOUIVariable"…58 6.12.20. クラス"PolicySNAPTypeVariable"…59 6.12.21. クラス"PolicyFlowDirectionVariable"…59 6.13. 抽象クラス"PolicyValue"…59 6.14. "PolicyValue"のサブクラスはPCIMeで指定しました…60 6.14.1. クラス"PolicyIPv4AddrValue"…60 6.14.2. クラス"PolicyIPv6AddrValue"…61 6.14.3. クラス"PolicyMACAddrValue"…62 6.14.4. クラス"PolicyStringValue"…63 6.14.5. クラス"PolicyBitStringValue"…63 6.14.6. クラス"PolicyIntegerValue"…64 6.14.7. クラス"PolicyBooleanValue"…65 6.15. クラス"PolicyRoleCollection"…65 6.15.1. 単一に評価された特性の"PolicyRole"…66 6.16. クラス"ReusablePolicyContainer"…66 6.17. PCIMのクラス"PolicyRepository"を非難してください…66 6.18. 抽象クラス"FilterEntryBase"…67 6.19. クラス"IpHeadersFilter"…67
Moore Standards Track [Page 3] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[3ページ]。
6.19.1. The Property HdrIpVersion.........................68
6.19.2. The Property HdrSrcAddress........................68
6.19.3. The Property HdrSrcAddressEndOfRange..............68
6.19.4. The Property HdrSrcMask...........................69
6.19.5. The Property HdrDestAddress.......................69
6.19.6. The Property HdrDestAddressEndOfRange.............69
6.19.7. The Property HdrDestMask..........................70
6.19.8. The Property HdrProtocolID........................70
6.19.9. The Property HdrSrcPortStart......................70
6.19.10. The Property HdrSrcPortEnd.......................70
6.19.11. The Property HdrDestPortStart....................71
6.19.12. The Property HdrDestPortEnd......................71
6.19.13. The Property HdrDSCP.............................72
6.19.14. The Property HdrFlowLabel.................... ...72
6.20. The Class "8021Filter"...................................72
6.20.1. The Property 8021HdrSrcMACAddr....................73
6.20.2. The Property 8021HdrSrcMACMask....................73
6.20.3. The Property 8021HdrDestMACAddr...................73
6.20.4. The Property 8021HdrDestMACMask...................73
6.20.5. The Property 8021HdrProtocolID....................74
6.20.6. The Property 8021HdrPriorityValue.................74
6.20.7. The Property 8021HdrVLANID........................74
6.21. The Class FilterList.....................................74
6.21.1. The Property Direction............................75
7. Association and Aggregation Definitions........................75
7.1. The Aggregation "PolicySetComponent"......................75
7.2. Deprecate PCIM's Aggregation "PolicyGroupInPolicyGroup"...76
7.3. Deprecate PCIM's Aggregation "PolicyRuleInPolicyGroup"....76
7.4. The Abstract Association "PolicySetInSystem"..............77
7.5. Update PCIM's Weak Association "PolicyGroupInSystem"......77
7.6. Update PCIM's Weak Association "PolicyRuleInSystem".......78
7.7. The Abstract Aggregation "PolicyConditionStructure".......79
7.8. Update PCIM's Aggregation "PolicyConditionInPolicyRule"...79
7.9. The Aggregation "PolicyConditionInPolicyCondition"........79
7.10. The Abstract Aggregation "PolicyActionStructure".........80
7.11. Update PCIM's Aggregation "PolicyActionInPolicyRule".....80
7.12. The Aggregation "PolicyActionInPolicyAction".............80
7.13. The Aggregation "PolicyVariableInSimplePolicyCondition"..80
7.14. The Aggregation "PolicyValueInSimplePolicyCondition".....81
7.15. The Aggregation "PolicyVariableInSimplePolicyAction".....82
7.16. The Aggregation "PolicyValueInSimplePolicyAction"........83
7.17. The Association "ReusablePolicy".........................83
7.18. Deprecate PCIM's "PolicyConditionInPolicyRepository".....84
7.19. Deprecate PCIM's "PolicyActionInPolicyRepository"........84
7.20. The Association ExpectedPolicyValuesForVariable..........84
7.21. The Aggregation "ContainedDomain"........................85
7.22. Deprecate PCIM's "PolicyRepositoryInPolicyRepository"....86
7.23. The Aggregation "EntriesInFilterList"....................86
6.19.1. 特性のHdrIpVersion…68 6.19.2. 特性のHdrSrcAddress…68 6.19.3. 特性のHdrSrcAddressEndOfRange…68 6.19.4. 特性のHdrSrcMask…69 6.19.5. 特性のHdrDestAddress…69 6.19.6. 特性のHdrDestAddressEndOfRange…69 6.19.7. 特性のHdrDestMask…70 6.19.8. 特性のHdrProtocolID…70 6.19.9. 特性のHdrSrcPortStart…70 6.19.10. 特性のHdrSrcPortEnd…70 6.19.11. 特性のHdrDestPortStart…71 6.19.12. 特性のHdrDestPortEnd…71 6.19.13. 特性のHdrDSCP…72 6.19.14. 特性のHdrFlowLabel… ...72 6.20. クラス"8021Filter"…72 6.20.1. 特性の8021HdrSrcMACAddr…73 6.20.2. 特性の8021HdrSrcMACMask…73 6.20.3. 特性の8021HdrDestMACAddr…73 6.20.4. 特性の8021HdrDestMACMask…73 6.20.5. 特性の8021HdrProtocolID…74 6.20.6. 特性の8021HdrPriorityValue…74 6.20.7. 特性の8021HdrVLANID…74 6.21. クラスFilterList…74 6.21.1. 特性の方向…75 7. 協会と集合定義…75 7.1. 集合"PolicySetComponent"…75 7.2. PCIMの集合"PolicyGroupInPolicyGroup"を非難してください…76 7.3. PCIMの集合"PolicyRuleInPolicyGroup"を非難してください…76 7.4. 抽象的な協会"PolicySetInSystem"…77 7.5. PCIMの弱い協会"PolicyGroupInSystem"をアップデートしてください…77 7.6. PCIMの弱い協会"PolicyRuleInSystem"をアップデートしてください…78 7.7. 抽象的な集合"PolicyConditionStructure"…79 7.8. PCIMの集合"PolicyConditionInPolicyRule"をアップデートしてください…79 7.9. 集合"PolicyConditionInPolicyCondition"…79 7.10. 抽象的な集合"PolicyActionStructure"…80 7.11. PCIMの集合"PolicyActionInPolicyRule"をアップデートしてください…80 7.12. 集合"PolicyActionInPolicyAction"…80 7.13. 集合"PolicyVariableInSimplePolicyCondition"。80 7.14. 集合"PolicyValueInSimplePolicyCondition"…81 7.15. 集合"PolicyVariableInSimplePolicyAction"…82 7.16. 集合"PolicyValueInSimplePolicyAction"…83 7.17. 協会"ReusablePolicy"…83 7.18. PCIMの"PolicyConditionInPolicyRepository"を非難してください…84 7.19. PCIMの"PolicyActionInPolicyRepository"を非難してください…84 7.20. 協会ExpectedPolicyValuesForVariable…84 7.21. 集合"ContainedDomain"…85 7.22. PCIMの"PolicyRepositoryInPolicyRepository"を非難してください…86 7.23. 集合"EntriesInFilterList"…86
Moore Standards Track [Page 4] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[4ページ]。
7.23.1. The Reference GroupComponent......................86
7.23.2. The Reference PartComponent.......................87
7.23.3. The Property EntrySequence........................87
7.24. The Aggregation "ElementInPolicyRoleCollection"..........87
7.25. The Weak Association "PolicyRoleCollectionInSystem"......87
8. Intellectual Property..........................................88
9. Acknowledgements..............................................89
10. Contributors..................................................89
11. Security Considerations.......................................91
12. Normative References..........................................91
13. Informative References........................................91
Author's Address..................................................92
Full Copyright Statement..........................................93
7.23.1. 参照GroupComponent…86 7.23.2. 参照PartComponent…87 7.23.3. 特性のEntrySequence…87 7.24. 集合"ElementInPolicyRoleCollection"…87 7.25. 弱い協会"PolicyRoleCollectionInSystem"…87 8. 知的所有権…88 9. 承認…89 10. 貢献者…89 11. セキュリティ問題…91 12. 標準の参照…91 13. 有益な参照…91作者のアドレス…92 完全な著作権宣言文…93
1. Introduction
1. 序論
This document specifies a number of changes to the Policy Core Information Model (PCIM), RFC 3060 [1]. Two types of changes are included. First, several completely new elements are introduced, for example, classes for header filtering, that extend PCIM into areas that it did not previously cover. Second, there are cases where elements of PCIM (for example, policy rule priorities) are deprecated, and replacement elements are defined (in this case, priorities tied to associations that refer to policy rules). Both types of changes are done in such a way that, to the extent possible, interoperability with implementations of the original PCIM model is preserved.
このドキュメントはPolicy Core情報Model(PCIM)、RFC3060[1]への多くの変化を指定します。 2つのタイプの変化は含まれています。 まず最初に、ヘッダーのための例えばクラスがフィルターにかけられて、それが以前にカバーしなかった領域にPCIMを広げる数個の完全に新しい要素が紹介されます。2番目に、ケースがPCIM(例えば、政策ルールプライオリティ)の要素が推奨しなく、交換要素が定義される(この場合、プライオリティは政策ルールを示す協会につながりました)ところにあります。 両方のタイプの変化は可能な範囲内でオリジナルのPCIMモデルの実装がある相互運用性が保存されるような方法で完了しています。
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 BCP 14, RFC 2119 [8].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[8])で説明されるように本書では解釈されることであるべきです。
2. Changes since RFC 3060
2. RFC3060以来の変化
Section 3.2 contains a short discussion of the changes that this document makes to the RFC 3060 information model. Here is a very brief list of the changes:
セクション3.2はこのドキュメントがRFC3060情報モデルに行う変更の短い議論を含みます。 ここに、変化の非常に簡潔なリストがあります:
1. Deprecate and replace PolicyRepository and its associations.
2. Clarify and expand the ways that PolicyRules and PolicyGroups are
aggregated.
3. Change how prioritization for PolicyRules is represented, and
introduce administrator-specified decision strategies for rule
evaluation.
4. Expand the role of PolicyRoles, and introduce a means of
associating a PolicyRole with a resource.
5. Introduce compound policy conditions and compound policy actions
into the model.
1. PolicyRepositoryとその協会を非難して、取り替えてください。 2. PolicyRulesとPolicyGroupsが集められる方法をはっきりさせて、広げてください。 3. PolicyRulesのための優先順位づけがどう表されるかを変えてください、そして、規則評価のための管理者によって指定された決定戦略を導入してください。 4. PolicyRolesの役割を広げてください、そして、PolicyRoleをリソースに関連づける手段を導入してください。 5. 合成保険約款と合成政策的措置をモデルに取り入れてください。
Moore Standards Track [Page 5] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[5ページ]。
6. Introduce variables and values into the model.
7. Introduce variable and value subclasses for packet-header
filtering.
8. Introduce classes for device-level packet-header filtering.
6. 変数と値をモデルに取り入れてください。 7. パケットのヘッダーフィルタリングのために変数と値のサブクラスを紹介してください。 8. デバイスレベルパケットのヘッダーフィルタリングのためにクラスを導入してください。
3. Overview of the Changes
3. 変化の概要
3.1. How to Change an Information Model
3.1. 情報モデルを変える方法
The Policy Core Information Model is closely aligned with the DMTF's CIM Core Policy model. Since there is no separately documented set of rules for specifying IETF information models such as PCIM, it is reasonable to look to the CIM specifications for guidance on how to modify and extend the model. Among the CIM rules for changing an information model are the following. Note that everything said here about "classes" applies to association classes (including aggregations) as well as to non- association classes.
Policy Core情報Modelは密接にDMTFのCIM Core Policyモデルに並べられます。 PCIMなどのIETF情報モデルを指定するための規則の別々に記録されたセットが全くないので、指導のためのモデルを変更して、どう広げるかに関するCIM仕様を当てにするのは妥当です。 CIMの中では、情報モデルを変えるための規則は以下です。 ここで「クラス」に関して言われたすべてが非協会のクラスに関してまた、協会のクラス(集合を含んでいる)に適用されることに注意してください。
o Properties may be added to existing classes.
o Classes, and individual properties, may be marked as DEPRECATED.
If there is a replacement feature for the deprecated class or
property, it is identified explicitly. Otherwise the notation "No
value" is used. In this document, the notation "DEPRECATED FOR
<feature-name>" is used to indicate that a feature has been
deprecated, and to identify its replacement feature.
o Classes may be inserted into the inheritance hierarchy above
existing classes, and properties from the existing classes may
then be "pulled up" into the new classes. The net effect is that
the existing classes have exactly the same properties they had
before, but the properties are inherited rather than defined
explicitly in the classes.
o New subclasses may be defined below existing classes.
o 特性は既存のクラスに追加されるかもしれません。o Classes、および個人財産はDEPRECATEDとしてマークされるかもしれません。 推奨しないクラスか特性のための交換機能があれば、それは明らかに特定されます。 さもなければ、記法「いいえ値」は使用されています。 本書では、「<の特徴名の>に推奨しない」記法は、特徴が推奨しないのを示して、交換機能を特定するのに使用されます。o Classesは継承階層構造に既存のクラスより上まで挿入されるかもしれません、そして、次に、既存のクラスからの特性は新しいクラスへ「引き上げられるかもしれません」。 ネットの効果は既存のクラスにはそれらが以前持っていたまさに同じ特性があるということですが、特性はクラスで明らかに定義するよりむしろ引き継がれます。o Newサブクラスは既存のクラスの下で定義されるかもしれません。
3.2. List of Changes to the Model
3.2. モデルへの変化のリスト
The following subsections provide a very brief overview of the changes to PCIM defined in PCIMe. In several cases, the origin of the change is noted, as QPIM [11], ICPM [12], or QDDIM [15].
以下の小区分はPCIMeで定義されたPCIMへの変化の非常に簡潔な概要を提供します。 いろいろな場合に、変化の発生源はQPIM[11]、ICPM[12]、またはQDDIM[15]として注意されます。
3.2.1. Changes to PolicyRepository
3.2.1. PolicyRepositoryへの変化
Because of the potential for confusion with the Policy Framework component Policy Repository (from the four-box picture: Policy Management Tool, Policy Repository, PDP, PEP), "PolicyRepository" is a bad name for the PCIM class representing a container of reusable policy elements. Thus the class PolicyRepository is being replaced with the class ReusablePolicyContainer. To accomplish this change, it is necessary to deprecate the PCIM class PolicyRepository and its
Policy Frameworkの部品Policy Repository(4箱の画像: 方針Management Tool、Policy RepositoryからのPDP、PEP)への混乱の可能性のために、"PolicyRepository"は再利用できる方針要素のコンテナを表すPCIMのクラスのための悪名です。 したがって、クラスPolicyRepositoryをクラスReusablePolicyContainerに取り替えています。 そして、この変化を達成するのに、PCIMのクラスPolicyRepositoryを非難するのが必要である、それ
Moore Standards Track [Page 6] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[6ページ]。
three associations, and replace them with a new class ReusablePolicyContainer and new associations. As a separate change, the associations for ReusablePolicyContainer are being broadened, to allow a ReusablePolicyContainer to contain any reusable policy elements. In PCIM, the only associations defined for a PolicyRepository were for it to contain reusable policy conditions and policy actions.
3つの協会、それらを新しいクラスReusablePolicyContainerと新連合に取り替えてください。 別々の変化として、ReusablePolicyContainerのための協会は、ReusablePolicyContainerがどんな再利用できる方針要素も含むのを許容するために広くされています。 PCIM、PolicyRepositoryのために定義された唯一の協会で、状態と政策的措置は再利用できる方針を含むそれのためのものでした。
3.2.2. Additional Associations and Additional Reusable Elements
3.2.2. 追加協会と追加再利用できる要素
The PolicyRuleInPolicyRule and PolicyGroupInPolicyRule aggregations
have, in effect, been imported from QPIM. ("In effect" because these
two aggregations, as well as PCIM's two aggregations
PolicyGroupInPolicyGroup and PolicyRuleInPolicyGroup, are all being
combined into a single aggregation PolicySetComponent.) These
aggregations make it possible to define larger "chunks" of reusable
policy to place in a ReusablePolicyContainer. These aggregations
also introduce new semantics representing the contextual implications
of having one PolicyRule executing within the scope of another
PolicyRule.
事実上、PolicyRuleInPolicyRuleとPolicyGroupInPolicyRule集合はQPIMからインポートされました。 (PCIMの2のこれらの2つの集合、集合PolicyGroupInPolicyGroup、およびPolicyRuleInPolicyGroupがただ一つの集合PolicySetComponentにすべて結合されているので「有効な」。) これらの集合で、ReusablePolicyContainerで入賞するために再利用できる方針の、より大きい「塊」を定義するのは可能になります。 また、これらの集合は別のPolicyRuleの範囲の中の1PolicyRuleの実行を持つ文脈上の含意を表す新しい意味論を紹介します。
3.2.3. Priorities and Decision Strategies
3.2.3. プライオリティと決定戦略
Drawing from both QPIM and ICPM, the Priority property has been deprecated in PolicyRule, and placed instead on the aggregation PolicySetComponent. The QPIM rules for resolving relative priorities across nested PolicyGroups and PolicyRules have been incorporated into PCIMe as well. With the removal of the Priority property from PolicyRule, a new modeling dependency is introduced. In order to prioritize a PolicyRule/PolicyGroup relative to other PolicyRules/PolicyGroups, the elements being prioritized must all reside in one of three places: in a common PolicyGroup, in a common PolicyRule, or in a common System.
QPIMとICPMの両方からの図面、Priorityの特性は、PolicyRuleで推奨しなく、代わりに集合PolicySetComponentに置かれました。 入れ子にされたPolicyGroupsとPolicyRulesの向こう側に相対的なプライオリティを決議するためのQPIM規則をまた、PCIMeに組み入れてあります。 PolicyRuleからのPriorityの特性の取り外しで、新しいモデルの依存を導入します。 他のPolicyRules/PolicyGroupsに比例してPolicyRule/PolicyGroupを最優先させるために、最優先する要素は3つの場所の1つですべてなければなりません: 一般的なPolicyGroup、一般的なPolicyRule、または一般的なSystemで。
In the absence of any clear, general criterion for detecting policy conflicts, the PCIM restriction stating that priorities are relevant only in the case of conflicts is being removed. In its place, a PolicyDecisionStrategy property has been added to the PolicyGroup and PolicyRule classes. This property allows policy administrator to select one of two behaviors with respect to rule evaluation: either perform the actions for all PolicyRules whose conditions evaluate to TRUE, or perform the actions only for the highest-priority PolicyRule whose conditions evaluate to TRUE. (This is accomplished by placing the PolicyDecisionStrategy property in an abstract class PolicySet,
方針闘争を検出するためのどんな明確で、一般的な評価基準がないとき、プライオリティが闘争の場合だけで関連していると述べるPCIM制限を取り除いています。 場所では、PolicyGroupとPolicyRuleのクラスにPolicyDecisionStrategyの特性を追加してあります。 この特性で、方針管理者は規則評価に関して2つの振舞いの1つを選択できます: どちらかが状態が最優先するPolicyRuleのためだけに動作をTRUEに評価するか、または実行するすべてのPolicyRulesのために動作を実行します。状態はTRUEにだれのものを評価しますか? (これは、抽象クラスPolicySetのPolicyDecisionStrategyの特性を置くことによって、達成されます。
Moore Standards Track [Page 7] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[7ページ]。
from which PolicyGroup and PolicyRule are derived.) The QPIM rules for applying decision strategies to a nested set of PolicyGroups and PolicyRules have also been imported.
PolicyGroupとPolicyRuleが引き出される。) また、PolicyGroupsとPolicyRulesの入れ子にされたセットに決定戦略を適用するためのQPIM規則はインポートされました。
3.2.4. Policy Roles
3.2.4. 方針の役割
The concept of policy roles is added to PolicyGroups (being present already in the PolicyRule class). This is accomplished via a new superclass for both PolicyRules and PolicyGroups - PolicySet. For nested PolicyRules and PolicyGroups, any roles associated with the outer rule or group are automatically "inherited" by the nested one. Additional roles may be added at the level of a nested rule or group.
方針の役割の概念はPolicyGroups(PolicyRuleのクラスで既に存在している)に加えられます。 これはPolicyRulesとPolicyGroupsの両方のための新しい「スーパー-クラス」を通して達成されます--PolicySet。 入れ子にされたPolicyRulesとPolicyGroupsに関しては、外側の規則かグループに関連しているどんな役割も入れ子にされたものによって自動的に「引き継がれます」。 追加役割は入れ子にされた規則かグループのレベルで加えられるかもしれません。
It was also observed that there is no mechanism in PCIM for assigning roles to resources. For example, while it is possible in PCIM to associate a PolicyRule with the role "FrameRelay&&WAN", there is no way to indicate which interfaces match this criterion. A new PolicyRoleCollection class has been defined in PCIMe, representing the collection of resources associated with a particular role. The linkage between a PolicyRule or PolicyGroup and a set of resources is then represented by an instance of PolicyRoleCollection. Equivalent values should be defined in the PolicyRoles property of PolicyRules and PolicyGroups, and in the PolicyRole property in PolicyRoleCollection.
また、メカニズムが全く役割をリソースに割り当てるためのPCIMにないのが観測されました。 PolicyRuleを役割に関連づけるのが例えばPCIMで可能である、「FrameRelay、WAN、」、どのインタフェースがこの評価基準に合っているかを示す方法が全くありません。 特定の役割に関連しているリソースの収集を表して、新しいPolicyRoleCollectionのクラスはPCIMeで定義されました。 そして、リソースのPolicyRuleかPolicyGroupとセットの間のリンケージはPolicyRoleCollectionのインスタンスによって表されます。 同等な値はPolicyRulesとPolicyGroupsのPolicyRolesの特性、およびPolicyRoleCollectionのPolicyRoleの特性で定義されるべきです。
3.2.5. CompoundPolicyConditions and CompoundPolicyActions
3.2.5. CompoundPolicyConditionsとCompoundPolicyActions
The concept of a CompoundPolicyCondition has also been imported into PCIMe from QPIM, and broadened to include a parallel CompoundPolicyAction. In both cases the idea is to create reusable "chunks" of policy that can exist as named elements in a ReusablePolicyContainer. The "Compound" classes and their associations incorporate the condition and action semantics that PCIM defined at the PolicyRule level: DNF/CNF for conditions, and ordering for actions.
また、CompoundPolicyConditionの概念を、QPIMからPCIMeにインポートされて、平行なCompoundPolicyActionを含むように広げてあります。 どちらの場合も、考えはReusablePolicyContainerの要素と命名されるように存在できる方針の再利用できる「塊」を作成することです。 「化合物」のクラスとそれらの協会はPCIMがPolicyRuleレベルで定義した状態と動作意味論を取り入れます: 状態のためのDNF/CNFと、動作のために注文すること。
Compound conditions and actions are defined to work with any component conditions and actions. In other words, while the components may be instances, respectively, of SimplePolicyCondition and SimplePolicyAction (discussed immediately below), they need not be.
複合条件と動作は、どんなコンポーネント状態と動作でも働くために定義されます。 言い換えれば、コンポーネントはそれぞれSimplePolicyConditionとSimplePolicyAction(すぐに、以下で議論する)のインスタンスであるかもしれませんが、それらはインスタンスである必要はありません。
Moore Standards Track [Page 8] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[8ページ]。
3.2.6. Variables and Values
3.2.6. 変数と値
The SimplePolicyCondition / PolicyVariable / PolicyValue structure has been imported into PCIMe from QPIM. A list of PCIMe-level variables is defined, as well as a list of PCIMe-level values. Other variables and values may, if necessary, be defined in submodels of PCIMe. For example, QPIM defines a set of implicit variables corresponding to fields in RSVP flows.
QPIMからSimplePolicyCondition/PolicyVariable/PolicyValue構造をPCIMeに輸入しました。 PCIMe-レベル変数のリストはPCIMe-レベル値のリストと同様に定義されます。 必要なら、他の変数と値はPCIMeの「副-モデル」で定義されるかもしれません。 例えば、QPIMはRSVP流れで分野に対応する暗黙の変数のセットを定義します。
A corresponding SimplePolicyAction / PolicyVariable / PolicyValue structure is also defined. While the semantics of a SimplePolicyCondition are "variable matches value", a SimplePolicyAction has the semantics "set variable to value".
また、対応するSimplePolicyAction/PolicyVariable/PolicyValue構造は定義されます。 SimplePolicyConditionの意味論は「変数は値に合っています」ですが、SimplePolicyActionは、意味論が「値に変数を設定すること」を持っています。
3.2.7. Domain-Level Packet Filtering
3.2.7. ドメインレベルパケットフィルタリング
For packet filtering specified at the domain level, a set of PolicyVariables and PolicyValues are defined, corresponding to the fields in an IP packet header plus the most common Layer 2 frame header fields. It is expected that domain-level policy conditions that filter on these header fields will be expressed in terms of CompoundPolicyConditions built up from SimplePolicyConditions that use these variables and values. An additional PolicyVariable, PacketDirection, is also defined, to indicate whether a packet being filtered is traveling inbound or outbound on an interface.
パケットとして、フィルタリングはドメインでレベル、PolicyVariablesの1セットを指定しました、そして、PolicyValuesは定義されます、IPパケットのヘッダーの分野と最も一般的なLayer2フレームヘッダーフィールドに対応しています。 これらのヘッダーフィールドのフィルタがCompoundPolicyConditionsに関して急送されるというドメインレベル保険約款がこれらの変数と値を使用するSimplePolicyConditionsから増したと予想されます。 また、追加PolicyVariable(PacketDirection)は、フィルターにかけられるパケットがインタフェースで旅行本国行きである、または外国行きであるかを示すために定義されます。
3.2.8. Device-Level Packet Filtering
3.2.8. 装置レベルパケットフィルタリング
For packet filtering expressed at the device level, including the packet classifier filters modeled in QDDIM, the variables and values discussed in Section 3.2.7 need not be used. Filter classes derived from the CIM FilterEntryBase class hierarchy are available for use in these contexts. These latter classes have two important differences from the domain-level classes:
装置レベルで言い表されたパケットフィルタリングのために、QDDIMでモデル化されたパケットクラシファイアフィルタを含んでいて、セクション3.2.7で議論した変数と値は使用される必要はありません。 CIM FilterEntryBaseクラス階層構造から得られたフィルタのクラスはこれらの文脈における使用に利用可能です。 これらの後者のクラスには、ドメインレベルのクラスからの2つの重要な違いがあります:
o They support specification of filters for all of the fields in a
particular protocol header in a single object instance. With the
domain-level classes, separate instances are needed for each
header field.
o 彼らは特定のプロトコルヘッダーの分野のすべてのためにただ一つの物の例でフィルタの仕様を支持します。 ドメインレベルのクラスと共に、別々の例が各ヘッダーフィールドに必要です。
o They provide native representations for the filter values, as
opposed to the string representation used by the domain-level
classes.
o 彼らはドメインレベルのクラスによって使用されたストリング表現と対照的にフィルタ値の固有の表現を提供します。
Device-level filter classes for the IP-related headers (IP, UDP, and TCP) and the 802 MAC headers are defined, respectively, in Sections 6.19 and 6.20.
IP関連のヘッダー(IP、UDP、およびTCP)と802個のMACヘッダーのための装置レベルフィルタのクラスはセクション6.19と6.20でそれぞれ定義されます。
Moore Standards Track [Page 9] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[9ページ]。
4. The Updated Class and Association Class Hierarchies
4. アップデートされたクラスと協会クラス階層構造
The following figure shows the class inheritance hierarchy for PCIMe. Changes from the PCIM hierarchy are noted parenthetically.
以下の図はPCIMeのためにクラス遺産階層構造を示しています。 PCIM階層構造からの変化は挿入的に注意されます。
ManagedElement (abstract)
|
+--Policy (abstract)
| |
| +---PolicySet (abstract -- new - 5.3)
| | |
| | +---PolicyGroup (moved - 5.3)
| | |
| | +---PolicyRule (moved - 5.3)
| |
| +---PolicyCondition (abstract)
| | |
| | +---PolicyTimePeriodCondition
| | |
| | +---VendorPolicyCondition
| | |
| | +---SimplePolicyCondition (new - 5.8.1)
| | |
| | +---CompoundPolicyCondition (new - 5.7.1)
| | |
| | +---CompoundFilterCondition (new - 5.9)
| |
| +---PolicyAction (abstract)
| | |
| | +---VendorPolicyAction
| | |
| | +---SimplePolicyAction (new - 5.8.4)
| | |
| | +---CompoundPolicyAction (new - 5.7.2)
| |
| +---PolicyVariable (abstract -- new - 5.8.5)
| | |
| | +---PolicyExplicitVariable (new - 5.8.6)
| | |
| | +---PolicyImplicitVariable (abstract -- new - 5.8.7)
| | |
| | +---(subtree of more specific classes -- new - 6.12)
| |
| +---PolicyValue (abstract -- new - 5.8.10)
| |
| +---(subtree of more specific classes -- new - 6.14)
|
+--Collection (abstract -- newly referenced)
ManagedElement(抽象的な)| +--方針(要約)| | | +---PolicySet(抽象的--新しい--の5.3)| | | | | +---PolicyGroup、(動き、--5.3)| | | | | +---PolicyRule、(動き、--5.3)| | | +---PolicyCondition(抽象的な)| | | | | +---PolicyTimePeriodCondition| | | | | +---VendorPolicyCondition| | | | | +---SimplePolicyCondition、(新しさ5.8、.1)| | | | | +---CompoundPolicyCondition、(新しさ5.7、.1)| | | | | +---CompoundFilterCondition(新しさ5.9)| | | +---PolicyAction(抽象的な)| | | | | +---VendorPolicyAction| | | | | +---SimplePolicyAction、(新しさ5.8、.4)| | | | | +---CompoundPolicyAction、(新しさ5.7、.2)| | | +---PolicyVariable(5.8に.5を新しく抜き取ります)| | | | | +---PolicyExplicitVariable、(新しさ5.8、.6)| | | | | +---PolicyImplicitVariable(5.8に.7を新しく抜き取ります)| | | | | +---(より特定の下位木は6.12を新しく分類します) | | | +---PolicyValue(5.8に.10を新しく抜き取ります)| | | +---(より特定の下位木は6.14を新しく分類します) | +--収集(要約--新たに参照をつけられます)
Moore Standards Track [Page 10] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[10ページ]。
| |
| +--PolicyRoleCollection (new - 5.6.2)
ManagedElement(abstract)
|
+--ManagedSystemElement (abstract)
|
+--LogicalElement (abstract)
|
+--System (abstract)
| |
| +--AdminDomain (abstract)
| |
| +---ReusablePolicyContainer (new - 5.2)
| |
| +---PolicyRepository (deprecated - 5.2)
|
+--FilterEntryBase (abstract -- new - 6.18)
| |
| +--IpHeadersFilter (new - 6.19)
| |
| +--8021Filter (new - 6.20)
|
+--FilterList (new - 6.21)
| | | + --PolicyRoleCollection、(新しい--、5.6.2)ManagedElement(要約)| +--ManagedSystemElement(抽象的な)| +--LogicalElement(抽象的な)| +--システム(要約)| | | +--AdminDomain(抽象的な)| | | +---ReusablePolicyContainer(新しさ5.2)| | | +---PolicyRepository、(推奨しなさ、--5.2)| +--FilterEntryBase(抽象的--新しい--の6.18)| | | +--IpHeadersFilter(新しさ6.19)| | | +--8021Filter(新しさ6.20)| +--FilterList(新しさ6.21)
Figure 1. Class Inheritance Hierarchy for PCIMe
図1。 PCIMeのためのクラス遺産階層構造
Moore Standards Track [Page 11] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[11ページ]。
The following figure shows the association class hierarchy for PCIMe. As before, changes from PCIM are noted parenthetically.
以下の図はPCIMeのために協会クラス階層構造を示しています。 従来と同様、PCIMからの変化は挿入的に注意されます。
[unrooted]
|
+---PolicyComponent (abstract)
| |
| +---PolicySetComponent (new - 5.3)
| |
| +---PolicyGroupInPolicyGroup (deprecated - 5.3)
| |
| +---PolicyRuleInPolicyGroup (deprecated - 5.3)
| |
| +---PolicyConditionStructure (abstract -- new - 5.7.1)
| | |
| | +---PolicyConditionInPolicyRule (moved - 5.7.1)
| | |
| | +---PolicyConditionInPolicyCondition (new - 5.7.1)
| |
| +---PolicyRuleValidityPeriod
| |
| +---PolicyActionStructure (abstract -- new - 5.7.2)
| | |
| | +---PolicyActionInPolicyRule (moved - 5.7.2)
| | |
| | +---PolicyActionInPolicyAction (new - 5.7.2)
| |
| +---PolicyVariableInSimplePolicyCondition (new - 5.8.2)
| |
| +---PolicyValueInSimplePolicyCondition (new - 5.8.2)
| |
| +---PolicyVariableInSimplePolicyAction (new - 5.8.4)
| |
| +---PolicyValueInSimplePolicyAction (new - 5.8.4)
[unrooted]
|
+---Dependency (abstract)
| |
| +---PolicyInSystem (abstract)
| | |
| | +---PolicySetInSystem (abstract, new - 5.3)
| | | |
| | | +---PolicyGroupInSystem
| | | |
| | | +---PolicyRuleInSystem
| | |
| | +---ReusablePolicy (new - 5.2)
| | |
[「非-根づ」きました]| +---PolicyComponent(抽象的な)| | | +---PolicySetComponent(新しさ5.3)| | | +---PolicyGroupInPolicyGroup、(推奨しなさ、--5.3)| | | +---PolicyRuleInPolicyGroup、(推奨しなさ、--5.3)| | | +---PolicyConditionStructure(5.7に.1を新しく抜き取ります)| | | | | +---PolicyConditionInPolicyRule、(動かされます--、5.7、.1)| | | | | +---PolicyConditionInPolicyCondition、(新しさ5.7、.1)| | | +---PolicyRuleValidityPeriod| | | +---PolicyActionStructure(5.7に.2を新しく抜き取ります)| | | | | +---PolicyActionInPolicyRule、(動かされます--、5.7、.2)| | | | | +---PolicyActionInPolicyAction、(新しさ5.7、.2)| | | +---PolicyVariableInSimplePolicyCondition、(新しさ5.8、.2)| | | +---PolicyValueInSimplePolicyCondition、(新しさ5.8、.2)| | | +---PolicyVariableInSimplePolicyAction、(新しさ5.8、.4)| | | +---PolicyValueInSimplePolicyAction、(新しさ5.8、.4[「非-根づ」きました])| +---依存(抽象的な)| | | +---PolicyInSystem(抽象的な)| | | | | +---PolicySetInSystem(新しさ5.3の要約)| | | | | | | +---PolicyGroupInSystem| | | | | | | +---PolicyRuleInSystem| | | | | +---ReusablePolicy(新しさ5.2)| | |
Moore Standards Track [Page 12] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[12ページ]。
| | +---PolicyConditionInPolicyRepository (deprecated - 5.2)
| | |
| | +---PolicyActionInPolicyRepository (deprecated - 5.2)
| |
| +---ExpectedPolicyValuesForVariable (new - 5.8)
| |
| +---PolicyRoleCollectionInSystem (new - 5.6.2)
|
+---Component (abstract)
| |
| +---SystemComponent
| | |
| | +---ContainedDomain (new - 5.2)
| | |
| | +---PolicyRepositoryInPolicyRepository (deprecated - 5.2)
| |
| +---EntriesInFilterList (new - 7.23)
|
+---MemberOfCollection (newly referenced)
|
+--- ElementInPolicyRoleCollection (new - 5.6.2)
| | +---PolicyConditionInPolicyRepository、(推奨しなさ、--5.2)| | | | | +---PolicyActionInPolicyRepository、(推奨しなさ、--5.2)| | | +---ExpectedPolicyValuesForVariable(新しさ5.8)| | | +---PolicyRoleCollectionInSystem、(新しさ5.6、.2)| +---コンポーネント(要約)| | | +---SystemComponent| | | | | +---ContainedDomain(新しさ5.2)| | | | | +---PolicyRepositoryInPolicyRepository、(推奨しなさ、--5.2)| | | +---EntriesInFilterList(新しさ7.23)| +---MemberOfCollection(新たに参照をつけられます)| +--- ElementInPolicyRoleCollection(新しさ5.6、.2)
Figure 2. Association Class Inheritance Hierarchy for PCIMe
図2。 PCIMeのための協会クラス遺産階層構造
In addition to these changes that show up at the class and association class level, there are other changes from PCIM involving individual class properties. In some cases new properties are introduced into existing classes, and in other cases existing properties are deprecated (without deprecating the classes that contain them).
クラスと協会クラスレベルで現れるこれらの変化に加えて、PCIMからの個々のクラス所有地にかかわる他の変化があります。 いくつかの場合、新しい資産は既存のクラスに取り入れられます、そして、他の場合では、既存の特性は推奨しないです(それらを含むクラスを非難することのない)。
5. Areas of Extension to PCIM
5. PCIMへの拡大の領域
The following subsections describe each of the areas for which PCIM extensions are being defined.
以下の小区分はPCIM拡張子が定義されているそれぞれの領域について説明します。
5.1. Policy Scope
5.1. 方針範囲
Policy scopes may be thought of in two dimensions: 1) the level of abstraction of the policy specification and 2) the applicability of policies to a set of managed resources.
方針範囲は二次元で考えられるかもしれません: 1) 方針仕様と2つのものの抽象化のレベル) 1セットの管理資源への方針の適用性。
5.1.1. Levels of Abstraction: Domain- and Device-Level Policies
5.1.1. 抽象化のレベル: ドメインと装置レベル方針
Policies vary in level of abstraction, from the business-level expression of service level agreements (SLAs) to the specification of a set of rules that apply to devices in a network. Those latter policies can, themselves, be classified into at least two groups:
方針は抽象化のレベルにおいて異なります、サービスレベル協定(SLA)のビジネスレベル表現からネットワークで装置に適用される1セットの規則の仕様まで。 それらの後者の方針がそうすることができる、自分たち、少なくとも2つのグループに分類されてください:
Moore Standards Track [Page 13] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[13ページ]。
those policies consumed by a Policy Decision Point (PDP) that specify the rules for an administrative and functional domain, and those policies consumed by a Policy Enforcement Point (PEP) that specify the device-specific rules for a functional domain. The higher-level rules consumed by a PDP, called domain-level policies, may have late binding variables unspecified, or specified by a classification, whereas the device-level rules are likely to have fewer unresolved bindings.
それらの方針は規則を指定する(PDP)がPolicy Decision Pointによって管理的、そして、機能的なドメインに消費されて、機能的なドメインに装置特有の規則を指定するPolicy Enforcement Point(PEP)によって消費されたそれらの方針を消費されました。 ドメインレベル方針と呼ばれるPDPによって消費されたよりハイレベルの規則は分類で遅延バインディング変数を不特定であるか、または指定されるようにするかもしれませんが、装置レベル規則は、より少ない未定の結合を持っていそうです。
There is a relationship between these levels of policy specification that is out of scope for this standards effort, but that is necessary in the development and deployment of a usable policy-based configuration system. An SLA-level policy transformation to the domain-level policy may be thought of as analogous to a visual builder that takes human input and develops a programmatic rule specification. The relationship between the domain-level policy and the device-level policy may be thought of as analogous to that of a compiler and linkage editor that translates the rules into specific instructions that can be executed on a specific type of platform.
すなわち、この規格の努力のための範囲の外に方針仕様のこれらのレベルの間には、関係がありますが、それが使用可能な方針ベースのコンフィギュレーションシステムの開発と展開で必要です。 ドメインレベル方針へのSLAレベル方針変化は人間の入力を取って、プログラムに従った規則仕様を開発する視覚建築業者への類似として考えられるかもしれません。 ドメインレベル方針と装置レベル方針との関係は特定のタイプのプラットホームで実行できる特定の指示に規則を翻訳するコンパイラとリンケージエディタのものへの類似として考えられるかもしれません。
PCIM and PCIMe may be used to specify rules at any and all of these levels of abstraction. However, at different levels of abstraction, different mechanisms may be more or less appropriate.
PCIMとPCIMeは、抽象化のこれらのレベルのありとあらゆるも規則を指定するのに使用されるかもしれません。 しかしながら、異なったレベルの抽象化では、異なったメカニズムは多少適切であるかもしれません。
5.1.2. Administrative and Functional Scopes
5.1.2. 管理的、そして、機能的な範囲
Administrative scopes for policy are represented in PCIM and in these extensions to PCIM as System subclass instances. Typically, a domain-level policy would be scoped by an AdminDomain instance (or by a hierarchy of AdminDomain instances) whereas a device-level policy might be scoped by a System instance that represents the PEP (e.g., an instance of ComputerSystem, see CIM [2]). In addition to collecting policies into an administrative domain, these System classes may also aggregate the resources to which the policies apply.
方針のための管理範囲はPCIMとSystemサブクラス例としてのPCIMへのこれらの拡大で表されます。 AdminDomain例(またはAdminDomain例の階層構造で)によって通常、ドメインレベル方針が見られるでしょうが、装置レベル方針がPEPを表すSystem例によって見られるかもしれない、(例えば、例、ComputerSystemでは、CIM[2])を見てください。 また、方針を管理ドメインに集めることに加えて、これらのSystemのクラスは方針が適用されるリソースに集められるかもしれません。
Functional scopes (sometimes referred to as functional domains) are generally defined by the submodels derived from PCIM and PCIMe, and correspond to the service or services to which the policies apply. So, for example, Quality of Service may be thought of as a functional scope, or Diffserv and Intserv may each be thought of as functional scopes. These scoping decisions are represented by the structure of the submodels derived from PCIM and PCIMe, and may be reflected in the number and types of PEP policy client(s), services, and the interaction between policies. Policies in different functional scopes are organized into disjoint sets of policy rules. Different functional domains may share some roles, some conditions, and even some actions. The rules from different functional domains may even be enforced at the same managed resource, but for the purposes of
機能的な範囲(時々機能的なドメインと呼ばれる)は、一般に、PCIMとPCIMeから得られた「副-モデル」によって定義されて、方針が適用されるサービスかサービスに対応しています。 そのように、例えば、ServiceのQualityが機能的な範囲として考えられるかもしれませんか、またはDiffservとIntservは機能的な範囲としてそれぞれ考えられるかもしれません。 決定を見るこれらは、PCIMとPCIMeから得られた「副-モデル」の構造によって表されて、方針の間のPEP方針クライアントの数とタイプ、サービス、および相互作用に反映されるかもしれません。 異なるところの機能的な範囲が組織化される方針は政策ルールのセットをばらばらにならせます。 異なった機能的なドメインはいくつかの役割、いくつかの状態、およびいくつかの動作さえ共有するかもしれません。 異なった機能的なドメインからの規則は同じ管理資源で実施されますが、目的のために実施さえされます。
Moore Standards Track [Page 14] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[14ページ]。
policy evaluation they are separate. See section 5.5.3 for more information.
政策評価は分離します。 詳しい情報に関してセクション5.5.3を見てください。
The functional scopes MAY be reflected in administrative scopes. That is, deployments of policy may have different administrative scopes for different functional scopes, but there is no requirement to do so.
機能的な範囲は管理範囲に反映されるかもしれません。 すなわち、方針の展開には異なった機能的な範囲への異なった管理範囲があるかもしれませんが、そうするという要件が全くありません。
5.2. Reusable Policy Elements
5.2. 再利用できるPolicy Elements
In PCIM, a distinction was drawn between reusable PolicyConditions and PolicyActions and rule-specific ones. The PolicyRepository class was also defined, to serve as a container for these reusable elements. The name "PolicyRepository" has proven to be an unfortunate choice for the class that serves as a container for reusable policy elements. This term is already used in documents like the Policy Framework, to denote the location from which the PDP retrieves all policy specifications, and into which the Policy Management Tool places all policy specifications. Consequently, the PolicyRepository class is being deprecated, in favor of a new class ReusablePolicyContainer.
PCIMでは、区別は再利用できるPolicyConditionsと、PolicyActionsと規則特有のものの間で引き起こされました。 また、PolicyRepositoryのクラスは、これらの再利用できる要素のための容器として機能するように定義されました。 "PolicyRepository"が再利用できる方針要素のための容器として機能するクラスのための不適切な選択であると立証した名前。 今期は、PDPがすべての方針仕様を検索して、Policy Management Toolがすべての方針仕様を置く位置を指示するのにPolicy Frameworkのようなドキュメントで既に使用されます。 その結果、PolicyRepositoryのクラスは新しいクラスReusablePolicyContainerを支持して非難されています。
When a class is deprecated, any associations that refer to it must also be deprecated. So replacements are needed for the two associations PolicyConditionInPolicyRepository and PolicyActionInPolicyRepository, as well as for the aggregation PolicyRepositoryInPolicyRepository. In addition to renaming the PolicyRepository class to ReusablePolicyContainer, however, PCIMe is also broadening the types of policy elements that can be reusable. Consequently, rather than providing one-for-one replacements for the two associations, a single higher-level association ReusablePolicy is defined. This new association allows any policy element (that is, an instance of any subclass of the abstract class Policy) to be placed in a ReusablePolicyContainer.
また、クラスが推奨しないときに、それについて言及するどんな協会も非難しなければなりません。 それで、交換が2の協会PolicyConditionInPolicyRepositoryとPolicyActionInPolicyRepository、および集合PolicyRepositoryInPolicyRepositoryに必要です。 しかしながら、PolicyRepositoryのクラスをReusablePolicyContainerに改名することに加えて、PCIMeはまた、再利用できる場合がある方針要素のタイプを広げています。 2つの協会への個人的には1個の交換品を提供するよりその結果、むしろ、単一の、よりハイレベルの協会ReusablePolicyは定義されます。 この新連合は、どんな方針要素(すなわち、抽象クラスPolicyのどんなサブクラスの例も)もReusablePolicyContainerに置かれるのを許容します。
Summarizing, the following changes in Sections 6 and 7 are the result of this item:
要約、セクション6と7における以下の変化はこの項目の結果です:
o The class ReusablePolicyContainer is defined.
o PCIM's PolicyRepository class is deprecated.
o The association ReusablePolicy is defined.
o PCIM's PolicyConditionInPolicyRepository association is
deprecated.
o PCIM's PolicyActionInPolicyRepository association is deprecated.
o The aggregation ContainedDomain is defined.
o PCIM's PolicyRepositoryInPolicyRepository aggregation is
deprecated.
o クラスReusablePolicyContainerは定義されます。o PCIMのPolicyRepositoryのクラスは推奨しないです。○ 協会ReusablePolicyは定義されます。o PCIMのPolicyConditionInPolicyRepository協会は推奨しないです。o PCIMのPolicyActionInPolicyRepository協会は推奨しないです。○ 集合ContainedDomainは定義されます。o PCIMのPolicyRepositoryInPolicyRepository集合は推奨しないです。
Moore Standards Track [Page 15] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[15ページ]。
5.3. Policy Sets
5.3. 方針セット
A "policy" can be thought of as a coherent set of rules to
administer, manage, and control access to network resources ("Policy
Terminology", reference [10]). The structuring of these coherent
sets of rules into subsets is enhanced in this document. In Section
5.4, we discuss the new options for the nesting of policy rules.
管理する一貫性を持っているセットの規則として「方針」を考えることができます、そして、管理してください、そして、ネットワーク資源へのアクセスを制御してください。(「方針用語。」(参照[10])) これらの一貫性を持っているセットの部分集合への規則の構造は本書では高められます。 セクション5.4では、私たちは政策ルールの巣篭もりのための新しいオプションについて議論します。
A new abstract class, PolicySet, is introduced to provide an abstraction for a set of rules. It is derived from Policy, and it is inserted into the inheritance hierarchy above both PolicyGroup and PolicyRule. This reflects the additional structural flexibility and semantic capability of both subclasses.
新しい抽象クラス(PolicySet)は、1セットの規則のための抽象化を提供するために紹介されます。 Policyからそれを得ます、そして、PolicyGroupとPolicyRuleの両方の上の遺産階層構造にそれを挿入します。 これは両方のサブクラスの追加構造的な柔軟で意味の能力を反映します。
Two properties are defined in PolicySet: PolicyDecisionStrategy and PolicyRoles. The PolicyDecisionStrategy property is included in PolicySet to define the evaluation relationship among the rules in the policy set. See Section 5.5 for more information. The PolicyRoles property is included in PolicySet to characterize the resources to which the PolicySet applies. See Section 5.6 for more information.
2つの特性がPolicySetで定義されます: PolicyDecisionStrategyとPolicyRoles。 PolicyDecisionStrategyの特性は、規則の中で方針セットで評価関係を定義するためにPolicySetに含まれています。 詳しい情報に関してセクション5.5を見てください。 PolicyRolesの特性は、PolicySetが適用するリソースを特徴付けるためにPolicySetに含まれています。 詳しい情報に関してセクション5.6を見てください。
Along with the definition of the PolicySet class, a new concrete aggregation class is defined that will also be discussed in the following sections. PolicySetComponent is defined as a subclass of PolicyComponent; it provides the containment relationship for a PolicySet in a PolicySet. PolicySetComponent replaces the two PCIM aggregations PolicyGroupInPolicyGroup and PolicyRuleInPolicyGroup, so these two aggregations are deprecated.
PolicySetのクラスの定義と共に、また、以下のセクションで議論する新しい具体的な集合のクラスは定義されます。 PolicySetComponentはPolicyComponentのサブクラスと定義されます。 それは封じ込め関係をPolicySetのPolicySetに供給します。 PolicyRuleInPolicyGroup、PolicySetComponentが2PCIM集合PolicyGroupInPolicyGroupを取り替えるので、これらの2つの集合が推奨しないです。
A PolicySet's relationship to an AdminDomain or other administrative scoping system (for example, a ComputerSystem) is represented by the PolicySetInSystem abstract association. This new association is derived from PolicyInSystem, and the PolicyGroupInSystem and PolicyRuleInSystem associations are now derived from PolicySetInSystem instead of directly from PolicyInSystem. The PolicySetInSystem.Priority property is discussed in Section 5.5.3.
AdminDomainか他の管理見るシステム(例えば、ComputerSystem)とのPolicySetの関係はPolicySetInSystemの抽象的な協会によって表されます。 PolicyInSystemからこの新連合を得ます、そして、現在、直接PolicyInSystemの代わりにPolicySetInSystemからPolicyGroupInSystemとPolicyRuleInSystem協会を得ます。 セクション5.5.3でPolicySetInSystem.Priorityの特性について議論します。
5.4. Nested Policy Rules
5.4. 入れ子にされた政策ルール
As previously discussed, policy is described by a set of policy rules that may be grouped into subsets. In this section we introduce the notion of nested rules, or the ability to define rules within rules. Nested rules are also called sub-rules, and we use both terms in this document interchangeably. The aggregation PolicySetComponent is used to represent the nesting of a policy rule in another policy rule.
以前に議論するように、方針は部分集合に分類されるかもしれない1セットの政策ルールで説明されます。 このセクションでは、私たちは入れ子にされた規則の概念、または規則の中で規則を定義する能力を紹介します。 また、入れ子にされた規則はサブ規則と呼ばれます、そして、私たちは両方の用語を本書では互換性を持って使用します。 集合PolicySetComponentは、別の政策ルールにおける、政策ルールの巣篭もりを表すのに使用されます。
Moore Standards Track [Page 16] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[16ページ]。
5.4.1. Usage Rules for Nested Rules
5.4.1. 入れ子にされた規則のための用法規則
The relationship between rules and sub-rules is defined as follows:
規則とサブ規則との関係は以下の通り定義されます:
o The parent rule's condition clause is a condition for evaluation
of all nested rules; that is, the conditions of the parent are
logically ANDed to the conditions of the sub-rules. If the parent
rule's condition clause evaluates to FALSE, sub-rules MAY be
skipped since they also evaluate to FALSE.
o 親規則の基本定款はすべての入れ子にされた規則の評価のための状態です。 すなわち、親の状態は論理的にそうです。サブ規則の状態へのANDed。 節がFALSE、サブ規則に評価する状態は親規則のものであるなら以来にスキップされるかもしれません。また、彼らはFALSEに評価します。
o If the parent rule's condition evaluates to TRUE, the set of sub-
rules SHALL BE evaluated according to the decision strategy and
priorities as discussed in Section 5.5.
o 親規則の状態がセクション5.5で議論する決定戦略とプライオリティに従って評価されたSHALL BEをTRUE、サブ規則のセットに評価するなら。
o If the parent rule's condition evaluates to TRUE, the parent
rule's set of actions is executed BEFORE execution of the sub-
rules actions. The parent rule's actions are not to be confused
with default actions. A default action is one that is to be
executed only if none of the more specific sub-rules are executed.
If a default action needs to be specified, it needs to be defined
as an action that is part of a catchall sub-rule associated with
the parent rule. The association linking the default action(s) in
this special sub-rule should have the lowest priority relative to
all other sub-rule associations:
o 親であるなら、状態がTRUE、親規則の動作のセットに評価する規則のものはサブ規則動作の実行されたBEFORE実行です。 親規則の動作はデフォルト動作に混乱しないことです。 デフォルト動作は、より特定のサブ規則のいずれも実行されない場合にだけ実行されることになっているものです。 デフォルト動作が、指定される必要があるなら、がらくた入れサブ規則の一部である動作が親規則と交際したので、それは、定義される必要があります。 この特別なサブ規則でデフォルト動作をリンクする協会は他のすべてのサブ規則協会に比例して最も低い優先度を持つべきです:
if parent-condition then parent rule's action
if condA then actA
if condB then ActB
if True then default action
condAの当時のactAであるならcondBの当時のActBであるならTrueの当時のデフォルト動作であるならその時親規則の動作を親と同じくらい条件とさせてくださいなら
Such a default action functions as a default when FirstMatching
decision strategies are in effect (see section 5.5). If
AllMatching applies, the "default" action is always performed.
FirstMatching決定戦略が有効であるときに(セクション5.5を見てください)、そのようなデフォルト動作はデフォルトとして機能します。 AllMatchingが適用するなら、「デフォルト」動作はいつも実行されます。
o Policy rules have a context in which they are executed. The rule
engine evaluates and applies the policy rules in the context of
the managed resource(s) that are identified by the policy roles
(or by an explicit association). Submodels MAY add additional
context to policy rules based on rule structure; any such
additional context is defined by the semantics of the action
classes of the submodel.
o 政策ルールには、それらが実行される文脈があります。 規則エンジンは、方針の役割(または明白な協会で)によって特定される管理資源の文脈の政策ルールを評価して、適用します。 Submodelsは規則構造に基づく政策ルールに追加文脈を追加するかもしれません。 そのようなどんな追加文脈も「副-モデル」の動作のクラスの意味論によって定義されます。
5.4.2. Motivation
5.4.2. 動機
Rule nesting enhances Policy readability, expressiveness and reusability. The ability to nest policy rules and form sub-rules is important for manageability and scalability, as it enables complex policy rules to be constructed from multiple simpler policy rules.
規則巣篭もりはPolicy読み易さ、表情の豊かさ、およびリユーザビリティを高めます。 管理可能性とスケーラビリティに、巣の政策ルールとフォームサブ規則への能力は重要です、複雑な政策ルールが複数の、より簡単な政策ルールから構成されるのを可能にするとき。
Moore Standards Track [Page 17] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[17ページ]。
These enhancements ease the policy management tools' task, allowing policy rules to be expressed in a way closer to how humans think.
これらの増進は政策管理ツールのタスクを緩和します、政策ルールが人間がどう考えるかの、より近くに方法で表されるのを許容して。
Although rule nesting can be used to suggest optimizations in the way policy rules are evaluated, as discussed in section 5.5.2 "Side Effects," nesting does not specify nor does it require any particular order of evaluation of conditions. Optimization of rule evaluation can be done in the PDP or in the PEP by dedicated code. This is similar to the relation between a high level programming language like C and machine code. An optimizer can create a more efficient machine code than any optimization done by the programmer within the source code. Nevertheless, if the PEP or PDP does not do optimization, the administrator writing the policy may be able to influence the evaluation of the policy rules for execution using rule nesting.
政策ルールが評価される方法で最適化を示すのに規則巣篭もりを使用できますが、巣篭もりはセクション5.5.2「副作用」で議論するように指定しません、そして、それは状態の評価の少しの特定の注文も必要としません。 PDPかひたむきなコードによるPEPで規則評価の最適化ができます。 これはCのような高い平らなプログラミング言語と機械コードとの関係と同様です。 オプティマイザはソースコードの中のプログラマによって行われたどんな最適化よりも効率的な機械コードを作成できます。 それにもかかわらず、PEPかPDPが最適化をしないなら、規則巣篭もりを使用することで方針を書いている管理者は実行のための政策ルールの評価に影響を及ぼすことができるかもしれません。
Nested rules are not designed for policy repository retrieval optimization. It is assumed that all rules and groups that are assigned to a role are retrieved by the PDP or PEP from the policy repository and enforced. Optimizing the number of rules retrieved should be done by clever selection of roles.
入れ子にされた規則は方針倉庫検索最適化のために設計されていません。 役割に割り当てられるすべての規則とグループがPDPかPEPによって方針倉庫から検索されて、励行されると思われます。 役割の賢明な品揃えで規則の数が検索した最適化をするべきです。
5.5. Priorities and Decision Strategies
5.5. プライオリティと決定戦略
A "decision strategy" is used to specify the evaluation method for the policies in a PolicySet. Two decision strategies are defined: "FirstMatching" and "AllMatching." The FirstMatching strategy is used to cause the evaluation of the rules in a set such that the only actions enforced on a given examination of the PolicySet are those for the first rule (that is, the rule with the highest priority) that has its conditions evaluate to TRUE. The AllMatching strategy is used to cause the evaluation of all rules in a set; for all of the rules whose conditions evaluate to TRUE, the actions are enforced. Implementations MUST support the FirstMatching decision strategy; implementations MAY support the AllMatching decision strategy.
「決定戦略」は、PolicySetの方針に評価方法を指定するのに使用されます。 2つの決定戦略が定義されます: "FirstMatching"と"AllMatching"。 FirstMatching戦略がセットにおける、規則の評価を引き起こすのに使用されるので、PolicySetの与えられた試験のときに励行された唯一の動作が状態がそれでTRUEに評価する最初の規則(すなわち、最優先がある規則)のためのそれらです。 AllMatching戦略はセットにおける、すべての規則の評価を引き起こすのに使用されます。 規則のすべて、状態がだれのものを評価する、TRUEに、動作は励行されます。 実現はFirstMatching決定戦略を支持しなければなりません。 実現はAllMatching決定戦略を支持するかもしれません。
As previously discussed, the PolicySet subclasses are PolicyGroup and PolicyRule: either subclass may contain PolicySets of either subclass. Loops, including the degenerate case of a PolicySet that contains itself, are not allowed when PolicySets contain other PolicySets. The containment relationship is specified using the PolicySetComponent aggregation.
以前に議論するように、PolicySetサブクラスは、PolicyGroupとPolicyRuleです: どちらのサブクラスもどちらかのサブクラスのPolicySetsを含むかもしれません。 PolicySetsが他のPolicySetsを含むとき、気持ちを抑えるPolicySetの堕落したケースを含む輪が許容されていません。 封じ込め関係は、PolicySetComponent集合を使用することで指定されます。
The relative priority within a PolicySet is established by the Priority property of the PolicySetComponent aggregation of the contained PolicyGroup and PolicyRule instances. The use of PCIM's PolicyRule.Priority property is deprecated in favor of this new property. The separation of the priority property from the rule has
PolicySetの中の相対的な優先権は含まれたPolicyGroupとPolicyRule例のPolicySetComponent集合のPriorityの特性によって確立されます。 PCIMのPolicyRule.Priorityの特性の使用はこの新しい特性を支持して非難されます。 規則からの特性が持っている優先権の分離
Moore Standards Track [Page 18] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[18ページ]。
two advantages. First, it generalizes the concept of priority, so that it can be used for both groups and rules. Second, it places the priority on the relationship between the parent policy set and the subordinate policy group or rule. The assignment of a priority value then becomes much easier, in that the value is used only in relationship to other priorities in the same set.
2つの利点。 まず最初に、それは、グループと規則の両方にそれを使用できるように優先権の概念を広めます。 2番目に、それは親方針セットと下位の方針グループか規則との関係に優先権を置きます。 次に、優先順位の値の課題ははるかに簡単になります、値が他のプライオリティとの関係だけに同じセットに使用されるので。
Together, the PolicySet.PolicyDecisionStrategy and PolicySetComponent.Priority determine the processing for the rules contained in a PolicySet. As before, the larger priority value represents the higher priority. Unlike the earlier definition, PolicySetComponent.Priority MUST have a unique value when compared with others defined for the same aggregating PolicySet. Thus, the evaluation of rules within a set is deterministically specified.
PolicySet.PolicyDecisionStrategyとPolicySetComponent.PriorityはPolicySetに含まれた規則のための処理を一緒に、決定します。 従来と同様、より大きい優先順位の値は、より高い優先度を表します。 以前の定義と異なって、同じ集合PolicySetのために定義される他のものと比べると、PolicySetComponent.Priorityにはユニークな値がなければなりません。 したがって、セットの中の規則の評価は決定論的に指定されます。
For a FirstMatching decision strategy, the first rule (that is, the one with the highest priority) in the set that evaluates to True, is the only rule whose actions are enforced for a particular evaluation pass through the PolicySet.
FirstMatching決定戦略(それがTrueに評価するセットにおける最初の規則(すなわち、最優先があるもの))が動作が特定の評価パスのためにPolicySetを通して励行される唯一の規則であるので。
For an AllMatching decision strategy, all of the matching rules are enforced. The relative priority of the rules is used to determine the order in which the actions are to be executed by the enforcement point: the actions of the higher priority rules are executed first. Since the actions of higher priority rules are executed first, lower priority rules that also match may get the "last word," and thus produce a counter-intuitive result. So, for example, if two rules both evaluate to True, and the higher priority rule sets the DSCP to 3 and the lower priority rule sets the DSCP to 4, the action of the lower priority rule will be executed later and, therefore, will "win," in this example, setting the DSCP to 4. Thus, conflicts between rules are resolved by this execution order.
AllMatching決定戦略において、合っている規則のすべてが実施されます。 規則の相対的な優先権は実施ポイントによって実行される動作がことである順番を決定するのに使用されます: より高い優先権規則の動作は最初に、実行されます。 より高い優先権規則の動作が最初に実行されるので、また、合っている低優先度規則は、「締め括りの言葉」を得て、その結果、直観に反している結果を生むかもしれません。 そのように、例えば、2つの規則がTrue、および、より高い優先権規則セットに3へのDSCPを評価して、低優先度規則が4にDSCPを設定すると、低優先度規則の動作は、後で実行されて、したがって、「勝つでしょう」、この例で、4にDSCPを設定して。 したがって、規則の間の闘争はこの実行命令で解決されています。
An implementation of the rule engine need not provide the action sequencing but the actions MUST be sequenced by the PEP or PDP on its behalf. So, for example, the rule engine may provide an ordered list of actions to be executed by the PEP and any required serialization is then provided by the service configured by the rule engine. See Section 5.5.2 for a discussion of side effects.
規則エンジンの実現は動作配列を提供する必要はありませんが、PEPかPDPがそのに代わって動作を配列しなければなりません。 そのように、例えば、PEPによって実行されるように、規則エンジンは動作の規則正しいリストを提供するかもしれません、そして、次に、規則エンジンで構成されたサービスでどんな必要な連載も提供します。 副作用の議論に関してセクション5.5.2を見てください。
5.5.1. Structuring Decision Strategies
5.5.1. 決定戦略を構造化します。
As discussed in Sections 5.3 and 5.4, PolicySet instances may be nested arbitrarily. For a FirstMatching decision strategy on a PolicySet, any contained PolicySet that matches satisfies the termination criteria for the FirstMatching strategy. A PolicySet is considered to match if it is a PolicyRule and its conditions evaluate to True, or if the PolicySet is a PolicyGroup and at least one of its
セクション5.3と5.4で議論するように、PolicySet例は任意に入れ子にされるかもしれません。 PolicySetの上のFirstMatching決定戦略のために、合っているどんな含まれたPolicySetもFirstMatching戦略の終了評価基準を満たします。 それがPolicyRuleであるならPolicySetが合わせると考えられて、状態がPolicySetがTrueかそれともPolicyGroupと少なくとも1つであるかどうかに評価する、それ
Moore Standards Track [Page 19] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[19ページ]。
contained PolicyGroups or PolicyRules match. The priority associated with contained PolicySets, then, determines when to terminate rule evaluation in the structured set of rules.
含まれたPolicyGroupsかPolicyRulesが合っています。 次に、含まれたPolicySetsに関連している優先権は、構造化されたセットの規則でいつ規則評価を終えるかを決定します。
In the example shown in Figure 3, the relative priorities for the nested rules, high to low, are 1A, 1B1, 1X2, 1B3, 1C, 1C1, 1X2 and 1C3. (Note that PolicyRule 1X2 is included in both PolicyGroup 1B and PolicyRule 1C, but with different priorities.) Of course, which rules are enforced is also dependent on which rules, if any, match.
図3の例では、入れ子にされた規則のための相対的な安値に高いプライオリティは、1 1Aと、1B1と、1×2と、1B3と、Cと、1C1と、1×2と1C3です。 (PolicyRule1X2がPolicyGroup 1BとPolicyRuleの両方に1C含まれていますが、異なったプライオリティで含まれていることに注意してください。) もちろん、また、どの規則が励行されるかも、もしあればどの規則が合っているかに依存しています。
PolicyGroup 1: FirstMatching
|
+-- Pri=6 -- PolicyRule 1A
|
+-- Pri=5 -- PolicyGroup 1B: AllMatching
| |
| +-- Pri=5 -- PolicyGroup 1B1: AllMatching
| | |
| | +---- etc.
| |
| +-- Pri=4 -- PolicyRule 1X2
| |
| +-- Pri=3 -- PolicyRule 1B3: FirstMatching
| |
| +---- etc.
|
+-- Pri=4 -- PolicyRule 1C: FirstMatching
|
+-- Pri=4 -- PolicyRule 1C1
|
+-- Pri=3 -- PolicyRule 1X2
|
+-- Pri=2 -- PolicyRule 1C3
PolicyGroup1: FirstMatching| +--Pri=6--PolicyRule 1A| +--Pri=5--PolicyGroup 1B: AllMatching| | | +--Pri=5--PolicyGroup 1B1: AllMatching| | | | | +---- など | | | +--Pri=4--PolicyRule1X2| | | +--Pri=3--PolicyRule 1B3: FirstMatching| | | +---- など | + --Pri=4--PolicyRule1C: FirstMatching| +--Pri=4--PolicyRule 1C1| +--Pri=3--PolicyRule1X2| +--Pri=2--PolicyRule 1C3
Figure 3. Nested PolicySets with Different Decision Strategies
図3。 異なった決定戦略がある入れ子にされたPolicySets
o Because PolicyGroup 1 has a FirstMatching decision strategy, if
the conditions of PolicyRule 1A match, its actions are enforced
and the evaluation stops.
o PolicyRule 1Aの状態が合っているならPolicyGroup1にはFirstMatching決定戦略があるので、動作は励行されます、そして、評価は止まります。
o If it does not match, PolicyGroup 1B is evaluated using an
AllMatching strategy. Since PolicyGroup 1B1 also has an
AllMatching strategy all of the rules and groups of rules
contained in PolicyGroup 1B1 are evaluated and enforced as
appropriate. PolicyRule 1X2 and PolicyRule 1B3 are also evaluated
and enforced as appropriate. If any of the sub-rules in the
o 合っていないなら、PolicyGroup 1Bは、AllMatching戦略を使用することで評価されます。 また、PolicyGroup 1B1にはAllMatching戦略があるので、規則のすべてとPolicyGroup 1B1に含まれた規則のグループは、適宜評価されて、励行されます。 PolicyRule1X2とPolicyRule 1B3は適宜また、評価されて、実施されます。 サブ規則のいずれでもあります。
Moore Standards Track [Page 20] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[20ページ]。
subtrees of PolicyGroup 1B evaluate to True, then PolicyRule 1C is
not evaluated because the FirstMatching strategy of PolicyGroup 1
has been satisfied.
PolicyGroup 1Bの下位木はTrue、当時のPolicyRuleに1Cを評価します。PolicyGroup1のFirstMatching戦略を満たしてあるので、評価されません。
o If neither PolicyRule 1A nor PolicyGroup 1B yield a match, then
PolicyRule 1C is evaluated. Since it is first matching, rules
1C1, 1X2, and 1C3 are evaluated until the first match, if any.
o PolicyRule 1AもPolicyGroup 1Bもマッチをもたらさないなら、PolicyRule1Cは評価されます。 最初に合っているので、規則の1C1、1×2、および1C3は初戦までもしあれば評価されます。
5.5.2. Side Effects
5.5.2. 副作用
Although evaluation of conditions is sometimes discussed as an ordered set of operations, the rule engine need not be implemented as a procedural language interpreter. Any side effects of condition evaluation or the execution of actions MUST NOT affect the result of the evaluation of other conditions evaluated by the rule engine in the same evaluation pass. That is, an implementation of a rule engine MAY evaluate all conditions in any order before applying the priority and determining which actions are to be executed.
状態の評価は1つの順序集合の操作として時々議論されていますが、規則エンジンは手続き型言語インタプリタとして実行される必要はありません。 状態評価のどんな副作用か動作の実行も同じ評価パスで規則エンジンによって評価された他の状態の評価の結果に影響してはいけません。 すなわち、規則エンジンの実現は実行されるために優先権を申し込んで、動作がどれであるかを決定する前に順不同なすべての状態を評価するかもしれません。
So, regardless of how a rule engine is implemented, it MUST NOT include any side effects of condition evaluation in the evaluation of conditions for either of the decision strategies. For both the AllMatching decision strategy and for the nesting of rules within rules (either directly or indirectly) where the actions of more than one rule may be enforced, any side effects of the enforcement of actions MUST NOT be included in condition evaluation on the same evaluation pass.
それで、規則エンジンがどう実行されるかにかかわらず、それは決定戦略のどちらかのための状態の評価における、状態評価のどんな副作用も含んではいけません。 AllMatching決定戦略と1つ以上の規則の動作が励行されるかもしれない規則(直接か間接的である)の中の規則の巣篭もりのための両方に関しては、同じ評価パスにおける状態評価に動作の実施のどんな副作用も含んではいけません。
5.5.3. Multiple PolicySet Trees For a Resource
5.5.3. リソースのための複数のPolicySet木
As shown in the example in Figure 3., PolicySet trees are defined by the PolicySet subclass instances and the PolicySetComponent aggregation instances between them. Each PolicySet tree has a defined set of decision strategies and evaluation priorities. In section 5.6 we discuss some improvements in the use of PolicyRoles that cause the parent PolicySet.PolicyRoles to be applied to all contained PolicySet instances. However, a given resource may still have multiple, disjoint PolicySet trees regardless of how they are collected. These top-level PolicySet instances are called "unrooted" relative to the given resource.
図3.、PolicySetの例に木がPolicySetサブクラス例とそれらの間のPolicySetComponent集合例によって定義されるのが示されるように。 それぞれのPolicySet木には、定義されたセットの決定戦略と評価プライオリティがあります。 セクション5.6で、私たちはすべての含まれたPolicySet例に親PolicySet.PolicyRolesを適用させるPolicyRolesの使用におけるいくつかの改良について議論します。 しかしながら、与えられたリソースには、倍数がまだあるかもしれなくて、それらがどう集められるかにかかわらずPolicySet木をばらばらにならせてください。 これらのトップレベルPolicySet例は与えられたリソースに比例して"「非-根づ」く"であると呼ばれます。
So, a PolicySet instance is defined to be rooted or unrooted in the context of a particular managed element; the relationship to the managed element is usually established by the policy roles of the PolicySet instance and of the managed element (see 5.6 "Policy Roles"). A PolicySet instance is unrooted in that context if and only if there is no PolicySetComponent association to a parent PolicySet that is also related to the same managed element. These
それで、PolicySet例は特定の管理された要素の文脈に根づくか、または「非-根づ」くために定義されます。 通常、管理された要素との関係はPolicySet例と管理された要素の方針の役割によって確立されます(5.6「方針の役割」を見てください)。 そして、PolicySet例がその文脈に「非-根づ」く、また、親PolicySetへのPolicySetComponent協会が全くない場合にだけ、それは同じ管理された要素に関連します。 これら
Moore Standards Track [Page 21] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[21ページ]。
PolicySetComponent aggregations are traversed up the tree without regard to how a PolicySet instance came to be related with the ManagedElement. Figure 4. shows an example where instance A has role A, instance B has role B and so on. In this example, in the context of interface X, instances B, and C are unrooted and instances D, E, and F are all rooted. In the context of interface Y, instance A is unrooted and instances B, C, D, E and F are all rooted.
PolicySetComponent集合は木で関係なしでPolicySet例がどうManagedElementに関連づけられるようになったかに横断されます。 図4は、例Aには役割Aがあるところに例Bが役割Bなどを持っているのを例に示します。 この例では、インタフェースXの文脈の例B、およびCは「非-根づ」きます、そして、例D、E、およびFはすべて根づきます。 インタフェースYの文脈では、例Aは「非-根づ」きます、そして、例B、C、D、E、およびFはすべて根づきます。
+---+ +-----------+ +-----------+
| A | | I/F X | | I/F Y |
+---+ | has roles | | has roles |
/ \ | B & C | | A & B |
/ \ +-----------+ +-----------+
+---+ +---+
| B | | C |
+---+ +---+
/ \ \
/ \ \
+---+ +---+ +---+
| D | | E | | F |
+---+ +---+ +---+
+---+ +-----------+ +-----------+ | A| | I/F X| | I/F Y| +---+ | 役割を持っています。| | 役割を持っています。| / \ | B&C| | A&B| / \ +-----------+ +-----------+ +---+ +---+ | B| | C| +---+ +---+ / \ \ / \ \ +---+ +---+ +---+ | D| | E| | F| +---+ +---+ +---+
Figure 4. Unrooted PolicySet Instances
図4。 Unrooted PolicySet例
For those cases where there are multiple unrooted PolicySet instances that apply to the same managed resource (i.e., not in a common PolicySetComponent tree), the decision strategy among these disjoint PolicySet instances is the FirstMatching strategy. The priority used with this FirstMatching strategy is defined in the PolicySetInSystem association. The PolicySetInSystem subclass instances are present for all PolicySet instances (it is a required association) but the priority is only used as a default for unrooted PolicySet instances in a given ManagedElement context.
同じ管理資源(すなわち、普通のPolicySetComponent木でないところの)に適用される複数のunrooted PolicySet例があるそれらのケースのために、これらの中の戦略がPolicySet例をばらばらにならせるという決定はFirstMatching戦略です。 このFirstMatching戦略で使用される優先権はPolicySetInSystem協会で定義されます。 PolicySetInSystemサブクラス例はすべてのPolicySet例のために存在していますが(それは必要な協会です)、優先権は与えられたManagedElement文脈のunrooted PolicySet例にデフォルトとして使用されるだけです。
The FirstMatching strategy is used among all unrooted PolicySet instances that apply to a given resource for a given functional domain. So, for example, the PolicySet instances that are used for QoS policy and the instances that are used for IKE policy, although they are disjoint, are not joined in a FirstMatching decision strategy. Instead, they are evaluated independently of one another.
FirstMatching戦略は与えられた機能的なドメインのための与えられたリソースに適用されるすべてのunrooted PolicySet例の中で使用されます。 そのように、例えば、ばらばらになって、QoS方針に使用されるPolicySet例とそれらがIKE方針使用されましたが、使用された例はFirstMatching決定戦略に接合されません。 代わりに、それらはお互いの如何にかかわらず評価されます。
5.5.4. Deterministic Decisions
5.5.4. 決定論的な決定
As previously discussed, PolicySetComponent.Priority values MUST be unique within a containing PolicySet and PolicySetInSystem.Priority values MUST be unique for an associated System. Each PolicySet, then, has a deterministic behavior based upon the decision strategy and uniquely defined priority.
以前に議論するように、PolicySetComponent.Priority値は関連Systemに、ユニークであるに違いないPolicySetとPolicySetInSystem.Priorityが、評価する含有の中でユニークであるに違いありません。 そして、各PolicySetは決定論的な振舞いを決定戦略と唯一定義された優先権に基づかせています。
Moore Standards Track [Page 22] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[22ページ]。
There are certainly cases where rules need not have a unique priority value (i.e., where evaluation and execution priority is not important). However, it is believed that the flexibility gained by this capability is not sufficiently beneficial to justify the possible variations in implementation behavior and the resulting confusion that might occur.
確かにケースが規則がユニークな優先順位の値を持つ必要はないところ(すなわち、評価と実行優先権が重要でないところ)にあります。 しかしながら、この能力によって獲得された柔軟性が実現の振舞いの可能な変化と起こるかもしれない結果として起こる混乱は正当化できるくらいには有利でないと信じられています。
5.6. Policy Roles
5.6. 方針の役割
A policy role is defined in [10] as "an administratively specified characteristic of a managed element (for example, an interface). It is a selector for policy rules and PRovisioning Classes (PRCs), to determine the applicability of the rule/PRC to a particular managed element."
方針の役割は[10]で「管理された要素(例えば、インタフェース)の行政上指定された特性」と定義されます。 「それは、規則/PRCの適用性を特定の管理された要素まで決定するためには政策ルールのためのセレクタとPRovisioning Classes(PRCs)です。」
In PCIMe, PolicyRoles is defined as a property of PolicySet, which is inherited by both PolicyRules and PolicyGroups. In this document, we also add PolicyRole as the identifying name of a collection of resources (PolicyRoleCollection), where each element in the collection has the specified role characteristic.
PCIMeでは、PolicyRolesはPolicySetの特性と定義されます。(PolicySetはPolicyRulesとPolicyGroupsの両方によって引き継がれます)。 また、本書では、私たちは収集における各要素が指定された役割を独特にするリソース(PolicyRoleCollection)の収集の特定名としてPolicyRoleを加えます。
5.6.1. Comparison of Roles in PCIM with Roles in snmpconf
5.6.1. RolesがsnmpconfにあるPCIMでのRolesの比較
In the Configuration Management with SNMP (snmpconf) working group's Policy Based Management MIB [14], policy rules are of the form
SNMP(snmpconf)ワーキンググループのPolicy Based Management MIB[14]とConfiguration Managementでは、政策ルールはフォームのものです。
if <policyFilter> then <policyAction>
<のpolicyFilterの>の当時の<policyAction>です。
where <policyFilter> is a set of conditions that are used to determine whether or not the policy applies to an object instance. The policy filter can perform comparison operations on SNMP variables already defined in MIBS (e.g., "ifType == ethernet").
<policyFilter>が方針が物の例に適用されるかどうか決定するのに使用される1セットの状態であるところ。 方針フィルタはMIBS(例えば、「ifType=イーサネット」)で既に定義されたSNMP変数に比較操作を実行できます。
The policy management MIB defined in [14] defines a Role table that enables one to associate Roles with elements, where roles have the same semantics as in PCIM. Then, since the policyFilter in a policy allows one to define conditions based on the comparison of the values of SNMP variables, one can filter elements based on their roles as defined in the Role group.
[14]で定義された政策管理MIBは1つが役割がPCIMに同じ意味論を持っている要素にRolesを関連づけるのを可能にするRoleテーブルを定義します。 そして、方針によるpolicyFilterが人にSNMP変数の値の比較に基づく状態を定義させるので、1つはRoleグループで定義されるようにそれらの役割に基づく要素をフィルターにかけることができます。
This approach differs from that adopted in PCIM in the following ways. First, in PCIM, a set of role(s) is associated with a policy rule as the values of the PolicyRoles property of a policy rule. The semantics of role(s) are then expected to be implemented by the PDP (i.e., policies are applied to the elements with the appropriate roles). In [14], however, no special processing is required for
このアプローチはPCIMに以下の方法で採用されたそれと異なっています。 まず最初に、PCIMでは、1セットの役割は政策ルールのPolicyRolesの特性の値として政策ルールに関連しています。 そして、役割の意味論はPDPによって実行されると予想されます(すなわち、方針は適切な役割で要素に適用されます)。 しかしながらいいえ特別な処理が必要である[14]で
Moore Standards Track [Page 23] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[23ページ]。
realizing the semantics of roles; roles are treated just as any other SNMP variables and comparisons of role values can be included in the policy filter of a policy rule.
役割の意味論がわかります。 役割はちょうど政策ルールの方針フィルタに役割の値のいかなる他のSNMP変数と比較も含むことができるように扱われます。
Secondly, in PCIM, there is no formally defined way of associating a role with an object instance, whereas in [14] this is done via the use of the Role tables (pmRoleESTable and pmRoleSETable). The Role tables associate Role values with elements.
第二に、PCIMでは、テーブル(pmRoleESTableとpmRoleSETable)を物の例に役割を関連づける正式に定義された方法ではありませんが、[14] これでRoleの使用でします。 RoleテーブルはRole値を要素に関連づけます。
5.6.2. Addition of PolicyRoleCollection to PCIMe
5.6.2. PCIMeへのPolicyRoleCollectionの添加
In order to remedy the latter shortcoming in PCIM (the lack of a way of associating a role with an object instance), PCIMe has a new class PolicyRoleCollection derived from the CIM Collection class. Resources that share a common role are aggregated by a PolicyRoleCollection instance, via the ElementInPolicyRoleCollection aggregation. The role is specified in the PolicyRole property of the aggregating PolicyRoleCollection instance.
PCIM(物の例に役割を関連づける方法の不足)で後者の短所を改善するために、PCIMeにはPolicyRoleCollectionがCIM Collectionのクラスから引き出した新しいクラスがあります。 一般的な役割を共有するリソースがPolicyRoleCollection例によってElementInPolicyRoleCollection集合で集められます。 役割は集合PolicyRoleCollection例のPolicyRole所有地で指定されます。
A PolicyRoleCollection always exists in the context of a system. As was done in PCIM for PolicyRules and PolicyGroups, an association, PolicyRoleCollectionInSystem, captures this relationship. Remember that in CIM, System is a base class for describing network devices and administrative domains.
PolicyRoleCollectionはシステムの文脈にいつも存在しています。 PolicyRulesとPolicyGroupsのためにPCIMでしたように、協会(PolicyRoleCollectionInSystem)はこの関係を得ます。 CIMでは、Systemがネットワーク装置と管理ドメインについて説明するための基底クラスであることを覚えていてください。
The association between a PolicyRoleCollection and a system should be consistent with the associations that scope the policy rules/groups that are applied to the resources in that collection. Specifically, a PolicyRoleCollection should be associated with the same System as the applicable PolicyRules and/or PolicyGroups, or to a System higher in the tree formed by the SystemComponent association. When a PEP belongs to multiple Systems (i.e., AdminDomains), and scoping by a single domain is impractical, two alternatives exist. One is to arbitrarily limit domain membership to one System/AdminDomain. The other option is to define a more global AdminDomain that simply includes the others, and/or that spans the business or enterprise.
PolicyRoleCollectionとシステムとの協会はその収集におけるリソースに適用される政策ルール/グループを見る関係と一致しているべきです。 明確に、PolicyRoleCollectionは適切なPolicyRules、そして/または、PolicyGroupsか、Systemへの同じSystemにSystemComponent協会によって形成された木で、より高く関連しているべきです。 PEPが複数のSystems(すなわち、AdminDomains)に属して、単一領域のそばで見るのが非実用的であるときに、2つの選択肢が存在しています。 人は任意にドメイン会員資格を1System/AdminDomainに制限することになっています。 別の選択肢は単に他のものを含んで、ビジネスか企業にかかるよりグローバルなAdminDomainを定義することです。
As an example, suppose that there are 20 traffic trunks in a network, and that an administrator would like to assign three of them to provide "gold" service. Also, the administrator has defined several policy rules which specify how the "gold" service is delivered. For these rules, the PolicyRoles property (inherited from PolicySet) is set to "Gold Service".
例として、ネットワークには20個の交通トランクスがあって、管理者が「金」サービスを提供するためにそれらの3つを割り当てたがっていると仮定してください。 また、管理者はどう「金」サービスを提供するかを指定するいくつかの政策ルールを定義しました。 これらの規則において、PolicyRolesの特性(PolicySetから、世襲する)は「ゴールドサービス」に設定されます。
In order to associate three traffic trunks with "gold" service, an instance of the PolicyRoleCollection class is created and its PolicyRole property is also set to "Gold Service". Following this, the administrator associates three traffic trunks with the new
「金」サービスに3個の交通トランクスを関連づけるために、PolicyRoleCollectionのクラスの例は作成されます、そして、また、PolicyRoleの特性は「ゴールドサービス」に設定されます。 これに続いて、管理者は3個の交通トランクスを新しさに関連づけます。
Moore Standards Track [Page 24] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[24ページ]。
instance of PolicyRoleCollection via the ElementInPolicyRoleCollection aggregation. This enables a PDP to determine that the "Gold Service" policy rules apply to the three aggregated traffic trunks.
ElementInPolicyRoleCollection集合を通したPolicyRoleCollectionの例。 これは、PDPが、「ゴールドサービス」政策ルールが3個の集められた交通トランクスに適用されることを決定するのを可能にします。
Note that roles are used to optimize policy retrieval. It is not mandatory to implement roles or, if they have been implemented, to group elements in a PolicyRoleCollection. However, if roles are used, then either the collection approach should be implemented, or elements should be capable of reporting their "pre-programmed" roles (as is done in COPS).
役割が方針検索を最適化するのに使用されることに注意してください。 役割を実行するのが義務的でないか、またはそれらであるなら実行されて、PolicyRoleCollectionの要素を分類してください、そうした。 しかしながら、役割が使用されているなら、収集アプローチが実行されるべきですか、または要素はそれらの「あらかじめプログラムされた」役割を報告できるべきです(COPSでするように)。
5.6.3. Roles for PolicyGroups
5.6.3. PolicyGroupsのための役割
In PCIM, role(s) are only associated with policy rules. However, it may be desirable to associate role(s) with groups of policy rules. For example, a network administrator may want to define a group of rules that apply only to Ethernet interfaces. A policy group can be defined with a role-combination="Ethernet", and all the relevant policy rules can be placed in this policy group. (Note that in PCIMe, role(s) are made available to PolicyGroups as well as to PolicyRules by moving PCIM's PolicyRoles property up from PolicyRule to the new abstract class PolicySet. The property is then inherited by both PolicyGroup and PolicyRule.) Then every policy rule in this policy group implicitly inherits this role-combination from the containing policy group. A similar implicit inheritance applies to nested policy groups.
単にPCIMでは、役割は政策ルールに関連しています。 しかしながら、政策ルールのグループに役割を関連づけるのは望ましいかもしれません。 例えば、ネットワーク管理者はイーサネットインタフェースだけに適用される規則のグループを定義したがっているかもしれません。 役割組み合わせ=「イーサネット」で方針グループを定義できます、そして、すべての関連政策ルールをこの方針グループに置くことができます。 (PCIMeでは、役割をPolicyRulesに関してPolicyRuleから新しい抽象クラスPolicySetまでPCIMのPolicyRolesの特性を上げることによってまた、PolicyGroupsに利用可能にすることに注意してください。 そして、特性はPolicyGroupとPolicyRuleの両方によって引き継がれます。) そして、この方針グループのあらゆる政策ルールがそれとなく含有からのこの役割組み合わせ方針グループを引き継ぎます。 同様の暗黙の遺産は入れ子にされた方針グループに申請されます。
There is no explicit copying of role(s) from container to contained entity. Obviously, this implicit inheritance of role(s) leads to the possibility of defining inconsistent role(s) (as explained in the example below); the handling of such inconsistencies is beyond the scope of PCIMe.
役割の明白な容器から含まれた実体までのコピーがありません。 明らかに、役割のこの暗黙の遺産は矛盾した役割を定義する可能性につながります(以下の例で説明されるように)。 そのような矛盾の取り扱いはPCIMeの範囲を超えています。
Moore Standards Track [Page 25] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[25ページ]。
As an example, suppose that there is a PolicyGroup PG1 that contains three PolicyRules, PR1, PR2, and PR3. Assume that PG1 has the roles "Ethernet" and "Fast". Also, assume that the contained policy rules have the role(s) shown below:
例として、3PolicyRules、PR1、PR2、およびPR3を含むPolicyGroup PG1があると仮定してください。 PG1には役割の「イーサネット」があって、「速い」と仮定してください。 また、含まれた政策ルールには以下に示された役割があると仮定してください:
+------------------------------+
| PolicyGroup PG1 |
| PolicyRoles = Ethernet, Fast |
+------------------------------+
|
| +------------------------+
| | PolicyRule PR1 |
|--------| PolicyRoles = Ethernet |
| +------------------------+
|
| +--------------------------+
| | PolicyRule PR2 |
|--------| PolicyRoles = <undefined>|
| +--------------------------+
|
| +------------------------+
| | PolicyRule PR3 |
|--------| PolicyRoles = Slow |
+------------------------+
+------------------------------+ | PolicyGroup PG1| | PolicyRolesは速くイーサネットと等しいです。| +------------------------------+ | | +------------------------+ | | PolicyRule PR1| |--------| PolicyRolesはイーサネットと等しいです。| | +------------------------+ | | +--------------------------+ | | PolicyRule PR2| |--------| PolicyRolesは<と未定義の状態で等しいです。>|、| +--------------------------+ | | +------------------------+ | | PolicyRule PR3| |--------| PolicyRoles=は遅くなります。| +------------------------+
Figure 5. Inheritance of Roles
図5。 役割の遺産
In this example, the PolicyRoles property value for PR1 is consistent with the value in PG1, and in fact, did not need to be redefined. The value of PolicyRoles for PR2 is undefined. Its roles are implicitly inherited from PG1. Lastly, the value of PolicyRoles for PR3 is "Slow". This appears to be in conflict with the role, "Fast," defined in PG1. However, whether these roles are actually in conflict is not clear. In one scenario, the policy administrator may have wanted only "Fast"- "Ethernet" rules in the policy group. In another scenario, the administrator may be indicating that PR3 applies to all "Ethernet" interfaces regardless of whether they are "Fast" or "Slow." Only in the former scenario (only "Fast"- "Ethernet" rules in the policy group) is there a role conflict.
そして、この例では、PR1のためのPolicyRoles資産価値がPG1の値と一致している、事実上、再定義される必要はなくなってください。 PR2のためのPolicyRolesの値は未定義です。 役割はPG1からそれとなく引き継がれます。 最後に、PR3のためのPolicyRolesの値は「遅いです」。 これは「速く」PG1で定義される役割との闘争にはあるように見えます。 しかしながら、これらの役割が実際に闘争中であるかは、明確ではありません。 1つのシナリオでは、方針管理者は「速く」だけ欲しかったかもしれません--方針グループの「イーサネット」規則。 別のシナリオでは、管理者は、それらが「速い」か「遅いこと」にかかわらずPR3がすべての「イーサネット」インタフェースに適用するのを示しているかもしれません。 前のシナリオ(方針による「イーサネット」規則は「速く」だけ分類される)だけには、役割葛藤があります。
Note that it is possible to override implicitly inherited roles via appropriate conditions on a PolicyRule. For example, suppose that PR3 above had defined the following conditions:
PolicyRuleに関する適切な状態でそれとなく引き継がれた役割をくつがえすのが可能であることに注意してください。 例えば、上のPR3が以下の条件を定義したと仮定してください:
(interface is not "Fast") and (interface is "Slow")
そして(インタフェースは「速くない」)。(インタフェースは「遅いです」)
This results in unambiguous semantics for PR3.
これはPR3のための明白な意味論をもたらします。
Moore Standards Track [Page 26] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[26ページ]。
5.7. Compound Policy Conditions and Compound Policy Actions
5.7. 合成保険約款と合成政策的措置
Compound policy conditions and compound policy actions are introduced to provide additional reusable "chunks" of policy.
方針の追加再利用できる「塊」を提供するために合成保険約款と合成政策的措置を導入します。
5.7.1. Compound Policy Conditions
5.7.1. 合成保険約款
A CompoundPolicyCondition is a PolicyCondition representing a Boolean combination of simpler conditions. The conditions being combined may be SimplePolicyConditions (discussed below in Section 6.4), but the utility of reusable combinations of policy conditions is not necessarily limited to the case where the component conditions are simple ones.
CompoundPolicyConditionは、より簡単な状態のブール組み合わせを表すPolicyConditionです。 結合される状態はSimplePolicyConditionsであるかもしれません(以下では、セクション6.4で議論する)が、保険約款の再利用できる組み合わせに関するユーティリティは必ずコンポーネント状態が簡単なものであるケースに制限されるというわけではありません。
The PCIM extensions to introduce compound policy conditions are relatively straightforward. Since the purpose of the extension is to apply the DNF / CNF logic from PCIM's PolicyConditionInPolicyRule aggregation to a compound condition that aggregates simpler conditions, the following changes are required:
合成保険約款を導入するPCIM拡張子は比較的簡単です。 拡大の目的がPCIMのPolicyConditionInPolicyRule集合から、より簡単な状態に集められる複合条件にDNF / CNF論理を適用することであるので、以下の変化が必要です:
o Create a new aggregation PolicyConditionInPolicyCondition, with
the same GroupNumber and ConditionNegated properties as
PolicyConditionInPolicyRule. The cleanest way to do this is to
move the properties up to a new abstract aggregation superclass
PolicyConditionStructure, from which the existing aggregation
PolicyConditionInPolicyRule and a new aggregation
PolicyConditionInPolicyCondition are derived. For now there is no
need to re-document the properties themselves, since they are
already documented in PCIM as part of the definition of the
PolicyConditionInPolicyRule aggregation.
o PolicyConditionInPolicyRuleとして同じGroupNumberとConditionNegatedの特性がある新しい集合PolicyConditionInPolicyConditionを作成してください。 これをする最も清潔な方法は特性をsuperclass PolicyConditionStructureであって、既存の集合PolicyConditionInPolicyRuleと新しい集合PolicyConditionInPolicyConditionがどれであるかから派生している新しい抽象的な集合まで動かすことです。 当分、特性自体を再記録する必要は全くありません、それらがPolicyConditionInPolicyRule集合の定義の一部として既にPCIMに記録されるので。
o It is also necessary to define a concrete subclass
CompoundPolicyCondition of PolicyCondition, to introduce the
ConditionListType property. This property has the same function,
and works in exactly the same way, as the corresponding property
currently defined in PCIM for the PolicyRule class.
o また、PolicyConditionのコンクリートサブクラスCompoundPolicyConditionを定義するのも、ConditionListType資産を紹介するのに必要です。 この特性は、同じ機能を持っていて、まさに同じように働いています、現在PolicyRuleのクラスのためにPCIMで定義されている対応する特性として。
The class and property definitions for representing compound policy conditions are below, in Section 6.
合成保険約款を表すためのクラスと特性の定義がセクション6に以下にあります。
5.7.2. Compound Policy Actions
5.7.2. 合成政策的措置
A compound action is a convenient construct to represent a sequence of actions to be applied as a single atomic action within a policy rule. In many cases, actions are related to each other and should be looked upon as sub-actions of one "logical" action. An example of such a logical action is "shape & mark" (i.e., shape a certain stream to a set of predefined bandwidth characteristics and then mark these
合成動作はただ一つの原子動作として政策ルールの中で適用されるために動作の系列を表す便利な構造物です。 多くの場合、動作は、互いに関連して、1つの「論理的な」動作のサブ動作として見られるべきです。 そのような論理的な動きに関する例が「形とマーク」である、(すなわち、1セットの事前に定義された帯域幅の特性に、ある流れを形成してください、そして、次に、これらをマークしてください。
Moore Standards Track [Page 27] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[27ページ]。
packets with a certain DSCP value). This logical action is actually composed of two different QoS actions, which should be performed in a well-defined order and as a complete set.
あるDSCP値があるパケット) この論理的な動きは実際に2つの異なったQoS動作で構成されます。(動作は明確な注文と、そして、完全なセットとして実行されるべきです)。
The CompoundPolicyAction construct allows one to create a logical relationship between a number of actions, and to define the activation logic associated with this logical action.
CompoundPolicyAction構造物で、人は、多くの動作の間の論理的関係性を作成して、この論理的な動きに関連している起動論理を定義します。
The CompoundPolicyAction construct allows the reusability of these complex actions, by storing them in a ReusablePolicyContainer and reusing them in different policy rules. Note that a compound action may also be aggregated by another compound action.
CompoundPolicyAction構造物はこれらの複雑な動きのリユーザビリティを許容します、ReusablePolicyContainerにそれらを格納して、異なった政策ルールでそれらを再利用することによって。 また、合成動作が別の合成動作で集められるかもしれないことに注意してください。
As was the case with CompoundPolicyCondition, the PCIM extensions to introduce compound policy actions are relatively straightforward. This time the goal is to apply the property ActionOrder from PCIM's PolicyActionInPolicyRule aggregation to a compound action that aggregates simpler actions. The following changes are required:
CompoundPolicyConditionがあるケースのように、合成政策的措置を導入するPCIM拡張子は比較的簡単です。 今回、目標はPCIMのPolicyActionInPolicyRule集合から、より簡単な動きに集められる合成動作に特性のActionOrderを適用することです。 以下の変化が必要です:
o Create a new aggregation PolicyActionInPolicyAction, with the same
ActionOrder property as PolicyActionInPolicyRule. The cleanest
way to do this is to move the property up to a new abstract
aggregation superclass PolicyActionStructure, from which the
existing aggregation PolicyActionInPolicyRule and a new
aggregation PolicyActionInPolicyAction are derived.
o PolicyActionInPolicyRuleと同じActionOrderの特性で新しい集合PolicyActionInPolicyActionを作成してください。 これをする最も清潔な方法は特性をsuperclass PolicyActionStructureであって、既存の集合PolicyActionInPolicyRuleと新しい集合PolicyActionInPolicyActionがどれであるかから派生している新しい抽象的な集合まで動かすことです。
o It is also necessary to define a concrete subclass
CompoundPolicyAction of PolicyAction, to introduce the
SequencedActions property. This property has the same function,
and works in exactly the same way, as the corresponding property
currently defined in PCIM for the PolicyRule class.
o また、PolicyActionのコンクリートサブクラスCompoundPolicyActionを定義するのも、SequencedActions資産を紹介するのに必要です。 この特性は、同じ機能を持っていて、まさに同じように働いています、現在PolicyRuleのクラスのためにPCIMで定義されている対応する特性として。
o Finally, a new property ExecutionStrategy is needed for both the
PCIM class PolicyRule and the new class CompoundPolicyAction. This
property allows the policy administrator to specify how the PEP
should behave in the case where there are multiple actions
aggregated by a PolicyRule or by a CompoundPolicyAction.
o 最終的に、新しい特性のExecutionStrategyがPCIMのクラスPolicyRuleと新しいクラスCompoundPolicyActionの両方に必要です。 この特性で、方針管理者はPEPがPolicyRuleかCompoundPolicyActionによって集められた複数の動作がある場合でどう振る舞うはずであるかを指定できます。
The class and property definitions for representing compound policy actions are below, in Section 6.
合成政策的措置を表すためのクラスと特性の定義がセクション6に以下にあります。
5.8. Variables and Values
5.8. 変数と値
The following subsections introduce several related concepts, including PolicyVariables and PolicyValues (and their numerous subclasses), SimplePolicyConditions, and SimplePolicyActions.
以下の小区分はPolicyVariables、PolicyValues(そして、彼らの多数のサブクラス)、SimplePolicyConditions、およびSimplePolicyActionsを含むいくつかの関連する概念を紹介します。
Moore Standards Track [Page 28] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[28ページ]。
5.8.1. Simple Policy Conditions
5.8.1. 簡単な保険約款
The SimplePolicyCondition class models elementary Boolean expressions of the form: "(<variable> MATCH <value>)". The relationship 'MATCH', which is implicit in the model, is interpreted based on the variable and the value. Section 5.8.3 explains the semantics of the 'MATCH' operator. Arbitrarily complex Boolean expressions can be formed by chaining together any number of simple conditions using relational operators. Individual simple conditions can be negated as well. Arbitrarily complex Boolean expressions are modeled by the class CompoundPolicyCondition (described in Section 5.7.1).
SimplePolicyConditionのクラスは形式の基本の論理式をモデル化します: 「(<の可変>マッチ<値の>)。」 関係'MATCH'(モデルで暗に示されている)が変数と値に基づいて解釈されます。 セクション5.8 .3 'MATCH'オペレータの意味論について説明します。 関係演算子を使用することでいろいろな単純条件を一緒にチェーニングすることによって、任意に複雑な論理式を形成できます。 また、個々の単純条件を否定できます。 任意に複雑な論理式はクラスCompoundPolicyCondition(セクション5.7.1では、説明される)によってモデル化されます。
For example, the expression "SourcePort == 80" can be modeled by a simple condition. In this example, 'SourcePort' is a variable, '==' is the relational operator denoting the equality relationship (which is generalized by PCIMe to a "MATCH" relationship), and '80' is an integer value. The complete interpretation of a simple condition depends on the binding of the variable. Section 5.8.5 describes variables and their binding rules.
例えば、表現、「単純条件はSourcePort=80インチをモデル化できます」。 'これでは、例、'SourcePort'による変数、'='が平等関係(PCIMeによって「マッチ」関係に一般化される)、および80年を指示する関係演算子であるということです'は整数値です。 単純条件の完全な解釈は変数の結合によります。 セクション5.8 .5 変数とそれらの拘束力がある規則について説明します。
The SimplePolicyCondition class refines the basic structure of the PolicyCondition class defined in PCIM by using the pair (<variable>, <value>) to form the condition. Note that the operator between the variable and the value is always implied in PCIMe: it is not a part of the formal notation.
SimplePolicyConditionのクラスはPCIMで状態を形成するのに、組(<の可変>、<値の>)を使用することによって定義されたPolicyConditionのクラスの基本構造を洗練します。 変数と値の間のオペレータがPCIMeでいつも含意されることに注意してください: それは正式な記法の一部ではありません。
The variable specifies the attribute of an object that should be matched when evaluating the condition. For example, for a QoS model, this object could represent the flow that is being conditioned. A set of predefined variables that cover network attributes commonly used for filtering is introduced in PCIMe, to encourage interoperability. This list covers layer 3 IP attributes such as IP network addresses, protocols and ports, as well as a set of layer 2 attributes (e.g., MAC addresses).
変数は状態を評価するとき合わせられるべきであるオブジェクトの属性を指定します。 例えば、QoSモデルのために、このオブジェクトは条件としている流れを表すかもしれません。 フィルタリングに一般的に使用されるネットワーク属性をカバーする1セットの事前に定義された変数は、相互運用性を奨励するためにPCIMeで紹介されます。 このリストはIPネットワーク・アドレスや、プロトコルやポートなどの層3のIP属性をカバーしています、1セットの層2の属性(例えば、MACアドレス)と同様に。
The bound variable is matched against a value to produce the Boolean result. For example, in the condition "The source IP address of the flow belongs to the 10.1.x.x subnet", a source IP address variable is matched against a 10.1.x.x subnet value.
束縛変項は、ブール結果を生むために値に取り組まされます。 例えば、「流れのソースIPアドレスは10.1.x.xサブネットに属す」という条件で、ソースIPアドレス変数は10.1.x.xサブネット価値に取り組まされます。
5.8.2. Using Simple Policy Conditions
5.8.2. 簡単な保険約款を使用します。
Simple conditions can be used in policy rules directly, or as building blocks for creating compound policy conditions.
直接か合成保険約款を作成するためのブロックとして政策ルールで単純条件を使用できます。
Simple condition composition MUST enforce the following data-type conformance rule: The ValueTypes property of the variable must be compatible with the type of the value class used. The simplest (and
単純条件構成は以下のデータ型順応規則を実施しなければなりません: 変数のValueTypesの特性は使用される値のクラスのタイプと互換性があるに違いありません。 そして最も簡単である、(。
Moore Standards Track [Page 29] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[29ページ]。
friendliest, from a user point-of-view) way to do this is to equate the type of the value class with the name of the class. By ensuring that the ValueTypes property of the variable matches the name of the value class used, we know that the variable and value instance values are compatible with each other.
最も好意的です、ユーザ観点) 道から、これをするのは、値のクラスのタイプをクラスの名前と同一視することです。 変数のValueTypesの特性が使用される値のクラスの名前に合っているのを確実にすることによって、私たちは、変数と値のインスタンス値は互いと互換性があるのを知っています。
Composing a simple condition requires that an instance of the class SimplePolicyCondition be created, and that instances of the variable and value classes that it uses also exist. Note that the variable and/or value instances may already exist as reusable objects in an appropriate ReusablePolicyContainer.
単純条件を構成するのは、クラスSimplePolicyConditionのインスタンスが作成されて、また、それが使用する変数と値のクラスのインスタンスが存在するのを必要とします。 変数、そして/または、値のインスタンスが再利用できるオブジェクトとして適切なReusablePolicyContainerに既に存在するかもしれないことに注意してください。
Two aggregations are used in order to create the pair (<variable>, <value>). The aggregation PolicyVariableInSimplePolicyCondition relates a SimplePolicyCondition to a single variable instance. Similarly, the aggregation PolicyValueInSimplePolicyCondition relates a SimplePolicyCondition to a single value instance. Both aggregations are defined in this document.
2つの集合が、組(<の可変>、<値の>)を創設するのに使用されています。 集合PolicyVariableInSimplePolicyConditionはただ一つの可変インスタンスにSimplePolicyConditionに関連します。 同様に、集合PolicyValueInSimplePolicyConditionはただ一つの値のインスタンスにSimplePolicyConditionに関連します。 両方の集合は本書では定義されます。
Figure 6. depicts a SimplePolicyCondition with its associated variable and value. Also shown are two PolicyValue instances that identify the values that the variable can assume.
図6はその記録変数と値でSimplePolicyConditionについて表現します。 また、示されているのは、変数が仮定できる値を特定する2つのPolicyValueインスタンスです。
+-----------------------+
| SimplePolicyCondition |
+-----------------------+
* @
* @
+------------------+ * @ +---------------+
| (PolicyVariable) |*** @@@| (PolicyValue) |
+------------------+ +---------------+
# #
# ooo #
# #
+---------------+ +---------------+
| (PolicyValue) | ooo | (PolicyValue) |
+---------------+ +---------------+
+-----------------------+ | SimplePolicyCondition| +-----------------------+ * @ * @ +------------------+ * @ +---------------+ | (PolicyVariable) |*** @@@| (PolicyValue) | +------------------+ +---------------+ ###ooo###+---------------+ +---------------+ | (PolicyValue) | ooo| (PolicyValue) | +---------------+ +---------------+
Aggregation Legend:
**** PolicyVariableInSimplePolicyCondition
@@@@ PolicyValueInSimplePolicyCondition
#### ExpectedPolicyValuesForVariable
集合伝説: **** PolicyVariableInSimplePolicyCondition@@@@PolicyValueInSimplePolicyCondition####ExpectedPolicyValuesForVariable
Figure 6. SimplePolicyCondition
図6。 SimplePolicyCondition
Note: The class names in parenthesis denote subclasses. The classes named in the figure are abstract, and thus cannot themselves be instantiated.
以下に注意してください。 挿入句のクラス名はサブクラスを指示します。 その結果、図で指定されたクラスが抽象的である、自分たち、例示できてください。
Moore Standards Track [Page 30] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[30ページ]。
5.8.3. The Simple Condition Operator
5.8.3. 単純条件オペレータ
A simple condition models an elementary Boolean expression of the form "variable MATCHes value". However, the formal notation of the SimplePolicyCondition, together with its associations, models only a pair, (<variable>, <value>). The 'MATCH' operator is not directly modeled -- it is implied. Furthermore, this implied 'MATCH' operator carries overloaded semantics.
単純条件は「可変MATCHesは評価する」形式の基本の論理式をモデル化します。 しかしながら、SimplePolicyConditionの正式な記法は関係と共に1組だけ、(<の可変>、<価値の>)をモデル化します。 'MATCH'オペレータは直接モデル化されません--それは含意されます。 その上、この暗示している'MATCH'オペレータは積みすぎられた意味論を運びます。
For example, in the simple condition "DestinationPort MATCH '80'", the interpretation of the 'MATCH' operator is equality (the 'equal' operator). Clearly, a different interpretation is needed in the following cases:
'例えば「DestinationPortは80年に合う'という簡単な状態」で、'MATCH'オペレータの解釈は平等('等しい'オペレータ)です。 明確に、異なった解釈が以下の場合で必要です:
o "DestinationPort MATCH {'80', '8080'}" -- operator is 'IS SET
MEMBER'
o 「'DestinationPort MATCH、80年、''8080'、」、--オペレータが'IS SET MEMBER'である
o "DestinationPort MATCH {'1 to 255'}" -- operator is 'IN INTEGER
RANGE'
o 「DestinationPort MATCH'1〜255'」--オペレータは'IN INTEGER RANGE'です。
o "SourceIPAddress MATCH 'MyCompany.com'" -- operator is 'IP ADDRESS
AS RESOLVED BY DNS'
o 「SourceIPAddress MATCH'MyCompany.com'」--オペレータは'IP ADDRESS AS RESOLVED BY DNS'です。
The examples above illustrate the implicit, context-dependent nature of the 'MATCH' operator. The interpretation depends on the actual variable and value instances in the simple condition. The interpretation is always derived from the bound variable and the value instance associated with the simple condition. Text accompanying the value class and implicit variable definition is used for interpreting the semantics of the 'MATCH' relationship. In the following list, we define generic (type-independent) matching.
上記の例は'MATCH'オペレータの暗黙の、そして、文脈依存する本質を例証します。 解釈は単純条件の実際の変数と値のインスタンスに依存します。 単純条件に関連している束縛変項と値のインスタンスから解釈をいつも得ます。 値のクラスと暗黙の可変定義に伴うテキストは、'MATCH'関係の意味論を解釈するのに使用されます。 以下のリストでは、私たちはジェネリックの(タイプから独立する)のマッチングを定義します。
PolicyValues may be multi-fielded, where each field may contain a range of values. The same equally holds for PolicyVariables. Basically, we have to deal with single values (singleton), ranges ([lower bound .. upper bound]), and sets (a,b,c). So independent of the variable and value type, the following set of generic matching rules for the 'MATCH' operator are defined.
PolicyValuesがそうである、マルチ、戦闘配置につける、各分野がさまざまな値を含むかもしれないところ。 同じくらいはPolicyVariablesのために等しく成立します。 基本的に、私たちはただ一つの値(単独個体)、範囲([下界上限])、およびセット(a、b、c)と取り引きしなければなりません。 変数と値のタイプからとても独立しています、'MATCH'オペレータのための以下のセットのジェネリックの合っている規則は定義されます。
o singleton matches singleton -> the matching rule is defined in the
type
o マッチングが統治する単独個体マッチ単独個体->はタイプで定義されます。
o singleton matches range [lower bound .. upper bound] -> the
matching evaluates to true, if the singleton matches the lower
bound or the upper bound or a value in between
o 単独個体はマッチングが本当に評価する範囲[下界上限]->に合っています、単独個体が中間で下界、上限または値に合っているなら
Moore Standards Track [Page 31] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[31ページ]。
o singleton matches set -> the matching evaluates to true, if the
value of the singleton matches one of the components in the set,
where a component may be a singleton or range again
o 単独個体マッチはマッチングが本当に評価する->を設定します、単独個体の値がセット(コンポーネントは、再び単独個体か範囲であるかもしれない)でコンポーネントの1つに合っているなら
o ranges [A..B] matches singleton -> is true if A matches B matches
singleton
o 範囲[A..B]マッチ単独個体->はAが合っているなら本当に、Bが単独個体に合っているということです。
o range [A..B] matches range [X..Y] -> the matching evaluates to
true, if all values of the range [A..B] are also in the range
[X..Y]. For instance, [3..5] match [1..6] evaluates to true,
whereas [3..5] match [4..6] evaluates to false.
o 範囲[A..B]はマッチングが本当に評価する範囲[X..Y]->に合っています、範囲[A..B]のすべての値が範囲[X..Y]にもあるなら。 例えば、真[4 .6]を合わせますが[3 .5]、[3 .5]マッチ[1 .6]が評価する、誤っているのに評価します。
o range [A..B] matches set (a,b,c, ...) -> the matching evaluates to
true, if all values in the range [A..B] are part of the set. For
instance, range [2..3] match set ([1..2],3) evaluates to true, as
well as range [2..3] match set (2,3), and range [2..3] match set
([1..2],[3..5]).
o 範囲[A..B]マッチは(a、b、c)を設定します。 -マッチングが範囲[A..B]のすべての値がセットの一部であるなら本当に評価する>。 例えば、範囲[2 .3]マッチセット[1 .2、]3)は範囲と同様に本当[2 .3]のマッチセット(2、3)、および範囲[2 .3]マッチセットに([1 .2]、[3 .5])を評価します。
o set (a,b,c, ...) match singleton -> is true if a match b match c
match ... match singleton
o セット(a、b、c)マッチ単独個体->はマッチbマッチcマッチ…マッチ単独個体であるなら本当です。
o set match range -> the matching evaluates to true, if all values
in the set are part of the range. For example, set (2,3) match
range [1..4] evaluates to true.
o セットにおけるすべての値が範囲の一部であるならマッチングが本当に評価するマッチ範囲->を設定してください。 例えば(2、3)マッチ範囲[1 .4]が本当に評価するセット。
o set (a,b,c,...) match set (x,y,z,...) -> the matching evaluates to
true, if all values in the set (a,b,c,...) are part of the set
(x,y,z,...). For example, set (1,2,3) match set (1,2,3,4)
evaluates to true. Set (1,2,3) match set (1,2) evaluates to
false.
o セット(a、b、c)マッチは(x、y、z)を設定しました。 -マッチングがセット(a、b、c)におけるすべての値がセット(x、y、z)の一部であるなら本当に評価する>。 例えば、(1、2、3、4)が本当に評価する(1、2、3)マッチセットを設定してください。 セット(1、2、3)は(1、2)が誤っているのに評価するセットに合っています。
Variables may contain various types (Section 6.11.1). When not stated otherwise, the type of the value bound to the variable at condition evaluation time and the value type of the PolicyValue instance need to be of the same type. If they differ, then the condition evaluates to FALSE.
変数は様々なタイプ(セクション6.11.1)を含むかもしれません。 別の方法で述べられないと、価値のタイプは状態評価時間に変数にバウンドします、そして、PolicyValueインスタンスの値のタイプは同じタイプにはある必要があります。 彼らが異なるなら、状態がFALSEに評価するその時です。
The ExpectedPolicyValuesForVariable association specifies an expected set of values that can be matched with a variable within a simple condition. Using this association, a source or destination port can be limited to the range 0-200, a source or destination IP address can be limited to a specified list of IPv4 address values, etc.
ExpectedPolicyValuesForVariable協会は単純条件の中で変数に合わせることができる予想されたセットの値を指定します。 この協会、ソースまたは仕向港を使用するのを範囲0-200に制限できて、ソースか送付先IPアドレスをIPv4アドレス値などの明細表に制限できます。
Moore Standards Track [Page 32] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[32ページ]。
+-----------------------+
| SimplePolicyCondition |
+-----------------------+
* @
* @
* @
+-----------------------------------+ +--------------------------+
| Name=SmallSourcePorts | | Name=Port300 |
| Class=PolicySourcePortVariable | | Class=PolicyIntegerValue |
| ValueTypes=[PolicyIntegerValue] | | IntegerList = [300] |
+-----------------------------------+ +--------------------------+
#
#
#
+-------------------------+
|Name=SmallPortsValues |
|Class=PolicyIntegerValue |
|IntegerList=[1..200] |
+-------------------------+
+-----------------------+ | SimplePolicyCondition| +-----------------------+ * @ * @ * @ +-----------------------------------+ +--------------------------+ | 名前=SmallSourcePorts| | 名前=Port300| | クラス=PolicySourcePortVariable| | クラス=PolicyIntegerValue| | ValueTypesは[PolicyIntegerValue]と等しいです。| | IntegerListは[300]と等しいです。| +-----------------------------------+ +--------------------------+ # # # +-------------------------+ |名前=SmallPortsValues| |クラス=PolicyIntegerValue| |IntegerList=[1 .200]| +-------------------------+
Aggregation Legend:
**** PolicyVariableInSimplePolicyCondition
@@@@ PolicyValueInSimplePolicyCondition
#### ExpectedPolicyValuesForVariable
集合伝説: **** PolicyVariableInSimplePolicyCondition@@@@PolicyValueInSimplePolicyCondition####ExpectedPolicyValuesForVariable
Figure 7. An Invalid SimplePolicyCondition
図7。 無効のSimplePolicyCondition
The ability to express these limitations appears in the model to support validation of a SimplePolicyCondition prior to its deployment to an enforcement point. A Policy Management Tool, for example SHOULD NOT accept the SimplePolicyCondition shown in Figure 7. If, however, a policy rule containing this condition does appear at an enforcement point, the expected values play no role in the determination of whether the condition evaluates to True or False. Thus in this example, the SimplePolicyCondition evaluates to True if the source port for the packet under consideration is 300, and it evaluates to False otherwise.
これらの制限を言い表す能力は展開の前に実施ポイントにSimplePolicyConditionの合法化をサポートするモデルに現れます。 Policy Management Toolであり、例えば、SHOULD NOTは図7で見せられたSimplePolicyConditionを受け入れます。 しかしながら、方針が、この状態を含むのが実施ポイント、期待値プレーで決断におけるどんな役割にも見えないと裁決する、状態はTrueかFalseに評価します。 その結果この例、SimplePolicyConditionが考慮しているパケットのためのソースポートが300であるならTrueに評価してそうでなければそれがFalseに評価するコネ。
5.8.4. SimplePolicyActions
5.8.4. SimplePolicyActions
The SimplePolicyAction class models the elementary set operation. "SET <variable> TO <value>". The set operator MUST overwrite an old value of the variable. In the case where the variable to be updated is multi- valued, the only update operation defined is a complete replacement of all previous values with a new set. In other words, there are no Add or Remove [to/from the set of values] operations defined for SimplePolicyActions.
SimplePolicyActionのクラスは基本の集合演算をモデル化します。 「<値の>に<の可変>を設定してください。」 セットオペレータは変数の古い値を上書きしなければなりません。 アップデートされるべき変数がマルチ評価されている場合では、操作が定義した唯一のアップデートは新しいセットがある前のすべての値の完全な交換です。 言い換えれば、SimplePolicyActionsのために定義されたAddかRemove[値のセットからの/への]操作が全くありません。
Moore Standards Track [Page 33] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[33ページ]。
For example, the action "set DSCP to EF" can be modeled by a simple action. In this example, 'DSCP' is an implicit variable referring to the IP packet header DSCP field. 'EF' is an integer or bit string value (6 bits). The complete interpretation of a simple action depends on the binding of the variable.
例えば、単純アクションで動作「EFへのセットDSCP」をモデル化できます。 この例では、'DSCP'はIPパケットのヘッダーDSCP野原について言及する暗黙の変数です。 'EF'は、整数かビット列値(6ビット)です。 単純アクションの完全な解釈は変数の結合によります。
The SimplePolicyAction class refines the basic structure of the PolicyAction class defined in PCIM, by specifying the contents of the action using the (<variable>, <value>) pair to form the action. The variable specifies the attribute of an object. The value of this attribute is set to the value specified in <value>. Selection of the object is a function of the type of variable involved. See Sections 5.8.6 and 5.8.7, respectively, for details on object selection for explicitly bound and implicitly bound policy variables.
SimplePolicyActionのクラスはPCIMで定義されたPolicyActionのクラスの基本構造を洗練します、動作を形成するのに(<の可変>、<値の>)組を使用することで動作のコンテンツを指定することによって。 変数はオブジェクトの属性を指定します。 この属性の値は<値の>で指定された値に設定されます。 オブジェクトの選択は変数のかかわったタイプの関数です。 セクション5.8 .6と5.8を見てください、.7 それぞれ、明らかに制限されてそれとなく制限された政策変数のためのオブジェクト選択に関する詳細のために。
SimplePolicyActions can be used in policy rules directly, or as building blocks for creating CompoundPolicyActions.
直接かCompoundPolicyActionsを作成するためのブロックとして政策ルールでSimplePolicyActionsを使用できます。
The set operation is only valid if the list of types of the variable (ValueTypes property of PolicyImplicitVariable) includes the specified type of the value. Conversion of values from one representation into another is not defined. For example, a variable of IPv4Address type may not be set to a string containing a DNS name. Conversions are part of an implementation-specific mapping of the model.
変数(PolicyImplicitVariableのValueTypesの特性)のタイプのリストが価値の指定されたタイプを含んでいる場合にだけ、集合演算は有効です。 別のものへの1つの表現からの値の変換は定義されません。 例えば、IPv4Addressタイプの変数はDNS名を含むストリングに設定されないかもしれません。 変換はモデルの実装特有のマッピングの一部です。
As was the case with SimplePolicyConditions, the role of expected values for the variables that appear in SimplePolicyActions is for validation, prior to the time when an action is executed. Expected values play no role in action execution.
SimplePolicyConditionsがあるケースのように、SimplePolicyActionsに現れる変数のための期待値の役割は合法化のためのものです、時代に動作が実行される前。 期待値は動作中のどんな役割も果たしません。実行。
Composing a simple action requires that an instance of the class SimplePolicyAction be created, and that instances of the variable and value classes that it uses also exist. Note that the variable and/or value instances may already exist as reusable objects in an appropriate ReusablePolicyContainer.
単純アクションを構成するのは、クラスSimplePolicyActionのインスタンスが作成されて、また、それが使用する変数と値のクラスのインスタンスが存在するのを必要とします。 変数、そして/または、値のインスタンスが再利用できるオブジェクトとして適切なReusablePolicyContainerに既に存在するかもしれないことに注意してください。
Two aggregations are used in order to create the pair (<variable>, <value>). The aggregation PolicyVariableInSimplePolicyAction relates a SimplePolicyAction to a single variable instance. Similarly, the aggregation PolicyValueInSimplePolicyAction relates a SimplePolicyAction to a single value instance. Both aggregations are defined in this document.
2つの集合が、組(<の可変>、<値の>)を創設するのに使用されています。 集合PolicyVariableInSimplePolicyActionはただ一つの可変インスタンスにSimplePolicyActionに関連します。 同様に、集合PolicyValueInSimplePolicyActionはただ一つの値のインスタンスにSimplePolicyActionに関連します。 両方の集合は本書では定義されます。
Figure 8. depicts a SimplePolicyAction with its associated variable and value.
エイト環その記録変数と値でSimplePolicyActionについて表現します。
Moore Standards Track [Page 34] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[34ページ]。
+-----------------------+
| SimplePolicyAction |
| |
+-----------------------+
* @
* @
+------------------+ * @ +---------------+
| (PolicyVariable) |*** @@@| (PolicyValue) |
+------------------+ +---------------+
# #
# ooo #
# #
+---------------+ +---------------+
| (PolicyValue) | ooo | (PolicyValue) |
+---------------+ +---------------+
+-----------------------+ | SimplePolicyAction| | | +-----------------------+ * @ * @ +------------------+ * @ +---------------+ | (PolicyVariable) |*** @@@| (PolicyValue) | +------------------+ +---------------+ ###ooo###+---------------+ +---------------+ | (PolicyValue) | ooo| (PolicyValue) | +---------------+ +---------------+
Aggregation Legend:
**** PolicyVariableInSimplePolicyAction
@@@@ PolicyValueInSimplePolicyAction
#### ExpectedPolicyValuesForVariable
集合伝説: **** PolicyVariableInSimplePolicyAction@@@@PolicyValueInSimplePolicyAction####ExpectedPolicyValuesForVariable
Figure 8. SimplePolicyAction
エイト環。 SimplePolicyAction
5.8.5. Policy Variables
5.8.5. 政策変数
A variable generically represents information that changes (or "varies"), and that is set or evaluated by software. In policy, conditions and actions can abstract information as "policy variables" to be evaluated in logical expressions, or set by actions.
変数は一般的にソフトウェアによって変化して(または、「異なる」)、設定されるか、または評価される情報を表します。 方針で、状態と動作は論理式で評価されるべきであるか、または動作で設定されるべき「政策変数」としての抽象的な情報をそうすることができます。
PCIMe defines two types of PolicyVariables, PolicyImplicitVariables and PolicyExplicitVariables. The semantic difference between these classes is based on modeling context. Explicit variables are bound to exact model constructs, while implicit variables are defined and evaluated outside of a model. For example, one can imagine a PolicyCondition testing whether a CIM ManagedSystemElement's Status property has the value "Error." The Status property is an explicitly defined PolicyVariable (i.e., it is defined in the context of the CIM Schema, and evaluated in the context of a specific instance). On the other hand, network packets are not explicitly modeled or instantiated, since there is no perceived value (at this time) in managing at the packet level. Therefore, a PolicyCondition can make no explicit reference to a model construct that represents a network packet's source address. In this case, an implicit PolicyVariable is defined, to allow evaluation or modification of a packet's source address.
PCIMeはPolicyVariables、PolicyImplicitVariables、およびPolicyExplicitVariablesの2つのタイプを定義します。 これらのクラスの意味違いはモデル文脈に基づいています。 明白な変数は必ずモデル構造物を強要するでしょうが、暗黙の変数は、モデルの外で定義されて、評価されます。 例えば、人は、値の「誤り」がCIM ManagedSystemElementのStatusの特性にあるか否かに関係なく、PolicyConditionがテストすると想像できます。 Statusの特性は明らかに定義されたPolicyVariable(すなわち、それは、CIM Schemaの文脈で定義されて、特定のインスタンスの文脈で評価される)です。 他方では、ネットワークパケットは、明らかにモデル化もされませんし、例示もされません、(このとき)のパケット・レベルで管理することにおける値が知覚されないので。 したがって、PolicyConditionはネットワークパケットのソースアドレスを表すモデル構造物のどんな明白な参照もできません。 この場合、内在しているPolicyVariableは、パケットのソースアドレスの評価か変更を許すために定義されます。
Moore Standards Track [Page 35] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[35ページ]。
5.8.6. Explicitly Bound Policy Variables
5.8.6. 明らかに制限された政策変数
Explicitly bound policy variables indicate the class and property names of the model construct to be evaluated or set. The CIM Schema defines and constrains "appropriate" values for the variable (i.e., model property) using data types and other information such as class/property qualifiers.
明らかに制限された政策変数は、評価されるか、または設定されるためにモデル構造物のクラスと特性の名を示します。 CIM Schemaは、変数(すなわち、モデルの特性)のためにクラス/特性の資格を与える人などのデータ型と他の情報を使用することで「適切な」値を定義して、抑制します。
A PolicyExplicitVariable is "explicit" because its model semantics are exactly defined. It is NOT explicit due to an exact binding to a particular object instance. If PolicyExplicitVariables were tied to instances (either via associations or by an object identification property in the class itself), then we would be forcing element- specific rules. On the other hand, if we only specify the object's model context (class and property name), but leave the binding to the policy framework (for example, using policy roles), then greater flexibility results for either general or element-specific rules.
モデル意味論がまさに定義されるので、PolicyExplicitVariableは「明白です」。 それは正確な結合のために特定のオブジェクトインスタンスに明白ではありません。 PolicyExplicitVariablesがインスタンス(協会を通したクラス自体におけるオブジェクト識別の特性による)に結ばれるなら、私たちは要素の特定の定規を押し込んでいるでしょうに。 他方では、私たちがオブジェクトのものを指定するだけであるなら、方針フレームワーク(例えば、方針の役割を使用する)との結合、どちらかのための当時の、より大きい柔軟性結果を一般的であるか要素特有の規則に残すのを除いて、文脈(クラスと特性の名)をモデル化してください。
For example, an element-specific rule is obtained by a condition ((<variable>, <value>) pair) that defines CIM LogicalDevice DeviceID="12345". Alternately, if a PolicyRule's PolicyRoles is "edge device" and the condition ((<variable>, <value>) pair) is Status="Error", then a general rule results for all edge devices in error.
例えば、CIM LogicalDevice DeviceID=「12345」を定義する条件((<の可変>、<値の>)は対にされる)で要素特有の規則を得ます。 交互に、PolicyRuleのPolicyRolesが「エッジデバイス」であり、そしてStatus=が「誤り」であるという条件((<の可変>、<値の>)は対にされる)が司令官であるならすべてのエッジデバイスのための結果が間違っていると裁決してください。
Currently, the only binding for a PolicyExplicitVariable defined in PCIMe is to the instances selected by policy roles. For each such instance, a SimplePolicyCondition that aggregates the PolicyExplicitVariable evaluates to True if and only if ALL of the following are true:
現在、方針の役割によって選択されたインスタンスにはPCIMeで定義されたPolicyExplicitVariableのための唯一の結合があります。 そして、そのような各インスタンス、PolicyExplicitVariableに集めるSimplePolicyCondition、Trueに関する評価、以下のすべてが本当である場合にだけ:
o The instance selected is of the class identified by the variable's
ModelClass property, or of a subclass of this class.
o The instance selected has the property identified by the
variable's ModelProperty property.
o The value of this property in the instance matches the value
specified in the PolicyValue aggregated by the condition.
o 選択されたインスタンスは変数のModelClassの特性によって特定されたクラス、またはこのクラスのサブクラスのものです。インスタンスが選択した○は変数のModelPropertyの特性によって特定された特性を持っています。○ インスタンスにおける、この属性の価値は状態によって集められたPolicyValueで指定された値に合っています。
In all other cases, the SimplePolicyCondition evaluates to False.
他のケース、すべてのSimplePolicyCondition、Falseに評価します。
For the case where a SimplePolicyAction aggregates a PolicyExplicitVariable, the indicated property in the selected instance is set to the value represented by the PolicyValue that the SimplePolicyAction also aggregates. However, if the selected instance is not of the class identified by the variable's ModelClass property, or of a subclass of this class, then the action is not performed. In this case the SimplePolicyAction is not treated either as a successfully executed action (for the execution strategy Do
SimplePolicyActionがPolicyExplicitVariableに集めるケースにおいて、選択されたインスタンスにおける示された特性はまたSimplePolicyActionが集めるPolicyValueによって表された値に設定されます。 しかしながら、選択されたインスタンスが変数のModelClassの特性によって特定されたクラス、またはこのクラスのサブクラスのものでないなら、動作は実行されません。 この場合SimplePolicyActionが首尾よく実行された動作としてどちらも扱われない、(実行戦略Do
Moore Standards Track [Page 36] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[36ページ]。
Until Success) or as a failed action (for the execution strategy Do Until Failure). Instead, the remaining actions for the policy rule, if any, are executed as if this SimplePolicyAction were not present at all in the list of actions aggregated by the rule.
Success、)、失敗した動作(実行戦略Do Until Failureのための)として。 代わりに、まるでこのSimplePolicyActionが規則で集められた動作のリストに全く存在していないかのようにもしあれば政策ルールのための残っている動作は実行されます。
Explicit variables would be more powerful if they could reach beyond the instances selected by policy roles, to related instances. However, to represent a policy rule involving such variables in any kind of general way requires something that starts to resemble very much a complete policy language. Clearly such a language is outside the scope of PCIMe, although it might be the subject of a future document.
方針の役割によって関連するインスタンスに選択されたインスタンスを超えて達することができるなら、明白な変数は、より強力でしょうに。 しかしながら、どんな種類の一般的な道にもそのような変数を伴う政策ルールを表すのは完全な方針言語にたいへん類似し始める何かを必要とします。 明確に、それは将来のドキュメントの対象であるかもしれませんが、PCIMeの範囲の外にそのような言語はあります。
By restricting much of the generality, it would be possible for explicit variables in PCIMe to reach slightly beyond a selected instance. For example, if a selected instance were related to exactly one instance of another class via a particular association class, and if the goal of the policy rule were both to test a property of this related instance and to set a property of that same instance, then it would be possible to represent the condition and action of the rule using PolicyExplicitVariables. Rather than handling this one specific case with explicit variables, though, it was decided to lump them with the more general case, and deal with them if and when a policy language is defined.
一般性の多くを制限することによって、PCIMeの明白な変数に、わずかに選択されたインスタンスを超えて達するのは可能でしょう。 例えば、政策ルールの目標が選択されたインスタンスが特定の協会のクラスを通してまさにもう1人のクラスの1つのインスタンスに関連して、ともにこの関連するインスタンスの特性をテストして、その同じインスタンスの特性を設定することであるなら、PolicyExplicitVariablesを使用する規則の状態と動作を表すのは可能です。 もっとも、明白な変数でこの1つの特定のケースを扱うよりむしろ、方針言語が定義されるなら、より一般的なケースでそれらをひとまとめにして、それらに対処するのは定まっていました。
Refer to Section 6.10 for the formal definition of the class PolicyExplicitVariable.
クラスPolicyExplicitVariableの公式の定義についてセクション6.10を参照してください。
5.8.7. Implicitly Bound Policy Variables
5.8.7. それとなく制限された政策変数
Implicitly bound policy variables define the data type and semantics of a variable. This determines how the variable is bound to a value in a condition or an action. Further instructions are provided for specifying data type and/or value constraints for implicitly bound variables.
それとなく制限された政策変数は変数のデータ型と意味論を定義します。 これは、変数がどのように状態か動作における値に制限されているかを決定します。 その後の支持は、それとなく制限された変数にデータ型、そして/または、値の規制を指定しながら、備えられます。
PCIMe introduces an abstract class, PolicyImplicitVariable, to model implicitly bound variables. This class is derived from the abstract class PolicyVariable also defined in PCIMe. Each of the implicitly bound variables introduced by PCIMe (and those that are introduced by domain- specific sub-models) MUST be derived from the PolicyImplicitVariable class. The rationale for using this mechanism for modeling is explained below in Section 5.8.9.
PCIMeは、それとなく制限された変数をモデル化するために抽象クラス、PolicyImplicitVariableを導入します。 また、PCIMeで定義された抽象クラスPolicyVariableからこのクラスを得ます。 PolicyImplicitVariableのクラスからPCIMe(そして、ドメインの特定のサブモデルによって導入されるもの)によって紹介されたそれぞれのそれとなく制限された変数を得なければなりません。 モデルにこのメカニズムを使用するための原理は以下でセクション5.8.9で説明されます。
A domain-specific policy information model that extends PCIMe may define additional implicitly bound variables either by deriving them directly from the class PolicyImplicitVariable, or by further
PCIMeを広げるドメイン特定保険証券情報モデルはさらに追加それとなく制限された変数を定義するかもしれません。
Moore Standards Track [Page 37] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[37ページ]。
refining an existing variable class such as SourcePort. When refining a class such as SourcePort, existing binding rules, type or value constraints may be narrowed.
SourcePortなどの既存の可変クラスを洗練します。 規則を縛りながら存在していて、SourcePortなどのクラスを洗練するときにはタイプしてください。さもないと、値の規制は狭くされるかもしれません。
5.8.8. Structure and Usage of Pre-Defined Variables
5.8.8. 事前に定義された変数の構造と用法
A class derived from PolicyImplicitVariable to model a particular implicitly bound variable SHOULD be constructed so that its name depicts the meaning of the variable. For example, a class defined to model the source port of a TCP/UDP flow SHOULD have 'SourcePort' in its name.
それとなく事項をモデル化するためにPolicyImplicitVariableから得られたクラスは名前が表現する組み立てられたそうが変数の意味であったなら可変SHOULDを縛りました。 例えば、TCP/UDP流れSHOULDのソースポートをモデル化するために定義されたクラスは名前で'SourcePort'を持っています。
PCIMe defines one association and one general-purpose mechanism that together characterize each of the implicitly bound variables that it introduces:
PCIMeは1つの協会を定義します、そして、そんなに一緒にいる1つの汎用メカニズムがそれが紹介するそれぞれのそれとなく制限された変数を特徴付けます:
1. The ExpectedPolicyValuesForVariable association defines the set of
value classes that could be matched to this variable.
1. ExpectedPolicyValuesForVariable協会はこの変数に合わせることができた値のクラスのセットを定義します。
2. The list of constraints on the values that the PolicyVariable can
hold (i.e., values that the variable must match) are defined by
the appropriate properties of an associated PolicyValue class.
2. PolicyVariableが成立できるという値における規制(すなわち、変数が合わなければならない値)のリストは関連PolicyValueのクラスの適切な特性によって定義されます。
In the example presented above, a PolicyImplicitVariable represents the SourcePort of incoming traffic. The ValueTypes property of an instance of this class will hold the class name PolicyIntegerValue. This by itself constrains the data type of the SourcePort instance to be an integer. However, we can further constrain the particular values that the SourcePort variable can hold by entering valid ranges in the IntegerList property of the PolicyIntegerValue instance (0 - 65535 in this document).
上に提示された例では、PolicyImplicitVariableは入って来るトラフィックのSourcePortを表します。 このクラスのインスタンスのValueTypesの特性はクラス名PolicyIntegerValueを持つでしょう。 それ自体でこれは、SourcePortインスタンスに関するデータ型が整数であることを抑制します。 しかしながら、私たちはさらにPolicyIntegerValueインスタンス(このドキュメントの0--65535)のIntegerList所有地の有効枠に入るSourcePort変数が固守できる特定の値を抑制できます。
The combination of the VariableName and the ExpectedPolicyValuesForVariable association provide a consistent and extensible set of metadata that define the semantics of variables that are used to form policy conditions. Since the ExpectedPolicyValuesForVariable association points to a PolicyValue instance, any of the values expressible in the PolicyValue class can be used to constrain values that the PolicyImplicitVariable can hold. For example:
VariableNameの組み合わせとExpectedPolicyValuesForVariable協会は保険約款を形成するのに使用される変数の意味論を定義する一貫して広げることができるセットのメタデータを提供します。 ExpectedPolicyValuesForVariable協会がPolicyValueインスタンスを示すので、PolicyImplicitVariableが保持できる値を抑制するのにPolicyValueのクラスで表現できる値のいずれも使用できます。 例えば:
o The ValueTypes property can be used to ensure that only proper
classes are used in the expression. For example, the SourcePort
variable will not be allowed to ever be of type
PolicyIPv4AddrValue, since source ports have different semantics
than IP addresses and may not be matched. However, integer value
types are allowed as the property ValueTypes holds the string
"PolicyIntegerValue", which is the class name for integer values.
o 適切なクラスだけが式に使用されるのを保証するのにValueTypesの特性を使用できます。 例えば、SourcePort変数は、ソースポートにはIPアドレスと異なった意味論があるので今までに、タイプPolicyIPv4AddrValueにはあるのが許容されないで、また合わせられないかもしれません。 しかしながら、特性のValueTypesがストリング"PolicyIntegerValue"(整数値のためのクラス名である)を保持するとき、整数値のタイプは許容されています。
Moore Standards Track [Page 38] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[38ページ]。
o The ExpectedPolicyValuesForVariable association also ensures that
variable-specific semantics are enforced (e.g., the SourcePort
variable may include a constraint association to a value object
defining a specific integer range that should be matched).
o また、ExpectedPolicyValuesForVariable協会は、可変に特定の意味論が励行されるのを確実にします(例えば、SourcePort変数は合わせられるべきである特定の整数範囲を定義する値のオブジェクトに規制協会を含むかもしれません)。
5.8.9. Rationale for Modeling Implicit Variables as Classes
5.8.9. クラスとして暗黙の変数をモデル化するための原理
An implicitly bound variable can be modeled in one of several ways, including a single class with an enumerator for each individual implicitly bound variable and an abstract class extended for each individual variable. The reasons for using a class inheritance mechanism for specifying individual implicitly bound variables are these:
いくつかの方法の1つでそれとなく制限された変数をモデル化できます、それぞれの個々のそれとなく制限された変数と各個体変数のために広げられた抽象クラスのための計数器がある1つのクラスを含んでいて。 個々のそれとなく制限された変数を指定するのにクラス継承メカニズムを使用する理由はこれらです:
1. It is easy to extend. A domain-specific information model can
easily extend the PolicyImplicitVariable class or its subclasses
to define domain-specific and context-specific variables. For
example, a domain-specific QoS policy information model may
introduce an implicitly bound variable class to model applications
by deriving a qosApplicationVariable class from the
PolicyImplicitVariable abstract class.
1. 広がるのは簡単です。 ドメイン特殊情報モデルは、ドメイン特有の、そして、文脈特有の変数を定義するために容易にPolicyImplicitVariableのクラスかそのサブクラスを広げることができます。 例えば、ドメイン特有のQoS方針情報モデルは、PolicyImplicitVariable抽象クラスからqosApplicationVariableのクラスを得ることによって、それとなく制限された可変クラスをモデルアプリケーションに紹介するかもしれません。
2. Introduction of a single structural class for implicitly bound
variables would have to include an enumerator property that
contains all possible individual implicitly bound variables. This
means that a domain-specific information model wishing to
introduce an implicitly bound variable must extend the enumerator
itself. This results in multiple definitions of the same class,
differing in the values available in the enumerator class. One
definition, in this document, would include the common implicitly
bound variables' names, while a second definition, in the domain-
specific information model document, may include additional values
('qosApplicationVariable' in the example above). It wouldn't even
be obvious to the application developer that multiple class
definitions existed. It would be harder still for the application
developer to actually find the correct class to use.
2. それとなく制限された変数のための1つの構造的なクラスの導入はすべての可能な個々のそれとなく制限された変数を含む計数器の特性を含まなければならないでしょう。 これは、それとなく制限された変数を紹介したがっているドメイン特殊情報モデルが計数器自身を広げなければならないことを意味します。 これは同じクラスの複数の定義をもたらして、計数器のクラスで利用可能な値において異なります。 1つの定義が本書では一般的なそれとなく制限された変数の名前を含んでいるでしょう、ドメイン特殊情報モデルドキュメントでは、2番目の定義は加算値(上記の例の'qosApplicationVariable')を含むかもしれませんが。 アプリケーション開発者にとって、複数のクラス定義が存在したのは、明白になりさえしないでしょう。 まだ、アプリケーション開発者は実際に使用する正しいクラスをより見つけにくいでしょう。
3. In addition, an enumerator-based definition would require each
additional value to be registered with IANA to ascertain adherence
to standards. This would make the process cumbersome.
3. さらに、計数器ベースの定義は、各加算値が固守を規格に確かめるためにIANAに示されるのを必要とするでしょう。 これで、プロセスは厄介になるでしょう。
4. A possible argument against the inheritance mechanism would cite
the fact that this approach results in an explosion of class
definitions compared to an enumerator class, which only introduces
a single class. While, by itself, this is not a strike against
the approach, it may be argued that data models derived from this
information model may be more difficult to optimize for
applications. This argument is rejected on the grounds that
4. 継承メカニズムに対する可能な議論は計数器のクラスと比べて、このアプローチがクラス定義の爆発をもたらすという事実を引用するでしょう。クラスは1つのクラスしか導入しません。 これがそれ自体でアプローチに対する打撃でない間、この情報モデルから得られたデータモデルはアプリケーションのために最適化するのが、より難しいかもしれないと主張されるかもしれません。 この議論は拒絶されます。
Moore Standards Track [Page 39] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[39ページ]。
application optimization is of lesser value for an information
model than clarity and ease of extension. In addition, it is hard
to claim that the inheritance model places an absolute burden on
the optimization. For example, a data model may still use
enumeration to denote instances of pre-defined variables and claim
PCIMe compliance, as long as the data model can be mapped
correctly to the definitions specified in this document.
アプリケーション最適化には、情報モデルには、明快と拡大の容易さより少ない価値があります。 さらに、継承モデルが絶対負担を最適化にかけると主張しにくいです。 例えば、データモデルは事前に定義された変数とクレームPCIMeコンプライアンスのインスタンスを指示するのにまだ列挙を使用しているかもしれません、正しく本書では指定された定義にデータモデルを写像できる限り。
5.8.10. Policy Values
5.8.10. 保険価額
The abstract class PolicyValue is used for modeling values and constants used in policy conditions. Different value types are derived from this class, to represent the various attributes required. Extensions of the abstract class PolicyValue, defined in this document, provide a list of values for basic network attributes. Values can be used to represent constants as named values. Named values can be kept in a reusable policy container to be reused by multiple conditions. Examples of constants include well-known ports, well-known protocols, server addresses, and other similar concepts.
抽象クラスPolicyValueは保険約款で使用されるモデル値と定数に使用されます。 必要である様々な属性を表すためにこのクラスから異価タイプを得ます。 本書では定義された抽象クラスPolicyValueの拡大は値のリストを基本的なネットワーク属性に提供します。 値と命名されるように定数を表すのに値を使用できます。 複数の状態によって再利用されるために再利用できる方針コンテナに命名された値を保つことができます。 定数に関する例はウェルノウンポート、よく知られるプロトコル、サーバアドレス、および他の同様の概念を含んでいます。
The PolicyValue subclasses define three basic types of values: scalars, ranges and sets. For example, a well-known port number could be defined using the PolicyIntegerValue class, defining a single value (80 for HTTP), a range (80-88), or a set (80, 82, 8080) of ports, respectively. For details, please see the class definition for each value type in Section 6.14 of this document.
PolicyValueサブクラスは3人の基本型の値を定義します: スカラ、範囲、およびセット。 例えば、PolicyIntegerValueのクラスを使用することでウェルノウン・ポート番号を定義できるでしょう、それぞれ、ポートのただ一つの値(HTTPのための80)、範囲(80-88)、またはセット(80、82、8080)を定義して。 詳細に関しては、各値のためのクラス定義がこのドキュメントのセクション6.14をタイプするのを見てください。
PCIMe defines the following subclasses of the abstract class PolicyValue:
PCIMeは抽象クラスPolicyValueの以下のサブクラスを定義します:
Classes for general use:
一般的使用のためのクラス:
- PolicyStringValue,
- PolicyIntegerValue,
- PolicyBitStringValue
- PolicyBooleanValue.
- PolicyStringValue--PolicyIntegerValue--PolicyBitStringValue--PolicyBooleanValue。
Classes for layer 3 Network values:
層3のNetwork値のためのクラス:
- PolicyIPv4AddrValue,
- PolicyIPv6AddrValue.
- PolicyIPv4AddrValue--PolicyIPv6AddrValue。
Classes for layer 2 Network values:
層2のNetwork値のためのクラス:
- PolicyMACAddrValue.
- PolicyMACAddrValue。
For details, please see the class definition section of each class in Section 6.14 of this document.
詳細に関しては、このドキュメントのセクション6.14でそれぞれのクラスのクラス定義部を見てください。
Moore Standards Track [Page 40] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[40ページ]。
5.9. Packet Filtering
5.9. パケットフィルタリング
PCIMe contains two mechanisms for representing packet filters. The more general of these, termed here the domain-level model, expresses packet filters in terms of policy variables and policy values. The other mechanism, termed here the device-level model, expresses packet filters in a way that maps more directly to the packet fields to which the filters are being applied. While it is possible to map between these two representations of packet filters, no mapping is provided in PCIMe itself.
PCIMeはパケットフィルタを表すための2つのメカニズムを含んでいます。 ドメインレベルモデル、パケットが政策変数に関してフィルターにかける急行、および方針が評価するここに呼ばれたこれらの一般は、より多いです。 もう片方のメカニズム、ここに呼ばれて、デバイスレベルはモデル化されます、パケットがパケットにより直接、フィルタが適用されている分野を写像する方法でフィルターにかける急行。 これらの2の間でパケットフィルタの表現を写像するのが可能である間、写像をPCIMe自身に提供しません。
5.9.1. Domain-Level Packet Filters
5.9.1. ドメインレベルパケットフィルタ
In addition to filling in the holes in the overall Policy infrastructure, PCIMe proposes a single mechanism for expressing domain-level packet filters in policy conditions. This is being done in response to concerns that even though the initial "wave" of submodels derived from PCIM were all filtering on IP packets, each was doing it in a slightly different way. PCIMe proposes a common way to express IP packet filters. The following figure illustrates how packet-filtering conditions are expressed in PCIMe.
総合的なPolicyインフラストラクチャの穴をふさぐことに加えて、PCIMeは、保険約款でドメインレベルパケットフィルタを急送するためにただ一つのメカニズムを提案します。 PCIMから得られた「副-モデル」の初期の「波」がIPでパケットをすべてフィルターにかけていましたが、それぞれがわずかに異なった方法でそれをしていたという関心に対応してこれをしています。 PCIMeは一般的な方法で急行IPパケットフィルタにプロポーズします。 以下の図はパケットフィルタリング状態がPCIMeでどう言い表されるかを例証します。
+---------------------------------+
| CompoundFilterCondition |
| - IsMirrored boolean |
| - ConditionListType (DNF|CNF) |
+---------------------------------+
+ + +
+ + +
+ + +
SimplePC SimplePC SimplePC
* @ * @ * @
* @ * @ * @
* @ * @ * @
FlowDirection "In" SrcIP <addr1> DstIP <addr2>
+---------------------------------+ | CompoundFilterCondition| | - IsMirrored論理演算子| | - ConditionListType(DNF| CNF)| +---------------------------------+ + + + + + + + + + SimplePC SimplePC SimplePC * @ * @ * @ * @ * @ * @ * @ * @ * @ FlowDirection "In" SrcIP <addr1> DstIP <addr2>
Aggregation Legend:
++++ PolicyConditionInPolicyCondition
**** PolicyVariableInSimplePolicyCondition
@@@@ PolicyValueInSimplePolicyCondition
集合伝説: + + + + PolicyConditionInPolicyCondition****PolicyVariableInSimplePolicyCondition@@@@PolicyValueInSimplePolicyCondition
Figure 9. Packet Filtering in Policy Conditions
図9。 保険約款のパケットフィルタリング
In Figure 9., each SimplePolicyCondition represents a single field to be filtered on: Source IP address, Destination IP address, Source port, etc. An additional SimplePolicyCondition indicates the direction that a packet is traveling on an interface: inbound or outbound. Because of the FlowDirection condition, care must be taken
図9.では、各SimplePolicyConditionは、以下でフィルターにかけられるためにただ一つの分野を表します。 ソースIPアドレス、Destination IPアドレス、Sourceポートなど 追加SimplePolicyConditionはパケットがインタフェースを旅行している方向を示します: 本国行きである、または外国行きです。 FlowDirection状態のために、注意しなければなりません。
Moore Standards Track [Page 41] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[41ページ]。
in aggregating a set of SimplePolicyConditions into a CompoundFilterCondition. Otherwise, the resulting CompoundPolicyCondition may match all inbound packets, or all outbound packets, when this is probably not what was intended.
CompoundFilterConditionへのSimplePolicyConditionsの1セットに集める際に。 さもなければ、結果として起こるCompoundPolicyConditionはすべての本国行きのパケット、またはすべての外国行きのパケットに合うかもしれません、これがたぶん意図したことでないときに。
Individual SimplePolicyConditions may be negated when they are aggregated by a CompoundFilterCondition.
彼らがCompoundFilterConditionによって集められるとき、個々のSimplePolicyConditionsは否定されるかもしれません。
CompoundFilterCondition is a subclass of CompoundPolicyCondition. It introduces one additional property, the Boolean property IsMirrored. The purpose of this property is to allow a single CompoundFilterCondition to match packets traveling in both directions on a higher-level connection such as a TCP session. When this property is TRUE, additional packets match a filter, beyond those that would ordinarily match it. An example will illustrate how this property works.
CompoundFilterConditionはCompoundPolicyConditionのサブクラスです。 それは1つの追加特性、ブール特性のIsMirroredを導入します。 この特性の目的は独身のCompoundFilterConditionがTCPセッションなどの、よりハイレベルの接続のときに両方の方向に移動するパケットに合っているのを許容することです。 この特性がTRUEであるときに、追加パケットは通常、それに合っているものを超えてフィルタに合っています。 例はこの特性がどう働いているかを例証するでしょう。
Suppose we have a CompoundFilterCondition that aggregates the following three filters, which are ANDed together:
私たちがANDedである以下の3個のフィルタに一緒に集めるCompoundFilterConditionを持っていると仮定してください:
o FlowDirection = "In"
o Source IP = 9.1.1.1
o Source Port = 80
o 9.1.1.1○Source Port=“In"FlowDirection=o Source IP=80
Regardless of whether IsMirrored is TRUE or FALSE, inbound packets will match this CompoundFilterCondition if their Source IP address = 9.1.1.1 and their Source port = 80. If IsMirrored is TRUE, however, an outbound packet will also match the CompoundFilterCondition if its Destination IP address = 9.1.1.1 and its Destination port = 80.
IsMirroredがTRUEかFALSEであることにかかわらず、本国行きのパケットはアドレス=9.1.1.1とそれらのSourceが移植するそれらのSource IP=80であるならこのCompoundFilterConditionに合うでしょう。 しかしながら、IsMirroredがTRUEであるなら、また、外国行きのパケットはアドレス=9.1.1.1とそのDestinationが移植するDestination IP=80であるならCompoundFilterConditionに合うでしょう。
IsMirrored "flips" the following Source/Destination packet header fields:
IsMirroredは以下のSource/目的地パケットヘッダーフィールドを「はじき出します」:
o FlowDirection "In" / FlowDirection "Out"
o Source IP address / Destination IP address
o Source port / Destination port
o Source MAC address / Destination MAC address
o Source [layer-2] SAP / Destination [layer-2] SAP.
o FlowDirection “In" / FlowDirection “Out"o Source IPのアドレス/目的地IPアドレスo Sourceポート/仕向港o Source MACのアドレス/目的地MACは、oがSource[層-2]のSAP/目的地[層-2]SAPであると扱います。
5.9.2. Device-Level Packet Filters
5.9.2. デバイスレベルパケットフィルタ
At the device level, packet header filters are represented by two subclasses of the abstract class FilterEntryBase: IpHeadersFilter and 8021Filter. Submodels of PCIMe may define other subclasses of FilterEntryBase in addition to these two; ICPM [12], for example, defines subclasses for IPsec-specific filters.
デバイスレベルでは、パケットのヘッダーフィルタは抽象クラスFilterEntryBaseの2つのサブクラスによって表されます: IpHeadersFilterと8021Filter。 PCIMeのSubmodelsはこれらの2に加えてFilterEntryBaseの他のサブクラスを定義するかもしれません。 例えば、ICPM[12]はIPsec特有のフィルタのためにサブクラスを定義します。
Moore Standards Track [Page 42] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[42ページ]。
Instances of the subclasses of FilterEntryBase are not used directly as filters. They are always aggregated into a FilterList, by the aggregation EntriesInFilterList. For PCIMe and its submodels, the EntrySequence property in this aggregation always takes its default value '0', indicating that the aggregated filter entries are ANDed together.
FilterEntryBaseのサブクラスのインスタンスは直接フィルタとして使用されません。 それらはいつも集合EntriesInFilterListによってFilterListに集められます。 PCIMeとその「副-モデル」のために、この集合のEntrySequenceの特性はいつもデフォルト値'0'を取ります、集められたフィルタエントリーが一緒にANDedであることを示して。
The FilterList class includes an enumeration property Direction, representing the direction of the traffic flow to which the FilterList is to be applied. The value Mirrored(4) for Direction represents exactly the same thing as the IsMirrored boolean does in CompoundFilterCondition. See Section 5.9.1 for details.
FilterListのクラスは列挙の特性のDirectionを含んでいます、FilterListが適用されていることになっている交通の流れの方向を表して。 Directionのための値のMirrored(4)はIsMirrored論理演算子がCompoundFilterConditionに表すようにまさに同じことを表します。 詳細に関してセクション5.9.1を見てください。
5.10. Conformance to PCIM and PCIMe
5.10. PCIMとPCIMeへの順応
Because PCIM and PCIMe provide the core classes for modeling policies, they are not in general sufficient by themselves for representing actual policy rules. Submodels, such as QPIM and ICPM, provide the means for expressing policy rules, by defining subclasses of the classes defined in PCIM and PCIMe, and/or by indicating how the PolicyVariables and PolicyValues defined in PCIMe can be used to express conditions and actions applicable to the submodel.
PCIMとPCIMeがコアのクラスをモデル方針に提供するので、一般に、それらは提供しません。実際の政策ルールを表すのに自分たちで十分です。 政策ルールを表すPCIMとPCIMeで定義されたクラスのサブクラスを定義するどうPCIMeで定義されたPolicyVariablesとPolicyValuesは使用できるかを示すことによって、QPIMやICPMなどのSubmodelsは「副-モデル」に適切な状態と動きを言い表すために手段を提供します。
A particular submodel will not, in general, need to use every element defined in PCIM and PCIMe. For the elements it does not use, a submodel SHOULD remain silent on whether its implementations must support the element, must not support the element, should support the element, etc. For the elements it does use, a submodel SHOULD indicate which elements its implementations must support, which elements they should support, and which elements they may support.
一般に、特定の「副-モデル」はPCIMとPCIMeで定義されたあらゆる要素を使用する必要はないでしょう。 それが使用しない要素、実装が要素を支えなければならなくて、要素を支えてはいけなくて、要素を支えるべきであるかどうかなどに関して静かなa submodel SHOULDの残りのために それがする要素のために、使用、submodel SHOULDは、それらが実装がどの要素を支えなければならないか、そして、どの要素を支えるべきであるか、そして、どの要素を支えるかもしれないかを示します。
PCIM and PCIMe themselves simply define elements that may be of use to submodels. These documents remain silent on whether implementations are required to support an element, should support it, etc.
PCIMとPCIMe、自分たち、単に「副-モデル」の役に立つかもしれない要素を定義してください。 これらのドキュメントは実装が要素を支えるのが必要であり、それをサポートするべきであるかどうかなどに関して静かなままで残っています。
This model (and derived submodels) defines conditions and actions that are used by policy rules. While the conditions and actions defined herein are straightforward and may be presumed to be widely supported, as submodels are developed it is likely that situations will arise in which specific conditions or actions are not supported by some part of the policy execution system. Similarly, situations may also occur where rules contain syntactic or semantic errors.
このモデル(そして、「副-モデル」を引き出す)は政策ルールで使用される状態と動作を定義します。 ここに定義された状態と動作は、簡単であり、あえて広くサポートされるかもしれませんが、「副-モデル」が開発されているとき、どの一定の条件か動作が方針実行システムの何らかの部分で後押しされていないかで状況は起こりそうでしょう。 また、同様に、状況は規則が構文の、または、意味の誤りを含むところに起こるかもしれません。
It should be understood that the behavior and effect of undefined or incorrectly defined conditions or actions is not prescribed by this information model. While it would be helpful if it were prescribed, the variations in implementation restrict the ability for this
未定義の、または、不当に定義された状態か動作の振舞いと効果がこの情報モデルによって定められないのが理解されるべきです。 それが処方されれば助かる間、実装の変化はこれのために能力を制限します。
Moore Standards Track [Page 43] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[43ページ]。
information model to control the effect. For example, if an implementation only detected that a PEP could not enforce a given action on that PEP, it would be very difficult to declare that such a failure should affect other PEPs, or the PDP process. On the other hand, if the PDP determines that it cannot properly evaluate a condition, that failure may well affect all applications of the containing rules.
効果を制御する情報モデル。 例えば、検出されるだけであって、PEPが与えられた動作にそのPEPに押しつけることができないで、そのそのようなものが失敗であると宣言するのが非常に難しいだろうというのが実装であるなら他のPEPsに影響するべきですか、またはPDPは処理します。 他方では、PDPが、適切に状態を評価できないことを決定するなら、その失敗はたぶん、含有のアプリケーションが統治するすべてに影響するでしょう。
6. Class Definitions
6. クラス定義
The following definitions supplement those in PCIM itself. PCIM definitions that are not DEPRECATED here are still current parts of the overall Policy Core Information Model.
以下の定義はPCIM自身でそれらを補います。 ここのDEPRECATEDでないPCIM定義は総合的なPolicy Core情報Modelのまだ現在の部分です。
6.1. The Abstract Class "PolicySet"
6.1. 抽象クラス"PolicySet"
PolicySet is an abstract class that may group policies into a structured set of policies.
PolicySetは方針を構造化されたセットの方針に分類するかもしれない抽象クラスです。
NAME PolicySet
DESCRIPTION An abstract class that represents a set of policies
that form a coherent set. The set of contained
policies has a common decision strategy and a
common set of policy roles. Subclasses include
PolicyGroup and PolicyRule.
DERIVED FROM Policy
ABSTRACT TRUE
PROPERTIES PolicyDecisionStrategy
PolicyRoles
一貫性を持っているセットを形成する1セットの方針を表すNAME PolicySet記述An抽象クラス。 含まれた方針のセットに、一般的な決定戦略と一般的なセットの方針の役割があります。 サブクラスはPolicyGroupとPolicyRuleを含んでいます。 方針の抽象的な本当の特性のPolicyDecisionStrategy PolicyRolesから、派生します。
The PolicyDecisionStrategy property specifies the evaluation method for policy groups and rules contained within the policy set.
PolicyDecisionStrategyの特性は方針セットの中に含まれた方針グループと規則に評価メソッドを指定します。
NAME PolicyDecisionStrategy
DESCRIPTION The evaluation method used for policies contained in
the PolicySet. FirstMatching enforces the actions
of the first rule that evaluates to TRUE;
All Matching enforces the actions of all rules
that evaluate to TRUE.
SYNTAX uint16
VALUES 1 [FirstMatching], 2 [AllMatching]
DEFAULT VALUE 1 [FirstMatching]
評価メソッドがPolicySetに含まれた方針に使用したNAME PolicyDecisionStrategy記述。 FirstMatchingはそれがTRUEに評価する最初の規則の動作を実施します。 すべてのMatchingがそれがTRUEに評価するすべての規則の動作を実施します。 SYNTAX uint16 VALUES1[FirstMatching]、2[AllMatching]DEFAULT VALUE1[FirstMatching]
The definition of PolicyRoles is unchanged from PCIM. It is, however, moved from the class Policy up to the superclass PolicySet.
PolicyRolesの定義はPCIMから変わりがありません。 しかしながら、それはsuperclass PolicySetまでのクラスPolicyから動かされます。
Moore Standards Track [Page 44] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[44ページ]。
6.2. Update PCIM's Class "PolicyGroup"
6.2. アップデートPCIMのクラス"PolicyGroup"
The PolicyGroup class is moved, so that it is now derived from PolicySet.
PolicyGroupのクラスが動かされるので、現在、PolicySetからそれを得ます。
NAME PolicyGroup
DESCRIPTION A container for a set of related PolicyRules and
PolicyGroups.
DERIVED FROM PolicySet
ABSTRACT FALSE
PROPERTIES (none)
関連するPolicyRulesとPolicyGroupsの1セットのためのNAME PolicyGroup記述Aコンテナ。 PolicySetの抽象的な偽の特性から、派生します。(なにも)
6.3. Update PCIM's Class "PolicyRule"
6.3. アップデートPCIMのクラス"PolicyRule"
The PolicyRule class is moved, so that it is now derived from PolicySet. The Priority property is also deprecated in PolicyRule, and PolicyRoles is now inherited from the parent class PolicySet. Finally, a new property ExecutionStrategy is introduced, paralleling the property of the same name in the class CompoundPolicyAction.
PolicyRuleのクラスが動かされるので、現在、PolicySetからそれを得ます。 また、Priorityの特性もPolicyRuleで推奨しないです、そして、PolicyRolesは現在、親のクラスPolicySetから引き継がれます。 最終的に、クラスCompoundPolicyActionの同じ名前の特性に沿って、新しい特性のExecutionStrategyを導入します。
NAME PolicyRule
DESCRIPTION The central class for representing the "If Condition
then Action" semantics associated with a policy
rule.
DERIVED FROM PolicySet
ABSTRACT FALSE
PROPERTIES Enabled
ConditionListType
RuleUsage
Priority DEPRECATED FOR PolicySetComponent.Priority
AND FOR PolicySetInSystem.Priority
Mandatory
SequencedActions
ExecutionStrategy
「Conditionの当時のActionであるなら」意味論を表すための中央のクラスが政策ルールに関連づけたNAME PolicyRule記述。 PolicySetから派生している抽象的な偽の特性はPolicySetComponent.PriorityとPolicySetInSystem.Priorityの義務的なSequencedActions ExecutionStrategyに、推奨しないConditionListType RuleUsage優先権を可能にしました。
The property ExecutionStrategy defines the execution strategy to be used upon the sequenced actions aggregated by this PolicyRule. (An equivalent ExecutionStrategy property is also defined for the CompoundPolicyAction class, to provide the same indication for the sequenced actions aggregated by a CompoundPolicyAction.) This document defines three execution strategies:
特性のExecutionStrategyは、このPolicyRuleによって集められた配列された動作のときに使用されるために実行戦略を定義します。 (また、同等なExecutionStrategyの特性はCompoundPolicyActionのクラスのために定義されて、配列された動作のための同じ指示を提供するのはCompoundPolicyActionによって集められました。) このドキュメントは3つの実行戦略を定義します:
Do Until Success - execute actions according to predefined order,
until successful execution of a single action.
Do All - execute ALL actions which are part of the modeled
set, according to their predefined order.
Continue doing this, even if one or more of the
actions fails.
Until Successをしてください--事前に定義された注文に従って、動作をただ一つの動作のうまくいっている実行まで実行してください。 Allをしてください--彼らの事前に定義された注文に従って、モデル化されたセットの一部であるすべての動作を実行してください。 動作の1つ以上が失敗してもこれをし続けてください。
Moore Standards Track [Page 45] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[45ページ]。
Do Until Failure - execute actions according to predefined order,
until the first failure in execution of a single
sub-action.
Until Failureをしてください--事前に定義された注文に従って、動作をただ一つのサブ動作の実行における最初の失敗まで実行してください。
The property definition is as follows:
特性の定義は以下の通りです:
NAME ExecutionStrategy
DESCRIPTION An enumeration indicating how to interpret the
action ordering for the actions aggregated by this
PolicyRule.
SYNTAX uint16 (ENUM, {1=Do Until Success, 2=Do All, 3=Do
Until Failure} )
DEFAULT VALUE Do All (2)
動作のために注文される動作を解釈する方法を示すNAME ExecutionStrategy記述An列挙がこのPolicyRuleによって集められました。 SYNTAX uint16(ENUM、=がUntil Success、=がAll、=がUntil Failureをする3をする2をする1)DEFAULT VALUE Do All(2)
6.4. The Class "SimplePolicyCondition"
6.4. クラス"SimplePolicyCondition"
A simple policy condition is composed of an ordered triplet:
簡単な方針状態は命令された三つ子で構成されます:
<Variable> MATCH <Value>
<の可変>マッチ<値の>。
No formal modeling of the MATCH operator is provided. The 'match' relationship is implied. Such simple conditions are evaluated by answering the question:
MATCHオペレータのどんな正式なモデルも提供しません。 'マッチ'関係は含意されます。 そのような単純条件は質問に答えることによって、評価されます:
Does <variable> match <value>?
<の可変>は<値の>に合っていますか?
The 'match' relationship is to be interpreted by analyzing the variable and value instances associated with the simple condition.
'マッチ'関係は単純条件に関連している変数と値のインスタンスを分析することによって解釈されることです。
Simple conditions are building blocks for more complex Boolean Conditions, modeled by the CompoundPolicyCondition class.
単純条件はCompoundPolicyConditionのクラスによってモデル化されたより複雑なブールConditionsのためのブロックです。
The SimplePolicyCondition class is derived from the PolicyCondition class defined in PCIM.
PCIMで定義されたPolicyConditionのクラスからSimplePolicyConditionのクラスを得ます。
A variable and a value must be associated with a simple condition to make it a meaningful condition, using, respectively, the aggregations PolicyVariableInSimplePolicyCondition and PolicyValueInSimplePolicyCondition.
変数と値はそれを重要な状態にするように単純条件に関連していなければなりません、それぞれ集合のPolicyVariableInSimplePolicyConditionとPolicyValueInSimplePolicyConditionを使用して。
The class definition is as follows:
クラス定義は以下の通りです:
NAME SimplePolicyCondition DERIVED FROM PolicyCondition ABSTRACT False PROPERTIES (none)
PolicyConditionの抽象的な偽の特性から得られた名前SimplePolicyCondition(なにも)
Moore Standards Track [Page 46] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[46ページ]。
6.5. The Class "CompoundPolicyCondition"
6.5. クラス"CompoundPolicyCondition"
This class represents a compound policy condition, formed by aggregation of simpler policy conditions.
このクラスは、より簡単な保険約款の集合によって形成された合成方針状態を表します。
NAME CompoundPolicyCondition
DESCRIPTION A subclass of PolicyCondition that introduces the
ConditionListType property, used for assigning DNF /
CNF semantics to subordinate policy conditions.
DERIVED FROM PolicyCondition
ABSTRACT FALSE
PROPERTIES ConditionListType
保険約款を下位に置かせるために意味論をDNF / CNFに割り当てるのに使用されるConditionListType資産を紹介するPolicyConditionのNAME CompoundPolicyCondition記述Aサブクラス。 PolicyConditionの抽象的な偽の特性のConditionListTypeから、派生します。
The ConditionListType property is used to specify whether the list of policy conditions associated with this compound policy condition 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:
ConditionListTypeの特性は、この合成方針状態に関連している保険約款のリストが離接的な正規形(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.6. The Class "CompoundFilterCondition"
6.6. クラス"CompoundFilterCondition"
This subclass of CompoundPolicyCondition introduces one additional property, the boolean IsMirrored. This property turns on or off the "flipping" of corresponding source and destination fields in a filter specification.
CompoundPolicyConditionのこのサブクラスは1つの追加特性、論理演算子IsMirroredを導入します。 この特性はフィルタ仕様で対応するソースとあて先フィールドの「宙返り」をつけたり消したりします。
NAME CompoundFilterCondition
DESCRIPTION A subclass of CompoundPolicyCondition that
introduces the IsMirrored property.
DERIVED FROM CompoundPolicyCondition
ABSTRACT FALSE
PROPERTIES IsMirrored
IsMirrored資産を紹介するCompoundPolicyConditionのNAME CompoundFilterCondition記述Aサブクラス。 CompoundPolicyConditionの抽象的な偽の特性のIsMirroredから、派生します。
The IsMirrored property indicates whether packets that "mirror" a compound filter condition should be treated as matching the filter. The property definition is as follows:
IsMirroredの特性は、複合フィルタ状態を「映す」パケットがフィルタを合わせるとして扱われるべきであるかどうかを示します。 特性の定義は以下の通りです:
Moore Standards Track [Page 47] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[47ページ]。
NAME IsMirrored
DESCRIPTION Indicates whether packets that mirror the specified
filter are to be treated as matching the filter.
SYNTAX boolean
DEFAULT VALUE FALSE
NAME IsMirrored記述Indicates、指定されたフィルタを映すパケットはフィルタを合わせるとして扱われるのであることになっているかどうか SYNTAX論理演算子DEFAULT VALUE FALSE
6.7. The Class "SimplePolicyAction"
6.7. クラス"SimplePolicyAction"
The SimplePolicyAction class models the elementary set operation. "SET <variable> TO <value>". The set operator MUST overwrite an old value of the variable.
SimplePolicyActionのクラスは基本の集合演算をモデル化します。 「<値の>に<の可変>を設定してください。」 セットオペレータは変数の古い値を上書きしなければなりません。
Two aggregations are used in order to create the pair <variable> <value>. The aggregation PolicyVariableInSimplePolicyAction relates a SimplePolicyAction to a single variable instance. Similarly, the aggregation PolicyValueInSimplePolicyAction relates a SimplePolicyAction to a single value instance. Both aggregations are defined in this document.
2つの集合が、組の<の可変><値の>を作成するのに使用されています。 集合PolicyVariableInSimplePolicyActionはただ一つの可変インスタンスにSimplePolicyActionに関連します。 同様に、集合PolicyValueInSimplePolicyActionはただ一つの値のインスタンスにSimplePolicyActionに関連します。 両方の集合は本書では定義されます。
NAME SimplePolicyAction
DESCRIPTION A subclass of PolicyAction that introduces the
notion of "SET variable TO value".
DERIVED FROM PolicyAction
ABSTRACT FALSE
PROPERTIES (none)
「SETの可変TO価値」の概念を紹介するPolicyActionのNAME SimplePolicyAction記述Aサブクラス。 PolicyActionの抽象的な偽の特性から、派生します。(なにも)
6.8. The Class "CompoundPolicyAction"
6.8. クラス"CompoundPolicyAction"
The CompoundPolicyAction class is used to represent an expression consisting of an ordered sequence of action terms. Each action term is represented as a subclass of the PolicyAction class, defined in [PCIM]. Compound actions are constructed by associating dependent action terms together using the PolicyActionInPolicyAction aggregation.
CompoundPolicyActionのクラスは、動作用語の規則正しい系列から成る式を表すのに使用されます。それぞれの動作用語は[PCIM]で定義されたPolicyActionのクラスのサブクラスとして表されます。 合成動作は、PolicyActionInPolicyAction集合を使用することで依存する動作用語を一緒に関連づけることによって、構成されます。
The class definition is as follows:
クラス定義は以下の通りです:
NAME CompoundPolicyAction
DESCRIPTION A class for representing sequenced action terms.
Each action term is defined to be a subclass of the
PolicyAction class.
DERIVED FROM PolicyAction
ABSTRACT FALSE
PROPERTIES SequencedActions
ExecutionStrategy
表すNAME CompoundPolicyAction記述Aのクラスは動作用語を配列しました。それぞれの動作用語は、PolicyActionのクラスのサブクラスになるように定義されます。 PolicyActionの抽象的な偽の特性のSequencedActions ExecutionStrategyから、派生します。
This is a concrete class, and is therefore directly instantiable.
これは、具象クラスであり、したがって、直接instantiableです。
Moore Standards Track [Page 48] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[48ページ]。
The Property SequencedActions is identical to the SequencedActions property defined in PCIM for the class PolicyRule.
Property SequencedActionsはクラスPolicyRuleのためにPCIMで定義されたSequencedActionsの特性と同じです。
The property ExecutionStrategy defines the execution strategy to be used upon the sequenced actions associated with this compound action. (An equivalent ExecutionStrategy property is also defined for the PolicyRule class, to provide the same indication for the sequenced actions associated with a PolicyRule.) This document defines three execution strategies:
特性のExecutionStrategyは、この合成動作に関連している配列された動作のときに使用されるために実行戦略を定義します。 (また、同等なExecutionStrategyの特性はPolicyRuleのクラスのために定義されて、提供するために、配列された動作のための同じ指示はPolicyRuleと交際しました。) このドキュメントは3つの実行戦略を定義します:
Do Until Success - execute actions according to predefined order,
until successful execution of a single sub-action.
Do All - execute ALL actions which are part of the modeled
set, according to their predefined order.
Continue doing this, even if one or more of the
sub-actions fails.
Do Until Failure - execute actions according to predefined order,
until the first failure in execution of a single
sub-action.
Until Successをしてください--事前に定義された注文に従って、動作をただ一つのサブ動作のうまくいっている実行まで実行してください。 Allをしてください--彼らの事前に定義された注文に従って、モデル化されたセットの一部であるすべての動作を実行してください。 サブ動作の1つ以上が失敗してもこれをし続けてください。 Until Failureをしてください--事前に定義された注文に従って、動作をただ一つのサブ動作の実行における最初の失敗まで実行してください。
Since a CompoundPolicyAction may itself be aggregated either by a PolicyRule or by another CompoundPolicyAction, its success or failure will be an input to the aggregating entity's execution strategy. Consequently, the following rules are specified, for determining whether a CompoundPolicyAction succeeds or fails:
CompoundPolicyActionがそうするかもしれないので、それ自体がPolicyRuleか別のCompoundPolicyActionによって集められて、成否は集合実体の実行戦略への入力になるでしょう。 その結果、CompoundPolicyActionが成功するか、または失敗するかを決定するのに以下の規則は指定されます:
If the CompoundPolicyAction's ExecutionStrategy is Do Until Success, then:
次に、CompoundPolicyActionのExecutionStrategyがDo Until Successであるなら:
o If one component action succeeds, then the CompoundPolicyAction
succeeds.
o If all component actions fail, then the CompoundPolicyAction
fails.
o 1つのコンポーネント動作が成功するなら、CompoundPolicyActionは成功します。すべてのコンポーネント動作が失敗するo If、次に、CompoundPolicyActionは失敗します。
If the CompoundPolicyAction's ExecutionStrategy is Do All, then:
次に、CompoundPolicyActionのExecutionStrategyがDo Allであるなら:
o If all component actions succeed, then the CompoundPolicyAction
succeeds.
o If at least one component action fails, then the
CompoundPolicyAction fails.
o すべてのコンポーネント動作が成功するなら、CompoundPolicyActionは成功します。oのIfの少なくとも1つのコンポーネントの動作は失敗して、次に、CompoundPolicyActionは失敗します。
If the CompoundPolicyAction's ExecutionStrategy is Do Until Failure, then:
次に、CompoundPolicyActionのExecutionStrategyがDo Until Failureであるなら:
o If all component actions succeed, then the CompoundPolicyAction
succeeds.
o If at least one component action fails, then the
CompoundPolicyAction fails.
o すべてのコンポーネント動作が成功するなら、CompoundPolicyActionは成功します。oのIfの少なくとも1つのコンポーネントの動作は失敗して、次に、CompoundPolicyActionは失敗します。
Moore Standards Track [Page 49] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[49ページ]。
The definition of the ExecutionStrategy property is as follows:
ExecutionStrategyの特性の定義は以下の通りです:
NAME ExecutionStrategy
DESCRIPTION An enumeration indicating how to interpret the
action ordering for the actions aggregated by this
CompoundPolicyAction.
SYNTAX uint16 (ENUM, {1=Do Until Success, 2=Do All, 3=Do
Until Failure} )
DEFAULT VALUE Do All (2)
動作のために注文される動作を解釈する方法を示すNAME ExecutionStrategy記述An列挙がこのCompoundPolicyActionによって集められました。 SYNTAX uint16(ENUM、=がUntil Success、=がAll、=がUntil Failureをする3をする2をする1)DEFAULT VALUE Do All(2)
6.9. The Abstract Class "PolicyVariable"
6.9. 抽象クラス"PolicyVariable"
Variables are used for building individual conditions. The variable specifies the property of a flow or an event that should be matched when evaluating the condition. However, not every combination of a variable and a value creates a meaningful condition. For example, a source IP address variable can not be matched against a value that specifies a port number. A given variable selects the set of matchable value types.
変数は、個々の状態を築き上げるのに使用されます。 変数は状態を評価するとき合わせられるべきである流れかイベントの特性を指定します。 しかしながら、変数と価値のあらゆる組み合わせが重要な状態を引き起こすというわけではありません。 例えば、ソースIPアドレス変数はポートナンバーを指定する値に取り組まされることができません。 与えられた変数は整合の値のタイプのセットを選択します。
A variable can have constraints that limit the set of values within a particular value type that can be matched against it in a condition. For example, a source-port variable limits the set of values to represent integers to the range of 0-65535. Integers outside this range cannot be matched to the source-port variable, even though they are of the correct data type. Constraints for a given variable are indicated through the ExpectedPolicyValuesForVariable association.
変数は特定の状態でそれに取り組まされることができる値のタイプの中で値のセットを制限する規制を持つことができます。 例えば、ソースポート変数は、0-65535の範囲に整数を表すために値のセットを制限します。 それらは正しいデータ型のものですが、この範囲の外の整数をソースポート変数に合わせることができません。 与えられた変数の規制はExpectedPolicyValuesForVariable協会を通して示されます。
The PolicyVariable is an abstract class. Implicit and explicit context variable classes are defined as sub classes of the PolicyVariable class. A set of implicit variables is defined in this document as well.
PolicyVariableは抽象クラスです。 暗黙の、そして、明白な文脈可変クラスはPolicyVariableのクラスの潜水艦のクラスと定義されます。 本書ではまた、1セットの暗黙の変数は定義されます。
The class definition is as follows:
クラス定義は以下の通りです:
NAME PolicyVariable DERIVED FROM Policy ABSTRACT TRUE PROPERTIES (none)
方針の抽象的な本当の特性から得られた名前PolicyVariable(なにも)
6.10. The Class "PolicyExplicitVariable"
6.10. クラス"PolicyExplicitVariable"
Explicitly defined policy variables are evaluated within the context of the CIM Schema and its modeling constructs. The PolicyExplicitVariable class indicates the exact model property to be evaluated or manipulated. See Section 5.8.6 for a complete discussion of what happens when the values of the ModelClass and
明らかに定義された政策変数は、CIM Schemaの文脈の中で評価されて、それは構造物をモデル化することです。 PolicyExplicitVariableのクラスは、評価されるか、または操られるために正確なモデルの特性を示します。 そしてModelClassの値であるときに、何が起こるかに関する完全な議論に関してセクション5.8.6を見てください。
Moore Standards Track [Page 50] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[50ページ]。
ModelProperty properties in an instance of this class do not correspond to the characteristics of the model construct being evaluated or updated.
このクラスのインスタンスにおけるModelPropertyの特性は評価されるか、またはアップデートされるモデル構造物の特性と食い違っています。
The class definition is as follows:
クラス定義は以下の通りです:
NAME PolicyExplicitVariable DERIVED FROM PolicyVariable ABSTRACT False PROPERTIES ModelClass, ModelProperty
PolicyVariableの抽象的な偽の特性のModelClass、ModelPropertyから得られた名前PolicyExplicitVariable
6.10.1. The Single-Valued Property "ModelClass"
6.10.1. 単一に評価された特性の「ModelClass」
This property is a string specifying the class name whose property is evaluated or set as a PolicyVariable.
この特性は特性がPolicyVariableとして評価されるか、または設定されるクラス名を指定するストリングです。
The property is defined as follows:
特性は以下の通り定義されます:
NAME ModelClass SYNTAX String
名前ModelClass構文ストリング
6.10.2. The Single-Valued Property ModelProperty
6.10.2. 単一に評価された特性のModelProperty
This property is a string specifying the property name, within the ModelClass, which is evaluated or set as a PolicyVariable. The property is defined as follows:
この特性はPolicyVariableとして評価されるか、または用意ができているModelClassの中で特性の名を指定するストリングです。 特性は以下の通り定義されます:
NAME ModelProperty SYNTAX String
名前ModelProperty構文ストリング
6.11. The Abstract Class "PolicyImplicitVariable"
6.11. 抽象クラス"PolicyImplicitVariable"
Implicitly defined policy variables are evaluated outside of the context of the CIM Schema and its modeling constructs. Subclasses specify the data type and semantics of the PolicyVariables.
それとなく定義された政策変数は、CIM Schemaの文脈の外で評価されて、それは構造物をモデル化することです。 サブクラスはPolicyVariablesのデータ型と意味論を指定します。
Interpretation and evaluation of a PolicyImplicitVariable can vary, depending on the particular context in which it is used. For example, a "SourceIP" address may denote the source address field of an IP packet header, or the sender address delivered by an RSVP PATH message.
それが使用されている特定の文脈によって、PolicyImplicitVariableの解釈と評価は異なることができます。 例えば、"SourceIP"というアドレスはIPパケットのヘッダーのソースアドレス・フィールド、またはRSVP PATHメッセージによって提供された送付者アドレスを指示するかもしれません。
The class definition is as follows:
クラス定義は以下の通りです:
NAME PolicyImplicitVariable DERIVED FROM PolicyVariable ABSTRACT True PROPERTIES ValueTypes[ ]
PolicyVariableの抽象的な本当の特性のValueTypesから得られた名前PolicyImplicitVariable[ ]
Moore Standards Track [Page 51] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[51ページ]。
6.11.1. The Multi-Valued Property "ValueTypes"
6.11.1. マルチ評価された特性の「ValueTypes」
This property is a set of strings specifying an unordered list of possible value/data types that can be used in simple conditions and actions, with this variable. The value types are specified by their class names (subclasses of PolicyValue such as PolicyStringValue). The list of class names enables an application to search on a specific name, as well as to ensure that the data type of the variable is of the correct type.
この特性は単純条件と動作に使用できる可能な値/データ型の順不同のリストを指定する1セットのストリングです、この変数で。 彼らのクラス名(PolicyStringValueなどのPolicyValueのサブクラス)によって値のタイプは指定されます。 クラス名のリストは、アプリケーションが、種名で探して、正しいタイプには変数に関するデータ型があるのを保証するのを可能にします。
The list of default ValueTypes for each subclass of PolicyImplicitVariable is specified within that variable's definition.
PolicyImplicitVariableの各サブクラスのためのデフォルトValueTypesのリストはその変数の定義の中で指定されます。
The property is defined as follows:
特性は以下の通り定義されます:
NAME ValueTypes SYNTAX String
名前ValueTypes構文ストリング
6.12. Subclasses of "PolicyImplicitVariable" Specified in PCIMe
6.12. PCIMeで指定された"PolicyImplicitVariable"のサブクラス
The following subclasses of PolicyImplicitVariable are defined in PCIMe.
PolicyImplicitVariableの以下のサブクラスはPCIMeで定義されます。
6.12.1. The Class "PolicySourceIPv4Variable"
6.12.1. クラス"PolicySourceIPv4Variable"
NAME PolicySourceIPv4Variable
DESCRIPTION The source IPv4 address. of the outermost IP packet
header. "Outermost" here refers to the IP packet as
it flows on the wire, before any headers have been
stripped from it.
NAME PolicySourceIPv4Variable記述、ソースIPv4アドレス一番はずれのIPパケットのヘッダーについて。 ワイヤの上に流れるとき、ここの「一番はずれ」はIPパケットを参照します、それからどんなヘッダーも裸にする前に。
ALLOWED VALUE TYPES:
- PolicyIPv4AddrValue
値のタイプは許容しました: - PolicyIPv4AddrValue
DERIVED FROM PolicyImplicitVariable ABSTRACT FALSE PROPERTIES (none)
PolicyImplicitVariableの抽象的な偽の特性から、派生します。(なにも)
6.12.2. The Class "PolicySourceIPv6Variable"
6.12.2. クラス"PolicySourceIPv6Variable"
NAME PolicySourceIPv6Variable
DESCRIPTION The source IPv6 address of the outermost IP packet
header. "Outermost" here refers to the IP packet as
it flows on the wire, before any headers have been
stripped from it.
ソースIPv6が扱う一番はずれのIPパケットのヘッダーのNAME PolicySourceIPv6Variable記述。 ワイヤの上に流れるとき、ここの「一番はずれ」はIPパケットを参照します、それからどんなヘッダーも裸にする前に。
Moore Standards Track [Page 52] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[52ページ]。
ALLOWED VALUE TYPES:
- PolicyIPv6AddrValue
値のタイプは許容しました: - PolicyIPv6AddrValue
DERIVED FROM PolicyImplicitVariable ABSTRACT FALSE PROPERTIES (none)
PolicyImplicitVariableの抽象的な偽の特性から、派生します。(なにも)
6.12.3. The Class "PolicyDestinationIPv4Variable"
6.12.3. クラス"PolicyDestinationIPv4Variable"
NAME PolicyDestinationIPv4Variable
DESCRIPTION The destination IPv4 address of the outermost IP
packet header. "Outermost" here refers to the IP
packet as it flows on the wire, before any headers
have been stripped from it.
目的地IPv4が扱う一番はずれのIPパケットのヘッダーのNAME PolicyDestinationIPv4Variable記述。 ワイヤの上に流れるとき、ここの「一番はずれ」はIPパケットを参照します、それからどんなヘッダーも裸にする前に。
ALLOWED VALUE TYPES:
- PolicyIPv4AddrValue
値のタイプは許容しました: - PolicyIPv4AddrValue
DERIVED FROM PolicyImplicitVariable ABSTRACT FALSE PROPERTIES (none)
PolicyImplicitVariableの抽象的な偽の特性から、派生します。(なにも)
6.12.4. The Class "PolicyDestinationIPv6Variable"
6.12.4. クラス"PolicyDestinationIPv6Variable"
NAME PolicyDestinationIPv6Variable
DESCRIPTION The destination IPv6 address of the outermost IP
packet header. "Outermost" here refers to the IP
packet as it flows on the wire, before any headers
have been stripped from it.
目的地IPv6が扱う一番はずれのIPパケットのヘッダーのNAME PolicyDestinationIPv6Variable記述。 ワイヤの上に流れるとき、ここの「一番はずれ」はIPパケットを参照します、それからどんなヘッダーも裸にする前に。
ALLOWED VALUE TYPES:
- PolicyIPv6AddrValue
値のタイプは許容しました: - PolicyIPv6AddrValue
DERIVED FROM PolicyImplicitVariable ABSTRACT FALSE PROPERTIES (none)
PolicyImplicitVariableの抽象的な偽の特性から、派生します。(なにも)
Moore Standards Track [Page 53] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[53ページ]。
6.12.5. The Class "PolicySourcePortVariable"
6.12.5. クラス"PolicySourcePortVariable"
NAME PolicySourcePortVariable
DESCRIPTION Ports are defined as the abstraction that transport
protocols use to distinguish among multiple
destinations within a given host computer. For TCP
and UDP flows, the PolicySourcePortVariable is
logically bound to the source port field of the
outermost UDP or TCP packet header. "Outermost"
here refers to the IP packet as it flows on the
wire, before any headers have been stripped from
it.
ALLOWED VALUE TYPES:
- PolicyIntegerValue (0..65535)
NAME PolicySourcePortVariable記述Portsはトランスポート・プロトコルが与えられたホストコンピュータの中の複数の目的地の中で区別するのに使用する抽象化と定義されます。 TCPとUDPでは、流れであり、PolicySourcePortVariableは一番はずれのUDPかTCPパケットのヘッダーのソースポート分野に論理的に向かっています。 ワイヤの上に流れるとき、ここの「一番はずれ」はIPパケットを参照します、それからどんなヘッダーも裸にする前に。 値のタイプは許容しました: - PolicyIntegerValue(0..65535)
DERIVED FROM PolicyImplicitVariable ABSTRACT FALSE PROPERTIES (none)
PolicyImplicitVariableの抽象的な偽の特性から、派生します。(なにも)
6.12.6. The Class "PolicyDestinationPortVariable"
6.12.6. クラス"PolicyDestinationPortVariable"
NAME PolicyDestinationPortVariable
DESCRIPTION Ports are defined as the abstraction that transport
protocols use to distinguish among multiple
destinations within a given host computer. For TCP
and UDP flows, the PolicyDestinationPortVariable is
logically bound to the destination port field of the
outermost UDP or TCP packet header. "Outermost"
here refers to the IP packet as it flows on the
wire, before any headers have been stripped from it.
NAME PolicyDestinationPortVariable記述Portsはトランスポート・プロトコルが与えられたホストコンピュータの中の複数の目的地の中で区別するのに使用する抽象化と定義されます。 TCPとUDPでは、流れであり、PolicyDestinationPortVariableは一番はずれのUDPかTCPパケットのヘッダーの目的地ポート分野に論理的に向かっています。 ワイヤの上に流れるとき、ここの「一番はずれ」はIPパケットを参照します、それからどんなヘッダーも裸にする前に。
ALLOWED VALUE TYPES:
- PolicyIntegerValue (0..65535)
値のタイプは許容しました: - PolicyIntegerValue(0..65535)
DERIVED FROM PolicyImplicitVariable ABSTRACT FALSE PROPERTIES (none)
PolicyImplicitVariableの抽象的な偽の特性から、派生します。(なにも)
6.12.7. The Class "PolicyIPProtocolVariable"
6.12.7. クラス"PolicyIPProtocolVariable"
NAME PolicyIPProtocolVariable DESCRIPTION The IP protocol number.
NAME PolicyIPProtocolVariable記述IPは数について議定書の中で述べます。
ALLOWED VALUE TYPES:
- PolicyIntegerValue (0..255)
値のタイプは許容しました: - PolicyIntegerValue(0..255)
Moore Standards Track [Page 54] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[54ページ]。
DERIVED FROM PolicyImplicitVariable ABSTRACT FALSE PROPERTIES (none)
PolicyImplicitVariableの抽象的な偽の特性から、派生します。(なにも)
6.12.8. The Class "PolicyIPVersionVariable"
6.12.8. クラス"PolicyIPVersionVariable"
NAME PolicyIPVersionVariable
DESCRIPTION The IP version number. The well-known values are 4
and 6.
IPバージョンが付番するNAME PolicyIPVersionVariable記述。 よく知られる値は、4と6です。
ALLOWED VALUE TYPES:
- PolicyIntegerValue (0..15)
値のタイプは許容しました: - PolicyIntegerValue(0..15)
DERIVED FROM PolicyImplicitVariable ABSTRACT FALSE PROPERTIES (none)
PolicyImplicitVariableの抽象的な偽の特性から、派生します。(なにも)
6.12.9. The Class "PolicyIPToSVariable"
6.12.9. クラス"PolicyIPToSVariable"
NAME PolicyIPToSVariable DESCRIPTION The IP TOS octet.
NAME PolicyIPToSVariable記述、IP TOS八重奏。
ALLOWED VALUE TYPES:
- PolicyIntegerValue (0..255)
- PolicyBitStringValue (8 bits)
値のタイプは許容しました: - PolicyIntegerValue(0 .255)--PolicyBitStringValue(8ビット)
DERIVED FROM PolicyImplicitVariable ABSTRACT FALSE PROPERTIES (none)
PolicyImplicitVariableの抽象的な偽の特性から、派生します。(なにも)
6.12.10. The Class "PolicyDSCPVariable"
6.12.10. クラス"PolicyDSCPVariable"
NAME PolicyDSCPVariable DESCRIPTION The 6 bit Differentiated Service Code Point.
NAME PolicyDSCPVariable記述、6はDifferentiated Service Code Pointに噛み付きました。
ALLOWED VALUE TYPES:
- PolicyIntegerValue (0..63)
- PolicyBitStringValue (6 bits)
値のタイプは許容しました: - PolicyIntegerValue(0 .63)--PolicyBitStringValue(6ビット)
DERIVED FROM PolicyImplicitVariable ABSTRACT FALSE PROPERTIES (none)
PolicyImplicitVariableの抽象的な偽の特性から、派生します。(なにも)
Moore Standards Track [Page 55] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[55ページ]。
6.12.11. The Class "PolicyFlowIdVariable"
6.12.11. クラス"PolicyFlowIdVariable"
NAME PolicyFlowIdVariable
DESCRIPTION The flow identifier of the outermost IPv6 packet
header. "Outermost" here refers to the IP packet as
it flows on the wire, before any headers have been
stripped from it.
NAME PolicyFlowIdVariable記述、一番はずれのIPv6パケットのヘッダーの流れ識別子。 ワイヤの上に流れるとき、ここの「一番はずれ」はIPパケットを参照します、それからどんなヘッダーも裸にする前に。
ALLOWED VALUE TYPES:
- PolicyIntegerValue (0..1048575
- PolicyBitStringValue (20 bits)
値のタイプは許容しました: - PolicyIntegerValue、(0 .1048575--、PolicyBitStringValue(20ビット)
DERIVED FROM PolicyImplicitVariable ABSTRACT FALSE PROPERTIES (none)
PolicyImplicitVariableの抽象的な偽の特性から、派生します。(なにも)
6.12.12. The Class "PolicySourceMACVariable"
6.12.12. クラス"PolicySourceMACVariable"
NAME PolicySourceMACVariable DESCRIPTION The source MAC address.
ソースMACが扱うNAME PolicySourceMACVariable記述。
ALLOWED VALUE TYPES:
- PolicyMACAddrValue
値のタイプは許容しました: - PolicyMACAddrValue
DERIVED FROM PolicyImplicitVariable ABSTRACT FALSE PROPERTIES (none)
PolicyImplicitVariableの抽象的な偽の特性から、派生します。(なにも)
6.12.13. The Class "PolicyDestinationMACVariable"
6.12.13. クラス"PolicyDestinationMACVariable"
NAME PolicyDestinationMACVariable DESCRIPTION The destination MAC address.
目的地MACが扱うNAME PolicyDestinationMACVariable記述。
ALLOWED VALUE TYPES:
- PolicyMACAddrValue
値のタイプは許容しました: - PolicyMACAddrValue
DERIVED FROM PolicyImplicitVariable ABSTRACT FALSE PROPERTIES (none)
PolicyImplicitVariableの抽象的な偽の特性から、派生します。(なにも)
6.12.14. The Class "PolicyVLANVariable"
6.12.14. クラス"PolicyVLANVariable"
NAME PolicyVLANVariable
DESCRIPTION The virtual Bridged Local Area Network Identifier, a
12-bit field as defined in the IEEE 802.1q standard.
NAME PolicyVLANVariable記述、仮想のBridgedローカル・エリア・ネットワークIdentifier、IEEE 802.1q規格で定義される12ビットの分野。
Moore Standards Track [Page 56] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[56ページ]。
ALLOWED VALUE TYPES:
- PolicyIntegerValue (0..4095)
- PolicyBitStringValue (12 bits)
値のタイプは許容しました: - PolicyIntegerValue(0 .4095)--PolicyBitStringValue(12ビット)
DERIVED FROM PolicyImplicitVariable ABSTRACT FALSE PROPERTIES (none)
PolicyImplicitVariableの抽象的な偽の特性から、派生します。(なにも)
6.12.15. The Class "PolicyCoSVariable"
6.12.15. クラス"PolicyCoSVariable"
NAME PolicyCoSVariable
DESCRIPTION Class of Service, a 3-bit field, used in the layer 2
header to select the forwarding treatment. Bound to
the IEEE 802.1q user-priority field.
ServiceのNAME PolicyCoSVariable記述Class(3ビットの分野)は、推進処理を選択するのに層の中で2ヘッダーを使用しました。 IEEE 802.1qユーザ優先権分野にバウンドしてください。
ALLOWED VALUE TYPES:
- PolicyIntegerValue (0..7)
- PolicyBitStringValue (3 bits)
値のタイプは許容しました: - PolicyIntegerValue(0 .7)--PolicyBitStringValue(3ビット)
DERIVED FROM PolicyImplicitVariable ABSTRACT FALSE PROPERTIES (none)
PolicyImplicitVariableの抽象的な偽の特性から、派生します。(なにも)
6.12.16. The Class "PolicyEthertypeVariable"
6.12.16. クラス"PolicyEthertypeVariable"
NAME PolicyEthertypeVariable DESCRIPTION The Ethertype protocol number of Ethernet frames.
イーサネットのEthertypeプロトコル番号が縁どるNAME PolicyEthertypeVariable記述。
ALLOWED VALUE TYPES:
- PolicyIntegerValue (0..65535)
- PolicyBitStringValue (16 bits)
値のタイプは許容しました: - PolicyIntegerValue(0 .65535)--PolicyBitStringValue(16ビット)
DERIVED FROM PolicyImplicitVariable ABSTRACT FALSE PROPERTIES (none)
PolicyImplicitVariableの抽象的な偽の特性から、派生します。(なにも)
6.12.17. The Class "PolicySourceSAPVariable"
6.12.17. クラス"PolicySourceSAPVariable"
NAME PolicySourceSAPVariable
DESCRIPTION The Source Service Access Point (SAP) number of the
IEEE 802.2 LLC header.
Source Service Access Point(SAP)が付番するIEEE802.2LLCヘッダーのNAME PolicySourceSAPVariable記述。
ALLOWED VALUE TYPES:
- PolicyIntegerValue (0..255)
- PolicyBitStringValue (8 bits)
値のタイプは許容しました: - PolicyIntegerValue(0 .255)--PolicyBitStringValue(8ビット)
Moore Standards Track [Page 57] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[57ページ]。
DERIVED FROM PolicyImplicitVariable ABSTRACT FALSE PROPERTIES (none)
PolicyImplicitVariableの抽象的な偽の特性から、派生します。(なにも)
6.12.18. The Class "PolicyDestinationSAPVariable"
6.12.18. クラス"PolicyDestinationSAPVariable"
NAME PolicyDestinationSAPVariable
DESCRIPTION The Destination Service Access Point (SAP) number of
the IEEE 802.2 LLC header.
Destination Service Access Point(SAP)が付番するIEEE802.2LLCヘッダーのNAME PolicyDestinationSAPVariable記述。
ALLOWED VALUE TYPES:
- PolicyIntegerValue (0..255)
- PolicyBitStringValue (8 bits)
値のタイプは許容しました: - PolicyIntegerValue(0 .255)--PolicyBitStringValue(8ビット)
DERIVED FROM PolicyImplicitVariable ABSTRACT FALSE PROPERTIES (none)
PolicyImplicitVariableの抽象的な偽の特性から、派生します。(なにも)
6.12.19. The Class "PolicySNAPOUIVariable"
6.12.19. クラス"PolicySNAPOUIVariable"
NAME PolicySNAPOUIVariable
DESCRIPTION The value of the first three octets of the Sub-
Network Access Protocol (SNAP) Protocol Identifier
field for 802.2 SNAP encapsulation, containing an
Organizationally Unique Identifier (OUI). The value
00-00-00 indicates the encapsulation of Ethernet
frames (RFC 1042). OUI value 00-00-F8 indicates the
special encapsulation of Ethernet frames by certain
types of bridges (IEEE 802.1H). Other values are
supported, but are not further defined here. These
OUI values are to be interpreted according to the
endian-notation conventions of IEEE 802. For either
of the two Ethernet encapsulations, the remainder of
the Protocol Identifier field is represented by the
PolicySNAPTypeVariable.
Organizationally Unique Identifier(OUI)を含んでいて、SubネットワークAccessプロトコル(SNAP)プロトコルIdentifierの最初の3つの八重奏の値が802.2SNAPカプセル化のためにさばくNAME PolicySNAPOUIVariable記述。 値00-00-00はイーサネットフレーム(RFC1042)のカプセル化を示します。 あるタイプのブリッジ(IEEE 802.1H)でOUI値の00-00-F8はイーサネットフレームの特別なカプセル化を示します。 他の値は、サポートされますが、ここでさらに定義されません。 これらのOUI値はIEEE802のエンディアン記法コンベンションによると、解釈されることです。 2つのイーサネットカプセル化のどちらかに関しては、プロトコルIdentifier分野の残りはPolicySNAPTypeVariableによって表されます。
ALLOWED VALUE TYPES:
- PolicyIntegerValue (0..16777215)
- PolicyBitStringValue (24 bits)
値のタイプは許容しました: - PolicyIntegerValue(0 .16777215)--PolicyBitStringValue(24ビット)
DERIVED FROM PolicyImplicitVariable ABSTRACT FALSE PROPERTIES (none)
PolicyImplicitVariableの抽象的な偽の特性から、派生します。(なにも)
Moore Standards Track [Page 58] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[58ページ]。
6.12.20. The Class "PolicySNAPTypeVariable"
6.12.20. クラス"PolicySNAPTypeVariable"
NAME PolicySNAPTypeVariable
DESCRIPTION The value of the 4th and 5th octets of the Sub-
Network Access Protocol (SNAP) Protocol Identifier
field for IEEE 802 SNAP encapsulation when the
PolicySNAPOUIVariable indicates one of the two
Encapsulated Ethernet frame formats. This value is
undefined for other values of PolicySNAPOUIVariable.
PolicySNAPOUIVariableであるときに4の番目ものの値とSubネットワークAccessプロトコル(SNAP)プロトコルIdentifierの5番目の八重奏がIEEE802SNAPカプセル化のためにさばくNAME PolicySNAPTypeVariable記述は2つのEncapsulatedイーサネットフレーム形式の1つを示します。 PolicySNAPOUIVariableの他の値に、この値は未定義です。
ALLOWED VALUE TYPES:
- PolicyIntegerValue (0..65535)
- PolicyBitStringValue (16 bits)
値のタイプは許容しました: - PolicyIntegerValue(0 .65535)--PolicyBitStringValue(16ビット)
DERIVED FROM PolicyImplicitVariable ABSTRACT FALSE PROPERTIES (none)
PolicyImplicitVariableの抽象的な偽の特性から、派生します。(なにも)
6.12.21. The Class "PolicyFlowDirectionVariable"
6.12.21. クラス"PolicyFlowDirectionVariable"
NAME PolicyFlowDirectionVariable
DESCRIPTION The direction of a flow relative to a network
element. Direction may be "IN" and/or "OUT".
NAME PolicyFlowDirectionVariable記述、ネットワーク要素に比例した流れの方向。 方向は、「IN」、そして/または、“OUT"であるかもしれません。
ALLOWED VALUE TYPES:
- PolicyStringValue ('IN", "OUT")
値のタイプは許容しました: - PolicyStringValue「('IN」、“OUT")'
DERIVED FROM PolicyImplicitVariable ABSTRACT FALSE PROPERTIES (none)
PolicyImplicitVariableの抽象的な偽の特性から、派生します。(なにも)
To match on both inbound and outbound flows, the associated PolicyStringValue object has two entries in its StringList property: "IN" and "OUT".
本国行きの、そして、外国行きの両方の流れで合うように、関連PolicyStringValueオブジェクトには、StringListの特性における2つのエントリーがあります: 「IN」と“OUT"。
6.13. The Abstract Class "PolicyValue"
6.13. 抽象クラス"PolicyValue"
This is an abstract class that serves as the base class for all subclasses that are used to define value objects in the PCIMe. It is used for defining values and constants used in policy conditions. The class definition is as follows:
これはPCIMeで値のオブジェクトを定義するのに使用されるすべてのサブクラスのための基底クラスとして機能する抽象クラスです。 それは、保険約款で使用される値と定数を定義するのに使用されます。 クラス定義は以下の通りです:
NAME PolicyValue DERIVED FROM Policy ABSTRACT True PROPERTIES (none)
方針の抽象的な本当の特性から得られた名前PolicyValue(なにも)
Moore Standards Track [Page 59] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[59ページ]。
6.14. Subclasses of "PolicyValue" Specified in PCIMe
6.14. PCIMeで指定された"PolicyValue"のサブクラス
The following subsections contain the PolicyValue subclasses defined in PCIMe. Additional subclasses may be defined in models derived from PCIMe.
以下の小区分はPCIMeで定義されたPolicyValueサブクラスを含んでいます。 追加サブクラスはPCIMeから得られたモデルで定義されるかもしれません。
6.14.1. The Class "PolicyIPv4AddrValue"
6.14.1. クラス"PolicyIPv4AddrValue"
This class is used to provide a list of IPv4Addresses, hostnames and address range values to be matched against in a policy condition. The class definition is as follows:
このクラスは、IPv4Addresses、ホスト名、および方針状態で合わせられるアドレス範囲値のリストを提供するのに使用されます。 クラス定義は以下の通りです:
NAME PolicyIPv4AddrValue DERIVED FROM PolicyValue ABSTRACT False PROPERTIES IPv4AddrList[ ]
PolicyValueの抽象的な偽の特性のIPv4AddrListから得られた名前PolicyIPv4AddrValue[ ]
The IPv4AddrList property provides an unordered list of strings, each specifying a single IPv4 address, a hostname, or a range of IPv4 addresses, according to the ABNF definition [6] of an IPv4 address, as specified below:
IPv4AddrListの特性はストリングの順不同のリストを提供します、それぞれただ一つのIPv4アドレス、ホスト名、またはさまざまなIPv4アドレスを指定して、IPv4アドレスのABNF定義[6]に従って、以下で指定されるとして:
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT IPv4prefix = IPv4address "/" 1*2DIGIT IPv4range = IPv4address"-"IPv4address IPv4maskedaddress = IPv4address","IPv4address Hostname (as defined in [4])
「IPv4addressは1*3DIGITと等しい」、」 「1*3DIGIT」、」 「1*3DIGIT」、」 」 「1*3DIGIT IPv4prefixはIPv4addressと等しく」/1*2DIGIT IPv4rangeがIPv4addressと等しいです。」 --「IPv4address IPv4maskedaddressはIPv4addressと等しい」、「IPv4addressホスト名」([4])では、定義されます。
In the above definition, each string entry is either:
上の定義では、それぞれのストリングエントリーはどちらかです:
1. A single IPv4address in dot notation, as defined above. Example:
121.1.1.2
1. 上で定義されるとしてのドット記法による独身のIPv4address。 例: 121.1.1.2
2. An IPv4prefix address range, as defined above, specified by an
address and a prefix length, separated by "/". Example:
2.3.128.0/15
2. 「」 /によって切り離されたアドレスと接頭語の長さに従って、上で定義されるIPv4prefixアドレスの範囲は指定しました。」 例: 2.3.128.0/15
3. An IPv4range address range defined above, specified by a starting
address in dot notation and an ending address in dot notation,
separated by "-". The range includes all addresses between the
range's starting and ending addresses, including these two
addresses. Example: 1.1.22.1-1.1.22.5
3. ドット記法による開始アドレスと終了アドレスによってドット記法で指定されて、上で定義されたIPv4rangeアドレスの範囲は「-」で分離しました。 範囲はこれらの2つのアドレスを含む範囲の始めと終了アドレスの間のすべてのアドレスを含んでいます。 例: 1.1.22.1-1.1.22.5
4. An IPv4maskedaddress address range, as defined above, specified by
an address and mask. The address and mask are represented in dot
notation, separated by a comma ",". The masked address appears
before the comma, and the mask appears after the comma. Example:
2.3.128.0,255.255.248.0.
4. 上で定義されるIPv4maskedaddressアドレスの範囲はアドレスとマスクで指定しました。 「アドレスとマスクはコンマによって切り離されたドット記法で表される」、」 仮面のアドレスはコンマの前に現れます、そして、マスクはコンマの後に現れます。 例: 2.3.128.0,255.255.248.0.
Moore Standards Track [Page 60] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[60ページ]。
5. A single Hostname. The Hostname format follows the guidelines and
restrictions specified in [4]. Example: www.bigcompany.com.
5. 独身のHostname。 Hostname形式は[4]で指定されたガイドラインと制限に従います。 例: www.bigcompany.com。
Conditions matching IPv4AddrValues evaluate to true according to the generic matching rules. Additionally, a hostname is matched against another valid IPv4address representation by resolving the hostname into an IPv4 address first, and then comparing the addresses afterwards. Matching hostnames against each other is done using a string comparison of the two names.
合っているIPv4AddrValuesが本当にジェネリックの合っている規則に従って評価する状態。 さらに、ホスト名は、最初にIPv4アドレスにホスト名に変えて、次に、その後アドレスをたとえることによって、別の有効なIPv4address表現に取り組まされます。 ホスト名は互いと取り組むのを2つの名前のストリング比較を使用させられます。
The property definition is as follows:
特性の定義は以下の通りです:
NAME IPv4AddrList
SYNTAX String
FORMAT IPv4address | IPv4prefix | IPv4range |
IPv4maskedaddress | hostname
名前IPv4AddrList構文記号列の書式IPv4address| IPv4prefix| IPv4range| IPv4maskedaddress| ホスト名
6.14.2. The Class "PolicyIPv6AddrValue
6.14.2. クラス"PolicyIPv6AddrValue"
This class is used to define a list of IPv6 addresses, hostnames, and address range values. The class definition is as follows:
このクラスは、IPv6アドレス、ホスト名、およびアドレス範囲値のリストを定義するのに使用されます。 クラス定義は以下の通りです:
NAME PolicyIPv6AddrValue DERIVED FROM PolicyValue ABSTRACT False PROPERTIES IPv6AddrList[ ]
PolicyValueの抽象的な偽の特性のIPv6AddrListから得られた名前PolicyIPv6AddrValue[ ]
The property IPv6AddrList provides an unordered list of strings, each specifying an IPv6 address, a hostname, or a range of IPv6 addresses. IPv6 address format definition uses the standard address format defined in [7]. The ABNF definition [6] as specified in [7] is:
特性のIPv6AddrListはストリングの順不同のリストを提供します、それぞれIPv6アドレス、ホスト名、またはさまざまなIPv6アドレスを指定して。 IPv6アドレス形式定義は[7]で定義された標準のアドレス形式を使用します。 [7]とのABNF定義[6]は指定されるのを以下の通りです。
IPv6address = hexpart [ ":" IPv4address ] IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT IPv6prefix = hexpart "/" 1*2DIGIT hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ] hexseq = hex4 *( ":" hex4) hex4 = 1*4HEXDIG IPv6range = IPv6address"-"IPv6address IPv6maskedaddress = IPv6address","IPv6address Hostname (as defines in [NAMES])
「IPv6address=hexpart[「:」 IPv4address]IPv4addressは1*3DIGITと等しい」、」 「1*3DIGIT」、」 「1*3DIGIT」、」 」 「1*3DIGIT IPv6prefixはhexpartと等しく」/1*2DIGIT hexpartがhexseqと等しいです。| "hexseq":、:、」 [hexseq]| "::" 「[hexseq]hexseq=hex4*(「:」 hex4)hex4は1*4HEXDIG IPv6range=IPv6addressと等しいです」--「IPv6address IPv6maskedaddressはIPv6addressと等しい」「IPv6addressホスト名」(中で[NAMES]を定義するので)
Each string entry is either:
それぞれのストリングエントリーはどちらかです:
1. A single IPv6address as defined above.
1. 上で定義される独身のIPv6address。
2. A single Hostname. Hostname format follows guidelines and
restrictions specified in [4].
2. 独身のHostname。 ホスト名形式は[4]で指定されたガイドラインと制限に従います。
Moore Standards Track [Page 61] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[61ページ]。
3. An IPv6range address range, specified by a starting address in dot
notation and an ending address in dot notation, separated by "-".
The range includes all addresses between the range's starting and
ending addresses, including these two addresses.
3. ドット記法による開始アドレスと終了アドレスによってドット記法で指定されたIPv6rangeアドレスの範囲は「-」で分離しました。 範囲はこれらの2つのアドレスを含む範囲の始めと終了アドレスの間のすべてのアドレスを含んでいます。
4. An IPv4maskedaddress address range defined above specified by an
address and mask. The address and mask are represented in dot
notation separated by a comma ",".
4. 上で定義されたIPv4maskedaddressアドレスの範囲はアドレスとマスクで指定しました。 「アドレスとマスクはコンマによって切り離されたドット記法で表される」、」
5. A single IPv6prefix as defined above.
5. 上で定義される独身のIPv6prefix。
Conditions matching IPv6AddrValues evaluate to true according to the generic matching rules. Additionally, a hostname is matched against another valid IPv6address representation by resolving the hostname into an IPv6 address first, and then comparing the addresses afterwards. Matching hostnames against each other is done using a string comparison of the two names.
合っているIPv6AddrValuesが本当にジェネリックの合っている規則に従って評価する状態。 さらに、ホスト名は、最初にIPv6アドレスにホスト名に変えて、次に、その後アドレスをたとえることによって、別の有効なIPv6address表現に取り組まされます。 ホスト名は互いと取り組むのを2つの名前のストリング比較を使用させられます。
6.14.3. The Class "PolicyMACAddrValue"
6.14.3. クラス"PolicyMACAddrValue"
This class is used to define a list of MAC addresses and MAC address range values. The class definition is as follows:
このクラスは、MACアドレスとMACアドレス範囲値のリストを定義するのに使用されます。 クラス定義は以下の通りです:
NAME PolicyMACAddrValue DERIVED FROM PolicyValue ABSTRACT False PROPERTIES MACAddrList[ ]
PolicyValueの抽象的な偽の特性のMACAddrListから得られた名前PolicyMACAddrValue[ ]
The property MACAddrList provides an unordered list of strings, each specifying a MAC address or a range of MAC addresses. The 802 MAC address canonical format is used. The ABNF definition [6] is:
それぞれMACアドレスかさまざまなMACアドレスを指定して、特性のMACAddrListはストリングの順不同のリストを提供します。 MACが正準な形式を扱う802は使用されています。 ABNF定義[6]は以下の通りです。
MACaddress = 1*4HEXDIG ":" 1*4HEXDIG ":" 1*4HEXDIG MACmaskedaddress = MACaddress","MACaddress
「MACaddressは1*4HEXDIGと等しい」:、」 「1*4HEXDIG」:、」 「1*4HEXDIG MACmaskedaddressはMACaddressと等しい」「MACaddress」
Each string entry is either:
それぞれのストリングエントリーはどちらかです:
1. A single MAC address. Example: 0000:00A5:0000
1. ただ一つのMACアドレス。 例: 0000:00A5:0000
2. A MACmaskedaddress address range defined specified by an address
and mask. The mask specifies the relevant bits in the address.
Example: 0000:00A5:0000,FFFF:FFFF:0000 defines a range of MAC
addresses in which the first four octets are equal to 0000:00A5.
2. アドレスの範囲が定義したMACmaskedaddressはアドレスとマスクで指定しました。 マスクはアドレスで関連ビットを指定します。 例: 0000:00A5:0000、FFFF:FFFF:0000は最初の4つの八重奏が0000と等しいさまざまなMACアドレスを定義します: 00A5。
Moore Standards Track [Page 62] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[62ページ]。
The property definition is as follows:
特性の定義は以下の通りです:
NAME MACAddrList SYNTAX String FORMAT MACaddress | MACmaskedaddress
名前MACAddrList構文記号列の書式MACaddress| MACmaskedaddress
6.14.4. The Class "PolicyStringValue"
6.14.4. クラス"PolicyStringValue"
This class is used to represent a single string value, or a set of string values. Each value can have wildcards. The class definition is as follows:
このクラスは、一連値、または1セットのストリング値を表すのに使用されます。 各値はワイルドカードを持つことができます。 クラス定義は以下の通りです:
NAME PolicyStringValue DERIVED FROM PolicyValue ABSTRACT False PROPERTIES StringList[ ]
PolicyValueの抽象的な偽の特性のStringListから得られた名前PolicyStringValue[ ]
The property StringList provides an unordered list of strings, each representing a single string with wildcards. The asterisk character "*" is used as a wildcard, and represents an arbitrary substring replacement. For example, the value "abc*def" matches the string "abcxyzdef", and the value "abc*def*" matches the string "abcxxxdefyyyzzz". The syntax definition is identical to the substring assertion syntax defined in [5]. If the asterisk character is required as part of the string value itself, it MUST be quoted as described in Section 4.3 of [5].
ワイルドカードでそれぞれ一連を表して、特性のStringListはストリングの順不同のリストを提供します。 アスタリスクキャラクタ「*」は、ワイルドカードとして使用されて、任意のサブストリング交換を表します。 例えば、値の「abc*クールな」マッチストリング"abcxyzdef"、および値の「abc*クールな*」はストリング"abcxxxdefyyyzzz"に合っています。 構文定義は[5]で定義されたサブストリング主張構文と同じです。 アスタリスクキャラクタがストリング価値自体の一部として必要であるなら、[5]のセクション4.3で説明されるようにそれを引用しなければなりません。
The property definition is as follows:
特性の定義は以下の通りです:
NAME StringList SYNTAX String
名前StringList構文ストリング
6.14.5. The Class "PolicyBitStringValue"
6.14.5. クラス"PolicyBitStringValue"
This class is used to represent a single bit string value, or a set of bit string values. The class definition is as follows:
このクラスは、ただ一つのビット列値、または1セットのビット列値を表すのに使用されます。 クラス定義は以下の通りです:
NAME PolicyBitStringValue DERIVED FROM PolicyValue ABSTRACT False PROPERTIES BitStringList[ ]
PolicyValueの抽象的な偽の特性のBitStringListから得られた名前PolicyBitStringValue[ ]
The property BitStringList provides an unordered list of strings, each representing a single bit string or a set of bit strings. The number of bits specified SHOULD equal the number of bits of the expected variable. For example, for a one-octet variable, 8 bits
特性のBitStringListはストリングの順不同のリストを提供します、それぞれただ一つのビット列かビット列のセットを表して。 ビットの数はSHOULD同輩のために予想された変数のビットの数を指定しました。 例えば、1八重奏の変数のための8ビット
Moore Standards Track [Page 63] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[63ページ]。
should be specified. If the variable does not have a fixed length, the bit string should be matched against the variable's most significant bit string. The formal definition of a bit string is:
指定されるべきであってください。 変数に固定長がないなら、ビット列は変数の最上位ビットストリングに取り組まされるべきです。 しばらくストリングの公式の定義は以下の通りです。
binary-digit = "0" / "1" bitString = 1*binary-digit maskedBitString = bitString","bitString
バイナリー・ディジット=、「0インチ/「1インチのbitString=1*バイナリー・ディジットmaskedBitString=bitString」、"bitString"
Each string entry is either:
それぞれのストリングエントリーはどちらかです:
1. A single bit string. Example: 00111010
1. ただ一つのビット列。 例: 00111010
2. A range of bit strings specified using a bit string and a bit
mask. The bit string and mask fields have the same number of bits
specified. The mask bit string specifies the significant bits in
the bit string value. For example, 110110, 100110 and 110111
would match the maskedBitString 100110,101110 but 100100 would
not.
2. 指定された使用が少し結んで、少しマスクをかけるさまざまなビット列。 ビット列とマスク分野で、同じ数のビットを指定します。 マスクビット列はビット列値で重要なビットを指定します。 例えば、110110、100110、および110111はmaskedBitString100110、101110に合っているでしょうが、100100は合わせないでしょう。
The property definition is as follows:
特性の定義は以下の通りです:
NAME BitStringList SYNTAX String FORMAT bitString | maskedBitString
名前BitStringList構文記号列の書式bitString| maskedBitString
6.14.6. The Class "PolicyIntegerValue"
6.14.6. クラス"PolicyIntegerValue"
This class provides a list of integer and integer range values. Integers of arbitrary sizes can be represented. The class definition is as follows:
このクラスは整数と整数範囲値のリストを提供します。 任意のサイズの整数を表すことができます。 クラス定義は以下の通りです:
NAME PolicyIntegerValue DERIVED FROM PolicyValue ABSTRACT False PROPERTIES IntegerList[ ]
PolicyValueの抽象的な偽の特性のIntegerListから得られた名前PolicyIntegerValue[ ]
The property IntegerList provides an unordered list of integers and integer range values, represented as strings. The format of this property takes one of the following forms:
特性のIntegerListは整数の順不同のリストとストリングとして表された整数範囲値を提供します。 この特性の形式は以下のフォームの1つを取ります:
1. An integer value.
1. 整数値。
2. A range of integers. The range is specified by a starting integer
and an ending integer, separated by '..'. The starting integer
MUST be less than or equal to the ending integer. The range
includes all integers between the starting and ending integers,
including these two integers.
2. さまざまな整数。 '切り離されて、範囲は始めの整数と終わりの整数によって指定されます'。'. 始めの整数は終わりの、より整数以下であるに違いありません。 範囲はこれらの2つの整数を含む始めの、そして、終わりの整数の間のすべての整数を含んでいます。
Moore Standards Track [Page 64] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[64ページ]。
To represent a range of integers that is not bounded, the reserved words -INFINITY and/or INFINITY can be used in place of the starting and ending integers. In addition to ordinary integer matches, INFINITY matches INFINITY and -INFINITY matches -INFINITY.
始めと整数を終わらせることに代わってリザーブドワードのさまざまな境界がない整数、-INFINITY、そして/または、INFINITYを表すのを使用できます。 普通の整数マッチに加えて、INFINITYはINFINITYに合っています、そして、-INFINITYは-INFINITYに合っています。
The ABNF definition [6] is:
ABNF定義[6]は以下の通りです。
integer = [-]1*DIGIT | "INFINITY" | "-INFINITY" integerrange = integer".."integer
[-] 整数=1*DIGIT| 「無限」| 「"-INFINITY"integerrange=整数」、」整数
Using ranges, the operators greater-than, greater-than-or-equal-to, less- than, and less-than-or-equal-to can be expressed. For example, "X is- greater-than 5" (where X is an integer) can be translated to "X matches 6-INFINITY". This enables the match condition semantics of the operator for the SimplePolicyCondition class to be kept simple (i.e., just the value "match").
範囲、オペレータを使用する、すばらしさ、-、 より少ない、それほど言い表すことができません。 例えば、「X、存在、すばらしさ、-、5インチ(Xが整数であるところ)を「Xは6-INFINITYに合うこと」に翻訳できる、」 これは、SimplePolicyConditionのクラスのオペレータのマッチ状態意味論が簡単に(すなわち、まさしく値の「マッチ」)保たれるのを可能にします。
The property definition is as follows:
特性の定義は以下の通りです:
NAME IntegerList SYNTAX String FORMAT integer | integerrange
NAME IntegerList SYNTAX String FORMAT整数| integerrange
6.14.7. The Class "PolicyBooleanValue"
6.14.7. クラス"PolicyBooleanValue"
This class is used to represent a Boolean (TRUE/FALSE) value. The class definition is as follows:
このクラスは、ブール(TRUE/FALSE)値を表すのに使用されます。 クラス定義は以下の通りです:
NAME PolicyBooleanValue DERIVED FROM PolicyValue ABSTRACT False PROPERTIES BooleanValue
PolicyValueの抽象的な偽の特性のBooleanValueから得られた名前PolicyBooleanValue
The property definition is as follows:
特性の定義は以下の通りです:
NAME BooleanValue SYNTAX boolean
NAME BooleanValue SYNTAX論理演算子
6.15. The Class "PolicyRoleCollection"
6.15. クラス"PolicyRoleCollection"
This class represents a collection of managed elements that share a common role. The PolicyRoleCollection always exists in the context of a system, specified using the PolicyRoleCollectionInSystem association. The value of the PolicyRole property in this class specifies the role, and can be matched with the value(s) in the PolicyRoles array in PolicyRules and PolicyGroups. ManagedElements that share the role defined in this collection are aggregated into the collection via the association ElementInPolicyRoleCollection.
このクラスは一般的な役割を共有する管理された要素の収集を表します。 PolicyRoleCollectionはPolicyRoleCollectionInSystem協会を使用することで指定されたシステムの文脈にいつも存在しています。 このクラスにおける、PolicyRole属性の価値は、役割を指定して、PolicyRulesのPolicyRoles配列における値とPolicyGroupsに合わせることができます。 この収集で定義された役割を共有するManagedElementsが協会ElementInPolicyRoleCollectionを通して収集に集められます。
Moore Standards Track [Page 65] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[65ページ]。
NAME PolicyRoleCollection
DESCRIPTION A subclass of the CIM Collection class used to group
together managed elements that share a role.
DERIVED FROM Collection
ABSTRACT FALSE
一緒に分類するのに使用されるCIM CollectionのクラスのNAME PolicyRoleCollection記述Aサブクラスは役割を共有する要素を管理しました。 収集要約から、虚偽で派生します。
PROPERTIES PolicyRole
特性のPolicyRole
6.15.1. The Single-Valued Property "PolicyRole"
6.15.1. 単一に評価された特性の"PolicyRole"
This property represents the role associated with a PolicyRoleCollection. The property definition is as follows:
この特性はPolicyRoleCollectionに関連している役割を表します。 特性の定義は以下の通りです:
NAME PolicyRole
DESCRIPTION A string representing the role associated with a
PolicyRoleCollection.
SYNTAX string
役割を表すNAME PolicyRole記述五弦がPolicyRoleCollectionと交際しました。 SYNTAXストリング
6.16. The Class "ReusablePolicyContainer"
6.16. クラス"ReusablePolicyContainer"
The new class ReusablePolicyContainer is defined as follows:
新しいクラスReusablePolicyContainerは以下の通り定義されます:
NAME ReusablePolicyContainer
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
PROPERTIES (none)
再利用できる方針関連の情報のために行政上定義されたコンテナを表すNAME ReusablePolicyContainer記述Aのクラス。 このクラスはsuperclass AdminDomainのそれらを超えて少しの追加資産も紹介しません。 しかしながら、それは多くのユニークな協会に参加します。 AdminDomainの抽象的な偽の特性から、派生します。(なにも)
6.17. Deprecate PCIM's Class "PolicyRepository"
6.17. PCIMのクラス"PolicyRepository"を非難してください。
The class definition of PolicyRepository (from PCIM) is updated as follows, with an indication that the class has been deprecated. Note that when an element of the model is deprecated, its replacement element is identified explicitly.
以下の通りクラスが推奨しないという指示でPolicyRepository(PCIMからの)のクラス定義をアップデートします。 モデルの原理が推奨しないときに、交換要素が明らかに特定されることに注意してください。
NAME PolicyRepository
DEPRECATED FOR ReusablePolicyContainer
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.
再利用できる方針関連の情報のために行政上定義されたコンテナを表すNAME PolicyRepository DEPRECATED FOR ReusablePolicyContainer記述Aのクラス。 このクラスはsuperclass AdminDomainのそれらを超えて少しの追加資産も紹介しません。 しかしながら、それは多くのユニークな協会に参加します。
Moore Standards Track [Page 66] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[66ページ]。
DERIVED FROM AdminDomain ABSTRACT FALSE PROPERTIES (none)
AdminDomainの抽象的な偽の特性から、派生します。(なにも)
6.18. The Abstract Class "FilterEntryBase"
6.18. 抽象クラス"FilterEntryBase"
FilterEntryBase is the abstract base class from which all filter entry classes are derived. It serves as the endpoint for the EntriesInFilterList aggregation, which groups filter entries into filter lists. Its properties include CIM naming attributes and an IsNegated boolean property (to easily "NOT" the match information specified in an instance of one of its subclasses).
FilterEntryBaseはすべてのフィルタエントリーのクラスが引き出される抽象的な基底クラスです。 それはEntriesInFilterList集合のための終点として機能します。(集合はフィルタエントリーをフィルタリストに分類します)。 特性はCIM命名属性とIsNegated論理演算子の特性を含んでいます(容易に「NOT」にマッチ情報はサブクラスの1つのインスタンスで指定しました)。
The class definition is as follows:
クラス定義は以下の通りです:
NAME FilterEntryBase
DESCRIPTION An abstract class representing a single
filter that is aggregated into a
FilterList via the aggregation
EntriesInFilterList.
DERIVED FROM LogicalElement
TYPE Abstract
PROPERTIES IsNegated
集合EntriesInFilterListを通してFilterListに集められる単一のフィルタを表すNAME FilterEntryBase記述An抽象クラス。 LogicalElementのタイプの抽象的な特性のIsNegatedから、派生します。
6.19. The Class "IpHeadersFilter"
6.19. クラス"IpHeadersFilter"
This concrete class contains the most commonly required properties for performing filtering on IP, TCP or UDP headers. Properties not present in an instance of IPHeadersFilter are treated as 'all values'. A property HdrIpVersion identifies whether the IP addresses in an instance are IPv4 or IPv6 addresses. Since the source and destination IP addresses come from the same packet header, they will always be of the same type.
この具象クラスはIP、TCPまたはUDPでヘッダーをフィルターにかけながら働くための最も一般的に必要な特性を含みます。 IPHeadersFilterのインスタンスにおける現在でない特性は'すべての値'として扱われます。 HdrIpVersionがインスタンスにおけるIPアドレスがIPv4かIPv6アドレスであることにかかわらず特定する特性。 IPが演説するソースと目的地が同じパケットのヘッダーから来るので、同じタイプには彼らがいつもいるでしょう。
The class definition is as follows:
クラス定義は以下の通りです:
NAME IpHeadersFilter
DESCRIPTION A class representing an entire IP
header filter, or any subset of one.
DERIVED FROM FilterEntryBase
TYPE Concrete
PROPERTIES HdrIpVersion, HdrSrcAddress,
HdrSrcAddressEndOfRange, HdrSrcMask,
HdrDestAddress, HdrDestAddressEndOfRange,
HdrDestMask, HdrProtocolID,
HdrSrcPortStart, HdrSrcPortEnd,
HdrDestPortStart, HdrDestPortEnd, HdrDSCP[ ],
HdrFlowLabel
全体のIPヘッダーフィルタ、または1のどんな部分集合も表すNAME IpHeadersFilter記述Aのクラス。 FilterEntryBaseから派生して、コンクリートの特性HdrIpVersionをタイプしてください、HdrSrcAddress、HdrSrcAddressEndOfRange、HdrSrcMask、HdrDestAddress、HdrDestAddressEndOfRange、HdrDestMask、HdrProtocolID、HdrSrcPortStart、HdrSrcPortEnd、HdrDestPortStart、HdrDestPortEnd、HdrDSCP[ ]、HdrFlowLabel
Moore Standards Track [Page 67] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[67ページ]。
6.19.1. The Property HdrIpVersion
6.19.1. 特性のHdrIpVersion
This property is an 8-bit unsigned integer, identifying the version of the IP addresses to be filtered on. IP versions are identified as they are in the Version field of the IP packet header - IPv4 = 4, IPv6 = 6. These two values are the only ones defined for this property.
フィルターにかけられるIPアドレスのバージョンを特定して、この特性は8ビットの符号のない整数です。 それらがIPパケットのヘッダーのバージョン分野にあるとき、IPバージョンは特定されます--IPv4=4、IPv6=6。 これらの2つの値がこの特性のために定義された唯一のものです。
The value of this property determines the sizes of the OctetStrings in the six properties HdrSrcAddress, HdrSrcAddressEndOfRange, HdrSrcMask, HdrDestAddress, HdrDestAddressEndOfRange, and HdrDestMask, as follows:
この属性の価値は6特性のHdrSrcAddress、HdrSrcAddressEndOfRange、HdrSrcMask、HdrDestAddress、HdrDestAddressEndOfRangeのOctetStringsのサイズ、およびHdrDestMaskを決定します、以下の通りです:
o IPv4: OctetString(SIZE (4))
o IPv4: OctetString(サイズ(4))
o IPv6: OctetString(SIZE (16|20)), depending on whether a scope
identifier is present
o IPv6: 範囲識別子が存在しているかどうかによるOctetString(SIZE(16|20))
If a value for this property is not provided, then the filter does not consider IP version in selecting matching packets, i.e., IP version matches for all values. In this case, the HdrSrcAddress, HdrSrcAddressEndOfRange, HdrSrcMask, HdrDestAddress, HdrDestAddressEndOfRange, and HdrDestMask must also not be present.
この特性のための値が提供されないなら、フィルタは合っているパケット(すなわち、すべての値のためのIPバージョンマッチ)を選択する際にIPバージョンを考えません。 また、この場合、HdrSrcAddress、HdrSrcAddressEndOfRange、HdrSrcMask、HdrDestAddress、HdrDestAddressEndOfRange、およびHdrDestMaskも存在しているはずがありません。
6.19.2. The Property HdrSrcAddress
6.19.2. 特性のHdrSrcAddress
This property is an OctetString, of a size determined by the value of the HdrIpVersion property, representing a source IP address. When there is no HdrSrcAddressEndOfRange value, this value is compared to the source address in the IP header, subject to the mask represented in the HdrSrcMask property. (Note that the mask is ANDed with the address.) When there is a HdrSrcAddressEndOfRange value, this value is the start of the specified range (i.e., the HdrSrcAddress is lower than the HdrSrcAddressEndOfRange) that is compared to the source address in the IP header and matches on any value in the range.
この特性はHdrIpVersion属性の価値で決定しているサイズのOctetStringです、ソースIPアドレスを表して。 HdrSrcAddressEndOfRange値が全くないとき、この値はIPヘッダーでHdrSrcMask所有地に表されたマスクを条件としてソースアドレスと比較されます。 (マスクがアドレスがあるANDedであることに注意してください。) HdrSrcAddressEndOfRange値があるとき、この値は範囲のどんな値でもIPヘッダーとマッチでソースアドレスと比較される指定された範囲(すなわち、HdrSrcAddressはHdrSrcAddressEndOfRangeより低い)の始まりです。
If a value for this property is not provided, then the filter does not consider HdrSrcAddress in selecting matching packets, i.e., HdrSrcAddress matches for all values.
この特性のための値が提供されないなら、フィルタは合っているパケット(すなわち、すべての値のためのHdrSrcAddressマッチ)を選択する際にHdrSrcAddressを考えません。
6.19.3. The Property HdrSrcAddressEndOfRange
6.19.3. 特性のHdrSrcAddressEndOfRange
This property is an OctetString, of a size determined by the value of the HdrIpVersion property, representing the end of a range of source IP addresses (inclusive), where the start of the range is the HdrSrcAddress property value.
この特性はHdrIpVersion属性の価値で決定しているサイズのOctetStringです、範囲の始まりがHdrSrcAddress資産価値であるさまざまなソースIPアドレス(包括的な)の終わりを表して。
Moore Standards Track [Page 68] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[68ページ]。
If a value for HdrSrcAddress is not provided, then this property also MUST NOT be provided. If a value for this property is provided, then HdrSrcMask MUST NOT be provided.
HdrSrcAddressのための値を提供しないなら、この資産も提供してはいけません。 この特性のための値を提供するなら、HdrSrcMaskを提供してはいけません。
6.19.4. The Property HdrSrcMask
6.19.4. 特性のHdrSrcMask
This property is an OctetString, of a size determined by the value of the HdrIpVersion property, representing a mask to be used in comparing the source address in the IP header with the value represented in the HdrSrcAddress property.
この特性はHdrIpVersion属性の価値で決定しているサイズのOctetStringです、IPヘッダーでHdrSrcAddress所有地に表される値とソースアドレスを比較する際に使用されるためにマスクを表して。
If a value for this property is not provided, then the filter does not consider HdrSrcMask in selecting matching packets, i.e., the value of HdrSrcAddress or the source address range must match the source address in the packet exactly. If a value for this property is provided, then HdrSrcAddressEndOfRange MUST NOT be provided.
この特性のための値が提供されないなら、フィルタは合っているパケットを選択する際にHdrSrcMaskを考えません、すなわち、HdrSrcAddressの値かソースアドレス範囲がまさにパケットでソースアドレスに合わなければなりません。 この特性のための値を提供するなら、HdrSrcAddressEndOfRangeを提供してはいけません。
6.19.5. The Property HdrDestAddress
6.19.5. 特性のHdrDestAddress
This property is an OctetString, of a size determined by the value of the HdrIpVersion property, representing a destination IP address. When there is no HdrDestAddressEndOfRange value, this value is compared to the destination address in the IP header, subject to the mask represented in the HdrDestMask property. (Note that the mask is ANDed with the address.) When there is a HdrDestAddressEndOfRange value, this value is the start of the specified range (i.e., the HdrDestAddress is lower than the HdrDestAddressEndOfRange) that is compared to the destination address in the IP header and matches on any value in the range.
この特性はHdrIpVersion属性の価値で決定しているサイズのOctetStringです、送付先IPアドレスを表して。 HdrDestAddressEndOfRange値が全くないとき、この値はIPヘッダーでHdrDestMask所有地に表されたマスクを条件として送付先アドレスと比較されます。 (マスクがアドレスがあるANDedであることに注意してください。) HdrDestAddressEndOfRange値があるとき、この値は範囲のどんな値でもIPヘッダーとマッチで送付先アドレスと比較される指定された範囲(すなわち、HdrDestAddressはHdrDestAddressEndOfRangeより低い)の始まりです。
If a value for this property is not provided, then the filter does not consider HdrDestAddress in selecting matching packets, i.e., HdrDestAddress matches for all values.
この特性のための値が提供されないなら、フィルタは合っているパケット(すなわち、すべての値のためのHdrDestAddressマッチ)を選択する際にHdrDestAddressを考えません。
6.19.6. The Property HdrDestAddressEndOfRange
6.19.6. 特性のHdrDestAddressEndOfRange
This property is an OctetString, of a size determined by the value of the HdrIpVersion property, representing the end of a range of destination IP addresses (inclusive), where the start of the range is the HdrDestAddress property value.
この特性はHdrIpVersion属性の価値で決定しているサイズのOctetStringです、範囲の始まりがHdrDestAddress資産価値であるさまざまな送付先IPアドレス(包括的な)の終わりを表して。
If a value for HdrDestAddress is not provided, then this property also MUST NOT be provided. If a value for this property is provided, then HdrDestMask MUST NOT be provided.
HdrDestAddressのための値を提供しないなら、この資産も提供してはいけません。 この特性のための値を提供するなら、HdrDestMaskを提供してはいけません。
Moore Standards Track [Page 69] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[69ページ]。
6.19.7. The Property HdrDestMask
6.19.7. 特性のHdrDestMask
This property is an OctetString, of a size determined by the value of the HdrIpVersion property, representing a mask to be used in comparing the destination address in the IP header with the value represented in the HdrDestAddress property.
この特性はHdrIpVersion属性の価値で決定しているサイズのOctetStringです、IPヘッダーでHdrDestAddress所有地に表される値と送付先アドレスを比較する際に使用されるためにマスクを表して。
If a value for this property is not provided, then the filter does not consider HdrDestMask in selecting matching packets, i.e., the value of HdrDestAddress or the destination address range must match the destination address in the packet exactly. If a value for this property is provided, then HdrDestAddressEndOfRange MUST NOT be provided.
この特性のための値が提供されないなら、フィルタは合っているパケットを選択する際にHdrDestMaskを考えません、すなわち、HdrDestAddressの値か目的地のアドレスの範囲がまさにパケットで送付先アドレスに合わなければなりません。 この特性のための値を提供するなら、HdrDestAddressEndOfRangeを提供してはいけません。
6.19.8. The Property HdrProtocolID
6.19.8. 特性のHdrProtocolID
This property is an 8-bit unsigned integer, representing an IP protocol type. This value is compared to the Protocol field in the IP header.
IPプロトコルタイプの代理をして、この特性は8ビットの符号のない整数です。 この値はIPヘッダーのプロトコル分野にたとえられます。
If a value for this property is not provided, then the filter does not consider HdrProtocolID in selecting matching packets, i.e., HdrProtocolID matches for all values.
この特性のための値が提供されないなら、フィルタは合っているパケット(すなわち、すべての値のためのHdrProtocolIDマッチ)を選択する際にHdrProtocolIDを考えません。
6.19.9. The Property HdrSrcPortStart
6.19.9. 特性のHdrSrcPortStart
This property is a 16-bit unsigned integer, representing the lower end of a range of UDP or TCP source ports. The upper end of the range is represented by the HdrSrcPortEnd property. The value of HdrSrcPortStart MUST be no greater than the value of HdrSrcPortEnd. A single port is indicated by equal values for HdrSrcPortStart and HdrSrcPortEnd.
さまざまなUDPかTCPソースポートの下側の端を表して、この特性は16ビットの符号のない整数です。 範囲の上側の端はHdrSrcPortEndの特性によって表されます。 HdrSrcPortStartの値はHdrSrcPortEndの、より値以下でなければなりません。 単一のポートはHdrSrcPortStartとHdrSrcPortEndのために等しい値によって示されます。
A source port filter is evaluated by testing whether the source port identified in the IP header falls within the range of values between HdrSrcPortStart and HdrSrcPortEnd, including these two end points.
ソースポートフィルタはIPヘッダーで特定されたソースポートがHdrSrcPortStartとHdrSrcPortEndの間の値の範囲の中で転ぶか否かに関係なく、テストすることによって、評価されます、これらの2つのエンドポイントを含んでいて。
If a value for this property is not provided, then the filter does not consider HdrSrcPortStart in selecting matching packets, i.e., there is no lower bound in matching source port values.
この特性のための値が提供されないなら、フィルタは合っているパケットを選択する際にHdrSrcPortStartを考えません、すなわち、合っているソースポート値には下界が全くありません。
6.19.10. The Property HdrSrcPortEnd
6.19.10. 特性のHdrSrcPortEnd
This property is a 16-bit unsigned integer, representing the upper end of a range of UDP or TCP source ports. The lower end of the range is represented by the HdrSrcPortStart property. The value of
さまざまなUDPかTCPソースポートの上側の終わりを表して、この特性は16ビットの符号のない整数です。 範囲の下側の端はHdrSrcPortStartの特性によって表されます。 価値
Moore Standards Track [Page 70] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[70ページ]。
HdrSrcPortEnd MUST be no less than the value of HdrSrcPortStart. A single port is indicated by equal values for HdrSrcPortStart and HdrSrcPortEnd.
HdrSrcPortEndは少なくともHdrSrcPortStartの値であるに違いありません。 単一のポートはHdrSrcPortStartとHdrSrcPortEndのために等しい値によって示されます。
A source port filter is evaluated by testing whether the source port identified in the IP header falls within the range of values between HdrSrcPortStart and HdrSrcPortEnd, including these two end points.
ソースポートフィルタはIPヘッダーで特定されたソースポートがHdrSrcPortStartとHdrSrcPortEndの間の値の範囲の中で転ぶか否かに関係なく、テストすることによって、評価されます、これらの2つのエンドポイントを含んでいて。
If a value for this property is not provided, then the filter does not consider HdrSrcPortEnd in selecting matching packets, i.e., there is no upper bound in matching source port values.
この特性のための値が提供されないなら、フィルタは合っているパケットを選択する際にHdrSrcPortEndを考えません、すなわち、合っているソースポート値には上限が全くありません。
6.19.11. The Property HdrDestPortStart
6.19.11. 特性のHdrDestPortStart
This property is a 16-bit unsigned integer, representing the lower end of a range of UDP or TCP destination ports. The upper end of the range is represented by the HdrDestPortEnd property. The value of HdrDestPortStart MUST be no greater than the value of HdrDestPortEnd. A single port is indicated by equal values for HdrDestPortStart and HdrDestPortEnd.
さまざまなUDPかTCP仕向港の下側の端を表して、この特性は16ビットの符号のない整数です。 範囲の上側の端はHdrDestPortEndの特性によって表されます。 HdrDestPortStartの値はHdrDestPortEndの、より値以下でなければなりません。 単一のポートはHdrDestPortStartとHdrDestPortEndのために等しい値によって示されます。
A destination port filter is evaluated by testing whether the destination port identified in the IP header falls within the range of values between HdrDestPortStart and HdrDestPortEnd, including these two end points.
仕向港フィルタはIPヘッダーで特定された仕向港がHdrDestPortStartとHdrDestPortEndの間の値の範囲の中で転ぶか否かに関係なく、テストすることによって、評価されます、これらの2つのエンドポイントを含んでいて。
If a value for this property is not provided, then the filter does not consider HdrDestPortStart in selecting matching packets, i.e., there is no lower bound in matching destination port values.
この特性のための値が提供されないなら、フィルタは合っているパケットを選択する際にHdrDestPortStartを考えません、すなわち、合っている仕向港値には下界が全くありません。
6.19.12. The Property HdrDestPortEnd
6.19.12. 特性のHdrDestPortEnd
This property is a 16-bit unsigned integer, representing the upper end of a range of UDP or TCP destination ports. The lower end of the range is represented by the HdrDestPortStart property. The value of HdrDestPortEnd MUST be no less than the value of HdrDestPortStart. A single port is indicated by equal values for HdrDestPortStart and HdrDestPortEnd.
さまざまなUDPかTCP仕向港の上側の端を表して、この特性は16ビットの符号のない整数です。 範囲の下側の端はHdrDestPortStartの特性によって表されます。 HdrDestPortEndの値は少なくともHdrDestPortStartの値でなければなりません。 単一のポートはHdrDestPortStartとHdrDestPortEndのために等しい値によって示されます。
A destination port filter is evaluated by testing whether the destination port identified in the IP header falls within the range of values between HdrDestPortStart and HdrDestPortEnd, including these two end points.
仕向港フィルタはIPヘッダーで特定された仕向港がHdrDestPortStartとHdrDestPortEndの間の値の範囲の中で転ぶか否かに関係なく、テストすることによって、評価されます、これらの2つのエンドポイントを含んでいて。
If a value for this property is not provided, then the filter does not consider HdrDestPortEnd in selecting matching packets, i.e., there is no upper bound in matching destination port values.
この特性のための値が提供されないなら、フィルタは合っているパケットを選択する際にHdrDestPortEndを考えません、すなわち、合っている仕向港値には上限が全くありません。
Moore Standards Track [Page 71] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[71ページ]。
6.19.13. The Property HdrDSCP
6.19.13. 特性のHdrDSCP
The property HdrDSCP is defined as an array of uint8's, restricted to the range 0..63. Since DSCPs are defined as discrete code points, with no inherent structure, there is no semantically significant relationship between different DSCPs. Consequently, there is no provision for specifying a range of DSCPs in this property. However, a list of individual DSCPs, which are ORed together to form a filter, is supported by the array syntax.
特性のHdrDSCPは範囲0に制限されたuint8のものの配列と定義されます。63. 離散的なコードが指す固有の構造なしでDSCPsが定義されるので、異なったDSCPsの間には、どんな意味的に重要な関係もありません。 その結果、さまざまなDSCPsを指定することへの支給が全くこの特性にありません。 しかしながら、個々のDSCPsのリストは配列構文でサポートされます。(DSCPsはフィルタを形成するために一緒にいるORedです)。
If a value for this property is not provided, then the filter does not consider HdrDSCP in selecting matching packets, i.e., HdrDSCP matches for all values.
この特性のための値が提供されないなら、フィルタは合っているパケット(すなわち、すべての値のためのHdrDSCPマッチ)を選択する際にHdrDSCPを考えません。
6.19.14. The Property HdrFlowLabel
6.19.14. 特性のHdrFlowLabel
The 20-bit Flow Label field in the IPv6 header may be used by a source to label sequences of packets for which it requests special handling by IPv6 devices, such as non-default quality of service or 'real-time' service. This property is an octet string of size 3 (that is, 24 bits), in which the 20-bit Flow Label appears in the rightmost 20 bits, padded on the left with b'0000'.
IPv6ヘッダーの20ビットのFlow Label分野はそれがIPv6による特別な取り扱いを要求するパケットの系列をデバイスとラベルするのにソースによって使用されるかもしれません、非デフォルトサービスの質や'リアルタイムで'のサービスのように。 この特性はサイズ3(すなわち、24ビット)の八重奏ストリングです、どのFlow Labelが一番右の20で見える20ビットビットで、左では、b'0000'で、そっと歩くか。
If a value for this property is not provided, then the filter does not consider HdrFlowLabel in selecting matching packets, i.e., HdrFlowLabel matches for all values.
この特性のための値が提供されないなら、フィルタは合っているパケット(すなわち、すべての値のためのHdrFlowLabelマッチ)を選択する際にHdrFlowLabelを考えません。
6.20. The Class "8021Filter"
6.20. クラス"8021Filter"
This concrete class allows 802.1.source and destination MAC addresses, as well as the 802.1 protocol ID, priority, and VLAN identifier fields, to be expressed in a single object
この具象クラスは、単一のオブジェクトで言い表されるために802.1.source、802.1がIDについて議定書の中で述べるときまた、MACが扱う目的地、優先権、およびVLANに識別子分野を許容します。
The class definition is as follows:
クラス定義は以下の通りです:
NAME 8021Filter
DESCRIPTION A class that allows 802.1 source
and destination MAC address and
protocol ID, priority, and VLAN
identifier filters to be
expressed in a single object.
DERIVED FROM FilterEntryBase
TYPE Concrete
PROPERTIES 8021HdrSrcMACAddr, 8021HdrSrcMACMask,
8021HdrDestMACAddr, 8021HdrDestMACMask,
8021HdrProtocolID, 8021HdrPriorityValue,
8021HDRVLANID
802.1ソースと目的地MACを許容するNAME 8021Filter記述Aのクラスは、単一のオブジェクトで言い表されるためにID、優先権、およびVLAN識別子フィルタを扱って、議定書の中で述べます。 FilterEntryBaseタイプコンクリートの特性8021HdrSrcMACAddr、8021HdrSrcMACMask、8021HdrDestMACAddr、8021HdrDestMACMask、8021HdrProtocolID、8021HdrPriorityValue、8021HDRVLANIDから、派生します。
Moore Standards Track [Page 72] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[72ページ]。
6.20.1. The Property 8021HdrSrcMACAddr
6.20.1. 特性の8021HdrSrcMACAddr
This property is an OctetString of size 6, representing a 48-bit source MAC address in canonical format. This value is compared to the SourceAddress field in the MAC header, subject to the mask represented in the 8021HdrSrcMACMask property.
正準な形式で48ビットのソースMACアドレスを表して、この特性はサイズ6のOctetStringです。 この値は8021HdrSrcMACMask所有地に表されたマスクを条件としてMACヘッダーのSourceAddress分野にたとえられます。
If a value for this property is not provided, then the filter does not consider 8021HdrSrcMACAddr in selecting matching packets, i.e., 8021HdrSrcMACAddr matches for all values.
この特性のための値が提供されないなら、フィルタは合っているパケット(すなわち、すべての値のための8021HdrSrcMACAddrマッチ)を選択する際に8021HdrSrcMACAddrを考えません。
6.20.2. The Property 8021HdrSrcMACMask
6.20.2. 特性の8021HdrSrcMACMask
This property is an OctetString of size 6, representing a 48-bit mask to be used in comparing the SourceAddress field in the MAC header with the value represented in the 8021HdrSrcMACAddr property.
この特性はサイズ6のOctetStringです、MACヘッダーのSourceAddress分野を8021HdrSrcMACAddr所有地に表される値にたとえる際に使用されるために48ビットのマスクを表して。
If a value for this property is not provided, then the filter does not consider 8021HdrSrcMACMask in selecting matching packets, i.e., the value of 8021HdrSrcMACAddr must match the source MAC address in the packet exactly.
この特性のための値が提供されないなら、フィルタは合っているパケットを選択する際に8021HdrSrcMACMaskを考えません、すなわち、8021HdrSrcMACAddrの値がまさにパケットでソースMACアドレスに合わなければなりません。
6.20.3. The Property 8021HdrDestMACAddr
6.20.3. 特性の8021HdrDestMACAddr
This property is an OctetString of size 6, representing a 48-bit destination MAC address in canonical format. This value is compared to the DestinationAddress field in the MAC header, subject to the mask represented in the 8021HdrDestMACMask property.
正準な形式で48ビットの送付先MACアドレスを表して、この特性はサイズ6のOctetStringです。 この値は8021HdrDestMACMask所有地に表されたマスクを条件としてMACヘッダーのDestinationAddress分野にたとえられます。
If a value for this property is not provided, then the filter does not consider 8021HdrDestMACAddr in selecting matching packets, i.e., 8021HdrDestMACAddr matches for all values.
この特性のための値が提供されないなら、フィルタは合っているパケット(すなわち、すべての値のための8021HdrDestMACAddrマッチ)を選択する際に8021HdrDestMACAddrを考えません。
6.20.4. The Property 8021HdrDestMACMask
6.20.4. 特性の8021HdrDestMACMask
This property is an OctetString of size 6, representing a 48-bit mask to be used in comparing the DestinationAddress field in the MAC header with the value represented in the 8021HdrDestMACAddr property.
この特性はサイズ6のOctetStringです、MACヘッダーのDestinationAddress分野を8021HdrDestMACAddr所有地に表される値にたとえる際に使用されるために48ビットのマスクを表して。
If a value for this property is not provided, then the filter does not consider 8021HdrDestMACMask in selecting matching packets, i.e., the value of 8021HdrDestMACAddr must match the destination MAC address in the packet exactly.
この特性のための値が提供されないなら、フィルタは合っているパケットを選択する際に8021HdrDestMACMaskを考えません、すなわち、8021HdrDestMACAddrの値がまさにパケットで送付先MACアドレスに合わなければなりません。
Moore Standards Track [Page 73] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[73ページ]。
6.20.5. The Property 8021HdrProtocolID
6.20.5. 特性の8021HdrProtocolID
This property is a 16-bit unsigned integer, representing an Ethernet protocol type. This value is compared to the Ethernet Type field in the 802.3 MAC header.
イーサネットプロトコルタイプの代理をして、この特性は16ビットの符号のない整数です。 この値は802.3MACヘッダーのイーサネットType分野にたとえられます。
If a value for this property is not provided, then the filter does not consider 8021HdrProtocolID in selecting matching packets, i.e., 8021HdrProtocolID matches for all values.
この特性のための値が提供されないなら、フィルタは合っているパケット(すなわち、すべての値のための8021HdrProtocolIDマッチ)を選択する際に8021HdrProtocolIDを考えません。
6.20.6. The Property 8021HdrPriorityValue
6.20.6. 特性の8021HdrPriorityValue
This property is an 8-bit unsigned integer, representing an 802.1Q priority. This value is compared to the Priority field in the 802.1Q header. Since the 802.1Q Priority field consists of 3 bits, the values for this property are limited to the range 0..7.
802.1Q優先を表して、この特性は8ビットの符号のない整数です。 この値は802.1QヘッダーのPriority分野にたとえられます。 802.1Q Priority分野が3ビットから成るので、この特性のための値は範囲0に制限されます。7.
If a value for this property is not provided, then the filter does not consider 8021HdrPriorityValue in selecting matching packets, i.e., 8021HdrPriorityValue matches for all values.
この特性のための値が提供されないなら、フィルタは合っているパケット(すなわち、すべての値のための8021HdrPriorityValueマッチ)を選択する際に8021HdrPriorityValueを考えません。
6.20.7. The Property 8021HdrVLANID
6.20.7. 特性の8021HdrVLANID
This property is a 32-bit unsigned integer, representing an 802.1Q VLAN Identifier. This value is compared to the VLAN ID field in the 802.1Q header. Since the 802.1Q VLAN ID field consists of 12 bits, the values for this property are limited to the range 0..4095.
802.1Q VLAN Identifierを表して、この特性は32ビットの符号のない整数です。 この値は802.1QヘッダーのVLAN ID分野にたとえられます。 802.1Q VLAN ID分野が12ビットから成るので、この特性のための値は範囲0に制限されます。4095.
If a value for this property is not provided, then the filter does not consider 8021HdrVLANID in selecting matching packets, i.e., 8021HdrVLANID matches for all values.
この特性のための値が提供されないなら、フィルタは合っているパケット(すなわち、すべての値のための8021HdrVLANIDマッチ)を選択する際に8021HdrVLANIDを考えません。
6.21. The Class FilterList
6.21. クラスFilterList
This is a concrete class that aggregates instances of (subclasses of) FilterEntryBase via the aggregation EntriesInFilterList. It is possible to aggregate different types of filters into a single FilterList - for example, packet header filters (represented by the IpHeadersFilter class) and security filters (represented by subclasses of FilterEntryBase defined by IPsec).
これがそれがインスタンスに集める具象クラスである、(サブクラス、)、集合EntriesInFilterListを通したFilterEntryBase。 独身のFilterListへの異なったタイプのフィルタに集めるのは可能です--例えば、パケットのヘッダーフィルタ(IpHeadersFilterのクラスによって表される)とセキュリティフィルタ(IPsecによって定義されたFilterEntryBaseのサブクラスで、表されます)。
The aggregation property EntriesInFilterList.EntrySequence is always set to 0, to indicate that the aggregated filter entries are ANDed together to form a selector for a class of traffic.
集合特性EntriesInFilterList.EntrySequenceはトラフィックのクラスのためにセレクタを形成するために集められたフィルタエントリーが一緒にANDedであることを示すのを0にいつも用意ができています。
Moore Standards Track [Page 74] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[74ページ]。
The class definition is as follows:
クラス定義は以下の通りです:
NAME FilterList
DESCRIPTION A concrete class representing
the aggregation of multiple filters.
DERIVED FROM LogicalElement
TYPE Concrete
PROPERTIES Direction
複数のフィルタの集合を表すNAME FilterList記述A具象クラス。 LogicalElementタイプコンクリートの特性方向から、派生します。
6.21.1. The Property Direction
6.21.1. 特性の方向
This property is a 16-bit unsigned integer enumeration, representing the direction of the traffic flow to which the FilterList is to be applied. Defined enumeration values are
この特性は16ビットの符号のない整数列挙です、FilterListが適用されていることになっている交通の流れの方向を表して。 定義された列挙値はそうです。
o NotApplicable(0)
o Input(1)
o Output(2)
o Both(3) - This value is used to indicate that the direction is
immaterial, e.g., to filter on a source subnet regardless of
whether the flow is inbound or outbound
o Mirrored(4) - This value is also applicable to both inbound and
outbound flow processing, but it indicates that the filter
criteria are applied asymmetrically to traffic in both directions
and, thus, specifies the reversal of source and destination
criteria (as opposed to the equality of these criteria as
indicated by "Both"). The match conditions in the aggregated
FilterEntryBase subclass instances are defined from the
perspective of outbound flows and applied to inbound flows as well
by reversing the source and destination criteria. So, for
example, consider a FilterList with 3 filter entries indicating
destination port = 80, and source and destination addresses of a
and b, respectively. Then, for the outbound direction, the filter
entries match as specified and the 'mirror' (for the inbound
direction) matches on source port = 80 and source and destination
addresses of b and a, respectively.
o NotApplicable(0)o Input(1)o Output(2)o Both(3)--この値は方向が重要でないのを示すのに使用されます、例えば、流れが本国行きの、または、外国行きのo Mirrored(4)であるかどうかにかかわらずソースサブネットのフィルタに--また、この値も本国行きの、そして、外国行きの両方の流れ処理に適切です; しかし、それは、フィルタ評価基準が両方の方向でトラフィックに非対称的に適用されるのを示して、その結果、ソースと目的地評価基準(示されるとしての「両方」によるこれらの評価基準の平等と対照的に)の反転を指定します。 集められたFilterEntryBaseサブクラスインスタンスにおけるマッチ状態は、外国行きの流れの見解から定義されて、ソースと目的地評価基準を逆にすることによって、また、本国行きの流れに適用されます。 そのように、例えば、それぞれaとbの3つのフィルタエントリーが仕向港=80を示しているFilterList、ソース、および送付先アドレスを考えてください。 次に、外国行きの方向に、フィルタエントリーは指定されるとして合っています、そして、ソースポートの上の'鏡'(本国行きの方向への)マッチはそれぞれbとaの80、ソース、および送付先アドレスと等しいです。
7. Association and Aggregation Definitions
7. 協会と集合定義
The following definitions supplement those in PCIM itself. PCIM definitions that are not DEPRECATED here are still current parts of the overall Policy Core Information Model.
以下の定義はPCIM自身でそれらを補います。 ここのDEPRECATEDでないPCIM定義は総合的なPolicy Core情報Modelのまだ現在の部分です。
7.1. The Aggregation "PolicySetComponent"
7.1. 集合"PolicySetComponent"
PolicySetComponent is a new aggregation class that collects instances of PolicySet subclasses (PolicyGroups and PolicyRules) into coherent sets of policies.
PolicySetComponentはPolicySetサブクラス(PolicyGroupsとPolicyRules)のインスタンスを一貫性を持っているセットの方針に集める新しい集合のクラスです。
Moore Standards Track [Page 75] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[75ページ]。
NAME PolicySetComponent
DESCRIPTION A concrete class representing the components of a
policy set that have the same decision strategy, and
are prioritized within the set.
DERIVED FROM PolicyComponent
ABSTRACT FALSE
PROPERTIES GroupComponent[ref PolicySet[0..n]]
PartComponent[ref PolicySet[0..n]]
Priority
同じ決定戦略を持って、セットの中で最優先する1つの方針セットの部品を表すNAME PolicySetComponent記述A具象クラス。 PolicyComponentの抽象的な誤った特性のGroupComponent[審判PolicySet[0..n]]PartComponent[審判PolicySet[0..n]]優先権から、派生します。
The definition of the Priority property is unchanged from its previous definition in [PCIM].
Priorityの特性の定義は[PCIM]との前の定義によって変わりがありません。
NAME Priority
DESCRIPTION A non-negative integer for prioritizing this
PolicySet component relative to other components of
the same PolicySet. A larger value indicates a
higher priority.
SYNTAX uint16
DEFAULT VALUE 0
同じPolicySetの他の部品に比例してこのPolicySetの部品を最優先させるための非負の整数のNAME Priority記述A。 より大きい値は、より高い優先度を示します。 SYNTAX uint16 DEFAULT VALUE0
7.2. Deprecate PCIM's Aggregation "PolicyGroupInPolicyGroup"
7.2. PCIMの集合"PolicyGroupInPolicyGroup"を非難してください。
The new aggregation PolicySetComponent is used directly to represent aggregation of PolicyGroups by a higher-level PolicyGroup. Thus the aggregation PolicyGroupInPolicyGroup is no longer needed, and can be deprecated.
新しい集合PolicySetComponentは、よりハイレベルのPolicyGroupでPolicyGroupsの集合を表すのに直接使用されます。 したがって、集合PolicyGroupInPolicyGroupはもう必要でなく、推奨しない場合があります。
NAME PolicyGroupInPolicyGroup
DEPRECATED FOR PolicySetComponent
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 DEPRECATED FOR PolicySetComponent記述Aのクラス。 PolicyComponentの抽象的な偽の特性のGroupComponent[審判PolicyGroup[0..n]]PartComponentから、派生します。[審判PolicyGroup[0..n]]
7.3. Deprecate PCIM's Aggregation "PolicyRuleInPolicyGroup"
7.3. PCIMの集合"PolicyRuleInPolicyGroup"を非難してください。
The new aggregation PolicySetComponent is used directly to represent aggregation of PolicyRules by a PolicyGroup. Thus the aggregation PolicyRuleInPolicyGroup is no longer needed, and can be deprecated.
新しい集合PolicySetComponentは、PolicyGroupでPolicyRulesの集合を表すのに直接使用されます。 したがって、集合PolicyRuleInPolicyGroupはもう必要でなく、推奨しない場合があります。
NAME PolicyRuleInPolicyGroup
DEPRECATED FOR PolicySetComponent
DESCRIPTION A class representing the aggregation of PolicyRules
by a PolicyGroup.
DERIVED FROM PolicyComponent
PolicyGroupでPolicyRulesの集合を表すNAME PolicyRuleInPolicyGroup DEPRECATED FOR PolicySetComponent記述Aのクラス。 PolicyComponentから、派生します。
Moore Standards Track [Page 76] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[76ページ]。
ABSTRACT FALSE
PROPERTIES GroupComponent[ref PolicyGroup[0..n]]
PartComponent[ref PolicyRule[0..n]]
抽象的な偽の特性のGroupComponent[審判PolicyGroup[0..n]]PartComponent[審判PolicyRule[0..n]]
7.4. The Abstract Association "PolicySetInSystem"
7.4. 抽象的な協会"PolicySetInSystem"
PolicySetInSystem is a new association that defines a relationship between a System and a PolicySet used in the administrative scope of that system (e.g., AdminDomain, ComputerSystem). The Priority property is used to assign a relative priority to a PolicySet within the administrative scope in contexts where it is not a component of another PolicySet.
PolicySetInSystemはそのシステム(例えば、AdminDomain、ComputerSystem)の管理範囲で使用されるSystemとPolicySetとの関係を定義する新連合です。 Priorityの特性は、それが別のPolicySetの部品でない文脈の管理範囲の中のPolicySetの相対的な優先を割り当てるのに使用されます。
NAME PolicySetInSystem
DESCRIPTION An abstract class representing the relationship
between a System and a PolicySet that is used in the
administrative scope of the System.
DERIVED FROM PolicyInSystem
ABSTRACT TRUE
PROPERTIES Antecedent[ref System[0..1]]
Dependent [ref PolicySet[0..n]]
Priority
SystemとPolicySetとのSystemの管理範囲で使用される関係を表すNAME PolicySetInSystem記述An抽象クラス。 PolicyInSystemの抽象的な本当の特性の前例から派生している[審判システム[0 .1]]依存する[審判PolicySet[0..n]]優先権
The Priority property is used to specify the relative priority of the referenced PolicySet when there are more than one PolicySet instances applied to a managed resource that are not PolicySetComponents and, therefore, have no other relative priority defined.
Priorityの特性は、PolicySetComponentsではなく、管理資源に適用された1つ以上のPolicySetインスタンスがあるとき、参照をつけられたPolicySetの相対的な優先権を指定して、したがって、相対的な優先権が定義したどんな他のものもいないように使用されます。
NAME Priority
DESCRIPTION A non-negative integer for prioritizing the
referenced PolicySet among other PolicySet
instances that are not components of a common
PolicySet. A larger value indicates a higher
priority.
SYNTAX uint16
DEFAULT VALUE 0
一般的なPolicySetの部品でない他のPolicySetインスタンスの中で参照をつけられたPolicySetを最優先させるための非負の整数のNAME Priority記述A。 より大きい値は、より高い優先度を示します。 SYNTAX uint16 DEFAULT VALUE0
7.5. Update PCIM's Weak Association "PolicyGroupInSystem"
7.5. アップデートPCIMの弱い協会"PolicyGroupInSystem"
Regardless of whether it a component of another PolicySet, a PolicyGroup is itself defined within the scope of a System. This association links a PolicyGroup to the System in whose scope the PolicyGroup is defined. It is a subclass of the abstract PolicySetInSystem association. The class definition for the association is as follows:
にかかわらず、それ、別のPolicySetの部品であり、PolicyGroupはSystemの範囲の中で定義されます。 この協会はPolicyGroupが範囲で定義されるSystemにPolicyGroupをリンクします。 それは抽象的なPolicySetInSystem協会のサブクラスです。 協会のためのクラス定義は以下の通りです:
Moore Standards Track [Page 77] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[77ページ]。
NAME PolicyGroupInSystem
DESCRIPTION A class representing the fact that a PolicyGroup is
defined within the scope of a System.
DERIVED FROM PolicySetInSystem
ABSTRACT FALSE
PROPERTIES Antecedent[ref System[1..1]]
Dependent [ref PolicyGroup[weak]]
PolicyGroupがSystemの範囲の中で定義されるという事実を表すNAME PolicyGroupInSystem記述Aのクラス。 PolicySetInSystemの抽象的な誤った特性の前例から派生している[審判システム[1 .1]]扶養家族[審判PolicyGroup[弱い]]
The Reference "Antecedent" is inherited from PolicySetInSystem, 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.
Reference「前例」は、PolicySetInSystemから引き継がれて、基数を[1 .1]に制限するためにくつがえされます。 それは1PolicyGroupsに範囲を供給するSystemのオブジェクト参照として機能します。 これが弱い協会であるので、いつもこのオブジェクト参照のための基数が1である、すなわち、PolicyGroupはちょうど1Systemの範囲の中でいつも定義されます。
The Reference "Dependent" is inherited from PolicySetInSystem, and overridden to become an object reference to a PolicyGroup defined within the scope of a System. Note that for any single instance of the association class PolicyGroupInSystem, this property (like all reference properties) is single-valued. The [0..n] cardinality indicates that a given System may have 0, 1, or more than one PolicyGroups defined within its scope.
Reference「扶養家族」は、PolicySetInSystemから引き継がれて、Systemの範囲の中で定義されたPolicyGroupのオブジェクト参照になるようにくつがえされます。 協会のクラスPolicyGroupInSystemのどんなただ一つのインスタンスにおいても、この特性(すべての参照の特性のような)が単一に評価されていることに注意してください。 [0..n]基数は、与えられたSystemが0、1、または範囲の中で定義された1PolicyGroupsを持っているかもしれないのを示します。
7.6. Update PCIM's Weak Association "PolicyRuleInSystem"
7.6. アップデートPCIMの弱い協会"PolicyRuleInSystem"
Regardless of whether it a component of another PolicySet, 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. It is a subclass of the abstract PolicySetInSystem association. The class definition for the association is as follows:
にかかわらず、それ、別のPolicySetの部品であり、PolicyRuleはSystemの範囲の中で定義されます。 この協会はPolicyRuleが範囲で定義されるSystemにPolicyRuleをリンクします。 それは抽象的なPolicySetInSystem協会のサブクラスです。 協会のためのクラス定義は以下の通りです:
NAME PolicyRuleInSystem
DESCRIPTION A class representing the fact that a PolicyRule is
defined within the scope of a System.
DERIVED FROM PolicySetInSystem
ABSTRACT FALSE
PROPERTIES Antecedent[ref System[1..1]]
Dependent[ref PolicyRule[weak]]
PolicyRuleがSystemの範囲の中で定義されるという事実を表すNAME PolicyRuleInSystem記述Aのクラス。 PolicySetInSystemの抽象的な誤った特性の前例から派生している[審判システム[1 .1]]扶養家族[審判PolicyRule[弱い]]
The Reference "Antecedent" is inherited from PolicySetInSystem, 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.
Reference「前例」は、PolicySetInSystemから引き継がれて、基数を[1 .1]に制限するためにくつがえされます。 それは1PolicyRulesに範囲を供給するSystemのオブジェクト参照として機能します。 これが弱い協会であるので、いつもこのオブジェクト参照のための基数が1である、すなわち、PolicyRuleはちょうど1Systemの範囲の中でいつも定義されます。
Moore Standards Track [Page 78] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[78ページ]。
The Reference "Dependent" is inherited from PolicySetInSystem, 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.
Reference「扶養家族」は、PolicySetInSystemから引き継がれて、Systemの範囲の中で定義されたPolicyRuleのオブジェクト参照になるようにくつがえされます。 協会のクラスPolicyRuleInSystemのどんなただ一つのインスタンスにおいても、この特性(すべてのReferenceの特性のような)が単一に評価されていることに注意してください。 [0..n]基数は、与えられたSystemが0、1、または範囲の中で定義された1PolicyRulesを持っているかもしれないのを示します。
7.7. The Abstract Aggregation "PolicyConditionStructure"
7.7. 抽象的な集合"PolicyConditionStructure"
NAME PolicyConditionStructure
DESCRIPTION A class representing the aggregation of
PolicyConditions by an aggregating instance.
DERIVED FROM PolicyComponent
ABSTRACT TRUE
PROPERTIES PartComponent[ref PolicyCondition[0..n]]
GroupNumber
ConditionNegated
7.8. Update PCIM's Aggregation "PolicyConditionInPolicyRule"
集合インスタンスでPolicyConditionsの集合を表すNAME PolicyConditionStructure記述Aのクラス。 PolicyComponentの抽象的な本当の特性のPartComponent[審判PolicyCondition[0..n]]GroupNumber ConditionNegated7.8から、派生します。 アップデートPCIMの集合"PolicyConditionInPolicyRule"
The PCIM aggregation "PolicyConditionInPolicyRule" is updated, to make it a subclass of the new abstract aggregation PolicyConditionStructure. The properties GroupNumber and ConditionNegated are now inherited, rather than specified explicitly as they were in PCIM.
それを新しい抽象的な集合PolicyConditionStructureのサブクラスにするようにPCIM集合"PolicyConditionInPolicyRule"をアップデートします。 特性のGroupNumberとConditionNegatedは現在、それらがPCIMにあったので明らかに指定されるよりむしろ引き継がれます。
NAME PolicyConditionInPolicyRule
DESCRIPTION A class representing the aggregation of
PolicyConditions by a PolicyRule.
DERIVED FROM PolicyConditionStructure
ABSTRACT FALSE
PROPERTIES GroupComponent[ref PolicyRule[0..n]]
PolicyRuleでPolicyConditionsの集合を表すNAME PolicyConditionInPolicyRule記述Aのクラス。 PolicyConditionStructureの抽象的な偽の特性のGroupComponentから、派生します。[審判PolicyRule[0..n]]
7.9. The Aggregation "PolicyConditionInPolicyCondition"
7.9. 集合"PolicyConditionInPolicyCondition"
A second subclass of PolicyConditionStructure is defined, representing the compounding of policy conditions into a higher-level policy condition.
よりハイレベルの方針状態に保険約款の合成を表して、PolicyConditionStructureの2番目のサブクラスは定義されます。
NAME PolicyConditionInPolicyCondition
DESCRIPTION A class representing the aggregation of
PolicyConditions by another PolicyCondition.
DERIVED FROM PolicyConditionStructure
ABSTRACT FALSE
PROPERTIES GroupComponent[ref CompoundPolicyCondition[0..n]]
別のPolicyConditionでPolicyConditionsの集合を表すNAME PolicyConditionInPolicyCondition記述Aのクラス。 PolicyConditionStructureの抽象的な偽の特性のGroupComponentから、派生します。[審判CompoundPolicyCondition[0..n]]
Moore Standards Track [Page 79] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[79ページ]。
7.10. The Abstract Aggregation "PolicyActionStructure"
7.10. 抽象的な集合"PolicyActionStructure"
NAME PolicyActionStructure
DESCRIPTION A class representing the aggregation of
PolicyActions by an aggregating instance.
DERIVED FROM PolicyComponent
ABSTRACT TRUE
PROPERTIES PartComponent[ref PolicyAction[0..n]]
ActionOrder
集合インスタンスでPolicyActionsの集合を表すNAME PolicyActionStructure記述Aのクラス。 PolicyComponentの抽象的な本当の特性のPartComponent[審判PolicyAction[0..n]]ActionOrderから、派生します。
The definition of the ActionOrder property appears in Section 7.8.3 of PCIM [1].
ActionOrderの特性の定義は.3セクション7.8PCIM[1]に現れます。
7.11. Update PCIM's Aggregation "PolicyActionInPolicyRule"
7.11. アップデートPCIMの集合"PolicyActionInPolicyRule"
The PCIM aggregation "PolicyActionInPolicyRule" is updated, to make it a subclass of the new abstract aggregation PolicyActionStructure. The property ActionOrder is now inherited, rather than specified explicitly as it was in PCIM.
それを新しい抽象的な集合PolicyActionStructureのサブクラスにするようにPCIM集合"PolicyActionInPolicyRule"をアップデートします。 特性のActionOrderは現在、それがPCIMにあったので明らかに指定されるよりむしろ引き継がれます。
NAME PolicyActionInPolicyRule
DESCRIPTION A class representing the aggregation of
PolicyActions by a PolicyRule.
DERIVED FROM PolicyActionStructure
ABSTRACT FALSE
PROPERTIES GroupComponent[ref PolicyRule[0..n]]
PolicyRuleでPolicyActionsの集合を表すNAME PolicyActionInPolicyRule記述Aのクラス。 PolicyActionStructureの抽象的な偽の特性のGroupComponentから、派生します。[審判PolicyRule[0..n]]
7.12. The Aggregation "PolicyActionInPolicyAction"
7.12. 集合"PolicyActionInPolicyAction"
A second subclass of PolicyActionStructure is defined, representing the compounding of policy actions into a higher-level policy action.
政策的措置の合成をよりハイレベルの政策的措置に表して、PolicyActionStructureの2番目のサブクラスは定義されます。
NAME PolicyActionInPolicyAction
DESCRIPTION A class representing the aggregation of
PolicyActions by another PolicyAction.
DERIVED FROM PolicyActionStructure
ABSTRACT FALSE
PROPERTIES GroupComponent[ref CompoundPolicyAction[0..n]]
別のPolicyActionでPolicyActionsの集合を表すNAME PolicyActionInPolicyAction記述Aのクラス。 PolicyActionStructureの抽象的な偽の特性のGroupComponentから、派生します。[審判CompoundPolicyAction[0..n]]
7.13. The Aggregation "PolicyVariableInSimplePolicyCondition"
7.13. 集合"PolicyVariableInSimplePolicyCondition"
A simple policy condition is represented as an ordered triplet
{variable, operator, value}. This aggregation provides the linkage
between a SimplePolicyCondition instance and a single PolicyVariable.
The aggregation PolicyValueInSimplePolicyCondition links the
SimplePolicyCondition to a single PolicyValue. The Operator property
of SimplePolicyCondition represents the third element of the triplet,
the operator.
簡単な方針状態は変数、オペレータが評価する命令された三つ子として表されます。 この集合はSimplePolicyConditionインスタンスと独身のPolicyVariableの間のリンケージを供給します。 集合PolicyValueInSimplePolicyConditionは独身のPolicyValueにSimplePolicyConditionをリンクします。 SimplePolicyConditionのOperatorの特性は三つ子、オペレータの3番目の原理を表します。
Moore Standards Track [Page 80] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[80ページ]。
The class definition for this aggregation is as follows:
この集合のためのクラス定義は以下の通りです:
NAME PolicyVariableInSimplePolicyCondition
DERIVED FROM PolicyComponent
ABSTRACT False
PROPERTIES GroupComponent[ref SimplePolicyCondition[0..n]]
PartComponent[ref PolicyVariable[1..1] ]
PolicyComponentの抽象的な偽の特性のGroupComponent[審判SimplePolicyCondition[0..n]]PartComponentから得られた名前PolicyVariableInSimplePolicyCondition[審判PolicyVariable[1 .1]]
The reference property "GroupComponent" is inherited from PolicyComponent, and overridden to become an object reference to a SimplePolicyCondition that contains exactly one PolicyVariable. Note that for any single instance of the aggregation class PolicyVariableInSimplePolicyCondition, this property is single- valued. The [0..n] cardinality indicates that there may be 0, 1, or more SimplePolicyCondition objects that contain any given policy variable object.
参照の特性の"GroupComponent"は、PolicyComponentから引き継がれて、ちょうど1PolicyVariableを含むSimplePolicyConditionのオブジェクト参照になるようにくつがえされます。 集合のクラスPolicyVariableInSimplePolicyConditionのどんなただ一つのインスタンスにも、この特性が評価されていた状態でただ一つであることに注意してください。 [0..n]基数は0、1以上がどんな与えられた政策変数オブジェクトも含むSimplePolicyConditionオブジェクトであったかもしれないならそこでそれを示します。
The reference property "PartComponent" is inherited from PolicyComponent, and overridden to become an object reference to a PolicyVariable that is defined within the scope of a SimplePolicyCondition. Note that for any single instance of the association class PolicyVariableInSimplePolicyCondition, this property (like all reference properties) is single-valued. The [1..1] cardinality indicates that a SimplePolicyCondition must have exactly one policy variable defined within its scope in order to be meaningful.
参照の特性の"PartComponent"は、PolicyComponentから引き継がれて、SimplePolicyConditionの範囲の中で定義されるPolicyVariableのオブジェクト参照になるようにくつがえされます。 協会のクラスPolicyVariableInSimplePolicyConditionのどんなただ一つのインスタンスにおいても、この特性(すべての参照の特性のような)が単一に評価されていることに注意してください。 [1 .1]基数は、SimplePolicyConditionにはまさに重要になるように範囲の中で定義された1つの政策変数がなければならないのを示します。
7.14. The Aggregation "PolicyValueInSimplePolicyCondition"
7.14. 集合"PolicyValueInSimplePolicyCondition"
A simple policy condition is represented as an ordered triplet
{variable, operator, value}. This aggregation provides the linkage
between a SimplePolicyCondition instance and a single PolicyValue.
The aggregation PolicyVariableInSimplePolicyCondition links the
SimplePolicyCondition to a single PolicyVariable. The Operator
property of SimplePolicyCondition represents the third element of the
triplet, the operator.
簡単な方針状態は変数、オペレータが評価する命令された三つ子として表されます。 この集合はSimplePolicyConditionインスタンスと独身のPolicyValueの間のリンケージを供給します。 集合PolicyVariableInSimplePolicyConditionは独身のPolicyVariableにSimplePolicyConditionをリンクします。 SimplePolicyConditionのOperatorの特性は三つ子、オペレータの3番目の原理を表します。
The class definition for this aggregation is as follows:
この集合のためのクラス定義は以下の通りです:
NAME PolicyValueInSimplePolicyCondition
DERIVED FROM PolicyComponent
ABSTRACT False
PROPERTIES GroupComponent[ref SimplePolicyCondition[0..n]]
PartComponent[ref PolicyValue[1..1] ]
PolicyComponentの抽象的な偽の特性のGroupComponent[審判SimplePolicyCondition[0..n]]PartComponentから得られた名前PolicyValueInSimplePolicyCondition[審判PolicyValue[1 .1]]
The reference property "GroupComponent" is inherited from PolicyComponent, and overridden to become an object reference to a SimplePolicyCondition that contains exactly one PolicyValue. Note
参照の特性の"GroupComponent"は、PolicyComponentから引き継がれて、ちょうど1PolicyValueを含むSimplePolicyConditionのオブジェクト参照になるようにくつがえされます。 注意
Moore Standards Track [Page 81] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[81ページ]。
that for any single instance of the aggregation class PolicyValueInSimplePolicyCondition, this property is single-valued. The [0..n] cardinality indicates that there may be 0, 1, or more SimplePolicyCondition objects that contain any given policy value object.
集合のクラスPolicyValueInSimplePolicyConditionのどんなただ一つのインスタンスにおいても、この特性は単一に評価されています。 [0..n]基数が、0、1があるかもしれないのを示すか、またはどんな与えられた方針も含むより多くのSimplePolicyConditionオブジェクトがオブジェクトを評価します。
The reference property "PartComponent" is inherited from PolicyComponent, and overridden to become an object reference to a PolicyValue that is defined within the scope of a SimplePolicyCondition. Note that for any single instance of the association class PolicyValueInSimplePolicyCondition, this property (like all reference properties) is single-valued. The [1..1] cardinality indicates that a SimplePolicyCondition must have exactly one policy value defined within its scope in order to be meaningful.
参照の特性の"PartComponent"は、PolicyComponentから引き継がれて、SimplePolicyConditionの範囲の中で定義されるPolicyValueのオブジェクト参照になるようにくつがえされます。 協会のクラスPolicyValueInSimplePolicyConditionのどんなただ一つのインスタンスにおいても、この特性(すべての参照の特性のような)が単一に評価されていることに注意してください。 [1 .1]基数は、SimplePolicyConditionにはまさに重要になるように範囲の中で定義された1つの保険価額がなければならないのを示します。
7.15. The Aggregation "PolicyVariableInSimplePolicyAction"
7.15. 集合"PolicyVariableInSimplePolicyAction"
A simple policy action is represented as a pair {variable, value}.
This aggregation provides the linkage between a SimplePolicyAction
instance and a single PolicyVariable. The aggregation
PolicyValueInSimplePolicyAction links the SimplePolicyAction to a
single PolicyValue.
aが変数、値を対にするとき、簡単な政策的措置は表されます。 この集合はSimplePolicyActionインスタンスと独身のPolicyVariableの間のリンケージを供給します。 集合PolicyValueInSimplePolicyActionは独身のPolicyValueにSimplePolicyActionをリンクします。
The class definition for this aggregation is as follows:
この集合のためのクラス定義は以下の通りです:
NAME PolicyVariableInSimplePolicyAction
DERIVED FROM PolicyComponent
ABSTRACT False
PROPERTIES GroupComponent[ref SimplePolicyAction[0..n]]
PartComponent[ref PolicyVariable[1..1] ]
PolicyComponentの抽象的な偽の特性のGroupComponent[審判SimplePolicyAction[0..n]]PartComponentから得られた名前PolicyVariableInSimplePolicyAction[審判PolicyVariable[1 .1]]
The reference property "GroupComponent" is inherited from PolicyComponent, and overridden to become an object reference to a SimplePolicyAction that contains exactly one PolicyVariable. Note that for any single instance of the aggregation class PolicyVariableInSimplePolicyAction, this property is single-valued. The [0..n] cardinality indicates that there may be 0, 1, or more SimplePolicyAction objects that contain any given policy variable object.
参照の特性の"GroupComponent"は、PolicyComponentから引き継がれて、ちょうど1PolicyVariableを含むSimplePolicyActionのオブジェクト参照になるようにくつがえされます。 集合のクラスPolicyVariableInSimplePolicyActionのどんなただ一つのインスタンスにおいても、この特性が単一に評価されていることに注意してください。 [0..n]基数は0、1以上がどんな与えられた政策変数オブジェクトも含むSimplePolicyActionオブジェクトであったかもしれないならそこでそれを示します。
The reference property "PartComponent" is inherited from PolicyComponent, and overridden to become an object reference to a PolicyVariable that is defined within the scope of a SimplePolicyAction. Note that for any single instance of the association class PolicyVariableInSimplePolicyAction, this property (like all reference properties) is single-valued. The [1..1] cardinality indicates that a SimplePolicyAction must have exactly one policy variable defined within its scope in order to be meaningful.
参照の特性の"PartComponent"は、PolicyComponentから引き継がれて、SimplePolicyActionの範囲の中で定義されるPolicyVariableのオブジェクト参照になるようにくつがえされます。 協会のクラスPolicyVariableInSimplePolicyActionのどんなただ一つのインスタンスにおいても、この特性(すべての参照の特性のような)が単一に評価されていることに注意してください。 [1 .1]基数は、SimplePolicyActionにはまさに重要になるように範囲の中で定義された1つの政策変数がなければならないのを示します。
Moore Standards Track [Page 82] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[82ページ]。
7.16. The Aggregation "PolicyValueInSimplePolicyAction"
7.16. 集合"PolicyValueInSimplePolicyAction"
A simple policy action is represented as a pair {variable, value}.
This aggregation provides the linkage between a SimplePolicyAction
instance and a single PolicyValue. The aggregation
PolicyVariableInSimplePolicyAction links the SimplePolicyAction to a
single PolicyVariable.
aが変数、値を対にするとき、簡単な政策的措置は表されます。 この集合はSimplePolicyActionインスタンスと独身のPolicyValueの間のリンケージを供給します。 集合PolicyVariableInSimplePolicyActionは独身のPolicyVariableにSimplePolicyActionをリンクします。
The class definition for this aggregation is as follows:
この集合のためのクラス定義は以下の通りです:
NAME PolicyValueInSimplePolicyAction
DERIVED FROM PolicyComponent
ABSTRACT False
PROPERTIES GroupComponent[ref SimplePolicyAction[0..n]]
PartComponent[ref PolicyValue[1..1] ]
PolicyComponentの抽象的な偽の特性のGroupComponent[審判SimplePolicyAction[0..n]]PartComponentから得られた名前PolicyValueInSimplePolicyAction[審判PolicyValue[1 .1]]
The reference property "GroupComponent" is inherited from PolicyComponent, and overridden to become an object reference to a SimplePolicyAction that contains exactly one PolicyValue. Note that for any single instance of the aggregation class PolicyValueInSimplePolicyAction, this property is single-valued. The [0..n] cardinality indicates that there may be 0, 1, or more SimplePolicyAction objects that contain any given policy value object.
参照の特性の"GroupComponent"は、PolicyComponentから引き継がれて、ちょうど1PolicyValueを含むSimplePolicyActionのオブジェクト参照になるようにくつがえされます。 集合のクラスPolicyValueInSimplePolicyActionのどんなただ一つのインスタンスにおいても、この特性が単一に評価されていることに注意してください。 [0..n]基数が、0、1があるかもしれないのを示すか、またはどんな与えられた方針も含むより多くのSimplePolicyActionオブジェクトがオブジェクトを評価します。
The reference property "PartComponent" is inherited from PolicyComponent, and overridden to become an object reference to a PolicyValue that is defined within the scope of a SimplePolicyAction. Note that for any single instance of the association class PolicyValueInSimplePolicyAction, this property (like all reference properties) is single-valued. The [1..1] cardinality indicates that a SimplePolicyAction must have exactly one policy value defined within its scope in order to be meaningful.
参照の特性の"PartComponent"は、PolicyComponentから引き継がれて、SimplePolicyActionの範囲の中で定義されるPolicyValueのオブジェクト参照になるようにくつがえされます。 協会のクラスPolicyValueInSimplePolicyActionのどんなただ一つのインスタンスにおいても、この特性(すべての参照の特性のような)が単一に評価されていることに注意してください。 [1 .1]基数は、SimplePolicyActionにはまさに重要になるように範囲の中で定義された1つの保険価額がなければならないのを示します。
7.17. The Association "ReusablePolicy"
7.17. 協会"ReusablePolicy"
The association ReusablePolicy makes it possible to include any subclass of the abstract class "Policy" in a ReusablePolicyContainer.
協会ReusablePolicyはReusablePolicyContainerの「方針」という抽象クラスのどんなサブクラスも含んでいるのを可能にします。
NAME ReusablePolicy
DESCRIPTION A class representing the inclusion of a reusable
policy element in a ReusablePolicyContainer.
Reusable elements may be PolicyGroups, PolicyRules,
PolicyConditions, PolicyActions, PolicyVariables,
PolicyValues, or instances of any other subclasses
of the abstract class Policy.
ReusablePolicyContainerでの再利用できる方針要素の包含を表すNAME ReusablePolicy記述Aのクラス。 再利用できる要素は、抽象クラスPolicyのいかなる他のサブクラスのPolicyGroups、PolicyRules、PolicyConditions、PolicyActions、PolicyVariables、PolicyValues、またはインスタンスであるかもしれません。
Moore Standards Track [Page 83] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[83ページ]。
DERIVED FROM PolicyInSystem ABSTRACT FALSE PROPERTIES Antecedent[ref ReusablePolicyContainer[0..1]]
PolicyInSystemの抽象的な誤った特性の前例から、派生します。[審判ReusablePolicyContainer[0 .1]]
7.18. Deprecate PCIM's "PolicyConditionInPolicyRepository"
7.18. PCIMの"PolicyConditionInPolicyRepository"を非難してください。
NAME PolicyConditionInPolicyRepository
DEPRECATED FOR ReusablePolicy
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 DEPRECATED FOR ReusablePolicy記述Aのクラス。 PolicyInSystemの抽象的な誤った特性の前例から派生している[審判PolicyRepository[0 .1]]扶養家族[審判PolicyCondition[0..n]]
7.19. Deprecate PCIM's "PolicyActionInPolicyRepository"
7.19. PCIMの"PolicyActionInPolicyRepository"を非難してください。
NAME PolicyActionInPolicyRepository
DEPRECATED FOR ReusablePolicy
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 DEPRECATED FOR ReusablePolicy記述Aのクラス。 PolicyInSystemの抽象的な誤った特性の前例から派生している[審判PolicyRepository[0 .1]]扶養家族[審判PolicyAction[0..n]]
7.20. The Association ExpectedPolicyValuesForVariable
7.20. 協会ExpectedPolicyValuesForVariable
This association links a PolicyValue object to a PolicyVariable object, modeling the set of expected values for that PolicyVariable. Using this association, a variable (instance) may be constrained to be bound- to/assigned only a set of allowed values. For example, modeling an enumerated source port variable, one creates an instance of the PolicySourcePortVariable class and associates with it the set of values (integers) representing the allowed enumeration, using appropriate number of instances of the ExpectedPolicyValuesForVariable association.
そのPolicyVariableのために期待値のセットをモデル化して、この協会はPolicyValue物をPolicyVariable物にリンクします。 この協会を使用して、1セットの許容値だけが縛られるか、または変数(例)が割り当てられるのが抑制されるかもしれません。 例えば、列挙されたソースポート変数をモデル化して、1つは、PolicySourcePortVariableのクラスの例を作成して、許容列挙を表しながら、値(整数)のセットをそれに関連づけます、ExpectedPolicyValuesForVariable協会の適切な数の例を使用して。
Note that a single variable instance may be constrained by any number of values, and a single value may be used to constrain any number of variables. These relationships are manifested by the n-to-m cardinality of the association.
ただ一つの可変例がいろいろな値によって抑制されるかもしれなくて、ただ一つの値がいろいろな変数を抑制するのに使用されるかもしれないことに注意してください。 これらの関係はnからmへの協会の基数によって表されます。
The purpose of this association is to support validation of simple policy conditions and simple policy actions, prior to their deployment to an enforcement point. This association, and the
この協会の目的は簡単な保険約款と簡単な政策的措置の合法化を支持することです、実施ポイントへの彼らの展開の前に。 そしてこの協会。
Moore Standards Track [Page 84] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[84ページ]。
PolicyValue object that it refers to, plays no role when a PDP or a PEP is evaluating a simple policy condition, or executing a simple policy action. See Section 5.8.3 for more details on this point.
PDPかPEPが簡単な方針状態を評価しているとき、役割を全く果たさないか、または簡単な政策的措置を実行して、それが示すPolicyValue物。 このポイントに関するその他の詳細に関してセクション5.8.3を見てください。
The class definition for the association is as follows:
協会のためのクラス定義は以下の通りです:
NAME ExpectedPolicyValuesForVariable
DESCRIPTION A class representing the association of a set of
expected values to a variable object.
DERIVED FROM Dependency
ABSTRACT FALSE
PROPERTIES Antecedent [ref PolicyVariable[0..n]]
Dependent [ref PolicyValue [0..n]]
1セットの期待値の協会を変数に代表するNAME ExpectedPolicyValuesForVariable記述Aのクラスが反対します。 依存の抽象的な誤った特性の前例から派生している[審判PolicyVariable[0..n]]扶養家族[審判PolicyValue[0..n]]
The reference property Antecedent is inherited from Dependency. Its type and cardinality are overridden to provide the semantics of a variable optionally having value constraints. The [0..n] cardinality indicates that any number of variables may be constrained by a given value.
参照の特性のAntecedentはDependencyから引き継がれます。 そのタイプと基数は、任意に変数の意味論を提供するために値の規制を持ちながら、くつがえされます。 [0..n]基数は、いろいろな変数が与えられた値によって抑制されるかもしれないのを示します。
The reference property "Dependent" is inherited from Dependency, and overridden to become an object reference to a PolicyValue representing the values that a particular PolicyVariable can have. The [0..n] cardinality indicates that a given policy variable may have 0, 1 or more than one PolicyValues defined to model the set(s) of values that the policy variable can take.
特性の「扶養家族」という参照は、Dependencyから引き継がれて、特定のPolicyVariableが持つことができる値を表すPolicyValueの物の参照になるように優越されます。 [0..n]基数が、与えられた政策変数には0、1があるかもしれないのを示すか、または1PolicyValuesが政策変数が取ることができる値のセットをモデルと定義しました。
7.21. The Aggregation "ContainedDomain"
7.21. 集合"ContainedDomain"
The aggregation ContainedDomain provides a means of nesting of one ReusablePolicyContainer inside another one. The aggregation is defined at the level of ReusablePolicyContainer's superclass, AdminDomain, to give it applicability to areas other than Core Policy.
集合ContainedDomainは別の1つで1ReusablePolicyContainerの巣篭もりの手段を提供します。 集合は、Core Policy以外の領域への適用性をそれに与えるためにReusablePolicyContainerの「スーパー-クラス」、AdminDomainのレベルで定義されます。
NAME ContainedDomain
DESCRIPTION A class representing the aggregation of lower level
administrative domains by a higher-level
AdminDomain.
DERIVED FROM SystemComponent
ABSTRACT FALSE
PROPERTIES GroupComponent[ref AdminDomain [0..n]]
PartComponent[ref AdminDomain [0..n]]
よりハイレベルのAdminDomainで下のレベルの管理ドメインの集合を表すNAME ContainedDomain記述Aのクラス。 SystemComponentの抽象的な偽の特性のGroupComponent[審判AdminDomain[0..n]]PartComponentから、派生します。[審判AdminDomain[0..n]]
Moore Standards Track [Page 85] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[85ページ]。
7.22. Deprecate PCIM's "PolicyRepositoryInPolicyRepository"
7.22. PCIMの"PolicyRepositoryInPolicyRepository"を非難してください。
NAME PolicyRepositoryInPolicyRepository
DEPRECATED FOR ContainedDomain
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]]
よりハイレベルのPolicyRepositoryでPolicyRepositoriesの集合を表すNAME PolicyRepositoryInPolicyRepository DEPRECATED FOR ContainedDomain記述Aのクラス。 SystemComponentの抽象的な偽の特性のGroupComponent[審判PolicyRepository[0..n]]PartComponentから、派生します。[審判PolicyRepository[0..n]]
7.23. The Aggregation "EntriesInFilterList"
7.23. 集合"EntriesInFilterList"
This aggregation is a specialization of the Component aggregation; it is used to define a set of filter entries (subclasses of FilterEntryBase) that are aggregated by a FilterList.
この集合はComponent集合の専門化です。 それは、FilterListによって集められる1セットのフィルタエントリー(FilterEntryBaseのサブクラス)を定義するのに使用されます。
The cardinalities of the aggregation itself are 0..1 on the FilterList end, and 0..n on the FilterEntryBase end. Thus in the general case, a filter entry can exist without being aggregated into any FilterList. However, the only way a filter entry can figure in the PCIMe model is by being aggregated into a FilterList by this aggregation.
集合自体の基数は0です。1 FilterListエンド、および0に関して。FilterEntryBaseのnは終わります。 したがって、一般的な場合では、どんなFilterListにも集められないで、フィルタエントリーは存在できます。 しかしながら、フィルタエントリーがPCIMeモデルを含むことができる唯一の方法はこの集合によってFilterListに集めることにされます。
The class definition for the aggregation is as follows:
集合のためのクラス定義は以下の通りです:
NAME EntriesInFilterList
DESCRIPTION An aggregation used to define a set of
filter entries (subclasses of
FilterEntryBase) that are aggregated by
a particular FilterList.
DERIVED FROM Component
ABSTRACT False
PROPERTIES GroupComponent[ref
FilterList[0..1]],
PartComponent[ref
FilterEntryBase[0..n],
EntrySequence
NAME EntriesInFilterList記述An集合は以前はよく特定のFilterListによって集められる1セットのフィルタエントリー(FilterEntryBaseのサブクラス)を定義していました。 コンポーネントの抽象的な偽の特性のGroupComponent[審判FilterList[0 .1]]、PartComponentから派生する、[審判FilterEntryBase[0..n]、EntrySequence
7.23.1. The Reference GroupComponent
7.23.1. 参照GroupComponent
This property is overridden in this aggregation to represent an object reference to a FilterList object (instead of to the more generic ManagedSystemElement object defined in its superclass). It also restricts the cardinality of the aggregate to 0..1 (instead of the more generic 0-or-more), representing the fact that a filter entry always exists within the context of at most one FilterList.
この特性は、FilterList物(「スーパー-クラス」で定義されたより一般的なManagedSystemElement物の代わりに)の物の参照を表すためにこの集合で無視されます。 また、それは集合の基数を0に制限します。フィルタエントリーが高々1FilterListの文脈の中にいつも存在しているという事実を表す1(より一般的な0以上の代わりに)。
Moore Standards Track [Page 86] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[86ページ]。
7.23.2. The Reference PartComponent
7.23.2. 参照PartComponent
This property is overridden in this aggregation to represent an object reference to a FilterEntryBase object (instead of to the more generic ManagedSystemElement object defined in its superclass). This object represents a single filter entry, which may be aggregated with other filter entries to form the FilterList.
この特性は、FilterEntryBase物(「スーパー-クラス」で定義されたより一般的なManagedSystemElement物の代わりに)の物の参照を表すためにこの集合で無視されます。 この物は単一のフィルタエントリーを表します。(それは、他のフィルタエントリーで集められて、)FilterListを形成するかもしれません。
7.23.3. The Property EntrySequence
7.23.3. 特性のEntrySequence
An unsigned 16-bit integer indicating the order of the filter entry relative to all others in the FilterList. The default value '0' indicates that order is not significant, because the entries in this FilterList are ANDed together.
FilterListのすべての他のものに比例してフィルタエントリーの注文を示す無記名の16ビットの整数。 このFilterListのエントリーが一緒にANDedであるので、デフォルト値'0'は、オーダーが重要でないことを示します。
7.24. The Aggregation "ElementInPolicyRoleCollection"
7.24. 集合"ElementInPolicyRoleCollection"
The following aggregation is used to associate ManagedElements with a PolicyRoleCollection object that represents a role played by these ManagedElements.
以下の集合は、これらのManagedElementsによって果たされた役割を表すPolicyRoleCollection物にManagedElementsを関連づけるのに使用されます。
NAME ElementInPolicyRoleCollection
DESCRIPTION A class representing the inclusion of a
ManagedElement in a collection, specified as
having a given role. All the managed elements
in the collection share the same role.
DERIVED FROM MemberOfCollection
ABSTRACT FALSE
PROPERTIES Collection[ref PolicyRoleCollection [0..n]]
Member[ref ManagedElement [0..n]]
与えられた役割を持っていると指定された収集でのManagedElementの包含を表すNAME ElementInPolicyRoleCollection記述Aのクラス。 収集におけるすべての管理された要素が同じ役割を共有します。 MemberOfCollection抽象的な誤った特性の収集[審判PolicyRoleCollection[0..n]]メンバーから、派生します。[審判ManagedElement[0..n]]
7.25. The Weak Association "PolicyRoleCollectionInSystem"
7.25. 弱い協会"PolicyRoleCollectionInSystem"
A PolicyRoleCollection is defined within the scope of a System. This association links a PolicyRoleCollection to the System in whose scope it is defined.
PolicyRoleCollectionはSystemの範囲の中で定義されます。 この協会はそれが範囲で定義されるSystemにPolicyRoleCollectionをリンクします。
When associating a PolicyRoleCollection with a System, this should be done consistently with the system that scopes the policy rules/groups that are applied to the resources in that collection. A PolicyRoleCollection is associated with the same system as the applicable PolicyRules and/or PolicyGroups, or to a System higher in the tree formed by the SystemComponent association.
PolicyRoleCollectionをSystemに関連づけるとき、その収集におけるリソースに適用される政策ルール/グループを見るシステムで一貫してこれをするべきです。 PolicyRoleCollectionは適切なPolicyRules、そして/または、PolicyGroupsか、Systemへの同じシステムにSystemComponent協会によって形成された木で、より高く関連しています。
The class definition for the association is as follows:
協会のためのクラス定義は以下の通りです:
Moore Standards Track [Page 87] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[87ページ]。
NAME PolicyRoleCollectionInSystem
DESCRIPTION A class representing the fact that a
PolicyRoleCollection is defined within the scope of
a System.
DERIVED FROM Dependency
ABSTRACT FALSE
PROPERTIES Antecedent[ref System[1..1]]
Dependent[ref PolicyRoleCollection[weak]]
PolicyRoleCollectionがSystemの範囲の中で定義されるという事実を表すNAME PolicyRoleCollectionInSystem記述Aのクラス。 依存の抽象的な誤った特性の前例から派生している[審判システム[1 .1]]扶養家族[審判PolicyRoleCollection[弱い]]
The reference property Antecedent is inherited from Dependency, and overridden to become an object reference to a System, and to restrict its cardinality to [1..1]. It serves as an object reference to a System that provides a scope for one or more PolicyRoleCollections. Since this is a weak association, the cardinality for this object reference is always 1, that is, a PolicyRoleCollection is always defined within the scope of exactly one System.
参照の特性のAntecedentは、Dependencyから引き継がれて、Systemの物の参照になって、基数を[1 .1]に制限するためにくつがえされます。 それは1PolicyRoleCollectionsに範囲を供給するSystemの物の参照として機能します。 これが弱い協会であるので、いつもこの物の参照のための基数が1である、すなわち、PolicyRoleCollectionはちょうど1Systemの範囲の中でいつも定義されます。
The reference property Dependent is inherited from Dependency, and overridden to become an object reference to a PolicyRoleCollection defined within the scope of a System. Note that for any single instance of the association class PolicyRoleCollectionInSystem, 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 PolicyRoleCollections defined within its scope.
参照の特性のDependentは、Dependencyから引き継がれて、Systemの範囲の中で定義されたPolicyRoleCollectionの物の参照になるようにくつがえされます。 協会のクラスPolicyRoleCollectionInSystemのどんなただ一つの例においても、この特性(すべてのReferenceの特性のような)が単一に評価されていることに注意してください。 [0..n]基数は、与えられたSystemが0、1、または範囲の中で定義された1PolicyRoleCollectionsを持っているかもしれないのを示します。
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専務に情報を記述してください。
Moore Standards Track [Page 88] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[88ページ]。
9. Acknowledgements
9. 承認
The starting point for this document was PCIM itself [1], and the first three submodels derived from it [11], [12], [13]. The authors of these documents created the extensions to PCIM, and asked the questions about PCIM, that are reflected in PCIMe.
このドキュメントのための出発点、PCIM自身は[1]でした、そして、最初の3「副-モデル」はそれから[11]を引き出しました、[12]、[13]。 これらのドキュメントの作者は、拡大をPCIMに作成して、PCIMに関して質問して、それはPCIMeに反映されます。
10. Contributors
10. 貢献者
This document includes text written by a number of authors (including the editor), that was subsequently merged by the editor. The following people contributed text to this document:
このドキュメントは多くの作者によって書かれたテキストを含んで(エディタを含んでいて)、それは次に、エディタによって合併されました。 以下の人々はこのドキュメントにテキストを寄付しました:
Lee Rafalow IBM Corporation, BRQA/501 4205 S. Miami Blvd. Research Triangle Park, NC 27709
BRQA/5014205秒間リーRafalow IBM社、マイアミBlvd. NC リサーチトライアングル公園、27709
Phone: +1 919-254-4455 Fax: +1 919-254-6243 EMail: rafalow@us.ibm.com
以下に電話をしてください。 +1 919-254-4455Fax: +1 919-254-6243 メールしてください: rafalow@us.ibm.com
Yoram Ramberg Cisco Systems 4 Maskit Street Herzliya Pituach, Israel 46766
ヨラムランベルクシスコシステムズ4Maskit Pituach、通りヘルズリヤイスラエル46766
Phone: +972-9-970-0081 Fax: +972-9-970-0219 EMail: yramberg@cisco.com
以下に電話をしてください。 +972-9-970-0081 Fax: +972-9-970-0219 メールしてください: yramberg@cisco.com
Yoram Snir Cisco Systems 4 Maskit Street Herzliya Pituach, Israel 46766
ヨラムSnirシスコシステムズ4Maskit Pituach、通りヘルズリヤイスラエル46766
Phone: +972-9-970-0085 Fax: +972-9-970-0366 EMail: ysnir@cisco.com
以下に電話をしてください。 +972-9-970-0085 Fax: +972-9-970-0366 メールしてください: ysnir@cisco.com
Moore Standards Track [Page 89] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[89ページ]。
Andrea Westerinen Cisco Systems Building 20 725 Alder Drive Milpitas, CA 95035
アンドレア・Westerinenシスコシステムズビル20 725ハンノキDriveミルピタス、カリフォルニア 95035
Phone: +1-408-853-8294 Fax: +1-408-527-6351 EMail: andreaw@cisco.com
以下に電話をしてください。 +1-408-853-8294 Fax: +1-408-527-6351 メールしてください: andreaw@cisco.com
Ritu Chadha Telcordia Technologies MCC 1J-218R 445 South Street Morristown NJ 07960.
Ritu Chadha Telcordia TechnologiesのMCC 1J-218R445の南通りモリスタウンニュージャージー 07960。
Phone: +1-973-829-4869 Fax: +1-973-829-5889 EMail: chadha@research.telcordia.com
以下に電話をしてください。 +1-973-829-4869 Fax: +1-973-829-5889 メールしてください: chadha@research.telcordia.com
Marcus Brunner NEC Europe Ltd. C&C Research Laboratories Adenauerplatz 6 D-69115 Heidelberg, Germany
マーカスブルンナーNECヨーロッパ株式会社CとC研究所Adenauerplatz6D-69115ハイデルベルグ(ドイツ)
Phone: +49 (0)6221 9051129 Fax: +49 (0)6221 9051155 EMail: brunner@ccrle.nec.de
以下に電話をしてください。 +49 (0)6221 9051129Fax: +49 (0) 6221 9051155はメールされます: brunner@ccrle.nec.de
Ron Cohen Ntear LLC
ロンコーエンNtear LLC
EMail: ronc@ntear.com
メール: ronc@ntear.com
John Strassner INTELLIDEN, Inc. 90 South Cascade Avenue Colorado Springs, CO 80903
ジョンStrassner INTELLIDEN Inc.90の南滝のアベニューコロラド・スプリングス、CO 80903
Phone: +1-719-785-0648 EMail: john.strassner@intelliden.com
以下に電話をしてください。 +1-719-785-0648 メールしてください: john.strassner@intelliden.com
Moore Standards Track [Page 90] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[90ページ]。
11. Security Considerations
11. セキュリティ問題
The Policy Core Information Model (PCIM) [1] describes the general security considerations related to the general core policy model. The extensions defined in this document do not introduce any additional considerations related to security.
Policy Core情報Model(PCIM)[1]は一般的なコア政策モデルと関係がある総合証券問題について説明します。 本書では定義された拡大はセキュリティに関連するどんな追加問題も紹介しません。
12. Normative References
12. 引用規格
[1] Moore, B., Ellesson, E., Strassner, J. and A. Westerinen,
"Policy Core Information Model -- Version 1 Specification", RFC
3060, February 2001.
[1] ムーア、B.、Ellesson、E.、Strassner、J.、およびA.Westerinen、「方針コア情報はモデル化されます--バージョン1仕様」、RFC3060、2001年2月。
[2] Distributed Management Task Force, Inc., "DMTF Technologies: CIM
Standards CIM Schema: Version 2.5", available at
http://www.dmtf.org/standards/cim_schema_v25.php.
[2] 分散管理特別委員会Inc.、「DMTF技術:」 CIM規格CIM図式: http://www.dmtf.org/standards/cim_schema_v25.php で利用可能なバージョン2.5インチ。
[3] Distributed Management Task Force, Inc., "Common Information
Model (CIM) Specification: Version 2.2", June 14, 1999,
available at
http://www.dmtf.org/standards/documents/CIM/DSP0004.pdf.
[3] 分散管理特別委員会Inc.、「一般的な情報は(CIM)仕様をモデル化します」。 1999年6月14日に http://www.dmtf.org/standards/documents/CIM/DSP0004.pdf で利用可能なバージョン2.2インチ。
[4] Mockapetris, P., "Domain Names - implementation and
specification", STD 13, RFC 1035, November 1987.
[4]Mockapetris、P.、「ドメインNames--、実現と仕様、」、STD13、RFC1035、11月1987日
[5] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax Definitions",
RFC 2252, December 1997.
[5] ウォール、M.、Coulbeck、A.、ハウズ、T.、およびS.Kille、「軽量のディレクトリアクセスは(v3)について議定書の中で述べます」。 「属性構文定義」、RFC2252、1997年12月。
[6] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[6] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[7] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[7]HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC2373、1998年7月。
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[8] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
13. Informative References
13. 有益な参照
[9] Hovey, R. and S. Bradner, "The Organizations Involved in the
IETF Standards Process", BCP 11, RFC 2028, October 1996.
[9] ハービとR.とS.ブラドナー、「IETF標準化過程にかかわる組織」、BCP11、RFC2028、1996年10月。
[10] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M.,
Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and
Waldbusser, "Terminology for Policy-Based Management", RFC 3198,
November 2001.
[10]WesterinenとA.とSchnizleinとJ.とStrassnerとJ.とScherlingとM.、クインとB.とハーツォグとS.とHuynhとA.とカールソンとM.とペリーとJ.とWaldbusser、「方針を拠点とする管理のための用語」RFC3198(2001年11月)。
Moore Standards Track [Page 91] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[91ページ]。
[11] Snir, Y., and Y. Ramberg, J. Strassner, R. Cohen, "Policy QoS
Information Model", Work in Progress.
[11] Snir、Y.とY.ランベルク、J.Strassner、R.コーエン、「方針QoS情報モデル」は進行中で働いています。
[12] Jason, J., and L. Rafalow, E. Vyncke, "IPsec Configuration
Policy Model", Work in Progress.
[12] ジェイソン、J.とL.Rafalow、E.Vyncke、「IPsec構成政策モデル」、進行中で、働いてください。
[13] Chadha, R., and M. Brunner, M. Yoshida, J. Quittek, G.
Mykoniatis, A. Poylisher, R. Vaidyanathan, A. Kind, F.
Reichmeyer, "Policy Framework MPLS Information Model for QoS and
TE", Work in Progress.
[13] Chadha、R.とM.ブルンナー、M.吉田、J.Quittek、G.Mykoniatis、A.Poylisher、R.Vaidyanathan、A.種類、「QoSとTeのための方針枠組みのMPLS情報モデル」というF.Reichmeyerは進行中で働いています。
[14] S. Waldbusser, and J. Saperia, T. Hongal, "Policy Based
Management MIB", Work in Progress.
[14] T.Hongal、「方針のベースの管理MIB」というS.Waldbusser、およびJ.Saperiaは進行中で働いています。
[15] B. Moore, and D. Durham, J. Halpern, J. Strassner, A.
Westerinen, W. Weiss, "Information Model for Describing Network
Device QoS Datapath Mechanisms", Work in Progress.
[15] B.ムーア、およびD.ダラム、J.アルペルン、J.Strassner、A.Westerinen、「ネットワーク装置QoS Datapathメカニズムについて説明するための情報モデル」というW.ウィスは進行中で働いています。
Author's Address
作者のアドレス
Bob Moore IBM Corporation, BRQA/501 4205 S. Miami Blvd. Research Triangle Park, NC 27709
BRQA/5014205秒間ボブムーア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
Moore Standards Track [Page 92] RFC 3460 PCIM Extensions January 2003
ムーアStandardsはPCIM拡大2003年1月にRFC3460を追跡します[92ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 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 Standards Track [Page 93]
ムーア標準化過程[93ページ]
一覧
スポンサーリンク
