Re: [sip-overload] draft minutes IETF83

"Vijay K. Gurbani" <vkg@bell-labs.com> Tue, 24 April 2012 21:15 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 E7A1511E80BB for <sip-overload@ietfa.amsl.com>; Tue, 24 Apr 2012 14:15:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.599
X-Spam-Level:
X-Spam-Status: No, score=-109.599 tagged_above=-999 required=5 tests=[AWL=1.000, 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 k-0SKkAEZdEO for <sip-overload@ietfa.amsl.com>; Tue, 24 Apr 2012 14:15:24 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 38BC511E80B6 for <sip-overload@ietf.org>; Tue, 24 Apr 2012 14:15:24 -0700 (PDT)
Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q3OLFNKU026269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Apr 2012 16:15:23 -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 q3OLFM5L029200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Apr 2012 16:15:23 -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 q3OLFMAC010488; Tue, 24 Apr 2012 16:15:22 -0500 (CDT)
Message-ID: <4F97191A.5020501@bell-labs.com>
Date: Tue, 24 Apr 2012 16:20:26 -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> <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>
In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E237E4A@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.33
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] 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: Tue, 24 Apr 2012 21:15:25 -0000

On 04/23/2012 08:24 PM, Ravindran, Parthasarathi wrote:
> Vijay/Volker,
>
> I'm reading this mail after replied to your initial proposal as this
> mail is not in my "To me" folder :-)
>
> I have difference of opinion about the content of sub/not in Sec 9 as
> it is not fully analyzed after deep-dive into "OC" parameters in
> "via" header based mechanism. My opinion comes from the Session
> Initiation Protocol (SIP) Resource availability Event package draft
> (http://tools.ietf.org/html/draft-partha-soc-overload-resource-availability-00).
> I personally feel that it is not worthy to discuss about SUB/NOT
> mechanism's merits/demerits within this draft at this moment. In case
> you wish to discuss, I'll continue the merit/demerit as part of this
> mail thread.

Initially, I was of the opinion that removing S9 may be the expedient
way forward, as my earlier email [1] indicated.  However, Volker has
made a case that we should maintain S9 as background information to
demonstrate the discussions that lead to the choice of the current
solution.

Having been through a rather brutal IESG review of sipclf where similar
justification was asked for, I am sympathetic to providing background
information precisely for the purpose of completeness.

I gather that you would rather see S9 excised completely.

We have to converge at a middle point somewhere.

If you are not comfortable with the suggested text of [2], then can I
kindly ask you to read S9.1.2 and send me some suggested text that gets
your point across?  I will be more than happy to put that into the
draft and move forward.

Please send me the text at your earliest convenience (or post on the
list) and we can iterate through it to include it in the next
revision.

[1] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00773.html
[2] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00778.html

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/