[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] I-D ACTION:draft-ietf-sip-mib-05.txt
We too have sip-mib implementation in our product.
Following is my view with respect to sipTransactionTable:
1. Maintaining this table info in the system is not
'simple and straight forward'.
Reason: Data involved are very volatile.
Moreover it requires indexing the transactions which
themselves are volatile (destroyed any time).
2. This information is usually obtained (if et-all obtained!)
will be via GET-BULK operation. To support GET-BULK to
retrieve information specific to all transactions
has momentory performance impact on the Server.
There are issues of thread-safety between GET-BULK
and the transaction handling operation.
3. Same information can be obtained either through
protocol trace logs or CDR (call detail records).
I feel sip-mib should not have tables involving volatile data.
I also feel sipCurrentTransTable is not useful.
May be TRAP objects based on sipCurrentTransTable, will be
more useful to SNMP admin.
I think sip-mib has captured very elaborately on following things.
1. Server Administration/Configuration
2. User data management
3. Statistics
I really appreciate the above factor.
I have some comments on following MIB fields, please
clarify them as my understanding may differ from the
auther's of sip-mib.
1. "sipMaxSessions" of SipCommonCfgEntry:
This is a READ-ONLY property supplied by the
SIP-ENTITY. As per the definition the entity
has to determine what is the maximum load it
can handle.
Again, the above factor depends on the
hardware/software configuration of the deployment
platform. Do we expect for instance a SIP-Proxy
to run some algorithm/load itself to find out
this value?
I feel this field may not be useful.
2. "sipTransportSnd" of SipPortEntry: I donot
understand how this field is utilized in SIP,
specific to a port number.
"sipTransportRcv" can be understood as for
associated port number the SIP entity will
receive message for TRANSPORTS that are
enabled in this field.
3. "sipPgpVersion" of SipServerCfgEntry,
"sipPgpPrivateKey" of SipProxyCfgEntry:
PGP is deprecated in SIP. Can these be removed?
There may be more things specific to PGP.
4. "sipServerRespectUAAction" of SipServerCfgEntry:
This mentions action parameter specific operation
in the proxy which is deprecated in SIP.
Can we deprecate here also?
5. "sipRegMaxUsers" of "SipRegCfgEntry":
This is a READ-ONLY field which is supposed
to be given out by REGISTRAR as what is the
number of users does it support.
Again, what is the criteria with which registrar
arrives at this data. This data again depends on
deployment platform such as capacity of the
database etc. This data too may not be useful
to administrator. This value is either known
to the admin or enforced by admin on REGISTRAR.
Therefore keeping it as READ-ONLY has no purpose.
6. "sipContactAction" of SipContactEntry:
Again deprecated by SIP. Can we deprecate here too?
7. "sipContactRetryAfter" of SipContactEntry:
Again deprecated by SIP. Can we deprecate here too?
8. Transaction timer specific configuration are based
on pre-bis05 drafts. They have to be updated
according to latest RFC. I think action-item is already
initiated for post mib-05 drafts.
Thanks and Regards,
Shrinivas Shetti
Kevin Lingle <klingle@cisco.com> on 03/19/2003 09:10:17 PM
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
cc: sip@ietf.org, Dave Walker <drwalker@ss8networks.com> (bcc: Shrinivas
Shetti/HSSBLR)
Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-mib-05.txt
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
_______________________________________________
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