[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Clarification on RowStatus and Agent Capabilities

Hi,

I am moving the discussion to the mibs@ops.ietf.org list.

Wes, I don't agree with your answers. Maybe there have been discussions of RowStatus usage I have missed, but I thought I'd heard all the discussions in the SMING WG and the MIB Doctors' mailing list.

According to RFC2579:
            "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 [...]"

I am not aware of anyplace that says you can have a RowStatus column and not need to use it when creating the row from a management application. You can certainly define tables without RowStatus columns if you don't want to use RowStatus functionality, but that may not meet the mib review guidelines recently published (ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-ops-mib-review-guidelines-01.txt).

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

I think a mib module might recommend (but not require) that agents implement using createAndGo for a table if possible, when it can be determined that the varbind needed can never exceed the minimum SNMP packet size (484) specified in section 3.2 of RFC3417.

I think a mib module might explain that createAndWait will be needed in the agent when the varbind needed to set all the required columns in a row may not be able to be handled in one SNMP message because the SET might exceed the maximum message size of an SNMP agent conformant to RFC3417 section 3.2 (SNMP/UDP/IPv4). Obviously we should discourage mib designs with row requirements that large.

Question #2: 

Mahesh, there is no AGENT-CAPABILITIES section in a standard mib. 

A standard mib contains a Conformance statement that specifies the requirements that must be met to have a standards-compliant implementation of the mib module.

An AGENT-CAPABILITIES statement is a separate document (in the format described in RFC2580) issued by an implementor to formally describe their implementation of the mib module, and how it compares to the requirements of the mib. This can help inform your customers and application developers about the variations in your implementation; having this will make managing your devices easier for operators (although not as easy as providing them with a standard-compliant implementation).

dbh

-----Original Message-----
From: Wes Hardaker [mailto:hardaker@tislabs.com]
Sent: Monday, May 12, 2003 9:43 AM
To: Kurapati, mahesh
Cc: midcom@ietf.org
Subject: Re: [midcom] Clarification on RowStatus and Agent Capabilities


>>>>> On Mon, 12 May 2003 04:34:51 -0400, "Kurapati, mahesh" <maheshk@netplane.com> said:

mahesh> 1.  Should a row be created when a set request is received on
mahesh> one of the columnar object (c1.<new instance>) with a non
mahesh> existing instance?  If a row is created, what shall be the
mahesh> value of RowStatus object?

That is up to the MIB designer.  You can document the behavior you
want in the DESCRIPTION clause of the RowStatus column.  Some
RowStatus columns state that the RowStatus column MUST be set, others
stay that rows can be created without using the RowStatus column.  If
done without, it should be equivalent to a "createAndGo".

MAHESH> 2.  Can the RowStatus be partially implemented?  In the sense,
MAHESH> for one of the table that we designed it does not make sense
MAHESH> to have all the RowStatus values supported?  In such
MAHESH> scenarios, can we implement this object partially?

One of the common things to do these days is to not require the use of
createAndWait.  Thus, in the IPSEC-POLICY-MIB we recently wrote:

        OBJECT      ipspAutoIkeRowStatus
        SYNTAX      RowStatus {
                active(1), createAndGo(4), destroy(6)
        }
        DESCRIPTION
            "Support of the values notInService(2), notReady(3),
             and createAndWait(5) is not required."

mahesh> 3.  Can we change the AGENT-CAPABILITIES section in a standard
mahesh> MIB, if we take deviations from the standard definitions?

Not sure what the question is...

mahesh> Please clarify me,

mahesh> Thanks and Regards
mahesh> Mahesh

mahesh> _______________________________________________
mahesh> midcom mailing list
mahesh> midcom@ietf.org
mahesh> https://www1.ietf.org/mailman/listinfo/midcom


--
Wes Hardaker
Network Associates Laboratories
_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom