From bruno.chatras@orange.com Wed Jan 2 02:09:04 2013 Return-Path: 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 B8ACE21F9005; Wed, 2 Jan 2013 02:09:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] 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 bteqyKTGCWdG; Wed, 2 Jan 2013 02:09:02 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id D46E721F9004; Wed, 2 Jan 2013 02:08:46 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 6A53018C64D; Wed, 2 Jan 2013 11:08:45 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 410BB23810C; Wed, 2 Jan 2013 11:08:45 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Wed, 2 Jan 2013 11:08:44 +0100 From: To: Janet P Gunn , Charles Shen Thread-Topic: Local Policy Re: [sip-overload] I-D Action: draft-ietf-soc-load-control-event-package-05.txt Thread-Index: AQHN53qug4Dbo2kaaUC9DJG9CBJuIJg10UTQ Date: Wed, 2 Jan 2013 10:08:43 +0000 Message-ID: <14332_1357121325_50E4072D_14332_348_1_88CAD1D4E8773F42858B58CAA28272A00E8050@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> <5EBD159DE88147488A3B1590E090018403530A9E6275@njfpsrvexg2.research.att.com> <24674_1355758104_50CF3A18_24674_468_1_88CAD1D4E8773F42858B58CAA28272A00E2A2C@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: multipart/alternative; boundary="_000_88CAD1D4E8773F42858B58CAA28272A00E8050PEXCVZYM12corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Cc: "sip-overload-bounces@ietf.org" , "sip-overload@ietf.org" , Arata Koike , "NOEL, ERIC \(ERIC C\)" , Henning Schulzrinne Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 10:09:04 -0000 --_000_88CAD1D4E8773F42858B58CAA28272A00E8050PEXCVZYM12corpora_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3b3VsZCBzYXkgaXQgaXMgdGhlIMKrIGxvY2FsIHBvbGljeSDCuyBkZWZpbmVkIGJ5IHRoZSBj YXJyaWVyIGJ1dCBpdCBoYXMgdG8gY29tcGx5IHdpdGggdGhlIHJlZ3VsYXRpb24gaW4gZm9yY2Ug aW4gdGhlIGNvdW50cnkgd2hlcmUgdGhlIGNhcnJpZXIgaXMgb3BlcmF0aW5nLiAgIOKAnFNob3Vs ZOKAnSBjb3VsZCBiZSB1bmRlcnN0b29kIGFzIHByb3ZpZGluZyByb29tIGZvciBub3QgaG9ub3Jp bmcgYW55IGxvY2FsIHBvbGljeSBleGNlcHQgb25lIHRoYXQgaGFzIGJlZW4gaGFyZC1jb2RlZCBi eSB0aGUgdmVuZG9yIG9mIHRoZSBlcXVpcG1lbnQuICBBbiB1bmRlc2lyYWJsZSBzaWRlLWVmZmVj dCB3b3VsZCBiZSB0aGF0IGRpZmZlcmVudCBTSVAgZW50aXRpZXMgZnJvbSBkaWZmZXJlbnQgdmVu ZG9ycyBjb3VsZCByZWFjdCBkaWZmZXJlbnRseSB3aGlsZSBiZWluZyB1c2VkIGluIHRoZSBzYW1l IG5ldHdvcmsuDQpCQw0KDQpEZSA6IEphbmV0IFAgR3VubiBbbWFpbHRvOmpndW5uNkBjc2MuY29t XQ0KRW52b3nDqSA6IGx1bmRpIDMxIGTDqWNlbWJyZSAyMDEyIDE4OjE3DQrDgCA6IENoYXJsZXMg U2hlbg0KQ2MgOiBDSEFUUkFTIEJydW5vIE9MTkMvT0xOOyBjaGFybGVzLm5ld3lvcmtAZ21haWwu Y29tOyBOT0VMLCBFUklDIChFUklDIEMpOyBIZW5uaW5nIFNjaHVsenJpbm5lOyBBcmF0YSBLb2lr ZTsgc2lwLW92ZXJsb2FkQGlldGYub3JnOyBzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZw0K T2JqZXQgOiBMb2NhbCBQb2xpY3kgUmU6IFtzaXAtb3ZlcmxvYWRdIEktRCBBY3Rpb246IGRyYWZ0 LWlldGYtc29jLWxvYWQtY29udHJvbC1ldmVudC1wYWNrYWdlLTA1LnR4dA0KDQoNCkkgd291bGQg IGJlIGhhcHB5IHdpdGggIk1VU1QiLCBidXQgSSdkIGxpa2UgdG8gaGVhciBmb3JtIHRoZSBjYXJy aWVycy0gZXNwZWNpYWxseSBmcm9tIEtlaXRoIERyYWdlLCBhcyBoZSBpcyB0aGUgb25lIHdobyBp bml0aWF0ZWQgdGhlIG5ldyB3b3JkaW5nLg0KDQpJdCBtYXkgYmUgYSBxdWVzdGlvbiBvZiAgV0hP U0UgbG9jYWwgcG9saWN5IHdlIGFyZSB0YWxraW5nIGFib3V0LiAgIFRoZXJlIGlzIHRoZSAibG9j YWwgcG9saWN5IiBhcyBkZWZpbmVkIGJ5IHRoZSBnb3Zlcm5tZW50ICh3aGljaCBtYXkgcG9saXRp Y2FsbHkgY29ycmVjdCBidXQgdGVjaG5pY2FsbHkgdW5zdGFibGUpLiAgVGhlcmUgaXMgYWxzbyAi bG9jYWwgcG9saWN5IiBkZWZpbmVkIGJ5IHRoZSAiY2FycmllciIgKHdoaWNoIG1heSBiZSAgdGVj aG5pY2FsbHkgc3RhYmxlLCBidXQgcG9saXRpY2FsbHkgaW5jb3JyZWN0KS4NCg0KIlNob3VsZCIg bGVhdmVzIHNvbWUgd2lnZ2xlIHJvb20gYXMgdG8gV0hJQ0ggbG9jYWwgcG9saWN5ICBpcyBiZWlu ZyBob25vcmVkLg0KDQpKYW5ldA0KDQoNCg0KRnJvbTogICAgICAgIENoYXJsZXMgU2hlbiA8Y2hh cmxlc0Bjcy5jb2x1bWJpYS5lZHU8bWFpbHRvOmNoYXJsZXNAY3MuY29sdW1iaWEuZWR1Pj4NClRv OiAgICAgICAgYnJ1bm8uY2hhdHJhc0BvcmFuZ2UuY29tPG1haWx0bzpicnVuby5jaGF0cmFzQG9y YW5nZS5jb20+DQpDYzogICAgICAgIEphbmV0IFAgR3Vubi9VU0EvQ1NDQENTQywgIk5PRUwsIEVS SUMgKEVSSUMgQykiIDxlY25vZWxAYXR0LmNvbTxtYWlsdG86ZWNub2VsQGF0dC5jb20+PiwgInNp cC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0Bp ZXRmLm9yZz4iIDxzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2lwLW92ZXJs b2FkLWJvdW5jZXNAaWV0Zi5vcmc+PiwgInNpcC1vdmVybG9hZEBpZXRmLm9yZzxtYWlsdG86c2lw LW92ZXJsb2FkQGlldGYub3JnPiIgPHNpcC1vdmVybG9hZEBpZXRmLm9yZzxtYWlsdG86c2lwLW92 ZXJsb2FkQGlldGYub3JnPj4sIEFyYXRhIEtvaWtlIDxrb2lrZS5hcmF0YUBsYWIubnR0LmNvLmpw PG1haWx0bzprb2lrZS5hcmF0YUBsYWIubnR0LmNvLmpwPj4sIEhlbm5pbmcgU2NodWx6cmlubmUg PGhnc0Bjcy5jb2x1bWJpYS5lZHU8bWFpbHRvOmhnc0Bjcy5jb2x1bWJpYS5lZHU+Pg0KRGF0ZTog ICAgICAgIDEyLzE4LzIwMTIgMTA6MzIgUE0NClN1YmplY3Q6ICAgICAgICBSZTogW3NpcC1vdmVy bG9hZF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1zb2MtbG9hZC1jb250cm9sLWV2ZW50LXBhY2th Z2UtMDUudHh0DQpTZW50IGJ5OiAgICAgICAgY2hhcmxlcy5uZXd5b3JrQGdtYWlsLmNvbTxtYWls dG86Y2hhcmxlcy5uZXd5b3JrQGdtYWlsLmNvbT4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQoNCg0KDQpIaSBCcnVubywgSSBub3RpY2VkIHlvdXIgY29tbWVudCwgY2FuIHdlIHJl YWNoIGEgY29uc2Vuc3VzIG9uIHRoaXMgbGlzdCBzbyBJIGNhbiB1cGRhdGUgdGhlIGRyYWZ0IGFj Y29yZGluZ2x5Pw0KDQpUaGFua3MhDQoNCkNoYXJsZXMNCg0KT24gTW9uLCBEZWMgMTcsIDIwMTIg YXQgMTA6MjggQU0sIDxicnVuby5jaGF0cmFzQG9yYW5nZS5jb208bWFpbHRvOmJydW5vLmNoYXRy YXNAb3JhbmdlLmNvbT4+IHdyb3RlOg0KSSBhZ3JlZSB0aGF0IGJvdGggZHJhZnRzIHNob3VsZCB1 c2UgdGhlIHNhbWUgdGV4dCBidXQgSeKAmW0gc3RpbGwgbm90IHN1cmUgdG8gdW5kZXJzdGFuZCB3 aHkgd2UgdXNlIOKAnFNIT1VMROKAnSByYXRoZXIgdGhhbiDigJxNVVNU4oCdPyAgU2V0dGluZyBh IGxvY2FsIHBvbGljeSBpcyBvcHRpb25hbCBidXQgaWYgdGhlcmUgaXMgb25lIGl0IHNlZW1zIHRv IG1lIHRoYXQgIFNJUCBjbGllbnRzIE1VU1QgaG9ub3IgaXQuDQoNCg0KDQoNCg0KDQoNCkRlIDog c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2Vz QGlldGYub3JnPiBbbWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpz aXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZz5dIERlIGxhIHBhcnQgZGUgQ2hhcmxlcyBTaGVu DQpFbnZvecOpIDogc2FtZWRpIDE1IGTDqWNlbWJyZSAyMDEyIDE2OjA2DQrDgCA6IEphbmV0IFAg R3Vubg0KQ2MgOiBOT0VMLCBFUklDIChFUklDIEMpOyBzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRm Lm9yZzxtYWlsdG86c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc+OyBzaXAtb3ZlcmxvYWRA aWV0Zi5vcmc8bWFpbHRvOnNpcC1vdmVybG9hZEBpZXRmLm9yZz47IEFyYXRhIEtvaWtlOyBIZW5u aW5nIFNjaHVsenJpbm5lDQpPYmpldCA6IFJlOiBbc2lwLW92ZXJsb2FkXSBJLUQgQWN0aW9uOiBk cmFmdC1pZXRmLXNvYy1sb2FkLWNvbnRyb2wtZXZlbnQtcGFja2FnZS0wNS50eHQNCg0KDQoNCkhp IEphbmV0LCBJIHdpbGwgcmV2aXNlIGFzIHN1Z2dlc3RlZC4gVGhhbmtzIHlvdSBhZ2FpbiENCg0K Q2hhcmxlcw0KDQpPbiBGcmksIERlYyAxNCwgMjAxMiBhdCAzOjU2IFBNLCBKYW5ldCBQIEd1bm4g PGpndW5uNkBjc2MuY29tPG1haWx0bzpqZ3VubjZAY3NjLmNvbT4+IHdyb3RlOg0KDQpZb3UgY2Fu IGNvdW50IG15IHJldmlldyBmb3IgSUVTRy4NCg0KSSBvbmx5IGhhdmUgYSBjb3VwbGUgb2YgdGhp bmdzIHRvIGFkZC4NCg0KSW4gc2VjdGlvbiA0LjQsIHlvdSBoYXZlIHRoZSB0ZXh0Og0K4oCcSW4g YWRkaXRpb24sIHdoYXRldmVyIHRoZSBhY3R1YWwgcG9saWN5IGlzLCBTSVANCiAgIHNlcnZlcnMg U0hPVUxEIGhvbm9yIHRoZSBsb2NhbCBwb2xpY3kgZm9yIHByaW9yaXRpemluZyBTSVAgcmVxdWVz dHMNCiAgIHN1Y2ggYXMgcG9saWNpZXMgYmFzZWQgb24gdGhlIGNvbnRlbnRzIG9mIHRoZSBSZXNv dXJjZS1Qcmlvcml0eQ0KICAgSGVhZGVyIChSUEgpIFtSRkM0NDEyXS4gIFRoZSBSUEggY29udGVu dHMgbWF5IGluZGljYXRlIGhpZ2ggcHJpb3JpdHkNCiAgIHJlcXVlc3RzIHRoYXQgc2hvdWxkIGJl IHByZXNlcnZlZCBhcyBtdWNoIGFzIHBvc3NpYmxlLCBvciBsb3cNCiAgIHByaW9yaXR5IHJlcXVl c3RzIHRoYXQgY291bGQgYmUgZHJvcHBlZCBkdXJpbmcgb3ZlcmxvYWQuICBPdGhlcg0KICAgaW5k aWNhdG9ycywgc3VjaCBhcyB0aGUgU09TIFVuaWZvcm0gUmVzb3VyY2UgTmFtZSAoVVJOKSBbUkZD NTAzMV0NCiAgIGluZGljYXRpbmcgYW4gZW1lcmdlbmN5IHJlcXVlc3QsIG1heSBhbHNvIGJlIHVz ZWQgZm9yIHByaW9yaXRpemF0aW9uLuKAnQ0KDQpEdXJpbmcgdGhlIGxhc3QgSUVURiBtZWV0aW5n LCB0aGVyZSB3YXMgYW4gZXhjaGFuZ2Ugb24gdGhlIGxpc3QgIGFib3V0IHRoaXMgd29yZGluZyAo aW4gbXVsdGlwbGUgSURzKSB3aXRoIGFwcGFyZW50IGFncmVlbWVudCAob24gdGhlIGxpc3QpIHRv IHVzZSAgdGhlIHNhbWUgdGV4dCBpbiBhbGwgdGhlIG92ZXJsb2FkIGRyYWZ0cw0KDQoiICAgQSBT SVAgY2xpZW50IFNIT1VMRCBob25vciBhbnkgbG9jYWwgcG9saWN5IGZvciBwcmlvcml0aXppbmcg U0lQDQogcmVxdWVzdHMgc3VjaCBhcyBwb2xpY2llcyBiYXNlZCBvbiBtZXNzYWdlIHR5cGUsIGUu Zy4sIElOVklURXMgdnMuDQogIHJlcXVlc3RzIGFzc29jaWF0ZWQgd2l0aCBleGlzdGluZyBzZXNz aW9ucy4NCg0KICBBIFNJUCBjbGllbnQgU0hPVUxEIGhvbm9yIGFueSBsb2NhbCBwb2xpY3kgZm9y IHByaW9yaXRpemluZyBTSVANCiAgcmVxdWVzdHMgYmFzZWQgb24gdGhlIGNvbnRlbnQgb2YgdGhl IFJlc291cmNlLQ0KIFByaW9yaXR5IGhlYWRlciAoUlBILCBSRkM0NDEyIFtSRkM0NDEyXSkuICBT cGVjaWZpYyAobmFtZXNwYWNlLnZhbHVlKQ0KIFJQSCBjb250ZW50cyBtYXkgaW5kaWNhdGUgaGln aCBwcmlvcml0eSByZXF1ZXN0cyB0aGF0IHNob3VsZCBiZQ0KIHByZXNlcnZlZCBhcyBtdWNoIGFz IHBvc3NpYmxlIGR1cmluZyBvdmVybG9hZC4gIFRoZSBSUEggY29udGVudHMgY2FuDQogYWxzbyBp bmRpY2F0ZSBhIGxvdy1wcmlvcml0eSByZXF1ZXN0IHRoYXQgaXMgZWxpZ2libGUgdG8gYmUgZHJv cHBlZA0KIGR1cmluZyB0aW1lcyBvZiBvdmVybG9hZC4NCg0KIEEgU0lQIGNsaWVudCBTSE9VTEQg aG9ub3IgYW55IGxvY2FsIHBvbGljeSBmb3IgcHJpb3JpdGl6aW5nIFNJUA0KIHJlcXVlc3RzIHJl bGF0aW5nIHRvIGVtZXJnZW5jeSBjYWxscywgYXMgaWRlbnRpZmllZCBieSB0aGUgU09TDQogVVJO IFtSRkM1MDMxXSBpbmRpY2F0aW5nIGFuIGVtZXJnZW5jeSByZXF1ZXN0LiINCg0KU28gd291bGQg eW91IHBsZWFzZSB1c2UgdGhpcyByZXZpc2VkIHdvcmRpbmcuDQoNCm5pdHMNCg0KU2VjIDUuOCBs YXN0IHNlbnRlbmNlIG9mIGZpcnN0IHBhcmFncmFwaA0K4oCcQSBzdWJzY3JpYmVyIHJlY2Vpdmlu ZyB0aGUgbm90aWZpY2F0aW9uIGZpcnN0IGluc3RhbGxzDQogICB0aGVzZSBydWxlcyBhbmQgdGhl biBmaWx0ZXIgaW5jb21pbmcgcmVxdWVzdHMgdG8gZW5mb3JjZSBhY3Rpb25zIG9uDQogICBhcHBy b3ByaWF0ZSByZXF1ZXN0cywgZm9yIGV4YW1wbGUsIGxpbWl0aW5nIHRoZSBzZW5kaW5nIHJhdGUg b2YgY2FsbA0KICAgcmVxdWVzdHMgZGVzdGluZWQgZm9yIGEgc3BlY2lmaWMgU0lQIGVudGl0eS7i gJ0NCuKAnGZpbHRlcuKAnSBzaG91bGQgYmUg4oCcZmlsdGVyc+KAnQ0KDQpQZyAxOA0KVGhpcw0K 4oCcdGhpcyBzb2x1dGlvbiBkb2VzIG5vdCBwZXJtaXQgdG8gZGVmaW5lIGEgZmlsdGVyIHRoYXQg ZXhjbHVkZXMNCiAgIGFsbCBFLjE2NCBudW1iZXJzIGluIHRoYXQgY291bnRyeSBidXQgcmV0YWlu IGFsbCBzaG9ydCBzZXJ2aWNlDQogICBudW1iZXJzLuKAnQ0KU2hvdWxkIGJlDQrigJx0aGlzIHNv bHV0aW9uIGRvZXMgbm90IHBlcm1pdCB0aGUgZGVmaW5pdGlvbiBvZiBmaWx0ZXIgdGhhdCBleGNs dWRlcw0KICAgYWxsIEUuMTY0IG51bWJlcnMgaW4gdGhhdCBjb3VudHJ5IGJ1dCByZXRhaW4gYWxs IHNob3J0IHNlcnZpY2UNCiAgIG51bWJlcnMu4oCdDQoNCkphbmV0DQoNClRoaXMgaXMgYSBQUklW QVRFIG1lc3NhZ2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFz ZSBkZWxldGUgd2l0aG91dCBjb3B5aW5nIGFuZCBraW5kbHkgYWR2aXNlIHVzIGJ5IGUtbWFpbCBv ZiB0aGUgbWlzdGFrZSBpbiBkZWxpdmVyeS4gTk9URTogUmVnYXJkbGVzcyBvZiBjb250ZW50LCB0 aGlzIGUtbWFpbCBzaGFsbCBub3Qgb3BlcmF0ZSB0byBiaW5kIENTQyB0byBhbnkgb3JkZXIgb3Ig b3RoZXIgY29udHJhY3QgdW5sZXNzIHB1cnN1YW50IHRvIGV4cGxpY2l0IHdyaXR0ZW4gYWdyZWVt ZW50IG9yIGdvdmVybm1lbnQgaW5pdGlhdGl2ZSBleHByZXNzbHkgcGVybWl0dGluZyB0aGUgdXNl IG9mIGUtbWFpbCBmb3Igc3VjaCBwdXJwb3NlLg0KDQoNCg0KRnJvbTogICAgICAgICJOT0VMLCBF UklDICAoRVJJQyBDKSIgPGVjbm9lbEByZXNlYXJjaC5hdHQuY29tPG1haWx0bzplY25vZWxAcmVz ZWFyY2guYXR0LmNvbT4+DQpUbzogICAgICAgICInQ2hhcmxlcyBTaGVuJyIgPGNoYXJsZXNAY3Mu Y29sdW1iaWEuZWR1PG1haWx0bzpjaGFybGVzQGNzLmNvbHVtYmlhLmVkdT4+LCAic2lwLW92ZXJs b2FkQGlldGYub3JnPG1haWx0bzpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmc+IiA8c2lwLW92ZXJsb2Fk QGlldGYub3JnPG1haWx0bzpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmc+Pg0KQ2M6ICAgICAgICBBcmF0 YSBLb2lrZSA8a29pa2UuYXJhdGFAbGFiLm50dC5jby5qcDxtYWlsdG86a29pa2UuYXJhdGFAbGFi Lm50dC5jby5qcD4+LCBIZW5uaW5nIFNjaHVsenJpbm5lIDxoZ3NAY3MuY29sdW1iaWEuZWR1PG1h aWx0bzpoZ3NAY3MuY29sdW1iaWEuZWR1Pj4NCkRhdGU6ICAgICAgICAxMi8xMy8yMDEyIDAzOjAx IFBNDQoNClN1YmplY3Q6ICAgICAgICBSZTogW3NpcC1vdmVybG9hZF0gSS1EICAgICAgICBBY3Rp b246ICAgICAgICBkcmFmdC1pZXRmLXNvYy1sb2FkLWNvbnRyb2wtZXZlbnQtcGFja2FnZS0wNS50 eHQNCg0KU2VudCBieTogICAgICAgIHNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPG1haWx0 bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZz4NCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCg0KDQoNCkNoYXJsZXMsDQoNCkkgd2VudCB0aHJvdWdoIHlvdXIgbGF0ZXN0 IHZlcnNpb24gYW5kIGhhdmUgbm8gY29tbWVudHMgYmV5b25kIHdoYXQgd2FzIGFscmVhZHkgcG9z dGVkLg0KDQpZb3UgY2FuIGhhdmUgbXkgcmV2aWV3IGNvdW50ZWQgZm9yIHRoZSBJRVNHIHJldmll dy4NCg0KVGhhbmtzLA0KDQpFcmljIE5vZWwNCkFUJlQgTGFicywgSW5jLg0KUmV0aGluayBQb3Nz aWJsZQ0KDQpOZXR3b3JrIERlc2lnbiBhbmQgUGVyZm9ybWFuY2UgQW5hbHlzaXMNCjIwMCBTb3V0 aCBMYXVyZWwgQXZlbnVlLCBENS0zRDE5DQpNaWRkbGV0b3duLCBOSiAwNzc0OA0KUDogNzMyLjQy MC40MTc0PHRlbDo3MzIuNDIwLjQxNzQ+DQplY25vZWxAYXR0LmNvbTxtYWlsdG86anNtaXRoQGF0 dC5jb20+DQoNCkZyb206IHNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzaXAt b3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIENoYXJsZXMgU2hlbg0KU2VudDogTW9uZGF5LCBPY3RvYmVy IDIyLCAyMDEyIDEyOjQ3IFBNDQpUbzogc2lwLW92ZXJsb2FkQGlldGYub3JnPG1haWx0bzpzaXAt b3ZlcmxvYWRAaWV0Zi5vcmc+DQpDYzogQXJhdGEgS29pa2U7IEhlbm5pbmcgU2NodWx6cmlubmUN ClN1YmplY3Q6IFJlOiBbc2lwLW92ZXJsb2FkXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXNvYy1s b2FkLWNvbnRyb2wtZXZlbnQtcGFja2FnZS0wNS50eHQNCg0KSGkgYWxsLA0KDQpJJ3ZlIHN1Ym1p dHRlZCBhIG5ldyB2ZXJzaW9uIG9mIGRyYWZ0LWlldGYtc29jLWxvYWQtY29udHJvbC1ldmVudC1w YWNrYWdlLg0KDQpEaWZmIGlzIGF2YWlsYWJsZSBhdDogaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtaWV0Zi1zb2MtbG9hZC1jb250cm9sLWV2ZW50LXBhY2thZ2UtMDUNCg0K VGhpcyB2ZXJzaW9uIHNob3VsZCBoYXZlIGluY29ycG9yYXRlZCByZXNwb25zZXMgdG8gYWxsIGNv bW1lbnRzIHJlY2VpdmVkIHNvIGZhciAocGxlYXNlIGxldCBtZSBrbm93IGlmIEkgbWlzc2VkIGFu eXRoaW5nKS4gTWFpbiBjaGFuZ2VzIGluY2x1ZGUgYWRkaW5nOiA2LjMuMyAodGFyZ2V0LXNpcC1l bnRpdHksIGN1cnJlbnRseSBvcHRpb25hbCkgNi41LjIgKGV4YW1wbGUgbWVzc2FnZSBmbG93KSwg cmVtb3ZpbmcgNS4xMiAoc3RhdGUgYWdlbnQpLCBhcyB3ZWxsIGFzIGNoYW5nZXMgYW5kIGNsYXJp ZmljYXRpb25zIGluIGEgbnVtYmVyIG9mIG90aGVyIHNlY3Rpb25zLCBlLmcuLCA2LjMuMiAoZXhw bGljaXQgbGlzdCBvZiBtZXRob2QgdHlwZXMgc3ViamVjdGVkIHRvIGNvbnRyb2wpIDYuNCAodXNp bmcgcmVkaXJlY3QgYXMgYWx0ZXJuYXRpdmUgYWN0aW9uKSwgNS44ICh0ZXJtaW5hdGluZyBwb2xp Y2llcyB1cG9uIHRlcm1pbmF0aW9uIG9mIHN1YnNjcmlwdGlvbikgYW5kIDEzLjIgUFNUTiByZWZl cmVuY2VzLg0KDQpDb21tZW50cyBhcmUgd2VsY29tZSAhDQoNCkNoYXJsZXMNCg0KDQoNCk9uIE1v biwgT2N0IDIyLCAyMDEyIGF0IDEyOjMyIFBNLCA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+PiB3cm90ZToNCg0KQSBOZXcgSW50ZXJuZXQt RHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVj dG9yaWVzLg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgU0lQIE92ZXJsb2FkIENv bnRyb2wgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4NCg0KICAgICAgIFRpdGxlICAgICAgICAg ICA6IEEgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChTSVApIExvYWQgQ29udHJvbCBFdmVu dCBQYWNrYWdlDQogICAgICAgQXV0aG9yKHMpICAgICAgIDogQ2hhcmxlcyBTaGVuDQogICAgICAg ICAgICAgICAgICAgICAgICAgSGVubmluZyBTY2h1bHpyaW5uZQ0KICAgICAgICAgICAgICAgICAg ICAgICAgIEFyYXRhIEtvaWtlDQogICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1z b2MtbG9hZC1jb250cm9sLWV2ZW50LXBhY2thZ2UtMDUudHh0DQogICAgICAgUGFnZXMgICAgICAg ICAgIDogMzkNCiAgICAgICBEYXRlICAgICAgICAgICAgOiAyMDEyLTEwLTIyDQoNCkFic3RyYWN0 Og0KICBXZSBkZWZpbmUgYSBsb2FkIGNvbnRyb2wgZXZlbnQgcGFja2FnZSBmb3IgdGhlIFNlc3Np b24gSW5pdGlhdGlvbg0KICBQcm90b2NvbCAoU0lQKS4gIEl0IGFsbG93cyBTSVAgc2VydmVycyB0 byBkaXN0cmlidXRlIGxvYWQgZmlsdGVycyB0bw0KICBvdGhlciBTSVAgc2VydmVycyBpbiB0aGUg bmV0d29yay4gIFRoZSBsb2FkIGZpbHRlcnMgY29udGFpbiBydWxlcyB0bw0KICB0aHJvdHRsZSBj YWxscyBiYXNlZCBvbiB0aGVpciBzb3VyY2Ugb3IgZGVzdGluYXRpb24gZG9tYWluLCB0ZWxlcGhv bmUNCiAgbnVtYmVyIHByZWZpeCBvciBmb3IgYSBzcGVjaWZpYyB1c2VyLiAgVGhlIG1lY2hhbmlz bSBoZWxwcyB0byBwcmV2ZW50DQogIHNpZ25hbGluZyBvdmVybG9hZCBhbmQgY29tcGxlbWVudHMg ZmVlZGJhY2stYmFzZWQgU0lQIG92ZXJsb2FkDQogIGNvbnRyb2wgZWZmb3J0cy4NCg0KDQpUaGUg SUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc29jLWxvYWQtY29udHJvbC1ldmVu dC1wYWNrYWdlDQoNClRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0 Og0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zb2MtbG9hZC1jb250cm9s LWV2ZW50LXBhY2thZ2UtMDUNCg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMg YXZhaWxhYmxlIGF0Og0KaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0 Zi1zb2MtbG9hZC1jb250cm9sLWV2ZW50LXBhY2thZ2UtMDUNCg0KDQpJbnRlcm5ldC1EcmFmdHMg YXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzLw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0Kc2lwLW92ZXJsb2FkIG1haWxpbmcgbGlzdA0Kc2lwLW92ZXJsb2FkQGll dGYub3JnPG1haWx0bzpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NpcC1vdmVybG9hZA0KIF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpzaXAtb3ZlcmxvYWQgbWFpbGluZyBsaXN0DQpzaXAt b3ZlcmxvYWRAaWV0Zi5vcmc8bWFpbHRvOnNpcC1vdmVybG9hZEBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwLW92ZXJsb2FkDQoNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVz IGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZl bnQgZG9uYw0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRv cmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxs ZXogbGUgc2lnbmFsZXINCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBs ZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2Nl cHRpYmxlcyBkJ2FsdGVyYXRpb24sDQpGcmFuY2UgVGVsZWNvbSAtIE9yYW5nZSBkZWNsaW5lIHRv dXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91 IGZhbHNpZmllLiBNZXJjaS4NCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5 IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkg YmUgcHJvdGVjdGVkIGJ5IGxhdzsNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNl ZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUg dGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVy ZWQsIEZyYW5jZSBUZWxlY29tIC0gT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRo YXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NClRoYW5rIHlvdS4N Cg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29u dGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0 IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBz YW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVy LCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5z aSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFu dCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApGcmFuY2UgVGVsZWNvbSAtIE9yYW5nZSBkZWNs aW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZv cm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRz IG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQg bWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwg dXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0 ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRl cmVkLCBGcmFuY2UgVGVsZWNvbSAtIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0 aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4K Cg== --_000_88CAD1D4E8773F42858B58CAA28272A00E8050PEXCVZYM12corpora_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEBTaW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEgNiA0 IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGku TXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4t cmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBj bTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJz ZXJpZiI7fQ0KdHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxl cyBDYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5UZXh0 ZWRlYnVsbGVzQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxlcyI7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIx DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkZSIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgd291bGQgc2F5IGl0IGlzIHRoZSDCqyZuYnNw O2xvY2FsIHBvbGljeSZuYnNwO8K7IGRlZmluZWQgYnkgdGhlIGNhcnJpZXIgYnV0IGl0IGhhcyB0 byBjb21wbHkgd2l0aCB0aGUgcmVndWxhdGlvbiBpbiBmb3JjZSBpbiB0aGUgY291bnRyeSB3aGVy ZSB0aGUgY2Fycmllcg0KIGlzIG9wZXJhdGluZy4gJm5ic3A7Jm5ic3A74oCcU2hvdWxk4oCdIGNv dWxkIGJlIHVuZGVyc3Rvb2QgYXMgcHJvdmlkaW5nIHJvb20gZm9yIG5vdCBob25vcmluZyBhbnkg bG9jYWwgcG9saWN5IGV4Y2VwdCBvbmUgdGhhdCBoYXMgYmVlbiBoYXJkLWNvZGVkIGJ5IHRoZSB2 ZW5kb3Igb2YgdGhlIGVxdWlwbWVudC4gJm5ic3A7QW4gdW5kZXNpcmFibGUgc2lkZS1lZmZlY3Qg d291bGQgYmUgdGhhdCBkaWZmZXJlbnQgU0lQIGVudGl0aWVzIGZyb20gZGlmZmVyZW50IHZlbmRv cnMgY291bGQNCiByZWFjdCBkaWZmZXJlbnRseSB3aGlsZSBiZWluZyB1c2VkIGluIHRoZSBzYW1l IG5ldHdvcmsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CQzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IEphbmV0IFAgR3VubiBbbWFpbHRvOmpndW5uNkBjc2MuY29tXQ0KPGJyPg0KPGI+RW52b3nD qSZuYnNwOzo8L2I+IGx1bmRpIDMxIGTDqWNlbWJyZSAyMDEyIDE4OjE3PGJyPg0KPGI+w4AmbmJz cDs6PC9iPiBDaGFybGVzIFNoZW48YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IENIQVRSQVMgQnJ1bm8g T0xOQy9PTE47IGNoYXJsZXMubmV3eW9ya0BnbWFpbC5jb207IE5PRUwsIEVSSUMgKEVSSUMgQyk7 IEhlbm5pbmcgU2NodWx6cmlubmU7IEFyYXRhIEtvaWtlOyBzaXAtb3ZlcmxvYWRAaWV0Zi5vcmc7 IHNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBM b2NhbCBQb2xpY3kgUmU6IFtzaXAtb3ZlcmxvYWRdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtc29j LWxvYWQtY29udHJvbC1ldmVudC1wYWNrYWdlLTA1LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4N Ckkgd291bGQgJm5ic3A7YmUgaGFwcHkgd2l0aCAmcXVvdDtNVVNUJnF1b3Q7LCBidXQgSSdkIGxp a2UgdG8gaGVhciBmb3JtIHRoZSBjYXJyaWVycy0gZXNwZWNpYWxseSBmcm9tIEtlaXRoIERyYWdl LCBhcyBoZSBpcyB0aGUgb25lIHdobyBpbml0aWF0ZWQgdGhlIG5ldyB3b3JkaW5nLjwvc3Bhbj4N Cjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkl0IG1heSBiZSBhIHF1ZXN0 aW9uIG9mICZuYnNwO1dIT1NFIGxvY2FsIHBvbGljeSB3ZSBhcmUgdGFsa2luZyBhYm91dC4gJm5i c3A7IFRoZXJlIGlzIHRoZSAmcXVvdDtsb2NhbCBwb2xpY3kmcXVvdDsgYXMgZGVmaW5lZCBieSB0 aGUgZ292ZXJubWVudCAod2hpY2ggbWF5IHBvbGl0aWNhbGx5IGNvcnJlY3QgYnV0IHRlY2huaWNh bGx5IHVuc3RhYmxlKS4gJm5ic3A7VGhlcmUgaXMNCiBhbHNvICZxdW90O2xvY2FsIHBvbGljeSZx dW90OyBkZWZpbmVkIGJ5IHRoZSAmcXVvdDtjYXJyaWVyJnF1b3Q7ICh3aGljaCBtYXkgYmUgJm5i c3A7dGVjaG5pY2FsbHkgc3RhYmxlLCBidXQgcG9saXRpY2FsbHkgaW5jb3JyZWN0KS48L3NwYW4+ DQo8YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mcXVvdDtTaG91bGQmcXVv dDsgbGVhdmVzIHNvbWUgd2lnZ2xlIHJvb20gYXMgdG8gV0hJQ0ggbG9jYWwgcG9saWN5ICZuYnNw O2lzIGJlaW5nIGhvbm9yZWQuPC9zcGFuPg0KPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+SmFuZXQ8L3NwYW4+IDxicj4NCjxicj4NCjxicj4NCjxicj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojNUY1RjVGIj5Gcm9tOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5DaGFybGVzIFNoZW4gJmx0Ozxh IGhyZWY9Im1haWx0bzpjaGFybGVzQGNzLmNvbHVtYmlhLmVkdSI+Y2hhcmxlc0Bjcy5jb2x1bWJp YS5lZHU8L2E+Jmd0Ozwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojNUY1RjVGIj5UbzogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0ibWFpbHRvOmJydW5vLmNoYXRyYXNAb3JhbmdlLmNv bSI+YnJ1bm8uY2hhdHJhc0BvcmFuZ2UuY29tPC9hPjwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojNUY1RjVGIj5DYzogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SmFuZXQgUCBHdW5uL1VTQS9DU0NA Q1NDLCAmcXVvdDtOT0VMLCBFUklDIChFUklDIEMpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 ZWNub2VsQGF0dC5jb20iPmVjbm9lbEBhdHQuY29tPC9hPiZndDssDQogJnF1b3Q7PGEgaHJlZj0i bWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnIj5zaXAtb3ZlcmxvYWQtYm91bmNl c0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWQtYm91 bmNlc0BpZXRmLm9yZyI+c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1 b3Q7PGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZEBpZXRmLm9yZyI+c2lwLW92ZXJsb2FkQGll dGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZEBpZXRmLm9y ZyI+c2lwLW92ZXJsb2FkQGlldGYub3JnPC9hPiZndDssDQogQXJhdGEgS29pa2UgJmx0OzxhIGhy ZWY9Im1haWx0bzprb2lrZS5hcmF0YUBsYWIubnR0LmNvLmpwIj5rb2lrZS5hcmF0YUBsYWIubnR0 LmNvLmpwPC9hPiZndDssIEhlbm5pbmcgU2NodWx6cmlubmUgJmx0OzxhIGhyZWY9Im1haWx0bzpo Z3NAY3MuY29sdW1iaWEuZWR1Ij5oZ3NAY3MuY29sdW1iaWEuZWR1PC9hPiZndDs8L3NwYW4+DQo8 YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzVGNUY1RiI+RGF0ZTogJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+MTIv MTgvMjAxMiAxMDozMiBQTTwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojNUY1RjVGIj5TdWJqZWN0OiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5SZTogW3NpcC1vdmVybG9hZF0gSS1EIEFjdGlvbjog ZHJhZnQtaWV0Zi1zb2MtbG9hZC1jb250cm9sLWV2ZW50LXBhY2thZ2UtMDUudHh0PC9zcGFuPg0K PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1RjVGNUYiPlNlbnQgYnk6ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PjxhIGhyZWY9Im1haWx0bzpjaGFybGVzLm5ld3lvcmtAZ21haWwuY29tIj5jaGFybGVzLm5ld3lv cmtAZ21haWwuY29tPC9hPjwvc3Bhbj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBjbGFzcz0iTXNv Tm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNp emU9IjIiIHdpZHRoPSIxMDAlIiBub3NoYWRlPSIiIHN0eWxlPSJjb2xvcjojQTBBMEEwIiBhbGln bj0iY2VudGVyIj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJy Pg0KSGkgQnJ1bm8sIEkgbm90aWNlZCB5b3VyIGNvbW1lbnQsIGNhbiB3ZSByZWFjaCBhIGNvbnNl bnN1cyBvbiB0aGlzIGxpc3Qgc28gSSBjYW4gdXBkYXRlIHRoZSBkcmFmdCBhY2NvcmRpbmdseT8m bmJzcDsNCjxicj4NCjxicj4NClRoYW5rcyEgPGJyPg0KPGJyPg0KQ2hhcmxlczxicj4NCjxicj4N Ck9uIE1vbiwgRGVjIDE3LCAyMDEyIGF0IDEwOjI4IEFNLCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJy dW5vLmNoYXRyYXNAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJydW5vLmNoYXRyYXNAb3Jh bmdlLmNvbTwvYT4mZ3Q7IHdyb3RlOg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMwMDQwODAiPkkgYWdyZWUgdGhhdCBib3RoIGRyYWZ0cyBzaG91bGQgdXNlIHRoZSBz YW1lIHRleHQgYnV0IEnigJltIHN0aWxsIG5vdCBzdXJlIHRvIHVuZGVyc3RhbmQgd2h5IHdlIHVz ZSDigJxTSE9VTETigJ0gcmF0aGVyIHRoYW4g4oCcTVVTVOKAnT8gJm5ic3A7U2V0dGluZyBhIGxv Y2FsIHBvbGljeSBpcyBvcHRpb25hbCBidXQgaWYgdGhlcmUgaXMNCiBvbmUgaXQgc2VlbXMgdG8g bWUgdGhhdCAmbmJzcDtTSVAgY2xpZW50cyBNVVNUIGhvbm9yIGl0Ljwvc3Bhbj4gPG86cD48L286 cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwNDA4MCI+Jm5i c3A7PC9zcGFuPg0KPG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzAwNDA4MCI+Jm5ic3A7PC9zcGFuPg0KPG86cD48L286cD48L3A+DQo8cD48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwNDA4MCI+Jm5ic3A7PC9zcGFuPg0KPG86 cD48L286cD48L3A+DQo8cD48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPC9z cGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFttYWlsdG86PC9zcGFuPjxhIGhy ZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5zaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9y Zzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPl0NCjxiPkRlIGxhIHBhcnQg ZGU8L2I+IENoYXJsZXMgU2hlbjxiPjxicj4NCkVudm95w6kmbmJzcDs6PC9iPiBzYW1lZGkgMTUg ZMOpY2VtYnJlIDIwMTIgMTY6MDY8Yj48YnI+DQrDgCZuYnNwOzo8L2I+IEphbmV0IFAgR3Vubjxi Pjxicj4NCkNjJm5ic3A7OjwvYj4gTk9FTCwgRVJJQyAoRVJJQyBDKTsgPC9zcGFuPjxhIGhyZWY9 Im1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5zaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzwv c3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjsNCjwvc3Bhbj48YSBocmVmPSJt YWlsdG86c2lwLW92ZXJsb2FkQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPnNpcC1vdmVybG9hZEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPjsgQXJhdGEgS29pa2U7IEhlbm5pbmcgU2NodWx6cmlubmU8Yj48 YnI+DQpPYmpldCZuYnNwOzo8L2I+IFJlOiBbc2lwLW92ZXJsb2FkXSBJLUQgQWN0aW9uOiBkcmFm dC1pZXRmLXNvYy1sb2FkLWNvbnRyb2wtZXZlbnQtcGFja2FnZS0wNS50eHQ8L3NwYW4+DQo8bzpw PjwvbzpwPjwvcD4NCjxwPiZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwPkhpIEphbmV0LCBJIHdp bGwgcmV2aXNlIGFzIHN1Z2dlc3RlZC4gVGhhbmtzIHlvdSBhZ2FpbiE8YnI+DQo8YnI+DQpDaGFy bGVzIDxvOnA+PC9vOnA+PC9wPg0KPHA+T24gRnJpLCBEZWMgMTQsIDIwMTIgYXQgMzo1NiBQTSwg SmFuZXQgUCBHdW5uICZsdDs8YSBocmVmPSJtYWlsdG86amd1bm42QGNzYy5jb20iIHRhcmdldD0i X2JsYW5rIj5qZ3VubjZAY3NjLmNvbTwvYT4mZ3Q7IHdyb3RlOg0KPG86cD48L286cD48L3A+DQo8 cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+WW91IGNhbiBjb3VudCBteSByZXZpZXcgZm9yIElFU0cuPC9zcGFuPg0KPGJy Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxicj4NCkkgb25seSBoYXZlIGEgY291cGxlIG9mIHRoaW5ncyB0byBhZGQu PC9zcGFuPiA8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KSW4gc2VjdGlvbiA0LjQsIHlvdSBoYXZlIHRo ZSB0ZXh0Ojwvc3Bhbj4gPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGJyPg0K4oCcSW4gYWRkaXRpb24sIHdoYXRldmVy IHRoZSBhY3R1YWwgcG9saWN5IGlzLCBTSVA8L3NwYW4+IDxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjxicj4NCiZuYnNw OyAmbmJzcDtzZXJ2ZXJzIFNIT1VMRCBob25vciB0aGUgbG9jYWwgcG9saWN5IGZvciBwcmlvcml0 aXppbmcgU0lQIHJlcXVlc3RzPC9zcGFuPiA8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8YnI+DQombmJzcDsgJm5ic3A7 c3VjaCBhcyBwb2xpY2llcyBiYXNlZCBvbiB0aGUgY29udGVudHMgb2YgdGhlIFJlc291cmNlLVBy aW9yaXR5PC9zcGFuPiA8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8YnI+DQombmJzcDsgJm5ic3A7SGVhZGVyIChSUEgp IFtSRkM0NDEyXS4gJm5ic3A7VGhlIFJQSCBjb250ZW50cyBtYXkgaW5kaWNhdGUgaGlnaCBwcmlv cml0eTwvc3Bhbj4gPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGJyPg0KJm5ic3A7ICZuYnNwO3JlcXVlc3RzIHRoYXQg c2hvdWxkIGJlIHByZXNlcnZlZCBhcyBtdWNoIGFzIHBvc3NpYmxlLCBvciBsb3c8L3NwYW4+IDxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4NCjxicj4NCiZuYnNwOyAmbmJzcDtwcmlvcml0eSByZXF1ZXN0cyB0aGF0IGNvdWxk IGJlIGRyb3BwZWQgZHVyaW5nIG92ZXJsb2FkLiAmbmJzcDtPdGhlcjwvc3Bhbj4gPHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi Pg0KPGJyPg0KJm5ic3A7ICZuYnNwO2luZGljYXRvcnMsIHN1Y2ggYXMgdGhlIFNPUyBVbmlmb3Jt IFJlc291cmNlIE5hbWUgKFVSTikgW1JGQzUwMzFdPC9zcGFuPiA8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8YnI+DQom bmJzcDsgJm5ic3A7aW5kaWNhdGluZyBhbiBlbWVyZ2VuY3kgcmVxdWVzdCwgbWF5IGFsc28gYmUg dXNlZCBmb3IgcHJpb3JpdGl6YXRpb24u4oCdIDwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+ DQpEdXJpbmcgdGhlIGxhc3QgSUVURiBtZWV0aW5nLCB0aGVyZSB3YXMgYW4gZXhjaGFuZ2Ugb24g dGhlIGxpc3QgJm5ic3A7YWJvdXQgdGhpcyB3b3JkaW5nIChpbiBtdWx0aXBsZSBJRHMpIHdpdGgg YXBwYXJlbnQgYWdyZWVtZW50IChvbiB0aGUgbGlzdCkgdG8gdXNlICZuYnNwO3RoZSBzYW1lIHRl eHQgaW4gYWxsIHRoZSBvdmVybG9hZCBkcmFmdHM8L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCiZxdW90OyAmbmJzcDsg QSBTSVAgY2xpZW50IFNIT1VMRCBob25vciBhbnkgbG9jYWwgcG9saWN5IGZvciBwcmlvcml0aXpp bmcgU0lQPGJyPg0KJm5ic3A7cmVxdWVzdHMgc3VjaCBhcyBwb2xpY2llcyBiYXNlZCA8aT5vbiBt ZXNzYWdlIHR5cGUsIGUuZy4sIElOVklURXMgdnMuPC9pPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjwv c3Bhbj48aT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi Pjxicj4NCiZuYnNwOyByZXF1ZXN0cyBhc3NvY2lhdGVkIHdpdGggZXhpc3Rpbmcgc2Vzc2lvbnMu PC9zcGFuPjwvaT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCiZuYnNwOyA8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+PGJyPg0KJm5ic3A7IDxpPkEgU0lQIGNsaWVudCBTSE9VTEQgaG9ub3IgYW55IGxvY2Fs IHBvbGljeSBmb3IgcHJpb3JpdGl6aW5nIFNJUCA8YnI+DQombmJzcDsgcmVxdWVzdHMgYmFzZWQ8 L2k+IG9uIHRoZSBjb250ZW50IG9mIHRoZSBSZXNvdXJjZS08YnI+DQombmJzcDtQcmlvcml0eSBo ZWFkZXIgKFJQSCwgUkZDNDQxMiBbUkZDNDQxMl0pLiAmbmJzcDtTcGVjaWZpYyAobmFtZXNwYWNl LnZhbHVlKTxicj4NCiZuYnNwO1JQSCBjb250ZW50cyBtYXkgaW5kaWNhdGUgaGlnaCBwcmlvcml0 eSByZXF1ZXN0cyB0aGF0IHNob3VsZCBiZTxicj4NCiZuYnNwO3ByZXNlcnZlZCBhcyBtdWNoIGFz IHBvc3NpYmxlIGR1cmluZyBvdmVybG9hZC4gJm5ic3A7VGhlIFJQSCBjb250ZW50cyBjYW48YnI+ DQombmJzcDthbHNvIGluZGljYXRlIGEgbG93LXByaW9yaXR5IHJlcXVlc3QgdGhhdCBpcyBlbGln aWJsZSB0byBiZSBkcm9wcGVkPGJyPg0KJm5ic3A7ZHVyaW5nIHRpbWVzIG9mIG92ZXJsb2FkLiAm bmJzcDs8YnI+DQo8YnI+DQombmJzcDtBIFNJUCBjbGllbnQgU0hPVUxEIGhvbm9yIGFueSBsb2Nh bCBwb2xpY3kgZm9yIHByaW9yaXRpemluZyBTSVAgPGJyPg0KJm5ic3A7cmVxdWVzdHMgcmVsYXRp bmcgdG8gZW1lcmdlbmN5IGNhbGxzLCBhcyBpZGVudGlmaWVkIGJ5IHRoZSBTT1MgPGJyPg0KJm5i c3A7VVJOIFtSRkM1MDMxXSBpbmRpY2F0aW5nIGFuIGVtZXJnZW5jeSByZXF1ZXN0LiZxdW90Ozwv c3Bhbj4gPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij48YnI+DQpTbyB3b3VsZCB5b3UgcGxlYXNlIHVzZSB0aGlzIHJldmlzZWQgd29yZGluZy48 L3NwYW4+IDxicj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+PGJyPg0Kbml0czwvc3Bhbj4gPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQpTZWMgNS44IGxhc3Qgc2VudGVuY2Ugb2YgZmly c3QgcGFyYWdyYXBoPC9zcGFuPiA8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPg0KPGJyPg0K4oCcQSBzdWJzY3JpYmVyIHJlY2VpdmluZyB0aGUgbm90aWZp Y2F0aW9uIGZpcnN0IGluc3RhbGxzPC9zcGFuPiA8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPg0KPGJyPg0KJm5ic3A7ICZuYnNwO3RoZXNlIHJ1bGVzIGFu ZCB0aGVuIGZpbHRlciBpbmNvbWluZyByZXF1ZXN0cyB0byBlbmZvcmNlIGFjdGlvbnMgb248L3Nw YW4+IDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+DQo8 YnI+DQombmJzcDsgJm5ic3A7YXBwcm9wcmlhdGUgcmVxdWVzdHMsIGZvciBleGFtcGxlLCBsaW1p dGluZyB0aGUgc2VuZGluZyByYXRlIG9mIGNhbGw8L3NwYW4+IDxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+DQo8YnI+DQombmJzcDsgJm5ic3A7cmVxdWVz dHMgZGVzdGluZWQgZm9yIGEgc3BlY2lmaWMgU0lQIGVudGl0eS7igJ08L3NwYW4+IDxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+DQo8YnI+DQrigJxmaWx0 ZXLigJ0gc2hvdWxkIGJlIOKAnGZpbHRlcnPigJ08L3NwYW4+IDxicj4NCjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KUGcgMTg8L3NwYW4+IDxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KVGhp czwvc3Bhbj4gPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij48YnI+DQrigJx0aGlzIHNvbHV0aW9uIGRvZXMgbm90IHBlcm1pdCB0byBkZWZpbmUgYSBmaWx0 ZXIgdGhhdCBleGNsdWRlczwvc3Bhbj4gPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4NCjxicj4NCiZuYnNwOyAmbmJzcDthbGwgRS4xNjQgbnVtYmVycyBp biB0aGF0IGNvdW50cnkgYnV0IHJldGFpbiBhbGwgc2hvcnQgc2VydmljZTwvc3Bhbj4gPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4NCjxicj4NCiZuYnNw OyAmbmJzcDtudW1iZXJzLuKAnTwvc3Bhbj4gPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQpTaG91bGQgYmU8L3NwYW4+IDxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0K4oCcdGhpcyBzb2x1dGlv biBkb2VzIG5vdCBwZXJtaXQgdGhlIGRlZmluaXRpb24gb2YgZmlsdGVyIHRoYXQgZXhjbHVkZXM8 L3NwYW4+IDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ DQo8YnI+DQombmJzcDsgJm5ic3A7YWxsIEUuMTY0IG51bWJlcnMgaW4gdGhhdCBjb3VudHJ5IGJ1 dCByZXRhaW4gYWxsIHNob3J0IHNlcnZpY2U8L3NwYW4+IDxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+DQo8YnI+DQombmJzcDsgJm5ic3A7bnVtYmVycy7i gJ08L3NwYW4+IDxicj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQpKYW5ldDxicj4NCjxicj4NClRoaXMgaXMg YSBQUklWQVRFIG1lc3NhZ2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQs IHBsZWFzZSBkZWxldGUgd2l0aG91dCBjb3B5aW5nIGFuZCBraW5kbHkgYWR2aXNlIHVzIGJ5IGUt bWFpbCBvZiB0aGUgbWlzdGFrZSBpbiBkZWxpdmVyeS4gTk9URTogUmVnYXJkbGVzcyBvZiBjb250 ZW50LCB0aGlzIGUtbWFpbCBzaGFsbCBub3Qgb3BlcmF0ZSB0byBiaW5kIENTQyB0byBhbnkgb3Jk ZXIgb3Igb3RoZXIgY29udHJhY3QNCiB1bmxlc3MgcHVyc3VhbnQgdG8gZXhwbGljaXQgd3JpdHRl biBhZ3JlZW1lbnQgb3IgZ292ZXJubWVudCBpbml0aWF0aXZlIGV4cHJlc3NseSBwZXJtaXR0aW5n IHRoZSB1c2Ugb2YgZS1tYWlsIGZvciBzdWNoIHB1cnBvc2UuPC9zcGFuPg0KPGJyPg0KPGJyPg0K PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1RjVGNUYiPjxicj4NCkZyb206 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiZxdW90O05PRUwsIEVSSUMgJm5ic3A7KEVSSUMgQykmcXVvdDsgJmx0Ozwvc3Bhbj48YSBo cmVmPSJtYWlsdG86ZWNub2VsQHJlc2VhcmNoLmF0dC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPmVjbm9lbEByZXNlYXJjaC5hdHQuY29tPC9zcGFuPjwvYT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDs8L3NwYW4+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzVGNUY1RiI+PGJyPg0KVG86ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZxdW90OydDaGFybGVzIFNoZW4nJnF1 b3Q7ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmNoYXJsZXNAY3MuY29sdW1iaWEuZWR1IiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5jaGFybGVzQGNzLmNvbHVt YmlhLmVkdTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7LA0KICZxdW90 Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86c2lwLW92ZXJsb2FkQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5zaXAtb3ZlcmxvYWRAaWV0Zi5vcmc8L3Nw YW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+JnF1b3Q7ICZsdDs8L3NwYW4+PGEgaHJl Zj0ibWFpbHRvOnNpcC1vdmVybG9hZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+c2lwLW92ZXJsb2FkQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiZndDs8L3NwYW4+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjcu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzVGNUY1RiI+PGJyPg0KQ2M6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkFyYXRhIEtvaWtlICZsdDs8L3NwYW4+PGEgaHJl Zj0ibWFpbHRvOmtvaWtlLmFyYXRhQGxhYi5udHQuY28uanAiIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPmtvaWtlLmFyYXRhQGxhYi5udHQuY28uanA8L3NwYW4+PC9h PjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OywNCiBIZW5uaW5nIFNjaHVsenJpbm5lICZs dDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmhnc0Bjcy5jb2x1bWJpYS5lZHUiIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmhnc0Bjcy5jb2x1bWJpYS5lZHU8L3NwYW4+ PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0Ozwvc3Bhbj4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojNUY1RjVGIj48YnI+DQpEYXRlOiAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4xMi8xMy8yMDEyIDAzOjAx IFBNPC9zcGFuPg0KPG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzVGNUY1RiI+U3ViamVjdDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UmU6IFtzaXAtb3ZlcmxvYWRdIEktRCAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtBY3Rpb246ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Ry YWZ0LWlldGYtc29jLWxvYWQtY29udHJvbC1ldmVudC1wYWNrYWdlLTA1LnR4dDwvc3Bhbj4NCjxv OnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1RjVGNUYi PlNlbnQgYnk6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWls dG86c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwv YT4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVy IiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBu b3NoYWRlPSIiIHN0eWxlPSJjb2xvcjojQTBBMEEwIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0K PHA+PGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA0MDgwIj48YnI+DQpDaGFybGVzLDwv c3Bhbj4gPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA0MDgwIj48YnI+DQombmJzcDs8L3NwYW4+IDxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzAwNDA4MCI+PGJyPg0KSSB3ZW50IHRocm91Z2ggeW91ciBsYXRlc3QgdmVy c2lvbiBhbmQgaGF2ZSBubyBjb21tZW50cyBiZXlvbmQgd2hhdCB3YXMgYWxyZWFkeSBwb3N0ZWQu PC9zcGFuPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA0MDgwIj48YnI+DQombmJzcDs8L3NwYW4+IDxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzAwNDA4MCI+PGJyPg0KWW91IGNhbiBoYXZlIG15IHJldmlldyBjb3Vu dGVkIGZvciB0aGUgSUVTRyByZXZpZXcuPC9zcGFuPiA8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDQwODAi Pg0KPGJyPg0KJm5ic3A7PC9zcGFuPiA8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDQwODAiPjxicj4NClRo YW5rcyw8L3NwYW4+IDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwNDA4MCI+PGJyPg0KJm5ic3A7PC9zcGFu PiA8c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojRkY4MTAwIj4NCjxicj4NCkVyaWMg Tm9lbDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNUY1RjVGIj4NCjxi Pjxicj4NCkFUJmFtcDtUIExhYnMsIEluYy48L2I+IDwvc3Bhbj48aT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMDBBMUUwIj48YnI+DQpSZXRoaW5rIFBvc3NpYmxlPC9zcGFuPjwv aT4gPGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtWZXJk YW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwQTFFMCI+PGJyPg0KJm5i c3A7PC9zcGFuPjwvaT4gPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTom cXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzVGNUY1RiI+ DQo8YnI+DQpOZXR3b3JrIERlc2lnbiBhbmQgUGVyZm9ybWFuY2UgQW5hbHlzaXM8YnI+DQoyMDAg U291dGggTGF1cmVsIEF2ZW51ZSwgRDUtM0QxOTxicj4NCk1pZGRsZXRvd24sIE5KIDA3NzQ4PGJy Pg0KUDogPC9zcGFuPjxhIGhyZWY9InRlbDo3MzIuNDIwLjQxNzQiIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+NzMyLjQyMC40MTc0PC9zcGFuPjwvYT4NCjx1Pjxz cGFuIHN0eWxlPSJjb2xvcjpibHVlIj48YnI+DQo8L3NwYW4+PC91PjxhIGhyZWY9Im1haWx0bzpq c21pdGhAYXR0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5lY25vZWxAYXR0LmNvbTwvc3Bhbj48L2E+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDQwODAiPjxi cj4NCiZuYnNwOzwvc3Bhbj4gPGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQpGcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0 Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQogWzwvc3Bhbj48YSBocmVmPSJtYWlsdG86c2lw LW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPm1h aWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5d DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkNoYXJsZXMgU2hlbjxiPjxicj4NClNlbnQ6PC9iPiBNb25k YXksIE9jdG9iZXIgMjIsIDIwMTIgMTI6NDcgUE08Yj48YnI+DQpUbzo8L2I+IDwvc3Bhbj48YSBo cmVmPSJtYWlsdG86c2lwLW92ZXJsb2FkQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5zaXAtb3ZlcmxvYWRAaWV0Zi5vcmc8L3NwYW4+PC9hPjxiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0K Q2M6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBBcmF0YSBLb2lrZTsgSGVubmluZyBTY2h1bHpyaW5u ZTxiPjxicj4NClN1YmplY3Q6PC9iPiBSZTogW3NpcC1vdmVybG9hZF0gSS1EIEFjdGlvbjogZHJh ZnQtaWV0Zi1zb2MtbG9hZC1jb250cm9sLWV2ZW50LXBhY2thZ2UtMDUudHh0PC9zcGFuPg0KPGJy Pg0KJm5ic3A7IDxicj4NCkhpIGFsbCwgPGJyPg0KJm5ic3A7IDxicj4NCkkndmUgc3VibWl0dGVk IGEgbmV3IHZlcnNpb24gb2YgZHJhZnQtaWV0Zi1zb2MtbG9hZC1jb250cm9sLWV2ZW50LXBhY2th Z2UuIDxicj4NCiZuYnNwOyA8YnI+DQpEaWZmIGlzIGF2YWlsYWJsZSBhdDogPGEgaHJlZj0iaHR0 cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1zb2MtbG9hZC1jb250cm9s LWV2ZW50LXBhY2thZ2UtMDUiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtc29jLWxvYWQtY29udHJvbC1ldmVudC1wYWNrYWdlLTA1 PC9hPg0KPGJyPg0KJm5ic3A7IDxicj4NClRoaXMgdmVyc2lvbiBzaG91bGQgaGF2ZSBpbmNvcnBv cmF0ZWQgcmVzcG9uc2VzIHRvIGFsbCBjb21tZW50cyByZWNlaXZlZCBzbyBmYXIgKHBsZWFzZSBs ZXQgbWUga25vdyBpZiBJIG1pc3NlZCBhbnl0aGluZykuIE1haW4gY2hhbmdlcyBpbmNsdWRlIGFk ZGluZzogNi4zLjMgKHRhcmdldC1zaXAtZW50aXR5LCBjdXJyZW50bHkgb3B0aW9uYWwpIDYuNS4y IChleGFtcGxlIG1lc3NhZ2UgZmxvdyksIHJlbW92aW5nIDUuMTIgKHN0YXRlIGFnZW50KSwNCiBh cyB3ZWxsIGFzIGNoYW5nZXMgYW5kIGNsYXJpZmljYXRpb25zIGluIGEgbnVtYmVyIG9mIG90aGVy IHNlY3Rpb25zLCBlLmcuLCA2LjMuMiAoZXhwbGljaXQgbGlzdCBvZiBtZXRob2QgdHlwZXMgc3Vi amVjdGVkIHRvIGNvbnRyb2wpIDYuNCAodXNpbmcgcmVkaXJlY3QgYXMgYWx0ZXJuYXRpdmUgYWN0 aW9uKSwgNS44ICh0ZXJtaW5hdGluZyBwb2xpY2llcyB1cG9uIHRlcm1pbmF0aW9uIG9mIHN1YnNj cmlwdGlvbikgYW5kIDEzLjIgUFNUTiByZWZlcmVuY2VzLg0KPGJyPg0KJm5ic3A7IDxicj4NCkNv bW1lbnRzIGFyZSB3ZWxjb21lICEgPGJyPg0KJm5ic3A7IDxicj4NCkNoYXJsZXMgPGJyPg0KJm5i c3A7IDxicj4NCiZuYnNwOyA8YnI+DQombmJzcDsgPGJyPg0KT24gTW9uLCBPY3QgMjIsIDIwMTIg YXQgMTI6MzIgUE0sICZsdDs8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiZndDsgd3JvdGU6 DQo8YnI+DQo8YnI+DQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUg b24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuPGJyPg0KVGhpcyBkcmFmdCBpcyBh IHdvcmsgaXRlbSBvZiB0aGUgU0lQIE92ZXJsb2FkIENvbnRyb2wgV29ya2luZyBHcm91cCBvZiB0 aGUgSUVURi48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaXRsZSAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogQSBTZXNzaW9uIEluaXRpYXRpb24gUHJv dG9jb2wgKFNJUCkgTG9hZCBDb250cm9sIEV2ZW50IFBhY2thZ2U8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtBdXRob3IocykgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBDaGFybGVzIFNo ZW48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtIZW5uaW5nIFNjaHVsenJp bm5lPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QXJhdGEgS29pa2U8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtGaWxlbmFtZSAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDs6IGRyYWZ0LWlldGYtc29jLWxvYWQtY29udHJvbC1ldmVudC1wYWNrYWdlLTA1LnR4 dDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1BhZ2VzICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgOiAzOTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0Rh dGUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IDIwMTItMTAtMjI8 YnI+DQo8YnI+DQpBYnN0cmFjdDo8YnI+DQombmJzcDsgV2UgZGVmaW5lIGEgbG9hZCBjb250cm9s IGV2ZW50IHBhY2thZ2UgZm9yIHRoZSBTZXNzaW9uIEluaXRpYXRpb248YnI+DQombmJzcDsgUHJv dG9jb2wgKFNJUCkuICZuYnNwO0l0IGFsbG93cyBTSVAgc2VydmVycyB0byBkaXN0cmlidXRlIGxv YWQgZmlsdGVycyB0bzxicj4NCiZuYnNwOyBvdGhlciBTSVAgc2VydmVycyBpbiB0aGUgbmV0d29y ay4gJm5ic3A7VGhlIGxvYWQgZmlsdGVycyBjb250YWluIHJ1bGVzIHRvPGJyPg0KJm5ic3A7IHRo cm90dGxlIGNhbGxzIGJhc2VkIG9uIHRoZWlyIHNvdXJjZSBvciBkZXN0aW5hdGlvbiBkb21haW4s IHRlbGVwaG9uZTxicj4NCiZuYnNwOyBudW1iZXIgcHJlZml4IG9yIGZvciBhIHNwZWNpZmljIHVz ZXIuICZuYnNwO1RoZSBtZWNoYW5pc20gaGVscHMgdG8gcHJldmVudDxicj4NCiZuYnNwOyBzaWdu YWxpbmcgb3ZlcmxvYWQgYW5kIGNvbXBsZW1lbnRzIGZlZWRiYWNrLWJhc2VkIFNJUCBvdmVybG9h ZDxicj4NCiZuYnNwOyBjb250cm9sIGVmZm9ydHMuPGJyPg0KPGJyPg0KPGJyPg0KVGhlIElFVEYg ZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6PHU+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsdWUiPjxicj4NCjwvc3Bhbj48L3U+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zb2MtbG9hZC1jb250cm9sLWV2ZW50LXBhY2thZ2Ui IHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLXNvYy1sb2FkLWNvbnRyb2wtZXZlbnQtcGFja2FnZTwvYT48YnI+DQo8YnI+DQpUaGVyZSdz IGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDo8dT48c3BhbiBzdHlsZT0iY29s b3I6Ymx1ZSI+PGJyPg0KPC9zcGFuPjwvdT48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLXNvYy1sb2FkLWNvbnRyb2wtZXZlbnQtcGFja2FnZS0wNSIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc29jLWxvYWQt Y29udHJvbC1ldmVudC1wYWNrYWdlLTA1PC9hPjxicj4NCjxicj4NCkEgZGlmZiBmcm9tIHRoZSBw cmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDo8dT48c3BhbiBzdHlsZT0iY29sb3I6Ymx1 ZSI+PGJyPg0KPC9zcGFuPjwvdT48YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1pZXRmLXNvYy1sb2FkLWNvbnRyb2wtZXZlbnQtcGFja2FnZS0wNSIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtc29j LWxvYWQtY29udHJvbC1ldmVudC1wYWNrYWdlLTA1PC9hPjxicj4NCjxicj4NCjxicj4NCkludGVy bmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8dT48c3Bh biBzdHlsZT0iY29sb3I6Ymx1ZSI+PGJyPg0KPC9zcGFuPjwvdT48YSBocmVmPSJmdHA6Ly9mdHAu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLyIgdGFyZ2V0PSJfYmxhbmsiPmZ0cDovL2Z0cC5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc2lwLW92ZXJsb2FkIG1haWxpbmcgbGlz dDx1PjxzcGFuIHN0eWxlPSJjb2xvcjpibHVlIj48YnI+DQo8L3NwYW4+PC91PjxhIGhyZWY9Im1h aWx0bzpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zaXAtb3ZlcmxvYWRA aWV0Zi5vcmc8L2E+PHU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPjxicj4NCjwvc3Bhbj48L3U+ PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXAtb3Zlcmxv YWQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NpcC1vdmVybG9hZDwvYT4NCjxicj4NCiZuYnNwOzx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0Kc2lwLW92ZXJsb2FkIG1haWxpbmcgbGlzdDx1Pjxz cGFuIHN0eWxlPSJjb2xvcjpibHVlIj48YnI+DQo8L3NwYW4+PC91Pjwvc3Bhbj48YSBocmVmPSJt YWlsdG86c2lwLW92ZXJsb2FkQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPnNp cC1vdmVybG9hZEBpZXRmLm9yZzwvc3Bhbj48L2E+PHU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUi Pjxicj4NCjwvc3Bhbj48L3U+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zaXAtb3ZlcmxvYWQiIHRhcmdldD0iX2JsYW5rIj48dHQ+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lw LW92ZXJsb2FkPC9zcGFuPjwvdHQ+PC9hPg0KPG86cD48L286cD48L3A+DQo8cD4mbmJzcDsgPG86 cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjx0dD5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PC90dD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxi cj4NCjxicj4NCjx0dD5DZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNv bnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBl dCBuZSBkb2l2ZW50IGRvbmM8L3R0Pjxicj4NCjx0dD5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9p dGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVz c2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjwvdHQ+PGJyPg0KPHR0PmEgbCdl eHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExl cyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24s PC90dD48YnI+DQo8dHQ+RnJhbmNlIFRlbGVjb20gLSBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNw b25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZp ZS4gTWVyY2kuPC90dD48YnI+DQo8YnI+DQo8dHQ+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo bWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24g dGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8L3R0Pjxicj4NCjx0dD50aGV5IHNob3VsZCBu b3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi48 L3R0Pjxicj4NCjx0dD5JZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cy48L3R0Pjxicj4NCjx0dD5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIEZyYW5j ZSBUZWxlY29tIC0gT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBi ZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48L3R0Pjxicj4NCjx0dD5UaGFuayB5 b3UuPC90dD48YnI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPFBSRT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50 IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVl cyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3Bp ZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVy cmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUg YWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMg ZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKRnJhbmNlIFRlbGVjb20gLSBPcmFuZ2Ug ZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwg ZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0 aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0 ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBk ZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUg YWx0ZXJlZCwgRnJhbmNlIFRlbGVjb20gLSBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2Fn ZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5 b3UuCjwvUFJFPjwvYm9keT4NCjwvaHRtbD4NCg== --_000_88CAD1D4E8773F42858B58CAA28272A00E8050PEXCVZYM12corpora_-- From md3135@att.com Wed Jan 2 07:21:40 2013 Return-Path: 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 822CC21F85CC; Wed, 2 Jan 2013 07:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 5ozD34EjiE4i; Wed, 2 Jan 2013 07:21:38 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id CABBE21F84DE; Wed, 2 Jan 2013 07:21:37 -0800 (PST) Received: from unknown [144.160.128.153] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-12) with ESMTP id 18054e05.6cecb940.759635.00-589.2081146.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 02 Jan 2013 15:21:37 +0000 (UTC) X-MXL-Hash: 50e4508145c5f432-b8c100ce6c2997b1ce79f3bbae96714ef9b6bfa9 Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id e6054e05.0.759485.00-344.2080677.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 02 Jan 2013 15:21:24 +0000 (UTC) X-MXL-Hash: 50e45074102be221-ded77bd1df59a55ffe76fe1b9e5f34778d66a4df Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id r02FLGKx002972; Wed, 2 Jan 2013 07:21:17 -0800 Received: from fflint03.pst.cso.att.com (fflint03.pst.cso.att.com [150.234.39.63]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id r02FKvZa002354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jan 2013 07:21:03 -0800 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by fflint03.pst.cso.att.com (RSA Interceptor); Wed, 2 Jan 2013 07:20:45 -0800 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.02.0318.001; Wed, 2 Jan 2013 10:20:45 -0500 From: "DOLLY, MARTIN C" To: "bruno.chatras@orange.com" , Janet P Gunn , Charles Shen Thread-Topic: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt Thread-Index: AQHN6NE2Bzf2fas8rEalJvR/BOX8/Jg2J1+A Date: Wed, 2 Jan 2013 15:20:44 +0000 Message-ID: References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> <5EBD159DE88147488A3B1590E090018403530A9E6275@njfpsrvexg2.research.att.com> <24674_1355758104_50CF3A18_24674_468_1_88CAD1D4E8773F42858B58CAA28272A00E2A2C@PEXCVZYM12.corporate.adroot.infra.ftgroup> <14332_1357121325_50E4072D_14332_348_1_88CAD1D4E8773F42858B58CAA28272A00E8050@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <14332_1357121325_50E4072D_14332_348_1_88CAD1D4E8773F42858B58CAA28272A00E8050@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.88.149] Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E8365601F9B5ADMISOUT7MSGUSR9I_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=2.0 cv=Uu3UwZMB c=1 sm=0 a=xwOvzTHDVLE4u4nGvK72ag==:17 a] X-AnalysisOut: [=iPsD5GzT_yEA:10 a=V18Ae5n6O6cA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=x7kmgyfEn] X-AnalysisOut: [jEA:10 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8 a=-x0Z3lzNAAAA:8 ] X-AnalysisOut: [a=pGLkceISAAAA:8 a=MNNfcbanv7Q7UQRpu10A:9 a=QEXdDO2ut3YA:1] X-AnalysisOut: [0 a=QYbaF5LxmtMA:10 a=lZB815dzVvQA:10 a=oAXR_kdF8uMA:10 a=] X-AnalysisOut: [cMdEYbctpPkA:10 a=MSl-tDqOz04A:10 a=Hz7IrDYlS0cA:10 a=FKZx] X-AnalysisOut: [7hm2Mnsj_KFG:21 a=0FmeR5JK3zsPqGSo:21 a=yMhMjlubAAAA:8 a=S] X-AnalysisOut: [SmOFEACAAAA:8 a=NJkoWjT89nah8ehz-UkA:9 a=gKO2Hq4RSVkA:10 a] X-AnalysisOut: [=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=tXs] X-AnalysisOut: [nliwV7b4A:10 a=A-e_iSKl3IZKKHmy:21 a=fSouWALeV_B21rk_:21 a] X-AnalysisOut: [=dF-Dqqu7UICwTu0J:21] Cc: "sip-overload-bounces@ietf.org" , "sip-overload@ietf.org" , Arata Koike , Henning Schulzrinne Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 15:21:40 -0000 --_000_E42CCDDA6722744CB241677169E8365601F9B5ADMISOUT7MSGUSR9I_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIEJydW5vLCBpbiB0aGF0IGl0IG5lZWRzIHRvIGJlIGEg4oCcTVVTVOKAnS4g V2h5IGhhdmUgbG9jYWwgcG9saWN5LCBpZiBpdCBpcyBub3QgYSBNVVNULg0KDQpGcm9tOiBzaXAt b3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgYnJ1bm8uY2hhdHJhc0BvcmFuZ2UuY29tDQpTZW50OiBXZWRu ZXNkYXksIEphbnVhcnkgMDIsIDIwMTMgNTowOSBBTQ0KVG86IEphbmV0IFAgR3VubjsgQ2hhcmxl cyBTaGVuDQpDYzogc2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc7IHNpcC1vdmVybG9hZEBp ZXRmLm9yZzsgQXJhdGEgS29pa2U7IE5PRUwsIEVSSUMgQzsgSGVubmluZyBTY2h1bHpyaW5uZQ0K U3ViamVjdDogUmU6IFtzaXAtb3ZlcmxvYWRdIExvY2FsIFBvbGljeSBSZTogSS1EIEFjdGlvbjog ZHJhZnQtaWV0Zi1zb2MtbG9hZC1jb250cm9sLWV2ZW50LXBhY2thZ2UtMDUudHh0DQoNCkkgd291 bGQgc2F5IGl0IGlzIHRoZSDCqyBsb2NhbCBwb2xpY3kgwrsgZGVmaW5lZCBieSB0aGUgY2Fycmll ciBidXQgaXQgaGFzIHRvIGNvbXBseSB3aXRoIHRoZSByZWd1bGF0aW9uIGluIGZvcmNlIGluIHRo ZSBjb3VudHJ5IHdoZXJlIHRoZSBjYXJyaWVyIGlzIG9wZXJhdGluZy4gICDigJxTaG91bGTigJ0g Y291bGQgYmUgdW5kZXJzdG9vZCBhcyBwcm92aWRpbmcgcm9vbSBmb3Igbm90IGhvbm9yaW5nIGFu eSBsb2NhbCBwb2xpY3kgZXhjZXB0IG9uZSB0aGF0IGhhcyBiZWVuIGhhcmQtY29kZWQgYnkgdGhl IHZlbmRvciBvZiB0aGUgZXF1aXBtZW50LiAgQW4gdW5kZXNpcmFibGUgc2lkZS1lZmZlY3Qgd291 bGQgYmUgdGhhdCBkaWZmZXJlbnQgU0lQIGVudGl0aWVzIGZyb20gZGlmZmVyZW50IHZlbmRvcnMg Y291bGQgcmVhY3QgZGlmZmVyZW50bHkgd2hpbGUgYmVpbmcgdXNlZCBpbiB0aGUgc2FtZSBuZXR3 b3JrLg0KQkMNCg0KRGUgOiBKYW5ldCBQIEd1bm4gW21haWx0bzpqZ3VubjZAY3NjLmNvbV0NCkVu dm95w6kgOiBsdW5kaSAzMSBkw6ljZW1icmUgMjAxMiAxODoxNw0Kw4AgOiBDaGFybGVzIFNoZW4N CkNjIDogQ0hBVFJBUyBCcnVubyBPTE5DL09MTjsgY2hhcmxlcy5uZXd5b3JrQGdtYWlsLmNvbTxt YWlsdG86Y2hhcmxlcy5uZXd5b3JrQGdtYWlsLmNvbT47IE5PRUwsIEVSSUMgKEVSSUMgQyk7IEhl bm5pbmcgU2NodWx6cmlubmU7IEFyYXRhIEtvaWtlOyBzaXAtb3ZlcmxvYWRAaWV0Zi5vcmc8bWFp bHRvOnNpcC1vdmVybG9hZEBpZXRmLm9yZz47IHNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZz4NCk9iamV0IDogTG9jYWwgUG9s aWN5IFJlOiBbc2lwLW92ZXJsb2FkXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXNvYy1sb2FkLWNv bnRyb2wtZXZlbnQtcGFja2FnZS0wNS50eHQNCg0KDQpJIHdvdWxkICBiZSBoYXBweSB3aXRoICJN VVNUIiwgYnV0IEknZCBsaWtlIHRvIGhlYXIgZm9ybSB0aGUgY2FycmllcnMtIGVzcGVjaWFsbHkg ZnJvbSBLZWl0aCBEcmFnZSwgYXMgaGUgaXMgdGhlIG9uZSB3aG8gaW5pdGlhdGVkIHRoZSBuZXcg d29yZGluZy4NCg0KSXQgbWF5IGJlIGEgcXVlc3Rpb24gb2YgIFdIT1NFIGxvY2FsIHBvbGljeSB3 ZSBhcmUgdGFsa2luZyBhYm91dC4gICBUaGVyZSBpcyB0aGUgImxvY2FsIHBvbGljeSIgYXMgZGVm aW5lZCBieSB0aGUgZ292ZXJubWVudCAod2hpY2ggbWF5IHBvbGl0aWNhbGx5IGNvcnJlY3QgYnV0 IHRlY2huaWNhbGx5IHVuc3RhYmxlKS4gIFRoZXJlIGlzIGFsc28gImxvY2FsIHBvbGljeSIgZGVm aW5lZCBieSB0aGUgImNhcnJpZXIiICh3aGljaCBtYXkgYmUgIHRlY2huaWNhbGx5IHN0YWJsZSwg YnV0IHBvbGl0aWNhbGx5IGluY29ycmVjdCkuDQoNCiJTaG91bGQiIGxlYXZlcyBzb21lIHdpZ2ds ZSByb29tIGFzIHRvIFdISUNIIGxvY2FsIHBvbGljeSAgaXMgYmVpbmcgaG9ub3JlZC4NCg0KSmFu ZXQNCg0KDQoNCkZyb206ICAgICAgICBDaGFybGVzIFNoZW4gPGNoYXJsZXNAY3MuY29sdW1iaWEu ZWR1PG1haWx0bzpjaGFybGVzQGNzLmNvbHVtYmlhLmVkdT4+DQpUbzogICAgICAgIGJydW5vLmNo YXRyYXNAb3JhbmdlLmNvbTxtYWlsdG86YnJ1bm8uY2hhdHJhc0BvcmFuZ2UuY29tPg0KQ2M6ICAg ICAgICBKYW5ldCBQIEd1bm4vVVNBL0NTQ0BDU0MsICJOT0VMLCBFUklDIChFUklDIEMpIiA8ZWNu b2VsQGF0dC5jb208bWFpbHRvOmVjbm9lbEBhdHQuY29tPj4sICJzaXAtb3ZlcmxvYWQtYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc+IiA8c2lwLW92 ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYu b3JnPj4sICJzaXAtb3ZlcmxvYWRAaWV0Zi5vcmc8bWFpbHRvOnNpcC1vdmVybG9hZEBpZXRmLm9y Zz4iIDxzaXAtb3ZlcmxvYWRAaWV0Zi5vcmc8bWFpbHRvOnNpcC1vdmVybG9hZEBpZXRmLm9yZz4+ LCBBcmF0YSBLb2lrZSA8a29pa2UuYXJhdGFAbGFiLm50dC5jby5qcDxtYWlsdG86a29pa2UuYXJh dGFAbGFiLm50dC5jby5qcD4+LCBIZW5uaW5nIFNjaHVsenJpbm5lIDxoZ3NAY3MuY29sdW1iaWEu ZWR1PG1haWx0bzpoZ3NAY3MuY29sdW1iaWEuZWR1Pj4NCkRhdGU6ICAgICAgICAxMi8xOC8yMDEy IDEwOjMyIFBNDQpTdWJqZWN0OiAgICAgICAgUmU6IFtzaXAtb3ZlcmxvYWRdIEktRCBBY3Rpb246 IGRyYWZ0LWlldGYtc29jLWxvYWQtY29udHJvbC1ldmVudC1wYWNrYWdlLTA1LnR4dA0KU2VudCBi eTogICAgICAgIGNoYXJsZXMubmV3eW9ya0BnbWFpbC5jb208bWFpbHRvOmNoYXJsZXMubmV3eW9y a0BnbWFpbC5jb20+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCg0KSGkg QnJ1bm8sIEkgbm90aWNlZCB5b3VyIGNvbW1lbnQsIGNhbiB3ZSByZWFjaCBhIGNvbnNlbnN1cyBv biB0aGlzIGxpc3Qgc28gSSBjYW4gdXBkYXRlIHRoZSBkcmFmdCBhY2NvcmRpbmdseT8NCg0KVGhh bmtzIQ0KDQpDaGFybGVzDQoNCk9uIE1vbiwgRGVjIDE3LCAyMDEyIGF0IDEwOjI4IEFNLCA8YnJ1 bm8uY2hhdHJhc0BvcmFuZ2UuY29tPG1haWx0bzpicnVuby5jaGF0cmFzQG9yYW5nZS5jb20+PiB3 cm90ZToNCkkgYWdyZWUgdGhhdCBib3RoIGRyYWZ0cyBzaG91bGQgdXNlIHRoZSBzYW1lIHRleHQg YnV0IEnigJltIHN0aWxsIG5vdCBzdXJlIHRvIHVuZGVyc3RhbmQgd2h5IHdlIHVzZSDigJxTSE9V TETigJ0gcmF0aGVyIHRoYW4g4oCcTVVTVOKAnT8gIFNldHRpbmcgYSBsb2NhbCBwb2xpY3kgaXMg b3B0aW9uYWwgYnV0IGlmIHRoZXJlIGlzIG9uZSBpdCBzZWVtcyB0byBtZSB0aGF0ICBTSVAgY2xp ZW50cyBNVVNUIGhvbm9yIGl0Lg0KDQoNCg0KDQoNCg0KDQpEZSA6IHNpcC1vdmVybG9hZC1ib3Vu Y2VzQGlldGYub3JnPG1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0 bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2lwLW92ZXJsb2FkLWJvdW5j ZXNAaWV0Zi5vcmc+XSBEZSBsYSBwYXJ0IGRlIENoYXJsZXMgU2hlbg0KRW52b3nDqSA6IHNhbWVk aSAxNSBkw6ljZW1icmUgMjAxMiAxNjowNg0Kw4AgOiBKYW5ldCBQIEd1bm4NCkNjIDogTk9FTCwg RVJJQyAoRVJJQyBDKTsgc2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNpcC1v dmVybG9hZC1ib3VuY2VzQGlldGYub3JnPjsgc2lwLW92ZXJsb2FkQGlldGYub3JnPG1haWx0bzpz aXAtb3ZlcmxvYWRAaWV0Zi5vcmc+OyBBcmF0YSBLb2lrZTsgSGVubmluZyBTY2h1bHpyaW5uZQ0K T2JqZXQgOiBSZTogW3NpcC1vdmVybG9hZF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1zb2MtbG9h ZC1jb250cm9sLWV2ZW50LXBhY2thZ2UtMDUudHh0DQoNCg0KDQpIaSBKYW5ldCwgSSB3aWxsIHJl dmlzZSBhcyBzdWdnZXN0ZWQuIFRoYW5rcyB5b3UgYWdhaW4hDQoNCkNoYXJsZXMNCg0KT24gRnJp LCBEZWMgMTQsIDIwMTIgYXQgMzo1NiBQTSwgSmFuZXQgUCBHdW5uIDxqZ3VubjZAY3NjLmNvbTxt YWlsdG86amd1bm42QGNzYy5jb20+PiB3cm90ZToNCg0KWW91IGNhbiBjb3VudCBteSByZXZpZXcg Zm9yIElFU0cuDQoNCkkgb25seSBoYXZlIGEgY291cGxlIG9mIHRoaW5ncyB0byBhZGQuDQoNCklu IHNlY3Rpb24gNC40LCB5b3UgaGF2ZSB0aGUgdGV4dDoNCuKAnEluIGFkZGl0aW9uLCB3aGF0ZXZl ciB0aGUgYWN0dWFsIHBvbGljeSBpcywgU0lQDQogICBzZXJ2ZXJzIFNIT1VMRCBob25vciB0aGUg bG9jYWwgcG9saWN5IGZvciBwcmlvcml0aXppbmcgU0lQIHJlcXVlc3RzDQogICBzdWNoIGFzIHBv bGljaWVzIGJhc2VkIG9uIHRoZSBjb250ZW50cyBvZiB0aGUgUmVzb3VyY2UtUHJpb3JpdHkNCiAg IEhlYWRlciAoUlBIKSBbUkZDNDQxMl0uICBUaGUgUlBIIGNvbnRlbnRzIG1heSBpbmRpY2F0ZSBo aWdoIHByaW9yaXR5DQogICByZXF1ZXN0cyB0aGF0IHNob3VsZCBiZSBwcmVzZXJ2ZWQgYXMgbXVj aCBhcyBwb3NzaWJsZSwgb3IgbG93DQogICBwcmlvcml0eSByZXF1ZXN0cyB0aGF0IGNvdWxkIGJl IGRyb3BwZWQgZHVyaW5nIG92ZXJsb2FkLiAgT3RoZXINCiAgIGluZGljYXRvcnMsIHN1Y2ggYXMg dGhlIFNPUyBVbmlmb3JtIFJlc291cmNlIE5hbWUgKFVSTikgW1JGQzUwMzFdDQogICBpbmRpY2F0 aW5nIGFuIGVtZXJnZW5jeSByZXF1ZXN0LCBtYXkgYWxzbyBiZSB1c2VkIGZvciBwcmlvcml0aXph dGlvbi7igJ0NCg0KRHVyaW5nIHRoZSBsYXN0IElFVEYgbWVldGluZywgdGhlcmUgd2FzIGFuIGV4 Y2hhbmdlIG9uIHRoZSBsaXN0ICBhYm91dCB0aGlzIHdvcmRpbmcgKGluIG11bHRpcGxlIElEcykg d2l0aCBhcHBhcmVudCBhZ3JlZW1lbnQgKG9uIHRoZSBsaXN0KSB0byB1c2UgIHRoZSBzYW1lIHRl eHQgaW4gYWxsIHRoZSBvdmVybG9hZCBkcmFmdHMNCg0KIiAgIEEgU0lQIGNsaWVudCBTSE9VTEQg aG9ub3IgYW55IGxvY2FsIHBvbGljeSBmb3IgcHJpb3JpdGl6aW5nIFNJUA0KIHJlcXVlc3RzIHN1 Y2ggYXMgcG9saWNpZXMgYmFzZWQgb24gbWVzc2FnZSB0eXBlLCBlLmcuLCBJTlZJVEVzIHZzLg0K ICByZXF1ZXN0cyBhc3NvY2lhdGVkIHdpdGggZXhpc3Rpbmcgc2Vzc2lvbnMuDQoNCiAgQSBTSVAg Y2xpZW50IFNIT1VMRCBob25vciBhbnkgbG9jYWwgcG9saWN5IGZvciBwcmlvcml0aXppbmcgU0lQ DQogIHJlcXVlc3RzIGJhc2VkIG9uIHRoZSBjb250ZW50IG9mIHRoZSBSZXNvdXJjZS0NCiBQcmlv cml0eSBoZWFkZXIgKFJQSCwgUkZDNDQxMiBbUkZDNDQxMl0pLiAgU3BlY2lmaWMgKG5hbWVzcGFj ZS52YWx1ZSkNCiBSUEggY29udGVudHMgbWF5IGluZGljYXRlIGhpZ2ggcHJpb3JpdHkgcmVxdWVz dHMgdGhhdCBzaG91bGQgYmUNCiBwcmVzZXJ2ZWQgYXMgbXVjaCBhcyBwb3NzaWJsZSBkdXJpbmcg b3ZlcmxvYWQuICBUaGUgUlBIIGNvbnRlbnRzIGNhbg0KIGFsc28gaW5kaWNhdGUgYSBsb3ctcHJp b3JpdHkgcmVxdWVzdCB0aGF0IGlzIGVsaWdpYmxlIHRvIGJlIGRyb3BwZWQNCiBkdXJpbmcgdGlt ZXMgb2Ygb3ZlcmxvYWQuDQoNCiBBIFNJUCBjbGllbnQgU0hPVUxEIGhvbm9yIGFueSBsb2NhbCBw b2xpY3kgZm9yIHByaW9yaXRpemluZyBTSVANCiByZXF1ZXN0cyByZWxhdGluZyB0byBlbWVyZ2Vu Y3kgY2FsbHMsIGFzIGlkZW50aWZpZWQgYnkgdGhlIFNPUw0KIFVSTiBbUkZDNTAzMV0gaW5kaWNh dGluZyBhbiBlbWVyZ2VuY3kgcmVxdWVzdC4iDQoNClNvIHdvdWxkIHlvdSBwbGVhc2UgdXNlIHRo aXMgcmV2aXNlZCB3b3JkaW5nLg0KDQpuaXRzDQoNClNlYyA1LjggbGFzdCBzZW50ZW5jZSBvZiBm aXJzdCBwYXJhZ3JhcGgNCuKAnEEgc3Vic2NyaWJlciByZWNlaXZpbmcgdGhlIG5vdGlmaWNhdGlv biBmaXJzdCBpbnN0YWxscw0KICAgdGhlc2UgcnVsZXMgYW5kIHRoZW4gZmlsdGVyIGluY29taW5n IHJlcXVlc3RzIHRvIGVuZm9yY2UgYWN0aW9ucyBvbg0KICAgYXBwcm9wcmlhdGUgcmVxdWVzdHMs IGZvciBleGFtcGxlLCBsaW1pdGluZyB0aGUgc2VuZGluZyByYXRlIG9mIGNhbGwNCiAgIHJlcXVl c3RzIGRlc3RpbmVkIGZvciBhIHNwZWNpZmljIFNJUCBlbnRpdHku4oCdDQrigJxmaWx0ZXLigJ0g c2hvdWxkIGJlIOKAnGZpbHRlcnPigJ0NCg0KUGcgMTgNClRoaXMNCuKAnHRoaXMgc29sdXRpb24g ZG9lcyBub3QgcGVybWl0IHRvIGRlZmluZSBhIGZpbHRlciB0aGF0IGV4Y2x1ZGVzDQogICBhbGwg RS4xNjQgbnVtYmVycyBpbiB0aGF0IGNvdW50cnkgYnV0IHJldGFpbiBhbGwgc2hvcnQgc2Vydmlj ZQ0KICAgbnVtYmVycy7igJ0NClNob3VsZCBiZQ0K4oCcdGhpcyBzb2x1dGlvbiBkb2VzIG5vdCBw ZXJtaXQgdGhlIGRlZmluaXRpb24gb2YgZmlsdGVyIHRoYXQgZXhjbHVkZXMNCiAgIGFsbCBFLjE2 NCBudW1iZXJzIGluIHRoYXQgY291bnRyeSBidXQgcmV0YWluIGFsbCBzaG9ydCBzZXJ2aWNlDQog ICBudW1iZXJzLuKAnQ0KDQpKYW5ldA0KDQpUaGlzIGlzIGEgUFJJVkFURSBtZXNzYWdlLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVsZXRlIHdpdGhvdXQg Y29weWluZyBhbmQga2luZGx5IGFkdmlzZSB1cyBieSBlLW1haWwgb2YgdGhlIG1pc3Rha2UgaW4g ZGVsaXZlcnkuIE5PVEU6IFJlZ2FyZGxlc3Mgb2YgY29udGVudCwgdGhpcyBlLW1haWwgc2hhbGwg bm90IG9wZXJhdGUgdG8gYmluZCBDU0MgdG8gYW55IG9yZGVyIG9yIG90aGVyIGNvbnRyYWN0IHVu bGVzcyBwdXJzdWFudCB0byBleHBsaWNpdCB3cml0dGVuIGFncmVlbWVudCBvciBnb3Zlcm5tZW50 IGluaXRpYXRpdmUgZXhwcmVzc2x5IHBlcm1pdHRpbmcgdGhlIHVzZSBvZiBlLW1haWwgZm9yIHN1 Y2ggcHVycG9zZS4NCg0KDQoNCkZyb206ICAgICAgICAiTk9FTCwgRVJJQyAgKEVSSUMgQykiIDxl Y25vZWxAcmVzZWFyY2guYXR0LmNvbTxtYWlsdG86ZWNub2VsQHJlc2VhcmNoLmF0dC5jb20+Pg0K VG86ICAgICAgICAiJ0NoYXJsZXMgU2hlbiciIDxjaGFybGVzQGNzLmNvbHVtYmlhLmVkdTxtYWls dG86Y2hhcmxlc0Bjcy5jb2x1bWJpYS5lZHU+PiwgInNpcC1vdmVybG9hZEBpZXRmLm9yZzxtYWls dG86c2lwLW92ZXJsb2FkQGlldGYub3JnPiIgPHNpcC1vdmVybG9hZEBpZXRmLm9yZzxtYWlsdG86 c2lwLW92ZXJsb2FkQGlldGYub3JnPj4NCkNjOiAgICAgICAgQXJhdGEgS29pa2UgPGtvaWtlLmFy YXRhQGxhYi5udHQuY28uanA8bWFpbHRvOmtvaWtlLmFyYXRhQGxhYi5udHQuY28uanA+PiwgSGVu bmluZyBTY2h1bHpyaW5uZSA8aGdzQGNzLmNvbHVtYmlhLmVkdTxtYWlsdG86aGdzQGNzLmNvbHVt YmlhLmVkdT4+DQpEYXRlOiAgICAgICAgMTIvMTMvMjAxMiAwMzowMSBQTQ0KDQpTdWJqZWN0OiAg ICAgICAgUmU6IFtzaXAtb3ZlcmxvYWRdIEktRCAgICAgICAgQWN0aW9uOiAgICAgICAgZHJhZnQt aWV0Zi1zb2MtbG9hZC1jb250cm9sLWV2ZW50LXBhY2thZ2UtMDUudHh0DQoNClNlbnQgYnk6ICAg ICAgICBzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2lwLW92ZXJsb2FkLWJv dW5jZXNAaWV0Zi5vcmc+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0K DQpDaGFybGVzLA0KDQpJIHdlbnQgdGhyb3VnaCB5b3VyIGxhdGVzdCB2ZXJzaW9uIGFuZCBoYXZl IG5vIGNvbW1lbnRzIGJleW9uZCB3aGF0IHdhcyBhbHJlYWR5IHBvc3RlZC4NCg0KWW91IGNhbiBo YXZlIG15IHJldmlldyBjb3VudGVkIGZvciB0aGUgSUVTRyByZXZpZXcuDQoNClRoYW5rcywNCg0K RXJpYyBOb2VsDQpBVCZUIExhYnMsIEluYy4NClJldGhpbmsgUG9zc2libGUNCg0KTmV0d29yayBE ZXNpZ24gYW5kIFBlcmZvcm1hbmNlIEFuYWx5c2lzDQoyMDAgU291dGggTGF1cmVsIEF2ZW51ZSwg RDUtM0QxOQ0KTWlkZGxldG93biwgTkogMDc3NDgNClA6IDczMi40MjAuNDE3NDx0ZWw6NzMyLjQy MC40MTc0Pg0KZWNub2VsQGF0dC5jb208bWFpbHRvOmpzbWl0aEBhdHQuY29tPg0KDQpGcm9tOiBz aXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2lwLW92ZXJsb2FkLWJvdW5jZXNA aWV0Zi5vcmc+IFttYWlsdG86c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBDaGFybGVzIFNoZW4NClNlbnQ6IE1vbmRheSwgT2N0b2JlciAyMiwgMjAxMiAxMjo0NyBQ TQ0KVG86IHNpcC1vdmVybG9hZEBpZXRmLm9yZzxtYWlsdG86c2lwLW92ZXJsb2FkQGlldGYub3Jn Pg0KQ2M6IEFyYXRhIEtvaWtlOyBIZW5uaW5nIFNjaHVsenJpbm5lDQpTdWJqZWN0OiBSZTogW3Np cC1vdmVybG9hZF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1zb2MtbG9hZC1jb250cm9sLWV2ZW50 LXBhY2thZ2UtMDUudHh0DQoNCkhpIGFsbCwNCg0KSSd2ZSBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lv biBvZiBkcmFmdC1pZXRmLXNvYy1sb2FkLWNvbnRyb2wtZXZlbnQtcGFja2FnZS4NCg0KRGlmZiBp cyBhdmFpbGFibGUgYXQ6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWll dGYtc29jLWxvYWQtY29udHJvbC1ldmVudC1wYWNrYWdlLTA1DQoNClRoaXMgdmVyc2lvbiBzaG91 bGQgaGF2ZSBpbmNvcnBvcmF0ZWQgcmVzcG9uc2VzIHRvIGFsbCBjb21tZW50cyByZWNlaXZlZCBz byBmYXIgKHBsZWFzZSBsZXQgbWUga25vdyBpZiBJIG1pc3NlZCBhbnl0aGluZykuIE1haW4gY2hh bmdlcyBpbmNsdWRlIGFkZGluZzogNi4zLjMgKHRhcmdldC1zaXAtZW50aXR5LCBjdXJyZW50bHkg b3B0aW9uYWwpIDYuNS4yIChleGFtcGxlIG1lc3NhZ2UgZmxvdyksIHJlbW92aW5nIDUuMTIgKHN0 YXRlIGFnZW50KSwgYXMgd2VsbCBhcyBjaGFuZ2VzIGFuZCBjbGFyaWZpY2F0aW9ucyBpbiBhIG51 bWJlciBvZiBvdGhlciBzZWN0aW9ucywgZS5nLiwgNi4zLjIgKGV4cGxpY2l0IGxpc3Qgb2YgbWV0 aG9kIHR5cGVzIHN1YmplY3RlZCB0byBjb250cm9sKSA2LjQgKHVzaW5nIHJlZGlyZWN0IGFzIGFs dGVybmF0aXZlIGFjdGlvbiksIDUuOCAodGVybWluYXRpbmcgcG9saWNpZXMgdXBvbiB0ZXJtaW5h dGlvbiBvZiBzdWJzY3JpcHRpb24pIGFuZCAxMy4yIFBTVE4gcmVmZXJlbmNlcy4NCg0KQ29tbWVu dHMgYXJlIHdlbGNvbWUgIQ0KDQpDaGFybGVzDQoNCg0KDQpPbiBNb24sIE9jdCAyMiwgMjAxMiBh dCAxMjozMiBQTSwgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnPj4gd3JvdGU6DQoNCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJs ZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NClRoaXMgZHJh ZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFNJUCBPdmVybG9hZCBDb250cm9sIFdvcmtpbmcgR3Jv dXAgb2YgdGhlIElFVEYuDQoNCiAgICAgICBUaXRsZSAgICAgICAgICAgOiBBIFNlc3Npb24gSW5p dGlhdGlvbiBQcm90b2NvbCAoU0lQKSBMb2FkIENvbnRyb2wgRXZlbnQgUGFja2FnZQ0KICAgICAg IEF1dGhvcihzKSAgICAgICA6IENoYXJsZXMgU2hlbg0KICAgICAgICAgICAgICAgICAgICAgICAg IEhlbm5pbmcgU2NodWx6cmlubmUNCiAgICAgICAgICAgICAgICAgICAgICAgICBBcmF0YSBLb2lr ZQ0KICAgICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtc29jLWxvYWQtY29udHJvbC1l dmVudC1wYWNrYWdlLTA1LnR4dA0KICAgICAgIFBhZ2VzICAgICAgICAgICA6IDM5DQogICAgICAg RGF0ZSAgICAgICAgICAgIDogMjAxMi0xMC0yMg0KDQpBYnN0cmFjdDoNCiAgV2UgZGVmaW5lIGEg bG9hZCBjb250cm9sIGV2ZW50IHBhY2thZ2UgZm9yIHRoZSBTZXNzaW9uIEluaXRpYXRpb24NCiAg UHJvdG9jb2wgKFNJUCkuICBJdCBhbGxvd3MgU0lQIHNlcnZlcnMgdG8gZGlzdHJpYnV0ZSBsb2Fk IGZpbHRlcnMgdG8NCiAgb3RoZXIgU0lQIHNlcnZlcnMgaW4gdGhlIG5ldHdvcmsuICBUaGUgbG9h ZCBmaWx0ZXJzIGNvbnRhaW4gcnVsZXMgdG8NCiAgdGhyb3R0bGUgY2FsbHMgYmFzZWQgb24gdGhl aXIgc291cmNlIG9yIGRlc3RpbmF0aW9uIGRvbWFpbiwgdGVsZXBob25lDQogIG51bWJlciBwcmVm aXggb3IgZm9yIGEgc3BlY2lmaWMgdXNlci4gIFRoZSBtZWNoYW5pc20gaGVscHMgdG8gcHJldmVu dA0KICBzaWduYWxpbmcgb3ZlcmxvYWQgYW5kIGNvbXBsZW1lbnRzIGZlZWRiYWNrLWJhc2VkIFNJ UCBvdmVybG9hZA0KICBjb250cm9sIGVmZm9ydHMuDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIg c3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLXNvYy1sb2FkLWNvbnRyb2wtZXZlbnQtcGFja2FnZQ0KDQpUaGVy ZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCmh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc29jLWxvYWQtY29udHJvbC1ldmVudC1wYWNrYWdlLTA1 DQoNCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0 dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtc29jLWxvYWQtY29udHJv bC1ldmVudC1wYWNrYWdlLTA1DQoNCg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJs ZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNp cC1vdmVybG9hZCBtYWlsaW5nIGxpc3QNCnNpcC1vdmVybG9hZEBpZXRmLm9yZzxtYWlsdG86c2lw LW92ZXJsb2FkQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zaXAtb3ZlcmxvYWQNCiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0Kc2lwLW92ZXJsb2FkIG1haWxpbmcgbGlzdA0Kc2lwLW92ZXJsb2FkQGlldGYub3Jn PG1haWx0bzpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NpcC1vdmVybG9hZA0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpDZSBtZXNzYWdlIGV0 IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29u ZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCnBhcyBldHJl IGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3Vz IGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQph IGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVz LiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0 aW9uLA0KRnJhbmNlIFRlbGVjb20gLSBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0 ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2ku DQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBs YXc7DQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhv dXQgYXV0aG9yaXNhdGlvbi4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQg aXRzIGF0dGFjaG1lbnRzLg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBGcmFuY2UgVGVsZWNv bSAtIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2Rp ZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KDQoN CkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGlu Zm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQg ZG9uYw0KDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9y aXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxl eiBsZSBzaWduYWxlcg0KDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUg bGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNj ZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KDQpGcmFuY2UgVGVsZWNvbSAtIE9yYW5nZSBkZWNsaW5l IHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1l IG91IGZhbHNpZmllLiBNZXJjaS4NCg0KDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRo YXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQoNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmli dXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KDQpJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg YW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCg0KQXMgZW1haWxz IG1heSBiZSBhbHRlcmVkLCBGcmFuY2UgVGVsZWNvbSAtIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZv ciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQu DQoNClRoYW5rIHlvdS4NCg== --_000_E42CCDDA6722744CB241677169E8365601F9B5ADMISOUT7MSGUSR9I_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9z ZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29u c29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KdHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRl LCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRl eHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxs b29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLlRleHRl ZGVidWxsZXMsIGxpLlRleHRlZGVidWxsZXMsIGRpdi5UZXh0ZWRlYnVsbGVzDQoJe21zby1zdHls ZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMiOw0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxs ZXMgQ2FyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bh bi5UZXh0ZWRlYnVsbGVzQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMgQ2Fy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1 bGxlcyI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxT dHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglm b250LWZhbWlseToiQ29uc29sYXMiLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjYNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB3aXRoIEJydW5vLCBpbiB0aGF0IGl0IG5l ZWRzIHRvIGJlIGEg4oCcTVVTVOKAnS4gV2h5IGhhdmUgbG9jYWwgcG9saWN5LCBpZiBpdCBpcyBu b3QgYSBNVVNULjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPmJydW5vLmNoYXRyYXNAb3JhbmdlLmNvbTxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNk YXksIEphbnVhcnkgMDIsIDIwMTMgNTowOSBBTTxicj4NCjxiPlRvOjwvYj4gSmFuZXQgUCBHdW5u OyBDaGFybGVzIFNoZW48YnI+DQo8Yj5DYzo8L2I+IHNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYu b3JnOyBzaXAtb3ZlcmxvYWRAaWV0Zi5vcmc7IEFyYXRhIEtvaWtlOyBOT0VMLCBFUklDIEM7IEhl bm5pbmcgU2NodWx6cmlubmU8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzaXAtb3ZlcmxvYWRd IExvY2FsIFBvbGljeSBSZTogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1zb2MtbG9hZC1jb250cm9s LWV2ZW50LXBhY2thZ2UtMDUudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkg d291bGQgc2F5IGl0IGlzIHRoZSDCqyZuYnNwO2xvY2FsIHBvbGljeSZuYnNwO8K7IGRlZmluZWQg YnkgdGhlIGNhcnJpZXIgYnV0IGl0IGhhcyB0byBjb21wbHkgd2l0aCB0aGUgcmVndWxhdGlvbiBp biBmb3JjZSBpbiB0aGUgY291bnRyeSB3aGVyZSB0aGUgY2FycmllciBpcyBvcGVyYXRpbmcuDQog Jm5ic3A7Jm5ic3A74oCcU2hvdWxk4oCdIGNvdWxkIGJlIHVuZGVyc3Rvb2QgYXMgcHJvdmlkaW5n IHJvb20gZm9yIG5vdCBob25vcmluZyBhbnkgbG9jYWwgcG9saWN5IGV4Y2VwdCBvbmUgdGhhdCBo YXMgYmVlbiBoYXJkLWNvZGVkIGJ5IHRoZSB2ZW5kb3Igb2YgdGhlIGVxdWlwbWVudC4gJm5ic3A7 QW4gdW5kZXNpcmFibGUgc2lkZS1lZmZlY3Qgd291bGQgYmUgdGhhdCBkaWZmZXJlbnQgU0lQIGVu dGl0aWVzIGZyb20gZGlmZmVyZW50IHZlbmRvcnMgY291bGQgcmVhY3QgZGlmZmVyZW50bHkNCiB3 aGlsZSBiZWluZyB1c2VkIGluIHRoZSBzYW1lIG5ldHdvcmsuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkJDPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRlIi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkZS IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEphbmV0IFAgR3VubiBbPGEgaHJlZj0ibWFpbHRvOmpn dW5uNkBjc2MuY29tIj5tYWlsdG86amd1bm42QGNzYy5jb208L2E+XQ0KPGJyPg0KPGI+RW52b3nD qSZuYnNwOzo8L2I+IGx1bmRpIDMxIGTDqWNlbWJyZSAyMDEyIDE4OjE3PGJyPg0KPGI+w4AmbmJz cDs6PC9iPiBDaGFybGVzIFNoZW48YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IENIQVRSQVMgQnJ1bm8g T0xOQy9PTE47IDxhIGhyZWY9Im1haWx0bzpjaGFybGVzLm5ld3lvcmtAZ21haWwuY29tIj5jaGFy bGVzLm5ld3lvcmtAZ21haWwuY29tPC9hPjsgTk9FTCwgRVJJQyAoRVJJQyBDKTsgSGVubmluZyBT Y2h1bHpyaW5uZTsgQXJhdGEgS29pa2U7DQo8YSBocmVmPSJtYWlsdG86c2lwLW92ZXJsb2FkQGll dGYub3JnIj5zaXAtb3ZlcmxvYWRAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86c2lwLW92 ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmciPg0Kc2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+PGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBMb2NhbCBQb2xpY3kgUmU6IFtzaXAtb3Zlcmxv YWRdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtc29jLWxvYWQtY29udHJvbC1ldmVudC1wYWNrYWdl LTA1LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi Pjxicj4NCkkgd291bGQgJm5ic3A7YmUgaGFwcHkgd2l0aCAmcXVvdDtNVVNUJnF1b3Q7LCBidXQg SSdkIGxpa2UgdG8gaGVhciBmb3JtIHRoZSBjYXJyaWVycy0gZXNwZWNpYWxseSBmcm9tIEtlaXRo IERyYWdlLCBhcyBoZSBpcyB0aGUgb25lIHdobyBpbml0aWF0ZWQgdGhlIG5ldyB3b3JkaW5nLjwv c3Bhbj48c3BhbiBsYW5nPSJGUiI+DQo8YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRlIi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkl0IG1heSBiZSBhIHF1ZXN0aW9uIG9mICZuYnNwO1dIT1NF IGxvY2FsIHBvbGljeSB3ZSBhcmUgdGFsa2luZyBhYm91dC4gJm5ic3A7IFRoZXJlIGlzIHRoZSAm cXVvdDtsb2NhbCBwb2xpY3kmcXVvdDsgYXMgZGVmaW5lZCBieSB0aGUgZ292ZXJubWVudCAod2hp Y2ggbWF5IHBvbGl0aWNhbGx5IGNvcnJlY3QgYnV0IHRlY2huaWNhbGx5IHVuc3RhYmxlKS4NCiAm bmJzcDtUaGVyZSBpcyBhbHNvICZxdW90O2xvY2FsIHBvbGljeSZxdW90OyBkZWZpbmVkIGJ5IHRo ZSAmcXVvdDtjYXJyaWVyJnF1b3Q7ICh3aGljaCBtYXkgYmUgJm5ic3A7dGVjaG5pY2FsbHkgc3Rh YmxlLCBidXQgcG9saXRpY2FsbHkgaW5jb3JyZWN0KS48L3NwYW4+PHNwYW4gbGFuZz0iRlIiPg0K PGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4m cXVvdDtTaG91bGQmcXVvdDsgbGVhdmVzIHNvbWUgd2lnZ2xlIHJvb20gYXMgdG8gV0hJQ0ggbG9j YWwgcG9saWN5ICZuYnNwO2lzIGJlaW5nIGhvbm9yZWQuPC9zcGFuPjxzcGFuIGxhbmc9IkZSIj4N Cjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ SmFuZXQ8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPC9z cGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzVGNUY1RiI+RnJv bTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHls ZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkNoYXJsZXMgU2hlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNoYXJsZXNA Y3MuY29sdW1iaWEuZWR1Ij5jaGFybGVzQGNzLmNvbHVtYmlhLmVkdTwvYT4mZ3Q7PC9zcGFuPjxz cGFuIGxhbmc9IkZSIj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt c2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiM1RjVGNUYiPlRvOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0ibWFpbHRvOmJy dW5vLmNoYXRyYXNAb3JhbmdlLmNvbSI+YnJ1bm8uY2hhdHJhc0BvcmFuZ2UuY29tPC9hPjwvc3Bh bj48c3BhbiBsYW5nPSJGUiI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm b250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojNUY1RjVGIj5DYzogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkphbmV0IFAgR3Vubi9V U0EvQ1NDQENTQywgJnF1b3Q7Tk9FTCwgRVJJQyAoRVJJQyBDKSZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmVjbm9lbEBhdHQuY29tIj5lY25vZWxAYXR0LmNvbTwvYT4mZ3Q7LA0KICZxdW90Ozxh IGhyZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZyI+c2lwLW92ZXJsb2Fk LWJvdW5jZXNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2lwLW92ZXJs b2FkLWJvdW5jZXNAaWV0Zi5vcmciPnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPC9hPiZn dDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmciPnNpcC1vdmVy bG9hZEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWRA aWV0Zi5vcmciPnNpcC1vdmVybG9hZEBpZXRmLm9yZzwvYT4mZ3Q7LA0KIEFyYXRhIEtvaWtlICZs dDs8YSBocmVmPSJtYWlsdG86a29pa2UuYXJhdGFAbGFiLm50dC5jby5qcCI+a29pa2UuYXJhdGFA bGFiLm50dC5jby5qcDwvYT4mZ3Q7LCBIZW5uaW5nIFNjaHVsenJpbm5lICZsdDs8YSBocmVmPSJt YWlsdG86aGdzQGNzLmNvbHVtYmlhLmVkdSI+aGdzQGNzLmNvbHVtYmlhLmVkdTwvYT4mZ3Q7PC9z cGFuPjxzcGFuIGxhbmc9IkZSIj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9 ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiM1RjVGNUYiPkRhdGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4xMi8xOC8yMDEy IDEwOjMyIFBNPC9zcGFuPjxzcGFuIGxhbmc9IkZSIj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5n PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1RjVGNUYiPlN1YmplY3Q6ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6 ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5SZTogW3NpcC1vdmVybG9hZF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1zb2MtbG9hZC1j b250cm9sLWV2ZW50LXBhY2thZ2UtMDUudHh0PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj4NCjxicj4N Cjwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1RjVGNUYi PlNlbnQgYnk6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJG UiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJtYWlsdG86Y2hhcmxlcy5uZXd5b3JrQGdt YWlsLmNvbSI+Y2hhcmxlcy5uZXd5b3JrQGdtYWlsLmNvbTwvYT48L3NwYW4+PHNwYW4gbGFuZz0i RlIiPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGln bj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIGxhbmc9IkZSIj4NCjxo ciBzaXplPSIyIiB3aWR0aD0iMTAwJSIgbm9zaGFkZT0iIiBzdHlsZT0iY29sb3I6I0EwQTBBMCIg YWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJGUiI+PGJyPg0KPGJyPg0KPGJyPg0KSGkgQnJ1bm8sIEkgbm90aWNlZCB5b3VyIGNv bW1lbnQsIGNhbiB3ZSByZWFjaCBhIGNvbnNlbnN1cyBvbiB0aGlzIGxpc3Qgc28gSSBjYW4gdXBk YXRlIHRoZSBkcmFmdCBhY2NvcmRpbmdseT8mbmJzcDsNCjxicj4NCjxicj4NClRoYW5rcyEgPGJy Pg0KPGJyPg0KQ2hhcmxlczxicj4NCjxicj4NCk9uIE1vbiwgRGVjIDE3LCAyMDEyIGF0IDEwOjI4 IEFNLCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJydW5vLmNoYXRyYXNAb3JhbmdlLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmJydW5vLmNoYXRyYXNAb3JhbmdlLmNvbTwvYT4mZ3Q7IHdyb3RlOg0KPGJyPg0K PC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwNDA4 MCI+SSBhZ3JlZSB0aGF0IGJvdGggZHJhZnRzIHNob3VsZCB1c2UgdGhlIHNhbWUgdGV4dCBidXQg SeKAmW0gc3RpbGwgbm90IHN1cmUgdG8gdW5kZXJzdGFuZCB3aHkgd2UgdXNlIOKAnFNIT1VMROKA nSByYXRoZXIgdGhhbiDigJxNVVNU4oCdPyAmbmJzcDtTZXR0aW5nIGEgbG9jYWwgcG9saWN5IGlz IG9wdGlvbmFsDQogYnV0IGlmIHRoZXJlIGlzIG9uZSBpdCBzZWVtcyB0byBtZSB0aGF0ICZuYnNw O1NJUCBjbGllbnRzIE1VU1QgaG9ub3IgaXQuPC9zcGFuPjxzcGFuIGxhbmc9IkZSIj4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzAwNDA4MCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzAwNDA4MCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzAwNDA4MCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwPjxiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUm bmJzcDs6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0K PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48YSBocmVmPSJtYWlsdG86c2lwLW92ZXJsb2FkLWJvdW5j ZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5n PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KIFttYWlsdG86PC9zcGFuPjxzcGFuIGxhbmc9 IkZSIj48YSBocmVmPSJtYWlsdG86c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+c2lwLW92ZXJsb2FkLWJvdW5j ZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPl0NCjxiPkRlIGxhIHBhcnQgZGU8L2I+IENoYXJsZXMgU2hlbjxiPjxicj4NCkVu dm95w6kmbmJzcDs6PC9iPiBzYW1lZGkgMTUgZMOpY2VtYnJlIDIwMTIgMTY6MDY8Yj48YnI+DQrD gCZuYnNwOzo8L2I+IEphbmV0IFAgR3VubjxiPjxicj4NCkNjJm5ic3A7OjwvYj4gTk9FTCwgRVJJ QyAoRVJJQyBDKTsgPC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48YSBocmVmPSJtYWlsdG86c2lwLW92 ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bh bj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjsNCjwvc3Bhbj48c3BhbiBs YW5nPSJGUiI+PGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5zaXAtb3ZlcmxvYWRAaWV0Zi5vcmc8 L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjsN CiBBcmF0YSBLb2lrZTsgSGVubmluZyBTY2h1bHpyaW5uZTxiPjxicj4NCk9iamV0Jm5ic3A7Ojwv Yj4gUmU6IFtzaXAtb3ZlcmxvYWRdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtc29jLWxvYWQtY29u dHJvbC1ldmVudC1wYWNrYWdlLTA1LnR4dDwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7IDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkZSIj5IaSBKYW5ldCwgSSB3aWxsIHJldmlzZSBhcyBz dWdnZXN0ZWQuIFRoYW5rcyB5b3UgYWdhaW4hPGJyPg0KPGJyPg0KQ2hhcmxlcyA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJGUiI+T24gRnJpLCBEZWMgMTQsIDIwMTIgYXQg Mzo1NiBQTSwgSmFuZXQgUCBHdW5uICZsdDs8YSBocmVmPSJtYWlsdG86amd1bm42QGNzYy5jb20i IHRhcmdldD0iX2JsYW5rIj5qZ3VubjZAY3NjLmNvbTwvYT4mZ3Q7IHdyb3RlOg0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Zb3UgY2FuIGNvdW50IG15IHJl dmlldyBmb3IgSUVTRy48L3NwYW4+PHNwYW4gbGFuZz0iRlIiPg0KPGJyPg0KPC9zcGFuPjxzcGFu IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PGJyPg0KSSBvbmx5IGhhdmUgYSBjb3VwbGUgb2YgdGhpbmdzIHRvIGFk ZC48L3NwYW4+PHNwYW4gbGFuZz0iRlIiPiA8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij48YnI+DQpJbiBzZWN0aW9uIDQuNCwgeW91IGhhdmUgdGhlIHRleHQ6PC9zcGFuPjxzcGFuIGxh bmc9IkZSIj4gPC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0K4oCcSW4gYWRkaXRpb24s IHdoYXRldmVyIHRoZSBhY3R1YWwgcG9saWN5IGlzLCBTSVA8L3NwYW4+PHNwYW4gbGFuZz0iRlIi PiA8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQombmJzcDsgJm5ic3A7c2VydmVycyBT SE9VTEQgaG9ub3IgdGhlIGxvY2FsIHBvbGljeSBmb3IgcHJpb3JpdGl6aW5nIFNJUCByZXF1ZXN0 czwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+ DQombmJzcDsgJm5ic3A7c3VjaCBhcyBwb2xpY2llcyBiYXNlZCBvbiB0aGUgY29udGVudHMgb2Yg dGhlIFJlc291cmNlLVByaW9yaXR5PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj4NCjwvc3Bhbj48c3Bh biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxicj4NCiZuYnNwOyAmbmJzcDtIZWFkZXIgKFJQSCkgW1JGQzQ0MTJd LiAmbmJzcDtUaGUgUlBIIGNvbnRlbnRzIG1heSBpbmRpY2F0ZSBoaWdoIHByaW9yaXR5PC9zcGFu PjxzcGFuIGxhbmc9IkZSIj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCiZuYnNw OyAmbmJzcDtyZXF1ZXN0cyB0aGF0IHNob3VsZCBiZSBwcmVzZXJ2ZWQgYXMgbXVjaCBhcyBwb3Nz aWJsZSwgb3IgbG93PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJG UiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxicj4NCiZuYnNwOyAmbmJzcDtwcmlvcml0eSByZXF1ZXN0cyB0aGF0IGNvdWxkIGJl IGRyb3BwZWQgZHVyaW5nIG92ZXJsb2FkLiAmbmJzcDtPdGhlcjwvc3Bhbj48c3BhbiBsYW5nPSJG UiI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQombmJzcDsgJm5ic3A7aW5kaWNh dG9ycywgc3VjaCBhcyB0aGUgU09TIFVuaWZvcm0gUmVzb3VyY2UgTmFtZSAoVVJOKSBbUkZDNTAz MV08L3NwYW4+PHNwYW4gbGFuZz0iRlIiPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJy Pg0KJm5ic3A7ICZuYnNwO2luZGljYXRpbmcgYW4gZW1lcmdlbmN5IHJlcXVlc3QsIG1heSBhbHNv IGJlIHVzZWQgZm9yIHByaW9yaXRpemF0aW9uLuKAnSA8L3NwYW4+DQo8c3BhbiBsYW5nPSJGUiI+ PGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KRHVyaW5nIHRoZSBsYXN0IElF VEYgbWVldGluZywgdGhlcmUgd2FzIGFuIGV4Y2hhbmdlIG9uIHRoZSBsaXN0ICZuYnNwO2Fib3V0 IHRoaXMgd29yZGluZyAoaW4gbXVsdGlwbGUgSURzKSB3aXRoIGFwcGFyZW50IGFncmVlbWVudCAo b24gdGhlIGxpc3QpIHRvIHVzZSAmbmJzcDt0aGUgc2FtZSB0ZXh0IGluIGFsbCB0aGUgb3Zlcmxv YWQgZHJhZnRzPC9zcGFuPjxzcGFuIGxhbmc9IkZSIj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5n PSJGUiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQom cXVvdDsgJm5ic3A7IEEgU0lQIGNsaWVudCBTSE9VTEQgaG9ub3IgYW55IGxvY2FsIHBvbGljeSBm b3IgcHJpb3JpdGl6aW5nIFNJUDxicj4NCiZuYnNwO3JlcXVlc3RzIHN1Y2ggYXMgcG9saWNpZXMg YmFzZWQgPGk+b24gbWVzc2FnZSB0eXBlLCBlLmcuLCBJTlZJVEVzIHZzLjwvaT48L3NwYW4+PHNw YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPg0KPC9zcGFuPjxpPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCiZuYnNwOyByZXF1ZXN0cyBh c3NvY2lhdGVkIHdpdGggZXhpc3Rpbmcgc2Vzc2lvbnMuPC9zcGFuPjwvaT48c3BhbiBsYW5nPSJG UiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KJm5ic3A7IDwvc3Bhbj48c3BhbiBsYW5nPSJGUiIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCiZuYnNwOyA8aT5BIFNJUCBjbGllbnQgU0hPVUxE IGhvbm9yIGFueSBsb2NhbCBwb2xpY3kgZm9yIHByaW9yaXRpemluZyBTSVAgPGJyPg0KJm5ic3A7 IHJlcXVlc3RzIGJhc2VkPC9pPiBvbiB0aGUgY29udGVudCBvZiB0aGUgUmVzb3VyY2UtPGJyPg0K Jm5ic3A7UHJpb3JpdHkgaGVhZGVyIChSUEgsIFJGQzQ0MTIgW1JGQzQ0MTJdKS4gJm5ic3A7U3Bl Y2lmaWMgKG5hbWVzcGFjZS52YWx1ZSk8YnI+DQombmJzcDtSUEggY29udGVudHMgbWF5IGluZGlj YXRlIGhpZ2ggcHJpb3JpdHkgcmVxdWVzdHMgdGhhdCBzaG91bGQgYmU8YnI+DQombmJzcDtwcmVz ZXJ2ZWQgYXMgbXVjaCBhcyBwb3NzaWJsZSBkdXJpbmcgb3ZlcmxvYWQuICZuYnNwO1RoZSBSUEgg Y29udGVudHMgY2FuPGJyPg0KJm5ic3A7YWxzbyBpbmRpY2F0ZSBhIGxvdy1wcmlvcml0eSByZXF1 ZXN0IHRoYXQgaXMgZWxpZ2libGUgdG8gYmUgZHJvcHBlZDxicj4NCiZuYnNwO2R1cmluZyB0aW1l cyBvZiBvdmVybG9hZC4gJm5ic3A7PGJyPg0KPGJyPg0KJm5ic3A7QSBTSVAgY2xpZW50IFNIT1VM RCBob25vciBhbnkgbG9jYWwgcG9saWN5IGZvciBwcmlvcml0aXppbmcgU0lQIDxicj4NCiZuYnNw O3JlcXVlc3RzIHJlbGF0aW5nIHRvIGVtZXJnZW5jeSBjYWxscywgYXMgaWRlbnRpZmllZCBieSB0 aGUgU09TIDxicj4NCiZuYnNwO1VSTiBbUkZDNTAzMV0gaW5kaWNhdGluZyBhbiBlbWVyZ2VuY3kg cmVxdWVzdC4mcXVvdDs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPiA8YnI+DQo8L3NwYW4+PHNwYW4g bGFuZz0iRlIiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJy Pg0KU28gd291bGQgeW91IHBsZWFzZSB1c2UgdGhpcyByZXZpc2VkIHdvcmRpbmcuPC9zcGFuPjxz cGFuIGxhbmc9IkZSIj4gPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCm5pdHM8L3NwYW4+PHNwYW4gbGFu Zz0iRlIiPiA8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KU2VjIDUuOCBsYXN0IHNlbnRlbmNlIG9mIGZp cnN0IHBhcmFncmFwaDwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+IDwvc3Bhbj48c3BhbiBsYW5nPSJG UiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQrigJxB IHN1YnNjcmliZXIgcmVjZWl2aW5nIHRoZSBub3RpZmljYXRpb24gZmlyc3QgaW5zdGFsbHM8L3Nw YW4+PHNwYW4gbGFuZz0iRlIiPiA8L3NwYW4+DQo8c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQombmJzcDsgJm5ic3A7dGhlc2Ug cnVsZXMgYW5kIHRoZW4gZmlsdGVyIGluY29taW5nIHJlcXVlc3RzIHRvIGVuZm9yY2UgYWN0aW9u cyBvbjwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KJm5ic3A7ICZuYnNw O2FwcHJvcHJpYXRlIHJlcXVlc3RzLCBmb3IgZXhhbXBsZSwgbGltaXRpbmcgdGhlIHNlbmRpbmcg cmF0ZSBvZiBjYWxsPC9zcGFuPjxzcGFuIGxhbmc9IkZSIj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJG UiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQombmJz cDsgJm5ic3A7cmVxdWVzdHMgZGVzdGluZWQgZm9yIGEgc3BlY2lmaWMgU0lQIGVudGl0eS7igJ08 L3NwYW4+PHNwYW4gbGFuZz0iRlIiPiA8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0K4oCcZmlsdGVy4oCdIHNob3Vs ZCBiZSDigJxmaWx0ZXJz4oCdPC9zcGFuPjxzcGFuIGxhbmc9IkZSIj4gPGJyPg0KPC9zcGFuPjxz cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi Pjxicj4NClBnIDE4PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj4gPC9zcGFuPjxzcGFuIGxhbmc9IkZS IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NClRoaXM8 L3NwYW4+PHNwYW4gbGFuZz0iRlIiPiA8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0K4oCcdGhpcyBzb2x1dGlvbiBk b2VzIG5vdCBwZXJtaXQgdG8gZGVmaW5lIGEgZmlsdGVyIHRoYXQgZXhjbHVkZXM8L3NwYW4+PHNw YW4gbGFuZz0iRlIiPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCiZuYnNwOyAmbmJzcDthbGwgRS4xNjQgbnVt YmVycyBpbiB0aGF0IGNvdW50cnkgYnV0IHJldGFpbiBhbGwgc2hvcnQgc2VydmljZTwvc3Bhbj48 c3BhbiBsYW5nPSJGUiI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KJm5ic3A7ICZuYnNwO251bWJlcnMu4oCd PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj4gPC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NClNob3VsZCBiZTwvc3Bhbj48 c3BhbiBsYW5nPSJGUiI+IDwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQrigJx0aGlzIHNvbHV0aW9uIGRvZXMgbm90 IHBlcm1pdCB0aGUgZGVmaW5pdGlvbiBvZiBmaWx0ZXIgdGhhdCBleGNsdWRlczwvc3Bhbj48c3Bh biBsYW5nPSJGUiI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KJm5ic3A7ICZuYnNwO2FsbCBFLjE2NCBudW1i ZXJzIGluIHRoYXQgY291bnRyeSBidXQgcmV0YWluIGFsbCBzaG9ydCBzZXJ2aWNlPC9zcGFuPjxz cGFuIGxhbmc9IkZSIj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQombmJzcDsgJm5ic3A7bnVtYmVycy7igJ08 L3NwYW4+PHNwYW4gbGFuZz0iRlIiPiA8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 YnI+DQpKYW5ldDxicj4NCjxicj4NClRoaXMgaXMgYSBQUklWQVRFIG1lc3NhZ2UuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgd2l0aG91dCBjb3B5 aW5nIGFuZCBraW5kbHkgYWR2aXNlIHVzIGJ5IGUtbWFpbCBvZiB0aGUgbWlzdGFrZSBpbiBkZWxp dmVyeS4gTk9URTogUmVnYXJkbGVzcyBvZiBjb250ZW50LCB0aGlzIGUtbWFpbCBzaGFsbCBub3Qg b3BlcmF0ZSB0byBiaW5kIENTQyB0byBhbnkgb3JkZXIgb3Igb3RoZXIgY29udHJhY3QNCiB1bmxl c3MgcHVyc3VhbnQgdG8gZXhwbGljaXQgd3JpdHRlbiBhZ3JlZW1lbnQgb3IgZ292ZXJubWVudCBp bml0aWF0aXZlIGV4cHJlc3NseSBwZXJtaXR0aW5nIHRoZSB1c2Ugb2YgZS1tYWlsIGZvciBzdWNo IHB1cnBvc2UuPC9zcGFuPjxzcGFuIGxhbmc9IkZSIj4NCjxicj4NCjxicj4NCjxicj4NCjwvc3Bh bj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1RjVGNUYiPjxicj4N CkZyb206ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJGUiIg c3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mcXVvdDtOT0VMLCBFUklDICZuYnNwOyhFUklDIEMpJnF1b3Q7 ICZsdDs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxhIGhyZWY9Im1haWx0bzplY25vZWxAcmVzZWFy Y2guYXR0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ZWNu b2VsQHJlc2VhcmNoLmF0dC5jb208L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5 bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj4NCjwvc3Bhbj48c3Bh biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1RjVGNUYiPjxicj4NClRvOiAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm b250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+JnF1b3Q7J0NoYXJsZXMgU2hlbicmcXVvdDsgJmx0Ozwvc3Bhbj48c3BhbiBs YW5nPSJGUiI+PGEgaHJlZj0ibWFpbHRvOmNoYXJsZXNAY3MuY29sdW1iaWEuZWR1IiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5jaGFybGVzQGNzLmNvbHVtYmlhLmVk dTwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjcuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZn dDssDQogJnF1b3Q7PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48YSBocmVmPSJtYWlsdG86c2lwLW92 ZXJsb2FkQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3 LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5zaXAtb3ZlcmxvYWRAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJGUiIg c3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mcXVvdDsNCiAmbHQ7PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48 YSBocmVmPSJtYWlsdG86c2lwLW92ZXJsb2FkQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5zaXAtb3ZlcmxvYWRAaWV0Zi5vcmc8L3NwYW4+PC9hPjwv c3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7PC9zcGFuPjxzcGFu IGxhbmc9IkZSIj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiM1RjVGNUYiPjxicj4NCkNjOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QXJhdGEgS29pa2UgJmx0Ozwvc3Bh bj48c3BhbiBsYW5nPSJGUiI+PGEgaHJlZj0ibWFpbHRvOmtvaWtlLmFyYXRhQGxhYi5udHQuY28u anAiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmtvaWtlLmFyYXRh QGxhYi5udHQuY28uanA8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZv bnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4mZ3Q7LA0KIEhlbm5pbmcgU2NodWx6cmlubmUgJmx0Ozwvc3Bhbj48c3BhbiBs YW5nPSJGUiI+PGEgaHJlZj0ibWFpbHRvOmhnc0Bjcy5jb2x1bWJpYS5lZHUiIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmhnc0Bjcy5jb2x1bWJpYS5lZHU8L3NwYW4+ PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7PC9zcGFu PjxzcGFuIGxhbmc9IkZSIj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6 ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiM1RjVGNUYiPjxicj4NCkRhdGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4xMi8xMy8yMDEyIDAz OjAxIFBNPC9zcGFuPjxzcGFuIGxhbmc9IkZSIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzVGNUY1RiI+U3ViamVj dDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHls ZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPlJlOiBbc2lwLW92ZXJsb2FkXSBJLUQgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7QWN0aW9uOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC1pZXRmLXNv Yy1sb2FkLWNvbnRyb2wtZXZlbnQtcGFja2FnZS0wNS50eHQ8L3NwYW4+PHNwYW4gbGFuZz0iRlIi Pg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250 LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojNUY1RjVGIj5TZW50IGJ5OiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxhIGhyZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWQtYm91 bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4 dC1hbGlnbjpjZW50ZXIiPjxzcGFuIGxhbmc9IkZSIj4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAw JSIgbm9zaGFkZT0iIiBzdHlsZT0iY29sb3I6I0EwQTBBMCIgYWxpZ249ImNlbnRlciI+DQo8L3Nw YW4+PC9kaXY+DQo8cD48c3BhbiBsYW5nPSJGUiI+PGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxh bmc9IkZSIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDQwODAiPjxicj4NCkNoYXJsZXMsPC9zcGFuPjxzcGFuIGxh bmc9IkZSIj4gPC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDQwODAiPjxicj4N CiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+IDwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMDA0MDgwIj48YnI+DQpJIHdlbnQgdGhyb3VnaCB5b3VyIGxhdGVzdCB2ZXJzaW9u IGFuZCBoYXZlIG5vIGNvbW1lbnRzIGJleW9uZCB3aGF0IHdhcyBhbHJlYWR5IHBvc3RlZC48L3Nw YW4+PHNwYW4gbGFuZz0iRlIiPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMw MDQwODAiPjxicj4NCiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+IDwvc3Bhbj48c3BhbiBs YW5nPSJGUiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMDA0MDgwIj48YnI+DQpZb3UgY2FuIGhhdmUgbXkgcmV2aWV3 IGNvdW50ZWQgZm9yIHRoZSBJRVNHIHJldmlldy48L3NwYW4+PHNwYW4gbGFuZz0iRlIiPiA8L3Nw YW4+DQo8c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA0MDgwIj48YnI+DQombmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRlIiPiA8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAw NDA4MCI+PGJyPg0KVGhhbmtzLDwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+IDwvc3Bhbj48c3BhbiBs YW5nPSJGUiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMDA0MDgwIj48YnI+DQombmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRlIiPiA8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiNGRjgxMDAiPjxicj4NCkVyaWMgTm9lbDwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZv bnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzVGNUY1RiI+DQo8Yj48YnI+DQpBVCZhbXA7VCBMYWJzLCBJbmMu PC9iPiA8L3NwYW4+PGk+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMwMEExRTAiPjxicj4NClJldGhpbmsgUG9zc2libGU8L3NwYW4+PC9pPjxzcGFuIGxhbmc9IkZS Ij4gPC9zcGFuPjxpPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MDBBMUUwIj48YnI+DQombmJzcDs8L3NwYW4+PC9pPjxzcGFuIGxhbmc9IkZSIj4gPC9zcGFuPjxz cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1Zl cmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNUY1RjVGIj48YnI+DQpO ZXR3b3JrIERlc2lnbiBhbmQgUGVyZm9ybWFuY2UgQW5hbHlzaXM8YnI+DQoyMDAgU291dGggTGF1 cmVsIEF2ZW51ZSwgRDUtM0QxOTxicj4NCk1pZGRsZXRvd24sIE5KIDA3NzQ4PGJyPg0KUDogPC9z cGFuPjxzcGFuIGxhbmc9IkZSIj48YSBocmVmPSJ0ZWw6NzMyLjQyMC40MTc0IiB0YXJnZXQ9Il9i bGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtWZXJk YW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjczMi40MjAuNDE3NDwvc3Bhbj48L2E+ DQo8dT48c3BhbiBzdHlsZT0iY29sb3I6Ymx1ZSI+PGJyPg0KPC9zcGFuPjwvdT48YSBocmVmPSJt YWlsdG86anNtaXRoQGF0dC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+ZWNub2VsQGF0dC5jb208L3NwYW4+PC9hPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkZS IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMwMDQwODAiPjxicj4NCiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+ IDwvc3Bhbj48Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQpGcm9tOjwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IDwvc3Bhbj4NCjxzcGFuIGxhbmc9IkZSIj48YSBocmVmPSJtYWls dG86c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4g bGFuZz0iRlIiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IFs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxhIGhyZWY9Im1haWx0bzpz aXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ bWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48L3NwYW4+PHNw YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5DaGFybGVzIFNoZW48Yj48 YnI+DQpTZW50OjwvYj4gTW9uZGF5LCBPY3RvYmVyIDIyLCAyMDEyIDEyOjQ3IFBNPGI+PGJyPg0K VG86PC9iPiA8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxhIGhyZWY9Im1haWx0bzpzaXAtb3Zlcmxv YWRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnNpcC1vdmVybG9hZEBpZXRm Lm9yZzwvc3Bhbj48L2E+PC9zcGFuPjxiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCkNjOjwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFyYXRhIEtvaWtlOyBIZW5uaW5nIFNjaHVs enJpbm5lPGI+PGJyPg0KU3ViamVjdDo8L2I+IFJlOiBbc2lwLW92ZXJsb2FkXSBJLUQgQWN0aW9u OiBkcmFmdC1pZXRmLXNvYy1sb2FkLWNvbnRyb2wtZXZlbnQtcGFja2FnZS0wNS50eHQ8L3NwYW4+ PHNwYW4gbGFuZz0iRlIiPg0KPGJyPg0KJm5ic3A7IDxicj4NCkhpIGFsbCwgPGJyPg0KJm5ic3A7 IDxicj4NCkkndmUgc3VibWl0dGVkIGEgbmV3IHZlcnNpb24gb2YgZHJhZnQtaWV0Zi1zb2MtbG9h ZC1jb250cm9sLWV2ZW50LXBhY2thZ2UuIDxicj4NCiZuYnNwOyA8YnI+DQpEaWZmIGlzIGF2YWls YWJsZSBhdDogPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt aWV0Zi1zb2MtbG9hZC1jb250cm9sLWV2ZW50LXBhY2thZ2UtMDUiIHRhcmdldD0iX2JsYW5rIj4N Cmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtc29jLWxvYWQtY29u dHJvbC1ldmVudC1wYWNrYWdlLTA1PC9hPg0KPGJyPg0KJm5ic3A7IDxicj4NClRoaXMgdmVyc2lv biBzaG91bGQgaGF2ZSBpbmNvcnBvcmF0ZWQgcmVzcG9uc2VzIHRvIGFsbCBjb21tZW50cyByZWNl aXZlZCBzbyBmYXIgKHBsZWFzZSBsZXQgbWUga25vdyBpZiBJIG1pc3NlZCBhbnl0aGluZykuIE1h aW4gY2hhbmdlcyBpbmNsdWRlIGFkZGluZzogNi4zLjMgKHRhcmdldC1zaXAtZW50aXR5LCBjdXJy ZW50bHkgb3B0aW9uYWwpIDYuNS4yIChleGFtcGxlIG1lc3NhZ2UgZmxvdyksIHJlbW92aW5nIDUu MTIgKHN0YXRlIGFnZW50KSwNCiBhcyB3ZWxsIGFzIGNoYW5nZXMgYW5kIGNsYXJpZmljYXRpb25z IGluIGEgbnVtYmVyIG9mIG90aGVyIHNlY3Rpb25zLCBlLmcuLCA2LjMuMiAoZXhwbGljaXQgbGlz dCBvZiBtZXRob2QgdHlwZXMgc3ViamVjdGVkIHRvIGNvbnRyb2wpIDYuNCAodXNpbmcgcmVkaXJl Y3QgYXMgYWx0ZXJuYXRpdmUgYWN0aW9uKSwgNS44ICh0ZXJtaW5hdGluZyBwb2xpY2llcyB1cG9u IHRlcm1pbmF0aW9uIG9mIHN1YnNjcmlwdGlvbikgYW5kIDEzLjIgUFNUTiByZWZlcmVuY2VzLg0K PGJyPg0KJm5ic3A7IDxicj4NCkNvbW1lbnRzIGFyZSB3ZWxjb21lICEgPGJyPg0KJm5ic3A7IDxi cj4NCkNoYXJsZXMgPGJyPg0KJm5ic3A7IDxicj4NCiZuYnNwOyA8YnI+DQombmJzcDsgPGJyPg0K T24gTW9uLCBPY3QgMjIsIDIwMTIgYXQgMTI6MzIgUE0sICZsdDs8YSBocmVmPSJtYWlsdG86aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnPC9hPiZndDsgd3JvdGU6DQo8YnI+DQo8YnI+DQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBp cyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMu PGJyPg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgU0lQIE92ZXJsb2FkIENvbnRy b2wgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtUaXRsZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogQSBT ZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCkgTG9hZCBDb250cm9sIEV2ZW50IFBhY2th Z2U8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtBdXRob3IocykgJm5ic3A7ICZuYnNw OyAmbmJzcDsgOiBDaGFybGVzIFNoZW48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtIZW5uaW5nIFNjaHVsenJpbm5lPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7QXJhdGEgS29pa2U8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtGaWxlbmFt ZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IGRyYWZ0LWlldGYtc29jLWxvYWQtY29udHJv bC1ldmVudC1wYWNrYWdlLTA1LnR4dDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1Bh Z2VzICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiAzOTxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO0RhdGUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDs6IDIwMTItMTAtMjI8YnI+DQo8YnI+DQpBYnN0cmFjdDo8YnI+DQombmJzcDsgV2Ug ZGVmaW5lIGEgbG9hZCBjb250cm9sIGV2ZW50IHBhY2thZ2UgZm9yIHRoZSBTZXNzaW9uIEluaXRp YXRpb248YnI+DQombmJzcDsgUHJvdG9jb2wgKFNJUCkuICZuYnNwO0l0IGFsbG93cyBTSVAgc2Vy dmVycyB0byBkaXN0cmlidXRlIGxvYWQgZmlsdGVycyB0bzxicj4NCiZuYnNwOyBvdGhlciBTSVAg c2VydmVycyBpbiB0aGUgbmV0d29yay4gJm5ic3A7VGhlIGxvYWQgZmlsdGVycyBjb250YWluIHJ1 bGVzIHRvPGJyPg0KJm5ic3A7IHRocm90dGxlIGNhbGxzIGJhc2VkIG9uIHRoZWlyIHNvdXJjZSBv ciBkZXN0aW5hdGlvbiBkb21haW4sIHRlbGVwaG9uZTxicj4NCiZuYnNwOyBudW1iZXIgcHJlZml4 IG9yIGZvciBhIHNwZWNpZmljIHVzZXIuICZuYnNwO1RoZSBtZWNoYW5pc20gaGVscHMgdG8gcHJl dmVudDxicj4NCiZuYnNwOyBzaWduYWxpbmcgb3ZlcmxvYWQgYW5kIGNvbXBsZW1lbnRzIGZlZWRi YWNrLWJhc2VkIFNJUCBvdmVybG9hZDxicj4NCiZuYnNwOyBjb250cm9sIGVmZm9ydHMuPGJyPg0K PGJyPg0KPGJyPg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJh ZnQgaXM6PHU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPjxicj4NCjwvc3Bhbj48L3U+PGEgaHJl Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zb2MtbG9hZC1j b250cm9sLWV2ZW50LXBhY2thZ2UiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNvYy1sb2FkLWNvbnRyb2wtZXZlbnQtcGFja2FnZTwv YT48YnI+DQo8YnI+DQpUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBh dDo8dT48c3BhbiBzdHlsZT0iY29sb3I6Ymx1ZSI+PGJyPg0KPC9zcGFuPjwvdT48YSBocmVmPSJo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNvYy1sb2FkLWNvbnRyb2wtZXZl bnQtcGFja2FnZS0wNSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtc29jLWxvYWQtY29udHJvbC1ldmVudC1wYWNrYWdlLTA1PC9hPjxicj4NCjxi cj4NCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDo8dT48 c3BhbiBzdHlsZT0iY29sb3I6Ymx1ZSI+PGJyPg0KPC9zcGFuPjwvdT48YSBocmVmPSJodHRwOi8v d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXNvYy1sb2FkLWNvbnRyb2wtZXZl bnQtcGFja2FnZS0wNSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlm Zj91cmwyPWRyYWZ0LWlldGYtc29jLWxvYWQtY29udHJvbC1ldmVudC1wYWNrYWdlLTA1PC9hPjxi cj4NCjxicj4NCjxicj4NCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5v bnltb3VzIEZUUCBhdDo8dT48c3BhbiBzdHlsZT0iY29sb3I6Ymx1ZSI+PGJyPg0KPC9zcGFuPjwv dT48YSBocmVmPSJmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLyIgdGFyZ2V0PSJf YmxhbmsiPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvPC9hPjxicj4NCjxicj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc2lw LW92ZXJsb2FkIG1haWxpbmcgbGlzdDx1PjxzcGFuIHN0eWxlPSJjb2xvcjpibHVlIj48YnI+DQo8 L3NwYW4+PC91PjxhIGhyZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5zaXAtb3ZlcmxvYWRAaWV0Zi5vcmc8L2E+PHU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs dWUiPjxicj4NCjwvc3Bhbj48L3U+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zaXAtb3ZlcmxvYWQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcC1vdmVybG9hZDwvYT4NCjxicj4NCiZuYnNwOzwvc3Bh bj48dHQ+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48L3R0PjxzcGFuIGxh bmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+PGJyPg0Kc2lwLW92ZXJsb2FkIG1haWxpbmcgbGlzdDx1PjxzcGFuIHN0eWxl PSJjb2xvcjpibHVlIj48YnI+DQo8L3NwYW4+PC91Pjwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PGEg aHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij5zaXAtb3ZlcmxvYWRAaWV0Zi5vcmc8L3NwYW4+PC9hPjx1PjxzcGFuIHN0eWxlPSJjb2xv cjpibHVlIj48YnI+DQo8L3NwYW4+PC91PjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2lwLW92ZXJsb2FkIiB0YXJnZXQ9Il9ibGFuayI+PHR0PjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NpcC1vdmVybG9hZDwvc3Bhbj48L3R0PjwvYT4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48dHQ+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjwvdHQ+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPGJyPg0KPC9zcGFuPjx0 dD48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkNlIG1lc3NhZ2UgZXQg c2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25m aWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzwvc3Bhbj48L3R0 PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNh dGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBs ZSBzaWduYWxlcjwvc3Bhbj48L3R0PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gbGFuZz0iRlIi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5hIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBh aW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBl dGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLDwvc3Bhbj48L3R0PjxzcGFuIGxhbmc9IkZS IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjwvc3Bh bj48dHQ+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5GcmFuY2UgVGVs ZWNvbSAtIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2Ug YSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48L3NwYW4+PC90dD48c3Bh biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48 YnI+DQo8YnI+DQo8L3NwYW4+PHR0PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdCI+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlk ZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5 IGxhdzs8L3NwYW4+PC90dD48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIGxhbmc9IkZSIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2Vk IG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uPC9zcGFuPjwvdHQ+PHNwYW4gbGFuZz0i RlIiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPC9z cGFuPjx0dD48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPklmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjwvc3Bhbj48L3R0 PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIEZyYW5jZSBUZWxlY29tIC0gT3JhbmdlIGlz IG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2Vk IG9yIGZhbHNpZmllZC48L3NwYW4+PC90dD48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIGxhbmc9 IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+VGhhbmsgeW91Ljwvc3Bhbj48L3R0PjxzcGFu IGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwcmU+PHNwYW4gbGFu Zz0iRlIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i RlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+ Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5m b3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBk b25jPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5wYXMgZXRy ZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91 cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+YSBsJ2V4cGVkaXRl dXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3Nh Z2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkZyYW5jZSBUZWxlY29tIC0g T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBh bHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIGxhbmc9IkZSIj5UaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkg Y29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBi ZSBwcm90ZWN0ZWQgYnkgbGF3OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs YW5nPSJGUiI+dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3 aXRob3V0IGF1dGhvcmlzYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkZSIj5JZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh Y2htZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkFz IGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgRnJhbmNlIFRlbGVjb20gLSBPcmFuZ2UgaXMgbm90IGxp YWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFs c2lmaWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+VGhh bmsgeW91LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_E42CCDDA6722744CB241677169E8365601F9B5ADMISOUT7MSGUSR9I_-- From keith.drage@alcatel-lucent.com Wed Jan 2 11:00:36 2013 Return-Path: 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 0AE4C21F86F0; Wed, 2 Jan 2013 11:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.152 X-Spam-Level: X-Spam-Status: No, score=-110.152 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 srYXbfQWnXyQ; Wed, 2 Jan 2013 11:00:29 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 5C99121F86DD; Wed, 2 Jan 2013 11:00:29 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r02J08ws026936 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 2 Jan 2013 20:00:08 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 2 Jan 2013 20:00:08 +0100 From: "DRAGE, Keith (Keith)" To: Janet P Gunn , Charles Shen Date: Wed, 2 Jan 2013 20:00:05 +0100 Thread-Topic: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt Thread-Index: Ac3nerQDMkNLBJPOSPafGzG7+M+vyQBoCqDQ Message-ID: References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> <5EBD159DE88147488A3B1590E090018403530A9E6275@njfpsrvexg2.research.att.com> <24674_1355758104_50CF3A18_24674_468_1_88CAD1D4E8773F42858B58CAA28272A00E2A2C@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE20D7456E216FRMRSSXCHMBSC_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "sip-overload-bounces@ietf.org" , "NOEL, ERIC \(ERIC C\)" , "sip-overload@ietf.org" , Arata Koike , Henning Schulzrinne Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 19:00:36 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE20D7456E216FRMRSSXCHMBSC_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I don't have a problem either way - all I want to ensure is that the text o= f the two drafts aligns with each other on the behaviour - so if we change = this one, we also change the other. Regards Keith ________________________________ From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] = On Behalf Of Janet P Gunn Sent: 31 December 2012 17:17 To: Charles Shen Cc: sip-overload-bounces@ietf.org; sip-overload@ietf.org; Arata Koike; NOEL= , ERIC (ERIC C); Henning Schulzrinne Subject: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-co= ntrol-event-package-05.txt I would be happy with "MUST", but I'd like to hear form the carriers- espe= cially from Keith Drage, as he is the one who initiated the new wording. It may be a question of WHOSE local policy we are talking about. There i= s the "local policy" as defined by the government (which may politically co= rrect but technically unstable). There is also "local policy" defined by t= he "carrier" (which may be technically stable, but politically incorrect). "Should" leaves some wiggle room as to WHICH local policy is being honored= . Janet From: Charles Shen To: bruno.chatras@orange.com Cc: Janet P Gunn/USA/CSC@CSC, "NOEL, ERIC (ERIC C)" = , "sip-overload-bounces@ietf.org" , "sip-ove= rload@ietf.org" , Arata Koike , Henning Schulzrinne Date: 12/18/2012 10:32 PM Subject: Re: [sip-overload] I-D Action: draft-ietf-soc-load-control-= event-package-05.txt Sent by: charles.newyork@gmail.com ________________________________ Hi Bruno, I noticed your comment, can we reach a consensus on this list so = I can update the draft accordingly? Thanks! Charles On Mon, Dec 17, 2012 at 10:28 AM, > wrote: I agree that both drafts should use the same text but I'm still not sure to= understand why we use "SHOULD" rather than "MUST"? Setting a local policy= is optional but if there is one it seems to me that SIP clients MUST hono= r it. De : sip-overload-bounces@ietf.org [m= ailto:sip-overload-bounces@ietf.org] = De la part de Charles Shen Envoy=E9 : samedi 15 d=E9cembre 2012 16:06 =C0 : Janet P Gunn Cc : NOEL, ERIC (ERIC C); sip-overload-bounces@ietf.org; sip-overload@ietf.org; Ar= ata Koike; Henning Schulzrinne Objet : Re: [sip-overload] I-D Action: draft-ietf-soc-load-control-event-pa= ckage-05.txt Hi Janet, I will revise as suggested. Thanks you again! Charles On Fri, Dec 14, 2012 at 3:56 PM, Janet P Gunn > wrote: You can count my review for IESG. I only have a couple of things to add. In section 4.4, you have the text: "In addition, whatever the actual policy is, SIP servers SHOULD honor the local policy for prioritizing SIP requests such as policies based on the contents of the Resource-Priority Header (RPH) [RFC4412]. The RPH contents may indicate high priority requests that should be preserved as much as possible, or low priority requests that could be dropped during overload. Other indicators, such as the SOS Uniform Resource Name (URN) [RFC5031] indicating an emergency request, may also be used for prioritization." During the last IETF meeting, there was an exchange on the list about this= wording (in multiple IDs) with apparent agreement (on the list) to use th= e same text in all the overload drafts " A SIP client SHOULD honor any local policy for prioritizing SIP requests such as policies based on message type, e.g., INVITEs vs. requests associated with existing sessions. A SIP client SHOULD honor any local policy for prioritizing SIP requests based on the content of the Resource- Priority header (RPH, RFC4412 [RFC4412]). Specific (namespace.value) RPH contents may indicate high priority requests that should be preserved as much as possible during overload. The RPH contents can also indicate a low-priority request that is eligible to be dropped during times of overload. A SIP client SHOULD honor any local policy for prioritizing SIP requests relating to emergency calls, as identified by the SOS URN [RFC5031] indicating an emergency request." So would you please use this revised wording. nits Sec 5.8 last sentence of first paragraph "A subscriber receiving the notification first installs these rules and then filter incoming requests to enforce actions on appropriate requests, for example, limiting the sending rate of call requests destined for a specific SIP entity." "filter" should be "filters" Pg 18 This "this solution does not permit to define a filter that excludes all E.164 numbers in that country but retain all short service numbers." Should be "this solution does not permit the definition of filter that excludes all E.164 numbers in that country but retain all short service numbers." Janet This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreeme= nt or government initiative expressly permitting the use of e-mail for such= purpose. From: "NOEL, ERIC (ERIC C)" > To: "'Charles Shen'" >, "sip-overload@ietf.org" > Cc: Arata Koike >, Henning Schulzrinne > Date: 12/13/2012 03:01 PM Subject: Re: [sip-overload] I-D Action: draft-ietf-soc= -load-control-event-package-05.txt Sent by: sip-overload-bounces@ietf.org ________________________________ Charles, I went through your latest version and have no comments beyond what was alr= eady posted. You can have my review counted for the IESG review. Thanks, Eric Noel AT&T Labs, Inc. Rethink Possible Network Design and Performance Analysis 200 South Laurel Avenue, D5-3D19 Middletown, NJ 07748 P: 732.420.4174 ecnoel@att.com From: sip-overload-bounces@ietf.org [= mailto:sip-overload-bounces@ietf.org] On Behalf Of Charles Shen Sent: Monday, October 22, 2012 12:47 PM To: sip-overload@ietf.org Cc: Arata Koike; Henning Schulzrinne Subject: Re: [sip-overload] I-D Action: draft-ietf-soc-load-control-event-p= ackage-05.txt Hi all, I've submitted a new version of draft-ietf-soc-load-control-event-package. Diff is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-soc-loa= d-control-event-package-05 This version should have incorporated responses to all comments received so= far (please let me know if I missed anything). Main changes include adding= : 6.3.3 (target-sip-entity, currently optional) 6.5.2 (example message flow= ), removing 5.12 (state agent), as well as changes and clarifications in a = number of other sections, e.g., 6.3.2 (explicit list of method types subjec= ted to control) 6.4 (using redirect as alternative action), 5.8 (terminatin= g policies upon termination of subscription) and 13.2 PSTN references. Comments are welcome ! Charles On Mon, Oct 22, 2012 at 12:32 PM, > wrote: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Overload Control Working Group of the = IETF. Title : A Session Initiation Protocol (SIP) Load Control E= vent Package Author(s) : Charles Shen Henning Schulzrinne Arata Koike Filename : draft-ietf-soc-load-control-event-package-05.txt Pages : 39 Date : 2012-10-22 Abstract: We define a load control event package for the Session Initiation Protocol (SIP). It allows SIP servers to distribute load filters to other SIP servers in the network. The load filters contain rules to throttle calls based on their source or destination domain, telephone number prefix or for a specific user. The mechanism helps to prevent signaling overload and complements feedback-based SIP overload control efforts. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-soc-load-control-event-package There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-soc-load-control-event-package-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-soc-load-control-event-packag= e-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload _______________________________________________ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. --_000_EDC0A1AE77C57744B664A310A0B23AE20D7456E216FRMRSSXCHMBSC_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I don’t have a problem either wa= y – all I want to ensure is that the text of the two drafts aligns with each other on= the behaviour – so if we change this one, we also change the other. =

 

Regards

 

Keith

 

From:= sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] On Behalf Of Janet P Gunn
Sent: 31 December 2012 17:17=
To: Charles Shen
Cc: sip-overload-bounces@iet= f.org; sip-overload@ietf.org; Arata Koike; NOEL, ERIC (ERIC C); Henning Schulzrinn= e
Subject: [sip-overload] Loca= l Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt

 


I would  be happy with "MUST", but I'd like to hear form the carriers- especially from Keith Drage, as he is the one who initiated the n= ew wording.

It may be a question of  WHOSE local policy we are talking about.   There is the "local policy" as defined by the government (which m= ay politically correct but technically unstable).  There is also "lo= cal policy" defined by the "carrier" (which may be  technic= ally stable, but politically incorrect).

"Should" leaves some wiggle room as to WHICH local policy  is being honored.

Janet



From:        Charles Shen <charles@cs.columbia.edu>
To:        bruno.chatras@orange.com
Cc:        Janet P Gunn/USA/CSC@CSC, "NOEL, ERIC (ERIC C)" <ecnoel@att.com>, "sip-overload-bounces@ietf.org" <sip-overload-bounces@ietf.org>, "sip-overload@ietf.org" <sip-overload@ietf.org>, Arata Koike <koike.arata@lab.ntt.co.jp>= ;, Henning Schulzrinne <hgs@cs.columbia.edu>
Date:        12/18/2012 10:32 PM<= /font>
Subject:        <= /span>Re: [sip-overload] I-D Action: draft-ietf-soc-load-control-event-package-05.txt=
Sent by:        <= /span>charles.newyork@gmail.com




Hi Bruno, I noticed your comment, can we reach a consensus on this list so = I can update the draft accordingly? 

Thanks!

Charles

On Mon, Dec 17, 2012 at 10:28 A= M, <bruno.cha= tras@orange.com> wrote:
I agree that both drafts should u= se the same text but I’m still not sure to understand why we use “= SHOULD” rather than “MUST”?  Setting a local policy is optional but if th= ere is one it seems to me that  SIP clients MUST honor it. =

 

 

 

De :<= span style=3D'font-size:10.0pt;font-family:Tahoma'> sip-overl= oad-bounces@ietf.org= [mailto:sip-overl= oad-bounces@ietf.org= ] De la part de Charles Shen
Envoy=E9 : samedi 15 d=E9cembre 2012 16:06
=C0 : Janet P Gunn
Cc : NOEL, ERIC (ERIC C); sip-overl= oad-bounces@ietf.org= ; sip-overload@ietf.org<= /font>= ; Arata Koike; Henning Schulzrinne
Objet : Re: [sip-overload] I-D Action: draft-ietf-soc-load-control-event-package-05.txt <= /p>

 

Hi Janet, I will revise as suggested. Thanks you again!

Charles

On Fri, Dec 14, 2012= at 3:56 PM, Janet P= Gunn <jgunn6@csc.com> wro= te:

You can count my review for IESG.

I only have a couple of things to add.

In section 4.4, you have the text:
“In addition, whatever the actual policy is, SIP
   servers SHOULD honor the local policy for prioritizing SIP requests
   such as policies based on the contents of the Resource-Priorit= y
   Header (RPH) [RFC4412].  The RPH contents may indicate hi= gh priority
   requests that should be preserved as much as possible, or low<= /span>
   priority requests that could be dropped during overload.  Other
   indicators, such as the SOS Uniform Resource Name (URN) [RFC5031]
   indicating an emergency request, may also be used for prioritization.”

During the last IETF meeting, there was an exchange on the list  about this wording (in multiple IDs) with apparent agreement (on the list) to use  the same text in all the overload drafts

"   A SIP client SHOULD honor any local policy for prioritizing S= IP
 requests such as policies based = on message type, e.g., INVITEs vs. =
  requests associated with existing sessions.
   
  A SIP client SHOULD honor any l= ocal policy for prioritizing SIP
  requests based on the content of the Resource-
 Priority header (RPH, RFC4412 [RFC4412]).  Specific (namespace.value)
 RPH contents may indicate high priority requests that should be
 preserved as much as possible during overload.  The RPH contents= can
 also indicate a low-priority request that is eligible to be dropped  during times of overload.  

 A SIP client SHOULD honor any local policy for prioritizing SIP
 requests relating to emergency calls, as identified by the SOS
 URN [RFC5031] indicating an emergency request."
So would you please use this revised wording.

nits

Sec 5.8 last sentence of first paragraph
“A subscriber receiving the notification first installs=
   these rules and then filter incoming requests to enforce actio= ns on
   appropriate requests, for example, limiting the sending rate o= f call
   requests destined for a specific SIP entity.”
“filter” should be “filters”

Pg 18
This
“this solution does not permit to define a filter that excludes
   all E.164 numbers in that country but retain all short service=
   numbers.”
Should be
“this solution does not permit the definition of filter that excludes=
   all E.164 numbers in that country but retain all short service=
   numbers.”

Janet

This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pur= suant to explicit written agreement or government initiative expressly permitting= the use of e-mail for such purpose.



From:        = "NOEL, ERIC  (ERIC C)= " <ecn= oel@research.att.com>= ;
To:        "'Charles Shen'" <= charles@cs.columbia.edu<= /font>>= ;, "sip-overload@ietf.org&qu= ot; <sip-overload@ietf.org>= ;
Cc:        Arata Koike <<= a href=3D"mailto:koike.arata@lab.ntt.co.jp" target=3D"_blank">koike.arata@= lab.ntt.co.jp>= ;, Henning Schulzrinne <hgs@cs.columbia.edu><= /font>
Date:        = 12/13/2012 03:01 PM

Subject:        Re: [sip-overload] I-D        Action:        draft-ietf-soc-load-control-event-package-05.txt <= /o:p>

Sent by:        sip-overload= -bounces@ietf.org




Charles,
 
I went through your latest version and have no comments beyond what was alr= eady posted.
 
You can have my review counted for the IESG review.
 
Thanks,
 
Eric Noel
AT&T Labs, Inc.
Rethink Possible
 
Network Design and Performance Analysis
200 South Laurel Avenue, D5-3D19
Middletown, NJ 07748
P: 732.420.= 4174
ecnoel@a= tt.com
 
From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] On Behalf Of Charles Shen
Sent: Monday, October 22, 2012 12:47 PM
To: si= p-overload@ietf.org
Cc: Arata Koike; Henning Schulzrinne
Subject: Re: [sip-overload] I-D Action: draft-ietf-soc-load-control-event-package-05.txt
 
Hi all,
 
I've submitted a new version of draft-ietf-soc-load-control-event-package. =
 
Diff is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-soc-load-co= ntrol-event-package-05
 
This version should have incorporated responses to all comments received so= far (please let me know if I missed anything). Main changes include adding: 6.3= .3 (target-sip-entity, currently optional) 6.5.2 (example message flow), remov= ing 5.12 (state agent), as well as changes and clarifications in a number of ot= her sections, e.g., 6.3.2 (explicit list of method types subjected to control) = 6.4 (using redirect as alternative action), 5.8 (terminating policies upon termination of subscription) and 13.2 PSTN references.
 
Comments are welcome !
 
Charles
 
 
 
On Mon, Oct 22, 2012 at 12:32 PM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the SIP Overload Control Working Group of the IETF.

       Title           : A Ses= sion Initiation Protocol (SIP) Load Control Event Package
       Author(s)       : Charles Shen                      = ;    Henning Schulzrinne
                     = ;    Arata Koike
       Filename        : draft-ietf-soc-load-control-event-package-05.txt
       Pages           : 39        Date            : 2012-10-22

Abstract:
  We define a load control event package for the Session Initiation   Protocol (SIP).  It allows SIP servers to distribute load filte= rs to
  other SIP servers in the network.  The load filters contain rul= es to
  throttle calls based on their source or destination domain, telephon= e
  number prefix or for a specific user.  The mechanism helps to prevent
  signaling overload and complements feedback-based SIP overload
  control efforts.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-soc-load-cont= rol-event-package

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-soc-load-control-ev= ent-package-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-soc-load-co= ntrol-event-package-05


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
sip-overload mailing list<= br> sip-overload@ietf.org
https://www.ietf.org/mailman/listinfo/sip-overload  _______________________________________________
sip-overload mailing list<= br> sip-overload@ietf.org
https://www.ietf.org/mailman/listinfo/sip-overload

 

<= span style=3D'font-size:12.0pt'>________________________________________________= _________________________________________________________________________

Ce message et ses pieces jointes peuvent con= tenir des informations confidentielles ou privilegiees et ne doivent donc<= /tt>
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler=
a l'expediteur et le detruire ainsi que les = pieces jointes. Les messages electroniques etant susceptibles d'alteration,=
France Telecom - Orange d= ecline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci= .

This message and its attachments may contain confidential or privileged information that may be protected by law;=
they should not be distributed, used or copi= ed without authorisation.
If you have received this email in error, pl= ease notify the sender and delete this message and its attachments.<= br> As emails may be altered, France Telecom - <= st1:City w:st=3D"on">Orange is not lia= ble for messages that have been modified, changed or falsified.
Thank you.

--_000_EDC0A1AE77C57744B664A310A0B23AE20D7456E216FRMRSSXCHMBSC_-- From charles.newyork@gmail.com Thu Jan 3 05:34:32 2013 Return-Path: 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 28ED821E8034; Thu, 3 Jan 2013 05:34:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 VO6RHQonCDgi; Thu, 3 Jan 2013 05:34:30 -0800 (PST) Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by ietfa.amsl.com (Postfix) with ESMTP id B997821F8C04; Thu, 3 Jan 2013 05:34:30 -0800 (PST) Received: by mail-oa0-f42.google.com with SMTP id j1so14190518oag.29 for ; Thu, 03 Jan 2013 05:34:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=JCp1HzWrAXlm1RReuVgW0OYjpn2bVQ3fLvT3oAnZV/8=; b=VXcQ/FfBo8TAL6lDfNP7GNgsU33SucPDxhttfpvao6XxVPlhCjdB+GB5yzCCAyb3Ql gKfmfNyMOoqzEKgV4RitQIrHmxnWX8cod+g2/Vm564MInFAcajcOLA/KAnlwvJRIJRBI ogMniyYCkrs8mMWS8EgsNkoDCERDp9lxk8wV1Hzu63SL+db9GPP3e/15SSlTPQ7qIYde bb4GqMbuwEWmNrDOzxMW3DUdxcqPybugdGvfpCWOgtfCyD4MM/U6I5vmA59JoZAvAkZX UoeBmKLkdTO18ScKfuyuY2CtokOjV+WWId4uVHLyVrl6XeEn6BndiHU/ka86tkM/ey9N 0cng== Received: by 10.60.172.229 with SMTP id bf5mr27035037oec.81.1357220070301; Thu, 03 Jan 2013 05:34:30 -0800 (PST) MIME-Version: 1.0 Sender: charles.newyork@gmail.com Received: by 10.182.12.202 with HTTP; Thu, 3 Jan 2013 05:34:09 -0800 (PST) In-Reply-To: References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> <5EBD159DE88147488A3B1590E090018403530A9E6275@njfpsrvexg2.research.att.com> <24674_1355758104_50CF3A18_24674_468_1_88CAD1D4E8773F42858B58CAA28272A00E2A2C@PEXCVZYM12.corporate.adroot.infra.ftgroup> From: Charles Shen Date: Thu, 3 Jan 2013 08:34:09 -0500 X-Google-Sender-Auth: Bx_1i5s53DCIXgvoWQrZ24AHGqA Message-ID: To: "DRAGE, Keith (Keith)" , vkg@bell-labs.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "sip-overload-bounces@ietf.org" , "sip-overload@ietf.org" , Arata Koike , "NOEL, ERIC \(ERIC C\)" , Henning Schulzrinne Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 13:34:32 -0000 Sounds good, I can update the wording in the event package draft, if Vijay is OK with the other one. Thanks Charles On Wed, Jan 2, 2013 at 2:00 PM, DRAGE, Keith (Keith) wrote: > I don=E2=80=99t have a problem either way =E2=80=93 all I want to ensure = is that the text of > the two drafts aligns with each other on the behaviour =E2=80=93 so if we= change > this one, we also change the other. > > > > Regards > > > > Keith > > > > ________________________________ > > From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org= ] > On Behalf Of Janet P Gunn > Sent: 31 December 2012 17:17 > To: Charles Shen > Cc: sip-overload-bounces@ietf.org; sip-overload@ietf.org; Arata Koike; NO= EL, > ERIC (ERIC C); Henning Schulzrinne > Subject: [sip-overload] Local Policy Re: I-D Action: > draft-ietf-soc-load-control-event-package-05.txt > > > > > I would be happy with "MUST", but I'd like to hear form the carriers- > especially from Keith Drage, as he is the one who initiated the new wordi= ng. > > It may be a question of WHOSE local policy we are talking about. There= is > the "local policy" as defined by the government (which may politically > correct but technically unstable). There is also "local policy" defined = by > the "carrier" (which may be technically stable, but politically incorrec= t). > > "Should" leaves some wiggle room as to WHICH local policy is being honor= ed. > > Janet > > > > From: Charles Shen > To: bruno.chatras@orange.com > Cc: Janet P Gunn/USA/CSC@CSC, "NOEL, ERIC (ERIC C)" , > "sip-overload-bounces@ietf.org" , > "sip-overload@ietf.org" , Arata Koike > , Henning Schulzrinne > Date: 12/18/2012 10:32 PM > Subject: Re: [sip-overload] I-D Action: > draft-ietf-soc-load-control-event-package-05.txt > Sent by: charles.newyork@gmail.com > > ________________________________ > > > > > Hi Bruno, I noticed your comment, can we reach a consensus on this list s= o I > can update the draft accordingly? > > Thanks! > > Charles > > On Mon, Dec 17, 2012 at 10:28 AM, wrote: > I agree that both drafts should use the same text but I=E2=80=99m still n= ot sure to > understand why we use =E2=80=9CSHOULD=E2=80=9D rather than =E2=80=9CMUST= =E2=80=9D? Setting a local policy > is optional but if there is one it seems to me that SIP clients MUST hon= or > it. > > > > > > > > De : sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org]= De > la part de Charles Shen > Envoy=C3=A9 : samedi 15 d=C3=A9cembre 2012 16:06 > =C3=80 : Janet P Gunn > Cc : NOEL, ERIC (ERIC C); sip-overload-bounces@ietf.org; > sip-overload@ietf.org; Arata Koike; Henning Schulzrinne > Objet : Re: [sip-overload] I-D Action: > draft-ietf-soc-load-control-event-package-05.txt > > > > Hi Janet, I will revise as suggested. Thanks you again! > > Charles > > On Fri, Dec 14, 2012 at 3:56 PM, Janet P Gunn wrote: > > You can count my review for IESG. > > I only have a couple of things to add. > > In section 4.4, you have the text: > =E2=80=9CIn addition, whatever the actual policy is, SIP > servers SHOULD honor the local policy for prioritizing SIP requests > such as policies based on the contents of the Resource-Priority > Header (RPH) [RFC4412]. The RPH contents may indicate high priority > requests that should be preserved as much as possible, or low > priority requests that could be dropped during overload. Other > indicators, such as the SOS Uniform Resource Name (URN) [RFC5031] > indicating an emergency request, may also be used for prioritization.= =E2=80=9D > > During the last IETF meeting, there was an exchange on the list about th= is > wording (in multiple IDs) with apparent agreement (on the list) to use t= he > same text in all the overload drafts > > " A SIP client SHOULD honor any local policy for prioritizing SIP > requests such as policies based on message type, e.g., INVITEs vs. > requests associated with existing sessions. > > A SIP client SHOULD honor any local policy for prioritizing SIP > requests based on the content of the Resource- > Priority header (RPH, RFC4412 [RFC4412]). Specific (namespace.value) > RPH contents may indicate high priority requests that should be > preserved as much as possible during overload. The RPH contents can > also indicate a low-priority request that is eligible to be dropped > during times of overload. > > A SIP client SHOULD honor any local policy for prioritizing SIP > requests relating to emergency calls, as identified by the SOS > URN [RFC5031] indicating an emergency request." > > So would you please use this revised wording. > > nits > > Sec 5.8 last sentence of first paragraph > =E2=80=9CA subscriber receiving the notification first installs > these rules and then filter incoming requests to enforce actions on > appropriate requests, for example, limiting the sending rate of call > requests destined for a specific SIP entity.=E2=80=9D > =E2=80=9Cfilter=E2=80=9D should be =E2=80=9Cfilters=E2=80=9D > > Pg 18 > This > =E2=80=9Cthis solution does not permit to define a filter that excludes > all E.164 numbers in that country but retain all short service > numbers.=E2=80=9D > Should be > =E2=80=9Cthis solution does not permit the definition of filter that excl= udes > all E.164 numbers in that country but retain all short service > numbers.=E2=80=9D > > Janet > > This is a PRIVATE message. If you are not the intended recipient, please > delete without copying and kindly advise us by e-mail of the mistake in > delivery. NOTE: Regardless of content, this e-mail shall not operate to b= ind > CSC to any order or other contract unless pursuant to explicit written > agreement or government initiative expressly permitting the use of e-mail > for such purpose. > > > > From: "NOEL, ERIC (ERIC C)" > To: "'Charles Shen'" , > "sip-overload@ietf.org" > Cc: Arata Koike , Henning Schulzrinne > > Date: 12/13/2012 03:01 PM > > Subject: Re: [sip-overload] I-D Action: > draft-ietf-soc-load-control-event-package-05.txt > > Sent by: sip-overload-bounces@ietf.org > > ________________________________ > > > > > Charles, > > I went through your latest version and have no comments beyond what was > already posted. > > You can have my review counted for the IESG review. > > Thanks, > > Eric Noel > AT&T Labs, Inc. > Rethink Possible > > Network Design and Performance Analysis > 200 South Laurel Avenue, D5-3D19 > Middletown, NJ 07748 > P: 732.420.4174 > ecnoel@att.com > > From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org= ] > On Behalf Of Charles Shen > Sent: Monday, October 22, 2012 12:47 PM > To: sip-overload@ietf.org > Cc: Arata Koike; Henning Schulzrinne > Subject: Re: [sip-overload] I-D Action: > draft-ietf-soc-load-control-event-package-05.txt > > Hi all, > > I've submitted a new version of draft-ietf-soc-load-control-event-package= . > > Diff is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-soc-load-control-event-pack= age-05 > > This version should have incorporated responses to all comments received = so > far (please let me know if I missed anything). Main changes include addin= g: > 6.3.3 (target-sip-entity, currently optional) 6.5.2 (example message flow= ), > removing 5.12 (state agent), as well as changes and clarifications in a > number of other sections, e.g., 6.3.2 (explicit list of method types > subjected to control) 6.4 (using redirect as alternative action), 5.8 > (terminating policies upon termination of subscription) and 13.2 PSTN > references. > > Comments are welcome ! > > Charles > > > > On Mon, Oct 22, 2012 at 12:32 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the SIP Overload Control Working Group of th= e > IETF. > > Title : A Session Initiation Protocol (SIP) Load Control > Event Package > Author(s) : Charles Shen > Henning Schulzrinne > Arata Koike > Filename : draft-ietf-soc-load-control-event-package-05.txt > Pages : 39 > Date : 2012-10-22 > > Abstract: > We define a load control event package for the Session Initiation > Protocol (SIP). It allows SIP servers to distribute load filters to > other SIP servers in the network. The load filters contain rules to > throttle calls based on their source or destination domain, telephone > number prefix or for a specific user. The mechanism helps to prevent > signaling overload and complements feedback-based SIP overload > control efforts. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-soc-load-control-event-packag= e > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-soc-load-control-event-package-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-soc-load-control-event-pack= age-05 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload > > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete > altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges > that have been modified, changed or falsified. > Thank you. > From vkg@bell-labs.com Thu Jan 3 08:42:07 2013 Return-Path: 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 CCEB321F8CD0 for ; Thu, 3 Jan 2013 08:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.362 X-Spam-Level: X-Spam-Status: No, score=-109.362 tagged_above=-999 required=5 tests=[AWL=1.237, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 140OqxOU2H4f for ; Thu, 3 Jan 2013 08:42:07 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 44BD421F8CA7 for ; Thu, 3 Jan 2013 08:42:02 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r03GfTUH012274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 3 Jan 2013 10:41:29 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r03GfTRv009563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Jan 2013 10:41:29 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r03GfPhC008225; Thu, 3 Jan 2013 10:41:25 -0600 (CST) Message-ID: <50E5B529.2090105@bell-labs.com> Date: Thu, 03 Jan 2013 10:43:21 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Charles Shen References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> <5EBD159DE88147488A3B1590E090018403530A9E6275@njfpsrvexg2.research.att.com> <24674_1355758104_50CF3A18_24674_468_1_88CAD1D4E8773F42858B58CAA28272A00E2A2C@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: "sip-overload@ietf.org" , Arata Koike , "NOEL, ERIC \(ERIC C\)" , Henning Schulzrinne Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 16:42:07 -0000 On 01/03/2013 07:34 AM, Charles Shen wrote: > Sounds good, I can update the wording in the event package draft, if > Vijay is OK with the other one. I just want to make sure we are all agreeing to the same thing. It seems to me that the question of using SHOULD versus MUST is being decided slightly in favour of a MUST. Martin and Bruno prefer a MUST, Janet is okay with, although her original text used a SHOULD; and Keith could go either way. Is the consensus, then, that the text on honoring local policy contains MUST? If so, the text to be inserted would be the following: A SIP client MUST honor any local policy for prioritizing SIP requests such as policies based on message type, e.g., INVITEs vs. requests associated with existing sessions. A SIP client MUST honor any local policy for prioritizing SIP requests based on the content of the Resource-Priority header (RPH, RFC4412 [RFC4412]). Specific (namespace.value) RPH contents may indicate high priority requests that should be preserved as much as possible during overload. The RPH contents can also indicate a low-priority request that is eligible to be dropped during times of overload. A SIP client MUST honor any local policy for prioritizing SIP requests relating to emergency calls, as identified by the SOS URN [RFC5031] indicating an emergency request. Yes? 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/ From bruno.chatras@orange.com Thu Jan 3 09:04:17 2013 Return-Path: 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 F34F721F86C8 for ; Thu, 3 Jan 2013 09:04:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[UNPARSEABLE_RELAY=0.001] 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 FN2rX5CbzIv2 for ; Thu, 3 Jan 2013 09:04:14 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id A2F7F21F8CDD for ; Thu, 3 Jan 2013 09:04:10 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 5C9D818C969; Thu, 3 Jan 2013 18:04:09 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 39F2E35C074; Thu, 3 Jan 2013 18:04:09 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Thu, 3 Jan 2013 18:04:08 +0100 From: To: "Vijay K. Gurbani" , Charles Shen Thread-Topic: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt Thread-Index: AQHN6dFH9RN0xEYj1kuD2bCFtlI55Zg31LRA Date: Thu, 3 Jan 2013 17:04:08 +0000 Message-ID: <30588_1357232649_50E5BA09_30588_276_1_88CAD1D4E8773F42858B58CAA28272A00EAFB1@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> <5EBD159DE88147488A3B1590E090018403530A9E6275@njfpsrvexg2.research.att.com> <24674_1355758104_50CF3A18_24674_468_1_88CAD1D4E8773F42858B58CAA28272A00E2A2C@PEXCVZYM12.corporate.adroot.infra.ftgroup> <50E5B529.2090105@bell-labs.com> In-Reply-To: <50E5B529.2090105@bell-labs.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.12.31.121227 Cc: "NOEL, ERIC \(ERIC C\)" , "sip-overload@ietf.org" , Arata Koike , Henning Schulzrinne Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 17:04:17 -0000 yes > -----Message d'origine----- > De=A0: sip-overload-bounces@ietf.org [mailto:sip-overload- > bounces@ietf.org] De la part de Vijay K. Gurbani > Envoy=E9=A0: jeudi 3 janvier 2013 17:43 > =C0=A0: Charles Shen > Cc=A0: sip-overload@ietf.org; Arata Koike; NOEL, ERIC (ERIC C); Henning > Schulzrinne > Objet=A0: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc- > load-control-event-package-05.txt >=20 > On 01/03/2013 07:34 AM, Charles Shen wrote: > > Sounds good, I can update the wording in the event package draft, if > > Vijay is OK with the other one. >=20 > I just want to make sure we are all agreeing to the same thing. >=20 > It seems to me that the question of using SHOULD versus MUST is being > decided slightly in favour of a MUST. Martin and Bruno prefer a MUST, > Janet is okay with, although her original text used a SHOULD; and Keith > could go either way. >=20 > Is the consensus, then, that the text on honoring local policy contains > MUST? If so, the text to be inserted would be the following: >=20 > A SIP client MUST honor any local policy for prioritizing SIP > requests such as policies based on message type, e.g., INVITEs vs. > requests associated with existing sessions. >=20 > A SIP client MUST honor any local policy for prioritizing SIP > requests based on the content of the Resource-Priority header (RPH, > RFC4412 [RFC4412]). Specific (namespace.value) RPH contents may > indicate high priority requests that should be preserved as much as > possible during overload. The RPH contents can also indicate a > low-priority request that is eligible to be dropped during times of > overload. >=20 > A SIP client MUST honor any local policy for prioritizing SIP > requests relating to emergency calls, as identified by the SOS > URN [RFC5031] indicating an emergency request. >=20 > Yes? >=20 > Thanks, >=20 > - 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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From jgunn6@csc.com Thu Jan 3 09:52:11 2013 Return-Path: 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 ECDEE21F868B for ; Thu, 3 Jan 2013 09:52:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[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 IpCKNYXbGyDh for ; Thu, 3 Jan 2013 09:52:10 -0800 (PST) Received: from mail87.messagelabs.com (mail87.messagelabs.com [216.82.250.19]) by ietfa.amsl.com (Postfix) with ESMTP id C11D921F8BED for ; Thu, 3 Jan 2013 09:52:10 -0800 (PST) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-16.tower-87.messagelabs.com!1357235529!15425676!1 X-Originating-IP: [20.137.2.88] X-StarScan-Received: X-StarScan-Version: 6.6.1.8; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3670 invoked from network); 3 Jan 2013 17:52:10 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-16.tower-87.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Jan 2013 17:52:10 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r03Hq4Jk018620; Thu, 3 Jan 2013 12:52:08 -0500 In-Reply-To: <50E5B529.2090105@bell-labs.com> References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> <5EBD159DE88147488A3B1590E090018403530A9E6275@njfpsrvexg2.research.att.com> <24674_1355758104_50CF3A18_24674_468_1_88CAD1D4E8773F42858B58CAA28272A00E2A2C@PEXCVZYM12.corporate.adroot.infra.ftgroup> <50E5B529.2090105@bell-labs.com> To: "Vijay K. Gurbani" MIME-Version: 1.0 X-KeepSent: 0589660E:64BDF257-85257AE8:006149FC; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Thu, 3 Jan 2013 12:52:05 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 01/03/2013 12:47:15 PM, Serialize complete at 01/03/2013 12:47:15 PM Content-Type: multipart/alternative; boundary="=_alternative 0062275C85257AE8_=" Cc: "sip-overload@ietf.org" , Arata Koike , "NOEL, ERIC \(ERIC C\)" , Charles Shen , Henning Schulzrinne Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 17:52:12 -0000 This is a multipart message in MIME format. --=_alternative 0062275C85257AE8_= Content-Type: text/plain; charset="US-ASCII" I prefer MUST to SHOULD. The original wording was based on Req 13 of RFC 5390: " REQ 13: The mechanism must not dictate a specific algorithm for prioritizing the processing of work within a proxy during times of overload. It must permit a proxy to prioritize requests based on any local policy, so that certain ones (such as a call for emergency services or a call with a specific value of the Resource-Priority header field [RFC4412]) are given preferential treatment, such as not being dropped, being given additional retransmission, or being processed ahead of others." which has a lower case "must". If we are going to say "MUST honor" (rather than "must permit"), I think we need to change "any" to "the" . (you can permit many alternatives, but you can really only honor one). I think this also reflects the intent of Martin's comment So I would prefer A SIP client MUST honor the local policy for prioritizing SIP requests such as policies based on message type, e.g., INVITEs vs. requests associated with existing sessions. A SIP client MUST honor the local policy for prioritizing SIP requests based on the content of the Resource-Priority header (RPH, RFC4412 [RFC4412]). Specific (namespace.value) RPH contents may indicate high priority requests that should be preserved as much as possible during overload. The RPH contents can also indicate a low-priority request that is eligible to be dropped during times of overload. A SIP client MUST honor the local policy for prioritizing SIP requests relating to emergency calls, as identified by the SOS URN [RFC5031] indicating an emergency request. Thanks Janet This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. From: "Vijay K. Gurbani" To: Charles Shen Cc: "DRAGE, Keith (Keith)" , Janet P Gunn/USA/CSC@CSC, "sip-overload@ietf.org" , Arata Koike , "NOEL, ERIC (ERIC C)" , Henning Schulzrinne Date: 01/03/2013 11:42 AM Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt On 01/03/2013 07:34 AM, Charles Shen wrote: > Sounds good, I can update the wording in the event package draft, if > Vijay is OK with the other one. I just want to make sure we are all agreeing to the same thing. It seems to me that the question of using SHOULD versus MUST is being decided slightly in favour of a MUST. Martin and Bruno prefer a MUST, Janet is okay with, although her original text used a SHOULD; and Keith could go either way. Is the consensus, then, that the text on honoring local policy contains MUST? If so, the text to be inserted would be the following: A SIP client MUST honor any local policy for prioritizing SIP requests such as policies based on message type, e.g., INVITEs vs. requests associated with existing sessions. A SIP client MUST honor any local policy for prioritizing SIP requests based on the content of the Resource-Priority header (RPH, RFC4412 [RFC4412]). Specific (namespace.value) RPH contents may indicate high priority requests that should be preserved as much as possible during overload. The RPH contents can also indicate a low-priority request that is eligible to be dropped during times of overload. A SIP client MUST honor any local policy for prioritizing SIP requests relating to emergency calls, as identified by the SOS URN [RFC5031] indicating an emergency request. Yes? 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/ --=_alternative 0062275C85257AE8_= Content-Type: text/html; charset="US-ASCII" I prefer MUST to SHOULD.

The original wording was based on Req 13 of RFC 5390:
" REQ 13:  The mechanism must not dictate a specific algorithm for
      prioritizing the processing of work within a proxy during times of
      overload.  It must permit a proxy to prioritize requests based on
      any local policy, so that certain ones (such as a call for
      emergency services or a call with a specific value of the
      Resource-Priority header field [RFC4412]) are given preferential
      treatment, such as not being dropped, being given additional
      retransmission, or being processed ahead of others."

which has a lower case "must".

If we are going to say "MUST honor" (rather than "must permit"), I think we need to change "any" to "the" . (you can permit many alternatives, but you can really only honor one).  I think this also reflects the intent of Martin's  comment

So I would prefer


  A SIP client MUST honor the local policy for prioritizing SIP
  requests such as policies based on message type, e.g., INVITEs vs.
  requests associated with existing sessions.

  A SIP client MUST honor the local policy for prioritizing SIP
  requests based on the content of the Resource-Priority header (RPH,
  RFC4412 [RFC4412]).  Specific (namespace.value) RPH contents may
  indicate high priority requests that should be preserved as much as
  possible during overload.  The RPH contents can also indicate a
  low-priority request that is eligible to be dropped during times of
  overload.

  A SIP client MUST honor the local policy for prioritizing SIP
  requests relating to emergency calls, as identified by the SOS
  URN [RFC5031] indicating an emergency request.


Thanks

Janet

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.



From:        "Vijay K. Gurbani" <vkg@bell-labs.com>
To:        Charles Shen <charles@cs.columbia.edu>
Cc:        "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>, Janet P Gunn/USA/CSC@CSC, "sip-overload@ietf.org" <sip-overload@ietf.org>, Arata Koike <koike.arata@lab.ntt.co.jp>, "NOEL, ERIC (ERIC C)" <ecnoel@att.com>, Henning Schulzrinne <hgs@cs.columbia.edu>
Date:        01/03/2013 11:42 AM
Subject:        Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt



On 01/03/2013 07:34 AM, Charles Shen wrote:
> Sounds good, I can update the wording in the event package draft, if
> Vijay is OK with the other one.

I just want to make sure we are all agreeing to the same thing.

It seems to me that the question of using SHOULD versus MUST is being
decided slightly in favour of a MUST.  Martin and Bruno prefer a MUST,
Janet is okay with, although her original text used a SHOULD; and Keith
could go either way.

Is the consensus, then, that the text on honoring local policy contains
MUST?  If so, the text to be inserted would be the following:

  A SIP client MUST honor any local policy for prioritizing SIP
  requests such as policies based on message type, e.g., INVITEs vs.
  requests associated with existing sessions.

  A SIP client MUST honor any local policy for prioritizing SIP
  requests based on the content of the Resource-Priority header (RPH,
  RFC4412 [RFC4412]).  Specific (namespace.value) RPH contents may
  indicate high priority requests that should be preserved as much as
  possible during overload.  The RPH contents can also indicate a
  low-priority request that is eligible to be dropped during times of
  overload.

  A SIP client MUST honor any local policy for prioritizing SIP
  requests relating to emergency calls, as identified by the SOS
  URN [RFC5031] indicating an emergency request.

Yes?

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/
--=_alternative 0062275C85257AE8_=-- From volker.hilt@bell-labs.com Fri Jan 11 06:07:22 2013 Return-Path: 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 2B6BF21F8581 for ; Fri, 11 Jan 2013 06:07:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.749 X-Spam-Level: X-Spam-Status: No, score=-9.749 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] 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 Z3hGFz1fewvg for ; Fri, 11 Jan 2013 06:07:21 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9D021F8570 for ; Fri, 11 Jan 2013 06:07:20 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r0BE6lV5024816 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 11 Jan 2013 15:07:18 +0100 Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 11 Jan 2013 15:07:03 +0100 Received: from [149.204.61.163] (135.5.27.17) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 11 Jan 2013 09:07:00 -0500 Message-ID: <50F01C82.9010406@bell-labs.com> Date: Fri, 11 Jan 2013 15:06:58 +0100 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> <5EBD159DE88147488A3B1590E090018403530A9E6275@njfpsrvexg2.research.att.com> <24674_1355758104_50CF3A18_24674_468_1_88CAD1D4E8773F42858B58CAA28272A00E2A2C@PEXCVZYM12.corporate.adroot.infra.ftgroup> <50E5B529.2090105@bell-labs.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.5.27.17] X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 14:07:22 -0000 Janet, All, while this sounds good in most cases, the concern I have is that there may be situation where a proxy is forced to violate local policy. E.g., a policy "emergency calls can never be dropped" will have to be violated eventually if overload reaches levels where only emergency calls are left. Maybe this boils down to formulating policies in a reasonable way. It has to be made clear, however, that not all policies call be kept under all circumstances. A SHOULD would imply this to the developer. With a MUST, I think one would have to add explanatory text. Thanks, Volker [with individual contributor hat on] On 03.01.2013 18:52, Janet P Gunn wrote: > I prefer MUST to SHOULD. > > The original wording was based on Req 13 of RFC 5390: > " REQ 13: The mechanism must not dictate a specific algorithm for > prioritizing the processing of work within a proxy during times of > overload*. It must permit a proxy to prioritize requests based on* > * any local policy*, so that certain ones (such as a call for > emergency services or a call with a specific value of the > Resource-Priority header field [RFC4412]) are given preferential > treatment, such as not being dropped, being given additional > retransmission, or being processed ahead of others." > > which has a lower case "must". > > If we are going to say "MUST honor" (rather than "must permit"), I think > we need to change "any" to "the" . (you can permit many alternatives, > but you can really only honor one). I think this also reflects the > intent of Martin's comment > > So I would prefer > > > A SIP client MUST honor *the *local policy for prioritizing SIP > requests such as policies based on message type, e.g., INVITEs vs. > requests associated with existing sessions. > > A SIP client MUST honor *the *local policy for prioritizing SIP > requests based on the content of the Resource-Priority header (RPH, > RFC4412 [RFC4412]). Specific (namespace.value) RPH contents may > indicate high priority requests that should be preserved as much as > possible during overload. The RPH contents can also indicate a > low-priority request that is eligible to be dropped during times of > overload. > > A SIP client MUST honor *the *local policy for prioritizing SIP > requests relating to emergency calls, as identified by the SOS > URN [RFC5031] indicating an emergency request. > > > Thanks > > Janet > > This is a PRIVATE message. If you are not the intended recipient, please > delete without copying and kindly advise us by e-mail of the mistake in > delivery. NOTE: Regardless of content, this e-mail shall not operate to > bind CSC to any order or other contract unless pursuant to explicit > written agreement or government initiative expressly permitting the use > of e-mail for such purpose. > > > > From: "Vijay K. Gurbani" > To: Charles Shen > Cc: "DRAGE, Keith (Keith)" , Janet P > Gunn/USA/CSC@CSC, "sip-overload@ietf.org" , Arata > Koike , "NOEL, ERIC (ERIC C)" > , Henning Schulzrinne > Date: 01/03/2013 11:42 AM > Subject: Re: [sip-overload] Local Policy Re: I-D Action: > draft-ietf-soc-load-control-event-package-05.txt > ------------------------------------------------------------------------ > > > > On 01/03/2013 07:34 AM, Charles Shen wrote: > > Sounds good, I can update the wording in the event package draft, if > > Vijay is OK with the other one. > > I just want to make sure we are all agreeing to the same thing. > > It seems to me that the question of using SHOULD versus MUST is being > decided slightly in favour of a MUST. Martin and Bruno prefer a MUST, > Janet is okay with, although her original text used a SHOULD; and Keith > could go either way. > > Is the consensus, then, that the text on honoring local policy contains > MUST? If so, the text to be inserted would be the following: > > A SIP client MUST honor any local policy for prioritizing SIP > requests such as policies based on message type, e.g., INVITEs vs. > requests associated with existing sessions. > > A SIP client MUST honor any local policy for prioritizing SIP > requests based on the content of the Resource-Priority header (RPH, > RFC4412 [RFC4412]). Specific (namespace.value) RPH contents may > indicate high priority requests that should be preserved as much as > possible during overload. The RPH contents can also indicate a > low-priority request that is eligible to be dropped during times of > overload. > > A SIP client MUST honor any local policy for prioritizing SIP > requests relating to emergency calls, as identified by the SOS > URN [RFC5031] indicating an emergency request. > > Yes? > > 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 > From jgunn6@csc.com Fri Jan 11 06:25:13 2013 Return-Path: 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 1C9FA21F8919; Fri, 11 Jan 2013 06:25:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.948 X-Spam-Level: X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[AWL=0.649, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 cIJsH---OJu0; Fri, 11 Jan 2013 06:25:10 -0800 (PST) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.250.242]) by ietfa.amsl.com (Postfix) with ESMTP id 5AAF421F8900; Fri, 11 Jan 2013 06:25:10 -0800 (PST) Received: from [216.82.250.19:28500] by server-4.bemta-12.messagelabs.com id DD/CE-30798-5C020F05; Fri, 11 Jan 2013 14:25:09 +0000 X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-13.tower-87.messagelabs.com!1357914306!13116690!1 X-Originating-IP: [20.137.2.88] X-StarScan-Received: X-StarScan-Version: 6.6.1.8; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25298 invoked from network); 11 Jan 2013 14:25:07 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-13.tower-87.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 Jan 2013 14:25:07 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r0BEP3lL020175; Fri, 11 Jan 2013 09:25:04 -0500 In-Reply-To: <50F01C82.9010406@bell-labs.com> References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> <5EBD159DE88147488A3B1590E090018403530A9E6275@njfpsrvexg2.research.att.com> <24674_1355758104_50CF3A18_24674_468_1_88CAD1D4E8773F42858B58CAA28272A00E2A2C@PEXCVZYM12.corporate.adroot.infra.ftgroup> <50E5B529.2090105@bell-labs.com> To: Volker Hilt MIME-Version: 1.0 X-KeepSent: 0CE71656:F6252012-85257AF0:004EB2E8; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Fri, 11 Jan 2013 09:25:01 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 01/11/2013 09:20:04 AM, Serialize complete at 01/11/2013 09:20:04 AM Content-Type: multipart/alternative; boundary="=_alternative 004F321185257AF0_=" Cc: sip-overload-bounces@ietf.org, sip-overload@ietf.org Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 14:25:13 -0000 This is a multipart message in MIME format. --=_alternative 004F321185257AF0_= Content-Type: text/plain; charset="US-ASCII" Good point If you say it MUST honor "local policy", then you need constraints on what the local policy can do (e.g., it can only prioritize within the number of messages permitted by the overload algorithm, it can't over ride the overload mechanism/algorithm) Janet sip-overload-bounces@ietf.org wrote on 01/11/2013 09:06:58 AM: > From: Volker Hilt > To: > Date: 01/11/2013 09:07 AM > Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf- > soc-load-control-event-package-05.txt > Sent by: sip-overload-bounces@ietf.org > > Janet, All, > > while this sounds good in most cases, the concern I have is that there > may be situation where a proxy is forced to violate local policy. E.g., > a policy "emergency calls can never be dropped" will have to be violated > eventually if overload reaches levels where only emergency calls are left. > > Maybe this boils down to formulating policies in a reasonable way. It > has to be made clear, however, that not all policies call be kept under > all circumstances. > > A SHOULD would imply this to the developer. With a MUST, I think one > would have to add explanatory text. > > Thanks, > > Volker [with individual contributor hat on] > > > > On 03.01.2013 18:52, Janet P Gunn wrote: > > I prefer MUST to SHOULD. > > > > The original wording was based on Req 13 of RFC 5390: > > " REQ 13: The mechanism must not dictate a specific algorithm for > > prioritizing the processing of work within a proxy during times of > > overload*. It must permit a proxy to prioritize requests based on* > > * any local policy*, so that certain ones (such as a call for > > emergency services or a call with a specific value of the > > Resource-Priority header field [RFC4412]) are given preferential > > treatment, such as not being dropped, being given additional > > retransmission, or being processed ahead of others." > > > > which has a lower case "must". > > > > If we are going to say "MUST honor" (rather than "must permit"), I think > > we need to change "any" to "the" . (you can permit many alternatives, > > but you can really only honor one). I think this also reflects the > > intent of Martin's comment > > > > So I would prefer > > > > > > A SIP client MUST honor *the *local policy for prioritizing SIP > > requests such as policies based on message type, e.g., INVITEs vs. > > requests associated with existing sessions. > > > > A SIP client MUST honor *the *local policy for prioritizing SIP > > requests based on the content of the Resource-Priority header (RPH, > > RFC4412 [RFC4412]). Specific (namespace.value) RPH contents may > > indicate high priority requests that should be preserved as much as > > possible during overload. The RPH contents can also indicate a > > low-priority request that is eligible to be dropped during times of > > overload. > > > > A SIP client MUST honor *the *local policy for prioritizing SIP > > requests relating to emergency calls, as identified by the SOS > > URN [RFC5031] indicating an emergency request. > > > > > > Thanks > > > > Janet > > > > This is a PRIVATE message. If you are not the intended recipient, please > > delete without copying and kindly advise us by e-mail of the mistake in > > delivery. NOTE: Regardless of content, this e-mail shall not operate to > > bind CSC to any order or other contract unless pursuant to explicit > > written agreement or government initiative expressly permitting the use > > of e-mail for such purpose. > > > > > > > > From: "Vijay K. Gurbani" > > To: Charles Shen > > Cc: "DRAGE, Keith (Keith)" , Janet P > > Gunn/USA/CSC@CSC, "sip-overload@ietf.org" , Arata > > Koike , "NOEL, ERIC (ERIC C)" > > , Henning Schulzrinne > > Date: 01/03/2013 11:42 AM > > Subject: Re: [sip-overload] Local Policy Re: I-D Action: > > draft-ietf-soc-load-control-event-package-05.txt > > ------------------------------------------------------------------------ > > > > > > > > On 01/03/2013 07:34 AM, Charles Shen wrote: > > > Sounds good, I can update the wording in the event package draft, if > > > Vijay is OK with the other one. > > > > I just want to make sure we are all agreeing to the same thing. > > > > It seems to me that the question of using SHOULD versus MUST is being > > decided slightly in favour of a MUST. Martin and Bruno prefer a MUST, > > Janet is okay with, although her original text used a SHOULD; and Keith > > could go either way. > > > > Is the consensus, then, that the text on honoring local policy contains > > MUST? If so, the text to be inserted would be the following: > > > > A SIP client MUST honor any local policy for prioritizing SIP > > requests such as policies based on message type, e.g., INVITEs vs. > > requests associated with existing sessions. > > > > A SIP client MUST honor any local policy for prioritizing SIP > > requests based on the content of the Resource-Priority header (RPH, > > RFC4412 [RFC4412]). Specific (namespace.value) RPH contents may > > indicate high priority requests that should be preserved as much as > > possible during overload. The RPH contents can also indicate a > > low-priority request that is eligible to be dropped during times of > > overload. > > > > A SIP client MUST honor any local policy for prioritizing SIP > > requests relating to emergency calls, as identified by the SOS > > URN [RFC5031] indicating an emergency request. > > > > Yes? > > > > 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 > > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload --=_alternative 004F321185257AF0_= Content-Type: text/html; charset="US-ASCII"
Good point

If you say it MUST honor "local policy", then you  need  constraints on what the local policy can do (e.g., it can only prioritize within the number of messages permitted by the overload algorithm, it can't over ride the overload mechanism/algorithm)

Janet



sip-overload-bounces@ietf.org wrote on 01/11/2013 09:06:58 AM:

> From: Volker Hilt <volker.hilt@bell-labs.com>
> To: <sip-overload@ietf.org>
> Date: 01/11/2013 09:07 AM
> Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-
> soc-load-control-event-package-05.txt
> Sent by: sip-overload-bounces@ietf.org
>
> Janet, All,
>
> while this sounds good in most cases, the concern I have is that there
> may be situation where a proxy is forced to violate local policy. E.g.,
> a policy "emergency calls can never be dropped" will have to be violated
> eventually if overload reaches levels where only emergency calls are left.
>
> Maybe this boils down to formulating policies in a reasonable way. It
> has to be made clear, however, that not all policies call be kept under
> all circumstances.
>
> A SHOULD would imply this to the developer. With a MUST, I think one
> would have to add explanatory text.
>
> Thanks,
>
> Volker [with individual contributor hat on]
>
>
>
> On 03.01.2013 18:52, Janet P Gunn wrote:
> > I prefer MUST to SHOULD.
> >
> > The original wording was based on Req 13 of RFC 5390:
> > " REQ 13:  The mechanism must not dictate a specific algorithm for
> >        prioritizing the processing of work within a proxy during times of
> >        overload*.  It must permit a proxy to prioritize requests based on*
> > *      any local policy*, so that certain ones (such as a call for
> >        emergency services or a call with a specific value of the
> >        Resource-Priority header field [RFC4412]) are given preferential
> >        treatment, such as not being dropped, being given additional
> >        retransmission, or being processed ahead of others."
> >
> > which has a lower case "must".
> >
> > If we are going to say "MUST honor" (rather than "must permit"), I think
> > we need to change "any" to "the" . (you can permit many alternatives,
> > but you can really only honor one).  I think this also reflects the
> > intent of Martin's  comment
> >
> > So I would prefer
> >
> >
> >    A SIP client MUST honor *the *local policy for prioritizing SIP
> >    requests such as policies based on message type, e.g., INVITEs vs.
> >    requests associated with existing sessions.
> >
> >    A SIP client MUST honor *the *local policy for prioritizing SIP
> >    requests based on the content of the Resource-Priority header (RPH,
> >    RFC4412 [RFC4412]).  Specific (namespace.value) RPH contents may
> >    indicate high priority requests that should be preserved as much as
> >    possible during overload.  The RPH contents can also indicate a
> >    low-priority request that is eligible to be dropped during times of
> >    overload.
> >
> >    A SIP client MUST honor *the *local policy for prioritizing SIP
> >    requests relating to emergency calls, as identified by the SOS
> >    URN [RFC5031] indicating an emergency request.
> >
> >
> > Thanks
> >
> > Janet
> >
> > This is a PRIVATE message. If you are not the intended recipient, please
> > delete without copying and kindly advise us by e-mail of the mistake in
> > delivery. NOTE: Regardless of content, this e-mail shall not operate to
> > bind CSC to any order or other contract unless pursuant to explicit
> > written agreement or government initiative expressly permitting the use
> > of e-mail for such purpose.
> >
> >
> >
> > From: "Vijay K. Gurbani" <vkg@bell-labs.com>
> > To: Charles Shen <charles@cs.columbia.edu>
> > Cc: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>, Janet P
> > Gunn/USA/CSC@CSC, "sip-overload@ietf.org" <sip-overload@ietf.org>, Arata
> > Koike <koike.arata@lab.ntt.co.jp>, "NOEL, ERIC (ERIC C)"
> > <ecnoel@att.com>, Henning Schulzrinne <hgs@cs.columbia.edu>
> > Date: 01/03/2013 11:42 AM
> > Subject: Re: [sip-overload] Local Policy Re: I-D Action:
> > draft-ietf-soc-load-control-event-package-05.txt
> > ------------------------------------------------------------------------
> >
> >
> >
> > On 01/03/2013 07:34 AM, Charles Shen wrote:
> >  > Sounds good, I can update the wording in the event package draft, if
> >  > Vijay is OK with the other one.
> >
> > I just want to make sure we are all agreeing to the same thing.
> >
> > It seems to me that the question of using SHOULD versus MUST is being
> > decided slightly in favour of a MUST.  Martin and Bruno prefer a MUST,
> > Janet is okay with, although her original text used a SHOULD; and Keith
> > could go either way.
> >
> > Is the consensus, then, that the text on honoring local policy contains
> > MUST?  If so, the text to be inserted would be the following:
> >
> >    A SIP client MUST honor any local policy for prioritizing SIP
> >    requests such as policies based on message type, e.g., INVITEs vs.
> >    requests associated with existing sessions.
> >
> >    A SIP client MUST honor any local policy for prioritizing SIP
> >    requests based on the content of the Resource-Priority header (RPH,
> >    RFC4412 [RFC4412]).  Specific (namespace.value) RPH contents may
> >    indicate high priority requests that should be preserved as much as
> >    possible during overload.  The RPH contents can also indicate a
> >    low-priority request that is eligible to be dropped during times of
> >    overload.
> >
> >    A SIP client MUST honor any local policy for prioritizing SIP
> >    requests relating to emergency calls, as identified by the SOS
> >    URN [RFC5031] indicating an emergency request.
> >
> > Yes?
> >
> > 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
> >
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload
 --=_alternative 004F321185257AF0_=-- From salvatore.loreto@ericsson.com Mon Jan 14 04:56:32 2013 Return-Path: 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 85B3321F854D for ; Mon, 14 Jan 2013 04:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.248 X-Spam-Level: X-Spam-Status: No, score=-106.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 E-QEptRfjEDH for ; Mon, 14 Jan 2013 04:56:30 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDF921F84FC for ; Mon, 14 Jan 2013 04:56:29 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-a4-50f4007c447a Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id B4.B8.32353.C7004F05; Mon, 14 Jan 2013 13:56:28 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Mon, 14 Jan 2013 13:56:28 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1D4B32454 for ; Mon, 14 Jan 2013 14:56:28 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9AD4E53888 for ; Mon, 14 Jan 2013 14:56:26 +0200 (EET) Received: from n94.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 51EBB51DA6 for ; Mon, 14 Jan 2013 14:56:26 +0200 (EET) Message-ID: <50F4007B.5050903@ericsson.com> Date: Mon, 14 Jan 2013 14:56:27 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: sip-overload@ietf.org References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> <5EBD159DE88147488A3B1590E090018403530A9E6275@njfpsrvexg2.research.att.com> <24674_1355758104_50CF3A18_24674_468_1_88CAD1D4E8773F42858B58CAA28272A00E2A2C@PEXCVZYM12.corporate.adroot.infra.ftgroup> <50E5B529.2090105@bell-labs.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020202040603020608090505" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNLMWRmVeSWpSXmKPExsUyM+JvjW4Nw5cAg6sN5hb7nyY4MHosWfKT KYAxissmJTUnsyy1SN8ugStj5cGnrAUNmxgrbl1dwtTA+KqBsYuRk0NCwESitfMgC4QtJnHh 3nq2LkYuDiGBk4wS7W+esEA4GxglNhw5wgrhXGOU+NZ9AqHsZdNfZgjnIKPErL2dzCDDeAW0 JWYfWwFUxcHBIqAqcb43HiTMJmAm8fzhFrASUYFkiY93rrFClAtKnJz5BOwOEQFJiS/PJ4Ld JyyQKfF8+wVGiPmn2CT+tZ8Ga+AUCJD4+aodbBCzQJjE6j3zoZ5Qk7h6bhNYXEhAS6L3bCfT BEbhWUh2zELSAmHbSlyYcx3KlpfY/nYOM4StK3Hh/xQU8QWMbKsY2XMTM3PSy803MQIj4OCW 3wY7GDfdFzvEKM3BoiTOG+56IUBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY+XZGWu/JfXI 9MuXnz4Ves10mcqthP3lJ752th2MM3+lsLpL8m5YNqeEcv/hs+vsNy5Yo8Ep9u1Z6aIW3svN 33adV1t6uzRx4Yr9WepbpR5u9t0qIbFwTf3CmCdCF1YsvljV9v79265bP39eTJb8Kao1I2rD xut1h5sOTHVMm+jO1F34/1SaqYkSS3FGoqEWc1FxIgBDcO1DTgIAAA== Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 12:56:32 -0000 --------------020202040603020608090505 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit my reading of the mailing list is that the question of using SHOULD versus MUST is being decided in favor of MUST however it would be great to also address the Valker concerns inserting a caveat/constraints explaining that the local policy can not override the overload mechanism/algorithm can someone propose text ? note this is the only remaining issue that we have to address in this event-package draft before we can ship to the IESG /Salvatore On 1/11/13 4:25 PM, Janet P Gunn wrote: > > Good point > > If you say it MUST honor "local policy", then you need constraints > on what the local policy can do (e.g., it can only prioritize within > the number of messages permitted by the overload algorithm, it can't > over ride the overload mechanism/algorithm) > > Janet > > > > sip-overload-bounces@ietf.org wrote on 01/11/2013 09:06:58 AM: > > > From: Volker Hilt > > To: > > Date: 01/11/2013 09:07 AM > > Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf- > > soc-load-control-event-package-05.txt > > Sent by: sip-overload-bounces@ietf.org > > > > Janet, All, > > > > while this sounds good in most cases, the concern I have is that there > > may be situation where a proxy is forced to violate local policy. E.g., > > a policy "emergency calls can never be dropped" will have to be > violated > > eventually if overload reaches levels where only emergency calls are > left. > > > > Maybe this boils down to formulating policies in a reasonable way. It > > has to be made clear, however, that not all policies call be kept under > > all circumstances. > > > > A SHOULD would imply this to the developer. With a MUST, I think one > > would have to add explanatory text. > > > > Thanks, > > > > Volker [with individual contributor hat on] > > > > > > > > On 03.01.2013 18:52, Janet P Gunn wrote: > > > I prefer MUST to SHOULD. > > > > > > The original wording was based on Req 13 of RFC 5390: > > > " REQ 13: The mechanism must not dictate a specific algorithm for > > > prioritizing the processing of work within a proxy during > times of > > > overload*. It must permit a proxy to prioritize requests > based on* > > > * any local policy*, so that certain ones (such as a call for > > > emergency services or a call with a specific value of the > > > Resource-Priority header field [RFC4412]) are given > preferential > > > treatment, such as not being dropped, being given additional > > > retransmission, or being processed ahead of others." > > > > > > which has a lower case "must". > > > > > > If we are going to say "MUST honor" (rather than "must permit"), I > think > > > we need to change "any" to "the" . (you can permit many alternatives, > > > but you can really only honor one). I think this also reflects the > > > intent of Martin's comment > > > > > > So I would prefer > > > > > > > > > A SIP client MUST honor *the *local policy for prioritizing SIP > > > requests such as policies based on message type, e.g., INVITEs vs. > > > requests associated with existing sessions. > > > > > > A SIP client MUST honor *the *local policy for prioritizing SIP > > > requests based on the content of the Resource-Priority header (RPH, > > > RFC4412 [RFC4412]). Specific (namespace.value) RPH contents may > > > indicate high priority requests that should be preserved as much as > > > possible during overload. The RPH contents can also indicate a > > > low-priority request that is eligible to be dropped during times of > > > overload. > > > > > > A SIP client MUST honor *the *local policy for prioritizing SIP > > > requests relating to emergency calls, as identified by the SOS > > > URN [RFC5031] indicating an emergency request. > > > > > > > > > Thanks > > > > > > Janet > > > > > > This is a PRIVATE message. If you are not the intended recipient, > please > > > delete without copying and kindly advise us by e-mail of the > mistake in > > > delivery. NOTE: Regardless of content, this e-mail shall not > operate to > > > bind CSC to any order or other contract unless pursuant to explicit > > > written agreement or government initiative expressly permitting > the use > > > of e-mail for such purpose. > > > > > > > > > > > > From: "Vijay K. Gurbani" > > > To: Charles Shen > > > Cc: "DRAGE, Keith (Keith)" , Janet P > > > Gunn/USA/CSC@CSC, "sip-overload@ietf.org" , > Arata > > > Koike , "NOEL, ERIC (ERIC C)" > > > , Henning Schulzrinne > > > Date: 01/03/2013 11:42 AM > > > Subject: Re: [sip-overload] Local Policy Re: I-D Action: > > > draft-ietf-soc-load-control-event-package-05.txt > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > On 01/03/2013 07:34 AM, Charles Shen wrote: > > > > Sounds good, I can update the wording in the event package > draft, if > > > > Vijay is OK with the other one. > > > > > > I just want to make sure we are all agreeing to the same thing. > > > > > > It seems to me that the question of using SHOULD versus MUST is being > > > decided slightly in favour of a MUST. Martin and Bruno prefer a MUST, > > > Janet is okay with, although her original text used a SHOULD; and > Keith > > > could go either way. > > > > > > Is the consensus, then, that the text on honoring local policy > contains > > > MUST? If so, the text to be inserted would be the following: > > > > > > A SIP client MUST honor any local policy for prioritizing SIP > > > requests such as policies based on message type, e.g., INVITEs vs. > > > requests associated with existing sessions. > > > > > > A SIP client MUST honor any local policy for prioritizing SIP > > > requests based on the content of the Resource-Priority header (RPH, > > > RFC4412 [RFC4412]). Specific (namespace.value) RPH contents may > > > indicate high priority requests that should be preserved as much as > > > possible during overload. The RPH contents can also indicate a > > > low-priority request that is eligible to be dropped during times of > > > overload. > > > > > > A SIP client MUST honor any local policy for prioritizing SIP > > > requests relating to emergency calls, as identified by the SOS > > > URN [RFC5031] indicating an emergency request. > > > > > > Yes? > > > > > > 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 > > > > > _______________________________________________ > > sip-overload mailing list > > sip-overload@ietf.org > > https://www.ietf.org/mailman/listinfo/sip-overload > > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload -- Salvatore Loreto, PhD www.sloreto.com --------------020202040603020608090505 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
my reading of the mailing list is that the question of using SHOULD versus MUST
is being decided in favor of MUST

however it would be great to also address the Valker concerns
inserting a caveat/constraints explaining that the local policy can not
override the overload mechanism/algorithm

can someone propose text ?

note this is the only remaining issue that we have to address in this event-package draft
before we can ship to the IESG

/Salvatore


On 1/11/13 4:25 PM, Janet P Gunn wrote:

Good point

If you say it MUST honor "local policy", then you  need  constraints on what the local policy can do (e.g., it can only prioritize within the number of messages permitted by the overload algorithm, it can't over ride the overload mechanism/algorithm)

Janet



sip-overload-bounces@ietf.org wrote on 01/11/2013 09:06:58 AM:

> From: Volker Hilt <volker.hilt@bell-labs.com>
> To: <sip-overload@ietf.org>
> Date: 01/11/2013 09:07 AM
> Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-
> soc-load-control-event-package-05.txt
> Sent by: sip-overload-bounces@ietf.org
>
> Janet, All,
>
> while this sounds good in most cases, the concern I have is that there
> may be situation where a proxy is forced to violate local policy. E.g.,
> a policy "emergency calls can never be dropped" will have to be violated
> eventually if overload reaches levels where only emergency calls are left.
>
> Maybe this boils down to formulating policies in a reasonable way. It
> has to be made clear, however, that not all policies call be kept under
> all circumstances.
>
> A SHOULD would imply this to the developer. With a MUST, I think one
> would have to add explanatory text.
>
> Thanks,
>
> Volker [with individual contributor hat on]
>
>
>
> On 03.01.2013 18:52, Janet P Gunn wrote:
> > I prefer MUST to SHOULD.
> >
> > The original wording was based on Req 13 of RFC 5390:
> > " REQ 13:  The mechanism must not dictate a specific algorithm for
> >        prioritizing the processing of work within a proxy during times of
> >        overload*.  It must permit a proxy to prioritize requests based on*
> > *      any local policy*, so that certain ones (such as a call for
> >        emergency services or a call with a specific value of the
> >        Resource-Priority header field [RFC4412]) are given preferential
> >        treatment, such as not being dropped, being given additional
> >        retransmission, or being processed ahead of others."
> >
> > which has a lower case "must".
> >
> > If we are going to say "MUST honor" (rather than "must permit"), I think
> > we need to change "any" to "the" . (you can permit many alternatives,
> > but you can really only honor one).  I think this also reflects the
> > intent of Martin's  comment
> >
> > So I would prefer
> >
> >
> >    A SIP client MUST honor *the *local policy for prioritizing SIP
> >    requests such as policies based on message type, e.g., INVITEs vs.
> >    requests associated with existing sessions.
> >
> >    A SIP client MUST honor *the *local policy for prioritizing SIP
> >    requests based on the content of the Resource-Priority header (RPH,
> >    RFC4412 [RFC4412]).  Specific (namespace.value) RPH contents may
> >    indicate high priority requests that should be preserved as much as
> >    possible during overload.  The RPH contents can also indicate a
> >    low-priority request that is eligible to be dropped during times of
> >    overload.
> >
> >    A SIP client MUST honor *the *local policy for prioritizing SIP
> >    requests relating to emergency calls, as identified by the SOS
> >    URN [RFC5031] indicating an emergency request.
> >
> >
> > Thanks
> >
> > Janet
> >
> > This is a PRIVATE message. If you are not the intended recipient, please
> > delete without copying and kindly advise us by e-mail of the mistake in
> > delivery. NOTE: Regardless of content, this e-mail shall not operate to
> > bind CSC to any order or other contract unless pursuant to explicit
> > written agreement or government initiative expressly permitting the use
> > of e-mail for such purpose.
> >
> >
> >
> > From: "Vijay K. Gurbani" <vkg@bell-labs.com>
> > To: Charles Shen <charles@cs.columbia.edu>
> > Cc: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>, Janet P
> > Gunn/USA/CSC@CSC, "sip-overload@ietf.org" <sip-overload@ietf.org>, Arata
> > Koike <koike.arata@lab.ntt.co.jp>, "NOEL, ERIC (ERIC C)"
> > <ecnoel@att.com>, Henning Schulzrinne <hgs@cs.columbia.edu>
> > Date: 01/03/2013 11:42 AM
> > Subject: Re: [sip-overload] Local Policy Re: I-D Action:
> > draft-ietf-soc-load-control-event-package-05.txt
> > ------------------------------------------------------------------------
> >
> >
> >
> > On 01/03/2013 07:34 AM, Charles Shen wrote:
> >  > Sounds good, I can update the wording in the event package draft, if
> >  > Vijay is OK with the other one.
> >
> > I just want to make sure we are all agreeing to the same thing.
> >
> > It seems to me that the question of using SHOULD versus MUST is being
> > decided slightly in favour of a MUST.  Martin and Bruno prefer a MUST,
> > Janet is okay with, although her original text used a SHOULD; and Keith
> > could go either way.
> >
> > Is the consensus, then, that the text on honoring local policy contains
> > MUST?  If so, the text to be inserted would be the following:
> >
> >    A SIP client MUST honor any local policy for prioritizing SIP
> >    requests such as policies based on message type, e.g., INVITEs vs.
> >    requests associated with existing sessions.
> >
> >    A SIP client MUST honor any local policy for prioritizing SIP
> >    requests based on the content of the Resource-Priority header (RPH,
> >    RFC4412 [RFC4412]).  Specific (namespace.value) RPH contents may
> >    indicate high priority requests that should be preserved as much as
> >    possible during overload.  The RPH contents can also indicate a
> >    low-priority request that is eligible to be dropped during times of
> >    overload.
> >
> >    A SIP client MUST honor any local policy for prioritizing SIP
> >    requests relating to emergency calls, as identified by the SOS
> >    URN [RFC5031] indicating an emergency request.
> >
> > Yes?
> >
> > 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
> >
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload
 

_______________________________________________
sip-overload mailing list
sip-overload@ietf.org
https://www.ietf.org/mailman/listinfo/sip-overload



-- 
Salvatore Loreto, PhD
www.sloreto.com
--------------020202040603020608090505-- From volker.hilt@bell-labs.com Mon Jan 14 06:22:03 2013 Return-Path: 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 3513621F88EE for ; Mon, 14 Jan 2013 06:22:03 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WU8bjVGQJr-S for ; Mon, 14 Jan 2013 06:22:01 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 4046821F88EA for ; Mon, 14 Jan 2013 06:22:00 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r0EELjOp024048 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 14 Jan 2013 15:21:58 +0100 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 14 Jan 2013 15:21:43 +0100 Received: from [135.244.178.1] (135.239.27.12) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 14 Jan 2013 15:21:43 +0100 Message-ID: <50F4146E.1080308@bell-labs.com> Date: Mon, 14 Jan 2013 15:21:34 +0100 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> <5EBD159DE88147488A3B1590E090018403530A9E6275@njfpsrvexg2.research.att.com> <24674_1355758104_50CF3A18_24674_468_1_88CAD1D4E8773F42858B58CAA28272A00E2A2C@PEXCVZYM12.corporate.adroot.infra.ftgroup> <50E5B529.2090105@bell-labs.com> <50F4007B.5050903@ericsson.com> In-Reply-To: <50F4007B.5050903@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.12] X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 14:22:03 -0000 I think SHOULD would, in fact, be the more appropriate wording here. There may be reasons why a local policy cannot be kept: a conflict with another policy, legal requirements, or very high levels of overload. In the end, the local policy will be a local matter including its enforcement. In other words, if a service provider has a SIP server that ignores his policies, I'm sure the service provide will know who to call. I've added a short explanatory sentence to the first paragraph: A SIP client SHOULD honor the local policy for prioritizing SIP requests such as policies based on message type, e.g., INVITEs vs. requests associated with existing sessions. A SIP client is expected generally to honor local policy except for very rare occasions when, for example, overload is so severe that messages, which should be preserved according to local policy, need to be discarded or local policies are in conflict. A SIP client SHOULD honor the local policy for prioritizing SIP requests based on the content of the Resource-Priority header (RPH, RFC4412 [RFC4412]). Specific (namespace.value) RPH contents may indicate high priority requests that should be preserved as much as possible during overload. The RPH contents can also indicate a low-priority request that is eligible to be dropped during times of overload. A SIP client SHOULD honor the local policy for prioritizing SIP requests relating to emergency calls, as identified by the SOS URN [RFC5031] indicating an emergency request. Thanks, Volker [as individual] On 14.01.2013 13:56, Salvatore Loreto wrote: > my reading of the mailing list is that the question of using SHOULD > versus MUST > is being decided in favor of MUST > > however it would be great to also address the Valker concerns > inserting a caveat/constraints explaining that the local policy can not > override the overload mechanism/algorithm > > can someone propose text ? > > note this is the only remaining issue that we have to address in this > event-package draft > before we can ship to the IESG > > /Salvatore > > > On 1/11/13 4:25 PM, Janet P Gunn wrote: >> >> Good point >> >> If you say it MUST honor "local policy", then you need constraints >> on what the local policy can do (e.g., it can only prioritize within >> the number of messages permitted by the overload algorithm, it can't >> over ride the overload mechanism/algorithm) >> >> Janet >> >> >> >> sip-overload-bounces@ietf.org wrote on 01/11/2013 09:06:58 AM: >> >> > From: Volker Hilt >> > To: >> > Date: 01/11/2013 09:07 AM >> > Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf- >> > soc-load-control-event-package-05.txt >> > Sent by: sip-overload-bounces@ietf.org >> > >> > Janet, All, >> > >> > while this sounds good in most cases, the concern I have is that there >> > may be situation where a proxy is forced to violate local policy. E.g., >> > a policy "emergency calls can never be dropped" will have to be >> violated >> > eventually if overload reaches levels where only emergency calls are >> left. >> > >> > Maybe this boils down to formulating policies in a reasonable way. It >> > has to be made clear, however, that not all policies call be kept under >> > all circumstances. >> > >> > A SHOULD would imply this to the developer. With a MUST, I think one >> > would have to add explanatory text. >> > >> > Thanks, >> > >> > Volker [with individual contributor hat on] >> > >> > >> > >> > On 03.01.2013 18:52, Janet P Gunn wrote: >> > > I prefer MUST to SHOULD. >> > > >> > > The original wording was based on Req 13 of RFC 5390: >> > > " REQ 13: The mechanism must not dictate a specific algorithm for >> > > prioritizing the processing of work within a proxy during >> times of >> > > overload*. It must permit a proxy to prioritize requests >> based on* >> > > * any local policy*, so that certain ones (such as a call for >> > > emergency services or a call with a specific value of the >> > > Resource-Priority header field [RFC4412]) are given >> preferential >> > > treatment, such as not being dropped, being given additional >> > > retransmission, or being processed ahead of others." >> > > >> > > which has a lower case "must". >> > > >> > > If we are going to say "MUST honor" (rather than "must permit"), I >> think >> > > we need to change "any" to "the" . (you can permit many alternatives, >> > > but you can really only honor one). I think this also reflects the >> > > intent of Martin's comment >> > > >> > > So I would prefer >> > > >> > > >> > > A SIP client MUST honor *the *local policy for prioritizing SIP >> > > requests such as policies based on message type, e.g., INVITEs vs. >> > > requests associated with existing sessions. >> > > >> > > A SIP client MUST honor *the *local policy for prioritizing SIP >> > > requests based on the content of the Resource-Priority header (RPH, >> > > RFC4412 [RFC4412]). Specific (namespace.value) RPH contents may >> > > indicate high priority requests that should be preserved as much as >> > > possible during overload. The RPH contents can also indicate a >> > > low-priority request that is eligible to be dropped during times of >> > > overload. >> > > >> > > A SIP client MUST honor *the *local policy for prioritizing SIP >> > > requests relating to emergency calls, as identified by the SOS >> > > URN [RFC5031] indicating an emergency request. >> > > >> > > >> > > Thanks >> > > >> > > Janet >> > > >> > > This is a PRIVATE message. If you are not the intended recipient, >> please >> > > delete without copying and kindly advise us by e-mail of the >> mistake in >> > > delivery. NOTE: Regardless of content, this e-mail shall not >> operate to >> > > bind CSC to any order or other contract unless pursuant to explicit >> > > written agreement or government initiative expressly permitting >> the use >> > > of e-mail for such purpose. >> > > >> > > >> > > >> > > From: "Vijay K. Gurbani" >> > > To: Charles Shen >> > > Cc: "DRAGE, Keith (Keith)" , Janet P >> > > Gunn/USA/CSC@CSC, "sip-overload@ietf.org" , >> Arata >> > > Koike , "NOEL, ERIC (ERIC C)" >> > > , Henning Schulzrinne >> > > Date: 01/03/2013 11:42 AM >> > > Subject: Re: [sip-overload] Local Policy Re: I-D Action: >> > > draft-ietf-soc-load-control-event-package-05.txt >> > > >> ------------------------------------------------------------------------ >> > > >> > > >> > > >> > > On 01/03/2013 07:34 AM, Charles Shen wrote: >> > > > Sounds good, I can update the wording in the event package >> draft, if >> > > > Vijay is OK with the other one. >> > > >> > > I just want to make sure we are all agreeing to the same thing. >> > > >> > > It seems to me that the question of using SHOULD versus MUST is being >> > > decided slightly in favour of a MUST. Martin and Bruno prefer a MUST, >> > > Janet is okay with, although her original text used a SHOULD; and >> Keith >> > > could go either way. >> > > >> > > Is the consensus, then, that the text on honoring local policy >> contains >> > > MUST? If so, the text to be inserted would be the following: >> > > >> > > A SIP client MUST honor any local policy for prioritizing SIP >> > > requests such as policies based on message type, e.g., INVITEs vs. >> > > requests associated with existing sessions. >> > > >> > > A SIP client MUST honor any local policy for prioritizing SIP >> > > requests based on the content of the Resource-Priority header (RPH, >> > > RFC4412 [RFC4412]). Specific (namespace.value) RPH contents may >> > > indicate high priority requests that should be preserved as much as >> > > possible during overload. The RPH contents can also indicate a >> > > low-priority request that is eligible to be dropped during times of >> > > overload. >> > > >> > > A SIP client MUST honor any local policy for prioritizing SIP >> > > requests relating to emergency calls, as identified by the SOS >> > > URN [RFC5031] indicating an emergency request. >> > > >> > > Yes? >> > > >> > > 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 >> > > >> > _______________________________________________ >> > sip-overload mailing list >> > sip-overload@ietf.org >> > https://www.ietf.org/mailman/listinfo/sip-overload >> >> >> _______________________________________________ >> sip-overload mailing list >> sip-overload@ietf.org >> https://www.ietf.org/mailman/listinfo/sip-overload > > > -- > Salvatore Loreto, PhD > www.sloreto.com > > > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload > From vkg@bell-labs.com Mon Jan 14 06:30:14 2013 Return-Path: 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 D570F21F8860 for ; Mon, 14 Jan 2013 06:30:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.187 X-Spam-Level: X-Spam-Status: No, score=-109.187 tagged_above=-999 required=5 tests=[AWL=1.412, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 cZ6Z0GvTXEf5 for ; Mon, 14 Jan 2013 06:30:12 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0686721F8841 for ; Mon, 14 Jan 2013 06:30:11 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r0EEUAmK020545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 14 Jan 2013 08:30:11 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r0EEUAH2024479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 14 Jan 2013 08:30:10 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r0EEUABZ014474 for ; Mon, 14 Jan 2013 08:30:10 -0600 (CST) Message-ID: <50F416ED.3050506@bell-labs.com> Date: Mon, 14 Jan 2013 08:32:13 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: sip-overload@ietf.org References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> <5EBD159DE88147488A3B1590E090018403530A9E6275@njfpsrvexg2.research.att.com> <24674_1355758104_50CF3A18_24674_468_1_88CAD1D4E8773F42858B58CAA28272A00E2A2C@PEXCVZYM12.corporate.adroot.infra.ftgroup> <50E5B529.2090105@bell-labs.com> <50F4007B.5050903@ericsson.com> In-Reply-To: <50F4007B.5050903@ericsson.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.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 14:30:14 -0000 On 01/14/2013 06:56 AM, Salvatore Loreto wrote: > my reading of the mailing list is that the question of using SHOULD > versus MUST is being decided in favor of MUST [...] Sal: Funny --- my reading of the mailing list after Volker and Janet's emails suggests that Janet is okay with a SHOULD. Given the number of people expressing an interest now, I think things are weighing in favour of a SHOULD. It will be good to close this so we can get the drafts out. 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/ From jgunn6@csc.com Mon Jan 14 06:56:04 2013 Return-Path: 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 62AA021F88D6; Mon, 14 Jan 2013 06:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.164 X-Spam-Level: X-Spam-Status: No, score=-6.164 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 FfhVx3eO01Wu; Mon, 14 Jan 2013 06:56:03 -0800 (PST) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.255.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2A80221F888A; Mon, 14 Jan 2013 06:56:02 -0800 (PST) Received: from [216.82.253.227:48750] by server-6.bemta-7.messagelabs.com id AB/B6-10358-28C14F05; Mon, 14 Jan 2013 14:56:02 +0000 X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-15.tower-170.messagelabs.com!1358175360!25985577!1 X-Originating-IP: [20.137.2.88] X-StarScan-Received: X-StarScan-Version: 6.6.1.8; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30847 invoked from network); 14 Jan 2013 14:56:01 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-15.tower-170.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Jan 2013 14:56:01 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r0EEtr9t002339; Mon, 14 Jan 2013 09:56:00 -0500 In-Reply-To: <50F416ED.3050506@bell-labs.com> References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> <24674_1355758104_50CF3A18_24674_468_1_88CAD1D4E8773F42858B58CAA28272A00E2A2C@PEXCVZYM12.corporate.adroot.infra.ftgroup> <50E5B529.2090105@bell-labs.com> To: "Vijay K. Gurbani" MIME-Version: 1.0 X-KeepSent: 1CE983DD:6050178F-85257AF3:0051FA1C; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Mon, 14 Jan 2013 09:56:00 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 01/14/2013 09:50:58 AM, Serialize complete at 01/14/2013 09:50:58 AM Content-Type: multipart/alternative; boundary="=_alternative 0052081F85257AF3_=" Cc: sip-overload-bounces@ietf.org, sip-overload@ietf.org Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 14:56:04 -0000 This is a multipart message in MIME format. --=_alternative 0052081F85257AF3_= Content-Type: text/plain; charset="US-ASCII" I am OK with either MUST or SHOULD. Janet This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. From: "Vijay K. Gurbani" To: sip-overload@ietf.org Date: 01/14/2013 09:30 AM Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt Sent by: sip-overload-bounces@ietf.org On 01/14/2013 06:56 AM, Salvatore Loreto wrote: > my reading of the mailing list is that the question of using SHOULD > versus MUST is being decided in favor of MUST [...] Sal: Funny --- my reading of the mailing list after Volker and Janet's emails suggests that Janet is okay with a SHOULD. Given the number of people expressing an interest now, I think things are weighing in favour of a SHOULD. It will be good to close this so we can get the drafts out. 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 --=_alternative 0052081F85257AF3_= Content-Type: text/html; charset="US-ASCII" I am OK with either MUST or SHOULD.

Janet

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.



From:        "Vijay K. Gurbani" <vkg@bell-labs.com>
To:        sip-overload@ietf.org
Date:        01/14/2013 09:30 AM
Subject:        Re: [sip-overload] Local Policy Re: I-D        Action:        draft-ietf-soc-load-control-event-package-05.txt
Sent by:        sip-overload-bounces@ietf.org



On 01/14/2013 06:56 AM, Salvatore Loreto wrote:
> my reading of the mailing list is that the question of using SHOULD
> versus MUST is being decided in favor of MUST  [...]

Sal: Funny --- my reading of the mailing list after Volker and Janet's
emails suggests that Janet is okay with a SHOULD.

Given the number of people expressing an interest now, I think things
are weighing in favour of a SHOULD.

It will be good to close this so we can get the drafts out.

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
--=_alternative 0052081F85257AF3_=-- From vkg@bell-labs.com Mon Jan 14 07:00:50 2013 Return-Path: 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 BFB1321F8ABD for ; Mon, 14 Jan 2013 07:00:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.344 X-Spam-Level: X-Spam-Status: No, score=-107.344 tagged_above=-999 required=5 tests=[AWL=-0.745, 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 LYWrNb4EQtom for ; Mon, 14 Jan 2013 07:00:49 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id C578021F8AB8 for ; Mon, 14 Jan 2013 07:00:49 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r0EF0mGl024827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 14 Jan 2013 09:00:49 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r0EF0lWK029439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 14 Jan 2013 09:00:48 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r0EF0jhJ004962 for ; Mon, 14 Jan 2013 09:00:47 -0600 (CST) Message-ID: <50F41E18.6020005@bell-labs.com> Date: Mon, 14 Jan 2013 09:02:48 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: sip-overload@ietf.org References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> <5EBD159DE88147488A3B1590E090018403530A9E6275@njfpsrvexg2.research.att.com> <24674_1355758104_50CF3A18_24674_468_1_88CAD1D4E8773F42858B58CAA28272A00E2A2C@PEXCVZYM12.corporate.adroot.infra.ftgroup> <50E5B529.2090105@bell-labs.com> <50F4007B.5050903@ericsson.com> <50F4146E.1080308@bell-labs.com> In-Reply-To: <50F4146E.1080308@bell-labs.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.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 15:00:50 -0000 I think the text Volker proposed below works, although it appears that the explanatory sentence Volker added is applicable to only the first paragraph. I think that the sentence is equally applicable to all the three SHOULDs. I would, thus, suggest a small modification as detailed below. On 01/14/2013 08:21 AM, Volker Hilt wrote: > A SIP client SHOULD honor the local policy for prioritizing SIP requests > such as policies based on message type, e.g., INVITEs vs. requests > associated with existing sessions. A SIP client is expected generally to > honor local policy except for very rare occasions when, for example, > overload is so severe that messages, which should be preserved according > to local policy, need to be discarded or local policies are in conflict. > > A SIP client SHOULD honor the local policy for prioritizing SIP requests > based on the content of the Resource-Priority header (RPH, RFC4412 > [RFC4412]). Specific (namespace.value) RPH contents may indicate high > priority requests that should be preserved as much as possible during > overload. The RPH contents can also indicate a low-priority request > that is eligible to be dropped during times of overload. > > A SIP client SHOULD honor the local policy for prioritizing SIP requests > relating to emergency calls, as identified by the SOS URN [RFC5031] > indicating an emergency request. I would re-word as: A SIP client is generally expected to honor local policy for prioritizing SIP requests except for very rare occasions, when, for example, overload is so severe that messages that would otherwise be preserved according to local policy need to be now discarded. Another example where local policies may not be honored is if these are in conflict. Accordingly, the normative statements in the next three paragraphs should be interpreted in the context provided here and with the understanding that the SIP client will aim to preserve local policy to the fullest extent possible. A SIP client SHOULD honor the local policy for prioritizing SIP requests such as policies based on message type, e.g., INVITEs vs. requests associated with existing sessions. A SIP client SHOULD honor the local policy for prioritizing SIP requests based on the content of the Resource-Priority header (RPH, RFC4412 [RFC4412]). Specific (namespace.value) RPH contents may indicate high priority requests that should be preserved as much as possible during overload. The RPH contents can also indicate a low-priority request that is eligible to be dropped during times of overload. A SIP client SHOULD honor the local policy for prioritizing SIP requests relating to emergency calls, as identified by the SOS URN [RFC5031] indicating an emergency request. Unless someone has objections, I will put this into the soc-overload-control draft, and I suspect that Charles will do the same for his draft. 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/ From volker.hilt@bell-labs.com Mon Jan 14 07:02:30 2013 Return-Path: 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 DCC4F21F8935 for ; Mon, 14 Jan 2013 07:02:30 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YE24p7ugo9P for ; Mon, 14 Jan 2013 07:02:30 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id B1D4321F88AC for ; Mon, 14 Jan 2013 07:02:29 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r0EEwMmR030348 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 14 Jan 2013 16:02:24 +0100 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 14 Jan 2013 16:02:04 +0100 Received: from [135.244.178.1] (135.239.27.11) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 14 Jan 2013 16:02:04 +0100 Message-ID: <50F41DE8.9040301@bell-labs.com> Date: Mon, 14 Jan 2013 16:02:00 +0100 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> <5EBD159DE88147488A3B1590E090018403530A9E6275@njfpsrvexg2.research.att.com> <24674_1355758104_50CF3A18_24674_468_1_88CAD1D4E8773F42858B58CAA28272A00E2A2C@PEXCVZYM12.corporate.adroot.infra.ftgroup> <50E5B529.2090105@bell-labs.com> <50F4007B.5050903@ericsson.com> <50F4146E.1080308@bell-labs.com> <50F41E18.6020005@bell-labs.com> In-Reply-To: <50F41E18.6020005@bell-labs.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.11] X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 15:02:31 -0000 Sounds good to me. Volker On 14.01.2013 16:02, Vijay K. Gurbani wrote: > I think the text Volker proposed below works, although it appears that > the explanatory sentence Volker added is applicable to only the first > paragraph. I think that the sentence is equally applicable to all the > three SHOULDs. > > I would, thus, suggest a small modification as detailed below. > > On 01/14/2013 08:21 AM, Volker Hilt wrote: >> A SIP client SHOULD honor the local policy for prioritizing SIP requests >> such as policies based on message type, e.g., INVITEs vs. requests >> associated with existing sessions. A SIP client is expected generally to >> honor local policy except for very rare occasions when, for example, >> overload is so severe that messages, which should be preserved according >> to local policy, need to be discarded or local policies are in conflict. >> >> A SIP client SHOULD honor the local policy for prioritizing SIP requests >> based on the content of the Resource-Priority header (RPH, RFC4412 >> [RFC4412]). Specific (namespace.value) RPH contents may indicate high >> priority requests that should be preserved as much as possible during >> overload. The RPH contents can also indicate a low-priority request >> that is eligible to be dropped during times of overload. >> >> A SIP client SHOULD honor the local policy for prioritizing SIP requests >> relating to emergency calls, as identified by the SOS URN [RFC5031] >> indicating an emergency request. > > I would re-word as: > > A SIP client is generally expected to honor local policy for > prioritizing SIP requests except for very rare occasions, when, > for example, overload is so severe that messages that would > otherwise be preserved according to local policy need to be > now discarded. Another example where local policies may not be > honored is if these are in conflict. Accordingly, the normative > statements in the next three paragraphs should be interpreted in > the context provided here and with the understanding that the SIP > client will aim to preserve local policy to the fullest extent > possible. > > A SIP client SHOULD honor the local policy for prioritizing SIP > requests such as policies based on message type, e.g., INVITEs vs. > requests associated with existing sessions. > > A SIP client SHOULD honor the local policy for prioritizing SIP > requests based on the content of the Resource-Priority header (RPH, > RFC4412 [RFC4412]). Specific (namespace.value) RPH contents may > indicate high priority requests that should be preserved as much as > possible during overload. The RPH contents can also indicate a > low-priority request that is eligible to be dropped during times of > overload. > > A SIP client SHOULD honor the local policy for prioritizing SIP > requests relating to emergency calls, as identified by the SOS URN > [RFC5031] indicating an emergency request. > > Unless someone has objections, I will put this into the > soc-overload-control draft, and I suspect that Charles will do the same > for his draft. > > Thanks, > > - vijay From salvatore.loreto@ericsson.com Mon Jan 14 07:09:03 2013 Return-Path: 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 A928E21F88CA for ; Mon, 14 Jan 2013 07:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.248 X-Spam-Level: X-Spam-Status: No, score=-106.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 nmfqGIRO1MXs for ; Mon, 14 Jan 2013 07:09:02 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 533C721F88AE for ; Mon, 14 Jan 2013 07:09:01 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-f9-50f41f8c364c Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 92.AB.32353.C8F14F05; Mon, 14 Jan 2013 16:09:00 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Mon, 14 Jan 2013 16:08:59 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id BDF132454 for ; Mon, 14 Jan 2013 17:08:59 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C3AA953E70 for ; Mon, 14 Jan 2013 17:08:57 +0200 (EET) Received: from n94.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7F81153DE5 for ; Mon, 14 Jan 2013 17:08:57 +0200 (EET) Message-ID: <50F41F8A.8020805@ericsson.com> Date: Mon, 14 Jan 2013 17:08:58 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: sip-overload@ietf.org References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> <5EBD159DE88147488A3B1590E090018403530A9E6275@njfpsrvexg2.research.att.com> <24674_1355758104_50CF3A18_24674_468_1_88CAD1D4E8773F42858B58CAA28272A00E2A2C@PEXCVZYM12.corporate.adroot.infra.ftgroup> <50E5B529.2090105@bell-labs.com> <50F4007B.5050903@ericsson.com> <50F4146E.1080308@bell-labs.com> <50F41E18.6020005@bell-labs.com> In-Reply-To: <50F41E18.6020005@bell-labs.com> Content-Type: multipart/alternative; boundary="------------090009030901060509020403" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUyM+JvjW6P/JcAg7c7pCz2P01wYPRYsuQn UwBjFJdNSmpOZllqkb5dAlfG3XsnGQvmeVdMuVjTwPjHtIuRg0NCwETiRk9NFyMnkCkmceHe erYuRi4OIYGTjBKvl21hhXA2MEo0bVnKAuFcY5R4P/EKM1zZ/b0H2CGcg4wSXdOPsIEM4xXQ lni3YTKYzSKgKrF9/yxWEJtNwEzi+cMtzCC2qECyxMc711gh6gUlTs58wgJiiwhISnx5PpER xBYWyJR4vv0CI8SCNewSv868ZAJJcAroSjTdewzWwCwQJtF//gYjxBdqElfPbQJbICSgJdF7 tpNpAqPwLCQ7ZiFpgbBtJS7MuQ4Vl5fY/nYOM4StK3Hh/xQU8QWMbKsY2XMTM3PSy803MQJD /+CW3wY7GDfdFzvEKM3BoiTOG+56IUBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo/46HZ6l uy5/m+E2IY27+bXK9mOprW66aX9vhkW3nzy99Gp/w7tHUvxcTQ5S7y7HTDTz7PCbk8kUn6bV 61wzV36r9/9PE/d/3LQrhOfJvcU3rspdqd71eolext5fNo/uBxvLsy5k0fKNfCNgZnB1w4GH gmrTpK4yKGdueTG7+cnvHc4NOVcv3FdiKc5INNRiLipOBAAIsg6OSwIAAA== Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 15:09:03 -0000 --------------090009030901060509020403 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit while I am OK with the "/A SIP client is expected generally to // //honor local policy except for very rare occasions when, for example, // //overload is so severe that messages, which should be preserved according // //to local policy, need to be discarded/" I don t like the last "/or local policies are in conflict/." as it can generate confusion i.e. what to do when local policies are in conflict, what policy then apply etc. /Sal On 1/14/13 5:02 PM, Vijay K. Gurbani wrote: > I think the text Volker proposed below works, although it appears that > the explanatory sentence Volker added is applicable to only the first > paragraph. I think that the sentence is equally applicable to all the > three SHOULDs. > > I would, thus, suggest a small modification as detailed below. > > On 01/14/2013 08:21 AM, Volker Hilt wrote: >> A SIP client SHOULD honor the local policy for prioritizing SIP requests >> such as policies based on message type, e.g., INVITEs vs. requests >> associated with existing sessions. A SIP client is expected generally to >> honor local policy except for very rare occasions when, for example, >> overload is so severe that messages, which should be preserved according >> to local policy, need to be discarded or local policies are in conflict. >> >> A SIP client SHOULD honor the local policy for prioritizing SIP requests >> based on the content of the Resource-Priority header (RPH, RFC4412 >> [RFC4412]). Specific (namespace.value) RPH contents may indicate high >> priority requests that should be preserved as much as possible during >> overload. The RPH contents can also indicate a low-priority request >> that is eligible to be dropped during times of overload. >> >> A SIP client SHOULD honor the local policy for prioritizing SIP requests >> relating to emergency calls, as identified by the SOS URN [RFC5031] >> indicating an emergency request. > > I would re-word as: > > A SIP client is generally expected to honor local policy for > prioritizing SIP requests except for very rare occasions, when, > for example, overload is so severe that messages that would > otherwise be preserved according to local policy need to be > now discarded. Another example where local policies may not be > honored is if these are in conflict. Accordingly, the normative > statements in the next three paragraphs should be interpreted in > the context provided here and with the understanding that the SIP > client will aim to preserve local policy to the fullest extent > possible. > > A SIP client SHOULD honor the local policy for prioritizing SIP > requests such as policies based on message type, e.g., INVITEs vs. > requests associated with existing sessions. > > A SIP client SHOULD honor the local policy for prioritizing SIP > requests based on the content of the Resource-Priority header (RPH, > RFC4412 [RFC4412]). Specific (namespace.value) RPH contents may > indicate high priority requests that should be preserved as much as > possible during overload. The RPH contents can also indicate a > low-priority request that is eligible to be dropped during times of > overload. > > A SIP client SHOULD honor the local policy for prioritizing SIP > requests relating to emergency calls, as identified by the SOS URN > [RFC5031] indicating an emergency request. > > Unless someone has objections, I will put this into the > soc-overload-control draft, and I suspect that Charles will do the same > for his draft. > > Thanks, > > - vijay --------------090009030901060509020403 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit

while I am OK with the
"A SIP client is expected generally to
honor local policy except for very rare occasions when, for example,
overload is so severe that messages, which should be preserved according
to local policy, need to be discarded"

I don t like the last "or local policies are in conflict."
as it can generate confusion
i.e. what to do when local policies are in conflict, what policy then apply etc.

/Sal




On 1/14/13 5:02 PM, Vijay K. Gurbani wrote:
I think the text Volker proposed below works, although it appears that
the explanatory sentence Volker added is applicable to only the first
paragraph.  I think that the sentence is equally applicable to all the
three SHOULDs.

I would, thus, suggest a small modification as detailed below.

On 01/14/2013 08:21 AM, Volker Hilt wrote:
A SIP client SHOULD honor the local policy for prioritizing SIP requests
such as policies based on message type, e.g., INVITEs vs. requests
associated with existing sessions. A SIP client is expected generally to
honor local policy except for very rare occasions when, for example,
overload is so severe that messages, which should be preserved according
to local policy, need to be discarded or local policies are in conflict.

A SIP client SHOULD honor the local policy for prioritizing SIP requests
based on the content of the Resource-Priority header (RPH, RFC4412
[RFC4412]).  Specific (namespace.value) RPH contents may indicate high
priority requests that should be preserved as much as possible during
overload.  The RPH contents can also indicate a low-priority request
that is eligible to be dropped during times of overload.

A SIP client SHOULD honor the local policy for prioritizing SIP requests
relating to emergency calls, as identified by the SOS URN [RFC5031]
indicating an emergency request.

I would re-word as:

   A SIP client is generally expected to honor local policy for
   prioritizing SIP requests except for very rare occasions, when,
   for example, overload is so severe that messages that would
   otherwise be preserved according to local policy need to be
   now discarded.  Another example where local policies may not be
   honored is if these are in conflict.  Accordingly, the normative
   statements in the next three paragraphs should be interpreted in
   the context provided here and with the understanding that the SIP
   client will aim to preserve local policy to the fullest extent
   possible.

   A SIP client SHOULD honor the local policy for prioritizing SIP
   requests such as policies based on message type, e.g., INVITEs vs.
   requests associated with existing sessions.

   A SIP client SHOULD honor the local policy for prioritizing SIP
   requests based on the content of the Resource-Priority header (RPH,
   RFC4412 [RFC4412]).  Specific (namespace.value) RPH contents may
   indicate high priority requests that should be preserved as much as
   possible during overload.  The RPH contents can also indicate a
   low-priority request that is eligible to be dropped during times of
   overload.

   A SIP client SHOULD honor the local policy for prioritizing SIP
   requests relating to emergency calls, as identified by the SOS URN
   [RFC5031] indicating an emergency request.

Unless someone has objections, I will put this into the
soc-overload-control draft, and I suspect that Charles will do the same
for his draft.

Thanks,

- vijay


--------------090009030901060509020403-- From jgunn6@csc.com Mon Jan 14 07:09:53 2013 Return-Path: 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 2D91121F89E9; Mon, 14 Jan 2013 07:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.772 X-Spam-Level: X-Spam-Status: No, score=-4.772 tagged_above=-999 required=5 tests=[AWL=-1.175, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] 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 OO179jhrvk50; Mon, 14 Jan 2013 07:09:51 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.50]) by ietfa.amsl.com (Postfix) with ESMTP id BB5F121F88AE; Mon, 14 Jan 2013 07:09:50 -0800 (PST) Received: from [216.82.241.211:11001] by server-8.bemta-8.messagelabs.com id 3E/76-25265-EBF14F05; Mon, 14 Jan 2013 15:09:50 +0000 X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-10.tower-85.messagelabs.com!1358176188!39334857!1 X-Originating-IP: [20.137.2.88] X-StarScan-Received: X-StarScan-Version: 6.6.1.8; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11274 invoked from network); 14 Jan 2013 15:09:49 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-10.tower-85.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Jan 2013 15:09:49 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r0EF9HOL024850; Mon, 14 Jan 2013 10:09:47 -0500 In-Reply-To: <50F4146E.1080308@bell-labs.com> References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> <24674_1355758104_50CF3A18_24674_468_1_88CAD1D4E8773F42858B58CAA28272A00E2A2C@PEXCVZYM12.corporate.adroot.infra.ftgroup> <50E5B529.2090105@bell-labs.com> To: Volker Hilt MIME-Version: 1.0 X-KeepSent: 4F87BE69:2F96FD4B-85257AF3:00523DD0; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Mon, 14 Jan 2013 10:09:46 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 01/14/2013 10:04:45 AM, Serialize complete at 01/14/2013 10:04:45 AM Content-Type: multipart/alternative; boundary="=_alternative 0053430085257AF3_=" Cc: sip-overload-bounces@ietf.org, sip-overload@ietf.org Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 15:09:53 -0000 This is a multipart message in MIME format. --=_alternative 0053430085257AF3_= Content-Type: text/plain; charset="US-ASCII" No, I don't like your added sentence. A VALID local policy prioritizes within the volume of messages permitted by the algorithm. A VALID local policy doe not attempt to send more messages than permitted by the Overload algorithm. A Local policy that attempts to override teh Overload Control Algorithm is not permitted That is pretty clear in the wording of Req 13. If you are going to say "MUST", then you must also define what constitutes a VALID local policy, in some detail. If you are going to say "SHOULD", then you do not need to define a VALID local policy in detail But the way you have written it implies that it is permissible to have a Local Policy that attempts to override the Overload control algorithm, and so must, in turn be over ridden by the Overload Algorithm. I don't even what to suggest that such a case would occur. I DO NOT WANT TO MENTION IT. The SHOULD takes care of it. Janet sip-overload-bounces@ietf.org wrote on 01/14/2013 09:21:34 AM: > From: Volker Hilt > To: > Date: 01/14/2013 09:22 AM > Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf- > soc-load-control-event-package-05.txt > Sent by: sip-overload-bounces@ietf.org > > I think SHOULD would, in fact, be the more appropriate wording here. > There may be reasons why a local policy cannot be kept: a conflict with > another policy, legal requirements, or very high levels of overload. > > In the end, the local policy will be a local matter including its > enforcement. In other words, if a service provider has a SIP server that > ignores his policies, I'm sure the service provide will know who to call. > > I've added a short explanatory sentence to the first paragraph: > > A SIP client SHOULD honor the local policy for prioritizing SIP requests > such as policies based on message type, e.g., INVITEs vs. requests > associated with existing sessions. A SIP client is expected generally to > honor local policy except for very rare occasions when, for example, > overload is so severe that messages, which should be preserved according > to local policy, need to be discarded or local policies are in conflict. > > A SIP client SHOULD honor the local policy for prioritizing SIP requests > based on the content of the Resource-Priority header (RPH, RFC4412 > [RFC4412]). Specific (namespace.value) RPH contents may indicate high > priority requests that should be preserved as much as possible during > overload. The RPH contents can also indicate a low-priority request > that is eligible to be dropped during times of overload. > > A SIP client SHOULD honor the local policy for prioritizing SIP requests > relating to emergency calls, as identified by the SOS URN [RFC5031] > indicating an emergency request. > > Thanks, > > Volker [as individual] > > > > > On 14.01.2013 13:56, Salvatore Loreto wrote: > > my reading of the mailing list is that the question of using SHOULD > > versus MUST > > is being decided in favor of MUST > > > > however it would be great to also address the Valker concerns > > inserting a caveat/constraints explaining that the local policy can not > > override the overload mechanism/algorithm > > > > can someone propose text ? > > > > note this is the only remaining issue that we have to address in this > > event-package draft > > before we can ship to the IESG > > > > /Salvatore > > > > > > On 1/11/13 4:25 PM, Janet P Gunn wrote: > >> > >> Good point > >> > >> If you say it MUST honor "local policy", then you need constraints > >> on what the local policy can do (e.g., it can only prioritize within > >> the number of messages permitted by the overload algorithm, it can't > >> over ride the overload mechanism/algorithm) > >> > >> Janet > >> > >> > >> > >> sip-overload-bounces@ietf.org wrote on 01/11/2013 09:06:58 AM: > >> > >> > From: Volker Hilt > >> > To: > >> > Date: 01/11/2013 09:07 AM > >> > Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf- > >> > soc-load-control-event-package-05.txt > >> > Sent by: sip-overload-bounces@ietf.org > >> > > >> > Janet, All, > >> > > >> > while this sounds good in most cases, the concern I have is that there > >> > may be situation where a proxy is forced to violate local policy. E.g., > >> > a policy "emergency calls can never be dropped" will have to be > >> violated > >> > eventually if overload reaches levels where only emergency calls are > >> left. > >> > > >> > Maybe this boils down to formulating policies in a reasonable way. It > >> > has to be made clear, however, that not all policies call be kept under > >> > all circumstances. > >> > > >> > A SHOULD would imply this to the developer. With a MUST, I think one > >> > would have to add explanatory text. > >> > > >> > Thanks, > >> > > >> > Volker [with individual contributor hat on] > >> > > >> > > >> > > >> > On 03.01.2013 18:52, Janet P Gunn wrote: > >> > > I prefer MUST to SHOULD. > >> > > > >> > > The original wording was based on Req 13 of RFC 5390: > >> > > " REQ 13: The mechanism must not dictate a specific algorithm for > >> > > prioritizing the processing of work within a proxy during > >> times of > >> > > overload*. It must permit a proxy to prioritize requests > >> based on* > >> > > * any local policy*, so that certain ones (such as a call for > >> > > emergency services or a call with a specific value of the > >> > > Resource-Priority header field [RFC4412]) are given > >> preferential > >> > > treatment, such as not being dropped, being given additional > >> > > retransmission, or being processed ahead of others." > >> > > > >> > > which has a lower case "must". > >> > > > >> > > If we are going to say "MUST honor" (rather than "must permit"), I > >> think > >> > > we need to change "any" to "the" . (you can permit many alternatives, > >> > > but you can really only honor one). I think this also reflects the > >> > > intent of Martin's comment > >> > > > >> > > So I would prefer > >> > > > >> > > > >> > > A SIP client MUST honor *the *local policy for prioritizing SIP > >> > > requests such as policies based on message type, e.g., INVITEs vs. > >> > > requests associated with existing sessions. > >> > > > >> > > A SIP client MUST honor *the *local policy for prioritizing SIP > >> > > requests based on the content of the Resource-Priority header (RPH, > >> > > RFC4412 [RFC4412]). Specific (namespace.value) RPH contents may > >> > > indicate high priority requests that should be preserved as much as > >> > > possible during overload. The RPH contents can also indicate a > >> > > low-priority request that is eligible to be dropped during times of > >> > > overload. > >> > > > >> > > A SIP client MUST honor *the *local policy for prioritizing SIP > >> > > requests relating to emergency calls, as identified by the SOS > >> > > URN [RFC5031] indicating an emergency request. > >> > > > >> > > > >> > > Thanks > >> > > > >> > > Janet > >> > > > >> > > This is a PRIVATE message. If you are not the intended recipient, > >> please > >> > > delete without copying and kindly advise us by e-mail of the > >> mistake in > >> > > delivery. NOTE: Regardless of content, this e-mail shall not > >> operate to > >> > > bind CSC to any order or other contract unless pursuant to explicit > >> > > written agreement or government initiative expressly permitting > >> the use > >> > > of e-mail for such purpose. > >> > > > >> > > > >> > > > >> > > From: "Vijay K. Gurbani" > >> > > To: Charles Shen > >> > > Cc: "DRAGE, Keith (Keith)" , Janet P > >> > > Gunn/USA/CSC@CSC, "sip-overload@ietf.org" , > >> Arata > >> > > Koike , "NOEL, ERIC (ERIC C)" > >> > > , Henning Schulzrinne > >> > > Date: 01/03/2013 11:42 AM > >> > > Subject: Re: [sip-overload] Local Policy Re: I-D Action: > >> > > draft-ietf-soc-load-control-event-package-05.txt > >> > > > >> ------------------------------------------------------------------------ > >> > > > >> > > > >> > > > >> > > On 01/03/2013 07:34 AM, Charles Shen wrote: > >> > > > Sounds good, I can update the wording in the event package > >> draft, if > >> > > > Vijay is OK with the other one. > >> > > > >> > > I just want to make sure we are all agreeing to the same thing. > >> > > > >> > > It seems to me that the question of using SHOULD versus MUST is being > >> > > decided slightly in favour of a MUST. Martin and Bruno prefer a MUST, > >> > > Janet is okay with, although her original text used a SHOULD; and > >> Keith > >> > > could go either way. > >> > > > >> > > Is the consensus, then, that the text on honoring local policy > >> contains > >> > > MUST? If so, the text to be inserted would be the following: > >> > > > >> > > A SIP client MUST honor any local policy for prioritizing SIP > >> > > requests such as policies based on message type, e.g., INVITEs vs. > >> > > requests associated with existing sessions. > >> > > > >> > > A SIP client MUST honor any local policy for prioritizing SIP > >> > > requests based on the content of the Resource-Priority header (RPH, > >> > > RFC4412 [RFC4412]). Specific (namespace.value) RPH contents may > >> > > indicate high priority requests that should be preserved as much as > >> > > possible during overload. The RPH contents can also indicate a > >> > > low-priority request that is eligible to be dropped during times of > >> > > overload. > >> > > > >> > > A SIP client MUST honor any local policy for prioritizing SIP > >> > > requests relating to emergency calls, as identified by the SOS > >> > > URN [RFC5031] indicating an emergency request. > >> > > > >> > > Yes? > >> > > > >> > > 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 > >> > > > >> > _______________________________________________ > >> > sip-overload mailing list > >> > sip-overload@ietf.org > >> > https://www.ietf.org/mailman/listinfo/sip-overload > >> > >> > >> _______________________________________________ > >> sip-overload mailing list > >> sip-overload@ietf.org > >> https://www.ietf.org/mailman/listinfo/sip-overload > > > > > > -- > > Salvatore Loreto, PhD > > www.sloreto.com > > > > > > > > _______________________________________________ > > sip-overload mailing list > > sip-overload@ietf.org > > https://www.ietf.org/mailman/listinfo/sip-overload > > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload --=_alternative 0053430085257AF3_= Content-Type: text/html; charset="US-ASCII"

No, I don't like your added sentence.

A VALID local policy prioritizes within the volume of messages permitted by the algorithm.   A VALID local policy doe not attempt to send more messages than permitted by the Overload algorithm.  

A Local policy that attempts to override teh Overload Control Algorithm is not permitted

That is pretty clear in the wording of Req 13.


If you are going to say "MUST", then you must also define what constitutes a VALID local policy, in some detail.

If you are going to say "SHOULD", then you do not need to define a VALID local  policy in detail

But the way you have written it implies that it is permissible to have  a Local Policy that  attempts to override the Overload control algorithm, and so must, in turn  be over ridden by the Overload Algorithm.

I don't even what to suggest that such a case would occur.    I DO NOT WANT TO MENTION IT.

The SHOULD takes care of it.

Janet

sip-overload-bounces@ietf.org wrote on 01/14/2013 09:21:34 AM:

> From: Volker Hilt <volker.hilt@bell-labs.com>
> To: <sip-overload@ietf.org>
> Date: 01/14/2013 09:22 AM
> Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-
> soc-load-control-event-package-05.txt
> Sent by: sip-overload-bounces@ietf.org
>
> I think SHOULD would, in fact, be the more appropriate wording here.
> There may be reasons why a local policy cannot be kept: a conflict with
> another policy, legal requirements, or very high levels of overload.
>
> In the end, the local policy will be a local matter including its
> enforcement. In other words, if a service provider has a SIP server that
> ignores his policies, I'm sure the service provide will know who to call.
>
> I've added a short explanatory sentence to the first paragraph:
>
> A SIP client SHOULD honor the local policy for prioritizing SIP requests
> such as policies based on message type, e.g., INVITEs vs. requests
> associated with existing sessions. A SIP client is expected generally to
> honor local policy except for very rare occasions when, for example,
> overload is so severe that messages, which should be preserved according
> to local policy, need to be discarded or local policies are in conflict.
>
> A SIP client SHOULD honor the local policy for prioritizing SIP requests
> based on the content of the Resource-Priority header (RPH, RFC4412
> [RFC4412]).  Specific (namespace.value) RPH contents may indicate high
> priority requests that should be preserved as much as possible during
> overload.  The RPH contents can also indicate a low-priority request
> that is eligible to be dropped during times of overload.
>
> A SIP client SHOULD honor the local policy for prioritizing SIP requests
> relating to emergency calls, as identified by the SOS URN [RFC5031]
> indicating an emergency request.
>
> Thanks,
>
> Volker [as individual]
>
>
>
>
> On 14.01.2013 13:56, Salvatore Loreto wrote:
> > my reading of the mailing list is that the question of using SHOULD
> > versus MUST
> > is being decided in favor of MUST
> >
> > however it would be great to also address the Valker concerns
> > inserting a caveat/constraints explaining that the local policy can not
> > override the overload mechanism/algorithm
> >
> > can someone propose text ?
> >
> > note this is the only remaining issue that we have to address in this
> > event-package draft
> > before we can ship to the IESG
> >
> > /Salvatore
> >
> >
> > On 1/11/13 4:25 PM, Janet P Gunn wrote:
> >>
> >> Good point
> >>
> >> If you say it MUST honor "local policy", then you  need  constraints
> >> on what the local policy can do (e.g., it can only prioritize within
> >> the number of messages permitted by the overload algorithm, it can't
> >> over ride the overload mechanism/algorithm)
> >>
> >> Janet
> >>
> >>
> >>
> >> sip-overload-bounces@ietf.org wrote on 01/11/2013 09:06:58 AM:
> >>
> >> > From: Volker Hilt <volker.hilt@bell-labs.com>
> >> > To: <sip-overload@ietf.org>
> >> > Date: 01/11/2013 09:07 AM
> >> > Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-
> >> > soc-load-control-event-package-05.txt
> >> > Sent by: sip-overload-bounces@ietf.org
> >> >
> >> > Janet, All,
> >> >
> >> > while this sounds good in most cases, the concern I have is that there
> >> > may be situation where a proxy is forced to violate local policy. E.g.,
> >> > a policy "emergency calls can never be dropped" will have to be
> >> violated
> >> > eventually if overload reaches levels where only emergency calls are
> >> left.
> >> >
> >> > Maybe this boils down to formulating policies in a reasonable way. It
> >> > has to be made clear, however, that not all policies call be kept under
> >> > all circumstances.
> >> >
> >> > A SHOULD would imply this to the developer. With a MUST, I think one
> >> > would have to add explanatory text.
> >> >
> >> > Thanks,
> >> >
> >> > Volker [with individual contributor hat on]
> >> >
> >> >
> >> >
> >> > On 03.01.2013 18:52, Janet P Gunn wrote:
> >> > > I prefer MUST to SHOULD.
> >> > >
> >> > > The original wording was based on Req 13 of RFC 5390:
> >> > > " REQ 13:  The mechanism must not dictate a specific algorithm for
> >> > >        prioritizing the processing of work within a proxy during
> >> times of
> >> > >        overload*.  It must permit a proxy to prioritize requests
> >> based on*
> >> > > *      any local policy*, so that certain ones (such as a call for
> >> > >        emergency services or a call with a specific value of the
> >> > >        Resource-Priority header field [RFC4412]) are given
> >> preferential
> >> > >        treatment, such as not being dropped, being given additional
> >> > >        retransmission, or being processed ahead of others."
> >> > >
> >> > > which has a lower case "must".
> >> > >
> >> > > If we are going to say "MUST honor" (rather than "must permit"), I
> >> think
> >> > > we need to change "any" to "the" . (you can permit many alternatives,
> >> > > but you can really only honor one).  I think this also reflects the
> >> > > intent of Martin's  comment
> >> > >
> >> > > So I would prefer
> >> > >
> >> > >
> >> > >    A SIP client MUST honor *the *local policy for prioritizing SIP
> >> > >    requests such as policies based on message type, e.g., INVITEs vs.
> >> > >    requests associated with existing sessions.
> >> > >
> >> > >    A SIP client MUST honor *the *local policy for prioritizing SIP
> >> > >    requests based on the content of the Resource-Priority header (RPH,
> >> > >    RFC4412 [RFC4412]).  Specific (namespace.value) RPH contents may
> >> > >    indicate high priority requests that should be preserved as much as
> >> > >    possible during overload.  The RPH contents can also indicate a
> >> > >    low-priority request that is eligible to be dropped during times of
> >> > >    overload.
> >> > >
> >> > >    A SIP client MUST honor *the *local policy for prioritizing SIP
> >> > >    requests relating to emergency calls, as identified by the SOS
> >> > >    URN [RFC5031] indicating an emergency request.
> >> > >
> >> > >
> >> > > Thanks
> >> > >
> >> > > Janet
> >> > >
> >> > > This is a PRIVATE message. If you are not the intended recipient,
> >> please
> >> > > delete without copying and kindly advise us by e-mail of the
> >> mistake in
> >> > > delivery. NOTE: Regardless of content, this e-mail shall not
> >> operate to
> >> > > bind CSC to any order or other contract unless pursuant to explicit
> >> > > written agreement or government initiative expressly permitting
> >> the use
> >> > > of e-mail for such purpose.
> >> > >
> >> > >
> >> > >
> >> > > From: "Vijay K. Gurbani" <vkg@bell-labs.com>
> >> > > To: Charles Shen <charles@cs.columbia.edu>
> >> > > Cc: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>, Janet P
> >> > > Gunn/USA/CSC@CSC, "sip-overload@ietf.org" <sip-overload@ietf.org>,
> >> Arata
> >> > > Koike <koike.arata@lab.ntt.co.jp>, "NOEL, ERIC (ERIC C)"
> >> > > <ecnoel@att.com>, Henning Schulzrinne <hgs@cs.columbia.edu>
> >> > > Date: 01/03/2013 11:42 AM
> >> > > Subject: Re: [sip-overload] Local Policy Re: I-D Action:
> >> > > draft-ietf-soc-load-control-event-package-05.txt
> >> > >
> >> ------------------------------------------------------------------------
> >> > >
> >> > >
> >> > >
> >> > > On 01/03/2013 07:34 AM, Charles Shen wrote:
> >> > >  > Sounds good, I can update the wording in the event package
> >> draft, if
> >> > >  > Vijay is OK with the other one.
> >> > >
> >> > > I just want to make sure we are all agreeing to the same thing.
> >> > >
> >> > > It seems to me that the question of using SHOULD versus MUST is being
> >> > > decided slightly in favour of a MUST.  Martin and Bruno prefer a MUST,
> >> > > Janet is okay with, although her original text used a SHOULD; and
> >> Keith
> >> > > could go either way.
> >> > >
> >> > > Is the consensus, then, that the text on honoring local policy
> >> contains
> >> > > MUST?  If so, the text to be inserted would be the following:
> >> > >
> >> > >    A SIP client MUST honor any local policy for prioritizing SIP
> >> > >    requests such as policies based on message type, e.g., INVITEs vs.
> >> > >    requests associated with existing sessions.
> >> > >
> >> > >    A SIP client MUST honor any local policy for prioritizing SIP
> >> > >    requests based on the content of the Resource-Priority header (RPH,
> >> > >    RFC4412 [RFC4412]).  Specific (namespace.value) RPH contents may
> >> > >    indicate high priority requests that should be preserved as much as
> >> > >    possible during overload.  The RPH contents can also indicate a
> >> > >    low-priority request that is eligible to be dropped during times of
> >> > >    overload.
> >> > >
> >> > >    A SIP client MUST honor any local policy for prioritizing SIP
> >> > >    requests relating to emergency calls, as identified by the SOS
> >> > >    URN [RFC5031] indicating an emergency request.
> >> > >
> >> > > Yes?
> >> > >
> >> > > 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
> >> > >
> >> > _______________________________________________
> >> > sip-overload mailing list
> >> > sip-overload@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/sip-overload
> >>
> >>
> >> _______________________________________________
> >> sip-overload mailing list
> >> sip-overload@ietf.org
> >> https://www.ietf.org/mailman/listinfo/sip-overload
> >
> >
> > --
> > Salvatore Loreto, PhD
> > www.sloreto.com
> >
> >
> >
> > _______________________________________________
> > sip-overload mailing list
> > sip-overload@ietf.org
> > https://www.ietf.org/mailman/listinfo/sip-overload
> >
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload
 --=_alternative 0053430085257AF3_=-- From volker.hilt@bell-labs.com Mon Jan 14 07:23:28 2013 Return-Path: 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 6646E21F88C7; Mon, 14 Jan 2013 07:23:28 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBudkGw1RsWi; Mon, 14 Jan 2013 07:23:27 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAEF21F87C8; Mon, 14 Jan 2013 07:23:26 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r0EFKwZu020533 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 14 Jan 2013 16:23:22 +0100 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 14 Jan 2013 16:23:20 +0100 Received: from [135.244.178.1] (135.239.27.12) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 14 Jan 2013 16:23:19 +0100 Message-ID: <50F422E4.8010809@bell-labs.com> Date: Mon, 14 Jan 2013 16:23:16 +0100 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Janet P Gunn References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> <24674_1355758104_50CF3A18_24674_468_1_88CAD1D4E8773F42858B58CAA28272A00E2A2C@PEXCVZYM12.corporate.adroot.infra.ftgroup> <50E5B529.2090105@bell-labs.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.12] X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: sip-overload-bounces@ietf.org, sip-overload@ietf.org Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 15:23:28 -0000 Janet, the root of this discussion is probably that there is no definition of what local policies can be and what a valid local policy would be. I also don't think we should open this can worms right now, which is I think what you are suggesting also. I do think, however, that it is useful to provide explanation to a developer why we used a SHOULD here. We could say that it is expected a SIP client will follow local policy as long as the result leads to an acceptable load under current conditions. This way we're not giving an example for a bad policy. Thanks, Volker On 14.01.2013 16:09, Janet P Gunn wrote: > No, I don't like your added sentence. > > A VALID local policy prioritizes within the volume of messages permitted > by the algorithm. A VALID local policy doe not attempt to send more > messages than permitted by the Overload algorithm. > > A Local policy that attempts to override teh Overload Control Algorithm > is not permitted > > That is pretty clear in the wording of Req 13. > > > If you are going to say "MUST", then you must also define what > constitutes a VALID local policy, in some detail. > > If you are going to say "SHOULD", then you do not need to define a VALID > local policy in detail > > But the way you have written it implies that it is permissible to have > a Local Policy that attempts to override the Overload control > algorithm, and so must, in turn be over ridden by the Overload Algorithm. > > I don't even what to suggest that such a case would occur. I DO NOT > WANT TO MENTION IT. > > The SHOULD takes care of it. > > Janet > > sip-overload-bounces@ietf.org wrote on 01/14/2013 09:21:34 AM: > > > From: Volker Hilt > > To: > > Date: 01/14/2013 09:22 AM > > Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf- > > soc-load-control-event-package-05.txt > > Sent by: sip-overload-bounces@ietf.org > > > > I think SHOULD would, in fact, be the more appropriate wording here. > > There may be reasons why a local policy cannot be kept: a conflict with > > another policy, legal requirements, or very high levels of overload. > > > > In the end, the local policy will be a local matter including its > > enforcement. In other words, if a service provider has a SIP server that > > ignores his policies, I'm sure the service provide will know who to call. > > > > I've added a short explanatory sentence to the first paragraph: > > > > A SIP client SHOULD honor the local policy for prioritizing SIP requests > > such as policies based on message type, e.g., INVITEs vs. requests > > associated with existing sessions. A SIP client is expected generally to > > honor local policy except for very rare occasions when, for example, > > overload is so severe that messages, which should be preserved according > > to local policy, need to be discarded or local policies are in conflict. > > > > A SIP client SHOULD honor the local policy for prioritizing SIP requests > > based on the content of the Resource-Priority header (RPH, RFC4412 > > [RFC4412]). Specific (namespace.value) RPH contents may indicate high > > priority requests that should be preserved as much as possible during > > overload. The RPH contents can also indicate a low-priority request > > that is eligible to be dropped during times of overload. > > > > A SIP client SHOULD honor the local policy for prioritizing SIP requests > > relating to emergency calls, as identified by the SOS URN [RFC5031] > > indicating an emergency request. > > > > Thanks, > > > > Volker [as individual] > > > > > > > > > > On 14.01.2013 13:56, Salvatore Loreto wrote: > > > my reading of the mailing list is that the question of using SHOULD > > > versus MUST > > > is being decided in favor of MUST > > > > > > however it would be great to also address the Valker concerns > > > inserting a caveat/constraints explaining that the local policy can not > > > override the overload mechanism/algorithm > > > > > > can someone propose text ? > > > > > > note this is the only remaining issue that we have to address in this > > > event-package draft > > > before we can ship to the IESG > > > > > > /Salvatore > > > > > > > > > On 1/11/13 4:25 PM, Janet P Gunn wrote: > > >> > > >> Good point > > >> > > >> If you say it MUST honor "local policy", then you need constraints > > >> on what the local policy can do (e.g., it can only prioritize within > > >> the number of messages permitted by the overload algorithm, it can't > > >> over ride the overload mechanism/algorithm) > > >> > > >> Janet > > >> > > >> > > >> > > >> sip-overload-bounces@ietf.org wrote on 01/11/2013 09:06:58 AM: > > >> > > >> > From: Volker Hilt > > >> > To: > > >> > Date: 01/11/2013 09:07 AM > > >> > Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf- > > >> > soc-load-control-event-package-05.txt > > >> > Sent by: sip-overload-bounces@ietf.org > > >> > > > >> > Janet, All, > > >> > > > >> > while this sounds good in most cases, the concern I have is that > there > > >> > may be situation where a proxy is forced to violate local > policy. E.g., > > >> > a policy "emergency calls can never be dropped" will have to be > > >> violated > > >> > eventually if overload reaches levels where only emergency calls are > > >> left. > > >> > > > >> > Maybe this boils down to formulating policies in a reasonable > way. It > > >> > has to be made clear, however, that not all policies call be > kept under > > >> > all circumstances. > > >> > > > >> > A SHOULD would imply this to the developer. With a MUST, I think one > > >> > would have to add explanatory text. > > >> > > > >> > Thanks, > > >> > > > >> > Volker [with individual contributor hat on] > > >> > > > >> > > > >> > > > >> > On 03.01.2013 18:52, Janet P Gunn wrote: > > >> > > I prefer MUST to SHOULD. > > >> > > > > >> > > The original wording was based on Req 13 of RFC 5390: > > >> > > " REQ 13: The mechanism must not dictate a specific algorithm for > > >> > > prioritizing the processing of work within a proxy during > > >> times of > > >> > > overload*. It must permit a proxy to prioritize requests > > >> based on* > > >> > > * any local policy*, so that certain ones (such as a call for > > >> > > emergency services or a call with a specific value of the > > >> > > Resource-Priority header field [RFC4412]) are given > > >> preferential > > >> > > treatment, such as not being dropped, being given > additional > > >> > > retransmission, or being processed ahead of others." > > >> > > > > >> > > which has a lower case "must". > > >> > > > > >> > > If we are going to say "MUST honor" (rather than "must permit"), I > > >> think > > >> > > we need to change "any" to "the" . (you can permit many > alternatives, > > >> > > but you can really only honor one). I think this also > reflects the > > >> > > intent of Martin's comment > > >> > > > > >> > > So I would prefer > > >> > > > > >> > > > > >> > > A SIP client MUST honor *the *local policy for prioritizing SIP > > >> > > requests such as policies based on message type, e.g., > INVITEs vs. > > >> > > requests associated with existing sessions. > > >> > > > > >> > > A SIP client MUST honor *the *local policy for prioritizing SIP > > >> > > requests based on the content of the Resource-Priority > header (RPH, > > >> > > RFC4412 [RFC4412]). Specific (namespace.value) RPH > contents may > > >> > > indicate high priority requests that should be preserved as > much as > > >> > > possible during overload. The RPH contents can also indicate a > > >> > > low-priority request that is eligible to be dropped during > times of > > >> > > overload. > > >> > > > > >> > > A SIP client MUST honor *the *local policy for prioritizing SIP > > >> > > requests relating to emergency calls, as identified by the SOS > > >> > > URN [RFC5031] indicating an emergency request. > > >> > > > > >> > > > > >> > > Thanks > > >> > > > > >> > > Janet > > >> > > > > >> > > This is a PRIVATE message. If you are not the intended recipient, > > >> please > > >> > > delete without copying and kindly advise us by e-mail of the > > >> mistake in > > >> > > delivery. NOTE: Regardless of content, this e-mail shall not > > >> operate to > > >> > > bind CSC to any order or other contract unless pursuant to > explicit > > >> > > written agreement or government initiative expressly permitting > > >> the use > > >> > > of e-mail for such purpose. > > >> > > > > >> > > > > >> > > > > >> > > From: "Vijay K. Gurbani" > > >> > > To: Charles Shen > > >> > > Cc: "DRAGE, Keith (Keith)" , > Janet P > > >> > > Gunn/USA/CSC@CSC, "sip-overload@ietf.org" , > > >> Arata > > >> > > Koike , "NOEL, ERIC (ERIC C)" > > >> > > , Henning Schulzrinne > > >> > > Date: 01/03/2013 11:42 AM > > >> > > Subject: Re: [sip-overload] Local Policy Re: I-D Action: > > >> > > draft-ietf-soc-load-control-event-package-05.txt > > >> > > > > >> > ------------------------------------------------------------------------ > > >> > > > > >> > > > > >> > > > > >> > > On 01/03/2013 07:34 AM, Charles Shen wrote: > > >> > > > Sounds good, I can update the wording in the event package > > >> draft, if > > >> > > > Vijay is OK with the other one. > > >> > > > > >> > > I just want to make sure we are all agreeing to the same thing. > > >> > > > > >> > > It seems to me that the question of using SHOULD versus MUST > is being > > >> > > decided slightly in favour of a MUST. Martin and Bruno prefer > a MUST, > > >> > > Janet is okay with, although her original text used a SHOULD; and > > >> Keith > > >> > > could go either way. > > >> > > > > >> > > Is the consensus, then, that the text on honoring local policy > > >> contains > > >> > > MUST? If so, the text to be inserted would be the following: > > >> > > > > >> > > A SIP client MUST honor any local policy for prioritizing SIP > > >> > > requests such as policies based on message type, e.g., > INVITEs vs. > > >> > > requests associated with existing sessions. > > >> > > > > >> > > A SIP client MUST honor any local policy for prioritizing SIP > > >> > > requests based on the content of the Resource-Priority > header (RPH, > > >> > > RFC4412 [RFC4412]). Specific (namespace.value) RPH > contents may > > >> > > indicate high priority requests that should be preserved as > much as > > >> > > possible during overload. The RPH contents can also indicate a > > >> > > low-priority request that is eligible to be dropped during > times of > > >> > > overload. > > >> > > > > >> > > A SIP client MUST honor any local policy for prioritizing SIP > > >> > > requests relating to emergency calls, as identified by the SOS > > >> > > URN [RFC5031] indicating an emergency request. > > >> > > > > >> > > Yes? > > >> > > > > >> > > 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 > > >> > > > > >> > _______________________________________________ > > >> > sip-overload mailing list > > >> > sip-overload@ietf.org > > >> > https://www.ietf.org/mailman/listinfo/sip-overload > > >> > > >> > > >> _______________________________________________ > > >> sip-overload mailing list > > >> sip-overload@ietf.org > > >> https://www.ietf.org/mailman/listinfo/sip-overload > > > > > > > > > -- > > > Salvatore Loreto, PhD > > > www.sloreto.com > > > > > > > > > > > > _______________________________________________ > > > sip-overload mailing list > > > sip-overload@ietf.org > > > https://www.ietf.org/mailman/listinfo/sip-overload > > > > > _______________________________________________ > > sip-overload mailing list > > sip-overload@ietf.org > > https://www.ietf.org/mailman/listinfo/sip-overload From jgunn6@csc.com Mon Jan 14 08:04:45 2013 Return-Path: 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 516FA21F8738; Mon, 14 Jan 2013 08:04:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.037 X-Spam-Level: X-Spam-Status: No, score=-6.037 tagged_above=-999 required=5 tests=[AWL=0.560, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 UjwUcXVGKsAX; Mon, 14 Jan 2013 08:04:41 -0800 (PST) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.255.50]) by ietfa.amsl.com (Postfix) with ESMTP id B453421F86BA; Mon, 14 Jan 2013 08:04:40 -0800 (PST) Received: from [216.82.253.243:41857] by server-16.bemta-7.messagelabs.com id 47/7F-02467-89C24F05; Mon, 14 Jan 2013 16:04:40 +0000 X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-7.tower-171.messagelabs.com!1358179477!19829317!1 X-Originating-IP: [20.137.2.88] X-StarScan-Received: X-StarScan-Version: 6.6.1.8; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21817 invoked from network); 14 Jan 2013 16:04:39 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-7.tower-171.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Jan 2013 16:04:39 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r0EG4OUW003195; Mon, 14 Jan 2013 11:04:36 -0500 In-Reply-To: <50F422E4.8010809@bell-labs.com> References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> <24674_1355758104_50CF3A18_24674_468_1_88CAD1D4E8773F42858B58CAA28272A00E2A2C@PEXCVZYM12.corporate.adroot.infra.ftgroup> <50E5B529.2090105@bell-labs.com> To: Volker Hilt MIME-Version: 1.0 X-KeepSent: 5077D3D0:BC87BCA4-85257AF3:00582679; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Mon, 14 Jan 2013 11:04:31 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 01/14/2013 10:59:34 AM, Serialize complete at 01/14/2013 10:59:34 AM Content-Type: multipart/alternative; boundary="=_alternative 00584E1B85257AF3_=" Cc: sip-overload-bounces@ietf.org, sip-overload@ietf.org Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 16:04:45 -0000 This is a multipart message in MIME format. --=_alternative 00584E1B85257AF3_= Content-Type: text/plain; charset="US-ASCII" I agree, except I would say "It is expected a SIP client will follow local policy as long as the result is consistent with the SIP Overload Algorithm." Janet Volker Hilt wrote on 01/14/2013 10:23:16 AM: > From: Volker Hilt > To: Janet P Gunn/USA/CSC@CSC > Cc: , > Date: 01/14/2013 10:23 AM > Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf- > soc-load-control-event-package-05.txt > > Janet, > > the root of this discussion is probably that there is no definition of > what local policies can be and what a valid local policy would be. I > also don't think we should open this can worms right now, which is I > think what you are suggesting also. > > I do think, however, that it is useful to provide explanation to a > developer why we used a SHOULD here. > > We could say that it is expected a SIP client will follow local policy > as long as the result leads to an acceptable load under current conditions. > > This way we're not giving an example for a bad policy. > > Thanks, > > Volker > > > > On 14.01.2013 16:09, Janet P Gunn wrote: > > No, I don't like your added sentence. > > > > A VALID local policy prioritizes within the volume of messages permitted > > by the algorithm. A VALID local policy doe not attempt to send more > > messages than permitted by the Overload algorithm. > > > > A Local policy that attempts to override teh Overload Control Algorithm > > is not permitted > > > > That is pretty clear in the wording of Req 13. > > > > > > If you are going to say "MUST", then you must also define what > > constitutes a VALID local policy, in some detail. > > > > If you are going to say "SHOULD", then you do not need to define a VALID > > local policy in detail > > > > But the way you have written it implies that it is permissible to have > > a Local Policy that attempts to override the Overload control > > algorithm, and so must, in turn be over ridden by the Overload Algorithm. > > > > I don't even what to suggest that such a case would occur. I DO NOT > > WANT TO MENTION IT. > > > > The SHOULD takes care of it. > > > > Janet > > > > sip-overload-bounces@ietf.org wrote on 01/14/2013 09:21:34 AM: > > > > > From: Volker Hilt > > > To: > > > Date: 01/14/2013 09:22 AM > > > Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf- > > > soc-load-control-event-package-05.txt > > > Sent by: sip-overload-bounces@ietf.org > > > > > > I think SHOULD would, in fact, be the more appropriate wording here. > > > There may be reasons why a local policy cannot be kept: a conflict with > > > another policy, legal requirements, or very high levels of overload. > > > > > > In the end, the local policy will be a local matter including its > > > enforcement. In other words, if a service provider has a SIP server that > > > ignores his policies, I'm sure the service provide will know who to call. > > > > > > I've added a short explanatory sentence to the first paragraph: > > > > > > A SIP client SHOULD honor the local policy for prioritizing SIP requests > > > such as policies based on message type, e.g., INVITEs vs. requests > > > associated with existing sessions. A SIP client is expected generally to > > > honor local policy except for very rare occasions when, for example, > > > overload is so severe that messages, which should be preserved according > > > to local policy, need to be discarded or local policies are in conflict. > > > > > > A SIP client SHOULD honor the local policy for prioritizing SIP requests > > > based on the content of the Resource-Priority header (RPH, RFC4412 > > > [RFC4412]). Specific (namespace.value) RPH contents may indicate high > > > priority requests that should be preserved as much as possible during > > > overload. The RPH contents can also indicate a low-priority request > > > that is eligible to be dropped during times of overload. > > > > > > A SIP client SHOULD honor the local policy for prioritizing SIP requests > > > relating to emergency calls, as identified by the SOS URN [RFC5031] > > > indicating an emergency request. > > > > > > Thanks, > > > > > > Volker [as individual] > > > > > > > > > > > > > > > On 14.01.2013 13:56, Salvatore Loreto wrote: > > > > my reading of the mailing list is that the question of using SHOULD > > > > versus MUST > > > > is being decided in favor of MUST > > > > > > > > however it would be great to also address the Valker concerns > > > > inserting a caveat/constraints explaining that the local policy can not > > > > override the overload mechanism/algorithm > > > > > > > > can someone propose text ? > > > > > > > > note this is the only remaining issue that we have to address in this > > > > event-package draft > > > > before we can ship to the IESG > > > > > > > > /Salvatore > > > > > > > > > > > > On 1/11/13 4:25 PM, Janet P Gunn wrote: > > > >> > > > >> Good point > > > >> > > > >> If you say it MUST honor "local policy", then you need constraints > > > >> on what the local policy can do (e.g., it can only prioritize within > > > >> the number of messages permitted by the overload algorithm, it can't > > > >> over ride the overload mechanism/algorithm) > > > >> > > > >> Janet > > > >> > > > >> > > > >> > > > >> sip-overload-bounces@ietf.org wrote on 01/11/2013 09:06:58 AM: > > > >> > > > >> > From: Volker Hilt > > > >> > To: > > > >> > Date: 01/11/2013 09:07 AM > > > >> > Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf- > > > >> > soc-load-control-event-package-05.txt > > > >> > Sent by: sip-overload-bounces@ietf.org > > > >> > > > > >> > Janet, All, > > > >> > > > > >> > while this sounds good in most cases, the concern I have is that > > there > > > >> > may be situation where a proxy is forced to violate local > > policy. E.g., > > > >> > a policy "emergency calls can never be dropped" will have to be > > > >> violated > > > >> > eventually if overload reaches levels where only emergencycalls are > > > >> left. > > > >> > > > > >> > Maybe this boils down to formulating policies in a reasonable > > way. It > > > >> > has to be made clear, however, that not all policies call be > > kept under > > > >> > all circumstances. > > > >> > > > > >> > A SHOULD would imply this to the developer. With a MUST, Ithink one > > > >> > would have to add explanatory text. > > > >> > > > > >> > Thanks, > > > >> > > > > >> > Volker [with individual contributor hat on] > > > >> > > > > >> > > > > >> > > > > >> > On 03.01.2013 18:52, Janet P Gunn wrote: > > > >> > > I prefer MUST to SHOULD. > > > >> > > > > > >> > > The original wording was based on Req 13 of RFC 5390: > > > >> > > " REQ 13: The mechanism must not dictate a specific algorithm for > > > >> > > prioritizing the processing of work within a proxy during > > > >> times of > > > >> > > overload*. It must permit a proxy to prioritize requests > > > >> based on* > > > >> > > * any local policy*, so that certain ones (such as a call for > > > >> > > emergency services or a call with a specific value of the > > > >> > > Resource-Priority header field [RFC4412]) are given > > > >> preferential > > > >> > > treatment, such as not being dropped, being given > > additional > > > >> > > retransmission, or being processed ahead of others." > > > >> > > > > > >> > > which has a lower case "must". > > > >> > > > > > >> > > If we are going to say "MUST honor" (rather than "must permit"), I > > > >> think > > > >> > > we need to change "any" to "the" . (you can permit many > > alternatives, > > > >> > > but you can really only honor one). I think this also > > reflects the > > > >> > > intent of Martin's comment > > > >> > > > > > >> > > So I would prefer > > > >> > > > > > >> > > > > > >> > > A SIP client MUST honor *the *local policy for prioritizing SIP > > > >> > > requests such as policies based on message type, e.g., > > INVITEs vs. > > > >> > > requests associated with existing sessions. > > > >> > > > > > >> > > A SIP client MUST honor *the *local policy for prioritizing SIP > > > >> > > requests based on the content of the Resource-Priority > > header (RPH, > > > >> > > RFC4412 [RFC4412]). Specific (namespace.value) RPH > > contents may > > > >> > > indicate high priority requests that should be preserved as > > much as > > > >> > > possible during overload. The RPH contents can also indicate a > > > >> > > low-priority request that is eligible to be dropped during > > times of > > > >> > > overload. > > > >> > > > > > >> > > A SIP client MUST honor *the *local policy for prioritizing SIP > > > >> > > requests relating to emergency calls, as identified by the SOS > > > >> > > URN [RFC5031] indicating an emergency request. > > > >> > > > > > >> > > > > > >> > > Thanks > > > >> > > > > > >> > > Janet > > > >> > > > > > >> > > This is a PRIVATE message. If you are not the intended recipient, > > > >> please > > > >> > > delete without copying and kindly advise us by e-mail of the > > > >> mistake in > > > >> > > delivery. NOTE: Regardless of content, this e-mail shall not > > > >> operate to > > > >> > > bind CSC to any order or other contract unless pursuant to > > explicit > > > >> > > written agreement or government initiative expressly permitting > > > >> the use > > > >> > > of e-mail for such purpose. > > > >> > > > > > >> > > > > > >> > > > > > >> > > From: "Vijay K. Gurbani" > > > >> > > To: Charles Shen > > > >> > > Cc: "DRAGE, Keith (Keith)" , > > Janet P > > > >> > > Gunn/USA/CSC@CSC, "sip-overload@ietf.org" , > > > >> Arata > > > >> > > Koike , "NOEL, ERIC (ERIC C)" > > > >> > > , Henning Schulzrinne > > > >> > > Date: 01/03/2013 11:42 AM > > > >> > > Subject: Re: [sip-overload] Local Policy Re: I-D Action: > > > >> > > draft-ietf-soc-load-control-event-package-05.txt > > > >> > > > > > >> > > ------------------------------------------------------------------------ > > > >> > > > > > >> > > > > > >> > > > > > >> > > On 01/03/2013 07:34 AM, Charles Shen wrote: > > > >> > > > Sounds good, I can update the wording in the event package > > > >> draft, if > > > >> > > > Vijay is OK with the other one. > > > >> > > > > > >> > > I just want to make sure we are all agreeing to the same thing. > > > >> > > > > > >> > > It seems to me that the question of using SHOULD versus MUST > > is being > > > >> > > decided slightly in favour of a MUST. Martin and Bruno prefer > > a MUST, > > > >> > > Janet is okay with, although her original text used a SHOULD; and > > > >> Keith > > > >> > > could go either way. > > > >> > > > > > >> > > Is the consensus, then, that the text on honoring local policy > > > >> contains > > > >> > > MUST? If so, the text to be inserted would be the following: > > > >> > > > > > >> > > A SIP client MUST honor any local policy for prioritizing SIP > > > >> > > requests such as policies based on message type, e.g., > > INVITEs vs. > > > >> > > requests associated with existing sessions. > > > >> > > > > > >> > > A SIP client MUST honor any local policy for prioritizing SIP > > > >> > > requests based on the content of the Resource-Priority > > header (RPH, > > > >> > > RFC4412 [RFC4412]). Specific (namespace.value) RPH > > contents may > > > >> > > indicate high priority requests that should be preserved as > > much as > > > >> > > possible during overload. The RPH contents can also indicate a > > > >> > > low-priority request that is eligible to be dropped during > > times of > > > >> > > overload. > > > >> > > > > > >> > > A SIP client MUST honor any local policy for prioritizing SIP > > > >> > > requests relating to emergency calls, as identified by the SOS > > > >> > > URN [RFC5031] indicating an emergency request. > > > >> > > > > > >> > > Yes? > > > >> > > > > > >> > > 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 > > > >> > > > > > >> > _______________________________________________ > > > >> > sip-overload mailing list > > > >> > sip-overload@ietf.org > > > >> > https://www.ietf.org/mailman/listinfo/sip-overload > > > >> > > > >> > > > >> _______________________________________________ > > > >> sip-overload mailing list > > > >> sip-overload@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/sip-overload > > > > > > > > > > > > -- > > > > Salvatore Loreto, PhD > > > > www.sloreto.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > sip-overload mailing list > > > > sip-overload@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sip-overload > > > > > > > _______________________________________________ > > > sip-overload mailing list > > > sip-overload@ietf.org > > > https://www.ietf.org/mailman/listinfo/sip-overload --=_alternative 00584E1B85257AF3_= Content-Type: text/html; charset="US-ASCII"
I agree, except I would say

"It is expected a SIP client will follow local policy
as long as the result is consistent with the SIP Overload Algorithm."

Janet

Volker Hilt <volker.hilt@bell-labs.com> wrote on 01/14/2013 10:23:16 AM:

> From: Volker Hilt <volker.hilt@bell-labs.com>
> To: Janet P Gunn/USA/CSC@CSC
> Cc: <sip-overload@ietf.org>, <sip-overload-bounces@ietf.org>
> Date: 01/14/2013 10:23 AM
> Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-
> soc-load-control-event-package-05.txt
>
> Janet,
>
> the root of this discussion is probably that there is no definition of
> what local policies can be and what a valid local policy would be. I
> also don't think we should open this can worms right now, which is I
> think what you are suggesting also.
>
> I do think, however, that it is useful to provide explanation to a
> developer why we used a SHOULD here.
>
> We could say that it is expected a SIP client will follow local policy
> as long as the result leads to an acceptable load under current conditions.
>
> This way we're not giving an example for a bad policy.
>
> Thanks,
>
> Volker
>
>
>
> On 14.01.2013 16:09, Janet P Gunn wrote:
> > No, I don't like your added sentence.
> >
> > A VALID local policy prioritizes within the volume of messages permitted
> > by the algorithm.   A VALID local policy doe not attempt to send more
> > messages than permitted by the Overload algorithm.
> >
> > A Local policy that attempts to override teh Overload Control Algorithm
> > is not permitted
> >
> > That is pretty clear in the wording of Req 13.
> >
> >
> > If you are going to say "MUST", then you must also define what
> > constitutes a VALID local policy, in some detail.
> >
> > If you are going to say "SHOULD", then you do not need to define a VALID
> > local  policy in detail
> >
> > But the way you have written it implies that it is permissible to have
> >   a Local Policy that  attempts to override the Overload control
> > algorithm, and so must, in turn  be over ridden by the Overload Algorithm.
> >
> > I don't even what to suggest that such a case would occur.    I DO NOT
> > WANT TO MENTION IT.
> >
> > The SHOULD takes care of it.
> >
> > Janet
> >
> > sip-overload-bounces@ietf.org wrote on 01/14/2013 09:21:34 AM:
> >
> >  > From: Volker Hilt <volker.hilt@bell-labs.com>
> >  > To: <sip-overload@ietf.org>
> >  > Date: 01/14/2013 09:22 AM
> >  > Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-
> >  > soc-load-control-event-package-05.txt
> >  > Sent by: sip-overload-bounces@ietf.org
> >  >
> >  > I think SHOULD would, in fact, be the more appropriate wording here.
> >  > There may be reasons why a local policy cannot be kept: a conflict with
> >  > another policy, legal requirements, or very high levels of overload.
> >  >
> >  > In the end, the local policy will be a local matter including its
> >  > enforcement. In other words, if a service provider has a SIP server that
> >  > ignores his policies, I'm sure the service provide will know who to call.
> >  >
> >  > I've added a short explanatory sentence to the first paragraph:
> >  >
> >  > A SIP client SHOULD honor the local policy for prioritizing SIP requests
> >  > such as policies based on message type, e.g., INVITEs vs. requests
> >  > associated with existing sessions. A SIP client is expected generally to
> >  > honor local policy except for very rare occasions when, for example,
> >  > overload is so severe that messages, which should be preserved according
> >  > to local policy, need to be discarded or local policies are in conflict.
> >  >
> >  > A SIP client SHOULD honor the local policy for prioritizing SIP requests
> >  > based on the content of the Resource-Priority header (RPH, RFC4412
> >  > [RFC4412]).  Specific (namespace.value) RPH contents may indicate high
> >  > priority requests that should be preserved as much as possible during
> >  > overload.  The RPH contents can also indicate a low-priority request
> >  > that is eligible to be dropped during times of overload.
> >  >
> >  > A SIP client SHOULD honor the local policy for prioritizing SIP requests
> >  > relating to emergency calls, as identified by the SOS URN [RFC5031]
> >  > indicating an emergency request.
> >  >
> >  > Thanks,
> >  >
> >  > Volker [as individual]
> >  >
> >  >
> >  >
> >  >
> >  > On 14.01.2013 13:56, Salvatore Loreto wrote:
> >  > > my reading of the mailing list is that the question of using SHOULD
> >  > > versus MUST
> >  > > is being decided in favor of MUST
> >  > >
> >  > > however it would be great to also address the Valker concerns
> >  > > inserting a caveat/constraints explaining that the local policy can not
> >  > > override the overload mechanism/algorithm
> >  > >
> >  > > can someone propose text ?
> >  > >
> >  > > note this is the only remaining issue that we have to address in this
> >  > > event-package draft
> >  > > before we can ship to the IESG
> >  > >
> >  > > /Salvatore
> >  > >
> >  > >
> >  > > On 1/11/13 4:25 PM, Janet P Gunn wrote:
> >  > >>
> >  > >> Good point
> >  > >>
> >  > >> If you say it MUST honor "local policy", then you  need  constraints
> >  > >> on what the local policy can do (e.g., it can only prioritize within
> >  > >> the number of messages permitted by the overload algorithm, it can't
> >  > >> over ride the overload mechanism/algorithm)
> >  > >>
> >  > >> Janet
> >  > >>
> >  > >>
> >  > >>
> >  > >> sip-overload-bounces@ietf.org wrote on 01/11/2013 09:06:58 AM:
> >  > >>
> >  > >> > From: Volker Hilt <volker.hilt@bell-labs.com>
> >  > >> > To: <sip-overload@ietf.org>
> >  > >> > Date: 01/11/2013 09:07 AM
> >  > >> > Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-
> >  > >> > soc-load-control-event-package-05.txt
> >  > >> > Sent by: sip-overload-bounces@ietf.org
> >  > >> >
> >  > >> > Janet, All,
> >  > >> >
> >  > >> > while this sounds good in most cases, the concern I have is that
> > there
> >  > >> > may be situation where a proxy is forced to violate local
> > policy. E.g.,
> >  > >> > a policy "emergency calls can never be dropped" will have to be
> >  > >> violated
> >  > >> > eventually if overload reaches levels where only emergencycalls are
> >  > >> left.
> >  > >> >
> >  > >> > Maybe this boils down to formulating policies in a reasonable
> > way. It
> >  > >> > has to be made clear, however, that not all policies call be
> > kept under
> >  > >> > all circumstances.
> >  > >> >
> >  > >> > A SHOULD would imply this to the developer. With a MUST, Ithink one
> >  > >> > would have to add explanatory text.
> >  > >> >
> >  > >> > Thanks,
> >  > >> >
> >  > >> > Volker [with individual contributor hat on]
> >  > >> >
> >  > >> >
> >  > >> >
> >  > >> > On 03.01.2013 18:52, Janet P Gunn wrote:
> >  > >> > > I prefer MUST to SHOULD.
> >  > >> > >
> >  > >> > > The original wording was based on Req 13 of RFC 5390:
> >  > >> > > " REQ 13:  The mechanism must not dictate a specific algorithm for
> >  > >> > >        prioritizing the processing of work within a proxy during
> >  > >> times of
> >  > >> > >        overload*.  It must permit a proxy to prioritize requests
> >  > >> based on*
> >  > >> > > *      any local policy*, so that certain ones (such as a call for
> >  > >> > >        emergency services or a call with a specific value of the
> >  > >> > >        Resource-Priority header field [RFC4412]) are given
> >  > >> preferential
> >  > >> > >        treatment, such as not being dropped, being given
> > additional
> >  > >> > >        retransmission, or being processed ahead of others."
> >  > >> > >
> >  > >> > > which has a lower case "must".
> >  > >> > >
> >  > >> > > If we are going to say "MUST honor" (rather than "must permit"), I
> >  > >> think
> >  > >> > > we need to change "any" to "the" . (you can permit many
> > alternatives,
> >  > >> > > but you can really only honor one).  I think this also
> > reflects the
> >  > >> > > intent of Martin's  comment
> >  > >> > >
> >  > >> > > So I would prefer
> >  > >> > >
> >  > >> > >
> >  > >> > >    A SIP client MUST honor *the *local policy for prioritizing SIP
> >  > >> > >    requests such as policies based on message type, e.g.,
> > INVITEs vs.
> >  > >> > >    requests associated with existing sessions.
> >  > >> > >
> >  > >> > >    A SIP client MUST honor *the *local policy for prioritizing SIP
> >  > >> > >    requests based on the content of the Resource-Priority
> > header (RPH,
> >  > >> > >    RFC4412 [RFC4412]).  Specific (namespace.value) RPH
> > contents may
> >  > >> > >    indicate high priority requests that should be preserved as
> > much as
> >  > >> > >    possible during overload.  The RPH contents can also indicate a
> >  > >> > >    low-priority request that is eligible to be dropped during
> > times of
> >  > >> > >    overload.
> >  > >> > >
> >  > >> > >    A SIP client MUST honor *the *local policy for prioritizing SIP
> >  > >> > >    requests relating to emergency calls, as identified by the SOS
> >  > >> > >    URN [RFC5031] indicating an emergency request.
> >  > >> > >
> >  > >> > >
> >  > >> > > Thanks
> >  > >> > >
> >  > >> > > Janet
> >  > >> > >
> >  > >> > > This is a PRIVATE message. If you are not the intended recipient,
> >  > >> please
> >  > >> > > delete without copying and kindly advise us by e-mail of the
> >  > >> mistake in
> >  > >> > > delivery. NOTE: Regardless of content, this e-mail shall not
> >  > >> operate to
> >  > >> > > bind CSC to any order or other contract unless pursuant to
> > explicit
> >  > >> > > written agreement or government initiative expressly permitting
> >  > >> the use
> >  > >> > > of e-mail for such purpose.
> >  > >> > >
> >  > >> > >
> >  > >> > >
> >  > >> > > From: "Vijay K. Gurbani" <vkg@bell-labs.com>
> >  > >> > > To: Charles Shen <charles@cs.columbia.edu>
> >  > >> > > Cc: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>,
> > Janet P
> >  > >> > > Gunn/USA/CSC@CSC, "sip-overload@ietf.org" <sip-overload@ietf.org>,
> >  > >> Arata
> >  > >> > > Koike <koike.arata@lab.ntt.co.jp>, "NOEL, ERIC (ERIC C)"
> >  > >> > > <ecnoel@att.com>, Henning Schulzrinne <hgs@cs.columbia.edu>
> >  > >> > > Date: 01/03/2013 11:42 AM
> >  > >> > > Subject: Re: [sip-overload] Local Policy Re: I-D Action:
> >  > >> > > draft-ietf-soc-load-control-event-package-05.txt
> >  > >> > >
> >  > >>
> > ------------------------------------------------------------------------
> >  > >> > >
> >  > >> > >
> >  > >> > >
> >  > >> > > On 01/03/2013 07:34 AM, Charles Shen wrote:
> >  > >> > >  > Sounds good, I can update the wording in the event package
> >  > >> draft, if
> >  > >> > >  > Vijay is OK with the other one.
> >  > >> > >
> >  > >> > > I just want to make sure we are all agreeing to the same thing.
> >  > >> > >
> >  > >> > > It seems to me that the question of using SHOULD versus MUST
> > is being
> >  > >> > > decided slightly in favour of a MUST.  Martin and Bruno prefer
> > a MUST,
> >  > >> > > Janet is okay with, although her original text used a SHOULD; and
> >  > >> Keith
> >  > >> > > could go either way.
> >  > >> > >
> >  > >> > > Is the consensus, then, that the text on honoring local policy
> >  > >> contains
> >  > >> > > MUST?  If so, the text to be inserted would be the following:
> >  > >> > >
> >  > >> > >    A SIP client MUST honor any local policy for prioritizing SIP
> >  > >> > >    requests such as policies based on message type, e.g.,
> > INVITEs vs.
> >  > >> > >    requests associated with existing sessions.
> >  > >> > >
> >  > >> > >    A SIP client MUST honor any local policy for prioritizing SIP
> >  > >> > >    requests based on the content of the Resource-Priority
> > header (RPH,
> >  > >> > >    RFC4412 [RFC4412]).  Specific (namespace.value) RPH
> > contents may
> >  > >> > >    indicate high priority requests that should be preserved as
> > much as
> >  > >> > >    possible during overload.  The RPH contents can also indicate a
> >  > >> > >    low-priority request that is eligible to be dropped during
> > times of
> >  > >> > >    overload.
> >  > >> > >
> >  > >> > >    A SIP client MUST honor any local policy for prioritizing SIP
> >  > >> > >    requests relating to emergency calls, as identified by the SOS
> >  > >> > >    URN [RFC5031] indicating an emergency request.
> >  > >> > >
> >  > >> > > Yes?
> >  > >> > >
> >  > >> > > 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
> >  > >> > >
> >  > >> > _______________________________________________
> >  > >> > sip-overload mailing list
> >  > >> > sip-overload@ietf.org
> >  > >> > https://www.ietf.org/mailman/listinfo/sip-overload
> >  > >>
> >  > >>
> >  > >> _______________________________________________
> >  > >> sip-overload mailing list
> >  > >> sip-overload@ietf.org
> >  > >> https://www.ietf.org/mailman/listinfo/sip-overload
> >  > >
> >  > >
> >  > > --
> >  > > Salvatore Loreto, PhD
> >  > > www.sloreto.com
> >  > >
> >  > >
> >  > >
> >  > > _______________________________________________
> >  > > sip-overload mailing list
> >  > > sip-overload@ietf.org
> >  > > https://www.ietf.org/mailman/listinfo/sip-overload
> >  > >
> >  > _______________________________________________
> >  > sip-overload mailing list
> >  > sip-overload@ietf.org
> >  > https://www.ietf.org/mailman/listinfo/sip-overload
 --=_alternative 00584E1B85257AF3_=-- From volker.hilt@bell-labs.com Mon Jan 14 08:09:18 2013 Return-Path: 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 C0D0521F87A6 for ; Mon, 14 Jan 2013 08:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.249 X-Spam-Level: X-Spam-Status: No, score=-8.249 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 Nxj3VGAhbMT0 for ; Mon, 14 Jan 2013 08:09:17 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0FEC021F8447 for ; Mon, 14 Jan 2013 08:09:16 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r0EG99Iv009567 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 14 Jan 2013 17:09:13 +0100 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 14 Jan 2013 17:09:11 +0100 Received: from [135.244.178.1] (135.239.27.12) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 14 Jan 2013 17:09:11 +0100 Message-ID: <50F42D9F.1080002@bell-labs.com> Date: Mon, 14 Jan 2013 17:09:03 +0100 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> <24674_1355758104_50CF3A18_24674_468_1_88CAD1D4E8773F42858B58CAA28272A00E2A2C@PEXCVZYM12.corporate.adroot.infra.ftgroup> <50E5B529.2090105@bell-labs.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.12] X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 16:09:18 -0000 That works for me! Volker On 14.01.2013 17:04, Janet P Gunn wrote: > > I agree, except I would say > > "It is expected a SIP client will follow local policy > as long as the result is consistent with the SIP Overload Algorithm." > > Janet > > Volker Hilt wrote on 01/14/2013 10:23:16 AM: > > > From: Volker Hilt > > To: Janet P Gunn/USA/CSC@CSC > > Cc: , > > Date: 01/14/2013 10:23 AM > > Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf- > > soc-load-control-event-package-05.txt > > > > Janet, > > > > the root of this discussion is probably that there is no definition of > > what local policies can be and what a valid local policy would be. I > > also don't think we should open this can worms right now, which is I > > think what you are suggesting also. > > > > I do think, however, that it is useful to provide explanation to a > > developer why we used a SHOULD here. > > > > We could say that it is expected a SIP client will follow local policy > > as long as the result leads to an acceptable load under current > conditions. > > > > This way we're not giving an example for a bad policy. > > > > Thanks, > > > > Volker > > > > > > > > On 14.01.2013 16:09, Janet P Gunn wrote: > > > No, I don't like your added sentence. > > > > > > A VALID local policy prioritizes within the volume of messages > permitted > > > by the algorithm. A VALID local policy doe not attempt to send more > > > messages than permitted by the Overload algorithm. > > > > > > A Local policy that attempts to override teh Overload Control Algorithm > > > is not permitted > > > > > > That is pretty clear in the wording of Req 13. > > > > > > > > > If you are going to say "MUST", then you must also define what > > > constitutes a VALID local policy, in some detail. > > > > > > If you are going to say "SHOULD", then you do not need to define a > VALID > > > local policy in detail > > > > > > But the way you have written it implies that it is permissible to have > > > a Local Policy that attempts to override the Overload control > > > algorithm, and so must, in turn be over ridden by the Overload > Algorithm. > > > > > > I don't even what to suggest that such a case would occur. I DO NOT > > > WANT TO MENTION IT. > > > > > > The SHOULD takes care of it. > > > > > > Janet > > > > > > sip-overload-bounces@ietf.org wrote on 01/14/2013 09:21:34 AM: > > > > > > > From: Volker Hilt > > > > To: > > > > Date: 01/14/2013 09:22 AM > > > > Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf- > > > > soc-load-control-event-package-05.txt > > > > Sent by: sip-overload-bounces@ietf.org > > > > > > > > I think SHOULD would, in fact, be the more appropriate wording here. > > > > There may be reasons why a local policy cannot be kept: a > conflict with > > > > another policy, legal requirements, or very high levels of overload. > > > > > > > > In the end, the local policy will be a local matter including its > > > > enforcement. In other words, if a service provider has a SIP > server that > > > > ignores his policies, I'm sure the service provide will know who > to call. > > > > > > > > I've added a short explanatory sentence to the first paragraph: > > > > > > > > A SIP client SHOULD honor the local policy for prioritizing SIP > requests > > > > such as policies based on message type, e.g., INVITEs vs. requests > > > > associated with existing sessions. A SIP client is expected > generally to > > > > honor local policy except for very rare occasions when, for example, > > > > overload is so severe that messages, which should be preserved > according > > > > to local policy, need to be discarded or local policies are in > conflict. > > > > > > > > A SIP client SHOULD honor the local policy for prioritizing SIP > requests > > > > based on the content of the Resource-Priority header (RPH, RFC4412 > > > > [RFC4412]). Specific (namespace.value) RPH contents may > indicate high > > > > priority requests that should be preserved as much as possible > during > > > > overload. The RPH contents can also indicate a low-priority request > > > > that is eligible to be dropped during times of overload. > > > > > > > > A SIP client SHOULD honor the local policy for prioritizing SIP > requests > > > > relating to emergency calls, as identified by the SOS URN [RFC5031] > > > > indicating an emergency request. > > > > > > > > Thanks, > > > > > > > > Volker [as individual] > > > > > > > > > > > > > > > > > > > > On 14.01.2013 13:56, Salvatore Loreto wrote: > > > > > my reading of the mailing list is that the question of using > SHOULD > > > > > versus MUST > > > > > is being decided in favor of MUST > > > > > > > > > > however it would be great to also address the Valker concerns > > > > > inserting a caveat/constraints explaining that the local > policy can not > > > > > override the overload mechanism/algorithm > > > > > > > > > > can someone propose text ? > > > > > > > > > > note this is the only remaining issue that we have to address > in this > > > > > event-package draft > > > > > before we can ship to the IESG > > > > > > > > > > /Salvatore > > > > > > > > > > > > > > > On 1/11/13 4:25 PM, Janet P Gunn wrote: > > > > >> > > > > >> Good point > > > > >> > > > > >> If you say it MUST honor "local policy", then you need > constraints > > > > >> on what the local policy can do (e.g., it can only prioritize > within > > > > >> the number of messages permitted by the overload algorithm, > it can't > > > > >> over ride the overload mechanism/algorithm) > > > > >> > > > > >> Janet > > > > >> > > > > >> > > > > >> > > > > >> sip-overload-bounces@ietf.org wrote on 01/11/2013 09:06:58 AM: > > > > >> > > > > >> > From: Volker Hilt > > > > >> > To: > > > > >> > Date: 01/11/2013 09:07 AM > > > > >> > Subject: Re: [sip-overload] Local Policy Re: I-D Action: > draft-ietf- > > > > >> > soc-load-control-event-package-05.txt > > > > >> > Sent by: sip-overload-bounces@ietf.org > > > > >> > > > > > >> > Janet, All, > > > > >> > > > > > >> > while this sounds good in most cases, the concern I have is > that > > > there > > > > >> > may be situation where a proxy is forced to violate local > > > policy. E.g., > > > > >> > a policy "emergency calls can never be dropped" will have to be > > > > >> violated > > > > >> > eventually if overload reaches levels where only > emergencycalls are > > > > >> left. > > > > >> > > > > > >> > Maybe this boils down to formulating policies in a reasonable > > > way. It > > > > >> > has to be made clear, however, that not all policies call be > > > kept under > > > > >> > all circumstances. > > > > >> > > > > > >> > A SHOULD would imply this to the developer. With a MUST, > Ithink one > > > > >> > would have to add explanatory text. > > > > >> > > > > > >> > Thanks, > > > > >> > > > > > >> > Volker [with individual contributor hat on] > > > > >> > > > > > >> > > > > > >> > > > > > >> > On 03.01.2013 18:52, Janet P Gunn wrote: > > > > >> > > I prefer MUST to SHOULD. > > > > >> > > > > > > >> > > The original wording was based on Req 13 of RFC 5390: > > > > >> > > " REQ 13: The mechanism must not dictate a specific > algorithm for > > > > >> > > prioritizing the processing of work within a proxy > during > > > > >> times of > > > > >> > > overload*. It must permit a proxy to prioritize > requests > > > > >> based on* > > > > >> > > * any local policy*, so that certain ones (such as a > call for > > > > >> > > emergency services or a call with a specific value > of the > > > > >> > > Resource-Priority header field [RFC4412]) are given > > > > >> preferential > > > > >> > > treatment, such as not being dropped, being given > > > additional > > > > >> > > retransmission, or being processed ahead of others." > > > > >> > > > > > > >> > > which has a lower case "must". > > > > >> > > > > > > >> > > If we are going to say "MUST honor" (rather than "must > permit"), I > > > > >> think > > > > >> > > we need to change "any" to "the" . (you can permit many > > > alternatives, > > > > >> > > but you can really only honor one). I think this also > > > reflects the > > > > >> > > intent of Martin's comment > > > > >> > > > > > > >> > > So I would prefer > > > > >> > > > > > > >> > > > > > > >> > > A SIP client MUST honor *the *local policy for > prioritizing SIP > > > > >> > > requests such as policies based on message type, e.g., > > > INVITEs vs. > > > > >> > > requests associated with existing sessions. > > > > >> > > > > > > >> > > A SIP client MUST honor *the *local policy for > prioritizing SIP > > > > >> > > requests based on the content of the Resource-Priority > > > header (RPH, > > > > >> > > RFC4412 [RFC4412]). Specific (namespace.value) RPH > > > contents may > > > > >> > > indicate high priority requests that should be > preserved as > > > much as > > > > >> > > possible during overload. The RPH contents can also > indicate a > > > > >> > > low-priority request that is eligible to be dropped during > > > times of > > > > >> > > overload. > > > > >> > > > > > > >> > > A SIP client MUST honor *the *local policy for > prioritizing SIP > > > > >> > > requests relating to emergency calls, as identified by > the SOS > > > > >> > > URN [RFC5031] indicating an emergency request. > > > > >> > > > > > > >> > > > > > > >> > > Thanks > > > > >> > > > > > > >> > > Janet > > > > >> > > > > > > >> > > This is a PRIVATE message. If you are not the intended > recipient, > > > > >> please > > > > >> > > delete without copying and kindly advise us by e-mail of the > > > > >> mistake in > > > > >> > > delivery. NOTE: Regardless of content, this e-mail shall not > > > > >> operate to > > > > >> > > bind CSC to any order or other contract unless pursuant to > > > explicit > > > > >> > > written agreement or government initiative expressly > permitting > > > > >> the use > > > > >> > > of e-mail for such purpose. > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > From: "Vijay K. Gurbani" > > > > >> > > To: Charles Shen > > > > >> > > Cc: "DRAGE, Keith (Keith)" , > > > Janet P > > > > >> > > Gunn/USA/CSC@CSC, "sip-overload@ietf.org" > , > > > > >> Arata > > > > >> > > Koike , "NOEL, ERIC (ERIC C)" > > > > >> > > , Henning Schulzrinne > > > > >> > > Date: 01/03/2013 11:42 AM > > > > >> > > Subject: Re: [sip-overload] Local Policy Re: I-D Action: > > > > >> > > draft-ietf-soc-load-control-event-package-05.txt > > > > >> > > > > > > >> > > > > ------------------------------------------------------------------------ > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > On 01/03/2013 07:34 AM, Charles Shen wrote: > > > > >> > > > Sounds good, I can update the wording in the event package > > > > >> draft, if > > > > >> > > > Vijay is OK with the other one. > > > > >> > > > > > > >> > > I just want to make sure we are all agreeing to the same > thing. > > > > >> > > > > > > >> > > It seems to me that the question of using SHOULD versus MUST > > > is being > > > > >> > > decided slightly in favour of a MUST. Martin and Bruno > prefer > > > a MUST, > > > > >> > > Janet is okay with, although her original text used a > SHOULD; and > > > > >> Keith > > > > >> > > could go either way. > > > > >> > > > > > > >> > > Is the consensus, then, that the text on honoring local > policy > > > > >> contains > > > > >> > > MUST? If so, the text to be inserted would be the following: > > > > >> > > > > > > >> > > A SIP client MUST honor any local policy for > prioritizing SIP > > > > >> > > requests such as policies based on message type, e.g., > > > INVITEs vs. > > > > >> > > requests associated with existing sessions. > > > > >> > > > > > > >> > > A SIP client MUST honor any local policy for > prioritizing SIP > > > > >> > > requests based on the content of the Resource-Priority > > > header (RPH, > > > > >> > > RFC4412 [RFC4412]). Specific (namespace.value) RPH > > > contents may > > > > >> > > indicate high priority requests that should be > preserved as > > > much as > > > > >> > > possible during overload. The RPH contents can also > indicate a > > > > >> > > low-priority request that is eligible to be dropped during > > > times of > > > > >> > > overload. > > > > >> > > > > > > >> > > A SIP client MUST honor any local policy for > prioritizing SIP > > > > >> > > requests relating to emergency calls, as identified by > the SOS > > > > >> > > URN [RFC5031] indicating an emergency request. > > > > >> > > > > > > >> > > Yes? > > > > >> > > > > > > >> > > 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 > > > > >> > > > > > > >> > _______________________________________________ > > > > >> > sip-overload mailing list > > > > >> > sip-overload@ietf.org > > > > >> > https://www.ietf.org/mailman/listinfo/sip-overload > > > > >> > > > > >> > > > > >> _______________________________________________ > > > > >> sip-overload mailing list > > > > >> sip-overload@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/sip-overload > > > > > > > > > > > > > > > -- > > > > > Salvatore Loreto, PhD > > > > > www.sloreto.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > sip-overload mailing list > > > > > sip-overload@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/sip-overload > > > > > > > > > _______________________________________________ > > > > sip-overload mailing list > > > > sip-overload@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sip-overload > > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload > From vkg@bell-labs.com Mon Jan 14 08:14:27 2013 Return-Path: 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 2AD5521F88C7 for ; Mon, 14 Jan 2013 08:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.269 X-Spam-Level: X-Spam-Status: No, score=-107.269 tagged_above=-999 required=5 tests=[AWL=-0.670, 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 O7d4+XEXAJ+s for ; Mon, 14 Jan 2013 08:14:26 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4987521F8824 for ; Mon, 14 Jan 2013 08:14:26 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r0EGDr3Y019275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 14 Jan 2013 10:13:53 -0600 (CST) 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 r0EGDqor002777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Jan 2013 10:13:52 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r0EGDpS1015874; Mon, 14 Jan 2013 10:13:51 -0600 (CST) Message-ID: <50F42F3A.3070204@bell-labs.com> Date: Mon, 14 Jan 2013 10:15:54 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Volker Hilt , Janet P Gunn References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> <24674_1355758104_50CF3A18_24674_468_1_88CAD1D4E8773F42858B58CAA28272A00E2A2C@PEXCVZYM12.corporate.adroot.infra.ftgroup> <50E5B529.2090105@bell-labs.com> <50F42D9F.1080002@bell-labs.com> In-Reply-To: <50F42D9F.1080002@bell-labs.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.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: sip-overload@ietf.org Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 16:14:27 -0000 On 01/14/2013 10:09 AM, Volker Hilt wrote: > That works for me! Volker: Can either you or Janet please propose the exact wordings to go into the modified text I proposed in [1]? This will avoid any guesswork and expedite the process of getting the drafts out. [1] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00885.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/ From volker.hilt@alcatel-lucent.com Mon Jan 14 08:16:06 2013 Return-Path: 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 1345921F8824 for ; Mon, 14 Jan 2013 08:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 gXa1D2uYBY5L for ; Mon, 14 Jan 2013 08:16:05 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 69AB721F8934 for ; Mon, 14 Jan 2013 08:15:59 -0800 (PST) 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 r0EGFMcm015356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 14 Jan 2013 10:15:22 -0600 (CST) 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 r0EGFLG9003221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Jan 2013 10:15:21 -0600 Received: from [135.244.178.1] (volkerh.lra.lucent.com [135.244.178.1]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r0EGF53f008846; Mon, 14 Jan 2013 10:15:08 -0600 (CST) Message-ID: <50F42F08.4080307@alcatel-lucent.com> Date: Mon, 14 Jan 2013 17:15:04 +0100 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Vijay K. Gurbani" References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> <24674_1355758104_50CF3A18_24674_468_1_88CAD1D4E8773F42858B58CAA28272A00E2A2C@PEXCVZYM12.corporate.adroot.infra.ftgroup> <50E5B529.2090105@bell-labs.com> <50F42D9F.1080002@bell-labs.com> <50F42F3A.3070204@bell-labs.com> In-Reply-To: <50F42F3A.3070204@bell-labs.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 Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 16:16:06 -0000 Vijay, the sentence Janet has proposed works for me. You can replace the sentence I had suggested after the first paragraph with Janets proposal. Cheers, Volker On 14.01.2013 17:15, Vijay K. Gurbani wrote: > On 01/14/2013 10:09 AM, Volker Hilt wrote: >> That works for me! > > Volker: Can either you or Janet please propose the exact wordings > to go into the modified text I proposed in [1]? This will avoid > any guesswork and expedite the process of getting the drafts out. > > [1] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00885.html > > Thanks, > > - vijay From charles.newyork@gmail.com Mon Jan 14 08:36:55 2013 Return-Path: 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 B13CB21F892D for ; Mon, 14 Jan 2013 08:36:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 JKGg2uHzQh4s for ; Mon, 14 Jan 2013 08:36:55 -0800 (PST) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) by ietfa.amsl.com (Postfix) with ESMTP id 212D021F88C8 for ; Mon, 14 Jan 2013 08:36:55 -0800 (PST) Received: by mail-ob0-f176.google.com with SMTP id un3so4049392obb.35 for ; Mon, 14 Jan 2013 08:36:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=kboBaQ8RlDrkQq0TMPK5gR6s/SyGqjTHX3bKXPOwNcA=; b=yOIxVZilTo6E0wy5XuAAss544ac+sUqmic5BDq5T4S27vpx5sCYrDLO076Sr07AZP/ rS64tP5K1UcAldrP2/k1I0bqvWMc0vPKGgMw8fdgbyo2gcvJE9HSYbXCMxsUDgtLYPFN NDjtJ17d3u4YTWhB9Iibql2OUtDOiwPOEYQAHRk5ZzO0yllzghYLYE4QcmCq5iY2uIvS 4KcycWvi63NCsV1DuGMe5nZKMOkqC27LTM4dXZWIiYE+SCnTjPLETXen0kmrJhf5UqXY ucaaT1l1MpyGeaVBivs+N312blre7IgjR6irw2qs9vwI8h8f2uP/wej2jjl0rHjsVhlp bTfw== Received: by 10.60.3.40 with SMTP id 8mr51380250oez.41.1358181414671; Mon, 14 Jan 2013 08:36:54 -0800 (PST) MIME-Version: 1.0 Sender: charles.newyork@gmail.com Received: by 10.182.151.82 with HTTP; Mon, 14 Jan 2013 08:36:34 -0800 (PST) In-Reply-To: <50F42F08.4080307@alcatel-lucent.com> References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> <24674_1355758104_50CF3A18_24674_468_1_88CAD1D4E8773F42858B58CAA28272A00E2A2C@PEXCVZYM12.corporate.adroot.infra.ftgroup> <50E5B529.2090105@bell-labs.com> <50F01C82.9010406@bell-labs.com> <50F4146E.1080308@bell-labs.com> <50F422E4.8010809@bell-labs.com> <50F42D9F.1080002@bell-labs.com> <50F42F3A.3070204@bell-labs.com> <50F42F08.4080307@alcatel-lucent.com> From: Charles Shen Date: Mon, 14 Jan 2013 11:36:34 -0500 X-Google-Sender-Auth: V_b-4i6yX0h_-3G7Jxc0NwKbjJs Message-ID: To: Volker Hilt , Janet P Gunn , "Vijay K. Gurbani" Content-Type: text/plain; charset=UTF-8 Cc: sip-overload@ietf.org Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 16:36:55 -0000 Hi Volker, Janet and Vijay, Since we are talking about putting the same texts in the overload-control and event-package draft, would it be better to clarify a bit about "the SIP Overload Algorithm" in this sentence? "It is expected a SIP client will follow local policy as long as the result is consistent with the SIP Overload Algorithm." Specifically, are we referring to mechanisms in both drafts (and in that case, should we add cross reference to them?) as well as any future Overload Algorithms? Thanks Charles On Mon, Jan 14, 2013 at 11:15 AM, Volker Hilt wrote: > Vijay, > > the sentence Janet has proposed works for me. You can replace the sentence I > had suggested after the first paragraph with Janets proposal. > > Cheers, > > Volker > > > > > On 14.01.2013 17:15, Vijay K. Gurbani wrote: >> >> On 01/14/2013 10:09 AM, Volker Hilt wrote: >>> >>> That works for me! >> >> >> Volker: Can either you or Janet please propose the exact wordings >> to go into the modified text I proposed in [1]? This will avoid >> any guesswork and expedite the process of getting the drafts out. >> >> [1] >> http://www.ietf.org/mail-archive/web/sip-overload/current/msg00885.html >> >> Thanks, >> >> - vijay > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload From jgunn6@csc.com Mon Jan 14 08:49:58 2013 Return-Path: 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 115E121F88BE for ; Mon, 14 Jan 2013 08:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.131 X-Spam-Level: X-Spam-Status: No, score=-6.131 tagged_above=-999 required=5 tests=[AWL=0.466, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 PSPugHEAk+ve for ; Mon, 14 Jan 2013 08:49:57 -0800 (PST) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.255.50]) by ietfa.amsl.com (Postfix) with ESMTP id 37AF521F8844 for ; Mon, 14 Jan 2013 08:49:56 -0800 (PST) Received: from [216.82.253.243:9795] by server-16.bemta-7.messagelabs.com id 4A/31-02467-43734F05; Mon, 14 Jan 2013 16:49:56 +0000 X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-4.tower-171.messagelabs.com!1358182195!25295743!1 X-Originating-IP: [20.137.2.87] X-StarScan-Received: X-StarScan-Version: 6.6.1.8; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21810 invoked from network); 14 Jan 2013 16:49:56 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-4.tower-171.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Jan 2013 16:49:56 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r0EGnrQS017544 for ; Mon, 14 Jan 2013 11:49:54 -0500 In-Reply-To: References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> <24674_1355758104_50CF3A18_24674_468_1_88CAD1D4E8773F42858B58CAA28272A00E2A2C@PEXCVZYM12.corporate.adroot.infra.ftgroup> <50E5B529.2090105@bell-labs.com> <50F01C82.9010406@bell-labs.com> <50F4146E.1080308@bell-labs.com> <50F422E4.8010809@bell-labs.com> <50F42D9F.1080002@bell-labs.com> <50F42F3A.3070204@bell-labs.com To: Charles Shen MIME-Version: 1.0 X-KeepSent: 36DB58E7:14AA60B0-85257AF3:005BDC42; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Mon, 14 Jan 2013 11:49:52 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 01/14/2013 11:44:52 AM, Serialize complete at 01/14/2013 11:44:52 AM Content-Type: multipart/alternative; boundary="=_alternative 005C74EC85257AF3_=" Cc: sip-overload@ietf.org, Volker Hilt Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 16:49:58 -0000 This is a multipart message in MIME format. --=_alternative 005C74EC85257AF3_= Content-Type: text/plain; charset="US-ASCII" My personal thought is that in each case, it would refer to the Overload Algorithm(s) in effect at that node. But that brings up a whole can of worms about interaction between algorithms.. If the Event package has set up an a-priori Overload Control, and then an actual overload triggers a "feedback" Overload Control, how do they interact? The max? the min? the "product" Is that a can of worms we want to open at this point? Janet charles.newyork@gmail.com wrote on 01/14/2013 11:36:34 AM: > From: Charles Shen > To: Volker Hilt , Janet P Gunn/USA/ > CSC@CSC, "Vijay K. Gurbani" > Cc: sip-overload@ietf.org > Date: 01/14/2013 11:37 AM > Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf- > soc-load-control-event-package-05.txt > Sent by: charles.newyork@gmail.com > > Hi Volker, Janet and Vijay, > > Since we are talking about putting the same texts in the > overload-control and event-package draft, would it be better to > clarify a bit about "the SIP Overload Algorithm" in this sentence? > > "It is expected a SIP client will follow local policy > as long as the result is consistent with the SIP Overload Algorithm." > > Specifically, are we referring to mechanisms in both drafts (and in > that case, should we add cross reference to them?) as well as any > future Overload Algorithms? > > Thanks > > Charles > > > > > > On Mon, Jan 14, 2013 at 11:15 AM, Volker Hilt > wrote: > > Vijay, > > > > the sentence Janet has proposed works for me. You can replace the sentence I > > had suggested after the first paragraph with Janets proposal. > > > > Cheers, > > > > Volker > > > > > > > > > > On 14.01.2013 17:15, Vijay K. Gurbani wrote: > >> > >> On 01/14/2013 10:09 AM, Volker Hilt wrote: > >>> > >>> That works for me! > >> > >> > >> Volker: Can either you or Janet please propose the exact wordings > >> to go into the modified text I proposed in [1]? This will avoid > >> any guesswork and expedite the process of getting the drafts out. > >> > >> [1] > >> http://www.ietf.org/mail-archive/web/sip-overload/current/msg00885.html > >> > >> Thanks, > >> > >> - vijay > > > > _______________________________________________ > > sip-overload mailing list > > sip-overload@ietf.org > > https://www.ietf.org/mailman/listinfo/sip-overload --=_alternative 005C74EC85257AF3_= Content-Type: text/html; charset="US-ASCII"

My personal thought is that in each case, it would refer to the Overload Algorithm(s) in effect at that node.

But that brings up a whole can of worms about interaction between algorithms..

If the Event package has set up an a-priori Overload  Control, and then an actual overload triggers a "feedback" Overload Control, how do they interact?  The max? the min? the "product"

Is that a can of worms we want to open at this point?

Janet

charles.newyork@gmail.com wrote on 01/14/2013 11:36:34 AM:

> From: Charles Shen <charles@cs.columbia.edu>
> To: Volker Hilt <volker.hilt@alcatel-lucent.com>, Janet P Gunn/USA/
> CSC@CSC, "Vijay K. Gurbani" <vkg@bell-labs.com>
> Cc: sip-overload@ietf.org
> Date: 01/14/2013 11:37 AM
> Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-
> soc-load-control-event-package-05.txt
> Sent by: charles.newyork@gmail.com
>
> Hi Volker, Janet and Vijay,
>
> Since we are talking about putting the same texts in the
> overload-control and event-package draft, would it be better to
> clarify a bit about "the SIP Overload Algorithm" in this sentence?
>
> "It is expected a SIP client will follow local policy
> as long as the result is consistent with the SIP Overload Algorithm."
>
> Specifically, are we referring to mechanisms in both drafts (and in
> that case, should we add cross reference to them?) as well as any
> future Overload Algorithms?
>
> Thanks
>
> Charles
>
>
>
>
>
> On Mon, Jan 14, 2013 at 11:15 AM, Volker Hilt
> <volker.hilt@alcatel-lucent.com> wrote:
> > Vijay,
> >
> > the sentence Janet has proposed works for me. You can replace the sentence I
> > had suggested after the first paragraph with Janets proposal.
> >
> > Cheers,
> >
> > Volker
> >
> >
> >
> >
> > On 14.01.2013 17:15, Vijay K. Gurbani wrote:
> >>
> >> On 01/14/2013 10:09 AM, Volker Hilt wrote:
> >>>
> >>> That works for me!
> >>
> >>
> >> Volker: Can either you or Janet please propose the exact wordings
> >> to go into the modified text I proposed in [1]?  This will avoid
> >> any guesswork and expedite the process of getting the drafts out.
> >>
> >> [1]
> >> http://www.ietf.org/mail-archive/web/sip-overload/current/msg00885.html
> >>
> >> Thanks,
> >>
> >> - vijay
> >
> > _______________________________________________
> > sip-overload mailing list
> > sip-overload@ietf.org
> > https://www.ietf.org/mailman/listinfo/sip-overload
 --=_alternative 005C74EC85257AF3_=-- From charles.newyork@gmail.com Mon Jan 14 09:03:50 2013 Return-Path: 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 2CF8C21F8919 for ; Mon, 14 Jan 2013 09:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 a8cXROiF1g5h for ; Mon, 14 Jan 2013 09:03:49 -0800 (PST) Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6ED21F8953 for ; Mon, 14 Jan 2013 09:03:49 -0800 (PST) Received: by mail-ob0-f174.google.com with SMTP id ta14so4078132obb.19 for ; Mon, 14 Jan 2013 09:03:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=dDzAC261KINHECfkeYAPyVhkoI7Z/GsQ7JHMrP7nSRw=; b=idqzdGdBMFKW2AysYjNuXNXW/lh9Xl0n3CYFU9j2D5liSSG/AcO8wMsJ08uETKJWZP jUB88v+ga2QwUgPSykV8KYV3abIB9wYi2oN1BD6HU+fsZgtEoSJqockZHeoI4kVWHRpC nt+tKw2d8X3rK+FMw+Bbi1WXnlMB52yApObkKes5347WF0RGH7PrFgKDTe+7xH4kXPyG a5YgTzkyeUt16okhiMOQI11uNYK6efZLGCCfP21KbeUnhEYuRpmEEcuqUCm4tsDdA7e/ rLlHacU+QOmabhqpB//FeEhd5hDapiE7NJ1Atz4NxxvmlQC67lGsKWlhqO5KsUpEY2UW NabA== Received: by 10.60.31.131 with SMTP id a3mr51482333oei.93.1358183023778; Mon, 14 Jan 2013 09:03:43 -0800 (PST) MIME-Version: 1.0 Sender: charles.newyork@gmail.com Received: by 10.182.151.82 with HTTP; Mon, 14 Jan 2013 09:03:22 -0800 (PST) In-Reply-To: References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> <24674_1355758104_50CF3A18_24674_468_1_88CAD1D4E8773F42858B58CAA28272A00E2A2C@PEXCVZYM12.corporate.adroot.infra.ftgroup> <50E5B529.2090105@bell-labs.com> <50F01C82.9010406@bell-labs.com> <50F4146E.1080308@bell-labs.com> <50F422E4.8010809@bell-labs.com> <50F42D9F.1080002@bell-labs.com> From: Charles Shen Date: Mon, 14 Jan 2013 12:03:22 -0500 X-Google-Sender-Auth: 2ULUcjw8-xQSHm_T96NynqScsdE Message-ID: To: Janet P Gunn Content-Type: text/plain; charset=UTF-8 Cc: sip-overload@ietf.org, Volker Hilt Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 17:03:50 -0000 I am not in favor of opening up more cans of whatever at this stage :) I think we just need to define and clarify the line. At least "the Overload Algorithm(s) in effect at that node" sounds much better than "the Overload Algorithm(s)" alone. (Optionally) plus something like "the interactions of those Overload Algorithms are out of scope". Thanks Charles On Mon, Jan 14, 2013 at 11:49 AM, Janet P Gunn wrote: > > > My personal thought is that in each case, it would refer to the Overload > Algorithm(s) in effect at that node. > > But that brings up a whole can of worms about interaction between > algorithms.. > > If the Event package has set up an a-priori Overload Control, and then an > actual overload triggers a "feedback" Overload Control, how do they > interact? The max? the min? the "product" > > Is that a can of worms we want to open at this point? > > Janet > > charles.newyork@gmail.com wrote on 01/14/2013 11:36:34 AM: > >> From: Charles Shen >> To: Volker Hilt , Janet P Gunn/USA/ >> CSC@CSC, "Vijay K. Gurbani" >> Cc: sip-overload@ietf.org >> Date: 01/14/2013 11:37 AM >> Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf- >> soc-load-control-event-package-05.txt >> Sent by: charles.newyork@gmail.com >> >> Hi Volker, Janet and Vijay, >> >> Since we are talking about putting the same texts in the >> overload-control and event-package draft, would it be better to >> clarify a bit about "the SIP Overload Algorithm" in this sentence? >> >> "It is expected a SIP client will follow local policy >> as long as the result is consistent with the SIP Overload Algorithm." >> >> Specifically, are we referring to mechanisms in both drafts (and in >> that case, should we add cross reference to them?) as well as any >> future Overload Algorithms? >> >> Thanks >> >> Charles >> >> >> >> >> >> On Mon, Jan 14, 2013 at 11:15 AM, Volker Hilt >> wrote: >> > Vijay, >> > >> > the sentence Janet has proposed works for me. You can replace the >> > sentence I >> > had suggested after the first paragraph with Janets proposal. >> > >> > Cheers, >> > >> > Volker >> > >> > >> > >> > >> > On 14.01.2013 17:15, Vijay K. Gurbani wrote: >> >> >> >> On 01/14/2013 10:09 AM, Volker Hilt wrote: >> >>> >> >>> That works for me! >> >> >> >> >> >> Volker: Can either you or Janet please propose the exact wordings >> >> to go into the modified text I proposed in [1]? This will avoid >> >> any guesswork and expedite the process of getting the drafts out. >> >> >> >> [1] >> >> http://www.ietf.org/mail-archive/web/sip-overload/current/msg00885.html >> >> >> >> Thanks, >> >> >> >> - vijay >> > >> > _______________________________________________ >> > sip-overload mailing list >> > sip-overload@ietf.org >> > https://www.ietf.org/mailman/listinfo/sip-overload From keith.drage@alcatel-lucent.com Mon Jan 14 09:28:21 2013 Return-Path: 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 BD49221F8828 for ; Mon, 14 Jan 2013 09:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.099 X-Spam-Level: X-Spam-Status: No, score=-107.099 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 iPsu+kEMtp1E for ; Mon, 14 Jan 2013 09:28:20 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABF521F8824 for ; Mon, 14 Jan 2013 09:28:19 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r0EHRrq8021580 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 14 Jan 2013 18:27:53 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Mon, 14 Jan 2013 18:27:53 +0100 From: "DRAGE, Keith (Keith)" To: Charles Shen , Janet P Gunn Date: Mon, 14 Jan 2013 18:27:52 +0100 Thread-Topic: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt Thread-Index: Ac3yeSej5LXA1rNiTny48kCQE6Jg+QAArU9Q Message-ID: References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> <24674_1355758104_50CF3A18_24674_468_1_88CAD1D4E8773F42858B58CAA28272A00E2A2C@PEXCVZYM12.corporate.adroot.infra.ftgroup> <50E5B529.2090105@bell-labs.com> <50F01C82.9010406@bell-labs.com> <50F4146E.1080308@bell-labs.com> <50F422E4.8010809@bell-labs.com> <50F42D9F.1080002@bell-labs.com> In-Reply-To: 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 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "sip-overload@ietf.org" , "Hilt, Volker \(Volker\)" Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 17:28:21 -0000 I'm not convinced we have got to the bottom of the requirement yet. Writing= SHOULD is not an excuse for writing a poor requirement, yet that seems cur= rently to be the excuse for wring SHOULD instead of MUST. Ideally I should = still be able to still identify conformance or no conformance to a SHOULD r= equirement. I suspect what we need to do is find a more specific requirement and then c= over the rest of the problem in more informative text, rather than trying t= o address everything in a single requirement sentence. I agree that if we end up writing a SHOULD, then there should be associated= informative text that identifies the example circumstances for ignoring th= e SHOULD. That has long been an unwritten rule, and without it the SHOULD a= lways gets interpreted as a MAY. Regards Keith > -----Original Message----- > From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org= ] > On Behalf Of Charles Shen > Sent: 14 January 2013 17:03 > To: Janet P Gunn > Cc: sip-overload@ietf.org; Hilt, Volker (Volker) > Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc- > load-control-event-package-05.txt >=20 > I am not in favor of opening up more cans of whatever at this stage :) >=20 > I think we just need to define and clarify the line. At least "the > Overload > Algorithm(s) in effect at that node" sounds much better than "the > Overload Algorithm(s)" alone. (Optionally) plus something like "the > interactions of those Overload Algorithms are out of scope". >=20 > Thanks >=20 > Charles >=20 > On Mon, Jan 14, 2013 at 11:49 AM, Janet P Gunn wrote: > > > > > > My personal thought is that in each case, it would refer to the Overloa= d > > Algorithm(s) in effect at that node. > > > > But that brings up a whole can of worms about interaction between > > algorithms.. > > > > If the Event package has set up an a-priori Overload Control, and then > an > > actual overload triggers a "feedback" Overload Control, how do they > > interact? The max? the min? the "product" > > > > Is that a can of worms we want to open at this point? > > > > Janet > > > > charles.newyork@gmail.com wrote on 01/14/2013 11:36:34 AM: > > > >> From: Charles Shen > >> To: Volker Hilt , Janet P Gunn/USA/ > >> CSC@CSC, "Vijay K. Gurbani" > >> Cc: sip-overload@ietf.org > >> Date: 01/14/2013 11:37 AM > >> Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf- > >> soc-load-control-event-package-05.txt > >> Sent by: charles.newyork@gmail.com > >> > >> Hi Volker, Janet and Vijay, > >> > >> Since we are talking about putting the same texts in the > >> overload-control and event-package draft, would it be better to > >> clarify a bit about "the SIP Overload Algorithm" in this sentence? > >> > >> "It is expected a SIP client will follow local policy > >> as long as the result is consistent with the SIP Overload Algorithm." > >> > >> Specifically, are we referring to mechanisms in both drafts (and in > >> that case, should we add cross reference to them?) as well as any > >> future Overload Algorithms? > >> > >> Thanks > >> > >> Charles > >> > >> > >> > >> > >> > >> On Mon, Jan 14, 2013 at 11:15 AM, Volker Hilt > >> wrote: > >> > Vijay, > >> > > >> > the sentence Janet has proposed works for me. You can replace the > >> > sentence I > >> > had suggested after the first paragraph with Janets proposal. > >> > > >> > Cheers, > >> > > >> > Volker > >> > > >> > > >> > > >> > > >> > On 14.01.2013 17:15, Vijay K. Gurbani wrote: > >> >> > >> >> On 01/14/2013 10:09 AM, Volker Hilt wrote: > >> >>> > >> >>> That works for me! > >> >> > >> >> > >> >> Volker: Can either you or Janet please propose the exact wordings > >> >> to go into the modified text I proposed in [1]? This will avoid > >> >> any guesswork and expedite the process of getting the drafts out. > >> >> > >> >> [1] > >> >> http://www.ietf.org/mail-archive/web/sip- > overload/current/msg00885.html > >> >> > >> >> Thanks, > >> >> > >> >> - vijay > >> > > >> > _______________________________________________ > >> > sip-overload mailing list > >> > sip-overload@ietf.org > >> > https://www.ietf.org/mailman/listinfo/sip-overload > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload From bruno.chatras@orange.com Mon Jan 14 10:08:42 2013 Return-Path: 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 2541221F87CB for ; Mon, 14 Jan 2013 10:08:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] 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 aaNaPVca2JWp for ; Mon, 14 Jan 2013 10:08:41 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id AB35721F882C for ; Mon, 14 Jan 2013 10:08:40 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id B91AC2DC462; Mon, 14 Jan 2013 19:08:37 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 99C644C07C; Mon, 14 Jan 2013 19:08:37 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Mon, 14 Jan 2013 19:08:37 +0100 From: To: "DRAGE, Keith (Keith)" , Charles Shen , Janet P Gunn Thread-Topic: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt Thread-Index: AQHN8nyPQSHamHgQRU638Ux7IjIPD5hJHKAg Date: Mon, 14 Jan 2013 18:08:36 +0000 Message-ID: <24379_1358186917_50F449A5_24379_12938_1_88CAD1D4E8773F42858B58CAA28272A00F1A88@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> <24674_1355758104_50CF3A18_24674_468_1_88CAD1D4E8773F42858B58CAA28272A00E2A2C@PEXCVZYM12.corporate.adroot.infra.ftgroup> <50E5B529.2090105@bell-labs.com> <50F01C82.9010406@bell-labs.com> <50F4146E.1080308@bell-labs.com> <50F422E4.8010809@bell-labs.com> <50F42D9F.1080002@bell-labs.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.1.14.163625 Cc: "sip-overload@ietf.org" , "Hilt, Volker \(Volker\)" Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 18:08:42 -0000 I'm not really happy with the SHOULD. I think we are mixing two different t= hings: priority and preservation. For example, a local policy that gives pr= iority to BYE requests over any other request MUST always be honored even i= n case of severe overload. This does not imply that BYE requests MUST alway= s be preserved; just that they MUST be given priority over other requests.= =20 I don't see any problem with using MUST for local policies that assign prio= rities to some requests. Use of MUST would of course be a problem if we wer= e to define local policies about preserving some requests, but it's not wha= t we are trying to do. BC > -----Message d'origine----- > De=A0: sip-overload-bounces@ietf.org [mailto:sip-overload- > bounces@ietf.org] De la part de DRAGE, Keith (Keith) > Envoy=E9=A0: lundi 14 janvier 2013 18:28 > =C0=A0: Charles Shen; Janet P Gunn > Cc=A0: sip-overload@ietf.org; Hilt, Volker (Volker) > Objet=A0: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc- > load-control-event-package-05.txt >=20 > I'm not convinced we have got to the bottom of the requirement yet. > Writing SHOULD is not an excuse for writing a poor requirement, yet > that seems currently to be the excuse for wring SHOULD instead of MUST. > Ideally I should still be able to still identify conformance or no > conformance to a SHOULD requirement. >=20 > I suspect what we need to do is find a more specific requirement and > then cover the rest of the problem in more informative text, rather > than trying to address everything in a single requirement sentence. >=20 > I agree that if we end up writing a SHOULD, then there should be > associated informative text that identifies the example circumstances > for ignoring the SHOULD. That has long been an unwritten rule, and > without it the SHOULD always gets interpreted as a MAY. >=20 > Regards >=20 > Keith >=20 >=20 > > -----Original Message----- > > From: sip-overload-bounces@ietf.org > > [mailto:sip-overload-bounces@ietf.org] > > On Behalf Of Charles Shen > > Sent: 14 January 2013 17:03 > > To: Janet P Gunn > > Cc: sip-overload@ietf.org; Hilt, Volker (Volker) > > Subject: Re: [sip-overload] Local Policy Re: I-D Action: > > draft-ietf-soc- load-control-event-package-05.txt > > > > I am not in favor of opening up more cans of whatever at this stage :) > > > > I think we just need to define and clarify the line. At least "the > > Overload > > Algorithm(s) in effect at that node" sounds much better than "the > > Overload Algorithm(s)" alone. (Optionally) plus something like "the > > interactions of those Overload Algorithms are out of scope". > > > > Thanks > > > > Charles > > > > On Mon, Jan 14, 2013 at 11:49 AM, Janet P Gunn wrote: > > > > > > > > > My personal thought is that in each case, it would refer to the > > > Overload > > > Algorithm(s) in effect at that node. > > > > > > But that brings up a whole can of worms about interaction between > > > algorithms.. > > > > > > If the Event package has set up an a-priori Overload Control, and > > > then > > an > > > actual overload triggers a "feedback" Overload Control, how do they > > > interact? The max? the min? the "product" > > > > > > Is that a can of worms we want to open at this point? > > > > > > Janet > > > > > > charles.newyork@gmail.com wrote on 01/14/2013 11:36:34 AM: > > > > > >> From: Charles Shen > > >> To: Volker Hilt , Janet P > Gunn/USA/ > > >> CSC@CSC, "Vijay K. Gurbani" > > >> Cc: sip-overload@ietf.org > > >> Date: 01/14/2013 11:37 AM > > >> Subject: Re: [sip-overload] Local Policy Re: I-D Action: > > >> draft-ietf- soc-load-control-event-package-05.txt > > >> Sent by: charles.newyork@gmail.com > > >> > > >> Hi Volker, Janet and Vijay, > > >> > > >> Since we are talking about putting the same texts in the > > >> overload-control and event-package draft, would it be better to > > >> clarify a bit about "the SIP Overload Algorithm" in this sentence? > > >> > > >> "It is expected a SIP client will follow local policy as long as > > >> the result is consistent with the SIP Overload Algorithm." > > >> > > >> Specifically, are we referring to mechanisms in both drafts (and > in > > >> that case, should we add cross reference to them?) as well as any > > >> future Overload Algorithms? > > >> > > >> Thanks > > >> > > >> Charles > > >> > > >> > > >> > > >> > > >> > > >> On Mon, Jan 14, 2013 at 11:15 AM, Volker Hilt > > >> wrote: > > >> > Vijay, > > >> > > > >> > the sentence Janet has proposed works for me. You can replace > the > > >> > sentence I had suggested after the first paragraph with Janets > > >> > proposal. > > >> > > > >> > Cheers, > > >> > > > >> > Volker > > >> > > > >> > > > >> > > > >> > > > >> > On 14.01.2013 17:15, Vijay K. Gurbani wrote: > > >> >> > > >> >> On 01/14/2013 10:09 AM, Volker Hilt wrote: > > >> >>> > > >> >>> That works for me! > > >> >> > > >> >> > > >> >> Volker: Can either you or Janet please propose the exact > > >> >> wordings to go into the modified text I proposed in [1]? This > > >> >> will avoid any guesswork and expedite the process of getting > the drafts out. > > >> >> > > >> >> [1] > > >> >> http://www.ietf.org/mail-archive/web/sip- > > overload/current/msg00885.html > > >> >> > > >> >> Thanks, > > >> >> > > >> >> - vijay > > >> > > > >> > _______________________________________________ > > >> > sip-overload mailing list > > >> > sip-overload@ietf.org > > >> > https://www.ietf.org/mailman/listinfo/sip-overload > > _______________________________________________ > > sip-overload mailing list > > sip-overload@ietf.org > > https://www.ietf.org/mailman/listinfo/sip-overload > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From vkg@bell-labs.com Mon Jan 14 10:15:45 2013 Return-Path: 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 662F921F88F0 for ; Mon, 14 Jan 2013 10:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.208 X-Spam-Level: X-Spam-Status: No, score=-109.208 tagged_above=-999 required=5 tests=[AWL=1.391, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 yjKkTe9wfMwI for ; Mon, 14 Jan 2013 10:15:44 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id BFFC521F888C for ; Mon, 14 Jan 2013 10:15:36 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r0EIFZUD025658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 14 Jan 2013 12:15:36 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r0EIFZ1g004557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 14 Jan 2013 12:15:35 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r0EIFZln024341 for ; Mon, 14 Jan 2013 12:15:35 -0600 (CST) Message-ID: <50F44BC2.2080703@bell-labs.com> Date: Mon, 14 Jan 2013 12:17:38 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: sip-overload@ietf.org References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> <50E5B529.2090105@bell-labs.com> <50F01C82.9010406@bell-labs.com> <50F4146E.1080308@bell-labs.com> <50F422E4.8010809@bell-labs.com> <50F42D9F.1080002@bell-labs.com> In-Reply-To: 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.9 Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 18:15:45 -0000 On 01/14/2013 11:27 AM, DRAGE, Keith (Keith) wrote: > I'm not convinced we have got to the bottom of the requirement yet. > Writing SHOULD is not an excuse for writing a poor requirement, yet > that seems currently to be the excuse for wring SHOULD instead of > MUST. Ideally I should still be able to still identify conformance or > no conformance to a SHOULD requirement. > > I suspect what we need to do is find a more specific requirement and > then cover the rest of the problem in more informative text, rather > than trying to address everything in a single requirement sentence. > > I agree that if we end up writing a SHOULD, then there should be > associated informative text that identifies the example circumstances > for ignoring the SHOULD. That has long been an unwritten rule, and > without it the SHOULD always gets interpreted as a MAY. Keith: Do you have specific text you'd like to suggest? Taking in account Sal's view of staying away from local policies in conflict and taking Janet's and Charles' suggestions, I have the following as a cautionary paragraph before the normative text: It is expected that a SIP client will follow local policy as long as the results in reduction of traffic is consistent with the SIP overload algorithm in effect at that node. Accordingly, the normative behaviour in the next three paragraphs should be interpreted with the understanding that the SIP client will aim to preserve local policy to the fullest extent possible. And then we go down the three SHOULD paragraphs. I believe that suggesting specific text will help close this gap more expeditiously. Is the above something that we can go with? 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/ From salvatore.loreto@ericsson.com Mon Jan 14 23:33:39 2013 Return-Path: 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 8935821F8919 for ; Mon, 14 Jan 2013 23:33:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 wvG0L+iH16Qm for ; Mon, 14 Jan 2013 23:33:38 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9C321F8910 for ; Mon, 14 Jan 2013 23:33:37 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-c0-50f506501aba Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 48.F9.19728.05605F05; Tue, 15 Jan 2013 08:33:36 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Tue, 15 Jan 2013 08:33:36 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id D836A2420 for ; Tue, 15 Jan 2013 09:33:35 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id DD0AB54098 for ; Tue, 15 Jan 2013 09:33:33 +0200 (EET) Received: from n94.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8FB3D53DC2 for ; Tue, 15 Jan 2013 09:33:33 +0200 (EET) Message-ID: <50F5064F.4090008@ericsson.com> Date: Tue, 15 Jan 2013 09:33:35 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: sip-overload@ietf.org References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> <50E5B529.2090105@bell-labs.com> <50F01C82.9010406@bell-labs.com> <50F4146E.1080308@bell-labs.com> <50F422E4.8010809@bell-labs.com> <50F42D9F.1080002@bell-labs.com> <24379_1358186917_50F449A5_24379_12938_1_88CAD1D4E8773F42858B58CAA28272A00F1A88@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <24379_1358186917_50F449A5_24379_12938_1_88CAD1D4E8773F42858B58CAA28272A00F1A88@PEXCVZYM12.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUyM+JvjW4A29cAg3mHFSz2P01wYPRYsuQn UwBjFJdNSmpOZllqkb5dAlfGv0OsBY12FcsuLWZrYFxm3MXIySEhYCLx9tg+ZghbTOLCvfVs XYxcHEICJxklHt7Zxg7hbGCUuHZgDyOEc41RYsP8t8xwZWs6J0H1HGSUeHfvOhPIMF4BbYnP 36azgNgsAqoSn1rfgNlsAmYSzx9uAVsoKpAs8fHONVaIekGJkzOfgNWICEhKfHk+kRHEFhbI lGi7swPqjiXsEvMeTmUBcTgF2hkltj7rYAepYhawlbgw5zoLhC0v0bx1NtRLahJXz20Cs4UE tCR6z3YyTWAUmYVk4Swk7bOQtC9gZF7FyJ6bmJmTXm60iREYzge3/FbdwXjnnMghRmkOFiVx 3nDXCwFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGFdKhAqvu1a0e+fUO6W3v0jKZl0PrvEI aVlReKhvcoQH/8pJlx6FP/lwPM3yXUBh2Z7p7tkXphz4UPVhV3G8f8ykxzwLz3M5zRE+E7bu +263zYYfpZxyT/5+KXB7F6OS9Io3O5nkHbfps16dJ7+55eyX6n4dU+ZLnrGTzrX7LOa9GnzN LWRBRq0SS3FGoqEWc1FxIgDvJh/xNQIAAA== Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 07:33:39 -0000 I do like the distinction between prioritization and preservation, maybe we need clearly distinguish the two cases in the draft for prioritization a MUST could by reasonable indeed a statement like: - "It *MUST* honor the local policy for *prioritizing* SIP requests..." tell that the SIP element has to prioritize requests following the policy but has still the possibility to discard in case of severe overload while for preserving a SHOULD seems to be more appropriate indeed a statement like this: - "It *SHOULD* honor the local policy for *preserving* SIP requests..." tell that SIP element will follow local policy as long as the result does not produce a severe overload (i.e. "the result is consistent with the SIP Overload Algorithm) /Salvatore On 1/14/13 8:08 PM, bruno.chatras@orange.com wrote: > I'm not really happy with the SHOULD. I think we are mixing two different things: priority and preservation. For example, a local policy that gives priority to BYE requests over any other request MUST always be honored even in case of severe overload. This does not imply that BYE requests MUST always be preserved; just that they MUST be given priority over other requests. > > I don't see any problem with using MUST for local policies that assign priorities to some requests. Use of MUST would of course be a problem if we were to define local policies about preserving some requests, but it's not what we are trying to do. > > BC > >> -----Message d'origine----- >> De : sip-overload-bounces@ietf.org [mailto:sip-overload- >> bounces@ietf.org] De la part de DRAGE, Keith (Keith) >> Envoyé : lundi 14 janvier 2013 18:28 >> À : Charles Shen; Janet P Gunn >> Cc : sip-overload@ietf.org; Hilt, Volker (Volker) >> Objet : Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc- >> load-control-event-package-05.txt >> >> I'm not convinced we have got to the bottom of the requirement yet. >> Writing SHOULD is not an excuse for writing a poor requirement, yet >> that seems currently to be the excuse for wring SHOULD instead of MUST. >> Ideally I should still be able to still identify conformance or no >> conformance to a SHOULD requirement. >> >> I suspect what we need to do is find a more specific requirement and >> then cover the rest of the problem in more informative text, rather >> than trying to address everything in a single requirement sentence. >> >> I agree that if we end up writing a SHOULD, then there should be >> associated informative text that identifies the example circumstances >> for ignoring the SHOULD. That has long been an unwritten rule, and >> without it the SHOULD always gets interpreted as a MAY. >> >> Regards >> >> Keith >> >> >>> -----Original Message----- >>> From: sip-overload-bounces@ietf.org >>> [mailto:sip-overload-bounces@ietf.org] >>> On Behalf Of Charles Shen >>> Sent: 14 January 2013 17:03 >>> To: Janet P Gunn >>> Cc: sip-overload@ietf.org; Hilt, Volker (Volker) >>> Subject: Re: [sip-overload] Local Policy Re: I-D Action: >>> draft-ietf-soc- load-control-event-package-05.txt >>> >>> I am not in favor of opening up more cans of whatever at this stage :) >>> >>> I think we just need to define and clarify the line. At least "the >>> Overload >>> Algorithm(s) in effect at that node" sounds much better than "the >>> Overload Algorithm(s)" alone. (Optionally) plus something like "the >>> interactions of those Overload Algorithms are out of scope". >>> >>> Thanks >>> >>> Charles >>> >>> On Mon, Jan 14, 2013 at 11:49 AM, Janet P Gunn wrote: >>>> >>>> My personal thought is that in each case, it would refer to the >>>> Overload >>>> Algorithm(s) in effect at that node. >>>> >>>> But that brings up a whole can of worms about interaction between >>>> algorithms.. >>>> >>>> If the Event package has set up an a-priori Overload Control, and >>>> then >>> an >>>> actual overload triggers a "feedback" Overload Control, how do they >>>> interact? The max? the min? the "product" >>>> >>>> Is that a can of worms we want to open at this point? >>>> >>>> Janet >>>> >>>> charles.newyork@gmail.com wrote on 01/14/2013 11:36:34 AM: >>>> >>>>> From: Charles Shen >>>>> To: Volker Hilt , Janet P >> Gunn/USA/ >>>>> CSC@CSC, "Vijay K. Gurbani" >>>>> Cc: sip-overload@ietf.org >>>>> Date: 01/14/2013 11:37 AM >>>>> Subject: Re: [sip-overload] Local Policy Re: I-D Action: >>>>> draft-ietf- soc-load-control-event-package-05.txt >>>>> Sent by: charles.newyork@gmail.com >>>>> >>>>> Hi Volker, Janet and Vijay, >>>>> >>>>> Since we are talking about putting the same texts in the >>>>> overload-control and event-package draft, would it be better to >>>>> clarify a bit about "the SIP Overload Algorithm" in this sentence? >>>>> >>>>> "It is expected a SIP client will follow local policy as long as >>>>> the result is consistent with the SIP Overload Algorithm." >>>>> >>>>> Specifically, are we referring to mechanisms in both drafts (and >> in >>>>> that case, should we add cross reference to them?) as well as any >>>>> future Overload Algorithms? >>>>> >>>>> Thanks >>>>> >>>>> Charles >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, Jan 14, 2013 at 11:15 AM, Volker Hilt >>>>> wrote: >>>>>> Vijay, >>>>>> >>>>>> the sentence Janet has proposed works for me. You can replace >> the >>>>>> sentence I had suggested after the first paragraph with Janets >>>>>> proposal. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Volker >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 14.01.2013 17:15, Vijay K. Gurbani wrote: >>>>>>> On 01/14/2013 10:09 AM, Volker Hilt wrote: >>>>>>>> That works for me! >>>>>>> >>>>>>> Volker: Can either you or Janet please propose the exact >>>>>>> wordings to go into the modified text I proposed in [1]? This >>>>>>> will avoid any guesswork and expedite the process of getting >> the drafts out. >>>>>>> [1] >>>>>>> http://www.ietf.org/mail-archive/web/sip- >>> overload/current/msg00885.html >>>>>>> Thanks, >>>>>>> >>>>>>> - vijay >>>>>> _______________________________________________ >>>>>> sip-overload mailing list >>>>>> sip-overload@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sip-overload >>> _______________________________________________ >>> sip-overload mailing list >>> sip-overload@ietf.org >>> https://www.ietf.org/mailman/listinfo/sip-overload >> _______________________________________________ >> sip-overload mailing list >> sip-overload@ietf.org >> https://www.ietf.org/mailman/listinfo/sip-overload > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload From volker.hilt@bell-labs.com Tue Jan 15 01:59:32 2013 Return-Path: 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 4D86621F8775 for ; Tue, 15 Jan 2013 01:59:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.849 X-Spam-Level: X-Spam-Status: No, score=-9.849 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] 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 zM6keG+Et9Up for ; Tue, 15 Jan 2013 01:59:31 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id EF9C321F874C for ; Tue, 15 Jan 2013 01:59:30 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r0F9x3UI012628 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 15 Jan 2013 10:59:28 +0100 Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 15 Jan 2013 10:59:16 +0100 Received: from [149.204.61.163] (135.5.27.16) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 15 Jan 2013 04:59:13 -0500 Message-ID: <50F5286F.9010605@bell-labs.com> Date: Tue, 15 Jan 2013 10:59:11 +0100 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> <50E5B529.2090105@bell-labs.com> <50F01C82.9010406@bell-labs.com> <50F4146E.1080308@bell-labs.com> <50F422E4.8010809@bell-labs.com> <50F42D9F.1080002@bell-labs.com> <24379_1358186917_50F449A5_24379_12938_1_88CAD1D4E8773F42858B58CAA28272A00F1A88@PEXCVZYM12.corporate.adroot.infra.ftgroup> <50F5064F.4090008@ericsson.com> In-Reply-To: <50F5064F.4090008@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.5.27.16] X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 09:59:32 -0000 I think my general concern is that we are creating a MUST for something that we haven't even defined. I'm not sure what MUST means in this context. I think without such a specification SHOULD and some explanatory text seems appropriate. Either way, let's try to close this one remaining issue and wrap up the draft. Thanks, Volker On 15.01.2013 08:33, Salvatore Loreto wrote: > > I do like the distinction between prioritization and preservation, > maybe we need clearly distinguish the two cases in the draft > > for prioritization a MUST could by reasonable indeed a statement like: > - "It *MUST* honor the local policy for *prioritizing* SIP requests..." > tell that the SIP element has to prioritize requests following the > policy but has still the possibility to discard in case of severe overload > > while for preserving a SHOULD seems to be more appropriate indeed a > statement like this: > - "It *SHOULD* honor the local policy for *preserving* SIP requests..." > tell that SIP element will follow local policy as long as the result > does not produce a severe overload (i.e. "the result is consistent with > the SIP Overload Algorithm) > > > /Salvatore > > On 1/14/13 8:08 PM, bruno.chatras@orange.com wrote: >> I'm not really happy with the SHOULD. I think we are mixing two >> different things: priority and preservation. For example, a local >> policy that gives priority to BYE requests over any other request MUST >> always be honored even in case of severe overload. This does not imply >> that BYE requests MUST always be preserved; just that they MUST be >> given priority over other requests. >> >> I don't see any problem with using MUST for local policies that assign >> priorities to some requests. Use of MUST would of course be a problem >> if we were to define local policies about preserving some requests, >> but it's not what we are trying to do. >> >> BC >> >>> -----Message d'origine----- >>> De : sip-overload-bounces@ietf.org [mailto:sip-overload- >>> bounces@ietf.org] De la part de DRAGE, Keith (Keith) >>> Envoyé : lundi 14 janvier 2013 18:28 >>> À : Charles Shen; Janet P Gunn >>> Cc : sip-overload@ietf.org; Hilt, Volker (Volker) >>> Objet : Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc- >>> load-control-event-package-05.txt >>> >>> I'm not convinced we have got to the bottom of the requirement yet. >>> Writing SHOULD is not an excuse for writing a poor requirement, yet >>> that seems currently to be the excuse for wring SHOULD instead of MUST. >>> Ideally I should still be able to still identify conformance or no >>> conformance to a SHOULD requirement. >>> >>> I suspect what we need to do is find a more specific requirement and >>> then cover the rest of the problem in more informative text, rather >>> than trying to address everything in a single requirement sentence. >>> >>> I agree that if we end up writing a SHOULD, then there should be >>> associated informative text that identifies the example circumstances >>> for ignoring the SHOULD. That has long been an unwritten rule, and >>> without it the SHOULD always gets interpreted as a MAY. >>> >>> Regards >>> >>> Keith >>> >>> >>>> -----Original Message----- >>>> From: sip-overload-bounces@ietf.org >>>> [mailto:sip-overload-bounces@ietf.org] >>>> On Behalf Of Charles Shen >>>> Sent: 14 January 2013 17:03 >>>> To: Janet P Gunn >>>> Cc: sip-overload@ietf.org; Hilt, Volker (Volker) >>>> Subject: Re: [sip-overload] Local Policy Re: I-D Action: >>>> draft-ietf-soc- load-control-event-package-05.txt >>>> >>>> I am not in favor of opening up more cans of whatever at this stage :) >>>> >>>> I think we just need to define and clarify the line. At least "the >>>> Overload >>>> Algorithm(s) in effect at that node" sounds much better than "the >>>> Overload Algorithm(s)" alone. (Optionally) plus something like "the >>>> interactions of those Overload Algorithms are out of scope". >>>> >>>> Thanks >>>> >>>> Charles >>>> >>>> On Mon, Jan 14, 2013 at 11:49 AM, Janet P Gunn wrote: >>>>> >>>>> My personal thought is that in each case, it would refer to the >>>>> Overload >>>>> Algorithm(s) in effect at that node. >>>>> >>>>> But that brings up a whole can of worms about interaction between >>>>> algorithms.. >>>>> >>>>> If the Event package has set up an a-priori Overload Control, and >>>>> then >>>> an >>>>> actual overload triggers a "feedback" Overload Control, how do they >>>>> interact? The max? the min? the "product" >>>>> >>>>> Is that a can of worms we want to open at this point? >>>>> >>>>> Janet >>>>> >>>>> charles.newyork@gmail.com wrote on 01/14/2013 11:36:34 AM: >>>>> >>>>>> From: Charles Shen >>>>>> To: Volker Hilt , Janet P >>> Gunn/USA/ >>>>>> CSC@CSC, "Vijay K. Gurbani" >>>>>> Cc: sip-overload@ietf.org >>>>>> Date: 01/14/2013 11:37 AM >>>>>> Subject: Re: [sip-overload] Local Policy Re: I-D Action: >>>>>> draft-ietf- soc-load-control-event-package-05.txt >>>>>> Sent by: charles.newyork@gmail.com >>>>>> >>>>>> Hi Volker, Janet and Vijay, >>>>>> >>>>>> Since we are talking about putting the same texts in the >>>>>> overload-control and event-package draft, would it be better to >>>>>> clarify a bit about "the SIP Overload Algorithm" in this sentence? >>>>>> >>>>>> "It is expected a SIP client will follow local policy as long as >>>>>> the result is consistent with the SIP Overload Algorithm." >>>>>> >>>>>> Specifically, are we referring to mechanisms in both drafts (and >>> in >>>>>> that case, should we add cross reference to them?) as well as any >>>>>> future Overload Algorithms? >>>>>> >>>>>> Thanks >>>>>> >>>>>> Charles >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Jan 14, 2013 at 11:15 AM, Volker Hilt >>>>>> wrote: >>>>>>> Vijay, >>>>>>> >>>>>>> the sentence Janet has proposed works for me. You can replace >>> the >>>>>>> sentence I had suggested after the first paragraph with Janets >>>>>>> proposal. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Volker >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 14.01.2013 17:15, Vijay K. Gurbani wrote: >>>>>>>> On 01/14/2013 10:09 AM, Volker Hilt wrote: >>>>>>>>> That works for me! >>>>>>>> >>>>>>>> Volker: Can either you or Janet please propose the exact >>>>>>>> wordings to go into the modified text I proposed in [1]? This >>>>>>>> will avoid any guesswork and expedite the process of getting >>> the drafts out. >>>>>>>> [1] >>>>>>>> http://www.ietf.org/mail-archive/web/sip- >>>> overload/current/msg00885.html >>>>>>>> Thanks, >>>>>>>> >>>>>>>> - vijay >>>>>>> _______________________________________________ >>>>>>> sip-overload mailing list >>>>>>> sip-overload@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sip-overload >>>> _______________________________________________ >>>> sip-overload mailing list >>>> sip-overload@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sip-overload >>> _______________________________________________ >>> sip-overload mailing list >>> sip-overload@ietf.org >>> https://www.ietf.org/mailman/listinfo/sip-overload >> _________________________________________________________________________________________________________________________ >> >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >> recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les >> messages electroniques etant susceptibles d'alteration, >> France Telecom - Orange decline toute responsabilite si ce message a >> ete altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for >> messages that have been modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> sip-overload mailing list >> sip-overload@ietf.org >> https://www.ietf.org/mailman/listinfo/sip-overload > > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload From bruno.chatras@orange.com Tue Jan 15 02:45:37 2013 Return-Path: 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 24C6C21F883F for ; Tue, 15 Jan 2013 02:45:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] 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 21AN7dAJzWiH for ; Tue, 15 Jan 2013 02:45:36 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 84A7E21F8841 for ; Tue, 15 Jan 2013 02:45:35 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 201FE18C8C5; Tue, 15 Jan 2013 11:45:34 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 0133827C06E; Tue, 15 Jan 2013 11:45:34 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Tue, 15 Jan 2013 11:45:33 +0100 From: To: Volker Hilt , "sip-overload@ietf.org" Thread-Topic: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt Thread-Index: AQHN8vKkF1BCelmLvkC+vZFzxyaLr5hKF0aAgAAajGA= Date: Tue, 15 Jan 2013 10:45:33 +0000 Message-ID: <26358_1358246734_50F5334E_26358_1656_1_88CAD1D4E8773F42858B58CAA28272A00F2185@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> <50E5B529.2090105@bell-labs.com> <50F01C82.9010406@bell-labs.com> <50F4146E.1080308@bell-labs.com> <50F422E4.8010809@bell-labs.com> <50F42D9F.1080002@bell-labs.com> <24379_1358186917_50F449A5_24379_12938_1_88CAD1D4E8773F42858B58CAA28272A00F1A88@PEXCVZYM12.corporate.adroot.infra.ftgroup> <50F5064F.4090008@ericsson.com> <50F5286F.9010605@bell-labs.com> In-Reply-To: <50F5286F.9010605@bell-labs.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 10:45:37 -0000 The problem I have with SHOULD is that it just means "RECOMMENDED". It impl= ies that a server that handle all requests the same way despite a local pol= icy giving priority to BYE requests can still claim conformance to the RFC. So I would just replace SHOULD with MUST in the following text since it mak= es already clear that we are talking about prioritization, not preservation. /// A SIP client SHOULD honor the local policy for prioritizing SIP requests=20 such as policies based on message type, e.g., INVITEs vs. requests=20 associated with existing sessions. A SIP client is expected generally to=20 honor local policy except for very rare occasions when, for example,=20 overload is so severe that messages, which should be preserved according=20 to local policy, need to be discarded or local policies are in conflict.=20 A SIP client SHOULD honor the local policy for prioritizing SIP requests=20 based on the content of the Resource-Priority header (RPH, RFC4412=20 [RFC4412]). Specific (namespace.value) RPH contents may indicate high=20 priority requests that should be preserved as much as possible during=20 overload. The RPH contents can also indicate a low-priority request=20 that is eligible to be dropped during times of overload.=20 A SIP client SHOULD honor the local policy for prioritizing SIP requests=20 relating to emergency calls, as identified by the SOS URN [RFC5031]=20 indicating an emergency request.=20 /// BC > -----Message d'origine----- > De=A0: sip-overload-bounces@ietf.org [mailto:sip-overload- > bounces@ietf.org] De la part de Volker Hilt > Envoy=E9=A0: mardi 15 janvier 2013 10:59 > =C0=A0: sip-overload@ietf.org > Objet=A0: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc- > load-control-event-package-05.txt >=20 > I think my general concern is that we are creating a MUST for something > that we haven't even defined. I'm not sure what MUST means in this > context. I think without such a specification SHOULD and some > explanatory text seems appropriate. >=20 > Either way, let's try to close this one remaining issue and wrap up the > draft. >=20 > Thanks, >=20 > Volker >=20 >=20 >=20 >=20 > On 15.01.2013 08:33, Salvatore Loreto wrote: > > > > I do like the distinction between prioritization and preservation, > > maybe we need clearly distinguish the two cases in the draft > > > > for prioritization a MUST could by reasonable indeed a statement like: > > - "It *MUST* honor the local policy for *prioritizing* SIP > requests..." > > tell that the SIP element has to prioritize requests following the > > policy but has still the possibility to discard in case of severe > > overload > > > > while for preserving a SHOULD seems to be more appropriate indeed a > > statement like this: > > - "It *SHOULD* honor the local policy for *preserving* SIP > requests..." > > tell that SIP element will follow local policy as long as the result > > does not produce a severe overload (i.e. "the result is consistent > > with the SIP Overload Algorithm) > > > > > > /Salvatore > > > > On 1/14/13 8:08 PM, bruno.chatras@orange.com wrote: > >> I'm not really happy with the SHOULD. I think we are mixing two > >> different things: priority and preservation. For example, a local > >> policy that gives priority to BYE requests over any other request > >> MUST always be honored even in case of severe overload. This does > not > >> imply that BYE requests MUST always be preserved; just that they > MUST > >> be given priority over other requests. > >> > >> I don't see any problem with using MUST for local policies that > >> assign priorities to some requests. Use of MUST would of course be a > >> problem if we were to define local policies about preserving some > >> requests, but it's not what we are trying to do. > >> > >> BC > >> > >>> -----Message d'origine----- > >>> De : sip-overload-bounces@ietf.org [mailto:sip-overload- > >>> bounces@ietf.org] De la part de DRAGE, Keith (Keith) Envoy=E9 : lundi > >>> 14 janvier 2013 18:28 =C0 : Charles Shen; Janet P Gunn Cc : > >>> sip-overload@ietf.org; Hilt, Volker (Volker) Objet : Re: > >>> [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc- > >>> load-control-event-package-05.txt > >>> > >>> I'm not convinced we have got to the bottom of the requirement yet. > >>> Writing SHOULD is not an excuse for writing a poor requirement, yet > >>> that seems currently to be the excuse for wring SHOULD instead of > MUST. > >>> Ideally I should still be able to still identify conformance or no > >>> conformance to a SHOULD requirement. > >>> > >>> I suspect what we need to do is find a more specific requirement > and > >>> then cover the rest of the problem in more informative text, rather > >>> than trying to address everything in a single requirement sentence. > >>> > >>> I agree that if we end up writing a SHOULD, then there should be > >>> associated informative text that identifies the example > >>> circumstances for ignoring the SHOULD. That has long been an > >>> unwritten rule, and without it the SHOULD always gets interpreted > as a MAY. > >>> > >>> Regards > >>> > >>> Keith > >>> > >>> > >>>> -----Original Message----- > >>>> From: sip-overload-bounces@ietf.org > >>>> [mailto:sip-overload-bounces@ietf.org] > >>>> On Behalf Of Charles Shen > >>>> Sent: 14 January 2013 17:03 > >>>> To: Janet P Gunn > >>>> Cc: sip-overload@ietf.org; Hilt, Volker (Volker) > >>>> Subject: Re: [sip-overload] Local Policy Re: I-D Action: > >>>> draft-ietf-soc- load-control-event-package-05.txt > >>>> > >>>> I am not in favor of opening up more cans of whatever at this > stage > >>>> :) > >>>> > >>>> I think we just need to define and clarify the line. At least "the > >>>> Overload > >>>> Algorithm(s) in effect at that node" sounds much better than > "the > >>>> Overload Algorithm(s)" alone. (Optionally) plus something like > "the > >>>> interactions of those Overload Algorithms are out of scope". > >>>> > >>>> Thanks > >>>> > >>>> Charles > >>>> > >>>> On Mon, Jan 14, 2013 at 11:49 AM, Janet P Gunn > wrote: > >>>>> > >>>>> My personal thought is that in each case, it would refer to the > >>>>> Overload > >>>>> Algorithm(s) in effect at that node. > >>>>> > >>>>> But that brings up a whole can of worms about interaction between > >>>>> algorithms.. > >>>>> > >>>>> If the Event package has set up an a-priori Overload Control, > and > >>>>> then > >>>> an > >>>>> actual overload triggers a "feedback" Overload Control, how do > >>>>> they interact? The max? the min? the "product" > >>>>> > >>>>> Is that a can of worms we want to open at this point? > >>>>> > >>>>> Janet > >>>>> > >>>>> charles.newyork@gmail.com wrote on 01/14/2013 11:36:34 AM: > >>>>> > >>>>>> From: Charles Shen > >>>>>> To: Volker Hilt , Janet P > >>> Gunn/USA/ > >>>>>> CSC@CSC, "Vijay K. Gurbani" > >>>>>> Cc: sip-overload@ietf.org > >>>>>> Date: 01/14/2013 11:37 AM > >>>>>> Subject: Re: [sip-overload] Local Policy Re: I-D Action: > >>>>>> draft-ietf- soc-load-control-event-package-05.txt > >>>>>> Sent by: charles.newyork@gmail.com > >>>>>> > >>>>>> Hi Volker, Janet and Vijay, > >>>>>> > >>>>>> Since we are talking about putting the same texts in the > >>>>>> overload-control and event-package draft, would it be better to > >>>>>> clarify a bit about "the SIP Overload Algorithm" in this > sentence? > >>>>>> > >>>>>> "It is expected a SIP client will follow local policy as long as > >>>>>> the result is consistent with the SIP Overload Algorithm." > >>>>>> > >>>>>> Specifically, are we referring to mechanisms in both drafts (and > >>> in > >>>>>> that case, should we add cross reference to them?) as well as > any > >>>>>> future Overload Algorithms? > >>>>>> > >>>>>> Thanks > >>>>>> > >>>>>> Charles > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Mon, Jan 14, 2013 at 11:15 AM, Volker Hilt > >>>>>> wrote: > >>>>>>> Vijay, > >>>>>>> > >>>>>>> the sentence Janet has proposed works for me. You can replace > >>> the > >>>>>>> sentence I had suggested after the first paragraph with Janets > >>>>>>> proposal. > >>>>>>> > >>>>>>> Cheers, > >>>>>>> > >>>>>>> Volker > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On 14.01.2013 17:15, Vijay K. Gurbani wrote: > >>>>>>>> On 01/14/2013 10:09 AM, Volker Hilt wrote: > >>>>>>>>> That works for me! > >>>>>>>> > >>>>>>>> Volker: Can either you or Janet please propose the exact > >>>>>>>> wordings to go into the modified text I proposed in [1]? This > >>>>>>>> will avoid any guesswork and expedite the process of getting > >>> the drafts out. > >>>>>>>> [1] > >>>>>>>> http://www.ietf.org/mail-archive/web/sip- > >>>> overload/current/msg00885.html > >>>>>>>> Thanks, > >>>>>>>> > >>>>>>>> - vijay > >>>>>>> _______________________________________________ > >>>>>>> sip-overload mailing list > >>>>>>> sip-overload@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/sip-overload > >>>> _______________________________________________ > >>>> sip-overload mailing list > >>>> sip-overload@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sip-overload > >>> _______________________________________________ > >>> sip-overload mailing list > >>> sip-overload@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sip-overload > >> > _____________________________________________________________________ > >> ____________________________________________________ > >> > >> > >> Ce message et ses pieces jointes peuvent contenir des informations > >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > >> exploites ou copies sans autorisation. Si vous avez recu ce message > >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi > >> que les pieces jointes. Les messages electroniques etant > susceptibles > >> d'alteration, France Telecom - Orange decline toute responsabilite > si > >> ce message a ete altere, deforme ou falsifie. Merci. > >> > >> This message and its attachments may contain confidential or > >> privileged information that may be protected by law; they should not > >> be distributed, used or copied without authorisation. > >> If you have received this email in error, please notify the sender > >> and delete this message and its attachments. > >> As emails may be altered, France Telecom - Orange is not liable for > >> messages that have been modified, changed or falsified. > >> Thank you. > >> > >> _______________________________________________ > >> sip-overload mailing list > >> sip-overload@ietf.org > >> https://www.ietf.org/mailman/listinfo/sip-overload > > > > > > _______________________________________________ > > sip-overload mailing list > > sip-overload@ietf.org > > https://www.ietf.org/mailman/listinfo/sip-overload > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From salvatore.loreto@ericsson.com Mon Jan 21 06:21:40 2013 Return-Path: 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 CE6CC21F86F8 for ; Mon, 21 Jan 2013 06:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 BMQYXuPj2eWG for ; Mon, 21 Jan 2013 06:21:40 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id DE6FF21F8460 for ; Mon, 21 Jan 2013 06:21:39 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-a7-50fd4ef2aa13 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id D1.F4.32353.2FE4DF05; Mon, 21 Jan 2013 15:21:38 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Mon, 21 Jan 2013 15:21:38 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 6E3E924ED for ; Mon, 21 Jan 2013 16:21:38 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 673125408A for ; Mon, 21 Jan 2013 16:21:36 +0200 (EET) Received: from n94.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 265A253A7B for ; Mon, 21 Jan 2013 16:21:36 +0200 (EET) Message-ID: <50FD4EF1.7090702@ericsson.com> Date: Mon, 21 Jan 2013 16:21:37 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: sip-overload@ietf.org References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> <50E5B529.2090105@bell-labs.com> <50F01C82.9010406@bell-labs.com> <50F4146E.1080308@bell-labs.com> <50F422E4.8010809@bell-labs.com> <50F42D9F.1080002@bell-labs.com> <50F44BC2.2080703@bell-labs.com> In-Reply-To: <50F44BC2.2080703@bell-labs.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUyM+Jvre4nv78BBocnWVjsf5rgwOixZMlP pgDGKC6blNSczLLUIn27BK6Mm3NusxWc4Kh4f+cicwPjSbYuRk4OCQETidPn21ghbDGJC/fW A8W5OIQETjJKLOu6yQjhbGCUeLb7D5RzjVFi/cL1LHBlzw5PA5slJHCQUeLFTR0Qm1dAW6Jp xmlGEJtFQFWiYcVMdhCbTcBM4vnDLcwgtqhAssTHO9dYIeoFJU7OfMICYosISEp8eT4RrFdY IFPi+fYLUJv72SW+r58CtoxTQFdi68n9TCA2s4CtxIU511kgbHmJ7W/nMEM8pCZx9dwmZojj tCR6z3YyTWAUmYVk3ywk7bOQtC9gZF7FyJ6bmJmTXm6+iREYzAe3/DbYwbjpvtghRmkOFiVx 3nDXCwFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGBMlLhWWiX024BYt8Qnw5+PIFC2OOcSp EZmkw8D2/FiS6p4rRuwZvWyRa/O2u2z2SOae+nVbKmtKw4bZ4RHXZPrT6nWei9c5fbfxmLf5 d8FlFZMlM0U3Te+d/VRAOz8oOeQPQ0i458klQee5LnxS7C99yVygee566zQOMyZZRUU17wtl UTeUWIozEg21mIuKEwH4akTMNAIAAA== Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 14:21:40 -0000 we have been discussing this issue (i.e. SHOULD vs MUST) over the last couple of weeks or even more. THE result is that an explanatory text is the key thing to have either way because of the different views on what a policy can and cannot be. having said that, my reading is that there is a large preference to use SHOULD with the explanatory text proposed by Vijay below Salvatore On 1/14/13 8:17 PM, Vijay K. Gurbani wrote: [snip] > > It is expected that a SIP client will follow local policy as long as > the results in reduction of traffic is consistent with the SIP > overload algorithm in effect at that node. Accordingly, the > normative behaviour in the next three paragraphs should be > interpreted with the understanding that the SIP client will aim to > preserve local policy to the fullest extent possible. > > And then we go down the three SHOULD paragraphs. > > I believe that suggesting specific text will help close this gap more > expeditiously. > > Is the above something that we can go with? > > Thanks, > > - vijay From volker.hilt@bell-labs.com Mon Jan 21 06:23:42 2013 Return-Path: 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 BE65421F881D for ; Mon, 21 Jan 2013 06:23:42 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqzrlulCRPgW for ; Mon, 21 Jan 2013 06:23:42 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 145FF21F8815 for ; Mon, 21 Jan 2013 06:23:41 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r0LDx4xa031475 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 21 Jan 2013 15:23:34 +0100 Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 21 Jan 2013 15:22:42 +0100 Received: from [149.204.61.163] (135.5.27.16) by US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 21 Jan 2013 09:22:36 -0500 Message-ID: <50FD4F2A.7000609@bell-labs.com> Date: Mon, 21 Jan 2013 15:22:34 +0100 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> <50E5B529.2090105@bell-labs.com> <50F01C82.9010406@bell-labs.com> <50F4146E.1080308@bell-labs.com> <50F422E4.8010809@bell-labs.com> <50F42D9F.1080002@bell-labs.com> <50F44BC2.2080703@bell-labs.com> <50FD4EF1.7090702@ericsson.com> In-Reply-To: <50FD4EF1.7090702@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.5.27.16] X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 14:23:42 -0000 Fine with me. Volker On 21.01.2013 15:21, Salvatore Loreto wrote: > we have been discussing this issue (i.e. SHOULD vs MUST) over the last > couple of weeks or even more. > THE result is that an explanatory text is the key thing to have either way > because of the different views on what a policy can and cannot be. > > having said that, > my reading is that there is a large preference to use SHOULD > with the explanatory text proposed by Vijay below > > Salvatore > > On 1/14/13 8:17 PM, Vijay K. Gurbani wrote: > > [snip] >> >> It is expected that a SIP client will follow local policy as long as >> the results in reduction of traffic is consistent with the SIP >> overload algorithm in effect at that node. Accordingly, the >> normative behaviour in the next three paragraphs should be >> interpreted with the understanding that the SIP client will aim to >> preserve local policy to the fullest extent possible. >> >> And then we go down the three SHOULD paragraphs. >> >> I believe that suggesting specific text will help close this gap more >> expeditiously. >> >> Is the above something that we can go with? >> >> Thanks, >> >> - vijay > > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload From salvatore.loreto@ericsson.com Mon Jan 28 05:53:12 2013 Return-Path: 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 ECE6321F845A for ; Mon, 28 Jan 2013 05:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 p7uE824ofFYd for ; Mon, 28 Jan 2013 05:53:11 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6D621F8432 for ; Mon, 28 Jan 2013 05:53:11 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-72-510682c626a9 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id F8.FC.32353.6C286015; Mon, 28 Jan 2013 14:53:10 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Mon, 28 Jan 2013 14:53:10 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id DCA18236D for ; Mon, 28 Jan 2013 15:53:09 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1BA365415B for ; Mon, 28 Jan 2013 15:53:08 +0200 (EET) Received: from n94.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C50555414E for ; Mon, 28 Jan 2013 15:53:07 +0200 (EET) Message-ID: <510682C5.1090800@ericsson.com> Date: Mon, 28 Jan 2013 15:53:09 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: sip-overload@ietf.org References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> <50E5B529.2090105@bell-labs.com> <50F01C82.9010406@bell-labs.com> <50F4146E.1080308@bell-labs.com> <50F422E4.8010809@bell-labs.com> <50F42D9F.1080002@bell-labs.com> <50F44BC2.2080703@bell-labs.com> <50FD4EF1.7090702@ericsson.com> In-Reply-To: <50FD4EF1.7090702@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUyM+Jvre6xJrZAgweTJSz2P01wYPRYsuQn UwBjFJdNSmpOZllqkb5dAlfGjw/H2Qsu81R0P33B1sD4ibOLkZNDQsBE4seHVYwQtpjEhXvr 2boYuTiEBE4ySvx4f5AJwtnAKDHl1goWCOcao0Rv4zpmkBawsgl/JCESBxkldj5dwASS4BXQ ljjb9RusiEVAVeJMx3wWEJtNwEzi+cMtYHFRgWSJj3eusULUC0qcnPkErEZEQFLiy/OJYDcJ C2RKPN9+gRFiwXp2idU3prGDJDgFdCTe93xmA7GZBWwlLsy5zgJhy0tsfzuHGeIhNYmr5zZB Xaol0Xu2k2kCo8gsJPtmIWmfhaR9ASPzKkb23MTMnPRy802MwGA+uOW3wQ7GTffFDjFKc7Ao ifOGu14IEBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cCoMGtXWqbjqpKbf/rcYmr0lZZ8Dz+9 XGa1j83cJ4bMfyfcOWcrfP7umaUvqxlqL56WOrfvh9KEmQpZtX8dPsqeFrSb7fjod59m8Rmm H0kKJq8EHNIsNj+sVJm5v8NssU/+nq6bXHzHuC49jIm9Xa0lyJF7qOXFx4C3t//I7JM5nSxf 0fj88sszSizFGYmGWsxFxYkAO65MxzQCAAA= Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 13:53:13 -0000 as co-chair I declare formal consensus on the SHOULD option the authors of the draft event-package and overload-control are invited to update their draft to reflect the decision best regards Salvatore On 1/21/13 4:21 PM, Salvatore Loreto wrote: > we have been discussing this issue (i.e. SHOULD vs MUST) over the last > couple of weeks or even more. > THE result is that an explanatory text is the key thing to have either > way > because of the different views on what a policy can and cannot be. > > having said that, > my reading is that there is a large preference to use SHOULD > with the explanatory text proposed by Vijay below > > Salvatore > > On 1/14/13 8:17 PM, Vijay K. Gurbani wrote: > > [snip] >> >> It is expected that a SIP client will follow local policy as long as >> the results in reduction of traffic is consistent with the SIP >> overload algorithm in effect at that node. Accordingly, the >> normative behaviour in the next three paragraphs should be >> interpreted with the understanding that the SIP client will aim to >> preserve local policy to the fullest extent possible. >> >> And then we go down the three SHOULD paragraphs. >> >> I believe that suggesting specific text will help close this gap more >> expeditiously. >> >> Is the above something that we can go with? >> >> Thanks, >> >> - vijay > > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload > > -- Salvatore Loreto, PhD www.sloreto.com From charles.newyork@gmail.com Tue Jan 29 07:29:42 2013 Return-Path: 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 7F30821F892F for ; Tue, 29 Jan 2013 07:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 P1-3um6bdYK9 for ; Tue, 29 Jan 2013 07:29:41 -0800 (PST) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by ietfa.amsl.com (Postfix) with ESMTP id C152C21F8923 for ; Tue, 29 Jan 2013 07:29:41 -0800 (PST) Received: by mail-oa0-f54.google.com with SMTP id n9so554112oag.13 for ; Tue, 29 Jan 2013 07:29:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=dMgg2XDKn2vlrkWXL8VdKjkw7sokMQ4E4nk6ecApgLg=; b=dMWRX6uGCKna8JqqVyBfR9WbZ4deO/U0l9SaT5O4L/Q2DJsZ3oF2vNFLyALx69Wd/9 UoRz2URD5tbAREVqZ175ToHJ9cqF7rH4ydU+ZdJD18+NjRxP1kK/Toceg31VHGepQ7yT prKr+H2Rn6H1DHb6/IBmHf9U9ZIVgthqRJHOgsv3lIri2KFY1h3tIX3ZHK4iIny71kZA 2iCVrPQ2EzOEqc/d1fKuSRC8ptCJ7WwFy4g7kUuf8QfeoryiFlqG2l5Q9NF1US+pkyzU fQCtSYv+2KvHMhgfSW8dHFKHza4SCc41hVlJoqV9m/KnCJOM88V24kKDvghuzm4U/YN+ Z/LA== X-Received: by 10.60.31.6 with SMTP id w6mr1016303oeh.65.1359473381204; Tue, 29 Jan 2013 07:29:41 -0800 (PST) MIME-Version: 1.0 Sender: charles.newyork@gmail.com Received: by 10.182.151.82 with HTTP; Tue, 29 Jan 2013 07:29:21 -0800 (PST) In-Reply-To: <510682C5.1090800@ericsson.com> References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> <50E5B529.2090105@bell-labs.com> <50F01C82.9010406@bell-labs.com> <50F4146E.1080308@bell-labs.com> <50F422E4.8010809@bell-labs.com> <50F42D9F.1080002@bell-labs.com> <50F44BC2.2080703@bell-labs.com> <50FD4EF1.7090702@ericsson.com> <510682C5.1090800@ericsson.com> From: Charles Shen Date: Tue, 29 Jan 2013 10:29:21 -0500 X-Google-Sender-Auth: YtmWJBqycmQ702mTCA9ZtDwhJDE Message-ID: To: vkg@bell-labs.com Content-Type: text/plain; charset=UTF-8 Cc: sip-overload@ietf.org Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 15:29:42 -0000 Dear Vijay, I just want to make sure I include the exact texts that have been finally agreed on. Could you please post the complete version of the final texts on this issue again, and I will update the event package draft right away. Thanks! Charles On Mon, Jan 28, 2013 at 8:53 AM, Salvatore Loreto wrote: > > as co-chair I declare formal consensus on the SHOULD option > > the authors of the draft event-package and overload-control are invited to > update their draft > to reflect the decision > > best regards > Salvatore > > > On 1/21/13 4:21 PM, Salvatore Loreto wrote: >> >> we have been discussing this issue (i.e. SHOULD vs MUST) over the last >> couple of weeks or even more. >> THE result is that an explanatory text is the key thing to have either way >> because of the different views on what a policy can and cannot be. >> >> having said that, >> my reading is that there is a large preference to use SHOULD >> with the explanatory text proposed by Vijay below >> >> Salvatore >> >> On 1/14/13 8:17 PM, Vijay K. Gurbani wrote: >> >> [snip] >>> >>> >>> It is expected that a SIP client will follow local policy as long as >>> the results in reduction of traffic is consistent with the SIP >>> overload algorithm in effect at that node. Accordingly, the >>> normative behaviour in the next three paragraphs should be >>> interpreted with the understanding that the SIP client will aim to >>> preserve local policy to the fullest extent possible. >>> >>> And then we go down the three SHOULD paragraphs. >>> >>> I believe that suggesting specific text will help close this gap more >>> expeditiously. >>> >>> Is the above something that we can go with? >>> >>> Thanks, >>> >>> - vijay >> >> >> >> _______________________________________________ >> sip-overload mailing list >> sip-overload@ietf.org >> https://www.ietf.org/mailman/listinfo/sip-overload >> >> > > > -- > Salvatore Loreto, PhD > www.sloreto.com > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload