Subject: RE: [Sip] Last Call: 'Management Information Base for the SessionInitiation Protocol (SIP)' to Proposed Standard

From: "Jean-Francois Mule" <[email-masked]>
Date: Mon, 3 Apr 2006 04:00:55 -0600

Samir,

   See more discussion inline. 
   Based on my understanding of your comments and your follow-up response, it seems that the 3 comments are closed. 
 
   To summarize:
--- 1. re: logging of SIP mib notifications using RFC 3014
You wrote:
> SS>> Shouldn't 3014 referred somewhere?
In short, my preference would be to not reference it in the SIP mib.
Note that your comment is applicable to any protocol MIB module that defines SNMP notifications. For this reason, a reference to generic MIB mechanisms could either be added to all MIBs (via the standard MIB boilerplate), or, it should be added on a case by case basis based on the scope of a given MIB module. It is not in the MIB boilerplate and based on the scope of the SIP MIB and the limited notifications we define in it, I would rather not recommend we add a new paragraph on how to log SNMP notifications (even as an informative reference). 
To me, if you open the broader requirement of how does a SIP implementation deal with logging management events on a device, you have to look at events that can be generated globally and the SIP application, above and beyond SNMP, and be prepared to discuss things that get logged via syslog, local file logs, etc.
Finally, folks who develop on SNMP agent and look at SNMP implementations are usually aware that they can use a bunch of other MIB modules to complement a pure protocol MIB (host mib, notification log and btw - all or some of the other mibs coming out of the disman wg, etc.)

--- 2. use of 'congested'
Ok - we will stick with the name *and* definition of 'congested' as defined in the Network Services MIB.

--- 3. expanding the definition of 'congested' based on sipping overload ID (draft-rosenberg-sipping-overload-reqs-00.txt)
Thanks for elaborating on your comment. 
My view on this comment is that 
	a) the SIP MIB as defined as capable of handling the RFC 3261 "very basic support for overload" as dicussed in section 3 of draft-rosenberg-sipping-overload-reqs-00.txt. ('congested' -> 503 or 5xx)
	b) once the overload requirements are stable, and new semantics are defined for handling overload, the MIB object sipServiceOperStatus could well be extended to add new values that could reflect the new behaviors an app can adopt under overload. 
So, based on the above, I would recommend we wait until the requirements in draft-rosenberg-sipping-overload-reqs-00.txt are stable, potential new mechanisms for dealing with overload are defined and see how this should be translated to reflect the operational status of a sip app through mgmt.

Is that ok?  

Jean-François

> -----Original Message-----
> From: Samir Srivastava [mailto:[email-masked]]
> Sent: Friday, March 31, 2006 12:17 PM
> To: Jean-Francois Mule
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [Sip] Last Call: 'Management Information Base for the
> SessionInitiation Protocol (SIP)' to Proposed Standard
> 
> Hi Jean-Francois,
> 
>    See in line.
> 
> Thx
> Samir
> 
> -----Original Message-----
> From: Jean-Francois Mule [mailto:[email-masked]]
> Sent: Friday, March 31, 2006 6:42 AM
> To: Srivastava, Samir [SC100:8826:EXCH]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [Sip] Last Call: 'Management Information Base for the
> SessionInitiation Protocol (SIP)' to Proposed Standard
> 
> Samir,
> 
>    Thank you for your comments - see responses inline.
> 
>    I removed the IETF-Announce recipient from the response to limit
> spam; if it should be added back, feel free to forward or add it back.
> 
> Jean-Francois
> ---
> Jean-François Mulé
> [email-masked]
> 
> 
> Samir Srivastava wrote:
> > -----Original Message-----
> > From: Samir Srivastava [mailto:[email-masked]]
> > Sent: Friday, March 31, 2006 2:45 AM
> > To: [email-masked]; IETF-Announce
> > Cc: [email-masked]
> > Subject: RE: [Sip] Last Call: 'Management Information Base for the
> > SessionInitiation Protocol (SIP)' to Proposed Standard
> >
> > Hi,
> >
> > 1.   It defines Object sipNotifSequenceNumber. It is defined for
> > Manager
> > to find a missing / out of
> > sequence NOTIFICATION. Why not NOTIFICATIONS are stored in a table ?
> > If
> > Manager looses a notification, it cannot find which one is lost.
> > Manager
> > might poll this sequence, if it finds something missing, it can
> fetch
> > from the table. If it is missing the latest Notification, then it is
> > very important for the determining server health. Am I missing
> > something ?
> See the Notification Log MIB (RFC 3014) for a generic mechanism that
> can be used for recording notification information. It can be used in
> conjunction with the SIP MIB to store or log specific SIP MIB
> notifications, hence addressing your question.
> 
> SS>> Shouldn't 3014 referred somewhere ?
> 
> > 2.  It defines "congested" as one of the value for
> > sipServiceOperStatus.
> > IMHO, Congestion is network property. It should be "overloaded" .
> > Overload is server CPU stuff. If SIP server is finding congestion
> also
> > based on retransmission etc, then shouldn't we have these two as
> > distinct values.
> See the I-D section on the relationship with other MIB modules and the
> Network Services MIB (RFC 2788) in particular.
> RFC 2788 defines an applOperStatus object for the operational status
> of the network service application with a valid value of congested(4),
> hence the re-use of congested in the SIP MIB module.
> 
> 
> SS>> This I am leaving to working group to decide where it should be
> fixed. For the future overload and congestion work, this looks to me
> confusing and we should separate these two.
> 
> > 3. As of now we know binary representation of overload/congestion is
> > problem ? Shouldn't we have variable with % of overload. This MIB
> > might be addressing 3261, it is a new requirement developing. So I
> am
> > not that much concerned on this.
> 
> I am not sure I get the point of your third comment, or the actual
> requirement behind the proposed "variable with % of overload". But if
> you are not much concerned on this, given that this version of the MIB
> has undergone numerous revisions to address wg comments, completed
> WGLC, and passed mib doctor review, I would recommend we do not
> increase the scope of this version of the MIB module at this time.
> 
> SS>> Refer the draft
>  http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-overload-
> reqs-00.txt
>  Section 5, page 11, REQ 7.
> 
> And it was accepted widely and work needs to be continued on this.
> Even if, we don't take this path, a separate object with % overload is
> good enough. If we retain the binary nature, then it will be
> 0 or 1 value.
> 
> >
> > Thx
> Thank you. The above responses should address your comments; if not,
> please elaborate or explain.
> 
> > Samir
> >
> >
> >
> > -----Original Message-----
> > From: The IESG [mailto:[email-masked]]
> > Sent: Thursday, March 23, 2006 12:59 PM
> > To: IETF-Announce
> > Cc: [email-masked]
> > Subject: [Sip] Last Call: 'Management Information Base for the
> Session
> > Initiation Protocol (SIP)' to Proposed Standard
> >
> > The IESG has received a request from the Session Initiation Protocol
> > WG to consider the following document:
> >
> > - 'Management Information Base for the Session Initiation Protocol
> > (SIP)
> > '
> >    <draft-ietf-sip-mib-10.txt> as a Proposed Standard
> >
> > The IESG plans to make a decision in the next few weeks, and
> solicits
> > final comments on this action.  Please send any comments to the
> > [email-masked] or [email-masked] mailing lists by 2006-04-06.
> >
> > The file can be obtained via
> > http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-10.txt
> 
> 
> 

_______________________________________________
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