INTERNET-DRAFT                                  Andreas Polyrakis 
Resource Allocation Working Group (RAP)         University of Toronto 
Intended Category: Standards Track              Raouf Boutaba 
Expires: October, 2001                          University of Waterloo 
                                      
                                      
                 The Meta-Policy Information Base (M-PIB) 
                                      
                       draft-polyrakis-mpib-00.txt 
                                      
                                      
Status of this Memo 
    
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC2026.  Internet-Drafts are 
   working documents of the Internet Engineering Task Force (IETF), its 
   areas, and its working groups.  Note that other groups may also 
   distribute working documents as Internet-Drafts. 
    
   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". 
    
   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt 
    
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html. 


















     
   R.Boutaba, A.Polyrakis  Internet-Draft, expires Oct.2001   [page 1] 
                   The Meta-Policy Information Base         April 2001 
    
Abstract 
    
   This document introduces the concept of COPS-PR meta-policies and 
   defines the Meta-Policy Information Base.  
    
   The meta-policy PIB does not introduce a new policing area. On the 
   contrary, it defines some provisioning classes that can be used by 
   all other PIBs, in order to add meta-policing functionality into 
   them. The meta-policy PIB, like every PIB, stores policing 
   information that controls some policing mechanisms of the device. 
   However, unlike other PIBs, the policing mechanism controlled by the 
   meta-policy PRCs is the PIB itself. The data maintained by these 
   PRCs implement policies that control other policies, this is why 
   they are called meta-policies. 
    
   Meta-policies is an attempt to push intelligence towards the COPS-PR 
   PEPs and overcome the rigidity of their PIBs. Through meta-policies, 
   more policing information and functionality can be pushed towards 
   the PEP, less interaction with the PDP is necessary and less network 
   and PDP resources are consumed. The PEP is more independent and it 
   can bear longer PDP absences. 
    
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 [RFC-2119]. 
    
    
    
Glossary - Terminology 
    
   This document follows the terminology of [P-TERM]. However, the most 
   commonly used terms are cited again here: 
    
   PDP    Policy Decision Point.  
   PEP    Policy Enforcement Point. 
   PRC    Provisioning Class. See [COPS-PR]. 
   PRI    Provisioning Instance. See [COPS-PR]. 
   PIB    Policy Information Base. See [COPS-PR]. 
   PRID   Provisioning Instance Identifier.  Uniquely identifies an  
          instance of a PRC. See [COPS-PR]. 
    
 










     
   R.Boutaba, A.Polyrakis  Internet-Draft, expires Oct.2001   [page 2] 
                   The Meta-Policy Information Base         April 2001 
    
Table of Contents 
    
   Status of this Memo...............................................1 
   Abstract..........................................................2 
   Conventions used in this document.................................2 
   Glossary - Terminology............................................2 
   Table of Contents.................................................3 
   1.Introduction....................................................4 
   1.1.PIB Limitations...............................................4 
   1.2.The concept of Meta-Policies..................................4 
   1.3.Why Meta-Policies?............................................5 
   2.Formal Definition...............................................6 
   2.1.Meta-Policies.................................................6 
   2.2.Parameters....................................................7 
   3.Representation of Meta-Policies in the PIB......................7 
   3.1.Meta-policies.................................................7 
   3.2.Conditions....................................................7 
   3.3.Actions.......................................................9 
   3.4.Parameters....................................................9 
   4.Structure of the M-PIB..........................................9 
   4.1.The Capabilities Group........................................9 
   4.2.The Meta-Policy Group.........................................9 
   4.3.The Condition Group..........................................10 
   4.4.The Actions Group............................................11 
   4.5.The Parameter Group..........................................11 
   5.Definition of the Meta-Policy PIB..............................11 
   AuthorsÆ Information.............................................28 
   References.......................................................28 
   Appendix A û Sample XML DTD for encoding conditions..............30 
   Full Copyright Statement.........................................31 
 























     
   R.Boutaba, A.Polyrakis  Internet-Draft, expires Oct.2001   [page 3] 
                   The Meta-Policy Information Base         April 2001 
    
1. Introduction 
    
    
1.1. PIB Limitations 
    
   PIBs are rigid structures. The PIB of a device follows specific 
   standards and can only store specific types of policies. Several 
   policies that could be processed entirely at the PEP level may need 
   to be partially processed by the PDP. For example, a PEP that 
   implements a small PIB that performs filtering according to the 
   IP/Mask/Port of the source/destination of the packets cannot 
   implement the policy ôbetween 5pm and 8pm do not allow traffic from 
   IP Xö, even if a clock exists on the device. In this case, the PDP 
   partially evaluates the conditions of the policy and installs, 
   according to the time, the appropriate filter in the PIB of the PEP. 
   Obviously, it would be more efficient if the involvement of the PDP 
   had been avoided and the entire policy had been processed entirely 
   at the PEP level. 
    
   A second observation is that the PDP may need to send the same or 
   similar commands to the PDP when the same network events occur. For 
   example, suppose that there is a policy: ôgive high priority to 
   administratorsö. If an administrator logs on to a workstation and 
   after a while to another one, the PDP will need to send similar 
   commands to the PEP. Or, each time congestion is detected in the 
   network, the PDP may need to modify the contents of the PIB to 
   reflect similar policies. 
    
   The latter limitation has been identified and has been partially 
   tackled in the framework PIB [FR-PIB]: The section ôMultiple PIB 
   instancesö describes how the PDP can activate, with a simple 
   command, different instances of the same PIB that relate to 
   different network states. 
    
    
1.2. The concept of Meta-Policies 
 
   Inspired by the previous, this document describes how the same can 
   be done in smaller portions of the PIB, i.e., how the PDP can send 
   in advance sets of commands that modify the PIB, which will be 
   activated with simple PDP commands. Moreover, this document 
   describes how the PDP can also download directions to the PEP on how 
   to perform the activation of these sets by itself, independently of 
   the PDP, if this is considered efficient or desirable. 
    
   This additional functionality is implemented through some extra PRCs 
   that supplement and control the PIB of the device. Data on these 
   PRCs control the data (policies) of the entire PIB; this is why the 
   policies implemented in these classes are called ômeta-policiesö.  
     
   Meta-policies are simple rules that monitor some events, and 
   according to their values install or remove PRIs from the PIB. 
   Notice that, according to the previous, meta-policies have in 
   principle the same functionality with the PDP that controls the 
     
   R.Boutaba, A.Polyrakis  Internet-Draft, expires Oct.2001   [page 4] 
                   The Meta-Policy Information Base         April 2001 
    
   device. Indeed, meta-policies attempt to push intelligence and PDP 
   functionality towards the PEP. However, this does not oppose to the 
   requirement that the PEP must always obey to the PDP, because meta-
   policies are rules produced by the PDP, hence the PDP ultimately 
   controls the exact behavior of the PEP. 
    
   As mentioned before, meta-policies monitor some events and perform 
   some actions. However, this does not imply that all monitoring has 
   to be performed by the PEP. The PDP still maintains the overall 
   picture of the network and informs the PEP of global events. 
   However, several events can be monitored by the PEP itself. Such 
   events may be local events that derive from the MIB (or even the 
   PIB) of the device. Alternatively, the PEP may get such information 
   from a third network service or server, e.g., time service, 
   authentication service, etc. (notice that this does not reduce the 
   scalability of the model: again, N PEPs connect to 1 server). 
    
   Depending on the values of the network events, meta-policies modify 
   the PIB of the device. Each meta-policy is associated with a 
   combination of events; when these events occur, the meta-policy is 
   activated and some PRIs are installed into the PIB. These PRIs are 
   uninstalled when these events no longer apply. The actions that a 
   meta-policy takes are predetermined by the PDP. In order to do so, 
   the PDP must associate with these actions the events that reflect 
   such network state that will ensure that these actions will not be 
   conflicting with any other installed actions, or that the policies 
   formed in the PIB are invalid or incorrect. Also, since two valid 
   meta-policies may be conflicting under certain circumstances, the 
   PDP must provide some relative priority order between such meta-
   policies, which will allow the PEP to take the correct decision. 
    
   Notice that meta-policies do not prohibit the PDP from controlling 
   the entire PIB of the device. On the contrary, the PDP has two ways 
   to modify the PIB: Either directly, by installing or removing PRIs, 
   or indirectly, by installing meta-policies that install or remove 
   these PRIs, when appropriate. Of course, meta-policies introduce 
   extra complexity at the PDP, since it also has to ensure that PRIs 
   installed directly cannot conflict with decisions taken by any 
   installed meta-policy. 
    
     
