[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] I-D ACTION:draft-ietf-sip-mib-05.txt
thanks for all of the input wrt sipTransactionTable.
consider the table removed from the mib. i plan on
keeping the sipCurrentTransactions gauge object but will
make it part of an optional group.
shrinivas,
thanks for you other comments. i'll go through them soon.
kevin
sshetti@hss.hns.com wrote:
>
> 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
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
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