[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
   SMIng Working Group                                     Harsha Hegde
   Internet Draft                                          Ravi Sahita
   Expiration: January 2002                                Intel





                       SMIng Mappings to COPS-PR
                     draft-ietf-sming-copspr-01.txt
                               July 2001



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.

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 [KEYWORD].

Abstract

   This memo presents an SMIng language extension that supports the
   mapping of SMIng definitions of identities, classes, and their
   attributes to dedicated definitions of nodes and tables for
   application in the policy based management framework [RAP-FRWK]
   using COPS-PR [COPS-PR].







                                                              [Page 1]


Internet Draft           SMIng COPSPR Mapping                July 2001


   Table of Contents

   Status of this Memo................................................1
   Conventions used in this document..................................1
   Abstract...........................................................1
   2. Policy Based Management using COPS-PR...........................4
   3. SMIng Data Type Mappings........................................5
   3.1 ASN.1 Definitions..............................................6
   4. Semantics of COPS-PR mappings...................................6
   4.1. The copspr Extension Statement................................6
   4.2. The oid Statement.............................................7
   4.3. The clienttype Statement......................................7
   4.4. The node Statement............................................7
   4.4.1. The node's oid Statement....................................7
   4.4.2. The node's represents Statement.............................7
   4.4.3. The node's status Statement.................................8
   4.4.4. The node's description Statement............................8
   4.4.5. The node's reference Statement..............................8
   4.4.6. Usage Example...............................................8
   4.5. The prc Statement.............................................8
   4.5.1. The prc's oid Statement.....................................9
   4.5.2. The prc's anyindex Statement................................9
   4.5.2.1. The pibindex Statement....................................9
   4.5.2.2. The augments Statement....................................9
   4.5.2.3. The extends Statement.....................................9
   4.5.3. The prc's implements Statement..............................9
   4.5.3.1. The implements' implobject Statement.....................10
   4.5.3.1.1. The implobject's pibreference Statement................10
   4.5.3.1.2. The implobject's pibtag Statement......................10
   4.5.4. The prc's status Statement.................................10
   4.5.5. The prc's description Statement............................11
   4.5.6. The prc's reference Statement..............................11
   4.5.7. The prc's pibaccess Statement..............................11
   4.5.8. The prc's piberrors Statement..............................11
   4.5.9. Usage Example..............................................12
   4.6. The group Statement..........................................12
   4.6.1. The group's oid Statement..................................12
   4.6.2. The group's members Statement..............................12
   4.6.3. The group's status Statement...............................12
   4.6.4. The group's description Statement..........................13
   4.6.5. The group's reference Statement............................13
   4.6.6. Usage Example..............................................13
   4.7. The compliance Statement.....................................13
   4.7.1. The compliance's oid Statement.............................13
   4.7.2. The compliance's status Statement..........................14
   4.7.3. The compliance's description Statement.....................14
   4.7.4. The compliance's reference Statement.......................14
   4.7.5. The compliance's mandatory Statement.......................14
   4.7.6. The compliance's optional Statement........................14
   4.7.6.1. The optional's description Statement.....................15
   4.7.7. The compliance's refine Statement..........................15
   4.7.7.1. The refine's installtype Statement.......................15
   4.7.7.2. The refine's pibminaccess Statement......................15

Hegde, Sahita            Expires January 2002                 [Page 2]


Internet Draft           SMIng COPSPR Mapping                July 2001


   4.7.7.3. The refine's description Statement.......................16
   4.7.8. Usage Example..............................................16
   5. IETF-SMING-COPSPR-EXT..........................................16
   6. IETF-SMING-COPSPR..............................................21
   7. Security Considerations........................................24
   8. Acknowledgements...............................................24
   9. Authors' Addresses.............................................24
   10. References....................................................24














































Hegde, Sahita            Expires January 2002                 [Page 3]


Internet Draft           SMIng COPSPR Mapping                July 2001


   1. Introduction

   This memo presents an SMIng language extension that supports the
   mapping of SMIng definitions of identities, classes, and their
   attributes to dedicated definitions of nodes and tables for
   application in the Policy Based Management framework [RAP-FRWK]
   using COPS-PR [COPS-PR].

   Section 2 introduces basics of the Policy Based Management using
   COPS-PR.

   Section 3 defines how SMIng data types are mapped to the data types
   supported by the COPS-PR protocol. It introduces some new ASN.1
   definitions, which are used to represent new SMIng base types such
   as floats in the COPS-PR protocol.

   Section 4 describes the semantics of the COPS-PR mapping extensions
   for SMIng.

   Section 5 presents the formal SMIng specification of the extension.

   Section 6 contains a SMIng module that defines data types that are
   specific to the COPS-PR mapping.

2. Policy Based Management using COPS-PR

   COPS [COPS] is a query/response protocol that allows policy servers
   to communicate policy decisions to network devices. A Policy server
   is a PDP (Policy Decision Point) and a network device (policy
   client) is a PEP (Policy Enforcement Point).

   COPS supports two models for policy control: Outsourcing and
   Configuration.

   Outsourcing model addresses the kind of events at the PEP that
   require an instantaneous policy decision. In the outsourcing model,
   the PEP delegates responsibility to a PDP to make decisions on its
   behalf.

   In the configuration model, the PDP proactively provision the PDP
   with the necessary policy information, so that decisions are made or
   actions are taken right at the PEP. The provisioning may be
   performed in bulk (e.g., entire router QoS configuration) or in
   small portions (e.g., updating a access filter on a network device).

   COPS Usage for Policy Provisioning (COPS-PR) protocol describes how
   base COPS protocol is used for provisioning (configuration model).

   In COPS-PR, policy requests describe the PEP and its configurable
   parameters. If a change occurs in the parameters, an updated request
   is sent. Decisions are not necessarily mapped directly to requests,
   and are issued mostly when the PDP responds to external events or
   PDP events such as policy updates.

Hegde, Sahita            Expires January 2002                 [Page 4]


Internet Draft           SMIng COPSPR Mapping                July 2001



   The data carried by COPS-PR is in the form of a tree structured
   information store known as Policy Information Base (PIB). The PIB is
   a conceptual tree namespace of Provisioning Classes (PRCs) and
   Provisioning Instances (PRIs). There may be multiple instances
   (PRIs) of any PRC. The tree is shown in the figure below.

             -------+-------+----------+---PRC--+--PRI
                    |       |          |        +--PRI
                    |       |          |
                    |       |          +---PRC-----PRI
                    |       |
                    |       +---PRC--+--PRI
                    |                +--PRI
                    |                +--PRI
                    |                +--PRI
                    |                +--PRI
                    |
                    +---PRC---PRI

                          Figure 1: A PIB Definition Tree

   PIB modules are written using an adapted subset of SNMP's Structure
   of Management Information (SMI) [SMIV2]. This structure of Policy
   Provisioning Information is defined in [SPPI].

3. SMIng Data Type Mappings

   The SMIng base types are mapped to the COPS-PR base types according
   to the following table:

              SMIng Data Type    COPS-PR Base Type       Comments
              ---------------    -----------------       --------
              OctetString        OctetString
              Pointer            Prid/ReferenceId         (1)
              Integer32          Integer32
              Unsigned32         Unsigned32
              Integer64          Integer64
              Unsigned64         Unsigned64
              Float32            Float32                  (2)
              Float64            Float64                  (2)
              Float128           Float128                 (2)
              Enumeration        Integer32
              Bits               OctetString

              Counter32          Unsigned32               (3)
              Counter64          Unsigned64               (3)
              TimeTicks          TimeTicks
              IpAddress          IpAddress
              Opaque             Opaque                   (4)

   (1) Prid and ReferenceId (SPPI specific data types) are pointers to
       a specific PRI (an instance of PRC). For more description see

Hegde, Sahita            Expires January 2002                 [Page 5]


Internet Draft           SMIng COPSPR Mapping                July 2001


       section 6.

   (2) This type is encoded according to the ASN.1 type with the same
       name defined in Section 3.1. Please note that SPPI does not
       have an opaque data type. This is a protocol mapping and COPS-PR
       can carry the types defined in Section 3.1.

   (3) Counters are mapped to their respective Unsigned Integer types.

   (4) This type is encoded according to the ASN.1 type with the same
       name defined in Section 3.1.Please note that SPPI does not have
       an opaque data type.


3.1 ASN.1 Definitions

   The ASN.1 [ASN1] type definitions below introduce data types that
   are used to map new SMIng base types into the set of ASN.1 types
   supported by the COPS-PR protocol.


   IETF-SMING-COPSPR-MAPPING DEFINITIONS ::= BEGIN

   Opaque ::=
       [APPLICATION 4]
           IMPLICIT OCTET STRING

   Float32
       [APPLICATION 12]
           IMPLICIT OCTET STRING (SIZE (4))

   Float64
       [APPLICATION 13]
           IMPLICIT OCTET STRING (SIZE (8))

   Float128
       [APPLICATION 14]
           IMPLICIT OCTET STRING (SIZE (16))
   END

   The definitions of the floating-point types Float32, Float64 and
   Float128 are consistent with the same definitions in [SNMP-MAP].


4. Semantics of COPS-PR mappings

   All the statements in the COPS-PR mapping are explained in this
   section. Please note that a majority of the statements are similar
   to the statements that are in SMIng to SNMP mapping [SNMP-MAP] as
   the SPPI definition for use in COPS-PR is very similar to SMI
   definition for SNMP.

4.1. The copspr Extension Statement

Hegde, Sahita            Expires January 2002                 [Page 6]


Internet Draft           SMIng COPSPR Mapping                July 2001



   The 'copspr' statement is the main statement of the COPS-PR mapping
   specification. It gets one or two arguments: an optional lowercase
   identifier that can specify a node that represents the module's
   identity, and a mandatory statement block that contains all details
   of COPS-PR mapping. A single SMIng module must not contain more than
   one 'copspr' statement.

4.2. The oid Statement

   The copspr's 'oid' statement, which must be present, if the 'copspr'
   statement contains a module identifier and must be absent otherwise,
   gets one argument that specifies the object identifier value that is
   assigned to the module's identity node.

4.3. The clienttype Statement

   The copspr's 'clienttype' statement, which must be present,
   identifies one or more categories of provisioning data for which
   this PIB module defines provisioning information.  For use with the
   COPS-PR protocol, the individual categories are mapped to COPS
   Client Types [COPS-PR]. The categories are identified either:

     - Via the keyword "all", indicating the PIB module defines
   provisioning information relevant for all COPS client-types, or

     - As a list of named-number enumerations, where each number, which
   must be greater than zero, identifies a COPS client-type.  The
   namespace for these named numbers is global and therefore the labels
   should be assigned consistently across PIB modules.  At present
   time, no more than one named-number enumeration should be specified.

4.4. The node Statement

   The 'node' statement is used to name and describe a node in the
   object identifier tree, without associating any class or attribute
   information with this node. This may be useful to group definitions
   in a sub-tree of related management information, or to uniquely
   define a SMIng 'identity' to be referenced in attributes of type
   Pointer.  The 'node' statement gets two arguments: a lower-case node
   identifier and a statement block that holds detailed node
   information in an obligatory order.

   See the 'nodeStatement' rule of the SMIng grammar (Section 5) for
   the formal syntax of the 'node' statement.

4.4.1. The node's oid Statement

   The node's 'oid' statement, which must be present, gets one
   argument, which specifies the object identifier value that is
   assigned to this node.

4.4.2. The node's represents Statement

Hegde, Sahita            Expires January 2002                 [Page 7]


Internet Draft           SMIng COPSPR Mapping                July 2001



   The node's 'represents' statement, which need not be present, makes
   this node represent an SMIng identity, so that objects of type
   Pointer can reference that identity. The statement gets one argument
   that specifies the identity name.

4.4.3. The node's status Statement

   The node's 'status' statement, which need not be present, gets one
   argument, which is used to specify whether this node definition is
   current or historic. The value 'current' means that the definition
   is current and valid. The value 'obsolete' means the definition is
   obsolete and should not be implemented and/or can be removed if
   previously implemented.  While the value 'deprecated' also indicates
   an obsolete definition, it permits new/continued implementation in
   order to foster interoperability with older/existing
   implementations.

   If the 'status' statement is omitted, the status value 'current' is
   implied.

4.4.4. The node's description Statement

   The node's 'description' statement, which need not be present, gets
   one argument, which is used to specify a high-level textual
   description of this node.

   It is RECOMMENDED to include all semantics and purposes of this
   node.

4.4.5. The node's reference Statement

   The node's 'reference' statement, which need not be present, gets
   one argument, which is used to specify a textual cross-reference to
   some other document, either another module which defines related
   definitions, or some other document which provides additional
   information relevant to this node.

4.4.6. Usage Example

       node   zeroDotZero {
           oid         0.0;
           represents  IETF-SMING::null;
           description "A value used for null identifiers.";
       };

4.5. The prc Statement

   The 'prc' statement is used to define the mapping of one or more
   classes to a single COPS-PR PRC (PRovisioning Class). Provisioning
   class instances are called PRIs. The 'prc' statement gets two
   arguments: a lower-case PRC identifier and a statement block that


Hegde, Sahita            Expires January 2002                 [Page 8]


Internet Draft           SMIng COPSPR Mapping                July 2001


   holds detailed mapping information of this PRC in an obligatory
   order.

   See the 'prcStatement' rule of the SMIng grammar (Section 5) for the
   formal syntax of the 'prc' statement.

4.5.1. The prc's oid Statement

   The prc's 'oid' statement, which must be present, gets one argument,
   which specifies the object identifier value that is assigned to this
   PRC.

4.5.2. The prc's anyindex Statement

   The prc's 'anyindex' statement consists of three types of index
   statement that define the type of the PRC. This statement must be
   present and only one type of index is allowed in a PRC definition.
   The three types of index statements are described below.

4.5.2.1. The pibindex Statement

   The 'pibindex' statement is included in definition of a base PRC. It
   takes one argument that identifies the attribute that is of type
   'InstanceId'.

   InstanceId identifies a particular instance of a PRC. InstanceId is
   a typedef described in section 6. As every base PRC definition,
   except one that uses augments or extends, must have an InstanceId
   attribute, it is added as the first attribute of the base PRC.
   Hence, it is not included in the SMIng COPS-PR mapping definition
   below in section 5. A PRC that augments or extends will not have
   this InstanceId.

4.5.2.2. The augments Statement

   The 'augments' statement is included in definition of a augmented
   PRC. This PRC definition augments a base PRC definition. It takes
   one argument that identifies the class that it augments.

4.5.2.3. The extends Statement

   The 'extends' statement is included in definition of a sparsely
   augmented PRC. This PRC definition sparsely augments a base PRC
   definition. It takes one argument that identifies the class that it
   sparsely augments.

   For more detailed explanation of usage of the above three index
   statements, please see [SPPI].

4.5.3. The prc's implements Statement

   The prc's 'implements' statement, which must be present at least
   once, makes this PRC contain columnar objects that are defined by a

Hegde, Sahita            Expires January 2002                 [Page 9]


Internet Draft           SMIng COPSPR Mapping                July 2001


   given class. It gets two arguments: the class being implemented and
   a statement block that holds detailed information on the attributes
   of that class being implemented in an obligatory order.

   It is possible to apply multiple implements statements to a single
   prc statement, each specifying a class. However, to add new
   attributes (that are added after a revision) from a class that is
   already implemented, it is possible to have multiple implements
   statements specifying the same class. This is needed to preserve the
   order of attributes existing prior to addition of the new
   attributes.

4.5.3.1. The implements' implobject Statement

   The 'implobject' statement, which must be present at least once,
   adds the single attribute of the class as a columnar object in the
   PRC. It gets one argument: the class attribute being implemented.
   Optionally, the attribute can be qualified with either a
   'pibreference' statement or 'pibtag' statement.

4.5.3.1.1. The implobject's pibreference Statement

   The 'pibreference' statement, which need not be present, is used to
   qualify the attribute as a 'ReferenceId'. For details about
   ReferenceId, please see section 6. It gets one argument, which is
   the name of the prc that is referenced by this pointer.

4.5.3.1.2. The implobject's pibtag Statement

   The 'pibtag' statement, which need not be present, is used to
   qualify the attribute as a 'TagReference'. For details about
   TagReference, please see section 6. This statement gets one
   argument, which is the name of the attribute in another class, which
   MUST be of type 'TagId'. For details about TagId, please see section
   6. Note that the SMIng currently does not support syntax to define
   groups of instances of a class contained as an attribute in another
   class. The TagId and TagReference semantics allow us to do that, and
   this mapping includes that ability.

4.5.4. The prc's status Statement

   The prc's 'status' statement, which need not be present, gets one
   argument, which is used to specify whether this PRC definition is
   current or historic. The value 'current' means that the definition
   is current and valid. The value 'obsolete' means the definition is
   obsolete and should not be implemented and/or can be removed if
   previously implemented.  While the value 'deprecated' also indicates
   an obsolete definition, it permits new/continued implementation in
   order to foster interoperability with older/existing
   implementations.

   PRCs SHOULD NOT be defined as 'current' if one or more of their
   classes are 'deprecated' or 'obsolete'. Similarly, they SHOULD NOT

Hegde, Sahita            Expires January 2002                [Page 10]


Internet Draft           SMIng COPSPR Mapping                July 2001


   be defined as 'deprecated' if one or more of their classes are
   'obsolete'.  Nevertheless, subsequent revisions of used class
   definition cannot be avoided, but SHOULD be taken into account in
   subsequent revisions of the local module.

   If the 'status' statement is omitted the status value 'current' is
   implied.

4.5.5. The prc's description Statement

   The prc's 'description' statement, which must be present, gets one
   argument, which is used to specify a high-level textual description
   of this PRC.

   It is RECOMMENDED to include all semantic definitions necessary for
   the implementation of this PRC.

4.5.6. The prc's reference Statement

   The prc's 'reference' statement, which need not be present, gets one
   argument which is used to specify a textual cross-reference to some
   other document, either another module which defines related
   definitions, or some other document which provides additional
   information relevant to this prc statement.

4.5.7. The prc's pibaccess Statement

   The prc's 'pibaccess' statement, which must be present, defines what
   kind of access is appropriate for the PRC.  The value for the
   pibaccess MUST be one of the following four choices:

   - The value "install" is used to indicate a PRC, which a PDP can
     install in the PEP as provisioning information.

   - The value "notify" is used to indicate a PRC for which the PEP
     must notify the PDP of all its instances and attribute values of
     that PRC.

   - The value "install-notify" is used to indicate the type
     of PRC which has both characteristics: "install" and "notify".

   - The value "report-only" is used to indicate a PRC which has
     neither the "install" characteristic nor the "notify"
     characteristic.  However, instances of such a PRC may be included
     in synchronous/asynchronous reports generated by the PEP.
     (Note: PRCs having the "install" and/or "notify" characteristics
     may also be included in reports generated by the PEP.)

4.5.8. The prc's piberrors Statement

   The prc's 'piberrors' statement, which need not be present, lists
   one or more potential reasons for rejecting an install or a removal
   of an instance of the PRC.  Each reason consists of a named-number

Hegde, Sahita            Expires January 2002                [Page 11]


Internet Draft           SMIng COPSPR Mapping                July 2001


   enumeration, where the number represents a PRC-specific error-code
   to be used in a COPS protocol message, as the Sub-Error Code, with
   the Error-Code set to priSpecificError (see [COPS-PR]).  The
   semantics of each named-number enumeration should be described in
   the prc's description statement.

   The numbers listed in 'piberrors' must be greater than zero and less
   than 65536.  If this clause is not present, an install/remove can
   still fail, but no PRC-specific error is available to be reported.

4.5.9. Usage Example

   prc filterTable {
       oid filterClasses.1;
       pibindex filterPrid;
       implements Filter {
           object name;
           object packets;
           object bytes;
       };
       description
           "A generic filter PRC.";
   };

   Note that the 'filterPrid' is the PRC's instance identifier of type
   'InstanceId', and is packaged as the first attribute.

4.6. The group Statement

   The 'group' statement is used to define a group of arbitrary nodes
   in the object identifier tree.  It gets two arguments: a lower-case
   group identifier and a statement block that holds detailed group
   information in an obligatory order.

   The primary application of groups are compliance statements.

   See the 'groupStatement' rule of the SMIng grammar (Section 5) for
   the formal syntax of the 'group' statement.

4.6.1. The group's oid Statement

   The group's 'oid' statement, which must be present, gets one
   argument which specifies the object identifier value that is
   assigned to this group.

4.6.2. The group's members Statement

   The group's 'members' statement, which must be present, gets one
   argument which specifies the list of nodes by their identifiers to
   be contained in this group. The list of nodes has to be comma-
   separated and enclosed in parenthesis.

4.6.3. The group's status Statement

Hegde, Sahita            Expires January 2002                [Page 12]


Internet Draft           SMIng COPSPR Mapping                July 2001



   The group's 'status' statement, which need not be present, gets one
   argument which is used to specify whether this group definition is
   current or historic. The value 'current' means that the definition
   is current and valid.  The value 'obsolete' means the definition is
   obsolete and the group should no longer be used.  While the value
   'deprecated' also indicates an obsolete definition, it permits
   new/continued use of this group.

   If the 'status' statement is omitted the status value 'current' is
   implied.

4.6.4. The group's description Statement

   The group's 'description' statement, which must be present, gets one
   argument which is used to specify a high-level textual description
   of this group.  It is RECOMMENDED to include any relation to other
   groups.

4.6.5. The group's reference Statement

   The group's 'reference' statement, which need not be present, gets
   one argument which is used to specify a textual cross-reference to
   some other document, either another module which defines related
   groups, or some other document which provides additional information
   relevant to this group.

4.6.6. Usage Example

   group frwkPrcSupportGroup {
       oid           frwkBasePibGroups.1;
       members       (frwkPrcSupportSupportedPrc,
                      frwkPrcSupportSupportedAttrs,
                      frwkPrcSupportMaxPris);
       description
           "A collection of object from the frwkPrcSupportTable."
   };

4.7. The compliance Statement

   The 'compliance' statement is used to define a set of compliance
   requirements. It gets two arguments: a lower-case compliance
   identifier and a statement block that holds detailed compliance
   information in an obligatory order.

   See the 'complianceStatement' rule of the SMIng grammar (Section 5)
   for the formal syntax of the 'compliance' statement.

4.7.1. The compliance's oid Statement

   The compliance's 'oid' statement, which must be present, gets one
   argument which specifies the object identifier value that is
   assigned to this compliance statement.

Hegde, Sahita            Expires January 2002                [Page 13]


Internet Draft           SMIng COPSPR Mapping                July 2001



4.7.2. The compliance's status Statement

   The compliance's 'status' statement, which need not be present, gets
   one argument which is used to specify whether this compliance
   statement is current or historic. The value 'current' means that the
   definition is current and valid. The value 'obsolete' means the
   definition is obsolete and no longer specifies a valid definition of
   conformance.  While the value 'deprecated' also indicates an
   obsolete definition, it permits new/continued use of the compliance
   specification.

   If the 'status' statement is omitted the status value 'current' is
   implied.

4.7.3. The compliance's description Statement

   The compliance's 'description' statement, which must be present,
   gets one argument which is used to specify a high-level textual
   description of this compliance statement.

4.7.4. The compliance's reference Statement

   The compliance's 'reference' statement, which need not be present,
   gets one argument which is used to specify a textual cross-reference
   to some other document, either another module which defines related
   compliance statements, or some other document which provides
   additional information relevant to this compliance statement.

4.7.5. The compliance's mandatory Statement

   The compliance's 'mandatory' statement, which need not be present,
   gets one argument which is used to specify a comma-separated list of
   one or more groups (Section 4.6) of objects and/or notifications
   enclosed in parenthesis. These groups are unconditionally mandatory
   for implementation.

   If the PEP or PDP [RAP-FRWK] claims compliance to a PIB module then
   it must implement each and every object within each group listed the
   'mandatory' statement(s) of the compliance statement(s) of that
   module.

4.7.6. The compliance's optional Statement

   The compliance's 'optional' statement, which need not be present, is
   repeatedly used to name each group which is conditionally mandatory
   for compliance to the module. It can also be used to name
   unconditionally optional groups.  A group named in an 'optional'
   statement MUST be absent from the correspondent 'mandatory'
   statement. The 'optional' statement gets two arguments: a lower-case
   group identifier and a statement block that holds detailed
   compliance information on that group.


Hegde, Sahita            Expires January 2002                [Page 14]


Internet Draft           SMIng COPSPR Mapping                July 2001


   Conditionally mandatory groups include those which are mandatory
   only if a particular protocol is implemented, or only if another
   group is implemented. The 'description' statement specifies the
   conditions under which the group is conditionally mandatory.

   A group which is named in neither a 'mandatory' statement nor an
   'optional' statement, is unconditionally optional for compliance to
   the module.

   See the 'optionalStatement' rule of the SMIng grammar (Section 5)
   for the formal syntax of the 'optional' statement.

4.7.6.1. The optional's description Statement

   The optional's 'description' statement, which must be present, gets
   one argument which is used to specify a high-level textual
   description of the conditions under which this group is
   conditionally mandatory or unconditionally optional.

4.7.7. The compliance's refine Statement

   The compliance's 'refine' statement, which need not be present, is
   repeatedly used to specify each object for which compliance has a
   refined requirement with respect to the module definition.  The
   object must be present in one of the conformance groups named in the
   correspondent 'mandatory' or 'optional' statements. The 'refine'
   statement gets two arguments: a lower-case identifier of an object
   and a statement block that holds detailed refinement information on
   that object.

   See the 'refineStatement' rule of the SMIng grammar (Section 5) for
   the formal syntax of the 'refine' statement.

4.7.7.1. The refine's installtype Statement

   The refine's 'installtype' statement, which need not be present,
   gets one argument that is used to provide a refined type for the
   correspondent object. Type restrictions may be applied by appending
   subtyping information according to the rules of the base type. See
   [SMING] for SMIng base types and their type restrictions.

4.7.7.2. The refine's pibminaccess Statement

   The refine's 'pibminaccess' statement, which need not be present,
   gets one argument that is used to specify the minimal level of
   access that the correspondent object must implement in the sense of
   its original 'access' statement. Hence, the refine's 'access'
   statement MUST NOT specify a greater level of access than is
   specified in the correspondent object definition.

   An implementation is compliant if the level of access it provides is
   greater or equal to the minimal level in the refine's 'pibminaccess'


Hegde, Sahita            Expires January 2002                [Page 15]


Internet Draft           SMIng COPSPR Mapping                July 2001


   statement and less or equal to the maximal level in the object's
   'pibminaccess' statement.

4.7.7.3. The refine's description Statement

   The refine's 'description' statement, which must be present, gets
   one argument which is used to specify a high-level textual
   description of the refined compliance requirement.

4.7.8. Usage Example

   compliance frwkBasePibCompliance {
       oid             frwkBasePibConformance.1;
       description
           "Describes the requirements for conformance to the Framework
           PIB."
       mandatory       (frwkPrcSupportGroup,
                        frwkPibIncarnationGroup,
                        frwkDeviceIdGroup,
                        frwkCompLimitsGroup,
                        frwkIfCapSetGroup,
                        frwkIfCapSetRoleComboGroup);
       refine frwkPibIncarnationLongevity {
           pibminaccess     notify;
           description
               "Install support is not required."
       };
       refine frwkPibIncarnationTtl{
           pibminaccess     notify;
           description
               "Install support is not required."
       };
       refine frwkPibIncarnationActive{
           pibminaccess     notify;
           description
               "Install support is not required."
       };
   };


5. IETF-SMING-COPSPR-EXT

   The grammar of the COPS-PR mapping SMIng extension conforms to the
   Augmented Backus-Naur Form (ABNF)[ABNF]. It is included in the abnf
   statement of the COPS-PR SMIng extension definition in the IETF-
   SMING-COPSPR-EXT module below.

   module IETF-SMING-COPSPR-EXT {

       organization    "IETF Next Generation Structure of
                        Management Information Working Group (SMIng)";

       contact         "Harsha Hegde

Hegde, Sahita            Expires January 2002                [Page 16]


Internet Draft           SMIng COPSPR Mapping                July 2001


                        JF3-206
                        2111 NE 25th Ave
                        Hillsboro, Oregon 97124
                        Phone: 503-264-1439
                        Email: shriharsha.hegde@intel.com

                        Ravi Sahita
                        JF3-206
                        2111 NE 25th Ave
                        Hillsboro, Oregon 97124
                        Phone: 503-712-1554
                        Email: ravi.sahita@intel.com ";

       description     "This module defines a SMIng extension to define
                        the mapping of SMIng definitions of identities,
                        classes, and their attributes to dedicated
                        definitions of nodes and tables for application
                        in the Policy Based Management framework using
                        COPS-PR."

       revision {
           date        "2001-07-18";
           description "Minor modifications to PRC statement.";
       };

       //
       // COPS-PR extension statement
       //

       extension copspr {
            description
              "The copspr statement maps SMIng definitions to COPS-PR
               conformant definitions.";
           abnf "
   ;;
   ;; sming-copspr.abnf -- Grammar of COPS-PR mappings in ABNF
   ;;                      notation (RFC 2234).
   ;;
   ;; Copyright (C) The Internet Society (2001). All Rights Reserved.
   ;;

   ;;
   ;; Statement rules.
   ;;

   copsprStatement         = copsprKeyword *1(sep lcIdentifier) optsep
                             "{" stmtsep
                                 *1(oidStatement stmtsep)
                                 *1(clienttypeStatement stmtsep)
                                 *(nodeStatement stmtsep)
                                 *(prcStatement stmtsep)
                                 *(groupStatement stmtsep)
                                 *(complianceStatement stmtsep)

Hegde, Sahita            Expires January 2002                [Page 17]


Internet Draft           SMIng COPSPR Mapping                July 2001


                                 *1(statusStatement stmtsep)
                                 descriptionStatement stmtsep
                                 *1(referenceStatement stmtsep)
                             "}" optsep ";"

   oidStatement            = oidKeyword sep objectIdentifier optsep ";"

   objectIdentifier        = (qlcIdentifier / subid) *127("." subid)

   subid                   = decimalNumber

   clienttypeStatement     = clienttypeKeyword optsep
                             "{" stmtsep
                                 allKeyword /
                                 categoryId *("," categoryId)
                             "}" optsep ";"

   categoryId              = identifier optsep "(" number ")"

   nodeStatement           = nodeKeyword sep lcIdentifier optsep
                             "{" stmtsep
                                 oidStatement stmtsep
                                 *1(representsStatement stmtsep)
                                 *1(statusStatement stmtsep)
                                 *1(descriptionStatement stmtsep)
                                 *1(referenceStatement stmtsep)
                             "}" optsep ";"

   representsStatement     = representsKeyword sep
                             qucIdentifier optsep ";"

   prcStatement            = prcKeyword sep lcIdentifier optsep
                             "{" stmtsep
                                 oidStatement stmtsep
                                 anyIndexStatement stmtsep
                                 1*(implementsStatement stmtsep)
                                 *1(statusStatement stmtsep)
                                 descriptionStatement stmtsep
                                 *1(referenceStatement stmtsep)
                                 pibaccessStatement stmtsep
                                 *1(piberrorsStatement stmtsep)
                             "}" optsep ";"


   anyIndexStatement       = pibindexStatement /
                             augmentsStatement /
                             extendsStatement

   pibindexStatement       = pibindexKeyword sep qlcIdentifier
                             optsep ";"

   augmentsStatement       = augmentsKeyword sep qlcIdentifier
                             optsep ";"

Hegde, Sahita            Expires January 2002                [Page 18]


Internet Draft           SMIng COPSPR Mapping                July 2001



   extendsStatement        = extendsKeyword sep qlcIdentifier
                             optsep ";"

   implementsStatement     = implementsKeyword sep identifier optsep
                             "{" stmtsep
                                 1*(implobjectStatement stmtsep)
                             "}" optsep ";"

   implobjectStatement     = objectKeyword sep
                             attributeIdentifier
                             *1( optsep
                                 "{" optsep
                                     pibreferenceStatement optsep /
                                     pibtagStatement optsep
                                 "}"
                             )
                             optsep ";"

   pibreferenceStatement   = pibreferenceKeyword sep
                             lcIdentifier optsep ";"

   pibtagStatement         = pibtagKeyword sep
                             lcIdentifier optsep ";"

   pibaccessStatement      = pibaccessKeyword sep
                             pibaccess optsep *1("," number)
                             optsep ";"

   pibaccess               = installonlyKeyword /
                             notifyonlyKeyword /
                             installnotifyKeyword /
                             reportonlyKeyword

   piberrorsStatement      = installerrorsKeyword sep
                             "{" stmtsep
                                 piberror optsep *("," piberror)
                             "}" optsep ";"

   piberror                = identifier optsep "(" number ")"

   groupStatement          = groupKeyword sep lcIdentifier optsep
                             "{" stmtsep
                                 oidStatement stmtsep
                                 membersStatement stmtsep
                                 *1(statusStatement stmtsep)
                                 descriptionStatement stmtsep
                                 *1(referenceStatement stmtsep)
                             "}" optsep ";"

   membersStatement        = membersKeyword optsep "(" optsep
                             qlcIdentifierList optsep
                             ")" optsep ";"

Hegde, Sahita            Expires January 2002                [Page 19]


Internet Draft           SMIng COPSPR Mapping                July 2001



   complianceStatement     = complianceKeyword sep lcIdentifier optsep
                             "{" stmtsep
                                 oidStatement stmtsep
                                 *1(statusStatement stmtsep)
                                 descriptionStatement stmtsep
                                 *1(referenceStatement stmtsep)
                                 *1(mandatoryStatement stmtsep)
                                 *(optionalStatement stmtsep)
                                 *(refineStatement stmtsep)
                             "}" optsep ";"

   mandatoryStatement      = mandatoryKeyword optsep "(" optsep
                             qlcIdentifierList optsep
                             ")" optsep ";"

   optionalStatement       = optionalKeyword sep qlcIdentifier optsep
                             "{" stmtsep
                                 descriptionStatement stmtsep
                             "}" optsep ";"

   refineStatement         = refineKeyword sep qlcIdentifier optsep "{"
                                 *1(installtypeStatement stmtsep)
                                 *1(pibminaccessStatement stmtsep)
                                 descriptionStatement stmtsep
                             "}" optsep ";"

   installtypeStatement    = installtypeKeyword sep
                             (refinedBaseType / refinedType)
                             optsep ";"

   pibminaccessStatement   = pibminaccessKeyword sep pibminaccess
                             optsep ";"

   pibminaccess            = noaccessKeyword /
                             installKeyword /
                             notifyKeyword /
                             installnotifyKeyword
   ;;
   ;; Statement keywords.
   ;;

   copsprKeyword       =  %x63 %x6f %x70 %x73 %x70 %x72
   oidKeyword          =  %x6f %x69 %x64
   clienttypeKeyword   =  %x63 %x6c %x69 %x65 %x6e %x74 %x74 %x79 %x70
                          %x65
   allKeyWord          =  %x63 %x6c %x6c
   nodeKeyword         =  %x6e %x6f %x64 %x65
   representsKeyword   =  %x72 %x65 %x70 %x72 %x65 %x73 %x65 %x6e %x74
                          %x73
   prcKeyword          =  %x70 %x72 %x63
   implementsKeyword   =  %x69 %x6d %x70 %x6c %x65 %x6d %x65 %x6e %x74
                          %x73

Hegde, Sahita            Expires January 2002                [Page 20]


Internet Draft           SMIng COPSPR Mapping                July 2001


   objectKeyword       =  %x6f %x62 %x6a %x65 %x63 %x74
   pibreferenceKeyword =  %x70 %x69 %x62 %x72 %x65 %x66 %x65 %x72  %x65
                          %x6E %x63 %x65
   pibtagKeyword       =  %x70 %x69 %x62 %x74 %x61 %x67
   pibaccessKeyword    =  %x70 %x69 %x62 %x61 %x63 %x63 %x65 %x73 %x73
   installonlyKeyword  =  %x69 %x6E %x73 %x74 %x61 %x6C %x6C %x6F %x6E
                          %x6C %x79
   notifyonlyKeyword   =  %x6E %x6F %x74 %x69 %x66 %x79 %x6F %x6E %x6C
                          %x79
   installnotifyKeyword=  %x69 %x6E %x73 %x74 %x61 %x6C %x6C %x6E %x6F
                          %x74 %x69 %x66 %x79
   reportonlyKeyword   =  %x72 %x65 %x70 %x6F %x72 %x74 %x6F %x6E %x6C
                          %x79
   installerrorsKeyword=  %x69 %x6E %x73 %x74 %x61 %x6C %x6C %x65 %x72
                          %x72 %x6F %x72 %x73
   pibindexKeyword     =  %x70 %x69 %x62 %x69 %x6e %x64 %x65 %x78
   augmentsKeyword     =  %x61 %x75 %x67 %x6d %x65 %x6e %x74 %x73
   extendsKeyword      =  %x65 %x78 %x74 %x65 %x6e %x64 %x73
   groupKeyword        =  %x67 %x72 %x6f %x75 %x70
   membersKeyword      =  %x6d %x65 %x6d %x62 %x65 %x72 %x73
   complianceKeyword   =  %x63 %x6f %x6d %x70 %x6c %x69 %x61 %x6e %x63
                          %x65
   mandatoryKeyword    =  %x6d %x61 %x6e %x64 %x61 %x74 %x6f %x72 %x79
   optionalKeyword     =  %x6f %x70 %x74 %x69 %x6f %x6e %x61 %x6c
   refineKeyword       =  %x72 %x65 %x66 %x69 %x6e %x65
   installtypeKeyword  =  %x69 %x6E %x73 %x74 %x61 %x6C %x6C %x74 %x79
                          %x70 %x65
   pibminacessKeyword  =  %x70 %x69 %x62 %x6d %x69 %x6E %x61 %x63 %x63
                          %x65 %x73 %x73
   noaccessKeyword     =  %x6E %x6f %x61 %x63 %x63 %x65 %x73 %x73
   installKeyword      =  %x69 %x6E %x73 %x74 %x61 %x6C %x6C
   notifyKeyword       =  %x6E %x6F %x74 %x69 %x66 %x79


   ;;
   ;; EOF
   ;;

                 ";

       };

   };


6. IETF-SMING-COPSPR

   module IETF-SMING-COPSPR {

       organization    "IETF Next Generation Structure of
                        Management Information Working Group (SMIng)";

       contact         "Harsha Hegde

Hegde, Sahita            Expires January 2002                [Page 21]


Internet Draft           SMIng COPSPR Mapping                July 2001


                        JF3-206
                        2111 NE 25th Ave
                        Hillsboro, Oregon 97124
                        Phone: 503-264-1439
                        Email: shriharsha.hegde@intel.com

                        Ravi Sahita
                        JF3-206
                        2111 NE 25th Ave
                        Hillsboro, Oregon 97124
                        Phone: 503-712-1554
                        Email: ravi.sahita@intel.com ";

       description     "Core type definitions for the SMIng COPS-PR
                        mapping. These definitions are based on [SPPI]
                        definitions. They are specific to the COPS-PR
                        protocol and its naming system.";

       revision {
           date        "2001-07-18";
           description "No modifications to the initial version.";
       };

       typedef InstanceId {
           type        Unsigned32 (1..4294967295);
           description
               "The type for use by an attribute which is used as
               the instance-identifying index of a PRC[COPS-PR], i.e.,
               an attribute that MUST be added as the 'pibindex' to a
               base PRC and it MUST be the first attribute of the PRC.
               The value of an attribute with this syntax is always
               greater than zero. PRIs[COPS-PR] of the same PRC need
               not have contiguous values for their instance-
               identifying attribute.";
           reference
               "[SPPI]";
       };

       typedef ReferenceId {
           type        Unsigned32;
           description
               "A typedef for use by an attribute which is used as a
               pointer in order to reference an instance of a
               particular PRC.  An attribute with this syntax must not
               be used in a pibindex statement, and the objects
               pibreference statement must specify the particular PRC
               to which the referenced PRI will belong. For an
               attribute of this type, the referenced PRI must exist.
               Furthermore, it is an error to try to delete a PRI that
               is referenced by another instance without first
               deleting/modifying the referencing instance. The
               definition of an attribute with this syntax can permit
               the attribute to have a value of zero to indicate that

Hegde, Sahita            Expires January 2002                [Page 22]


Internet Draft           SMIng COPSPR Mapping                July 2001


               it is not currently pointing to an PRI.";
           reference
               "[SPPI]. Also see definition of 'Prid'.";
       };

       typedef Prid {
           type        Pointer;
           description
               "Represents a pointer to a PRI, i.e,. to an instance of
               a PRC.  The value is the OID name of the PRC's row
               definition, appended with one sub-identifier containing
               the value of the InstanceId value for the referenced
               instance.  The definition of an attribute with this
               syntax can permit the attribute to have a value of
               'NULL' (0.0) to indicate that it is not currently
               pointing to a PRI.";
           reference
               "[SPPI]. Also see definition of 'ReferenceId'.";
       };

       typedef TagId {
           type        Unsigned32 (1..4294967295);
           description
               "Represents a tag value, such that all instances of
               aparticular PRC having the same tag value form a tag
               list. A tag list is identified by the tag value shared
               by all instances in that tag list.";
           reference
               "[SPPI]. Also see definition of 'TagReferenceId'.";
       };

       typedef TagReferenceId {
           type        Unsigned32;
           description
               "Represents a reference to a tag list of instances of a
               particular PRC.  The particular PRC must have an
               attribute with the syntax of TagId.  The tag list
               consists of all instances which have the same value of
               the TagId attribute.  Reference to the tag list is via
               the attribute with the syntax of TagReferenceId
               containing the tag value which identifies the tag list.
               The attribute of this type must use the pibtagstatement
               to specify the attribute of type TagId in the PRC
               containing the tagged list of instances. The attribute
               can have a value zero if it is not currently  pointing
               to a tagged list.";
           reference
               "[SPPI]. Also see definition of 'TagId'.";
       };

   };



Hegde, Sahita            Expires January 2002                [Page 23]


Internet Draft           SMIng COPSPR Mapping                July 2001


7. Security Considerations

   This document presents an extension of the SMIng data definition
   language that supports the mapping of SMIng data definitions so that
   they can be used with the Policy Based Management framework using
   COPS-PR. The language extension and the mapping itself have no
   security impact on the Internet.

8. Acknowledgements

   Since SPPI is very similar to SMIv2, some paragraphs and phrases are
   directly taken from the SMIng mappings to SNMP Internet Draft [SNMP-
   MAP]. Thanks to the authors of [SNMP-MAP].

9. Authors' Addresses

   Harsha Hegde
   JF3-206
   2111 NE 25th Ave
   Hillsboro, Oregon 97124
   Phone: 503-264-1439
   Email: shriharsha.hegde@intel.com

   Ravi Sahita
   JF3-206
   2111 NE 25th Ave
   Hillsboro, Oregon 97124
   Phone: 503-712-1554
   Email: ravi.sahita@intel.com


10. References

   [SMING]
       Strauss, F., Schoenwaelder, J., McCloghrie, K., "SMIng ├╗Next
       Generation Structure of Management Information", draft-ietf-
       sming-01.txt, March 2001.

   [SNMP-MAP]
       Strauss, F., Schoenwaelder, J., McCloghrie, K., "SMIng Mappings
       to SNMP", draft-ietf-sming-snmp-01.txt, March 2001.

   [SMIV2]
       McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
       M. and Waldbusser, S., "Structure of Management Information
       Version 2(SMIv2)", STD 58, RFC 2578, April 1999.

   [RAP-FRWK]
       R. Yavatkar, D. Pendarakis, "A Framework for Policy-based
       Admission Control", RFC 2753, January 2000.

   [COPS]
       Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., and A.

Hegde, Sahita            Expires January 2002                [Page 24]


Internet Draft           SMIng COPSPR Mapping                July 2001


       Sastry, "The COPS (Common Open Policy Service) Protocol" RFC
       2748, January 2000.

   [COPS-PR]
       D. Durham, K. McCloghrie, J. Seligson, K. Chan, S. Gai, S.
       Herzog, A. Smith, R. Yavatkar, F. Reichmeyer., "COPS Usage for
       Policy Provisioning (COPS-PR)" RFC 3084, March 2001.

   [SPPI]
       M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, R.Sahita,
       A. Smith, F. Reichmeyer., "Structure of Policy Provisioning
       Information," draft-ietf-rap-sppi-07.txt, May 2001.

   [ABNF]
       Crocker, D., Overell, P., "Augmented BNF for Syntax
       Specifications: ABNF", RFC 2234, November 1997.

   [ASN1]
       Information processing systems - Open Systems Interconnection -
       Specification of Abstract Syntax Notation One (ASN.1),
       International Organization for Standardization.  International
       Standard 8824, December 1987.

   [KEYWORD]
       Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", RFC 2119, BCP 14, March 1997.




























Hegde, Sahita            Expires January 2002                [Page 25]