Appendix 1:  Notational Tools for Managed Object Definition

   This section provides descriptions of the notational tools used to
   define the templates defined in this memorandum.  The text is
   excerpted and paraphrased from reference 6.  Only the templates used
   in this document are included here.  For a complete description of
   the notational tools specified for OSI management, see reference 6.

A1.1 Overview of Notational Tools

   The "Templates" defined in this clause provide a common set of tools
   and a common format for the representation of the various aspects of
   a managed object class definition and its associated naming
   structure.  Formal definitions of each template will be found in
   clauses A1.3 -A1.11 inclusive; the syntactic conventions used in
   these formal definitions are specified in clause A1.2.  Examples of
   the use of these tools may be found in Annex A (of 10165-4).

   The structure and behaviour of a managed object class is primarily
   defined by means of the Managed Object Class Template.  This template
   identifies the inheritance relationships that exist between the class
   and other managed object classes, the packages of class specific
   behaviour, the attributes that are associated with the class, the
   notifications that the class may issue and the operations that may be
   performed upon the class.  In order to allow re-use of parts of this
   specification in the specification of other managed object classes,
   additional templates are defined to provide for the specification of
   attributes (individual and group), behaviour, actions, notifications
   and conditional packages.  These other templates are "called up" by
   the Managed Object Class template by means of the referencing
   mechanism defined in clause A1.2; this mechanism allows references to
   be made in one standard to specifications that are contained in other
   standards, hence allowing "generic" specifications to be made
   available for use in managed object class definitions in addition to
   local specifications. Templates may also be included "in-line" if so
   desired.

   The naming of a managed object class is defined by means of the Name
   Binding template.  This template identifies the managed object class
   being named and defines the relative distinguished name that will be
   used to name instances of the class in the context of a particular
   superior class.  This template also provides for the specification of
   relationships that exist between two object classes as a consequence
   of a particular name binding.

