Re: [sip-overload] draft minutes IETF83

<bruno.chatras@orange.com> Mon, 23 April 2012 15:16 UTC

Return-Path: <bruno.chatras@orange.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 0261321F8672 for <sip-overload@ietfa.amsl.com>; Mon, 23 Apr 2012 08:16:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
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 xIUJSO65I49K for <sip-overload@ietfa.amsl.com>; Mon, 23 Apr 2012 08:16:25 -0700 (PDT)
Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id C60A521F8494 for <sip-overload@ietf.org>; Mon, 23 Apr 2012 08:16:24 -0700 (PDT)
Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 20FD45D8A42; Mon, 23 Apr 2012 17:16:23 +0200 (CEST)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 111325D89CC; Mon, 23 Apr 2012 17:16:23 +0200 (CEST)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Apr 2012 17:16:23 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 23 Apr 2012 17:16:21 +0200
Message-ID: <9ECCF01B52E7AB408A7EB8535264214104059E8E@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <4F956FC8.2030503@bell-labs.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [sip-overload] draft minutes IETF83
Thread-Index: Ac0hYgNFlJCJ4EahRKGrQe6dHk24/AAASRiQ
References: <4F93044A.5020207@ericsson.com><387F9047F55E8C42850AD6B3A7A03C6C0E228BF8@inba-mail01.sonusnet.com> <4F956FC8.2030503@bell-labs.com>
From: <bruno.chatras@orange.com>
To: <vkg@bell-labs.com>, <pravindran@sonusnet.com>
X-OriginalArrivalTime: 23 Apr 2012 15:16:23.0089 (UTC) FILETIME=[0B22D210:01CD2164]
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:16:26 -0000

I support removing Section 9. I think I made this comment on the list in 2010 actually.
BC

> -----Message d'origine-----
> De : sip-overload-bounces@ietf.org [mailto:sip-overload-
> bounces@ietf.org] De la part de Vijay K. Gurbani
> Envoyé : lundi 23 avril 2012 17:06
> À : Ravindran, Parthasarathi
> Cc : sip-overload@ietf.org
> Objet : Re: [sip-overload] draft minutes IETF83
> 
> 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/
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload