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

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




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.


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. I don't think the table is viable. You had similar feedback. Seems like a clear cut resolution to me.

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

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.

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