MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY
                                        FROM SNMPv2-SMI
                                          -- RFC 2578
OBJECT-GROUP, MODULE-COMPLIANCE
                                        FROM SNMPv2-CONF
                                          -- RFC 2580
SnmpAdminString
                                        FROM SNMP-FRAMEWORK-MIB
                                          -- RFC 3411
fdGlobalMIB, fdAdminGlobal, fdGlobalConformance
                                        FROM ISO26048-1-Global

This MIB defines a transaction mode that allows an SNMP manager to place the device into a mode where the SNMP agent buffers all set requests for configuration parameters until the SNMP manager completes the transaction. This allows an SNMP manager to configure a large number of inter-related parameters as if they were all contained in a single request and consistency checks are only performed on the complete set of updated values thereby eliminating potential consistency errors resulting from partial update conditions. Copyright (C) International Organization for Standardization (ISO). This MIB module is part of ISO 26048-1; see ISO 26048-1 for full legal notices.

<Definition> A node used to contain conformance concepts for the transaction feature.

<Definition> This object allows a user with sufficient rights to force the dbCreateTransactionV2 object back to the 'normal' state.

<Format> An attempt to set this object to 'normal' shall cause Step 6 of RFC 3416 Clause 4.2.5 to fail, thereby resulting in a 'wrongValue' error. An attempt to set this object to 'reset' when the dbCreateTransactionV2 is in the process of implementing the buffer while shifting from the 'done' state to the 'normal' state shall cause Step 10 of RFC 3416 Clause 4.2.5 to fail, thereby resulting in an 'inconsistentValue' error. An attempt to set this object to 'reset' when the dbCreateTransactionV2 is in the 'verify' state shall cause Step 10 of RFC 3416 Clause 4.2.5 to fail, thereby resulting in an 'inconsistentValue' error. Phase 2 of the set operation shall include discarding any information that is in the buffer.

<Definition> This object allows a manager (through its command generator) to modify a potentially large number of interrelated configuration parameters within a field device (through its command responder). In the normal state, set operations are processed without any special rules. In the transaction state, value assignments for parameter objects shall be buffered until the verify state performs a consistency check. When the consistency check completes, the command responder automatically transitions to the done state where a normal or transaction command may be issued. The normal state is the default state of this object upon initialization.

