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

From: [email-masked]
Date: Fri, 07 Mar 2003 06:54:42 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: Management Information Base for Session Initiation 
                          Protocol
	Author(s)	: K. Lingle, J. Maeng, J. Mule, D. Walker
	Filename	: draft-ietf-sip-mib-05.txt
	Pages		: 97
	Date		: 2003-3-6
	
This memo defines a portion of the Management Information Base (MIB) 
for use with network management protocols in the Internet community.  
In particular, it describes a set of managed objects that are used 
to manage Session Initiation Protocol (SIP) entities, which include 
User Agents, Proxy servers, Redirect servers and Registrars.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sip-mib-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-mib-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 14 Mar 2003 15:02:57 -0500

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.

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. 
My suspicion is that this kind of information will normally be logged by 
implementations, and when you need it, its not in real time, but rather 
through some kind of offline analysis of the logs.

Generally, it is my perception that MIB status variables are primarily 
aimed at fault and performance analysis. I dont see how a full list of 
each transaction, with the call-id, cseq and all, supports either aim.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Kevin Lingle <[email-masked]>
Date: Tue, 18 Mar 2003 09:43:04 -0500

jonathan,

thanks for your comments.  please send more if you have them.
my comments inline below...

> 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.  if not, are there
other statistics that you feel fall into the category or
exposing far too much information?

> 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.  
i'd rather do that than to yank the table w/out further 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.

kevin

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 19 Mar 2003 00:03:23 -0500

Kevin Lingle wrote:

> to your comment on sipTransactionTable below or not. 

Yes.

> if not, are there

I want to look some more and provide some additional comments.

> 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.

> 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.

---

From: Kevin Lingle <[email-masked]>
Date: Wed, 19 Mar 2003 10:40:17 -0500

> I want to look some more and provide some additional comments.

that would be great.

> 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

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.

> *This* is the discussion.

agreed.

> to monitor the current set of transactions held in the system. Thus, I

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 <[email-masked]> 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 <[email-masked]> 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

---

From: "Cullen Jennings" <[email-masked]>
Date: Sun, 23 Mar 2003 23:05:18 -0800

I'm wondering about actual implementation experience with the SIP MIB. Has
anyone implemented any version or portion of it? Any operational experience
folks could provide on what turned out to be useful?

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Friday, March 07, 2003 3:55 AM
> To: IETF-Announce:
> Cc: [email-masked]
> Subject: [Sip] I-D ACTION:draft-ietf-sip-mib-05.txt
>
>