RE: Clarification on RowStatus and Agent Capabilities

["Harrington, David" <dbh@enterasys.com>]

Hi,

It is OK for an agent to not support createAndWait. This is spelled out in RFC2579 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.)"

It is my interpretation that a compliant agent may choose to support createAndGo or createAndWait or both but not neither. It is also my experience as an application developer that some agents support one or the other or both.

I believe it is incorrect for a mib module to specify that a specific choice is required of the agent when implementing the mib module, although it is possible to design mib tables where a createAndGo simply couldn't work given max message size limitations of the agent.

It of course gets very difficult to be compliant if you don't support createAndWait and a mib module defines a row that you cannot process using createAndGo because the request is bigger than your max message size. sigh.

dbh
-----Original Message-----
From: Wes Hardaker [mailto:wjhns1@hardakers.net]
Sent: Wednesday, May 14, 2003 3:43 PM
To: Harrington, David
Cc: Kurapati, mahesh; mibs@ops.ietf.org
Subject: Re: Clarification on RowStatus and Agent Capabilities


>>>>> On Wed, 14 May 2003 13:52:50 -0400, "Harrington, David" <dbh@enterasys.com> said:

David> I am not aware of anyplace that says you can have a RowStatus
David> column and not need to use it when creating the row from a
David> management application.

David P. responded to this, so I won't...

David> RFC2579 RowStatus Interaction 2b describes the use of the
David> createAndWait and createAndGo values. The statefulness of the
David> createAndWait operation makes things more difficult for an
David> agent, but requiring createAndGo can be problematic if the row
David> has multiple required columns, and the agent cannot handle all
David> the column SETs in one request. It is up to the agent
David> implementer to determine which create option they support,
David> based on their available resources. I don't think the choice of
David> create option should be specified as a requirement in a mib
David> module.

Oddly enough, I asked a question a while back (I think it was even on
this list though I'd have to go look for it in my archives) about what
the current best-practice was with respect to RowStatus and
createAndWait/createAndGo and was told at the time that making
createAndWait optional was an ok thing to do.  I'll see if I can dig
up the previous discussion.  Maybe it was on the sming list.


--
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett