From keith.drage@alcatel-lucent.com Mon Nov 5 05:47:40 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1620F21F8619 for ; Mon, 5 Nov 2012 05:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.916 X-Spam-Level: X-Spam-Status: No, score=-107.916 tagged_above=-999 required=5 tests=[AWL=-1.666, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svRBRMmuiqJd for ; Mon, 5 Nov 2012 05:47:39 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE8A21F8606 for ; Mon, 5 Nov 2012 05:47:39 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qA5DkWXK019925 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 5 Nov 2012 14:47:37 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 5 Nov 2012 14:47:19 +0100 From: "DRAGE, Keith (Keith)" To: "sip-overload@ietf.org" Date: Mon, 5 Nov 2012 14:47:17 +0100 Thread-Topic: Overload and emergency Thread-Index: Ac27XBGk8UY7OF/RTOG+2agRF0Hy5w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: [sip-overload] Overload and emergency X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 13:47:40 -0000 For emergency, draft-ietf-soc-overload-control-10 A SIP client SHOULD honor the local policy for prioritizing SIP requests such as policies based on the content of the Resource- Priority header (RPH, RFC4412 [RFC4412]). Specific (namespace.value) RPH contents may indicate high priority requests that should be preserved as much as possible during overload. The RPH contents can also indicate a low-priority request that is eligible to be dropped during times of overload. Other indicators, such as the SOS URN [RFC5031] indicating an emergency request, may also be used for prioritization. And for draft-ietf-soc-load-control-event-package-05 In addition, whatever the actual policy is, SIP servers SHOULD honor the local policy for prioritizing SIP requests such as policies based on the contents of the Resource-Priority Header (RPH) [RFC4412]. The RPH contents may indicate high priority requests that should be preserved as much as possible, or low priority requests that could be dropped during overload. Other indicators, such as the SOS Uniform Resource Name (URN) [RFC5031] indicating an emergency request, may also be used for prioritization. SIP request rejection and message prioritization at an overloaded server are also discussed in Section 5.10 of [I-D.ietf-soc-overload-control] and Section 12 of [RFC6357]. Prioritisation of emergency is under exactly the same sort constraints as p= riority, therefore in both these drafts I would like to see exactly paralle= l specification to priority. A SIP client SHOULD honor any local policy for prioritizing SIP requests such as policies based on the content of the Resource- Priority header (RPH, RFC4412 [RFC4412]). Specific (namespace.value) RPH contents may indicate high priority requests that should be preserved as much as possible during overload. The RPH contents can also indicate a low-priority request that is eligible to be dropped during times of overload. =20 A SIP client SHOULD honor any local policy for prioritizing SIP=20 requests relating to emergency calls, as identified by the SOS=20 URN [RFC5031] indicating an emergency request. While only some countries require priority for emergency, those that do wan= t this adequately specified. Note that in the load control document, this does need to be separate parag= raphs. Keith From jgunn6@csc.com Mon Nov 5 06:37:20 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E987621F871F; Mon, 5 Nov 2012 06:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.467 X-Spam-Level: X-Spam-Status: No, score=-5.467 tagged_above=-999 required=5 tests=[AWL=1.131, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7t3V66I6hRum; Mon, 5 Nov 2012 06:37:20 -0800 (PST) Received: from mail87.messagelabs.com (mail87.messagelabs.com [216.82.250.19]) by ietfa.amsl.com (Postfix) with ESMTP id EED5221F8720; Mon, 5 Nov 2012 06:37:19 -0800 (PST) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-4.tower-87.messagelabs.com!1352126238!15653063!1 X-Originating-IP: [20.137.2.87] X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25892 invoked from network); 5 Nov 2012 14:37:19 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-4.tower-87.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Nov 2012 14:37:19 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qA5EbGAU006361; Mon, 5 Nov 2012 09:37:17 -0500 In-Reply-To: References: To: "DRAGE, Keith (Keith)" MIME-Version: 1.0 X-KeepSent: F0F38980:013B4E62-85257AAD:004DDF31; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Mon, 5 Nov 2012 09:37:16 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 11/05/2012 09:32:47 AM, Serialize complete at 11/05/2012 09:32:47 AM Content-Type: multipart/alternative; boundary="=_alternative 0050512285257AAD_=" Cc: sip-overload-bounces@ietf.org, "sip-overload@ietf.org" Subject: Re: [sip-overload] Overload and emergency X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 14:37:21 -0000 This is a multipart message in MIME format. --=_alternative 0050512285257AAD_= Content-Type: text/plain; charset="US-ASCII" Keith, I agree we should have the same wording in draft-ietf-soc-overload-control soc-load-control-event-package also draft-ietf-soc-overload-rate-control But I do have one concern with your proposed new wording. Both versions of the current wording give RPH and SOS as examples of "local policy" which may prioritize which SIP messages don't get drops. However, they are only examples, and do not preclude other local policies. For instance I have understood "drop new INVITES before you drop messages associated with already established sessions" to be another example of "local policy". But it isn't explicitly mentioned in that text. Some of the documents mention it elsewhere. Perhaps " A SIP client SHOULD honor any local policy for prioritizing SIP requests such as policies based on message type, e.g., INVITEs vs. requests associated with existing sessions. A SIP client SHOULD honor any local policy for prioritizing SIP requests based on the content of the Resource- Priority header (RPH, RFC4412 [RFC4412]). Specific (namespace.value) RPH contents may indicate high priority requests that should be preserved as much as possible during overload. The RPH contents can also indicate a low-priority request that is eligible to be dropped during times of overload. A SIP client SHOULD honor any local policy for prioritizing SIP requests relating to emergency calls, as identified by the SOS URN [RFC5031] indicating an emergency request." That puts RPH and the SOS URN on the same level, and makes the use of "INVITEs" vs, "existing sessions" an explicit example. Janet From: "DRAGE, Keith (Keith)" To: "sip-overload@ietf.org" Date: 11/05/2012 08:47 AM Subject: [sip-overload] Overload and emergency Sent by: sip-overload-bounces@ietf.org For emergency, draft-ietf-soc-overload-control-10 A SIP client SHOULD honor the local policy for prioritizing SIP requests such as policies based on the content of the Resource- Priority header (RPH, RFC4412 [RFC4412]). Specific (namespace.value) RPH contents may indicate high priority requests that should be preserved as much as possible during overload. The RPH contents can also indicate a low-priority request that is eligible to be dropped during times of overload. Other indicators, such as the SOS URN [RFC5031] indicating an emergency request, may also be used for prioritization. And for draft-ietf-soc-load-control-event-package-05 In addition, whatever the actual policy is, SIP servers SHOULD honor the local policy for prioritizing SIP requests such as policies based on the contents of the Resource-Priority Header (RPH) [RFC4412]. The RPH contents may indicate high priority requests that should be preserved as much as possible, or low priority requests that could be dropped during overload. Other indicators, such as the SOS Uniform Resource Name (URN) [RFC5031] indicating an emergency request, may also be used for prioritization. SIP request rejection and message prioritization at an overloaded server are also discussed in Section 5.10 of [I-D.ietf-soc-overload-control] and Section 12 of [RFC6357]. Prioritisation of emergency is under exactly the same sort constraints as priority, therefore in both these drafts I would like to see exactly parallel specification to priority. A SIP client SHOULD honor any local policy for prioritizing SIP requests such as policies based on the content of the Resource- Priority header (RPH, RFC4412 [RFC4412]). Specific (namespace.value) RPH contents may indicate high priority requests that should be preserved as much as possible during overload. The RPH contents can also indicate a low-priority request that is eligible to be dropped during times of overload. A SIP client SHOULD honor any local policy for prioritizing SIP requests relating to emergency calls, as identified by the SOS URN [RFC5031] indicating an emergency request. While only some countries require priority for emergency, those that do want this adequately specified. Note that in the load control document, this does need to be separate paragraphs. Keith _______________________________________________ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload --=_alternative 0050512285257AAD_= Content-Type: text/html; charset="US-ASCII"

Keith,

I agree we should have the same wording in
draft-ietf-soc-overload-control
soc-load-control-event-package
also
draft-ietf-soc-overload-rate-control

But I do have one concern with your proposed new wording.

Both versions of the current wording give RPH and SOS as examples of "local policy" which may prioritize  which SIP messages don't get drops.  However, they are only examples, and do not preclude other local policies.  

For instance I have understood "drop new INVITES before you drop messages associated with already established sessions" to be another example of "local policy".  But it isn't explicitly mentioned in that text.  Some of the documents mention it elsewhere.


Perhaps
"   A SIP client SHOULD honor any local policy for prioritizing SIP
  requests such as policies based on message type, e.g., INVITEs vs.
   requests associated with existing sessions.
   
   A SIP client SHOULD honor any local policy for prioritizing SIP
   requests based on the content of the Resource-
  Priority header (RPH, RFC4412 [RFC4412]).  Specific (namespace.value)
  RPH contents may indicate high priority requests that should be
  preserved as much as possible during overload.  The RPH contents can
  also indicate a low-priority request that is eligible to be dropped
  during times of overload.  

  A SIP client SHOULD honor any local policy for prioritizing SIP
  requests relating to emergency calls, as identified by the SOS
  URN [RFC5031] indicating an emergency request."

That puts RPH and the SOS URN on the same level, and makes the  use of "INVITEs" vs, "existing sessions" an explicit example.

Janet




From:        "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To:        "sip-overload@ietf.org" <sip-overload@ietf.org>
Date:        11/05/2012 08:47 AM
Subject:        [sip-overload] Overload and emergency
Sent by:        sip-overload-bounces@ietf.org



For emergency, draft-ietf-soc-overload-control-10

  A SIP client SHOULD honor the local policy for prioritizing SIP
  requests such as policies based on the content of the Resource-
  Priority header (RPH, RFC4412 [RFC4412]).  Specific (namespace.value)
  RPH contents may indicate high priority requests that should be
  preserved as much as possible during overload.  The RPH contents can
  also indicate a low-priority request that is eligible to be dropped
  during times of overload.  Other indicators, such as the SOS URN
  [RFC5031] indicating an emergency request, may also be used for
  prioritization.

And for draft-ietf-soc-load-control-event-package-05

  In addition, whatever the actual policy is, SIP
  servers SHOULD honor the local policy for prioritizing SIP requests
  such as policies based on the contents of the Resource-Priority
  Header (RPH) [RFC4412].  The RPH contents may indicate high priority
  requests that should be preserved as much as possible, or low
  priority requests that could be dropped during overload.  Other
  indicators, such as the SOS Uniform Resource Name (URN) [RFC5031]
  indicating an emergency request, may also be used for prioritization.
  SIP request rejection and message prioritization at an overloaded
  server are also discussed in Section 5.10 of
  [I-D.ietf-soc-overload-control] and Section 12 of [RFC6357].

Prioritisation of emergency is under exactly the same sort constraints as priority, therefore in both these drafts I would like to see exactly parallel specification to priority.

  A SIP client SHOULD honor any local policy for prioritizing SIP
  requests such as policies based on the content of the Resource-
  Priority header (RPH, RFC4412 [RFC4412]).  Specific (namespace.value)
  RPH contents may indicate high priority requests that should be
  preserved as much as possible during overload.  The RPH contents can
  also indicate a low-priority request that is eligible to be dropped
  during times of overload.  

  A SIP client SHOULD honor any local policy for prioritizing SIP
  requests relating to emergency calls, as identified by the SOS
  URN [RFC5031] indicating an emergency request.

While only some countries require priority for emergency, those that do want this adequately specified.

Note that in the load control document, this does need to be separate paragraphs.

Keith
_______________________________________________
sip-overload mailing list
sip-overload@ietf.org
https://www.ietf.org/mailman/listinfo/sip-overload
--=_alternative 0050512285257AAD_=-- From keith.drage@alcatel-lucent.com Mon Nov 5 06:41:55 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3D021F8661 for ; Mon, 5 Nov 2012 06:41:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.677 X-Spam-Level: X-Spam-Status: No, score=-109.677 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lI0ylZFeaW8G for ; Mon, 5 Nov 2012 06:41:54 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 745D421F85B8 for ; Mon, 5 Nov 2012 06:41:54 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qA5E9hbY006771 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 5 Nov 2012 15:41:47 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Mon, 5 Nov 2012 15:41:32 +0100 From: "DRAGE, Keith (Keith)" To: Janet P Gunn Date: Mon, 5 Nov 2012 15:41:30 +0100 Thread-Topic: [sip-overload] Overload and emergency Thread-Index: Ac27YyG4NMeuoLoITw+z1ChKkvHaGgAAGbNw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE202D2F6FDC2FRMRSSXCHMBSC_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "sip-overload@ietf.org" Subject: Re: [sip-overload] Overload and emergency X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 14:41:55 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE202D2F6FDC2FRMRSSXCHMBSC_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That is fine by me Keith ________________________________ From: Janet P Gunn [mailto:jgunn6@csc.com] Sent: 05 November 2012 14:37 To: DRAGE, Keith (Keith) Cc: sip-overload@ietf.org; sip-overload-bounces@ietf.org Subject: Re: [sip-overload] Overload and emergency Keith, I agree we should have the same wording in draft-ietf-soc-overload-control soc-load-control-event-package also draft-ietf-soc-overload-rate-control But I do have one concern with your proposed new wording. Both versions of the current wording give RPH and SOS as examples of "local= policy" which may prioritize which SIP messages don't get drops. However= , they are only examples, and do not preclude other local policies. For instance I have understood "drop new INVITES before you drop messages a= ssociated with already established sessions" to be another example of "loca= l policy". But it isn't explicitly mentioned in that text. Some of the do= cuments mention it elsewhere. Perhaps " A SIP client SHOULD honor any local policy for prioritizing SIP requests such as policies based on message type, e.g., INVITEs vs. requests associated with existing sessions. A SIP client SHOULD honor any local policy for prioritizing SIP requests based on the content of the Resource- Priority header (RPH, RFC4412 [RFC4412]). Specific (namespace.value) RPH contents may indicate high priority requests that should be preserved as much as possible during overload. The RPH contents can also indicate a low-priority request that is eligible to be dropped during times of overload. A SIP client SHOULD honor any local policy for prioritizing SIP requests relating to emergency calls, as identified by the SOS URN [RFC5031] indicating an emergency request." That puts RPH and the SOS URN on the same level, and makes the use of "INV= ITEs" vs, "existing sessions" an explicit example. Janet From: "DRAGE, Keith (Keith)" To: "sip-overload@ietf.org" Date: 11/05/2012 08:47 AM Subject: [sip-overload] Overload and emergency Sent by: sip-overload-bounces@ietf.org ________________________________ For emergency, draft-ietf-soc-overload-control-10 A SIP client SHOULD honor the local policy for prioritizing SIP requests such as policies based on the content of the Resource- Priority header (RPH, RFC4412 [RFC4412]). Specific (namespace.value) RPH contents may indicate high priority requests that should be preserved as much as possible during overload. The RPH contents can also indicate a low-priority request that is eligible to be dropped during times of overload. Other indicators, such as the SOS URN [RFC5031] indicating an emergency request, may also be used for prioritization. And for draft-ietf-soc-load-control-event-package-05 In addition, whatever the actual policy is, SIP servers SHOULD honor the local policy for prioritizing SIP requests such as policies based on the contents of the Resource-Priority Header (RPH) [RFC4412]. The RPH contents may indicate high priority requests that should be preserved as much as possible, or low priority requests that could be dropped during overload. Other indicators, such as the SOS Uniform Resource Name (URN) [RFC5031] indicating an emergency request, may also be used for prioritization. SIP request rejection and message prioritization at an overloaded server are also discussed in Section 5.10 of [I-D.ietf-soc-overload-control] and Section 12 of [RFC6357]. Prioritisation of emergency is under exactly the same sort constraints as p= riority, therefore in both these drafts I would like to see exactly paralle= l specification to priority. A SIP client SHOULD honor any local policy for prioritizing SIP requests such as policies based on the content of the Resource- Priority header (RPH, RFC4412 [RFC4412]). Specific (namespace.value) RPH contents may indicate high priority requests that should be preserved as much as possible during overload. The RPH contents can also indicate a low-priority request that is eligible to be dropped during times of overload. A SIP client SHOULD honor any local policy for prioritizing SIP requests relating to emergency calls, as identified by the SOS URN [RFC5031] indicating an emergency request. While only some countries require priority for emergency, those that do wan= t this adequately specified. Note that in the load control document, this does need to be separate parag= raphs. Keith _______________________________________________ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload --_000_EDC0A1AE77C57744B664A310A0B23AE202D2F6FDC2FRMRSSXCHMBSC_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That is fine by me

 

Keith

 

From:= Janet P Gunn [mailto:jgunn6@csc.com]
Sent: 05 November 2012 14:37=
To: DRAGE, Keith (Keith)
Cc: sip-overload@ietf.org; sip-overload-bounces@ietf.org
Subject: Re: [sip-overload] Overload and emergency

 



Keith,

I agree we should have the same wording in
dr= aft-ietf-soc-overload-control
so= c-load-control-event-package
al= so
dr= aft-ietf-soc-overload-rate-control

Bu= t I do have one concern with your proposed new wording.

Bo= th versions of the current wording give RPH and S= OS as examples of "local policy" which may prioritize  which SI= P messages don't get drops.  However, they are only examples, and do not preclude other local policies.  

Fo= r instance I have understood "drop new INVITES before you drop messages associate= d with already established sessions" to be another example of "loca= l policy".  But it isn't explicitly mentioned in that text.  S= ome of the documents mention it elsewhere.


Pe= rhaps
&q= uot;   A SIP client SHOULD honor any local policy for prioritizing SIP
  requests such as policies based on message type, e.g., INVITEs vs.
   requests associated with existing sessions.=
&n= bsp;  
&n= bsp;  A SIP client SHOULD honor any lo= cal policy for prioritizing SIP
   requests based on the cont= ent of the Resource-
  Priority header (RPH, RFC4412 [RFC441= 2]).  Specific (namespace.value)
  RPH contents may indicate high priori= ty requests that should be
  preserved as much as possible during overload.  The RPH contents can
  also indicate a low-priority request = that is eligible to be dropped
  during times of overload.  

  A SIP client SHOULD honor any local p= olicy for prioritizing SIP
  requests relating to emergency calls,= as identified by the SOS
  URN [RFC5031] indicating an emergency request."

Th= at puts RPH and the SOS URN on the s= ame level, and makes the  use of "INVITEs" vs, "existing sessions" an explicit example.

Ja= net




From:        "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> To:        "sip-overload@ietf.org" <sip-overload@ietf.org>
Date:        11/05/2012 08:47 AM
Subject:        <= /span>[sip-overload] Overload and emergency
Sent by:        <= /span>sip-overload-bounces@ietf.org




For emergency, draft-ietf-soc-overload-control-10

  A SIP client SHOULD honor the local p= olicy for prioritizing SIP
  requests such as policies based on th= e content of the Resource-
  Priority header (RPH, RFC4412 [RFC441= 2]).  Specific (namespace.value)
  RPH contents may indicate high priori= ty requests that should be
  preserved as much as possible during overload.  The RPH contents can
  also indicate a low-priority request = that is eligible to be dropped
  during times of overload.  Other indicators, such as the SOS = URN
  [RFC5031] indicating an emergency req= uest, may also be used for
  prioritization.

And for draft-ietf-soc-load-control-event-package-05

  In addition, whatever the actual poli= cy is, SIP
  servers SHOULD honor the local policy= for prioritizing SIP requests
  such as policies based on the content= s of the Resource-Priority
  Header (RPH) [RFC4412].  The RPH contents may indicate high priority
  requests that should be preserved as = much as possible, or low
  priority requests that could be dropp= ed during overload.  Other
  indicators, such as the SOS Uniform Resource Name (URN) [RFC5031]
  indicating an emergency request, may = also be used for prioritization.
  SIP request rejection and message prioritization at an overloaded
  server are also discussed in Section = 5.10 of
  [I-D.ietf-soc-overload-control] and S= ection 12 of [RFC6357].

Prioritisation of emergency is under exactly= the same sort constraints as priority, therefore in both these drafts I would l= ike to see exactly parallel specification to priority.

  A SIP client SHOULD honor any local p= olicy for prioritizing SIP
  requests such as policies based on th= e content of the Resource-
  Priority header (RPH, RFC4412 [RFC441= 2]).  Specific (namespace.value)
  RPH contents may indicate high priori= ty requests that should be
  preserved as much as possible during overload.  The RPH contents can
  also indicate a low-priority request = that is eligible to be dropped
  during times of overload.  

  A SIP client SHOULD honor any local p= olicy for prioritizing SIP
  requests relating to emergency calls,= as identified by the SOS
  URN [RFC5031] indicating an emergency request.

While only some countries require priority f= or emergency, those that do want this adequately specified.

Note that in the load control document, this= does need to be separate paragraphs.

Keith
____________________________________________= ___
sip-overload mailing list
sip-overload@ietf.org
https://www.= ietf.org/mailman/listinfo/sip-overload

--_000_EDC0A1AE77C57744B664A310A0B23AE202D2F6FDC2FRMRSSXCHMBSC_-- From bruno.chatras@orange.com Wed Nov 7 07:13:17 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0341621F8B71 for ; Wed, 7 Nov 2012 07:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dEzgCFvNXfj for ; Wed, 7 Nov 2012 07:13:15 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 06EDA21F8C0A for ; Wed, 7 Nov 2012 07:13:14 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id E31422DC5D5; Wed, 7 Nov 2012 16:13:12 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id C291B4C072; Wed, 7 Nov 2012 16:13:12 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Wed, 7 Nov 2012 16:13:12 +0100 From: To: "DRAGE, Keith (Keith)" , Janet P Gunn Thread-Topic: [sip-overload] Overload and emergency Thread-Index: Ac27XBGk8UY7OF/RTOG+2agRF0Hy5////TMAgAABLwD//MJGcA== Date: Wed, 7 Nov 2012 15:13:10 +0000 Message-ID: <29785_1352301192_509A7A88_29785_760_1_88CAD1D4E8773F42858B58CAA28272A00B895C@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: multipart/alternative; boundary="_000_88CAD1D4E8773F42858B58CAA28272A00B895CPEXCVZYM12corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Cc: "sip-overload@ietf.org" Subject: Re: [sip-overload] Overload and emergency X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 15:13:17 -0000 --_000_88CAD1D4E8773F42858B58CAA28272A00B895CPEXCVZYM12corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable BTW, why do we have a SHOULD rather than a MUST? Setting a local policy is = optional but if there is one it seems to me that the SIP client MUST honor = it. BC De : sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] D= e la part de DRAGE, Keith (Keith) Envoy=E9 : lundi 5 novembre 2012 15:42 =C0 : Janet P Gunn Cc : sip-overload@ietf.org Objet : Re: [sip-overload] Overload and emergency That is fine by me Keith ________________________________ From: Janet P Gunn [mailto:jgunn6@csc.com] Sent: 05 November 2012 14:37 To: DRAGE, Keith (Keith) Cc: sip-overload@ietf.org; sip-overload-bounces@ietf.org Subject: Re: [sip-overload] Overload and emergency Keith, I agree we should have the same wording in draft-ietf-soc-overload-control soc-load-control-event-package also draft-ietf-soc-overload-rate-control But I do have one concern with your proposed new wording. Both versions of the current wording give RPH and SOS as examples of "local= policy" which may prioritize which SIP messages don't get drops. However= , they are only examples, and do not preclude other local policies. For instance I have understood "drop new INVITES before you drop messages a= ssociated with already established sessions" to be another example of "loca= l policy". But it isn't explicitly mentioned in that text. Some of the do= cuments mention it elsewhere. Perhaps " A SIP client SHOULD honor any local policy for prioritizing SIP requests such as policies based on message type, e.g., INVITEs vs. requests associated with existing sessions. A SIP client SHOULD honor any local policy for prioritizing SIP requests based on the content of the Resource- Priority header (RPH, RFC4412 [RFC4412]). Specific (namespace.value) RPH contents may indicate high priority requests that should be preserved as much as possible during overload. The RPH contents can also indicate a low-priority request that is eligible to be dropped during times of overload. A SIP client SHOULD honor any local policy for prioritizing SIP requests relating to emergency calls, as identified by the SOS URN [RFC5031] indicating an emergency request." That puts RPH and the SOS URN on the same level, and makes the use of "INV= ITEs" vs, "existing sessions" an explicit example. Janet From: "DRAGE, Keith (Keith)" To: "sip-overload@ietf.org" Date: 11/05/2012 08:47 AM Subject: [sip-overload] Overload and emergency Sent by: sip-overload-bounces@ietf.org ________________________________ For emergency, draft-ietf-soc-overload-control-10 A SIP client SHOULD honor the local policy for prioritizing SIP requests such as policies based on the content of the Resource- Priority header (RPH, RFC4412 [RFC4412]). Specific (namespace.value) RPH contents may indicate high priority requests that should be preserved as much as possible during overload. The RPH contents can also indicate a low-priority request that is eligible to be dropped during times of overload. Other indicators, such as the SOS URN [RFC5031] indicating an emergency request, may also be used for prioritization. And for draft-ietf-soc-load-control-event-package-05 In addition, whatever the actual policy is, SIP servers SHOULD honor the local policy for prioritizing SIP requests such as policies based on the contents of the Resource-Priority Header (RPH) [RFC4412]. The RPH contents may indicate high priority requests that should be preserved as much as possible, or low priority requests that could be dropped during overload. Other indicators, such as the SOS Uniform Resource Name (URN) [RFC5031] indicating an emergency request, may also be used for prioritization. SIP request rejection and message prioritization at an overloaded server are also discussed in Section 5.10 of [I-D.ietf-soc-overload-control] and Section 12 of [RFC6357]. Prioritisation of emergency is under exactly the same sort constraints as p= riority, therefore in both these drafts I would like to see exactly paralle= l specification to priority. A SIP client SHOULD honor any local policy for prioritizing SIP requests such as policies based on the content of the Resource- Priority header (RPH, RFC4412 [RFC4412]). Specific (namespace.value) RPH contents may indicate high priority requests that should be preserved as much as possible during overload. The RPH contents can also indicate a low-priority request that is eligible to be dropped during times of overload. A SIP client SHOULD honor any local policy for prioritizing SIP requests relating to emergency calls, as identified by the SOS URN [RFC5031] indicating an emergency request. While only some countries require priority for emergency, those that do wan= t this adequately specified. Note that in the load control document, this does need to be separate parag= raphs. Keith _______________________________________________ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. --_000_88CAD1D4E8773F42858B58CAA28272A00B895CPEXCVZYM12corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

BTW, why do we have a SHOULD rather than a MUST? Setting a l= ocal policy is optional but if there is one it seems to me that the SIP cli= ent MUST honor it.

BC

 

De : sip-= overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] De la part de DRAGE, Keith (Keith)
Envoy=E9 : lundi 5 novembre 2012 15:42
=C0 : Janet P Gunn
Cc : sip-overload@ietf.org
Objet : Re: [sip-overload] Overload and emergency

 

