Subject: Re: snmpconf 18.Update capabilities table

From: "David T. Perkins" <[email-masked]>
Date: Tue, 10 Apr 2001 16:08:35 -0700

HI,

I'm having a difficult time understanding the MIB objects below.
Is there a document that provides some additional description?

I have the specific questions/concerns:
1) SMIv2 has the MODULE-COMPLIANCE construct for formally describing
   implementation requirements, and the AGENT-CAPABILITIES construct
   for describing implementation of object types and notification
   types in SNMP agents. However, it appears that the objects
   below are using instances of MODULE-COMPLIANCE definitions
   instead of instances of AGENT-CAPABILITIES definitions.
   Is the author confused or is below a creative use of
   compliance definitions?

2) The DESCRIPTION clause for pmCapabilitiesTable contains the
   sentence "An entry is removed from this table when the last
   element in the system that has the capability is removed."
   What does this mean? Is this referring to an instance of
   a managed resource? Or something else? Please focus on the
   phrase "last element in the system".

3) Note that MODULE-COMPLIANCE constructs can name object and
   notification types in one or more MIB modules. Also, a
   MODULE-COMPLIANCE construct specifies mandatory and conditional
   groups of object and/or notification types. A MODULE-COMPLIANCE
   may also contain object and notification exceptions that allow
   subset behaviors to be specified. When used as a capability
   specification, is a MODULE-COMPLIANCE instance interpreted
   in a minimal or maximal form?

4) The definition of object pmCapabilitiesType seems to imply that
   the value specified does not have to be the OID of a
   MODULE-COMPLIANCE definition (see point 2). If so, this is
   an ambiguous specification. What do the value of object
   pmCapabilitiesType identify?

5) The definition of object pmCapabilitiesType seems to imply that
   the value specified can identify a collection of capabilities
   (point 3). Note that SMIv2 does not have a construct to
   define a collection. What is this?

In general, what is trying to be described by the objects defined
below? Is it potential of support for instances of a resource?
And/or is it potential of support a particular instance of
a resource? Is it trying in any way to describe capacity (max
number of instances of resources), or interaction between
allocation of instances of one resource with another? (For example,
say there are two memory pools and instances of resource A and
B are allocated from pool 1, and instances or resources C, D, and E
are allocated from pool 2. Is there anyway to describe the
relationship between the resources and the memory pools? Does
the capabilities change if out of resources so no new ones
can be allocated?) 

Regards,
/david t. perkins

