RFC relevance of definition

As per Relevance of the word definition, we have this rfc below:

Network Working Group Editors of this version
Request for Comments: 2578 K.
STD: 58 Cisco
Obsoletes: 1902 D.
Category: Standards Track
J.
TU
Authors of previous version
J.
SNMP
K.
Cisco
M.
First Virtual
S.
International Network
April 1999

Structure of Management Information Version 2 (SMIv2)

Status of this

This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited

Copyright

Copyright (C) The Internet Society (1999). All Rights Reserved

Table of

1 Introduction .................................................3
1.1 A Note on Terminology ......................................4
2 Definitions ..................................................4
2.1 The MODULE-IDENTITY macro ..................................5
2.2 Object Names and Syntaxes ..................................5
2.3 The OBJECT-TYPE macro ......................................8
2.5 The NOTIFICATION-TYPE macro ...............................10
2.6 Administrative Identifiers ................................11
3 Information Modules .........................................11
3.1 Macro Invocation ..........................................12
3.1.1 Textual Values and Strings ..............................13

McCloghrie, et al. Standards Track [Page 1]

RFC 2578 SMIv2 April 1999

3.2 IMPORTing Symbols .........................................14
3.3 Exporting Symbols .........................................14
3.4 ASN.1 Comments ............................................14
3.5 OBJECT IDENTIFIER values ..................................15
3.6 OBJECT IDENTIFIER usage ...................................15
3.7 Reserved Keywords .........................................16
4 Naming Hierarchy ............................................16
5 Mapping of the MODULE-IDENTITY macro ........................17
5.1 Mapping of the LAST-UPDATED clause ........................17
5.2 Mapping of the ORGANIZATION clause ........................17
5.3 Mapping of the CONTACT-INFO clause ........................18
5.4 Mapping of the DESCRIPTION clause .........................18
5.5 Mapping of the REVISION clause ............................18
5.5.1 Mapping of the DESCRIPTION sub-clause ...................18
5.6 Mapping of the MODULE-IDENTITY value ......................18
5.7 Usage Example .............................................18
6 Mapping of the OBJECT-IDENTITY macro ........................19
6.1 Mapping of the STATUS clause ..............................19
6.2 Mapping of the DESCRIPTION clause .........................20
6.3 Mapping of the REFERENCE clause ...........................20
6.4 Mapping of the OBJECT-IDENTITY value ......................20
6.5 Usage Example .............................................20
7 Mapping of the OBJECT-TYPE macro ............................20
7.1 Mapping of the SYNTAX clause ..............................21
7.1.1 Integer32 and INTEGER ...................................21
7.1.2 OCTET STRING ............................................21
7.1.3 OBJECT IDENTIFIER .......................................22
7.1.4 The BITS construct ......................................22
7.1.5 IpAddress ...............................................22
7.1.6 Counter32 ...............................................23
7.1.7 Gauge32 .................................................23
7.1.8 TimeTicks ...............................................24
7.1.9 Opaque ..................................................24
7.1.10 Counter64 ..............................................24
7.1.11 Unsigned32 .............................................25
7.1.12 Conceptual Tables ......................................25
7.1.12.1 Creation and Deletion of Conceptual Rows .............26
7.2 Mapping of the UNITS clause ...............................26
7.3 Mapping of the MAX-ACCESS clause ..........................26
7.4 Mapping of the STATUS clause ..............................27
7.5 Mapping of the DESCRIPTION clause .........................27
7.6 Mapping of the REFERENCE clause ...........................27
7.7 Mapping of the INDEX clause ...............................27
7.8 Mapping of the AUGMENTS clause ............................29
7.8.1 Relation between INDEX and AUGMENTS clauses .............30
7.9 Mapping of the DEFVAL clause ..............................30
7.10 Mapping of the OBJECT-TYPE value .........................31
7.11 Usage Example ............................................32

McCloghrie, et al. Standards Track [Page 2]

RFC 2578 SMIv2 April 1999

8 Mapping of the NOTIFICATION-TYPE macro ......................34
8.1 Mapping of the OBJECTS clause .............................34
8.2 Mapping of the STATUS clause ..............................34
8.3 Mapping of the DESCRIPTION clause .........................35
8.4 Mapping of the REFERENCE clause ...........................35
8.5 Mapping of the NOTIFICATION-TYPE value ....................35
8.6 Usage Example .............................................35
9 Refined Syntax ..............................................36
10 Extending an Information Module ............................37
10.1 Object Assignments .......................................37
10.2 Object Definitions .......................................38
10.3 Notification Definitions .................................39
11 Appendix A: Detailed Sub-typing Rules ......................40
11.1 Syntax Rules .............................................40
11.2 Examples .................................................41
12 Security Considerations ....................................41
13 Editors' Addresses .........................................41
14 References .................................................42
15 Full Copyright Statement ...................................43

1.

Management information is viewed as a collection of managed objects
residing in a virtual information store, termed the
Information Base (MIB). Collections of related objects are
in MIB modules. These modules are written using an adapted subset
OSI's Abstract Syntax Notation One, ASN.1 (1988) [1]. It is
purpose of this document, the Structure of Management
(SMI), to define that adapted subset, and to assign a set
associated administrative values

The SMI is divided into three parts: module definitions,
definitions, and, notification definitions

(1) Module definitions are used when describing information modules
An ASN.1 macro, MODULE-IDENTITY, is used to concisely convey
semantics of an information module

(2) Object definitions are used when describing managed objects.
ASN.1 macro, OBJECT-TYPE, is used to concisely convey the
and semantics of a managed object

(3) Notification definitions are used when describing
transmissions of management information. An ASN.1 macro
NOTIFICATION-TYPE, is used to concisely convey the syntax
semantics of a notification

McCloghrie, et al. Standards Track [Page 3]

RFC 2578 SMIv2 April 1999

1.1. A Note on

For the purpose of exposition, the original Structure of
Information, as described in RFCs 1155 (STD 16), 1212 (STD 16),
RFC 1215, is termed the SMI version 1 (SMIv1). The current
of the Structure of Management Information is termed SMI version 2
(SMIv2).

2.

SNMPv2-SMI DEFINITIONS ::=

-- the path to the

org OBJECT IDENTIFIER ::= { iso 3 } -- "iso" = 1
dod OBJECT IDENTIFIER ::= { org 6 }
internet OBJECT IDENTIFIER ::= { dod 1 }