1.3. Why Meta-Policies? 
    
   Meta-policies push some of the PDP functionality towards the PEP. 
   This approach has several advantages: 
    
   1. The PDP is relieved from some of the policy processing. Since the 
     global network policies seldom change, meta-policies are usually 
     generated once and sent to the PEP. The PDP does not have to re-
     generate similar COPS-PR commands each time that the network 
     conditions change.  
    
   2. Less network resources are consumed. Instead of sending whole 
     policies, the PDP can activate the pre-installed meta-policies by 
     
   R.Boutaba, A.Polyrakis  Internet-Draft, expires Oct.2001   [page 5] 
                   The Meta-Policy Information Base         April 2001 
    
     communicating network events.  Also, the PEPs can be programmed to 
     monitor local events, which means that these events do not need to 
     be communicated to the PDP, and then back to the PEP. 
 
   3. The PEPs become more independent, since they are able to take more 
     decisions, according to various network events. Thus, they can 
     operate correctly during larger PDP absences, and they are less 
     affected by situations such as congestion, high network delays, 
     packet loss and PDP overload. 
 
   4. The fact that the behavior of the PEPs can be controlled with 
     smaller messages (network events instead of whole policies) makes 
     the model more robust in erroneous network situations, such as 
     congestion and high packet loss. 
    
   In general, meta-policies contribute towards the scalability, 
   distribution, robustness and fault-tolerance of the COPS-PR model. 
    
   Note that meta-policies allow the PDP to push towards the PEP as 
   little intelligence as a few simple meta-policies or as much as 
   integrating almost the entire PDP functionality into it. 
    
    
    
2. Formal Definition 
    
    
2.1. Meta-Policies 
    
   We define a meta-policy as a rule of the form: 
    
   if (condition) then {actions} 
    
   where ôconditionö is a logical expression,  
   e.g., ô(C>80%) and (D=true)ö,  
   and "actions" is a set of commands that install PRIs into the PIB.  
    
   Since the actions encode a specific policy, this rule is a rule on 
   how policies are enforced; this is why it is called ômeta-policyö.  
    
   Each meta-policy is generated for a specific PEP, according to its 
   capabilities, limitations and the device on which it resides. The 
   PEP evaluates the condition of each meta-policy, and when it 
   evaluates true, it enforces the actions. When it becomes false, the 
   PRIs are uninstalled. The key idea in meta-policies is that the PEP 
   can store and process these meta-policies without knowing their 
   exact semantics: The condition is treated as a logical expression; 
   the actions, pre-generated by the PDP, just denote PRIs that must be 
   installed, and this can be done by the PEP without knowing the high-
   level policy that these PRIs actually implement. In this way, the 
   PEP can process any meta-policy, independently of its complexity and 
   its meaning.  
    

     
   R.Boutaba, A.Polyrakis  Internet-Draft, expires Oct.2001   [page 6] 
                   The Meta-Policy Information Base         April 2001 
    
   Both the condition and the actions may contain parameters (such as 
   ôCongestionö or ôTimeö); the values for these parameters are either 
   sent by the PDP or evaluated by the PEP, according to directions 
   provided by the former.  
    
    
2.2. Parameters  
    
   The parameters are used in meta-policy conditions in order to 
   determine when a meta-policy must be activated. Moreover, they are 
   used by meta-policy actions in order to dynamically bind the network 
   state within policies. For example, the meta-policy ôif 
   (AdminLogged) then {give high priority to AdminIP}ö, contains the 
   parameters AdminLogged and AdminIP. 
     
   When installing a parameter, the PDP must specify an evaluation 
   method for this parameter. For instance, the PEP can be directed to 
   get a value for a parameter from the MIB or the PIB of the device. 
   Alternatively, the PDP could provide the value for this parameter. 
   However, other methods are also possible, depending on the 
   capabilities of the device, such as to download and execute a 
   script, use mobile agents, or get the desired information from some 
   server or service. 
    
    
    
3. Representation of Meta-Policies in the PIB 
    
    
3.1. Meta-policies 
    
   Each meta-policy is comprised of two parts: The ôconditionö and the 
   ôactionsö. The ôconditionö is a logical expression that may be 
   divided into simpler conditions. The ôactionsö is a group of PIB 
   commands that install or remove PRIs. A meta-policy MUST always be 
   associated with a condition, and it is expected to be associated 
   with one or more actions (meta-policies without actions should 
   normally occur only as the result of temporal deactivation of its 
   actions). 
    
   Since meta-policies may be conflicting, the relative priority 
   between potentially conflicting meta-policies MUST be declared in 
   the PIB. 
    
    
3.2. Conditions 
    
   The ôconditionö of a meta-policy is a logical expression that 
   determines when the meta-policy must be activated. Each meta-policy 
   must contain exactly one condition. The condition may consist other 
   simpler conditions; and these conditions may similarly be comprised 
   of even simpler conditions, etc. In this way, the condition is 
   eventually decomposed in primitives that are logical expressions 

     
   R.Boutaba, A.Polyrakis  Internet-Draft, expires Oct.2001   [page 7] 
                   The Meta-Policy Information Base         April 2001 
    
   (i.e., they evaluate true or false), but cannot be further 
   decomposed (i.e., the expression X>Y). 
    
   This document distinguishes two types of such primitives: Booleans 
   and generic logical expressions. Booleans are a subset of the 
   generic expressions, but due to their simplicity and commonality, 
   they are treated separately. Such primitives are evaluated according 
   to the value of a Boolean parameter. For instance, the condition 
   (X>Y) && (!Congestion) && (WorkTime) is decomposed into three 
   primitives: ôX>Yö, ôCongestionö and ôWorkTimeö. From these three 
   primitives, only the last two are Booleans. Booleans MUST be 
   supported by all meta-policy PIBs. 
    
   Generic expressions contain all the other logical expressions that 
   cannot be decomposed into simpler primitives. Examples of such 
   primitives are ôX>Yö, ôIP matches X.Y.Z.Wö or ô8:00am < time < 
   5:00pm). Each PEP can only support specific types of such 
   expressions (e.g., arithmetic), which are reported along with the 
   other PEP capabilities to the PDP. The PDP can only sent to the PEP 
   expressions that are supported by the latter. 
    
   In order to encode and communicate such generic conditions, XML is 
   used. The PEP supports some XML Document Type Definitions (DTDs), 
   which describe the semantics of XML tags that can be used to 
   described such an expression. For instance, a simple DTD that 
   defines XML tags for encoding arithmetic expressions is presented in 
   Appendix A. The PDP encodes the condition (if this is feasible) 
   according to one of these DTDs, and sends it to the PEP, notifying 
   it which DTD it chose. The PEP MUST be able to interpret any kind of 
   expressions encoded according to the DTDs that it supports (with the 
   exception of some limitations like the size of the XML document, 
   etc, that it reports to the PDP in the REQ message). In this way, 
   complex expressions can be communicated from the PDP to the PEP and 
   be evaluated by the latter. Notice that each atom conditions should 
   be parametric (it does not make sense to use constant conditions), 
   the DTDs MUST provide a way to reference to the parameters that are 
   installed in the PEP, through their identifiers. 
    
   For example, suppose that the PDP needs to send to the PEP the 
   expression A ôA+B>7ö. The PEP has reported that it supports the DTD 
   of Appendix A. In this case, the expression will be sent as: 
    
   <ar_cond comp=ÆGTÆ> 
        <expr> 
           <expr><par>1</par></expr> 
           <arop op=Æ+Æ></arop> 
           <expr><par>2</par></expr> 
        </expr> 
        <expr><num>7</num></expr> 
   </ar_cond> 
    
   (Parameters ôAö and ôBö are mapped to the Parameter IDs 1 and 2, 
   respectively) 
    
     
   R.Boutaba, A.Polyrakis  Internet-Draft, expires Oct.2001   [page 8] 
                   The Meta-Policy Information Base         April 2001 
    
    
   Note that the XML-encoded expression does not describe how the 
   parameters are evaluated. It only references the parameters that are 
   used in order to evaluate this expression. 
    
