Re: [sip-overload] draft minutes IETF83

"Vijay K. Gurbani" <vkg@bell-labs.com> Mon, 23 April 2012 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 3646321F84F1 for <sip-overload@ietfa.amsl.com>; Mon, 23 Apr 2012 08:00:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.326
X-Spam-Level:
X-Spam-Status: No, score=-109.326 tagged_above=-999 required=5 tests=[AWL=1.273, 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 S8rj2qu+TV+B for <sip-overload@ietfa.amsl.com>; Mon, 23 Apr 2012 08:00:45 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 76F8921F8476 for <sip-overload@ietf.org>; Mon, 23 Apr 2012 08:00:44 -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 q3NF0g8T013226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Apr 2012 10:00:42 -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 q3NF0e91029536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 23 Apr 2012 10:00:42 -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 q3NF0eE8027633; Mon, 23 Apr 2012 10:00:40 -0500 (CDT)
Message-ID: <4F956FC8.2030503@bell-labs.com>
Date: Mon, 23 Apr 2012 10:05:44 -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: "Ravindran, Parthasarathi" <pravindran@sonusnet.com>
References: <4F93044A.5020207@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228BF8@inba-mail01.sonusnet.com>
In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E228BF8@inba-mail01.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>
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:00:53 -0000

On 04/21/2012 08:21 PM, Ravindran, Parthasarathi wrote:
> Salvatore,
>
> I have provided the comment on ietf-soc-overload-control-08 that
> subscribe/notify mechanism mentioned in the draft has to updated with
> proper detail mechanism or the section to be removed and Vijay agrees
> to update the draft with the proper text in the next revision. Please
> update in the minutes.

Partha: I promised to get back to the list with proposed modifications
to S9.1.2 based on your feedback at the mic during the meeting.  So,
here goes.

I believe you are pointing out an incongruity in the text in S9, which
discusses two alternatives to providing overload control --- one is by
sending the feedback in the Via header (the chosen means) and the second
is through a subs/not event package.  The incongruity occurs because the
phrasing of the text in the subs/not alternative appears to imply that
subs/not is supported mechanism as well, which clearly it is not.

To remedy this, I propose that we simply remove Section 9 in its 
entirety.  The justification for choosing the Via header is already
provided in Section 3, as such Section 9 does not contribute much.
The subs/not package is used in a different scenario (as described
by Shen et al. [1]).  Having the discussion on subs/not in the
overload-control document may simply be distracting.

Let me know if that is okay with you and I will remove Section 9 in
the next revision.

[1] 
http://datatracker.ietf.org/doc/draft-ietf-soc-load-control-event-package/

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/