[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Internet-Draft submission
Hi
Please accept our submission of the attached Internet Draft.
This I-D is a "-00" *individual* submission addressed to the SMING WG.
The proposed file name for the I-D is:
draft-triglia-sming-asn1-sming-00.txt
The abstract is:
This memo presents a solution, based on the ASN.1 language, to the need for
a more expressive and complete representation of management information than
is currently possible with SMIv2 and SPPI. The proposal largely meets the
SMIng Workgroup's objectives for Next Generation SMI.
Regards
Alessandro Triglia
INTERNET-DRAFT Olivier Dubuisson
Expires: May 13, 2002 France Telecom R&D
Michel Perin
Atos Origin
Amardeo Sarma
NEC Europe
Bancroft Scott
Alessandro Triglia
OSS Nokalva
November 13, 2001
ASN.1 for SMIng
draft-triglia-sming-asn1-sming-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026 [RFC2026].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This memo presents a solution, based on the ASN.1 language, to the
need for a more expressive and complete representation of management
information than is currently possible with SMIv2 and SPPI. The
proposal largely meets the SMIng Workgroup's objectives for Next
Generation SMI.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Internet Draft ASN.1 for SMIng November 13, 2001
Table of Contents
1. Introduction..................................................2
2. ASN.1.........................................................3
3. The ASN.1 SMIng module........................................4
3.1 MODULE-INFO................................................5
3.2 ENTITY-CLASS...............................................6
3.3 EVENT......................................................9
3.4 ENTITY-INSTANCE...........................................10
3.5 NOTIFICATION..............................................11
3.6 NODE......................................................12
3.7 NODE-GROUP................................................13
3.8 COMPLIANCE-STATEMENT......................................13
4. Compliance with the SMIng Work Group objectives..............15
4.1 Accepted Objectives.......................................15
4.2 Nice-to-Have Objectives...................................27
4.3 Rejected Objectives.......................................28
Intellectual Property...........................................31
Security Considerations.........................................32
Acknowledgements................................................32
References......................................................32
Authors' Addresses..............................................34
A. The ASN.1 SMIng module.......................................35
Full Copyright Statement........................................39
1. Introduction
The document "SMIng Objectives", that has been circulating for
several months as an Internet Draft [SMING-OBJ], "describes the
objectives for a new data definition language, suitable for the
modeling of network management constructs, that can be directly
mapped into SNMP and COPS-PR protocol operations" ([SMING-OBJ],
Abstract). It is assumed that the contents and the purposes of that
document are already well-known and understood by the readers of
this memo, therefore they will not be illustrated here.
The present proposal recognizes all those objectives as valid and
addresses most of them, and by doing so, it provides a more
expressive and complete representation of management information
than is currently possible with SMIv2 and SPPI.
Several proposals have been submitted so far (see [SMING-NMRG],
[SMI-DS]), and the present document acknowledges their value.
However, it is believed that a different solution, based on an
existing formal notation rather than on a completely new language,
may be more viable.
The present proposal is based on the ASN.1 language, and provides an
ASN.1 module that defines a set of constructs which allow to specify
structures of management information.
Expires May 13, 2002 [Page 2]
Internet Draft ASN.1 for SMIng November 13, 2001
A later section of this document lists all the SMIng requirements
from [SMING-OBJ] and contains a statement of compliance for each
item.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. ASN.1
The ASN.1 language has evolved considerably during the last decade,
and is very lively today (see http://asn1.elibel.tm.fr). Among the
most important achievements in the development of the language, that
are relevant to the present document, have been:
- the establishment of a rich set of elementary types, with a
well-defined syntax and semantics;
- the introduction of "information object classes",
"information objects" and "information object sets", that enable the
language to describe complex relationships between types, values and
other elements defined in the specification, such as other
"information objects" and "information object sets";
- the ability to specify a "user-defined syntax" for defining
these information objects;
- the introduction of sophisticated constraints such as "table
constraints" and "component relation constraints" between the
components of a SEQUENCE type, and the "content" constraint on
values of type OCTET STRING and BIT STRING;
- the introduction of the types RELATIVE-OID and UTF8String.
The standard documents where the ASN.1 language is specified
([X.680], [X.681], [X.682], [X.683], [X.690] and [X.691]) are
available on the ITU-T website
(http://www.itu.int/ITU-T/studygroups/com17/languages) and can be
downloaded free of charge.
Two electronic publications that fully cover the ASN.1 language can
also be downloaded free of charge from the Web ([ASN1-DUB] and
[ASN1-LAR]).
Although the primary purpose of ASN.1 is the specification of the
data structures interchanged in protocols, nevertheless the ability
to specify complex structures of meta-information (which is not
meant to be transmitted) in a completely formal way makes it a
strong candidate as a language for specifying structures of
management information.
Expires May 13, 2002 [Page 3]
Internet Draft ASN.1 for SMIng November 13, 2001
3. The ASN.1 SMIng module
This document presents an ASN.1 module (ASN1-SMIng) that defines a
set of basic types and a set of constructs which allow an expressive
and complete representation of structures of management information.
These constructs are specified in terms of "information object
classes" and their associated "user-defined syntax", and are fully
defined by means of the standard ASN.1 grammar. These facilities,
that replaced the "macros" existing in earlier versions of ASN.1,
are suitable to represent structured information in a formal manner.
In the context of the present document, the constructs defined in
the ASN.1 SMIng module will be referred to as "ASN.1 SMIng
statements" or just "statements".
The following basic types are defined in the module:
Integer32
Integer64
Unsigned32
Unsigned64
Float32
Float64
Float128
Counter32
Counter64
TimeTicks
IpAddress
Opaque
SMICharacterString
SMIOctetString
Status
MaxAccess
NamingScheme
EntityInstanceRelationship
MaxOperation
The following statements are defined in the module:
MODULE-INFO
ENTITY-CLASS
EVENT
ENTITY-INSTANCE
NOTIFICATION
NODE
NODE-GROUP
COMPLIANCE-STATEMENT
The statements are presented in the following subsections. See
appendix A for the definitions of the basic types.
Expires May 13, 2002 [Page 4]
Internet Draft ASN.1 for SMIng November 13, 2001
3.1 MODULE-INFO
Allows the specification of information related to the SMIng MIB
module itself, such as ORGANIZATION, CONTACT, REVISIONS (DATE and
DESCRIPTION), STATUS and DESCRIPTION.
A MODULE-INFO statement MUST be included somewhere in the SMIng MIB
module.
The parameters ORGANIZATION, CONTACT and DESCRIPTION have the same
format and meaning of the corresponding parameters in [SMING-NMRG].
The STATUS parameter MUST be a value of type Status:
Status ::= ENUMERATED { current, deprecated, obsolete }
It has the same meaning as the corresponding parameter in [SMING-
NMRG], apart from the different format.
The DATE parameter is of type GeneralizedTime.
The MODULE-INFO statement has the following ASN.1 definition:
MODULE-INFO ::= CLASS {
&organization SMICharacterString,
&contact SMICharacterString,
&Revisions MODULE-REVISION,
&status Status DEFAULT current,
&description SMICharacterString }
WITH SYNTAX {
ORGANIZATION &organization
CONTACT &contact
REVISIONS &Revisions
[STATUS &status]
DESCRIPTION &description }
MODULE-REVISION ::= CLASS {
&date GeneralizedTime,
&description SMICharacterString }
WITH SYNTAX {
DATE &date
DESCRIPTION &description }
Example:
module-info MODULE-INFO ::= {
Expires May 13, 2002 [Page 5]
Internet Draft ASN.1 for SMIng November 13, 2001
ORGANIZATION "Name of the Organization"
CONTACT "Contact person"
REVISIONS {
{ DATE "20010714130000Z"
DESCRIPTION
"Description of the initial version" } |
{ DATE "20010903220000Z"
DESCRIPTION
"Description of the first revision" } }
STATUS current
DESCRIPTION "Description of module and Reference" }
3.2 ENTITY-CLASS
Allows the definition of an "entity class".
An entity class is an ASN.1 type together with essential information
about the type. The entity class will be subsequently referenced by
ENTITY-INSTANCE statements (in the same module or in another module
that imports the entity class), which will declare instances of the
entity class (see subsection 3.4).
The type can be either a simple type (such as an Integer32 or an
OBJECT IDENTIFIER), or an aggregate type (SEQUENCE), or an array
type (SEQUENCE OF).
For simple types, the parameters UNITS and DISPLAY-FORMAT MAY be
specified (both are optional). These parameters have the same format
and meaning as in [SMING-NMRG].
For SEQUENCE types, the parameters ASSIGNED-ATTRIBUTE-IDS and
ATTRIBUTE-INFO apply.
The parameter ASSIGNED-ATTRIBUTE-IDS (optional) specifies an ordered
list of "attribute identifiers" (of the ASN.1 type RELATIVE-OID)
that are assigned to the components of the SEQUENCE, in order. If
this parameter is absent, the attribute identifiers
{1} {2} {3} ...
are assigned by default to the components.
The parameter ATTRIBUTE-INFO specifies the properties of the
attributes of the entity class (components of the SEQUENCE that have
been assigned attribute identifiers). These properties are MAX-
ACCESS, STATUS and DESCRIPTION.
The MAX-ACCESS parameter MUST be a value of type MaxAccess:
MaxAccess ::= ENUMERATED { none,
Expires May 13, 2002 [Page 6]
Internet Draft ASN.1 for SMIng November 13, 2001
notificationsOnly, readOnly, readWrite }
The STATUS parameter MUST be a value of type Status:
Status ::= ENUMERATED { current, deprecated, obsolete }
These parameters have the same meaning as the corresponding
parameters in [SMING-NMRG], apart from the different format.
For SEQUENCE OF types, the parameters INDEXING-ATTRIBUTES and
NAMING-SCHEME apply.
INDEXING-ATTRIBUTES (optional) is a list of the attribute
identifiers (RELATIVE-OID) that make up the index of the array type.
Any instances of this entity class that are subsequently declared
will be indexed by these attributes. If this parameter is absent,
the array type is not indexed (this is useful for defining tables
that have an AUGMENTS or EXTENDS relationship with another table:
see 3.4).
NAMING-SCHEME (optional) indicates which mechanism is to be used to
form the complete OBJECT IDENTIFIERS that identify the data items of
a table (entity instance) of this array type. This parameter MUST be
a value of type NamingScheme:
NamingScheme ::= ENUMERATED { tabular, hierarchical,
extensible }
"tabular" means that the attribute identifiers (which identify a
column of a table) are appended to the OBJECT IDENTIFIER that
identifies the entity instance (the whole table) first, and the OID
components that identify the row (which are extracted from the
indexing attributes) are appended after. This models the traditional
object naming scheme of SMI.
"hierarchical" means that the OID components that identify the row
(which are extracted from the indexing attributes) are appended to
the OBJECT IDENTIFIER that identifies the entity instance (the whole
table) first, and the attribute identifiers (which identify the
column) are appended after. If an arbitrarily-complex data structure
is defined (with arrays nested within elements of other arrays, and
so on), this scheme can be used to assign cleanly hierarchical
OBJECT IDENTIFIERs to all the data items contained in an entity
instance.
"extensible" is similar to "hierarchical", except that an extra
component is inserted in the OBJECT IDENTIFIER after the components
that identify the row, and before the attribute identifiers. This
component is called the "extension identifier" and is provided by
the EXTENSION parameter (see below).
If the NAMING-SCHEME parameter is absent, "tabular" is assumed by
default.
Expires May 13, 2002 [Page 7]
Internet Draft ASN.1 for SMIng November 13, 2001
The EXTENSION parameter (optional) specifies the value of the
"extension identifier" if the NAMING-SCHEME is "extensible". If it
is absent, the value 0 is assumed by default.
The ENTITY-CLASS statement has the following ASN.1 definition:
ENTITY-CLASS ::= CLASS {
&Syntax,
&units SMICharacterString OPTIONAL,
&displayFormat SMICharacterString OPTIONAL,
&assignedAttributeIDs SEQUENCE OF RELATIVE-OID
OPTIONAL,
&AttributeInfo ATTRIBUTE-INFO OPTIONAL,
&indexingAttributeIDs SEQUENCE OF RELATIVE-OID
OPTIONAL,
&namingScheme NamingScheme DEFAULT tabular,
&extensionID RELATIVE-OID DEFAULT {0},
&status Status DEFAULT current,
&description SMICharacterString }
WITH SYNTAX {
SYNTAX &Syntax
[UNITS &units]
[DISPLAY-FORMAT &displayFormat]
[ASSIGNED-ATTRIBUTE-IDS &assignedAttributeIDs]
[ATTRIBUTE-INFO &AttributeInfo]
[INDEXING-ATTRIBUTES &indexingAttributeIDs]
[NAMING-SCHEME &namingScheme]
[EXTENSION &extensionID]
[STATUS &status]
DESCRIPTION &description }
ATTRIBUTE-INFO ::= CLASS {
&attributeID RELATIVE-OID,
&maxAccess MaxAccess DEFAULT none,
&status Status DEFAULT current,
&description SMICharacterString }
WITH SYNTAX {
ATTRIBUTE &attributeID
[MAX-ACCESS &maxAccess]
[STATUS &status]
DESCRIPTION &description }
Examples:
ec-simple ENTITY-CLASS ::= {
SYNTAX Integer32
Expires May 13, 2002 [Page 8]
Internet Draft ASN.1 for SMIng November 13, 2001
UNITS "M"
DISPLAY-FORMAT "d"
STATUS current
DESCRIPTION "description" }
ec-table-row ENTITY-CLASS ::= {
SYNTAX SEQUENCE {
aaa Integer32,
bbbbb SMICharacterString (SIZE(8)),
cc BOOLEAN DEFAULT FALSE,
dddddddd BIT STRING {aa(0), bb(1)} (SIZE(2))
DEFAULT ''B }
ASSIGNED-ATTRIBUTE-IDS {{1}, {2}, {3}, {4}}
--This is the default value
ATTRIBUTE-INFO {
{ ATTRIBUTE {1}
MAX-ACCESS readOnly
STATUS current
DESCRIPTION "description" } |
{ ATTRIBUTE {2}
MAX-ACCESS readOnly
STATUS current
DESCRIPTION "description" } |
{ ATTRIBUTE {3}
MAX-ACCESS readOnly
STATUS current
DESCRIPTION "description" } |
{ ATTRIBUTE {4}
MAX-ACCESS readOnly
STATUS current
DESCRIPTION "description" } }
STATUS current
DESCRIPTION "description" }
ec-table ENTITY-CLASS ::= {
SYNTAX SEQUENCE (SIZE(100)) OF ec-table-row.&Syntax
INDEXING-ATTRIBUTES {{1}}
NAMING-SCHEME tabular
STATUS current
DESCRIPTION "description" }
3.3 EVENT
Expires May 13, 2002 [Page 9]
Internet Draft ASN.1 for SMIng November 13, 2001
Allows the definition of an event.
The EVENT statement has the following ASN.1 definition:
EVENT ::= CLASS {
&status Status DEFAULT current,
&description SMICharacterString }
WITH SYNTAX {
[STATUS &status]
DESCRIPTION &description }
Example:
event1 EVENT ::= {
STATUS current
DESCRIPTION "Description of event" }
3.4 ENTITY-INSTANCE
Allows the declaration of an instance of an entity class. The entity
instance can be either of a simple type, or of an aggregate type or
a table, depending on the entity class.
Multiple entity instances can be declared of the same entity class.
Each entity instance is assigned an OBJECT IDENTIFIER.
If the entity class of an entity instance is based on a SEQUENCE OF
type (i.e., a table), it can be specified by means of the MAX-
OPERATION parameter if is acceptable to dynamically create/delete
rows from the table.
If the entity class of an entity instance is an indexed array type,
the table is indexed. The particular mechanism for assigning names
(OBJECT IDENTIFIERs) to the data items of the table is specified in
the ENTITY-CLASS statement (see 3.2).
If the entity class of an entity instance is an array type without
an INDEXING-ATTRIBUTES parameter, the table is not indexed. Such a
table must be linked to another table by means of the BASE-ENTITY-
INSTANCE and RELATIONSHIP parameters.
The ENTITY-INSTANCE statement has the following ASN.1 definition:
ENTITY-INSTANCE ::= CLASS {
&entityInstanceOid OBJECT IDENTIFIER,
&entityClass ENTITY-CLASS,
Expires May 13, 2002 [Page 10]
Internet Draft ASN.1 for SMIng November 13, 2001
&baseEntityInstanceOid OBJECT IDENTIFIER OPTIONAL,
&relationship EntityInstanceRelationship
DEFAULT none,
&maxOperation MaxOperation DEFAULT none,
&status Status DEFAULT current,
&description SMICharacterString }
WITH SYNTAX {
OID &entityInstanceOid
ENTITY-CLASS &entityClass
[BASE-ENTITY-INSTANCE &baseEntityInstanceOid]
[RELATIONSHIP &relationship]
[MAX-OPERATION &maxOperation]
[STATUS &status]
DESCRIPTION &description }
Examples:
ei1 ENTITY-INSTANCE ::= {
OID {some-oid-base instances(4) 171}
ENTITY-CLASS ec-simple
STATUS current
DESCRIPTION "description" }
ei2 ENTITY-INSTANCE ::= {
OID {some-oid-base instances(4) 518}
ENTITY-CLASS ec-table
MAX-OPERATION createDelete
STATUS current
DESCRIPTION "description" }
ei3 ENTITY-INSTANCE ::= {
OID {some-oid-base instances(4) 1613}
ENTITY-CLASS ec-table-augmenting
BASE-ENTITY-INSTANCE ei2
RELATIONSHIP augments
MAX-OPERATION createDelete
STATUS current
DESCRIPTION "description" }
3.5 NOTIFICATION
Allows the definition of a notification. Each notification is
assigned an OBJECT IDENTIFIER.
The NOTIFICATION statement has the following ASN.1 definition:
Expires May 13, 2002 [Page 11]
Internet Draft ASN.1 for SMIng November 13, 2001
NOTIFICATION ::= CLASS {
¬ificationOid OBJECT IDENTIFIER,
&event EVENT,
&entityClass ENTITY-CLASS,
&transmittedAttributeIDs SEQUENCE OF RELATIVE-OID
OPTIONAL,
&status Status DEFAULT current,
&description SMICharacterString }
WITH SYNTAX {
OID ¬ificationOid
EVENT &event
ENTITY-CLASS &entityClass
[TRANSMITTED-ATTRIBUTES &transmittedAttributeIDs]
[STATUS &status]
DESCRIPTION &description }
Example:
no1 NOTIFICATION ::= {
OID {some-oid-base notifications(5) 4}
EVENT event1
ENTITY-CLASS ec-table
TRANSMITTED-ATTRIBUTES {{1}, {3}}
STATUS current
DESCRIPTION "Description of notification" }
3.6 NODE
Allows the definition of a node in the OBJECT IDENTIFIER tree. Each
node is assigned an OBJECT IDENTIFIER.
The NODE statement has the following ASN.1 definition:
NODE ::= CLASS {
&oid OBJECT IDENTIFIER,
&status Status DEFAULT current,
&description SMICharacterString }
WITH SYNTAX {
OID &oid
[STATUS &status]
DESCRIPTION &description }
Example:
Expires May 13, 2002 [Page 12]
Internet Draft ASN.1 for SMIng November 13, 2001
nd1 NODE ::= {
OID {some-oid-base nodes(8) 145}
STATUS current
DESCRIPTION "Description of node" }
3.7 NODE-GROUP
Allows the definition of a group of nodes. Each group is assigned an
OBJECT IDENTIFIER.
The NODE-GROUP statement has the following ASN.1 definition:
NODE-GROUP ::= CLASS {
&nodeGroupOid OBJECT IDENTIFIER,
&memberOids SEQUENCE OF OBJECT IDENTIFIER,
&status Status DEFAULT current,
&description SMICharacterString }
WITH SYNTAX {
OID &nodeGroupOid
MEMBERS &memberOids
[STATUS &status]
DESCRIPTION &description }
Example:
ng1 NODE-GROUP ::= {
OID {some-oid-base nodegroups(11) 18}
MEMBERS {
{some-oid-base nodes(8) 145},
nd-abcde.&oid,
{some-oid-base nodes(8) 77} }
STATUS current
DESCRIPTION "Description of node group" }
3.8 COMPLIANCE-STATEMENT
Expresses a compliance statement.
An OBJECT IDENTIFIER is assigned to the compliance statement.
The meaning of the parameters MANDATORY-NODE-GROUPS, OPTIONAL-NODE-
GROUPS and REFINED-ATTRIBUTES is the same as in [SMING-NMRG] and
[SMING-SNMP].
Expires May 13, 2002 [Page 13]
Internet Draft ASN.1 for SMIng November 13, 2001
The COMPLIANCE-STATEMENT statement has the following ASN.1
definition:
COMPLIANCE-STATEMENT ::= CLASS {
&statementOid OBJECT IDENTIFIER,
&mandatoryNodeGroupOids SEQUENCE OF OBJECT IDENTIFIER
OPTIONAL,
&OptionalNodeGroupsInfo OPTIONAL-NODE-GROUP-INFO
OPTIONAL,
&RefinedAttributesInfo REFINED-ATTRIBUTE-INFO OPTIONAL,
&status Status DEFAULT current,
&description SMICharacterString }
WITH SYNTAX {
OID &statementOid
[MANDATORY-NODE-GROUPS &mandatoryNodeGroupOids]
[OPTIONAL-NODE-GROUPS &OptionalNodeGroupsInfo]
[REFINED-ATTRIBUTES &RefinedAttributesInfo]
[STATUS &status]
DESCRIPTION &description }
OPTIONAL-NODE-GROUP-INFO ::= CLASS {
&nodeGroupOid OBJECT IDENTIFIER,
&description SMICharacterString }
WITH SYNTAX {
NODE-GROUP &nodeGroupOid
DESCRIPTION &description }
REFINED-ATTRIBUTE-INFO ::= CLASS {
&entityClass ENTITY-CLASS,
&attributeID RELATIVE-OID,
&description SMICharacterString }
WITH SYNTAX {
ENTITY-CLASS &entityClass
ATTRIBUTE &attributeID
DESCRIPTION &description }
Example:
cs1 COMPLIANCE-STATEMENT ::= {
OID {some-oid-base compliance-statements(14) 1}
MANDATORY-NODE-GROUPS {
{some-oid-base nodegroups(11) 18},
ng-qwerty.&nodeGroupOid,
{some-oid-base nodegroups(11) 22} }
Expires May 13, 2002 [Page 14]
Internet Draft ASN.1 for SMIng November 13, 2001
OPTIONAL-NODE-GROUPS {
{NODE-GROUP {some-oid-base ndgroups(11) 22}
DESCRIPTION "description"} |
{NODE-GROUP ng-poiuy.&nodeGroupOid
DESCRIPTION "description"} |
{NODE-GROUP {some-oid-base nodegroups(11) 41}
DESCRIPTION "description"} }
REFINED-ATTRIBUTES {
{ENTITY-CLASS ec1 ATTRIBUTE {4}
DESCRIPTION "description"} |
{ENTITY-CLASS ec1 ATTRIBUTE {21}
DESCRIPTION "description"}}
STATUS current
DESCRIPTION "description" }
4. Compliance with the SMIng Work Group objectives
This section lists all the objectives specified in [SMING-OBJ]. For
each objective, one of the following statements is made:
- MET: the objective is deemed fully met by the present
proposal
- PARTIALLY MET: the objective is deemed partially met by the
present proposal
- NOT ADDRESSED: the objective, listed in [SMING-OBJ] as a
"nice-to-have" or "rejected" objective, has not been taken into
account in the development of the present proposal
Wherever necessary, an explanation and/or an example is given.
The numbering and naming of subsections is the same as in [SMING-
OBJ].
4.1 Accepted Objectives
4.1.1 The Set of Specification Documents
Description: SMIv2 is defined in three documents, based on an
obsolete ITU ASN.1 specification. SPPI is defined in one
document, based on SMIv2. The core of SMIng must be defined in
one document and must be independent of external specifications.
PARTIALLY MET
The minimum set of documents that are needed in order to write an
ASN.1 SMIng specification are the following:
Expires May 13, 2002 [Page 15]
Internet Draft ASN.1 for SMIng November 13, 2001
1) ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998,
"Information technology Abstract Syntax Notation One (ASN.1):
Specification of basic notation" [X.680];
2) ITU-T Recommendation X.681 (1997) | ISO/IEC 8824 2:1998,
"Information technology Abstract Syntax Notation One (ASN.1):
Information object specification" [X.681];
3) The present document.
The ITU-T Recommendations that specify the ASN.1 language are
downloadable free-of-charge from the ITU-T website
(http://www.itu.int/ITU-T/studygroups/com17/languages).
Most of the information actually needed in order to write an ASN.1
SMIng specification is contained in the present document.
4.1.2 Textual Representation
Description: SMIng definitions must be represented in a textual
format.
MET
ASN.1 is a textual language.
4.1.3 Human Readability
Description: The syntax must make it easy for humans to directly
read and write SMIng modules.
MET
The ASN.1 language is very oriented towards human readability. This
is especially true when user-defined syntax is specified for an
information object class.
4.1.4 Rigorously Defined Syntax
Description: There must be a rigorously defined syntax for the
SMIng language.
MET
The ASN.1 language itself is rigorously defined.
Expires May 13, 2002 [Page 16]
Internet Draft ASN.1 for SMIng November 13, 2001
Moreover, the 1994 version of ASN.1 introduced "information object
classes", "information objects" and "information object sets", that
allow, among other things, to define new specific, application-
oriented constructs having a rigorously-defined syntax and a clear
associated semantics, and from which an ABNF can easily be derived.
The present proposal makes extensive use of this capability and
specifies a whole set of these constructs.
4.1.5 Accessibility
Description: Attribute definitions must indicate whether
attributes can be read, written, created, deleted, and whether they
are accessible for notifications, or are not accessible. Align PIB-
ACCESS and MAX-ACCESS, and PIB-MIN-ACCESS and MIN-ACCESS.
MET
(Example to be included)
4.1.6 Language Extensibility
Description: The language must have characteristics, so that
future modules can contain information of future syntax without
breaking original SMIng parsers.
MET
Language extensibility is achieved by using the ASN.1 language to
define all the constructs that make up the "ASN.1 SMIng" itself.
These constructs are specified in ASN.1 as "information object
classes", each with its associated "defined syntax" and semantics.
ASN.1 SMIng parsers will never be affected by any changes in the
defined syntax, because they will know how to parse any (present or
future) specification by first parsing the definitions imported from
the ASN.1 SMIng module (that is referenced in the specification).
This is a property of ASN.1.
4.1.7 Special Characters in Text
Description: Allow an escaping mechanism to encode special
characters, e.g. double quotes and new-line characters, in text
such as DESCRIPTIONs or REFERENCEs.
MET
This feature is present in ASN.1.
Expires May 13, 2002 [Page 17]
Internet Draft ASN.1 for SMIng November 13, 2001
4.1.8 Naming
Description: SMIng must provide mechanisms to uniquely identify
attributes, groups of attributes, and events. It is necessary to
specify how name collisions are handled.
MET
(Example to be included)
4.1.9 Namespace Control
Description: There must be a hierarchical, centrally-controlled
namespace for standard named items, and a distributed namespace
must be supported to allow vendor-specific naming and to assure
unique module names across vendors and organizations.
MET
The model of SMI/SNMP for naming objects is retained in the present
proposal.
4.1.10 Modules
Description: SMIng must provide a mechanism for uniquely
identifying a module, and specifying the status, contact person,
revision information, and the purpose of a module. SMIng must
provide mechanisms to group definitions into modules and it must
provide rules for referencing definitions from other modules
MET
Handling of module information in the present proposal is aligned
with the [SMING-NMRG] proposal.
(Example to be included)
4.1.11 Module Conformance
Description: SMIng must provide mechanisms to detail the minimum
requirements implementers must meet to claim conformance to a
standard based on the module.
Expires May 13, 2002 [Page 18]
Internet Draft ASN.1 for SMIng November 13, 2001
MET
Handling of conformance statements in the present proposal is
aligned with the [SMING-NMRG] proposal.
(Example to be included)
4.1.12 Arbitrary Unambiguous Identities
Description: SMI allows the use of OBJECT-IDENTITIES to define
unambiguous identities without the need of a central registry. SMI
uses OIDs to represent values that represent references to such
identities. SMIng needs a similar mechanism (a statement to
register identities, and a base type to represent values).
MET
Handling of nodes, groups and OIDs in the present proposal is
aligned with the [SMING-NMRG] proposal.
(Example to be included)
4.1.13 Protocol Independence
Description: SMIng must define data definitions in support of the
SNMP and COPS-PR protocols. SMIng may define data definitions in
support of other protocols.
(Yet to be addressed)
4.1.14 Protocol Mapping
Description: The SMIng working group, in accordance with the
working group charter, will define mappings of protocol independent
data definitions to protocols based upon installed
implementations.The SMIng working group can define mappings to other
protocols as long as this does not impede the progress on other
objectives.
(Yet to be addressed)
Mapping to SNMP is built into the present proposal.
(Mappings to other protocols to be addressed)
4.1.15 Translation to Other Data Definition Languages
Expires May 13, 2002 [Page 19]
Internet Draft ASN.1 for SMIng November 13, 2001
Description: SMIng language constructs must, wherever possible,
be translatable to SMIv2 and SPPI. At the time of standardization
of a SMIng language, existing SMIv2 MIBs and SPPI PIBs on the
standards track will not be required to be translated to the SMIng
language. New MIBs/PIBs will be defined using the SMIng language.
MET
The present proposal contains constructs that have correspondent
constructs in the [SMING-NMRG] proposal.
However the present proposal allows different object naming schemes
and allows the definition of more-complex data structures than can
be mapped to SMI and SPPI straightforwardly.
(Example to be included)
4.1.16 Base Data Types
Description: SMIng must support the base data types Integer32,
Unsigned32, Integer64, Unsigned64, Enumeration, Bits, OctetString,
and OID.
MET
The types ENUMERATED, BIT STRING, OCTET STRING and OBJECT IDENTIFIER
are built-in ASN.1 types. The types Integer32, Unsigned32,
Integer64, Unsigned64, SMIOctetString, and SMICharacterString are
defined in the ASN.1 SMIng module by derivation from built-in types
with the use of subtype constraints.
4.1.17 Enumerations
Description: SMIng must provide support for enumerations.
Enumerated values must be a part of the enumeration definition.
MET
The ENUMERATED type is built into ASN.1 and has an inherent
constraint on the values.
4.1.18 Discriminated Unions
Description: SMIng must support discriminated unions.
MET
Expires May 13, 2002 [Page 20]
Internet Draft ASN.1 for SMIng November 13, 2001
Discriminated unions can be specified in ASN.1 by using "component
relation" constraints within SEQUENCEs.
(Example to be included)
4.1.19 Instance Pointers
Description: SMIng must allow specifying pointers to instances
(i.e., a pointer to a particular attribute in a row).
MET
Pointers to instances can be specified as components of type OBJECT
IDENTIFIER referencing an instance.
4.1.20 Row Pointers
Description: SMIng must allow specifying pointers to rows.
MET
Pointers to rows can be specified as components of type OBJECT
IDENTIFIER referencing a row.
4.1.21 Constraints on Pointers
Description: SMIng must allow specifying the types of objects to
which a pointer may point.
(Yet to be addressed)
4.1.22 Base Type Set
Description: SMIng must support a fixed set of base types of
fixed size and precision. The list of base types must not be
extensible unless the SMI itself changes.
MET
4.1.23 Extended Data Types
Expires May 13, 2002 [Page 21]
Internet Draft ASN.1 for SMIng November 13, 2001
Description: SMIng must support a mechanism to derive new types,
which provide additional semantics (e.g., Counters, Gauges, Strings,
etc.), from base types. It may be desirable to also allow the
derivation of new types from derived types. New types must be as
restrictive or more restrictive than the types that they are
specializing.
MET
The ASN.1 language has a sophisticated capability to derive new
types from other types. Additional information on the new derived
types is provided by the constructs defined in the ASN.1 SMIng
module.
(Example to be included)
4.1.24 Units, Formats, and Default Values of Defined Types and
Attributes
Description: In SMIv2 OBJECT-TYPE definitions may contain UNITS
and DEFVAL clauses and TEXTUAL-CONVENTIONs may contain DISPLAY-
HINTs. In a similar fashion units and default values must be
applicable to defined types and format information must be
applicable to attributes.
MET
(Example to be included)
4.1.25 Table Existence Relationships
Description: SMIng must support INDEX, AUGMENTS, and EXTENDS in
the SNMP/COPS-PR protocol mappings.
MET
(Example to be included)
4.1.26 Table Existence Relationships (2)
Description: SMIng must support EXPANDS and REORDERS
relationships in the SNMP/COPS-PR protocol mappings.
MET
(Example to be included)
Expires May 13, 2002 [Page 22]
Internet Draft ASN.1 for SMIng November 13, 2001
4.1.27 Attribute Groups
Description: An attribute group is a named, reusable set of
attributes that are meaningful together. It can be reused as the
type of attributes in other attribute groups (see also Section
4.1.28). This is similar to `structs' in C.
MET
In the present proposal, attribute groups can be specified as
"entity classes" based on ASN.1 SEQUENCEs.
(Example to be included)
4.1.28 Containment
Description: SMIng must provide support for the creation of new
attribute groups from attributes of more basic types and potentially
other attribute groups.
MET
In the present proposal, this is achieved by re-using an "entity
class" based on a SEQUENCE, either as a component of an outer
"entity class" (also based on a SEQUENCE), or as the source in a
"COMPONENTS OF" construct.
(Example to be included)
4.1.29 Single Inheritance
Description: SMIng must provide support for mechanisms to extend
attribute groups through single inheritance.
MET
(Example to be included)
In the present proposal, this is achieved by re-using an "entity
class" based on a SEQUENCE, either as a component of an outer
"entity class" (also based on a SEQUENCE), or as the source in a
"COMPONENTS OF" construct.
4.1.30 Reusable vs. Final Attribute Groups
Expires May 13, 2002 [Page 23]
Internet Draft ASN.1 for SMIng November 13, 2001
Description: SMIng must differentiate between "final" and
reusable attribute groups, where the reuse of attribute groups
covers inheritance and containment.
(Yet to be addressed)
4.1.31 Events
Description: SMIng must provide mechanisms to define events which
identify significant state changes.
MET
Handling of events in the present proposal is aligned with the
[SMING-NMRG] proposal.
(Example to be included)
4.1.32 Creation/Deletion
Description: SMIng must support a mechanism to define
creation/deletion operations for instances. Specific
creation/deletion errors, such as INSTALL-ERRORS, must be supported.
MET
Handling of instance creation/deletion in the present proposal is
aligned with the [SMING-NMRG], [SMING-SNMP] proposal.
4.1.33 Range and Size Constraints
Description: SMIng must allow specifying range and size
constraints where applicable.
MET
Range and size constraints are built into ASN.1.
4.1.34 Uniqueness
Description: SMIng must allow the specification of uniqueness
constraints on attributes. SMIng must allow the specification of
multiple independent uniqueness constraints.
(Yet to be addressed)
Expires May 13, 2002 [Page 24]
Internet Draft ASN.1 for SMIng November 13, 2001
4.1.35 Extension Rules
Description: SMIng must provide clear rules how one can extend
SMIng modules without causing interoperability problems "over the
wire".
(Yet to be addressed)
4.1.36 Deprecate Use of IMPLIED Keyword
Description: The SMIng SNMP mapping must deprecate the use of the
IMPLIED indexing schema.
MET
This facility is not provided.
4.1.37 No Redundancy
Description: The SMIng language must avoid redundancy.
MET
The present proposal does not require the user to specify redundant
information.
4.1.38 Compliance and Conformance
Description: SMIng must provide a mechanism for compliance and
conformance specifications for protocol-independent definitions as
well as for protocol mappings.
MET
Compliance and conformance handling in the present proposal is
aligned with the [SMING-NMRG], [SMING-SNMP] proposal.
(Example to be included)
4.1.39 Allow Refinement of All Definitions in Conformance Statements
Description: (...)
(Yet to be addressed)
4.1.40 Categories
Expires May 13, 2002 [Page 25]
Internet Draft ASN.1 for SMIng November 13, 2001
Description: SMIng must provide a mechanism to group definitions
into subject categories. Concrete instances may only exist in the
scope of a given subject category or context.
(Yet to be addressed)
4.1.41 Core Language Keywords vs. Defined Identifiers
Description: In SMI and SPPI modules some language keywords
(macros and a number of basetypes) have to be imported from
different SMI language defining modules, e.g. OBJECT-TYPE, MODULE-
IDENTITY, Integer32 must to be imported from SNMPv2-SMI and TEXTUAL-
CONVENTION must be imported from SNMPv2-TC, if used. MIB authors
are continuously confused about these import rules. In SMIng only
defined identifiers must be imported. All SMIng language keywords
must be implicitly known and there must not be a need to import them
from any module.
PARTIALLY MET
There is only one module (the ASN.1 SMIng module) from which all the
SMIng definitions are to be imported.
4.1.42 Instance Naming
Description: Instance naming in SMIv2 and SPPI is different.
SMIng must align the instance naming (either in the protocol neutral
model or the protocol mappings).
(Yet to be addressed)
4.1.43 Length of Identifiers
Description: The allowed length of the various kinds of
identifiers must be extended from the current `should not exceed 32'
(maybe even from the `must not exceed 64') rule.
MET
ASN.1 imposes no limit on the length of identifiers.
4.1.44 Assign OIDs in the Protocol Mappings
Description: SMIng must not assign OIDs to reusable definition of
attributes, attribute groups, events, etc. Instead, SNMP and COPS-
PR mappings must assign OIDs to the mapped items.
MET
Expires May 13, 2002 [Page 26]
Internet Draft ASN.1 for SMIng November 13, 2001
In the present proposal, OBJECT IDENTIFIERs are assigned to "entity
instances", not to "entity classes".
4.2 Nice-to-Have Objectives
4.2.1 Methods
Description: SMIng should support a mechanism to define method
signatures (parameters, return values, exception) that are
implemented on agents.
NOT ADDRESSED
4.2.2 Unions
Description: SMIng should support a standard format for unions.
MET
Unions are built into ASN.1 as the CHOICE type.
4.2.3 Float Data Types
Description: SMIng should support the base data types Float32,
Float64, Float128.
MET
4.2.4 Comments
Description: The syntax of comments should be well defined,
unambiguous and intuitive to most people, e.g., the C++/Java `//'
syntax.
MET
C-style comments (/* */) are available in the current version of
ASN.1 besides traditional double-hyphen comments.
4.2.5 Referencing Tagged Rows
Description: PIB and MIB row attributes reference a group of
entries in another table. SPPI formalizes this by introducing PIB-
Expires May 13, 2002 [Page 27]
Internet Draft ASN.1 for SMIng November 13, 2001
TAG and PIB-REFERENCES clauses. This functionality should be
retained in SMIng.
NOT ADDRESSED
4.2.6 Arrays
Description: SMIng should allow the definition of a SEQUENCE OF
attributes or attribute groups (Section 4.1.27).
MET
Arrays can be specified as SEQUENCE OFs at any level of nesting, in
the definition of any arbitrarily-complex data structure. Names (in
the form of OBJECT IDENTIFIERs) can be assigned to all the attribute
instances.
Three naming schemes are provided, allowing both flexibility and
compatibility with existing practice or applications.
(Example to be included)
4.2.7 Internationalization
Description: Informational text (DESCRIPTION, REFERENCE, ...)
should allow internationalized encoding, probably UTF-8.
MET
The UTF8String built-in type of ASN.1 is used as the base character-
string type in the present proposal.
4.2.8 Separate Data Modelling from Management Protocol Mapping
Description: It should be possible to separate the domain
specific data modelling work from the network management protocol
specific work.
*Unclear*
4.3 Rejected Objectives
4.3.1 Incomplete Translations
Description: Reality sucks. All information expressed in SMIng
may not be directly translatable to a MIB or PIB construct, but all
Expires May 13, 2002 [Page 28]
Internet Draft ASN.1 for SMIng November 13, 2001
information should be able to be conveyed in documentation or via
other mechanisms.
NOT ADDRESSED
4.3.2 Attribute Value Constraints
Description: SMIng should provide mechanisms to formally specify
constraints between values of multiple attributes.
MET
Constraints between attribute values can be specified in ASN.1 by
using "component relation" constraints within SEQUENCEs.
(Example to be included)
4.3.3 Attribute Transaction Constraints
Description: SMIng should provide a mechanism to formally express
that certain sets of attributes can only be modified in combination.
NOT ADDRESSED
4.3.4 Method Constraints
Description: Method definitions should provide constraints on
parameters.
NOT ADDRESSED
4.3.5 Agent Capabilities
Description: SMIng should provide mechanisms to describe agent
implementations.
NOT ADDRESSED
4.3.6 Relationships
Description: Ability to formally depict existence dependency,
value dependency, aggregation, containment, and other relationships
between attributes or attribute groups.
NOT ADDRESSED
4.3.7 Procedures
Expires May 13, 2002 [Page 29]
Internet Draft ASN.1 for SMIng November 13, 2001
Description: SMIng should support a mechanism to formally define
procedures that are used by managers when interacting with an agent.
NOT ADDRESSED
4.3.8 Associations
Description: SMIng should provide mechanisms to explicitly
specify associations.
NOT ADDRESSED
4.3.9 Association Cardinalities
Description: Cardinalities between associations should be
formally defined.
NOT ADDRESSED
4.3.10 Categories of Modules
Description: The SMIng documents should give clear guidance on
which kind of information (with respect to generality,
type/attribute group/extension/..) should be put in which kind of a
module.
NOT ADDRESSED
4.3.11 Mapping Modules to Files
Description: There should be a clear statement how SMIng modules
are mapped to files (1:1, n:1?) and how files should be named (by
module name in case of 1:1 mapping?).
NOT ADDRESSED
4.3.12 Simple Grammar
Description: The grammar of the language should be as simple as
possible. It should be free of exception rules. A measurement of
simplicity is shortness of the ABNF grammar.
NOT ADDRESSED
4.3.13 Place of Module Information
Expires May 13, 2002 [Page 30]
Internet Draft ASN.1 for SMIng November 13, 2001
Description: Module specific information (organization, contact,
description, revision information) should be bound to the module
itself and not to an artificial node (like SMIv2 MODULE-IDENTITY).
MET
(Example to be included)
4.3.14 Module Namespace
Description: Currently the namespace of modules is flat and there
is no structure in module naming causing the potential risk of name
clashes.
MET
Modules in ASN.1 are assigned both a name and (optionally) an OBJECT
IDENTIFIER. By assigning OBJECT IDENTIFIERs to modules, it is
possible to give a hierarchical structure to module naming.
(Example to be included)
4.3.15 Hyphens in Identifiers
Description: There has been some confusion whether hyphens are
allowed in SMIv2 identifiers: Module names are allowed to contain
hyphens. Node identifiers usually are not. But for example `mib-
2' is a frequently used identifier that contains a hyphen due to its
SMIv1 origin, when hyphen were not disallowed. Similarly, a number
of named numbers of enumeration types contain hyphens violating an
SMIv2 rule. SMIng should simply allow hyphens in all kinds of
identifiers. No exceptions.
MET
ASN.1 allows hyphens in names, as well as arbitrarily-long names.
The existing ASN.1 tools already solve the problem of mapping any
ASN.1 names into identifiers that comply with the rules of any
particular programming language.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
Expires May 13, 2002 [Page 31]
Internet Draft ASN.1 for SMIng November 13, 2001
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification
can be obtained from the IETF Secretariat. The IETF invites any
interested party to bring to its attention any copyrights, patents
or patent applications, or other proprietary rights which may cover
technology that may be required to practice this standard. Please
address the information to the IETF Executive Director.
Security Considerations
This document proposes the use of the ASN.1 language to describe
structures of management information, and presents an ASN.1 module
where a set of constructs serving that purpose are defined. The
adoption of ASN.1 and the use of the module have, by themselves, no
security impact on the Internet.
Acknowledgements
Some of the existing proposals for Next Generation SMI (especially
[SMING-NMRG], [SMING-SNMP] and [SMI-DS]) have inspired part of this
work.
References
[X.680]
ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998,
"Information technology Abstract Syntax Notation One (ASN.1):
Specification of basic notation",
http://www.itu.int/ITU-T/studygroups/com17/languages.
[X.681]
ITU-T Recommendation X.681 (1997) | ISO/IEC 8824 2:1998,
"Information technology Abstract Syntax Notation One (ASN.1):
Information object specification",
http://www.itu.int/ITU-T/studygroups/com17/languages.
[X.682]
ITU-T Recommendation X.682 (1997) | ISO/IEC 8824-3:1998,
"Information technology Abstract Syntax Notation One (ASN.1):
Constraint specification",
http://www.itu.int/ITU-T/studygroups/com17/languages.
[X.683]
ITU-T Recommendation X.683 (1997) | ISO/IEC 8824-4:1998,
"Information technology Abstract Syntax Notation One (ASN.1):
Parameterization of ASN.1 specifications",
http://www.itu.int/ITU-T/studygroups/com17/languages.
Expires May 13, 2002 [Page 32]
Internet Draft ASN.1 for SMIng November 13, 2001
[X.690]
ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998,
"Information technology ASN.1 encoding Rules: Specification of
Basic Encoding Rules (BER), Canonical Encoding Rules (CER), and
Distinguished Encoding Rules (DER)",
http://www.itu.int/ITU-T/studygroups/com17/languages.
[X.691]
ITU-T Recommendation X.691 (1997) | ISO/IEC 8825-2:1998,
"Information technology ASN.1 encoding rules: Specification of
Packed Encoding Rules (PER)",
http://www.itu.int/ITU-T/studygroups/com17/languages.
[RFC2026]
Bradner, S., "The Internet Standards Process -- Revision 3", RFC
2026, Harvard University, October, 1996.
[RFC2119]
S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels" RFC 2119, Harvard University, March 1997.
[SMING-OBJ]
Elliot, C., Harrington, D., Jason, J., Schoenwaelder, J., Strauss,
F., and W. Weiss, "SMIng Objectives", Work in progress (draft-ietf-
sming-reqs-06.txt), Cisco Systems, Enterasys Networks, Intel
Corporation, TU Braunschweig, Ellacoya Networks, October 2001.
[SMING-NMRG]
Strauss, F., Schoenwaelder, J., and McCloghrie, K., "SMIng - Next
Generation Structure of Management Information", Work in Progress
(draft-irtf-nmrg-sming-04), TU Braunschweig, Cisco Systems, November
2000.
[SMING-SNMP]
Strauss, F., and Schoenwaelder, J., "SMIng Mappings to SNMP", Work
in Progress (draft-ietf-sming-snmp-02), TU Braunschweig, July 2001.
[SMI-DS]
Bierman, A., "Structure of Management Information: Data Structures",
Work in Progress (draft-bierman-sming-ds-00.txt), Cisco Systems,
November 2001.
[ASN1-DUB]
Dubuisson, O., "ASN.1 - Communication between Heterogeneous
Systems", OSS Nokalva, 2000, http://www.oss.com/asn1/dubuisson.html.
[ASN1-LAR]
Larmouth, J., "ASN.1 Complete", Open Systems Solutions, 1999,
http://www.oss.com/asn1/larmouth.html.
Expires May 13, 2002 [Page 33]
Internet Draft ASN.1 for SMIng November 13, 2001
Authors' Addresses
Olivier Dubuisson
France Telecom R&D
DTL/MSV
22307 Lannion Cedex
France
Phone: +33 2 96 05 38 50
EMail: Olivier.Dubuisson@francetelecom.com
URI: http://asn1.elibel.tm.fr
Bancroft Scott
OSS Nokalva
One Executive Drive
Suite #450
Somerset, NJ 08873
USA
Phone: +1-732-302-9669 x-200
EMail: baos@oss.com
URI: http://www.oss.com
Alessandro Triglia
OSS Nokalva
One Executive Drive, Suite #450
Somerset, NJ 08873
USA
Phone: +39 091 625 7685
EMail: sandro@mclink.it
URI: http://www.oss.com
Michel Perin
Atos Origin
Tour "Les Miroirs"
18, avenue d'Alsace
92926 Paris La Dιfense Cedex
France
Phone: +33 1 55 91 28 41
EMail: michel.perin@atosorigin.com
URI: http://www.marben-products.com
Amardeo Sarma
NEC Europe Ltd.
Network Laboratories
Adenauerplatz 6
69115 Heidelberg
Expires May 13, 2002 [Page 34]
Internet Draft ASN.1 for SMIng November 13, 2001
Germany
Phone: +49 6221 13708-19
EMail: sarma@ccrle.nec.de
A. The ASN.1 SMIng module
--****************************************************
--
-- ASN1-SMIng base module
--
-- Alessandro Triglia, OSS Nokalva, 2001
--
--****************************************************
ASN1-SMIng DEFINITIONS IMPLICIT TAGS ::= BEGIN
SMICharacterString ::= UTF8String(SIZE(0..65535))
(CONSTRAINED BY {--Not all characters are allowed--})
SMIOctetString ::= OCTET STRING (SIZE(0..65535))
Integer32 ::= INTEGER(-2147483648..2147483647)
Integer64 ::= INTEGER
(-9223372036854775808..9223372036854775807)
Unsigned32 ::= INTEGER(0..4294967295)
Unsigned64 ::= INTEGER(0..18446744073709551615)
Float32 ::= REAL
(CONSTRAINED BY {-- Encodable in 4 octets --})
Float64 ::= REAL
(CONSTRAINED BY {-- Encodable in 8 octets --})
Float128 ::= REAL
(CONSTRAINED BY {-- Encodable in 16 octets --})
Counter32 ::= Unsigned32
Counter64 ::= Unsigned64
TimeTicks ::= Unsigned32
IpAddress ::= SMIOctetString (SIZE(4))
Opaque ::= SMIOctetString
Expires May 13, 2002 [Page 35]
Internet Draft ASN.1 for SMIng November 13, 2001
Status ::= ENUMERATED { current, deprecated, obsolete }
MaxAccess ::= ENUMERATED { none,
notificationsOnly, readOnly, readWrite }
NamingScheme ::= ENUMERATED { tabular,
hierarchical, extensible }
EntityInstanceRelationship ::= ENUMERATED { none, augments,
extends, expands }
MaxOperation ::= ENUMERATED { none, createDelete }
MODULE-INFO ::= CLASS {
&organization SMICharacterString,
&contact SMICharacterString,
&Revisions MODULE-REVISION,
&status Status DEFAULT current,
&description SMICharacterString }
WITH SYNTAX {
ORGANIZATION &organization
CONTACT &contact
REVISIONS &Revisions
[STATUS &status]
DESCRIPTION &description }
MODULE-REVISION ::= CLASS {
&date GeneralizedTime,
&description SMICharacterString }
WITH SYNTAX {
DATE &date
DESCRIPTION &description }
ENTITY-CLASS ::= CLASS {
&Syntax,
&units SMICharacterString OPTIONAL,
&displayFormat SMICharacterString OPTIONAL,
&assignedAttributeIDs SEQUENCE OF RELATIVE-OID
OPTIONAL,
&AttributeInfo ATTRIBUTE-INFO OPTIONAL,
&indexingAttributeIDs SEQUENCE OF RELATIVE-OID
OPTIONAL,
&namingScheme NamingScheme DEFAULT tabular,
Expires May 13, 2002 [Page 36]
Internet Draft ASN.1 for SMIng November 13, 2001
&extensionID RELATIVE-OID DEFAULT {0},
&status Status DEFAULT current,
&description SMICharacterString }
WITH SYNTAX {
SYNTAX &Syntax
[UNITS &units]
[DISPLAY-FORMAT &displayFormat]
[ASSIGNED-ATTRIBUTE-IDS &assignedAttributeIDs]
[ATTRIBUTE-INFO &AttributeInfo]
[INDEXING-ATTRIBUTES &indexingAttributeIDs]
[NAMING-SCHEME &namingScheme]
[EXTENSION &extensionID]
[STATUS &status]
DESCRIPTION &description }
ATTRIBUTE-INFO ::= CLASS {
&attributeID RELATIVE-OID,
&maxAccess MaxAccess DEFAULT none,
&status Status DEFAULT current,
&description SMICharacterString }
WITH SYNTAX {
ATTRIBUTE &attributeID
[MAX-ACCESS &maxAccess]
[STATUS &status]
DESCRIPTION &description }
EVENT ::= CLASS {
&status Status DEFAULT current,
&description SMICharacterString }
WITH SYNTAX {
[STATUS &status]
DESCRIPTION &description }
ENTITY-INSTANCE ::= CLASS {
&entityInstanceOid OBJECT IDENTIFIER,
&entityClass ENTITY-CLASS,
&baseEntityInstanceOid OBJECT IDENTIFIER OPTIONAL,
&relationship EntityInstanceRelationship
DEFAULT none,
&maxOperation MaxOperation DEFAULT none,
&status Status DEFAULT current,
&description SMICharacterString }
WITH SYNTAX {
Expires May 13, 2002 [Page 37]
Internet Draft ASN.1 for SMIng November 13, 2001
OID &entityInstanceOid
ENTITY-CLASS &entityClass
[BASE-ENTITY-INSTANCE &baseEntityInstanceOid]
[RELATIONSHIP &relationship]
[MAX-OPERATION &maxOperation]
[STATUS &status]
DESCRIPTION &description }
NOTIFICATION ::= CLASS {
¬ificationOid OBJECT IDENTIFIER,
&event EVENT,
&entityClass ENTITY-CLASS,
&transmittedAttributeIDs SEQUENCE OF RELATIVE-OID
OPTIONAL,
&status Status DEFAULT current,
&description SMICharacterString }
WITH SYNTAX {
OID ¬ificationOid
EVENT &event
ENTITY-CLASS &entityClass
[TRANSMITTED-ATTRIBUTES &transmittedAttributeIDs]
[STATUS &status]
DESCRIPTION &description }
NODE ::= CLASS {
&oid OBJECT IDENTIFIER,
&status Status DEFAULT current,
&description SMICharacterString }
WITH SYNTAX {
OID &oid
[STATUS &status]
DESCRIPTION &description }
NODE-GROUP ::= CLASS {
&nodeGroupOid OBJECT IDENTIFIER,
&memberOids SEQUENCE OF OBJECT IDENTIFIER,
&status Status DEFAULT current,
&description SMICharacterString }
WITH SYNTAX {
OID &nodeGroupOid
MEMBERS &memberOids
[STATUS &status]
DESCRIPTION &description }
Expires May 13, 2002 [Page 38]
Internet Draft ASN.1 for SMIng November 13, 2001
COMPLIANCE-STATEMENT ::= CLASS {
&statementOid OBJECT IDENTIFIER,
&mandatoryNodeGroupOids SEQUENCE OF OBJECT IDENTIFIER
OPTIONAL,
&OptionalNodeGroupsInfo OPTIONAL-NODE-GROUP-INFO
OPTIONAL,
&RefinedAttributesInfo REFINED-ATTRIBUTE-INFO OPTIONAL,
&status Status DEFAULT current,
&description SMICharacterString }
WITH SYNTAX {
OID &statementOid
[MANDATORY-NODE-GROUPS &mandatoryNodeGroupOids]
[OPTIONAL-NODE-GROUPS &OptionalNodeGroupsInfo]
[REFINED-ATTRIBUTES &RefinedAttributesInfo]
[STATUS &status]
DESCRIPTION &description }
OPTIONAL-NODE-GROUP-INFO ::= CLASS {
&nodeGroupOid OBJECT IDENTIFIER,
&description SMICharacterString }
WITH SYNTAX {
NODE-GROUP &nodeGroupOid
DESCRIPTION &description }
REFINED-ATTRIBUTE-INFO ::= CLASS {
&entityClass ENTITY-CLASS,
&attributeID RELATIVE-OID,
&description SMICharacterString }
WITH SYNTAX {
ENTITY-CLASS &entityClass
ATTRIBUTE &attributeID
DESCRIPTION &description }
END
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
Expires May 13, 2002 [Page 39]
Internet Draft ASN.1 for SMIng November 13, 2001
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Expires May 13, 2002 [Page 40]