A1.2 Conventions Used in Template Definitions

   The templates definitions contained in this clause are based on the
   following syntactic conventions:

   - Strings surrounded by [ ] delimit parts of the template that may
     either be present or absent in each instance of use of the
     template. If the closing brace is followed by an asterisk,
     e.g., [ ]*, the contents of the braces may appear zero or more
     times.  The circumstances under which these parts of the
     definition may be omitted or repeated are dependent upon the
     template type;

   - Strings surrounded by < > delimit strings that must be replaced in
     each instance of use of the template.  The structure and meaning
     of the replacement string is dependent upon the string type;

   - Upper case strings denote Keywords which are required to be
     present in each instance of use of the template, unless they are
     enclosed in [ ];

   - The solidus, |, is used to separate alternative strings in the
     template;

   - Spaces and carriage returns are significant only as string
     delimiters;

   - In order to simplify the structure of the templates, particularly
     where the same syntactic structure is repeated in the template
     definitions, supporting syntactic definitions may be defined.  If
     any such supporting syntactic definitions are required in order to
     complete the template definition, these appear following the
     keywords "supporting productions" at the end of the template
     definition. These supporting definitions take the general form

                   definition-label-> syntactic-definition

   where definition-label allows the definition to be referenced by the
   template definition and syntactic-definition gives the expansion of
   the definition, using the above notational rules;

   - The templates themselves have the general structure:

                <template-label>TEMPLATE NAME

        [ELEMENT NAME [<element-definition>] ;]*

        [REGISTERED AS <object-identifier> ;]

        [supporting productions

        [<definition-label> -> <syntactic-definition >]*]

   Each instance of use of a template therefore declares a template-
   label by which that instance may be referenced from other templates,
   and if the REGISTERED AS clause is present, assigns a value of an
   ASN.1 OBJECT IDENTIFIER under which the instance has been registered;

   - Semicolons are used to mark the end of each distinct element in
     the template.  In an instance of use of the template, any text
     inserted between a semicolon and the next valid keyword is
     assumed to be a comment;

   - The notation used for representing object identifiers is the
     normal notation defined in ASN.1 for object identifier values;
     i.e., the production:

        object-identifier-> <ASN.l ObjectIdentifierValue notation>

        is assumed to be a supporting production for all template
        definitions in this document;

   - Further definitions, such as the nature of the element definitions,
     follow the syntactic definition of the template;

   - Template labels shall be unique within the standard or document
     in which they are declared.  Where a template-label is declared in
     document A and referenced in document B, the reference in
     document B shall be prefixed by the globally unique name of
     document A.  In the case of documents named by an
     internationally recognized naming authority such as
     [CCITT|ISO/IEC], the registered name of the document shall be
     used as the identifier, such as [Recommendation X.722|ISO/IEC
     10165-4]. Where a globally unique name is not already available,
     it is permissible to assign the value of an OBJECT IDENTIFIER to
     the referenced document, and use this value as a globally unique
     document name.  The syntax of a template-label, defined using the
     above notation, is defined as follows:

        [<document-identifier> :] < label-string>

        document-identifier-> "<standard-name>" | <object-identifier>

   A label-string may include any number of the following characters:

        -       upper or lower case alphabetic characters;

        -       the digits 0-9;

        -       the hyphen character (-);

   in any order, commencing with a lower case character.  For example,
   the following template-label:

        "ISO/IEC 10165/4":exampleObjectClass

   constitutes a globally unique label for the definition of
   exampleObjectClass contained in Annex A of 10165-4.

   Label references that are not prefixed by a document-identifier are
   assumed to refer to labels declared in the document in which the
   reference appears.

   -  Whenever a template-label is present in a template as a
      pointer to another template, it may be replaced by the entire
      text of the referenced template itself (including the
      template's label).

A1.3  Managed Object Class Template

A1.3.1  Overview

   The Managed Object Class template forms the basis of the formal
   definition of a managed object.  Elements in the template allow the
   class to be placed at the appropriate node of the inheritance tree,
   the various attributes of the class to be specified, and the
   behaviour of the class to be defined.  The major elements of the
   definition are:

   - Inheritance.  Each managed object class defines the
     superclass(es) from which it has been derived.  All
     characteristics of the superclass(es) are inherited by the
     subclass; the subclass definition may add to these
     characteristics (refinement) but may not remove any
     characteristics of the superclass. Ultimately, all classes are
     subclasses of TOP;

   - Allomorphs.  If the class supports allomorphism, the set of
     classes that are legitimate allomorphic views of the class must
     be defined.  These classes must all be superclasses of the class
     being defined;

   - Mandatory Packages.  The managed object class definition
     includes the packages of behaviour, attributes, operations and
     notifications that provide a complete specification of the

     behaviour that is common to all instances of the class;

   - Conditional Packages.  The managed object class definition
     includes the specification of packages of behaviour, attributes,
     operations and notifications that are present or absent in
     instances of that class as a consequence of a specified condition;

   Note: Attributes, Operations and Notifications that form part of a
   class definition may only be omitted from an instance of that class
   if they are defined as features of a Conditional Package and are
   omitted in accordance with the condition defined for that package.

   - Class Naming. The managed object class definition must include a
     class name which may be used to refer to the class in CMIP.  This
     is achieved by registration of an Object Identifier value which
     corresponds to the class.

A1.3.2 Template Structure

   <class-label> MANAGED OBJECT CLASS

           [DERIVED FROM   <class-label>
                   [, <class-label>]*;
           ]
           [ALLOMORPHIC SET        <class-label>
           [, < class-label > ] *;
           ]
    [CHARACTERIZED BY <package-label>[,<package-label>]*;
    ]
    [CONDITIONAL PACKAGES <package-label> PRESENT IF
                                           <condition-definition>
                                           [,<package-label> PRESENT IF
                                            <condition-definition>]*;
    ]
    [PARAMETERS <parameter-label> [,<parameter-label>]*;
    ]

   REGISTERED AS < object-identifier>;

A1.3.3 Supporting Definitions

   DERIVED FROM <class-label>[,<class-label>]*

   The DERIVED FROM clause shall be present in all managed object class
   definitions other than "top".  It is therefore the case that "top" is
   a superclass of all classes other than itself.

   The class-label identifies a managed object class from which the

   managed object class has been derived; i.e., a managed object class
   which is one of the object class's parents in the inheritance
   hierarchy.  As multiple inheritance is permitted, a managed object
   class may have one or more parent classes.

   The process of inheritance (specialization) requires all the
   characteristics of the superclass(es) other than DERIVED FROM and
   ALLOMORPHIC SET to be included in the definition of the subclass.  If
   it is intended that the subclass be allomorphic, the definition of
   the subclass shall include a ALLOMORPHIC SET clause that explicitly
   defines the set of classes that the subclass is allomorphic to.

   Where multiple inheritance results in the same element definition
   being multiply imported (as could happen, for example, if two parent
   superclasses contain the same attribute), the subclass is assumed to
   contain a single copy of the definition concerned.

   Characteristics that are inherited from a superclass shall not be
   repeated in the documentation of the subclass unless one of the
   techniques described in ISO/IEC 10165-4 for extending or modifying an
   element of the superclass is being used.  The DERIVED FROM clause is
   therefore presumed to automatically import all inheritable elements
   of definition from the superclass definition(s).  There may be
   augmented or modified by elements defined within the CHARACTERISED
   BY, CONDITIONAL PACKAGES, and PARAMETER constructs.

   ALLOMORPHIC SET <class-label>[,<class-label>]*

   The Allomorphic Set allows a set of superclasses to be identified
   that are "backwards compatible" with the managed object class. Thus,
   if managed object class A identifies classes B and C as members of
   its allomorphic set, it is possible to operate on an instance of
   class A as if it were an instance of class B or C.  The definition of
   allomorphic forms allows, for example, the definition of enhanced
   versions of a managed object class that are backwards compatible with
   previous versions.  The class label shall identify the class-label of
   a managed object class definition that is a superclass of the managed
   object class that is being defined.

   CHARACTERIZED BY <package-label>[,<package-label]*

   This construct, if present, allows one or more mandatory packages of
   behaviour, attributes, operations, and notifications to be included
   in the managed object class definition, in addition to those that are
   present as a result of the Derived From construct.

   CONDITIONAL PACKAGES <package-label>  PRESENT IF <condition-
   definition>[, <package-label>  PRESENT IF <condition-definition>]*

   Present if one or more conditional packages are to be included in the
   managed object class definition.  The package-label identifies the
   package definition that is applicable.  The condition-definition is a
   description of the condition that, if true, requires that the package
   be included in an instance of the class.  The condition shall refer
   to a documented feature of the definition of the underlying resource
   or a related standard which is permitted to be present or absent in
   an implementation.

   PARAMETERS <parameter-label>[,<parameter-label>]*

   If present, this construct permits the definition of parameters to be
   included in the object class definition in addition to any inherited
   parameters.

   REGISTERED AS <object-identifier>

   The object identifier value provides a globally unique identifier for
   the object class definition.  This value is used in the management
   protocol when it is necessary to identify the object class.

A1.4  Package Template

   This template allows a package of behaviour definitions, attributes,
   operations and notifications to be defined for subsequent insertion
   into a managed object class template under the Characterized By and
   Conditional Packages constructs.  The major elements of the
   definition are:

   - Behaviour. The managed object class definition provides a
     complete specification of the behaviour of the object.  This
     includes:

      - The effect of the Operations upon the managed object;

      - Any constraints that are placed on operations in order to
        satisfy consistency rules, and in particular, the rules under
        which Creation and Deletion of managed objects may be
        performed and the consequences of these operations;

      - A specification of how instances of a managed object class
        interact with each other, related, managed objects of the same
        or different classes.

      - A complete definition of any other aspects of the
        behaviour of the managed object class.

      - Contained attributes.  The set of attributes that the

        package contains must be defined;

      - Operations and Notifications.  The package definition
        specifies which notifications instances of the class that make
        use of this package shall be able to generate, which operations
        instance of the class shall be capable of performing, and in the
        case of attribute related operations, which attributes shall be
        available to be operated upon.

   Note: The operations identified in the package definition are the
   operation types defined in the Information Model (Get, Replace, Set
   to Default,...etc).  In the case of Actions and Notifications,
   further definitions are required in order to characterise their
   functionality, as described in clauses A1.10, A1.11.  The create and
   delete operations are defined as part of the Name Binding template
   described in clause A1.6, a creation and deletion of an object is
   closely bound to the containment relationship between superior and
   subordinate objects, rather than to all instances of a managed object
   class.

A1.4.1 Template Structure

< package-label> PACKAGE

[BEHAVIOUR DEFINITIONS  < behaviour-definition-label>
        [, < behaviour-definition-label > ] *;
]
[ATTRIBUTES<attribute-label> <propertylist>[<parameter-label>]
        [,< attribute-label> < propertylist> [< parameter-label> ]*]*;
]
[ATTRIBUTE GROUPS       <group-label> [<attribute-label>]*
                          [, < group-label > [ < attribute-label > ]*]*;
]
[ACTIONS        <action-label>[<parameter-label>]*
                          [, < action-label > [ < parameter-label > ]*]*;
]
[NOTIFICATIONS             <notification-label> [<parameter-label>]*
                    [, < notification-label > [< parameter-label >]*]*;
]
[REGISTERED AS < object-identifier>];

supporting productions

propertylist -> [REPLACE WITH DEFAULT]
        [DEFAULT VALUE < value-definition > ]
        [PERMITTED VALUES <value-set-syntax-label>]
        [REQUIRED VALUES        <value-set-syntax-label>]
        [GET | REPLACE | GET-REPLACE]

        [ADD | REMOVE | ADD-REMOVE]

A1.4.2 Supporting Definitions

   BEHAVIOUR DEFINITIONS < definition-label> [,<definition-label>]*

   Behaviour Definitions allow the behaviour (semantics) of the managed
   object class to be completely described.  These definitions relate
   the external view of the object (its operations and notifications) to
   its internal operation.  The definition-label identifies an instance
   of use of the Behaviour template.

   Note:  It should not be assumed that the behaviour defined by this
   clause is testable using existing conformance test technology.

   ATTRIBUTES.  <attribute-label><propertylist> [<parameter-label>]*
           [,<attribute-label><propertylist> [<parameter-label>]*]*

   This allows attributes to be included in the package definition. The
   propertylist that follows each attribute label defines the set of
   operations that may be performed on the managed object with reference
   to the attribute, and defines any default, permitted or required
   value(s) associated with the attribute.  The Replace With Default
   property is included if the property has a default value that may be
   set by means of the Replace With Default Value operation.  The
   value-definition used to specify the default value shall be a value
   reference name, using the Externaltypereference notation defined in
   ISO 8824.

   If the PERMITTED VALUES property is present, the value-set- syntax-
   label specifies any restrictions on the possible values that the
   attribute may take.  The value-set-syntax-label shall be a type
   reference name, using the ExternaltypeReference notation defined in
   ISO 8824.  The form of the specification referenced shall be a
   subtype of the attribute syntax type, defined using the ASN.1 subtype
   notation.

   Note:  The Permitted Values construct is required only in attribute
   definitions where it is necessary to specify a restriction on the
   value set permitted by the specification of the Attribute Syntax,
   e.g., when modifying an existing attribute specification.

   If the REQUIRED VALUES property is present, the value-set- syntax-
   label specifies any restrictions on the possible values that the
   attribute may take.  The value-set-syntax-label shall be a type
   reference name, using the ExternaltypeReference notation defined in
   ISO 8824.  The form of the specification referenced shall be a
   subtype of the attribute syntax type, defined using the ASN.1 subtype

   notation.

   Note:  This property defines the value set required for conformance.

   The parameter-labels allow parameters to be associated with the
   operations permitted on the attribute.

   ATTRIBUTE GROUPS <group-label> [<attribute-label>]*[,<group-label>
   [<attribute-label>]*]*

   This allows a set of attributes groups to be identified as part of
   the package.  The original definition of an attribute group may be
   extended by the addition of further attribute-labels.

   ACTIONS <action-label>[<parameter-label>]*
           [,<action-label>[<parameter-label>]*]*

   If present, the action-labels identify the set of action definitions
   that are included in the package.  The behaviour definitions shall
   specify the effect of these Actions upon managed objects.

   The parameter-labels allow parameters to be associated with the
   Action.

   NOTIFICATIONS <notification-label>[<parameter-label>]*
                   [,<notification-label>[<parameter-label>]*]*

   Present if any Notifications are included in the package. The
   notification labels identify the Notification definitions that are
   applicable.  The behaviour definitions shall specify the
   circumstances under which those Notifications are generated by a
   managed object.

   The parameter-labels allow parameters to be associated with the
   Notification.

   REGISTERED AS <object-identifier>

   The object identifier value, if present, provides a globally unique
   identifier for the package definition, and registers the groupings of
   behaviour definitions, attributes, attribute groups, actions and
   notifications that the package defines.  This value is required in
   cases where the package is referenced by a conditional packages
   construct in an object class template and the package contains a
   behaviour construct or more than one element, in which case the value
   of the object identifier is included in the conditional packages
   attribute of any instances of the object class that are created with
   the package present.

A1.5 Parameter Template

   This template permits the specification and registration of parameter
   syntaxes and associated behaviour that may be associated with
   particular operations and notifications within the managed object
   class and conditional package templates defined in clauses A1.3 and
   A1.4.  This mechanism is not used in the OIM MIB-II.

A1.6  Name Binding Template

A1.6.1  Overview

   This template allows alternative naming structures to be defined for
   managed objects of a given managed object class by means of name
   bindings.  The name binding allows an attribute to be selected as the
   naming attribute for a given subordinate class/superior class pair.

   The attribute selected must be an attribute of the subordinate object
   that is present in all instances of the specified managed object
   class.  This attribute is used for the purpose of constructing the
   relative distinguished name (RDN) of subordinate objects of that
   class.  An RDN is constructed from the OBJECT IDENTIFIER assigned to
   that attribute type and the value of the instance of the attribute.
   The Distinguished Name of the subordinate object is obtained by
   appending its RDN to the Distinguished Name of its superior object.

   Name bindings are not considered to be part of the definition of
   either of the managed object classes that they reference.  A given
   managed object class may have more than one name binding associated
   with it.  The set of name bindings defines the set of possible naming
   relationships with superior managed objects and the set of managed
   object classes from which subordinate object classes may be
   instantiated.

   Note: Name Bindings may be specified for a managed object class
   subsequent to the specification of the managed object class itself.

A1.6.2  Template Structure

   <name-binding-label> NAME BINDING

   SUBORDINATE OBJECT CLASS <class-label>;
   NAMED BY
   SUPERIOR OBJECT CLASS    <class-label>;
   WITH ATTRIBUTE       <attribute-label>;
   [BEHAVIOUR     <behaviour-definition-label>
                                   [,<behaviour-definition-label>]*;
   ]

    [CREATE [<create-modifier>[,<create-modifier>]]
                                                   [<parameter-label>]*;
    ]
    [DELETE                <delete-modifier>[<parameter-label>]*;
    ]

   REGISTERED AS < object-identifier>;

   supporting productions

   create-modifier->       with-reference-object |
                           with-automatic-instance-naming

   delete-modifier ->      only-if-no-contained-objects |
                                   deletes-contained-objects

A1.6.3  Supporting Definitions

   SUBORDINATE OBJECT CLASS <class-label>

   This defines the managed object class being named.  The name of an
   instance of the subordinate managed object class is constructed by
   concatenating the distinguished name of the superior managed object
   class with the relative distinguished name of the subordinate managed
   object class.

   NAMED BY SUPERIOR OBJECT CLASS <class-label>

   This defines a managed object class that may contain instances of the
   subordinate managed object class.

   WITH ATTRIBUTE <attribute label>

   This defines the attribute that shall be used, in the context of this
   name binding, to construct the relative distinguished name for the
   subordinate managed object class.  Values of this attribute shall be
   represented by single-valued data types, complying with the
   restrictions specified in ISO 10165-1;  if no naturally suitable
   attribute is available for use as a naming attribute, object
   designers are encouraged to provide a naming attribute of type
   Graphic String.

   BEHAVIOUR <behaviour-definition-label>

   If present, this clause permits any behavioural impact imposed as a
   consequence of the name binding to be defined.  The behaviour-
   definition-label identifies the constraint definition concerned; the
   constraint is therefore expressed using the behaviour template.

   CREATE  [<create-modifier>[,<create-modifier>]][<parameter-label>]*

   Present if it is permitted to create new instances of the managed
   object class referenced by the SUBORDINATE OBJECT CLASS construct in
   the context of this name binding, by means of systems management
   operations.  The create-modifier values specify the options available
   on creation.  The permitted create- modifiers are as follows:

      - with reference-object.  If present, a reference object may be
        specified on creation as a source of default values and to
        specify choice of Conditional Packages;

      - with automatic  instance  naming.  If present, the CREATE
        request may omit to specify the instance name of the new
        object instance.  The behaviour definitions shall specify what
        course of action is taken when there is a choice of Name Forms
        that may be applied to the new object instance.

   If neither create-modifier is specified, the instance name and all
   necessary default values shall be specified in the CREATE request.

   The parameter-labels allows parameters to be associated with the
   CREATE operation.

   DELETE <delete-modifier> [<parameter-label>]*

   Present if it is permitted to delete instances of the managed object
   class referenced by the SUBORDINATE OBJECT CLASS construct in the
   context of this name binding.  The delete- modifier indicates the
   behaviour of a managed object of that class if the managed object is
   deleted.  The permitted delete-modifiers are:

      - only-if-no-contained-objects.  If specified, any contained
        managed objects must be explicitly deleted prior to deletion of
        the containing managed object, i.e., a DELETE request will cause an
        error if there are contained managed objects;

      - delete-contained-objects.  If specified, a DELETE request
        applied to an instance of the managed object class has the effect
        of deleting contained objects also.

   If there are constraints on deletion relative to other relationships
   or conditions, these are specified as part of the behaviour of the
   managed object class.

   The parameter-labels allows parameters to be associated with the
   DELETE operation.

A1.7 Attribute Template

A1.7.1  Overview

   This template is used to define individual attribute types. These
   definitions may be further combined by the Attribute Group template
   where attribute groups are required.  The major elements of the
   definition are:

      - Derivation.  The definition of an attribute type may modify or
        constrain the definition of another attribute type.

      - Attribute Syntax.  The definition of an attribute type must
        include the definition of the syntax that will be used to convey
        values of the attribute in CMIP.  This definition is achieved by
        means of a reference to an ASN.l Type Definition.  The
        definition of an attribute syntax indicates whether the
        attribute value is a single or set-valued attribute type.  If
        the base type is SET OF, the attribute is a set-valued type,
        otherwise it is a single-valued type;

      - Value Matching.  The definition of an attribute type may
        include the valid ways in which the value of an instance of the
        type may be tested, i.e., whether the attribute may be tested
        for equality, magnitude, etc..  Value matching on some attribute
        types may require the specification of how a matching rule is
        defined to operate, as part of the attribute's behaviour
        definition.  The absence of any matching rules in the attribute
        definition implies that matching of values is undefined;

      - Behaviour.  The attribute definition may include definition of
        attribute specific behaviour; i.e., behaviour that applies to an
        attribute type regardless of which managed object class contains
        instances of tho attribute type;

      - Attribute type name.  An Object Identifier value shall be
        allocated to each attribute that is to be included in the
        definition of a managed object class. This value is used in CMIP
        to identify the attribute.

A1.7.2 Template Structure

      <attribute-label> ATTRIBUTE

      derived-from-construct | with attribute-syntax-construct
      [MATCHES FOR    <qualifier>[,<qualifier>]* ;]
      [BEHAVIOUR      <behaviour-definition-label>
                      [,<behaviour-definition-label>]* ;

      ]
      [PARAMETERS     <parameter-label>
                      [,<parameter-label>]*
      ]

      [REGISTERED AS < object-identifier> ;]

      supporting productions

      qualifier -> Equality | Ordering | Substrings
                   | Set Comparison | Set Intersection

      derived-from-construct -> DERIVED FROM  <attribute-label > ;

      with-attribute-syntax-construct -> WITH ATTRIBUTE SYNTAX
                                      <syntax-label> ;

A1.7.3 Supporting Definitions

   DERIVED FROM <attribute-label>

   If this element is present, the attribute definition takes as a
   starting point all aspects of the definition referenced by
   attribute-label, including any that it may in turn have derived from
   other attribute definitions.  The rules for interpreting the effect
   of presence of any of the other elements of the attribute template
   under these circumstances are as follows:

      - WITH ATTRIBUTE SYNTAX is not permitted to be present.  The
        attribute syntax shall be the attribute syntax of the attribute
        from which this attribute has been derived.;

      - MATCHES FOR: The resultant set of matching rules shall be the
        logical OR of the matching rules specified by this construct
        with any derived matching rules;

      - BEHAVIOUR is assumed to extend any derived behaviour
        definitions;

      - REGISTERED AS is assumed to replace any registration derived
        from other definitions.

   This derivation mechanism permits:

      - The definition of an attribute based on an existing attribute
        definition;

      - The addition of further constraints to an existing attribute

        definition.

   WITH ATTRIBUTE SYNTAX <syntax label>

   This element, present only if the DERIVED FROM construct is absent,
   identifies the ASN.1 data type that describes how instances of the
   attribute value are carried in protocol.  The syntax-label shall be
   an ASN.l Externaltypereference.

   The ASN.1 data type also defines the data type of the attribute
   itself.  If the base type of the syntax is set-of, the attribute is a
   set-valued attribute.  All other ASN.l data types, including set,
   sequence of, and sequence type, define single-valued attribute types.

   MATCHES FOR <qualifier>[,<qualifier>]*

   This element defines the types of test that may be applied to a value
   of the attribute as part of a Filter operation. Matching for the
   presence of an attribute is implicitly permitted for all attributes.
   For all other types of matching, if this clause is not present,
   matching is undefined and is therefore not permitted on the
   attribute.  The options are:

      - Equality.  If present, the attribute value may be tested for
        equality against a given value;

      - Ordering.  If present, the attribute value may be tested against
        a given value in order to determine which has the greater
        value;

      - Substrings.  If present, the attribute value may be tested
        against a given substring value in order to determine its
        presence or absence in the attribute value;

      - Set Comparison.  If present, the attribute value may be tested
        against a given value in order to determine set equality or
        subset/superset relationships between the values;

      - Set Intersection.  If present, the attribute value may be tested
        against a given value in order to determine the presence or
        absence of a non-null set intersection between the two values.

   BEHAVIOUR <behaviour-definition-label>
                   [,<behaviour-definition-label>]*

   Any behaviour that is generic to this attribute type may be defined
   by means of this behaviour clause.  The behaviour definition shall
   include any additional specification that is required in order to

   define how the chosen set of matching rules are applied to the
   attribute definition.  Behaviour that is specific to the managed
   object class is defined in the behaviour clause of the managed object
   class template.

   Note:  It should not be assumed that the behaviour defined by this
   clause is testable using existing conformance test technology.

   REGISTERED AS <object-identifier>

   If present, the object-identifier provides a globally unique
   identifier for the attribute definition;  this includes all elements
   referenced either directly, or indirectly by the Derived From, With
   Attribute Syntax, Matches For and Behaviour constructs, where
   present.  This value is used in the management protocol when it is
   necessary to identify the attribute type.  If this construct is
   omitted, the attribute definition shall not be referenced in a
   managed object class definition without further constraints being
   applied in another attribute definition.

A1.8  Notification Template

A1.8.1 Overview

   This template is used to define the behaviour and syntax associated
   with a particular Notification type.  The main features of the
   definition are as follows:

      - Behaviour.  The definition of a Notification type must specify
        the circumstances under which a notification of the type is
        generated;

      - Mode of operation.  The definition of a notification type shall
        indicate whether the notification may be confirmed,
        unconfirmed or both;

      - Syntax Definitions.  The definition of the Notification type
        must specify any syntax that will be used to convey the CMIS
        Event Information and Event Reply parameters in CMIP.  These
        syntaxes are defined by means of ASN.1 data types.  The
        template also permits the allocation of attribute values to
        fields in the syntax;

      - Notification naming.  The value of the Object Identifier
        associated with the Notification definition is used to identify
        the Event type in CMIP.

A1.8.2  Template Structure

      <notification-label> NOTIFICATION

      BEHAVIOUR       <behaviour-definition-label>
                                      [,<behaviour-definition-label>]*;
      MODE    <confirmation-mode>;
      [PARAMETERS  <parameter-label>[,<parameter-label]*;
      ]
      [WITH INFORMATION SYNTAX <syntax-label>
                      [AND ATTRIBUTE IDS <field-name><attribute-label>
                                      [,<field-name><attribute-label]*];
      ]
      [WITH REPLY SYNTAX <syntax-label>;]

      REGISTERED AS <object-identifier>;

      supporting productions

      confirmation-mode -> CONFIRMED | NON-CONFIRMED | CONFIRMED AND
      NON-CONFIRMED

A1.8.3  Supporting Definitions

   BEHAVIOUR <behaviour-definition-label>

   This defines the behaviour of the notification, the data that must be
   specified with the notification, the results that the notification
   may generate and their meaning.  The behaviour- definition-label
   references a behaviour description defined by use of the Behaviour
   Template.

   Note:  It should not be assumed that the behaviour defined by this
   clause is testable using existing conformance test technology.

   MODE CONFIRMED | NON-CONFIRMED | CONFIRMED AND NON-CONFIRMED

   This defines the allowable mode of operation of the notification
   type, as follows:

        - CONFIRMED:  The notification type shall operate in the
                confirmed mode only;

        - NON-CONFIRMED:  The notification type shall operate in the
                non-confirmed mode only;

        - CONFIRMED AND NON-CONFIRMED:  The notification type may
                operate in either confirmed mode or non-confirmed mode.

   PARAMETERS  <parameter-label>[,<parameter-label>]*

   The parameter-labels allow parameters to be associated with with the
   behaviour of the attribute type.

   WITH INFORMATION SYNTAX <syntax-label> [AND ATTRIBUTE IDS
   <field-name><attribute-label> [,<field-name><attribute-label>]*;]

   This construct identifies the ASN.l data type that describes the
   structure of the notification information that is carried in
   management protocol, and permits the association of attribute
   identifiers with named fields in the abstract syntax.  The syntax-
   label shall be a type reference name, using the Externaltypereference
   notation defined in ISO 8824.  If absent, there is no information
   associated with the notification invocation.  If the AND ATTRIBUTE
   IDS option is used, the field- name label shall be a label defined
   within the abstract syntax referenced by the syntax that appears in
   the construct.  The data type that is labeled by the field-name is
   used to carry values of the attribute referenced by attribute-label.
   The ASN.1 data type of the attribute shall be the same as the data
   type referenced by field-name.

   WITH REPLY SYNTAX <syntax-label>

   If a syntax-label is present, this identifies the ASN.1 data type
   that describes the structure of the notification reply that is
   carried in management protocol.  The syntax-label shall be a type
   reference name, using the Externaltypereference notation defined in
   ISO 8824.  If absent, there is no information associated with the
   notification reply.

Appendix 2:  New Objects: Internet SMI Object Type Macros

   atEntryId OBJECT-TYPE
                 SYNTAX  DisplayString
                 ACCESS  read-only
                 STATUS  mandatory
                DESCRIPTION
       "<index>.1.<address>, where <index is the decimal representation
        of atIfIndex and <address> is atNetAddress represented in
        dot notation.  The 1 is a subidentifier indicating that an IP
        address follows. "
                 ::= { attributes 3}

   atTableId OBJECT-TYPE
                 SYNTAX  DisplayString
                 ACCESS  read-only
                 STATUS  mandatory
                DESCRIPTION
                   "An empty string."
                 ::= { attributes 2}


   egpId OBJECT-TYPE
                 SYNTAX  DisplayString
                 ACCESS  read-only
                 STATUS  mandatory
                DESCRIPTION
                   "An empty string."
                 ::= { attributes 16}

   egpNeighEntryId OBJECT-TYPE
                 SYNTAX  DisplayString
                 ACCESS  read-only
                 STATUS  mandatory
                DESCRIPTION
                        "egpNeighAddr encoded in dot notation."
                 ::= { attributes 22}

   egpNeighTableId OBJECT-TYPE
                 SYNTAX  DisplayString
                 ACCESS  read-only
                 STATUS  mandatory
                DESCRIPTION
                   "An empty string."
                 ::= { attributes 17}

   icmpId OBJECT-TYPE
                 SYNTAX  DisplayString

                 ACCESS  read-only
                 STATUS  mandatory
                DESCRIPTION
                   "An empty string."
                 ::= { attributes 9}

   ifId OBJECT-TYPE
                 SYNTAX  DisplayString
                 ACCESS  read-only
                 STATUS  mandatory
                DESCRIPTION
                   "An empty string."
                 ::= { attributes 23}

   ifEntryId OBJECT-TYPE
                 SYNTAX  DisplayString
                 ACCESS  read-only
                 STATUS  mandatory
                DESCRIPTION
                   "The decimal representation of ifIndex."
                 ::= { attributes  21}

   ifTableId OBJECT-TYPE
                 SYNTAX  DisplayString
                 ACCESS  read-only
                 STATUS  mandatory
                DESCRIPTION
                   "An empty string."
                 ::= { attributes 1}

   ipAdEntryId OBJECT-TYPE
                 SYNTAX  DisplayString
                 ACCESS  read-only
                 STATUS  mandatory
                DESCRIPTION
                   "ipAdEntAddr encoded in dot notation."
                 ::= { attributes 19}

   ipAddrTableId OBJECT-TYPE
                 SYNTAX  DisplayString
                 ACCESS  read-only
                 STATUS  mandatory
                DESCRIPTION
                   "An empty string."
                 ::= { attributes 5}

   ipId OBJECT-TYPE
                 SYNTAX  DisplayString
                 ACCESS  read-only
                 STATUS  mandatory
                DESCRIPTION
                   "An empty string."
                 ::= { attributes 4}

   ipNetToMediaEntryId OBJECT-TYPE
                 SYNTAX  DisplayString
                 ACCESS  read-only
                 STATUS  mandatory
                DESCRIPTION
        "<interface>.<address>, where <interface> is the decimal
        representation of ipNetToMediaIndex and <address> is
        ipNetToMediaNetAddress in dot notation."
                 ::= { attributes 8}

   ipNetToMediaTableId OBJECT-TYPE
                 SYNTAX  DisplayString
                 ACCESS  read-only
                 STATUS  mandatory
                DESCRIPTION
                   "An empty string."
                 ::= { attributes 7}

   ipRouteEntryId OBJECT-TYPE
                 SYNTAX  DisplayString
                 ACCESS  read-only
                 STATUS  mandatory
                DESCRIPTION
           "<dest> , where <dest> is ipRouteDest represented in dot
           notation."
                 ::= { attributes 20}

   ipRoutingTableId OBJECT-TYPE
                 SYNTAX  DisplayString
                 ACCESS  read-only
                 STATUS  mandatory
                DESCRIPTION
                   "An empty string."
                 ::= { attributes 6}

   snmpId OBJECT-TYPE
                 SYNTAX  DisplayString
                 ACCESS  read-only
                 STATUS  mandatory
                DESCRIPTION

                   "An empty string."
                 ::= { attributes 18}

   tcpConnId OBJECT-TYPE
                 SYNTAX  DisplayString
                 ACCESS  read-only
                 STATUS  mandatory
                DESCRIPTION
            "<laddr> . <lport> . <raddr> . <rport>, where
            <laddr> is the dot notation representation of
                   tcpConnLocalAddress,
            <lport> is the decimal representation of tcpConnLocalPort,
            <raddr> is the dot notation representation of
                   tcpConnRemAddress, and
            <rport> is the decimal representation of tcpConnRemPort."
                 ::= { attributes 12}

   tcpConnTableId OBJECT-TYPE
                 SYNTAX  DisplayString
                 ACCESS  read-only
                 STATUS  mandatory
                DESCRIPTION
                   "An empty string."
                 ::= { attributes 11}

   tcpId OBJECT-TYPE
                 SYNTAX  DisplayString
                 ACCESS  read-only
                 STATUS  mandatory
                DESCRIPTION
                   "An empty string."
                 ::= { attributes 10}

   updEntryId OBJECT-TYPE
                 SYNTAX  DisplayString
                 ACCESS  read-only
                 STATUS  mandatory
                DESCRIPTION
           "<index> . <address>, where <index> is the decimal
           representation of atIfIndex and <address> is atNetAddress
           represented in dot notation."
                 ::= { attributes 15}

   udpId OBJECT-TYPE
                 SYNTAX  DisplayString
                 ACCESS  read-only
                 STATUS  mandatory
                DESCRIPTION

                   "An empty string."
                 ::= { attributes 13}

   udpTableId OBJECT-TYPE
                 SYNTAX  DisplayString
                 ACCESS  read-only
                 STATUS  mandatory
                DESCRIPTION
                   "An empty string."
                 ::= { attributes 14}

Appendix 3: Supporting Definitions

   The definition of the object class "top", from which all object
   classes are derived, is taken from ISO/IEC DIS 10165-2: Definition of
   Management Information [5].  However, pending progression of that
   document to an International Standard, the object class "top" and its
   associated attributes have been registered here under the oim
   registration arc.

   top     MANAGED OBJECT CLASS
           CHARACTERIZED BY
               topPackage PACKAGE
           BEHAVIOUR DEFINITIONS topBehaviour;
           ATTRIBUTES
                   objectClass     GET,
                   name            GET,
                   allomorphs      GET,
                   nameBindings    GET,
                   packages        GET;;;
   REGISTERED AS {objects 1};

   topBehaviour    BEHAVIOUR
           DEFINED AS
   This is the top level of managed object class hierarchy and
   every other managed object class is a specialization of either
   this generic class (top) or a specialization of a subclass of top.;

   allomorphs ATTRIBUTE
           WITH ATTRIBUTE SYNTAX
                   Top-Syntax.Allomorphs;
                   -- A set of allormorphic superclass identifiers
           MATCHES FOR  Set Comparison, Set Intersection;
   REGISTERED AS {attributes 30};

   name ATTRIBUTE
           WITH ATTRIBUTE SYNTAX InformationFramework.
                                   RelativeDistinguishedName;
                   -- defined in Directory standards
           MATCHES FOR Equality;
   REGISTERED AS {attributes 31};

   nameBindings ATTRIBUTE
           WITH ATTRIBUTE SYNTAX
                   Top-Syntax.NameBindings;
                   -- A set of valid namebindings for this object.
           MATCHES FOR     Set Comparison, Set Intersection;
   REGISTERED AS {attributes 32};

   objectClass     ATTRIBUTE
           WITH ATTRIBUTE SYNTAX CMIP-1.ObjectClass;
           MATCHES FOR Equality, Ordering;
   REGISTERED AS {attributes 33};

   packages ATTRIBUTE
           WITH ATTRIBUTE SYNTAX
                   Top-Syntax.Packages;
                   -- The set of optional packages defined for the
                   -- class that are included in this instantiation of
                   -- the object.
           MATCHES FOR Set Comparison, Set Intersection;
   REGISTERED AS {attributes 34};


   Top-Syntax {iso(1) org(3) dod(6) internet(1) mgmt(1) mib(1)
                   oim(9) misc(4) 2}
   DEFINITIONS ::=
   BEGIN

   -- from ISO/IEC DIS 10165-2:Definition of Management Information

   Allomorphs ::=  SET OF OBJECT IDENTIFIER

   NameBindings ::=        SET OF OBJECT IDENTIFIER

   Packages ::=    SET OF OBJECT IDENTIFIER

   -- From Directory InformationFramework

   RelativeDistinguishedName ::= SET OF AttributeValueAssertion

   AttributeValueAssertion ::= SEQUENCE {AttributeType,
                                         AttributeValue}

   AttributeType ::= OBJECT IDENTIFIER

   AttributeValue ::= ANY

   -- From CMIP-1

   ObjectClass ::= CHOICE {globalForm      [0] OBJECT IDENTIFIER,
                                      localForm    [1] INTEGER }
   END

Security Considerations

   Security issues are not discussed in this memo.

Author's Address

   Lee LaBarre
   The MITRE Corporation
   Burlington Road
   Bedford, MA 01730

   Phone: (617) 271-8507

   EMail: cel@mbunix.mitre.org