At 09:57 AM 4/10/2001 -0400, Jon Saperia wrote:
>Before and during the IETF there was a lot of discussion about the
>capabilities table and the capMatch function. I have exchanged some
>email and talked with people about this since that time. This is for our
>to do item 18 - capabilities table update.
>
>There are now two quite small tables as presented at the IETF.
>
>-- Capabilities table
>
>pmCapabilitiesTable OBJECT-TYPE
>    SYNTAX      SEQUENCE OF PmCapabilitiesEntry
>    MAX-ACCESS  not-accessible
>    STATUS      current
>    DESCRIPTION
>         "The pmCapabilitiesTable lists the capabilities of a system so
>         that policies can be differentially installed by management
>         systems based on capabilities. The capMatch function uses
>         entries in this table, and further modified by the
>         pmCapabilitiesOverrideTable, to determine whether or not to
>         apply policy actions based on whether the system has a
>         particular capability. Capabilities are expressed at the system
>         level. That is, entries appear in this table if any element in
>         the system has the capability. An entry is removed from this
>         table when the last element in the system that has the
>         capability is removed."
>    ::= { policyMgt 6 }
>
>pmCapabilitiesEntry OBJECT-TYPE
>    SYNTAX      PmCapabilitiesEntry
>    MAX-ACCESS  not-accessible
>    STATUS      current
>    DESCRIPTION
>         "A capabilities entry holds an OID indicating support for a
>         particular capability.  The semantics of the OID are
>         defined in the description of pmCapabilitiesType.
>
>         These capabilities need not be limited to those that represent
>         MIB modules with one or more configurable objects. It may also
>         be valuable to include entries for capabilities that do not
>         include configuration objects since that information in
>         combination with other entries in this table might be used by
>         the management software to determine whether or not to install
>         a policy.
>
>         Vendor software may also add entries in this table to express
>         capabilities from their private branch."
>    INDEX       { pmCapabilitiesType }
>    ::= { pmCapabilitiesTable 1 }
>
>PmCapabilitiesEntry ::= SEQUENCE {
>    pmCapabilitiesType               OBJECT IDENTIFIER
>}
>
>pmCapabilitiesType OBJECT-TYPE
>    SYNTAX      OBJECT IDENTIFIER
>    MAX-ACCESS  read-only
>    STATUS      current
>    DESCRIPTION
>        "There are three types of OIDs that may be present in the
>        pmCapabilitiesType object:
>
>        1) The OID representing the highest level of compliance for the
>        MIB Module realized by the agent. This value should be from the
>        compliance statements for agents realizing MIB Modules that
>        have been written with them. In the case where multiple levels
>        of compliance are available for a MIB Module, the entry in this
>        table should reflect this highest level of support provided by
>        the agent.  An agent that implements the OSPF MIB module at the
>        highest level of compliance would have the value of
>        '1.3.6.1.2.1.14.15.2' in pmCapabilitiesType object. In the case
>        of software that realizes standard MIB modules that do not have
>        compliance statements, the base OID of the MIB Module should be
>        used instead. If the OSPF MIB Module had not been created with
>        compliance statement, then the correct value of the
>        pmCapabilitiesType would be '1.3.6.1.2.1.14'. In the cases
>        where multiple compliance statements in a MIB Module are
>        supported by the agent, and one compliance statement does not
>        by definition include the other, each of the compliance OIDs
>        would have entries in this table. 
>
>         MIB Documents can contain more than one MIB Module. In the case
>         of OSPF, there is a second MIB Module in that document that
>         describes traps for the OSPF Version 2 Protocol. If the agent
>         also realizes these functions, an entry will also exist for
>         those capabilities in this table.
>
>        2) Vendors should install OIDs in this table that represent
>        vendor-specific capabilities. These capabilities can be
>        expressed just as those described above for standard MIB
>        Modules. In addition, vendors may install any OID they desire
>        from their registered branch. The OIDs may be at any level of
>        granularity, from the root of their entire branch to an
>        instance of a single OID. There is no restriction on the
>        number of registrations they may make, though care should be
>        taken to avoid unnecessary entries.
>
>        3) OIDs that represent one or a collection of capabilities
>        which could be any collection of MIB Objects or hardware or
>        software functions may be created in working groups and
>        registered with IANA. Other entities (e.g., vendors) may also
>        make registrations. Software will register these standard
>        capability OIDs as well as vendor specific OIDs."
>    ::= { pmCapabilitiesEntry 1 }
>
>-- Capabilities override table
>
>pmCapabilitiesOverrideTable OBJECT-TYPE
>    SYNTAX      SEQUENCE OF PmCapabilitiesOverrideEntry
>    MAX-ACCESS  not-accessible
>    STATUS      current
>    DESCRIPTION
>         "The pmCapabilitiesOverrideTable allows management stations to
>         override entries that have been made in the pmCapabilitiesTable
>         by native software on the managed system. This facility can be
>         used to avoid the condition where managers in the network send
>         policies to a system that has advertised a capability in the
>         pmCapabilitiesTable but which should not be installed on this
>         particular system. One case could be newly deployed equipment
>         that is still in a trial state, or when resources are reserved
>         for some other administrative reason. This table can also be
>         used to override entries in the pmCapabilitiesTable through the
>         use of the pmCapabilitiesOverrideState object. Capabilities can
>         also be declared available in this table that were not
>         registered in the pmCapabilitiesTable. A management application
>         can make an entry in this table for any valid OID and declare
>         the capability available by setting the
>         pmCapabilitiesOverrideState for that row to valid(1)."
>    ::= { policyMgt 7 }
>
>pmCapabilitiesOverrideEntry OBJECT-TYPE
>    SYNTAX      PmCapabilitiesOverrideEntry
>    MAX-ACCESS  not-accessible
>    STATUS      current
>    DESCRIPTION
>         "An entry in this table indicates whether a particular
>         capability is valid or invalid."
>    INDEX       { pmCapabilitiesOverrideType }
>    ::= { pmCapabilitiesOverrideTable 1 }
>
>PmCapabilitiesOverrideEntry ::= SEQUENCE {
>    pmCapabilitiesOverrideType               OBJECT IDENTIFIER,
>    pmCapabilitiesOverrideState              INTEGER,
>    pmCapabilitiesOverrideRowStatus          RowStatus
>}
>
>pmCapabilitiesOverrideType OBJECT-TYPE
>    SYNTAX      OBJECT IDENTIFIER
>    MAX-ACCESS  read-create
>    STATUS      current
>    DESCRIPTION
>        "This is the OID of the capability that is declared valid or
>        invalid by the pmCapabilitiesOverrideState value for this
>        row. Any valid OID as described in the pmCapabilitiesTable is
>        permitted in the pmCapabilitiesOverrideType object. This means
>        that capabilities can be expressed at any level from a specific
>        instance of an object to a table or entire module. There are no
>        restrictions on whether these objects are from standards track
>        MIB documents or in the private branch of the MIB.
>
>         If an entry exists in this table for which there is a
>         corresponding entry in the pmCapabilitiesTable, then this entry
>         shall have precedence over the entry in the
>         pmCapabilitiesTable. All such entries in this table must be
>         preserved across reboots."
>    ::= { pmCapabilitiesOverrideEntry 1 }
>
>pmCapabilitiesOverrideState OBJECT-TYPE
>    SYNTAX      INTEGER {
>                    invalid(0),
>                    valid(1)
>                }
>    MAX-ACCESS  read-create
>    STATUS      current
>    DESCRIPTION
>        "A pmCapabilitiesOverrideState of invalid indicates that
>        management software should not send policies to this system for
>        the capability identified in the pmCapabilitiesOverrideType for
>        this row of the table. The capMatch function will always return
>        0 (false) for capabilities marked as invalid using this
>        object. This behavior is the same whether the capability
>        represented by the pmCapabilitiesOverrideType exists only in
>        this table, that is it was installed by an external management
>        application, or exists in this table as well as the
>        pmCapabilitiesTable. This would be the case when a manager
>        wanted to disable a capability that the native management
>        system found and registered in the pmCapabilitiesTable.
>
>         An entry in this table that has a pmCapabilitiesOverrideState
>         of valid should be treated as if it appeared in the
>         pmCapabilitiesTable. If the entry also exists in the
>         pmCapabilitiesTable in the pmCapabilitiesType object, and the
>         value of this object is valid, then the system shall operate
>         as if this entry did not exist and policy installations and
>         executions will continue in a normal fashion."
>    ::= { pmCapabilitiesOverrideEntry 2 }
>
>pmCapabilitiesOverrideRowStatus OBJECT-TYPE
>    SYNTAX      RowStatus
>    MAX-ACCESS  read-create
>    STATUS      current
>    DESCRIPTION
>         "The row status of this pmCapabilitiesOverrideEntry.
>    ::= { pmCapabilitiesOverrideEntry 3 }
>
>Thanks,
>/jon
>
>--
>Jon Saperia                  [email-masked]
>                             Phone: 617-744-1079
>                             Fax:   617-249-0874
>                             http://www.jdscons.com/