That is fine by me

 

Keith

 

From: Janet P Gunn [mailt= o:jgunn6@csc.com]
Sent: 05 November 2012 14:37
To: DRAGE, Keith (Keith)
Cc: sip-overload@ietf.org; sip-overload-bounces@ietf.org
Subject: Re: [sip-overload] Overload and emergency

 



Keith,

I agree we should have the same wording in
draft-ietf-soc-o= verload-control
soc-load-control= -event-package
also=
draft-ietf-soc-o= verload-rate-control

But I do have on= e concern with your proposed new wording.

Both versions of= the current wording give RPH and SOS as examples of "local policy&quo= t; which may prioritize  which SIP messages don't get drops.  How= ever, they are only examples, and do not preclude other local policies.  

For instance I h= ave understood "drop new INVITES before you drop messages associated w= ith already established sessions" to be another example of "local= policy".  But it isn't explicitly mentioned in that text.  Some of the documents mention it elsewhere.


Perhaps
"   A = SIP client SHOULD honor any local policy for prioritizing SIP
  requests such as policies based on message type, e.g., INVITE= s vs.
   = requests associated with existing sessions.
   
   = A SIP client SHOULD honor any local policy for prioritizing SIP
   = requests based on the content of the Resource-
  Priority header (RPH, RFC4412 [RFC4412]).  Specific (namesp= ace.value)
  RPH contents may indicate high priority requests that should be<= /tt>
  preserved as much as possible during overload.  The RPH con= tents can
  also indicate a low-priority request that is eligible to be drop= ped
  during times of overload.  

  A SIP client SHOULD honor any local policy for prioritizing SIP =
  requests relating to emergency calls, as identified by the SOS <= /tt>
  URN [RFC5031] indicating an emergency request."=

