ISO/IEC 10165-1:1993

INTERNATIONAL ISO/IEC
STANDARD 10165-I
First edition
1993-09- 15
Information technology - Open Systems
Interconnection - Structure of
management information: Management
Information Model
- lnterconnexion de systemes ouverts -
Technologies de I’informa tion
Structure des informations de gestion: Mod&/e d’informations de gestion

ISO/IEC 101651:1993 (E)
Contents
Page
1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Normative references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1 Identical Recommendations I International Standards. . . . . . . . . . . . . . . . . 1
2.2 Paired Recommendations I International Standards equivalent in
technical content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Additional references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
........................................................................
3 Definitions
........................................ 2
3.1 Basic reference model definitions
...................................... 3
3.2 Management framework definitions
.............................. 3
3.3 Systems management overview definitions
................. 3
3.4 Common management information service definitions
3.5 Abstract Syntax Notation One definitions .
........... 3
3.6 Guidelines for the definition of managed objects definitions
.......................................... 3
3.7 Security architecture definitions
......................................................
3.8 Additional definitions
4 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Information Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1 Managed object concepts using object-oriented design . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Compatibility and interoperability
.......................................... 13
5.3 Systems management operations
.......................................................................
5.4 Filters
................................................................ 23
5.5 Notifications
......................................... 23
6 Principles of containment and naming
................................................................
6.1 Containment
0 ISO/IEC 1993
All rights reserved. No part of this publication may be reproduced or utilized in any form or by any
means, electronic or mechanical, including photocopying and microfilm, without permission in writing
from the publisher.
l CH-1211 Geneve20 l Switzerland
ISO/IEC Copyright Office l Case postale 56
Printed in Switzerland
ii
ISO/IEC 101651:1993 (E)
6.2 ‘The naming tree . . . . . . . . . . . . . . . . . . . .*. 24
6.3 Name structure
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7 Attributes of top . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

ISO/IEC 10165-l: 1993 (E)
Foreword
IS0 (the International Organization for Standardization) and IEC (the Inter-
national Electrotechnical Commission) form the specialized system for world-
wide standardization. National bodies that are members of IS0 or IEC participate
in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of
technical activity. IS0 and IEC technical committees collaborate in fields of
mutual interest. Other international organizations, governmental and non-
governmental, in liaison with IS0 and IEC, also take part in the work.
In the field of information technology, IS0 and IEC have established a joint
technical comm’ittee, ISO/IEC JTC 1. Draft International. Standards adopted by
the joint technical committee are circulated to national bodies for voting. Publi-
cation as an International Standard requires approval by at least 75% of the
national bodies casting a vote.
International Standard ISO/IEC 10165-l was prepared by Joint Technical Com-
mittee ISO/IEC JTC 1, Information technology, in collaboration with CCITT.
The identical text is published as CCITT Recommendation X.720.
ISO/IEC 10165 consists of the following parts, under the general title Infor-
mation technology - Open Systems Interconnection - Structure of management
information:
-
Part 1: Management information model
-
Part 2: Definition of management information
-
Part 4: Guidelines for the definition of managed objects
-
Part 5: Generic management information
-
conformance
Part 6: Requirements and guidelines for implementation
statement proformas associated with management information

ISO/IEC 1016515993 (E)
Introduction
ISO/IEC 10165 is a multipart standard developed accoiding to IS0 7498 and
ISO/IEC 7498-4. ISO/IEC 10165 is related to the following International Stan-
dards:
- ISO/IEC 9595: 1990, Information technology - Open Systems Interconnection
- Common management information service deBnition;
- ISOJIEC 9596: 1990, Information technology - Open Systems Interconnection
- Common management information protocol;
-
ISO/IEC 10040: 1992, Information technology - Open Systems Interconnec-
tion - Systems management overview;
-
ISO/IEC 10165: 1992, Information technology - Open Systems Interconnec-
tion - Structure of management information.

This page intentionally left blank

