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

Re: snmpconf Issue #18 resolution - Update capabilities table



> 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.

(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.
> 
> 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.

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).

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

Thanks
/jon
> 
> 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
> 

Thanks,
/jon
--

Jon Saperia		     saperia@jdscons.com
			     Phone: 617-744-1079
			     Fax:   617-249-0874
			     http://www.jdscons.com/