That puts RPH an= d the SOS URN on the same level, and makes the  use of "INVITEs&q= uot; vs, "existing sessions" an explicit example.

Janet




From:        "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>= ;
To:        "sip-overload@ietf.org" <sip-overload@ietf.org>
Date:        11/05/2012 08:47 AM
Subject:        [sip-overload] Overload and emergency
Sent by:        sip-overload-bounces@ietf.org

=


For emergency, d= raft-ietf-soc-overload-control-10

  A SIP client SHOULD honor the local policy for prioritizing SIP<= /tt>
  requests such as policies based on the content of the Resource-<= /tt>
  Priority header (RPH, RFC4412 [RFC4412]).  Specific (namesp= ace.value)
  RPH contents may indicate high priority requests that should be<= /tt>
  preserved as much as possible during overload.  The RPH con= tents can
  also indicate a low-priority request that is eligible to be drop= ped
  during times of overload.  Other indicators, such as the SO= S URN
  [RFC5031] indicating an emergency request, may also be used for<= /tt>
  prioritization.

And for draft-ietf-soc-load-control-event-package-05

  In addition, whatever the actual policy is, SIP
  servers SHOULD honor the local policy for prioritizing SIP reque= sts
  such as policies based on the contents of the Resource-Priority<= /tt>
  Header (RPH) [RFC4412].  The RPH contents may indicate high= priority
  requests that should be preserved as much as possible, or low
  priority requests that could be dropped during overload.  O= ther
  indicators, such as the SOS Uniform Resource Name (URN) [RFC5031= ]
  indicating an emergency request, may also be used for prioritiza= tion.
  SIP request rejection and message prioritization at an overloade= d
  server are also discussed in Section 5.10 of
  [I-D.ietf-soc-overload-control] and Section 12 of [RFC6357].

