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

Re: Agent Capabilities and sysORTable


Reasons why AGENT-CAPs are not used:
1) there are no examples in IETF documents (other than RFC 2580),
     and so engineers have nothing from which to cut, paste,
     adapt, and publish
2) agent-caps have problems - there is a missing level of indirection,
     some of the clause don't make sense, etc
3) it is difficult to create correct ones
4) the value of them has not been shown
5) agent-caps don't provide all the information needed for an application
     to determine if it will interoperate with an agent. Thus, human
     directed testing is needed anyway, so no value having agent-caps.

At 09:19 AM 4/17/2001 -0400, Thomas, Steven C (Steve) wrote:
>Hey all,
>I need some help understanding here...
>When I first saw the Charter discussing capabilities, I thought this might
>be related to the agent capabilities addressed in the sysORTable.  Since
>then I understand that this part of the eos charter is referring to protocol
>capabilities.  However, having the agent document its MIB capabilities would
>be desirable also.
>My question is:  Why don't most agents (I haven't found any so far)
>implement or at least populate the sysORTable?  Is there some hidden
>difficulty in implementing it on the agent side?  Or have I misunderstood
>the purpose of sysORTable?
>My comment is: If the agents don't bother to populate the sysORTable to
>document their agent MIB capabilities, why would we expect them to populate
>some other MIB documenting protocol capabilities?  We need to understand the
>dynamics in order to overcome them.
>I am not arguing that the protocol capabilities MIB or mechanism isn't
>needed, but I am cautious considering my experience so far with sysORTable.

/david t. perkins