IETF Logo Mail Archive

Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt

"Vijay K. Gurbani" <vkg@bell-labs.com> Mon, 14 January 2013 15:00 UTC

Return-Path: <vkg@bell-labs.com>
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 BFB1321F8ABD for <sip-overload@ietfa.amsl.com>; Mon, 14 Jan 2013 07:00:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.344
X-Spam-Level:
X-Spam-Status: No, score=-107.344 tagged_above=-999 required=5 tests=[AWL=-0.745, 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 LYWrNb4EQtom for <sip-overload@ietfa.amsl.com>; Mon, 14 Jan 2013 07:00:49 -0800 (PST)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id C578021F8AB8 for <sip-overload@ietf.org>; Mon, 14 Jan 2013 07:00:49 -0800 (PST)
Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r0EF0mGl024827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <sip-overload@ietf.org>; Mon, 14 Jan 2013 09:00:49 -0600 (CST)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r0EF0lWK029439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <sip-overload@ietf.org>; Mon, 14 Jan 2013 09:00:48 -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 r0EF0jhJ004962 for <sip-overload@ietf.org>; Mon, 14 Jan 2013 09:00:47 -0600 (CST)
Message-ID: <50F41E18.6020005@bell-labs.com>
Date: Mon, 14 Jan 2013 09:02:48 -0600
From: "Vijay K. Gurbani" <vkg@bell-labs.com>
Organization: Bell Laboratories, Alcatel-Lucent
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: sip-overload@ietf.org
References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> <5EBD159DE88147488A3B1590E090018403530A9E6275@njfpsrvexg2.research.att.com> <OF7CCDE698.10939705-ON85257AD4.0072A173-85257AD4.007308A2@csc.com> <CAPSQ9ZVx7K_2_ApjG_sP2uopRLocaasgpJQNUNeh6NmSVAGiyw@mail.gmail.com> <24674_1355758104_50CF3A18_24674_468_1_88CAD1D4E8773F42858B58CAA28272A00E2A2C@PEXCVZYM12.corporate.adroot.infra.ftgroup> <CAPSQ9ZU-9fZRGksgut-UiRmbVfTi9WR9Orn6cockYqgjVjRF7Q@mail.gmail.com> <OF0E1F39E5.19A27B85-ON85257AE5.005E7CF8-85257AE5.005EF464@csc.com> <EDC0A1AE77C57744B664A310A0B23AE20D7456E216@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <CAPSQ9ZV10ShtsZwzA10RfBmjyzmLy7TpxomJW+GfPr08qh5z2g@mail.gmail.com> <50E5B529.2090105@bell-labs.com> <OF0589660E.64BDF2 <50F01C82.9010406@bell-labs.com> <OF0CE71656.F6252012-ON85257AF0.004EB2E8-85257AF0.004F322C@csc.com> <50F4007B.5050903@ericsson.com> <50F4146E.1080308@bell-labs.com>
In-Reply-To: <50F4146E.1080308@bell-labs.com>
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.11
Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt
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: Mon, 14 Jan 2013 15:00:50 -0000

I think the text Volker proposed below works, although it appears that
the explanatory sentence Volker added is applicable to only the first
paragraph.  I think that the sentence is equally applicable to all the
three SHOULDs.

I would, thus, suggest a small modification as detailed below.

On 01/14/2013 08:21 AM, Volker Hilt wrote:
> A SIP client SHOULD honor the 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 is expected generally to
> honor local policy except for very rare occasions when, for example,
> overload is so severe that messages, which should be preserved according
> to local policy, need to be discarded or local policies are in conflict.
>
> A SIP client SHOULD honor the 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 the local policy for prioritizing SIP requests
> relating to emergency calls, as identified by the SOS URN [RFC5031]
> indicating an emergency request.

I would re-word as:

    A SIP client is generally expected to honor local policy for
    prioritizing SIP requests except for very rare occasions, when,
    for example, overload is so severe that messages that would
    otherwise be preserved according to local policy need to be
    now discarded.  Another example where local policies may not be
    honored is if these are in conflict.  Accordingly, the normative
    statements in the next three paragraphs should be interpreted in
    the context provided here and with the understanding that the SIP
    client will aim to preserve local policy to the fullest extent
    possible.

    A SIP client SHOULD honor the 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 the 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 the local policy for prioritizing SIP
    requests relating to emergency calls, as identified by the SOS URN
    [RFC5031] indicating an emergency request.

Unless someone has objections, I will put this into the
soc-overload-control draft, and I suspect that Charles will do the same
for his draft.

Thanks,

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

v2.23.0 | Report a Bug | By Email