How to use RowStatus?

Question

I'm writing an SNMP manager and a simulated SNMP agent from a MIB (to test a manager). I have a table similar to below that the manager should be able to add/delete rows. What's the customary way to do this using RowStatus? Is RowStatus set first? Can other OIDs be included in the PDU?

My initial use case is the table is empty at startup. So if I send a SET PDU like this:

createStuffEntry.1.1.1 = 1
createStuffEntry.2.1.1 = 1
createStuffEntry.3.1.1 = 99
createStuffEntry.4.1.1 = "Dustbunnies"
createStuffEntry.5.1.1 = 5

Should that work for the definition below? What should happen if cRowStatus is left out?

createStuffTable OBJECT-TYPE
    SYNTAX  SEQUENCE OF CreateStuffEntry
    ACCESS  not-accessible
    STATUS  mandatory
    DESCRIPTION
            "A table for creating stuff."
    ::= { parentGroup 1 }

createStuffEntry OBJECT-TYPE
    SYNTAX  CreateStuffEntry
    ACCESS  not-accessible
    STATUS  mandatory
    DESCRIPTION
            "An entry for building a stuff to create."
    INDEX   { cPlanID,  cID }
    ::= { createStuffTable 1 }

CreateStuffEntry ::=
    SEQUENCE {
        cPlanID
            INTEGER,
        cID
            INTEGER,
        cTemplateID
            INTEGER,
        cStuffName
            DisplayString,
        cRowStatus
            RowStatus
    }

cPlanID OBJECT-TYPE
    SYNTAX  INTEGER
    ACCESS  read-write
    STATUS  mandatory
    DESCRIPTION
            "The plan ID (cpPlanID)"
    ::= { createStuffEntry 1 }

cID OBJECT-TYPE
    SYNTAX  INTEGER
    ACCESS  read-write
    STATUS  mandatory
    DESCRIPTION
            "The table entry index."
    ::= { createStuffEntry 2 }
    
cTemplateID OBJECT-TYPE
    SYNTAX  INTEGER
    ACCESS  read-write
    STATUS  mandatory
    DESCRIPTION
            "The ID of the stuff template to create this stuff from."
    ::= { createStuffEntry 3 }

cStuffName OBJECT-TYPE
    SYNTAX  DisplayString
    ACCESS  read-write
    STATUS  mandatory
    DESCRIPTION
            "The stuff name."
    ::= { createStuffEntry 4 }
    
    
 cRowStatus OBJECT-TYPE
    SYNTAX  RowStatus
    ACCESS  read-write
    STATUS  current
    DESCRIPTION
       "This OID uses six main statuses:
        active(1)         is in use and available in stuffTable
        notinService(2)   it is present but not yet created
        notReady(3)       it is present but missing info
        createAndGo(4)    create stuff in stuffTable.  Row will be
                          added to this table if necessary.
        createAndWait(5)  add stuff row to this table
        destroy(6)        will remove the stuff row
    
        This OID is used to add/remove rows for stuff creation.  
        It can also be used to determine if a stuff has been 
        created successfully."
    ::= { createStuffEntry 5 }

Note this is a SMI v1 MIB using RowStatus as a defined type, similar to that described here. Thus read-create is implied, rather than stated here.

Guzman

Answer 1

The RowStatus textual convention actually gives a fair amount of leeway to the agent in how it implements it. Thus, a manager must support both of these ways and the agent must support only one (but could support two):

1. Consecutive PDUs:
1. Set the row status variable to "createAndWait"
2. Set all the columns you want set up (in one PDU or many)
3. Set the row status variable to "active"
2. Set the row status variable to "createAndGo" and include **all** the variables you need to set into a single PDU

Unfortunately, a manager needs to be intelligent and know how to talk to agents that support one or the other. The general belief is that managers are bigger and have more room to code around issues than puny agents. Many small devices only support #2 above though.

Narration

In #2 would the agent expect the row status variable to be the first loaded into the PDU? Should it matter? – Guzman

It shouldn't matter, but the one thing I've learned over the years is that people write code that don't follow the rules and make expectations that they shouldn't. So... I'd put it first because some agents will likely expect it. – Narration

I've had to deal with SNMP Agents from Nortel that couldn't tell between scalar and columnar objects and Cisco agents that could bring down an enterprise ATM switch. SNMP is pretty simple and it is amazing how few implementers actually read the RFCs. – Gearalt

Management is the last thing most people want to spend money on, and most vendors thus treat it that way. Ask yourself if you'd rather buy a box with better management or a box with new routing feature X. Most people choose the second, and the vendors know that. New features beat management any day. – Narration