Re: [sip-overload] draft-ietf-soc-overload-design-05

Janet P Gunn <jgunn6@csc.com> Tue, 19 April 2011 15:26 UTC

Return-Path: <jgunn6@csc.com>
X-Original-To: sip-overload@ietfc.amsl.com
Delivered-To: sip-overload@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3786CE0758; Tue, 19 Apr 2011 08:26:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NKE5ZaDI493; Tue, 19 Apr 2011 08:26:10 -0700 (PDT)
Received: from mail64.messagelabs.com (mail64.messagelabs.com [216.82.249.227]) by ietfc.amsl.com (Postfix) with ESMTP id BA13FE0756; Tue, 19 Apr 2011 08:26:09 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: jgunn6@csc.com
X-Msg-Ref: server-8.tower-64.messagelabs.com!1303226667!119622003!1
X-StarScan-Version: 6.2.9; banners=-,-,-
X-Originating-IP: [20.137.2.88]
Received: (qmail 2243 invoked from network); 19 Apr 2011 15:24:31 -0000
Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-8.tower-64.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Apr 2011 15:24:31 -0000
Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.4.3/Switch-3.3.3mp) with ESMTP id p3JFORC5000540; Tue, 19 Apr 2011 11:24:27 -0400
In-Reply-To: <4DADA3E8.6080409@bell-labs.com>
References: <9FEB75F0-712B-4CDE-949D-F3DE4D80BCD7@g11.org.uk> <OF0DF6A035.7421167A-ON85257876.00646380-85257876.0064CA28@csc.com> <EDC0A1AE77C57744B664A310A0B23AE21EC516BD@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <69BD7A69-FF32-4750-A73C-3B28D39FA5BF@g11.org.uk> <EDC0A1AE77C57744B664A310A0B23AE21EC517B7@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <578BF6E7-89CD-4300-AED2-EED8BF6F2547@g11.org.uk> <EDC0A1AE77C57744B664A310A0B23AE21EC517EC@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <847C3FA5-B73C-4BB9-B5BD-253C6DC994A5@g11.org.uk> <4DADA3E8.6080409@bell-labs.com>
To: "Vijay K. Gurbani" <vkg@bell-labs.com>
MIME-Version: 1.0
X-KeepSent: 90D7BCEF:193A9527-85257877:0054915A; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.0.2FP1 CCH2 April 23, 2009
From: Janet P Gunn <jgunn6@csc.com>
Message-ID: <OF90D7BCEF.193A9527-ON85257877.0054915A-85257877.0054A334@csc.com>
Date: Tue, 19 Apr 2011 11:24:24 -0400
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP1 HF29|January 09, 2011) at 04/19/2011 11:23:18 AM, Serialize complete at 04/19/2011 11:23:18 AM
Content-Type: multipart/alternative; boundary="=_alternative 0054A2F785257877_="
Cc: sip-overload-bounces@ietf.org, sip-overload@ietf.org
Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Overload <sip-overload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sip-overload>, <mailto:sip-overload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip-overload>
List-Post: <mailto:sip-overload@ietf.org>
List-Help: <mailto:sip-overload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip-overload>, <mailto:sip-overload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Apr 2011 15:26:11 -0000

Vijay,

What is there now is fine with me. I see no need for change.

Janet

sip-overload-bounces@ietf.org wrote on 04/19/2011 11:02:00 AM:

> [image removed] 
> 
> Re: [sip-overload] draft-ietf-soc-overload-design-05
> 
> Vijay K. Gurbani 
> 
> to:
> 
> sip-overload
> 
> 04/19/2011 11:00 AM
> 
> Sent by:
> 
> sip-overload-bounces@ietf.org
> 
> On 04/19/2011 09:30 AM, ken carlberg wrote:
> > I think the subject has been beaten to a pulp. And to a large degree, 
we
> > have gone much further into topics than perhaps was necessary. The
> > purpose of the suggested new next was to broaden the picture and bring
> > up topics that are attributed to the RPH. The only position that was
> > taken in the text was to suggest in the form of a "should" the use of
> > the first RPH (which I meant to be the first "recognized/supported"
> > RPH). But I conceded that i was fine to remove that position.
> [...]
> 
> As the editor of draft-ietf-sip-overload-control, I have read this
> thread with interest.
> 
> So, the question now is: what, if any, from this thread carries over
> into the draft-ietf-sip-overload-control draft?  I am certainly not
> up to verse with RPH as some of the members of this working group
> are, so I will depend on them to point out any text that should be
> modified in draft-ietf-sip-overload-control.
> 
> For the sake of completeness, here is what
> draft-ietf-sip-overload-control has to say about prioritizing
> requests containing the RPH header:
> 
>     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.
> 
> Do we deem this to be enough?
> 
> Thanks,
> 
> - vijay
> -- 
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
> Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
> Web:   http://ect.bell-labs.com/who/vkg/
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload