Re: [sip-overload] Comment on draft-ietf-soc-overload-control SIP Event package section [was RE: draft minutes IETF83]

"Vijay K. Gurbani" <vkg@bell-labs.com> Fri, 06 July 2012 21:31 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 1E5E511E80F3 for <sip-overload@ietfa.amsl.com>; Fri, 6 Jul 2012 14:31:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.799
X-Spam-Level:
X-Spam-Status: No, score=-109.799 tagged_above=-999 required=5 tests=[AWL=0.800, 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 TFXTfqehJhQT for <sip-overload@ietfa.amsl.com>; Fri, 6 Jul 2012 14:31:20 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2589411E808F for <sip-overload@ietf.org>; Fri, 6 Jul 2012 14:31:20 -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 q66LVaje024428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 6 Jul 2012 16:31:37 -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 q66LVaIe011634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 6 Jul 2012 16:31:36 -0500
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 q66LVZIO015994; Fri, 6 Jul 2012 16:31:35 -0500 (CDT)
Message-ID: <4FF75A9E.5090307@bell-labs.com>
Date: Fri, 06 Jul 2012 16:37:34 -0500
From: "Vijay K. Gurbani" <vkg@bell-labs.com>
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: "Ravindran, Parthasarathi" <pravindran@sonusnet.com>
References: <4F93044A.5020207@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228BF8@inba-mail01.sonusnet.com> <4F956FC8.2030503@bell-labs.com> <4F95732A.1000506@bell-labs.com> <4F957A0C.4050606@bell-labs.com> <4F957A50.7040402@bell-labs.com> <4F95845B.2040508@bell-labs.com> <387F9047F55E8C42850AD6B3A7A03C6C0E237E4A@inba-mail01.sonusnet.com> <4F97191A.5020501@bell-labs.com> <387F9047F55E8C42850AD6B3A7A03C6C16045036@inba-mail02.sonusnet.com>
In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C16045036@inba-mail02.sonusnet.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" <sip-overload@ietf.org>, Volker Hilt <volker.hilt@bell-labs.com>
Subject: Re: [sip-overload] Comment on draft-ietf-soc-overload-control SIP Event package section [was RE: 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: Fri, 06 Jul 2012 21:31:21 -0000

This response is for Partha's original email archived at
http://www.ietf.org/mail-archive/web/sip-overload/current/msg00789.html.
I am not inline including his original email.  Please see above URL
for the context.

Partha: I am in the process of closing the open issues for
draft-ietf-soc-overload control.  One of these is yours, although
I do not think your comments in the above URL will necessitate
any changes in the draft.  But to close the loop, please see below.

To recap, I had suggested that we remove S9 from
draft-ietf-soc-overload-control [1], but it was felt that S9
provides useful information that should be retained for
archival purposes [2].

The merits and demerits of choosing the Via parameter approach over
SUBS/NOT were looked at a long time ago, and I just want to make
sure that your intent is not to reopen that discussion.  (Personally,
I don't think that is a good use of our time.)  In the instance
where SUBS/NOT adds value to the general SIP overload control
problem, an event package has been defined for that purpose [4].

So, let's be sure that S9 is currently there for archival purposes
only.  Unless you have specific objections to proceeding with S9 in the
draft --- and I don't think you do based on your earlier response in
[3] --- I'd rather continue moving the work ahead.

Please advise.

[1] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00773.html
[2] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00775.html
[3] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00780.html
[4] http://tools.ietf.org/html/draft-ietf-soc-load-control-event-package-03

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/