idnits 2.17.1 draft-brunner-policy-core-ext-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([PQIM]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 17, 2000) is 8554 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'String' is mentioned on line 120, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'PCIM' -- Possible downref: Non-RFC (?) normative reference: ref. 'PQIM' -- Possible downref: Non-RFC (?) normative reference: ref. 'PMPLS' -- Possible downref: Non-RFC (?) normative reference: ref. 'PIPSEC' Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT M. Brunner 3 J. Quittek 4 Expires in six months NEC Corporation 6 November 17, 2000 8 Policy Framework Core Info Model Extensions 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This memo should help starting the discussion on extensions of the 34 Policy Framework Core Information Model (PCIM). It does not replace 35 nor change concepts used in PCIM, but tries to add concepts, which 36 could help different application areas to define policies more easily 37 by reusing some of the concepts proposed in this draft. The draft 38 basically tries to generalize concepts introduced by other drafts 39 such as the Policy Framework QoS Information Model [PQIM]. The focus 40 lies in means for specifying general conditions and actions. 41 Additionally, group ordering, events, and variables are introduced. 43 1. Introduction 45 PCIM as proposed today is a well defined as a high-level information 46 model for policies. However, many concepts are useful for the simple 47 case, whereas more complicated policies poses problems using the 48 classes available. The other problem lies in a set of application 49 areas using the basic model and adapt and enhance it to area specific 50 needs. It turns out that many concepts are developed again and 51 again, e.g., filters, variables, simple conditions etc. 53 The goal of this draft is to extend PCIM with general constructs, 54 which may be used in other areas. Basically, they center around 55 generic definition of conditions and actions with the knowlege of the 56 structure of the modeling language. They are heavily influenced by 57 constructs used in [PQIM], [PMPLS], and [PIPSEC]. 59 The draft in its current state is far from being complete. e.g., the 60 definition of class do not contain any formal property definition 61 yet. However, the proposed concepts and the list of open issues 62 should help discussing useful extensions to the core information 63 model. 65 Other authors are very welcome to contribute to make the policy 66 framework core information model useful in various areas. 68 2. PolicyGroup Ordering 70 In PCIM, the policyRule has a property Priority, which allows a 71 manager to give a rule priority over others. However, it is not 72 specified what the scope of the priority is, in the system or in the 73 group. 75 We propose a class OrderedPolicyGroup, which has a property priority 76 as well. This allows for prioritizing groups over other groups. 77 Furthermore, groups within the OrderPolicyGroup are ordered via the 78 rule's or group's priority property. Additionally, the scope of the 79 priority is only within that group, not globally as it could be read 80 in PCIM. Groups in OrderPolicyGroups not being of type 81 OrderPolicyGroup or a derivative of it, have the least priority. 83 Note, that the functionality could be placed in the aggregation 84 PolicyGroupinPolicyGroup as well. (What is preferred?) 86 NAME OrderedPolicyGroup 87 DERIVED FROM PolicyGroup (defined in [PCIM]) 88 ABSTRACT False 89 PROPERTIES Priority [int] 91 3. Conditions 93 3.1. BasicPolicyCondition 95 This class refines the basic structure of the policyCondition class 96 defined in [PCIM] by using the triplet , and 97 . The SimplePolicyCondition of PQIM is similar in 98 structure, and a special case of this one, where the right variable 99 has a constant value. 101 The operator is relational and the binding is given by the types of 102 both sides. Whether the operator is statically of dynamically bound 103 (variable type or value type) is for further study. 105 If one of the variables evaluate to undefined, the condition 106 evaluates to false. 108 What kind of RelOperators do we want? 110 For example, the RelOperator property values may be 111 - equal, notequal, lessthan, greaterthan, lessthanequal, 112 greaterthanequal, for totally ordered values 113 - startswith, endswith, equals, contains, for strings 114 - contains, in, equals, includes, intersects, for sets 116 NAME BasicPolicyCondition 117 DERIVED FROM PolicyCondition (defined in [PCIM]) 118 ABSTRACT False 119 PROPERTIES firstVariable [ref PolicyVariable], 120 RelOperator [String], 121 secondVariable [ref PolicyVariable] 123 3.2. Class PolicyObjectTypeSelector 125 Basically, PCIM uses the policyRole property in the PolicyRule class 126 in order to select a set of objects the rule should apply to. The 127 selection may be refined by conditions. 129 This kind of condition is special in the sense, that it compares the 130 set of objects available in the context (basically specified by the 131 role) whether they are of the type specified in this condition. So 132 the rule containing this selector in the condition list operates only 133 on objects of the specific type. This is very convenient, because it 134 allows a policy designer to specify the actions with the knowledge, 135 that only objects of a specific type will pass the condition. 137 NAME PolicyObjectTypeSelector 138 DERIVED FROM policyCondition (defined in [PCIM]) 139 ABSTRACT False 140 PROPERTIES SelectorClassName 142 3.3. Class PolicyAssociatedObjectSelector 143 The PolicyAssociatedObjectSelector provides means to select objects 144 only if they are associated with objects of a certain type and the 145 AssocObjectPolicyCondition evaluates to true. 147 Note that the class has a association to PolicyConditions 148 (PolicyConditionInAssocObjectSelector). With that it is possible to 149 specify again a PolicyAssociationObjectSelector as the condition. 150 This allows to recursivly hop throught associated object. 152 Furthermore, note that the condition within this selector has a 153 different context, compared to the condition itself. Conceptually, 154 the PolicyAssociatedObjectSelector takes a set of objects and checks 155 for all of them, whether they are in an association of type 156 AssociationClassName where the object in this association is of type 157 AssocObjectClassName and the policy condition evaluates to true. 159 NAME PolicyAssociatedObjectSelector 160 DERIVED FROM policyCondition (defined in [PCIM]) 161 ABSTRACT False 162 PROPERTIES AssociationClassName, AssocObjectClassName, 164 3.4. Association PolicyConditionInAssocObjectSelector 166 This association ties together the PolicyAssociatedObjectSelector 167 with a PolicyCondition. 169 NAME PolicyConditionInAssocObjectSelector 170 ABSTRACT False 171 PROPERTIES selector [ref PolicyObjectTypeSelector[0..1]], 172 condition [ref PolicyCondition[0..1]] 174 4. Variables 176 Variables may be global or local. We propose to use only local 177 variables, which means a variable is always used in the context of an 178 object. 180 4.1. Class PolicyAttributeVariable 182 The PolicyAttributeVariable has an attribute name and a class name as 183 properties. The class name specifies in what scope the attribute name 184 is valid. The class name is only used in cases, where attribute 185 names are not globally unique. 187 Conceptually, if the variable is used in a condition, it evaluates to 188 the value of the attribute named by AttributeName. Note, that this 189 variable may be undefined. This means the basic condition it is 190 contained in evaluates to false. 192 NAME PolicyAttributeVariable 193 DERIVED FROM Policy (defined in [PCIM]) 194 ABSTRACT False 195 PROPERTIES AttrClassName, 196 AttributeName 198 5. Actions 200 5.1. Class PolicyAttributeSetAction 202 The AttributeSetAction is used to set or change a value of an 203 attribute. The action has again a class name and an attribute name as 204 property. The class name specifies what type of objects to set, and 205 the attribute name specifies what attribute to change. Note again, 206 in case of globally unique attribute names, the class name is not 207 used in the action. 209 The semantic behind the AttributeSetAction is, that setting the 210 attribute of an object results in the configuration of the real 211 object, represented by that object. 213 If the attribute is not compatible with the type of the value, the 214 action is not performed. 216 NAME PolicyAttributeSetAction 217 DERIVED FROM PolicyAction (defined in [PCIM]) 218 ABSTRACT False 219 PROPERTIES AttrSetClassName, 220 AttributeSetName, 221 value 223 6. Events 225 6.1. PolicyEvent 227 An event is a mean for triggering a rule to be evaluated. The source 228 of the event may be in- or outside of the policy engine. Therefore, 229 an event has in its basic version no source identification 230 associated. However, classes derived from the base class may add the 231 source, if needed. The PolicyEvent has a time and date when it 232 happened. It has a name. The event name is used to differ the events. 233 It could be usefule to add a context string, which make different 234 policy models more independet and less error prone, because of global 235 name spaces. 237 The semantic behind the event is open, but see the next section for 238 conditions on events. However, typically the name will also define 239 the semantic of the event. 241 NAME PolicyEvent 242 DERIVED FROM Policy (defined in [PCIM]) 243 ABSTRACT False 244 PROPERTIES event_time, 245 event_date, 246 event_name 248 6.2. PolicyEventCondition 250 The event condition evaluates to true if an event happened with the 251 name specified in cond_event_name. In general, there is no time 252 constrain defined, until when the rule containing the event condition 253 needs to be evaluated. But depending on the execution environment of 254 the policy rules, this may immediately trigger the evaluation of the 255 policy rule containing the event condition. 257 After evaluating all rules in the system, containing the event 258 condition in its condition tree, the event does not exist anymore, 259 and the condition is evaluating to false for all further evaluations 260 until the event is created once more. 262 Note that, with this definition of the semantic, we do not run into 263 problems of nested conditions and rules, which contain associations 264 to the same event condition. However, more advanced semantics are 265 possible, but may produce difficult to implement semantic. 267 NAME PolicyEventCondition 268 DERIVED FROM PolicyCondition (defined in [PCIM]) 269 ABSTRACT False 270 PROPERTIES cond_event_name 272 6.3. PolicyEventCreateAction 274 The PolicyEventCreateAction creates an event with a certain name. 275 This may be useful in cases, where you have multi-level policy 276 systems running in the same execution environment. 278 NAME PolicyEventCreateAction 279 DERIVED FROM PolicyAction (defined in [PCIM]) 280 ABSTRACT False 281 PROPERTIES create_event_name 283 7. Security Considerations 285 The security considerations for this document are the same as those 286 of the [PCIM] and are not further addressed in this version of the 287 draft. 289 8. Open Issues 291 8.1. Multi-Object Selectors 293 There are many cases where you want to select two or more objects, in 294 order to associate the two objects, or all objects in a set to each 295 other. 297 8.2. Creation of Objects 299 It could be very beneficial for policies to create objects just with 300 the type information, and set the attributes afterwards. However, 301 what is the semantic of the creation of an object? 303 8.3. Creation of Associations 305 Section 8.1, already mention the problem of multi-object selection. 306 One goal could be the creation of a new association, between these 307 objects. This action would not be difficult to specify, but it is 308 not useful without the multi-object selection. 310 8.4. Modification of Associations 312 Until now, we have no means other than area specific actions, which 313 allow a policy designer to implement the modification of an 314 association, or its properties. 316 8.5. Expressions 318 How can we set or change attributes and parameters of action by an 319 expression (e.g., set bandwidth to 50% of the existing one) 321 8.6. IP specific filters 323 Filters are used many times, why not specifing it in the PCIM 324 extension. 326 9. References 328 [PCIM] B. Moore, E. Ellesson, J. Strassner, "Policy Core Information 329 Model -- Version 1 Specification", Internet Draft, 330 , May, 2000 332 [PQIM] Y. Snir, Y. Ramberg, J. Strassner, R. Cohen, "Policy 333 Framework QoS Information Model", Internet draft, 334 , April 2000 336 [PMPLS] K. Isoyama, M. Brunner, M. Yoshida, J. Quittek, R. Chadha, 337 A. Poylisher, G. Mykoniatis, A. Kind,F. Reichmeyer, 338 "Policy Framework MPLS Information Model for QoS and TE" 339 , December 2000. 341 [PIPSEC] J. Jason, "IPsec Configuration Policy Model", Internet draft 342 , July 2000. 344 10. Authors' Addresses 346 Marcus Brunner, Juergen Quittek 347 NEC Europe Ltd. 348 C&C Research Laboratories 349 Adenauerplatz 6 350 D-69115 Heidelberg, Germany 351 Phone: +49 (0)6221 905110 352 Fax: +49 (0)6221 9051155 353 Email: [brunner|quittek]@ccrle.nec.de 355 Full Copyright Statement 357 Copyright (C) The Internet Society (2000). All Rights Reserved. 359 This document and translations of it may be copied and furnished to 360 others, and derivative works that comment on or otherwise explain it 361 or assist in its implmentation may be prepared, copied, published and 362 distributed, in whole or in part, without restriction of any kind, 363 provided that the above copyright notice and this paragraph are 364 included on all such copies and derivative works. However, this 365 document itself may not be modified in any way, such as by removing 366 the copyright notice or references to the Internet Society or other 367 Internet organizations, except as needed for the purpose of 368 developing Internet standards in which case the procedures for 369 copyrights defined in the Internet Standards process must be 370 followed, or as required to translate it into languages other than 371 English. 373 The limited permissions granted above are perpetual and will not be 374 revoked by the Internet Society or its successors or assigns. 376 This document and the information contained herein is provided on an 377 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 378 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDIN BUT 379 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 380 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 381 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.