Subject: Re: [Sip] sip-mib: removal of sipStatusCodeClassesTable

From: Cullen Jennings <[email-masked]>
Date: Thu, 02 Oct 2003 14:44:03 -0700

One tiny comment on this ....

A 407 may not be an indication that anything bad is happening. I'm not sure
there is much use in grouping all the 4xx together.

Cullen

On 9/26/03 6:38 AM, "Kevin Lingle" <[email-masked]> wrote:

> additionally...
> 
> recently i was cc'd on an email where one developer
> asked another for a list of statistics that could be
> used as a measure of the health/well-being of a sip
> proxy.    the developer responded in terms of the sip
> stats we have in the sip-common-mib and said the following
> about some objects from the sipStatusCodeClassesTable:
> 
> -----
> Successful responses - When calls are successful, these counters
> should be going up.
> 
>    sipStatsSuccessClassIns       Counter32, /* 200 OK response */
>    sipStatsSuccessClassOuts      Counter32,
> 
> Failure responses - A very high value for these counters indicates
> calls failing in the network. Typically, if calls are not failing,
> these counters should have low values and increment slowly.
> 
>    sipStatsReqFailClassIns       Counter32, /* 4XX class errors */
>    sipStatsReqFailClassOuts      Counter32,
>    sipStatsServerFailClassIns    Counter32, /* 5xx class errors */
>    sipStatsServerFailClassOuts   Counter32,
>    sipStatsGlobalFailClassIns    Counter32, /* 6xx class errors */
>    sipStatsGlobalFailClassOuts   Counter32,
> --------
> 
> so i chimed in saying that there was a proposal to
> remove this table from the mib.  if that were to
> occur, was there a small subset of individual rsp code
> counters that could be polled in order to draw
> the same conclusion on failures.
> 
> the answer i got back was that all of the individial
> 4xx,5xx,6xx counters.  a subset of "important" counters
> really wasn't feasible.
> 
> if that is the case, then aren't these per class stats
> potentially of use in quickly gauging whether a sip system
> may be experiencing problems that warrent further investigation?
> 
> kevin
> 
> 
> Kevin Lingle wrote:
>> hi all,
>> 
>> a proposal in on the table to remove this table from
>> the SIP-COMMON-MIB.  cullen was the only one of the reviewers
>> who raised this issue explicitly.  i wanted to give others a
>> chance to comment on it.
>> 
>> orit, did allude to there being too many counters and suggested
>> removal of some summary counters.  he didn't mention this table
>> by name though (i don't think).
>> 
>> these are "summary counters", but were defined this way to give
>> a high level (gross) indicator of problems so a manager could
>> to and probe a system further for the details.  working at a
>> more granular level of rsp code counters would require more polling
>> on the part of snmp managers.  that was the thought behind providing
>> these aggregate counters.
>> 
>> http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-07.txt
>> 
>> comments?
>> 
>> kevin
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Kevin Lingle <[email-masked]>
Date: Fri, 03 Oct 2003 13:13:13 -0400

> there is much use in grouping all the 4xx together.

cullen,

do i detect, in this comment, that perhap you could see usefulness in
any of the other classes ;) (eg, 6xx);  or do you still essentially want
the entire table removed?

it would be good to hear the views of others (assigned reviewers especially).

i don't have any great attachement to the table.  i was ready to remove it
based on cullens original comments and then i got feed back (below)
with a point of view supporting the concept behind this table.

if i don't here any other support for the table, then i'll remove it from the mib.

kevin

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Kevin R. Lingle       919.392.2029
  http://www.klove.com                               http://www.air1.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 15 Oct 2003 12:16:14 -0700

I was suggesting considering removing the whole thing but don't have a super
strong opinion. I'm all for making the MIB as simple as possible to
implement while still providing the relevant information. This aggregated
table might make it easier to use the mib but does not have any extra
information that is not available some other way in the MIB. I'm always
worried about providing the same data two ways and try to provide the data
at the most atomic level.

---

From: Kevin Lingle <[email-masked]>
Date: Fri, 17 Oct 2003 16:19:56 -0400

cullen,

understood.  as no one else has stood up as an advocate for
keeping the table, i'll plan on removing it.

kevin