Subject: snmpconf Problems with capabilities table

From: Steve Waldbusser <[email-masked]>
Date: Tue, 13 Mar 2001 00:26:00 -0800

I have some problems with the capabilities table as it stands and
suggest a major change. Here's the details:

Problems with capabilities table:

1. General: It is a bad idea to suggest that capabilities OIDs map to
   base OIDs of tables or MIBS or that capabilities are tied to the
   implementation of a MIB. While it's true that many times we're 
   interested in whether we'll be able to set a particular MIB 
   variable, often we need something different:

   What if there's a MIB with a single table that represents multiple
   (optional) capabilities? The ethernet MIB supports both full-duplex
   and half-duplex ethernet, yet I want both 'ethernet' and
   'full-duplex-ethernet' as capabilities. Which capability does the
   base OID represent?

   What about a table that's been implemented yet the underlying
   feature isn't available. If I pull all diffserv-capable cards out
   of a router, does the diffserv table disappear? (in other words,
   does the MIB fate-share with the capability?) If the
   diffserv-capable cards are unplugged I need capMatch() to return
   false so that I can try a different mechanism, yet it seems like
   this could come in conflict with the mandate to describe the 
   implementation of the diffserv MIB. This really raises the question
   as to whether we're describing the capabilities of an agent or the 
   capabilities of the managed system. I think the answer needs to be 
   the latter.

   What if we have a capability for which there's no MIB defined yet?

   What does a capability of mib-2.etherMIB mean? What are the minimal
   acceptable requirements of claiming etherMIB as a capability? Where
   is it written? (it isn't written in the ether MIB unless you're just
   talking about MIB objects and that's insufficient). BTW, which
   version of the etherMIB are we referencing anyway?

   I think we should view capabilities as things like:
     ethernet
     full-duplex ethernet
     Unix
     diffserv
     802
     TailDropper
     HeadDropper
     WeightedFairQueueing
     ...

   Not all of these are going to map to MIBs or tables. The
   granularity is often different.

   I think the modelling process should be:
     - Decide which capabilities are important to policy-writers
     - Decide what the capability conceptually is
     - Define what it means to have that capability (this isn't
       clarified by a pointer to a MIB)
     - Decide what OID to use (a MIB or table OID might be perfectly
       fine, so is an OBJECT IDENTITY)

2. (Special case of above, but particularly heinous): If the router is
   diffserv capable but interface #7 isn't, I need
   capMatch('diffserv') to return false for interface #7 even if it
   returns true for all other interfaces. In this case the agent has
   the capability but the element doesn't. Are we going to describe
   agent caps on an element-by-element basis?

3. There has to be an agreement by all implementors not only on what
   OID to use, but also on the list of capabilities and that if you
   don't advertise a capability then you don't have it. We can't have
   a situation where no mention might mean 'no comment'.

   The way the pmCapabilitiesModification* stuff is set up there's no
   mandate at what you have to declare as a modification. There's no
   way to depend on a vendor to declare stuff they don't do. There's
   no way to know whether lack of TailDrop is handled as a
   modification to diffServAlgDropType or as a discrete OID. Maybe
   the vendor has a TailDrop table and they advertise this feature by
   referencing its OID.

   Note that Agent Caps isn't used (or useful) because vendors don't
   want to go out of their way to admit what they don't do. I don't
   expect that to change here.

4. What do I do when a particular capability is linked with a table
   that has dozens of modifications? The table isn't well structured
   for that. There are many columns that would be needlessly and
   confusingly repeated.

5. Filling out the modifications ends up in way, way more granularity
   than we want in a capabilities table. The only reason something
   MUST be a capability is so that we can conditionally download a
   policy based on it. Capabilities MAY also be helpful in rolling up
   things so that a filter doesn't need to inspect mib objects to
   figure it out. But policies are not going to be replaceable with
   this level of granularity ("the agent doesn't support retrievals of
   ifOutNUCastPkts, so download the version of the policy that doesn't
   use ifOutNUCastPkts" - not likely).

   There's also no way for the implementor of the caps table to know
   how to judge whether or not a particular deviation rises to the
   right granularity or not.

6. The capMatch function only matches the pmCapabilitiesType object so
   the rest is a no-op anyway. And if we were to try to fix this the
   capMatch function would become hopelessly complicated.

7. (Minor) What is the "base oid"? Is it ifEntry, ifTable, interfaces,
or
   mib-2? What if vendor A advertises ifTable and vendor B advertises
   ifEntry?

My suggestion is that we pare down the capabilities table to just:

PmCapabilitiesEntry ::= SEQUENCE {
    pmCapabilitiesIndex              Unsigned32,
    pmCapabilitiesType               OBJECT IDENTIFIER
}

and that we define capabilities such that the following are natural
examples:
     ethernet
     full-duplex ethernet
     Unix
     diffserv
     802
     TailDropper
     HeadDropper
     WeightedFairQueueing
     ...

We'll also need to start soon defining what the initial set of standard
capabilities should be.

Steve