dbMgmtV2Mode

{
  "smi_kind": "OBJECT-TYPE",
  "definition": [
    "dbMgmtV2Mode",
    "OBJECT-TYPE",
    "SYNTAX",
    "INTEGER",
    "{",
    "normal",
    "(",
    "1",
    ")",
    ",",
    "transaction",
    "(",
    "2",
    ")",
    ",",
    "verify",
    "(",
    "3",
    ")",
    ",",
    "done",
    "(",
    "4",
    ")",
    "}",
    "MAX-ACCESS",
    "read-write",
    "STATUS",
    "current",
    "DESCRIPTION",
    "\"<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. <Object Identifier> 1.3.6.1.4.1.1206.4.2.6.9.1.1\"",
    "DEFVAL",
    "{",
    "normal",
    "}",
    "::=",
    "{",
    "dbMgmtV2",
    "1",
    "}"
  ],
  "syntax_tree": [
    [
      "SimpleSyntax",
      "INTEGER",
      [
        "enumSpec",
        [
          [
            "normal",
            1
          ],
          [
            "transaction",
            2
          ],
          [
            "verify",
            3
          ],
          [
            "done",
            4
          ]
        ]
      ]
    ],
    null,
    [
      "MaxAccessPart",
      "read-write"
    ],
    [
      "Status",
      "current"
    ],
    [
      "DESCRIPTION",
      "<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. <Object Identifier> 1.3.6.1.4.1.1206.4.2.6.9.1.1"
    ],
    null,
    null,
    null,
    [
      "DEFVAL",
      "normal"
    ]
  ]
}