---

From: Jon Saperia <[email-masked]>
Date: Mon, 16 Apr 2001 09:30:51 -0400

David Perkins and I did some follow-up on his concerns (see his posting
of 4/10). I am sure I have not resolved them all. In particular I have
made changes in the description of pmCapabilitiesTable, and
pmCapabilitiesEntry. 

        1. I have put in language about the fact that management
        applications should consider this entry along with information
        about the model and vendor before installing a policy since
        realizations of capability will vary. In short a capability
        indicates that a system can do something, not how it does it. In
        general David was concerned about over-claiming what the table
        can do. This helps.

        2. Another concern was when instances come and go in the
        pmCapabilitiesTable. I have placed additional language to help
        address this concern.

        3. The use of the OIDs from MODULE-COMPLIANCE is in fact
        unusual. I think the text clearly specifies how we are using
        them. They seem to be the best handles we have a the present
        time.

A changed version follows.

-- Capabilities table

         systems based on capabilities.

	 Capabilities are expressed at the system level. There can be
	 variation in how capabilities are realized from one vendor or
	 model to the next. Management systems should consider these
	 differences before selecting which policy to install in a
	 system.
	 
	 The capMatch function uses entries in this table, and further
	 modified by the pmCapabilitiesOverrideTable, to determine
	 whether or not to apply policy actions based on whether the
	 system has a particular capability."

    ::= { policyMgt 6 }

	 Entries appear in this table if any element in the system has a
	 specific capability. A capability should appear in this table
	 only once regardless of the number of elements in the system
	 with that capability. An entry is removed from this table when
	 the last element in the system that has the capability is
	 removed. In some cases, capabilities are dynamic and exist only
	 in software. This table should have an entry for the capability
	 even if there are no current instances. Examples include
	 systems with database or WEB services. While the system has the
	 ability to create new databases or WEB services, the entry
	 should exist. In these cases, the ability to create these
	 services could come from other processes that are running in
	 the system even though there are no currently open databases or
	 WEB servers running.

         Capabilities need not be limited to those that represent MIB
         modules with one or more configurable objects. It may also be
         valuable to include entries for capabilities that do not
         include configuration objects since that information, in
         combination with other entries in this table, might be used by
         the management software to determine whether or not to install
         a policy.

