RE: [Sip] I-D ACTION:draft-ietf-sip-mib-05.txt

["Romascanu, Dan (Dan)" <dromasca@avaya.com>]

There is a delicate balance to be looked for here. I doubt that 'every piece pf state' is useful information, both on grounds of resources, as well quantity of information that needs to be processed. SNMP agents run on the same hosts that run protocols, and the management information carried from SNMP agents to SNMP clients (managers) competes for bandwidth with other data traffic. When designing a MIB one needs to take into account that in order for the MIB to be useful, it needs to run in the context of the host and application resources, and that the management traffic that is generated needs to be a reasonable fraction of the traffic of the protocol or application that is being managed. In the context of the current discussion it looks to me that large state or session tables should be avoided, with more compact indications, or threshold based alarms being put in place instead.

Dan


> So - here is the question. What is the bar for putting 
> something in the 
> MIB? At one extreme, every piece of state managed by a server 
> could be 
> in the mib. At the other extreme, there is nothing, or a 
> single summary 
> statistic. I think a reasonable bar, is that there should be 
> clear value 
> in monitoring that information, from the perspective of fault and 
> performance management in particular. If you cannot 
> demonstrate such a 
> use, it should be out.
> 
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip