INTERNET-DRAFT Expires December 1997 INTERNET-DRAFT
Draft Clarification for Textual Conventions June 8, 1997
A Clarification for
Textual Conventions
in SMIv2
<draft-perkins-clartc-00.txt>
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]