directory OBJECT IDENTIFIER ::= { internet 1 }

mgmt OBJECT IDENTIFIER ::= { internet 2 }
mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }
transmission OBJECT IDENTIFIER ::= { mib-2 10 }

experimental OBJECT IDENTIFIER ::= { internet 3 }

private OBJECT IDENTIFIER ::= { internet 4 }
enterprises OBJECT IDENTIFIER ::= { private 1 }

security OBJECT IDENTIFIER ::= { internet 5 }

snmpV2 OBJECT IDENTIFIER ::= { internet 6 }

-- transport
snmpDomains OBJECT IDENTIFIER ::= { snmpV2 1 }

-- transport
snmpProxys OBJECT IDENTIFIER ::= { snmpV2 2 }

-- module
snmpModules OBJECT IDENTIFIER ::= { snmpV2 3 }

-- Extended UTCTime, to allow dates with four-digit
-- (Note that this definition of ExtUTCTime is not to be
-- by MIB modules.)
ExtUTCTime ::= OCTET STRING(SIZE(11 | 13))
-- format is YYMMDDHHMMZ or

McCloghrie, et al. Standards Track [Page 4]

RFC 2578 SMIv2 April 1999

-- where: YY - last two digits of year (only
-- between 1900-1999)
-- YYYY - last four digits of the year (any year
-- MM - month (01 through 12)
-- DD - day of month (01 through 31)
-- HH - hours (00 through 23)
-- MM - minutes (00 through 59)
-- Z - denotes GMT (the ASCII character Z
--
-- For example, "9502192015Z" and "199502192015Z"
-- 8:15pm GMT on 19 February 1995. Years after 1999 must
-- the four digit year format. Years 1900-1999 may use
-- two or four digit format

-- definitions for information

MODULE-IDENTITY MACRO ::=

TYPE NOTATION ::=
"LAST-UPDATED" value(Update ExtUTCTime
"ORGANIZATION"
"CONTACT-INFO"
"DESCRIPTION"

VALUE NOTATION ::=
value(VALUE OBJECT IDENTIFIER

RevisionPart ::=

|
Revisions ::=

| Revisions
Revision ::=
"REVISION" value(Update ExtUTCTime
"DESCRIPTION"

-- a character string as defined in section 3.1.1
Text ::= value(IA5String

OBJECT-IDENTITY MACRO ::=

TYPE NOTATION ::=
"STATUS"
"DESCRIPTION"

McCloghrie, et al. Standards Track [Page 5]

RFC 2578 SMIv2 April 1999

VALUE NOTATION ::=
value(VALUE OBJECT IDENTIFIER

Status ::=
"current
| "deprecated
| "obsolete

ReferPart ::=
"REFERENCE"
|

-- a character string as defined in section 3.1.1
Text ::= value(IA5String

-- names of
-- (Note that these definitions of ObjectName and
-- are not to be IMPORTed by MIB modules.)

ObjectName ::=
OBJECT

NotificationName ::=
OBJECT

-- syntax of

-- the "base types" defined here are
-- 3 built-in ASN.1 types: INTEGER, OCTET STRING, OBJECT
-- 8 application-defined types: Integer32, IpAddress, Counter32,
-- Gauge32, Unsigned32, TimeTicks, Opaque, and Counter64

ObjectSyntax ::=
CHOICE {

SimpleSyntax

-- note that SEQUENCEs for conceptual tables
-- rows are not mentioned here...

application-

}

McCloghrie, et al. Standards Track [Page 6]

RFC 2578 SMIv2 April 1999

-- built-in ASN.1

SimpleSyntax ::=
CHOICE {
-- INTEGERs with a more restrictive
-- may also be
integer-value -- includes Integer32
INTEGER (-2147483648..2147483647),

-- OCTET STRINGs with a more restrictive
-- may also be
string-
OCTET STRING (SIZE (0..65535)),

objectID-
OBJECT
}

-- indistinguishable from INTEGER, but never needs more
-- 32-bits for a two's complement
Integer32 ::=
INTEGER (-2147483648..2147483647)

-- application-wide

ApplicationSyntax ::=
CHOICE {
ipAddress-
IpAddress

counter-
Counter32,

timeticks-
TimeTicks

arbitrary-
Opaque

big-counter-
Counter64,

unsigned-integer-value -- includes Gauge32
Unsigned32
}

-- in network-byte

McCloghrie, et al. Standards Track [Page 7]

RFC 2578 SMIv2 April 1999

-- (this is a tagged type for historical reasons
IpAddress ::=
[APPLICATION 0]
IMPLICIT OCTET STRING (SIZE (4))

-- this
Counter32 ::=
[APPLICATION 1]
IMPLICIT INTEGER (0..4294967295)

-- this doesn't
Gauge32 ::=
[APPLICATION 2]
IMPLICIT INTEGER (0..4294967295)

-- an unsigned 32-bit
-- indistinguishable from Gauge32
Unsigned32 ::=
[APPLICATION 2]
IMPLICIT INTEGER (0..4294967295)

-- hundredths of seconds since an
TimeTicks ::=
[APPLICATION 3]
IMPLICIT INTEGER (0..4294967295)

-- for backward-compatibility
Opaque ::=
[APPLICATION 4]
IMPLICIT OCTET

-- for counters that wrap in less than one hour with only 32
Counter64 ::=
[APPLICATION 6]
IMPLICIT INTEGER (0..18446744073709551615)

-- definition for

OBJECT-TYPE MACRO ::=

TYPE NOTATION ::=
"SYNTAX"

"MAX-ACCESS"
"STATUS"
"DESCRIPTION"

McCloghrie, et al. Standards Track [Page 8]

RFC 2578 SMIv2 April 1999

VALUE NOTATION ::=
value(VALUE ObjectName

Syntax ::= -- Must be one of the following
-- a base type (or its refinement),
-- a textual convention (or its refinement),
-- a BITS pseudo-

| "BITS" "{" NamedBits "}"

NamedBits ::=
| NamedBits ","

NamedBit ::= identifier "(" number ")" -- number is

UnitsPart ::=
"UNITS"
|

Access ::=
"not-accessible
| "accessible-for-notify
| "read-only
| "read-write
| "read-create

Status ::=
"current
| "deprecated
| "obsolete

ReferPart ::=
"REFERENCE"
|

IndexPart ::=
"INDEX" "{" IndexTypes "}"
| "AUGMENTS" "{" Entry "}"
|
IndexTypes ::=

| IndexTypes ","
IndexType ::=
"IMPLIED"
|

McCloghrie, et al. Standards Track [Page 9]

RFC 2578 SMIv2 April 1999

Index ::=
-- use the SYNTAX value of
-- correspondent OBJECT-TYPE
value(ObjectName
Entry ::=
-- use the INDEX value of
-- correspondent OBJECT-TYPE
value(ObjectName

DefValPart ::= "DEFVAL" "{" Defvalue "}"
|

Defvalue ::= -- must be valid for the type specified
-- SYNTAX clause of same OBJECT-TYPE
value(ObjectSyntax
| "{" BitsValue "}"

BitsValue ::=
|

BitNames ::=
| BitNames ","

BitName ::=

-- a character string as defined in section 3.1.1
Text ::= value(IA5String

-- definitions for

NOTIFICATION-TYPE MACRO ::=

TYPE NOTATION ::=

"STATUS"
"DESCRIPTION"

VALUE NOTATION ::=
value(VALUE NotificationName

ObjectsPart ::=
"OBJECTS" "{" Objects "}"
|
Objects ::=

McCloghrie, et al. Standards Track [Page 10]

RFC 2578 SMIv2 April 1999

| Objects ","
Object ::=
value(ObjectName

Status ::=
"current
| "deprecated
| "obsolete

ReferPart ::=
"REFERENCE"
|

-- a character string as defined in section 3.1.1
Text ::= value(IA5String

-- definitions of administrative

zeroDotZero OBJECT-
STATUS

"A value used for null identifiers."
::= { 0 0 }

3. Information

An "information module" is an ASN.1 module defining
relating to network management

The SMI describes how to use an adapted subset of ASN.1 (1988)
define an information module. Further, additional restrictions
placed on "standard" information modules. It is strongly
that "enterprise-specific" information modules also adhere to
restrictions

Typically, there are three kinds of information modules

(1) MIB modules, which contain definitions of inter-related
objects, make use of the OBJECT-TYPE and NOTIFICATION-TYPE macros

(2) compliance statements for MIB modules, which make use of
MODULE-COMPLIANCE and OBJECT-GROUP macros [2]; and

(3) capability statements for agent implementations which make use
the AGENT-CAPABILITIES macros [2].

McCloghrie, et al. Standards Track [Page 11]

RFC 2578 SMIv2 April 1999

This classification scheme does not imply a rigid taxonomy.
example, a "standard" information module will normally
definitions of managed objects and a compliance statement
Similarly, an "enterprise-specific" information module might
definitions of managed objects and a capability statement.
course, a "standard" information module may not contain
statements

The constructs of ASN.1 allowed in SMIv2 information modules include
the IMPORTS clause, value definitions for OBJECT IDENTIFIERs,
definitions for SEQUENCEs (with restrictions), ASN.1 type
of the restricted ASN.1 types allowed in SMIv2, and instances
ASN.1 macros defined in this document and its companion documents [2,
3]. Additional ASN.1 macros must not be defined in SMIv2
modules. SMIv1 macros must not be used in SMIv2 information modules

The names of all standard information modules must be unique (
different versions of the same information module should have
same name). Developers of enterprise information modules
encouraged to choose names for their information modules that
have a low probability of colliding with standard or other
information modules. An information module may not use the ASN.1
construct of placing an object identifier value between the
name and the "DEFINITIONS" keyword. For the purposes of
specification, an ASN.1 module name begins with an upper-case
and continues with zero or more letters, digits, or hyphens,
that a hyphen can not be the last character, nor can there be
consecutive hyphens

All information modules start with exactly one invocation of
MODULE-IDENTITY macro, which provides contact information as well
revision history to distinguish between versions of the
information module. This invocation must appear immediately
any IMPORTs statements

3.1. Macro

Within an information module, each macro invocation appears as

<descriptor> ::=
where <descriptor> corresponds to an ASN.1 identifier,
the macro being invoked, and and depend on
definition of the macro. (Note that this definition of a
applies to all macros defined in this memo and in [2].)

McCloghrie, et al. Standards Track [Page 12]

RFC 2578 SMIv2 April 1999

For the purposes of this specification, an ASN.1 identifier
of one or more letters or digits, and its initial character must be
lower-case letter. Note that hyphens are not allowed by
specification (except for use by information modules converted
SMIv1 which did allow hyphens).

For all descriptors appearing in an information module,
descriptor shall be unique and mnemonic, and shall not exceed 64
characters in length. (However, descriptors longer than 32
characters are not recommended.) This promotes a common language
humans to use when discussing the information module and
facilitates simple table mappings for user-interfaces

The set of descriptors defined in all "standard" information
shall be unique

Finally, by convention, if the descriptor refers to an object with
SYNTAX clause value of either Counter32 or Counter64, then
descriptor used for the object should denote plurality

3.1.1. Textual Values and

Some clauses in a macro invocation may take a character string as
textual value (e.g., the DESCRIPTION clause). Other clauses
binary or hexadecimal strings (in any position where a non-
number is allowed).

A character string is preceded and followed by the quote
("), and consists of an arbitrary number (possibly zero) of

- any 7-bit displayable ASCII characters except quote ("),
- tab characters
- spaces,
- line terminator characters (\n or \r\n).

The value of a character string is interpreted as ASCII

A binary string consists of a number (possibly zero) of zeros
ones preceded by a single (') and followed by either the pair ('B)
('b), where the number is a multiple of eight

A hexadecimal string consists of an even number (possibly zero)
hexadecimal digits, preceded by a single (') and followed by
the pair ('H) or ('h). Digits specified via letters can be in
or lower case

Note that ASN.1 comments can not be enclosed inside any of
types of strings

McCloghrie, et al. Standards Track [Page 13]

RFC 2578 SMIv2 April 1999

3.2. IMPORTing

To reference an external object, the IMPORTS statement must be
to identify both the descriptor and the module in which
descriptor is defined, where the module is identified by its ASN.1
module name

Note that when symbols from "enterprise-specific" information
are referenced (e.g., a descriptor), there is the possibility
collision. As such, if different objects with the same
are IMPORTed, then this ambiguity is resolved by prefixing
descriptor with the name of the information module and a dot ("."),
i.e.,

"module.descriptor

(All descriptors must be unique within any information module.)

Of course, this notation can be used to refer to objects even
there is no collision when IMPORTing symbols

Finally, if any of the ASN.1 named types and macros defined in
document, specifically

Counter32, Counter64, Gauge32, Integer32, IpAddress, MODULE
IDENTITY, NOTIFICATION-TYPE, Opaque, OBJECT-TYPE, OBJECT
IDENTITY, TimeTicks, Unsigned32,

or any of those defined in [2] or [3], are used in an
module, then they must be imported using the IMPORTS statement
However, the following must not be included in an IMPORTS statement

- named types defined by ASN.1 itself, specifically: INTEGER
OCTET STRING, OBJECT IDENTIFIER, SEQUENCE, SEQUENCE OF type
- the BITS construct

3.3. Exporting

The ASN.1 EXPORTS statement is not allowed in SMIv2
modules. All items defined in an information module
automatically exported

3.4. ASN.1

ASN.1 comments can be included in an information module. However,
is recommended that all substantive descriptions be placed within
appropriate DESCRIPTION clause

McCloghrie, et al. Standards Track [Page 14]

RFC 2578 SMIv2 April 1999

ASN.1 comments commence with a pair of adjacent hyphens and end
the next pair of adjacent hyphens or at the end of the line
whichever occurs first. Comments ended by a pair of hyphens have
effect of a single space character

3.5. OBJECT IDENTIFIER

An OBJECT IDENTIFIER value is an ordered list of non-
numbers. For the SMIv2, each number in the list is referred to as
sub-identifier, there are at most 128 sub-identifiers in a value,
each sub-identifier has a maximum value of 2^32-1 (4294967295
decimal).

All OBJECT IDENTIFIER values have at least two sub-identifiers,
the value of the first sub-identifier is one of the following well
known names

Value
0
1
2 joint-iso-

(Note that this SMI does not recognize "new" well-known names, e.g.,
as defined when the CCITT became the ITU.)

3.6. OBJECT IDENTIFIER

OBJECT IDENTIFIERs are used in information modules in two ways

(1) registration: the definition of a particular item is registered
a particular OBJECT IDENTIFIER value, and associated with
particular descriptor. After such a registration, the
thereby associated with the value are not allowed to change,
OBJECT IDENTIFIER can not be used for any other registration,
the descriptor can not be changed nor associated with any
registration. The following macros result in a registration

OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE, OBJECT-GROUP
OBJECT-IDENTITY, NOTIFICATION-GROUP, MODULE-COMPLIANCE
AGENT-CAPABILITIES

(2) assignment: a descriptor can be assigned to a particular
IDENTIFIER value. For this usage, the semantics associated
the OBJECT IDENTIFIER value is not allowed to change, and
descriptor assigned to a particular OBJECT IDENTIFIER value
subsequently be assigned to another. However, multiple
can be assigned to the same OBJECT IDENTIFIER value.
assignments are specified in the following manner

McCloghrie, et al. Standards Track [Page 15]

RFC 2578 SMIv2 April 1999

mib OBJECT IDENTIFIER ::= { mgmt 1 } -- from RFC1156
mib-2 OBJECT IDENTIFIER ::= { mgmt 1 } -- from RFC1213
fredRouter OBJECT IDENTIFIER ::= { flintStones 1 1 }
barneySwitch OBJECT IDENTIFIER ::= { flintStones bedrock(2) 1 }

Note while the above examples are legal, the following is not

dinoHost OBJECT IDENTIFIER ::= { flintStones bedrock 2 }

A descriptor is allowed to be associated with both a registration
an assignment, providing both are associated with the same
IDENTIFIER value and semantics

3.7. Reserved

The following are reserved keywords which must not be used
descriptors or module names

ABSENT ACCESS AGENT-CAPABILITIES ANY APPLICATION AUGMENTS
BIT BITS BOOLEAN BY CHOICE COMPONENT COMPONENTS CONTACT-
CREATION-REQUIRES Counter32 Counter64 DEFAULT
DEFINITIONS DEFVAL DESCRIPTION DISPLAY-HINT END
ENTERPRISE EXPLICIT EXPORTS EXTERNAL FALSE FROM GROUP Gauge32
IDENTIFIER IMPLICIT IMPLIED IMPORTS INCLUDES INDEX
Integer32 IpAddress LAST-UPDATED MANDATORY-GROUPS MAX MAX-
MIN MIN-ACCESS MINUS-INFINITY MODULE MODULE-COMPLIANCE MODULE
IDENTITY NOTIFICATION-GROUP NOTIFICATION-TYPE NOTIFICATIONS
OBJECT OBJECT-GROUP OBJECT-IDENTITY OBJECT-TYPE OBJECTS OCTET
OPTIONAL ORGANIZATION Opaque PLUS-INFINITY PRESENT
PRODUCT-RELEASE REAL REFERENCE REVISION SEQUENCE SET SIZE
STRING SUPPORTS SYNTAX TAGS TEXTUAL-CONVENTION TRAP-TYPE
TimeTicks UNITS UNIVERSAL Unsigned32 VARIABLES VARIATION
WRITE-

4. Naming

The root of the subtree administered by the Internet Assigned
Authority (IANA) for the Internet is

internet OBJECT IDENTIFIER ::= { iso 3 6 1 }

That is, the Internet subtree of OBJECT IDENTIFIERs starts with
prefix

1.3.6.1.

Several branches underneath this subtree are used for
management

McCloghrie, et al. Standards Track [Page 16]

RFC 2578 SMIv2 April 1999

mgmt OBJECT IDENTIFIER ::= { internet 2 }
experimental OBJECT IDENTIFIER ::= { internet 3 }
private OBJECT IDENTIFIER ::= { internet 4 }
enterprises OBJECT IDENTIFIER ::= { private 1 }

However, the SMI does not prohibit the definition of objects in
portions of the object tree

The mgmt(2) subtree is used to identify "standard" objects

The experimental(3) subtree is used to identify objects
designed by working groups of the IETF. If an information
produced by a working group becomes a "standard" information module
then at the very beginning of its entry onto the Internet
track, the objects are moved under the mgmt(2) subtree

The private(4) subtree is used to identify objects
unilaterally. The enterprises(1) subtree beneath private is used
among other things, to permit providers of networking subsystems
register models of their products

5. Mapping of the MODULE-IDENTITY

The MODULE-IDENTITY macro is used to provide contact and
history for each information module. It must appear exactly once
every information module. It should be noted that the expansion
the MODULE-IDENTITY macro is something which conceptually
during implementation and not during run-time

Note that reference in an IMPORTS clause or in clauses of SMIv
macros to an information module is NOT through the use of
'descriptor' of a MODULE-IDENTITY macro; rather, an
module is referenced through specifying its module name

5.1. Mapping of the LAST-UPDATED

The LAST-UPDATED clause, which must be present, contains the date
time that this information module was last edited

5.2. Mapping of the ORGANIZATION

The ORGANIZATION clause, which must be present, contains a
description of the organization under whose auspices this
module was developed

McCloghrie, et al. Standards Track [Page 17]

RFC 2578 SMIv2 April 1999

5.3. Mapping of the CONTACT-INFO

The CONTACT-INFO clause, which must be present, contains the name
postal address, telephone number, and electronic mail address of
person to whom technical queries concerning this information
should be sent

5.4. Mapping of the DESCRIPTION

The DESCRIPTION clause, which must be present, contains a high-
textual description of the contents of this information module

5.5. Mapping of the REVISION

The REVISION clause, which need not be present, is repeatedly used
describe the revisions (including the initial version) made to
information module, in reverse chronological order (i.e., most
first). Each instance of this clause contains the date and time
the revision

5.5.1. Mapping of the DESCRIPTION sub-

The DESCRIPTION sub-clause, which must be present for each
clause, contains a high-level textual description of the
identified in that REVISION clause

5.6. Mapping of the MODULE-IDENTITY

The value of an invocation of the MODULE-IDENTITY macro is an
IDENTIFIER. As such, this value may be authoritatively used
specifying an OBJECT IDENTIFIER value to refer to the
module containing the invocation

Note that it is a common practice to use the value of the MODULE
IDENTITY macro as a subtree under which other OBJECT
values assigned within the module are defined. However, it is
(and occasionally necessary) for the other OBJECT IDENTIFIER
assigned within the module to be unrelated to the OBJECT
value of the MODULE-IDENTITY macro

5.7. Usage

Consider how a skeletal MIB module might be constructed: e.g.,

FIZBIN-MIB DEFINITIONS ::=

MODULE-IDENTITY, OBJECT-TYPE,

McCloghrie, et al. Standards Track [Page 18]

RFC 2578 SMIv2 April 1999

FROM SNMPv2-SMI

fizbin MODULE-
LAST-UPDATED "199505241811Z
ORGANIZATION "IETF SNMPv2 Working Group
CONTACT-
" Marshall T.

Postal: Dover Beach Consulting, Inc
420 Whisman
Mountain View, CA 94043-2186

Tel: +1 415 968 1052
Fax: +1 415 968 2510

E-mail: mrose@dbc.mtview.ca.us

"The MIB module for entities implementing the
protocol."
REVISION "9505241811Z

"The latest version of this MIB module."
REVISION "9210070433Z

"The initial version of this MIB module, published
RFC yyyy."
-- contact IANA for actual
::= { experimental xx }

6. Mapping of the OBJECT-IDENTITY

The OBJECT-IDENTITY macro is used to define information about
OBJECT IDENTIFIER assignment. All administrative OBJECT
assignments which define a type identification value (
AutonomousType, a textual convention defined in [3]) should
defined via the OBJECT-IDENTITY macro. It should be noted that
expansion of the OBJECT-IDENTITY macro is something
conceptually happens during implementation and not during run-time

6.1. Mapping of the STATUS

The STATUS clause, which must be present, indicates whether
definition is current or historic

McCloghrie, et al. Standards Track [Page 19]

RFC 2578 SMIv2 April 1999

The value "current" means that the definition is current and valid
The value "obsolete" means the definition is obsolete and should
be implemented and/or can be removed if previously implemented
While the value "deprecated" also indicates an obsolete definition
it permits new/continued implementation in order to
interoperability with older/existing implementations

6.2. Mapping of the DESCRIPTION

The DESCRIPTION clause, which must be present, contains a
description of the object assignment

6.3. Mapping of the REFERENCE

The REFERENCE clause, which need not be present, contains a
cross-reference to some other document, either another
module which defines a related assignment, or some other
which provides additional information relevant to this definition

6.4. Mapping of the OBJECT-IDENTITY

The value of an invocation of the OBJECT-IDENTITY macro is an
IDENTIFIER

6.5. Usage

Consider how an OBJECT IDENTIFIER assignment might be made: e.g.,

fizbin69 OBJECT-
STATUS

"The authoritative identity of the Fizbin 69 chipset."
::= { fizbinChipSets 1 }

7. Mapping of the OBJECT-TYPE

The OBJECT-TYPE macro is used to define a type of managed object.
should be noted that the expansion of the OBJECT-TYPE macro
something which conceptually happens during implementation and
during run-time

For leaf objects which are not columnar objects (i.e., not
within a conceptual table), instances of the object are identified
appending a sub-identifier of zero to the name of that object
Otherwise, the INDEX clause of the conceptual row object superior
a columnar object defines instance identification information

McCloghrie, et al. Standards Track [Page 20]

RFC 2578 SMIv2 April 1999

7.1. Mapping of the SYNTAX

The SYNTAX clause, which must be present, defines the abstract
structure corresponding to that object. The data structure must
one of the following: a base type, the BITS construct, or a
convention. (SEQUENCE OF and SEQUENCE are also possible
conceptual tables, see section 7.1.12). The base types are
defined in the ObjectSyntax CHOICE. A textual convention is
newly-defined type defined as a sub-type of a base type [3].

An extended subset of the full capabilities of ASN.1 (1988) sub
typing is allowed, as appropriate to the underlying ASN.1 type.
such restriction on size, range or enumerations specified in
clause represents the maximal level of support which makes "
sense". Restrictions on sub-typing are specified in detail
Section 9 and Appendix A of this memo

The semantics of ObjectSyntax are now described

7.1.1. Integer32 and

The Integer32 type represents integer-valued information
-2^31 and 2^31-1 inclusive (-2147483648 to 2147483647 decimal).
type is indistinguishable from the INTEGER type. Both the
and Integer32 types may be sub-typed to be more constrained than
Integer32 type

The INTEGER type (but not the Integer32 type) may also be used
represent integer-valued information as named-number enumerations
In this case, only those named-numbers so enumerated may be
as a value. Note that although it is recommended that
values start at 1 and be numbered contiguously, any valid value
Integer32 is allowed for an enumerated value and, further,
values needn't be contiguously assigned

Finally, a label for a named-number enumeration must consist of
or more letters or digits, up to a maximum of 64 characters, and
initial character must be a lower-case letter. (However,
longer than 32 characters are not recommended.) Note that
are not allowed by this specification (except for use by
modules converted from SMIv1 which did allow hyphens).

7.1.2. OCTET

The OCTET STRING type represents arbitrary binary or textual data
Although the SMI-specified size limitation for this type is 65535
octets, MIB designers should realize that there may be
and interoperability limitations for sizes in excess of 255 octets

McCloghrie, et al. Standards Track [Page 21]

RFC 2578 SMIv2 April 1999

7.1.3. OBJECT

The OBJECT IDENTIFIER type represents administratively
names. Any instance of this type may have at most 128 sub
identifiers. Further, each sub-identifier must not exceed the
2^32-1 (4294967295 decimal).

7.1.4. The BITS

The BITS construct represents an enumeration of named bits.
collection is assigned non-negative, contiguous (but see below
values, starting at zero. Only those named-bits so enumerated may
present in a value. (Thus, enumerations must be assigned
consecutive bits; however, see Section 9 for refinements of an
with this syntax.)

As part of updating an information module, for an object
using the BITS construct, new enumerations can be added or
enumerations can have new labels assigned to them. After
enumeration is added, it might not be possible to distinguish
an implementation of the updated object for which the new
is not asserted, and an implementation of the object prior to
addition. Depending on the circumstances, such an ambiguity
either be desirable or could be undesirable. The means to avoid
an ambiguity is dependent on the encoding of values on the wire
however, one possibility is to define new enumerations starting
the next multiple of eight bits. (Of course, this can also result
the enumerations no longer being contiguous.)

Although there is no SMI-specified limitation on the number
enumerations (and therefore on the length of a value), except as
be imposed by the limit on the length of an OCTET STRING,
designers should realize that there may be implementation
interoperability limitations for sizes in excess of 128 bits

Finally, a label for a named-number enumeration must consist of
or more letters or digits, up to a maximum of 64 characters, and
initial character must be a lower-case letter. (However,
longer than 32 characters are not recommended.) Note that
are not allowed by this specification

7.1.5.

The IpAddress type represents a 32-bit internet address. It
represented as an OCTET STRING of length 4, in network byte-order

McCloghrie, et al. Standards Track [Page 22]

RFC 2578 SMIv2 April 1999

Note that the IpAddress type is a tagged type for historical reasons
Network addresses should be represented using an invocation of
TEXTUAL-CONVENTION macro [3].

7.1.6. Counter32

The Counter32 type represents a non-negative integer
monotonically increases until it reaches a maximum value of 2^32-1
(4294967295 decimal), when it wraps around and starts
again from zero

Counters have no defined "initial" value, and thus, a single value
a Counter has (in general) no information content.
in the monotonically increasing value normally occur at re
initialization of the management system, and at other times
specified in the description of an object-type using this ASN.1 type
If such other times can occur, for example, the creation of an
instance at times other than re-initialization, then a
object should be defined, with an appropriate SYNTAX clause,
indicate the last discontinuity. Examples of appropriate
clause include: TimeStamp (a textual convention defined in [3]),
DateAndTime (another textual convention from [3]) or TimeTicks

The value of the MAX-ACCESS clause for objects with a SYNTAX
value of Counter32 is either "read-only" or "accessible-for-notify".

A DEFVAL clause is not allowed for objects with a SYNTAX clause
of Counter32.

7.1.7. Gauge32

The Gauge32 type represents a non-negative integer, which
increase or decrease, but shall never exceed a maximum value,
fall below a minimum value. The maximum value can not be
than 2^32-1 (4294967295 decimal), and the minimum value can not
smaller than 0. The value of a Gauge32 has its maximum
whenever the information being modeled is greater than or equal
its maximum value, and has its minimum value whenever the
being modeled is smaller than or equal to its minimum value. If
information being modeled subsequently decreases below (
above) the maximum (minimum) value, the Gauge32 also
(increases). (Note that despite of the use of the term "latched"
the original definition of this type, it does not become "stuck"
its maximum or minimum value.)

McCloghrie, et al. Standards Track [Page 23]

RFC 2578 SMIv2 April 1999

7.1.8.

The TimeTicks type represents a non-negative integer which
the time, modulo 2^32 (4294967296 decimal), in hundredths of a
between two epochs. When objects are defined which use this ASN.1
type, the description of the object identifies both of the
epochs

For example, [3] defines the TimeStamp textual convention which
based on the TimeTicks type. With a TimeStamp, the first
epoch is defined as the time when sysUpTime [5] was zero, and
second reference epoch is defined as the current value of sysUpTime

The TimeTicks type may not be sub-typed

7.1.9.

The Opaque type is provided solely for backward-compatibility,
shall not be used for newly-defined object types

The Opaque type supports the capability to pass arbitrary ASN.1
syntax. A value is encoded using the ASN.1 Basic Encoding Rules [4]
into a string of octets. This, in turn, is encoded as an
STRING, in effect "double-wrapping" the original ASN.1 value

Note that a conforming implementation need only be able to accept
recognize opaquely-encoded data. It need not be able to unwrap
data and then interpret its contents

A requirement on "standard" MIB modules is that no object may have
SYNTAX clause value of Opaque

7.1.10. Counter64

The Counter64 type represents a non-negative integer
monotonically increases until it reaches a maximum value of 2^64-1
(18446744073709551615 decimal), when it wraps around and
increasing again from zero

Counters have no defined "initial" value, and thus, a single value
a Counter has (in general) no information content.
in the monotonically increasing value normally occur at re
initialization of the management system, and at other times
specified in the description of an object-type using this ASN.1 type
If such other times can occur, for example, the creation of an
instance at times other than re-initialization, then a
object should be defined, with an appropriate SYNTAX clause,
indicate the last discontinuity. Examples of appropriate

McCloghrie, et al. Standards Track [Page 24]

RFC 2578 SMIv2 April 1999

clause are: TimeStamp (a textual convention defined in [3]),
DateAndTime (another textual convention from [3]) or TimeTicks

The value of the MAX-ACCESS clause for objects with a SYNTAX
value of Counter64 is either "read-only" or "accessible-for-notify".

A requirement on "standard" MIB modules is that the Counter64
may be used only if the information being modeled would wrap in
than one hour if the Counter32 type was used instead

A DEFVAL clause is not allowed for objects with a SYNTAX clause
of Counter64.

7.1.11. Unsigned32

The Unsigned32 type represents integer-valued information between 0
and 2^32-1 inclusive (0 to 4294967295 decimal).

7.1.12. Conceptual

Management operations apply exclusively to scalar objects. However
it is sometimes convenient for developers of management
to impose an imaginary, tabular structure on an ordered collection
objects within the MIB. Each such conceptual table contains zero
more rows, and each row may contain one or more scalar objects
termed columnar objects. This conceptualization is formalized
using the OBJECT-TYPE macro to define both an object
corresponds to a table and an object which corresponds to a row
that table. A conceptual table has SYNTAX of the form

SEQUENCE OF
where refers to the SEQUENCE type of its
conceptual row. A conceptual row has SYNTAX of the form

where is a SEQUENCE type defined as follows

::= SEQUENCE { , ... , }

where there is one for each subordinate object, and
is of the form

<descriptor>
where <descriptor> is the descriptor naming a subordinate object,
has the value of that subordinate object's SYNTAX clause

McCloghrie, et al. Standards Track [Page 25]

RFC 2578 SMIv2 April 1999

except that both sub-typing information and the named values
enumerated integers or the named bits for the BITS construct,
omitted from .

Further, a is always present for every subordinate object
(The ASN.1 DEFAULT and OPTIONAL clauses are disallowed in
SEQUENCE definition.) The MAX-ACCESS clause for conceptual
and rows is "not-accessible".

7.1.12.1. Creation and Deletion of Conceptual

For newly-defined conceptual rows which allow the creation of
object instances and/or the deletion of existing object instances
there should be one columnar object with a SYNTAX clause value
RowStatus (a textual convention defined in [3]) and a MAX-
clause value of read-create. By convention, this is termed
status column for the conceptual row

7.2. Mapping of the UNITS

This UNITS clause, which need not be present, contains a
definition of the units associated with that object

7.3. Mapping of the MAX-ACCESS

The MAX-ACCESS clause, which must be present, defines whether
makes "protocol sense" to read, write and/or create an instance
the object, or to include its value in a notification. This is
maximal level of access for the object. (This maximal level
access is independent of any administrative authorization policy.)

The value "read-write" indicates that read and write access
"protocol sense", but create does not. The value "read-create
indicates that read, write and create access make "protocol sense".
The value "not-accessible" indicates an auxiliary object (see
7.7). The value "accessible-for-notify" indicates an object which
accessible only via a notification (e.g., snmpTrapOID [5]).

These values are ordered, from least to greatest: "not-accessible",
"accessible-for-notify", "read-only", "read-write", "read-create".

If any columnar object in a conceptual row has "read-create" as
maximal level of access, then no other columnar object of the
conceptual row may have a maximal access of "read-write". (Note
"read-create" is a superset of "read-write".)

McCloghrie, et al. Standards Track [Page 26]

RFC 2578 SMIv2 April 1999

7.4. Mapping of the STATUS

The STATUS clause, which must be present, indicates whether
definition is current or historic

The value "current" means that the definition is current and valid
The value "obsolete" means the definition is obsolete and should
be implemented and/or can be removed if previously implemented
While the value "deprecated" also indicates an obsolete definition
it permits new/continued implementation in order to
interoperability with older/existing implementations

7.5. Mapping of the DESCRIPTION

The DESCRIPTION clause, which must be present, contains a
definition of that object which provides all semantic
necessary for implementation, and should embody any information
would otherwise be communicated in any ASN.1 commentary
associated with the object

7.6. Mapping of the REFERENCE

The REFERENCE clause, which need not be present, contains a
cross-reference to some other document, either another
module which defines a related assignment, or some other
which provides additional information relevant to this definition

7.7. Mapping of the INDEX

The INDEX clause, which must be present if that object corresponds
a conceptual row (unless an AUGMENTS clause is present instead),
must be absent otherwise, defines instance identification
for the columnar objects subordinate to that object

The instance identification information in an INDEX clause
specify object(s) such that value(s) of those object(s)
unambiguously distinguish a conceptual row. The objects can
columnar objects from the same and/or another conceptual table,
must not be scalar objects. Multiple occurrences of the same
in a single INDEX clause is strongly discouraged

The syntax of the objects in the INDEX clause indicate how to
the instance-identifier

(1) integer-valued (i.e., having INTEGER as its underlying
type): a single sub-identifier taking the integer value (
works only for non-negative integers);

McCloghrie, et al. Standards Track [Page 27]

RFC 2578 SMIv2 April 1999

(2) string-valued, fixed-length strings (or variable-length preceded
the IMPLIED keyword): `n' sub-identifiers, where `n' is the
of the string (each octet of the string is encoded in a
sub-identifier);

(3) string-valued, variable-length strings (not preceded by the
keyword): `n+1' sub-identifiers, where `n' is the length of
string (the first sub-identifier is `n' itself, following this
each octet of the string is encoded in a separate sub-identifier);

(4) object identifier-valued (when preceded by the IMPLIED keyword):
`n' sub-identifiers, where `n' is the number of sub-identifiers
the value (each sub-identifier of the value is copied into
separate sub-identifier);

(5) object identifier-valued (when not preceded by the
keyword): `n+1' sub-identifiers, where `n' is the number of sub
identifiers in the value (the first sub-identifier is `n' itself
following this, each sub-identifier in the value is copied);

(6) IpAddress-valued: 4 sub-identifiers, in the familiar a.b.c.
notation

Note that the IMPLIED keyword can only be present for an
having a variable-length syntax (e.g., variable-length strings
object identifier-valued objects), Further, the IMPLIED keyword
only be associated with the last object in the INDEX clause
Finally, the IMPLIED keyword may not be used on a variable-
string object if that string might have a value of zero-length

Since a single value of a Counter has (in general) no
content (see section 7.1.6 and 7.1.10), objects defined using
syntax, Counter32 or Counter64, must not be specified in an

clause. If an object defined using the BITS construct is used in
INDEX clause, it is considered a variable-length string

Instances identified by use of integer-valued objects should
numbered starting from one (i.e., not from zero). The use of zero
a value for an integer-valued index object should be avoided,
in special cases

Objects which are both specified in the INDEX clause of a
row and also columnar objects of the same conceptual row are
auxiliary objects. The MAX-ACCESS clause for auxiliary objects
"not-accessible", except in the following circumstances

McCloghrie, et al. Standards Track [Page 28]

RFC 2578 SMIv2 April 1999

(1) within a MIB module originally written to conform to SMIv1,
later converted to conform to SMIv2;

(2) a conceptual row must contain at least one columnar object which
not an auxiliary object. In the event that all of a
row's columnar objects are also specified in its INDEX clause,
one of them must be accessible, i.e., have a MAX-ACCESS clause
"read-only". (Note that this situation does not arise for
conceptual row allowing create access, since such a row will have
status column which will not be an auxiliary object.)

Note that objects specified in a conceptual row's INDEX clause
not be columnar objects of that conceptual row. In this situation
the DESCRIPTION clause of the conceptual row must include a
explanation of how the objects which are included in the INDEX
but not columnar objects of that conceptual row, are used in
identifying instances of the conceptual row's columnar objects

7.8. Mapping of the AUGMENTS

The AUGMENTS clause, which must not be present unless the
corresponds to a conceptual row, is an alternative to the
clause. Every object corresponding to a conceptual row has either
INDEX clause or an AUGMENTS clause

If an object corresponding to a conceptual row has an INDEX clause
that row is termed a base conceptual row; alternatively, if
object has an AUGMENTS clause, the row is said to be a conceptual
augmentation, where the AUGMENTS clause names the
corresponding to the base conceptual row which is augmented by
conceptual row augmentation. (Thus, a conceptual row
cannot itself be augmented.) Instances of subordinate
objects of a conceptual row augmentation are identified according
the INDEX clause of the base conceptual row corresponding to
object named in the AUGMENTS clause. Further, instances
subordinate columnar objects of a conceptual row augmentation
according to the same semantics as instances of subordinate
objects of the base conceptual row being augmented. As such,
that creation of a base conceptual row implies the
creation of any conceptual row augmentations

For example, a MIB designer might wish to define additional
in an "enterprise-specific" MIB which logically extend a
row in a "standard" MIB. The "standard" MIB definition of
conceptual row would include the INDEX clause and the "enterprise
specific" MIB would contain the definition of a conceptual row
the AUGMENTS clause. On the other hand, it would be incorrect to
the AUGMENTS clause for the relationship between RFC 2233's

McCloghrie, et al. Standards Track [Page 29]

RFC 2578 SMIv2 April 1999

and the many media-specific MIBs which extend it for specific
(e.g., the dot3Table in RFC 2358), since not all interfaces are
the same media

Note that a base conceptual row may be augmented by
conceptual row augmentations

7.8.1. Relation between INDEX and AUGMENTS

When defining instance identification information for a
table

(1) If there is a one-to-one correspondence between the conceptual
of this table and an existing table, then the AUGMENTS
should be used

(2) Otherwise, if there is a sparse relationship between the
rows of this table and an existing table, then an INDEX
should be used which is identical to that in the existing table
For example, the relationship between RFC 2233's ifTable and
media-specific MIB which extends the ifTable for a specific
(e.g., the dot3Table in RFC 2358), is a sparse relationship

(3) Otherwise, if no existing objects have the required syntax
semantics, then auxiliary objects should be defined within
conceptual row for the new table, and those objects should be
within the INDEX clause for the conceptual row

7.9. Mapping of the DEFVAL

The DEFVAL clause, which need not be present, defines an
default value which may be used at the discretion of an agent when
object instance is created. That is, the value is a "hint"
implementors

During conceptual row creation, if an instance of a columnar
is not present as one of the operands in the correspondent
protocol set operation, then the value of the DEFVAL clause,
present, indicates an acceptable default value that an agent
use (especially for a read-only object).

Note that with this definition of the DEFVAL clause, it
appropriate to use it for any columnar object of a read-create table
It is also permitted to use it for scalar objects dynamically
by an agent, or for columnar objects of a read-write
dynamically created by an agent

McCloghrie, et al. Standards Track [Page 30]

RFC 2578 SMIv2 April 1999

The value of the DEFVAL clause must, of course, correspond to
SYNTAX clause for the object. If the value is an OBJECT IDENTIFIER
then it must be expressed as a single ASN.1 identifier, and not as
collection of sub-identifiers

Note that if an operand to the management protocol set operation
an instance of a read-only object, then the error `notWritable' [6]
will be returned. As such, the DEFVAL clause can be used to
an acceptable default value that an agent might use

By way of example, consider the following possible DEFVAL clauses

ObjectSyntax DEFVAL
---------------- ------------
Integer32 DEFVAL { 1 }
-- same for Gauge32, TimeTicks, Unsigned32
INTEGER DEFVAL { valid } -- enumerated
OCTET STRING DEFVAL { 'ffffffffffff'H }
DisplayString DEFVAL { "SNMP agent" }
IpAddress DEFVAL { 'c0210415'H } -- 192.33.4.21
OBJECT IDENTIFIER DEFVAL { sysDescr }
BITS DEFVAL { { primary, secondary } }
-- enumerated values that are
BITS DEFVAL { { } }
-- no enumerated values are

A binary string used in a DEFVAL clause for an OCTET STRING must
either an integral multiple of eight or zero bits in length
similarly, a hexadecimal string must be an even number of
digits. The value of a character string used in a DEFVAL clause
not contain tab characters or line terminator characters

Object types with SYNTAX of Counter32 and Counter64 may not
DEFVAL clauses, since they do not have defined initial values
However, it is recommended that they be initialized to zero

7.10. Mapping of the OBJECT-TYPE

The value of an invocation of the OBJECT-TYPE macro is the name
the object, which is an OBJECT IDENTIFIER, an
assigned name

When an OBJECT IDENTIFIER is assigned to an object

(1) If the object corresponds to a conceptual table, then only a
assignment, that for a conceptual row, is present
beneath that object. The administratively assigned name for
conceptual row object is derived by appending a sub-identifier

McCloghrie, et al. Standards Track [Page 31]

RFC 2578 SMIv2 April 1999

"1" to the administratively assigned name for the conceptual table

(2) If the object corresponds to a conceptual row, then at least