INTERNET-DRAFT Expires December 1997 INTERNET-DRAFT Draft Clarification for Textual Conventions June 8, 1997 A Clarification for Textual Conventions in SMIv2 June 8, 1997 David T. Perkins dperkins@snmpinfo.com 1. Status of this Memo This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the internet-drafts Shadow Directories on: ftp.is.co.za (Africa) nic.nordu.net (Europe) ds.internic.net (US East Coast) ftp.isi.edu (US West Coast) munnari.oz.au (Pacific Rim) Expires 12/08/97 [Page 1] Draft Clarification for Textual Conventions June 8, 1997 2. Introduction This memo is informational. It specifies a clarification of version 2 of the SNMP SMI, a standard for the Internet community, which is defined by RFCs 1902[1], 1903[2], and 1904[3]. The clarification is to fix a perceived inconsistency in the definition of the TEXTUAL-CONVENTION construct. This problem is resolved by replacement text for section 3.5 of RFC 1903. 3. Background The TEXTUAL-CONVENTION construct, defined in RFC 1903, is used by MIB designers as a mechanism to create a "new" data type to be used in defining object types. A newly created type is nothing more than a short cut way to write an SNMP base type with additional constraints. These constraints may be a restriction in the range of values of integer types, a restriction in the length of string types, or a restriction in the values of individual octets in string types. A TEXTUAL-CONVENTION construct contains several clauses, some optional and some required. The required DESCRIPTION and SYNTAX clauses are used to specify the semantics and data type for the "new" data type defined by the construct. (Note that a textual convention may also be specified as an ASN.1 type assignment. This method, while legal, is not preferred, since the TEXTUAL-CONVENTION construct is more expressive and the associated clauses parsable by MIB compilers. However, the description of the SYNTAX clause also applies to the data type specified in a type assignment.) RFC 1903 contains the following text in section 3.5 that describes the SYNTAX clause: The SYNTAX clause, which must be present, defines abstract data structure corresponding to the textual convention. The data structure must be one of the alternatives defined in the ObjectSyntax CHOICE or the BITS construct (see section 7.1 in [2]). Reference "[2]" in the above text is to RFC 1902. Thus, to some readers this text seems to indicate that the only values allowed are the "base" SMIv2 data types from RFC 1902: INTEGER (-2147483648..2147483647), Integer32, OCTET STRING (SIZE (0..65535)), OBJECT IDENTIFIER, IpAddress, Counter32, Gauge32, TimeTicks, Opaque, Counter64, and Unsigned32. Also, some readers interpret the text to mean that sub-typing of these types is not allowed. However, section 13.3 of RFC 1902, shown below, gives explicit examples of textual conventions that contradict a strict interpretation of section 3.5 of RFC 1303. That is, the text allows a textual convention to use a previously defined textual convention as a data type, and the text allows sub-typing. The text from section 13.3 of RFC 1902 is: Expires 12/08/97 [Page 2] Draft Clarification for Textual Conventions June 8, 1997 Sub-typing of Textual Conventions (see [3]) is allowed but must be valid. In particular, each range specified for the textual convention must be a subset of a range specified for the base type. For example, Tc1 ::= INTEGER (1..10 | 11..20) Tc2 ::= Tc1 (2..10 | 12..15) -- is valid Tc3 ::= Tc1 (4..8) -- is valid Tc4 ::= Tc1 (8..12) -- is invalid 4. Replacement Text The text specified below is a replacement for the text of section 3.5 of RFC 1903. It resolves that perceived inconsistency between RFCs 1903 and 1902. This replacement text does not change or invalidate any existing SNMP MIB module, nor does it affect any existing or SNMP agent or management application. It affects only those existing MIB compilers whose implementors interpreted section 3.5 of RFC 1903 in the most restrictive terms. The replacement text is consistent with ASN.1 type definitions, and the normal usage by MIB designers. The replacement text is the following: 3.5. Mapping of the SYNTAX clause The SYNTAX clause, which must be present, defines the abstract data type corresponding to the textual convention. The data type must be one of the base SNMP data types described in section 7.1 of [2], a previously defined textual convention, or an allowed sub-typing of a base data type or previously defined textual convention. The following are examples of the SYNTAX clause: SYNTAX Integer32 SYNTAX OCTET STRING(SIZE(0..20)) SYNTAX INTEGER { up(1), down(2) } SYNTAX BITS { red(0), blue(1), green(2) } SYNTAX OBJECT IDENTIFIER SYNTAX DisplayString(SIZE(1..10)) -- DisplayString must be -- previously defined with -- a resolved data type of -- OCTET STRING SYNTAX Tc1(1..45 | 100..200) -- Tc1 must be previously defined -- with a resolved data type -- that is integer based Expires 12/08/97 [Page 3] Draft Clarification for Textual Conventions June 8, 1997 5. References [1] J. Case, K. McCloghrie, M. Rose, S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, 01/22/1996. [2] J. Case, K. McCloghrie, M. Rose, S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1903, 01/22/1996. [3] J. Case, K. McCloghrie, M. Rose, S. Waldbusser, "Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1904, 01/22/1996. Expires 12/08/97 [Page 4]