3.3. Actions 
    
   The Actions of a meta-policy is a group of commands that install 
   PRIs into the PIB. Each action MUST specify a target PRID that 
   specifies a single PRI, and the value that will be installed into 
   it. This value may be either a BER-encoded value, sent by the PDP, 
   or the value of a parameter. 
    
    
3.4. Parameters 
    
   Two standard types of parameters are defined in this document. The 
   first type is parameters the values of which are sent by the PDP. 
   The second one is parameters that are evaluated by the MIB or the 
   PIB of the PEP. However, the evaluation methods of the parameters 
   can be extended (this is described later in this document). For 
   instance, the vendors of a device with open node architecture 
   (programmable/active device) may define a way through which scripts 
   or code can be downloaded and executed in order to evaluate a 
   parameter. 
    
    
    
4. Structure of the M-PIB 
    
   The Meta-Policy PIB consists of five groups. 
    
    
4.1. The Capabilities Group 
    
   This group contains a single table, the xmlDTDTable. This contains 
   the XML DTDs that the PEP supports, for encoding expressions. Each 
   row consists of an identifier and the DTD URL. The rows of this 
   table are reported to the PDP in the REQ message. 
 
 
4.2. The Meta-Policy Group 
    
   This group contains three tables: the metaPolicyTable, the 
   metaPolicyStatusTable and the metaPolicyPriorityTable. 
    
   The metaPolicyTable is the table where meta-policies are 
   constructed. Each row represents exactly one meta-policy. The meta-
   policy comprises an identifier, a name, a condition and an action 
   tag. The condition is a reference to the conditionTable that we will 
   describe later in this document, which encodes conditions. The 
   action tag identifies a group of actions from the actionTable that 
   must be executed when the meta-policy is activated. 
    
     
   R.Boutaba, A.Polyrakis  Internet-Draft, expires Oct.2001   [page 9] 
                   The Meta-Policy Information Base         April 2001 
    
   The metaPolicyStatusTable is a table that AUGMENTS the previous 
   table (this means that there is a 1-1 correspondence between the 
   rows of these tables). Each row of this table reports whether the 
   corresponding meta-policy is active, and whether it suppresses or it 
   is suppressed by anoter meta-policy with higher priority. This table 
   is used to report to the PDP the meta-policy status. This class, 
   unlike the metaPolicy class, is only used to report the status of 
   the meta-policies to the PDP and it cannot be modified by it. 
    
   Finally, the metaPolicyPriorityTable is used by the PDP in order to 
   report to the PEP conflicting meta-policies, and direct it how to 
   resolve the conflict. Each row identifies two meta-policies, and 
   defines which one has the higher priority. Rows with two active 
   meta-policies MUST NOT exist in this table. 
    
    
4.3. The Condition Group 
    
   This group contains four tables: the conditionTable, the 
   complexConditionTable, the booleanConditionTable and the 
   generalConditionTable. 
    
   The conditionTable is the base table of this group. Each row 
   represents a logical expression. It consists of an identifier and an 
   attribute that defines whether the condition should be logically 
   reversed (i.e., whether its negation must be computed, instead). 
   Rows of this table MUST always be associated with rows of an other 
   table that extends the base one. 
    
   Some (but not all) of the rows of this table are used in order to 
   represent conditions of meta-policy. Other rows, though, can be used 
   to break down a complex condition to simpler ones.  
    
   In order to achieve that, the complexConditionTable is used. This 
   table EXTENDS the base conditionTable. Each row consists of two 
   references to the conditionTable, and an operator. The references 
   reference two other logical conditions, and the operator defines a 
   logical operation between these two conditions. In this way, the row 
   in this table forms a more complex condition. Obviously, the PDP 
   must not install rows that reference themselves, either explicitly 
   or implicitly. 
 
    
   The booleanConditionTable is a table that also extends the base 
   table. Each row contains a reference to a parameter, which must be 
   of type ôTrueValueö. The value of the condition is evaluated 
   according to the value of this parameter. 
    
   Finally, the generalConditionTable is used to allow conditions to be 
   evaluated through more complex expressions. Each row consists of a 
   reference to the xmlDTDtable and a string, which encodes in XML an 
   expression. The reference to the xmlDTDtable defines the XML DTD 
   that must be used in order to interpret this expression. The 

     
   R.Boutaba, A.Polyrakis  Internet-Draft, expires Oct.2001  [page 10] 
                   The Meta-Policy Information Base         April 2001 
    
   expression encoded MUST be a logical expression, i.e., it MUST 
   evaluate either true or false. 
 
 
4.4. The Actions Group 
    
   This group consists of three tables: the actionTable, the 
   actionValueTable and the actionParametricValueTable. 
    
   The actionTable is the base table for storing meta-policy actions. 
   Each row contains a tag-reference attribute that groups the actions 
   of a single meta-policy. Each row specifies the PRID of the PRI to 
   be installed. 
    
   The value of the PRI is determined either in the actionValueTable or 
   the actionParametricValueTable. Both tables EXTEND the base one and 
   provide the value that must be installed for the specific target 
   PRID. The former provides a BER-encoded value, while the latter 
   specifies a parameter, from where the value is evaluated. 
    
    
4.5. The Parameter Group 
    
   This group contains three tables: the parameterTable, the 
   mibPibParameterTable and the PDPParameterTable. 
    
   The parameterTable is the base table for representing conditions. 
   Each row constist of an identifier, a name and an attribute that 
   denotes the type of the parameter. Each row in this table must be 
   associated with a row of a table that EXTENDS this one. 
    
   The mibPibParameterTable is such a table. It defines a MIB or PIB 
   identifier from where the parameter gets its value. Of course, this 
   identifier must point to an existing variable. Each row also defines 
   the frequency that this value will be updated. 
    
   The pdpParameterTable also extends the base parameterTable. Each row 
   of this table contains a single attribute that encodes, in BER, a 
   single value. The PDP sends the values for this row. 
 
 
 
 
