--- 1/draft-ietf-supa-generic-policy-info-model-00.txt 2016-07-19 05:16:12.795436690 -0700 +++ 2/draft-ietf-supa-generic-policy-info-model-01.txt 2016-07-19 05:16:13.051443082 -0700 @@ -1,19 +1,20 @@ Network Working Group J. Strassner Internet Draft Huawei Technologies Intended status: Standard Track J. Halpern -Expires: December 21, 2016 Ericsson - June 21, 2016 +Expires: January 19, 2017 S. van der Meer + Ericsson + July 19, 2016 Generic Policy Information Model for Simplified Use of Policy Abstractions (SUPA) - draft-ietf-supa-generic-policy-info-model-00 + draft-ietf-supa-generic-policy-info-model-01 Abstract This document defines an information model for representing policies using a common extensible framework that is independent of language, protocol, repository. It is also independent of the level of abstraction of the content and meaning of a policy. Status of this Memo @@ -24,21 +25,21 @@ Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on December 21, 2016. + This Internet-Draft will expire on January 19, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -48,49 +49,50 @@ Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Overview ....................................................... 9 1.1. Introduction .............................................. 9 1.2. Changes Since Version -03 ................................ 11 2. Conventions Used in This Document ............................. 11 3. Terminology ................................................... 12 - 3.1. Acronyms .................................................. 12 - 3.2. Definitions ............................................... 12 - 3.2.1. Core Terminology ..................................... 12 + 3.1. Acronyms ................................................. 12 + 3.2. Definitions .............................................. 12 + 3.2.1. Core Terminology .................................... 12 3.2.1.1. Information Model .............................. 12 3.2.1.2. Data Model ..................................... 13 - 3.2.1.3. Abstract Class ................................. 13 - 3.2.1.4. Concrete Class ................................. 13 - 3.2.1.5. Container ...................................... 13 - 3.2.1.6. PolicyContainer ................................ 13 - 3.2.2. Policy Terminology ................................... 14 + 3.2.1.3. Class .......................................... 13 + 3.2.1.3.1. Abstract Class ............................... 13 + 3.2.1.3.2. Concrete Class ............................... 13 + 3.2.1.4. Container ...................................... 13 + 3.2.1.5. PolicyContainer ................................ 13 + 3.2.2. Policy Terminology .................................. 14 3.2.2.1. SUPAPolicyObject ............................... 14 3.2.2.2. SUPAPolicy ..................................... 14 3.2.2.3. SUPAPolicyClause ............................... 14 - 3.2.2.4. SUPAECAPolicyRule .............................. 14 + 3.2.2.4. SUPAECAPolicyRule .............................. 15 3.2.2.5. SUPAMetadata ................................... 15 3.2.2.6. SUPAPolicyTarget ............................... 15 3.2.2.7. SUPAPolicySource ............................... 15 - 3.2.3. Modeling Terminology ................................. 16 + 3.2.3. Modeling Terminology ................................ 16 3.2.3.1. Inheritance .................................... 16 3.2.3.2. Relationship ................................... 16 - 3.2.3.3. Association .................................... 16 - 3.2.3.4. Aggregation .................................... 16 + 3.2.3.3. Association .................................... 17 + 3.2.3.4. Aggregation .................................... 17 3.2.3.5. Composition .................................... 17 3.2.3.6. Association Class .............................. 17 - 3.2.3.7. Multiplicity ................................... 17 - 3.2.3.8. Navigability ................................... 17 + 3.2.3.7. Multiplicity ................................... 18 + 3.2.3.8. Navigability ................................... 18 3.3. Symbology ................................................ 18 3.3.1. Inheritance ......................................... 18 - 3.3.2. Association ......................................... 18 + 3.3.2. Association ......................................... 19 3.3.3. Aggregation ......................................... 19 3.3.4. Composition ......................................... 19 3.3.5. Association Class ................................... 19 3.3.6. Abstract vs. Concrete Classes ....................... 20 4. Policy Abstraction Architecture ............................... 21 4.1. Motivation ............................................... 22 4.2. SUPA Approach ............................................ 23 Table of Contents (continued) @@ -113,29 +115,29 @@ 4.4.7.1. Motivation ..................................... 39 4.4.7.2. Design Approach ................................ 40 4.4.7.2.1. Policies and Actors ....................... 42 4.4.7.2.2. Deployment vs. Execution of Policies ...... 43 4.4.7.2.3. Using SUPAMetadata for Policy Deployment and Execution ............................. 43 4.4.7.3. Structure of SUPAPolicyMetadata ................ 44 4.5. Advanced Features ........................................ 47 4.5.1. Policy Grouping ..................................... 47 4.5.2. Policy Rule Nesting ................................. 47 -5. GPIM Model ..................................................... 48 - 5.1. Overview .................................................. 48 - 5.2. The Abstract Class "SUPAPolicyObject" ..................... 49 - 5.2.1. SUPAPolicyObject Attributes .......................... 50 +5. GPIM Model .................................................... 48 + 5.1. Overview ................................................. 48 + 5.2. The Abstract Class "SUPAPolicyObject" .................... 49 + 5.2.1. SUPAPolicyObject Attributes ......................... 50 5.2.1.1. Object Identifiers ............................. 50 - 5.2.1.2. The Attribute "supaPolObjIDContent" ............. 51 - 5.2.1.3. The Attribute "supaPolObjIDEncoding" ............ 51 - 5.2.1.4. The Attribute "supaPolicyDescription" ........... 51 - 5.2.1.5. The Attribute "supaPolicyName" .................. 51 + 5.2.1.2. The Attribute "supaPolObjIDContent" ............ 51 + 5.2.1.3. The Attribute "supaPolObjIDEncoding" ........... 51 + 5.2.1.4. The Attribute "supaPolicyDescription" .......... 51 + 5.2.1.5. The Attribute "supaPolicyName" ................. 51 5.2.2. SUPAPolicy Relationships ............................ 52 5.2.2.1. The Relationship "SUPAHasPolicyMetadata" ....... 52 5.2.2.2. The Association Class "SUPAHasPolicyMetadataDetail" .................. 52 5.3. The Abstract Class "SUPAPolicyStructure" ................. 52 5.3.1. SUPAPolicyStructure Attributes ...................... 53 5.3.1.1. The Attribute "supaPolAdminStatus" ............. 53 5.3.1.2. The Attribute "supaPolContinuumLevel" .......... 53 5.3.1.3. The Attribute "supaPolDeployStatus" ............ 54 5.3.1.4. The Attribute "supaPolExecStatus" .............. 54 @@ -169,194 +171,195 @@ 5.4.2. SUPAPolicyComponentStructure Relationships .......... 59 5.5. The Abstract Class "SUPAPolicyClause" .................... 59 5.5.1. SUPAPolicyClause Attributes ......................... 60 5.5.1.1. The Attribute "supaPolClauseExecStatus" ........ 60 5.5.2. SUPAPolicyClause Relationships ...................... 61 5.6. The Concrete Class "SUPAEncodedClause" ................... 61 5.6.1. SUPAEncodedClause Attributes ........................ 61 5.6.1.1. The Attribute "supaEncodedClauseContent" ....... 61 5.6.1.2. The Attribute "supaEncodedClauseEncoding" ...... 61 5.6.1.3. The Attribute "supaEncodedClauseResponse" ...... 62 + 5.6.1.4. The Attribute "supaEncodedClauseLang[0..n]" .... 62 + 5.6.1.5. The Attribute "supaEncodedClauseResponse" ...... 62 5.6.2. SUPAEncodedClause Relationships ..................... 62 5.7. The Abstract Class "SUPAPolicyComponentDecorator" ........ 62 5.7.1. The Decorator Pattern ............................... 63 5.7.2. SUPAPolicyComponentDecorator Attributes ............. 64 - 5.7.2.1. The Attribute "supaPolCompConstraintEncoding" .. 64 - 5.7.2.2. The Attribute "supaAPolCompConstraint[0..n]" ... 64 + 5.7.2.1. The Attribute "supaPolCompConstraintEncoding" .. 65 + 5.7.2.2. The Attribute "supaAPolCompConstraint[0..n]" ... 65 5.7.3. SUPAPolicyComponentDecorator Relationships .......... 65 5.7.3.1. The Aggregation - "SUPAHasDecoratedPolicyComponent" .............. 65 + "SUPAHasDecoratedPolicyComponent" .............. 66 5.7.3.2. The Association Class - "SUPAHasDecoratedPolicyComponentDetail" ........ 65 + "SUPAHasDecoratedPolicyComponentDetail" ........ 66 5.7.3.2.1. The Attribute - "supaDecoratedConstraintEncoding" ......... 65 + "supaDecoratedConstraintEncoding" ......... 66 5.7.3.2.2. The Attribute - "supaDecoratedConstraint[0..n]" ........... 66 - 5.7.4. Illustration of Constraints in the Decorator Pattern 66 + "supaDecoratedConstraint[0..n]" ........... 67 Table of Contents (continued) - 5.8. The Abstract Class "SUPAPolicyTerm" ...................... 67 - 5.8.1. SUPAPolicyTerm Attributes ........................... 68 - 5.8.1.1. The Attribute "supaPolTermIsNegated" ........... 68 - 5.8.2. SUPAPolicyTerm Relationships ........................ 68 - 5.9. The Concrete Class "SUPAPolicyVariable" .................. 68 - 5.9.1. Problems with the RFC3460 Version of PolicyVariable . 69 - 5.9.2. SUPAPolicyVariable Attributes ....................... 69 - 5.9.2.1. The Attribute "supaPolVarName" ................. 69 - 5.9.3. SUPAPolicyVariable Relationships .................... 69 - 5.10. The Concrete Class "SUPAPolicyOperator" ................. 69 - 5.10.1. Problems with the RFC3460 Version .................. 70 - 5.10.2. SUPAPolicyOperator Attributes ...................... 70 - 5.10.2.1. The Attribute "supaPolOpType" ................. 70 - 5.10.3. SUPAPolicyOperator Relationships ................... 70 - 5.11. The Concrete Class "SUPAPolicyValue" .................... 71 - 5.11.1. Problems with the RFC3460 Version of PolicyValue ... 71 - 5.11.2. SUPAPolicyValue Attributes ......................... 71 - 5.11.2.1. The Attribute "supaPolValContent[0..n]" ....... 71 - 5.11.2.2. The Attribute "supaPolValEncoding" ............ 72 - 5.11.3. SUPAPolicyValue Relationships ...................... 72 - 5.12. The Concrete Class "SUPAGenericDecoratedComponent" ...... 72 - 5.12.1. SUPAGenericDecoratedComponent Attributes ........... 73 + 5.7.4. Illustration of Constraints in the Decorator Pattern 67 + 5.8. The Abstract Class "SUPAPolicyTerm" ...................... 68 + 5.8.1. SUPAPolicyTerm Attributes ........................... 69 + 5.8.1.1. The Attribute "supaPolTermIsNegated" ........... 69 + 5.8.2. SUPAPolicyTerm Relationships ........................ 69 + 5.9. The Concrete Class "SUPAPolicyVariable" .................. 69 + 5.9.1. Problems with the RFC3460 Version of PolicyVariable . 70 + 5.9.2. SUPAPolicyVariable Attributes ....................... 70 + 5.9.2.1. The Attribute "supaPolVarName" ................. 70 + 5.9.3. SUPAPolicyVariable Relationships .................... 70 + 5.10. The Concrete Class "SUPAPolicyOperator" ................. 70 + 5.10.1. Problems with the RFC3460 Version .................. 71 + 5.10.2. SUPAPolicyOperator Attributes ...................... 71 + 5.10.2.1. The Attribute "supaPolOpType" ................. 71 + 5.10.3. SUPAPolicyOperator Relationships ................... 71 + 5.11. The Concrete Class "SUPAPolicyValue" .................... 72 + 5.11.1. Problems with the RFC3460 Version of PolicyValue ... 72 + 5.11.2. SUPAPolicyValue Attributes ......................... 72 + 5.11.2.1. The Attribute "supaPolValContent[0..n]" ....... 72 + 5.11.2.2. The Attribute "supaPolValEncoding" ............ 73 + 5.11.3. SUPAPolicyValue Relationships ...................... 73 + 5.12. The Concrete Class "SUPAGenericDecoratedComponent" ...... 73 + 5.12.1. SUPAGenericDecoratedComponent Attributes ........... 74 5.12.1.1. The Attribute - "supaVendorDecoratedCompContent[0..n]" ......... 73 - 5.12.1.2. The Attribute "supaVendorDecoratedCompEncoding" 73 - 5.12.2. SUPAGenericDecoratedComponent Relationships ........ 73 - 5.13. The Concrete Class "SUPAPolicyCollection" ............... 74 - 5.13.1. Motivation ......................................... 74 - 5.13.2. Solution ........................................... 74 - 5.13.3. SUPAPolicyCollection Attributes .................... 75 - 5.13.3.1. The Attribute "supaPolCollectionContent[0..n]" 75 - 5.13.3.2. The Attribute "supaPolCollectionEncoding" ..... 75 - 5.13.3.3. The Attribute "supaPolCollectionFunction" ..... 75 - 5.13.3.4. The Attribute "supaPolCollectionIsOrdered" .... 75 - 5.13.3.5. The Attribute "supaPolCollectionType" ......... 76 - 5.13.4. SUPAPolicyCollection Relationships ................. 77 - 5.14. The Concrete Class "SUPAPolicySource" ..................... 77 - 5.14.1. SUPAPolicySource Attributes ........................ 77 - 5.14.2. SUPAPolicySource Relationships ..................... 77 - 5.15. The Concrete Class "SUPAPolicyTarget" ................... 77 - 5.15.1. SUPAPolicyTarget Attributes ........................ 78 - 5.15.2. SUPAPolicyTarget Relationships ..................... 78 + "supaVendorDecoratedCompContent[0..n]" ........ 74 + 5.12.1.2. The Attribute "supaVendorDecoratedCompEncoding" 74 + 5.12.2. SUPAGenericDecoratedComponent Relationships ........ 74 + 5.13. The Concrete Class "SUPAPolicyCollection" ............... 75 + 5.13.1. Motivation ......................................... 75 + 5.13.2. Solution ........................................... 75 + 5.13.3. SUPAPolicyCollection Attributes .................... 76 + 5.13.3.1. The Attribute "supaPolCollectionContent[0..n]" 76 + 5.13.3.2. The Attribute "supaPolCollectionEncoding" ..... 76 + 5.13.3.3. The Attribute "supaPolCollectionFunction" ..... 76 + 5.13.3.4. The Attribute "supaPolCollectionIsOrdered" .... 76 + 5.13.3.5. The Attribute "supaPolCollectionType" ......... 77 + 5.13.4. SUPAPolicyCollection Relationships ................. 78 + 5.14. The Concrete Class "SUPAPolicySource" .................... 78 + 5.14.1. SUPAPolicySource Attributes ........................ 78 + 5.14.2. SUPAPolicySource Relationships ..................... 78 + 5.15. The Concrete Class "SUPAPolicyTarget" ................... 78 + 5.15.1. SUPAPolicyTarget Attributes ........................ 79 + 5.15.2. SUPAPolicyTarget Relationships ..................... 79 Table of Contents (continued) - 5.16. The Abstract Class "SUPAPolicyMetadata" ................. 78 - 5.16.1. SUPAPolicyMetadata Attributes ...................... 79 - 5.16.1.1. The Attribute "supaPolMetadataDescription" .... 79 - 5.16.1.2. The Attribute "supaPolMetadataIDContent" ...... 79 - 5.16.1.3. The Attribute "supaPolMetadataIDEncoding" ..... 79 - 5.16.1.4. The Attribute "supaPolMetadataName" ........... 80 - 5.16.2. SUPAPolicyMetadata Relationships ................... 80 - 5.16.2.1. The Aggregation "SUPAHasPolicyMetadata" ....... 80 - 5.16.2.2. The Abstract Class - "SUPAHasPolicyMetadataDetail" ................. 80 + 5.16. The Abstract Class "SUPAPolicyMetadata" ................. 79 + 5.16.1. SUPAPolicyMetadata Attributes ...................... 80 + 5.16.1.1. The Attribute "supaPolMetadataDescription" .... 80 + 5.16.1.2. The Attribute "supaPolMetadataIDContent" ...... 80 + 5.16.1.3. The Attribute "supaPolMetadataIDEncoding" ..... 80 + 5.16.1.4. The Attribute "supaPolMetadataName" ........... 81 + 5.16.2. SUPAPolicyMetadata Relationships ................... 81 + 5.16.2.1. The Aggregation "SUPAHasPolicyMetadata" ....... 81 + 5.16.2.2. The Association Class + "SUPAHasPolicyMetadataDetail" ................. 81 5.16.2.2.1. The Attribute - "supaPolMetadataIsApplicable" ............ 80 + "supaPolMetadataIsApplicable" ............ 81 5.16.2.2.2. The Attribute - "supaPolMetadataConstraintEncoding" ...... 81 + "supaPolMetadataConstraintEncoding" ...... 82 5.16.2.2.3. The Attribute - "supaPolMetadataConstraint[0..n]" ........ 81 - 5.17. The Concrete Class "SUPAPolicyConcreteMetadata" ......... 81 - 5.17.1. SUPAPolicyConcreteMetadata Attributes .............. 82 - 5.17.2. SUPAPolicyConcreteMetadata Relationships ........... 82 - 5.18. The Abstract Class "SUPAPolicyMetadataDecorator" ........ 82 - 5.18.1. SUPAPolicyMetadataDecorator Attributes ............. 82 - 5.18.1.1. The Attribute "supaPolMDValidPeriodEnd" ....... 82 - 5.18.1.2. The Attribute "supaPolMDValidPeriodStart" ..... 82 - 5.18.2. SUPAPolicyMetadataDecorator Relationships .......... 82 - 5.18.2.1. The Aggregation "HasSUPAMetadataDecorator" .... 83 + "supaPolMetadataConstraint[0..n]" ........ 82 + 5.17. The Concrete Class "SUPAPolicyConcreteMetadata" ......... 82 + 5.17.1. SUPAPolicyConcreteMetadata Attributes .............. 83 + 5.17.1.1. The Attribute "supaPolMDValidPeriodEnd" ...... 83 + 5.17.1.2. The Attribute "supaPolMDValidPeriodStart" .... 83 + 5.17.2. SUPAPolicyConcreteMetadata Relationships ........... 83 + 5.18. The Abstract Class "SUPAPolicyMetadataDecorator" ........ 83 + 5.18.1. SUPAPolicyMetadataDecorator Attributes ............. 83 + 5.18.2. SUPAPolicyMetadataDecorator Relationships .......... 83 + 5.18.2.1. The Aggregation "SUPAHasMetadataDecorator" .... 84 5.18.2.2. The Association Class - "HasSUPAMetadataDecoratorDetail" .............. 83 - 5.19. The Concrete Class "SUPAPolicyAccessMetadataDef" ........ 83 - 5.19.1. SUPAPolicyAccessMetadataDef Attributes ............. 84 - 5.19.1.1. The Attribute "supaAccessPrivilegeDef" ........ 84 - 5.19.1.2. The Attribute "supaAccessPrivilegeModelName" .. 84 - 5.19.1.3. The Attribute "supaAccessPrivilegeModelRef" ... 85 - 5.20. The Concrete Class "SUPAPolicyVersionMetadataDef" ....... 85 - 5.20.1. SUPAPolicyVersionMetadataDef Attributes ............ 85 - 5.20.1.1. The Attribute "supaVersionMajor" .............. 85 - 5.20.1.2. The Attribute "supaVersionMinor" .............. 86 - 5.20.1.3. The Attribute "supaVersionRelType" ............ 86 - 5.20.1.4. The Attribute "supaVersionTypeNum" ............ 86 -6. SUPA ECAPolicyRule Information Model .......................... 87 - 6.1. Overview ................................................. 87 - 6.2. Constructing a SUPAECAPolicyRule ......................... 88 - 6.3. Working With SUPAECAPolicyRules .......................... 89 - 6.4. The Abstract Class "SUPAECAPolicyRule" ................... 91 - 6.4.1. SUPAECAPolicyRule Attributes ........................ 92 - 6.4.1.1. The Attribute "supaECAPolicyRulePriority" ...... 93 - 6.4.1.2. The Attribute "supaECAPolicyRuleStatus" ........ 93 - 6.4.2. SUPAECAPolicyRule Relationships ..................... 93 + "SUPAHasMetadataDecoratorDetail" .............. 84 + 5.19. The Concrete Class "SUPAPolicyAccessMetadataDef" ........ 84 + 5.19.1. SUPAPolicyAccessMetadataDef Attributes ............. 85 + 5.19.1.1. The Attribute "supaAccessPrivilegeDef" ........ 85 + 5.19.1.2. The Attribute "supaAccessPrivilegeModelName" .. 85 + 5.19.1.3. The Attribute "supaAccessPrivilegeModelRef" ... 86 + 5.20. The Concrete Class "SUPAPolicyVersionMetadataDef" ....... 86 + 5.20.1. SUPAPolicyVersionMetadataDef Attributes ............ 86 + 5.20.1.1. The Attribute "supaVersionMajor" .............. 87 + 5.20.1.2. The Attribute "supaVersionMinor" .............. 88 + 5.20.1.3. The Attribute "supaVersionPatch" .............. 88 + 5.20.1.4. The Attribute "supaVersionPreRelease" ......... 88 + 5.20.1.5. The Attribute "supaVersionBuildMetadata" ...... 89 +6. SUPA ECAPolicyRule Information Model .......................... 89 + 6.1. Overview ................................................. 89 + 6.2. Constructing a SUPAECAPolicyRule ......................... 91 + 6.3. Working With SUPAECAPolicyRules .......................... 92 + 6.4. The Abstract Class "SUPAECAPolicyRule" ................... 93 + 6.4.1. SUPAECAPolicyRule Attributes ........................ 95 + 6.4.1.1. The Attribute "supaECAPolicyRulePriority" ...... 95 + 6.4.1.2. The Attribute "supaECAPolicyRuleStatus" ........ 95 + 6.4.2. SUPAECAPolicyRule Relationships ..................... 96 Table of Contents (continued) - 6.5. The Concrete Class "SUPAECAPolicyRuleAtomic" ............. 93 - 6.5.1. SUPAECAPolicyRuleAtomic Attributes .................. 93 - 6.5.2. SUPAECAPolicyRuleAtomic Relationships ............... 93 - 6.6. The Concrete Class "SUPAECAPolicyRuleComposite" .......... 94 - 6.6.1. SUPAECAPolicyRuleComposite Attributes ............... 94 - 6.6.1.1. The Attribute "supaECAEvalStrategy" ............ 94 - 6.6.2. SUPAECAPolicyRuleComposite Relationships ............ 95 - 6.6.2.1. The Aggregation "SUPAHasECAPolicyRule" ......... 95 - 6.6.3. The Association Class "SUPAHasECAPolicyRuleDetail" .. 95 - 6.6.3.1. The Attribute "supaECAPolicyIsDefault" ......... 95 - 6.7. The Abstract Class "SUPABooleanClause" ................... 96 - 6.7.1. SUPABooleanClause Attributes ........................ 96 - 6.7.1.1. The Attribute "supaBoolClauseIsNegated" ........ 97 - 6.7.2. SUPABooleanClause Relationships ..................... 97 - 6.8. The Concrete Class "SUPABooleanClauseAtomic" ............. 97 - 6.8.1. SUPABooleanClauseAtomic Attributes .................. 97 - 6.8.2. SUPABooleanClauseAtomic Relationships ............... 97 - 6.9. The Concrete Class "SUPABooleanClauseComposite" .......... 97 - 6.9.1. SUPABooleanClauseComposite Attributes ................ 98 - 6.9.1.1. The Attribute "supaBoolClauseBindValue" ........ 98 - 6.9.1.2. The Attribute "supaBoolClauseIsCNF" ............ 98 - 6.9.2. SUPABooleanClauseComposite Relationships ............ 98 - 6.9.2.1. The Aggregation "SUPAHasBooleanClause" ......... 98 - 6.9.3. The Concrete Class "SUPAHasBooleanClauseDetail" ..... 99 - 6.9.3.1. SUPAHasBooleanClauseDetail Attributes .......... 99 - 6.10. The Abstract Class "SUPAECAComponent" ................... 99 - 6.10.1. SUPAECAComponent Attributes ........................ 99 - 6.10.1.1. The Attribute supaECACompIsTerm .............. 100 - 6.10.2. SUPAECAComponent Relationships .................... 100 - 6.11. The Concrete Class "SUPAPolicyEvent" ................... 100 - 6.11.1. SUPAPolicyEvent Attributes ........................ 100 - 6.11.1.1. The Attribute "supaPolicyEventIsPreProcessed" 100 - 6.11.1.2. The Attribute "supaPolicyEventIsSynthetic" ... 100 - 6.11.1.3. The Attribute "supaPolicyEventTopic[0..n]" ... 101 - 6.11.1.4. The Attribute "supaPolicyEventEncoding[1..n]" 101 - 6.11.1.5. The Attribute "supaPolicyEventData[1..n]" .... 101 - 6.11.2. SUPAPolicyEvent Relationships ..................... 101 - 6.12. The Concrete Class "SUPAPolicyCondition" ............... 102 - 6.12.1. SUPAPolicyCondition Attributes .................... 102 - 6.12.1.1. The Attribute "supaPolicyConditionData[1..n]" 102 - 6.12.1.2. The Attribute "supaPolicyConditionEncoding" .. 102 - 6.12.2. SUPAPolicyEvent Relationships ..................... 102 - 6.13. The Concrete Class "SUPAPolicyAction" .................. 103 - 6.13.1. SUPAPolicyAction Attributes ....................... 103 - 6.13.1.1. The Attribute "supaPolicyActionData[1..n]" ... 103 - 6.13.1.2. The Attribute "supaPolicyActionEncoding" ..... 104 - 6.13.2. SUPAPolicyAction Relationships .................... 104 + 6.5. The Concrete Class "SUPAECAPolicyRuleAtomic" ............. 96 + 6.5.1. SUPAECAPolicyRuleAtomic Attributes .................. 96 + 6.5.2. SUPAECAPolicyRuleAtomic Relationships ............... 96 + 6.6. The Concrete Class "SUPAECAPolicyRuleComposite" .......... 96 + 6.6.1. SUPAECAPolicyRuleComposite Attributes ............... 96 + 6.6.1.1. The Attribute "supaECAEvalStrategy" ............ 97 + 6.6.2. SUPAECAPolicyRuleComposite Relationships ............ 97 + 6.6.2.1. The Aggregation "SUPAHasECAPolicyRule" ......... 98 + 6.6.3. The Association Class "SUPAHasECAPolicyRuleDetail" .. 98 + 6.6.3.1. The Attribute "supaECAPolicyIsDefault" ......... 98 + 6.7. The Abstract Class "SUPABooleanClause" ................... 98 + 6.7.1. SUPABooleanClause Attributes ........................ 99 + 6.7.1.1. The Attribute "supaBoolClauseIsNegated" ........ 99 + 6.7.2. SUPABooleanClause Relationships ..................... 99 + 6.8. The Concrete Class "SUPABooleanClauseAtomic" ............ 100 + 6.8.1. SUPABooleanClauseAtomic Attributes ................. 100 + 6.8.2. SUPABooleanClauseAtomic Relationships .............. 100 + 6.9. The Concrete Class "SUPABooleanClauseComposite" ......... 100 + 6.9.1. SUPABooleanClauseComposite Attributes .............. 100 + 6.9.1.1. The Attribute "supaBoolClauseBindValue" ....... 101 + 6.9.1.2. The Attribute "supaBoolClauseIsCNF" ........... 101 + 6.9.2. SUPABooleanClauseComposite Relationships ........... 101 + 6.9.2.1. The Aggregation "SUPAHasBooleanClause" ........ 101 + 6.9.3. The Association Class "SUPAHasBooleanClauseDetail" . 101 + 6.9.3.1. SUPAHasBooleanClauseDetail Attributes ......... 101 + 6.10. The Abstract Class "SUPAECAComponent" .................. 102 + 6.10.1. SUPAECAComponent Attributes ....................... 102 + 6.10.1.1. The Attribute supaECACompIsTerm .............. 102 + 6.10.2. SUPAECAComponent Relationships .................... 102 + 6.11. The Concrete Class "SUPAPolicyEvent" ................... 103 + 6.11.1. SUPAPolicyEvent Attributes ........................ 103 + 6.11.1.1. The Attribute "supaPolicyEventIsPreProcessed" 103 + 6.11.1.2. The Attribute "supaPolicyEventIsSynthetic" ... 103 + 6.11.1.3. The Attribute "supaPolicyEventTopic[0..n]" ... 103 + 6.11.1.4. The Attribute "supaPolicyEventEncoding[1..n]" 103 + 6.11.1.5. The Attribute "supaPolicyEventData[1..n]" .... 104 + 6.11.2. SUPAPolicyEvent Relationships ..................... 104 + 6.12. The Concrete Class "SUPAPolicyCondition" ............... 104 + 6.12.1. SUPAPolicyCondition Attributes .................... 105 + 6.12.1.1. The Attribute "supaPolicyConditionData[1..n]" 105 + 6.12.1.2. The Attribute "supaPolicyConditionEncoding" .. 105 + 6.12.2. SUPAPolicyEvent Relationships ..................... 105 + 6.13. The Concrete Class "SUPAPolicyAction" .................. 106 + 6.13.1. SUPAPolicyAction Attributes ....................... 106 + 6.13.1.1. The Attribute "supaPolicyActionData[1..n]" ... 106 + 6.13.1.2. The Attribute "supaPolicyActionEncoding" ..... 107 + 6.13.2. SUPAPolicyAction Relationships .................... 107 -7. Examples ...................................................... 104 -8. Security Considerations ...................................... 104 -9. IANA Considerations ........................................... 105 -10. Contributors ................................................ 105 -11. Acknowledgments ............................................. 105 -12. References .................................................. 105 - 12.1. Normative References .................................... 105 - 12.2. Informative References ................................. 105 -Authors' Addresses ............................................... 107 -Appendix A. Brief Analyses of Previous Policy Work .............. 107 -Appendix B. Mathematical Logic Terminology and Symbology ........ 114 -Appendix C. SUPA Logic Statement Information Model .............. 114 +7. Examples ..................................................... 107 +8. Security Considerations ..................................... 107 +9. IANA Considerations .......................................... 107 +10. Contributors ................................................ 108 +11. Acknowledgments ............................................. 108 +12. References .................................................. 108 + 12.1. Normative References ................................... 108 + 12.2. Informative References ................................ 108 +Authors' Addresses ............................................... 109 +Appendix A. Brief Analyses of Previous Policy Work .............. 110 1. Overview This document defines an information model for representing policies using a common extensible framework that is independent of language, protocol, repository, and the level of abstraction of the content and meaning of a policy. This enables a common set of concepts defined in this information model to be mapped into different representations of policy (e.g., procedural, imperative, and declarative). It also enables different data models that use different languages, protocols, and repositories to optimize @@ -368,128 +371,133 @@ model that will be generated. This version of the information model focuses on defining one type of policy rule: the event-condition-action (ECA) policy rule. Accordingly, this document defines two sets of model elements: 1. A framework for defining the concept of policy, independent of how policy is represented or used; this is called the SUPA Generic Policy Information Model (GPIM) 2. A framework for defining a policy model that uses the - event-condition-action paradigm; this is called the SUPA - Eca Policy Rule Information Model (EPRIM), and extends + event-condition-action (ECA) paradigm; this is called the + SUPA ECA Policy Rule Information Model (EPRIM), and extends concepts from the GPIM. The combination of the GPIM and the EPRIM provides an extensible framework for defining policy that uses an event-condition-action representation that is independent of data repository, data definition language, query language, implementation language, and protocol. The Appendices describe how the structure of the GPIM defines a set of generic concepts that enables other types of policies, such as declarative (or "intent-based") policies, to be added later. 1.1. Introduction - Simplified Use of Policy Abstractions (SUPA) defines an interface - to a network management function that takes high-level, possibly - network-wide policies as input and creates element configuration - snippets as output. SUPA addresses the needs of operators and - application developers to represent multiple types of policy - rules, which vary in the level of abstraction, to suit the needs - of different actors [1], [10]. - - Different constituencies of users would like to use languages that - use terminology and concepts that are familiar to each constituency. - Rather than require multiple software systems to be used for each - language, a common information model enables these different - languages to be mapped to terms in the information model. This - facilitiates the use of a single software system to generate data - models for each language. In the example shown in Figure 1 (which - is a simplified policy continuum [10]), each constituency needs - different grammars using different concepts and terminologies to - match their skill set. This is shown in Figure 1. A unified - information model is one way to build a consensual lexicon that - enables terms from one language to be mapped to terms of another - language. - - +---------------------+ - +---------------+ \| High-level Policies | \+-------------+ - | Business User |----| Without Technical |----| Language #1 | - +---------------+ /| Terminology | /+-------------+ - +---------------------+ - - +---------------------+ - +---------------+ \| Policies That Use | \+-------------+ - | Developer |----| Classes, Attributes,|----| Language #2 | - +---------------+ /| Relationships, ... | /+-------------+ - +---------------------+ + Simplified Use of Policy Abstractions (SUPA) defines a technology- + independent neutral information model for creating high-level, + possibly network-wide policies as input and producing element + configurations (either whole or snippets) as output. SUPA addresses + the needs of operators, end-users, and application developers to + represent multiple types of ECA policy rules, such as for traffic + selection and configuration or security. These ECA policy rules may + vary in the level of abstraction to suit the needs of different + actors (e.g., end-users vs. administrators) [1], [10]. - ... ... ... + Different constituencies of users would like to use terminology and + concepts that are familiar to each constituency. Rather than require + multiple software systems to be used for each constituency, a common + information model enables these different concepts and terms to be + mapped to elements in the information model. This facilitiates the + use of a single software system to generate data models for each + language. In the example shown in Figure 1 (which is a simplified + Policy Continuum [10]), each constituency uses different concepts + and terms (according to their skill sets and roles) to formulate + (ECA) policy rules that are useful for their job functions. A + unified information model is one way to build a consensual lexicon + that enables terms from one language to be mapped to terms of + another language. This approach enables the syntax of each language + to be modified appropriate to its user while keeping a common set + of semantics for all languages. This is shown in Figure 1. - +---------------------+ - +---------------+ \| Low-level Policies | \+-------------+ - | Admin |----| with Technology- |----| Language #n | + +-------------------+ + | Information Model | + | and one or more +<------------------------+ + | Data Models | | + +-------------------+ | + | + +---------------------+ | + +---------------+ \| High-level Policies | \+-------------+ | + | Business User |----| Without Technical |----| Language #1 +<----+ + +---------------+ /| Terminology | /+-------------+ | + +---------------------+ | + | + +---------------------+ | + +---------------+ \| Policies That Use | \+-------------+ | + | Developer |----| Classes, Attributes,|----| Language #2 +<----+ + +---------------+ /| Relationships, ... | /+-------------+ | + +---------------------+ | + | + ... ... ... | + | + +---------------------+ | + +---------------+ \| Low-level Policies | \+-------------+ | + | Admin |----| with Technology- |----| Language #n +<----+ +---------------+ /| Specific Terms in a | /+-------------+ | Specific Language | +---------------------+ Figure 1. Different Constituencies Need Different Policies More importantly, an information model defines concepts in a uniform way, enabling formal mapping processes to be developed to translate the information model to a set of data models. This simplifies the process of constructing software to automate the policy management process. It also simplifies the language generation process, though that is beyond the scope of this document. This common framework takes the form of an information model that - is divided into one high-level module and any number of lower- - level modules, where each lower-level module extends the concepts - of the single high-level module. Conceptually, a set of model - elements (e.g., classes, attributes, and relationships) are used - to define the Generic Policy Information Model (GPIM); this module - defines a common set of policy management concepts that are - independent of the type of policy (e.g., imperative, procedural, - declarative, or otherwise). Then, any number of additional modules - are derived from the GPIM; each additional module MUST extend the - GPIM to define a new type of policy rule by adding to the GPIM. - (Note: using extensions preserves the core interoperability, as - compared with modification of the base GPIM, which would adversely - compromise interoperability. + is divided into one high-level module and one or more number of + lower-level modules. A lower-level module extends the higher-level + module into a new domain; each lower-level domain module can itself + be extended to model more granular domain-specific (but still + technology- and vendor-independent) concepts as necessary. - The SUPA Eca Policy Rule Information Model (EPRIM) extends the + Conceptually, a set of model elements (e.g., classes, attributes, + constraints, and relationships) are used to define the Generic + Policy Information Model (GPIM); this module defines a common set of + policy concepts that are independent of the type of policy (e.g., + imperative, procedural, declarative, or otherwise). Then, any number + of additional modules can be derived from the GPIM; each additional + module MUST extend the GPIM to define a new type of policy rule by + adding to the GPIM. Each additoinal module MUST NOT alter any of + the model elements of the GPIM. The use of extensions preserves the + interoperability of this approach; if the base GPIM was modified, + then this would adversely compromise interoperability. + + The SUPA ECA Policy Rule Information Model (EPRIM) extends the GPIM to represent policy rules that use the Event-Condition-Action - (ECA) paradigm. (The Appendices describe the SUPA Logic Statement - Information Model (LSIM), which shows how to extend the GPIM to - represent a collection of statements that are either Propositional - Logic (PL) or First-Order Logic (FOL), respectively. Both of these - logics are types of declarative logic. Note that the LSIM is - currently out of scope. However, it is outlined as a set of - Appendices in this document to get feedback on its utility. + (ECA) paradigm. -1.2. Changes Since Version -04 +1.2. Changes Since Version -00 There are several changes in this version of this document compared to the previous versions of this document. They are: - 1) The SUPAVendorDecoratedComponent class has been renamed to - SUPAGenericDecoratedComponent, and its function has been - made more generic. - 2) A number of clarifications have been made in response to - questions from the SUPA mailing list. - 3) The multiplicity of all relationships have been fine-tuned - 4) A **preliminary** YANG model [RFC6020] [RFC6991] has been - built from the GPIM; see [15]. - 5) Various additional typos have been fixed. + 1) Rewrote parts of the Introduction. + 2) Clarified how to extend the GPIM and EPRIM + 3) Redesigned the SUPAPolicyVersionMetadataDef class + 4) Added Fully Qualified Path Names where applicable + 5) Removed Appendices B and C (declarative policies) + 6) Fixed typos 2. Conventions Used in This Document 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 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying [RFC2119] significance. @@ -529,66 +537,73 @@ 3.2.1.1. Information Model An information model is a representation of concepts of interest to an environment in a form that is independent of data repository, data definition language, query language, implementation language, and protocol. Note: this definition is more specific than that of [RFC3198], so as to focus on the properties of information models. That definition was: "An abstraction and representation of the entities in a managed - environmentl, their properties, attributes and operations, and the + environment, their properties, attributes and operations, and the way that they relate to each other. It is independent of any specific repository, software usage, protocol, or platform." 3.2.1.2. Data Model A data model is a representation of concepts of interest to an environment in a form that is dependent on data repository, data - definition language, query language, implementation language, and - protocol (typically, but not necessarily, all three). + definition language, query language, implementation language, and/or + protocol (typically, but not necessarily, all five). Note: this definition is more specific than that of [RFC3198], so as to focus on the properties of data models that are generated from information models. That definition was: "A mapping of the contents of an information model into a form that is specific to a particular type of data store or repository." -3.2.1.3. Abstract Class +3.2.1.3. Class + + A class is a set of objects that exhibit a common set of + characteristics and behavior. + +3.2.1.3.1. Abstract Class An abstract class is a class that cannot be directly instantiated. It MAY have abstract or concrete subclasses. It is denoted with a - capital A near the top-left side of the class. + capital A (for abstract) near the top-left side of the class. -3.2.1.4. Concrete Class +3.2.1.3.2. Concrete Class A concrete class is a class that can be directly instantiated. Note that classes are either abstract or concrete. In addition, once a class has been defined as concrete in the hierarchy, all of its subclasses MUST also be concrete. It is denoted with a capital C - near the top-left side of the class. + (for concrete) near the top-left side of the class. -3.2.1.5. Container +3.2.1.4. Container A container is an object whose instances may contain zero or more additional objects, including container objects. A container provides storage, query, and retrieval of its contained objects in a well-known, organized way. -3.2.1.6. PolicyContainer +3.2.1.5. PolicyContainer In this document, a PolicyContainer is a special type of container that provides at least the following three functions: + 1. It uses metadata to define how its content is interpreted 2. It separates the content of the policy from the representation of the policy - 3. It provides a convenient control point for OAMP operations + 3. It provides a convenient control point for OAM&P operations + The combination of these three functions enables a PolicyContainer to define the behavior of how its constituent components will be accessed, queried, stored, retrieved, and how they operate. This document does NOT define a specific data type to implementation a PolicyContainer, as many different types of data types can be used. However, the data type chosen SHOULD NOT allow duplicate members in the PolicyContainer. In addition, order is irrelevant, since priority will override any initial order of the members of this PolicyContainer. @@ -598,35 +613,34 @@ The following terms define different policy concepts used in the SUPA Generic Policy Information Model (GPIM). Note that the prefix "SUPA" is used for all classes and relationships defined in this model to ensure name uniqueness. Similarly, the prefix "supa" is defined for all SUPA class attributes. 3.2.2.1. SUPAPolicyObject A SUPAPolicyObject is the root of the GPIM class hierarchy. It is an abstract class that all classes inherit from, except the - SUPAPolicyMetadata class. + SUPAPolicyMetadata class and its subclasses. 3.2.2.2. SUPAPolicy A SUPAPolicy is, in this version of this document, an ECA policy rule that is a type of PolicyContainer. The PolicyContainer MUST contain an ECA policy rule, SHOULD contain one or more SUPAPolicyMetadata objects, and MAY contain other elements that define the semantics of the policy rule. Policies are generically defined as a means to monitor and control the changing and/or maintaining of the state of one or more managed objects [1]. In - this context, "manage" means that at least create, read, query (a - more complex operation than read that may involve pre- and/or post- - processing of the results of the operation), update, and delete - functions are supported. + this context, "manage" means that one or more of the following six + fundamental operations are supported: create, read, write, delete, + start, and stop) [16]. 3.2.2.3. SUPAPolicyClause A SUPAPolicyClause is an abstract class. Its subclasses define different types of clauses that are used to create the content for different types of SUPAPolicies. For example, the SUPABooleanClause subclass models the content of a SUPAPolicy as a Boolean clause, where each Boolean clause is made up of a set of reusable objects. In contrast, a @@ -637,21 +651,23 @@ 3.2.2.4. SUPAECAPolicyRule An Event-Condition-Action (ECA) Policy (SUPAECAPolicyRule) is an abstract class that is a type of PolicyContainer. It represents a policy rule as a three-tuple, consisting of an event, a condition, and an action clause. In an information model, this takes the form of three different aggregations, one for each clause. Each clause MUST be represented by at least one SUPAPolicyClause. Optionally, the SUPAECAPolicyRule MAY contain zero or more SUPAPolicySources, zero or more SUPAPolicyTargets, - and zero or more SUPAPolicyMetadata objects. + and zero or more SUPAPolicyMetadata objects. Note that for this + version of this document, ECA Policy Rules are the **only** + types of Policies that are defined. 3.2.2.5. SUPAMetadata Metadata is, literally, data about data. SUPAMetadata is an abstract class that contains prescriptive and/or descriptive information about the object(s) to which it is attached. While metadata can be attached to any information model element, this document only considers metadata attached to classes and relationships. @@ -673,26 +689,29 @@ SUPAPolicyTarget class MUST have its own aggregation relationship with each SUPAPolicy that uses it. However, a data model MAY map these definitions to a more efficient form (e.g., flattening the SUPAPolicyTarget, SUPAMetadata, and SUPAPolicy object instances into a single object instance). 3.2.2.7. SUPAPolicySource SUPAPolicySource is an abstract class that defines a set of managed objects that authored this SUPAPolicyClause. This is - required for auditability. A SUPAPolicySource may use one or more - mechanisms to identify the set of managed objects that authored it; - examples include OIDs and URIs. Specifically, policy CRUD MUST be - subject to authentication and authorization, and MUST be auditable. - Note that the mechanisms for doing these three operations are - currently not included, and are for further discussion. + required for auditability and authorization policies, as well + as some forms of deontic and alethic logic. + + A SUPAPolicySource may use one or more mechanisms to identify the + set of managed objects that authored it; examples include OIDs and + URIs. Specifically, policy CRUD MUST be subject to authentication + and authorization, and MUST be auditable. Note that the mechanisms + for doing these three operations are currently not included, and + are for further discussion. When defined in an information model, each instance of the SUPAPolicySource class MUST have its own aggregation relationship with each SUPAPolicy that uses it. However, a data model MAY map these definitions to a more efficient form (e.g., flattening the SUPAPolicySource, SUPAMetadata, and SUPAPolicy object instances into a single object instance). 3.2.3. Modeling Terminology @@ -762,68 +781,65 @@ constituent part entities are also deleted. This is not true of aggregations or associations - in both, only the entity being deleted is actually removed, and the other entities are unaffected. In an information model, a composition MAY be represented as a class. 3.2.3.6. Association Class A relationship may be implemented as an association class. This is used to define the relationship as having its own set of features. + (Note: in this document, all relationships are implemented as + association classes for consistency and to simplify implementation.) More specifically, if the relationship is implemented as an association class, then the attributes of the association class, as well as other relationships that the association class participates in, may be used to define the semantics of the relationship. If the relationship is not implemented as an association class, then no additional semantics (beyond those defined by the type of the relationship) are expressed by the relationship. 3.2.3.7. Multiplicity A specification of the range of allowable cardinalities that a set of entities may assume. This is always a pair of ranges, such as 1 - 1 or 0..n - 2..5. 3.2.3.8. Navigability - A relationship may have a restriction on the ability of an object - at one end of the relationship to access the object at the other - end of the relationship. This document defines two choices: + A relationship may restrict one object from accessing the other + object. This document defines two choices: 1. Each object is navigable by the other, which is indicated by NOT providing any additional symbology, or - 2. An object A can navigate to object B, but object B cannot navigate to object A. This is indicated by an open-headed arrow pointing to the object that cannot navigate to the - other object. In this example, the arrow would be pointing - at object B. - - Examples of navigability are: + other object. An example is shown below: +---------+ 3..4 +---------+ | | 1..2 \| | | Class A |--------------| Class B | | | /| | +---------+ +---------+ - This is an association. Class A can navigate to Class B, but Class - B cannot navigate to Class A. This is a mandatory association, - since none of the multiplicities contain a '0'. This association - reads as follows: + The above figure shows a navigability restriction. Class A can + navigate to Class B, but Class B cannot navigate to Class A. This is + a mandatory association, since none of the multiplicities contain a + '0'. This association reads as follows: Class A depends on 3 to 4 instances of Class B, and Class B depends on 1 to 2 instances of Class A. 3.3. Symbology - The following symbology is used in this document: + The following symbology is used in this document. 3.3.1. Inheritance Inheritance: a subclass inherits the attributes and relationships of its superclass, as shown below: +------------+ | Superclass | +------+-----+ / \ @@ -904,33 +920,33 @@ An Abstract Class A Concrete Class 4. Policy Abstraction Architecture This section describes the motivation for the policy abstractions that are used in SUPA. The following abstractions are provided: o The GPIM defines a technology-neutral information model that can express the concept of Policy. o All classes, except for SUPAPolicyMetadata, inherit from - SUPAPolicyObject, or one of its subclasses + SUPAPolicyObject, or one of its subclasses. o SUPAPolicyObject and SUPAPolicyMetadata are designed to inherit from classes in another model; the GPIM does not define an "all-encompassing" model. o This version of this document restricts the expression of Policy to a set of event-condition-action clauses. - o Each clause is defined as a Boolean expression, and is a - reusable object + o Each clause is defined as a Boolean expression, and MAY + also be defined as a reusable object. o Clauses may be combined to form more complex Boolean - expressions + expressions. o The purpose of the GPIM is to enable different policies that have fundamentally different representations to share common - model elements. Policy statmeents, which are implemented as + model elements. Policy statements, which are implemented as instances of the SUPAPolicyClause class, separates the content of a Policy from its representation. This is supported by: o All policy rules (of which SUPAECAPolicyRule is the first example of a concrete class) are derived from the SUPAPolicyStructure class. o All objects that are components of policy rules are derived from the SUPAPolicyComponentStructure class. o A SUPAPolicy MUST contain at least one SUPAPolicyClause. o A SUPAPolicy MAY specify one or more SUPAPolicyTarget, SUPAPolicySource, and SUPAPolicyMetadata objects to @@ -945,24 +961,20 @@ that are responsible for executing its actions; it MUST have at least one event clause, at least one condition clause, and at least one action clause. o The action(s) of a SUPAECAPolicyRule are ONLY executed if both the event and condition clauses evaluate to TRUE o A SUPAPolicyAction MAY invoke another SUPAECAPolicyRule (see section 6.13). o SUPAMetadata MAY be defined for any SUPAPolicyObject class. o SUPAMetadata MAY be prescriptive and/or descriptive in nature. - Please see the Appendices for experimental definitions of - declarative policies. Note that they also are derived from the - GPIM, and extend (but do not change) the above abstractions. - 4.1. Motivation The power of policy management is its applicability to many different types of systems. There are many different actors that can use a policy management system, including end-users, operators, application developers, and administrators. Each of these constituencies have different concepts and skills, and use different terminology. For example, an operator may want to express an operational rule that states that only Platinum and Gold users can use streaming multimedia applications. As a second example, a @@ -1073,35 +1085,35 @@ / \ / \ | | | | +-----------+-----------+ +-----------+------------+ | ECAPolicyRule | | Other Types of | | Data Model | | Data Models | +-----------------------+ +------------------------+ Figure 2. Overview of SUPA Policy Rule Abstractions - This draft defines the GPIM and EPRIM. Note that there is only - ONE GPIM and ONE EPRIM. While both can be extended, it is - important to limit the number of information models to one, in - order to avoid defining conflicting concepts at this high a - level of abstraction. Similarly, if the GPIM and EPRIM are part - of another information model, then they should collectively - still define a single information model. The GPIM defines the - following concepts: + This draft defines the GPIM and EPRIM. This draft further assumes + that the SUPA Information Model is made up of either the GPIM or the + combination of the GPIM and the EPRIM. Extensions to both the GPIM + and the EPRIM can be made as long as these extensions do not + conflict with the content and structure defined in the GPIM and + EPRIM. If the GPIM and EPRIM are part of another information model, + then they should collectively still define a single information + model. The GPIM defines the following concepts: o A class defining the top of the GPIM class hierarchy, called SUPAPolicyObject o Four subclasses of SUPAPolicyObject, representing: - o the top of the PolicyRule hierarchy, called + o the top of the Policy hierarchy, called SUPAPolicyStructure - o the top of the PolicyRule component hierarchy, called + o the top of the Policy component hierarchy, called SUPAPolicyComponentStructure o PolicySource o PolicyTarget The SUPAPolicyStructure class is the superclass for all types of Policies (e.g., imperative, declarative, and others). This document is currently limited to imperative (e.g., ECA) policies. However, care has been taken to ensure that the attributes and relationships of the SUPAPolicyStructure class are extensible, and can be used for more types of policies than just ECA policies. @@ -1123,48 +1135,48 @@ +----+----------------+ I +------------+-----------------+ / \ I / \ I +--------+----+ I I I I I I C I I I I +-------+----------+ I I I | SUPAPolicySource | I I I +------------------+ I I I I I I +-------------+ I - I I I - I C I +-----+-------+ - I +-------+----------+ I I - I | SUPAPolicyTarget | A I I - I +------------------+ +--------+---------+ I - A I | SUPAPolicyClause | I - +-----+------------+ +------------------+ I - | SUPAECAPolicyRule| I - +------------------+ A I - +--------------------+---------+ + I I +-----+-------+ + I C I I I + I +-------+----------+ A I I + I | SUPAPolicyTarget | +--------+---------+ I + I +------------------+ | SUPAPolicyClause | I + A I +------------------+ I + +-----+------------+ I + | SUPAECAPolicyRule| A I + +------------------+ +--------------------+---------+ | SUPAPolicyComponentDecorator | +------------------------------+ Figure 3. Functional View of the Top-Level GPIM Note that all classes except the SUPAPolicySource and the SUPAPolicyTarget classes are defined as abstract. This provides more freedom for the data modeler in implementing the data model. For example, if the data model uses an object-oriented language, such as Java, then the above structure enables all of the abstract - classes to be collapsed to a single concrete class. If this is + classes to be collapsed into a single concrete class. If this is done, attributes as well as relationships are inherited. 4.3.1. SUPAPolicyObject A SUPAPolicyObject serves as a single root of the SUPA system (i.e., all other classes in the model are subclasses of the - SUPAPolicyObject class). This simplifes code generation and + SUPAPolicyObject class) except for the Metadata objects, which are + in a separate class hierarchy. This simplifies code generation and reusability. It also enables SUPAPolicyMetadata objects to be attached to any appropriate subclass of SUPAPolicyObject. 4.3.2. SUPAPolicyStructure SUPAPolicyStructure is an abstract superclass that is the base class for defining different types of policies (however, in this version of this document, only ECA policy rules are modeled). It serves as a convenient aggregation point to define atomic (i.e., individual policies that can be used independently) and composite @@ -1389,27 +1401,28 @@ C I A I +----------------+---------------+ +-----------+-----------+ | Future Subclasses to Represent | | SUPAECAPolicyRule | | Represent Different Policies | +-----------------------+ +--------------------------------+ Figure 5. The Composite Pattern Applied to SUPAPolicyStructure 4.4.2. Representing an ECA Policy Rule - An ECA policy rule is a 3-tuple, made up of one or more event - clauses, one or more condition clauses, and one or more action - clauses. Each clause may be viewed as a predicate, as it provides - a TRUE or FALSE output. The canonical form of a clause is a - 3-tuple of the form "variable operator value", and can be made - into more complex Boolean expressions. For example, the - SUPAPolicyClause: "((A AND B) OR NOT (C AND D)) consists of two + An ECA policy rule is a 3-tuple, which is made up of an event + clause, a condition clause, and an action clause. Each of these + three types of clauses may in turn be made up of a Boolean + combination of clauses of that type. Each clause may be viewed as + a predicate, as it provides a TRUE or FALSE output. The canonical + form of a clause is a 3-tuple of the form "variable operator value", + and can be made into more complex Boolean expressions. For example, + the SUPAPolicyClause: "((A AND B) OR NOT (C AND D)) consists of two clauses, "(A AND B)" and "(C OR D)", that are combined together using the operators OR and NOT. A SUPAECAPolicyRule is defined (in the EPRIM) as an abstract subclass of SUPAPolicyStructure. A A +---------------------------+ +------------------+ | SUPAPolicyStructure | | SUPAPolicyClause | +---------+---------+-------+ +--------+----+----+ @@ -1648,21 +1660,21 @@ | SUPAPolicyTerm | I | SUPAPolicyCollection | I +----------------+ I +----------------------+ I (for defining I (for defining sets and/or I clauses in I groups of objects) I canonical form) I I I I C I A I +----------------+--------------+ +---------+--------+ | SUPAGenericDecoratedComponent | | SUPAECAComponent | +-------------------------------+ +------------------+ - (for decorating concrete (for defiing reusable + (for decorating concrete (for defining reusable subclasses of SUPAPolicyClause) event, condition, and action objects) Figure 10. Subclasses of SUPAPolicyComponentDecorator If a SUPAEncodedClause is being used, then there is no need to use any of the SUPAPolicyComponentDecorator subclasses, since the SUPAEncodedClause already completely defines the content of the SUPAPolicyClause. @@ -1813,21 +1825,21 @@ A SUPAPolicyTarget defines the set of managed entities that a SUPAPolicy is applied to. This is useful for debugging, as well as when the nature of the application requires the set of managed entities affected by a Policy to be explicitly identified. This is determined by two conditions: 1) The set of managed entities that are to be affected by the SUPAPolicy must all agree to play the role of a SUPAPolicyTarget. For example, a managed entity may not be in a state that enables SUPAPolicies to be applied to it; - hence, in this case, it MUST NOT assume the role of ability + hence, in this case, it MUST NOT assume the role of a SUPAPolicyTarget 2) A SUPAPolicyTarget must be able to: a) process (either directly or with the aid of a proxy) SUPAPolicies, or b) receive the results of a processed SUPAPolicy and apply those results to itself. Figure 12 showed how SUPAPolicyTargets are attached to SUPAECAPolicyRules. @@ -1867,20 +1879,27 @@ Note that this also violates a number of well-known software architecture principles, including: o the Liskov Substitution Principle [13] (if A is a subclass of B, then objects instantiated from class B may be replaced with objects instantiated from class A WITHOUT ALTERING ANY OF THE PROGRAM SEMANTICS) o the Single Responsibility Principle [14] (every class should have responsibility over one, and only one, part of the functionality provided by the program) + o the Open/Closed Principle (software should be open for + extension, but closed for modification) [17] + o the Interface-Segreation Principle (clients should not be + forced to depend on methods that they do not use) [14] + o the Dependency Inversion Principle (high-level modules should + not depend on low-level modules; both should depend on + abstractions) [14] Most models use inheritance, not composition. The former is simpler, but has some well-known problems. One is called "weak encapsulaton", meaning that a subclass can use attributes and methods of a superclass, but if the superclass changes, the subclass may break. Another is that each time a new object is required, a new subclass must be created. These problems are present in [RFC3460], [4], and [6]. Composition is an alternative that provides code that is easier to @@ -1986,21 +2005,21 @@ programming, of software systems. In contrast to design, development emphasizes constructing software artifacts via coding and documentation. Deployment may be described as the process of releasing software. It includes all of the operations required to assemble a completed software product. It typically also includes the process of preparing a software product for execution (e.g., assembling a set of software products into a larger product, determining if the consumer site has appropriate resources to install and execute the - software product, and collecting information on the feasbility of + software product, and collecting information on the feasibility of using the software product). This contrasts with the execution process, which is the set of processes that follow deployment. In summary, exemplar states in the policy lifecycle process include: o Design: determining how the policy-based management system will operate o Development: documenting, programming, testing, and maintaining policies and policy components @@ -2120,21 +2139,21 @@ +--------+---------+ / \ 0..n A \ / | A | 0..n +--------------------+ | SUPAHasPolicyMetadata \| | +-------------+-----------------+ SUPAPolicyMetadata | ^ /| | | +------+------+------+ - A | / \ | 1..n + C | / \ | 1..n +-------------+---------------+ I | 1..n | | I | +----------+ SUPAHasPolicyMetadataDetail | I | | | | I | | +-----------------------------+ I | | I | | (gets/sets values of attributes and/or I | | methods of the SUPAHasPolicyMetadataDetail I | | class; this affects which SUPAPolicyMetadata I | | objects can be attached to which policies I | @@ -2152,35 +2171,35 @@ | | I | | SUPAPolicyMetadataDecorator +IIIIIIIII+ | | | | +-------+--------------+------+ | / \ / \ 0..1 | I A | I \ / | I | | subclasses for adding | | behavior to policies +-----------------------+ - and policy components PolicyObjectHasMetadata + and policy components SUPAHasMetadataDecorator Figure 14. SUPAPolicyMetadata Subclasses and Relationships Since a class encapsulates attributes, methods, and behavior, defining the Identification Object in the above example as a type of SUPAPolicyMetadata object enables the decorator pattern to be used to attach all or part of that object to other objects that need it. Figure 15 shows a portion of the SUPAPolicyMetadata hierarchy. A +--------------------+ - | | HasSUPAMetadataDecorator + | | SUPAHasMetadataDecorator | SUPAPolicyMetadata +-------------------+ | | 1..n | +---------+----------+ | I | I | I | +-------------+-----------------+ | | | | C | | / \ +---------+------------------+ | A @@ -2346,27 +2365,28 @@ 5.2.1.1. Object Identifiers This document defines two class attributes in SUPAPolicyObject, called supaPolObjIDContent and supaPolObjIDEncoding, that together define a unique object ID. This enables all class instances to be uniquely identified. One of the goals of SUPA is to be able to generate different data models that support different types of protocols and repositories. This means that the notion of an object ID must be generic. It is - inappropriate to use data modeling concepts, such as keys, GUIDs, - UUIDs, FQDNs, URIs, and other similar mechanisms, to define the - structure of an information model. Therefore, a synthetic object - ID is defined using these two attributes. This can be used to - facilitate mapping to different data model object schemes, such - as those depending on URIs, FQDNs, UUIDs, primary key-foreign key - relationships, UUIDs, and others can all be accommodated. + inappropriate to use data modeling concepts, such as keys, Globally + Unique IDentifiers (GUIDs), Universally Unique IDentifiers (UUIDs), + Fully Qualified Domain Names (FQDNs), Fully Qualified Path Names + (FQPNs), Uniform Resource Identifiers (URIs), and other similar + mechanisms, to define the structure of an information model. + Therefore, a synthetic object ID is defined using these two class + attributes. This can be used to facilitate mapping to different data + model object schemes. The two attributes work together, with the supaPolObjIDContent attribute defining the content of the object ID and the supaPolObjIDEncoding attribute defining how to interpret the content. These two attributes form a tuple, and together enable a machine to understand the syntax and value of an object identifier for the object instance of this class. Similarly, all SUPA classes are attributes are both uniquely named as well as prepended with the prefixes "SUPA" and "supa", @@ -2395,20 +2415,21 @@ this class. The supaPolObjIDEncoding attribute is mapped to the following values: 0: undefined 1: GUID 2: UUID 3: primary key 4: foreign key 5: URI 6: FQDN + 7: FQPN The value 0 may be used to initialize the system, or to signal that there is a problem with this particular SUPAPolicyObject. 5.2.1.4. The Attribute "supaPolicyDescription" This is an optional string attribute that defines a free-form textual description of this object. 5.2.1.5. The Attribute "supaPolicyName" @@ -2433,21 +2454,21 @@ SUPAPolicyObject. This aggregation is defined in section 5.16.2. 5.2.2.2. The Association Class "SUPAHasPolicyMetadataDetail" This is a mandatory concrete association class that defines the semantics of the SUPAPolicyMetadata aggregation. This enables the attributes and relationships of the SUPAPolicyMetadataDetail class to be used to constrain which SUPAPolicyMetadata objects can be aggregated by this particular SUPAPolicyObject instance. This - association class is defined in Section 5.16.3. + association class is defined in Section 5.16.2.2. 5.3. The Abstract Class "SUPAPolicyStructure" This is a mandatory abstract class that is used to represent the structure of a SUPAPolicy. This class (and all of its subclasses) is a type of PolicyContainer. SUPAPolicyStructure was abstracted from DEN-ng [2], and a version of this class is in the process of being added to [5]. However, the version in [5] differs significantly. First, the class and relationship definitions ared different. Second, [5] uses the composite pattern. Neither of @@ -2600,22 +2621,22 @@ as to enforce deontic and alethic logic. The multiplicity of this aggregation is 0..n - 0..n. This means that it is an optional aggregation; zero or more SUPAPolicySource objects may be aggregated by this SUPAPolicyStructure object, and zero or more SUPAPolicyStructure objects may aggregate this particular SUPAPolicySource object. 5.3.2.2. The Association Class "SUPAHasPolicySourceDetail" - This is an optional association class, and defines the semantics - of the SUPAHasPolicySource aggregation. The attributes and + This is an optional concrete association class, and defines the + semantics of the SUPAHasPolicySource aggregation. The attributes and relationships of this class can be used to define which SUPAPolicySource objects can be attached to which particular set of SUPAPolicyStructure objects. 5.3.2.2.1. The Attribute "supaPolSrcIsAuthenticated" This is an optional Boolean attribute. If the value of this attribute is true, then this SUPAPolicySource object has been authenticated by this particular SUPAPolicyStructure object. @@ -2636,22 +2657,22 @@ that will be affected by the execution of one or more SUPAPolicies. The multiplicity of this aggregation is 0..n - 0..n. This means that it is an optional aggregation; zero or more SUPAPolicyTarget objects may be aggregated by this SUPAPolicyStructure object, and zero or more SUPAPolicyStructure objects may aggregate this particular SUPAPolicyTarget object. 5.3.2.4. The Association Class "SUPAHasPolicyTargetDetail" - This is an optional association class, and defines the semantics - of the SUPAPolicyTargetOf aggregation. The attributes and + This is an optional concrete association class, and defines the + semantics of the SUPAPolicyTargetOf aggregation. The attributes and relationships of this class can be used to define which SUPAPolicyTargets can be attached to which particular set of SUPAPolicyStructure objects. 5.3.2.4.1. The Attribute "supaPolTgtIsAuthenticated" This is an optional Boolean attribute. If the value of this attribute is true, then this SUPAPolicyTarget object has been authenticated by this particular SUPAPolicyStructure object. @@ -2718,20 +2739,21 @@ that defines how to find the set of SUPAPolicyActions contained in each element of the supaPolExecFailTakeActionName class attribute. Values include: 0: undefined 1: String 2: GUID 3: UUID 4: URI 5: FQDN + 6: FQPN 5.3.2.6.2. The Attribute "supaPolExecFailTakeActionName[1..n]" This is an optional array of string attributes that identifies the set of policy actions to take if the SUPAPolicyStructure object that owns this association failed to execute properly. The interpretation of this string attribute is defined by the supaPolExecFailTakeActionEncoding class attribute. The association defines the SUPAPolicyStructure that contains the set of policy actions to execute, and this attribute defines which of these @@ -2756,24 +2778,24 @@ more SUPAPolicyStructure object instances at a given time. Thus, the multiplicity of this aggregation is defined as 0..1 on the aggregate (i.e., the SUPAPolicyStructure side) and 1..n on the part (i.e., the SUPAPolicyClause side). This means that at least one SUPAPolicyClause MUST be aggregated by this SUPAPolicyStructure object. Similarly, a SUPAPolicyClause may be aggregated by this particular SUPAPolicyStructure object. 5.3.2.8. The Association Class "SUPAHasPolicyClauseDetail" - This is an optional association class, and defines the semantics - of the SUPAHasPolicyClause aggregation. The attributes and/or - relationships of this association class can be used to determine - which SUPAPolicyClauses are aggregated by which + This is an optional abstract association class, and defines the + semantics of the SUPAHasPolicyClause aggregation. The attributes + and/or relationships of this association class can be used to + determine which SUPAPolicyClauses are aggregated by which SUPAPolicyStructure objects. Attributes will be added to this class at a later time. 5.4. The Abstract Class "SUPAPolicyComponentStructure" This is a mandatory abstract class that is the superclass of all objects that represent different types of components of a SUPAPolicy. Different types of policies have different types of structural components. However, all of these are used in at least @@ -2817,21 +2839,21 @@ type of policy), and SUPABooleanClause (which is also generic, but is typically used by SUPAECAPolicyRule objects). SUPAPolicyClauses are objects in their own right, which facilitates their reuse. SUPAPolicyClauses can aggregate a set of any of the subclasses of SUPAPolicyComponentDecorator, which was shown in Figure 10. These four subclasses provide four different ways to construct a SUPAPolicyClause: 1) SUPAPolicyTerm, which enables constructing a {variable, - operator, value} expression for building DUPAPolicyClauses + operator, value} expression for building SUPAPolicyClauses 2) SUPAEncodedClause, which enables policy clauses to be formed as an encoded object (e.g., to pass YANG or CLI code) 3) SUPAPolicyCollection, which defines a collection of objects that requires further processing by the policy management system in order to be made into a SUPAPolicyClause 4) SUPAECAComponent, which enables policy clauses to be formed using (reusable) Event, Condition, and/or Action objects SUPAPolicyClauses are aggregated by a SUPAPolicyStructure object, which enables all types of SUPAPolicies to uniformly be @@ -2854,23 +2876,23 @@ 0: Unknown (an error state) 1: Completed (i.e., successfully executed, but now idle) 2: Working (i.e., in use and no errors reported) 3: Not Working (i.e., in use, but errors have been reported) 4: Available (i.e., could be used, but currently isn't) 5: In Test (i.e., cannot be used as part of an OAM&P policy) 6: Disabled (i.e., not available for use) Value 0 denotes an error that prevents this SUPAPolicyClause from being used. Value 1 means that this SUPAPolicyClause has - successfully finished execution, and is now idle. Value 2 means - that this SUPAPolicyClause is in use; in addition, this - SUPAPolicyClause is working correctly. Value 3 is the same as + successfully finished execution, and is now idle and available. + Value 2 means that this SUPAPolicyClause is in use; in addition, + this SUPAPolicyClause is working correctly. Value 3 is the same as value 2, except that this SUPAPolicyClause is not working correctly. Value 4 means that this SUPAPolicyClause is available, but not currently in use. Value 5 means that this SUPAPolicyClause is in a special test state. A test state signifies that it SHOULD NOT be used to evaluate OAM&P policies. A value of 6 means that this SUPAPolicyClause is unavailable for use. 5.5.2. SUPAPolicyClause Relationships SUPAPolicyClause participates in a single relationship, @@ -2908,36 +2930,56 @@ This is a mandatory string attribute, and defines the content of this clause. It works with another class attribute, called supaEncodedClauseEncoding, which defines how to interpret the value of this attribute (e.g., as a string or reference). These two attributes form a tuple, and together enable a machine to understand the syntax and value of this object instance. 5.6.1.2. The Attribute "supaEncodedClauseEncoding" - This is a mandatory integer attribute, and defines how to - interpret the value of this encoded clause. It works with another - class attribute, called supaEncodedClauseContent, which defines + This is a mandatory non-negative integer attribute, and defines + how to interpret the value of this encoded clause. It works with + another class attribute (supaEncodedClauseContent), which defines the content of the encoded clause. These two attributes form a tuple, and together enable a machine to understand the syntax and value of the encoded clause for the object instance of this class. Values include: 0: undefined 1: String 2: GUID 3: UUID 4: URI 5: FQDN + 6: FQPN -5.6.1.3. The Attribute "supaEncodedClauseResponse" +5.6.1.3. The Attribute "supaEncodedClauseLanguage" + + This is mandatory non-negative integer attribute, and defines + the type of language used in this encoded clause. Values include: + + 0: undefined + 1: Text + 2: YANG + 3: XML + 4: CLI + 5: TL1 + +5.6.1.4. The Attribute "supaEncodedClauseLang[0..n]" + + This is an optional array of string attribute that contains + descriptive information about the type of language used in the + supaEncodedClauseLanguage class attribute. Text is in comma + separated value (i.e., vendorName, vendorVersion) format. + +5.6.1.5. The Attribute "supaEncodedClauseResponse" This is an optional Boolean attribute that emulates a Boolean response of this clause, so that it may be combined with other subclasses of the SUPAPolicyClause that provide a status as to their correctness and/or evaluation state. This enables this object to be used to construct more complex Boolean clauses. 5.6.2. SUPAEncodedClause Relationships SUPAPolicyClause participates in a single inherited relationship, @@ -2983,23 +3025,23 @@ the SUPAPolicyComponentDecorator object has an instance variable that holds a reference to a SUPAPolicyClause object. Since the SUPAPolicyComponentDecorator object has the same interface as the SUPAPolicyClause object, the SUPAPolicyComponentDecorator object (and all of its subclasses) are transparent to clients of the SUPAPolicyClause object (and its subclasses). This means that SUPAPolicyComponentDecorator object instances can add attributes and/or methods to those of the concrete instance of the chosen subclass of SUPAPolicyClause. - Figure 19 shows how this is done for methods. 19a shows the - initial object to be wrapped; 19b shows SUPAPolicyCollection - wrapping SUPAEncodedClause; 19c shows SUPAGenericDecoratedComponent + Figure 20 shows how this is done for methods. 20a shows the + initial object to be wrapped; 20b shows SUPAPolicyCollection + wrapping SUPAEncodedClause; 20c shows SUPAGenericDecoratedComponent wrapping SUPAPolicyCollection. +-------------------+ | SUPAEncodedClause | | eval() | +-------------------+ (a) Initial Object ===> +------------------------+ @@ -3037,55 +3079,60 @@ results to SUPAGenericDecoratedComponent, which executes and returns the final result. 5.7.2. SUPAPolicyComponentDecorator Attributes Currently, there are two attributes defined for this class, which are described in the following subsections. Both attributes are used by subclasses to constrain the behavior of that subclass; they do **not** affect the relationship between the concrete subclass of SUPAPolicyComponentDecorator that is wrapping the - concrete subclass of SUPAPolicyClause. This is different - than the use of similar attributes defined in the - SUPAHasDecoratedPolicyComponentDetail association class (which + concrete subclass of SUPAPolicyClause. + + This is different than the use of similar attributes defined in + the SUPAHasDecoratedPolicyComponentDetail association class (which are used to constrain the relationship between the concrete subclass of SUPAPolicyClause and the concrete subclass of the - SUPAHasDecoratedPolicyComponent object that is wrapping it). + SUPAPolicyComponentDecorator object that is wrapping it). Note that [2] does not define any attributes for this class. 5.7.2.1. The Attribute "supaPolCompConstraintEncoding" This is a mandatory non-negative enumerated integer that defines how to interpret each string in the supaPolCompConstraint class attribute. Values include: 0: undefined 1: OCL 2.4 2: OCL 2.x 3: OCL 1.x 4: QVT 1.2 - Relations Language 5: QVT 1.2 - Operational language 6: Alloy + 7: English text Enumerations 1-3 are dedicated to OCL (with OCL 2.4 being the latest version as of this writing). QVT defines a set of languages (the two most powerful and useful are defined by enumerations 4 and 5). Alloy is a language for describing constraints, and uses a - SAT solver to guarantee correctness. + SAT solver to guarantee correctness. Note that enumeration 7 + (English text) is not recommended (since it is informal, and hence, + not verifiable), but included for completeness. 5.7.2.2. The Attribute "supaAPolCompConstraint[0..n]" This is a mandatory array of string attributes. Each attribute specifies a constraint to be applied using the encoding defined in the supaPolCompConstraintEncoding class attribute. This provides a more rigorous and flexible treatment of constraints than is possible in [RFC3460]. + Note: [0..n] means that this is a multi-valued property that may have zero or more attributes. 5.7.3. SUPAPolicyComponentDecorator Relationships One relationship is currently defined for this class, which is described in the following subsection. 5.7.3.1. The Aggregation "SUPAHasDecoratedPolicyComponent" @@ -3120,26 +3167,29 @@ how to interpret each string in the supaDecoratedConstraint class attribute. Values include: 0: undefined 1: OCL 2.4 2: OCL 2.x 3: OCL 1.x 4: QVT 1.2 - Relations Language 5: QVT 1.2 - Operational language 6: Alloy + 7: English text Enumerations 1-3 are dedicated to OCL (with OCL 2.4 being the latest version as of this writing). QVT defines a set of languages (the two most powerful and useful are defined by enumerations 4 and 5). Alloy is a language for describing constraints, and uses a - SAT solver to guarantee correctness. + SAT solver to guarantee correctness. Note that enumeration 7 + (English text) is not recommended (since it is informal, and hence, + not verifiable), but included for completeness. 5.7.3.2.2. The Attribute "supaDecoratedConstraint[0..n]" This is a mandatory array of string attributes. Its purpose is to collect a set of constraints to be applied to a decorated object. The interpretation of each constraint in the array is defined in the supaDecoratedConstraintsEncoding class attribute. Note: [0..n] means that this is a multi-valued property that may have zero or more attributes. @@ -3270,22 +3320,21 @@ section 5.7.3. 5.9. The Concrete Class "SUPAPolicyVariable" This is a mandatory concrete class that defines information that forms a part of a SUPAPolicyClause. It specifies a concept or attribute that represents a variable, which should be compared to a value, as specifed in this SUPAPolicyClause. If it is used in a SUPAECAPolicyRule, then its value MAY be able to be changed at any time, including run-time, via use of the decorator pattern. - Note that this is not possible in previous designs ([RFC3460, [4], - and [6]). + This is not possible in previous designs ([RFC3460, [4], and [6]). The value of a SUPAPolicyVariable is typically compared to the value of a SUPAPolicyValue using the type of operator defined in a SUPAPolicyOperator. However, other objects may be used instead of a SUPAPolicyValue object, and other operators may be defined in addition to those defined in the SUPAPolicyOperator class. SUPAPolicyVariables are used to abstract the representation of a SUPAPolicyRule from its implementation. Some SUPAPolicyVariables are restricted in the values and/or the data type that they may @@ -3313,21 +3362,21 @@ SUPAPolicyVariable defines one attribute, as described below. 5.9.2.1. The Attribute "supaPolVarName" This is an optional string attribute that contains the name of this SUPAPolicyVariable. This variable name forms part of the {variable, operator, value} canonical form of a SUPAPolicyClause. 5.9.3. SUPAPolicyVariable Relationships - Currently, no relationships are defiend for the SUPAPolicyVariable + Currently, no relationships are defined for the SUPAPolicyVariable class (note that the decorator pattern obviates the need for relationships such as those in [RFC3460] and [6]). SUPAPolicyVariable, and its subclasses, inherit the SUPAHasDecoratedPolicyComponent aggregation, which was defined in section 5.7.3. 5.10. The Concrete Class "SUPAPolicyOperator" This is a mandatory concrete class for modeling different types of operators that are used in a SUPAPolicyClause. @@ -3356,37 +3405,37 @@ 1: Greater than 2: Greater than or equal to 3: Less than 4: Less than or equal to 5: Equal to 6: Not equal to 7: IN 8: NOT IN 9: SET 10: CLEAR - 11: BETWEEN + 11: BETWEEN (inclusive) Note that 0 is an unacceptable value. Its purpose is to support dynamically building a SUPAPolicyClause by enabling the application to set the value of this attribute to a standard default value if the real value is not yet known. Additional operators may be defined in future work. For example, if SUPAPolicyVariables and SUPAPolicyValues are expanded to/from include structured objects, then "deep" versions of operators 1-6 could also be defined. In this case, values 1-6 will be edited to explicitly indicate that they perform "shallow" comparison operations. 5.10.3. SUPAPolicyOperator Relationships - Currently, no relationships are defiend for the SUPAPolicyOperator + Currently, no relationships are defined for the SUPAPolicyOperator class (note that the decorator pattern obviates the need for relationships such as those in [6]). SUPAPolicyOperator, and its subclasses, inherit the SUPAHasDecoratedPolicyComponent aggregation, which was defined in section 5.7.3. Please refer to the examples in section 7, which show how to restrict the value, data type, range, and other semantics of the SUPAPolicyOperator when used in a SUPAPolicyClause. 5.11. The Concrete Class "SUPAPolicyValue" @@ -3447,33 +3496,34 @@ 0: Undefined 1: String 2: Integer 3: Boolean 4: Floating Point 5: DateTime 6: GUID 7: UUID 8: URI 9: FQDN - 10: NULL + 10: FQPN + 11: NULL A string is a sequence of zero or more characters. An Integer is a whole number (e.g., it has no fractional part). A Boolean represents the values TRUE and FALSE. A floating point number may contain fractional values, as well as an exponent. A DateTime represents a value that has a date and/or a time component (as in the Java or Python libraries). A NULL explicitly models the lack of a value. 5.11.3. SUPAPolicyValue Relationships - Currently, no relationships are defiend for the SUPAPolicyValue + Currently, no relationships are defined for the SUPAPolicyValue class (note that the decorator pattern obviates the need for relationships such as those in [6]). SUPAPolicyValue, and its subclasses, inherit the SUPAHasDecoratedPolicyComponent aggregation, which was defined in section 5.7.3. Please refer to the examples in section 7, which show how to restrict the value, data type, range, and other semantics of the SUPAPolicyValue when used in a SUPAPolicyClause. 5.12. The Concrete Class "SUPAGenericDecoratedComponent" @@ -3512,21 +3562,22 @@ 0: undefined 1: String 2: Integer 3: Boolean 4: Floating Point 5: DateTime 6: GUID 7: UUID 8: URI 9: FQDN - 10: NULL + 10: FQPN + 11: NULL A string is a sequence of zero or more characters. An Integer is a whole number (e.g., it has no fractional part). A Boolean represents the values TRUE and FALSE. A floating point number may contain fractional values, as well as an exponent. A DateTime represents a value that has a date and/or a time component (as in the Java or Python libraries). A NULL explicitly models the lack of a value. 5.12.2. SUPAGenericDecoratedComponent Relationships @@ -3646,21 +3696,21 @@ This is an optional non-negative enumerated integer that defines the type of collection that this instance is. Values include: 0: undefined 1: set 2: bag (e.g., multi-set) 3: dictionary (e.g., associative array) A set is an unordered collection of elements that MUST NOT have duplicates. A bag is an unordered collection of elements; it MAY - also have duplicates. A dictonary is a table that associates a + also have duplicates. A dictionary is a table that associates a key with a value. Sets have a number of important functions, including: o membership: returns TRUE if the element being tested is in the set, and FALSE otherwise o subset: returns TRUE if all elements in the first set are also in the second set o union: returns all elements from both sets with no duplicates @@ -3686,21 +3736,21 @@ key and a value is called an item. The format of an item is defined as one element (the key) followed by a colon followed by a second element (the value). Each item in a set of items is separated by a comma. Keys MUST NOT be NULL; values MAY be NULL. An example of a dictionary is {20:"FTP", 21:"FTP", 22: "SSH"}. An example of a null dictionary is simply {}. 5.13.4. SUPAPolicyCollection Relationships - Currently, no relationships are defiend for the + Currently, no relationships are defined for the SUPAGenericDecoratedComponent class (note that the decorator pattern obviates the need for relationships such as those in [6]). SUPAPolicyCollection participates in a single relationship, SUPAHasDecoratedPolicyComponent, as defined in section 5.7.3. 5.14. The Concrete Class "SUPAPolicySource" This is an optional class that defines a set of managed entities that authored, or are otherwise responsible for, this SUPAPolicyRule. Note that a SUPAPolicySource does NOT @@ -3839,47 +3889,48 @@ These two attributes form a tuple, and together enable a machine to understand the syntax and value of an object identifier for the object instance of this class. The supaPolMetadataIDEncoding attribute is mapped to the following values: 0: undefined 1: GUID 2: UUID 3: URI 4: FQDN + 5: FQPN 5.16.1.4. The Attribute "supaPolMetadataName" This is an optional string attribute that defines the name of this SUPAPolicyMetadata object. 5.16.2. SUPAPolicyMetadata Relationships SUPAPolicyMetadata participates in a single aggregation, which is defined in the following subsections. 5.16.2.1. The Aggregation "SUPAHasPolicyMetadata" - This is an optional aggregation that defines the set of + This is a mandatory aggregation that defines the set of SUPAPolicyMetadata that are aggregated by this particular SUPAPolicyObject. It is recommended that this aggregation be used as part of a conformant implementation. The multiplicity of this relationship is defined as 0..n on the aggregate (SUPAPolicyObject) side, and 0..n on the part (SUPAPolicyMetadata) side. This means that this relationship is optional. The semantics of this aggregation are implemented using the SUPAHasPolicyMetadataDetail association class. 5.16.2.2. The Abstract Class "SUPAHasPolicyMetadataDetail" - This is an optional abstract association class, and defines the + This is a mandatory concrete association class, and defines the semantics of the SUPAHasPolicyMetadata aggregation. Its purpose is to determine which SUPAPolicyMetadata object instances should be attached to which particular object instances of the SUPAPolicyObject class. This is done by using the attributes and relationships of the SUPAPolicyMetadataDetail class to constrain which SUPAPolicyMetadata objects can be aggregated by which particular SUPAPolicyObject instances. It is recommended that this association class be used as part of a conformant implementation. 5.16.2.2.1. The Attribute "supaPolMetadataIsApplicable" @@ -3895,26 +3946,29 @@ how to interpret each string in the supaPolMetadataConstraint class attribute. Values include: 0: undefined 1: OCL 2.4 2: OCL 2.x 3: OCL 1.x 4: QVT 1.2 - Relations Language 5: QVT 1.2 - Operational language 6: Alloy + 7: English text Enumerations 1-3 are dedicated to OCL (with OCL 2.4 being the latest version as of this writing). QVT defines a set of languages (the two most powerful and useful are defined by enumerations 4 and 5). Alloy is a language for describing constraints, and uses a - SAT solver to guarantee correctness. + SAT solver to guarantee correctness. Note that enumeration 7 + (English text) is not recommended (since it is informal, and hence, + not verifiable), but included for completeness. If this class is instantiated, then this attribute SHOULD also be instantiated, and should be part of a conformant implementation. 5.16.2.2.3. The Attribute "supaPolMetadataConstraint[0..n]" This is an optional array of string attributes. Each attribute specifies a constraint to be applied using the format identified by the value of the supaPolMetadataPolicyConstraintEncoding class attribute. This provides a more rigorous and flexible treatment of @@ -3954,69 +4008,69 @@ This is an optional attribute. Its data type should be able to express a date and a time. This attribute defines the starting date and time that this Metadata object is valid for. 5.17.2. SUPAPolicyConcreteMetadata Relationships This class inherits the relationships of the SUPAPolicyMetadata class; see section 5.16.2. It can also be used by subclasses of the SUPAPolicyMetadataDecorator class, and hence, can participate - in the HasSUPAMetadataDecorator aggregation; see section 5.18.2. + in the SUPAHasMetadataDecorator aggregation; see section 5.18.2. 5.18. The Abstract Class "SUPAPolicyMetadataDecorator" This is an optional class, and is used to implement the decorator pattern (see section 5.7.1.) for metadata objects. This pattern enables all or part of one or more SUPAPolicyMetadataDecorator subclasses to "wrap" a SUPAPolicyConcreteMetadata object instance. It is recommended that this class be used as part of a conformant implementation. 5.18.1. SUPAPolicyMetadataDecorator Attributes Currently, no attributes are defined for the SUPAPolicyMetadataDecorator class. 5.18.2. SUPAPolicyMetadataDecorator Relationships This class inherits the relationships of the SUPAPolicyMetadata class; see section 5.16.2. It also defines a single aggregation, - HasSUPAMetadataDecorator, which is used to implement the decorator + SUPAHasMetadataDecorator, which is used to implement the decorator pattern, as described in the following subsections. -5.18.2.1. The Aggregation "HasSUPAMetadataDecorator" +5.18.2.1. The Aggregation "SUPAHasMetadataDecorator" This is an optional aggregation, and is part of a decorator pattern. It is used to enable a concrete instance of a SUPAPolicyMetadataDecorator to dynamically add behavior to a SUPAPolicyConcreteMetadata object instance. The semantics of this - aggregation are defined by the HasSUPAMetadataDecoratorDetail + aggregation are defined by the SUPAHasMetadataDecoratorDetail association class. It is recommended that this aggregation be part of a conformant implementation. The multiplicity of this aggregation is 0..1 on the aggregate (SUPAPolicyMetadataDecorator) side and 1..n on the part (SUPAPolicyMetadata) side. This means that if this aggregation is defined, then at least one SUPAPolicyMetadata object (e.g., a concrete subclass of SUPAPolicyMetadataDecorator) must also be instantiated and wrapped by this SUPAPolicyConcreteMetadata object instance. The semantics of this aggregation are defined by the - HasSUPAMetadataDecoratorDetail association class. + SUPAHasMetadataDecoratorDetail association class. -5.18.2.2. The Association Class "HasSUPAMetadataDecoratorDetail" +5.18.2.2. The Association Class "SUPAHasMetadataDecoratorDetail" This is an optional concrete association class, and defines the - semantics of the HasSUPAMetadataDecorator aggregation. The purpose + semantics of the SUPAHasMetadataDecorator aggregation. The purpose of this class is to use the Decorator pattern to determine which SUPAPolicyMetadataDecorator object instances, if any, are required to augment the functionality of the SUPAPolicyConcreteMetadata object instance that is being used. It is recommended that this association class be part of a conformant implementation. Attributes for this association class will be defined in a future version of this document. @@ -4089,88 +4143,165 @@ attribute is 0-2, then the value of this attribute is not applicable. Otherwise, the value of this class attribute defines how to interpret the text in the supaPolAccessPrivilegeModelRef class attribute. Values include: 0: Undefined 1: URI 2: GUID 3: UUID 4: FQDN + 5: FQPN 5.20. The Concrete Class "SUPAPolicyVersionMetadataDef" This is an optional concrete class that defines versioning information, in the form of metadata, that can be added to a SUPAPolicyObject. This enables all or part of a standardized description and/or specification of version information for a given SUPAPolicyObject to be easily changed at runtime by wrapping an object instance of the SUPAPolicyConcreteMetadata class (or its subclass) with all or part of this object. 5.20.1. SUPAPolicyVersionMetadataDef Attributes - Version information is defined in a generic format as follows: + Version information is defined in a generic format based on the + Semantic Versioning Specification [18] as follows: - ... + ..[][] + + where the first three components (major, minor, and patch) MUST be + present, and the latter two components (pre-release and build- + metadata) MAY be present. A version number MUST take the form + .., where , , and are + each non-negative integers that MUST NOT contain leading zeros. + In addition, the value of each of these three elements MUST + increase numerically. In this approach: - o supaVersionMajor denotes a major new release - o supaVersionMinor denotes an incremental release, that adds new - features and/or bug fixes to a major release - o supaVersionRelType denotes the type of release (e.g., internal, - alpha, production) - o supaVersionRelTypeNum denotes an incremental release of ability - particular type + o supaVersionMajor denotes a new release; this number MUST be + incremented when either changes are introduced that are not + backwards-compatible, and/or new functionality not previously + present is introduced - Currently, the SUPAPolicyVersionMetadataDef class defines three + o supaVersionMinor denotes a minor release; this number MUST be + incremented when new features and/or bug fixes to a major + release that are backwards-compatible are introduced, and/or + if any features are marked as deprecated + o supaVersionPatch denotes a version that consists ONLY of bug + fixes, and MUST be incremented when these bug fixes are Not + backwards-compatible + + When multiple versions exist, the following rules define their + precedence: + + 1. Precedence MUST be calculated by separating the version into + major, minor, patch, and pre-release identifiers, in that + order. Note that build-metadata is NOT used to calculated + precedence. + 2. Precedence is determined by the first difference when + comparing each of these identifiers, from left to right, + as follows: + a. Major, minor, and patch versions are always compared + numerically (e.g., 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1) + b. When major, minor, and patch are equal, a pre-release + version has LOWER precedence than a normal version + (e.g., 1.0.0-alpha < 1.0.0) + c. Precedence for two pre-release versions with the same + major, minor, and patch version MUST be determined by + comparing each dot separated identifier from left to + right until a difference is found as follows: + - identifiers consisting only of digits are compared + numerically and identifiers with letters and/or + hyphens are compared lexically in ASCII sort order + - Numeric identifiers always have lower precedence + than non-numeric identifiers + - A larger set of pre-release fields has a higher + precedence than a smaller set, if all of the + preceding identifiers are equal + 3. Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha-beta + < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-rc.1 < 1.0.0. + + Currently, the SUPAPolicyVersionMetadataDef class defines five attributes; these are described in the following subsections. 5.20.1.1. The Attribute "supaVersionMajor" - This is an optional string attribute, and contains a string - (typically representing an integer) indicating a significant - increase in functionality is present in this version. + This is a mandatory string attribute, and contains a string + representation of an integer that is greater than or equal to zero. + It indicates that a significant increase in functionality is + present in this version. It MAY also indicate that this version has + changes that are NOT backwards-compatible; this MAY be denoted in + the supaVersionBuildMetadata class attribute. + + The special string "0.1.0" is for initial development that MUST + NOT be considered stable. Improvements to this initial version, + before they are released to the public, are denoted by incrementing + the minor and patch version numbers. + + The major version X (i.e., X.y.z, where X > 0) MUST be incremented + if any backwards incompatible changes are introduced. It MAY + include minor and patch level changes. The minor and patch version + numbers MUST be reset to 0 when the major version number is + incremented. 5.20.1.2. The Attribute "supaVersionMinor" - This is an optional string attribute, and contains a string - (typically representing an integer) indicating that this release - contains a set of features and/or bug fixes that collectively do - not warrant incrementing the supaVersionMajor attribute. This - attribute should only be used if the supaVersionMajor attribute - is NOT NULL. + This is a mandatory string attribute, and contains a string + representation of an integer that is greater than or equal to zero. + It indicates that this release contains a set of features and/or + bug fixes that MUST be backwards-compatible. -5.20.1.3. The Attribute "supaVersionRelType" + The minor version Y (i.e., x.Y.z, where x > 0) MUST be incremented + if new, backwards-compatible changes are introduced. It MUST be + incremented if any features are marked as deprecated. It MAY be + incremented if new functionality or improvements are introduced. + It MAY include patch level changes. The patch version number MUST + be reset to 0 when the minor version number is incremented. - This is an optional integer attribute, and contains a string - defining the type of release of this SUPAPolicyObject. Values - include: +5.20.1.3. The Attribute "supaVersionPatch" - 0: undefined - 1: internal - 2: alpha - 3: beta - 4: release candidate - 5: production - 6: maintenance + This is a mandatory string attribute, and contains a string + representation of an integer that is greater than or equal to zero. + It indicates that this version contains ONLY bug fixes. - This attribute should only be used if the supaVersionMinor - attribute is NOT NULL. + The patch version Z (i.e., x.y.Z, where x > 0) MUST be incremented + if new, backwards-compatible changes are introduced. A bug fix is + defined as an internal change that fixes incorrect behavior. -5.20.1.4. The Attribute "supaVersionRelTypeNum" +5.20.1.4. The Attribute "supaVersionPreRelease" This is an optional string attribute, and contains a string - defining the incremental release associated with the - supaVersionRelType class attribute. This attribute should only be - used if the supaVersionRelType attribute is NOT NULL. + defining the pre-release version. + + A pre-release version MAY be denoted by appending a hyphen and a + series of dot-separated identifiers immediately following the patch + version. Identifiers MUST comprise only ASCII alphanumerics and a + hyphen. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT + include leading zeroes. Pre-release versions have a lower + precedence than the associated normal version. A pre-release version + indicates that the version is unstable and might not satisfy the + intended compatibility requirements as denoted by its associated + normal version. Examples include: 1.0.0-alpha, + 1.0.0-alpha.1, 1.0.0-0.3.7, and 1.0.0-x.7.z.92. + +5.20.1.5. The Attribute "supaVersionBuildMetadata" + + This is an optional string attribute, and contains a string defining + the build metadata. Build metadata MAY be denoted by appending a + plus sign and a series of dot-separated identifiers immediately + following the patch or pre-release version. Identifiers MUST be + made up of only ASCII alphanumerics and a hyphen. Identifiers + MUST NOT be empty. Build metadata SHOULD be ignored when determining + version precedence. Examples include: 1.0.0.-alpha+1, + 1.0.0+20130313144700, and 1.0.0-beta+exp.sha.5114f85. 6. SUPA ECAPolicyRule Information Model This section defines the classes, attributes, and relationships of the SUPA ECAPolicyRule Information Model (EPRIM). Unless otherwise stated, all classes (and attributes) defined in this section were abstracted from DEN-ng [2], and a version of them are in the process of being added to [5]. 6.1. Overview @@ -4198,26 +4329,26 @@ | | | +---SUPABooleanClause (6.7) | | | +---SUPAECAPolicyRuleAtomic (6.8) | | | +---SUPAECAPolicyRuleComposite (6.9) | +---SUPAPolicyComponentDecorator (5.9) | +---SUPAECAComponent(6.10) - | | - | +---SUPAPolicyEvent (6.11) - | | - | +---SUPAPolicyCondition (6.12) - | | - | +---SUPAPolicyAction (6.13) + | + +---SUPAPolicyEvent (6.11) + | + +---SUPAPolicyCondition (6.12) + | + +---SUPAPolicyAction (6.13) Figure 23. The EPRIM Class Hierarchy Specifically, the EPRIM specializes the SUPAPolicyStructure class class to create a SUPAECAPolicyRule (see sections 6.4 - 6.6); it also specializes two subclasses of the SUPAPolicyComponentStructure class to create two new sets of policy components. These two SUPAPolicyComponentStructure subclasses are: o a new subclass of SUPAPolicyClause, called SUPABooleanClause @@ -4414,21 +4546,31 @@ When defined in an information model, each of the event, condition, and action clauses MUST be represented as an aggregation between a SUPAECAPolicyRule (the aggregate) and a set of event, condition, or action objects (the components). However, a data model MAY map these definitions to a more efficient form (e.g., by flattening these three types of object instances, along with their respective aggregations, into a single object instance). The composite pattern [3] is applied to the SUPAECAPolicyRule class, enabling its (concrete) subclasses to be used as either a - stand-alone policy rule or as a hierarchy of policy rules. This is + stand-alone policy rule or as a hierarchy of policy rules. + SUPAECAPolicyRuleComposite and SUPAECAPolicyRuleAtomic both + inherit from SUPAECAPolicyRule. This means that they are both + a type of SUPAECAPolicyRule. Hence, the HasSUPAECAPolicyRule + aggregation enables a particular SUPAECAPolicyRuleComposite + object to aggregate both SUPAECAPolicyRuleComposite as well as + SUPAECAPolicyRuleAtomic objects. In contrast, a + SUPAECAPolicyRuleAtomic can NOT aggregate either a + SUPAECAPolicyRuleComposite or a SUPAECAPolicyRuleAtomic. + SUPAECAPolicyRuleAtomic and SUPAECAPolicyRuleComposite are + defined in sections 6.5 and 6.6, respectively. This is shown in Figure 25. A 1..n +-------------------+ \| | +--------------- + SUPAECAPolicyRule | | /| | | +--------+----------+ | / \ | SUPAHasECAPolicyRule I @@ -4439,31 +4581,20 @@ | I I / \ I I A I I C \ / 0..1 I C I +-----+---------+----------+ +-----------+-----------+ |SUPAECAPolicyRuleComposite| |SUPAECAPolicyRuleAtomic| +--------------------------+ +-----------------------+ Figure 25. The Composite Pattern Applied to a SUPAECAPolicyRule - SUPAECAPolicyRuleComposite and SUPAECAPolicyRuleAtomic both - inherit from SUPAECAPolicyRule. This means that they are both - a type of SUPAECAPolicyRule. Hence, the HasSUPAECAPolicyRule - aggregation enables a particular SUPAECAPolicyRuleComposite - object to aggregate both SUPAECAPolicyRuleComposite as well as - SUPAECAPolicyRuleAtomic objects. In contrast, a - SUPAECAPolicyRuleAtomic can NOT aggregate either a - SUPAECAPolicyRuleComposite or a SUPAECAPolicyRuleAtomic. - SUPAECAPolicyRuleAtomic and SUPAECAPolicyRuleComposite are - defined in sections 6.5 and 6.6, respectively. - Note that the HasSUPAECAPolicyRule aggregation is defined by the HasSUPAECAPolicyRuleDetail association class; both are defined in sections 6.6.2 and 6.6.3, respectively. 6.4.1. SUPAECAPolicyRule Attributes Currently, the SUPAECAPolicyRule defines two attributes, as described in the following subsections. 6.4.1.1. The Attribute "supaECAPolicyRulePriority" @@ -4593,22 +4724,22 @@ (SUPAECAPolicyRule) side. This means that if this aggregation is defined, then at least one SUPAECAPolicyRule object (which may be either an instance of a SUPAECAPolicyRuleAtomic or a SUPAECAPolicyRuleComposite class) must also be instantiated and aggregated by this particular SUPAECAPolicyRuleComposite object. The semantics of this aggregation are defined by the SUPAHasECAPolicyRuleDetail association class. 6.6.3. The Association Class "SUPAHasECAPolicyRuleDetail" - This is an optional association class, and defines the semantics - of the SUPHasECAPolicyRule aggregation. This enables the + This is an optional concrete association class, and defines the + semantics of the SUPHasECAPolicyRule aggregation. This enables the attributes and relationships of the SUPAHasECAPolicyRuleDetail class to be used to constrain which SUPHasECAPolicyRule objects can be aggregated by this particular SUPAECAPolicyRuleComposite object instance. 6.6.3.1. The Attribute "supaECAPolicyIsDefault" This is an optional Boolean attribute. If the value of this attribute is true, then this SUPAECAPolicyRule is a default policy, and will be executed if no other SUPAECAPolicyRule @@ -4760,33 +4892,33 @@ (SUPABooleanClauseComposite) side, and 1..n on the part (SUPABooleanClause) side. This means that one or more SUPABooleanClauses are aggregated and used to define this SUPABooleanClauseComposite object. The 0..1 cardinality on the SUPABooleanClauseComposite side is necessary to enable SUPABooleanClauses to exist (e.g., in a PolicyRepository) before they are used by a SUPABooleanClauseComposite. The semantics of this aggregation is defined by the SUPAHasBooleanClauseDetail association class. -6.9.3. The Concrete Class "SUPAHasBooleanClauseDetail" +6.9.3. The Association Class "SUPAHasBooleanClauseDetail" - This is a mandatory association class that defines the semantics - of the SUPAHasBooleanClause aggregation. This enables the + This is a mandatory concrete association class that defines the + semantics of the SUPAHasBooleanClause aggregation. This enables the attributes and relationships of the SUPAHasBooleanClauseDetail class to be used to constrain which SUPABooleanClause objects can be aggregated by this particular SUPABooleanClauseComposite object instance. 6.9.3.1. SUPAHasBooleanClauseDetail Attributes The SUPAHasBooleanClauseDetail class currently does not define - any attributes at this time. + any attributes. 6.10. The Abstract Class "SUPAECAComponent" This is a mandatory abstract class that defines three concrete subclasses, one each to represent the concepts of reusable events, conditions, and actions. They are called SUPAPolicyEvent, SUPAPolicyCondition, and SUPAPolicyAction, respectively. SUPAECAComponents provide two different ways to construct SUPAPolicyClauses. The first is for the SUPAECAComponent to be @@ -4828,27 +4960,27 @@ section 6.10 above). 6.10.2. SUPAECAComponent Relationships No relationships are currently defined for this class. 6.11. The Concrete Class "SUPAPolicyEvent" This is a mandatory concrete class that represents the concept of an Event that is applicable to a policy management system. Such - an Event is defined as any important occurrence in time of a - change in the system being managed, and/or in the environment of - the system being managed. SUPAPolicyEvents can be used as part of - a SUPAPolicyClause; this is done by specifying the attribute name - and value of an Event in the supaPolicyEventData attribute of the - SUPAPolicyEvent. This enables event attributes to be used as part - of a SUPAPolicyClause. + an Event is defined as anything of importance to the management + system (e.g., a change in the system being managed and/or its + environment) occuring on a time-axis (as defined in [19]). + SUPAPolicyEvents can be used as part of a SUPAPolicyClause; this + is done by specifying the attribute name and value of an Event in + the supaPolicyEventData attribute of the SUPAPolicyEvent. This + enables event attributes to be used as part of a SUPAPolicyClause. Note: this class does NOT model the "raw" occurrences of Events. Rather, it represents the concept of an Event object whose class attributes describe pertinent attributes that can trigger the evaluation of a SUPAECAPolicyRule. 6.11.1. SUPAPolicyEvent Attributes Currently, five attributes are defined for the SUPAPolicyEvent class, which are described in the following subsections. @@ -4894,24 +5026,26 @@ This is a mandatory attribute that defines an array of strings. Each string in the array represents an attribute name and value of an Event object. The format of each string is defined as name:value. The 'name' part is the name of the SUPAPolicyEvent attribute, and the 'value' part is the value of that attribute. Note: [1..n] means that this is a multi-valued property that has at least one (and possibly more) attributes. For example, if this value of this attribute is: - {(startTime:0800), (endTime:1700)} + {(startTime:0800), (endTime:1700), (date:2016-05-11), + (timeZone:-08:00)} - then this attribute contains two properties, called startTime and - endTime, whose values are 0800 and 1700, respectively. + then this attribute contains four properties, called startTime, + endTime, date, and timeZone whose values are 0800, 1700, May 11 + 2016, and Pacific Standard Time, respectively. Note that the supaPolicyEventEncoding class attribute defines how to interpret the value portion of this attribute. This attribute works with another class attribute, called supaPolicyEventEncoding, which defines how to interpret this attribute. These two attributes form a tuple, and together enable a machine to understand the syntax and value of the data carried by the object instance of this class. @@ -4957,20 +5091,29 @@ to understand the syntax and value of the content of this SUPAPolicyCondition object. Values include: 0: undefined 1: String 2: OCL 2.x 3: OCL 1.x 4: QVT 1.2 - Relations Language 5: QVT 1.2 - Operational language 6: Alloy + 7: English text + + Enumerations 1-3 are dedicated to OCL (with OCL 2.4 being the + latest version as of this writing). QVT defines a set of languages + (the two most powerful and useful are defined by enumerations 4 + and 5). Alloy is a language for describing constraints, and uses a + SAT solver to guarantee correctness. Note that enumeration 7 + (English text) is not recommended (since it is informal, and hence, + not verifiable), but included for completeness. 6.12.2. SUPAPolicyEvent Relationships No relationships are currently defined for this class. It inherits the relationships defined by the SUPAPolicyComponentDecorator (see section 5.7.3.). 6.13. The Concrete Class "SUPAPolicyAction" This is a mandatory concrete class that represents the concept of @@ -5061,31 +5204,32 @@ 8. Security Considerations This will be defined in the next version of this document. 9. IANA Considerations This document has no actions for IANA. 10. Contributors - The following people contributed significantly to the previous - versions of this document: + The following people contributed to creating this document, and are + listed in alphabetical order: - - Jason Coleman (Cisco) + Jason Coleman 11. Acknowledgments This document has benefited from reviews, suggestions, comments and proposed text provided by the following members, listed in - alphabetical order: Andy Bierman, Bob Natale, Fred Feisullin, - Georgios Karagiannis, Liu (Will) Shucheng, Marie-Jose Montpetit. + alphabetical order: Andy Bierman, Bert Wijnen, Bob Natale, Dave + Hood, Fred Feisullin, Georgios Karagiannis, Liu (Will) Shucheng, + Marie-Jose Montpetit. 12. References This section defines normative and informative references for this document. 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. @@ -5164,37 +5308,59 @@ [13] Liskov, B.H., Wing, J.M., "A Behavioral Notion of subtyping", ACM Transactions on Programming languages and Systems, 16 (6): 1811 - 1841, 1994 [14] Martin, R.C., "Agile Software Development, Principles, Patterns, and Practices", Prentice-Hall, 2002, ISBN: 0-13-597444-5 [15] Halpern, J., Strassner, J., "Generic Policy Data Model for Simplified Use of Policy Abstractions (SUPA)" - draft-halpern-supa-generic-policy-data-model-01, - April 15, 2016 + draft-ietf-supa-generic-policy-data-model-00, + July 13, 2016 + + [16] Wang, Y., Esposito, F., Matta, I., Day, J., "RINA: An + Architecture for Policy-based Dynamic Service + Management", Tech Report BUCS-TR-2013-014, 2013 + + [17] Meyer, B., "Object-Oriented Software Construction", + Prentice Hall, second edition, 1997 ISBN 0-13-629155-4 + + [18] http://semver.org/ + + [19] ISO/IEC:2004(E), "Data elements and interchange + formats -- Information interchange -- Representation + of dates and times", 2004 Authors' Addresses John Strassner Huawei Technologies 2330 Central Expressway Santa Clara, CA 95138 USA Email: john.sc.strassner@huawei.com Joel Halpern Ericsson P. O. Box 6049 Leesburg, VA 20178 Email: joel.halpern@ericsson.com + Sven van der Meer + LM Ericsson Ltd. + Ericsson Software Campus + Garrycastle + Athlone + N37 PV44 + Ireland + Email: sven.van.der.meer@ericsson.com + Appendix A. Brief Analyses of Previous Policy Work This appendix describes of some of the important problems with previous IETF policy work., and describes the rationale for taking different design decisions in this document. A.1. PolicySetComponent vs. SUPAPolicyStructure The ability to define different types of policy rules is not present in [RFC3060] and [RFC3460], because both are based on [4], @@ -5305,22 +5471,22 @@ second is that PolicyGroups cannot aggregate PolicyRules (which again implies that PolicyGroups are not needed). Furthermore, there are no mechanisms defined in the [RFC3460] model to prevent loops of PolicyRules. This is a problem, because EVERY PolicyRule and PolicyGroup inherits this recursive aggregation. This is why this document uses the composite pattern. First, this pattern clearly shows what object is aggregating what other - object (i.e., a SUPAECAPolicyRuleAtomic cannot aggregate ability - SUPAECAPolicyRuleComposite). Second, it does not allow ability + object (i.e., a SUPAECAPolicyRuleAtomic cannot aggregate a + SUPAECAPolicyRuleComposite). Second, it does not allow a SUPAECAPolicyRule to be aggregated by another SUPAECAPolicyRule (this is discussed more in the following subsection). A.3.1. Sub-rules Sub-rules (also called nested policy rules) enable a policy rule to be contained within another policy rule. These have very complex semantics, are very hard to debug, and provide limited value. They also require a complex set of aggregations (see section A.4.). @@ -5589,14 +5755,10 @@ [RFC3460] has no symmetry in how it defines variables and values. In contrast, this document recognizes that variables and values are just terms in a clause; hence, the only difference in the definition of the SUPAPolicyVariable and SUPAPolicyValue classes is that the content attribute in the former is a single string, whereas the content attribute in the latter is a string array. In particular, the semantics of both variables and values are defined using the decorator pattern, along with the attributes of the SUPAPolicyComponentDecorator and the SUPAHasDecoratedPolicyComponentDetail classes. - -Appendix B. Mathematical Logic Terminology and Symbology - -Appendix C. SUPA Logic Statement Information Model