|
This textual-convention provides a means
to represent the state of a conceptual row;
it does not provide a means to manage creation
and/or destruction of conceptual rows.
In any row which includes a definition of RowState
that is also mandatory, that row MUST contain
an instantiation of a RowState object if any other
object in the same row is instantiated.
A status column of this type has three defined
values:
- `active', which indicates that the
conceptual row is in use by the managed
device and is considered fully operational
from a management perspective;
- `notInService', which indicates that the
conceptual row is available for use by
the managed device but is NOT considered
fully operational from a management
perspective; a row in this state contains
all information necessary for a transition to
the active state;
- `notReady', which indicates that the
conceptual row is not available for use
by the managed device, perhaps because the
row is missing information or the row has
been explicitly set to this state;
Any of the three states may be specified in a
management protocol set operation. At any time,
the value of an existing RowState object may be
modified or changed to any other state unless
the current value is notReady and the row (after
completion of a management set operation) would
not be consistent with an active state (i.e.
information is missing or inconsistent and as a
result the row could not assume an active state
until further management set operations were
performed). In this case, the value MUST remain
at notReady and an inconsistentValue error is
returned.
A RowState object whose value is notReady MUST
implicitly promote itself from notReady to
notInService if any management protocol set
operation not referencing the status column
explicitly changes the value of any other object
in the same row AND the row afterward is now
consistent with the active state (i.e all
information needed to make the row active is
available).
When a row does not exist, and a management
protocol set operation causes any object in the row
to be created, the status object will also be
instantiated and its initial value will be determined
by the first of the following rules that are satisfied:
1. if the set operation includes an initial value,
the RowState object will take on the highest
value (i.e. active is highest) consistent with
the state definitions, but no higher than the
provided value. For example, if a set operation
contains a varbind where RowState=notInService
(or active), the initial value will be notReady
if the row is in an inconsistent state after the
operation is complete; otherwise, it will be
notInService (or active).
2. if the set operation does not include an initial
value, but the RowState definition does include
a supported DEFVAL, the initial value will be the
highest value consistent with the state definitions
but no higher than the value specified in the
DEFVAL, unless the DEFVAL specifies a value of
notReady, which in this case, the DEFVAL is ignored
(i.e. case 3 below instead applies).
3. otherwise, the set operation does not include an
initial value, and the RowState definition does
not include a DEFVAL, and the initial value will
be set to the highest value consistent with the
state definitions. Thus, the initial state will
be active if the new row is consistent with that
state, or it will be notReady otherwise.
No constraint is imposed on whether other objects
in the same row can be modified, regardless of the
value of the associated RowState object. If such
constraints are desired, they MUST be explicitly
stated in the DESCRIPTION clause of the status column.
In the absence of such statements, the managed device
MUST allow any object in any row to be modified at
any time, notwithstanding the possibility that other
MIB objects MAY also impose similar constraints.
An inconsistentValue error is returned when an invalid
attempt is made to alter a row whose state precludes
such an operation.
RowState description clauses, in addition to
the DESCRIPTION clauses of associated column
objects, SHOULD together describe the general
conditions under which a row can be made active.
In the absence of such statements, any row SHOULD
generally be capable of being made active at any
time.
The agent must detect conceptual rows that
have been in the notReady state for an abnormally
long period of time and remove them. It is the
responsibility of the DESCRIPTION clause of the
status column to indicate what an abnormally long
period of time would be. This period of time should
be long enough to allow for human response time
(including `think time') between the creation of the
conceptual row and the setting of the status to `active'.
In the absense of such information in the DESCRIPTION
clause, it is suggested that this period be approximately
5 minutes in length. This removal action applies not only
to newly-created rows, but also to previously active rows
which are set to, and left in, the notReady state for a
prolonged period exceeding that which is considered normal
for such a conceptual row. |
