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

Re: snmpconf Issue #18 resolution - Update capabilities table

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.

Joel M. Halpern

At 07:27 AM 4/23/01 -0400, David Harrington wrote:
>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
>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.
>David Partain wrote:
> >
> > 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                  David.Partain@ericsson.com
> > 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
>David Harrington            Network Management Standards Architect
>dbh@enterasys.com           Office of the CTO
>+1 603 337 2614 - voice     Enterasys Networks
>+1 603 332 1524 - fax       Rochester NH, USA