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

[Kevin Lingle <klingle@cisco.com>]

Jonathan Rosenberg wrote:
> 
> Kevin Lingle wrote:
> 
> >>I have begun to look at the mib a bit, and I am a bit concerned that
> >>there is far too much information exposed, in terms of statistics, at
> >>least. I have to apologize for raising this so late in the game, but it
> >>is only recently that my day job has brought me into OAMP areas.
> >
> >
> > not sure if the above reference to statistics is directly related
> > to your comment on sipTransactionTable below or not.
> 
> Yes.
> 
> > if not, are there
> > other statistics that you feel fall into the category or
> > exposing far too much information?
> 
> I want to look some more and provide some additional comments.

that would be great.

> 
> >
> >
> >>One item that struck me as particularly demanding on an implementation
> >>is the sipTransactionTable. There is a huge amount of work in
> >>maintaining this table. I really doubt people will want to implement it.
> >
> >
> > i had similar feedback from others when support of the sipTransactionTable
> > was being considered by a project.    the effort involved in supporting
> > the table was a problem.
> >
> > we can focus some discussion on the viability of the table during wg last call.
> 
> Well, discussion can happen any time. Its happening now, in this email
> thread. I dont know what else you are expecting. 

sorry.  didn't mean to imply what came across.  we can definitely discuss
it now.  i'm just not used to actually having active discussion of the mib.
i'm used to getting one or two sporatic comments and only having focused
discussion during last call - when someone is forced to review the mib ;)

> I don't think the table
> is viable. You had similar feedback. Seems like a clear cut resolution
> to me.

not that i don't take your point of view as very significant, i do.  
i was hoping that others might concur before we decide to remove the table.
the table has been in every revision of the mib, so it has been reviewed
multiple times by multiple people... no one - until now has recommended it
come out.   i guess i had taken that as acceptance of it's potential usefulness
to someone.  my case of one project finding it questionable does not necessarily
make a case for it's removal.   we determined that support was feasible but
not all that useful for our platform.  

implementation experience with a mib usually decides such things and we don't 
have much (any?) feedback in that area (not likely to until the mibs are in an
rfc).   still, if we can resolve the question of usefulness now it would be
better than 
to have to revise the mib (ie, rfc) and deprecate objects found - through 
implementation experience - to be useless.

> 
> > i'd rather do that than to yank the table w/out further discussion.
> 
> *This* is the discussion.

agreed.

> 
> > at the very least, we can definitely make the table optional.
> > right now it appears to be in a mandatory group - which seem wrong to me anyway.
> 
> Mandatory is definitely wrong. I am not even sure optional is useful.
> 
> 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.
> 
> I cannot think of a reason that I would want, from an operations center,
> to monitor the current set of transactions held in the system. Thus, I
> think it should be out.

it's hard for me to justify or defend the existence of this table as i
was not the original author of it.  but for the sake of discussion...

is there no value from a troubleshooting perspective?   you mentioned that
this information is likely logged for offline analysis - not real-time.
are transactions generally occuring too fast for real-time analysis to
be of worth?   it would seem to me that unless you know specifically which
transactions are of interest to you, it would be hard to use this table
for anything.  the table is defintely not a logging mechanism as transactions
will not persist for any historically significant time.

from a performance mgmt point of view...
could the increase in entries in this table be used to gain insight into
congestion in this or other parts of the sip network?   even if that were
the case, the simple sipCurrentTransactions gauge object would provide
similar insight (to congestion at least).   perhaps the to/from details 
in the table would lend some more insight to problems elsewhere in the
network?   i'm not sure.   

dave walker was the original author of this table, so maybe
he can offer some insight.  dave? 
i did find one old comment related to this table squirreled away in some 
old emails....

Kurt Robohm <kurt@mci.net> wrote:
> 
> sipCurrentTransacations         Does this reflect number of
>                                 calls in progress?
>                                 Intent of objects in table to
> sipTransactionTable             provide real time info on
>                                 number of calls being handled
>                                 real time?

Dave Walker <drwalker@ss8networks.com> responded:
> Transactions aren't calls.  The intent, as mentioned in Adelaide,
> is to evolve the transaction table to a call leg table (probably 
> for UAs only).  This hasn't been resolved yet, so no real changes 
> were made.


i can't find any further discussion by dave (or others) in subsequent 
revisions of the draft to work out any further evolution of this table.  
only minor comments related to the table - none questioning its existence.
dave's involvement in the last couple of revisions of the draft have been nil.
so perhaps the table is an articfact of an idea that was not fully
conceived or fleshed out.  that would lend itself to removal imo.

kevin
> 
> Is not our aim to take things out of protocols until we can't take out
> any more, rather than the other way around?
> 
> -Jonathan R.
> 
> --
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> 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

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Kevin R. Lingle       919.392.2029
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
_______________________________________________
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