Thanks,
/jon
--

---

From: David Partain <[email-masked]>
Date: Fri, 20 Apr 2001 18:37:07 +0200

Greetings,

See http://www.snmp.com/snmpconf/mailing-list/msg00726.html for
the most recent thread on this topic.

There has been much discussion on the capabilities table.
It is my reading of the working group that we have reached
a consensus that we would define the table as we decided
in Minneapolis (as described on the todo list - see #18 on
http://www.cs.utk.edu/~partain/snmpconf/todo.html) and as sent
to this mailing list by Jon on 16 Apr 2001.

With kind regards,

--
David Partain                  [email-masked]
Ericsson Radio Systems AB      Tel:    +46 13 28 41 44
Research and Innovation        Fax:    +46 13 28 75 67
P.O. Box 1248                  http://linlab.ericsson.se/~epkpart
SE-581 12  Linköping, Sweden

---

From: "David T. Perkins" <[email-masked]>
Date: Fri, 20 Apr 2001 11:24:05 -0700

David,

I haven't read Jon's update message after speaking with him on
the phone. The talk troubled me greatly due to my perception
of Jon's lack of knowledge about MODULE-COMPLIANCEs and AGENT-CAPs.
I believe that it is bad for the SNMP community to use
MODULE-COMPLIANCEs to specify capabilities. Whatever small gain
that would help SNMPCONF, is offset by the damage that it can
and I believe will do the SNMP community.

Additionally, I have a major problem with trying to use some
sort of capabilities specification that an agent provides
to assist an unknown manager. I believe that EVERY management
application must have either a separate program or a component
within it to probe an agent to determine if it has the
capabilities that are needed to support its requirements.
Only the management app knows its requirements. Only after
a management app is written and the requirements specified,
can an agent developer determine if it meets the requirements.
It is "just silly" for an agent to advertise capabilities
for future and of course unknown management apps and HOPE
that the capabilities specification is complete and precise
enough to allow a management app to determine if it can
interoperate with an agent without probing the agent.
Once you need to probe an agent, when why bother with
checking for a capabilities specification.

Regards,
/david t. perkins

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 20 Apr 2001 15:59:09 -0400

In your description Dave, you state that the management app should "probe 
the capabilities of the individual device.  Given taht what we are trying 
to do is provide a means my which a common set of configuration can be 
defined by the administrator, and applied across a number of devices, there 
is no way that the application can "know" much about what capabilities are 
required unless the language / libraries / objects tell it so.  What we are 
trying to define are the hooks that make it likely that the policy will be 
applicable / useful.  We recognize that you can not define fine enough 
grained capabilities in a general fashion.  Instead we are trying to 
provide coarse grained information that will help the management system 
determine whether a given configuration policy is likely to be useful to 
send to a given system.
Yours,
Joel M. Halpern

---

From: "David T. Perkins" <[email-masked]>
Date: Fri, 20 Apr 2001 13:58:23 -0700

HI,

I hope that we can agree that this is a potentially difficult problem.
However, in the case that you bring up, I believe that one has to run
a classifier program that probes the managed systems. Of course if you
have 100 systems, and 30% are brand X, 45% are brand Y, and the remaining
25% are brand Z, you don't need to do extensive probing of each of
the 100 systems for each new management app.

I get a little worried about deploying a new management app (or script)
on 100 systems at the same time on a live network that I have not tested
pretty extensively on a single system in a controlled environment.

A capabilities mechanism that allows me to skip testing,
but will fail sometimes (because of approximate completion
and low precision in its description of capabilities) 
doesn't seem like a prudent addition.
I've still got to test in my world.

At 03:59 PM 4/20/2001 -0400, Joel M. Halpern wrote:
>In your description Dave, you state that the management app should "probe the capabilities of the individual device.  Given taht what we are trying to do is provide a means my which a common set of configuration can be defined by the administrator, and applied across a number of devices, there is no way that the application can "know" much about what capabilities are required unless the language / libraries / objects tell it so.  What we are trying to define are the hooks that make it likely that the policy will be applicable / useful.  We recognize that you can not define fine enough grained capabilities in a general fashion.  Instead we are trying to provide coarse grained information that will help the management system determine whether a given configuration policy is likely to be useful to send to a given system.
>Yours,
>Joel M. Halpern

Regards,
/david t. perkins

---

From: Jon Saperia <[email-masked]>
Date: Fri, 20 Apr 2001 17:13:17 -0400

> the 100 systems for each new management app.

As I explained on the phone, one combines information at the management
station learned from the capabilities tables with other information
known about a device before installing policies. The capabilities table
will let you know if a device can perform DiffServ. Knowing the model
and vendor and sometime even release number are required before a
management application will know what type of policy to install.

> pretty extensively on a single system in a controlled environment.

That is not an SNMPCONF specific issue. Just as one should test things
with CLI based scripts or file transfer based technology so too should
scripts be tested. Seems kind of obvious to me.
> I've still got to test in my world.

Capabilities does not, nor is it intended - by itself or in
combination with other factors - eliminate the need for testing. It is
good operational practice to test.

Thanks,
/jon
--

---

From: David Harrington <[email-masked]>
Date: Mon, 23 Apr 2001 07:27:40 -0400

Hi,

I am concerned that the resulting text is not what was specified on the
todo list.

The pmCapabilitiesType seems to have been greatly expanded from what is
mentioned in the todo list.
The purpose of the IETF is to provide standardized solutions. The
wide-open nature of this object seems to work against standardization.
The ability to define any OID without it being a module identity or a
compliance OID means that vendors can use OIDs that are proprietary
"codes" for their own applications to recognize, promoting the use of
"hidden" capabilities. This does not work toward interoperability and
industry standardization. 

According to the todo list, the pmCapabilitiesOverrideTable would
contain two objects - one which could be set to valid or invalid, and a
rowstatus object.
The text proposed has additional functionality beyond a valid/invalid
switch and a rowstatus.

I am particularly concerned about a manager being allowed to override
the agent by asserting that a capability is present even though the
agent says it is not. There is no way for a manager to better understand
the agent implementation than the agent itself. This smacks of creeping
featurism.

I am concerned about the multiple manager problem and the override
table. Should one manager be able to override the capabilities table,
thus affecting all managers? or should this be on a manager-by-manager
basis via the use of ownerstrings or something? The capabilities table
advertises what the agent believes are its capabilities, and they are
consistent for all managers. The capabilitiesoverride table is one
managers' opinion about the capabilities of the agent, and should not
necessarily be applied to all managers. I think the design specified in
the todo list had a simple task to accomplish. The text has extended the
design in ways that make the reliability of this table questionable.

So when you're calculating consensus, count me as not supporting the
proposed text as the correct expression of the todo list agreements.

dharrington

-- 
---
David Harrington            Network Management Standards Architect
[email-masked]           Office of the CTO
+1 603 337 2614 - voice     Enterasys Networks
+1 603 332 1524 - fax       Rochester NH, USA

---

From: Jon Saperia <[email-masked]>
Date: Mon, 23 Apr 2001 07:54:33 -0400

> the agent implementation than the agent itself. This smacks of creeping

(Jon - not wearing co-chair hat)

Clearly I do not agree. The posted to do list item (for just about
anything) points in the direction of a solution, not a complete
specification. The addition of a row status object is there for all the
reasons one would have an object in any other table. With regard to an
a manager putting an entry in that was not put in by the agent, this can
correct for agents that have not been upgraded to make this registration
but still perform the function.
> design in ways that make the reliability of this table questionable.

There is nothing unique about the multiple manager problem here. Also
not the to do item specifically does call for a manager to be able to
correct false negative and positive reports ( false negative would be not
reporting a capability that exists).

> proposed text as the correct expression of the todo list agreements.

Thanks
/jon

Thanks,
/jon
--

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 23 Apr 2001 09:43:27 -0400

As a practical matter, even if we said that "only listed OIDs may be used 
for capabilities" sensible implementors would ignore this restriction, and 
creative implementors would make use of arbitrary OIDs anyway.
The other side of this coin is that we can not reasonable define a priori 
what the full list of capabilities should be.  Therefore, we need to leave 
room for the vendors to add capabilities.  Having left such room, it is 
certainly true that we are also leaving them room for interesting 
proprietary capabilities.  So be it.

Yours,
Joel M. Halpern