Initial commit
This commit is contained in:
707
MIBS/bdcom/BDCOM-TC
Normal file
707
MIBS/bdcom/BDCOM-TC
Normal file
@ -0,0 +1,707 @@
|
||||
-- *****************************************************************
|
||||
-- BDCOM-TC.my: BDCOM MIB Textual Conventions
|
||||
--
|
||||
-- October 2003
|
||||
--
|
||||
-- Copyright (c) 2003 by BDCOM, Inc.
|
||||
-- All rights reserved.
|
||||
--
|
||||
-- *****************************************************************
|
||||
--
|
||||
|
||||
BDCOM-TC DEFINITIONS ::= BEGIN
|
||||
|
||||
IMPORTS
|
||||
MODULE-IDENTITY,
|
||||
Unsigned32, Gauge32,
|
||||
Integer32,
|
||||
Counter64
|
||||
FROM SNMPv2-SMI
|
||||
TEXTUAL-CONVENTION
|
||||
FROM SNMPv2-TC
|
||||
bdcomModules
|
||||
FROM BDCOM-SMI;
|
||||
|
||||
|
||||
bdcomTextualConventions MODULE-IDENTITY
|
||||
LAST-UPDATED "200310160000Z"
|
||||
ORGANIZATION "BDCOM, Inc."
|
||||
CONTACT-INFO
|
||||
" Tel: +86-21-50800666
|
||||
Postal: No.123,Juli RD,Zhangjiang Hitech Park,
|
||||
Shanghai Baud Data Communication Corporation Inc,
|
||||
Shanghai City 201203,
|
||||
P.R.C "
|
||||
DESCRIPTION
|
||||
"This module defines textual conventions used throughout
|
||||
bdcom enterprise mibs."
|
||||
REVISION "200310160000Z"
|
||||
DESCRIPTION
|
||||
"Initial version of this MIB."
|
||||
::= { bdcomModules 1 }
|
||||
|
||||
|
||||
BDCOMNetworkProtocol ::= TEXTUAL-CONVENTION
|
||||
STATUS current
|
||||
DESCRIPTION
|
||||
"Represents the different types of network layer protocols."
|
||||
-- internal note: enumerations must match those in address.h
|
||||
SYNTAX INTEGER {
|
||||
ip (1),
|
||||
decnet (2),
|
||||
pup (3),
|
||||
chaos (4),
|
||||
xns (5),
|
||||
x121 (6),
|
||||
appletalk (7),
|
||||
clns (8),
|
||||
lat (9),
|
||||
vines (10),
|
||||
cons (11),
|
||||
apollo (12),
|
||||
stun (13),
|
||||
novell (14),
|
||||
qllc (15),
|
||||
snapshot (16),
|
||||
atmIlmi (17),
|
||||
bstun (18),
|
||||
x25pvc (19),
|
||||
ipv6 (20), -- IP version 6
|
||||
cdm (21), -- Cable Data Modem
|
||||
nbf (22), -- NetBIOS
|
||||
bpxIgx (23), -- BGP/IGX
|
||||
clnsPfx(24), -- ISO 8473 CLNS NSAP
|
||||
http(25),
|
||||
unknown (65535)
|
||||
}
|
||||
|
||||
BDCOMNetworkAddress ::= TEXTUAL-CONVENTION
|
||||
DISPLAY-HINT "1x:"
|
||||
STATUS current
|
||||
DESCRIPTION
|
||||
"Represents a network layer address. The length and format of
|
||||
the address is protocol dependent as follows:
|
||||
ip 4 octets
|
||||
decnet 2 octets
|
||||
pup obsolete
|
||||
chaos 2 octets
|
||||
xns 10 octets
|
||||
first 4 octets are the net number
|
||||
last 6 octets are the host number
|
||||
x121
|
||||
appletalk 3 octets
|
||||
first 2 octets are the net number
|
||||
last octet is the host number
|
||||
clns
|
||||
lat
|
||||
vines 6 octets
|
||||
first 4 octets are the net number
|
||||
last 2 octets are the host number
|
||||
cons
|
||||
apollo 10 octets
|
||||
first 4 octets are the net number
|
||||
last 6 octets are the host number
|
||||
stun 8 octets
|
||||
novell 10 octets
|
||||
first 4 octets are the net number
|
||||
last 6 octets are the host number
|
||||
qllc 6 octets
|
||||
bstun 1 octet - bi-sync serial tunnel
|
||||
snapshot 1 octet
|
||||
atmIlmi 4 octets
|
||||
x25 pvc 2 octets (12 bits)
|
||||
ipv6 16 octets
|
||||
cdm
|
||||
nbf
|
||||
bgpIgx
|
||||
clnsPfx upto 20 octets
|
||||
http upto 70 octets
|
||||
first 4 octets are the IPv4 host
|
||||
address
|
||||
next 2 octets are the TCP port
|
||||
number
|
||||
remaining(1 upto 64) octets are
|
||||
the URI
|
||||
"
|
||||
SYNTAX OCTET STRING
|
||||
|
||||
--SMI Unsigned32
|
||||
--Unsigned32 ::= TEXTUAL-CONVENTION
|
||||
-- STATUS current
|
||||
-- DESCRIPTION
|
||||
-- "An unsigned 32-bit quantity indistinguishable from Gauge32."
|
||||
-- SYNTAX Gauge32
|
||||
|
||||
Unsigned64 ::= TEXTUAL-CONVENTION
|
||||
STATUS current
|
||||
DESCRIPTION
|
||||
"An unsigned 64 bit integer. We use SYNTAX Counter64 for the
|
||||
encoding rules."
|
||||
SYNTAX Counter64
|
||||
|
||||
InterfaceIndexOrZero ::= TEXTUAL-CONVENTION
|
||||
DISPLAY-HINT "d"
|
||||
STATUS current
|
||||
DESCRIPTION
|
||||
"Either the value 0, or the ifIndex value of an
|
||||
interface in the ifTable."
|
||||
SYNTAX Integer32 (0..2147483647)
|
||||
|
||||
SAPType ::= TEXTUAL-CONVENTION
|
||||
DISPLAY-HINT "d"
|
||||
STATUS current
|
||||
DESCRIPTION
|
||||
"Service Access Point - is a term that denotes the means
|
||||
by which a user entity in layer n+1 accesses a service
|
||||
of a provider entity in layer n."
|
||||
SYNTAX Integer32 (0..254)
|
||||
|
||||
CountryCode ::= TEXTUAL-CONVENTION
|
||||
DISPLAY-HINT "2a"
|
||||
STATUS current
|
||||
DESCRIPTION
|
||||
"Represents a case-insensitive 2-letter country code taken
|
||||
from ISO-3166. Unrecognized countries are represented as
|
||||
empty string."
|
||||
SYNTAX OCTET STRING (SIZE (0 | 2))
|
||||
|
||||
CountryCodeITU ::= TEXTUAL-CONVENTION
|
||||
DISPLAY-HINT "d"
|
||||
STATUS current
|
||||
DESCRIPTION
|
||||
"This textual convention represents a country or area code for
|
||||
non-standard facilities in telematic services."
|
||||
REFERENCE
|
||||
"ITU-T T.35 - Section 3.1 Country Code"
|
||||
SYNTAX Unsigned32 (0..255)
|
||||
|
||||
EntPhysicalIndexOrZero ::= TEXTUAL-CONVENTION
|
||||
STATUS current
|
||||
DESCRIPTION
|
||||
"This textual convention is an extension of entPhysicalIndex.
|
||||
If non-zero, the object is an entPhysicalIndex. If zero, no
|
||||
appropriate entPhysicalIndex exists. Any additional semantics
|
||||
are object specific."
|
||||
SYNTAX Integer32 (0..2147483647)
|
||||
|
||||
BDCOMRowOperStatus ::= TEXTUAL-CONVENTION
|
||||
STATUS current
|
||||
DESCRIPTION
|
||||
"Represents the operational status of an table entry.
|
||||
This textual convention allows explicitly representing
|
||||
the states of rows dependent on rows in other tables.
|
||||
|
||||
active(1) -
|
||||
Indicates this entry's RowStatus is active
|
||||
and the RowStatus for each dependency is active.
|
||||
|
||||
activeDependencies(2) -
|
||||
Indicates that the RowStatus for each dependency
|
||||
is active, but the entry's RowStatus is not active.
|
||||
|
||||
inactiveDependency(3) -
|
||||
Indicates that the RowStatus for at least one
|
||||
dependency is not active.
|
||||
|
||||
missingDependency(4) -
|
||||
Indicates that at least one dependency does
|
||||
not exist in it's table.
|
||||
"
|
||||
SYNTAX INTEGER {
|
||||
active(1),
|
||||
activeDependencies(2),
|
||||
inactiveDependency(3),
|
||||
missingDependency(4)
|
||||
}
|
||||
|
||||
BDCOMPort ::= TEXTUAL-CONVENTION
|
||||
STATUS current
|
||||
DESCRIPTION
|
||||
"The TCP or UDP port number range."
|
||||
REFERENCE
|
||||
"Transmission Control Protocol. J. Postel. RFC793,
|
||||
User Datagram Protocol. J. Postel. RFC768"
|
||||
SYNTAX Integer32 ( 0..65535 )
|
||||
|
||||
BDCOMIpProtocol ::= TEXTUAL-CONVENTION
|
||||
STATUS current
|
||||
DESCRIPTION
|
||||
"IP protocol number range."
|
||||
REFERENCE
|
||||
"Internet Protocol. J. Postel. RFC791"
|
||||
SYNTAX Integer32 ( 0..255 )
|
||||
|
||||
|
||||
|
||||
BDCOMLocationClass ::= TEXTUAL-CONVENTION
|
||||
STATUS current
|
||||
DESCRIPTION
|
||||
"An enumerated value which provides an indication of
|
||||
the general location type of a particular physical and/or
|
||||
logical interface.
|
||||
chassis - a system framework for mounting one or more
|
||||
shelves/slots/cards.
|
||||
shelf - a cabinet that holds one or more slots.
|
||||
slot - card or subSlot holder.
|
||||
subSlot - daughter-card holder.
|
||||
port - a physical port (e.g., a DS1 or DS3 physical port).
|
||||
subPort - a logical port on a physical port (e.g., a DS1
|
||||
subPort on a DS3 physical port).
|
||||
channel - a logical interface (e.g., a DS0 channel, signalling
|
||||
channel, ATM port, other virtual interfaces).
|
||||
subChannel - a sub-channel on a logical interface.
|
||||
"
|
||||
SYNTAX INTEGER {
|
||||
chassis(1),
|
||||
shelf(2),
|
||||
slot(3),
|
||||
subSlot(4),
|
||||
port(5),
|
||||
subPort(6),
|
||||
channel(7),
|
||||
subChannel(8)
|
||||
}
|
||||
|
||||
BDCOMLocationSpecifier ::= TEXTUAL-CONVENTION
|
||||
STATUS current
|
||||
DESCRIPTION
|
||||
"Use this TC to define objects that indicate the
|
||||
physical entity and/or logical interface location
|
||||
of a managed entity on a managed device. In SNMP, a
|
||||
standard mechanism for indicating the physical location
|
||||
of entities is via the ENTITY-MIB. However, that approach
|
||||
is not satisfactory in some cases because:
|
||||
|
||||
1. The entity requiring a location-based naming may be
|
||||
associated with an entity which can not be represented
|
||||
as a physical entity in the ENTITY-MIB,
|
||||
2. NMS applications may desire a more direct
|
||||
name/representation of a physical entity than is
|
||||
available via the ENTITY-MIB, e.g., a physical entity
|
||||
which is named via a hierarchy of levels in the ENTITY-MIB.
|
||||
|
||||
The value of an object defined using this TC is an ASCII
|
||||
string consisting of zero or more elements separated by
|
||||
commas. Each element is of the form <tag> = <value>.
|
||||
|
||||
An example of this syntax is 'slot=5,port=3'.
|
||||
|
||||
The syntax of the string is formally specified using
|
||||
ABNF notation (with one exception, noted below), as
|
||||
follows:
|
||||
|
||||
location-specifier = elem *(',' elem)
|
||||
; subject to
|
||||
; size restriction specified in the SYNTAX
|
||||
; clause below
|
||||
|
||||
elem = loctype '=' number
|
||||
|
||||
number = %x00-FFFFFFFF / %d0-4294967295
|
||||
|
||||
loctype = 1*32VCHAR
|
||||
|
||||
It is recommended that loctype use one of the enumerated
|
||||
labels defined for BDCOMLocationClass.
|
||||
|
||||
(NOTE: To conform to ABNF notation as defined in RFC2234,
|
||||
substitute the single-quote symbol with a double-quote
|
||||
symbol in the above rules.)
|
||||
|
||||
A zero length of BDCOMLocationSpecifier is object-specific
|
||||
and must be defined as part of the description of any object
|
||||
which uses this syntax.
|
||||
"
|
||||
REFERENCE
|
||||
"RFC2234, Augmented BNF for syntax specifications: ABNF"
|
||||
|
||||
SYNTAX OCTET STRING (SIZE (0..255))
|
||||
|
||||
BDCOMInetAddressMask ::= TEXTUAL-CONVENTION
|
||||
STATUS current
|
||||
DESCRIPTION
|
||||
"Denotes a generic Internet subnet address mask.
|
||||
The Internet subnet address mask is represented as the
|
||||
number of contiguous 1-bit from MSB (most significant bit)
|
||||
of the Internet subnet address mask.
|
||||
A BDCOMInetAddressMask value is always interpreted within
|
||||
the context of an InetAddressType value. The
|
||||
InetAddressType only object or InetAddressType with
|
||||
InetAddress objects which define the context must be
|
||||
registered immediately before the object which uses the
|
||||
BDCOMInetAddressMask textual convention. In other words,
|
||||
the object identifiers for the InetAddressType object and
|
||||
the BDCOMInetAddressMask object MUST have the same length
|
||||
and the last sub-identifier of the InetAddressType object
|
||||
MUST be 1 less than the last sub-identifier of the
|
||||
BDCOMInetAddressMask object and MUST be 2 less than the
|
||||
last sub-identifier of the BDCOMInetAddressMask object if
|
||||
an InetAddress object is defined between InetAddressType
|
||||
and BDCOMInetAddressMask objects.
|
||||
The maximum value of the BDCOMInetAddressMask TC is 32 for
|
||||
the value 'ipv4(1)' in InetAddressType object and 128 for
|
||||
the value 'ipv6(2)' in InetAddressType object.
|
||||
The value zero is object-specific and must therefore be
|
||||
defined as part of the description of any object which
|
||||
uses this syntax. Examples of the usage of zero might
|
||||
include situations where Internet subnet mask was unknown,
|
||||
or when none subnet masks need to be referenced."
|
||||
|
||||
REFERENCE
|
||||
"RFC2851, Textual Conventions for Internet Network Addresses."
|
||||
|
||||
SYNTAX Unsigned32 (0..128)
|
||||
|
||||
BDCOMAbsZeroBasedCounter32 ::= TEXTUAL-CONVENTION
|
||||
STATUS current
|
||||
DESCRIPTION
|
||||
"This TC describes an object which counts events with the
|
||||
following semantics: objects of this type will be set to
|
||||
zero(0) on creation and will thereafter count appropriate
|
||||
events, it locks at the maximum value of 4,294,967,295 if
|
||||
the counter overflows.
|
||||
This TC may be used only in situations where wrapping is
|
||||
not possible or extremely unlikely situation."
|
||||
SYNTAX Gauge32
|
||||
|
||||
BDCOMSnapShotAbsCounter32 ::= TEXTUAL-CONVENTION
|
||||
STATUS current
|
||||
DESCRIPTION
|
||||
"This TC describes an object which stores a snap-shot value
|
||||
with the following semantics: objects of this type will
|
||||
take a snap-shot value from their associated
|
||||
BDCOMAbsZeroBasedCounter32 type objects on creation."
|
||||
SYNTAX Unsigned32
|
||||
|
||||
BDCOMAlarmSeverity ::= TEXTUAL-CONVENTION
|
||||
STATUS current
|
||||
DESCRIPTION
|
||||
"Represents the perceived alarm severity associated
|
||||
with a service or safety affecting condition and/or
|
||||
event. These are based on ITU severities, except
|
||||
that info(7) is added.
|
||||
|
||||
cleared(1) -
|
||||
Indicates a previous alarm condition has been
|
||||
cleared. It is not required (unless specifically
|
||||
stated elsewhere on a case by case basis) that an
|
||||
alarm condition that has been cleared will produce
|
||||
a notification or other event containing an
|
||||
alarm severity with this value.
|
||||
|
||||
indeterminate(2) -
|
||||
Indicates that the severity level cannot be
|
||||
determined.
|
||||
|
||||
critical(3) -
|
||||
Indicates that a service or safety affecting
|
||||
condition has occurred and an immediate
|
||||
corrective action is required.
|
||||
|
||||
major(4) -
|
||||
Indicates that a service affecting condition has
|
||||
occurred and an urgent corrective action is
|
||||
required.
|
||||
|
||||
minor(5) -
|
||||
Indicates the existence of a non-service affecting
|
||||
condition and that corrective action should be
|
||||
taken in order to prevent a more serious (for
|
||||
example, service or safety affecting) condition.
|
||||
|
||||
warning(6) -
|
||||
Indicates the detection of a potential or impending
|
||||
service or safety affecting condition, before any
|
||||
significant effects have been felt.
|
||||
|
||||
info(7) -
|
||||
Indicates an alarm condition that does not
|
||||
meet any other severity definition. This can
|
||||
include important, but non-urgent, notices or
|
||||
informational events.
|
||||
"
|
||||
REFERENCE
|
||||
"ITU-X.733"
|
||||
SYNTAX INTEGER {
|
||||
cleared(1),
|
||||
indeterminate(2),
|
||||
critical(3),
|
||||
major(4),
|
||||
minor(5),
|
||||
warning(6),
|
||||
info(7)
|
||||
}
|
||||
|
||||
|
||||
PerfHighIntervalCount ::= TEXTUAL-CONVENTION
|
||||
STATUS current
|
||||
DESCRIPTION
|
||||
"A 64 bit counter associated with a
|
||||
performance measurement in a previous
|
||||
15 minute measurement interval. In the
|
||||
case where the agent has no valid data
|
||||
available for a particular interval the
|
||||
corresponding object instance is not
|
||||
available and upon a retrieval request
|
||||
a corresponding error message shall be
|
||||
returned to indicate that this instance
|
||||
does not exist (for example, a noSuchName
|
||||
error for SNMPv1 and a noSuchInstance for
|
||||
SNMPv2 GET operation).
|
||||
In a system supporting
|
||||
a history of n intervals with
|
||||
IntervalCount(1) and IntervalCount(n) the
|
||||
most and least recent intervals
|
||||
respectively, the following applies at
|
||||
the end of a 15 minute interval:
|
||||
- discard the value of IntervalCount(n)
|
||||
- the value of IntervalCount(i) becomes that
|
||||
of IntervalCount(i-1) for n >= i > 1
|
||||
- the value of IntervalCount(1) becomes that
|
||||
of CurrentCount
|
||||
- the TotalCount, if supported, is adjusted.
|
||||
|
||||
This definition is based on CounterBasedGauge64 TEXTUAL
|
||||
CONVENTION defined in RFC2856. The PerfHighIntervalCount
|
||||
type represents a non-negative
|
||||
integer, which may increase or decrease, but shall never
|
||||
exceed a maximum value, nor fall below a minimum value. The
|
||||
maximum value can not be greater than 2^64-1
|
||||
(18446744073709551615 decimal), and the minimum value can
|
||||
not be smaller than 0. The value of a PerfHighIntervalCount,
|
||||
has its maximum value whenever the information being modeled
|
||||
is greater than or equal to its maximum value, and has its
|
||||
minimum value whenever the information being modeled is
|
||||
smaller than or equal to its minimum value. If the
|
||||
information being modeled subsequently decreases below
|
||||
(increases above) the maximum (minimum) value, the
|
||||
PerfHighIntervalCount also decreases (increases).
|
||||
|
||||
Note that this TC is not strictly supported in SMIv2,
|
||||
because the 'always increasing' and 'counter wrap' semantics
|
||||
associated with the Counter64 base type are not preserved.
|
||||
It is possible that management applications which rely
|
||||
solely upon the (Counter64) ASN.1 tag to determine object
|
||||
semantics will mistakenly operate upon objects of this type
|
||||
as they would for Counter64 objects.
|
||||
|
||||
This textual convention represents a limited and short-term
|
||||
solution, and may be deprecated as a long term solution is
|
||||
defined and deployed to replace it."
|
||||
REFERENCE
|
||||
"RFC 2856(HCNUM-TC MIB).
|
||||
RFC 2493(PerfHist-TC-MIB)."
|
||||
SYNTAX Counter64
|
||||
|
||||
ConfigIterator ::= TEXTUAL-CONVENTION
|
||||
STATUS current
|
||||
DESCRIPTION
|
||||
"This object type is a control object type which applies to
|
||||
writable objects in the same SNMP PDU related to the
|
||||
same table containing those objects. It controls an
|
||||
operation which repeatedly applies the specified
|
||||
configuration data to more than one rows in a table.
|
||||
The operation starts from the row specified by the index
|
||||
of the instance and repeats for the number of rows as
|
||||
the value of the object.
|
||||
|
||||
ConfigIterator object needs to be accompanied by one set of
|
||||
writable objects which are of the same instance to apply to.
|
||||
|
||||
For example, a SNMP PDU contains
|
||||
{ objectA.10 = 1,
|
||||
objectB.10 = 'E1',
|
||||
objectC.10 = 44,
|
||||
objectRepetition.10 = 100 }
|
||||
|
||||
The SYNTAX of objectRepetition is ConfigIterator.
|
||||
This will apply value 1 to objectA, value 'E1' to objectB,
|
||||
value 44 to objectC in the table starting from row 10
|
||||
repeatedly for 100 rows.
|
||||
|
||||
The iteration is based on the number of rows, not based on
|
||||
the value of the index. For sparse tables, the index 10,
|
||||
20, 30, 110, and 120 counts for 5 rows, the operation will
|
||||
go beyond index 100 in the previous SNMP PDU example.
|
||||
|
||||
The iteration will stop prematurely when it comes to the
|
||||
following situations:
|
||||
(1) When the number of the rows in the table is less than
|
||||
the designated row indicated by the ConfigIterator
|
||||
object.
|
||||
(2) When it encounters the first error in any row, the
|
||||
operation won't continue to next row.
|
||||
|
||||
The operation of ConfigIterator object applies only to
|
||||
the writable objects having the same index as the
|
||||
ConfigIterator object in one SNMP PDU.
|
||||
|
||||
For example, a SNMP PDU contains
|
||||
{ objectD.5 = 38,
|
||||
objectE.6 = 'T1',
|
||||
objectF.5 = 'false',
|
||||
objectIterator.5 = 10 }
|
||||
|
||||
The SYNTAX of objectIterator is ConfigIterator.
|
||||
This will apply value 38 to objectD, value 'false' to
|
||||
objectF in the table starting from row 5 repeatedly
|
||||
for 10 rows. Since the object objectE.6 has different
|
||||
index (6) from the index of objectIterator, the
|
||||
repetition won't be applied to it. However the value
|
||||
of objectE in the row 6 will be set to 'T1' according
|
||||
to regular SNMP SET orperation.
|
||||
|
||||
If there is row overlapping of the iteration in a SNMP PDU,
|
||||
it will be operated as they are in two different SNMP PDUs.
|
||||
|
||||
For example, a SNMP PDU contains
|
||||
{ objectD.5 = 38,
|
||||
objectD.6 = 40,
|
||||
objectE.6 = 'T1',
|
||||
objectF.5 = 'false',
|
||||
objectIterator.5 = 10
|
||||
objectIterator.6 = 10 }
|
||||
|
||||
This will apply value 38 to objectD, value 'false' to
|
||||
objectF starting from row 5 repeatedly for 10 rows, and
|
||||
apply value 40 to objectD, value 'T1' to objectE starting
|
||||
from row 6 repeatedly for 10 rows. The final value of
|
||||
objectD.6 can be 38 or 40, it depends on the SNMP stack of
|
||||
the system starts SNMP SET for the row 5 before the row 6
|
||||
or the other way around.
|
||||
|
||||
The object defined as ConfigIterator will be set to value 1
|
||||
after the iteration operation is kick-off regardless the
|
||||
system has completed the operation to the designated rows
|
||||
or not. Therefore retrieving the value of this object
|
||||
is meaningless. It acts as the one time operation for
|
||||
bulk configuration.
|
||||
|
||||
The object defined as ConfigIterator has no meaning by itself,
|
||||
it has to be combined with one or more than one writable
|
||||
objects from the same table and within the same SNMP PDU
|
||||
for the repetition operation.
|
||||
|
||||
For example, a SNMP PDU contains
|
||||
{ objectG.2 = 49,
|
||||
objectH.2 = 'AE'h
|
||||
objectIterator.4 = 20 }
|
||||
|
||||
The SYNTAX of objectIterator is ConfigIterator. Since
|
||||
there are no objects having the same index as the index
|
||||
of objectIterator in the PDU, the result of this SNMP
|
||||
operation will set value 49 to objectG and value 0xAE
|
||||
to objectH of the row 2 only as regular SNMP SET operation.
|
||||
|
||||
The index of the instance indicates the starting row for the
|
||||
iteration.
|
||||
The order of the iteration depends, for instance, on:
|
||||
(1) physical hardware position, or
|
||||
(2) logical index.
|
||||
|
||||
It depends on the characters of the table which contains
|
||||
the ConfigIterator object.
|
||||
|
||||
Iteration can be done through some or all the components
|
||||
of the index for a table. The description of the iterator
|
||||
object in that table should describe which part of the
|
||||
index the iteration is applied to.
|
||||
|
||||
The operation for this object type is based on the best
|
||||
effort. When the agent receives a SNMP PDU containing this
|
||||
data type, the return status of the SNMP request reflects
|
||||
only the result of the SET operation has applied to the
|
||||
starting row. It may return a SNMP response with SUCCESS
|
||||
status regardless the number of rows for the data actually
|
||||
been deployed later on. Therefore it is possible the data
|
||||
might not be completely deployed to the number of rows
|
||||
designated by the ConfigIterator and the operation stops
|
||||
prematurely due to an error it first encounters after
|
||||
n rows (n < the value of ConfigIterator object).
|
||||
|
||||
Usually the error report mechanism for this type of operation
|
||||
is accomplished by combining this type of object with the
|
||||
other two objects in the same table:
|
||||
|
||||
(1) An OwnerString object
|
||||
(2) An object indicates the result of the operation.
|
||||
|
||||
When issuing this bulk configuration request, the SNMP
|
||||
manager should provide its identifier in (1) object.
|
||||
After issuing the request, it should check the value of (1)
|
||||
object if it is the same with it own name.
|
||||
If they are the same, then the value of the object presents
|
||||
in (2) is the result from the previous operation from this
|
||||
manager. Otherwise, another SNMP manager might issue
|
||||
the bulk configuration to the same table before the previous
|
||||
bulk operation has been completed. These two objects will
|
||||
represent the last bulk operation in the table.
|
||||
"
|
||||
SYNTAX Unsigned32 (1..4294967295)
|
||||
|
||||
BulkConfigResult ::= TEXTUAL-CONVENTION
|
||||
STATUS current
|
||||
DESCRIPTION
|
||||
"This textual convention defines the format of the
|
||||
displayable textual result from the bulk configuration
|
||||
operation specified as ConfigIterator type.
|
||||
|
||||
The format should be:
|
||||
'COMPLETION=<number of rows had completed before any
|
||||
error occured>/<number of rows was designated>,
|
||||
ERROR=<error code>/<index where the error occured>:
|
||||
<error text>'
|
||||
|
||||
For example:
|
||||
'COMPLETION=22/100,ERROR=38/44:Invalid Ds1 line coding
|
||||
for the line type'
|
||||
"
|
||||
SYNTAX OCTET STRING (SIZE(0..255))
|
||||
|
||||
ListIndex ::= TEXTUAL-CONVENTION
|
||||
DISPLAY-HINT "d"
|
||||
STATUS current
|
||||
DESCRIPTION
|
||||
"A unique value greater than zero, for each of the
|
||||
list that is defined. The object using this
|
||||
convention should give all the object specific
|
||||
details including the list type."
|
||||
SYNTAX Integer32 (1..2147483647)
|
||||
|
||||
ListIndexOrZero ::= TEXTUAL-CONVENTION
|
||||
DISPLAY-HINT "d"
|
||||
STATUS current
|
||||
DESCRIPTION
|
||||
"This textual convention is an extension of the
|
||||
ListIndex. In addition to the ListIndex range,
|
||||
this also includes 0 in its range of values.
|
||||
This value could be object specific and
|
||||
should be given the description of that object.
|
||||
In most cases, a value 0 means that the it does
|
||||
not represent any lists."
|
||||
SYNTAX Integer32 (0..2147483647)
|
||||
|
||||
TimeIntervalSec ::= TEXTUAL-CONVENTION
|
||||
STATUS current
|
||||
DESCRIPTION
|
||||
"A period of time, measured in units of 1 second."
|
||||
SYNTAX Unsigned32
|
||||
|
||||
TimeIntervalMin ::= TEXTUAL-CONVENTION
|
||||
STATUS current
|
||||
DESCRIPTION
|
||||
"A period of time, measured in units of 1 minute."
|
||||
SYNTAX Unsigned32
|
||||
|
||||
BDCOMMilliSeconds ::= TEXTUAL-CONVENTION
|
||||
STATUS current
|
||||
DESCRIPTION
|
||||
"Represents time unit value in milliseconds."
|
||||
SYNTAX Unsigned32
|
||||
|
||||
MicroSeconds ::= TEXTUAL-CONVENTION
|
||||
STATUS current
|
||||
DESCRIPTION
|
||||
"Represents time unit value in microseconds."
|
||||
SYNTAX Unsigned32
|
||||
END
|
Reference in New Issue
Block a user