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

From: "Jean-Francois Mule" <[email-masked]>
Date: Fri, 31 Mar 2006 07:42:19 -0700

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. 

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

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

> 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

---

From: "Samir Srivastava" <[email-masked]>
Date: Fri, 31 Mar 2006 13:17:19 -0600

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,

Jean-Francois
---
Jean-François Mulé
[email-masked] 

Samir Srivastava wrote:
> something ?

SS>> Shouldn't 3014 referred somewhere ?

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.

> might be addressing 3261, it is a new requirement developing. So I am 
> not that much concerned on this.

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.

> WG to consider the following document:
>