Re: [sip-overload] WG Last Call for draft-ietf-soc-overload-control-12

"NOEL, ERIC (ERIC C)" <ecnoel@research.att.com> Sun, 17 February 2013 22:49 UTC

Return-Path: <ecnoel@research.att.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 82C6D21F8849 for <sip-overload@ietfa.amsl.com>; Sun, 17 Feb 2013 14:49:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XzHRCx2Fqdu for <sip-overload@ietfa.amsl.com>; Sun, 17 Feb 2013 14:49:07 -0800 (PST)
Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 8425621F868B for <sip-overload@ietf.org>; Sun, 17 Feb 2013 14:49:07 -0800 (PST)
Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 19130120994; Sun, 17 Feb 2013 17:51:17 -0500 (EST)
Received: from njfpsrvexg2.research.att.com (njfpsrvexg2.research.att.com [135.207.177.29]) by mail-green.research.att.com (Postfix) with ESMTP id 51AC3E36E0; Sun, 17 Feb 2013 17:42:49 -0500 (EST)
Received: from njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9]) by njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9%14]) with mapi; Sun, 17 Feb 2013 17:49:06 -0500
From: "NOEL, ERIC (ERIC C)" <ecnoel@research.att.com>
To: Salvatore Loreto <salvatore.loreto@ericsson.com>, "sip-overload@ietf.org" <sip-overload@ietf.org>
Date: Sun, 17 Feb 2013 17:49:06 -0500
Thread-Topic: [sip-overload] WG Last Call for draft-ietf-soc-overload-control-12
Thread-Index: Ac4IKkvhKhhs5fbWS4qQYC7+V29EsAFMIG6n
Message-ID: <5EBD159DE88147488A3B1590E09001840353173DCBC2@njfpsrvexg2.research.att.com>
References: <51110A56.7030402@ericsson.com>,<51189F14.6050405@ericsson.com>
In-Reply-To: <51189F14.6050405@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Volker Hilt <volker.hilt@alcatel-lucent.com>
Subject: Re: [sip-overload] WG Last Call for draft-ietf-soc-overload-control-12
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: Sun, 17 Feb 2013 22:49:08 -0000

Salvatore,

I read the document and have a few comments:

- Typos:
      + Section 5.4 page 12, second paragraph "... is larger than the value stored value, ...." --> "... is larger than the stored value, ..."
      + Section 6.2 page 18, 7th paragraph, "20% for 1s." --> "20% for 0.5s" or "oc-validity=500"  --> "oc-validity=1000"

- Questions:
      + Section 4.1 page 6, 4th paragraph, why using SHOULD and not MUST to describe the client behavior upon receiving a response with the oc parameters filled in. This is in contrast with section 5.5 page 12, first paragraph, where a SIP client MUST honor overload control values it receives from downstream neighbors.
      + Section 4.4 page 8, 4th paragraph, following a sequence number overflow, the server must reset the oc-seq parameter. Do we incur the risk of having the client ignore all server requests with the new oc-seq until oc-validity expires? Or does the client need to be able to identify when oc-seq was reset? 
      + Section 7, should there be any mention of draft soc-overload-rate-control?
     
Thanks,

Eric
________________________________________
From: sip-overload-bounces@ietf.org [sip-overload-bounces@ietf.org] On Behalf Of Salvatore Loreto [salvatore.loreto@ericsson.com]
Sent: Monday, February 11, 2013 2:34 AM
To: sip-overload@ietf.org
Cc: Volker Hilt
Subject: Re: [sip-overload] WG Last Call for    draft-ietf-soc-overload-control-12

this is just a reminder for this WG Last Call

I haven't seen yet any comment or feedback
please we really need you spend some time to reading and reviewing the draft

thanks a lot
Salvatore

On 2/5/13 3:34 PM, Salvatore Loreto wrote:
Dear WG partecipants,


Volker and I would like to initiate a second 2 weeks WG Last Call on
draft-ietf-soc-overload-control-12 (" Session Initiation Protocol (SIP) Overload Control")
http://tools.ietf.org/id/draft-ietf-soc-overload-control-12.txt

The first WGLC that we run ( http://www.ietf.org/mail-archive/web/sip-overload/current/msg00731.html )
has produced a significant amount of feedback and comments that have been discussed and addressed in subsequent versions

Please send your reviews, as well as expression of support regarding
document readiness for IESG (or not) either to the *soc* mailing list (sip-overload@ietf.org<mailto:sip-overload@ietf.org>),
or directly to the WG chairs (Murray Kucherawy and myself).

Comments like "I've read the document and it is Ok to publish" or
"I've read the document and it has the following issues"
are useful and would be gratefully accepted by chairs.


The WG LC will end on Friday, February 19th.


Thank you,
Salvatore as an SoC co-chair.