Prioritisation of emergency is under exactly the same sort constraints = as priority, therefore in both these drafts I would like to see exactly par= allel specification to priority.

  A SIP client SHOULD honor any local policy for prioritizing SIP<= /tt>
  requests such as policies based on the content of the Resource-<= /tt>
  Priority header (RPH, RFC4412 [RFC4412]).  Specific (namesp= ace.value)
  RPH contents may indicate high priority requests that should be<= /tt>
  preserved as much as possible during overload.  The RPH con= tents can
  also indicate a low-priority request that is eligible to be drop= ped
  during times of overload.  

  A SIP client SHOULD honor any local policy for prioritizing SIP =
  requests relating to emergency calls, as identified by the SOS <= /tt>
  URN [RFC5031] indicating an emergency request.

While only some countries require priority for emergency, those that do= want this adequately specified.

Note that in the load control document, this does need to be separate p= aragraphs.

Keith
_______________________________________________
sip-overload mailing list
sip-overload@ietf.org
https://www.ietf.org/m= ailman/listinfo/sip-overload

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.
--_000_88CAD1D4E8773F42858B58CAA28272A00B895CPEXCVZYM12corpora_-- From internet-drafts@ietf.org Wed Nov 21 11:04:18 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E368E21F8841; Wed, 21 Nov 2012 11:04:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DA1z8bo9lPYz; Wed, 21 Nov 2012 11:04:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3658121F883C; Wed, 21 Nov 2012 11:04:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121121190418.4380.83325.idtracker@ietfa.amsl.com> Date: Wed, 21 Nov 2012 11:04:18 -0800 Cc: sip-overload@ietf.org Subject: [sip-overload] I-D Action: draft-ietf-soc-overload-control-11.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 19:04:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Overload Control Working Group of the= IETF. Title : Session Initiation Protocol (SIP) Overload Control Author(s) : Vijay K. Gurbani Volker Hilt Henning Schulzrinne Filename : draft-ietf-soc-overload-control-11.txt Pages : 35 Date : 2012-11-21 Abstract: Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload. This document defines the behaviour of SIP servers involved in overload control, and in addition, it specifies a loss-based overload scheme for SIP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-soc-overload-control There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-soc-overload-control-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-soc-overload-control-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From vkg@bell-labs.com Wed Nov 21 11:21:27 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E07221F87F4 for ; Wed, 21 Nov 2012 11:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.932 X-Spam-Level: X-Spam-Status: No, score=-107.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlIWM-+YrCeI for ; Wed, 21 Nov 2012 11:21:26 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8597D21F87BC for ; Wed, 21 Nov 2012 11:21:26 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id qALJLPUc006533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 21 Nov 2012 13:21:25 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id qALJLPtA017922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 21 Nov 2012 13:21:25 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id qALJLPQZ011764 for ; Wed, 21 Nov 2012 13:21:25 -0600 (CST) Message-ID: <50AD2A06.7090101@bell-labs.com> Date: Wed, 21 Nov 2012 13:22:46 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: "sip-overload@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: [sip-overload] draft-ietf-soc-overload-control-11 released X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 19:21:27 -0000 Folks: I have released a new version of the overload control draft [1]. Janet Gunn performed an exhaustive review of -09 version of the draft (thanks, Janet). The -10 version of the draft included changes suggested by Janet's review until Section 4 [2]; this version (i.e., -11) includes the changes in Section 5 onwards. The overload control reference algorithm is the same in both -11 and -10. While most of the changes are editorial and designed to reduce ambiguities when implementing the draft, a couple of changes that may need closer scrutiny: a) Interaction between draft-ietf-soc-load-control-event-package and this draft was straddled in S5.10.1 and S7 in -10. In -11, I have consolidated this in S7, taking it out from S5.10.1. b) On the same subject of interaction, whereas -10 stated in S5.10.2 that: A SIP client SHOULD honor user-level load control filters installed by signaling neighbors [I-D.ietf-soc-load-control-event- package] by sending the SIP messages that matched the filter downstream. -11 now states in S7 that: Local policy will also dictate the precedence of different overload control mechanisms applied to the traffic. Specifically, in a scenario where load control filters are installed by signaling neighbours [I-D.ietf-soc-load-control-event-package] and the same traffic can also be throttled using the overload control mechanism, local policy will dictate which of these schemes shall be given precedence. Interactions between the two schemes are out of scope for this document. Finally, I had a quick hallway conversation with Adam during the Atlanta IETF to remind him to review the updated version of the reference algorithm. As soon as he does that, and pending the scrutiny of the WG on the changes in -11, the draft will be ready to move ahead. Note that I have not yet incorporated the changes being debated on the list about overload and emergency [3]. As soon as they reach a consensus point (they seem to be close to it), I will incorporate these in. Thanks, [1] http://www.ietf.org/internet-drafts/draft-ietf-soc-overload-control-11.txt [2] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00847.html [3] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00848.html - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From salvatore.loreto@ericsson.com Thu Nov 29 05:21:15 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03CD021F89B8 for ; Thu, 29 Nov 2012 05:21:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3a-CiCxrwQt for ; Thu, 29 Nov 2012 05:21:13 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 743AC21F888D for ; Thu, 29 Nov 2012 05:21:13 -0800 (PST) X-AuditID: c1b4fb25-b7f926d00000661f-54-50b761475bcc Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 55.9D.26143.74167B05; Thu, 29 Nov 2012 14:21:12 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Thu, 29 Nov 2012 14:21:11 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 581662420; Thu, 29 Nov 2012 15:21:11 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2D5A053A30; Thu, 29 Nov 2012 15:21:10 +0200 (EET) Received: from n94.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C70CE517CF; Thu, 29 Nov 2012 15:21:09 +0200 (EET) Message-ID: <50B76146.2010200@ericsson.com> Date: Thu, 29 Nov 2012 15:21:10 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "sip-overload@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUyM+Jvja5H4vYAgw3LeS2uzWlks9j/NMFi 3v49rA7MHq3P9rJ6LFnyk8lj1s4nLAHMUVw2Kak5mWWpRfp2CVwZpw5eYSuYx1Lx8eYu5gbG 48xdjJwcEgImEt13f7FC2GISF+6tZ+ti5OIQEjjJKLG9cxJYkZDABkaJbbecIRK7GCXuvfzO AuGsZZT41dwF5SxllJg3cQFQCwcHr4C2xOo5kiDdLAKqEuc3/mEDsdkEzCSeP9wCNlVUIFZi 66XLYHFeAUGJkzOfsIDYIgLGEkceb2EEmcks0M8osatxM1hCWMBC4tLD2+wgNrOArcSFOddZ IGx5ie1v50D9oyZx9dwmqLO1JHrPdjJNYBSehWTHLCTts5C0L2BkXsXInpuYmZNebrSJERja B7f8Vt3BeOecyCFGaQ4WJXFe6617/IUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwpj9MZtq4 QJZtdhJ7z6yHHt9b13SGbrc/tq3h1XluBk3N3N1vRZU0znmY2l6yO1aqlZd5RktRvM+8cuMV ocB38f+fxM/fUNu7pHOJj+j0v7n1H6dFrjB0f57Ks8h9ybT7TTu6Oy81zvJ/riC+fGZWVfPE xOv7DtYwPdKJ+ZybJxfV9GLHlEUNSizFGYmGWsxFxYkAa0TbmjsCAAA= Cc: Volker Hilt Subject: [sip-overload] WGLC: draft-ietf-soc-load-control-event-package X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 13:21:15 -0000 [as chair] due to the comments and feedback received during the first one [1], we have decided to run a second WGLC on the updated version of the draft: http://tools.ietf.org/html/draft-ietf-soc-load-control-event-package-05 Today we are starting another two-weeks working group last call. This call ends on Thursday, December 13th. reviews and comments are really appreciate and requested from all the participants cheers Volker and Salvatore [1]http://www.ietf.org/mail-archive/web/sip-overload/current/msg00799.html