be equal to `active' either immediately before or after                 processing the PDU.  In other words, if the PDU also                 contained a varbind that would change the RowStatus                 value, the column in question may be changed if the                 RowStatus was not equal to `active' as the PDU was                 received, or if the varbind sets the status to a value                 other than 'active'.            Also note that whenever any elements of a row exist, the            RowStatus column must also exist.            To summarize the effect of having a conceptual row with a            status column having a SYNTAX clause value of RowStatus,            consider the following state diagram:                                         STATE              +--------------+-----------+-------------+-------------              |      A       |     B     |      C      |      D              |              |status col.|status column|              |status column |    is     |      is     |status column    ACTION    |does not exist|  notReady | notInService|  is active--------------+--------------+-----------+-------------+-------------set status    |noError    ->D|inconsist- |inconsistent-|inconsistent-column to     |       or     |   entValue|        Value|        ValuecreateAndGo   |inconsistent- |           |             |              |         Value|           |             |--------------+--------------+-----------+-------------+-------------set status    |noError  see 1|inconsist- |inconsistent-|inconsistent-column to     |       or     |   entValue|        Value|        ValuecreateAndWait |wrongValue    |           |             |--------------+--------------+-----------+-------------+-------------set status    |inconsistent- |inconsist- |noError      |noErrorcolumn to     |         Value|   entValue|             |active        |              |           |             |              |              |     or    |             |              |              |           |             |              |              |see 2   ->D|          ->D|          ->D--------------+--------------+-----------+-------------+-------------set status    |inconsistent- |inconsist- |noError      |noError   ->Ccolumn to     |         Value|   entValue|             |notInService  |              |           |             |              |              |     or    |             |      or              |              |           |             |              |              |see 3   ->C|          ->C|wrongValue--------------+--------------+-----------+-------------+-------------set status    |noError       |noError    |noError      |noErrorcolumn to     |              |           |             |destroy       |           ->A|        ->A|          ->A|          ->A--------------+--------------+-----------+-------------+-------------set any other |see 4         |noError    |noError      |see 5column to some|              |           |             |value         |              |      see 1|          ->C|          ->D--------------+--------------+-----------+-------------+-------------            (1) goto B or C, depending on information available to the            agent.            (2) if other variable bindings included in the same PDU,            provide values for all columns which are missing but            required, then return noError and goto D.            (3) if other variable bindings included in the same PDU,            provide values for all columns which are missing but            required, then return noError and goto C.            (4) at the discretion of the agent, the return value may be            either:                 inconsistentName:  because the agent does not choose to                 create such an instance when the corresponding                 RowStatus instance does not exist, or                 inconsistentValue:  if the supplied value is                 inconsistent with the state of some other MIB object's                 value, or                 noError: because the agent chooses to create the                 instance.            If noError is returned, then the instance of the status            column must also be created, and the new state is B or C,            depending on the information available to the agent.  If            inconsistentName or inconsistentValue is returned, the row            remains in state A.            (5) depending on the MIB definition for the column/table,            either noError or inconsistentValue may be returned.            NOTE: Other processing of the set request may result in a            response other than noError being returned, e.g.,            wrongValue, noCreation, etc.                              Conceptual Row Creation            There are four potential interactions when creating a            conceptual row:  selecting an instance-identifier which is            not in use; creating the conceptual row; initializing any            objects for which the agent does not supply a default; and,            making the conceptual row available for use by the managed            device.            Interaction 1: Selecting an Instance-Identifier            The algorithm used to select an instance-identifier varies            for each conceptual row.  In some cases, the instance-            identifier is semantically significant, e.g., the            destination address of a route, and a management station            selects the instance-identifier according to the semantics.            In other cases, the instance-identifier is used solely to            distinguish conceptual rows, and a management station            without specific knowledge of the conceptual row might            examine the instances present in order to determine an            unused instance-identifier.  (This approach may be used, but            it is often highly sub-optimal; however, it is also a            questionable practice for a naive management station to            attempt conceptual row creation.)            Alternately, the MIB module which defines the conceptual row            might provide one or more objects which provide assistance            in determining an unused instance-identifier.  For example,            if the conceptual row is indexed by an integer-value, then            an object having an integer-valued SYNTAX clause might be            defined for such a purpose, allowing a management station to            issue a management protocol retrieval operation.  In order            to avoid unnecessary collisions between competing management            stations, `adjacent' retrievals of this object should be            different.            Finally, the management station could select a pseudo-random            number to use as the index.  In the event that this index            was already in use and an inconsistentValue was returned in            response to the management protocol set operation, the            management station should simply select a new pseudo-random            number and retry the operation.            A MIB designer should choose between the two latter            algorithms based on the size of the table (and therefore the            efficiency of each algorithm).  For tables in which a large            number of entries are expected, it is recommended that a MIB            object be defined that returns an acceptable index for            creation.  For tables with small numbers of entries, it is            recommended that the latter pseudo-random index mechanism be            used.            Interaction 2: Creating the Conceptual Row            Once an unused instance-identifier has been selected, the            management station determines if it wishes to create and            activate the conceptual row in one transaction or in a            negotiated set of interactions.            Interaction 2a: Creating and Activating the Conceptual Row            The management station must first determine the column            requirements, i.e., it must determine those columns for            which it must or must not provide values.  Depending on the            complexity of the table and the management station's            knowledge of the agent's capabilities, this determination            can be made locally by the management station.  Alternately,            the management station issues a management protocol get            operation to examine all columns in the conceptual row that            it wishes to create.  In response, for each column, there            are three possible outcomes:                 - a value is returned, indicating that some other                 management station has already created this conceptual                 row.  We return to interaction 1.                 - the exception `noSuchInstance' is returned,                 indicating that the agent implements the object-type                 associated with this column, and that this column in at                 least one conceptual row would be accessible in the MIB                 view used by the retrieval were it to exist. For those                 columns to which the agent provides read-create access,                 the `noSuchInstance' exception tells the management                 station that it should supply a value for this column                 when the conceptual row is to be created.                 - the exception `noSuchObject' is returned, indicating                 that the agent does not implement the object-type                 associated with this column or that there is no                 conceptual row for which this column would be                 accessible in the MIB view used by the retrieval.  As                 such, the management station can not issue any                 management protocol set operations to create an                 instance of this column.            Once the column requirements have been determined, a            management protocol set operation is accordingly issued.            This operation also sets the new instance of the status            column to `createAndGo'.            When the agent processes the set operation, it verifies that            it has sufficient information to make the conceptual row            available for use by the managed device.  The information            available to the agent is provided by two sources:  the            management protocol set operation which creates the            conceptual row, and, implementation-specific defaults            supplied by the agent (note that an agent must provide            implementation-specific defaults for at least those objects            which it implements as read-only).  If there is sufficient            information available, then the conceptual row is created, a            `noError' response is returned, the status column is set to            `active', and no further interactions are necessary (i.e.,            interactions 3 and 4 are skipped).  If there is insufficient            information, then the conceptual row is not created, and the            set operation fails with an error of `inconsistentValue'.            On this error, the management station can issue a management            protocol retrieval operation to determine if this was            because it failed to specify a value for a required column,            or, because the selected instance of the status column            already existed.  In the latter case, we return to            interaction 1.  In the former case, the management station            can re-issue the set operation with the additional            information, or begin interaction 2 again using            `createAndWait' in order to negotiate creation of the            conceptual row.                                     NOTE WELL                 Regardless of the method used to determine the column                 requirements, it is possible that the management                 station might deem a column necessary when, in fact,                 the agent will not allow that particular columnar                 instance to be created or written.  In this case, the                 management protocol set operation will fail with an                 error such as `noCreation' or `notWritable'.  In this                 case, the management station decides whether it needs                 to be able to set a value for that particular columnar                 instance.  If not, the management station re-issues the                 management protocol set operation, but without setting                 a value for that particular columnar instance;                 otherwise, the management station aborts the row                 creation algorithm.            Interaction 2b: Negotiating the Creation of the Conceptual            Row            The management station issues a management protocol set            operation which sets the desired instance of the status            column to `createAndWait'.  If the agent is unwilling to            process a request of this sort, the set operation fails with            an error of `wrongValue'.  (As a consequence, such an agent            must be prepared to accept a single management protocol set            operation, i.e., interaction 2a above, containing all of the            columns indicated by its column requirements.)  Otherwise,            the conceptual row is created, a `noError' response is            returned, and the status column is immediately set to either