Re: [sip-overload] draft minutes IETF83

Volker Hilt <volker.hilt@bell-labs.com> Mon, 23 April 2012 15:52 UTC

Return-Path: <volker.hilt@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 9303721F8744 for <sip-overload@ietfa.amsl.com>; Mon, 23 Apr 2012 08:52:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level:
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
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 WbzpuZ3-nEvN for <sip-overload@ietfa.amsl.com>; Mon, 23 Apr 2012 08:52:15 -0700 (PDT)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 17C6521F872E for <sip-overload@ietf.org>; Mon, 23 Apr 2012 08:52:14 -0700 (PDT)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q3NFqCSL005632 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 23 Apr 2012 17:52:13 +0200
Received: from [149.204.61.31] (135.120.57.7) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 23 Apr 2012 17:52:07 +0200
Message-ID: <4F957A50.7040402@bell-labs.com>
Date: Mon, 23 Apr 2012 17:50:40 +0200
From: Volker Hilt <volker.hilt@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: "Vijay K. Gurbani" <vkg@bell-labs.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>
In-Reply-To: <4F957A0C.4050606@bell-labs.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80
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:52:17 -0000

Vijay,
>>
>> 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?
>
This discussion is specific to the mechanism proposed in this draft and 
it was felt that it is better to keep it there.

> 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.
>
Works fine for me.

Thanks,

Volker [as individual]