Re: [sip-overload] draft minutes IETF83

"Vijay K. Gurbani" <vkg@bell-labs.com> Mon, 23 April 2012 15:44 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 D87E521F873A for <sip-overload@ietfa.amsl.com>; Mon, 23 Apr 2012 08:44:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.432
X-Spam-Level:
X-Spam-Status: No, score=-109.432 tagged_above=-999 required=5 tests=[AWL=1.167, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wD-9l2EXXIE for <sip-overload@ietfa.amsl.com>; Mon, 23 Apr 2012 08:44:30 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id DE13721F8739 for <sip-overload@ietf.org>; Mon, 23 Apr 2012 08:44:29 -0700 (PDT)
Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q3NFiTYH029387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <sip-overload@ietf.org>; Mon, 23 Apr 2012 10:44:29 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q3NFiSLr026029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <sip-overload@ietf.org>; Mon, 23 Apr 2012 10:44:29 -0500
Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q3NFiRIP006231; Mon, 23 Apr 2012 10:44:28 -0500 (CDT)
Message-ID: <4F957A0C.4050606@bell-labs.com>
Date: Mon, 23 Apr 2012 10:49:32 -0500
From: "Vijay K. Gurbani" <vkg@bell-labs.com>
Organization: Bell Laboratories, Alcatel-Lucent
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Volker Hilt <volker.hilt@bell-labs.com>
References: <4F93044A.5020207@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228BF8@inba-mail01.sonusnet.com> <4F956FC8.2030503@bell-labs.com> <4F95732A.1000506@bell-labs.com>
In-Reply-To: <4F95732A.1000506@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.35
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12
Cc: sip-overload@ietf.org
Subject: Re: [sip-overload] draft minutes IETF83
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, 23 Apr 2012 15:44:31 -0000

On 04/23/2012 10:20 AM, Volker Hilt wrote:
> Vijay, Partha,
>
> I think section 9 provides useful background on the discussions that
> lead to the current solution. For this reason, it would be good to keep
> this section in the draft.
>
> Section 9 does not refer to a specific event packet. Rather, explains
> general design considerations.

Volker: Indeed, I thought of that as well.  But then, I wonder why we
did not put this in rfc6357?

Regardless, if it is desirable to maintain this section, then I'd be a
bit more pro-active in the wording to make sure there is no ambiguity.
Something along these lines is what I would suggest if we want to
maintain S9:

OLD:
9.1. SIP Mechanism

    A SIP mechanism is needed to convey overload feedback from the
    receiving to the sending SIP entity.  A number of different
    alternatives exist to implement such a mechanism.

NEW:
9.1. SIP Mechanism

    A SIP mechanism is needed to convey overload feedback from the
    receiving to the sending SIP entity.  Different alternatives exist
    to implement such a mechanism, and the fundamental design choices
    related to each are discussed below.  This document uses the SIP
    response headers (Section 9.1.1) to achieve overload control;
    the design choices related to SIP event package (Section 9.1.2) are
    provided for the sake of completeness.

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/