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