5. Definition of the Meta-Policy PIB 
    
    
   META-POLICY-PIB PIB-DEFINITIONS ::= BEGIN 
    
   IMPORTS 
        Unsigned32, timeticks, 
        MODULE-IDENTITY, OBJECT-TYPE, 
        InstanceId, ReferenceId 
             FROM COPS-PR-SPPI 
        TEXTUAL-CONVENTION 
     
   R.Boutaba, A.Polyrakis  Internet-Draft, expires Oct.2001  [page 11] 
                   The Meta-Policy Information Base         April 2001 
    
             FROM SNMPv2-TC; 
    
   metaPolicyPib  MODULE-IDENTITY 
        SUBJECT-CATEGORY { all } 
        LAST-UPDATED "200104010000" 
        ORGANIZATION "IETF" 
        CONTACT-INFO " Andreas Polyrakis 
                       Dept. of Computer Science, 
                       University of Toronto, 
                       10 King's College Road, 
                       Toronto, Ontario,M5S 3G4, Canada. 
                       e-mail: apolyr@cs.toronto.edu 
                       Phone: ++1 (416) 978-4837 
                       Fax: ++1 (416) 978 1931 
    
                       Raouf Boutaba 
                       Dept. of Computer Science, 
                       University of Waterloo, 
                       200 University Avenue West, 
                       Waterloo, Ontario N2L 3G1, Canada 
                       e-mail: rboutaba@bbcr.uwaterloo.ca 
                       Phone: ++1 (519) 888 4567 ext.4820 
                       Fax: ++1 (519) 885 1208" 
        DESCRIPTION 
             "The meta-policy PIB module. It contains the classes 
             that are necessary for the provisioning of meta-policy 
             related information. This module is applicable, 
             but not mandatory, to all subject-categories" 
    
        ::= { tbd } 
   -- The root OID for PRCs in the Meta-Policy PIB 
    
    
   --- 
   --- Textual Conventions 
   --- 
   BERValue ::= TEXTUAL-CONVENTION 
        STATUS       current 
        DESCRIPTION 
             "A sequence of octets that encodes a value using BER. 
             The suppoted BER types are (borrowed by SNMPv2): 
             Type                | BER identifier 
             --------------------|---------------- 
    
             INTEGER             | 02 
             BIT STRING          | 03 
             OCTET STRING        | 04 
             NULL                | 05 
             OBJECT IDENTIFIER   | 06 
             IP ADDRESS          | 40 
             COUNTER32           | 41 
             GAUGE32             | 42 
             TIMETICKS           | 43 
             OPAQUE              | 44 
     
   R.Boutaba, A.Polyrakis  Internet-Draft, expires Oct.2001  [page 12] 
                   The Meta-Policy Information Base         April 2001 
    
    
             By using this type, the PEP can store values for different  
             types of parameters in the same class (PRC)." 
   " 
        SYNTAX OCTET STRING (SIZE (0..16)) 
    
   XMLString ::= TEXTUAL-CONVENTION 
          STATUS       current 
          DESCRIPTION 
             "A string that contains a logical expression encoded using  
             XML. The semantics of the XML tags are defined in special  
             DTDs, which the PEP declares that supports." 
          SYNTAX OCTET STRING (SIZE (0..1024)) 
   --- 
   --- End of Textual Conventions 
   --- 
    
   ----------------------------------------------- 
   ----------------------------------------------- 
    
    
   -- Meta-Policy Capabilities Group 
   metaPolicyCapabilitiesClasses 
        OBJECT IDENTIFIER ::= { metaPolicyPib 1 } 
    
    
   --- 
   --- Meta-Policy Capabilities Table 
   --- 
   xmlDTDTable OBJECT-TYPE 
        SYNTAX SEQUENCE OF xmlDTDEntry 
        PIB-ACCESS notify 
        STATUS current 
        DESCRIPTION 
             "Each instance of this class specifies a PRC that 
             identifies an XML DTD supported by the PEP for encoding 
             logical expressions. If this class has no instances, 
             then the PEP supports only expressions that are formed 
             with boolean predicates and operators, and in this case 
             the PDP MUST not attempt to install any XML-encoded 
             expressions in the generalConditionTable." 
        ::= { metaPolicyCapabilitiesClasses 1 } 
    
   xmlDTDEntry OBJECT-TYPE 
        SYNTAX MetaPolicyCapabilitiesEntry 
        STATUS current 
        DESCRIPTION 
             "An instance of the xmlDTDTable class that determines an 
             XML DTD that can be used to encode a logical expression" 
        INDEX { metaPolicyPrid } 
        ::= { metaPolicyTable 1 } 
    
   XmlDTDEntry ::= 
        SEQUENCE { 
     
   R.Boutaba, A.Polyrakis  Internet-Draft, expires Oct.2001  [page 13] 
                   The Meta-Policy Information Base         April 2001 
    
             xmlDTDPrid           InstanceId, 
             xmlDTDURL            SnmpAdminString 
        } 
    
   xmlDTDPrid OBJECT-TYPE 
        SYNTAX InstanceId 
        STATUS current 
        DESCRIPTION 
             "An arbitrary integer that uniquely identifies an 
             instance of the xmlDTD class." 
        ::= { xmlDTDEntry 1 } 
    
   xmlDTDURL OBJECT-TYPE 
        SYNTAX SnmpAdminString 
        STATUS current 
        DESCRIPTION 
             "The XML DTD URL. A string that indicates the URL of an 
             XML DTD that can be used for encoding expressions. 
             These DTDs can be defined either by standardization 
             organizations, such as IETF, or be vendor specific. 
    
             When the PDP receives a URL that uniquely identifies 
             such a DTD, it knows that it may encode expressions 
             according to this DTD that the PEP will be able to 
             evaluate." 
        ::= { xmlDTDEntry 2 } 
    
   --End of xmlDTDTable 
    
   ----------------------------------------------- 
   ----------------------------------------------- 
    
   -- Base Meta-Policy Group 
   metaPolicyClasses 
        OBJECT IDENTIFIER ::= { metaPolicyPib 2 } 
    
    
   --- 
   --- Meta-Policy Table 
   --- 
   metaPolicyTable OBJECT-TYPE 
        SYNTAX SEQUENCE OF metaPolicyEntry 
        PIB-ACCESS INSTALL 
        STATUS current 
        DESCRIPTION 
             "Each instance of this class specifies a PRC that 
             represents a meta-policy. Each meta-policy, apart 
             from a unique identifier and an optional name, it 
             constists of a condition and a group of actions." 
        ::= { metaPolicyClasses 1 } 
    
   metaPolicyEntry OBJECT-TYPE 
        SYNTAX MetaPolicyEntry 
        STATUS current 
     
   R.Boutaba, A.Polyrakis  Internet-Draft, expires Oct.2001  [page 14] 
                   The Meta-Policy Information Base         April 2001 
    
        DESCRIPTION 
             "An instance of the metaPolicy Class that represents 
             a meta-policy." 
        INDEX { metaPolicyPrid } 
        ::= { metaPolicyTable 1 } 
    
   MetaPolicyEntry ::= 
        SEQUENCE { 
             metaPolicyPrid            InstanceId, 
             metaPolicyName            SnmpAdminString, 
             metaPolicyCondition       ReferenceId, 
             metaPolicyActions         TagId 
        } 
    
   metaPolicyPrid OBJECT-TYPE 
        SYNTAX InstanceId 
        STATUS current 
        DESCRIPTION 
             "An arbitrary integer that uniquely identifies an 
             instance of the metaPolicy class." 
        ::= { metaPolicyEntry 1 } 
    
   metaPolicyName OBJECT-TYPE 
        SYNTAX SnmpAdminString 
        STATUS current 
        DESCRIPTION 
             "A display string that represents the name of the 
             meta-policy. It is reccomented that different 
             meta-policies have different names. However, similar 
             meta-policies may have the same name. 
             Also, an empty string can be used as a name." 
        ::= { metaPolicyEntry 2 } 
    
   metaPolicyCondition OBJECT-TYPE 
        SYNTAX ReferenceId 
        PIB-REFERENCES contitionTable 
        STATUS current 
        DESCRIPTION 
             "This attribute associates the specific meta-policy with 
             a condition in the condition Class. The condition MUST 
    
             exist when the meta-policy is installed. The meta-policy 
             MUST always be assosiated with one condition (which means 
             that the attribute can never be null/invalid." 
        ::= { metaPolicyEntry 3 } 
    
   metaPolicyActions OBJECT-TYPE 
        SYNTAX TagId 
        PIB-REFERENCES actionsTable 
        STATUS current 
        DESCRIPTION 
             "A tag that maps this instance (meta-policy) to a group 
             of actions in the actions Class. Although the tag should 
             map to at least one action, there might be cases where a 
     
   R.Boutaba, A.Polyrakis  Internet-Draft, expires Oct.2001  [page 15] 
                   The Meta-Policy Information Base         April 2001 
    
             meta-policy is associated to no actions. However such 
             cases should be avoided and only be temporal." 
        ::= { metaPolicyEntry 4 } 
   --End of metaPolicyTable 
    
   -- 
   -- Meta-Policy Status Table 
   -- 
   metaPolicyStatusTable OBJECT-TYPE 
        SYNTAX SEQUENCE OF metaPolicyStatusEntry 
        PIB-ACCESS REPORT-ONLY 
        STATUS current 
        DESCRIPTION 
             "This class augments the metaPolicy class. 
             Each instance of this class defines a PRC that is used 
             in order to report to the PDP the status of the 
             meta-policies. 
    
             Also, information form this table can be used as a 
             parameter to another meta-policy, as an alternative 
             way to ensure that two priorities cannot be 
             activated at the same time." 
        ::= { metaPolicyClasses 2 } 
    
   metaPolicyStatusEntry OBJECT-TYPE 
        SYNTAX MetaPolicyStatusEntry 
        STATUS current 
        DESCRIPTION 
             "An instance of the metaPolicyStatus class that reports 
             the status of the corresponding meta-policy in the 
             metaPolicy class." 
        AUGMENTS { metaPolicyEntry } 
        ::= { metaPolicyStatusTable 1 } 
    
   metaPolicyStatusEntry ::= 
        SEQUENCE { 
             metaPolicyActive     TruthValue, 
             metaPolicySuppressed TruthValue 
        } 
    
   metaPolicyActive OBJECT-TYPE 
        SYNTAX TruthValue 
        STATUS current 
        DESCRIPTION 
             "True while the meta-policy is active" 
        ::= { metaPolicyStatusEntry 1 } 
    
   metaPolicySuppress OBJECT-TYPE 
        SYNTAX TruthValue 
        STATUS current 
        DESCRIPTION 
             "If this meta-policy is prevented from being active by 
             an other meta-policy (but its conditions are met), this 
             attribute is set to true. 
     
   R.Boutaba, A.Polyrakis  Internet-Draft, expires Oct.2001  [page 16] 
                   The Meta-Policy Information Base         April 2001 
    
    
             If this meta-policy prevents another meta-policy from 
             being active, then this attribute is true. 
    
             In other words: 
             Active | Suppr.| 
             -------------------------------- 
              true  | true  | meta-policy active, 
                            | it suppresses another one 
              true  | false | meta-policy active, 
                            | does not suppress another one 
              false | true  | meta-policy inactive 
                            | because it is suppressed by another one 
              false | false | meta-policy inactive because 
                            | the conditions are not met 
             " 
        ::= { metaPolicyStatusEntry 2 } 
   --End of metaPolicyStatusTable 
    
    
   --- 
   --- Meta-Policy Priority Table 
   --- 
   metaPolicyPriorityTable OBJECT-TYPE 
        SYNTAX SEQUENCE OF metaPolicyPriorityEntry 
        PIB-ACCESS INSTALL 
        STATUS current 
        DESCRIPTION 
             "This table reports conflicting meta-policies. 
             When a meta-policy needs to be activated, the PEP 
             MUST check if it is conflicting with another meta-policy, 
             which is already active or needs to be activated at the 
             same time. If so, the one that is referenced in the 
             higherPriority attribute is activated and the other one 
             is deactivated or remains deactivated. Similarly, when a 
             meta-policy is deactivated, the PEP must check if a 
             lower-priority meta-policy must now be activated." 
        ::= { metaPolicyClasses 3 } 
    
   metaPolicyPriorityEntry OBJECT-TYPE 
        SYNTAX MetaPolicyPriorityEntry 
        STATUS current 
        DESCRIPTION 
             "An instance of the metaPolicyPriority Class that 
             identifies the relative priority between two 
             meta-policies." 
        INDEX { metaPolicyPrid } 
        ::= { metaPolicyPriorityTable 1 } 
    
   MetaPolicyPriorityEntry ::= 
        SEQUENCE { 
             metaPolicyPriorityPrid   InstanceId, 
             higherPriority           ReferenceId, 
             lowerPriority            ReferenceId, 
     
   R.Boutaba, A.Polyrakis  Internet-Draft, expires Oct.2001  [page 17] 
                   The Meta-Policy Information Base         April 2001 
    
        } 
    
   metaPolicyPriorityPrid OBJECT-TYPE 
        SYNTAX InstanceId 
        STATUS current 
        DESCRIPTION 
             "An arbitrary integer  that uniquely identifies an 
             instance of the metaPolicyPriority class." 
        ::= { metaPolicyPriorityEntry 1 } 
    
   higherPriority OBJECT-TYPE 
        SYNTAX ReferenceId 
        PIB-REFERENCES metaPolicyTable 
        STATUS current 
        DESCRIPTION 
             "This attribute references to the meta-policy that 
             has higher priority than the one referenced by the 
             lowerPriority attribute" 
        ::= { metaPolicyPriorityEntry 2 } 
    
   lowerPriority OBJECT-TYPE 
        SYNTAX ReferenceId 
        PIB-REFERENCES metaPolicyTable 
        STATUS current 
        DESCRIPTION 
    
             "This attribute references to the meta-policy that 
             has lower priority than the one referenced by the 
             higherPriority attribute" 
        ::= { metaPolicyPriorityEntry 3 } 
    
   --End of metaPolicyPriorityTable 
   ----------------------------------------------- 
   ---------------------------------------------- 
    
    
   -- Condition Group 
   conditionClasses 
        OBJECT IDENTIFIER ::= { metaPolicyPib 3 } 
    
    
   -- 
   -- Condition Table 
   -- 
   conditionTable OBJECT-TYPE 
        SYNTAX SEQUENCE OF conditionEntry 
        PIB-ACCESS INSTALL 
        STATUS current 
        DESCRIPTION 
             "Each instance of this PRC represents a boolean 
             expression. The conditionss of the meta-policies are 
             instances of this class. However, if the condition of 
             a meta-policy contains more than one predicate, the 
             predicates are also instances of this PRC. 
     
   R.Boutaba, A.Polyrakis  Internet-Draft, expires Oct.2001  [page 18] 
                   The Meta-Policy Information Base         April 2001 
    
    
             For instance, Suppose that we want to encode a condition 
             A, which is evaluated as ( B OR C ), where B and C some 
             other boolean expressions. 
             In this case, A, B and C are instances of this PRC. 
    
             All instances of this PRC MUST be extended by an instance 
             of one of the rest PRCs of this group, in order to denote 
             if this condition should be evaluated based on simpler 
             conditions, if it is a boolean operand or an other 
             logical expression." 
        ::= { conditionClasses 1 } 
    
   conditionEntry OBJECT-TYPE 
        SYNTAX ConditionEntry 
        STATUS current 
        DESCRIPTION 
             "An instance of the condition Class that defines a 
             boolean condition" 
        INDEX { conditionIndex } 
        ::= { conditionTable 1 } 
    
   ConditionEntry ::= 
        SEQUENCE { 
             conditionPrid       InstanceId, 
             conditionReverse    Truevalue 
        } 
    
   conditionPrid OBJECT-TYPE 
        SYNTAX InstanceId 
        STATUS current 
        DESCRIPTION 
             "An arbitrary integer that uniquely identifies an 
             instance of the condition class." 
        ::= { conditionEntry 1 } 
    
   conditionReverse OBJECT-TYPE 
        SYNTAX Truevalue 
        STATUS current 
        DESCRIPTION 
             "if true, the negation of the logical expression 
              is evaluated, instead." 
        ::= { conditionEntry 2 } 
   -- END OF conditionTable 
    
   -- 
   -- Complex Condition Table 
   -- 
   complexConditionTable OBJECT-TYPE 
        SYNTAX SEQUENCE OF complexConditionEntry 
        PIB-ACCESS INSTALL 
        STATUS current 
        DESCRIPTION 
             "Each instance of this PRC represents a complex 
     
   R.Boutaba, A.Polyrakis  Internet-Draft, expires Oct.2001  [page 19] 
                   The Meta-Policy Information Base         April 2001 
    
             condition. It consists of two simplier conditions, 
             and a logical operator that determines how the two 
             terms are assosiated to compose the more 
             complicated condition" 
        ::= { conditionClasses 2 } 
    
   complexConditionEntry OBJECT-TYPE 
        SYNTAX ComplexConditionEntry 
        STATUS current 
        DESCRIPTION 
             "An instance of the complexCondition class that breaks a 
             complex condition into two simpler ones." 
        EXTENDS { conditionTable } 
    
        ::= { complexConditionTable } 
    
   ComplexConditionEntry ::= 
        SEQUENCE { 
             operator       Unsigned32, 
             leftTerm       ReferenceId, 
             rightTerm      ReferenceId 
        } 
    
   operator OBJECT-TYPE 
        SYNTAX Unsigned32 { 
             AND (0), 
             OR (1) 
             } 
        STATUS current 
        DESCRIPTION 
             "The logical operator in the complex condition" 
        ::= { complexConditionEntry 1 } 
    
   leftTerm OBJECT-TYPE 
        SYNTAX ReferenceId 
        PIB-REFERENCES conditionTable 
        STATUS current 
        DESCRIPTION 
             "A reference to the first simpler condition." 
        ::= { complexConditionEntry 2 } 
    
   rightTerm OBJECT-TYPE 
        SYNTAX ReferenceId 
        PIB-REFERENCES conditionTable 
        STATUS current 
    
        DESCRIPTION 
             "A reference to the second simpler condition." 
        ::= { complexConditionEntry 3 } 
   -- END OF complexConditionTable 
    
   -- 
   -- Boolean Condition Expression Table 
   -- 
     
   R.Boutaba, A.Polyrakis  Internet-Draft, expires Oct.2001  [page 20] 
                   The Meta-Policy Information Base         April 2001 
    
   booleanConditionTable OBJECT-TYPE 
        SYNTAX SEQUENCE OF booleanConditionEntry 
        PIB-ACCESS INSTALL 
        STATUS mandatory 
        DESCRIPTION 
             "Each instance of this class extends the condition class 
             and represents a boolean parameter from which the 
             condition is evaluated." 
        ::= { metaPolicyPibClasses 2 } 
    
   booleanConditionEntry OBJECT-TYPE 
        SYNTAX BooleanConditionEntry 
        STATUS mandatory 
        DESCRIPTION 
             "An instance of the booleanCondition class that defines 
             the boolean parameter that gives values to the 
             corresponding condition." 
        EXTENDS { conditionTable } 
        ::= { booleanConditionTable 1 } 
    
   BooleanConditionEntry ::= 
        SEQUENCE { 
             parameterReference  ReferenceId 
        } 
    
   parameterReference OBJECT-TYPE 
        SYNTAX ReferenceId 
        PIB-REFERENCES parameterTable 
        STATUS current 
        DESCRIPTION 
             "A reference to a parameter from where the condition is 
             evaluated. This condition MUST be of type boolean 
             (Truthvalue)." 
        ::= { booleanConditionEntry 1 } 
   -- End of booleanConditionTable 
    
   -- 
   -- Generic Condition Table 
   -- 
   genericConditionTable OBJECT-TYPE 
        SYNTAX SEQUENCE OF genericConditionEntry 
        PIB-ACCESS INSTALL 
        STATUS current 
        DESCRIPTION 
             "Each instance of this class extends the condition class 
             and assosiates the corresponding condition with a complex 
             logical expression, from where the condition is 
             evaluated." 
        ::= { conditionClasses 2 } 
    
   genericConditionEntry OBJECT-TYPE 
        SYNTAX GenericConditionEntry 
        STATUS current 
        DESCRIPTION 
     
   R.Boutaba, A.Polyrakis  Internet-Draft, expires Oct.2001  [page 21] 
                   The Meta-Policy Information Base         April 2001 
    
             "An instance of the generalCondition class that defines 
             the logical expression for the corresponding condition 
             of the condition class." 
        EXTENDS { generalConditionTable } 
        ::= { conditionNumericalExpressionTable } 
    
   GenericConditionEntry ::= 
        SEQUENCE { 
           xmlDTDRef   ReferenceId, 
             xmlCondition   XMLString 
        } 
    
   xmlDTDRef OBJECT-TYPE 
        SYNTAX ReferenceId 
        PIB-REFERENCES xmlDTDTable 
        STATUS current 
        DESCRIPTION 
             "A reference to the xmlDTD class that deternies which 
             of the XML DTDs that this PEP supports is used in 
             order to encode the expression." 
        ::= { genericConditionEntry 1 } 
    
   xmlCondition OBJECT-TYPE 
        SYNTAX XMLString 
        STATUS mandatory 
        DESCRIPTION 
             "The XML-encoded expression." 
        ::={ genericConditionEntry 2 } 
   -- End of genericConditionTable 
    
   ----------------------------------------------- 
   ----------------------------------------------- 
    
    
   -- Actions Group 
   actionClasses 
        OBJECT IDENTIFIER ::= { metaPolicyPib 4 } 
    
    
   -- 
   -- Actions Table 
   -- 
   actionTable OBJECT-TYPE 
        SYNTAX SEQUENCE of actionEntry 
        PIB-ACCESS INSTALL 
        STATUS current 
        DESCRIPTION 
             "Each instance of this class stores an action of 
             a meta-policy." 
        ::= { actionClasses 1 } 
    
   actionEntry OBJECT-TYPE 
        SYNTAX ActionEntry 
        STATUS current 
     
   R.Boutaba, A.Polyrakis  Internet-Draft, expires Oct.2001  [page 22] 
                   The Meta-Policy Information Base         April 2001 
    
        DESCRIPTION 
             "An instance of the action class that stores an action 
             of a meta-policy." 
        INDEX { actionPrid } 
        ::= { actionTable 1 } 
    
   ActionEntry ::= 
        SEQUENCE { 
             actionPrid        InstanceId, 
             actionRefTag      TagReferenceId, 
             actionTargetPrid  Prid 
        } 
    
   actionPrid OBJECT-TYPE 
        SYNTAX InstanceId 
        STATUS current 
        DESCRIPTION 
             "An arbitrary integer that uniquely identifies an 
             instance of the action class." 
        ::= { actionEntry 1 } 
    
   actionRefTag OBJECT-TYPE 
        SYNTAX TagReferenceId 
        PIB-TAG metaPolicyActions 
        STATUS current 
        DESCRIPTION 
             "An attribute that defines a Tag Group of actions. 
             All actions with the same tag are grouped as the actions 
             of a single meta-policy." 
        ::={ actionEntry 2 } 
    
   actionTargetPrid OBJECT-TYPE 
        SYNTAX Prid 
        STATUS current 
        DESCRIPTION 
             "The PRID of the PRI to be installed/updated. 
             The PRID must point to a single PRI." 
        ::={ actionEntry 3 } 
   -- END OF actionsTable 
    
   -- 
   -- Action Value table 
   -- 
   actionValueTable OBJECT-TYPE 
        SYNTAX SEQUENCE OF actionValueEntry 
        PIB-ACCESS INSTALL 
        STATUS current 
        DESCRIPTION 
             "Each instance of this class extends the corresponding 
             instance of the action class. It provides the BER-encoded 
   value  
             that will be installed at the corresponding PRI." 
        ::= { actionClasses 2 } 

     
   R.Boutaba, A.Polyrakis  Internet-Draft, expires Oct.2001  [page 23] 
                   The Meta-Policy Information Base         April 2001 
    
    
    
   actionValueEntry OBJECT-TYPE 
        SYNTAX ActionsValueEntry 
        STATUS current 
        DESCRIPTION 
             "An insance of the actionValue class. It provides 
             the value (encoded with BER) that will be installed at 
             the PRI denoted by the corresponding instance of the 
             action class." 
        EXTENDS { actionEntry } 
        ::= { actionValueTable 1 } 
    
   ActionValueEntry ::= 
        SEQUENCE { 
             ActionValueEpd      BERValue 
        } 
    
   actionValueEpd OBJECT-TYPE 
        SYNTAX BERValue 
        STATUS current 
        DESCRIPTION 
             "This attribute contains the BER-encoded value of the 
             PRI to be installed/updated." 
        ::={ actionValueEntry 1 } 
   -- END OF actionValueTable 
    
   -- 
   -- Action Parametric Value Table 
   -- 
   actionParametricValueTable OBJECT-TYPE 
        SYNTAX SEQUENCE OF actionParametricValueEntry 
        PIB-ACCESS INSTALL 
        STATUS current 
        DESCRIPTION 
             "Each instance of this class that extends the 
              corresponding instance of the action class. It provides 
   with the 
              parametric value that will be installed at the 
   corresponding PRI." 
        ::= { actionClasses 3 } 
    
   actionParametricValueEntry OBJECT-TYPE 
        SYNTAX ActionParametricValueEntry 
        STATUS current 
        DESCRIPTION 
             "An insance of the actionValue class. It provides with 
             the parametric value that will be installed at the PRI 
              denoted by the corresponding instance of the action 
              class." 
        EXTENDS { actionEntry } 
    
        ::= { actionParametricValueTable 1 } 
    
     
   R.Boutaba, A.Polyrakis  Internet-Draft, expires Oct.2001  [page 24] 
                   The Meta-Policy Information Base         April 2001 
    
   ActionParametricValueEntry ::= 
        SEQUENCE { 
             ParameterRef        ReferenceId 
        } 
    
   ParameterRef OBJECT-TYPE 
        SYNTAX ReferenceId 
        PIB-REFERENCES parameterTable 
        STATUS current 
        DESCRIPTION 
             "A reference to a the parameter, from where the value 
             of the installed PRI should be obtained. Whenever the 
             value of the parameter changes, the installed PRI 
             MUST be updated." 
        ::={ actionParametricValueEntry 1 } 
   -- END OF actionParametricValueTable 
    
   ----------------------------------------------- 
   ----------------------------------------------- 
    
    
   -- Parameter Group 
   parameterClasses 
        OBJECT IDENTIFIER ::= { metaPolicyPib 5 } 
    
    
   - 
   - Parameter Table 
   - 
   parameterTable OBJECT-TYPE 
        SYNTAX SEQUENCE OF parameterEntry 
        PIB-ACCESS INSTALL 
        STATUS current 
        DESCRIPTION 
             "Each instance of this class defines a parameter 
             that has been installed on the PEP. This class 
             MUST be extended by a class that defines how 
             the value of the parameter will be evaluated." 
        ::= { parameterClasses 1} 
    
   parameterEntry OBJECT-TYPE 
        SYNTAX ParameterEntry 
        STATUS current 
        DESCRIPTION 
             "An instance of the parameter class that installs 
             a parameter into the PEP." 
        INDEX { parameterPrid } 
        ::= { parameterTable 1 } 
    
   ParameterEntry ::= 
        SEQUENCE { 
             parameterPrid       InstanceId, 
             parameterName       SNMPAdminString, 
             parameterType       Unsigned32 
     
   R.Boutaba, A.Polyrakis  Internet-Draft, expires Oct.2001  [page 25] 
                   The Meta-Policy Information Base         April 2001 
    
        } 
    
   parameterPrid OBJECT-TYPE 
        SYNTAX InstanceId 
        STATUS current 
        DESCRIPTION 
             "An arbitrary integer that uniquely identifies an 
             instance of the parameter class." 
        ::= { parameterEntry 1 } 
    
   parameterNameOBJECT-TYPE 
        SYNTAX SNMPAdminString 
        STATUS current 
        DESCRIPTION 
             "A string that represents the name of the parameter. 
             It is reccomented that different parameter have different 
             names. However, similar parameter may have the same name. 
             Also, an empty string can be used as a name." 
        ::= { parameterEntry 2 } 
    
   parameterType 
        SYNTAX Unsigned32 { 
             INTEGER (02) 
             BIT STRING (03) 
             OCTET STRING (04) 
             NULL (05) 
             OBJECT IDENTIFIER (06) 
             IP ADDRESS (40) 
             } 
        STATUS current 
        DESCRIPTION 
             "The BER type of the parameter. 
             The suppoted BER types are: 
             Type                | BER identifier 
             --------------------|---------------- 
             INTEGER             | 02 
             BIT STRING          | 03 
             OCTET STRING        | 04 
             NULL                | 05 
             OBJECT IDENTIFIER   | 06 
             IP ADDRESS          | 40" 
        ::= { parameterEntry 3 } 
   -- END OF parameterTable 
    
   -- 
   -- MIBPIB Parameter Table 
   -- 
   mibPibParameterTable OBJECT-TYPE 
        SYNTAX SEQUENCE OF mibPibParameterEntry 
        PIB-ACCESS INSTALL 
        STATUS current 
        DESCRIPTION 
             "This class extends the parameter class. 
             Each instance of this class assosiates to the 
     
   R.Boutaba, A.Polyrakis  Internet-Draft, expires Oct.2001  [page 26] 
                   The Meta-Policy Information Base         April 2001 
    
             corresponding parameter a MIB or PIB variable, from 
             where the parameter is evaluated" 
        ::= { parameterClasses 2 } 
    
   mibPibParameterEntry OBJECT-TYPE 
        SYNTAX MibPibParameterEntry 
        STATUS current 
        DESCRIPTION 
             "An instance of the mibPibParameter class that provides 
             the identifier of the MIB/PIB variable from where the 
             corresponding parameter is evaluated." 
        EXTENDS { parameterEntry } 
        ::= { mibPibParameterTable 1 } 
    
   MibPibParameterEntry ::= 
        SEQUENCE { 
             targetOID        OBJECT-IDENTIFIER, 
             EvaluationFrequency timeticks 
             } 
    
   targetOID OBJECT-TYPE 
        SYNTAX OBJECT-IDENTIFIER 
        PIB-ACCESS INSTALL 
        STATUS current 
        DESCRIPTION 
             "The object identifier of the MIB/PIB variable. 
             The MIB/PIB variable MUST exist in the MIB/PIB of the 
             device. Also, the type of the target variable MUST be 
             compatible with the type of the corresponding PRI of the 
             parameter Class." 
        ::={ mibPibParameterEntry 1 } 
    
   EvaluationFrequency OBJECT-TYPE 
        SYNTAX timeticks 
        STATUS current 
        DESCRIPTION 
             "The frequency of updating the parameter in milliseconds" 
        ::={ mibPibParameterEntry 2 } 
   -- END of mibPibParameterTable 
    
   -- 
   -- PDP Parameter Table 
   -- 
   pdpParameterTable OBJECT-TYPE 
        SYNTAX SEQUENCE OF pdpParameterEntry 
        PIB-ACCESS INSTALL 
        STATUS current 
        DESCRIPTION 
             "This class extends the parameter class. Each instance 
             of this class contains the value of the corresponding 
             paramter. This value is send by the PDP and updated 
             whenever necessary." 
        ::= { parameterClasses 3 } 
    
     
   R.Boutaba, A.Polyrakis  Internet-Draft, expires Oct.2001  [page 27] 
                   The Meta-Policy Information Base         April 2001 
    
   pdpParameterEntry OBJECT-TYPE 
        SYNTAX PdpParameterEntry 
        STATUS current 
        DESCRIPTION 
             "An instance of the pdpParameter class that stores the 
             value, sent by the PDP, for the corresponding parameter." 
        INDEX { parameterIndex } 
        ::= { pdpParametersTable 1 } 
    
   PdpParameterEntry ::= 
        SEQUENCE { 
             lastValue         BERValue 
        } 
    
   lastValue OBJECT-TYPE 
        SYNTAX BERValue 
        STATUS current 
        DESCRIPTION 
             "The latest value of the parameter, encoded with BER. 
             The BER-encoded value must be of the same type as the 
             corresponding PRI of the parameter class." 
        ::={ pdpParameterEntry 1 } 
   -- END OF pdpParameterTable 
    
    
   END 
    
    
    
AuthorsÆ Information 
    
   Andreas Polyrakis 
   Dept. of Computer Science, 
   University of Toronto, 
   10 King's College Road, 
   Toronto, Ontario, M5S 3G4, Canada. 
   e-mail: apolyr@cs.toronto.edu
   Phone: ++1 (416) 978-4837 
   Fax: ++1 (416) 978 1931 
    
   Raouf Boutaba 
   Dept. of Computer Science, 
   University of Waterloo, 
   200 University Avenue West, 
   Waterloo, Ontario N2L 3G1, Canada 
   e-mail: rboutaba@bbcr.uwaterloo.ca 
   Phone: ++1 (519) 888 4567 ext.4820 
   Fax: ++1 (519) 885 1208 
    
    
References 
    
   [P-TERM]  A. Westerinen, J. Schnizlein, J. Strassner, Mark 
             Scherling, Bob Quinn, Shai Herzog, An-Ni Huynh, Mark 
             Carlson, Jay Perry, ôTerminology for Policy-Based 
     
   R.Boutaba, A.Polyrakis  Internet-Draft, expires Oct.2001  [page 28] 
                   The Meta-Policy Information Base         April 2001 
    
             Managementö, IETF RFC 3198, Proposed Standard, November 
             2000. 
    
    
   [RAP-FRM] R. Yavatkar, D. Pendarakis, R. Guerin, "A Framework for 
             Policy-based Admission Control", IETF RFC 2753, January 
             2000. 
                                                                         
   [COPS]    Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R.,  
             Sastry, A., "The COPS (Common Open Policy Service)  
             Protocol", IETF RFC 2748, Proposed Standard, January 2000. 
    
   [COPS-PR] K. Chan, J. Seligson, D. Durham, S. Gai, K. McCloghrie, S. 
             Herzog, F. Reichmeyer, R. Yavatkar, A. Smith, "COPS Usage 
             for Policy Provisioning", IETF RFC 3084, Proposed 
             Standard, March 2001. 
    
   [FR-PIB]  M. Fine, K. McCloghrie, J. Seligson, K. Chan; S. Hahn, R. 
             Sahita, A. Smith, F. Reichmeyer, "Framework Policy 
             Information Base", IETF, Internet-Draft, draft-ietf-rap-
             frameworkpib-07.txt, January 2002 
    
   [SPPI]    K. McCloghrie, M. Fine, J. Seligson, K. Chan, S. Hahn, R. 
             Sahita, A. Smith, F. Reichmeyer, "Structure of Policy 
             Provisioning Information (SPPI)", IETF RFC 3159, Proposed 
             Standard, Augoust 2001. 
    
        
    

























     
   R.Boutaba, A.Polyrakis  Internet-Draft, expires Oct.2001  [page 29] 
                   The Meta-Policy Information Base         April 2001 
    
Appendix A û Sample XML DTD for encoding conditions 
    
   <!ųSimple DTD for arithmetic expression representation --> 
    
   <!ų------------------------------------------> 
   <!ųSince these XML documents will be both  --> 
   <!ųgenerated and consumed by machines, the --> 
   <!ųreadability of the tags is not very     --> 
   <!ųimportant. However, since there might be--> 
   <!ųconcerns about the XML document size,   --> 
   <!ųthe tag names were kept as small as     --> 
   <!ųpossible.                               --> 
   <!ų------------------------------------------> 
    
    
   <!ų Only arithmetic expressions are supported. --> 
   <!ų The attribute defines the comparison type --> 
   <!ų GT = Greater than, LT = Less than --> 
   <!ų EQ = Equal, NE = Not equal --> 
   <!ų GE = Greater or equal, LE = Less or equal --> 
   <!ELEMENT ar_cond (expr, expr)> 
   <!ATTLIST ar_cond 
                comp (GT | LT | EQ | NE | GE | LE ) #REQUIRED 
   > 
    
   <!ELEMENT expr ((expr, arop, expr) | par | num)> 
   <!ELEMENT par #PCDATA> 
   <!ELEMENT num #PCDATA> 
    
   <!ELEMENT arop EMPTY> 
   <!ATTLIST arop 
                op ( + | - | * | / ) #REQUIRED 
   > 
    
    
    
    

















     
   R.Boutaba, A.Polyrakis  Internet-Draft, expires Oct.2001  [page 30] 
                   The Meta-Policy Information Base         April 2001 
    
Full Copyright Statement  
    
   Copyright (C) The Internet Society (2000).  All Rights Reserved.  
    
   This document and translations of it may be copied and furnished to 
   others, and derivative works that comment on or otherwise explain it 
   or assist in its implementation may be prepared, copied, published 
   and distributed, in whole or in part, without restriction of any 
   kind, provided that the above copyright notice and this paragraph  
   are included on all such copies and derivative works.  However, this 
   document itself may not be modified in any way, such as by removing 
   the copyright notice or references to the Internet Society or other 
   Internet organizations, except as needed for the purpose of 
   developing Internet standards in which case the procedures for 
   copyrights defined in the Internet Standards process must be 
   followed, or as required to translate it into languages other than 
   English.  
    
   The limited permissions granted above are perpetual and will not be 
   revoked by the Internet Society or its successors or assigns.  
    
   This document and the information contained herein is provided on an 
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
    
    

























     
   R.Boutaba, A.Polyrakis  Internet-Draft, expires Oct.2001  [page 31]