<Format> All writable objects shall be treated as control objects unless otherwise specified (e.g., within a MIB or device-type standard). This object is a control object.
Implementations shall not change the designation (e.g., control, parameter, or transaction) of any writable object type from that assigned in the standards to which it claims conformance.
The following rules are applied during the processing of SetRequest-PDUs as defined in RFC 3416 Clause 4.2.5:
NORMAL:
When this object is in the 'normal' state:
1. An attempt to set a transaction object shall cause Step 9 of RFC 3416 Clause 4.2.5 to fail, thereby resulting in a 'notWritable' error.
2. An attempt to set this object to any value other than 'transaction' shall cause Step 10 of RFC 3416 Clause 4.2.5 to fail, thereby resulting in an 'inconsistentValue' error.
3. When setting this object to 'transition', the second phase of the set operation shall include the command responder copying all the parameter objects currently stored in the device into a buffer. A failure of this copy operation shall result in a failure in the second phase of the set operation and thereby result in a 'commitFailed' error and this object remaining in the 'normal' state.
TRANSACTION: When this object is in the 'transaction' state:
1. An attempt to set a parameter object using a securityName other than the securityName that was used to start this transaction session shall cause Step 9 of RFC 3416 Clause 4.2.5 to fail, thereby resulting in a 'notWritable' error.
2. An attempt to set this object using a securityName other than the securityName that was used to start this transaction session shall cause Step 9 of RFC 3416 Clause 4.2.5 to fail, thereby resulting in a 'notWritable' error.
3. An attempt to set this object to any value other than 'normal' or 'verify' shall cause Step 10 of RFC 3416 Clause 4.2.5 to fail, thereby resulting in an 'inconsistentValue' error.
4. Within the second phase of the set operation, the command responder shall buffer the creation of and assignments to parameter objects rather than immediately implementing them.
5. Within the second phase of the set operation to set this object to 'normal', the agent shall discard all data in the transaction session buffer.
NOTE: Control and status objects are processed normally given the above constraints. For example, another securityName can be used to set a control object without error. However, if that request also includes a parameter object, an 'inconsistentValue' error will be generated and neither the control object nor the parameter object will be altered. If the securityName used to initiate the transaction session is used to request setting both a control and a parameter object in a single request, the control object is immediately implemented while the parameter object request is buffered. GetRequest-PDUs are not affected by transaction sessions; they return the values currently implemented while ignoring any buffered values.
VERIFY: Upon entry into the verify state, the command responder shall initiate the consistency check process.
When this object is in the 'verify' state:
1. An attempt to set a parameter object using a securityName other than the securityName that was used to start this transaction session shall cause Step 9 of RFC 3416 Clause 4.2.5 to fail, thereby resulting in a 'notWritable' error.
2. An attempt to set this object using a securityName other than the securityName that was used to start this transaction session shall cause Step 9 of RFC 3416 Clause 4.2.5 to fail, thereby resulting in a 'notWritable' error.
3. An attempt to set a parameter object shall cause Step 10 of RFC 3416 Clause 4.2.5 to fail, thereby resulting in an 'inconsistentValue' error.
4. An attempt to set this object to any value shall cause Step 10 of RFC 3416 Clause 4.2.5 to fail, thereby resulting in an 'inconsistentValue' error.
When consistency checks are complete the device shall update the values of dbVerifyStatusV2 and dbVerifyErrorV2 and automatically transition this object to the 'done' state.
DONE: When this object is in the 'done' state:
1. The value of dbVerifyStatusV2 and dbVerifyErrorV2 shall indicate whether the consistency checks found any errors.
2. An attempt to set a parameter object using a securityName other than the securityName that was used to start this transaction session shall cause Step 9 of RFC 3416 Clause 4.2.5 to fail, thereby resulting in a 'notWritable' error.
3. An attempt to set this object using a securityName other than the securityName that was used to start this transaction session shall cause Step 9 of RFC 3416 Clause 4.2.5 to fail, thereby resulting in a 'notWritable' error.
4. An attempt to set a parameter object shall cause Step 10 of RFC 3416 Clause 4.2.5 to fail, thereby resulting in an 'inconsistentValue' error.
5. An attempt to set this object to any value other than 'normal' or 'transaction' shall cause Step 10 of RFC 3416 Clause 4.2.5 to fail, thereby resulting in an 'inconsistentValue' error.
6. An attempt to set this object to any value when this object is in the process of implementing the buffer while shifting from the 'done' state to the 'normal' state shall cause Step 10 of RFC 3416 Clause 4.2.5 to fail, thereby resulting in an 'inconsistentValue' error.
7. An attempt to set this object to a value of 'transaction' shall cause the command responder to re-enter the 'transaction' state without affecting the contents of the buffer.
8. An attempt to set this object to a value of 'normal' when dbVerifyStatusV2 has a value of 'doneWithNoError' shall result in the second phase of the set operation including the assignment of all the buffered data to the device's parameter objects. Any failure in the assignment process shall result in a failure in the second phase of the set operation and thereby result in the Response-PDU indicating either a 'commitFailed' or 'undoFailed' error, as appropriate, and this object remaining in the 'done' state. The values of dbVerifyStatusV2 and dbVerifyErrorV2 shall be updated at the end of the operation as appropriate.
9. An attempt to set this object to a value of 'normal' when dbVerifyStatusV2 has a value other than 'doneWithNoError' shall result in the transaction buffer being discarded during the second phase of the set operation.
Usage
Consistency checks are intended to analyze parameter objects 'in context' by treating them as an interrelated whole rather than separate non-related data items. Other standards (e.g., device-type standards) should define the minimum consistency check rules to be implemented for their context. Implementations may include additional, custom consistency checks beyond those standardized.
NOTE: Other requests (e.g., GetRequest-PDUs and SetRequests containing only control objects) can be processed as normal regardless of the state of this object.

<Definition> This object indicates the status of the consistency checking associated with the dbCreateTransactionV2 object.

<Format> When dbCreateTransactionV2 is in the 'normal' or 'transaction' state, this object shall indicate the respective value. When dbCreateTransactionV2 is in the 'verify' state, this object shall indicate a value of 'verifying'.
When in the 'done' state, this object shall have one of the following values:
doneWithNoError: The consistency checks did not identify any inconsistencies with the buffered parameter objects.
doneWithError: The consistency checks identified one or more inconsistencies with the buffered parameter objects.
commitFailed: the attempt to assign the buffered parameter objects failed and the device has been restored to its previous state; dbCreateTransactionV2 can be set to 'transaction' and the process tried again
undoFailed: the attempt to assign the buffered parameter objects failed and the device's database is in an unknown state with potential inconsistencies; dbCreateTransactionV2 can be set to 'transaction' and the process tried again.

<Definition> This object contains a textual description of or a reference to an error or condition that was found by the consistency checks implemented with the dbCreateTransactionV2 process. The value of this object shall be updated each time dbVerifyStatusV2 is updated. If dbCreateTransactionV2 is in the 'normal' state due to a reset command of dbTransactionReset, this field shall indicate 'Reset received' as the first characters in the string. Otherwise, unless the status reflects an error state (i.e., doneWithError, commitFailed, or undoFailed), this object shall indicate 'No error' as the first characters in the string.

<Definition> A node used to contain conformance concepts for the transaction feature.

<Definition> A node used to contain compliance statements for the transaction feature.

<Definition> A node used to contain object groups for the transaction feature.

The conformance statement for the transaction mode within an ITS field device.

<Definition> The objects necessary for managing the database transaction feature.