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]