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

Atle Monrad <atle.monrad@ericsson.com> Fri, 15 February 2013 21:52 UTC

Return-Path: <atle.monrad@ericsson.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 2680321E803C for <sip-overload@ietfa.amsl.com>; Fri, 15 Feb 2013 13:52:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.248
X-Spam-Level:
X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 PhS7sze+bzVT for <sip-overload@ietfa.amsl.com>; Fri, 15 Feb 2013 13:52:36 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0B56721E8047 for <sip-overload@ietf.org>; Fri, 15 Feb 2013 13:52:33 -0800 (PST)
X-AuditID: c1b4fb30-b7f0d6d000007e61-b8-511eae200aad
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 1D.FA.32353.02EAE115; Fri, 15 Feb 2013 22:52:33 +0100 (CET)
Received: from ESESSMB203.ericsson.se ([169.254.3.65]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0318.004; Fri, 15 Feb 2013 22:52:32 +0100
From: Atle Monrad <atle.monrad@ericsson.com>
To: "sip-overload@ietf.org" <sip-overload@ietf.org>
Thread-Topic: [sip-overload] WG Last Call for draft-ietf-soc-overload-control-12
Thread-Index: AQHOCCpNJrfjPBGi6kGoJYBve6LVbZh0flrQgAbQleA=
Date: Fri, 15 Feb 2013 21:52:30 +0000
Message-ID: <7D2F7D7ADBA812449F25F4A69922881C066214@ESESSMB203.ericsson.se>
References: <51110A56.7030402@ericsson.com> <51189F14.6050405@ericsson.com> <E42CCDDA6722744CB241677169E8365602002006@MISOUT7MSGUSR9I.ITServices.sbc.com>
In-Reply-To: <E42CCDDA6722744CB241677169E8365602002006@MISOUT7MSGUSR9I.ITServices.sbc.com>
Accept-Language: nb-NO, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.18]
Content-Type: multipart/alternative; boundary="_000_7D2F7D7ADBA812449F25F4A69922881C066214ESESSMB203ericsso_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+Jvja7iOrlAg67LbBb7nyY4MHosWfKT KYAxissmJTUnsyy1SN8ugSvj16dbjAWPIysa7i9namB85NvFyMkhIWAicWfmBSYIW0ziwr31 bF2MXBxCAocYJdZ9XMEO4SxmlDiy4zkLSBWbgI7EuZ93WEFsEQFjiSOPtzCC2MICgRJr301l g4gHSfS0LGGEsK0kZt1dAFbPIqAqseDQdrA4r4C3xJrnu1ggFsxmlJi3ZiZYEadAlMSWIzuY uxg5OBgFZCXmNvGChJkFxCVuPZkPdamAxJI955khbFGJl4//sULYihIfX+1jBGllFsiXuPkj CmKVoMTJmU9YJjCKzEIyaRZC1SwkVRAlOhILdn9ig7C1JZYtfM0MY5858JgJWXwBI/sqRvbc xMyc9HLzTYzAGDm45bfBDsZN98UOMUpzsCiJ84a7XggQEkhPLEnNTk0tSC2KLyrNSS0+xMjE wSnVwCgg+dJOPv+yfaQS4+G7GnP93RT5Q8+xHHZ/HBO1fU5EZIcm204/zY1iex0keLYy7oo4 7cev90SV58E6Px2f4z9etsV92D7xq1BnVO2pbYH+zTNSLc/wZrgeNN7/31x4hUO16y8piw8v pVV/HdObUniHRdCpdKfZ7j/758bsLpZP+3AhZ4sGpxJLcUaioRZzUXEiAD7e9nFfAgAA
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: Fri, 15 Feb 2013 21:52:37 -0000

G'day

The draft is a 3GPP Rel-11 dependency that I support going forward.

I've read through the draft and have no real comments.

However, I find the statement in section 5.10.2 a bit odd

  .... It would be fair to devote the same amount
   of processing at the overloaded server to the combination of
   rejection and processing from a non-participating client as the
   overloaded server would devote to processing requests from a
   participating client.  This is to ensure that SIP clients that do not
   support this specification don't receive an unfair advantage over
   those that do.
Personally I would have used a term like "local policy" for such decisions and not the current guidance given in a the current "fair to devote" fashion ...

I'd like to see the draft progressing.

thanks
/atle

________________________________


Atle Monrad
3GPP CT Chairman
Standardization and Regulation,
Group Function Technology and Portfolio Management
Ericsson


From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] On Behalf Of Salvatore Loreto
Sent: Monday, February 11, 2013 2:35 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.