| 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. |
