The status of the PeriodicTable. Only those communities with level4 access shall have access to this object. When the agent sets the status of a row in the echoTestPeriodicTable to underCreation, it must set this object to beingModified(4). This object must be reset to valid(1) after the row leaves the underCreation state (either by being set to valid or invalid). The agent should not allow the management station to modify this object when it's value is beingModified(4). The status for any row should be ignored by a manager that has successfully placed the table underRecovery(3). Managers trying to operate on row status during the recovery operation should fail. Management stations which start walking the table after ensuring the table status is valid should ensure the table has remained unchanged during the walk by checking the PeriodicTableLastEdit. A management station cannot set the state to underRecovery(3). To initiate a recovery operation, the management station must set this object to recoveryRequest(2). The agent must clear the table entries when setting this object to recoveryRequest. If successful, the management station may download the echo test table. If unsuccessful, then the contents of the PeriodicTable cannot be guaranteed. The table shall exist in the underRecovery state until the management station has finished downloading the table and sets this object back to valid(1). If the agent determines the table has been in the underRecovery(3) state for an abornmally long time, it may decide that the management station has crashed. The agent then can set the clear the table and set this object to valid(1).