ISOAEC 10165-l : 1993 (E)
INTERNATIONAL STANDARD
CCITT RECOMMENDATION
INFORMATION TECHNOLOGY - OPEN SYSTEMS INTERCONNECTION -
STRUCTURE OF MANAGEMENT INFORMATION:
MANAGEMENT INFORMATION MODEL
1 Scope
This Recommendation I International Standard is one of the set of Recommendations I International Standards for the
OS1 Management Information Service (MIS). It defines the Information Model of managed objects and their attributes
that corresponds to the Information aspects of the systems management model introduced in the Systems Management
Overview CCITT Rec. X.701 I ISOLIEC 10040, thus providing the modelling concepts necessary for the development
of the other systems management Recommendations I International Standards. It also defines the principles of naming
managed objects and attributes.
This Recommendation I International Standard defines the logical structure of systems management information. In
accordance with CCITT Rec. X.700 I IS0 7498-4 and X.701 I ISO/IEC 10040 management information is structured in
terms of managed objects, their attributes, the management operations that can be performed upon them, and the
notifications that they can emit. The set of managed objects in an open system, together with their attributes,
constitutes that open system’s management information base (NUB).
This Recommendation I International Standard defines the concepts of managed objects in the Information Model, and
prescribes the principles for naming the managed objects and their attributes so that they may be identified in and
accessed by management protocols. This Recommendation I International Standard also describes the concept of
managed object classes and the relationships into which managed objects and managed object classes can enter,
including: inheritance, specialization, allomorphism and containment.
This Recommendation I International Standard applies to all definitions of managed objects and their attributes for the
purposes of systems management.
NOTE - Although this Recommendation I International Standard applies to sys terns management, layer management,
when defined, can also use this Recommendation I International Standard.
2 Normative references
The following CCITI’ Recommendations and International Standards contain provisions which, through reference in
this text, constitute provisions of this Recommendation I International Standard. At the time of publication, the editions
indicated were valid. All Recommendations and Standards are subject to revision, and parties to agreements based on
this Recommendation I International Standard are encouraged to investigate the possibility of applying the most recent
editions of the Recommendations and Standards listed below. Members of IEC and IS0 maintain registers of currently
valid International Standards. The CCITI’ Secretariat maintains a list of currently valid CCITT Recommendations.
21 l Identical Recommendations I International Standards
- CCITT Recommendation X.701 (1992) I ISO/IEC 10040:1992, InfortPzation technology - Open Systems
Interconnection - Systems management overview.
-
CCITT Recommendation X.722 (1992) I ISO/IEC 101654: 1992, Information technology - Open
Systems Interconnection - Structure of management information:
Guidelines for the definition of
management objects.
-
CCITT Recommendation X.734 (1992) I ISO/IEC 10164-5:1993, Information technology - Open
Systems Interconnection - Systems Management - Event report managementfinction.
CCITT Rec. X.720 (1992 E) 1
Paired Recommendations I International Standards equivalent in technical content
22 .
- CCITT Recommendation X.200 (1988), Reference Model of Open Systems Interconnection for CCITT
Applications.
IS0 7498~1984, Information processing systems - Open Systems Interconnection - Basic Reference
Model.
-
CCI’M’ Recommendation X.208 (1988), Specification of Abstract Syntax Notation One (ASNJ).
ISOAEC 8824: 1990, Information technology - Open Systems Interconnection - Specification of Abstract
Syntax Notation One (ASN.1).
- CCITT Recommendation X.700 (1992), Management Framework Definition for Open Systems
Interconnection (OSI) for CCITT Applications.
ISO/IEC 7498-4: 1989, Information processing systems - Open Systems Interconnection - Basic
Reference Model - Part 4: Management framework.
-
CCITT Recommendation X.710 (l991), Common Management Infomzation Service Definition for
CCIlT Applications.
ISOLEC 9595: 199 1, Information technology - Open Systems Interconnection - Common management
information service definition.
- CCITI’ Recommendation X.71 1 (1991), Common Management Information Protocol Specification for
CCITT applications.
ISOIIEC 9596-l: 1991, Information technology - Open Systems Interconnection - Common management
information protocol - Part 1: Specification.
CCITT Recommendation X.800 (199 l), Security Architecture for CCITT Applications.
-
IS0 7498-2: 1989, Information processing systems - Open Systems Interconnection - Basic Reference
Model - Part 2: Security architecture.
- CCITT Recommendation X.501 (1988), The Directory - Models.
ISO/IEC 9594-2: 1990, Information technology - Open Systems Interconnection - The Directory -
Part 2: Models.
- CCITT Recommendation X.51 1 (1988), The Directory - Abstract Service Definition.
Open Systems Interconnection - T?ze Directory -
ISOIEC 9594-3: 1990, Information technology -
Part 3: Abstract service definition.
23 0 Additional references
-
ISO/lEC 7498-3: 1989, Information processing systems - Open Systems Interconnection - Basic
Reference Model - Part 3: Naming and addressing.
3 Definitions
For the purposes of this Recommendation I International Standard, the following definitions apply.
Basic reference model definitions
31 .
This Recommendation I International Standard makes use of the following terms defined in the OS1 Basic Reference
Model, CCITT Rec. X.200 I IS0 7498.
open system;
b) systems management;
c) (N)-entity;
d) (IV)-layer;
e) (IV)-protocol.
CCITT Rec. X.720 (1992 E)
ISO/IEC 101651: 1993 (E)
32 l Management framework definitions
This Recommendation I International Standard makes use of the following terms defined in CCI’IT Rec. X.700 I
IS0 7498-4.
management information base;
a)
b) managed object.
33 a Systems management overview definitions
This Recommendation I International Standard makes use of the following terms defined in CCITI’ Rec. X.701 I
ISO/IEC 10040.
agent;
a)
b) manager;
notification;
Cl
d) managed object class;
e) (systems management) operation.
0 Common management information service definitions
This Recommendation I International Standard makes use of the following terms defined in CCITT Rec. X.710 I
ISO/lEC 9595.
attribute;
a)
set-valued attribute.
b)
Abstract Syntax Notation One definitions
35 0
This Recommendation I International Standard makes use of the following terms defined in CCITT Rec. X.219 1
ISO/IEC 8824.
type
Guidelines for the definition of managed objects definitions
36 l
This Recommendation I International Standard makes use of the following terms defined in CCITT Rec. X.722 I
ISO/lEC 10165-4.
template
37 . Security architecture definitions
This Recommendation I International Standard uses the following terms defined in CCITT Rec. X.800 I IS0 7498-2.
access control;
a)
b) security policy.
Additional definitions
38 0
3.8.1 action: An operation on a managed object, the semantics of which are defined as part of the managed object
class definition.
3.8.2 actual class: The managed object class of which a managed object is an instance, as distinct from an
allomorphic class of that managed object.
3.8.3 allomorphic class (of a managed object): A class, other than the managed object’s actual class, which a
managed object can be managed as, using allomorphism.
that is an instance of a given class to be managed as an
3.8.4 allomorphism: The ability of a managed object
instance of one or more other managed object classes.
CCITT Rec. X.720 (1992 E) 3
Isomxc 10165-l : 1993 (E)
3.8.5 attribute group: A group of attributes which have been assigned a single identifier for ease of access.
3.8.6 attribute identifier: An identifier used to distinguish an attribute of a managed object class from all other
attributes.
attribute type: A named definition of a specific kind of attribute, including definitions of its syntax (type)
3.8.7
and semantics. An attribute is an instance of an attribute type.
3.8.8 attribute value assertion: A statement, which may be true or false, concerning the value of an attribute.
3.8.9 attribute value set: A set of values, members of which are valid values of an attribute.
3.8.10 behaviour: The way in which managed objects, name bindings, attributes, notifications and actions interact
with the actual resources they model and with each other.
3.8.11 characteristic: An element of a managed object class definition; that is an attribute definition, an attribute
group definition, a notification definition, a behaviour definition, a parameter definition or a package definition.
which is present in a given managed object if the condi tion given in its
3.8.12 conditional package: A package
definition is satisfied.
managed object class
3.8.13 containment: A structuring relationship for managed objects in which the existence of a managed object is
dependent on the existence of a containing managed object.
3.8.14 distinguished name: The name of an object formed from the sequence of the RDNs of the object and each of
its superior objects.
3.8.15 encapsulation: A relation between a managed object and its attributes and behaviour, which represents the
property that attributes and behaviour may be observed only through management operations on the managed object or
notifications emitted by it.
3.8.16 inheritance: The conceptual mechanism by which attributes, notifications, operations and behaviour are
acquired by a subclass from its superclass.
3.8.17 inheritance hierarchy: A hierarchical arrangement of managed object classes where the hierarchy is
organized on the basis of the class specialization.
3.8.18 initial value managed object: A managed object that serves as a source for the derivation of initial values of
another managed object.
3.8.19 instantiation: The process of creating a managed object according to a managed object class definition.
underlying
3.8.20 managed object boundary: The conceptual location where aspects of an resource are made
visible to management and which bounds the scope of the managed object’s definition.
3.8.21 mandatory package: A package which must be present in all instances of a given managed object class.
multiple inheritance: A conceptual mechanism that allows a subclass to acquire attributes, notifications,
3.8.22
operations and behaviour from more than one superclass.
name binding: A relation between object classes which specifies that an object of one identified class may
3.8.23
be the superior of an object of another named class. A name binding definition also includes other information about
the relation, and may be defined to also apply to subclasses of the superior or the subordinate class or both.
3.8.24 naming schema: A collection of name bindings.
3.8.25 naming tree: A hierarchical arrangement of objects where the hierarchy is organized on the basis of the
name binding relationship. An object used to name another managed object is higher in the hierarchy than the named
object. The naming object is referred to as the superior of the named object, which is referred to as the subordinate.
3.8.26 package: A collection of attributes, notifications, operations and/or behaviour which is treated as a single
module in the specification of a managed object class. Packages may be specified as being mandatory or conditional
when referenced in a managed object class definition.
3.8.27 parameter: A value of a type which has associated semantics and is associated
with an object identifier and
other information where the value of the type may be carried in protocol
4 CCITT Rec. X.720 (1992 E)
ISO/IEC 10165-l : 1993 (E)
3.8.28 permitted value set: An attribute value set which includes all of the values which an attribute of a specified
attribute type is permitted to take.
3.8.29 relative distinguished name: An attribute value assertion that a particular attribute has a pa.rt,iahr v&z
used to identify one object out of all those immediately subordinate to a given object. It serves as a component of a
distinguished name of an object.
includes all of the
3.8.30 required value set: An attribute value set which values which an attribute of a specified
attribute type is required to take.
3.8.31 specialization: The technique of deriving a new managed object class from one or more existing managed
object classes by inheritance and by the addition of new characteristics.
3.8.32 subclass: A class derived from another class by specialization.
3.8.33 superclass: A class used in deriving another class by specialization.
3.8.34 superior object: See 3.8.25
3.8.35 subordinate object: See 3.8.25
3.8.36 uninstantiable managed object class: A class that is not intended to be instantiated, either by a systems
management operation or by a local operation within the open system.
NOTE - The terms
attribute;
attribute value assertion;
relative distinguished name;
- distinguished name,
are also used in the Directory, CCI’IT X.500 Series I ISO/IEC 9594, and have been deliberately used here in a similar sense in
order to reflect similarities between the Directory model and the Management information model. However, the use of these terms
in the two models are not identical in their details.
4 Abbreviations
AVA Attribute value assertion
CMIR Common management information protocol
CMIS Common management information service
GDMO Guidelines for the definition of managed objects
Id Identifier
IVMO Initial value managed object
Management information base
MIB
MIS Management information services
RDN Relative distinguished name
SMI Structure of management information
5 Information Model
The purpose of the Information Model is to give structure to the management information conveyed externally by
systems management protocols and to model management aspects of the related resources (e.g. an X.25 protocol
machine). The information model deals with managed objects. Managed objects are abstractions of data processing
and data communications resources (e.g. protocol state machines, connections, and modems) for the purposes of
management. The resources exist independently of their need to be managed. The relationship that exists between the
resource and the managed object as an abstraction of that resource is not modelled in a general way; that is, the precise
properties abstracted and the specific effects of management operations on a resource must be specified as part of the
managed object class specification.
CCITT Rec. X.720 (1992 E) 5
ISO/IEC 101654: 1993 (E)
The distinction between the managed object as visible to management and the resource that it represents for
management purposes may be described by saying that the attributes, operations and notifications are visible to
management at the managed object boundary, whereas the internal functioning of the resource that is represented by
the managed object is not otherwise visible to management. This concept of a managed object boundary has no
implications for implementation, but provides an architectural distinction between the definitions to be developed by
managed object class definers (e.g. layer groups), which are at and inside the boundary, and the definitions and
Recommendations I International Standards of the remainder of systems management, which are at and outside the
boundary.
A managed object class is defined as a collection of packages, each of which is defined to be a collection of attributes,
operations, notifications and related behaviour. Packages are either mandatory or conditional upon some explicitly
stated condition. A managed object is an instance of a managed object class.
In order to document the specification of a managed object class and its associated characteristics, a set of templates is
used. The templates used for systems management are specified in CCITT Rec. X.722 I ISO/IEC 101654.
The definition of a managed object class, as specified by templates, consists of
-
the position of the managed object class in the inheritance hierarchy;
a collection of mandatory packages of attributes, operations, notifications and behaviour;
-
a collection of conditional packages of attributes, operations, notifications and behaviour, together with
the condition under which each package will be present;
within the package structure,
the attributes visible at the managed object boundary;
the operations which can be applied to the managed object;
the behaviour exhibited by the managed object;
the notifications which can be emitted by the managed object.
Other templates specify the possible superior objects for instances of a given managed object class, together with the
attribute used for naming (see clause 6) in these circumstances.
Other aspects of the resources represented by a managed object class are not visible to systems management.
A managed object is instantiated according to a set of rules. These rules specify how the class
specification, as defined
the managed object. The rules are
by means of the template, is to be realized in creating
a) that a managed object shall support all the attributes, management operations, behaviour and
notifications specified in all the mandatory packages and in all the conditional packages whose
condition is satisfied;
b) that a managed object shall support the name binding, as specified by the appropriate template, with
which it is instantiated. Instantiation will fail if an unsupported name binding is requested.
Each managed object is an instance of a class that includes all managed objects that share the same definition. A
distin guished name is used to name each managed object unambiguously.
A managed object exists, from a management point of view, if it has a distinguished name (as defined in 6.3.2) and
supports the operations and notifications defined for its class. Otherwise, it does not exist from a management point of
view, even if a physical counterpart exists.
51 0 Managed object concepts using object-oriented design
In the formulation of systems management Recommendations I International Standards, new managed object classes
and functions will be added as needs are identified. The design of systems management, therefore, requires that an
approach be adopted that will allow the Recommendations I International Standards to be standardized in a modular
fashion and provide for extensibility of the protocol and procedures. The information model makes use of object-
oriented design principles because they provide the above capabilities and provide for reuse of pieces of specification.
In the Information model, object-oriented design is applied to the specification of management information as seen in
protocol exchanges by open systems involved in management activities.
It need not be applied to system
implementation.
6 CCITI’ Rec. X.720 (1992 E)
ISOIIEC 10165-l : 1993 (E)
Object-oriented design is characterized by the definition of objects, where an object is an abstraction of a physical or
logical thing. *
NOTE - The term “object” is used in this document when referring to objects in a wider context than OS1 management.
The term “managed object” is used to refer to objects that represent resources for the purpose of management.
5.1.1 Encapsulation
A facet of object-oriented design is that of encapsulation. Encapsulation ensures that the integrity of an object is
preserved. This requires that all operations to be performed are accomplished by sending a “message” to the object.
That is, the internal operation of a managed object is not visible at the object boundary unless attributes, operations, or
notifications are defined to expose this information. The definition of the managed object class specifies what
operations can be performed and what consistency constraints are required to maintain the integrity of the managed
object.
5.1.2 Managed object classes and their characteristics
Managed objects that share the same definition are instances of the same managed object class. Different instances of a
given class will share the attributes, operations, notifications and behaviour defined in mandatory packages of the
class, and will share those defined in conditional packages to the extent that the instances satisfy the conditions
associated with those packages.
5.1.2.1 Packages
A package is a collection of characteristics, i.e. attributes, notifications, operations and/or behaviour, which is an
integral module of a managed object class definition. Packages are specified as either man&tory or conditional when
referenced in a managed object defmition. A mandatory package must be present in all instances of a given managed
object class. A conditional package is a package that shall be present in a managed object for which the explicit
condition associated with that package in the managed object class definition is TRUE. The same characteristic may
be present in more than one package. The condition under which a package is present is related either to the capability
of the underlying resource being modelled by the managed object or to the presence or absence of management
functions supported by the managed system. In the case of OS1 standard managed objects (e.g. transport layer protocol
machine) these packages will model options that have been specified as part of the relevant specification.
Packages have the following properties:
only one instance of a given package can exist in a managed object;
b) since only one instance of a package can exist in any managed object, no name bindings are assigned to
packages;
once encapsulated in a managed object, the attributes, operations, notifications and behaviour become
d
an integral part of the managed object and are accessible only as a part of that managed object;
a package can never be instantiated without the managed object that encapsulates it;
d)
a package must be instantiated at the same time as the managed object; instantiation of a package at a
e)
later time is not allowed;
packages must be deleted at the same time as the managed object; deletion of a
package at an earlier
time is not allowed;
operations are always performed on managed objects, not on packages.
g)
Since not all managed objects of a managed object class will include all allowed conditional packages defined for that
managed object class, the registered packages supported by a managed object are identified in the Packages attribute
of the managed object (see clause 7).
5.1.2.2 Attributes
,
Managed objects have attributes. An attribute has an associated value, which can exhibit structure, i.e. it can consist of
a set or sequence of elements. An attribute value assertion (AVA) is a statement, which may be true or false,
concerning the value of an attribute.
The value of an attribute may be observable (at the managed object boundary). The value of an attribute can determine
or reflect the behaviour of the managed object. The value of an attribute is observed or modified by sending a request
to a managed object to read (get) or write (replace) the value. Additional operations are defined for set-valued
CCI’IT Rec. X.720 (1992 E) 7
ISOmEC 10165-l : 1993 (E)
attributes; these are attributes whose value is a set of elements, each of the same data-type. Operations on attributes are
defined to be performed upon the managed object that contains the attributes and not directly upon the attributes. The
managed object is able to enforce constraints on attribute values to ensure internal consistency. The definition of a
managed object class can specify constraints between the values of individual attributes. The operations that can be
performed on a particular attribute are specified in the definition of the managed object class.
Attributes are defined to be in packages, mandatory or conditional. Therefore, attributes defined to be part of
mandatory packages are present in all instances of the managed object class, whereas those defined to be part of
conditional packages are present in those instances that satisfy the conditions associated with the package.
Attribute value sets
5.1.2.2.1
The syntax of an attribute is an ASN.l type that describes how instances of the attribute value are carried in protocol.
This syntax is inherent to the attribute and remains constant for all uses of the attribute.
Within a managed object class specification, the properties of an attribute are further defined in terms of the permitted
value set and required value set. The permitted value and required value sets specify value restrictions on the
attribute.
The required value set specifies all values that the attribute is required to be capable of taking. This set may be empty
if no specific values are required.
capable of replacing the value of the attribute by any one of the values specified in the set
A managed object must be
control.
of ’ required values, subject to behavioural or other constraints, such as access
The permitted value set specifies the possible values that the attribute is permitted to take.
A managed object shall not return an attribute value outside the permitted value set in response to an operation
requesting the managed object to read the attribute value. A managed object shall reject a request to modify the value
of an attribute outside its permitted value set.
The permitted value set shall be a subset of the values of the syntax, and the required value set shall be a subset of the
permitted value set, where identity is allowed in both cases.
5.1.2.2.2 Set-valued attributes
A set-valued attribute is an attribute whose value is an unordered set of members of a given type. The size of the set is
variable and the set can be empty. Part of the definition of a set-valued attribute are the permitted and required values
for the cardinality of the set. In addition to the operations that are available for all attribute types, operations are
defined for set-valued attributes that allow the addition and removal of elements to and from set-valued attributes.
5.1.2.3 Attribute groups
An attribute group provides a means of referring to a collection of attributes within a managed object that contains the
collection of attributes. Two types of attribute groups may be defined: fixed and extensible. Whether or not extension
is possible is part of the definition of the attribute group.
A fixed attribute group is an attribute group whose set of attributes is defined as part of the initial attribute group
definition and whose set of attributes may not be changed in any way. For fixed attribute groups, all attributes that care
a part of the attribute group shall be defined in the same package as the attribute group.
An extensible attribute group is an attribute group to which attributes can be added as a result of specialization. For
extensible attribute groups the attributes specified for each extension shall either be defined in the same conditional
package as the attribute group or in a mandatory package.
The individual attributes comprising the group are specified in the definition of the managed object class. An attribute
group has no value of its own. The only operations that are allowed on attribute groups are those which do not require
a value to be specified.
to corresponding operations on
Allowable operations on an attribute group are interpreted as referring each individu‘al
attribute included in the attribute group. The operation is applied to the attributes in no particular order.
A managed object class can have more than one attribute group. An individual attribute can be included in more than
one attribute group.
CCITT Rec. X.720 (1992 E)
ISO/IEC 10165-l : 1993 (E)
5.1.2.4 Behaviour
Part of the definition of a managed object class is behaviour.
The behaviour can define
the semantics of the attributes, operations and notifications;
a)
the response to management operations being invoked on the managed object;
b)
the circumstances under which notifications will be emitted;
C)
dependencies between values of particular attributes, which must be expressed in a way that takes
(-0
account of the possible presence or absence of conditional packages;
the effects of relationships on the participating managed objects;
e)
consistency constraints on attributes;
preconditions that identify the conditions when operations and notifications can be assumed to have
45)
valid meaning;
postconditions that identify the results of the processing of a management operation or the emission of a
h)
notification;
invariants that are in effect for the entire lifetime of the managed object and that describe conditions
i)
that are true for operation of the managed object;
.
synchronization properties of the managed object.
J)
CCITT Rec. X.722 I ISO/IEC 10165-4 defines a set of templates that can be used to define all aspects of managed
object behaviour.
5.1.3 Specialization and inheritance
One managed object class is specialized from another managed object class by defining it as an extension of the other
managed object class. Such an extension is made by defining further packages that include one or more of the
following:
-
new management operations;
-
new attributes;
new notifications;
new behaviour;
extensions to the characteristics of the original managed object class.
The ways in which the capabilities of a given managed object class can be extended are specified, in detail, in 5.2.2.
A managed object class that is specialized from another managed object class is known as a subclass of that class (its
superclass). One managed object class, called top, is designated as the ultimate superclass in the class hierarchy. Top
is an uninstantiable managed object class.
The subclass inherits the operations, attributes, notifications, packages and behaviour of the superclass. This
Recommendation I International Standard allows only for strict inheritance of characteristics, that is, every instance
of a subclass is compatible with its superclass, according to the rules defined in 5.2.2. Specialization by deleting any of
the superclass characteristics is not allowed.
Multiple inheritance is the ability of a subclass to be specialized from more than one superclass. The
subclass inherits
the operations, attributes, notifications, packages and behaviour from more than one superclass.
When a class has multiply inherited the same characteristic from multiple superclasses, then that class is defined as
though that characteristic were inherited from only a single superclass.
Specialization shall not introduce
contradictions in the subclass’s definitions.
An example of the inheritance hierarchy, as it might apply to management, is shown in Figure 1.
CCITT Rec. X.720 (1992 E)
ISOLIEC 10165-l : 1993 (E)
discriminator logRecord
system
Figure 1 - Example of an inheritance hierarchy
52 0 Compatibility and interoperability
5.2.1 Requirements
There is a requirement for interoperability between managing and managed systems. There is also a requirement to
maintain interoperability when either the managed system is enhanced or one or more managed object definitions are
extended.
The following are specific interoperability requirements of systems management for a given managed object:
it must be possible to manage a system from another system of equal knowledge of the managed object
a)
class definition of a given managed object;
b) it must be possible for a system to manage another system of less knowledge of the managed object
class definition of a given managed object;
to the extent feasible, it must be possible for a system to manage a system of greater knowledge of the
C)
managed object class definition of a given managed object. Specifically, it is a requirement that if none
of the extended capabilities are required, management must be possible as effectively as if the managed
system did not have them.
5.2.2 Rules for compatibility
This subclause defines a set of rules that ensure that a managed object that is an instance of one managed object class
(referred to as the extended managed object) is compatible with the definition of a second managed object class
(referred to as the compatible managed object class). These two managed object classes are not necessarily related by
inheritance.
These rules are defined for two purposes:
- for use in the definition of strict inheritance (see 5.1.3);
-
for use in interoperability methods.
5.2.2.1 Additional characteristics
An extended managed object shall include all of the attributes, attribute groups, management operations and
notifications that would be present in an instance of the compatible managed object class instantiated under the same
conditions. Additional attributes, attribute groups, management operations and notifications may be included in an
extended managed object.
10 CCITI’ Rec. X.720 (1992 E)
I~OIIEC 10165-l : 1993 (E)
The mandatory packages instantiated in the extended managed object and those defined in the compatible managed
object class definition need not be related, provided that the above rules are satisfied for all characteristics in those
mandatory packages.
An extended managed object shall include all of the conditional packages defined for the compatible managed object
class, for which the conditions for presence are satisfied for the extended managed object.
5.2.2.2 Package conditions
In all cases where the condition for the presence of a conditional package in the compatible managed object class is
true, the condition for the same conditional package in the extended managed object shall also be satisfied. This rule
allows a conditional package in a compatible managed object class to be mandatory in the extended managed object.
5.2.2.3 Constraints on the values of attributes
There are constraints on the values that can be taken by attributes common to the extended managed object and the
compatible managed object class. The general condition on each such attribute is that the required value set defined in
the compatible managed object class definition is a subset of the value set supported by the extended managed object,
which is in turn a subset of the permitted value set defined for the compatible managed object class (with equality
permitted in both cases). Thus, the extended managed object supports all values guaranteed for the compatible
managed object class, yet supports no values not permitted in that class.
attributes only the conditions on the required value sets are relevant. Conversely, for non-w&able
For non-readable
conditions on the permitted value sets arerele Aant.
attributes only the
NOTE - Compatibility does not ensure that the initial and default values specified in the compatible managed object
class will be used by the extended managed object.
5.2.2.4 Constraints on attribute groups
An extensible attribute group in the extended managed object shall include all attributes that are required to be present
according to the definition of the same attribute group in the compatible managed object class and according to the
conditions for the packages which include those attributes.
5.2.2.5 Constraints on action and notification parameters present
The following conditions shall apply to action and notification parameters.
Action parameters
For a given action common to both the compatible managed object class and the extended managed
object,
all action parameters def?ned in the compatible managed object class shall be supported by the
extended managed object;
- optional parameters shall be supported by the extended managed object that are not defined for the
compatible managed object class only if the definition of the action in the compatible managed
object class definition allows for additional optional parameters;
parameters that are required by the extended managed object in order to perform the action and that
-
are not defined in the compatible managed object class definition, shall be supported only if
defaults are defined in the extended managed object class definition for the case when they are
absent;
- all response parameters defined in the compatible object class definition shall be
supported by the extended managed object;
response parameters that are not defined for the compatible managed object class shall be
-
supported by the extended managed object only if the definition of the response in the compatible
managed object class allows for additional optional parameters.
Notification parameters
b)
For a given notification common to both the extended managed object and the compatible managed
object class,
all notification parameters defined
- in the compatible managed object class shall be supported
bY
the extended managed object;
CCI’IT Rec. X.720 (1992 E) 11
ISO/IEC 10165-l : 1993 (E)
-
parameters that are not defined in the compatible managed object class definition shall be
supported by the extended managed object only if the definition of the notification in the
compatible class definition allows for additional parameters.
5.2.2.6 Extensions to behaviour defmitions
ition for the ex
The rule for extension of behaviour definition is that the behaviour defin .tended managed object class
does not contradict
...