From james.yu@neustar.biz Tue Jul 2 06:42: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 51B7621F9E26; Tue, 2 Jul 2013 06:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4g7blZ77ibgZ; Tue, 2 Jul 2013 06:42:09 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id DFF0621F9E20; Tue, 2 Jul 2013 06:42:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1372772702; x=1688127746; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=bkZRGI+vvZVupKgSpredY/8IkkT7n56W7Lmr+8+mOn4=; b=X64CCmk5Yt83FHRYj4KbXsPMzuBEonKBMDXYMp952w/KvaqdA/HAy4rKQ2IML9 sXAD3GE/WqvB5m6JEwQwoDXw== Received: from ([10.31.58.70]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.26019898; Tue, 02 Jul 2013 09:45:01 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Tue, 2 Jul 2013 09:42:00 -0400 From: "Yu, James" To: Janet P Gunn Thread-Topic: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Thread-Index: Ac5zhcqru7dYQFxqQKSGvvGKSQFJEAA0j1MAALOuppA= Date: Tue, 2 Jul 2013 13:41:59 +0000 Message-ID: <56FB15AFE08E1242B0736CBDCE6E85610808EF90@stntexmb12.cis.neustar.com> References: <56FB15AFE08E1242B0736CBDCE6E85610808C32F@stntexmb12.cis.neustar.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.31.32.114] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: RFf4NfUO719f+/+H9MUOWg== Content-Type: multipart/alternative; boundary="_000_56FB15AFE08E1242B0736CBDCE6E85610808EF90stntexmb12cisne_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 02 Jul 2013 07:29:05 -0700 Cc: "sip-overload-bounces@ietf.org" , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" , "sip-overload@ietf.org" Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.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, 02 Jul 2013 13:42:13 -0000 --_000_56FB15AFE08E1242B0736CBDCE6E85610808EF90stntexmb12cisne_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Janet, For my comment on section 3.4 (the first one below), the current text does = not provide any value. The client's arrival rate could be well below the t= arget SIP request rate when its load is light so the fact that the client m= ay not achieve the target SIP request rate (the max. rate it is allowed to = send to the server) is well understood. But with your explanation on the "= delta" part, the text then makes sense. Please add some discussions on the= "delta" aspect so that even if the average arrival rate at the client is h= igher than the target SIP request rate the client at times may not send mor= e than what the target SIP request rate allows due to the fluctuation of th= e arriving requests at the client. For the comment on section 3.5.1, I agree with your proposed change. For the rate control, the server could calculate the arrival rate from each= communicating client so that it could allocate the overall target SIP requ= est rate to the clients based on their arrival rates known to the server. = But another option is for the client to "optionally" include its calculated= arrival rate in its request to the server when rate control related parame= ters are present. Should this option be evaluated/included to relieve the = server from doing the arrival rate calculations. This would be beneficial = to a server when it receives the requests from many clients. James From: Janet P Gunn [mailto:jgunn6@csc.com] Sent: Friday, June 28, 2013 3:34 PM To: Yu, James Cc: draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@i= etf.org; sip-overload-bounces@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, It is a little hard to respond in email when your comments are in a separat= e document, but here goes. section 3.4 ID says: "Note that the target SIP request rate is a max rate that may not be attained by the arrival rate at the client, and the server cannot assume that it will." Your comment : "Not clear what value this paragraph tries to add. Is it saying that the c= lient's arrival rate may be lower than the target SIP request rate? " Yes. Suppose the server want to limit the total rate of arriving SIP messages to= 100 / sec, and has 10 clients. Each client has a high variance in its mes= sage rate, but together they are well above 100 messages per sec If it sets the rate at 10 messages per second for each of the clients, it w= ill almost certainly end up with an overall average of less than 100 messa= ges per sec, because some clients will be in a "lull" while others are busy= . This is good from a throttling perspective, but, assuming messages are c= orrelated with revenue, bad/wasteful from a revenue, or overall productivit= y perspective. So the server might want to set the rate per client to 10 += delta, where delta is going to be very specific to operating environment. --- In section 3.5.1, bottom of page 8 ID says: "And the larger the difference between TAU1 and TAU2, the closer to the control is to strict priority." You propose changing it to: "And the larger the difference between TAU1 and TAU2, the closer the control is to strict priority queuing." I agree with taking out the redundant "to". But I disagree wit adding "que= uing". There is no queuing, priority or otherwise involved. You could say: "And the larger the difference between TAU1 and TAU2, the closer the control is to strict priority treatment." where " strict priority treatment" would refer to the case where non-priori= ty messages are restricted to a total (priority + non-priority) rate of 10 = messages per second, but priority messages can continue to be sent as long = as the total (priority + non-priority) rate is less than 12 messages per se= cond. At least, I think that is what Eric and Philip are trying to say. 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: "Yu, James" = > To: "sip-overload-bounces@ietf.org" >= , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" >, "sip-overload@ietf.org"= > Date: 06/28/2013 08:10 AM Subject: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Sent by: sip-overload-bounces@ietf.org ________________________________ Salvatore, Please see the attachment for my comments. I pasted the text to a word document to trace/show the proposed changes and= comments. Regards, James [attachment "comments on draft-ietf-soc-overload-rate-control-04.docx" del= eted by Janet P Gunn/USA/CSC] _____________________________________________= __ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6452 - Release Date: 06/30/13 --_000_56FB15AFE08E1242B0736CBDCE6E85610808EF90stntexmb12cisne_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Janet,<= /p>

 <= /p>

For my comment on section= 3.4 (the first one below), the current text does not provide any value.&nb= sp; The client’s arrival rate could be well below the target SIP request rate when its load is light so the fact that the client may no= t achieve the target SIP request rate (the max. rate it is allowed to send = to the server) is well understood.  But with your explanation on the &= #8220;delta” part, the text then makes sense.  Please add some discussions on the “delta” aspect so that even= if the average arrival rate at the client is higher than the target SIP re= quest rate the client at times may not send more than what the target SIP r= equest rate allows due to the fluctuation of the arriving requests at the client.

 <= /p>

For the comment on sectio= n 3.5.1, I agree with your proposed change.

 <= /p>

For the rate control, the= server could calculate the arrival rate from each communicating client so = that it could allocate the overall target SIP request rate to the clients based on their arrival rates known to the server.  But= another option is for the client to “optionally” include its c= alculated arrival rate in its request to the server when rate control relat= ed parameters are present.  Should this option be evaluated/included to relieve the server from doing the arrival rate calcu= lations.  This would be beneficial to a server when it receives the re= quests from many clients.

 <= /p>

James

 <= /p>

From: Janet P = Gunn [mailto:jgunn6@csc.com]
Sent: Friday, June 28, 2013 3:34 PM
To: Yu, James
Cc: draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-ove= rload@ietf.org; sip-overload-bounces@ietf.org
Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt

 

James,

It is a little hard to respond in email when your comments are i= n a separate document, but here goes.


section 3.4
ID says:
"Note that the target SIP request rate is a max rate that m= ay not be
   attained by the arrival rate at the client, and the= server cannot
   assume that it will."

Your comment :
"Not clear what value this paragraph tries to add.  Is= it saying that the client's arrival rate may be lower than the target SIP = request rate?  "

Yes.

Suppose the server want to limit the total rate of arriving SIP = messages to 100 / sec, and has 10 clients.  Each client has a high var= iance in its message rate, but together they are well above 100 messages per sec

If it sets the rate at 10 messages per second for each of the cl= ients, it will almost certainly end up  with an overall average of les= s than 100 messages per sec, because some clients will be in a "lull" while others are busy.  This is good from a thrott= ling perspective, but, assuming messages are correlated with revenue, bad/w= asteful from a revenue, or overall productivity perspective.  So the s= erver might want to set the rate per client to 10 + delta, where delta is going to be very specific to operating environment.<= /span>

---
In section  3.5.1, bottom of page 8
ID says:
"And the larger
   the difference between TAU1 and TAU2, the closer to= the control is
   to strict priority."

You propose changing it to:
"And the larger
   the difference between TAU1 and TAU2, the closer &n= bsp;the control is
   to strict priority queuing."

I agree with taking out the redundant "to".  But = I disagree wit adding "queuing".  There is no queuing, prior= ity or otherwise involved.

You could say:
"And the larger
   the difference between TAU1 and TAU2, the closer &n= bsp;the control is
   to strict priority treatment."

where " strict priority treatment" would refer to the = case where non-priority messages are restricted to a total (priority + = non-priority) rate of 10 messages per second, but priority messages can continue to be sent as long as the total (priority + non-priority)= rate is less than 12 messages per second.

At least, I think that is what Eric and  Philip are trying = to say.

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 agreement or government initiative exp= ressly permitting the use of e-mail for such purpose.



From:        &= quot;Yu, James" <james.yu@n= eustar.biz>
To:        &= quot;sip-overload-bounces@= ietf.org" <sip= -overload-bounces@ietf.org>, "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" &l= t;draft-ietf-soc-overload-rate-control.all@tools.ietf.org>, "sip-overload@ietf.org&q= uot; <sip-overload@ietf.org= >
Date:        0= 6/28/2013 08:10 AM
Subject:        [sip-overload] draft-ietf-soc-overload-rate-control-04.txt
Sent by:        sip-overload-bounces@iet= f.org




Salvatore,
 
Please see the attachment for my comments.
 
I pasted the text to a word document to trace/show the propose= d changes and comments.
 
Regards,
 
James
 [attachment "comments on draft-ietf-soc-overload-ra= te-control-04.docx" deleted by Janet P Gunn/USA/CSC] _______________________________= ________________
sip-overload mailing list
sip-overload@ietf.org=
<= span style=3D"font-size:10.0pt">https://www.ietf.org/mailman/listinfo/sip-o= verload

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 3204/6452 - Release Date: 06/30/13

--_000_56FB15AFE08E1242B0736CBDCE6E85610808EF90stntexmb12cisne_-- From ecnoel@research.att.com Mon Jul 8 16:34: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 6BB7021F9130; Mon, 8 Jul 2013 16:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGqRd+kH2osi; Mon, 8 Jul 2013 16:34:32 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 9E59711E80E3; Mon, 8 Jul 2013 16:34:31 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 5CC8C120445; Mon, 8 Jul 2013 19:34:27 -0400 (EDT) Received: from njfpsrvexg2.research.att.com (njfpsrvexg2.research.att.com [135.207.177.29]) by mail-blue.research.att.com (Postfix) with ESMTP id ECD89F035E; Mon, 8 Jul 2013 19:34:27 -0400 (EDT) Received: from njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9]) by njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9%14]) with mapi; Mon, 8 Jul 2013 19:34:27 -0400 From: "NOEL, ERIC C (ERIC C)" To: 'Janet P Gunn' , Christer Holmberg Date: Mon, 8 Jul 2013 19:34:26 -0400 Thread-Topic: [sip-overload] NaN? RE: WGLC: draft-ietf-soc-overload-rate-control - Christer's comments Thread-Index: Ac50EnS/YoXUUMYZQza9CySEFn2SGgIHs60g Message-ID: <5EBD159DE88147488A3B1590E09001840353BDA4CABE@njfpsrvexg2.research.att.com> References: <7594FB04B1934943A5C02806D1A2204B1C3BD16D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C3BD239@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C3BD25A@ESESSMB209.ericsson.se> 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_5EBD159DE88147488A3B1590E09001840353BDA4CABEnjfpsrvexg2_" MIME-Version: 1.0 Cc: "sip-overload-bounces@ietf.org" , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" , "sip-overload@ietf.org" Subject: Re: [sip-overload] NaN? RE: WGLC: draft-ietf-soc-overload-rate-control - Christer's comments 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, 08 Jul 2013 23:34:37 -0000 --_000_5EBD159DE88147488A3B1590E09001840353BDA4CABEnjfpsrvexg2_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SmFuZXQsIENocmlzdGVyLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMgYW5kIGRpc2N1 c3Npb24uDQoNCkFjdHVhbGx5IHdlIGRpZCBub3QgZGVmaW5lIGFueSBvcGVyYXRpb24gZm9yIG9j ICA9ICJOYU4iLg0KDQpJbiBzZWN0aW9uIDUuMCwgSSBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgY2hh bmdlICh3aGF0IGlzIHVzZWQgaW4gZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtY29udHJvbC0xMik6 DQoNClJlcGxhY2Ugb2MtdmFsdWUgPSAiTmFOIiAvIG9jLW51bSAgIGJ5ICAgb2MgPSAib2MiIFtF UVVBTCBvYy1udW1dDQoNClBsZWFzZSBjb25maXJtIHRoaXMgY2hhbmdlIHdvdWxkIGFkZHJlc3Mg dGhlIGlzc3VlLg0KDQpUaGFua3MsDQoNCkVyaWMgTm9lbA0KQVQmVCBMYWJzLCBJbmMuDQpSZXRo aW5rIFBvc3NpYmxlDQoNCk5ldHdvcmsgRGVzaWduIGFuZCBQZXJmb3JtYW5jZSBBbmFseXNpcw0K MjAwIFNvdXRoIExhdXJlbCBBdmVudWUsIEQ1LTNEMTkNCk1pZGRsZXRvd24sIE5KIDA3NzQ4DQpQ OiA3MzIuNDIwLjQxNzQNCmVjbm9lbEBhdHQuY29tPG1haWx0bzpqc21pdGhAYXR0LmNvbT4NCg0K RnJvbTogc2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzaXAtb3ZlcmxvYWQt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEphbmV0IFAgR3Vubg0KU2VudDogRnJpZGF5 LCBKdW5lIDI4LCAyMDEzIDExOjE2IEFNDQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcNCkNjOiBzaXAt b3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1j b250cm9sLmFsbEB0b29scy5pZXRmLm9yZzsgc2lwLW92ZXJsb2FkQGlldGYub3JnDQpTdWJqZWN0 OiBbc2lwLW92ZXJsb2FkXSBOYU4/IFJFOiBXR0xDOiBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1y YXRlLWNvbnRyb2wgLSBDaHJpc3RlcidzIGNvbW1lbnRzDQoNClRoYW5rcyBDaHJpc3RlciwNCg0K U3ludGF4IGlzIGRlZmluaXRlbHkgTk9UIG15IGFyZWEgb2YgZXhwZXJ0aXNlLCBzbyBJIHdpbGwg bGV0IHRoZSBhdXRob3JzIGZvbGxvdyB1cC4NCg0KRXJpYyBhbmQgUGhpbGlwLA0KV2hhdCBpcyBz dXBwb3NlZCB0byBoYXBwZW4gd2hlbiBvYyA9ICJOYU4iPyAgSSBkbyBub3Qgc2VlIGFueSByZWZl cmVuY2UgdG8gaXQgaW4gdGhlIHJlc3Qgb2YgdGhlIGRvY3VtZW50LiAgSXMgaXQgZXZlbiBuZWVk ZWQ/DQoNCkphbmV0DQoNClRoaXMgaXMgYSBQUklWQVRFIG1lc3NhZ2UuIElmIHlvdSBhcmUgbm90 IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgd2l0aG91dCBjb3B5aW5nIGFu ZCBraW5kbHkgYWR2aXNlIHVzIGJ5IGUtbWFpbCBvZiB0aGUgbWlzdGFrZSBpbiBkZWxpdmVyeS4g Tk9URTogUmVnYXJkbGVzcyBvZiBjb250ZW50LCB0aGlzIGUtbWFpbCBzaGFsbCBub3Qgb3BlcmF0 ZSB0byBiaW5kIENTQyB0byBhbnkgb3JkZXIgb3Igb3RoZXIgY29udHJhY3QgdW5sZXNzIHB1cnN1 YW50IHRvIGV4cGxpY2l0IHdyaXR0ZW4gYWdyZWVtZW50IG9yIGdvdmVybm1lbnQgaW5pdGlhdGl2 ZSBleHByZXNzbHkgcGVybWl0dGluZyB0aGUgdXNlIG9mIGUtbWFpbCBmb3Igc3VjaCBwdXJwb3Nl Lg0KDQoNCg0KRnJvbTogICAgICAgIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+DQpU bzogICAgICAgIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5j b208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+LCBKYW5ldCBQIEd1bm4v VVNBL0NTQ0BDU0MNCkNjOiAgICAgICAgInNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZz4iIDxzaXAtb3ZlcmxvYWQtYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc+PiwgImRyYWZ0 LWlldGYtc29jLW92ZXJsb2FkLXJhdGUtY29udHJvbC5hbGxAdG9vbHMuaWV0Zi5vcmc8bWFpbHRv OmRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLXJhdGUtY29udHJvbC5hbGxAdG9vbHMuaWV0Zi5vcmc+ IiA8ZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLmFsbEB0b29scy5pZXRmLm9y ZzxtYWlsdG86ZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLmFsbEB0b29scy5p ZXRmLm9yZz4+LCAic2lwLW92ZXJsb2FkQGlldGYub3JnPG1haWx0bzpzaXAtb3ZlcmxvYWRAaWV0 Zi5vcmc+IiA8c2lwLW92ZXJsb2FkQGlldGYub3JnPG1haWx0bzpzaXAtb3ZlcmxvYWRAaWV0Zi5v cmc+Pg0KRGF0ZTogICAgICAgIDA2LzI4LzIwMTMgMDM6MjUgQU0NClN1YmplY3Q6ICAgICAgICBS RTogW3NpcC1vdmVybG9hZF0gV0dMQzogZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250 cm9sIC0gQ2hyaXN0ZXIncyBjb21tZW50cw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCg0KDQoNClRoZSBmb2xsb3dpbmcgaXMgb2J2aW91c2x5IG5vdCBuZWVkZWQgaW4gZHJhZnQt aWV0Zi1zb2Mtb3ZlcmxvYWQtY29udHJvbDoNCg0KIkVRVUFMIiBpcyBkZWZpbmVkIGluIFJGQyAz MjYxLiAgIkRJR0lUIiBpcyBkZWZpbmVkIGluIFJGQyA1MjM0Lg0KDQoNCkZyb206IHNpcC1vdmVy bG9hZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9y Zz4gW21haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENo cmlzdGVyIEhvbG1iZXJnDQpTZW50OiAyOC4ga2Vzw6RrdXV0YSAyMDEzIDk6MjcNClRvOiBKYW5l dCBQIEd1bm4NCkNjOiBzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2lwLW92 ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1yYXRlLWNv bnRyb2wuYWxsQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1y YXRlLWNvbnRyb2wuYWxsQHRvb2xzLmlldGYub3JnPjsgc2lwLW92ZXJsb2FkQGlldGYub3JnPG1h aWx0bzpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NpcC1vdmVybG9hZF0g V0dMQzogZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sIC0gQ2hyaXN0ZXIncyBj b21tZW50cw0KDQpIaSwNCg0KU28sIHdpdGggdGhlIHRoaXJkIGFsdGVybmF0aXZlLCBTZWN0aW9u IDUgd291bGQgbG9vayBzb21ldGhpbmcgbGlrZToNCg0KNS4gIFN5bnRheA0KDQogICBUaGlzIHNw ZWNpZmljYXRpb24gZXh0ZW5kcyB0aGUgZXhpc3RpbmcgZGVmaW5pdGlvbiBvZiB0aGUgVmlhIGhl YWRlcg0KICAgZmllbGQgcGFyYW1ldGVycyBvZiBbUkZDMzI2MV0gYXMgZm9sbG93czoNCg0KICAg ICAgICB2aWEtcGFyYW1zID0vIG9jLW5hbg0KICAgICAgIG9jLW5hbiAgICAgID0gIk5hTiINCg0K DQpCVFcsIEkgdGhpbmsgdGhlIHN5bnRheCBpbiBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1jb250 cm9sIHNob3VsZCBsb29rIGxpa2U6DQoNCiAgICAgICAgdmlhLXBhcmFtcyAgPS8gb2MgLyBvYy12 YWxpZGl0eSAvIG9jLXNlcSAvIG9jLWFsZ28NCg0KICAgICAgIG9jICAgICAgICAgID0gIm9jIiBb RVFVQUwgb2MtbnVtXQ0KICAgICAgIG9jLW51bSAgICAgID0gMSpESUdJVA0KICAgICAgIG9jLXZh bGlkaXR5ID0gIm9jLXZhbGlkaXR5IiBbRVFVQUwgZGVsdGEtbXNdDQogICAgICAgb2Mtc2VxICAg ICAgPSAib2Mtc2VxIiBFUVVBTCAxKjEyRElHSVQgIi4iIDEqNURJR0lUDQogICAgICAgb2MtYWxn byAgICAgPSAib2MtYWxnbyIgRVFVQUwgRFFVT1RFIGFsZ28tbGlzdCAqKENPTU1BIGFsZ28tbGlz dCkNCiAgICAgICAgICAgICAgICAgICAgIERRVU9URQ0KICAgICAgIGFsZ28tbGlzdCAgID0gImxv c3MiIC8gKihvdGhlci1hbGdvKQ0KICAgICAgIG90aGVyLWFsZ28gID0gJXg0MS01QSAvICV4NjEt N0EgLyAleDMwLTM5DQogICAgICAgZGVsdGEtbXMgICAgPSAxKkRJR0lUDQoNCg0KSW4gYm90aCBk cmFmdHMsIEkgd291bGQgYWxzbyBzdWdnZXN0IHRvIHJld3JpdGUgdGhlIFN5bnRheCBzZWN0aW9u cyBpbiB0aGUgZm9sbG93aW5nIHdheToNCg0KNS4gIEdyYW1tYXINCg0KNS4xLiAgR2VuZXJhbA0K DQogICBUaGlzIHNlY3Rpb24gZXh0ZW5kcyB0aGUgQUJORiBkZWZpbml0aW9uIG9mIHZpYS1wYXJh bXMgZnJvbSBbUkZDMzI2MV0NCiAgIGJ5IGFkZGluZyBhIG5ldyBWaWEgaGVhZGVyIGZpZWxkIHBh cmFtZXRlciwgIm9jLW5hbiIuICBUaGUgQUJORiBkZWZpbmVkDQogICBpbiB0aGlzIHNwZWNpZmlj YXRpb24gaXMgY29uZm9ybWFudCB0byBSRkMgNTIzNCBbUkZDNTIzNF0uICAiRVFVQUwiDQogICBp cyBkZWZpbmVkIGluIFJGQyAzMjYxLiAgIkRJR0lUIiBpcyBkZWZpbmVkIGluIFJGQyA1MjM0Lg0K DQo1LjIuICBBQk5GDQoNCiAgIHZpYS1wYXJhbXMgPS8gb2MtbmFuDQogICBvYy1uYW4gICAgICA9 ICJOYU4iDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQoNCkZyb206IENocmlzdGVyIEhv bG1iZXJnDQpTZW50OiAyOC4ga2Vzw6RrdXV0YSAyMDEzIDg6NDANClRvOiBDaHJpc3RlciBIb2xt YmVyZzsgSmFuZXQgUCBHdW5uDQpDYzogc2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPjsgZHJhZnQtaWV0Zi1zb2Mtb3Zlcmxv YWQtcmF0ZS1jb250cm9sLmFsbEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1zb2Mt b3ZlcmxvYWQtcmF0ZS1jb250cm9sLmFsbEB0b29scy5pZXRmLm9yZz47IHNpcC1vdmVybG9hZEBp ZXRmLm9yZzxtYWlsdG86c2lwLW92ZXJsb2FkQGlldGYub3JnPg0KU3ViamVjdDogVlM6IFtzaXAt b3ZlcmxvYWRdIFdHTEM6IGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLXJhdGUtY29udHJvbCAtIENo cmlzdGVyJ3MgY29tbWVudHMNCg0KSGksDQoNCkEgdGhpcmQgYWx0ZXJuYXRpdmUgKHByb2JhYmx5 IHRoZSBlYXNpZXN0IG9uZSwgYXQgbGVhc3QgZnJvbSBhIHN5bnRheCBwZXJzcGVjdGl2ZSkgd291 bGQgYmUgdG8gc2ltcGx5IGRlZmluZSBhIG5ldyDigJxvYy1uYW7igJ0gVmlhIGhlYWRlciBmaWVs ZCBwYXJhbWV0ZXIuDQoNCm9jLW5hbiAgICAgICAgICA9ICJuYW4iDQoNCuKApm9yIHNvbWV0aGlu ZyBsaWtlIHRoYXQuDQoNCkl0IHdvdWxkIG5vdCByZXF1aXJlIGFueSBjaGFuZ2VzIHRvIGRyYWZ0 LWlldGYtc29jLW92ZXJsb2FkLWNvbnRyb2wgLg0KDQooVGhlbiwgaW4gdGhlIHByb2NlZHVyZSBz ZWN0aW9ucyB5b3UgbmVlZCB0byBkZXNjcmliZSBob3cvd2hldGhlciB0aGUgb2MgYW5kIG9jLW5h biBwYXJhbWV0ZXJzIGNhbiBiZSB1c2VkIGF0IHRoZSBzYW1lIHRpbWUgZXRjLCBidXQgdGhhdCBp cyBub3QgYSBzeW50YXggcXVlc3Rpb24uKQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCkzD pGhldHTDpGrDpDogc2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNpcC1vdmVy bG9hZC1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYu b3JnXSBQdW9sZXN0YSBDaHJpc3RlciBIb2xtYmVyZw0KTMOkaGV0ZXR0eTogMjcuIGtlc8Oka3V1 dGEgMjAxMyAyMjo0Mg0KVmFzdGFhbm90dGFqYTogSmFuZXQgUCBHdW5uDQpLb3Bpbzogc2lwLW92 ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYu b3JnPjsgZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLmFsbEB0b29scy5pZXRm Lm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLmFsbEB0b29s cy5pZXRmLm9yZz47IHNpcC1vdmVybG9hZEBpZXRmLm9yZzxtYWlsdG86c2lwLW92ZXJsb2FkQGll dGYub3JnPg0KQWloZTogUmU6IFtzaXAtb3ZlcmxvYWRdIFdHTEM6IGRyYWZ0LWlldGYtc29jLW92 ZXJsb2FkLXJhdGUtY29udHJvbCAtIENocmlzdGVyJ3MgY29tbWVudHMNCg0KSGksDQoNCldoZW4g dGFraW5nIGEgY2xvc2VyIGxvb2ssIEkgYWN0dWFsbHkgdGhpbmsgdGhlcmUgaXMgc29tZXRoaW5n IHRlY2huaWNhbGx5IHdyb25nIHdpdGggdGhlIHN5bnRheCBpbiBTZWN0aW9uIDUgb2YgZHJhZnQt aWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLg0KDQpkcmFmdC1pZXRmLXNvYy1vdmVybG9h ZC1jb250cm9sICBkZWZpbmVzIHRoZSBvYyBwYXJhbWV0ZXIgYXM6DQoNCm9jICAgICAgICAgID0g Im9jIiBbRVFVQUwgb2MtbnVtXQ0KDQoNCk5vdywgaXQgc2VlbXMgbGlrZSBkcmFmdC1pZXRmLXNv Yy1vdmVybG9hZC1yYXRlLWNvbnRyb2wgYWN0dWFsbHkgcmUtZGVmaW5lcyB0aGUgc2FtZSBwYXJh bWV0ZXIuIEluIGFkZGl0aW9uLCBpdOKAmXMgZG9uZSBpbiBhIGJhY2t3YXJkIGNvbXBhdGlibGUg bWFubmVyLCBlLmcuIGJlY2F1c2UgdGhlIHBhcmFtZXRlciBjYW4gbm93IGNvbnRhaW4gYSBub24t bnVtZXJpYyB2YWx1ZSAoc2VlIHRoZSBidWxsZXQgbGlzdCBiZWxvdyB3aGF0IGNhbiBnbyB3cm9u Zyk6DQoNCm9jICAgICAgICAgID0gIm9jIiBFUVVBTCBvYy12YWx1ZQ0KDQoNClRoZSBmb2xsb3dp bmcgY2FuIGhhcHBlbjoNCg0KMS4gICAgICAgSWYgYW4gZW50aXR5IHRoYXQgc3VwcG9ydHMgZHJh ZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtY29udHJvbCAgcmVjZWl2ZXMg4oCcb2M9TmFO4oCdIGl0IHdp bGwgcmVqZWN0IGl0LCBhcyBpdCBleHBlY3RzIGEgbnVtZXJpYyB2YWx1ZS4NCjIuICAgICAgIElm IGFuIGVudGl0eSB0aGF0IHN1cHBvcnRzIGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLXJhdGUtY29u dHJvbCByZWNlaXZlcyDigJxvY+KAnSBpdCB3aWxsIHJlamVjdCBpdCwgYXMgaXQgZXhwZWN0cyBh biBvYy12YWx1ZS4gQnV0LCBpbiBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1jb250cm9sICB0aGUg dXNhZ2Ugb2Ygb2MtdmFsdWUgaXMgb3B0aW9uYWwuDQoNCg0KT25lIHdheSB0byBmaXggdGhpcyBj b3VsZCBiZSB0byBkZWZpbmUgb2MtdmFsdWUgYXMgYSBzZXBhcmF0ZSBWaWEgaGVhZGVyIGZpZWxk IHBhcmFtZXRlciAoc2ltaWxhciB0byBvYy12YWxpZGl0eSwgb2Mtc2VxIGV0YyksIGluc3RlYWQg b2YgYSB2YWx1ZSBvZiB0aGUgb2MgcGFyYW1ldGVyLiBCdXQsIHRoZW4geW91IHdvdWxkIGhhdmUg b2MtbnVtDQoNCkFub3RoZXIgd2F5IGlzIHRvIGNoYW5nZSB0aGUgc3ludGF4IGluIGRyYWZ0LWll dGYtc29jLW92ZXJsb2FkLWNvbnRyb2wgLCBpbiBvcmRlciB0byBhbGxvdyB3aGF0IHlvdSB3YW50 IHRvIGRvIGluIGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLXJhdGUtY29udHJvbC4NCg0KUmVnYXJk cywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KTMOkaGV0dMOkasOkOiBKYW5ldCBQIEd1bm4gW21haWx0 bzpqZ3VubjZAY3NjLmNvbV0NCkzDpGhldGV0dHk6IDI3LiBrZXPDpGt1dXRhIDIwMTMgMjI6MDQN ClZhc3RhYW5vdHRhamE6IENocmlzdGVyIEhvbG1iZXJnDQpLb3BpbzogZHJhZnQtaWV0Zi1zb2Mt b3ZlcmxvYWQtcmF0ZS1jb250cm9sLmFsbEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0 Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLmFsbEB0b29scy5pZXRmLm9yZz47IHNpcC1vdmVy bG9hZEBpZXRmLm9yZzxtYWlsdG86c2lwLW92ZXJsb2FkQGlldGYub3JnPjsgc2lwLW92ZXJsb2Fk LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPg0K QWloZTogUmU6IFZTOiBbc2lwLW92ZXJsb2FkXSBXR0xDOiBkcmFmdC1pZXRmLXNvYy1vdmVybG9h ZC1yYXRlLWNvbnRyb2wgLSBDaHJpc3RlcidzIGNvbW1lbnRzDQoNCkNocmlzdGVyDQoNCmRyYWZ0 LWlldGYtc29jLW92ZXJsb2FkLWNvbnRyb2wgIHNheXMNCiIgOC4gIFN5bnRheA0KDQogIFRoaXMg c3BlY2lmaWNhdGlvbiBleHRlbmRzIHRoZSBleGlzdGluZyBkZWZpbml0aW9uIG9mIHRoZSBWaWEg aGVhZGVyDQogIGZpZWxkIHBhcmFtZXRlcnMgb2YgW1JGQzMyNjFdIGFzIGZvbGxvd3M6DQoNCiAg ICAgIHZpYS1wYXJhbXMgID0gIHZpYS10dGwgLyB2aWEtbWFkZHINCiAgICAgICAgICAgICAgICAg ICAgIC8gdmlhLXJlY2VpdmVkIC8gdmlhLWJyYW5jaA0KICAgICAgICAgICAgICAgICAgICAgLyBv YyAvIG9jLXZhbGlkaXR5DQogICAgICAgICAgICAgICAgICAgICAvIG9jLXNlcSAvIG9jLWFsZ28g LyB2aWEtZXh0ZW5zaW9uDQoNCg0KICAgICAgb2MgICAgICAgICAgPSAib2MiIFtFUVVBTCBvYy1u dW1dDQogICAgICBvYy1udW0gICAgICA9IDEqRElHSVQNCiAgICAgIG9jLXZhbGlkaXR5ID0gIm9j LXZhbGlkaXR5IiBbRVFVQUwgZGVsdGEtbXNdDQogICAgICBvYy1zZXEgICAgICA9ICJvYy1zZXEi IEVRVUFMIDEqMTJESUdJVCAiLiIgMSo1RElHSVQNCiAgICAgIG9jLWFsZ28gICAgID0gIm9jLWFs Z28iIEVRVUFMIERRVU9URSBhbGdvLWxpc3QgKihDT01NQSBhbGdvLWxpc3QpDQogICAgICAgICAg ICAgICAgICAgIERRVU9URQ0KICAgICAgYWxnby1saXN0ICAgPSAibG9zcyIgLyAqKG90aGVyLWFs Z28pDQogICAgICBvdGhlci1hbGdvICA9ICV4NDEtNUEgLyAleDYxLTdBIC8gJXgzMC0zOQ0KICAg ICAgZGVsdGEtbXMgICAgPSAxKkRJR0lUIg0KYW5kDQoiMTEuICBJQU5BIENvbnNpZGVyYXRpb25z DQoNCiAgVGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgZm91ciBuZXcgVmlhIGhlYWRlciBwYXJh bWV0ZXJzIGFzIGRldGFpbGVkDQogIGJlbG93IGluIHRoZSAiSGVhZGVyIEZpZWxkIFBhcmFtZXRl ciBhbmQgUGFyYW1ldGVyIFZhbHVlcyIgc3ViLQ0KICByZWdpc3RyeSBhcyBwZXIgdGhlIHJlZ2lz dHJ5IGNyZWF0ZWQgYnkgW1JGQzM5NjhdLiAgVGhlIHJlcXVpcmVkDQogIGluZm9ybWF0aW9uIGlz Og0KDQogICAgICBIZWFkZXIgRmllbGQgIFBhcmFtZXRlciBOYW1lICBQcmVkZWZpbmVkIFZhbHVl cyAgUmVmZXJlbmNlDQogICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQogICAgICBWaWEgICAgICAgICAgIG9jICAgICAgICAgICAg ICAgICBZZXMgICAgICAgICAgICAgUkZDWFhYWA0KICAgICAgVmlhICAgICAgICAgICBvYy12YWxp ZGl0eSAgICAgICAgWWVzICAgICAgICAgICAgIFJGQ1hYWFgNCiAgICAgIFZpYSAgICAgICAgICAg b2Mtc2VxICAgICAgICAgICAgIFllcyAgICAgICAgICAgICBSRkNYWFhYDQogICAgICBWaWEgICAg ICAgICAgIG9jLWFsZ28gICAgICAgICAgICBZZXMgICAgICAgICAgICAgUkZDWFhYWA0KDQogICAg ICBSRkMgWFhYWCBbTk9URSBUTyBSRkMtRURJVE9SOiBQbGVhc2UgcmVwbGFjZSB3aXRoIGZpbmFs IFJGQw0KICAgICAgbnVtYmVyIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi5dIg0KDQpUaGUgdGV4dCBv ZiBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1jb250cm9sIHJlZmVycyB0byBib3RoICJsb3NzIiBh bmQgInJhdGUiICBhcyB2YWx1ZXMgZm9yICBvYy1hbGdvLg0KDQpUaGUgdGV4dCBvZiBkcmFmdC1p ZXRmLXNvYy1vdmVybG9hZC1jb250cm9sICBzZWN0aW9uIDUuMyByZWZlcnMgdG8gdGhlIHVzZSBv ZiBvYyBmb3IgZWl0aGVyIHJhdGUgb3IgbG9zcw0KDQoiQXMgYW4gZXhhbXBsZSwgYSB2YWx1ZSBv ZiAib2M9MTAiIHdoZW4gdGhlIGxvc3MtYmFzZWQgYWxnb3JpdGhtIGlzDQogIHVzZWQgaW1wbGll cyB0aGF0IDEwJSBvZiB0aGUgdG90YWwgbnVtYmVyIG9mIFNJUCByZXF1ZXN0cyAoZGlhbG9nDQog IGZvcm1pbmcgYXMgd2VsbCBhcyBpbi1kaWFsb2d1ZSkgYXJlIHN1YmplY3QgdG8gcmVkdWN0aW9u IGF0IHRoZQ0KICBjbGllbnQuICBBbmFsb2dvdXNseSwgYSB2YWx1ZSBvZiAib2M9MTAiIHdoZW4g dGhlIHJhdGUtYmFzZWQNCiAgYWxnb3JpdGhtIFtJLUQuaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1j b250cm9sXSBpcyB1c2VkIGluZGljYXRlcyB0aGF0DQogIHRoZSBjbGllbnQgc2hvdWxkIHNlbmQg U0lQIHJlcXVlc3RzIGF0IGEgcmF0ZSBvZiAxMCBTSVAgcmVxdWVzdHMgb3INCiAgZmV3ZXIgcGVy IHNlY29uZC4iDQoNCldoYXQgYXJlIHlvdSBzdWdnZXN0aW5nIHdvdWxkIGdvIGluIHRoZSAiSUFO QSBDb25zaWRlcmF0aW9ucyIgc2VjdGlvbiBvZiAgZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0 ZS1jb250cm9sID8gIERvZXMgaXQganVzdCBuZWVkIGEgcmVmZXJlbmNlIHRvIHRoZSBJQU5BIENv bnNpZGVyYXRpb25zIGluIGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLWNvbnRyb2w/DQoNCkphbmV0 DQoNCg0KDQoNCg0KDQpUaGlzIGlzIGEgUFJJVkFURSBtZXNzYWdlLiBJZiB5b3UgYXJlIG5vdCB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVsZXRlIHdpdGhvdXQgY29weWluZyBhbmQg a2luZGx5IGFkdmlzZSB1cyBieSBlLW1haWwgb2YgdGhlIG1pc3Rha2UgaW4gZGVsaXZlcnkuIE5P VEU6IFJlZ2FyZGxlc3Mgb2YgY29udGVudCwgdGhpcyBlLW1haWwgc2hhbGwgbm90IG9wZXJhdGUg dG8gYmluZCBDU0MgdG8gYW55IG9yZGVyIG9yIG90aGVyIGNvbnRyYWN0IHVubGVzcyBwdXJzdWFu dCB0byBleHBsaWNpdCB3cml0dGVuIGFncmVlbWVudCBvciBnb3Zlcm5tZW50IGluaXRpYXRpdmUg ZXhwcmVzc2x5IHBlcm1pdHRpbmcgdGhlIHVzZSBvZiBlLW1haWwgZm9yIHN1Y2ggcHVycG9zZS4N Cg0KDQoNCkZyb206ICAgICAgICBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+Pg0KVG86 ICAgICAgICBKYW5ldCBQIEd1bm4vVVNBL0NTQ0BDU0MNCkNjOiAgICAgICAgImRyYWZ0LWlldGYt c29jLW92ZXJsb2FkLXJhdGUtY29udHJvbC5hbGxAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0 LWlldGYtc29jLW92ZXJsb2FkLXJhdGUtY29udHJvbC5hbGxAdG9vbHMuaWV0Zi5vcmc+IiA8ZHJh ZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLmFsbEB0b29scy5pZXRmLm9yZzxtYWls dG86ZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLmFsbEB0b29scy5pZXRmLm9y Zz4+LCAic2lwLW92ZXJsb2FkQGlldGYub3JnPG1haWx0bzpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmc+ IiA8c2lwLW92ZXJsb2FkQGlldGYub3JnPG1haWx0bzpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmc+Piwg InNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNl c0BpZXRmLm9yZz4iIDxzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2lwLW92 ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc+Pg0KRGF0ZTogICAgICAgIDA2LzI3LzIwMTMgMTI6NTQg UE0NClN1YmplY3Q6ICAgICAgICBWUzogW3NpcC1vdmVybG9hZF0gV0dMQzogZHJhZnQtaWV0Zi1z b2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sIC0gICAgICAgIENocmlzdGVyJ3MgY29tbWVudHMNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KDQoNCg0KSGksDQoNCj5UaGUgSUFO QSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIG9mICBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1jb250 cm9sIHJlZ2lzdGVycyB0aGUgbmV3IFZpYSBoZWFkZXIgZmllbGQgcGFyYW1ldGVycy4NCj4NCj5J cyBpdCBuZWVkZWQgaGVyZSBhcyB3ZWxsPw0KDQpUaGUgZHJhZnQgKFNlY3Rpb24gNSkgZG9lcyBl eHRlbmQgdGhlIG9jIHBhcmFtZXRlciwgZG9lc27igJl0IGl0PyBJIHdvdWxkIGFzc3VtZSB0aGF0 IG5lZWRzIHRvIGdvIHRvIElBTkEuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0Kc2lwLW92 ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYu b3JnPiB3cm90ZSBvbiAwNi8yNy8yMDEzIDA2OjA1OjQxIEFNOg0KDQo+IEZyb206IENocmlzdGVy IEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+DQo+IFRvOiAic2lwLW92ZXJsb2FkQGlldGYub3JnPG1h aWx0bzpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmc+IiA8c2lwLW92ZXJsb2FkQGlldGYub3JnPG1haWx0 bzpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmc+Pg0KPiBDYzogImRyYWZ0LWlldGYtc29jLW92ZXJsb2Fk LXJhdGUtY29udHJvbC5hbGxAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtc29jLW92 ZXJsb2FkLXJhdGUtY29udHJvbC5hbGxAdG9vbHMuaWV0Zi5vcmc+Ig0KPiA8ZHJhZnQtaWV0Zi1z b2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLmFsbEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQt aWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLmFsbEB0b29scy5pZXRmLm9yZz4+DQo+IERh dGU6IDA2LzI3LzIwMTMgMDY6MDUgQU0NCj4gU3ViamVjdDogW3NpcC1vdmVybG9hZF0gV0dMQzog ZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sIC0NCj4gQ2hyaXN0ZXIncyBjb21t ZW50cw0KPiBTZW50IGJ5OiBzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2lw LW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc+DQo+DQo+IEhpLA0KPg0KPiBJIGhhdmUgcmVhZCBk cmFmdC1pZXRmLXNvYy1vdmVybG9hZC1yYXRlLWNvbnRyb2wtMDQudHh0IGFzIHBhcnQgb2YgdGhl IFdHTEMuDQo+DQouLi4NCj4gUTc6IEluIFNlY3Rpb24gNyB5b3Ugc2F5IHRoYXQgdGhlcmUgYXJl IG5vIElBTkEgY29uc2lkZXJhdGlvbnMuIEJ1dCwNCj4gZG9u4oCZdCB5b3UgbmVlZCB0byByZXF1 ZXN0IElBTkEgdG8gcmVnaXN0ZXIgdGhlIG5ldyBWaWEgaGVhZGVyIGZpZWxkDQo+IHBhcmFtZXRl cnM/DQo+DQo+IFJlZ2FyZHMsDQo+DQo+IENocmlzdGVyDQo+DQo+DQo+DQo+DQo+ICBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzaXAtb3ZlcmxvYWQg bWFpbGluZyBsaXN0DQo+IHNpcC1vdmVybG9hZEBpZXRmLm9yZzxtYWlsdG86c2lwLW92ZXJsb2Fk QGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcC1v dmVybG9hZA0K --_000_5EBD159DE88147488A3B1590E09001840353BDA4CABEnjfpsrvexg2_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEgNiA0 IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGku TXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVt YWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2 bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+SmFuZXQsIENocmlzdGVyLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ VGhhbmsgeW91IGZvciB5b3VyIGNvbW1lbnRzIGFuZCBkaXNjdXNzaW9uLiA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPkFjdHVhbGx5IHdlIGRpZCBub3QgZGVmaW5lIGFueSBvcGVyYXRpb24gZm9yIG9jIMKg PSAmcXVvdDtOYU4mcXVvdDsuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SW4gc2VjdGlvbiA1LjAsIEkg cHJvcG9zZSB0aGUgZm9sbG93aW5nIGNoYW5nZSAod2hhdCBpcyB1c2VkIGluIGRyYWZ0LWlldGYt c29jLW92ZXJsb2FkLWNvbnRyb2wtMTIpOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+UmVwbGFjZSBvYy12 YWx1ZSA9ICZxdW90O05hTiZxdW90OyAvIG9jLW51bSDCoMKgYnkgwqDCoG9jID0gJnF1b3Q7b2Mm cXVvdDsgW0VRVUFMIG9jLW51bV08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlBsZWFzZSBjb25maXJtIHRo aXMgY2hhbmdlIHdvdWxkIGFkZHJlc3MgdGhlIGlzc3VlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhh bmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5z LXNlcmlmIjtjb2xvcjojRjQ3QjIwJz5FcmljIE5vZWw8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOiM2NjY2 NjYnPiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjtj b2xvcjojNjY2NjY2Jz5BVCZhbXA7VCBMYWJzLCBJbmMuPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzY2NjY2Nic+IDxicj48L3NwYW4+PGk+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOiMwMEIwRTAnPlJldGhpbmsgUG9z c2libGU8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48aT48c3Bh biBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzAwQjBFMCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiVmVy ZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOiM2NjY2NjYnPk5ldHdvcmsgRGVzaWduIGFuZCBQZXJm b3JtYW5jZSBBbmFseXNpczxicj4yMDAgU291dGggTGF1cmVsIEF2ZW51ZSwgRDUtM0QxOTxicj5N aWRkbGV0b3duLCBOSiAwNzc0ODxicj5QOiA3MzIuNDIwLjQxNzQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PGEgaHJlZj0ibWFp bHRvOmpzbWl0aEBhdHQuY29tIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiInPmVjbm9lbEBhdHQuY29tPC9zcGFuPjwvYT48L3Nw YW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiIn PiBzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnNpcC1vdmVybG9hZC1ib3Vu Y2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPkphbmV0IFAgR3Vubjxicj48Yj5TZW50 OjwvYj4gRnJpZGF5LCBKdW5lIDI4LCAyMDEzIDExOjE2IEFNPGJyPjxiPlRvOjwvYj4gQ2hyaXN0 ZXIgSG9sbWJlcmc8YnI+PGI+Q2M6PC9iPiBzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzsg ZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLmFsbEB0b29scy5pZXRmLm9yZzsg c2lwLW92ZXJsb2FkQGlldGYub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBbc2lwLW92ZXJsb2FkXSBO YU4/IFJFOiBXR0xDOiBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1yYXRlLWNvbnRyb2wgLSBDaHJp c3RlcidzIGNvbW1lbnRzPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPlRoYW5rcyBDaHJp c3Rlciw8L3NwYW4+IDxicj48YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPlN5bnRheCBpcyBkZWZpbml0ZWx5IE5PVCBteSBh cmVhIG9mIGV4cGVydGlzZSwgc28gSSB3aWxsIGxldCB0aGUgYXV0aG9ycyBmb2xsb3cgdXAuPC9z cGFuPiA8YnI+PGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiJz5FcmljIGFuZCBQaGlsaXAsPC9zcGFuPiA8YnI+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPldo YXQgaXMgc3VwcG9zZWQgdG8gaGFwcGVuIHdoZW4gb2MgPSAmcXVvdDtOYU4mcXVvdDs/ICZuYnNw O0kgZG8gbm90IHNlZSBhbnkgcmVmZXJlbmNlIHRvIGl0IGluIHRoZSByZXN0IG9mIHRoZSBkb2N1 bWVudC4gJm5ic3A7SXMgaXQgZXZlbiBuZWVkZWQ/PC9zcGFuPiA8YnI+PGJyPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5KYW5l dDxicj48YnI+VGhpcyBpcyBhIFBSSVZBVEUgbWVzc2FnZS4gSWYgeW91IGFyZSBub3QgdGhlIGlu dGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB3aXRob3V0IGNvcHlpbmcgYW5kIGtpbmRs eSBhZHZpc2UgdXMgYnkgZS1tYWlsIG9mIHRoZSBtaXN0YWtlIGluIGRlbGl2ZXJ5LiBOT1RFOiBS ZWdhcmRsZXNzIG9mIGNvbnRlbnQsIHRoaXMgZS1tYWlsIHNoYWxsIG5vdCBvcGVyYXRlIHRvIGJp bmQgQ1NDIHRvIGFueSBvcmRlciBvciBvdGhlciBjb250cmFjdCB1bmxlc3MgcHVyc3VhbnQgdG8g ZXhwbGljaXQgd3JpdHRlbiBhZ3JlZW1lbnQgb3IgZ292ZXJubWVudCBpbml0aWF0aXZlIGV4cHJl c3NseSBwZXJtaXR0aW5nIHRoZSB1c2Ugb2YgZS1tYWlsIGZvciBzdWNoIHB1cnBvc2UuPC9zcGFu PiA8YnI+PGJyPjxicj48YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWls eToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojNUY1RjVGJz5Gcm9tOiAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Q2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9 Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iPmNocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbTwvYT4mZ3Q7PC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3 LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojNUY1RjVGJz5Ubzog Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPkNocmlzdGVyIEhvbG1iZXJn ICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIj5jaHJp c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OywgSmFuZXQgUCBHdW5uL1VTQS9DU0NA Q1NDPC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojNUY1RjVGJz5DYzogJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6 IkFyaWFsIiwic2Fucy1zZXJpZiInPiZxdW90OzxhIGhyZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWQt Ym91bmNlc0BpZXRmLm9yZyI+c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+JnF1b3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmciPnNpcC1v dmVybG9hZC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpk cmFmdC1pZXRmLXNvYy1vdmVybG9hZC1yYXRlLWNvbnRyb2wuYWxsQHRvb2xzLmlldGYub3JnIj5k cmFmdC1pZXRmLXNvYy1vdmVybG9hZC1yYXRlLWNvbnRyb2wuYWxsQHRvb2xzLmlldGYub3JnPC9h PiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLXJhdGUt Y29udHJvbC5hbGxAdG9vbHMuaWV0Zi5vcmciPmRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLXJhdGUt Y29udHJvbC5hbGxAdG9vbHMuaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRv OnNpcC1vdmVybG9hZEBpZXRmLm9yZyI+c2lwLW92ZXJsb2FkQGlldGYub3JnPC9hPiZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZEBpZXRmLm9yZyI+c2lwLW92ZXJsb2FkQGll dGYub3JnPC9hPiZndDs8L3NwYW4+IDxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2Zv bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiM1RjVGNUYnPkRhdGU6ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0 O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4wNi8yOC8yMDEzIDAzOjI1IEFNPC9z cGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIjtjb2xvcjojNUY1RjVGJz5TdWJqZWN0OiAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIic+UkU6IFtzaXAtb3ZlcmxvYWRdIFdHTEM6IGRyYWZ0LWlldGYt c29jLW92ZXJsb2FkLXJhdGUtY29udHJvbCAtIENocmlzdGVyJ3MgY29tbWVudHM8L3NwYW4+IDxv OnA+PC9vOnA+PC9wPjxkaXYgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4 dC1hbGlnbjpjZW50ZXInPjxociBzaXplPTIgd2lkdGg9IjEwMCUiIG5vc2hhZGUgc3R5bGU9J2Nv bG9yOiNBQ0E4OTknIGFsaWduPWNlbnRlcj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPjxi cj48YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Iic+VGhlIGZvbGxvd2luZyBpcyBvYnZpb3VzbHkgbm90IG5lZWRlZCBpbiBkcmFmdC1pZXRm LXNvYy1vdmVybG9hZC1jb250cm9sOjwvc3Bhbj4gPGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOzwvc3Bhbj4gPGJyPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZxdW90 O0VRVUFMJnF1b3Q7IGlzIGRlZmluZWQgaW4gUkZDIDMyNjEuICZuYnNwOyZxdW90O0RJR0lUJnF1 b3Q7IGlzIGRlZmluZWQgaW4gUkZDIDUyMzQuPC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMDA0 MDgwJz4mbmJzcDs8L3NwYW4+IDxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMwMDQwODAnPiZuYnNwOzwvc3Bh bj4gPGJyPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IDxhIGhyZWY9Im1haWx0 bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZyI+c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0 Zi5vcmc8L2E+IFs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGll dGYub3JnIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiInPm1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzwvc3Bh bj48L2E+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiJz5dIDxiPk9uIEJlaGFsZiBPZiA8L2I+Q2hyaXN0ZXIgSG9sbWJlcmc8Yj48 YnI+U2VudDo8L2I+IDI4LiBrZXPDpGt1dXRhIDIwMTMgOToyNzxiPjxicj5Ubzo8L2I+IEphbmV0 IFAgR3VubjxiPjxicj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNl c0BpZXRmLm9yZyI+c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJt YWlsdG86ZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLmFsbEB0b29scy5pZXRm Lm9yZyI+ZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLmFsbEB0b29scy5pZXRm Lm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmciPnNpcC1vdmVy bG9hZEBpZXRmLm9yZzwvYT48Yj48YnI+U3ViamVjdDo8L2I+IFJlOiBbc2lwLW92ZXJsb2FkXSBX R0xDOiBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1yYXRlLWNvbnRyb2wgLSBDaHJpc3RlcidzIGNv bW1lbnRzPC9zcGFuPiA8YnI+Jm5ic3A7IDxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMwMDQwODAnPkhpLDwv c3Bhbj4gPGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwNDA4MCc+Jm5ic3A7PC9zcGFuPiA8YnI+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMDA0MDgwJz5Tbywgd2l0aCB0aGUgdGhpcmQgYWx0ZXJuYXRpdmUsIFNlY3Rpb24g NSB3b3VsZCBsb29rIHNvbWV0aGluZyBsaWtlOjwvc3Bhbj4gPGJyPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzAw NDA4MCc+Jm5ic3A7PC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+NS4gJm5ic3A7U3ludGF4PC9zcGFuPiA8YnI+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7 PC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Iic+Jm5ic3A7ICZuYnNwO1RoaXMgc3BlY2lmaWNhdGlvbiBleHRlbmRzIHRoZSBl eGlzdGluZyBkZWZpbml0aW9uIG9mIHRoZSBWaWEgaGVhZGVyPC9zcGFuPiA8YnI+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7ICZu YnNwO2ZpZWxkIHBhcmFtZXRlcnMgb2YgW1JGQzMyNjFdIGFzIGZvbGxvd3M6PC9zcGFuPiA8YnI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+ Jm5ic3A7PC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHZpYS1wYXJhbXMg PS8gb2MtbmFuPC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7b2MtbmFuICZu YnNwOyAmbmJzcDsgJm5ic3A7PSAmcXVvdDtOYU4mcXVvdDs8L3NwYW4+IDxicj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDs8L3Nw YW4+IDxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMwMDQwODAnPiZuYnNwOzwvc3Bhbj4gPGJyPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzAwNDA4MCc+QlRXLCBJIHRoaW5rIHRoZSBzeW50YXggaW4gPGI+ZHJhZnQtaWV0Zi1z b2Mtb3ZlcmxvYWQtY29udHJvbCA8L2I+c2hvdWxkIGxvb2sgbGlrZTo8L3NwYW4+IDxicj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMwMDQwODAnPiZuYnNwOzwvc3Bhbj4gPGJyPjxiPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyB2aWEtcGFyYW1zICZuYnNwOz0vIG9jIC8gb2MtdmFsaWRpdHkgLyBvYy1zZXEg LyBvYy1hbGdvPC9zcGFuPjwvYj4gPGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOzwvc3Bhbj4gPGJyPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO29jICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs9ICZxdW90 O29jJnF1b3Q7IFtFUVVBTCBvYy1udW1dPC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7b2MtbnVtICZuYnNwOyAmbmJzcDsgJm5ic3A7PSAxKkRJR0lUPC9zcGFuPiA8YnI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7b2MtdmFsaWRpdHkgPSAmcXVvdDtvYy12YWxpZGl0eSZx dW90OyBbRVFVQUwgZGVsdGEtbXNdPC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7b2Mtc2VxICZuYnNwOyAmbmJzcDsgJm5ic3A7PSAmcXVvdDtvYy1zZXEmcXVvdDsgRVFVQUwg MSoxMkRJR0lUICZxdW90Oy4mcXVvdDsgMSo1RElHSVQ8L3NwYW4+IDxicj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtvYy1hbGdvICZuYnNwOyAmbmJzcDsgPSAmcXVvdDtvYy1hbGdvJnF1b3Q7 IEVRVUFMIERRVU9URSBhbGdvLWxpc3QgKihDT01NQSBhbGdvLWxpc3QpPC9zcGFuPiA8YnI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO0RRVU9URTwvc3Bhbj4gPGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO2FsZ28tbGlzdCAmbmJzcDsgPSAmcXVvdDtsb3NzJnF1b3Q7IC8gKihvdGhlci1hbGdvKTwv c3Bhbj4gPGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyInPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO290aGVyLWFsZ28gJm5ic3A7PSAl eDQxLTVBIC8gJXg2MS03QSAvICV4MzAtMzk8L3NwYW4+IDxicj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtkZWx0YS1tcyAmbmJzcDsgJm5ic3A7PSAxKkRJR0lUPC9zcGFuPiA8YnI+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMDA0MDgwJz4mbmJzcDs8L3NwYW4+IDxicj48Yj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMwMDQw ODAnPiZuYnNwOzwvc3Bhbj48L2I+IDxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMwMDQwODAnPkluIGJvdGgg ZHJhZnRzLCBJIHdvdWxkIGFsc28gc3VnZ2VzdCB0byByZXdyaXRlIHRoZSBTeW50YXggc2VjdGlv bnMgaW4gdGhlIGZvbGxvd2luZyB3YXk6PC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMDA0MDgw Jz4mbmJzcDs8L3NwYW4+IDxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQ291cmllciBOZXciJz41LiAmbmJzcDtHcmFtbWFyPC9zcGFuPiA8YnI+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7PC9z cGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Iic+NS4xLiAmbmJzcDtHZW5lcmFsPC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7PC9zcGFuPiA8YnI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+ Jm5ic3A7ICZuYnNwO1RoaXMgc2VjdGlvbiBleHRlbmRzIHRoZSBBQk5GIGRlZmluaXRpb24gb2Yg dmlhLXBhcmFtcyBmcm9tIFtSRkMzMjYxXTwvc3Bhbj4gPGJyPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyAmbmJzcDtieSBhZGRp bmcgYSBuZXcgVmlhIGhlYWRlciBmaWVsZCBwYXJhbWV0ZXIsICZxdW90O29jLW5hbiZxdW90Oy4g Jm5ic3A7VGhlIEFCTkYgZGVmaW5lZDwvc3Bhbj4gPGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyAmbmJzcDtpbiB0aGlzIHNw ZWNpZmljYXRpb24gaXMgY29uZm9ybWFudCB0byBSRkMgNTIzNCBbUkZDNTIzNF0uICZuYnNwOyZx dW90O0VRVUFMJnF1b3Q7PC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7ICZuYnNwO2lzIGRlZmluZWQgaW4gUkZD IDMyNjEuICZuYnNwOyZxdW90O0RJR0lUJnF1b3Q7IGlzIGRlZmluZWQgaW4gUkZDIDUyMzQuPC9z cGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Iic+Jm5ic3A7PC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+NS4yLiAmbmJzcDtBQk5GPC9zcGFuPiA8YnI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5i c3A7PC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Iic+Jm5ic3A7ICZuYnNwO3ZpYS1wYXJhbXMgPS8gb2MtbmFuPC9zcGFuPiA8 YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Iic+Jm5ic3A7ICZuYnNwO29jLW5hbiAmbmJzcDsgJm5ic3A7ICZuYnNwOz0gJnF1b3Q7TmFOJnF1 b3Q7PC9zcGFuPiA8YnI+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMDA0MDgwJz4mbmJzcDs8L3NwYW4+PC9i PiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMDA0MDgwJz5SZWdhcmRzLDwvc3Bhbj4gPGJyPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzAwNDA4MCc+Jm5ic3A7PC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMDA0MDgwJz5D aHJpc3Rlcjwvc3Bhbj4gPGJyPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwNDA4MCc+Jm5ic3A7PC9zcGFu PjwvYj4gPGJyPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwNDA4MCc+Jm5ic3A7PC9zcGFuPjwvYj4gPGJy PjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzAwNDA4MCc+Jm5ic3A7PC9zcGFuPjwvYj4gPGJyPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzAwNDA4MCc+Jm5ic3A7PC9zcGFuPiA8YnI+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiJz4gQ2hyaXN0ZXIgSG9sbWJlcmcgPGI+PGJyPlNlbnQ6PC9iPiAyOC4ga2Vzw6Rr dXV0YSAyMDEzIDg6NDA8Yj48YnI+VG86PC9iPiBDaHJpc3RlciBIb2xtYmVyZzsgSmFuZXQgUCBH dW5uPGI+PGJyPkNjOjwvYj4gPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWQtYm91 bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5zaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzwvc3Bh bj48L2E+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiJz47IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1zb2Mtb3Zl cmxvYWQtcmF0ZS1jb250cm9sLmFsbEB0b29scy5pZXRmLm9yZyI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5kcmFmdC1pZXRm LXNvYy1vdmVybG9hZC1yYXRlLWNvbnRyb2wuYWxsQHRvb2xzLmlldGYub3JnPC9zcGFuPjwvYT48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiInPjsgPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmciPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIic+c2lwLW92ZXJsb2FkQGlldGYub3JnPC9zcGFuPjwvYT48Yj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPjxicj5TdWJq ZWN0Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gVlM6IFtzaXAtb3ZlcmxvYWRdIFdHTEM6IGRyYWZ0LWll dGYtc29jLW92ZXJsb2FkLXJhdGUtY29udHJvbCAtIENocmlzdGVyJ3MgY29tbWVudHM8L3NwYW4+ IDxicj4mbmJzcDsgPGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwNDA4MCc+SGksPC9zcGFuPiA8YnI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMDA0MDgwJz4mbmJzcDs8L3NwYW4+IDxicj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMwMDQw ODAnPkEgPGI+dGhpcmQgYWx0ZXJuYXRpdmU8L2I+IChwcm9iYWJseSB0aGUgZWFzaWVzdCBvbmUs IGF0IGxlYXN0IGZyb20gYSBzeW50YXggcGVyc3BlY3RpdmUpIHdvdWxkIGJlIHRvIHNpbXBseSBk ZWZpbmUgYSBuZXcg4oCcb2MtbmFu4oCdIFZpYSBoZWFkZXIgZmllbGQgcGFyYW1ldGVyLjwvc3Bh bj4gPGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwNDA4MCc+Jm5ic3A7PC9zcGFuPiA8YnI+PGI+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMDA0MDgwJz5vYy1uYW4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Oz0gJnF1b3Q7bmFuJnF1b3Q7PC9zcGFuPjwvYj4gPGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwNDA4MCc+ Jm5ic3A7PC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMDA0MDgwJz7igKZvciBzb21ldGhpbmcg bGlrZSB0aGF0Ljwvc3Bhbj4gPGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwNDA4MCc+Jm5ic3A7PC9zcGFu PiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMDA0MDgwJz5JdCB3b3VsZCA8Yj5ub3Q8L2I+IHJlcXVpcmUg YW55IGNoYW5nZXMgdG8gZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtY29udHJvbCAuPC9zcGFuPiA8 YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMDA0MDgwJz4mbmJzcDs8L3NwYW4+IDxicj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMwMDQwODAnPihUaGVuLCBpbiB0aGUgPGI+cHJvY2VkdXJlIHNlY3Rpb25zPC9iPiB5b3UgbmVl ZCB0byBkZXNjcmliZSBob3cvd2hldGhlciB0aGUgb2MgYW5kIG9jLW5hbiBwYXJhbWV0ZXJzIGNh biBiZSB1c2VkIGF0IHRoZSBzYW1lIHRpbWUgZXRjLCBidXQgdGhhdCBpcyBub3QgYSBzeW50YXgg cXVlc3Rpb24uKTwvc3Bhbj4gPGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwNDA4MCc+Jm5ic3A7PC9zcGFu PiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMDA0MDgwJz5SZWdhcmRzLDwvc3Bhbj4gPGJyPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzAwNDA4MCc+Jm5ic3A7PC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMDA0MDgwJz5D aHJpc3Rlcjwvc3Bhbj4gPGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwNDA4MCc+Jm5ic3A7PC9zcGFuPiA8 YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMDA0MDgwJz4mbmJzcDs8L3NwYW4+IDxicj48Yj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkzD pGhldHTDpGrDpDo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86c2lw LW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+c2lwLW92ZXJsb2FkLWJvdW5jZXNA aWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IFs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnNpcC1v dmVybG9hZC1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPm1haWx0bzpzaXAtb3ZlcmxvYWQtYm91 bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5dIDxiPlB1b2xlc3RhIDwvYj5DaHJpc3Rl ciBIb2xtYmVyZzxiPjxicj5Mw6RoZXRldHR5OjwvYj4gMjcuIGtlc8Oka3V1dGEgMjAxMyAyMjo0 MjxiPjxicj5WYXN0YWFub3R0YWphOjwvYj4gSmFuZXQgUCBHdW5uPGI+PGJyPktvcGlvOjwvYj4g PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZyI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiJz5zaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz47IDwv c3Bhbj48YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9s LmFsbEB0b29scy5pZXRmLm9yZyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5kcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1yYXRl LWNvbnRyb2wuYWxsQHRvb2xzLmlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPjsgPC9zcGFuPjxh IGhyZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+c2lwLW92ZXJsb2Fk QGlldGYub3JnPC9zcGFuPjwvYT48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPjxicj5BaWhlOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi Jz4gUmU6IFtzaXAtb3ZlcmxvYWRdIFdHTEM6IGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLXJhdGUt Y29udHJvbCAtIENocmlzdGVyJ3MgY29tbWVudHM8L3NwYW4+IDxicj4mbmJzcDsgPGJyPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzAwNDA4MCc+SGksPC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMDA0MDgwJz4m bmJzcDs8L3NwYW4+IDxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMwMDQwODAnPldoZW4gdGFraW5nIGEgY2xv c2VyIGxvb2ssIEkgYWN0dWFsbHkgdGhpbmsgdGhlcmUgaXMgc29tZXRoaW5nIHRlY2huaWNhbGx5 IHdyb25nIHdpdGggdGhlIHN5bnRheCBpbiBTZWN0aW9uIDUgb2YgZHJhZnQtaWV0Zi1zb2Mtb3Zl cmxvYWQtcmF0ZS1jb250cm9sLjwvc3Bhbj4gPGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwNDA4MCc+Jm5i c3A7PC9zcGFuPiA8YnI+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMDA0MDgwJz5kcmFmdC1pZXRmLXNvYy1v dmVybG9hZC1jb250cm9sIDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMDA0MDgwJz4mbmJzcDtk ZWZpbmVzIHRoZSBvYyBwYXJhbWV0ZXIgYXM6PC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMDA0 MDgwJz4mbmJzcDs8L3NwYW4+IDxicj48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMwMDQwODAnPm9jICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs9ICZxdW90O29jJnF1b3Q7IFtFUVVBTCBvYy1u dW1dPC9zcGFuPjwvYj4gPGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwNDA4MCc+Jm5ic3A7PC9zcGFuPiA8 YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMDA0MDgwJz4mbmJzcDs8L3NwYW4+IDxicj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMwMDQwODAnPk5vdywgaXQgc2VlbXMgbGlrZSA8Yj5kcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1y YXRlLWNvbnRyb2w8L2I+IGFjdHVhbGx5IDxiPnJlLWRlZmluZXMgPC9iPnRoZSA8Yj5zYW1lIHBh cmFtZXRlcjwvYj4uIEluIGFkZGl0aW9uLCBpdOKAmXMgZG9uZSBpbiBhIGJhY2t3YXJkIGNvbXBh dGlibGUgbWFubmVyLCBlLmcuIGJlY2F1c2UgdGhlIHBhcmFtZXRlciBjYW4gbm93IGNvbnRhaW4g YSBub24tbnVtZXJpYyB2YWx1ZSAoc2VlIHRoZSBidWxsZXQgbGlzdCBiZWxvdyB3aGF0IGNhbiBn byB3cm9uZyk6PC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMDA0MDgwJz4mbmJzcDs8L3NwYW4+ IDxicj48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMwMDQwODAnPm9jICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDs9ICZxdW90O29jJnF1b3Q7IEVRVUFMIG9jLXZhbHVlPC9zcGFuPjwvYj4gPGJy PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzAwNDA4MCc+Jm5ic3A7PC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MDA0MDgwJz4mbmJzcDs8L3NwYW4+IDxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMwMDQwODAnPlRoZSBmb2xs b3dpbmcgY2FuIGhhcHBlbjo8L3NwYW4+IDxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMwMDQwODAnPiZuYnNw Ozwvc3Bhbj4gPGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwNDA4MCc+MS4gJm5ic3A7ICZuYnNwOyAmbmJz cDsgSWYgYW4gZW50aXR5IHRoYXQgc3VwcG9ydHMgZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtY29u dHJvbCAmbmJzcDtyZWNlaXZlcyA8Yj7igJxvYz1OYU7igJ08L2I+IGl0IHdpbGwgPGI+cmVqZWN0 PC9iPiBpdCwgYXMgaXQgZXhwZWN0cyBhIG51bWVyaWMgdmFsdWUuPC9zcGFuPiA8YnI+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMDA0MDgwJz4yLiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJZiBhbiBlbnRpdHkgdGhh dCBzdXBwb3J0cyBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1yYXRlLWNvbnRyb2wgcmVjZWl2ZXMg PGI+4oCcb2PigJ08L2I+IGl0IHdpbGwgPGI+cmVqZWN0PC9iPiBpdCwgYXMgaXQgZXhwZWN0cyBh biBvYy12YWx1ZS4gQnV0LCBpbiBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1jb250cm9sICZuYnNw O3RoZSB1c2FnZSBvZiBvYy12YWx1ZSBpcyBvcHRpb25hbC48L3NwYW4+IDxicj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMwMDQwODAnPiZuYnNwOzwvc3Bhbj4gPGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwNDA4MCc+Jm5i c3A7PC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMDA0MDgwJz5PbmUgd2F5IHRvIGZpeCB0aGlz IGNvdWxkIGJlIHRvIGRlZmluZSBvYy12YWx1ZSBhcyBhIHNlcGFyYXRlIFZpYSBoZWFkZXIgZmll bGQgcGFyYW1ldGVyIChzaW1pbGFyIHRvIG9jLXZhbGlkaXR5LCBvYy1zZXEgZXRjKSwgaW5zdGVh ZCBvZiBhIHZhbHVlIG9mIHRoZSBvYyBwYXJhbWV0ZXIuIEJ1dCwgdGhlbiB5b3Ugd291bGQgaGF2 ZSBvYy1udW08L3NwYW4+IDxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMwMDQwODAnPiZuYnNwOzwvc3Bhbj4g PGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzAwNDA4MCc+QW5vdGhlciB3YXkgaXMgdG8gY2hhbmdlIHRoZSBz eW50YXggaW4gZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtY29udHJvbCAsIGluIG9yZGVyIHRvIGFs bG93IHdoYXQgeW91IHdhbnQgdG8gZG8gaW4gZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1j b250cm9sLjwvc3Bhbj4gPGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwNDA4MCc+Jm5ic3A7PC9zcGFuPiA8 YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMDA0MDgwJz5SZWdhcmRzLDwvc3Bhbj4gPGJyPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzAwNDA4MCc+Jm5ic3A7PC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMDA0MDgwJz5DaHJp c3Rlcjwvc3Bhbj4gPGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwNDA4MCc+Jm5ic3A7PC9zcGFuPiA8YnI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMDA0MDgwJz4mbmJzcDs8L3NwYW4+IDxicj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMw MDQwODAnPiZuYnNwOzwvc3Bhbj4gPGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwNDA4MCc+Jm5ic3A7PC9z cGFuPiA8YnI+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRh aG9tYSIsInNhbnMtc2VyaWYiJz5Mw6RoZXR0w6Rqw6Q6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBKYW5l dCBQIEd1bm4gWzwvc3Bhbj48YSBocmVmPSJtYWlsdG86amd1bm42QGNzYy5jb20iPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+ bWFpbHRvOmpndW5uNkBjc2MuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPl0gPGI+PGJyPkzDpGhldGV0 dHk6PC9iPiAyNy4ga2Vzw6RrdXV0YSAyMDEzIDIyOjA0PGI+PGJyPlZhc3RhYW5vdHRhamE6PC9i PiBDaHJpc3RlciBIb2xtYmVyZzxiPjxicj5Lb3Bpbzo8L2I+IDwvc3Bhbj48YSBocmVmPSJtYWls dG86ZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLmFsbEB0b29scy5pZXRmLm9y ZyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiJz5kcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1yYXRlLWNvbnRyb2wuYWxsQHRvb2xz LmlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPjsgPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzaXAt b3ZlcmxvYWRAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+c2lwLW92ZXJsb2FkQGlldGYub3JnPC9zcGFuPjwv YT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiInPjsgPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0Bp ZXRmLm9yZyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9t YSIsInNhbnMtc2VyaWYiJz5zaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+ PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiJz48YnI+QWloZTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IFJlOiBWUzogW3NpcC1vdmVy bG9hZF0gV0dMQzogZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sIC0gQ2hyaXN0 ZXIncyBjb21tZW50czwvc3Bhbj4gPGJyPiZuYnNwOyA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5DaHJpc3Rlcjwvc3Bhbj4gPGJyPjxzcGFuIHN0eWxl PSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+PGJyPmRyYWZ0LWlldGYtc29jLW92 ZXJsb2FkLWNvbnRyb2wgJm5ic3A7c2F5czwvc3Bhbj4gPHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5 OiJBcmlhbCIsInNhbnMtc2VyaWYiJz48YnI+JnF1b3Q7IDguICZuYnNwO1N5bnRheDwvc3Bhbj4g PGJyPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+PGJyPiZu YnNwOyBUaGlzIHNwZWNpZmljYXRpb24gZXh0ZW5kcyB0aGUgZXhpc3RpbmcgZGVmaW5pdGlvbiBv ZiB0aGUgVmlhIGhlYWRlcjwvc3Bhbj4gPHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIs InNhbnMtc2VyaWYiJz48YnI+Jm5ic3A7IGZpZWxkIHBhcmFtZXRlcnMgb2YgW1JGQzMyNjFdIGFz IGZvbGxvd3M6PC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiJz48YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgdmlhLXBhcmFtcyAmbmJzcDs9ICZu YnNwO3ZpYS10dGwgLyB2aWEtbWFkZHI8L3NwYW4+IDxzcGFuIHN0eWxlPSdmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIic+PGJyPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsvIHZpYS1yZWNlaXZl ZCAvIHZpYS1icmFuY2g8L3NwYW4+IDxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJz YW5zLXNlcmlmIic+PGJyPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsvIG9jIC8gb2MtdmFsaWRpdHk8L3Nw YW4+IDxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+PGJyPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsvIG9jLXNlcSAvIG9jLWFsZ28gLyB2aWEtZXh0ZW5zaW9uPC9zcGFu PiA8YnI+PGJyPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+ PGJyPiZuYnNwOyAmbmJzcDsgJm5ic3A7IG9jICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDs9ICZxdW90O29jJnF1b3Q7IFtFUVVBTCBvYy1udW1dPC9zcGFuPiA8c3BhbiBzdHlsZT0n Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPjxicj4mbmJzcDsgJm5ic3A7ICZuYnNw OyBvYy1udW0gJm5ic3A7ICZuYnNwOyAmbmJzcDs9IDEqRElHSVQ8L3NwYW4+IDxzcGFuIHN0eWxl PSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+PGJyPiZuYnNwOyAmbmJzcDsgJm5i c3A7IG9jLXZhbGlkaXR5ID0gJnF1b3Q7b2MtdmFsaWRpdHkmcXVvdDsgW0VRVUFMIGRlbHRhLW1z XTwvc3Bhbj4gPHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz48 YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgb2Mtc2VxICZuYnNwOyAmbmJzcDsgJm5ic3A7PSAmcXVv dDtvYy1zZXEmcXVvdDsgRVFVQUwgMSoxMkRJR0lUICZxdW90Oy4mcXVvdDsgMSo1RElHSVQ8L3Nw YW4+IDxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+PGJyPiZu YnNwOyAmbmJzcDsgJm5ic3A7IG9jLWFsZ28gJm5ic3A7ICZuYnNwOyA9ICZxdW90O29jLWFsZ28m cXVvdDsgRVFVQUwgRFFVT1RFIGFsZ28tbGlzdCAqKENPTU1BIGFsZ28tbGlzdCk8L3NwYW4+IDxz cGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+PGJyPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBEUVVPVEU8L3NwYW4+IDxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIic+PGJyPiZuYnNwOyAmbmJzcDsgJm5ic3A7IGFsZ28tbGlzdCAmbmJzcDsgPSAmcXVv dDtsb3NzJnF1b3Q7IC8gKihvdGhlci1hbGdvKTwvc3Bhbj4gPHNwYW4gc3R5bGU9J2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz48YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgb3RoZXIt YWxnbyAmbmJzcDs9ICV4NDEtNUEgLyAleDYxLTdBIC8gJXgzMC0zOTwvc3Bhbj4gPHNwYW4gc3R5 bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz48YnI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgZGVsdGEtbXMgJm5ic3A7ICZuYnNwOz0gMSpESUdJVCZxdW90Ozwvc3Bhbj4gPHNwYW4g c3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz48YnI+YW5kPC9zcGFuPiA8 c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPjxicj4mcXVvdDsx MS4gJm5ic3A7SUFOQSBDb25zaWRlcmF0aW9uczwvc3Bhbj4gPGJyPjxzcGFuIHN0eWxlPSdmb250 LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+PGJyPiZuYnNwOyBUaGlzIHNwZWNpZmljYXRp b24gZGVmaW5lcyBmb3VyIG5ldyBWaWEgaGVhZGVyIHBhcmFtZXRlcnMgYXMgZGV0YWlsZWQ8L3Nw YW4+IDxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+PGJyPiZu YnNwOyBiZWxvdyBpbiB0aGUgJnF1b3Q7SGVhZGVyIEZpZWxkIFBhcmFtZXRlciBhbmQgUGFyYW1l dGVyIFZhbHVlcyZxdW90OyBzdWItPC9zcGFuPiA8c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiInPjxicj4mbmJzcDsgcmVnaXN0cnkgYXMgcGVyIHRoZSByZWdpc3Ry eSBjcmVhdGVkIGJ5IFtSRkMzOTY4XS4gJm5ic3A7VGhlIHJlcXVpcmVkPC9zcGFuPiA8c3BhbiBz dHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPjxicj4mbmJzcDsgaW5mb3Jt YXRpb24gaXM6PC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiJz48YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgSGVhZGVyIEZpZWxkICZuYnNwO1Bh cmFtZXRlciBOYW1lICZuYnNwO1ByZWRlZmluZWQgVmFsdWVzICZuYnNwO1JlZmVyZW5jZTwvc3Bh bj4gPHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz48YnI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzwvc3Bhbj4gPHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiJz48YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgVmlhICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgb2MgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBZZXMgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgUkZDWFhYWDwvc3Bhbj4gPHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiJz48YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgVmlhICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgb2MtdmFsaWRpdHkgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7WWVzICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFJG Q1hYWFg8L3NwYW4+IDxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Iic+PGJyPiZuYnNwOyAmbmJzcDsgJm5ic3A7IFZpYSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IG9jLXNlcSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBZZXMgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUkZDWFhYWDwv c3Bhbj4gPHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz48YnI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgVmlhICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgb2MtYWxnbyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1llcyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBSRkNYWFhYPC9zcGFuPiA8 YnI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz48YnI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgUkZDIFhYWFggW05PVEUgVE8gUkZDLUVESVRPUjogUGxlYXNlIHJl cGxhY2Ugd2l0aCBmaW5hbCBSRkM8L3NwYW4+IDxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIic+PGJyPiZuYnNwOyAmbmJzcDsgJm5ic3A7IG51bWJlciBvZiB0aGlz IHNwZWNpZmljYXRpb24uXSZxdW90Ozwvc3Bhbj4gPGJyPjxzcGFuIHN0eWxlPSdmb250LWZhbWls eToiQXJpYWwiLCJzYW5zLXNlcmlmIic+PGJyPlRoZSB0ZXh0IG9mIGRyYWZ0LWlldGYtc29jLW92 ZXJsb2FkLWNvbnRyb2wgcmVmZXJzIHRvIGJvdGggJnF1b3Q7bG9zcyZxdW90OyBhbmQgJnF1b3Q7 cmF0ZSZxdW90OyAmbmJzcDthcyB2YWx1ZXMgZm9yICZuYnNwO29jLWFsZ28uPC9zcGFuPiA8YnI+ PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz48YnI+VGhlIHRl eHQgb2YgZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtY29udHJvbCAmbmJzcDtzZWN0aW9uIDUuMyBy ZWZlcnMgdG8gdGhlIHVzZSBvZiBvYyBmb3IgZWl0aGVyIHJhdGUgb3IgbG9zczwvc3Bhbj4gPGJy PjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+PGJyPiZxdW90 O0FzIGFuIGV4YW1wbGUsIGEgdmFsdWUgb2YgJnF1b3Q7b2M9MTAmcXVvdDsgd2hlbiB0aGUgbG9z cy1iYXNlZCBhbGdvcml0aG0gaXM8L3NwYW4+IDxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIic+PGJyPiZuYnNwOyB1c2VkIGltcGxpZXMgdGhhdCAxMCUgb2YgdGhl IHRvdGFsIG51bWJlciBvZiBTSVAgcmVxdWVzdHMgKGRpYWxvZzwvc3Bhbj4gPHNwYW4gc3R5bGU9 J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz48YnI+Jm5ic3A7IGZvcm1pbmcgYXMg d2VsbCBhcyBpbi1kaWFsb2d1ZSkgYXJlIHN1YmplY3QgdG8gcmVkdWN0aW9uIGF0IHRoZTwvc3Bh bj4gPHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz48YnI+Jm5i c3A7IGNsaWVudC4gJm5ic3A7QW5hbG9nb3VzbHksIGEgdmFsdWUgb2YgJnF1b3Q7b2M9MTAmcXVv dDsgd2hlbiB0aGUgcmF0ZS1iYXNlZDwvc3Bhbj4gPHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiJz48YnI+Jm5ic3A7IGFsZ29yaXRobSBbSS1ELmlldGYtc29jLW92 ZXJsb2FkLXJhdGUtY29udHJvbF0gaXMgdXNlZCBpbmRpY2F0ZXMgdGhhdDwvc3Bhbj4gPHNwYW4g c3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz48YnI+Jm5ic3A7IHRoZSBj bGllbnQgc2hvdWxkIHNlbmQgU0lQIHJlcXVlc3RzIGF0IGEgcmF0ZSBvZiAxMCBTSVAgcmVxdWVz dHMgb3I8L3NwYW4+IDxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Iic+PGJyPiZuYnNwOyBmZXdlciBwZXIgc2Vjb25kLiZxdW90Ozwvc3Bhbj4gPGJyPjxzcGFuIHN0 eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+PGJyPldoYXQgYXJlIHlvdSBz dWdnZXN0aW5nIHdvdWxkIGdvIGluIHRoZSAmcXVvdDtJQU5BIENvbnNpZGVyYXRpb25zJnF1b3Q7 IHNlY3Rpb24gb2YgJm5ic3A7ZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sID8g Jm5ic3A7RG9lcyBpdCBqdXN0IG5lZWQgYSByZWZlcmVuY2UgdG8gdGhlIElBTkEgQ29uc2lkZXJh dGlvbnMgaW4gZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtY29udHJvbD88L3NwYW4+IDxicj48c3Bh biBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPjxicj5KYW5ldDwvc3Bh bj4gPGJyPjxicj48YnI+PGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz48YnI+PGJyPjxicj5UaGlzIGlzIGEgUFJJVkFURSBt ZXNzYWdlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVs ZXRlIHdpdGhvdXQgY29weWluZyBhbmQga2luZGx5IGFkdmlzZSB1cyBieSBlLW1haWwgb2YgdGhl IG1pc3Rha2UgaW4gZGVsaXZlcnkuIE5PVEU6IFJlZ2FyZGxlc3Mgb2YgY29udGVudCwgdGhpcyBl LW1haWwgc2hhbGwgbm90IG9wZXJhdGUgdG8gYmluZCBDU0MgdG8gYW55IG9yZGVyIG9yIG90aGVy IGNvbnRyYWN0IHVubGVzcyBwdXJzdWFudCB0byBleHBsaWNpdCB3cml0dGVuIGFncmVlbWVudCBv ciBnb3Zlcm5tZW50IGluaXRpYXRpdmUgZXhwcmVzc2x5IHBlcm1pdHRpbmcgdGhlIHVzZSBvZiBl LW1haWwgZm9yIHN1Y2ggcHVycG9zZS48L3NwYW4+IDxicj48YnI+PGJyPjxzcGFuIHN0eWxlPSdm b250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzVG NUY1Ric+PGJyPkZyb206ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvc3Bhbj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5D aHJpc3RlciBIb2xtYmVyZyAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb20iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwv c3Bhbj48L2E+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIic+Jmd0Ozwvc3Bhbj4gPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojNUY1RjVGJz48YnI+VG86ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcu NXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5KYW5ldCBQIEd1bm4vVVNBL0NT Q0BDU0M8L3NwYW4+IDxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzVGNUY1Ric+PGJyPkNjOiAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWls eToiQXJpYWwiLCJzYW5zLXNlcmlmIic+JnF1b3Q7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkcmFm dC1pZXRmLXNvYy1vdmVybG9hZC1yYXRlLWNvbnRyb2wuYWxsQHRvb2xzLmlldGYub3JnIj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi Jz5kcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1yYXRlLWNvbnRyb2wuYWxsQHRvb2xzLmlldGYub3Jn PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiJz4mcXVvdDsgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZHJhZnQt aWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLmFsbEB0b29scy5pZXRmLm9yZyI+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+ ZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLmFsbEB0b29scy5pZXRmLm9yZzwv c3Bhbj48L2E+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIic+Jmd0OywgJnF1b3Q7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzaXAtb3Zl cmxvYWRAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6 IkFyaWFsIiwic2Fucy1zZXJpZiInPnNpcC1vdmVybG9hZEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Iic+JnF1b3Q7ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZEBpZXRmLm9y ZyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIic+c2lwLW92ZXJsb2FkQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4mZ3Q7LCAmcXVv dDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnIj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiJz5zaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+JnF1b3Q7 ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3Jn Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiJz5zaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Jmd0 Ozwvc3Bhbj4gPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIjtjb2xvcjojNUY1RjVGJz48YnI+RGF0ZTogJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6 IkFyaWFsIiwic2Fucy1zZXJpZiInPjA2LzI3LzIwMTMgMTI6NTQgUE08L3NwYW4+IDxzcGFuIHN0 eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29s b3I6IzVGNUY1Ric+PGJyPlN1YmplY3Q6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvc3Bh bj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiJz5WUzogW3NpcC1vdmVybG9hZF0gV0dMQzogZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQt cmF0ZS1jb250cm9sIC0gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Q2hyaXN0ZXIncyBjb21t ZW50czwvc3Bhbj4gPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNlbnRl ciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXYgY2xh c3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxociBz aXplPTIgd2lkdGg9IjEwMCUiIG5vc2hhZGUgc3R5bGU9J2NvbG9yOiNBQ0E4OTknIGFsaWduPWNl bnRlcj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPjxicj48YnI+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MDA0MDgwJz48YnI+SGksPC9zcGFuPiA8c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMDA0MDgwJz48YnI+PGJyPiZndDs8 L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwi c2Fucy1zZXJpZiInPlRoZSBJQU5BIGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gb2YgJm5ic3A7ZHJh ZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtY29udHJvbCByZWdpc3RlcnMgdGhlIG5ldyBWaWEgaGVhZGVy IGZpZWxkIHBhcmFtZXRlcnMuPC9zcGFuPiA8c3BhbiBzdHlsZT0nY29sb3I6IzAwNDA4MCc+PGJy PiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwNDA4MCc+PGJyPiZndDs8L3NwYW4+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPklz IGl0IG5lZWRlZCBoZXJlIGFzIHdlbGw/PC9zcGFuPiA8c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMwMDQwODAnPjxi cj48L3NwYW4+Jm5ic3A7PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMDA0MDgwJz48YnI+VGhlIGRyYWZ0IChTZWN0 aW9uIDUpIGRvZXMgZXh0ZW5kIHRoZSBvYyBwYXJhbWV0ZXIsIGRvZXNu4oCZdCBpdD8gSSB3b3Vs ZCBhc3N1bWUgdGhhdCBuZWVkcyB0byBnbyB0byBJQU5BLjwvc3Bhbj4gPHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MDA0MDgwJz48YnI+PC9zcGFuPiZuYnNwOzxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMwMDQwODAnPjxicj5SZWdhcmRz LDwvc3Bhbj4gPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwNDA4MCc+PGJyPjwvc3Bhbj4mbmJzcDs8c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xv cjojMDA0MDgwJz48YnI+Q2hyaXN0ZXI8L3NwYW4+PGJyPjx1PjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6Ymx1ZSc+PGJyPjwvc3Bh bj48c3BhbiBzdHlsZT0nY29sb3I6Ymx1ZSc+PGJyPjwvc3Bhbj48L3U+PGEgaHJlZj0ibWFpbHRv OnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5zaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRm Lm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Iic+IHdyb3RlIG9uIDA2LzI3LzIwMTMgMDY6MDU6NDEgQU06PGJyPjxicj4m Z3Q7IEZyb206IENocmlzdGVyIEhvbG1iZXJnICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmNo cmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi Q291cmllciBOZXciJz4mZ3Q7PC9zcGFuPiA8c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQ291cmllciBOZXciJz48YnI+Jmd0OyBUbzogJnF1b3Q7PC9zcGFuPjxhIGhy ZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPnNpcC1vdmVybG9hZEBpZXRmLm9yZzwv c3Bhbj48L2E+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Iic+JnF1b3Q7ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZEBp ZXRmLm9yZyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Iic+c2lwLW92ZXJsb2FkQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7PC9zcGFuPiA8c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48YnI+ Jmd0OyBDYzogJnF1b3Q7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLXNvYy1vdmVy bG9hZC1yYXRlLWNvbnRyb2wuYWxsQHRvb2xzLmlldGYub3JnIj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5kcmFmdC1pZXRmLXNvYy1vdmVy bG9hZC1yYXRlLWNvbnRyb2wuYWxsQHRvb2xzLmlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mcXVvdDsgPGJy PiZndDsgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQt cmF0ZS1jb250cm9sLmFsbEB0b29scy5pZXRmLm9yZyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+ZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQt cmF0ZS1jb250cm9sLmFsbEB0b29scy5pZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0Ozwvc3Bhbj4gPHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PGJy PiZndDsgRGF0ZTogMDYvMjcvMjAxMyAwNjowNSBBTTwvc3Bhbj4gPHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PGJyPiZndDsgU3ViamVjdDog W3NpcC1vdmVybG9hZF0gV0dMQzogZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9s IC08YnI+Jmd0OyBDaHJpc3RlcidzIGNvbW1lbnRzPC9zcGFuPiA8c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48YnI+Jmd0OyBTZW50IGJ5OiA8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnIj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5zaXAt b3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+IDxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxicj4mZ3Q7IDxicj4mZ3Q7IEhp LDwvc3Bhbj4gPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Iic+PGJyPiZndDsgJm5ic3A7PC9zcGFuPiA8c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48YnI+Jmd0OyBJIGhhdmUgcmVhZCBkcmFm dC1pZXRmLXNvYy1vdmVybG9hZC1yYXRlLWNvbnRyb2wtMDQudHh0IGFzIHBhcnQgb2YgdGhlIFdH TEMuIDxicj4mZ3Q7IDxicj4uLi48L3NwYW4+IDxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxicj4mZ3Q7IFE3OiBJbiBTZWN0aW9uIDcgeW91 IHNheSB0aGF0IHRoZXJlIGFyZSBubyBJQU5BIGNvbnNpZGVyYXRpb25zLiBCdXQsPGJyPiZndDsg ZG9u4oCZdCB5b3UgbmVlZCB0byByZXF1ZXN0IElBTkEgdG8gcmVnaXN0ZXIgdGhlIG5ldyBWaWEg aGVhZGVyIGZpZWxkIDxicj4mZ3Q7IHBhcmFtZXRlcnM/PC9zcGFuPiA8c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48YnI+Jmd0OyAmbmJzcDs8 L3NwYW4+IDxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyInPjxicj4mZ3Q7IFJlZ2FyZHMsPC9zcGFuPiA8c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48YnI+Jmd0OyAmbmJzcDs8L3NwYW4+IDxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxi cj4mZ3Q7IENocmlzdGVyPC9zcGFuPiA8c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQ291cmllciBOZXciJz48YnI+Jmd0OyAmbmJzcDs8L3NwYW4+IDxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxicj4mZ3Q7ICZu YnNwOzwvc3Bhbj4gPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Iic+PGJyPiZndDsgJm5ic3A7PC9zcGFuPiA8c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48YnI+Jmd0OyAmbmJzcDs8L3NwYW4+ IDxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIn Pjxicj4mZ3Q7ICZuYnNwO19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPiZndDsgc2lwLW92ZXJsb2FkIG1haWxpbmcgbGlzdDxicj4mZ3Q7IDwvc3Bhbj48 YSBocmVmPSJtYWlsdG86c2lwLW92ZXJsb2FkQGlldGYub3JnIj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5zaXAtb3ZlcmxvYWRAaWV0Zi5v cmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPjxicj4mZ3Q7IDwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NpcC1vdmVybG9hZCI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zaXAtb3ZlcmxvYWQ8L3NwYW4+PC9hPiA8bzpwPjwvbzpwPjwvcD48L2Rp dj48L2JvZHk+PC9odG1sPg== --_000_5EBD159DE88147488A3B1590E09001840353BDA4CABEnjfpsrvexg2_-- From ecnoel@research.att.com Mon Jul 8 16:38:38 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 EF39C21F9A27; Mon, 8 Jul 2013 16:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gM65h+B4qV+U; Mon, 8 Jul 2013 16:38:33 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 3808311E80E0; Mon, 8 Jul 2013 16:38:33 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 98F2412045C; Mon, 8 Jul 2013 19:38:23 -0400 (EDT) Received: from njfpsrvexg2.research.att.com (njfpsrvexg2.research.att.com [135.207.177.29]) by mail-green.research.att.com (Postfix) with ESMTP id 86685E018A; Mon, 8 Jul 2013 19:36:50 -0400 (EDT) Received: from njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9]) by njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9%14]) with mapi; Mon, 8 Jul 2013 19:38:23 -0400 From: "NOEL, ERIC C (ERIC C)" To: 'Christer Holmberg' , Janet P Gunn Date: Mon, 8 Jul 2013 19:38:23 -0400 Thread-Topic: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - Christer's comments Thread-Index: Ac5zweEAF4KSgJ2oQr+eAJpjbv955QABR1ggAACFppACGrbysA== Message-ID: <5EBD159DE88147488A3B1590E09001840353BDA4CABF@njfpsrvexg2.research.att.com> References: <7594FB04B1934943A5C02806D1A2204B1C3BD16D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C3BD239@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C3BD25A@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3BD25A@ESESSMB209.ericsson.se> 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_5EBD159DE88147488A3B1590E09001840353BDA4CABFnjfpsrvexg2_" MIME-Version: 1.0 Cc: "sip-overload-bounces@ietf.org" , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" , "sip-overload@ietf.org" , "volker.hilt@bell-labs.com" , "vkg@bell-labs.com" Subject: Re: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - Christer's comments 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, 08 Jul 2013 23:38:39 -0000 --_000_5EBD159DE88147488A3B1590E09001840353BDA4CABFnjfpsrvexg2_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q2hyaXN0ZXIsDQoNCkkgd2lsbCBkZWZlciBiZWxvdyBjb21tZW50IHRvIGRyYWZ0LWlldGYtc29j LW92ZXJsb2FkLWNvbnRyb2wgYXV0aG9ycyBhbmQgY29tcGx5IHdpdGggdGhlaXIgcmVzb2x1dGlv bi4NCg0KVGhhbmsgeW91IGFnYWluIGZvciB5b3VyIGNvbW1lbnRzLA0KDQpFcmljIE5vZWwNCkFU JlQgTGFicywgSW5jLg0KUmV0aGluayBQb3NzaWJsZQ0KDQpOZXR3b3JrIERlc2lnbiBhbmQgUGVy Zm9ybWFuY2UgQW5hbHlzaXMNCjIwMCBTb3V0aCBMYXVyZWwgQXZlbnVlLCBENS0zRDE5DQpNaWRk bGV0b3duLCBOSiAwNzc0OA0KUDogNzMyLjQyMC40MTc0DQplY25vZWxAYXR0LmNvbTxtYWlsdG86 anNtaXRoQGF0dC5jb20+DQoNCkZyb206IHNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDaHJpc3Rl ciBIb2xtYmVyZw0KU2VudDogRnJpZGF5LCBKdW5lIDI4LCAyMDEzIDI6MzIgQU0NClRvOiBDaHJp c3RlciBIb2xtYmVyZzsgSmFuZXQgUCBHdW5uDQpDYzogc2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0 Zi5vcmc7IGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLXJhdGUtY29udHJvbC5hbGxAdG9vbHMuaWV0 Zi5vcmc7IHNpcC1vdmVybG9hZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzaXAtb3ZlcmxvYWRd IFdHTEM6IGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLXJhdGUtY29udHJvbCAtIENocmlzdGVyJ3Mg Y29tbWVudHMNCg0KVGhlIGZvbGxvd2luZyBpcyBvYnZpb3VzbHkgbm90IG5lZWRlZCBpbiBkcmFm dC1pZXRmLXNvYy1vdmVybG9hZC1jb250cm9sOg0KDQoiRVFVQUwiIGlzIGRlZmluZWQgaW4gUkZD IDMyNjEuICAiRElHSVQiIGlzIGRlZmluZWQgaW4gUkZDIDUyMzQuDQoNCg0KRnJvbTogc2lwLW92 ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIENocmlzdGVyIEhvbG1iZXJnDQpTZW50OiAyOC4ga2Vzw6RrdXV0 YSAyMDEzIDk6MjcNClRvOiBKYW5ldCBQIEd1bm4NCkNjOiBzaXAtb3ZlcmxvYWQtYm91bmNlc0Bp ZXRmLm9yZzsgZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLmFsbEB0b29scy5p ZXRmLm9yZzsgc2lwLW92ZXJsb2FkQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NpcC1vdmVybG9h ZF0gV0dMQzogZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sIC0gQ2hyaXN0ZXIn cyBjb21tZW50cw0KDQpIaSwNCg0KU28sIHdpdGggdGhlIHRoaXJkIGFsdGVybmF0aXZlLCBTZWN0 aW9uIDUgd291bGQgbG9vayBzb21ldGhpbmcgbGlrZToNCg0KNS4gIFN5bnRheA0KDQogICBUaGlz IHNwZWNpZmljYXRpb24gZXh0ZW5kcyB0aGUgZXhpc3RpbmcgZGVmaW5pdGlvbiBvZiB0aGUgVmlh IGhlYWRlcg0KICAgZmllbGQgcGFyYW1ldGVycyBvZiBbUkZDMzI2MV0gYXMgZm9sbG93czoNCg0K ICAgICAgICB2aWEtcGFyYW1zID0vIG9jLW5hbg0KICAgICAgIG9jLW5hbiAgICAgID0gIk5hTiIN Cg0KDQpCVFcsIEkgdGhpbmsgdGhlIHN5bnRheCBpbiBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1j b250cm9sIHNob3VsZCBsb29rIGxpa2U6DQoNCiAgICAgICAgdmlhLXBhcmFtcyAgPS8gb2MgLyBv Yy12YWxpZGl0eSAvIG9jLXNlcSAvIG9jLWFsZ28NCg0KICAgICAgIG9jICAgICAgICAgID0gIm9j IiBbRVFVQUwgb2MtbnVtXQ0KICAgICAgIG9jLW51bSAgICAgID0gMSpESUdJVA0KICAgICAgIG9j LXZhbGlkaXR5ID0gIm9jLXZhbGlkaXR5IiBbRVFVQUwgZGVsdGEtbXNdDQogICAgICAgb2Mtc2Vx ICAgICAgPSAib2Mtc2VxIiBFUVVBTCAxKjEyRElHSVQgIi4iIDEqNURJR0lUDQogICAgICAgb2Mt YWxnbyAgICAgPSAib2MtYWxnbyIgRVFVQUwgRFFVT1RFIGFsZ28tbGlzdCAqKENPTU1BIGFsZ28t bGlzdCkNCiAgICAgICAgICAgICAgICAgICAgIERRVU9URQ0KICAgICAgIGFsZ28tbGlzdCAgID0g Imxvc3MiIC8gKihvdGhlci1hbGdvKQ0KICAgICAgIG90aGVyLWFsZ28gID0gJXg0MS01QSAvICV4 NjEtN0EgLyAleDMwLTM5DQogICAgICAgZGVsdGEtbXMgICAgPSAxKkRJR0lUDQoNCg0KSW4gYm90 aCBkcmFmdHMsIEkgd291bGQgYWxzbyBzdWdnZXN0IHRvIHJld3JpdGUgdGhlIFN5bnRheCBzZWN0 aW9ucyBpbiB0aGUgZm9sbG93aW5nIHdheToNCg0KNS4gIEdyYW1tYXINCg0KNS4xLiAgR2VuZXJh bA0KDQogICBUaGlzIHNlY3Rpb24gZXh0ZW5kcyB0aGUgQUJORiBkZWZpbml0aW9uIG9mIHZpYS1w YXJhbXMgZnJvbSBbUkZDMzI2MV0NCiAgIGJ5IGFkZGluZyBhIG5ldyBWaWEgaGVhZGVyIGZpZWxk IHBhcmFtZXRlciwgIm9jLW5hbiIuICBUaGUgQUJORiBkZWZpbmVkDQogICBpbiB0aGlzIHNwZWNp ZmljYXRpb24gaXMgY29uZm9ybWFudCB0byBSRkMgNTIzNCBbUkZDNTIzNF0uICAiRVFVQUwiDQog ICBpcyBkZWZpbmVkIGluIFJGQyAzMjYxLiAgIkRJR0lUIiBpcyBkZWZpbmVkIGluIFJGQyA1MjM0 Lg0KDQo1LjIuICBBQk5GDQoNCiAgIHZpYS1wYXJhbXMgPS8gb2MtbmFuDQogICBvYy1uYW4gICAg ICA9ICJOYU4iDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQoNCkZyb206IENocmlzdGVy IEhvbG1iZXJnDQpTZW50OiAyOC4ga2Vzw6RrdXV0YSAyMDEzIDg6NDANClRvOiBDaHJpc3RlciBI b2xtYmVyZzsgSmFuZXQgUCBHdW5uDQpDYzogc2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPjsgZHJhZnQtaWV0Zi1zb2Mtb3Zl cmxvYWQtcmF0ZS1jb250cm9sLmFsbEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1z b2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLmFsbEB0b29scy5pZXRmLm9yZz47IHNpcC1vdmVybG9h ZEBpZXRmLm9yZzxtYWlsdG86c2lwLW92ZXJsb2FkQGlldGYub3JnPg0KU3ViamVjdDogVlM6IFtz aXAtb3ZlcmxvYWRdIFdHTEM6IGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLXJhdGUtY29udHJvbCAt IENocmlzdGVyJ3MgY29tbWVudHMNCg0KSGksDQoNCkEgdGhpcmQgYWx0ZXJuYXRpdmUgKHByb2Jh Ymx5IHRoZSBlYXNpZXN0IG9uZSwgYXQgbGVhc3QgZnJvbSBhIHN5bnRheCBwZXJzcGVjdGl2ZSkg d291bGQgYmUgdG8gc2ltcGx5IGRlZmluZSBhIG5ldyDigJxvYy1uYW7igJ0gVmlhIGhlYWRlciBm aWVsZCBwYXJhbWV0ZXIuDQoNCm9jLW5hbiAgICAgICAgICA9ICJuYW4iDQoNCuKApm9yIHNvbWV0 aGluZyBsaWtlIHRoYXQuDQoNCkl0IHdvdWxkIG5vdCByZXF1aXJlIGFueSBjaGFuZ2VzIHRvIGRy YWZ0LWlldGYtc29jLW92ZXJsb2FkLWNvbnRyb2wgLg0KDQooVGhlbiwgaW4gdGhlIHByb2NlZHVy ZSBzZWN0aW9ucyB5b3UgbmVlZCB0byBkZXNjcmliZSBob3cvd2hldGhlciB0aGUgb2MgYW5kIG9j LW5hbiBwYXJhbWV0ZXJzIGNhbiBiZSB1c2VkIGF0IHRoZSBzYW1lIHRpbWUgZXRjLCBidXQgdGhh dCBpcyBub3QgYSBzeW50YXggcXVlc3Rpb24uKQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoN CkzDpGhldHTDpGrDpDogc2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNpcC1v dmVybG9hZC1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGll dGYub3JnXSBQdW9sZXN0YSBDaHJpc3RlciBIb2xtYmVyZw0KTMOkaGV0ZXR0eTogMjcuIGtlc8Ok a3V1dGEgMjAxMyAyMjo0Mg0KVmFzdGFhbm90dGFqYTogSmFuZXQgUCBHdW5uDQpLb3Bpbzogc2lw LW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGll dGYub3JnPjsgZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLmFsbEB0b29scy5p ZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLmFsbEB0 b29scy5pZXRmLm9yZz47IHNpcC1vdmVybG9hZEBpZXRmLm9yZzxtYWlsdG86c2lwLW92ZXJsb2Fk QGlldGYub3JnPg0KQWloZTogUmU6IFtzaXAtb3ZlcmxvYWRdIFdHTEM6IGRyYWZ0LWlldGYtc29j LW92ZXJsb2FkLXJhdGUtY29udHJvbCAtIENocmlzdGVyJ3MgY29tbWVudHMNCg0KSGksDQoNCldo ZW4gdGFraW5nIGEgY2xvc2VyIGxvb2ssIEkgYWN0dWFsbHkgdGhpbmsgdGhlcmUgaXMgc29tZXRo aW5nIHRlY2huaWNhbGx5IHdyb25nIHdpdGggdGhlIHN5bnRheCBpbiBTZWN0aW9uIDUgb2YgZHJh ZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLg0KDQpkcmFmdC1pZXRmLXNvYy1vdmVy bG9hZC1jb250cm9sICBkZWZpbmVzIHRoZSBvYyBwYXJhbWV0ZXIgYXM6DQoNCm9jICAgICAgICAg ID0gIm9jIiBbRVFVQUwgb2MtbnVtXQ0KDQoNCk5vdywgaXQgc2VlbXMgbGlrZSBkcmFmdC1pZXRm LXNvYy1vdmVybG9hZC1yYXRlLWNvbnRyb2wgYWN0dWFsbHkgcmUtZGVmaW5lcyB0aGUgc2FtZSBw YXJhbWV0ZXIuIEluIGFkZGl0aW9uLCBpdOKAmXMgZG9uZSBpbiBhIGJhY2t3YXJkIGNvbXBhdGli bGUgbWFubmVyLCBlLmcuIGJlY2F1c2UgdGhlIHBhcmFtZXRlciBjYW4gbm93IGNvbnRhaW4gYSBu b24tbnVtZXJpYyB2YWx1ZSAoc2VlIHRoZSBidWxsZXQgbGlzdCBiZWxvdyB3aGF0IGNhbiBnbyB3 cm9uZyk6DQoNCm9jICAgICAgICAgID0gIm9jIiBFUVVBTCBvYy12YWx1ZQ0KDQoNClRoZSBmb2xs b3dpbmcgY2FuIGhhcHBlbjoNCg0KDQoxLiAgICAgICBJZiBhbiBlbnRpdHkgdGhhdCBzdXBwb3J0 cyBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1jb250cm9sICByZWNlaXZlcyDigJxvYz1OYU7igJ0g aXQgd2lsbCByZWplY3QgaXQsIGFzIGl0IGV4cGVjdHMgYSBudW1lcmljIHZhbHVlLg0KDQoyLiAg ICAgICBJZiBhbiBlbnRpdHkgdGhhdCBzdXBwb3J0cyBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1y YXRlLWNvbnRyb2wgcmVjZWl2ZXMg4oCcb2PigJ0gaXQgd2lsbCByZWplY3QgaXQsIGFzIGl0IGV4 cGVjdHMgYW4gb2MtdmFsdWUuIEJ1dCwgaW4gZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtY29udHJv bCAgdGhlIHVzYWdlIG9mIG9jLXZhbHVlIGlzIG9wdGlvbmFsLg0KDQoNCk9uZSB3YXkgdG8gZml4 IHRoaXMgY291bGQgYmUgdG8gZGVmaW5lIG9jLXZhbHVlIGFzIGEgc2VwYXJhdGUgVmlhIGhlYWRl ciBmaWVsZCBwYXJhbWV0ZXIgKHNpbWlsYXIgdG8gb2MtdmFsaWRpdHksIG9jLXNlcSBldGMpLCBp bnN0ZWFkIG9mIGEgdmFsdWUgb2YgdGhlIG9jIHBhcmFtZXRlci4gQnV0LCB0aGVuIHlvdSB3b3Vs ZCBoYXZlIG9jLW51bQ0KDQpBbm90aGVyIHdheSBpcyB0byBjaGFuZ2UgdGhlIHN5bnRheCBpbiBk cmFmdC1pZXRmLXNvYy1vdmVybG9hZC1jb250cm9sICwgaW4gb3JkZXIgdG8gYWxsb3cgd2hhdCB5 b3Ugd2FudCB0byBkbyBpbiBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1yYXRlLWNvbnRyb2wuDQoN ClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQoNCkzDpGhldHTDpGrDpDogSmFuZXQgUCBHdW5u IFttYWlsdG86amd1bm42QGNzYy5jb21dDQpMw6RoZXRldHR5OiAyNy4ga2Vzw6RrdXV0YSAyMDEz IDIyOjA0DQpWYXN0YWFub3R0YWphOiBDaHJpc3RlciBIb2xtYmVyZw0KS29waW86IGRyYWZ0LWll dGYtc29jLW92ZXJsb2FkLXJhdGUtY29udHJvbC5hbGxAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRy YWZ0LWlldGYtc29jLW92ZXJsb2FkLXJhdGUtY29udHJvbC5hbGxAdG9vbHMuaWV0Zi5vcmc+OyBz aXAtb3ZlcmxvYWRAaWV0Zi5vcmc8bWFpbHRvOnNpcC1vdmVybG9hZEBpZXRmLm9yZz47IHNpcC1v dmVybG9hZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRm Lm9yZz4NCkFpaGU6IFJlOiBWUzogW3NpcC1vdmVybG9hZF0gV0dMQzogZHJhZnQtaWV0Zi1zb2Mt b3ZlcmxvYWQtcmF0ZS1jb250cm9sIC0gQ2hyaXN0ZXIncyBjb21tZW50cw0KDQpDaHJpc3Rlcg0K DQogZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtY29udHJvbCAgc2F5cw0KIiA4LiAgU3ludGF4DQoN CiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBleHRlbmRzIHRoZSBleGlzdGluZyBkZWZpbml0aW9uIG9m IHRoZSBWaWEgaGVhZGVyDQogICBmaWVsZCBwYXJhbWV0ZXJzIG9mIFtSRkMzMjYxXSBhcyBmb2xs b3dzOg0KDQogICAgICAgdmlhLXBhcmFtcyAgPSAgdmlhLXR0bCAvIHZpYS1tYWRkcg0KICAgICAg ICAgICAgICAgICAgICAgIC8gdmlhLXJlY2VpdmVkIC8gdmlhLWJyYW5jaA0KICAgICAgICAgICAg ICAgICAgICAgIC8gb2MgLyBvYy12YWxpZGl0eQ0KICAgICAgICAgICAgICAgICAgICAgIC8gb2Mt c2VxIC8gb2MtYWxnbyAvIHZpYS1leHRlbnNpb24NCg0KDQogICAgICAgb2MgICAgICAgICAgPSAi b2MiIFtFUVVBTCBvYy1udW1dDQogICAgICAgb2MtbnVtICAgICAgPSAxKkRJR0lUDQogICAgICAg b2MtdmFsaWRpdHkgPSAib2MtdmFsaWRpdHkiIFtFUVVBTCBkZWx0YS1tc10NCiAgICAgICBvYy1z ZXEgICAgICA9ICJvYy1zZXEiIEVRVUFMIDEqMTJESUdJVCAiLiIgMSo1RElHSVQNCiAgICAgICBv Yy1hbGdvICAgICA9ICJvYy1hbGdvIiBFUVVBTCBEUVVPVEUgYWxnby1saXN0ICooQ09NTUEgYWxn by1saXN0KQ0KICAgICAgICAgICAgICAgICAgICAgRFFVT1RFDQogICAgICAgYWxnby1saXN0ICAg PSAibG9zcyIgLyAqKG90aGVyLWFsZ28pDQogICAgICAgb3RoZXItYWxnbyAgPSAleDQxLTVBIC8g JXg2MS03QSAvICV4MzAtMzkNCiAgICAgICBkZWx0YS1tcyAgICA9IDEqRElHSVQiDQphbmQNCiIx MS4gIElBTkEgQ29uc2lkZXJhdGlvbnMNCg0KICAgVGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMg Zm91ciBuZXcgVmlhIGhlYWRlciBwYXJhbWV0ZXJzIGFzIGRldGFpbGVkDQogICBiZWxvdyBpbiB0 aGUgIkhlYWRlciBGaWVsZCBQYXJhbWV0ZXIgYW5kIFBhcmFtZXRlciBWYWx1ZXMiIHN1Yi0NCiAg IHJlZ2lzdHJ5IGFzIHBlciB0aGUgcmVnaXN0cnkgY3JlYXRlZCBieSBbUkZDMzk2OF0uICBUaGUg cmVxdWlyZWQNCiAgIGluZm9ybWF0aW9uIGlzOg0KDQogICAgICAgSGVhZGVyIEZpZWxkICBQYXJh bWV0ZXIgTmFtZSAgUHJlZGVmaW5lZCBWYWx1ZXMgIFJlZmVyZW5jZQ0KICAgICAgIF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICAg ICBWaWEgICAgICAgICAgIG9jICAgICAgICAgICAgICAgICBZZXMgICAgICAgICAgICAgUkZDWFhY WA0KICAgICAgIFZpYSAgICAgICAgICAgb2MtdmFsaWRpdHkgICAgICAgIFllcyAgICAgICAgICAg ICBSRkNYWFhYDQogICAgICAgVmlhICAgICAgICAgICBvYy1zZXEgICAgICAgICAgICAgWWVzICAg ICAgICAgICAgIFJGQ1hYWFgNCiAgICAgICBWaWEgICAgICAgICAgIG9jLWFsZ28gICAgICAgICAg ICBZZXMgICAgICAgICAgICAgUkZDWFhYWA0KDQogICAgICAgUkZDIFhYWFggW05PVEUgVE8gUkZD LUVESVRPUjogUGxlYXNlIHJlcGxhY2Ugd2l0aCBmaW5hbCBSRkMNCiAgICAgICBudW1iZXIgb2Yg dGhpcyBzcGVjaWZpY2F0aW9uLl0iDQoNClRoZSB0ZXh0IG9mIGRyYWZ0LWlldGYtc29jLW92ZXJs b2FkLWNvbnRyb2wgcmVmZXJzIHRvIGJvdGggImxvc3MiIGFuZCAicmF0ZSIgIGFzIHZhbHVlcyBm b3IgIG9jLWFsZ28uDQoNClRoZSB0ZXh0IG9mIGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLWNvbnRy b2wgIHNlY3Rpb24gNS4zIHJlZmVycyB0byB0aGUgdXNlIG9mIG9jIGZvciBlaXRoZXIgcmF0ZSBv ciBsb3NzDQoNCiJBcyBhbiBleGFtcGxlLCBhIHZhbHVlIG9mICJvYz0xMCIgd2hlbiB0aGUgbG9z cy1iYXNlZCBhbGdvcml0aG0gaXMNCiAgIHVzZWQgaW1wbGllcyB0aGF0IDEwJSBvZiB0aGUgdG90 YWwgbnVtYmVyIG9mIFNJUCByZXF1ZXN0cyAoZGlhbG9nDQogICBmb3JtaW5nIGFzIHdlbGwgYXMg aW4tZGlhbG9ndWUpIGFyZSBzdWJqZWN0IHRvIHJlZHVjdGlvbiBhdCB0aGUNCiAgIGNsaWVudC4g IEFuYWxvZ291c2x5LCBhIHZhbHVlIG9mICJvYz0xMCIgd2hlbiB0aGUgcmF0ZS1iYXNlZA0KICAg YWxnb3JpdGhtIFtJLUQuaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sXSBpcyB1c2VkIGlu ZGljYXRlcyB0aGF0DQogICB0aGUgY2xpZW50IHNob3VsZCBzZW5kIFNJUCByZXF1ZXN0cyBhdCBh IHJhdGUgb2YgMTAgU0lQIHJlcXVlc3RzIG9yDQogICBmZXdlciBwZXIgc2Vjb25kLiINCg0KV2hh dCBhcmUgeW91IHN1Z2dlc3Rpbmcgd291bGQgZ28gaW4gdGhlICJJQU5BIENvbnNpZGVyYXRpb25z IiBzZWN0aW9uIG9mICBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1yYXRlLWNvbnRyb2wgPyAgRG9l cyBpdCBqdXN0IG5lZWQgYSByZWZlcmVuY2UgdG8gdGhlIElBTkEgQ29uc2lkZXJhdGlvbnMgaW4g ZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtY29udHJvbD8NCg0KSmFuZXQNCg0KDQoNCg0KDQoNClRo aXMgaXMgYSBQUklWQVRFIG1lc3NhZ2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQsIHBsZWFzZSBkZWxldGUgd2l0aG91dCBjb3B5aW5nIGFuZCBraW5kbHkgYWR2aXNlIHVz IGJ5IGUtbWFpbCBvZiB0aGUgbWlzdGFrZSBpbiBkZWxpdmVyeS4gTk9URTogUmVnYXJkbGVzcyBv ZiBjb250ZW50LCB0aGlzIGUtbWFpbCBzaGFsbCBub3Qgb3BlcmF0ZSB0byBiaW5kIENTQyB0byBh bnkgb3JkZXIgb3Igb3RoZXIgY29udHJhY3QgdW5sZXNzIHB1cnN1YW50IHRvIGV4cGxpY2l0IHdy aXR0ZW4gYWdyZWVtZW50IG9yIGdvdmVybm1lbnQgaW5pdGlhdGl2ZSBleHByZXNzbHkgcGVybWl0 dGluZyB0aGUgdXNlIG9mIGUtbWFpbCBmb3Igc3VjaCBwdXJwb3NlLg0KDQoNCg0KRnJvbTogICAg ICAgIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFp bHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+DQpUbzogICAgICAgIEphbmV0IFAg R3Vubi9VU0EvQ1NDQENTQw0KQ2M6ICAgICAgICAiZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0 ZS1jb250cm9sLmFsbEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1zb2Mtb3Zlcmxv YWQtcmF0ZS1jb250cm9sLmFsbEB0b29scy5pZXRmLm9yZz4iIDxkcmFmdC1pZXRmLXNvYy1vdmVy bG9hZC1yYXRlLWNvbnRyb2wuYWxsQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLXNv Yy1vdmVybG9hZC1yYXRlLWNvbnRyb2wuYWxsQHRvb2xzLmlldGYub3JnPj4sICJzaXAtb3Zlcmxv YWRAaWV0Zi5vcmc8bWFpbHRvOnNpcC1vdmVybG9hZEBpZXRmLm9yZz4iIDxzaXAtb3ZlcmxvYWRA aWV0Zi5vcmc8bWFpbHRvOnNpcC1vdmVybG9hZEBpZXRmLm9yZz4+LCAic2lwLW92ZXJsb2FkLWJv dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPiIgPHNp cC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0Bp ZXRmLm9yZz4+DQpEYXRlOiAgICAgICAgMDYvMjcvMjAxMyAxMjo1NCBQTQ0KU3ViamVjdDogICAg ICAgIFZTOiBbc2lwLW92ZXJsb2FkXSBXR0xDOiBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1yYXRl LWNvbnRyb2wgLSAgICAgICAgQ2hyaXN0ZXIncyBjb21tZW50cw0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCg0KDQoNCkhpLA0KDQo+VGhlIElBTkEgY29uc2lkZXJhdGlvbnMgc2Vj dGlvbiBvZiAgZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtY29udHJvbCByZWdpc3RlcnMgdGhlIG5l dyBWaWEgaGVhZGVyIGZpZWxkIHBhcmFtZXRlcnMuDQo+DQo+SXMgaXQgbmVlZGVkIGhlcmUgYXMg d2VsbD8NCg0KVGhlIGRyYWZ0IChTZWN0aW9uIDUpIGRvZXMgZXh0ZW5kIHRoZSBvYyBwYXJhbWV0 ZXIsIGRvZXNu4oCZdCBpdD8gSSB3b3VsZCBhc3N1bWUgdGhhdCBuZWVkcyB0byBnbyB0byBJQU5B Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZz4gd3JvdGUgb24gMDYvMjcv MjAxMyAwNjowNTo0MSBBTToNCg0KPiBGcm9tOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIu aG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5j b20+Pg0KPiBUbzogInNpcC1vdmVybG9hZEBpZXRmLm9yZzxtYWlsdG86c2lwLW92ZXJsb2FkQGll dGYub3JnPiIgPHNpcC1vdmVybG9hZEBpZXRmLm9yZzxtYWlsdG86c2lwLW92ZXJsb2FkQGlldGYu b3JnPj4NCj4gQ2M6ICJkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1yYXRlLWNvbnRyb2wuYWxsQHRv b2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1yYXRlLWNvbnRyb2wu YWxsQHRvb2xzLmlldGYub3JnPiINCj4gPGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLXJhdGUtY29u dHJvbC5hbGxAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLXJh dGUtY29udHJvbC5hbGxAdG9vbHMuaWV0Zi5vcmc+Pg0KPiBEYXRlOiAwNi8yNy8yMDEzIDA2OjA1 IEFNDQo+IFN1YmplY3Q6IFtzaXAtb3ZlcmxvYWRdIFdHTEM6IGRyYWZ0LWlldGYtc29jLW92ZXJs b2FkLXJhdGUtY29udHJvbCAtDQo+IENocmlzdGVyJ3MgY29tbWVudHMNCj4gU2VudCBieTogc2lw LW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGll dGYub3JnPg0KPg0KPiBIaSwNCj4NCj4gSSBoYXZlIHJlYWQgZHJhZnQtaWV0Zi1zb2Mtb3Zlcmxv YWQtcmF0ZS1jb250cm9sLTA0LnR4dCBhcyBwYXJ0IG9mIHRoZSBXR0xDLg0KPg0KLi4uDQo+IFE3 OiBJbiBTZWN0aW9uIDcgeW91IHNheSB0aGF0IHRoZXJlIGFyZSBubyBJQU5BIGNvbnNpZGVyYXRp b25zLiBCdXQsDQo+IGRvbuKAmXQgeW91IG5lZWQgdG8gcmVxdWVzdCBJQU5BIHRvIHJlZ2lzdGVy IHRoZSBuZXcgVmlhIGhlYWRlciBmaWVsZA0KPiBwYXJhbWV0ZXJzPw0KPg0KPiBSZWdhcmRzLA0K Pg0KPiBDaHJpc3Rlcg0KPg0KPg0KPg0KPg0KPiAgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gc2lwLW92ZXJsb2FkIG1haWxpbmcgbGlzdA0KPiBzaXAt b3ZlcmxvYWRAaWV0Zi5vcmc8bWFpbHRvOnNpcC1vdmVybG9hZEBpZXRmLm9yZz4NCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXAtb3ZlcmxvYWQNCg== --_000_5EBD159DE88147488A3B1590E09001840353BDA4CABFnjfpsrvexg2_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYg OSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJcGFu b3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAu TXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpw Lk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5N c29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90 dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7 fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVm b3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5CYWxs b29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9u dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uSFRNTC1lc2ltdW90b2lsdHVD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MLWVzaW11b3RvaWx0dSBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6SFRNTC1lc2ltdW90b2lsdHU7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpGSTt9DQpwLkhU TUwtZXNpbXVvdG9pbHR1LCBsaS5IVE1MLWVzaW11b3RvaWx0dSwgZGl2LkhUTUwtZXNpbXVvdG9p bHR1DQoJe21zby1zdHlsZS1uYW1lOkhUTUwtZXNpbXVvdG9pbHR1Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MLWVzaW11b3RvaWx0dSBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLCJzZXJpZiI7fQ0Kc3Bhbi5TZWxpdGV0ZWtzdGlDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJT ZWxpdGV0ZWtzdGkgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOlNlbGl0ZXRla3N0aTsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0K cC5TZWxpdGV0ZWtzdGksIGxpLlNlbGl0ZXRla3N0aSwgZGl2LlNlbGl0ZXRla3N0aQ0KCXttc28t c3R5bGUtbmFtZTpTZWxpdGV0ZWtzdGk7DQoJbXNvLXN0eWxlLWxpbms6IlNlbGl0ZXRla3N0aSBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjYNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyOA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjkNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0 OTdEO30NCnNwYW4uRW1haWxTdHlsZTMwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46NzAuODVwdCA1Ni43cHQgNzAuODVwdCA1Ni43cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0K CXttc28tbGlzdC1pZDoxOTUwNjk0NTY0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczotMTY3ODA5NzE2MCA2NzgyOTc3NSA2NzgyOTc4NSA2NzgyOTc4NyA2 NzgyOTc3NSA2NzgyOTc4NSA2NzgyOTc4NyA2NzgyOTc3NSA2NzgyOTc4NSA2NzgyOTc4Nzt9DQpA bGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZl bDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0 DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0K QGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmln aHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVs OQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5k ZW50Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90 dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBs ZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz5DaHJpc3Rlciw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkkgd2lsbCBkZWZlciBiZWxv dyBjb21tZW50IHRvIGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLWNvbnRyb2wgYXV0aG9ycyBhbmQg Y29tcGx5IHdpdGggdGhlaXIgcmVzb2x1dGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoYW5rIHlv dSBhZ2FpbiBmb3IgeW91ciBjb21tZW50cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjtjb2xvcjojRjQ3QjIwJz5FcmljIE5v ZWw8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiVmVyZGFu YSIsInNhbnMtc2VyaWYiO2NvbG9yOiM2NjY2NjYnPiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjtjb2xvcjojNjY2NjY2Jz5BVCZhbXA7VCBMYWJzLCBJ bmMuPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJW ZXJkYW5hIiwic2Fucy1zZXJpZiI7Y29sb3I6IzY2NjY2Nic+IDxicj48L3NwYW4+PGk+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYi O2NvbG9yOiMwMEIwRTAnPlJldGhpbmsgUG9zc2libGU8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48aT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwQjBFMCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9pPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOiM2NjY2 NjYnPk5ldHdvcmsgRGVzaWduIGFuZCBQZXJmb3JtYW5jZSBBbmFseXNpczxicj4yMDAgU291dGgg TGF1cmVsIEF2ZW51ZSwgRDUtM0QxOTxicj5NaWRkbGV0b3duLCBOSiAwNzc0ODxicj5QOiA3MzIu NDIwLjQxNzQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PGEgaHJlZj0ibWFpbHRvOmpzbWl0aEBhdHQuY29tIj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiInPmVj bm9lbEBhdHQuY29tPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+PGRpdiBzdHlsZT0nYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiInPiBzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnNpcC1vdmVybG9h ZC1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPkNocmlzdGVyIEhvbG1iZXJn PGJyPjxiPlNlbnQ6PC9iPiBGcmlkYXksIEp1bmUgMjgsIDIwMTMgMjozMiBBTTxicj48Yj5Ubzo8 L2I+IENocmlzdGVyIEhvbG1iZXJnOyBKYW5ldCBQIEd1bm48YnI+PGI+Q2M6PC9iPiBzaXAtb3Zl cmxvYWQtYm91bmNlc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250 cm9sLmFsbEB0b29scy5pZXRmLm9yZzsgc2lwLW92ZXJsb2FkQGlldGYub3JnPGJyPjxiPlN1Ympl Y3Q6PC9iPiBSZTogW3NpcC1vdmVybG9hZF0gV0dMQzogZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQt cmF0ZS1jb250cm9sIC0gQ2hyaXN0ZXIncyBjb21tZW50czxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPlRoZSBmb2xsb3dpbmcgaXMgb2J2aW91c2x5IG5vdCBuZWVkZWQgaW4gZHJh ZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtY29udHJvbDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J3RleHQtaW5kZW50Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZxdW90O0VRVUFMJnF1b3Q7IGlzIGRlZmluZWQg aW4gUkZDIDMyNjEuJm5ic3A7ICZxdW90O0RJR0lUJnF1b3Q7IGlzIGRlZmluZWQgaW4gUkZDIDUy MzQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48 ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIic+IHNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnIFttYWls dG86c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+Q2hy aXN0ZXIgSG9sbWJlcmc8YnI+PGI+U2VudDo8L2I+IDI4LiBrZXPDpGt1dXRhIDIwMTMgOToyNzxi cj48Yj5Ubzo8L2I+IEphbmV0IFAgR3Vubjxicj48Yj5DYzo8L2I+IHNpcC1vdmVybG9hZC1ib3Vu Y2VzQGlldGYub3JnOyBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1yYXRlLWNvbnRyb2wuYWxsQHRv b2xzLmlldGYub3JnOyBzaXAtb3ZlcmxvYWRAaWV0Zi5vcmc8YnI+PGI+U3ViamVjdDo8L2I+IFJl OiBbc2lwLW92ZXJsb2FkXSBXR0xDOiBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1yYXRlLWNvbnRy b2wgLSBDaHJpc3RlcidzIGNvbW1lbnRzPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlNvLCB3aXRo IHRoZSB0aGlyZCBhbHRlcm5hdGl2ZSwgU2VjdGlvbiA1IHdvdWxkIGxvb2sgc29tZXRoaW5nIGxp a2U6PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+ NS4mbmJzcDsgU3ludGF4PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyZuYnNw OyBUaGlzIHNwZWNpZmljYXRpb24gZXh0ZW5kcyB0aGUgZXhpc3RpbmcgZGVmaW5pdGlvbiBvZiB0 aGUgVmlhIGhlYWRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5i c3A7Jm5ic3A7IGZpZWxkIHBhcmFtZXRlcnMgb2YgW1JGQzMyNjFdIGFzIGZvbGxvd3M6PG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB2aWEtcGFyYW1zID0vIG9jLW5hbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9jLW5h biZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA9ICZxdW90O05hTiZxdW90OzxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3BhZ2UtYnJlYWstYmVmb3Jl OmFsd2F5cyc+PHNwYW4gbGFuZz1FTiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQ291cmllciBOZXciJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkJUVywgSSB0aGluayB0 aGUgc3ludGF4IGluIDxiPmRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLWNvbnRyb2wgPC9iPnNob3Vs ZCBsb29rIGxpa2U6PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PGI+PHNwYW4gbGFuZz1GSSBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQ291cmllciBOZXciJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQ291cmllciBOZXciJz52aWEtcGFyYW1zJm5ic3A7ID0vIG9jIC8gb2MtdmFsaWRpdHkg LyBvYy1zZXEgLyBvYy1hbGdvPG86cD48L286cD48L3NwYW4+PC9iPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Iic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb2MmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPSAmcXVvdDtvYyZxdW90OyBbRVFVQUwg b2MtbnVtXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9jLW51bSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA9IDEqRElHSVQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIn PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvYy12YWxpZGl0eSA9ICZxdW90 O29jLXZhbGlkaXR5JnF1b3Q7IFtFUVVBTCBkZWx0YS1tc108bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBv Yy1zZXEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPSAmcXVvdDtvYy1zZXEmcXVvdDsg RVFVQUwgMSoxMkRJR0lUICZxdW90Oy4mcXVvdDsgMSo1RElHSVQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBvYy1hbGdvJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ID0gJnF1b3Q7b2MtYWxnbyZxdW90OyBF UVVBTCBEUVVPVEUgYWxnby1saXN0ICooQ09NTUEgYWxnby1saXN0KTxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERRVU9URTxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGFsZ28tbGlzdCZuYnNwOyZuYnNwOyA9ICZxdW90O2xvc3MmcXVvdDsgLyAqKG90aGVyLWFsZ28p PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgb3RoZXItYWxnbyZuYnNwOyA9ICV4NDEtNUEgLyAleDYxLTdB IC8gJXgzMC0zOTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlbHRhLW1zJm5ic3A7Jm5ic3A7Jm5ic3A7 ID0gMSpESUdJVDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9iPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JbiBib3Ro IGRyYWZ0cywgSSB3b3VsZCBhbHNvIHN1Z2dlc3QgdG8gcmV3cml0ZSB0aGUgU3ludGF4IHNlY3Rp b25zIGluIHRoZSBmb2xsb3dpbmcgd2F5OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyInPjUuJm5ic3A7IEdyYW1tYXI8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Iic+NS4xLiZuYnNwOyBHZW5lcmFsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi Q291cmllciBOZXciJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyInPiZuYnNwOyZuYnNwOyBUaGlzIHNlY3Rpb24gZXh0ZW5kcyB0aGUgQUJORiBkZWZpbml0aW9u IG9mIHZpYS1wYXJhbXMgZnJvbSBbUkZDMzI2MV08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPiZuYnNwOyZuYnNwOyBieSBhZGRpbmcgYSBuZXcgVmlhIGhlYWRlciBmaWVs ZCBwYXJhbWV0ZXIsICZxdW90O29jLW5hbiZxdW90Oy4mbmJzcDsgVGhlIEFCTkYgZGVmaW5lZDxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7IGluIHRo aXMgc3BlY2lmaWNhdGlvbiBpcyBjb25mb3JtYW50IHRvIFJGQyA1MjM0IFtSRkM1MjM0XS4mbmJz cDsgJnF1b3Q7RVFVQUwmcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyInPiZuYnNwOyZuYnNwOyBpcyBkZWZpbmVkIGluIFJGQyAzMjYxLiZuYnNwOyAmcXVvdDtESUdJ VCZxdW90OyBpcyBkZWZpbmVkIGluIFJGQyA1MjM0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Iic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBO ZXciJz41LjIuJm5ic3A7IEFCTkY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g bGFuZz1GSSBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXci Jz4mbmJzcDsmbmJzcDsgdmlhLXBhcmFtcyA9LyBvYy1uYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9Rkkgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7IG9jLW5hbiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyA9ICZxdW90O05hTiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gbGFuZz1GSSBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkNocmlzdGVyPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxi PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9iPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L2I+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi Jz4gQ2hyaXN0ZXIgSG9sbWJlcmcgPGJyPjxiPlNlbnQ6PC9iPiAyOC4ga2Vzw6RrdXV0YSAyMDEz IDg6NDA8YnI+PGI+VG86PC9iPiBDaHJpc3RlciBIb2xtYmVyZzsgSmFuZXQgUCBHdW5uPGJyPjxi PkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnIj5z aXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1p ZXRmLXNvYy1vdmVybG9hZC1yYXRlLWNvbnRyb2wuYWxsQHRvb2xzLmlldGYub3JnIj5kcmFmdC1p ZXRmLXNvYy1vdmVybG9hZC1yYXRlLWNvbnRyb2wuYWxsQHRvb2xzLmlldGYub3JnPC9hPjsgPGEg aHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZEBpZXRmLm9yZyI+c2lwLW92ZXJsb2FkQGlldGYub3Jn PC9hPjxicj48Yj5TdWJqZWN0OjwvYj4gVlM6IFtzaXAtb3ZlcmxvYWRdIFdHTEM6IGRyYWZ0LWll dGYtc29jLW92ZXJsb2FkLXJhdGUtY29udHJvbCAtIENocmlzdGVyJ3MgY29tbWVudHM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUZJIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+SGksPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5n PUZJIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkEgPGI+dGhpcmQgYWx0ZXJuYXRpdmU8 L2I+IChwcm9iYWJseSB0aGUgZWFzaWVzdCBvbmUsIGF0IGxlYXN0IGZyb20gYSBzeW50YXggcGVy c3BlY3RpdmUpIHdvdWxkIGJlIHRvIHNpbXBseSBkZWZpbmUgYSBuZXcg4oCcb2MtbmFu4oCdIFZp YSBoZWFkZXIgZmllbGQgcGFyYW1ldGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+b2MtbmFuJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ID0gJnF1 b3Q7bmFuJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9iPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+4oCmb3Igc29tZXRoaW5nIGxpa2Ug dGhhdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkl0IHdvdWxkIDxiPm5vdDwvYj4gcmVxdWlyZSBhbnkg Y2hhbmdlcyB0byBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1jb250cm9sIC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPihUaGVuLCBpbiB0aGUgPGI+cHJvY2VkdXJlIHNlY3Rpb25zPC9iPiB5b3UgbmVlZCB0 byBkZXNjcmliZSBob3cvd2hldGhlciB0aGUgb2MgYW5kIG9jLW5hbiBwYXJhbWV0ZXJzIGNhbiBi ZSB1c2VkIGF0IHRoZSBzYW1lIHRpbWUgZXRjLCBidXQgdGhhdCBpcyBub3QgYSBzeW50YXggcXVl c3Rpb24uKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkNo cmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRp dj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+ TMOkaGV0dMOkasOkOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gPC9zcGFuPjxzcGFuIGxhbmc9Rkkgc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz48 YSBocmVmPSJtYWlsdG86c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIGxhbmc9 RU4tVVM+c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiInPiBbPC9zcGFuPjxzcGFuIGxhbmc9Rkkgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz48YSBocmVmPSJtYWlsdG86c2lwLW92ZXJsb2Fk LWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIGxhbmc9RU4tVVM+bWFpbHRvOnNpcC1vdmVybG9hZC1i b3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5dIDxiPlB1b2xlc3RhIDwv Yj5DaHJpc3RlciBIb2xtYmVyZzxicj48Yj5Mw6RoZXRldHR5OjwvYj4gMjcuIGtlc8Oka3V1dGEg MjAxMyAyMjo0Mjxicj48Yj5WYXN0YWFub3R0YWphOjwvYj4gSmFuZXQgUCBHdW5uPGJyPjxiPktv cGlvOjwvYj4gPC9zcGFuPjxzcGFuIGxhbmc9Rkkgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz48YSBocmVmPSJtYWlsdG86c2lwLW92ZXJs b2FkLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIGxhbmc9RU4tVVM+c2lwLW92ZXJsb2FkLWJvdW5j ZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPjsgPC9zcGFuPjxzcGFuIGxhbmc9 Rkkgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiJz48YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9s LmFsbEB0b29scy5pZXRmLm9yZyI+PHNwYW4gbGFuZz1FTi1VUz5kcmFmdC1pZXRmLXNvYy1vdmVy bG9hZC1yYXRlLWNvbnRyb2wuYWxsQHRvb2xzLmlldGYub3JnPC9zcGFuPjwvYT48L3NwYW4+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiJz47IDwvc3Bhbj48c3BhbiBsYW5nPUZJIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+PGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVybG9h ZEBpZXRmLm9yZyI+PHNwYW4gbGFuZz1FTi1VUz5zaXAtb3ZlcmxvYWRAaWV0Zi5vcmc8L3NwYW4+ PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiInPjxicj48Yj5BaWhlOjwvYj4gUmU6IFtzaXAtb3ZlcmxvYWRdIFdH TEM6IGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLXJhdGUtY29udHJvbCAtIENocmlzdGVyJ3MgY29t bWVudHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUZJIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+SGksPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBsYW5nPUZJIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPldoZW4gdGFraW5n IGEgY2xvc2VyIGxvb2ssIEkgYWN0dWFsbHkgdGhpbmsgdGhlcmUgaXMgc29tZXRoaW5nIHRlY2hu aWNhbGx5IHdyb25nIHdpdGggdGhlIHN5bnRheCBpbiBTZWN0aW9uIDUgb2YgZHJhZnQtaWV0Zi1z b2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ZHJhZnQtaWV0 Zi1zb2Mtb3ZlcmxvYWQtY29udHJvbCA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ Jm5ic3A7ZGVmaW5lcyB0aGUgb2MgcGFyYW1ldGVyIGFzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ b2MmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg PSAmcXVvdDtvYyZxdW90OyBbRVFVQUwgb2MtbnVtXTxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz5Ob3csIGl0IHNlZW1zIGxpa2UgPGI+ZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQt cmF0ZS1jb250cm9sPC9iPiBhY3R1YWxseSA8Yj5yZS1kZWZpbmVzIDwvYj50aGUgPGI+c2FtZSBw YXJhbWV0ZXI8L2I+LiBJbiBhZGRpdGlvbiwgaXTigJlzIGRvbmUgaW4gYSBiYWNrd2FyZCBjb21w YXRpYmxlIG1hbm5lciwgZS5nLiBiZWNhdXNlIHRoZSBwYXJhbWV0ZXIgY2FuIG5vdyBjb250YWlu IGEgbm9uLW51bWVyaWMgdmFsdWUgKHNlZSB0aGUgYnVsbGV0IGxpc3QgYmVsb3cgd2hhdCBjYW4g Z28gd3JvbmcpOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+b2MmbmJzcDsmbmJzcDsgJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PSAmcXVvdDtvYyZxdW90OyBFUVVBTCBv Yy12YWx1ZTxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGUgZm9sbG93aW5n IGNhbiBoYXBwZW46PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29MaXN0UGFyYWdyYXBoIHN0eWxlPSd0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2 ZWwxIGxmbzInPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PHNw YW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+MS48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGlt ZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bh bj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPklmIGFuIGVu dGl0eSB0aGF0IHN1cHBvcnRzIGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLWNvbnRyb2wmbmJzcDsg cmVjZWl2ZXMgPGI+4oCcb2M9TmFO4oCdPC9iPiBpdCB3aWxsIDxiPnJlamVjdDwvYj4gaXQsIGFz IGl0IGV4cGVjdHMgYSBudW1lcmljIHZhbHVlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSd0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzInPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+Mi48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAi VGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPklmIGFu IGVudGl0eSB0aGF0IHN1cHBvcnRzIGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLXJhdGUtY29udHJv bCByZWNlaXZlcyA8Yj7igJxvY+KAnTwvYj4gaXQgd2lsbCA8Yj5yZWplY3Q8L2I+IGl0LCBhcyBp dCBleHBlY3RzIGFuIG9jLXZhbHVlLiBCdXQsIGluIGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLWNv bnRyb2wmbmJzcDsgdGhlIHVzYWdlIG9mIG9jLXZhbHVlIGlzIG9wdGlvbmFsLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPk9uZSB3YXkgdG8gZml4IHRoaXMgY291bGQgYmUgdG8gZGVm aW5lIG9jLXZhbHVlIGFzIGEgc2VwYXJhdGUgVmlhIGhlYWRlciBmaWVsZCBwYXJhbWV0ZXIgKHNp bWlsYXIgdG8gb2MtdmFsaWRpdHksIG9jLXNlcSBldGMpLCBpbnN0ZWFkIG9mIGEgdmFsdWUgb2Yg dGhlIG9jIHBhcmFtZXRlci4gQnV0LCB0aGVuIHlvdSB3b3VsZCBoYXZlIG9jLW51bTxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+QW5vdGhlciB3YXkgaXMgdG8gY2hhbmdlIHRoZSBzeW50YXggaW4gZHJhZnQt aWV0Zi1zb2Mtb3ZlcmxvYWQtY29udHJvbCAsIGluIG9yZGVyIHRvIGFsbG93IHdoYXQgeW91IHdh bnQgdG8gZG8gaW4gZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkNocmlzdGVyPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Mw6RoZXR0w6Rqw6Q6PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiInPiBKYW5ldCBQIEd1bm4gWzwvc3Bhbj48c3BhbiBsYW5nPUZJIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+PGEgaHJl Zj0ibWFpbHRvOmpndW5uNkBjc2MuY29tIj48c3BhbiBsYW5nPUVOLVVTPm1haWx0bzpqZ3VubjZA Y3NjLmNvbTwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+XSA8YnI+PGI+TMOkaGV0ZXR0eTo8L2I+ IDI3LiBrZXPDpGt1dXRhIDIwMTMgMjI6MDQ8YnI+PGI+VmFzdGFhbm90dGFqYTo8L2I+IENocmlz dGVyIEhvbG1iZXJnPGJyPjxiPktvcGlvOjwvYj4gPC9zcGFuPjxzcGFuIGxhbmc9Rkkgc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz48YSBo cmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLmFsbEB0b29s cy5pZXRmLm9yZyI+PHNwYW4gbGFuZz1FTi1VUz5kcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1yYXRl LWNvbnRyb2wuYWxsQHRvb2xzLmlldGYub3JnPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz47IDwv c3Bhbj48c3BhbiBsYW5nPUZJIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIic+PGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZEBpZXRmLm9y ZyI+PHNwYW4gbGFuZz1FTi1VUz5zaXAtb3ZlcmxvYWRAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bh bj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiInPjsgPC9zcGFuPjxzcGFuIGxhbmc9Rkkgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz48YSBocmVmPSJtYWlsdG86c2lwLW92 ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIGxhbmc9RU4tVVM+c2lwLW92ZXJsb2FkLWJv dW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPjxicj48Yj5BaWhlOjwvYj4g UmU6IFZTOiBbc2lwLW92ZXJsb2FkXSBXR0xDOiBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1yYXRl LWNvbnRyb2wgLSBDaHJpc3RlcidzIGNvbW1lbnRzPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1GSSBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPkNocmlz dGVyPC9zcGFuPjxzcGFuIGxhbmc9Rkk+IDxicj48YnI+PC9zcGFuPjxzcGFuIGxhbmc9Rkkgc3R5 bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4mbmJzcDtkcmFmdC1pZXRmLXNv Yy1vdmVybG9hZC1jb250cm9sICZuYnNwO3NheXM8L3NwYW4+PHNwYW4gbGFuZz1GST4gPGJyPjwv c3Bhbj48c3BhbiBsYW5nPUZJIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Iic+JnF1b3Q7IDguICZuYnNwO1N5bnRheDwvc3Bhbj48c3BhbiBsYW5nPUZJPiA8YnI+PGJyPjwv c3Bhbj48c3BhbiBsYW5nPUZJIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Iic+Jm5ic3A7ICZuYnNwO1RoaXMgc3BlY2lmaWNhdGlvbiBleHRlbmRzIHRoZSBleGlzdGluZyBk ZWZpbml0aW9uIG9mIHRoZSBWaWEgaGVhZGVyPC9zcGFuPjxzcGFuIGxhbmc9Rkk+IDxicj48L3Nw YW4+PHNwYW4gbGFuZz1GSSBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiIn PiZuYnNwOyAmbmJzcDtmaWVsZCBwYXJhbWV0ZXJzIG9mIFtSRkMzMjYxXSBhcyBmb2xsb3dzOjwv c3Bhbj48c3BhbiBsYW5nPUZJPiA8YnI+PGJyPjwvc3Bhbj48c3BhbiBsYW5nPUZJIHN0eWxlPSdm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7dmlhLXBhcmFtcyAmbmJzcDs9ICZuYnNwO3ZpYS10dGwgLyB2aWEtbWFkZHI8L3NwYW4+PHNw YW4gbGFuZz1GST4gPGJyPjwvc3Bhbj48c3BhbiBsYW5nPUZJIHN0eWxlPSdmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIic+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAvIHZpYS1yZWNlaXZlZCAv IHZpYS1icmFuY2g8L3NwYW4+PHNwYW4gbGFuZz1GST4gPGJyPjwvc3Bhbj48c3BhbiBsYW5nPUZJ IHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAvIG9jIC8gb2MtdmFsaWRpdHk8L3NwYW4+PHNwYW4gbGFuZz1GST4gPGJyPjwvc3Bhbj48 c3BhbiBsYW5nPUZJIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAvIG9jLXNlcSAvIG9jLWFsZ28gLyB2aWEtZXh0ZW5zaW9uPC9zcGFu PjxzcGFuIGxhbmc9Rkk+IDxicj48YnI+PGJyPjwvc3Bhbj48c3BhbiBsYW5nPUZJIHN0eWxlPSdm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7b2MgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOz0gJnF1b3Q7b2MmcXVvdDsg W0VRVUFMIG9jLW51bV08L3NwYW4+PHNwYW4gbGFuZz1GST4gPGJyPjwvc3Bhbj48c3BhbiBsYW5n PUZJIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7b2MtbnVtICZuYnNwOyAmbmJzcDsgJm5ic3A7PSAxKkRJR0lUPC9zcGFu PjxzcGFuIGxhbmc9Rkk+IDxicj48L3NwYW4+PHNwYW4gbGFuZz1GSSBzdHlsZT0nZm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO29jLXZh bGlkaXR5ID0gJnF1b3Q7b2MtdmFsaWRpdHkmcXVvdDsgW0VRVUFMIGRlbHRhLW1zXTwvc3Bhbj48 c3BhbiBsYW5nPUZJPiA8YnI+PC9zcGFuPjxzcGFuIGxhbmc9Rkkgc3R5bGU9J2ZvbnQtZmFtaWx5 OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtvYy1zZXEg Jm5ic3A7ICZuYnNwOyAmbmJzcDs9ICZxdW90O29jLXNlcSZxdW90OyBFUVVBTCAxKjEyRElHSVQg JnF1b3Q7LiZxdW90OyAxKjVESUdJVDwvc3Bhbj48c3BhbiBsYW5nPUZJPiA8YnI+PC9zcGFuPjxz cGFuIGxhbmc9Rkkgc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtvYy1hbGdvICZuYnNwOyAmbmJzcDsgPSAmcXVvdDtvYy1h bGdvJnF1b3Q7IEVRVUFMIERRVU9URSBhbGdvLWxpc3QgKihDT01NQSBhbGdvLWxpc3QpPC9zcGFu PjxzcGFuIGxhbmc9Rkk+IDxicj48L3NwYW4+PHNwYW4gbGFuZz1GSSBzdHlsZT0nZm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtEUVVPVEU8L3NwYW4+ PHNwYW4gbGFuZz1GST4gPGJyPjwvc3Bhbj48c3BhbiBsYW5nPUZJIHN0eWxlPSdmb250LWZhbWls eToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YWxnby1s aXN0ICZuYnNwOyA9ICZxdW90O2xvc3MmcXVvdDsgLyAqKG90aGVyLWFsZ28pPC9zcGFuPjxzcGFu IGxhbmc9Rkk+IDxicj48L3NwYW4+PHNwYW4gbGFuZz1GSSBzdHlsZT0nZm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiInPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO290aGVyLWFsZ28g Jm5ic3A7PSAleDQxLTVBIC8gJXg2MS03QSAvICV4MzAtMzk8L3NwYW4+PHNwYW4gbGFuZz1GST4g PGJyPjwvc3Bhbj48c3BhbiBsYW5nPUZJIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIic+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZGVsdGEtbXMgJm5ic3A7ICZuYnNw Oz0gMSpESUdJVCZxdW90Ozwvc3Bhbj48c3BhbiBsYW5nPUZJPiA8YnI+PC9zcGFuPjxzcGFuIGxh bmc9Rkkgc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5hbmQ8L3NwYW4+ PHNwYW4gbGFuZz1GST4gPGJyPjwvc3Bhbj48c3BhbiBsYW5nPUZJIHN0eWxlPSdmb250LWZhbWls eToiQXJpYWwiLCJzYW5zLXNlcmlmIic+JnF1b3Q7MTEuICZuYnNwO0lBTkEgQ29uc2lkZXJhdGlv bnM8L3NwYW4+PHNwYW4gbGFuZz1GST4gPGJyPjxicj48L3NwYW4+PHNwYW4gbGFuZz1GSSBzdHls ZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPiZuYnNwOyAmbmJzcDtUaGlzIHNw ZWNpZmljYXRpb24gZGVmaW5lcyBmb3VyIG5ldyBWaWEgaGVhZGVyIHBhcmFtZXRlcnMgYXMgZGV0 YWlsZWQ8L3NwYW4+PHNwYW4gbGFuZz1GST4gPGJyPjwvc3Bhbj48c3BhbiBsYW5nPUZJIHN0eWxl PSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Jm5ic3A7ICZuYnNwO2JlbG93IGlu IHRoZSAmcXVvdDtIZWFkZXIgRmllbGQgUGFyYW1ldGVyIGFuZCBQYXJhbWV0ZXIgVmFsdWVzJnF1 b3Q7IHN1Yi08L3NwYW4+PHNwYW4gbGFuZz1GST4gPGJyPjwvc3Bhbj48c3BhbiBsYW5nPUZJIHN0 eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Jm5ic3A7ICZuYnNwO3JlZ2lz dHJ5IGFzIHBlciB0aGUgcmVnaXN0cnkgY3JlYXRlZCBieSBbUkZDMzk2OF0uICZuYnNwO1RoZSBy ZXF1aXJlZDwvc3Bhbj48c3BhbiBsYW5nPUZJPiA8YnI+PC9zcGFuPjxzcGFuIGxhbmc9Rkkgc3R5 bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4mbmJzcDsgJm5ic3A7aW5mb3Jt YXRpb24gaXM6PC9zcGFuPjxzcGFuIGxhbmc9Rkk+IDxicj48YnI+PC9zcGFuPjxzcGFuIGxhbmc9 Rkkgc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtIZWFkZXIgRmllbGQgJm5ic3A7UGFyYW1ldGVyIE5hbWUgJm5ic3A7UHJl ZGVmaW5lZCBWYWx1ZXMgJm5ic3A7UmVmZXJlbmNlPC9zcGFuPjxzcGFuIGxhbmc9Rkk+IDxicj48 L3NwYW4+PHNwYW4gbGFuZz1GSSBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiInPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PHNwYW4gbGFuZz1GST4gPGJy Pjwvc3Bhbj48c3BhbiBsYW5nPUZJIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNl cmlmIic+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VmlhICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgb2MgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBZZXMgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgUkZDWFhYWDwvc3Bhbj48c3BhbiBsYW5nPUZJPiA8YnI+PC9zcGFuPjxzcGFuIGxhbmc9 Rkkgc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtWaWEgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBvYy12 YWxpZGl0eSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtZZXMgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUkZDWFhYWDwvc3Bhbj48c3BhbiBsYW5nPUZJPiA8YnI+ PC9zcGFuPjxzcGFuIGxhbmc9Rkkgc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiJz4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtWaWEgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBvYy1zZXEgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgWWVzICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFJGQ1hY WFg8L3NwYW4+PHNwYW4gbGFuZz1GST4gPGJyPjwvc3Bhbj48c3BhbiBsYW5nPUZJIHN0eWxlPSdm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7VmlhICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgb2MtYWxnbyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1llcyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBSRkNYWFhYPC9zcGFuPjxzcGFuIGxhbmc9Rkk+IDxicj48 YnI+PC9zcGFuPjxzcGFuIGxhbmc9Rkkgc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiJz4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtSRkMgWFhYWCBbTk9URSBUTyBSRkMt RURJVE9SOiBQbGVhc2UgcmVwbGFjZSB3aXRoIGZpbmFsIFJGQzwvc3Bhbj48c3BhbiBsYW5nPUZJ PiA8YnI+PC9zcGFuPjxzcGFuIGxhbmc9Rkkgc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiJz4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtudW1iZXIgb2YgdGhpcyBzcGVj aWZpY2F0aW9uLl0mcXVvdDs8L3NwYW4+PHNwYW4gbGFuZz1GST4gPGJyPjxicj48L3NwYW4+PHNw YW4gbGFuZz1GSSBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPlRoZSB0 ZXh0IG9mIGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLWNvbnRyb2wgcmVmZXJzIHRvIGJvdGggJnF1 b3Q7bG9zcyZxdW90OyBhbmQgJnF1b3Q7cmF0ZSZxdW90OyAmbmJzcDthcyB2YWx1ZXMgZm9yICZu YnNwO29jLWFsZ28uPC9zcGFuPjxzcGFuIGxhbmc9Rkk+IDxicj48YnI+PC9zcGFuPjxzcGFuIGxh bmc9Rkkgc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5UaGUgdGV4dCBv ZiBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1jb250cm9sICZuYnNwO3NlY3Rpb24gNS4zIHJlZmVy cyB0byB0aGUgdXNlIG9mIG9jIGZvciBlaXRoZXIgcmF0ZSBvciBsb3NzPC9zcGFuPjxzcGFuIGxh bmc9Rkk+IDxicj48YnI+PC9zcGFuPjxzcGFuIGxhbmc9Rkkgc3R5bGU9J2ZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiJz4mcXVvdDtBcyBhbiBleGFtcGxlLCBhIHZhbHVlIG9mICZxdW90 O29jPTEwJnF1b3Q7IHdoZW4gdGhlIGxvc3MtYmFzZWQgYWxnb3JpdGhtIGlzPC9zcGFuPjxzcGFu IGxhbmc9Rkk+IDxicj48L3NwYW4+PHNwYW4gbGFuZz1GSSBzdHlsZT0nZm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiInPiZuYnNwOyAmbmJzcDt1c2VkIGltcGxpZXMgdGhhdCAxMCUgb2Yg dGhlIHRvdGFsIG51bWJlciBvZiBTSVAgcmVxdWVzdHMgKGRpYWxvZzwvc3Bhbj48c3BhbiBsYW5n PUZJPiA8YnI+PC9zcGFuPjxzcGFuIGxhbmc9Rkkgc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIs InNhbnMtc2VyaWYiJz4mbmJzcDsgJm5ic3A7Zm9ybWluZyBhcyB3ZWxsIGFzIGluLWRpYWxvZ3Vl KSBhcmUgc3ViamVjdCB0byByZWR1Y3Rpb24gYXQgdGhlPC9zcGFuPjxzcGFuIGxhbmc9Rkk+IDxi cj48L3NwYW4+PHNwYW4gbGFuZz1GSSBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiInPiZuYnNwOyAmbmJzcDtjbGllbnQuICZuYnNwO0FuYWxvZ291c2x5LCBhIHZhbHVlIG9m ICZxdW90O29jPTEwJnF1b3Q7IHdoZW4gdGhlIHJhdGUtYmFzZWQ8L3NwYW4+PHNwYW4gbGFuZz1G ST4gPGJyPjwvc3Bhbj48c3BhbiBsYW5nPUZJIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJz YW5zLXNlcmlmIic+Jm5ic3A7ICZuYnNwO2FsZ29yaXRobSBbSS1ELmlldGYtc29jLW92ZXJsb2Fk LXJhdGUtY29udHJvbF0gaXMgdXNlZCBpbmRpY2F0ZXMgdGhhdDwvc3Bhbj48c3BhbiBsYW5nPUZJ PiA8YnI+PC9zcGFuPjxzcGFuIGxhbmc9Rkkgc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiJz4mbmJzcDsgJm5ic3A7dGhlIGNsaWVudCBzaG91bGQgc2VuZCBTSVAgcmVxdWVz dHMgYXQgYSByYXRlIG9mIDEwIFNJUCByZXF1ZXN0cyBvcjwvc3Bhbj48c3BhbiBsYW5nPUZJPiA8 YnI+PC9zcGFuPjxzcGFuIGxhbmc9Rkkgc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiJz4mbmJzcDsgJm5ic3A7ZmV3ZXIgcGVyIHNlY29uZC4mcXVvdDs8L3NwYW4+PHNwYW4g bGFuZz1GST4gPGJyPjxicj48L3NwYW4+PHNwYW4gbGFuZz1GSSBzdHlsZT0nZm9udC1mYW1pbHk6 IkFyaWFsIiwic2Fucy1zZXJpZiInPldoYXQgYXJlIHlvdSBzdWdnZXN0aW5nIHdvdWxkIGdvIGlu IHRoZSAmcXVvdDtJQU5BIENvbnNpZGVyYXRpb25zJnF1b3Q7IHNlY3Rpb24gb2YgJm5ic3A7ZHJh ZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sID8gJm5ic3A7RG9lcyBpdCBqdXN0IG5l ZWQgYSByZWZlcmVuY2UgdG8gdGhlIElBTkEgQ29uc2lkZXJhdGlvbnMgaW4gZHJhZnQtaWV0Zi1z b2Mtb3ZlcmxvYWQtY29udHJvbD88L3NwYW4+PHNwYW4gbGFuZz1GST4gPGJyPjxicj48L3NwYW4+ PHNwYW4gbGFuZz1GSSBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPkph bmV0PC9zcGFuPjxzcGFuIGxhbmc9Rkk+IDxicj48YnI+PGJyPjxicj48YnI+PC9zcGFuPjxzcGFu IGxhbmc9Rkkgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiInPiZuYnNwOzxicj48YnI+VGhpcyBpcyBhIFBSSVZBVEUgbWVzc2FnZS4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB3aXRob3V0IGNv cHlpbmcgYW5kIGtpbmRseSBhZHZpc2UgdXMgYnkgZS1tYWlsIG9mIHRoZSBtaXN0YWtlIGluIGRl bGl2ZXJ5LiBOT1RFOiBSZWdhcmRsZXNzIG9mIGNvbnRlbnQsIHRoaXMgZS1tYWlsIHNoYWxsIG5v dCBvcGVyYXRlIHRvIGJpbmQgQ1NDIHRvIGFueSBvcmRlciBvciBvdGhlciBjb250cmFjdCB1bmxl c3MgcHVyc3VhbnQgdG8gZXhwbGljaXQgd3JpdHRlbiBhZ3JlZW1lbnQgb3IgZ292ZXJubWVudCBp bml0aWF0aXZlIGV4cHJlc3NseSBwZXJtaXR0aW5nIHRoZSB1c2Ugb2YgZS1tYWlsIGZvciBzdWNo IHB1cnBvc2UuPC9zcGFuPjxzcGFuIGxhbmc9Rkk+IDxicj48YnI+PGJyPjxicj48L3NwYW4+PHNw YW4gbGFuZz1GSSBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiO2NvbG9yOiM1RjVGNUYnPkZyb206ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPUZJIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6 IkFyaWFsIiwic2Fucy1zZXJpZiInPkNocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWls dG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmlj c3Nvbi5jb208L2E+Jmd0Ozwvc3Bhbj48c3BhbiBsYW5nPUZJPiA8YnI+PC9zcGFuPjxzcGFuIGxh bmc9Rkkgc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNl cmlmIjtjb2xvcjojNUY1RjVGJz5UbzogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9Rkkgc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIic+SmFuZXQgUCBHdW5uL1VTQS9DU0NAQ1NDPC9zcGFuPjxzcGFuIGxhbmc9 Rkk+IDxicj48L3NwYW4+PHNwYW4gbGFuZz1GSSBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiM1RjVGNUYnPkNjOiAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz1GSSBzdHlsZT0nZm9udC1zaXplOjcu NXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4mcXVvdDs8YSBocmVmPSJtYWls dG86ZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLmFsbEB0b29scy5pZXRmLm9y ZyI+ZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLmFsbEB0b29scy5pZXRmLm9y ZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1y YXRlLWNvbnRyb2wuYWxsQHRvb2xzLmlldGYub3JnIj5kcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1y YXRlLWNvbnRyb2wuYWxsQHRvb2xzLmlldGYub3JnPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1h aWx0bzpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmciPnNpcC1vdmVybG9hZEBpZXRmLm9yZzwvYT4mcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmciPnNpcC1vdmVybG9h ZEBpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86c2lwLW92ZXJsb2FkLWJv dW5jZXNAaWV0Zi5vcmciPnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPC9hPiZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnIj5zaXAtb3Zl cmxvYWQtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7PC9zcGFuPjxzcGFuIGxhbmc9Rkk+IDxicj48 L3NwYW4+PHNwYW4gbGFuZz1GSSBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiM1RjVGNUYnPkRhdGU6ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPUZJIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPjA2LzI3LzIwMTMgMTI6NTQgUE08L3NwYW4+ PHNwYW4gbGFuZz1GST4gPGJyPjwvc3Bhbj48c3BhbiBsYW5nPUZJIHN0eWxlPSdmb250LXNpemU6 Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzVGNUY1Ric+U3Vi amVjdDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9Rkkgc3R5 bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+VlM6 IFtzaXAtb3ZlcmxvYWRdIFdHTEM6IGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLXJhdGUtY29udHJv bCAtICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0NocmlzdGVyJ3MgY29tbWVudHM8L3NwYW4+ PHNwYW4gbGFuZz1GST4gPG86cD48L286cD48L3NwYW4+PC9wPjxkaXYgY2xhc3M9TXNvTm9ybWFs IGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxzcGFuIGxhbmc9Rkk+PGhy IHNpemU9MiB3aWR0aD0iMTAwJSIgbm9zaGFkZSBzdHlsZT0nY29sb3I6I0EwQTBBMCcgYWxpZ249 Y2VudGVyPjwvc3Bhbj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1GST48YnI+ PGJyPjxicj48L3NwYW4+PHNwYW4gbGFuZz1GSSBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMwMDQwODAnPkhpLDwvc3Bhbj48 c3BhbiBsYW5nPUZJPiA8YnI+PC9zcGFuPjxzcGFuIGxhbmc9Rkkgc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwNDA4MCc+PGJy PiZndDs8L3NwYW4+PHNwYW4gbGFuZz1GSSBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+VGhlIElBTkEgY29uc2lkZXJhdGlvbnMgc2VjdGlv biBvZiAmbmJzcDtkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1jb250cm9sIHJlZ2lzdGVycyB0aGUg bmV3IFZpYSBoZWFkZXIgZmllbGQgcGFyYW1ldGVycy48L3NwYW4+PHNwYW4gbGFuZz1GST4gPHNw YW4gc3R5bGU9J2NvbG9yOiMwMDQwODAnPjxicj4mZ3Q7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5n PUZJIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiO2NvbG9yOiMwMDQwODAnPjxicj4mZ3Q7PC9zcGFuPjxzcGFuIGxhbmc9Rkkgc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPklzIGl0IG5l ZWRlZCBoZXJlIGFzIHdlbGw/PC9zcGFuPjxzcGFuIGxhbmc9Rkk+IDxicj48L3NwYW4+PHNwYW4g bGFuZz1GSSBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMwMDQwODAnPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPUZJPiA8YnI+ PC9zcGFuPjxzcGFuIGxhbmc9Rkkgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMDA0MDgwJz5UaGUgZHJhZnQgKFNlY3Rpb24g NSkgZG9lcyBleHRlbmQgdGhlIG9jIHBhcmFtZXRlciwgZG9lc27igJl0IGl0PyBJIHdvdWxkIGFz c3VtZSB0aGF0IG5lZWRzIHRvIGdvIHRvIElBTkEuPC9zcGFuPjxzcGFuIGxhbmc9Rkk+IDxicj48 L3NwYW4+PHNwYW4gbGFuZz1GSSBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMwMDQwODAnPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPUZJPiA8YnI+PC9zcGFuPjxzcGFuIGxhbmc9Rkkgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwNDA4MCc+UmVnYXJkcyw8 L3NwYW4+PHNwYW4gbGFuZz1GST4gPGJyPjwvc3Bhbj48c3BhbiBsYW5nPUZJIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMwMDQw ODAnPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPUZJPiA8YnI+PC9zcGFuPjxzcGFuIGxhbmc9Rkkg c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzAwNDA4MCc+Q2hyaXN0ZXI8L3NwYW4+PHNwYW4gbGFuZz1GST48YnI+PGJyPjwvc3Bh bj48dT48c3BhbiBsYW5nPUZJIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7Y29sb3I6Ymx1ZSc+PGJyPjwvc3Bhbj48L3U+PHNwYW4gbGFuZz1GST48YSBo cmVmPSJtYWlsdG86c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPnNpcC1vdmVybG9hZC1i b3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz1GSSBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4gd3JvdGUgb24gMDYvMjcv MjAxMyAwNjowNTo0MSBBTTo8YnI+PGJyPiZndDsgRnJvbTogQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0 Ozwvc3Bhbj48c3BhbiBsYW5nPUZJPjxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Bl cmljc3Nvbi5jb20iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvc3Bhbj48L2E+PC9z cGFuPjxzcGFuIGxhbmc9Rkkgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Iic+Jmd0Ozwvc3Bhbj48c3BhbiBsYW5nPUZJPiA8L3NwYW4+PHNwYW4gbGFuZz1G SSBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48YnI+ Jmd0OyBUbzogJnF1b3Q7PC9zcGFuPjxzcGFuIGxhbmc9Rkk+PGEgaHJlZj0ibWFpbHRvOnNpcC1v dmVybG9hZEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Iic+c2lwLW92ZXJsb2FkQGlldGYub3JnPC9zcGFuPjwvYT48L3NwYW4+ PHNwYW4gbGFuZz1GSSBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmll ciBOZXciJz4mcXVvdDsgJmx0Ozwvc3Bhbj48c3BhbiBsYW5nPUZJPjxhIGhyZWY9Im1haWx0bzpz aXAtb3ZlcmxvYWRAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyInPnNpcC1vdmVybG9hZEBpZXRmLm9yZzwvc3Bhbj48L2E+PC9z cGFuPjxzcGFuIGxhbmc9Rkkgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Iic+Jmd0Ozwvc3Bhbj48c3BhbiBsYW5nPUZJPiA8L3NwYW4+PHNwYW4gbGFuZz1G SSBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48YnI+ Jmd0OyBDYzogJnF1b3Q7PC9zcGFuPjxzcGFuIGxhbmc9Rkk+PGEgaHJlZj0ibWFpbHRvOmRyYWZ0 LWlldGYtc29jLW92ZXJsb2FkLXJhdGUtY29udHJvbC5hbGxAdG9vbHMuaWV0Zi5vcmciPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPmRyYWZ0 LWlldGYtc29jLW92ZXJsb2FkLXJhdGUtY29udHJvbC5hbGxAdG9vbHMuaWV0Zi5vcmc8L3NwYW4+ PC9hPjwvc3Bhbj48c3BhbiBsYW5nPUZJIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyInPiZxdW90OyA8YnI+Jmd0OyAmbHQ7PC9zcGFuPjxzcGFuIGxhbmc9 Rkk+PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLXJhdGUtY29udHJvbC5h bGxAdG9vbHMuaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyInPmRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLXJhdGUtY29udHJvbC5h bGxAdG9vbHMuaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPUZJIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDs8L3NwYW4+PHNw YW4gbGFuZz1GST4gPC9zcGFuPjxzcGFuIGxhbmc9Rkkgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PGJyPiZndDsgRGF0ZTogMDYvMjcvMjAxMyAwNjow NSBBTTwvc3Bhbj48c3BhbiBsYW5nPUZJPiA8L3NwYW4+PHNwYW4gbGFuZz1GSSBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48YnI+Jmd0OyBTdWJqZWN0 OiBbc2lwLW92ZXJsb2FkXSBXR0xDOiBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1yYXRlLWNvbnRy b2wgLTxicj4mZ3Q7IENocmlzdGVyJ3MgY29tbWVudHM8L3NwYW4+PHNwYW4gbGFuZz1GST4gPC9z cGFuPjxzcGFuIGxhbmc9Rkkgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Iic+PGJyPiZndDsgU2VudCBieTogPC9zcGFuPjxzcGFuIGxhbmc9Rkk+PGEgaHJl Zj0ibWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5zaXAtb3ZlcmxvYWQtYm91 bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+IDwvc3Bhbj48c3BhbiBsYW5nPUZJIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxicj4mZ3Q7IDxicj4mZ3Q7 IEhpLDwvc3Bhbj48c3BhbiBsYW5nPUZJPiA8L3NwYW4+PHNwYW4gbGFuZz1GSSBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48YnI+Jmd0OyAmbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz1GST4gPC9zcGFuPjxzcGFuIGxhbmc9Rkkgc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PGJyPiZndDsgSSBoYXZlIHJlYWQg ZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLTA0LnR4dCBhcyBwYXJ0IG9mIHRo ZSBXR0xDLiA8YnI+Jmd0OyA8YnI+Li4uPC9zcGFuPjxzcGFuIGxhbmc9Rkk+IDwvc3Bhbj48c3Bh biBsYW5nPUZJIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyInPjxicj4mZ3Q7IFE3OiBJbiBTZWN0aW9uIDcgeW91IHNheSB0aGF0IHRoZXJlIGFyZSBubyBJ QU5BIGNvbnNpZGVyYXRpb25zLiBCdXQsPGJyPiZndDsgZG9u4oCZdCB5b3UgbmVlZCB0byByZXF1 ZXN0IElBTkEgdG8gcmVnaXN0ZXIgdGhlIG5ldyBWaWEgaGVhZGVyIGZpZWxkIDxicj4mZ3Q7IHBh cmFtZXRlcnM/PC9zcGFuPjxzcGFuIGxhbmc9Rkk+IDwvc3Bhbj48c3BhbiBsYW5nPUZJIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxicj4mZ3Q7ICZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPUZJPiA8L3NwYW4+PHNwYW4gbGFuZz1GSSBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48YnI+Jmd0OyBSZWdhcmRz LDwvc3Bhbj48c3BhbiBsYW5nPUZJPiA8L3NwYW4+PHNwYW4gbGFuZz1GSSBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48YnI+Jmd0OyAmbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz1GST4gPC9zcGFuPjxzcGFuIGxhbmc9Rkkgc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PGJyPiZndDsgQ2hyaXN0ZXI8L3NwYW4+ PHNwYW4gbGFuZz1GST4gPC9zcGFuPjxzcGFuIGxhbmc9Rkkgc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PGJyPiZndDsgJm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9Rkk+IDwvc3Bhbj48c3BhbiBsYW5nPUZJIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxicj4mZ3Q7ICZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PUZJPiA8L3NwYW4+PHNwYW4gbGFuZz1GSSBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQ291cmllciBOZXciJz48YnI+Jmd0OyAmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz1GST4g PC9zcGFuPjxzcGFuIGxhbmc9Rkkgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Iic+PGJyPiZndDsgJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9Rkk+IDwvc3Bh bj48c3BhbiBsYW5nPUZJIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyInPjxicj4mZ3Q7ICZuYnNwO19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPiZndDsgc2lwLW92ZXJsb2FkIG1haWxpbmcgbGlzdDxicj4mZ3Q7 IDwvc3Bhbj48c3BhbiBsYW5nPUZJPjxhIGhyZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWRAaWV0Zi5v cmciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyInPnNpcC1vdmVybG9hZEBpZXRmLm9yZzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9Rkkg c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PGJyPiZn dDsgPC9zcGFuPjxzcGFuIGxhbmc9Rkk+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zaXAtb3ZlcmxvYWQiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2lwLW92ZXJsb2FkPC9zcGFuPjwvYT4gPG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjwvYm9keT48L2h0bWw+ --_000_5EBD159DE88147488A3B1590E09001840353BDA4CABFnjfpsrvexg2_-- From ecnoel@research.att.com Mon Jul 8 16:40:48 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 33FA921F9702 for ; Mon, 8 Jul 2013 16:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cV8mOmIiBR-3 for ; Mon, 8 Jul 2013 16:40:43 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 7663321F9B21 for ; Mon, 8 Jul 2013 16:40:41 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 76C4612048E; Mon, 8 Jul 2013 19:40:40 -0400 (EDT) Received: from njfpsrvexg2.research.att.com (njfpsrvexg2.research.att.com [135.207.177.29]) by mail-green.research.att.com (Postfix) with ESMTP id 6FB77E018A; Mon, 8 Jul 2013 19:39:07 -0400 (EDT) Received: from njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9]) by njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9%14]) with mapi; Mon, 8 Jul 2013 19:40:40 -0400 From: "NOEL, ERIC C (ERIC C)" To: 'Paul Kyzivat' , "DRAGE, Keith (Keith)" Date: Mon, 8 Jul 2013 19:40:40 -0400 Thread-Topic: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - Christer's comments Thread-Index: Ac50Jht7h6V62016QXiVOooLcDGPAwIDk90Q Message-ID: <5EBD159DE88147488A3B1590E09001840353BDA4CAC0@njfpsrvexg2.research.att.com> References: <7594FB04B1934943A5C02806D1A2204B1C3BD16D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C3BD239@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C3BD25A@ESESSMB209.ericsson.se> <51CDA863.6030802@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B062B74@FR712WXCHMBA11.zeu.alcatel-lucent.com> <51CDC9B4.306@alum.mit.edu> In-Reply-To: <51CDC9B4.306@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "vkg@bell-labs.com" , "sip-overload@ietf.org" , "volker.hilt@bell-labs.com" Subject: Re: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - Christer's comments 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, 08 Jul 2013 23:40:48 -0000 Keith, Paul, I will also defer this comment to draft-ietf-soc-overload-control authors a= nd comply with the resolution. 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 -----Original Message----- From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] = On Behalf Of Paul Kyzivat Sent: Friday, June 28, 2013 1:37 PM To: DRAGE, Keith (Keith) Cc: sip-overload@ietf.org Subject: Re: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - Ch= rister's comments Sorry to inflict this on the SOC wg, who probably just want to be told what= to do. But this is not settled ground. On 6/28/13 12:46 PM, DRAGE, Keith (Keith) wrote: > Nowhere in RFC 3968 does it say that. By "that" I presume you mean "3261 is no longer authoritative for header fi= eld parameters"? > I agreed that what RFC 3968 does is ensure that new header field paramete= rs have to be registered, and therefore an IANA registration section is req= uired in this i-d to accomplish this. IANA registrations should be correct,= but they are never "authorative". I agree with you. Before 3968 there was no registry. And while 3261 makes provision for parameters defined in the future via "ge= neric-param", it doesn't say what the rules for defining new ones are. If y= ou just infer from the names, then for Via the hook is called "via-extensio= n". So I would be inclined to infer that it intended that an extension to 3= 261 was required. Then a convention grew up where such extensions did so by redefining the 3261 ABNF (e.g., 'via-params =3D/ ...') in a normative extension to 3261. So at that time, to obtain an exhaustive list of header parameters, you cou= ld search 3261 and all declared extensions to it for syntax definitions of = header field parameters. RFC 3968 changed this by introducing a registry, and by saying that to add = a new parameter you needed an RFC, but that it didn't need to be standards = track. I *think* that also means it doesn't need to be declared as an *exte= nsion* to 3261. And so searching 3261 and extensions is no longer a suffici= ent mechanism to find all defined header field params. > However the defining i-d / RFC is still the normative specification of th= at parameter. If ABNF is the easiest way of defining this, then so be it. Agreed that ABNF is not required. But it must be clear. And since this is intended to coordinate with the rest of sip that is defin= ed by ABNF, it is strongly recommended. If it isn't, then some of use will = probably complain if/when we notice. > Adding a header field parameter has never required the defining i-d / RFC= to update RFC 3261, assuming the underlying RFC 3261 ABNF was extendable i= n the first place. The IANA registry is an authoritative list of all legitimate header field p= arameters. I agree that the registry is not authoritative for the definitions themselv= es. The drafts containing those definitions, referenced by the registry, pr= ovide the actual authoritative definitions of the parameters. The IANA registry is the only IETF supported way to discover *all* defined = header field parameters other than reading each and every RFC. Thanks, Paul > Regards > > Keith > >> -----Original Message----- >> From: sip-overload-bounces@ietf.org >> [mailto:sip-overload-bounces@ietf.org] >> On Behalf Of Paul Kyzivat >> Sent: 28 June 2013 16:15 >> To: sip-overload@ietf.org >> Subject: Re: [sip-overload] WGLC: >> draft-ietf-soc-overload-rate-control - Christer's comments >> >> Sorry, I haven't been following the progress of this draft for a long >> time, but this just caught my eye... >> >> The ABNF of 3261 is no longer authoritative for header field parameters. >> This was changed by RFC3968. Now these are registered in the "Header >> Field Parameters and Parameter Values" sub-registry of the IANA >> "Session Initiation Protocol (SIP) Parameters" registry. >> >> So you need an IANA considerations section that provides the info in >> the form called out in Section 4.1 of RFC3968. >> >> There is some debate if need, or even if it is good to provide ABNF >> extension syntax relative to 3261. IMO it is sufficient for you to >> register the parameter in IANA and define the syntax of the parameter >> *value* using ABNF. >> >> Done that way, IMO the draft doesn't technically extend 3261, but >> that point has also been debated. >> >> If you want to reuse EQUAL and DIGIT from 3261 then you should >> probably say so, though if you are formally extending 3261 via =3D/ >> then of course you are implicitly inheriting everything defined in 3261. >> >> Thanks, >> Paul >> >> >> On 6/28/13 2:32 AM, Christer Holmberg wrote: >>> The following is obviously not needed in draft-ietf-soc-overload- >> control: >>> >>> "EQUAL" is defined in RFC 3261. "DIGIT" is defined in RFC 5234. >>> >>> *From:*sip-overload-bounces@ietf.org >>> [mailto:sip-overload-bounces@ietf.org] *On Behalf Of *Christer >>> Holmberg >>> *Sent:* 28. kes=E4kuuta 2013 9:27 >>> *To:* Janet P Gunn >>> *Cc:* sip-overload-bounces@ietf.org; >>> draft-ietf-soc-overload-rate-control.all@tools.ietf.org; >>> sip-overload@ietf.org >>> *Subject:* Re: [sip-overload] WGLC: >>> draft-ietf-soc-overload-rate-control >>> - Christer's comments >>> >>> Hi, >>> >>> So, with the third alternative, Section 5 would look something like: >>> >>> 5. Syntax >>> >>> This specification extends the existing definition of the Via >>> header >>> >>> field parameters of [RFC3261] as follows: >>> >>> via-params =3D/ oc-nan >>> >>> oc-nan =3D "NaN" >>> >>> BTW, I think the syntax in *draft-ietf-soc-overload-control *should >>> look >>> like: >>> >>> ***via-params =3D/ oc / oc-validity / oc-seq / oc-algo* >>> >>> oc =3D "oc" [EQUAL oc-num] >>> >>> oc-num =3D 1*DIGIT >>> >>> oc-validity =3D "oc-validity" [EQUAL delta-ms] >>> >>> oc-seq =3D "oc-seq" EQUAL 1*12DIGIT "." 1*5DIGIT >>> >>> oc-algo =3D "oc-algo" EQUAL DQUOTE algo-list *(COMMA algo- >> list) >>> >>> DQUOTE >>> >>> algo-list =3D "loss" / *(other-algo) >>> >>> other-algo =3D %x41-5A / %x61-7A / %x30-39 >>> >>> delta-ms =3D 1*DIGIT >>> >>> ** >>> >>> In both drafts, I would also suggest to rewrite the Syntax sections >>> in the following way: >>> >>> 5. Grammar >>> >>> 5.1. General >>> >>> This section extends the ABNF definition of via-params from >> [RFC3261] >>> >>> by adding a new Via header field parameter, "oc-nan". The ABNF >> defined >>> >>> in this specification is conformant to RFC 5234 [RFC5234]. "EQUAL= " >>> >>> is defined in RFC 3261. "DIGIT" is defined in RFC 5234. >>> >>> 5.2. ABNF >>> >>> via-params =3D/ oc-nan >>> >>> oc-nan =3D "NaN" >>> >>> ** >>> >>> Regards, >>> >>> Christer >>> >>> ** >>> >>> ** >>> >>> ** >>> >>> *From:*Christer Holmberg >>> *Sent:* 28. kes=E4kuuta 2013 8:40 >>> *To:* Christer Holmberg; Janet P Gunn >>> *Cc:* sip-overload-bounces@ietf.org >>> ; >>> draft-ietf-soc-overload-rate-control.all@tools.ietf.org >>> ; >>> sip-overload@ietf.org >>> *Subject:* VS: [sip-overload] WGLC: >>> draft-ietf-soc-overload-rate-control >>> - Christer's comments >>> >>> Hi, >>> >>> A *third alternative* (probably the easiest one, at least from a >>> syntax >>> perspective) would be to simply define a new "oc-nan" Via header >>> field parameter. >>> >>> *oc-nan =3D "nan"* >>> >>> .or something like that. >>> >>> It would *not* require any changes to draft-ietf-soc-overload-control . >>> >>> (Then, in the *procedure sections* you need to describe how/whether >>> the oc and oc-nan parameters can be used at the same time etc, but >>> that is not a syntax question.) >>> >>> Regards, >>> >>> Christer >>> >>> *L=E4hett=E4j=E4:*sip-overload-bounces@ietf.org >>> [mailto:sip-overload- >> bounces@ietf.org] >>> *Puolesta *Christer Holmberg >>> *L=E4hetetty:* 27. kes=E4kuuta 2013 22:42 >>> *Vastaanottaja:* Janet P Gunn >>> *Kopio:* sip-overload-bounces@ietf.org >>> ; >>> draft-ietf-soc-overload-rate-control.all@tools.ietf.org >>> ; >>> sip-overload@ietf.org >>> *Aihe:* Re: [sip-overload] WGLC: >>> draft-ietf-soc-overload-rate-control - Christer's comments >>> >>> Hi, >>> >>> When taking a closer look, I actually think there is something >>> technically wrong with the syntax in Section 5 of >>> draft-ietf-soc-overload-rate-control. >>> >>> *draft-ietf-soc-overload-control * defines the oc parameter as: >>> >>> *oc =3D "oc" [EQUAL oc-num]* >>> >>> Now, it seems like *draft-ietf-soc-overload-rate-control* actually >>> *re-defines *the *same parameter*. In addition, it's done in a >>> backward compatible manner, e.g. because the parameter can now >>> contain a non-numeric value (see the bullet list below what can go wron= g): >>> >>> *oc =3D "oc" EQUAL oc-value* >>> >>> The following can happen: >>> >>> 1.If an entity that supports draft-ietf-soc-overload-control >>> receives >>> *"oc=3DNaN"* it will *reject* it, as it expects a numeric value. >>> >>> 2.If an entity that supports draft-ietf-soc-overload-rate-control >>> receives *"oc"* it will *reject* it, as it expects an oc-value. But, >>> in draft-ietf-soc-overload-control the usage of oc-value is optional. >>> >>> One way to fix this could be to define oc-value as a separate Via >>> header field parameter (similar to oc-validity, oc-seq etc), instead >>> of a value of the oc parameter. But, then you would have oc-num >>> >>> Another way is to change the syntax in >>> draft-ietf-soc-overload-control , in order to allow what you want to >>> do in draft-ietf-soc-overload-rate-control. >>> >>> Regards, >>> >>> Christer >>> >>> *L=E4hett=E4j=E4:*Janet P Gunn [mailto:jgunn6@csc.com] >>> *L=E4hetetty:* 27. kes=E4kuuta 2013 22:04 >>> *Vastaanottaja:* Christer Holmberg >>> *Kopio:* draft-ietf-soc-overload-rate-control.all@tools.ietf.org >>> ; >>> sip-overload@ietf.org ; >>> sip-overload-bounces@ietf.org >>> *Aihe:* Re: VS: [sip-overload] WGLC: >>> draft-ietf-soc-overload-rate-control - Christer's comments >>> >>> Christer >>> >>> draft-ietf-soc-overload-control says " 8. Syntax >>> >>> This specification extends the existing definition of the Via head= er >>> field parameters of [RFC3261] as follows: >>> >>> via-params =3D via-ttl / via-maddr >>> / via-received / via-branch >>> / oc / oc-validity >>> / oc-seq / oc-algo / via-extension >>> >>> >>> oc =3D "oc" [EQUAL oc-num] >>> oc-num =3D 1*DIGIT >>> oc-validity =3D "oc-validity" [EQUAL delta-ms] >>> oc-seq =3D "oc-seq" EQUAL 1*12DIGIT "." 1*5DIGIT >>> oc-algo =3D "oc-algo" EQUAL DQUOTE algo-list *(COMMA algo- >> list) >>> DQUOTE >>> algo-list =3D "loss" / *(other-algo) >>> other-algo =3D %x41-5A / %x61-7A / %x30-39 >>> delta-ms =3D 1*DIGIT" >>> and >>> "11. IANA Considerations >>> >>> This specification defines four new Via header parameters as >> detailed >>> below in the "Header Field Parameter and Parameter Values" sub- >>> registry as per the registry created by [RFC3968]. The required >>> information is: >>> >>> Header Field Parameter Name Predefined Values Reference >>> __________________________________________________________ >>> Via oc Yes RFCXXXX >>> Via oc-validity Yes RFCXXXX >>> Via oc-seq Yes RFCXXXX >>> Via oc-algo Yes RFCXXXX >>> >>> RFC XXXX [NOTE TO RFC-EDITOR: Please replace with final RFC >>> number of this specification.]" >>> >>> The text of draft-ietf-soc-overload-control refers to both "loss" >>> and "rate" as values for oc-algo. >>> >>> The text of draft-ietf-soc-overload-control section 5.3 refers to >>> the use of oc for either rate or loss >>> >>> "As an example, a value of "oc=3D10" when the loss-based algorithm is >>> used implies that 10% of the total number of SIP requests (dialog >>> forming as well as in-dialogue) are subject to reduction at the >>> client. Analogously, a value of "oc=3D10" when the rate-based >>> algorithm [I-D.ietf-soc-overload-rate-control] is used >>> indicates >> that >>> the client should send SIP requests at a rate of 10 SIP requests o= r >>> fewer per second." >>> >>> What are you suggesting would go in the "IANA Considerations" section o= f >>> draft-ietf-soc-overload-rate-control ? Does it just need a >>> reference to the IANA Considerations in draft-ietf-soc-overload-control= ? >>> >>> 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: Christer Holmberg >> > >>> To: Janet P Gunn/USA/CSC@CSC >>> Cc: "draft-ietf-soc-overload-rate-control.all@tools.ietf.org >>> " >>> >> >, >>> "sip-overload@ietf.org " >>> >, >>> "sip-overload-bounces@ietf.org " >>> >> > >>> Date: 06/27/2013 12:54 PM >>> Subject: VS: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control = - >>> Christer's comments >>> >>> -------------------------------------------------------------------- >>> ---- >>> >>> >>> >>> >>> Hi, >>> >>>> The IANA considerations section of draft-ietf-soc-overload-control >>> registers the new Via header field parameters. >>>> >>>> Is it needed here as well? >>> >>> The draft (Section 5) does extend the oc parameter, doesn't it? I >>> would assume that needs to go to IANA. >>> >>> Regards, >>> >>> Christer >>> >>> _ >>> _sip-overload-bounces@ietf.org >>> wrote on 06/27/2013 06:05:41 AM: >>> >>>> From: Christer Holmberg > > >>>> To: "sip-overload@ietf.org " >>> > >>>> Cc: "draft-ietf-soc-overload-rate-control.all@tools.ietf.org >>> " >>>> >> > >>>> Date: 06/27/2013 06:05 AM >>>> Subject: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control >>>> - Christer's comments Sent by:sip-overload-bounces@ietf.org >>>> > bounces@ietf.org> >>>> >>>> Hi, >>>> >>>> I have read draft-ietf-soc-overload-rate-control-04.txt as part of >>>> the >> WGLC. >>>> >>> ... >>>> Q7: In Section 7 you say that there are no IANA considerations. >>>> But, don't you need to request IANA to register the new Via header >>>> field parameters? >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 > _______________________________________________ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload From ecnoel@research.att.com Mon Jul 8 16:52:00 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 8895211E80DF for ; Mon, 8 Jul 2013 16:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w13a-D6GgJf1 for ; Mon, 8 Jul 2013 16:51:54 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id E621C21F9ABA for ; Mon, 8 Jul 2013 16:51:53 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id C0443120486; Mon, 8 Jul 2013 19:51:52 -0400 (EDT) Received: from njfpsrvexg2.research.att.com (njfpsrvexg2.research.att.com [135.207.177.29]) by mail-blue.research.att.com (Postfix) with ESMTP id 71217F035E; Mon, 8 Jul 2013 19:51:53 -0400 (EDT) Received: from njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9]) by njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9%14]) with mapi; Mon, 8 Jul 2013 19:51:53 -0400 From: "NOEL, ERIC C (ERIC C)" To: 'Christer Holmberg' , "sip-overload@ietf.org" Date: Mon, 8 Jul 2013 19:51:51 -0400 Thread-Topic: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - Christer's comments Thread-Index: Ac5zHZr1o6fItvHiQZeBysyYYV71ngJFw9wQ Message-ID: <5EBD159DE88147488A3B1590E09001840353BDA4CAC1@njfpsrvexg2.research.att.com> References: <7594FB04B1934943A5C02806D1A2204B1C3BC5DA@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3BC5DA@ESESSMB209.ericsson.se> 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_5EBD159DE88147488A3B1590E09001840353BDA4CAC1njfpsrvexg2_" MIME-Version: 1.0 Cc: "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" Subject: Re: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - Christer's comments 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, 08 Jul 2013 23:52:00 -0000 --_000_5EBD159DE88147488A3B1590E09001840353BDA4CAC1njfpsrvexg2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Christer, Thank you for your review and valuable comments. Please see my response below: Q1: General: The draft uses "client" and "SIP client" terminology (similar = for "server"). I suggest to use consistent terminology. [EN] Agreed, will make terminology consistent where ever it applies. Q2: General: In some places the draft refers to draft-ietf-soc-overload-con= trol-12 without the "[" and "]" characters around. I assume you have "hardc= oded" the draft name, instead of using a reference? [EN] Yes this is hard coded, will add "[" and "]" wherever needed. Q3: My understanding is that the Abstract section shall not contain referen= ces, so please remove those. [EN] Will remove references in abstract. Q4: In Section 3.1, I suggest to replace: "When in overload, the server uses [draft-ietf-soc-overload-control- 12] via header oc parameters of SIP responses to inform the clients of its overload state and of the target SIP request rate." ...with: "When in overload, the server uses the Via header field oc parameters [draf= t-ietf-soc-overload-control-12] of SIP responses in order to inform the clients of its overload state and o= f the target SIP request rate." [EN] Agreed Q5: In Section 3.2, I suggest to change the section name from: "3.2. Summary of via headers parameters for overload control" ...to: "3.2. Via header field parameters for overload control" [EN] Agreed Q6: In Section 3.2, I think it would be good to indicate whether the Via he= ader field parameters are used in SIP Requests, SIP Responses, or both. I k= now that you describe it later, but I think it would be good to have it alr= eady in the overview section. [EN] Agreed Q7: In Section 7 you say that there are no IANA considerations. But, don't = you need to request IANA to register the new Via header field parameters? [EN] Question resulted in several email exchange. I have deferred the issue= to draft-ietf-soc-overload-control authors. Please note I will address your comments in the next version of the draft a= t the end of the WGLC and after having addressed all comments. 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 Christer Holmberg Sent: Thursday, June 27, 2013 6:06 AM To: sip-overload@ietf.org Cc: draft-ietf-soc-overload-rate-control.all@tools.ietf.org Subject: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - Christ= er's comments Hi, I have read draft-ietf-soc-overload-rate-control-04.txt as part of the WGLC= . I don't have any technical issues, in general I think it's a will written d= ocument, and I think the draft can be passed to IESG for publication. However, there are some editorial issues that you might want to fix at this= point, because they might come up sooner or later anyway. Q1: General: The draft uses "client" and "SIP client" terminology (similar = for "server"). I suggest to use consistent terminology. Q2: General: In some places the draft refers to draft-ietf-soc-overload-con= trol-12 without the "[" and "]" characters around. I assume you have "hardc= oded" the draft name, instead of using a reference? Q3: My understanding is that the Abstract section shall not contain referen= ces, so please remove those. Q4: In Section 3.1, I suggest to replace: "When in overload, the server uses [draft-ietf-soc-overload-control- 12] via header oc parameters of SIP responses to inform the clients of its overload state and of the target SIP request rate." ...with: "When in overload, the server uses the Via header field oc parameters [draf= t-ietf-soc-overload-control- of SIP responses in order to inform the clients of its overload state and o= f the target SIP request rate." Q5: In Section 3.2, I suggest to change the section name from: "3.2. Summary of via headers parameters for overload control" ...to: "3.2. Via header field parameters for overload control" Q6: In Section 3.2, I think it would be good to indicate whether the Via he= ader field parameters are used in SIP Requests, SIP Responses, or both. I k= now that you describe it later, but I think it would be good to have it alr= eady in the overview section. Q7: In Section 7 you say that there are no IANA considerations. But, don't = you need to request IANA to register the new Via header field parameters? Regards, Christer --_000_5EBD159DE88147488A3B1590E09001840353BDA4CAC1njfpsrvexg2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Christer,

 

Thank you for your review and valuable comments. <= o:p>

 

Please see my response below:

 

Q1: General: The draft uses “client&#= 8221; and “SIP client” terminology (similar for “server&#= 8221;). I suggest to use consistent terminology.

[EN] Agreed, will make termin= ology consistent where ever it applies.

 

Q2: General: In some places the = draft refers to draft-ietf-soc-overload-control-12 without the “[R= 20; and “]” characters around. I assume you have “hardcod= ed” the draft name, instead of using a reference?

[EN] Yes this is hard = coded, will add “[“ and “]” wherever needed.

&nbs= p;

Q3: M= y understanding is that the Abstract section shall not contain references, = so please remove those.

[EN] Will remove references in abstract.

 

Q4: In Secti= on 3.1, I suggest to replace:

 

“When in overload, the server uses [dr= aft-ietf-soc-overload-control-

      12] via header o= c parameters of SIP responses to inform the clients

    &n= bsp; of its overload state and of the target SIP request rate.”<= /o:p>

&nb= sp;

R= 30;with:

 

“When in overload, the server uses the Via header field oc = parameters [draft-ietf-soc-overload-control-12]

of SIP responses in order to i= nform the clients of its overload state and of the target SIP request rate.= ”

[EN] Agreed

 

Q5: In Section 3.2, I suggest to change the section name= from:

 

“3.2. Summary of via headers parameters for overload control&= #8221;

 

…to:

 

“3.2. Via header field parameters for overload co= ntrol”

[EN] Agreed

 

Q6: In Section 3.2, I think it would be good to indi= cate whether the Via header field parameters are used in SIP Requests, SIP = Responses, or both. I know that you describe it later, but I think it would= be good to have it already in the overview section.

<= p class=3DMsoNormal>[EN] Agreed

 

Q7: In Secti= on 7 you say that there are no IANA considerations. But, don’t you ne= ed to request IANA to register the new Via header field parameters?

[EN] Quest= ion resulted in several email exchange. I have deferred the issue to draft-= ietf-soc-overload-control authors.

 

Please note I will address your commen= ts in the next version of the draft at the end of the WGLC and after having= addressed all comments.

 

Thanks,

 

Eric Noel

AT&T Labs, Inc.
Re= think Possible

=  

Network Design and Pe= rformance Analysis
200 South Laurel Avenue, D5-3D19
Middletown, NJ 07= 748
P: 732.420.4174

ecnoel@att.com

 

From: sip-overlo= ad-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] On Behalf Of = Christer Holmberg
Sent: Thursday, June 27, 2013 6:06 AM
To: sip-overload@ietf.org
Cc: draft-ietf-soc-overload-rate-c= ontrol.all@tools.ietf.org
Subject: [sip-overload] WGLC: draft-iet= f-soc-overload-rate-control - Christer's comments

 

Hi,

<= o:p> 

I have read draft-ietf-soc-= overload-rate-control-04.txt as part of the WGLC.

 

I don’t have a= ny technical issues, in general I think it’s a will written document,= and I think the draft can be passed to IESG for publication.

 

However, th= ere are some editorial issues that you might want to fix at this point, bec= ause they might come up sooner or later anyway.

 

Q1: General: The draft us= es “client” and “SIP client” terminology (similar f= or “server”). I suggest to use consistent terminology.

 

Q2: Ge= neral: In some places the draft refers to draft-ietf-soc-overload-control-1= 2 without the “[“ and “]” characters around. I assu= me you have “hardcoded” the draft name, instead of using a refe= rence?

 

Q3: My understanding is that the Abstract section shall not contai= n references, so please remove those.

 

Q4: In Section 3.1, I suggest to re= place:

 

“When in overload, the server uses [draft-ietf-soc-overload-con= trol-

      12] via header oc parameters of= SIP responses to inform the clients

      = of its overload state and of the target SIP request rate.”=

 

&= #8230;with:

 

“When in overload, the server uses the Via header field oc= parameters [draft-ietf-soc-overload-control-

of SIP responses in order to inform the clients of its overload s= tate and of the target SIP request rate.”

 

 

Q5: In Section 3.2, I suggest to change the section name from:

 

“3= .2. Summary of via headers parameters for overload control”

 

…to:

 

“3= .2. Via header field parameters for overload control”

 

 

Q6: In Section 3.2, I think it woul= d be good to indicate whether the Via header field parameters are used in S= IP Requests, SIP Responses, or both. I know that you describe it later, but= I think it would be good to have it already in the overview section.<= /o:p>

 

Q7:= In Section 7 you say that there are no IANA considerations. But, don’= ;t you need to request IANA to register the new Via header field parameters= ?

 

Regards,

 

Christer

 

 

 = ;

 

 

= --_000_5EBD159DE88147488A3B1590E09001840353BDA4CAC1njfpsrvexg2_-- From ecnoel@research.att.com Tue Jul 9 13:44:15 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 8DFC811E8162; Tue, 9 Jul 2013 13:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVTTTWZ7Iu9W; Tue, 9 Jul 2013 13:44:10 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id A3FF021F9CFB; Tue, 9 Jul 2013 13:44:09 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 696A912058D; Tue, 9 Jul 2013 16:44:08 -0400 (EDT) Received: from njfpsrvexg2.research.att.com (njfpsrvexg2.research.att.com [135.207.177.29]) by mail-green.research.att.com (Postfix) with ESMTP id 323F9E0220; Tue, 9 Jul 2013 16:42:34 -0400 (EDT) Received: from njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9]) by njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9%14]) with mapi; Tue, 9 Jul 2013 16:44:08 -0400 From: "NOEL, ERIC C (ERIC C)" To: "'Yu, James'" , Janet P Gunn Date: Tue, 9 Jul 2013 16:44:08 -0400 Thread-Topic: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Thread-Index: Ac5zhcqru7dYQFxqQKSGvvGKSQFJEAA0j1MAALOuppABZadV0A== Message-ID: <5EBD159DE88147488A3B1590E09001840353BDA4CAD4@njfpsrvexg2.research.att.com> References: <56FB15AFE08E1242B0736CBDCE6E85610808C32F@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610808EF90@stntexmb12.cis.neustar.com> In-Reply-To: <56FB15AFE08E1242B0736CBDCE6E85610808EF90@stntexmb12.cis.neustar.com> 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_5EBD159DE88147488A3B1590E09001840353BDA4CAD4njfpsrvexg2_" MIME-Version: 1.0 Cc: "sip-overload-bounces@ietf.org" , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" , "sip-overload@ietf.org" Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.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, 09 Jul 2013 20:44:15 -0000 --_000_5EBD159DE88147488A3B1590E09001840353BDA4CAD4njfpsrvexg2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Janet, James, Thanks you for your valuable comments and discussion. I tried to capture a= ll resolution in the following text (based on James word document with trac= k changes and imbedded comments enabled). + Abstract section: - Agreed with suggested changes - Please note I will also need to make further changes to remove all refere= nces per Christer Holmberg comment + Section 1: - Agreed with suggested changes + Section 3.1: - Agreed with suggested changes + Section 3.2: - Please note the section title will become "Via header fiel= d parameters for overload control " per Christer Holmberg comment - Agreed with suggested changes excluding title that will change per previo= us bullet + Section 3.3: - Agreed with suggested changes + Section 3.4: - ID: "Note that the target SIP request rate is a max rate that may not be= attained by the arrival rate at the client, and the server cannot assume t= hat it will." [JY] Not clear what value this paragraph tries to add. Is it saying tha= t the client's arrival rate may be lower than the target SIP request rate? [JG] Yes + supporting example (see below in thread) Agreed with Janet and supporting example. Per James request, I will add t= he following text (inspired from Janet's illustrative example): "In other words, when multiple clients are being controlled by an overlo= aded server, at any given time some clients may receive requests at a rate = below its target SIP request rate while others above that target rate. But = the resulting request rate presented to the overloaded server will converge= towards the target SIP request rate." - Agreed with other suggested changes + Section 3.5.1: - ID: "And the larger the difference between TAU1 and TAU2, the closer to t= he control is to strict priority." [JY] Suggest changing into "And the larger the difference between TAU1 an= d TAU2, the closer the control is to strict priority queuing." [JG] Suggest changing into "And the larger the difference between TAU1 an= d TAU2, the closer the control is to strict priority treatment." [EN] Agreed with Janet's suggestion - Agreed with other suggested changes + Section 4: - Agreed with suggested changes + Section 5: - Please note that based comments from per Christer Holmberg and Janet Gunn= , the following was tentatively agreed Replace oc-value =3D "NaN" / oc-num by oc =3D "oc" [EQUAL oc-num] - Agreed with other suggested change + Section 7: - [JY] Should "rate" in oc-algo be registered with IANA? This issue needs to be addressed by draft-ietf-soc-overload-control autho= rs Please note I will wait until expiration of WGLC prior updating our draft R= FC. Once again your comments and/or suggestions are most appreciated. 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 Yu, James Sent: Tuesday, July 02, 2013 9:42 AM To: Janet P Gunn Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all= @tools.ietf.org; sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Janet, For my comment on section 3.4 (the first one below), the current text does = not provide any value. The client's arrival rate could be well below the t= arget SIP request rate when its load is light so the fact that the client m= ay not achieve the target SIP request rate (the max. rate it is allowed to = send to the server) is well understood. But with your explanation on the "= delta" part, the text then makes sense. Please add some discussions on the= "delta" aspect so that even if the average arrival rate at the client is h= igher than the target SIP request rate the client at times may not send mor= e than what the target SIP request rate allows due to the fluctuation of th= e arriving requests at the client. For the comment on section 3.5.1, I agree with your proposed change. For the rate control, the server could calculate the arrival rate from each= communicating client so that it could allocate the overall target SIP requ= est rate to the clients based on their arrival rates known to the server. = But another option is for the client to "optionally" include its calculated= arrival rate in its request to the server when rate control related parame= ters are present. Should this option be evaluated/included to relieve the = server from doing the arrival rate calculations. This would be beneficial = to a server when it receives the requests from many clients. James From: Janet P Gunn [mailto:jgunn6@csc.com] Sent: Friday, June 28, 2013 3:34 PM To: Yu, James Cc: draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@i= etf.org; sip-overload-bounces@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, It is a little hard to respond in email when your comments are in a separat= e document, but here goes. section 3.4 ID says: "Note that the target SIP request rate is a max rate that may not be attained by the arrival rate at the client, and the server cannot assume that it will." Your comment : "Not clear what value this paragraph tries to add. Is it saying that the c= lient's arrival rate may be lower than the target SIP request rate? " Yes. Suppose the server want to limit the total rate of arriving SIP messages to= 100 / sec, and has 10 clients. Each client has a high variance in its mes= sage rate, but together they are well above 100 messages per sec If it sets the rate at 10 messages per second for each of the clients, it w= ill almost certainly end up with an overall average of less than 100 messa= ges per sec, because some clients will be in a "lull" while others are busy= . This is good from a throttling perspective, but, assuming messages are c= orrelated with revenue, bad/wasteful from a revenue, or overall productivit= y perspective. So the server might want to set the rate per client to 10 += delta, where delta is going to be very specific to operating environment. --- In section 3.5.1, bottom of page 8 ID says: "And the larger the difference between TAU1 and TAU2, the closer to the control is to strict priority." You propose changing it to: "And the larger the difference between TAU1 and TAU2, the closer the control is to strict priority queuing." I agree with taking out the redundant "to". But I disagree wit adding "que= uing". There is no queuing, priority or otherwise involved. You could say: "And the larger the difference between TAU1 and TAU2, the closer the control is to strict priority treatment." where " strict priority treatment" would refer to the case where non-priori= ty messages are restricted to a total (priority + non-priority) rate of 10 = messages per second, but priority messages can continue to be sent as long = as the total (priority + non-priority) rate is less than 12 messages per se= cond. At least, I think that is what Eric and Philip are trying to say. 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: "Yu, James" = > To: "sip-overload-bounces@ietf.org" >= , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" >, "sip-overload@ietf.org"= > Date: 06/28/2013 08:10 AM Subject: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Sent by: sip-overload-bounces@ietf.org ________________________________ Salvatore, Please see the attachment for my comments. I pasted the text to a word document to trace/show the proposed changes and= comments. Regards, James [attachment "comments on draft-ietf-soc-overload-rate-control-04.docx" del= eted by Janet P Gunn/USA/CSC] _____________________________________________= __ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6452 - Release Date: 06/30/13 --_000_5EBD159DE88147488A3B1590E09001840353BDA4CAD4njfpsrvexg2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Janet, Ja= mes,

 

Thanks you for your valuable comments an= d discussion.  I tried to capture all resolution in the following text= (based on James word document with track changes and imbedded comments ena= bled).

 

+ Abstract section: =

- Agreed with suggested changes<= /span>

- Please note I will also need to mak= e further changes to remove all references per Christer Holmberg comment

 

=

+ Section 1:

- Agreed with suggested changes

 

+ Section 3.1:

- Agreed = with suggested changes

&nb= sp;

+ Section 3.2: - Plea= se note the section title will become “Via header field parameters fo= r overload control “ per Christer Holmberg comment<= /p>

- Agreed with suggested changes excluding ti= tle that will change per previous bullet

 

+ Se= ction 3.3:

- Agreed with s= uggested changes

&nbs= p;

+ Section 3.4:

- ID:  "Note that the target = SIP request rate is a max rate that may not be attained by the arrival rate= at the client, and the server cannot assume that it will."

   [JY] Not clear wh= at value this paragraph tries to add.  Is it saying that the client's = arrival rate may be lower than the target SIP request rate?

   [JG] Yes + supporting = example (see below in thread)

  Agreed with Janet and supporting example. Per James reques= t, I will add the following text (inspired from Janet’s illustrative = example):

   = 220;In other words, when multiple clients are being controlled by an overlo= aded server, at any given time some clients may receive requests at a rate = below its target SIP request rate while others above that target rate. But = the resulting request rate presented to the overloaded server will converge= towards the target SIP request rate.”

- Agreed with other suggested changes

     <= /span>

+ Section 3.5.1:

- ID: “And the larger the difference bet= ween TAU1 and TAU2, the closer to the control is to strict priority.”=

  [JY] Suggest chang= ing into “And the larger the difference between TAU1 and TAU2, the cl= oser the control is to strict priority queuing.”

  [JG] Suggest changing into “And t= he larger the difference between TAU1 and TAU2, the closer the control is t= o strict priority treatment.”

  [EN] Agreed with Janet’s suggestion

- Agreed with other suggested changes=

 

+ Section 4:

- Agreed with suggested changes

 

+ Section 5:

- Please not= e that based comments from per Christer Holmberg and Janet Gunn, the follow= ing was tentatively agreed

   Replace oc-value =3D "NaN" / oc-num &nbs= p;  by    oc =3D "oc" [EQUAL oc-num]

- Agreed with other suggested chan= ge

 

+ Section 7:

- [JY] Should “rate” in oc-algo be register= ed with IANA?

  This = issue needs to be addressed by draft-ietf-soc-overload-control authors=

 

Please note I will wait until expiration of WGLC = prior updating our draft RFC. Once again your comments and/or suggestions a= re most appreciated.

 

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

 

<= div>

From: sip-overload-bounces@ietf.org [mailto= :sip-overload-bounces@ietf.org] On Behalf Of Yu, James
Sent: Tuesday, July 02, 2013 9:42 AM
To: Janet P Gunn
Cc: = sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all@too= ls.ietf.org; sip-overload@ietf.org
Subject: Re: [sip-overload] dr= aft-ietf-soc-overload-rate-control-04.txt

=

 

Jane= t,

 

For my comment on section 3.4 (the first o= ne below), the current text does not provide any value.  The client= 217;s arrival rate could be well below the target SIP request rate when its= load is light so the fact that the client may not achieve the target SIP r= equest rate (the max. rate it is allowed to send to the server) is well und= erstood.  But with your explanation on the “delta” part, t= he text then makes sense.  Please add some discussions on the “d= elta” aspect so that even if the average arrival rate at the client i= s higher than the target SIP request rate the client at times may not send = more than what the target SIP request rate allows due to the fluctuation of= the arriving requests at the client.

 

For the= comment on section 3.5.1, I agree with your proposed change.

 

For the rate control, the server could calculate the arriv= al rate from each communicating client so that it could allocate the overal= l target SIP request rate to the clients based on their arrival rates known= to the server.  But another option is for the client to “option= ally” include its calculated arrival rate in its request to the serve= r when rate control related parameters are present.  Should this optio= n be evaluated/included to relieve the server from doing the arrival rate c= alculations.  This would be beneficial to a server when it receives th= e requests from many clients.

 

James

 

From: Janet P Gunn [mailto:jgunn6@csc.com]
Sent= : Friday, June 28, 2013 3:34 PM
To: Yu, James
Cc: d= raft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.o= rg; sip-overload-bounces@ietf.org
Subject: Re: [sip-overload] dra= ft-ietf-soc-overload-rate-control-04.txt

 

James,

It is a little = hard to respond in email when your comments are in a separate document, but= here goes.


section 3.4
ID says:
"Note that the target S= IP request rate is a max rate that may not be
   attained by th= e arrival rate at the client, and the server cannot
   assume = that it will."

Your comment :
"Not clear what value this = paragraph tries to add.  Is it saying that the client's arrival rate m= ay be lower than the target SIP request rate?  "

<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Yes.

Suppose the server want to limit the total rate of arriving SIP messages t= o 100 / sec, and has 10 clients.  Each client has a high variance in i= ts message rate, but together they are well above 100 messages per sec

If it sets the rate at 10 messages per second for each of the clients, it= will almost certainly end up  with an overall average of less than 10= 0 messages per sec, because some clients will be in a "lull" whil= e others are busy.  This is good from a throttling perspective, but, a= ssuming messages are correlated with revenue, bad/wasteful from a revenue, = or overall productivity perspective.  So the server might want to set = the rate per client to 10 + delta, where delta is going to be very specific= to operating environment.

---
In section  3.5.1, bottom of pa= ge 8
ID says:
"And the larger
   the difference betwee= n TAU1 and TAU2, the closer to the control is
   to strict prio= rity."

You propose changing it to:
"And the larger=
&nbs= p;  the difference between TAU1 and TAU2, the closer  the control= is
   to strict priority queuing."

I agree with tak= ing out the redundant "to".  But I disagree wit adding "= ;queuing".  There is no queuing, priority or otherwise involved.<= /span>

You could say:
"And the larger
   the difference b= etween TAU1 and TAU2, the closer  the control is
   to str= ict priority treatment."

where " strict priority treatment&= quot; would refer to the case where non-priority messages are restricted to= a total (priority + non-priority) rate of 10 messages per second, but prio= rity messages can continue to be sent as long as the total (priority + non-= priority) rate is less than 12 messages per second.

At least, I think= that is what Eric and  Philip are trying to say.

Janet <= br>

 


This is a PRIVATE message. If you are not the intended r= ecipient, please delete without copying and kindly advise us by e-mail of t= he 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 expli= cit written agreement or government initiative expressly permitting the use= of e-mail for such purpose.



From:    =    "Yu, James" <james.yu@neustar.biz>
To:       &nbs= p;&= quot;sip-overload-bounces@= ietf.org" <sip= -overload-bounces@ietf.org>, "draft-ietf-soc-overload-rate-cont= rol.all@tools.ietf.org" <draft-ietf-soc-overload-rate-control.a= ll@tools.ietf.org>, "s= ip-overload@ietf.org" <sip-overload@ietf.org>
Date:       &n= bsp;06/28/2013 08:10 AM
Subject:        [sip-o= verload] draft-ietf-soc-overload-rate-control-04.txt
Sent by= :        = sip-overload-bounces@ietf.org




Salvatore,
 
Please see the= attachment for my comments.
 
I pasted the text to a word doc= ument to trace/show the proposed changes and comments.
  Regar= ds,
 
James
 [attachment "comments on draft-ietf= -soc-overload-rate-control-04.docx" deleted by Janet P Gunn/USA/CSC] <= /span>________________________________= _______________
sip-overload mailing list
sip-overload@ietf.org
https://www.ietf.org/mailman/listinfo/sip-overload

No virus found in this message.
Checked by AVG -= www.avg.com
Version: 2013.0.2904 / V= irus Database: 3204/6452 - Release Date: 06/30/13

= --_000_5EBD159DE88147488A3B1590E09001840353BDA4CAD4njfpsrvexg2_-- From james.yu@neustar.biz Wed Jul 10 06:01: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 E26FD21F9FFC; Wed, 10 Jul 2013 06:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sG5KMEYpPOVS; Wed, 10 Jul 2013 06:01:16 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 31C7521F9D8C; Wed, 10 Jul 2013 06:01:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1373461422; x=1688816170; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=EeOzWYyhFzoqcYZkZTAZX1U7mSGetZW8f1wg2qsMy3w=; b=mtN/e4NjNuloGgrrQto2Uk+Q56vMmPCnF5LUr7096NYkXAzAK5HZ9GpyBBa7qV 0QlDKQT76Ul4KFWY+C/dDatQ== Received: from ([10.31.58.69]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.26473928; Wed, 10 Jul 2013 09:03:41 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.240]) with mapi id 14.02.0342.003; Wed, 10 Jul 2013 09:00:36 -0400 From: "Yu, James" To: "NOEL, ERIC C (ERIC C)" Thread-Topic: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Thread-Index: Ac5zhcqru7dYQFxqQKSGvvGKSQFJEAA0j1MAALOuppABZadV0AAr0zMg Date: Wed, 10 Jul 2013 13:00:35 +0000 Message-ID: <56FB15AFE08E1242B0736CBDCE6E85610809239D@stntexmb12.cis.neustar.com> References: <56FB15AFE08E1242B0736CBDCE6E85610808C32F@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610808EF90@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353BDA4CAD4@njfpsrvexg2.research.att.com> In-Reply-To: <5EBD159DE88147488A3B1590E09001840353BDA4CAD4@njfpsrvexg2.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.31.32.239] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: LmGuuQd+W8diGq9WU5BZ3A== Content-Type: multipart/alternative; boundary="_000_56FB15AFE08E1242B0736CBDCE6E85610809239Dstntexmb12cisne_" MIME-Version: 1.0 Cc: "sip-overload-bounces@ietf.org" , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" , "sip-overload@ietf.org" Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.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, 10 Jul 2013 13:01:23 -0000 --_000_56FB15AFE08E1242B0736CBDCE6E85610809239Dstntexmb12cisne_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Noel, I mentioned in my message to Janet on 7/2: For the rate control, the server could calculate the arrival rate from each= communicating client so that it could allocate the overall target SIP requ= est rate to the clients based on their arrival rates known to the server. = But another option is for the client to "optionally" include its calculated= arrival rate in its request to the server when rate control related parame= ters are present. Should this option be evaluated/included to relieve the = server from doing the arrival rate calculations. This would be beneficial = to a server when it receives the requests from many clients. I suggest that the I-D adds that option to allow the client to indicate its= current arrival rate (towards the receiving server) in the SIP request. James From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] Sent: Tuesday, July 09, 2013 4:44 PM To: Yu, James; Janet P Gunn Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all= @tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Janet, James, Thanks you for your valuable comments and discussion. I tried to capture a= ll resolution in the following text (based on James word document with trac= k changes and imbedded comments enabled). + Abstract section: - Agreed with suggested changes - Please note I will also need to make further changes to remove all refere= nces per Christer Holmberg comment + Section 1: - Agreed with suggested changes + Section 3.1: - Agreed with suggested changes + Section 3.2: - Please note the section title will become "Via header fiel= d parameters for overload control " per Christer Holmberg comment - Agreed with suggested changes excluding title that will change per previo= us bullet + Section 3.3: - Agreed with suggested changes + Section 3.4: - ID: "Note that the target SIP request rate is a max rate that may not be= attained by the arrival rate at the client, and the server cannot assume t= hat it will." [JY] Not clear what value this paragraph tries to add. Is it saying tha= t the client's arrival rate may be lower than the target SIP request rate? [JG] Yes + supporting example (see below in thread) Agreed with Janet and supporting example. Per James request, I will add t= he following text (inspired from Janet's illustrative example): "In other words, when multiple clients are being controlled by an overlo= aded server, at any given time some clients may receive requests at a rate = below its target SIP request rate while others above that target rate. But = the resulting request rate presented to the overloaded server will converge= towards the target SIP request rate." - Agreed with other suggested changes + Section 3.5.1: - ID: "And the larger the difference between TAU1 and TAU2, the closer to t= he control is to strict priority." [JY] Suggest changing into "And the larger the difference between TAU1 an= d TAU2, the closer the control is to strict priority queuing." [JG] Suggest changing into "And the larger the difference between TAU1 an= d TAU2, the closer the control is to strict priority treatment." [EN] Agreed with Janet's suggestion - Agreed with other suggested changes + Section 4: - Agreed with suggested changes + Section 5: - Please note that based comments from per Christer Holmberg and Janet Gunn= , the following was tentatively agreed Replace oc-value =3D "NaN" / oc-num by oc =3D "oc" [EQUAL oc-num] - Agreed with other suggested change + Section 7: - [JY] Should "rate" in oc-algo be registered with IANA? This issue needs to be addressed by draft-ietf-soc-overload-control autho= rs Please note I will wait until expiration of WGLC prior updating our draft R= FC. Once again your comments and/or suggestions are most appreciated. 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 Yu, James Sent: Tuesday, July 02, 2013 9:42 AM To: Janet P Gunn Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Janet, For my comment on section 3.4 (the first one below), the current text does = not provide any value. The client's arrival rate could be well below the t= arget SIP request rate when its load is light so the fact that the client m= ay not achieve the target SIP request rate (the max. rate it is allowed to = send to the server) is well understood. But with your explanation on the "= delta" part, the text then makes sense. Please add some discussions on the= "delta" aspect so that even if the average arrival rate at the client is h= igher than the target SIP request rate the client at times may not send mor= e than what the target SIP request rate allows due to the fluctuation of th= e arriving requests at the client. For the comment on section 3.5.1, I agree with your proposed change. For the rate control, the server could calculate the arrival rate from each= communicating client so that it could allocate the overall target SIP requ= est rate to the clients based on their arrival rates known to the server. = But another option is for the client to "optionally" include its calculated= arrival rate in its request to the server when rate control related parame= ters are present. Should this option be evaluated/included to relieve the = server from doing the arrival rate calculations. This would be beneficial = to a server when it receives the requests from many clients. James From: Janet P Gunn [mailto:jgunn6@csc.com] Sent: Friday, June 28, 2013 3:34 PM To: Yu, James Cc: draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org; sip-overload-bounces@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, It is a little hard to respond in email when your comments are in a separat= e document, but here goes. section 3.4 ID says: "Note that the target SIP request rate is a max rate that may not be attained by the arrival rate at the client, and the server cannot assume that it will." Your comment : "Not clear what value this paragraph tries to add. Is it saying that the c= lient's arrival rate may be lower than the target SIP request rate? " Yes. Suppose the server want to limit the total rate of arriving SIP messages to= 100 / sec, and has 10 clients. Each client has a high variance in its mes= sage rate, but together they are well above 100 messages per sec If it sets the rate at 10 messages per second for each of the clients, it w= ill almost certainly end up with an overall average of less than 100 messa= ges per sec, because some clients will be in a "lull" while others are busy= . This is good from a throttling perspective, but, assuming messages are c= orrelated with revenue, bad/wasteful from a revenue, or overall productivit= y perspective. So the server might want to set the rate per client to 10 += delta, where delta is going to be very specific to operating environment. --- In section 3.5.1, bottom of page 8 ID says: "And the larger the difference between TAU1 and TAU2, the closer to the control is to strict priority." You propose changing it to: "And the larger the difference between TAU1 and TAU2, the closer the control is to strict priority queuing." I agree with taking out the redundant "to". But I disagree wit adding "que= uing". There is no queuing, priority or otherwise involved. You could say: "And the larger the difference between TAU1 and TAU2, the closer the control is to strict priority treatment." where " strict priority treatment" would refer to the case where non-priori= ty messages are restricted to a total (priority + non-priority) rate of 10 = messages per second, but priority messages can continue to be sent as long = as the total (priority + non-priority) rate is less than 12 messages per se= cond. At least, I think that is what Eric and Philip are trying to say. 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: "Yu, James" = > To: "sip-overload-bounces@ietf.org" >= , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" >, "sip-overload@ietf.org"= > Date: 06/28/2013 08:10 AM Subject: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Sent by: sip-overload-bounces@ietf.org ________________________________ Salvatore, Please see the attachment for my comments. I pasted the text to a word document to trace/show the proposed changes and= comments. Regards, James [attachment "comments on draft-ietf-soc-overload-rate-control-04.docx" del= eted by Janet P Gunn/USA/CSC] _____________________________________________= __ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6452 - Release Date: 06/30/13 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13 --_000_56FB15AFE08E1242B0736CBDCE6E85610809239Dstntexmb12cisne_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Noel,

 <= /p>

I mentioned in my message= to Janet on 7/2:

 <= /p>

= For the rate control, the server could calculate the arrival rate from each= communicating client so that it could allocate the overall target SIP request rate to the clients based on their arrival rates known = to the server.  But another option is for the client to “optiona= lly” include its calculated arrival rate in its request to the server= when rate control related parameters are present.  Should this option be evaluated/included to relieve the server from = doing the arrival rate calculations.  This would be beneficial to a se= rver when it receives the requests from many clients.

 <= /p>

I suggest that the I-D ad= ds that option to allow the client to indicate its current arrival rate (to= wards the receiving server) in the SIP request.

 <= /p>

James

 <= /p>

From: NOEL, ER= IC C (ERIC C) [mailto:ecnoel@research.att.com]
Sent: Tuesday, July 09, 2013 4:44 PM
To: Yu, James; Janet P Gunn
Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-cont= rol.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt

 

Janet, James,<= /span>

 <= /p>

Thanks you for your valua= ble comments and discussion.  I tried to capture all resolution in the= following text (based on James word document with track changes and imbedded comments enabled).

 <= /p>

+ Abstract section:

- Agreed with suggested c= hanges

- Please note I will also= need to make further changes to remove all references per Christer Holmber= g comment

 <= /p>

+ Section 1:

- Agreed with suggested c= hanges

 <= /p>

+ Section 3.1:

- Agreed with suggested c= hanges

 

+ Section 3.2: - Plea= se note the section title will become “Via header field parameters fo= r overload control “ per Christer Holmberg comment<= /p>

- Agreed with suggested c= hanges excluding title that will change per previous bullet

 <= /p>

+ Section 3.3:

- Agreed with suggested c= hanges

 <= /p>

+ Section 3.4:

- ID:  "Note th= at the target SIP request rate is a max rate that may not be attained by th= e arrival rate at the client, and the server cannot assume that it will."

   [JY] No= t clear what value this paragraph tries to add.  Is it saying that the= client's arrival rate may be lower than the target SIP request rate?

   [JG] Ye= s + supporting example (see below in thread)

  Agreed with J= anet and supporting example. Per James request, I will add the following te= xt (inspired from Janet’s illustrative example):

   “In ot= her words, when multiple clients are being controlled by an overloaded serv= er, at any given time some clients may receive requests at a rate below its target SIP request rate while others above that target rate. But the r= esulting request rate presented to the overloaded server will converge towa= rds the target SIP request rate.”

- Agreed with other sugge= sted changes

    &= nbsp;

+ Section 3.5.1:=

- ID: “And the larg= er the difference between TAU1 and TAU2, the closer to the control is to st= rict priority.”

  [JY] Suggest chang= ing into “And the larger the difference between TAU1 and TAU2, the cl= oser the control is to strict priority queuing.”

  [JG] Suggest chang= ing into “And the larger the difference between TAU1 and TAU2, the cl= oser the control is to strict priority treatment.”<= /p>

  [EN] Agreed with J= anet’s suggestion

- Agreed with other sugge= sted changes

 <= /p>

+ Section 4:

- Agreed with suggested c= hanges

 <= /p>

+ Section 5:

- Please note that based = comments from per Christer Holmberg and Janet Gunn, the following was tenta= tively agreed

   Replace= oc-value =3D "NaN" / oc-num    by   &nb= sp;oc =3D "oc" [EQUAL oc-num]

- Agreed with other sugge= sted change

 <= /p>

+ Section 7:

- [JY] Should “rate= ” in oc-algo be registered with IANA?

  This issue needs t= o be addressed by draft-ietf-soc-overload-control authors=

 <= /p>

Please note I will wait u= ntil expiration of WGLC prior updating our draft RFC. Once again your comme= nts and/or suggestions are most appreciated.

 <= /p>

Thanks,=

 <= /p>

Eric Noel

AT&T Labs, Inc.
Rethink Possible<= /p>

 

Network Design and Perform= ance Analysis
200 South Laurel Avenue, D5-3D19
Middletown, NJ 07748
P: 732.420.4174

ecnoel@att.com

 <= /p>

From: sip-overload-bounces@ietf.= org [mailto:sip-overlo= ad-bounces@ietf.org] On Behalf Of Yu, James
Sent: Tuesday, July 02, 2013 9:42 AM
To: Janet P Gunn
Cc: sip-overload-bo= unces@ietf.org; = draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt

 

Janet,<= /p>

 <= /p>

For my comment on section= 3.4 (the first one below), the current text does not provide any value.&nb= sp; The client’s arrival rate could be well below the target SIP request rate when its load is light so the fact that the client may no= t achieve the target SIP request rate (the max. rate it is allowed to send = to the server) is well understood.  But with your explanation on the &= #8220;delta” part, the text then makes sense.  Please add some discussions on the “delta” aspect so that even= if the average arrival rate at the client is higher than the target SIP re= quest rate the client at times may not send more than what the target SIP r= equest rate allows due to the fluctuation of the arriving requests at the client.

 <= /p>

For the comment on sectio= n 3.5.1, I agree with your proposed change.

 <= /p>

For the rate control, the= server could calculate the arrival rate from each communicating client so = that it could allocate the overall target SIP request rate to the clients based on their arrival rates known to the server.  But= another option is for the client to “optionally” include its c= alculated arrival rate in its request to the server when rate control relat= ed parameters are present.  Should this option be evaluated/included to relieve the server from doing the arrival rate calcu= lations.  This would be beneficial to a server when it receives the re= quests from many clients.

 <= /p>

James

 <= /p>

From: Janet P = Gunn [mailto:jgunn6@csc.com]
Sent: Friday, June 28, 2013 3:34 PM
To: Yu, James
Cc: draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org; sip-overload-bounces@ietf.org
Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt

 

James,

It is a little hard to respond in email when your comments are i= n a separate document, but here goes.


section 3.4
ID says:
"Note that the target SIP request rate is a max rate that m= ay not be
   attained by the arrival rate at the client, and the= server cannot
   assume that it will."

Your comment :
"Not clear what value this paragraph tries to add.  Is= it saying that the client's arrival rate may be lower than the target SIP = request rate?  "

Yes.

Suppose the server want to limit the total rate of arriving SIP = messages to 100 / sec, and has 10 clients.  Each client has a high var= iance in its message rate, but together they are well above 100 messages per sec

If it sets the rate at 10 messages per second for each of the cl= ients, it will almost certainly end up  with an overall average of les= s than 100 messages per sec, because some clients will be in a "lull" while others are busy.  This is good from a thrott= ling perspective, but, assuming messages are correlated with revenue, bad/w= asteful from a revenue, or overall productivity perspective.  So the s= erver might want to set the rate per client to 10 + delta, where delta is going to be very specific to operating environment.<= /span>

---
In section  3.5.1, bottom of page 8
ID says:
"And the larger
   the difference between TAU1 and TAU2, the closer to= the control is
   to strict priority."

You propose changing it to:
"And the larger
   the difference between TAU1 and TAU2, the closer &n= bsp;the control is
   to strict priority queuing."

I agree with taking out the redundant "to".  But = I disagree wit adding "queuing".  There is no queuing, prior= ity or otherwise involved.

You could say:
"And the larger
   the difference between TAU1 and TAU2, the closer &n= bsp;the control is
   to strict priority treatment."

where " strict priority treatment" would refer to the = case where non-priority messages are restricted to a total (priority + = non-priority) rate of 10 messages per second, but priority messages can continue to be sent as long as the total (priority + non-priority)= rate is less than 12 messages per second.

At least, I think that is what Eric and  Philip are trying = to say.

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 agreement or government initiative exp= ressly permitting the use of e-mail for such purpose.



From:        &= quot;Yu, James" <james.yu@n= eustar.biz>
To:        &= quot;sip-overload-bounces@= ietf.org" <sip= -overload-bounces@ietf.org>, "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" &l= t;draft-ietf-soc-overload-rate-control.all@tools.ietf.org>, "sip-overload@ietf.org&q= uot; <sip-overload@ietf.org= >
Date:        0= 6/28/2013 08:10 AM
Subject:        [sip-overload] draft-ietf-soc-overload-rate-control-04.txt
Sent by:        sip-overload-bounces@iet= f.org




Salvatore,
 
Please see the attachment for my comments.
 
I pasted the text to a word document to trace/show the propose= d changes and comments.
 
Regards,
 
James
 [attachment "comments on draft-ietf-soc-overload-ra= te-control-04.docx" deleted by Janet P Gunn/USA/CSC] _______________________________= ________________
sip-overload mailing list
sip-overload@ietf.org=
<= span style=3D"font-size:10.0pt">https://www.ietf.org/mailman/listinfo/sip-o= verload

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 3204/6452 - Release Date: 06/30/13

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13

--_000_56FB15AFE08E1242B0736CBDCE6E85610809239Dstntexmb12cisne_-- From jgunn6@csc.com Wed Jul 10 07:11:52 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 9ED6521F9E7B; Wed, 10 Jul 2013 07:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9YJZBqoS5jj; Wed, 10 Jul 2013 07:11:48 -0700 (PDT) Received: from mail85.messagelabs.com (mail85.messagelabs.com [216.82.241.211]) by ietfa.amsl.com (Postfix) with ESMTP id 42BC421F9D98; Wed, 10 Jul 2013 07:11:46 -0700 (PDT) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-10.tower-85.messagelabs.com!1373465500!3107085!1 X-Originating-IP: [20.137.2.87] X-StarScan-Received: X-StarScan-Version: 6.9.9; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12136 invoked from network); 10 Jul 2013 14:11:41 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-10.tower-85.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Jul 2013 14:11:41 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (8.13.8/8.13.8) with ESMTP id r6AEAOKJ021912; Wed, 10 Jul 2013 10:10:25 -0400 In-Reply-To: <56FB15AFE08E1242B0736CBDCE6E85610809239D@stntexmb12.cis.neustar.com> References: <56FB15AFE08E1242B0736CBDCE6E85610808C32F@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610808EF90@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353BDA4CAD4@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E85610809239D@stntexmb12.cis.neustar.com> To: "Yu, James" MIME-Version: 1.0 X-KeepSent: 0B974183:5C9FA6AA-85257BA4:004CB1AD; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Wed, 10 Jul 2013 10:11:36 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 07/10/2013 10:05:23 AM, Serialize complete at 07/10/2013 10:05:23 AM Content-Type: multipart/alternative; boundary="=_alternative 004DFC1D85257BA4_=" Cc: "sip-overload-bounces@ietf.org" , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" , "sip-overload@ietf.org" Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.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, 10 Jul 2013 14:11:52 -0000 This is a multipart message in MIME format. --=_alternative 004DFC1D85257BA4_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SSB0aG91Z2h0IEkgdW5kZXJzdG9vZCB0aGF0IHRoZSBwb2ludCBvZiB0aGlzIHJhdGUgYmFzZWQg YWxnb3JpdGhtIElEICB3YXMgDQp0byAicGlnZ3kgYmFjayIgb24gdGhlIGNvbW11bmljYXRpb25z ICBwcm90b2NvbCBwYXJhbWV0ZXJzIGRlZmluZWQgaW4gdGhlIA0KbG9zcyBiYXNlZCBhbGdvcml0 aG0gSUQgKG9jLCBvYy1hbGdvLCBvYy1udW0sIG9jLXZhbGlkaXR5LCBvYy1zZXEpLCANCmludHJv ZHVjaW5nIG5ldyBwYXJhbWV0ZXIgVkFMVUVTLCBidXQgbm90IG5ldyBwYXJhbWV0ZXJzLg0KDQpJ biBvcmRlciB0byBjb252ZXkgdGhlICJjdXJyZW50IGFycml2YWwgcmF0ZSBvZiBtZXNzYWdlcyBp bnRlbmRlZCBmb3IgeW91IiANCmZyb20gdGhlIGNsaWVudCB0byB0aGUgc2VydmVyLCB5b3Ugd291 bGQgbmVlZCB0byBhZGQgbmV3IHBhcmFtZXRlcnMsICBvciANCnVzZSBleGlzdGluZyBwYXJhbWV0 ZXJzIGluIGEgd2F5IHRoYXQgd291bGQgY2F1c2UgcHJvYmxlbXMgZm9yICB0aGUgbG9zcyANCmJh c2VkIHZlcnNpb24uDQoNCkZ1cnRoZXJtb3JlLCB3aGVuIHRoZSBjbGllbnQgaXMgcmVjZWl2aW5n LCBhbmQgdGhlcmVmb3JlIHNlbmRpbmcsIG1lc3NhZ2VkIA0KaW50ZW5kZWQgZm9yIHRoaXMgc2Vy dmVyLCBhdCBhIHJhdGUgbG93ZXIgdGhhbiB0aGUgY3VycmVudCBzcGVjaWZpZWQgcmF0ZSANCmxp bWl0LCB0aGUgc2VydmVyIGNhbiBkZWR1Y2UgdGhhdCBkaXJlY3RseSwgYW5kIGFkanVzdCB0aGUg c3BlY2lmaWMgcmF0ZSANCmxpbWl0IGl0IHNlbmRzIHRvICh0aGlzIG9yIG90aGVyKSBjbGllbnRz IGlmIGl0IHdhbnRzIHRvLg0KDQpJIHRoaW5rIHRoYXQgd291bGQgYmUgbXVjaCAiY2xlYW5lciIg KGFuZCBwcm9iYWJseSBtb3JlIGVmZmVjdGl2ZSBhcyANCndlbGwpLCB0aGFuIGFkZGluZyBuZXcg cGFyYW1ldGVycywgb3IgbWFraW5nIG1ham9yIGNoYW5nZXMgdG8gdGhlIA0KY29tbXVuaWNhdGlv bnMgcHJvdG9jb2wgaW4gdGhlIGxvc3MgYmFzZWQgYWxnb3JpdGhtIElELg0KDQpKYW5ldA0KDQoN Cg0Kc2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmcgd3JvdGUgb24gMDcvMTAvMjAxMyAwOTow MDozNSBBTToNCg0KPiBGcm9tOiAiWXUsIEphbWVzIiA8amFtZXMueXVAbmV1c3Rhci5iaXo+DQo+ IFRvOiAiTk9FTCwgRVJJQyBDIChFUklDIEMpIiA8ZWNub2VsQHJlc2VhcmNoLmF0dC5jb20+DQo+ IENjOiAic2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmciIDxzaXAtb3ZlcmxvYWQtYm91bmNl c0BpZXRmLm9yZz4sDQo+ICJkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1yYXRlLWNvbnRyb2wuYWxs QHRvb2xzLmlldGYub3JnIiA8ZHJhZnQtDQo+IGlldGYtc29jLW92ZXJsb2FkLXJhdGUtY29udHJv bC5hbGxAdG9vbHMuaWV0Zi5vcmc+LCAic2lwLQ0KPiBvdmVybG9hZEBpZXRmLm9yZyIgPHNpcC1v dmVybG9hZEBpZXRmLm9yZz4NCj4gRGF0ZTogMDcvMTAvMjAxMyAwOTowMSBBTQ0KPiBTdWJqZWN0 OiBSZTogW3NpcC1vdmVybG9hZF0gZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9s LTA0LnR4dA0KPiBTZW50IGJ5OiBzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZw0KPiANCj4g Tm9lbCwNCj4gDQo+IEkgbWVudGlvbmVkIGluIG15IG1lc3NhZ2UgdG8gSmFuZXQgb24gNy8yOg0K PiANCj4gRm9yIHRoZSByYXRlIGNvbnRyb2wsIHRoZSBzZXJ2ZXIgY291bGQgY2FsY3VsYXRlIHRo ZSBhcnJpdmFsIHJhdGUgDQo+IGZyb20gZWFjaCBjb21tdW5pY2F0aW5nIGNsaWVudCBzbyB0aGF0 IGl0IGNvdWxkIGFsbG9jYXRlIHRoZSBvdmVyYWxsDQo+IHRhcmdldCBTSVAgcmVxdWVzdCByYXRl IHRvIHRoZSBjbGllbnRzIGJhc2VkIG9uIHRoZWlyIGFycml2YWwgcmF0ZXMgDQo+IGtub3duIHRv IHRoZSBzZXJ2ZXIuICBCdXQgYW5vdGhlciBvcHRpb24gaXMgZm9yIHRoZSBjbGllbnQgdG8gDQo+ IOKAnG9wdGlvbmFsbHnigJ0gaW5jbHVkZSBpdHMgY2FsY3VsYXRlZCBhcnJpdmFsIHJhdGUgaW4g aXRzIHJlcXVlc3QgdG8gDQo+IHRoZSBzZXJ2ZXIgd2hlbiByYXRlIGNvbnRyb2wgcmVsYXRlZCBw YXJhbWV0ZXJzIGFyZSBwcmVzZW50LiAgU2hvdWxkDQo+IHRoaXMgb3B0aW9uIGJlIGV2YWx1YXRl ZC9pbmNsdWRlZCB0byByZWxpZXZlIHRoZSBzZXJ2ZXIgZnJvbSBkb2luZyANCj4gdGhlIGFycml2 YWwgcmF0ZSBjYWxjdWxhdGlvbnMuICBUaGlzIHdvdWxkIGJlIGJlbmVmaWNpYWwgdG8gYSBzZXJ2 ZXINCj4gd2hlbiBpdCByZWNlaXZlcyB0aGUgcmVxdWVzdHMgZnJvbSBtYW55IGNsaWVudHMuDQo+ IA0KPiBJIHN1Z2dlc3QgdGhhdCB0aGUgSS1EIGFkZHMgdGhhdCBvcHRpb24gdG8gYWxsb3cgdGhl IGNsaWVudCB0byANCj4gaW5kaWNhdGUgaXRzIGN1cnJlbnQgYXJyaXZhbCByYXRlICh0b3dhcmRz IHRoZSByZWNlaXZpbmcgc2VydmVyKSBpbiANCj4gdGhlIFNJUCByZXF1ZXN0Lg0KPiANCj4gSmFt ZXMNCj4gDQo+IEZyb206IE5PRUwsIEVSSUMgQyAoRVJJQyBDKSBbbWFpbHRvOmVjbm9lbEByZXNl YXJjaC5hdHQuY29tXSANCj4gU2VudDogVHVlc2RheSwgSnVseSAwOSwgMjAxMyA0OjQ0IFBNDQo+ IFRvOiBZdSwgSmFtZXM7IEphbmV0IFAgR3Vubg0KPiBDYzogc2lwLW92ZXJsb2FkLWJvdW5jZXNA aWV0Zi5vcmc7IGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLXJhdGUtDQo+IGNvbnRyb2wuYWxsQHRv b2xzLmlldGYub3JnOyBzaXAtb3ZlcmxvYWRAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFtzaXAt b3ZlcmxvYWRdIGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLXJhdGUtY29udHJvbC0wNC50eHQNCj4g DQo+IEphbmV0LCBKYW1lcywNCj4gDQo+IFRoYW5rcyB5b3UgZm9yIHlvdXIgdmFsdWFibGUgY29t bWVudHMgYW5kIGRpc2N1c3Npb24uICBJIHRyaWVkIHRvIA0KPiBjYXB0dXJlIGFsbCByZXNvbHV0 aW9uIGluIHRoZSBmb2xsb3dpbmcgdGV4dCAoYmFzZWQgb24gSmFtZXMgd29yZCANCj4gZG9jdW1l bnQgd2l0aCB0cmFjayBjaGFuZ2VzIGFuZCBpbWJlZGRlZCBjb21tZW50cyBlbmFibGVkKS4NCj4g DQo+ICsgQWJzdHJhY3Qgc2VjdGlvbjogDQo+IC0gQWdyZWVkIHdpdGggc3VnZ2VzdGVkIGNoYW5n ZXMNCj4gLSBQbGVhc2Ugbm90ZSBJIHdpbGwgYWxzbyBuZWVkIHRvIG1ha2UgZnVydGhlciBjaGFu Z2VzIHRvIHJlbW92ZSBhbGwNCj4gcmVmZXJlbmNlcyBwZXIgQ2hyaXN0ZXIgSG9sbWJlcmcgY29t bWVudA0KPiANCj4gKyBTZWN0aW9uIDE6DQo+IC0gQWdyZWVkIHdpdGggc3VnZ2VzdGVkIGNoYW5n ZXMNCj4gDQo+ICsgU2VjdGlvbiAzLjE6DQo+IC0gQWdyZWVkIHdpdGggc3VnZ2VzdGVkIGNoYW5n ZXMNCj4gDQo+ICsgU2VjdGlvbiAzLjI6IC0gUGxlYXNlIG5vdGUgdGhlIHNlY3Rpb24gdGl0bGUg d2lsbCBiZWNvbWUg4oCcVmlhIA0KPiBoZWFkZXIgZmllbGQgcGFyYW1ldGVycyBmb3Igb3Zlcmxv YWQgY29udHJvbCDigJwgcGVyIENocmlzdGVyIEhvbG1iZXJnIA0KY29tbWVudA0KPiAtIEFncmVl ZCB3aXRoIHN1Z2dlc3RlZCBjaGFuZ2VzIGV4Y2x1ZGluZyB0aXRsZSB0aGF0IHdpbGwgY2hhbmdl IHBlcg0KPiBwcmV2aW91cyBidWxsZXQNCj4gDQo+ICsgU2VjdGlvbiAzLjM6DQo+IC0gQWdyZWVk IHdpdGggc3VnZ2VzdGVkIGNoYW5nZXMNCj4gDQo+ICsgU2VjdGlvbiAzLjQ6DQo+IC0gSUQ6ICAi Tm90ZSB0aGF0IHRoZSB0YXJnZXQgU0lQIHJlcXVlc3QgcmF0ZSBpcyBhIG1heCByYXRlIHRoYXQg bWF5DQo+IG5vdCBiZSBhdHRhaW5lZCBieSB0aGUgYXJyaXZhbCByYXRlIGF0IHRoZSBjbGllbnQs IGFuZCB0aGUgc2VydmVyIA0KPiBjYW5ub3QgYXNzdW1lIHRoYXQgaXQgd2lsbC4iIA0KPiAgICBb SlldIE5vdCBjbGVhciB3aGF0IHZhbHVlIHRoaXMgcGFyYWdyYXBoIHRyaWVzIHRvIGFkZC4gIElz IGl0IA0KPiBzYXlpbmcgdGhhdCB0aGUgY2xpZW50J3MgYXJyaXZhbCByYXRlIG1heSBiZSBsb3dl ciB0aGFuIHRoZSB0YXJnZXQgDQo+IFNJUCByZXF1ZXN0IHJhdGU/IA0KPiAgICBbSkddIFllcyAr IHN1cHBvcnRpbmcgZXhhbXBsZSAoc2VlIGJlbG93IGluIHRocmVhZCkNCj4gICBBZ3JlZWQgd2l0 aCBKYW5ldCBhbmQgc3VwcG9ydGluZyBleGFtcGxlLiBQZXIgSmFtZXMgcmVxdWVzdCwgSSANCj4g d2lsbCBhZGQgdGhlIGZvbGxvd2luZyB0ZXh0IChpbnNwaXJlZCBmcm9tIEphbmV04oCZcyBpbGx1 c3RyYXRpdmUgDQpleGFtcGxlKToNCj4gICAg4oCcSW4gb3RoZXIgd29yZHMsIHdoZW4gbXVsdGlw bGUgY2xpZW50cyBhcmUgYmVpbmcgY29udHJvbGxlZCBieSBhbg0KPiBvdmVybG9hZGVkIHNlcnZl ciwgYXQgYW55IGdpdmVuIHRpbWUgc29tZSBjbGllbnRzIG1heSByZWNlaXZlIA0KPiByZXF1ZXN0 cyBhdCBhIHJhdGUgYmVsb3cgaXRzIHRhcmdldCBTSVAgcmVxdWVzdCByYXRlIHdoaWxlIG90aGVy cyANCj4gYWJvdmUgdGhhdCB0YXJnZXQgcmF0ZS4gQnV0IHRoZSByZXN1bHRpbmcgcmVxdWVzdCBy YXRlIHByZXNlbnRlZCB0byANCj4gdGhlIG92ZXJsb2FkZWQgc2VydmVyIHdpbGwgY29udmVyZ2Ug dG93YXJkcyB0aGUgdGFyZ2V0IFNJUCByZXF1ZXN0IA0KcmF0ZS7igJ0NCj4gLSBBZ3JlZWQgd2l0 aCBvdGhlciBzdWdnZXN0ZWQgY2hhbmdlcyANCj4gDQo+ICsgU2VjdGlvbiAzLjUuMToNCj4gLSBJ RDog4oCcQW5kIHRoZSBsYXJnZXIgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBUQVUxIGFuZCBUQVUy LCB0aGUgDQo+IGNsb3NlciB0byB0aGUgY29udHJvbCBpcyB0byBzdHJpY3QgcHJpb3JpdHku4oCd DQo+ICAgW0pZXSBTdWdnZXN0IGNoYW5naW5nIGludG8g4oCcQW5kIHRoZSBsYXJnZXIgdGhlIGRp ZmZlcmVuY2UgYmV0d2VlbiANCj4gVEFVMSBhbmQgVEFVMiwgdGhlIGNsb3NlciB0aGUgY29udHJv bCBpcyB0byBzdHJpY3QgcHJpb3JpdHkgcXVldWluZy7igJ0NCj4gICBbSkddIFN1Z2dlc3QgY2hh bmdpbmcgaW50byDigJxBbmQgdGhlIGxhcmdlciB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIA0KPiBU QVUxIGFuZCBUQVUyLCB0aGUgY2xvc2VyIHRoZSBjb250cm9sIGlzIHRvIHN0cmljdCBwcmlvcml0 eSB0cmVhdG1lbnQu4oCdDQo+ICAgW0VOXSBBZ3JlZWQgd2l0aCBKYW5ldOKAmXMgc3VnZ2VzdGlv bg0KPiAtIEFncmVlZCB3aXRoIG90aGVyIHN1Z2dlc3RlZCBjaGFuZ2VzDQo+IA0KPiArIFNlY3Rp b24gNDoNCj4gLSBBZ3JlZWQgd2l0aCBzdWdnZXN0ZWQgY2hhbmdlcw0KPiANCj4gKyBTZWN0aW9u IDU6DQo+IC0gUGxlYXNlIG5vdGUgdGhhdCBiYXNlZCBjb21tZW50cyBmcm9tIHBlciBDaHJpc3Rl ciBIb2xtYmVyZyBhbmQgDQo+IEphbmV0IEd1bm4sIHRoZSBmb2xsb3dpbmcgd2FzIHRlbnRhdGl2 ZWx5IGFncmVlZCANCj4gICAgUmVwbGFjZSBvYy12YWx1ZSA9ICJOYU4iIC8gb2MtbnVtICAgIGJ5 ICAgIG9jID0gIm9jIiBbRVFVQUwgb2MtbnVtXQ0KPiAtIEFncmVlZCB3aXRoIG90aGVyIHN1Z2dl c3RlZCBjaGFuZ2UNCj4gDQo+ICsgU2VjdGlvbiA3Og0KPiAtIFtKWV0gU2hvdWxkIOKAnHJhdGXi gJ0gaW4gb2MtYWxnbyBiZSByZWdpc3RlcmVkIHdpdGggSUFOQT8NCj4gICBUaGlzIGlzc3VlIG5l ZWRzIHRvIGJlIGFkZHJlc3NlZCBieSBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1jb250cm9sIA0K YXV0aG9ycw0KPiANCj4gUGxlYXNlIG5vdGUgSSB3aWxsIHdhaXQgdW50aWwgZXhwaXJhdGlvbiBv ZiBXR0xDIHByaW9yIHVwZGF0aW5nIG91ciANCj4gZHJhZnQgUkZDLiBPbmNlIGFnYWluIHlvdXIg Y29tbWVudHMgYW5kL29yIHN1Z2dlc3Rpb25zIGFyZSBtb3N0IA0KYXBwcmVjaWF0ZWQuDQo+IA0K PiBUaGFua3MsDQo+IA0KPiBFcmljIE5vZWwgDQo+IEFUJlQgTGFicywgSW5jLiANCj4gUmV0aGlu ayBQb3NzaWJsZQ0KPiANCj4gTmV0d29yayBEZXNpZ24gYW5kIFBlcmZvcm1hbmNlIEFuYWx5c2lz DQo+IDIwMCBTb3V0aCBMYXVyZWwgQXZlbnVlLCBENS0zRDE5DQo+IE1pZGRsZXRvd24sIE5KIDA3 NzQ4DQo+IFA6IDczMi40MjAuNDE3NA0KPiBlY25vZWxAYXR0LmNvbQ0KPiANCj4gRnJvbTogc2lw LW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmcgWw0KbWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2Vz QGlldGYub3JnXSANCj4gT24gQmVoYWxmIE9mIFl1LCBKYW1lcw0KPiBTZW50OiBUdWVzZGF5LCBK dWx5IDAyLCAyMDEzIDk6NDIgQU0NCj4gVG86IEphbmV0IFAgR3Vubg0KPiBDYzogc2lwLW92ZXJs b2FkLWJvdW5jZXNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLXJhdGUtDQo+IGNv bnRyb2wuYWxsQHRvb2xzLmlldGYub3JnOyBzaXAtb3ZlcmxvYWRAaWV0Zi5vcmcNCj4gU3ViamVj dDogUmU6IFtzaXAtb3ZlcmxvYWRdIGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLXJhdGUtY29udHJv bC0wNC50eHQNCj4gDQo+IEphbmV0LA0KPiANCj4gRm9yIG15IGNvbW1lbnQgb24gc2VjdGlvbiAz LjQgKHRoZSBmaXJzdCBvbmUgYmVsb3cpLCB0aGUgY3VycmVudCANCj4gdGV4dCBkb2VzIG5vdCBw cm92aWRlIGFueSB2YWx1ZS4gIFRoZSBjbGllbnTigJlzIGFycml2YWwgcmF0ZSBjb3VsZCBiZQ0K PiB3ZWxsIGJlbG93IHRoZSB0YXJnZXQgU0lQIHJlcXVlc3QgcmF0ZSB3aGVuIGl0cyBsb2FkIGlz IGxpZ2h0IHNvIHRoZQ0KPiBmYWN0IHRoYXQgdGhlIGNsaWVudCBtYXkgbm90IGFjaGlldmUgdGhl IHRhcmdldCBTSVAgcmVxdWVzdCByYXRlIA0KPiAodGhlIG1heC4gcmF0ZSBpdCBpcyBhbGxvd2Vk IHRvIHNlbmQgdG8gdGhlIHNlcnZlcikgaXMgd2VsbCANCj4gdW5kZXJzdG9vZC4gIEJ1dCB3aXRo IHlvdXIgZXhwbGFuYXRpb24gb24gdGhlIOKAnGRlbHRh4oCdIHBhcnQsIHRoZSB0ZXh0DQo+IHRo ZW4gbWFrZXMgc2Vuc2UuICBQbGVhc2UgYWRkIHNvbWUgZGlzY3Vzc2lvbnMgb24gdGhlIOKAnGRl bHRh4oCdIGFzcGVjdA0KPiBzbyB0aGF0IGV2ZW4gaWYgdGhlIGF2ZXJhZ2UgYXJyaXZhbCByYXRl IGF0IHRoZSBjbGllbnQgaXMgaGlnaGVyIA0KPiB0aGFuIHRoZSB0YXJnZXQgU0lQIHJlcXVlc3Qg cmF0ZSB0aGUgY2xpZW50IGF0IHRpbWVzIG1heSBub3Qgc2VuZCANCj4gbW9yZSB0aGFuIHdoYXQg dGhlIHRhcmdldCBTSVAgcmVxdWVzdCByYXRlIGFsbG93cyBkdWUgdG8gdGhlIA0KPiBmbHVjdHVh dGlvbiBvZiB0aGUgYXJyaXZpbmcgcmVxdWVzdHMgYXQgdGhlIGNsaWVudC4NCj4gDQo+IEZvciB0 aGUgY29tbWVudCBvbiBzZWN0aW9uIDMuNS4xLCBJIGFncmVlIHdpdGggeW91ciBwcm9wb3NlZCBj aGFuZ2UuDQo+IA0KPiBGb3IgdGhlIHJhdGUgY29udHJvbCwgdGhlIHNlcnZlciBjb3VsZCBjYWxj dWxhdGUgdGhlIGFycml2YWwgcmF0ZSANCj4gZnJvbSBlYWNoIGNvbW11bmljYXRpbmcgY2xpZW50 IHNvIHRoYXQgaXQgY291bGQgYWxsb2NhdGUgdGhlIG92ZXJhbGwNCj4gdGFyZ2V0IFNJUCByZXF1 ZXN0IHJhdGUgdG8gdGhlIGNsaWVudHMgYmFzZWQgb24gdGhlaXIgYXJyaXZhbCByYXRlcyANCj4g a25vd24gdG8gdGhlIHNlcnZlci4gIEJ1dCBhbm90aGVyIG9wdGlvbiBpcyBmb3IgdGhlIGNsaWVu dCB0byANCj4g4oCcb3B0aW9uYWxseeKAnSBpbmNsdWRlIGl0cyBjYWxjdWxhdGVkIGFycml2YWwg cmF0ZSBpbiBpdHMgcmVxdWVzdCB0byANCj4gdGhlIHNlcnZlciB3aGVuIHJhdGUgY29udHJvbCBy ZWxhdGVkIHBhcmFtZXRlcnMgYXJlIHByZXNlbnQuICBTaG91bGQNCj4gdGhpcyBvcHRpb24gYmUg ZXZhbHVhdGVkL2luY2x1ZGVkIHRvIHJlbGlldmUgdGhlIHNlcnZlciBmcm9tIGRvaW5nIA0KPiB0 aGUgYXJyaXZhbCByYXRlIGNhbGN1bGF0aW9ucy4gIFRoaXMgd291bGQgYmUgYmVuZWZpY2lhbCB0 byBhIHNlcnZlcg0KPiB3aGVuIGl0IHJlY2VpdmVzIHRoZSByZXF1ZXN0cyBmcm9tIG1hbnkgY2xp ZW50cy4NCj4gDQo+IEphbWVzDQo+IA0KPiBGcm9tOiBKYW5ldCBQIEd1bm4gW21haWx0bzpqZ3Vu bjZAY3NjLmNvbV0gDQo+IFNlbnQ6IEZyaWRheSwgSnVuZSAyOCwgMjAxMyAzOjM0IFBNDQo+IFRv OiBZdSwgSmFtZXMNCj4gQ2M6IGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLXJhdGUtY29udHJvbC5h bGxAdG9vbHMuaWV0Zi5vcmc7IHNpcC0NCj4gb3ZlcmxvYWRAaWV0Zi5vcmc7IHNpcC1vdmVybG9h ZC1ib3VuY2VzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbc2lwLW92ZXJsb2FkXSBkcmFmdC1p ZXRmLXNvYy1vdmVybG9hZC1yYXRlLWNvbnRyb2wtMDQudHh0DQo+IA0KPiBKYW1lcywgDQo+IA0K PiBJdCBpcyBhIGxpdHRsZSBoYXJkIHRvIHJlc3BvbmQgaW4gZW1haWwgd2hlbiB5b3VyIGNvbW1l bnRzIGFyZSBpbiBhIA0KPiBzZXBhcmF0ZSBkb2N1bWVudCwgYnV0IGhlcmUgZ29lcy4gDQo+IA0K PiANCj4gc2VjdGlvbiAzLjQgDQo+IElEIHNheXM6IA0KPiAiTm90ZSB0aGF0IHRoZSB0YXJnZXQg U0lQIHJlcXVlc3QgcmF0ZSBpcyBhIG1heCByYXRlIHRoYXQgbWF5IG5vdCBiZSANCj4gICAgYXR0 YWluZWQgYnkgdGhlIGFycml2YWwgcmF0ZSBhdCB0aGUgY2xpZW50LCBhbmQgdGhlIHNlcnZlciBj YW5ub3QgDQo+ICAgIGFzc3VtZSB0aGF0IGl0IHdpbGwuIiANCj4gDQo+IFlvdXIgY29tbWVudCA6 IA0KPiAiTm90IGNsZWFyIHdoYXQgdmFsdWUgdGhpcyBwYXJhZ3JhcGggdHJpZXMgdG8gYWRkLiAg SXMgaXQgc2F5aW5nIA0KPiB0aGF0IHRoZSBjbGllbnQncyBhcnJpdmFsIHJhdGUgbWF5IGJlIGxv d2VyIHRoYW4gdGhlIHRhcmdldCBTSVAgDQo+IHJlcXVlc3QgcmF0ZT8gICIgDQo+IA0KPiBZZXMu IA0KPiANCj4gU3VwcG9zZSB0aGUgc2VydmVyIHdhbnQgdG8gbGltaXQgdGhlIHRvdGFsIHJhdGUg b2YgYXJyaXZpbmcgU0lQIA0KPiBtZXNzYWdlcyB0byAxMDAgLyBzZWMsIGFuZCBoYXMgMTAgY2xp ZW50cy4gIEVhY2ggY2xpZW50IGhhcyBhIGhpZ2ggDQo+IHZhcmlhbmNlIGluIGl0cyBtZXNzYWdl IHJhdGUsIGJ1dCB0b2dldGhlciB0aGV5IGFyZSB3ZWxsIGFib3ZlIDEwMCANCj4gbWVzc2FnZXMg cGVyIHNlYyANCj4gDQo+IElmIGl0IHNldHMgdGhlIHJhdGUgYXQgMTAgbWVzc2FnZXMgcGVyIHNl Y29uZCBmb3IgZWFjaCBvZiB0aGUgDQo+IGNsaWVudHMsIGl0IHdpbGwgYWxtb3N0IGNlcnRhaW5s eSBlbmQgdXAgIHdpdGggYW4gb3ZlcmFsbCBhdmVyYWdlIG9mDQo+IGxlc3MgdGhhbiAxMDAgbWVz c2FnZXMgcGVyIHNlYywgYmVjYXVzZSBzb21lIGNsaWVudHMgd2lsbCBiZSBpbiBhIA0KPiAibHVs bCIgd2hpbGUgb3RoZXJzIGFyZSBidXN5LiAgVGhpcyBpcyBnb29kIGZyb20gYSB0aHJvdHRsaW5n IA0KPiBwZXJzcGVjdGl2ZSwgYnV0LCBhc3N1bWluZyBtZXNzYWdlcyBhcmUgY29ycmVsYXRlZCB3 aXRoIHJldmVudWUsIA0KPiBiYWQvd2FzdGVmdWwgZnJvbSBhIHJldmVudWUsIG9yIG92ZXJhbGwg cHJvZHVjdGl2aXR5IHBlcnNwZWN0aXZlLiANCj4gU28gdGhlIHNlcnZlciBtaWdodCB3YW50IHRv IHNldCB0aGUgcmF0ZSBwZXIgY2xpZW50IHRvIDEwICsgZGVsdGEsIA0KPiB3aGVyZSBkZWx0YSBp cyBnb2luZyB0byBiZSB2ZXJ5IHNwZWNpZmljIHRvIG9wZXJhdGluZyBlbnZpcm9ubWVudC4gDQo+ IA0KPiAtLS0gDQo+IEluIHNlY3Rpb24gIDMuNS4xLCBib3R0b20gb2YgcGFnZSA4IA0KPiBJRCBz YXlzOiANCj4gIkFuZCB0aGUgbGFyZ2VyIA0KPiAgICB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIFRB VTEgYW5kIFRBVTIsIHRoZSBjbG9zZXIgdG8gdGhlIGNvbnRyb2wgaXMgDQo+ICAgIHRvIHN0cmlj dCBwcmlvcml0eS4iIA0KPiANCj4gWW91IHByb3Bvc2UgY2hhbmdpbmcgaXQgdG86IA0KPiAiQW5k IHRoZSBsYXJnZXIgDQo+ICAgIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gVEFVMSBhbmQgVEFVMiwg dGhlIGNsb3NlciAgdGhlIGNvbnRyb2wgaXMgDQo+ICAgIHRvIHN0cmljdCBwcmlvcml0eSBxdWV1 aW5nLiIgDQo+IA0KPiBJIGFncmVlIHdpdGggdGFraW5nIG91dCB0aGUgcmVkdW5kYW50ICJ0byIu ICBCdXQgSSBkaXNhZ3JlZSB3aXQgDQo+IGFkZGluZyAicXVldWluZyIuICBUaGVyZSBpcyBubyBx dWV1aW5nLCBwcmlvcml0eSBvciBvdGhlcndpc2UgaW52b2x2ZWQuIA0KPiANCj4gWW91IGNvdWxk IHNheTogDQo+ICJBbmQgdGhlIGxhcmdlciANCj4gICAgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBU QVUxIGFuZCBUQVUyLCB0aGUgY2xvc2VyICB0aGUgY29udHJvbCBpcyANCj4gICAgdG8gc3RyaWN0 IHByaW9yaXR5IHRyZWF0bWVudC4iIA0KPiANCj4gd2hlcmUgIiBzdHJpY3QgcHJpb3JpdHkgdHJl YXRtZW50IiB3b3VsZCByZWZlciB0byB0aGUgY2FzZSB3aGVyZSANCj4gbm9uLXByaW9yaXR5IG1l c3NhZ2VzIGFyZSByZXN0cmljdGVkIHRvIGEgdG90YWwgKHByaW9yaXR5ICsgbm9uLQ0KPiBwcmlv cml0eSkgcmF0ZSBvZiAxMCBtZXNzYWdlcyBwZXIgc2Vjb25kLCBidXQgcHJpb3JpdHkgbWVzc2Fn ZXMgY2FuIA0KPiBjb250aW51ZSB0byBiZSBzZW50IGFzIGxvbmcgYXMgdGhlIHRvdGFsIChwcmlv cml0eSArIG5vbi1wcmlvcml0eSkgDQo+IHJhdGUgaXMgbGVzcyB0aGFuIDEyIG1lc3NhZ2VzIHBl ciBzZWNvbmQuIA0KPiANCj4gQXQgbGVhc3QsIEkgdGhpbmsgdGhhdCBpcyB3aGF0IEVyaWMgYW5k ICBQaGlsaXAgYXJlIHRyeWluZyB0byBzYXkuIA0KPiANCj4gSmFuZXQgDQo+IA0KPiANCj4gDQo+ IA0KPiANCj4gVGhpcyBpcyBhIFBSSVZBVEUgbWVzc2FnZS4gSWYgeW91IGFyZSBub3QgdGhlIGlu dGVuZGVkIHJlY2lwaWVudCwgDQo+IHBsZWFzZSBkZWxldGUgd2l0aG91dCBjb3B5aW5nIGFuZCBr aW5kbHkgYWR2aXNlIHVzIGJ5IGUtbWFpbCBvZiB0aGUgDQo+IG1pc3Rha2UgaW4gZGVsaXZlcnku IE5PVEU6IFJlZ2FyZGxlc3Mgb2YgY29udGVudCwgdGhpcyBlLW1haWwgc2hhbGwgDQo+IG5vdCBv cGVyYXRlIHRvIGJpbmQgQ1NDIHRvIGFueSBvcmRlciBvciBvdGhlciBjb250cmFjdCB1bmxlc3Mg DQo+IHB1cnN1YW50IHRvIGV4cGxpY2l0IHdyaXR0ZW4gYWdyZWVtZW50IG9yIGdvdmVybm1lbnQg aW5pdGlhdGl2ZSANCj4gZXhwcmVzc2x5IHBlcm1pdHRpbmcgdGhlIHVzZSBvZiBlLW1haWwgZm9y IHN1Y2ggcHVycG9zZS4gDQo+IA0KPiANCj4gDQo+IEZyb206ICAgICAgICAiWXUsIEphbWVzIiA8 amFtZXMueXVAbmV1c3Rhci5iaXo+IA0KPiBUbzogICAgICAgICJzaXAtb3ZlcmxvYWQtYm91bmNl c0BpZXRmLm9yZyIgDQo8c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc+LCAiDQo+IGRyYWZ0 LWlldGYtc29jLW92ZXJsb2FkLXJhdGUtY29udHJvbC5hbGxAdG9vbHMuaWV0Zi5vcmciIDxkcmFm dC0NCj4gaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLmFsbEB0b29scy5pZXRmLm9yZz4s IA0KInNpcC1vdmVybG9hZEBpZXRmLm9yZyIgPA0KPiBzaXAtb3ZlcmxvYWRAaWV0Zi5vcmc+IA0K PiBEYXRlOiAgICAgICAgMDYvMjgvMjAxMyAwODoxMCBBTSANCj4gU3ViamVjdDogICAgICAgIFtz aXAtb3ZlcmxvYWRdIA0KZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLTA0LnR4 dCANCj4gU2VudCBieTogICAgICAgIHNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnIA0KPiAN Cj4gDQo+IA0KPiANCj4gU2FsdmF0b3JlLCANCj4gDQo+IFBsZWFzZSBzZWUgdGhlIGF0dGFjaG1l bnQgZm9yIG15IGNvbW1lbnRzLiANCj4gDQo+IEkgcGFzdGVkIHRoZSB0ZXh0IHRvIGEgd29yZCBk b2N1bWVudCB0byB0cmFjZS9zaG93IHRoZSBwcm9wb3NlZCANCj4gY2hhbmdlcyBhbmQgY29tbWVu dHMuIA0KPiANCj4gUmVnYXJkcywgDQo+IA0KPiBKYW1lcyANCj4gIFthdHRhY2htZW50ICJjb21t ZW50cyBvbiBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1yYXRlLQ0KPiBjb250cm9sLTA0LmRvY3gi IGRlbGV0ZWQgYnkgSmFuZXQgUCBHdW5uL1VTQS9DU0NdIA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzaXAtb3ZlcmxvYWQgbWFpbGluZyBsaXN0 DQo+IHNpcC1vdmVybG9hZEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NpcC1vdmVybG9hZA0KPiANCj4gTm8gdmlydXMgZm91bmQgaW4gdGhpcyBtZXNz YWdlLg0KPiBDaGVja2VkIGJ5IEFWRyAtIHd3dy5hdmcuY29tDQo+IFZlcnNpb246IDIwMTMuMC4y OTA0IC8gVmlydXMgRGF0YWJhc2U6IDMyMDQvNjQ1MiAtIFJlbGVhc2UgRGF0ZTogDQowNi8zMC8x Mw0KPiANCj4gTm8gdmlydXMgZm91bmQgaW4gdGhpcyBtZXNzYWdlLg0KPiBDaGVja2VkIGJ5IEFW RyAtIHd3dy5hdmcuY29tDQo+IFZlcnNpb246IDIwMTMuMC4yOTA0IC8gVmlydXMgRGF0YWJhc2U6 IDMyMDQvNjQ3OCAtIFJlbGVhc2UgRGF0ZTogDQowNy8wOS8xMw0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzaXAtb3ZlcmxvYWQgbWFpbGluZyBs aXN0DQo+IHNpcC1vdmVybG9hZEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NpcC1vdmVybG9hZA0KDQo= --=_alternative 004DFC1D85257BA4_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgdGhvdWdodCBJIHVuZGVyc3Rvb2QgdGhh dCB0aGUgcG9pbnQgb2YNCnRoaXMgcmF0ZSBiYXNlZCBhbGdvcml0aG0gSUQgJm5ic3A7d2FzIHRv ICZxdW90O3BpZ2d5IGJhY2smcXVvdDsgb24gdGhlDQpjb21tdW5pY2F0aW9ucyAmbmJzcDtwcm90 b2NvbCBwYXJhbWV0ZXJzIGRlZmluZWQgaW4gdGhlIGxvc3MgYmFzZWQgYWxnb3JpdGhtDQpJRCAo b2MsIG9jLWFsZ28sIG9jLW51bSwgb2MtdmFsaWRpdHksIG9jLXNlcSksIGludHJvZHVjaW5nIG5l dyBwYXJhbWV0ZXINClZBTFVFUywgYnV0IG5vdCBuZXcgcGFyYW1ldGVycy48L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkluIG9yZGVyIHRvIGNvbnZleSB0 aGUgJnF1b3Q7Y3VycmVudA0KYXJyaXZhbCByYXRlIG9mIG1lc3NhZ2VzIGludGVuZGVkIGZvciB5 b3UmcXVvdDsgZnJvbSB0aGUgY2xpZW50IHRvIHRoZQ0Kc2VydmVyLCB5b3Ugd291bGQgbmVlZCB0 byBhZGQgbmV3IHBhcmFtZXRlcnMsICZuYnNwO29yIHVzZSBleGlzdGluZyBwYXJhbWV0ZXJzDQpp biBhIHdheSB0aGF0IHdvdWxkIGNhdXNlIHByb2JsZW1zIGZvciAmbmJzcDt0aGUgbG9zcyBiYXNl ZCB2ZXJzaW9uLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+RnVydGhlcm1vcmUsIHdoZW4gdGhlIGNsaWVudCBpcyByZWNlaXZpbmcsDQphbmQgdGhlcmVm b3JlIHNlbmRpbmcsIG1lc3NhZ2VkIGludGVuZGVkIGZvciB0aGlzIHNlcnZlciwgYXQgYSByYXRl IGxvd2VyDQp0aGFuIHRoZSBjdXJyZW50IHNwZWNpZmllZCByYXRlIGxpbWl0LCB0aGUgc2VydmVy IGNhbiBkZWR1Y2UgdGhhdCBkaXJlY3RseSwNCmFuZCBhZGp1c3QgdGhlIHNwZWNpZmljIHJhdGUg bGltaXQgaXQgc2VuZHMgdG8gKHRoaXMgb3Igb3RoZXIpIGNsaWVudHMNCmlmIGl0IHdhbnRzIHRv LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSB0aGlu ayB0aGF0IHdvdWxkIGJlIG11Y2ggJnF1b3Q7Y2xlYW5lciZxdW90Ow0KKGFuZCBwcm9iYWJseSBt b3JlIGVmZmVjdGl2ZSBhcyB3ZWxsKSwgdGhhbiBhZGRpbmcgbmV3IHBhcmFtZXRlcnMsIG9yIG1h a2luZw0KbWFqb3IgY2hhbmdlcyB0byB0aGUgY29tbXVuaWNhdGlvbnMgcHJvdG9jb2wgaW4gdGhl IGxvc3MgYmFzZWQgYWxnb3JpdGhtDQpJRC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPkphbmV0PGJyPg0KPGJyPg0KPC9mb250Pg0KPGJyPg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmcgd3JvdGUgb24gMDcv MTAvMjAxMw0KMDk6MDA6MzUgQU06PGJyPg0KPGJyPg0KJmd0OyBGcm9tOiAmcXVvdDtZdSwgSmFt ZXMmcXVvdDsgJmx0O2phbWVzLnl1QG5ldXN0YXIuYml6Jmd0OzwvZm9udD48L3R0Pg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+Jmd0OyBUbzogJnF1b3Q7Tk9FTCwgRVJJQyBDIChFUklDIEMpJnF1b3Q7 ICZsdDtlY25vZWxAcmVzZWFyY2guYXR0LmNvbSZndDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPiZndDsgQ2M6ICZxdW90O3NpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnJnF1 b3Q7DQombHQ7c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7LDxicj4NCiZndDsgJnF1 b3Q7ZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLmFsbEB0b29scy5pZXRmLm9y ZyZxdW90Ow0KJmx0O2RyYWZ0LTxicj4NCiZndDsgaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250 cm9sLmFsbEB0b29scy5pZXRmLm9yZyZndDssICZxdW90O3NpcC08YnI+DQomZ3Q7IG92ZXJsb2Fk QGlldGYub3JnJnF1b3Q7ICZsdDtzaXAtb3ZlcmxvYWRAaWV0Zi5vcmcmZ3Q7PC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IERhdGU6IDA3LzEwLzIwMTMgMDk6MDEgQU08L2Zv bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgU3ViamVjdDogUmU6IFtzaXAtb3Zl cmxvYWRdIGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLXJhdGUtY29udHJvbC0wNC50eHQ8L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgU2VudCBieTogc2lwLW92ZXJsb2FkLWJv dW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJy Pg0KJmd0OyBOb2VsLDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJz cDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgSSBtZW50aW9uZWQgaW4g bXkgbWVzc2FnZSB0byBKYW5ldCBvbiA3LzI6PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBG b3IgdGhlIHJhdGUgY29udHJvbCwgdGhlIHNlcnZlciBjb3VsZCBjYWxjdWxhdGUNCnRoZSBhcnJp dmFsIHJhdGUgPGJyPg0KJmd0OyBmcm9tIGVhY2ggY29tbXVuaWNhdGluZyBjbGllbnQgc28gdGhh dCBpdCBjb3VsZCBhbGxvY2F0ZSB0aGUgb3ZlcmFsbDxicj4NCiZndDsgdGFyZ2V0IFNJUCByZXF1 ZXN0IHJhdGUgdG8gdGhlIGNsaWVudHMgYmFzZWQgb24gdGhlaXIgYXJyaXZhbCByYXRlcw0KPGJy Pg0KJmd0OyBrbm93biB0byB0aGUgc2VydmVyLiAmbmJzcDtCdXQgYW5vdGhlciBvcHRpb24gaXMg Zm9yIHRoZSBjbGllbnQgdG8NCjxicj4NCiZndDsg4oCcb3B0aW9uYWxseeKAnSBpbmNsdWRlIGl0 cyBjYWxjdWxhdGVkIGFycml2YWwgcmF0ZSBpbiBpdHMgcmVxdWVzdA0KdG8gPGJyPg0KJmd0OyB0 aGUgc2VydmVyIHdoZW4gcmF0ZSBjb250cm9sIHJlbGF0ZWQgcGFyYW1ldGVycyBhcmUgcHJlc2Vu dC4gJm5ic3A7U2hvdWxkPGJyPg0KJmd0OyB0aGlzIG9wdGlvbiBiZSBldmFsdWF0ZWQvaW5jbHVk ZWQgdG8gcmVsaWV2ZSB0aGUgc2VydmVyIGZyb20gZG9pbmcNCjxicj4NCiZndDsgdGhlIGFycml2 YWwgcmF0ZSBjYWxjdWxhdGlvbnMuICZuYnNwO1RoaXMgd291bGQgYmUgYmVuZWZpY2lhbCB0byBh DQpzZXJ2ZXI8YnI+DQomZ3Q7IHdoZW4gaXQgcmVjZWl2ZXMgdGhlIHJlcXVlc3RzIGZyb20gbWFu eSBjbGllbnRzLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgSSBzdWdnZXN0IHRoYXQgdGhl IEktRCBhZGRzIHRoYXQgb3B0aW9uIHRvIGFsbG93DQp0aGUgY2xpZW50IHRvIDxicj4NCiZndDsg aW5kaWNhdGUgaXRzIGN1cnJlbnQgYXJyaXZhbCByYXRlICh0b3dhcmRzIHRoZSByZWNlaXZpbmcg c2VydmVyKSBpbg0KPGJyPg0KJmd0OyB0aGUgU0lQIHJlcXVlc3QuPC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+Jmd0OyBKYW1lczwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAm bmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgRnJvbTogTk9FTCwg RVJJQyBDIChFUklDIEMpIFs8L2ZvbnQ+PC90dD48YSBocmVmPW1haWx0bzplY25vZWxAcmVzZWFy Y2guYXR0LmNvbT48dHQ+PGZvbnQgc2l6ZT0yPm1haWx0bzplY25vZWxAcmVzZWFyY2guYXR0LmNv bTwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPl0NCjxicj4NCiZndDsgU2VudDogVHVl c2RheSwgSnVseSAwOSwgMjAxMyA0OjQ0IFBNPGJyPg0KJmd0OyBUbzogWXUsIEphbWVzOyBKYW5l dCBQIEd1bm48YnI+DQomZ3Q7IENjOiBzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzsgZHJh ZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS08YnI+DQomZ3Q7IGNvbnRyb2wuYWxsQHRvb2xzLmll dGYub3JnOyBzaXAtb3ZlcmxvYWRAaWV0Zi5vcmc8YnI+DQomZ3Q7IFN1YmplY3Q6IFJFOiBbc2lw LW92ZXJsb2FkXSBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1yYXRlLWNvbnRyb2wtMDQudHh0PC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBKYW5ldCwgSmFtZXMsPC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+Jmd0OyBUaGFua3MgeW91IGZvciB5b3VyIHZhbHVhYmxlIGNvbW1lbnRzIGFuZCBkaXNj dXNzaW9uLg0KJm5ic3A7SSB0cmllZCB0byA8YnI+DQomZ3Q7IGNhcHR1cmUgYWxsIHJlc29sdXRp b24gaW4gdGhlIGZvbGxvd2luZyB0ZXh0IChiYXNlZCBvbiBKYW1lcyB3b3JkDQo8YnI+DQomZ3Q7 IGRvY3VtZW50IHdpdGggdHJhY2sgY2hhbmdlcyBhbmQgaW1iZWRkZWQgY29tbWVudHMgZW5hYmxl ZCkuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyArIEFic3RyYWN0IHNlY3Rpb246IDwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAtIEFncmVlZCB3aXRoIHN1Z2dlc3Rl ZCBjaGFuZ2VzPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IC0gUGxlYXNl IG5vdGUgSSB3aWxsIGFsc28gbmVlZCB0byBtYWtlIGZ1cnRoZXINCmNoYW5nZXMgdG8gcmVtb3Zl IGFsbDxicj4NCiZndDsgcmVmZXJlbmNlcyBwZXIgQ2hyaXN0ZXIgSG9sbWJlcmcgY29tbWVudDwv Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgKyBTZWN0aW9uIDE6PC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IC0gQWdyZWVkIHdpdGggc3VnZ2VzdGVkIGNoYW5nZXM8L2Zv bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICsgU2VjdGlvbiAzLjE6PC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IC0gQWdyZWVkIHdpdGggc3VnZ2VzdGVkIGNoYW5nZXM8L2Zv bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7IDwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyArIFNlY3Rpb24gMy4yOiAtIFBsZWFzZSBub3RlIHRo ZSBzZWN0aW9uIHRpdGxlDQp3aWxsIGJlY29tZSDigJxWaWEgPGJyPg0KJmd0OyBoZWFkZXIgZmll bGQgcGFyYW1ldGVycyBmb3Igb3ZlcmxvYWQgY29udHJvbCDigJwgcGVyIENocmlzdGVyIEhvbG1i ZXJnDQpjb21tZW50PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IC0gQWdy ZWVkIHdpdGggc3VnZ2VzdGVkIGNoYW5nZXMgZXhjbHVkaW5nIHRpdGxlDQp0aGF0IHdpbGwgY2hh bmdlIHBlcjxicj4NCiZndDsgcHJldmlvdXMgYnVsbGV0PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ Jmd0OyArIFNlY3Rpb24gMy4zOjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0 OyAtIEFncmVlZCB3aXRoIHN1Z2dlc3RlZCBjaGFuZ2VzPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ Jmd0OyArIFNlY3Rpb24gMy40OjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0 OyAtIElEOiAmbmJzcDsmcXVvdDtOb3RlIHRoYXQgdGhlIHRhcmdldCBTSVAgcmVxdWVzdA0KcmF0 ZSBpcyBhIG1heCByYXRlIHRoYXQgbWF5PGJyPg0KJmd0OyBub3QgYmUgYXR0YWluZWQgYnkgdGhl IGFycml2YWwgcmF0ZSBhdCB0aGUgY2xpZW50LCBhbmQgdGhlIHNlcnZlcg0KPGJyPg0KJmd0OyBj YW5ub3QgYXNzdW1lIHRoYXQgaXQgd2lsbC4mcXVvdDsgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDtbSlldIE5vdCBjbGVhciB3aGF0IHZhbHVlIHRo aXMgcGFyYWdyYXBoDQp0cmllcyB0byBhZGQuICZuYnNwO0lzIGl0IDxicj4NCiZndDsgc2F5aW5n IHRoYXQgdGhlIGNsaWVudCdzIGFycml2YWwgcmF0ZSBtYXkgYmUgbG93ZXIgdGhhbiB0aGUgdGFy Z2V0DQo8YnI+DQomZ3Q7IFNJUCByZXF1ZXN0IHJhdGU/IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7W0pHXSBZZXMgKyBzdXBwb3J0aW5nIGV4YW1w bGUgKHNlZQ0KYmVsb3cgaW4gdGhyZWFkKTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+Jmd0OyAmbmJzcDsgQWdyZWVkIHdpdGggSmFuZXQgYW5kIHN1cHBvcnRpbmcgZXhhbXBsZS4N ClBlciBKYW1lcyByZXF1ZXN0LCBJIDxicj4NCiZndDsgd2lsbCBhZGQgdGhlIGZvbGxvd2luZyB0 ZXh0IChpbnNwaXJlZCBmcm9tIEphbmV04oCZcyBpbGx1c3RyYXRpdmUgZXhhbXBsZSk6PC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDvigJxJbiBvdGhl ciB3b3Jkcywgd2hlbiBtdWx0aXBsZQ0KY2xpZW50cyBhcmUgYmVpbmcgY29udHJvbGxlZCBieSBh bjxicj4NCiZndDsgb3ZlcmxvYWRlZCBzZXJ2ZXIsIGF0IGFueSBnaXZlbiB0aW1lIHNvbWUgY2xp ZW50cyBtYXkgcmVjZWl2ZSA8YnI+DQomZ3Q7IHJlcXVlc3RzIGF0IGEgcmF0ZSBiZWxvdyBpdHMg dGFyZ2V0IFNJUCByZXF1ZXN0IHJhdGUgd2hpbGUgb3RoZXJzDQo8YnI+DQomZ3Q7IGFib3ZlIHRo YXQgdGFyZ2V0IHJhdGUuIEJ1dCB0aGUgcmVzdWx0aW5nIHJlcXVlc3QgcmF0ZSBwcmVzZW50ZWQg dG8NCjxicj4NCiZndDsgdGhlIG92ZXJsb2FkZWQgc2VydmVyIHdpbGwgY29udmVyZ2UgdG93YXJk cyB0aGUgdGFyZ2V0IFNJUCByZXF1ZXN0DQpyYXRlLuKAnTwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+Jmd0OyAtIEFncmVlZCB3aXRoIG90aGVyIHN1Z2dlc3RlZCBjaGFuZ2VzIDwv Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNw OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyArIFNlY3Rpb24gMy41LjE6 PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IC0gSUQ6IOKAnEFuZCB0aGUg bGFyZ2VyIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4NClRBVTEgYW5kIFRBVTIsIHRoZSA8YnI+DQom Z3Q7IGNsb3NlciB0byB0aGUgY29udHJvbCBpcyB0byBzdHJpY3QgcHJpb3JpdHku4oCdPC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyBbSlldIFN1Z2dlc3QgY2hh bmdpbmcgaW50byDigJxBbmQgdGhlIGxhcmdlcg0KdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiA8YnI+ DQomZ3Q7IFRBVTEgYW5kIFRBVTIsIHRoZSBjbG9zZXIgdGhlIGNvbnRyb2wgaXMgdG8gc3RyaWN0 IHByaW9yaXR5IHF1ZXVpbmcu4oCdPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m Z3Q7ICZuYnNwOyBbSkddIFN1Z2dlc3QgY2hhbmdpbmcgaW50byDigJxBbmQgdGhlIGxhcmdlcg0K dGhlIGRpZmZlcmVuY2UgYmV0d2VlbiA8YnI+DQomZ3Q7IFRBVTEgYW5kIFRBVTIsIHRoZSBjbG9z ZXIgdGhlIGNvbnRyb2wgaXMgdG8gc3RyaWN0IHByaW9yaXR5IHRyZWF0bWVudC7igJ08L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7IFtFTl0gQWdyZWVkIHdpdGgg SmFuZXTigJlzIHN1Z2dlc3Rpb248L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn dDsgLSBBZ3JlZWQgd2l0aCBvdGhlciBzdWdnZXN0ZWQgY2hhbmdlczwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgKyBTZWN0aW9uIDQ6PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7IC0gQWdyZWVkIHdpdGggc3VnZ2VzdGVkIGNoYW5nZXM8L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj4mZ3Q7ICsgU2VjdGlvbiA1OjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ Jmd0OyAtIFBsZWFzZSBub3RlIHRoYXQgYmFzZWQgY29tbWVudHMgZnJvbSBwZXIgQ2hyaXN0ZXIN CkhvbG1iZXJnIGFuZCA8YnI+DQomZ3Q7IEphbmV0IEd1bm4sIHRoZSBmb2xsb3dpbmcgd2FzIHRl bnRhdGl2ZWx5IGFncmVlZCA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg Jm5ic3A7ICZuYnNwO1JlcGxhY2Ugb2MtdmFsdWUgPSAmcXVvdDtOYU4mcXVvdDsNCi8gb2MtbnVt ICZuYnNwOyAmbmJzcDtieSAmbmJzcDsgJm5ic3A7b2MgPSAmcXVvdDtvYyZxdW90OyBbRVFVQUwg b2MtbnVtXTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAtIEFncmVlZCB3 aXRoIG90aGVyIHN1Z2dlc3RlZCBjaGFuZ2U8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICsg U2VjdGlvbiA3OjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAtIFtKWV0g U2hvdWxkIOKAnHJhdGXigJ0gaW4gb2MtYWxnbyBiZSByZWdpc3RlcmVkDQp3aXRoIElBTkE/PC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyBUaGlzIGlzc3VlIG5l ZWRzIHRvIGJlIGFkZHJlc3NlZCBieSBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1jb250cm9sDQph dXRob3JzPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBQbGVhc2Ugbm90ZSBJIHdpbGwgd2Fp dCB1bnRpbCBleHBpcmF0aW9uIG9mIFdHTEMNCnByaW9yIHVwZGF0aW5nIG91ciA8YnI+DQomZ3Q7 IGRyYWZ0IFJGQy4gT25jZSBhZ2FpbiB5b3VyIGNvbW1lbnRzIGFuZC9vciBzdWdnZXN0aW9ucyBh cmUgbW9zdCBhcHByZWNpYXRlZC48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn dDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFRoYW5rcyw8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEVyaWMgTm9lbCA8L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPiZndDsgQVQmYW1wO1QgTGFicywgSW5jLiA8YnI+DQomZ3Q7IFJldGhp bmsgUG9zc2libGU8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7 PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IE5ldHdvcmsgRGVzaWduIGFu ZCBQZXJmb3JtYW5jZSBBbmFseXNpczxicj4NCiZndDsgMjAwIFNvdXRoIExhdXJlbCBBdmVudWUs IEQ1LTNEMTk8YnI+DQomZ3Q7IE1pZGRsZXRvd24sIE5KIDA3NzQ4PGJyPg0KJmd0OyBQOiA3MzIu NDIwLjQxNzQ8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgZWNub2VsQGF0 dC5jb208L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEZyb206IHNpcC1vdmVybG9hZC1ib3Vu Y2VzQGlldGYub3JnIFs8L2ZvbnQ+PC90dD48YSBocmVmPSJtYWlsdG86c2lwLW92ZXJsb2FkLWJv dW5jZXNAaWV0Zi5vcmciPjx0dD48Zm9udCBzaXplPTI+bWFpbHRvOnNpcC1vdmVybG9hZC1ib3Vu Y2VzQGlldGYub3JnPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+XQ0KPGJyPg0KJmd0 OyBPbiBCZWhhbGYgT2YgWXUsIEphbWVzPGJyPg0KJmd0OyBTZW50OiBUdWVzZGF5LCBKdWx5IDAy LCAyMDEzIDk6NDIgQU08YnI+DQomZ3Q7IFRvOiBKYW5ldCBQIEd1bm48YnI+DQomZ3Q7IENjOiBz aXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0 ZS08YnI+DQomZ3Q7IGNvbnRyb2wuYWxsQHRvb2xzLmlldGYub3JnOyBzaXAtb3ZlcmxvYWRAaWV0 Zi5vcmc8YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBbc2lwLW92ZXJsb2FkXSBkcmFmdC1pZXRmLXNv Yy1vdmVybG9hZC1yYXRlLWNvbnRyb2wtMDQudHh0PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0 OyBKYW5ldCw8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEZvciBteSBjb21tZW50IG9uIHNl Y3Rpb24gMy40ICh0aGUgZmlyc3Qgb25lDQpiZWxvdyksIHRoZSBjdXJyZW50IDxicj4NCiZndDsg dGV4dCBkb2VzIG5vdCBwcm92aWRlIGFueSB2YWx1ZS4gJm5ic3A7VGhlIGNsaWVudOKAmXMgYXJy aXZhbCByYXRlDQpjb3VsZCBiZTxicj4NCiZndDsgd2VsbCBiZWxvdyB0aGUgdGFyZ2V0IFNJUCBy ZXF1ZXN0IHJhdGUgd2hlbiBpdHMgbG9hZCBpcyBsaWdodCBzbyB0aGU8YnI+DQomZ3Q7IGZhY3Qg dGhhdCB0aGUgY2xpZW50IG1heSBub3QgYWNoaWV2ZSB0aGUgdGFyZ2V0IFNJUCByZXF1ZXN0IHJh dGUgPGJyPg0KJmd0OyAodGhlIG1heC4gcmF0ZSBpdCBpcyBhbGxvd2VkIHRvIHNlbmQgdG8gdGhl IHNlcnZlcikgaXMgd2VsbCA8YnI+DQomZ3Q7IHVuZGVyc3Rvb2QuICZuYnNwO0J1dCB3aXRoIHlv dXIgZXhwbGFuYXRpb24gb24gdGhlIOKAnGRlbHRh4oCdIHBhcnQsDQp0aGUgdGV4dDxicj4NCiZn dDsgdGhlbiBtYWtlcyBzZW5zZS4gJm5ic3A7UGxlYXNlIGFkZCBzb21lIGRpc2N1c3Npb25zIG9u IHRoZSDigJxkZWx0YeKAnQ0KYXNwZWN0PGJyPg0KJmd0OyBzbyB0aGF0IGV2ZW4gaWYgdGhlIGF2 ZXJhZ2UgYXJyaXZhbCByYXRlIGF0IHRoZSBjbGllbnQgaXMgaGlnaGVyIDxicj4NCiZndDsgdGhh biB0aGUgdGFyZ2V0IFNJUCByZXF1ZXN0IHJhdGUgdGhlIGNsaWVudCBhdCB0aW1lcyBtYXkgbm90 IHNlbmQNCjxicj4NCiZndDsgbW9yZSB0aGFuIHdoYXQgdGhlIHRhcmdldCBTSVAgcmVxdWVzdCBy YXRlIGFsbG93cyBkdWUgdG8gdGhlIDxicj4NCiZndDsgZmx1Y3R1YXRpb24gb2YgdGhlIGFycml2 aW5nIHJlcXVlc3RzIGF0IHRoZSBjbGllbnQuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBG b3IgdGhlIGNvbW1lbnQgb24gc2VjdGlvbiAzLjUuMSwgSSBhZ3JlZSB3aXRoDQp5b3VyIHByb3Bv c2VkIGNoYW5nZS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7 PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEZvciB0aGUgcmF0ZSBjb250 cm9sLCB0aGUgc2VydmVyIGNvdWxkIGNhbGN1bGF0ZQ0KdGhlIGFycml2YWwgcmF0ZSA8YnI+DQom Z3Q7IGZyb20gZWFjaCBjb21tdW5pY2F0aW5nIGNsaWVudCBzbyB0aGF0IGl0IGNvdWxkIGFsbG9j YXRlIHRoZSBvdmVyYWxsPGJyPg0KJmd0OyB0YXJnZXQgU0lQIHJlcXVlc3QgcmF0ZSB0byB0aGUg Y2xpZW50cyBiYXNlZCBvbiB0aGVpciBhcnJpdmFsIHJhdGVzDQo8YnI+DQomZ3Q7IGtub3duIHRv IHRoZSBzZXJ2ZXIuICZuYnNwO0J1dCBhbm90aGVyIG9wdGlvbiBpcyBmb3IgdGhlIGNsaWVudCB0 bw0KPGJyPg0KJmd0OyDigJxvcHRpb25hbGx54oCdIGluY2x1ZGUgaXRzIGNhbGN1bGF0ZWQgYXJy aXZhbCByYXRlIGluIGl0cyByZXF1ZXN0DQp0byA8YnI+DQomZ3Q7IHRoZSBzZXJ2ZXIgd2hlbiBy YXRlIGNvbnRyb2wgcmVsYXRlZCBwYXJhbWV0ZXJzIGFyZSBwcmVzZW50LiAmbmJzcDtTaG91bGQ8 YnI+DQomZ3Q7IHRoaXMgb3B0aW9uIGJlIGV2YWx1YXRlZC9pbmNsdWRlZCB0byByZWxpZXZlIHRo ZSBzZXJ2ZXIgZnJvbSBkb2luZw0KPGJyPg0KJmd0OyB0aGUgYXJyaXZhbCByYXRlIGNhbGN1bGF0 aW9ucy4gJm5ic3A7VGhpcyB3b3VsZCBiZSBiZW5lZmljaWFsIHRvIGENCnNlcnZlcjxicj4NCiZn dDsgd2hlbiBpdCByZWNlaXZlcyB0aGUgcmVxdWVzdHMgZnJvbSBtYW55IGNsaWVudHMuPC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyBKYW1lczwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg RnJvbTogSmFuZXQgUCBHdW5uIFs8L2ZvbnQ+PC90dD48YSBocmVmPW1haWx0bzpqZ3VubjZAY3Nj LmNvbT48dHQ+PGZvbnQgc2l6ZT0yPm1haWx0bzpqZ3VubjZAY3NjLmNvbTwvZm9udD48L3R0Pjwv YT48dHQ+PGZvbnQgc2l6ZT0yPl0NCjxicj4NCiZndDsgU2VudDogRnJpZGF5LCBKdW5lIDI4LCAy MDEzIDM6MzQgUE08YnI+DQomZ3Q7IFRvOiBZdSwgSmFtZXM8YnI+DQomZ3Q7IENjOiBkcmFmdC1p ZXRmLXNvYy1vdmVybG9hZC1yYXRlLWNvbnRyb2wuYWxsQHRvb2xzLmlldGYub3JnOyBzaXAtPGJy Pg0KJmd0OyBvdmVybG9hZEBpZXRmLm9yZzsgc2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8 YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBbc2lwLW92ZXJsb2FkXSBkcmFmdC1pZXRmLXNvYy1vdmVy bG9hZC1yYXRlLWNvbnRyb2wtMDQudHh0PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBKYW1l cywgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEl0IGlzIGEgbGl0dGxlIGhhcmQgdG8gcmVzcG9uZCBp biBlbWFpbCB3aGVuIHlvdXIgY29tbWVudHMgYXJlIGluDQphIDxicj4NCiZndDsgc2VwYXJhdGUg ZG9jdW1lbnQsIGJ1dCBoZXJlIGdvZXMuIDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IHNlY3Rpb24gMy40IDxicj4NCiZndDsgSUQgc2F5czogPGJyPg0KJmd0OyAmcXVvdDtOb3RlIHRo YXQgdGhlIHRhcmdldCBTSVAgcmVxdWVzdCByYXRlIGlzIGEgbWF4IHJhdGUgdGhhdCBtYXkNCm5v dCBiZSA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDthdHRhaW5lZCBieSB0aGUgYXJyaXZhbCByYXRl IGF0IHRoZSBjbGllbnQsIGFuZCB0aGUgc2VydmVyDQpjYW5ub3QgPGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7YXNzdW1lIHRoYXQgaXQgd2lsbC4mcXVvdDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFlv dXIgY29tbWVudCA6IDxicj4NCiZndDsgJnF1b3Q7Tm90IGNsZWFyIHdoYXQgdmFsdWUgdGhpcyBw YXJhZ3JhcGggdHJpZXMgdG8gYWRkLiAmbmJzcDtJcyBpdA0Kc2F5aW5nIDxicj4NCiZndDsgdGhh dCB0aGUgY2xpZW50J3MgYXJyaXZhbCByYXRlIG1heSBiZSBsb3dlciB0aGFuIHRoZSB0YXJnZXQg U0lQIDxicj4NCiZndDsgcmVxdWVzdCByYXRlPyAmbmJzcDsmcXVvdDsgPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IFllcy4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFN1cHBvc2UgdGhlIHNlcnZlciB3YW50 IHRvIGxpbWl0IHRoZSB0b3RhbCByYXRlIG9mIGFycml2aW5nIFNJUCA8YnI+DQomZ3Q7IG1lc3Nh Z2VzIHRvIDEwMCAvIHNlYywgYW5kIGhhcyAxMCBjbGllbnRzLiAmbmJzcDtFYWNoIGNsaWVudCBo YXMgYQ0KaGlnaCA8YnI+DQomZ3Q7IHZhcmlhbmNlIGluIGl0cyBtZXNzYWdlIHJhdGUsIGJ1dCB0 b2dldGhlciB0aGV5IGFyZSB3ZWxsIGFib3ZlIDEwMA0KPGJyPg0KJmd0OyBtZXNzYWdlcyBwZXIg c2VjIDxicj4NCiZndDsgPGJyPg0KJmd0OyBJZiBpdCBzZXRzIHRoZSByYXRlIGF0IDEwIG1lc3Nh Z2VzIHBlciBzZWNvbmQgZm9yIGVhY2ggb2YgdGhlIDxicj4NCiZndDsgY2xpZW50cywgaXQgd2ls bCBhbG1vc3QgY2VydGFpbmx5IGVuZCB1cCAmbmJzcDt3aXRoIGFuIG92ZXJhbGwgYXZlcmFnZQ0K b2Y8YnI+DQomZ3Q7IGxlc3MgdGhhbiAxMDAgbWVzc2FnZXMgcGVyIHNlYywgYmVjYXVzZSBzb21l IGNsaWVudHMgd2lsbCBiZSBpbiBhDQo8YnI+DQomZ3Q7ICZxdW90O2x1bGwmcXVvdDsgd2hpbGUg b3RoZXJzIGFyZSBidXN5LiAmbmJzcDtUaGlzIGlzIGdvb2QgZnJvbSBhDQp0aHJvdHRsaW5nIDxi cj4NCiZndDsgcGVyc3BlY3RpdmUsIGJ1dCwgYXNzdW1pbmcgbWVzc2FnZXMgYXJlIGNvcnJlbGF0 ZWQgd2l0aCByZXZlbnVlLCA8YnI+DQomZ3Q7IGJhZC93YXN0ZWZ1bCBmcm9tIGEgcmV2ZW51ZSwg b3Igb3ZlcmFsbCBwcm9kdWN0aXZpdHkgcGVyc3BlY3RpdmUuDQombmJzcDs8YnI+DQomZ3Q7IFNv IHRoZSBzZXJ2ZXIgbWlnaHQgd2FudCB0byBzZXQgdGhlIHJhdGUgcGVyIGNsaWVudCB0byAxMCAr IGRlbHRhLA0KPGJyPg0KJmd0OyB3aGVyZSBkZWx0YSBpcyBnb2luZyB0byBiZSB2ZXJ5IHNwZWNp ZmljIHRvIG9wZXJhdGluZyBlbnZpcm9ubWVudC4NCjxicj4NCiZndDsgPGJyPg0KJmd0OyAtLS0g PGJyPg0KJmd0OyBJbiBzZWN0aW9uICZuYnNwOzMuNS4xLCBib3R0b20gb2YgcGFnZSA4IDxicj4N CiZndDsgSUQgc2F5czogPGJyPg0KJmd0OyAmcXVvdDtBbmQgdGhlIGxhcmdlciA8YnI+DQomZ3Q7 ICZuYnNwOyAmbmJzcDt0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIFRBVTEgYW5kIFRBVTIsIHRoZSBj bG9zZXIgdG8gdGhlDQpjb250cm9sIGlzIDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO3RvIHN0cmlj dCBwcmlvcml0eS4mcXVvdDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFlvdSBwcm9wb3NlIGNoYW5n aW5nIGl0IHRvOiA8YnI+DQomZ3Q7ICZxdW90O0FuZCB0aGUgbGFyZ2VyIDxicj4NCiZndDsgJm5i c3A7ICZuYnNwO3RoZSBkaWZmZXJlbmNlIGJldHdlZW4gVEFVMSBhbmQgVEFVMiwgdGhlIGNsb3Nl ciAmbmJzcDt0aGUNCmNvbnRyb2wgaXMgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7dG8gc3RyaWN0 IHByaW9yaXR5IHF1ZXVpbmcuJnF1b3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBJIGFncmVlIHdp dGggdGFraW5nIG91dCB0aGUgcmVkdW5kYW50ICZxdW90O3RvJnF1b3Q7LiAmbmJzcDtCdXQgSQ0K ZGlzYWdyZWUgd2l0IDxicj4NCiZndDsgYWRkaW5nICZxdW90O3F1ZXVpbmcmcXVvdDsuICZuYnNw O1RoZXJlIGlzIG5vIHF1ZXVpbmcsIHByaW9yaXR5IG9yDQpvdGhlcndpc2UgaW52b2x2ZWQuIDxi cj4NCiZndDsgPGJyPg0KJmd0OyBZb3UgY291bGQgc2F5OiA8YnI+DQomZ3Q7ICZxdW90O0FuZCB0 aGUgbGFyZ2VyIDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO3RoZSBkaWZmZXJlbmNlIGJldHdlZW4g VEFVMSBhbmQgVEFVMiwgdGhlIGNsb3NlciAmbmJzcDt0aGUNCmNvbnRyb2wgaXMgPGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7dG8gc3RyaWN0IHByaW9yaXR5IHRyZWF0bWVudC4mcXVvdDsgPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IHdoZXJlICZxdW90OyBzdHJpY3QgcHJpb3JpdHkgdHJlYXRtZW50JnF1 b3Q7IHdvdWxkIHJlZmVyIHRvIHRoZSBjYXNlDQp3aGVyZSA8YnI+DQomZ3Q7IG5vbi1wcmlvcml0 eSBtZXNzYWdlcyBhcmUgcmVzdHJpY3RlZCB0byBhIHRvdGFsIChwcmlvcml0eSArIG5vbi08YnI+ DQomZ3Q7IHByaW9yaXR5KSByYXRlIG9mIDEwIG1lc3NhZ2VzIHBlciBzZWNvbmQsIGJ1dCBwcmlv cml0eSBtZXNzYWdlcyBjYW4NCjxicj4NCiZndDsgY29udGludWUgdG8gYmUgc2VudCBhcyBsb25n IGFzIHRoZSB0b3RhbCAocHJpb3JpdHkgKyBub24tcHJpb3JpdHkpDQo8YnI+DQomZ3Q7IHJhdGUg aXMgbGVzcyB0aGFuIDEyIG1lc3NhZ2VzIHBlciBzZWNvbmQuIDxicj4NCiZndDsgPGJyPg0KJmd0 OyBBdCBsZWFzdCwgSSB0aGluayB0aGF0IGlzIHdoYXQgRXJpYyBhbmQgJm5ic3A7UGhpbGlwIGFy ZSB0cnlpbmcgdG8NCnNheS4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEphbmV0IDxicj4NCiZndDsg PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0K Jmd0OyBUaGlzIGlzIGEgUFJJVkFURSBtZXNzYWdlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50LA0KPGJyPg0KJmd0OyBwbGVhc2UgZGVsZXRlIHdpdGhvdXQgY29weWluZyBh bmQga2luZGx5IGFkdmlzZSB1cyBieSBlLW1haWwgb2YgdGhlDQo8YnI+DQomZ3Q7IG1pc3Rha2Ug aW4gZGVsaXZlcnkuIE5PVEU6IFJlZ2FyZGxlc3Mgb2YgY29udGVudCwgdGhpcyBlLW1haWwgc2hh bGwNCjxicj4NCiZndDsgbm90IG9wZXJhdGUgdG8gYmluZCBDU0MgdG8gYW55IG9yZGVyIG9yIG90 aGVyIGNvbnRyYWN0IHVubGVzcyA8YnI+DQomZ3Q7IHB1cnN1YW50IHRvIGV4cGxpY2l0IHdyaXR0 ZW4gYWdyZWVtZW50IG9yIGdvdmVybm1lbnQgaW5pdGlhdGl2ZSA8YnI+DQomZ3Q7IGV4cHJlc3Ns eSBwZXJtaXR0aW5nIHRoZSB1c2Ugb2YgZS1tYWlsIGZvciBzdWNoIHB1cnBvc2UuIDxicj4NCiZn dDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgRnJvbTogJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7JnF1b3Q7WXUsIEphbWVzJnF1b3Q7ICZsdDtqYW1lcy55dUBuZXVzdGFyLmJp eiZndDsNCjxicj4NCiZndDsgVG86ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O3Np cC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnJnF1b3Q7DQombHQ7c2lwLW92ZXJsb2FkLWJvdW5j ZXNAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDs8YnI+DQomZ3Q7IGRyYWZ0LWlldGYtc29jLW92ZXJsb2Fk LXJhdGUtY29udHJvbC5hbGxAdG9vbHMuaWV0Zi5vcmcmcXVvdDsgJmx0O2RyYWZ0LTxicj4NCiZn dDsgaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLmFsbEB0b29scy5pZXRmLm9yZyZndDss ICZxdW90O3NpcC1vdmVybG9hZEBpZXRmLm9yZyZxdW90Ow0KJmx0Ozxicj4NCiZndDsgc2lwLW92 ZXJsb2FkQGlldGYub3JnJmd0OyA8YnI+DQomZ3Q7IERhdGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOzA2LzI4LzIwMTMgMDg6MTAgQU0gPGJyPg0KJmd0OyBTdWJqZWN0OiAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtbc2lwLW92ZXJsb2FkXSBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1y YXRlLWNvbnRyb2wtMDQudHh0DQo8YnI+DQomZ3Q7IFNlbnQgYnk6ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO3NpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnDQo8L2ZvbnQ+PC90dD4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsg PGJyPg0KJmd0OyBTYWx2YXRvcmUsIDxicj4NCiZndDsgJm5ic3A7IDxicj4NCiZndDsgUGxlYXNl IHNlZSB0aGUgYXR0YWNobWVudCBmb3IgbXkgY29tbWVudHMuIDxicj4NCiZndDsgJm5ic3A7IDxi cj4NCiZndDsgSSBwYXN0ZWQgdGhlIHRleHQgdG8gYSB3b3JkIGRvY3VtZW50IHRvIHRyYWNlL3No b3cgdGhlIHByb3Bvc2VkIDxicj4NCiZndDsgY2hhbmdlcyBhbmQgY29tbWVudHMuIDxicj4NCiZn dDsgJm5ic3A7IDxicj4NCiZndDsgUmVnYXJkcywgPGJyPg0KJmd0OyAmbmJzcDsgPGJyPg0KJmd0 OyBKYW1lcyA8YnI+DQomZ3Q7ICZuYnNwO1thdHRhY2htZW50ICZxdW90O2NvbW1lbnRzIG9uIGRy YWZ0LWlldGYtc29jLW92ZXJsb2FkLXJhdGUtPGJyPg0KJmd0OyBjb250cm9sLTA0LmRvY3gmcXVv dDsgZGVsZXRlZCBieSBKYW5ldCBQIEd1bm4vVVNBL0NTQ10gPGJyPg0KJmd0OyBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgc2lwLW92ZXJs b2FkIG1haWxpbmcgbGlzdDxicj4NCiZndDsgc2lwLW92ZXJsb2FkQGlldGYub3JnPGJyPg0KJmd0 OyA8L2ZvbnQ+PC90dD48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NpcC1vdmVybG9hZCI+PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NpcC1vdmVybG9hZDwvZm9udD48L3R0PjwvYT4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBObyB2aXJ1cyBmb3VuZCBpbiB0aGlzIG1lc3NhZ2Uu PGJyPg0KJmd0OyBDaGVja2VkIGJ5IEFWRyAtIDwvZm9udD48L3R0PjxhIGhyZWY9d3d3LmF2Zy5j b20+PHR0Pjxmb250IHNpemU9Mj53d3cuYXZnLmNvbTwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQg c2l6ZT0yPjxicj4NCiZndDsgVmVyc2lvbjogMjAxMy4wLjI5MDQgLyBWaXJ1cyBEYXRhYmFzZTog MzIwNC82NDUyIC0gUmVsZWFzZSBEYXRlOiAwNi8zMC8xMzwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IE5vIHZpcnVzIGZvdW5kIGluIHRoaXMgbWVzc2Fn ZS48YnI+DQomZ3Q7IENoZWNrZWQgYnkgQVZHIC0gPC9mb250PjwvdHQ+PGEgaHJlZj13d3cuYXZn LmNvbT48dHQ+PGZvbnQgc2l6ZT0yPnd3dy5hdmcuY29tPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9u dCBzaXplPTI+PGJyPg0KJmd0OyBWZXJzaW9uOiAyMDEzLjAuMjkwNCAvIFZpcnVzIERhdGFiYXNl OiAzMjA0LzY0NzggLSBSZWxlYXNlIERhdGU6IDA3LzA5LzEzPGJyPg0KJmd0OyBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgc2lwLW92ZXJs b2FkIG1haWxpbmcgbGlzdDxicj4NCiZndDsgc2lwLW92ZXJsb2FkQGlldGYub3JnPGJyPg0KJmd0 OyA8L2ZvbnQ+PC90dD48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NpcC1vdmVybG9hZCI+PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NpcC1vdmVybG9hZDwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6 ZT0yPjxicj4NCjwvZm9udD48L3R0Pg0K --=_alternative 004DFC1D85257BA4_=-- From james.yu@neustar.biz Wed Jul 10 07:17:15 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 70F1C21F9FA1; Wed, 10 Jul 2013 07:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpiWQn5eA8Wd; Wed, 10 Jul 2013 07:17:08 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 0442D21F9F0C; Wed, 10 Jul 2013 07:17:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1373465790; x=1688823191; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=6KgcxoM5C+9yQRIJomrNoYfHUfbGegQ25j34c1GM9zg=; b=jWEA3KpdiKC0+UX2UDwrC3p+EdookW6sJhxV0+z5mlvv9nhXch59juJqeKtSTC z/GL0KMynK5R3B9CExr55ENw== Received: from ([10.31.58.69]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.22124090; Wed, 10 Jul 2013 10:16:29 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.240]) with mapi id 14.02.0342.003; Wed, 10 Jul 2013 10:17:03 -0400 From: "Yu, James" To: "NOEL, ERIC C (ERIC C)" Thread-Topic: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Thread-Index: Ac5zhcqru7dYQFxqQKSGvvGKSQFJEAA0j1MAALOuppABZadV0AAr0zMgAAJGKhA= Date: Wed, 10 Jul 2013 14:17:02 +0000 Message-ID: <56FB15AFE08E1242B0736CBDCE6E85610809253D@stntexmb12.cis.neustar.com> References: <56FB15AFE08E1242B0736CBDCE6E85610808C32F@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610808EF90@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353BDA4CAD4@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E85610809239D@stntexmb12.cis.neustar.com> In-Reply-To: <56FB15AFE08E1242B0736CBDCE6E85610809239D@stntexmb12.cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.31.32.239] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: /SMPFyFRXglTVSmK4Boesw== Content-Type: multipart/alternative; boundary="_000_56FB15AFE08E1242B0736CBDCE6E85610809253Dstntexmb12cisne_" MIME-Version: 1.0 Cc: "sip-overload-bounces@ietf.org" , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" , "sip-overload@ietf.org" Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.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, 10 Jul 2013 14:17:15 -0000 --_000_56FB15AFE08E1242B0736CBDCE6E85610809253Dstntexmb12cisne_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Noel, I forgot to respond to your reply about the IANA registration of "rate" in = oc-algo. I see that draft-ietf-soc-overload-control-13 mentions your I-D b= ut does not have "rate" in algo-list. There are two possible ways to address "rate" in algo-list. One is to have= draft-ietf-soc-overload-control-13 add "rate" to algo-list and refer to yo= ur I-D for details. The other is to register "rate" in algo-list with IANA= in your I-D, and this should be a simple task. The cleaner way that is mo= re inline with the IETF process would be the latter. It seems odd to have = something defined in a RFC without details about it, and it would be too mu= ch trouble to combine the two I-Ds. James From: Yu, James Sent: Wednesday, July 10, 2013 9:01 AM To: 'NOEL, ERIC C (ERIC C)' Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all= @tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Noel, I mentioned in my message to Janet on 7/2: For the rate control, the server could calculate the arrival rate from each= communicating client so that it could allocate the overall target SIP requ= est rate to the clients based on their arrival rates known to the server. = But another option is for the client to "optionally" include its calculated= arrival rate in its request to the server when rate control related parame= ters are present. Should this option be evaluated/included to relieve the = server from doing the arrival rate calculations. This would be beneficial = to a server when it receives the requests from many clients. I suggest that the I-D adds that option to allow the client to indicate its= current arrival rate (towards the receiving server) in the SIP request. James From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] Sent: Tuesday, July 09, 2013 4:44 PM To: Yu, James; Janet P Gunn Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Janet, James, Thanks you for your valuable comments and discussion. I tried to capture a= ll resolution in the following text (based on James word document with trac= k changes and imbedded comments enabled). + Abstract section: - Agreed with suggested changes - Please note I will also need to make further changes to remove all refere= nces per Christer Holmberg comment + Section 1: - Agreed with suggested changes + Section 3.1: - Agreed with suggested changes + Section 3.2: - Please note the section title will become "Via header fiel= d parameters for overload control " per Christer Holmberg comment - Agreed with suggested changes excluding title that will change per previo= us bullet + Section 3.3: - Agreed with suggested changes + Section 3.4: - ID: "Note that the target SIP request rate is a max rate that may not be= attained by the arrival rate at the client, and the server cannot assume t= hat it will." [JY] Not clear what value this paragraph tries to add. Is it saying tha= t the client's arrival rate may be lower than the target SIP request rate? [JG] Yes + supporting example (see below in thread) Agreed with Janet and supporting example. Per James request, I will add t= he following text (inspired from Janet's illustrative example): "In other words, when multiple clients are being controlled by an overlo= aded server, at any given time some clients may receive requests at a rate = below its target SIP request rate while others above that target rate. But = the resulting request rate presented to the overloaded server will converge= towards the target SIP request rate." - Agreed with other suggested changes + Section 3.5.1: - ID: "And the larger the difference between TAU1 and TAU2, the closer to t= he control is to strict priority." [JY] Suggest changing into "And the larger the difference between TAU1 an= d TAU2, the closer the control is to strict priority queuing." [JG] Suggest changing into "And the larger the difference between TAU1 an= d TAU2, the closer the control is to strict priority treatment." [EN] Agreed with Janet's suggestion - Agreed with other suggested changes + Section 4: - Agreed with suggested changes + Section 5: - Please note that based comments from per Christer Holmberg and Janet Gunn= , the following was tentatively agreed Replace oc-value =3D "NaN" / oc-num by oc =3D "oc" [EQUAL oc-num] - Agreed with other suggested change + Section 7: - [JY] Should "rate" in oc-algo be registered with IANA? This issue needs to be addressed by draft-ietf-soc-overload-control autho= rs Please note I will wait until expiration of WGLC prior updating our draft R= FC. Once again your comments and/or suggestions are most appreciated. 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 Yu, James Sent: Tuesday, July 02, 2013 9:42 AM To: Janet P Gunn Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Janet, For my comment on section 3.4 (the first one below), the current text does = not provide any value. The client's arrival rate could be well below the t= arget SIP request rate when its load is light so the fact that the client m= ay not achieve the target SIP request rate (the max. rate it is allowed to = send to the server) is well understood. But with your explanation on the "= delta" part, the text then makes sense. Please add some discussions on the= "delta" aspect so that even if the average arrival rate at the client is h= igher than the target SIP request rate the client at times may not send mor= e than what the target SIP request rate allows due to the fluctuation of th= e arriving requests at the client. For the comment on section 3.5.1, I agree with your proposed change. For the rate control, the server could calculate the arrival rate from each= communicating client so that it could allocate the overall target SIP requ= est rate to the clients based on their arrival rates known to the server. = But another option is for the client to "optionally" include its calculated= arrival rate in its request to the server when rate control related parame= ters are present. Should this option be evaluated/included to relieve the = server from doing the arrival rate calculations. This would be beneficial = to a server when it receives the requests from many clients. James From: Janet P Gunn [mailto:jgunn6@csc.com] Sent: Friday, June 28, 2013 3:34 PM To: Yu, James Cc: draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org; sip-overload-bounces@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, It is a little hard to respond in email when your comments are in a separat= e document, but here goes. section 3.4 ID says: "Note that the target SIP request rate is a max rate that may not be attained by the arrival rate at the client, and the server cannot assume that it will." Your comment : "Not clear what value this paragraph tries to add. Is it saying that the c= lient's arrival rate may be lower than the target SIP request rate? " Yes. Suppose the server want to limit the total rate of arriving SIP messages to= 100 / sec, and has 10 clients. Each client has a high variance in its mes= sage rate, but together they are well above 100 messages per sec If it sets the rate at 10 messages per second for each of the clients, it w= ill almost certainly end up with an overall average of less than 100 messa= ges per sec, because some clients will be in a "lull" while others are busy= . This is good from a throttling perspective, but, assuming messages are c= orrelated with revenue, bad/wasteful from a revenue, or overall productivit= y perspective. So the server might want to set the rate per client to 10 += delta, where delta is going to be very specific to operating environment. --- In section 3.5.1, bottom of page 8 ID says: "And the larger the difference between TAU1 and TAU2, the closer to the control is to strict priority." You propose changing it to: "And the larger the difference between TAU1 and TAU2, the closer the control is to strict priority queuing." I agree with taking out the redundant "to". But I disagree wit adding "que= uing". There is no queuing, priority or otherwise involved. You could say: "And the larger the difference between TAU1 and TAU2, the closer the control is to strict priority treatment." where " strict priority treatment" would refer to the case where non-priori= ty messages are restricted to a total (priority + non-priority) rate of 10 = messages per second, but priority messages can continue to be sent as long = as the total (priority + non-priority) rate is less than 12 messages per se= cond. At least, I think that is what Eric and Philip are trying to say. 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: "Yu, James" = > To: "sip-overload-bounces@ietf.org" >= , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" >, "sip-overload@ietf.org"= > Date: 06/28/2013 08:10 AM Subject: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Sent by: sip-overload-bounces@ietf.org ________________________________ Salvatore, Please see the attachment for my comments. I pasted the text to a word document to trace/show the proposed changes and= comments. Regards, James [attachment "comments on draft-ietf-soc-overload-rate-control-04.docx" del= eted by Janet P Gunn/USA/CSC] _____________________________________________= __ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6452 - Release Date: 06/30/13 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13 --_000_56FB15AFE08E1242B0736CBDCE6E85610809253Dstntexmb12cisne_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Noel,

 <= /p>

I forgot to respond to yo= ur reply about the IANA registration of “rate” in oc-algo. = ; I see that draft-ietf-soc-overload-control-13 mentions your I-D but does not have “rate” in algo-list.

 <= /p>

There are two possible wa= ys to address “rate” in algo-list.  One is to have draft-i= etf-soc-overload-control-13 add “rate” to algo-list and refer t= o your I-D for details.  The other is to register “rate” in algo-lis= t with IANA in your I-D, and this should be a simple task.  The cleane= r way that is more inline with the IETF process would be the latter.  = It seems odd to have something defined in a RFC without details about it, and it would be too much trouble to combine the two I-Ds.

 <= /p>

James

 <= /p>

From: Yu, Jame= s
Sent: Wednesday, July 10, 2013 9:01 AM
To: 'NOEL, ERIC C (ERIC C)'
Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-cont= rol.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt

 

Noel,

 <= /p>

I mentioned in my message= to Janet on 7/2:

 <= /p>

= For the rate control, the server could calculate the arrival rate from each= communicating client so that it could allocate the overall target SIP request rate to the clients based on their arrival rates known = to the server.  But another option is for the client to “optiona= lly” include its calculated arrival rate in its request to the server= when rate control related parameters are present.  Should this option be evaluated/included to relieve the server from = doing the arrival rate calculations.  This would be beneficial to a se= rver when it receives the requests from many clients.

 <= /p>

I suggest that the I-D ad= ds that option to allow the client to indicate its current arrival rate (to= wards the receiving server) in the SIP request.

 <= /p>

James

 <= /p>

From: NOEL, ER= IC C (ERIC C) [mailto:ecnoel@res= earch.att.com]
Sent: Tuesday, July 09, 2013 4:44 PM
To: Yu, James; Janet P Gunn
Cc: sip-overload-bo= unces@ietf.org; = draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt

 

Janet, James,<= /span>

 <= /p>

Thanks you for your valua= ble comments and discussion.  I tried to capture all resolution in the= following text (based on James word document with track changes and imbedded comments enabled).

 <= /p>

+ Abstract section:

- Agreed with suggested c= hanges

- Please note I will also= need to make further changes to remove all references per Christer Holmber= g comment

 <= /p>

+ Section 1:

- Agreed with suggested c= hanges

 <= /p>

+ Section 3.1:

- Agreed with suggested c= hanges

 

+ Section 3.2: - Plea= se note the section title will become “Via header field parameters fo= r overload control “ per Christer Holmberg comment<= /p>

- Agreed with suggested c= hanges excluding title that will change per previous bullet

 <= /p>

+ Section 3.3:

- Agreed with suggested c= hanges

 <= /p>

+ Section 3.4:

- ID:  "Note th= at the target SIP request rate is a max rate that may not be attained by th= e arrival rate at the client, and the server cannot assume that it will."

   [JY] No= t clear what value this paragraph tries to add.  Is it saying that the= client's arrival rate may be lower than the target SIP request rate?

   [JG] Ye= s + supporting example (see below in thread)

  Agreed with J= anet and supporting example. Per James request, I will add the following te= xt (inspired from Janet’s illustrative example):

   “In ot= her words, when multiple clients are being controlled by an overloaded serv= er, at any given time some clients may receive requests at a rate below its target SIP request rate while others above that target rate. But the r= esulting request rate presented to the overloaded server will converge towa= rds the target SIP request rate.”

- Agreed with other sugge= sted changes

    &= nbsp;

+ Section 3.5.1:=

- ID: “And the larg= er the difference between TAU1 and TAU2, the closer to the control is to st= rict priority.”

  [JY] Suggest chang= ing into “And the larger the difference between TAU1 and TAU2, the cl= oser the control is to strict priority queuing.”

  [JG] Suggest chang= ing into “And the larger the difference between TAU1 and TAU2, the cl= oser the control is to strict priority treatment.”<= /p>

  [EN] Agreed with J= anet’s suggestion

- Agreed with other sugge= sted changes

 <= /p>

+ Section 4:

- Agreed with suggested c= hanges

 <= /p>

+ Section 5:

- Please note that based = comments from per Christer Holmberg and Janet Gunn, the following was tenta= tively agreed

   Replace= oc-value =3D "NaN" / oc-num    by   &nb= sp;oc =3D "oc" [EQUAL oc-num]

- Agreed with other sugge= sted change

 <= /p>

+ Section 7:

- [JY] Should “rate= ” in oc-algo be registered with IANA?

  This issue needs t= o be addressed by draft-ietf-soc-overload-control authors=

 <= /p>

Please note I will wait u= ntil expiration of WGLC prior updating our draft RFC. Once again your comme= nts and/or suggestions are most appreciated.

 <= /p>

Thanks,=

 <= /p>

Eric Noel

AT&T Labs, Inc.
Rethink Possible<= /p>

 

Network Design and Perform= ance Analysis
200 South Laurel Avenue, D5-3D19
Middletown, NJ 07748
P: 732.420.4174

ecnoel@att.com

 <= /p>

From: sip-overload-bounces@ietf.= org [mailto:sip-overlo= ad-bounces@ietf.org] On Behalf Of Yu, James
Sent: Tuesday, July 02, 2013 9:42 AM
To: Janet P Gunn
Cc: sip-overload-bo= unces@ietf.org; = draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt

 

Janet,<= /p>

 <= /p>

For my comment on section= 3.4 (the first one below), the current text does not provide any value.&nb= sp; The client’s arrival rate could be well below the target SIP request rate when its load is light so the fact that the client may no= t achieve the target SIP request rate (the max. rate it is allowed to send = to the server) is well understood.  But with your explanation on the &= #8220;delta” part, the text then makes sense.  Please add some discussions on the “delta” aspect so that even= if the average arrival rate at the client is higher than the target SIP re= quest rate the client at times may not send more than what the target SIP r= equest rate allows due to the fluctuation of the arriving requests at the client.

 <= /p>

For the comment on sectio= n 3.5.1, I agree with your proposed change.

 <= /p>

For the rate control, the= server could calculate the arrival rate from each communicating client so = that it could allocate the overall target SIP request rate to the clients based on their arrival rates known to the server.  But= another option is for the client to “optionally” include its c= alculated arrival rate in its request to the server when rate control relat= ed parameters are present.  Should this option be evaluated/included to relieve the server from doing the arrival rate calcu= lations.  This would be beneficial to a server when it receives the re= quests from many clients.

 <= /p>

James

 <= /p>

From: Janet P = Gunn [mailto:jgunn6@csc.com]
Sent: Friday, June 28, 2013 3:34 PM
To: Yu, James
Cc: draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org; sip-overload-bounces@ietf.org
Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt

 

James,

It is a little hard to respond in email when your comments are i= n a separate document, but here goes.


section 3.4
ID says:
"Note that the target SIP request rate is a max rate that m= ay not be
   attained by the arrival rate at the client, and the= server cannot
   assume that it will."

Your comment :
"Not clear what value this paragraph tries to add.  Is= it saying that the client's arrival rate may be lower than the target SIP = request rate?  "

Yes.

Suppose the server want to limit the total rate of arriving SIP = messages to 100 / sec, and has 10 clients.  Each client has a high var= iance in its message rate, but together they are well above 100 messages per sec

If it sets the rate at 10 messages per second for each of the cl= ients, it will almost certainly end up  with an overall average of les= s than 100 messages per sec, because some clients will be in a "lull" while others are busy.  This is good from a thrott= ling perspective, but, assuming messages are correlated with revenue, bad/w= asteful from a revenue, or overall productivity perspective.  So the s= erver might want to set the rate per client to 10 + delta, where delta is going to be very specific to operating environment.<= /span>

---
In section  3.5.1, bottom of page 8
ID says:
"And the larger
   the difference between TAU1 and TAU2, the closer to= the control is
   to strict priority."

You propose changing it to:
"And the larger
   the difference between TAU1 and TAU2, the closer &n= bsp;the control is
   to strict priority queuing."

I agree with taking out the redundant "to".  But = I disagree wit adding "queuing".  There is no queuing, prior= ity or otherwise involved.

You could say:
"And the larger
   the difference between TAU1 and TAU2, the closer &n= bsp;the control is
   to strict priority treatment."

where " strict priority treatment" would refer to the = case where non-priority messages are restricted to a total (priority + = non-priority) rate of 10 messages per second, but priority messages can continue to be sent as long as the total (priority + non-priority)= rate is less than 12 messages per second.

At least, I think that is what Eric and  Philip are trying = to say.

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 agreement or government initiative exp= ressly permitting the use of e-mail for such purpose.



From:        &= quot;Yu, James" <james.yu@n= eustar.biz>
To:        &= quot;sip-overload-bounces@= ietf.org" <sip= -overload-bounces@ietf.org>, "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" &l= t;draft-ietf-soc-overload-rate-control.all@tools.ietf.org>, "sip-overload@ietf.org&q= uot; <sip-overload@ietf.org= >
Date:        0= 6/28/2013 08:10 AM
Subject:        [sip-overload] draft-ietf-soc-overload-rate-control-04.txt
Sent by:        sip-overload-bounces@iet= f.org




Salvatore,
 
Please see the attachment for my comments.
 
I pasted the text to a word document to trace/show the propose= d changes and comments.
 
Regards,
 
James
 [attachment "comments on draft-ietf-soc-overload-ra= te-control-04.docx" deleted by Janet P Gunn/USA/CSC] _______________________________= ________________
sip-overload mailing list
sip-overload@ietf.org=
<= span style=3D"font-size:10.0pt">https://www.ietf.org/mailman/listinfo/sip-o= verload

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 3204/6452 - Release Date: 06/30/13

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13

--_000_56FB15AFE08E1242B0736CBDCE6E85610809253Dstntexmb12cisne_-- From james.yu@neustar.biz Wed Jul 10 07:24: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 C8D9F11E81A0; Wed, 10 Jul 2013 07:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cQyzRI0xWYO; Wed, 10 Jul 2013 07:23:59 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 8661111E8123; Wed, 10 Jul 2013 07:23:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1373466170; x=1688823191; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=Qxce4mBYiYSvPLGgHwFKSLN0dh56oS2t1hBMssilkh8=; b=iYxUCouaoDzXYrO32FlKcBLSMRX2frOSW8kYAnpwcOWW3IaMVb+XSB6MdOPMus OeC9CX6pLG9YSCimQMVqN6pA== Received: from ([10.31.58.69]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.22124609; Wed, 10 Jul 2013 10:22:49 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.240]) with mapi id 14.02.0342.003; Wed, 10 Jul 2013 10:23:20 -0400 From: "Yu, James" To: Janet P Gunn Thread-Topic: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Thread-Index: Ac5zhcqru7dYQFxqQKSGvvGKSQFJEAA0j1MAALOuppABZadV0AAr0zMgAAsPaAAACA47sA== Date: Wed, 10 Jul 2013 14:23:20 +0000 Message-ID: <56FB15AFE08E1242B0736CBDCE6E856108092557@stntexmb12.cis.neustar.com> References: <56FB15AFE08E1242B0736CBDCE6E85610808C32F@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610808EF90@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353BDA4CAD4@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E85610809239D@stntexmb12.cis.neustar.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.31.32.239] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: LHZiEKv9seqsDwJAtvhY7Q== Content-Type: multipart/alternative; boundary="_000_56FB15AFE08E1242B0736CBDCE6E856108092557stntexmb12cisne_" MIME-Version: 1.0 Cc: "sip-overload-bounces@ietf.org" , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" , "sip-overload@ietf.org" Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.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, 10 Jul 2013 14:24:04 -0000 --_000_56FB15AFE08E1242B0736CBDCE6E856108092557stntexmb12cisne_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SmFuZXQsDQoNCkkgYWdyZWUgd2l0aCB5b3UgdGhhdCB1c2luZyB0aGUgZXhpc3RpbmcgcGFyYW1l dGVycyB3b3VsZCBjYXVzZSBwcm9ibGVtcyBmb3IgdGhlIGxvc3MgYmFzZWQgdmVyc2lvbiBhbmQg YWRkaW5nIG5ldyBwYXJhbWV0ZXJzIGF0IHRoaXMgc3RhZ2Ugd291bGQgZGVsYXkgdGhpcyBJLUQu ICBJ4oCZbGwgZHJvcCB0aGlzIGNvbW1lbnQuDQoNCkphbWVzDQoNCkZyb206IEphbmV0IFAgR3Vu biBbbWFpbHRvOmpndW5uNkBjc2MuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDEwLCAyMDEz IDEwOjEyIEFNDQpUbzogWXUsIEphbWVzDQpDYzogZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0 ZS1jb250cm9sLmFsbEB0b29scy5pZXRmLm9yZzsgTk9FTCwgRVJJQyBDIChFUklDIEMpOyBzaXAt b3ZlcmxvYWRAaWV0Zi5vcmc7IHNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW3NpcC1vdmVybG9hZF0gZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9s LTA0LnR4dA0KDQpJIHRob3VnaHQgSSB1bmRlcnN0b29kIHRoYXQgdGhlIHBvaW50IG9mIHRoaXMg cmF0ZSBiYXNlZCBhbGdvcml0aG0gSUQgIHdhcyB0byAicGlnZ3kgYmFjayIgb24gdGhlIGNvbW11 bmljYXRpb25zICBwcm90b2NvbCBwYXJhbWV0ZXJzIGRlZmluZWQgaW4gdGhlIGxvc3MgYmFzZWQg YWxnb3JpdGhtIElEIChvYywgb2MtYWxnbywgb2MtbnVtLCBvYy12YWxpZGl0eSwgb2Mtc2VxKSwg aW50cm9kdWNpbmcgbmV3IHBhcmFtZXRlciBWQUxVRVMsIGJ1dCBub3QgbmV3IHBhcmFtZXRlcnMu DQoNCkluIG9yZGVyIHRvIGNvbnZleSB0aGUgImN1cnJlbnQgYXJyaXZhbCByYXRlIG9mIG1lc3Nh Z2VzIGludGVuZGVkIGZvciB5b3UiIGZyb20gdGhlIGNsaWVudCB0byB0aGUgc2VydmVyLCB5b3Ug d291bGQgbmVlZCB0byBhZGQgbmV3IHBhcmFtZXRlcnMsICBvciB1c2UgZXhpc3RpbmcgcGFyYW1l dGVycyBpbiBhIHdheSB0aGF0IHdvdWxkIGNhdXNlIHByb2JsZW1zIGZvciAgdGhlIGxvc3MgYmFz ZWQgdmVyc2lvbi4NCg0KRnVydGhlcm1vcmUsIHdoZW4gdGhlIGNsaWVudCBpcyByZWNlaXZpbmcs IGFuZCB0aGVyZWZvcmUgc2VuZGluZywgbWVzc2FnZWQgaW50ZW5kZWQgZm9yIHRoaXMgc2VydmVy LCBhdCBhIHJhdGUgbG93ZXIgdGhhbiB0aGUgY3VycmVudCBzcGVjaWZpZWQgcmF0ZSBsaW1pdCwg dGhlIHNlcnZlciBjYW4gZGVkdWNlIHRoYXQgZGlyZWN0bHksIGFuZCBhZGp1c3QgdGhlIHNwZWNp ZmljIHJhdGUgbGltaXQgaXQgc2VuZHMgdG8gKHRoaXMgb3Igb3RoZXIpIGNsaWVudHMgaWYgaXQg d2FudHMgdG8uDQoNCkkgdGhpbmsgdGhhdCB3b3VsZCBiZSBtdWNoICJjbGVhbmVyIiAoYW5kIHBy b2JhYmx5IG1vcmUgZWZmZWN0aXZlIGFzIHdlbGwpLCB0aGFuIGFkZGluZyBuZXcgcGFyYW1ldGVy cywgb3IgbWFraW5nIG1ham9yIGNoYW5nZXMgdG8gdGhlIGNvbW11bmljYXRpb25zIHByb3RvY29s IGluIHRoZSBsb3NzIGJhc2VkIGFsZ29yaXRobSBJRC4NCg0KSmFuZXQNCg0KDQoNCnNpcC1vdmVy bG9hZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9y Zz4gd3JvdGUgb24gMDcvMTAvMjAxMyAwOTowMDozNSBBTToNCg0KPiBGcm9tOiAiWXUsIEphbWVz IiA8amFtZXMueXVAbmV1c3Rhci5iaXo8bWFpbHRvOmphbWVzLnl1QG5ldXN0YXIuYml6Pj4NCj4g VG86ICJOT0VMLCBFUklDIEMgKEVSSUMgQykiIDxlY25vZWxAcmVzZWFyY2guYXR0LmNvbTxtYWls dG86ZWNub2VsQHJlc2VhcmNoLmF0dC5jb20+Pg0KPiBDYzogInNpcC1vdmVybG9hZC1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZz4iIDxzaXAtb3Zl cmxvYWQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5v cmc+PiwNCj4gImRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLXJhdGUtY29udHJvbC5hbGxAdG9vbHMu aWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLXJhdGUtY29udHJvbC5hbGxA dG9vbHMuaWV0Zi5vcmc+IiA8ZHJhZnQtDQo+IGlldGYtc29jLW92ZXJsb2FkLXJhdGUtY29udHJv bC5hbGxAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmlldGYtc29jLW92ZXJsb2FkLXJhdGUtY29udHJv bC5hbGxAdG9vbHMuaWV0Zi5vcmc+PiwgInNpcC0NCj4gb3ZlcmxvYWRAaWV0Zi5vcmc8bWFpbHRv Om92ZXJsb2FkQGlldGYub3JnPiIgPHNpcC1vdmVybG9hZEBpZXRmLm9yZzxtYWlsdG86c2lwLW92 ZXJsb2FkQGlldGYub3JnPj4NCj4gRGF0ZTogMDcvMTAvMjAxMyAwOTowMSBBTQ0KPiBTdWJqZWN0 OiBSZTogW3NpcC1vdmVybG9hZF0gZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9s LTA0LnR4dA0KPiBTZW50IGJ5OiBzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86 c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc+DQo+DQo+IE5vZWwsDQo+DQo+IEkgbWVudGlv bmVkIGluIG15IG1lc3NhZ2UgdG8gSmFuZXQgb24gNy8yOg0KPg0KPiBGb3IgdGhlIHJhdGUgY29u dHJvbCwgdGhlIHNlcnZlciBjb3VsZCBjYWxjdWxhdGUgdGhlIGFycml2YWwgcmF0ZQ0KPiBmcm9t IGVhY2ggY29tbXVuaWNhdGluZyBjbGllbnQgc28gdGhhdCBpdCBjb3VsZCBhbGxvY2F0ZSB0aGUg b3ZlcmFsbA0KPiB0YXJnZXQgU0lQIHJlcXVlc3QgcmF0ZSB0byB0aGUgY2xpZW50cyBiYXNlZCBv biB0aGVpciBhcnJpdmFsIHJhdGVzDQo+IGtub3duIHRvIHRoZSBzZXJ2ZXIuICBCdXQgYW5vdGhl ciBvcHRpb24gaXMgZm9yIHRoZSBjbGllbnQgdG8NCj4g4oCcb3B0aW9uYWxseeKAnSBpbmNsdWRl IGl0cyBjYWxjdWxhdGVkIGFycml2YWwgcmF0ZSBpbiBpdHMgcmVxdWVzdCB0bw0KPiB0aGUgc2Vy dmVyIHdoZW4gcmF0ZSBjb250cm9sIHJlbGF0ZWQgcGFyYW1ldGVycyBhcmUgcHJlc2VudC4gIFNo b3VsZA0KPiB0aGlzIG9wdGlvbiBiZSBldmFsdWF0ZWQvaW5jbHVkZWQgdG8gcmVsaWV2ZSB0aGUg c2VydmVyIGZyb20gZG9pbmcNCj4gdGhlIGFycml2YWwgcmF0ZSBjYWxjdWxhdGlvbnMuICBUaGlz IHdvdWxkIGJlIGJlbmVmaWNpYWwgdG8gYSBzZXJ2ZXINCj4gd2hlbiBpdCByZWNlaXZlcyB0aGUg cmVxdWVzdHMgZnJvbSBtYW55IGNsaWVudHMuDQo+DQo+IEkgc3VnZ2VzdCB0aGF0IHRoZSBJLUQg YWRkcyB0aGF0IG9wdGlvbiB0byBhbGxvdyB0aGUgY2xpZW50IHRvDQo+IGluZGljYXRlIGl0cyBj dXJyZW50IGFycml2YWwgcmF0ZSAodG93YXJkcyB0aGUgcmVjZWl2aW5nIHNlcnZlcikgaW4NCj4g dGhlIFNJUCByZXF1ZXN0Lg0KPg0KPiBKYW1lcw0KPg0KPiBGcm9tOiBOT0VMLCBFUklDIEMgKEVS SUMgQykgW21haWx0bzplY25vZWxAcmVzZWFyY2guYXR0LmNvbV0NCj4gU2VudDogVHVlc2RheSwg SnVseSAwOSwgMjAxMyA0OjQ0IFBNDQo+IFRvOiBZdSwgSmFtZXM7IEphbmV0IFAgR3Vubg0KPiBD Yzogc2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNpcC1vdmVybG9hZC1ib3Vu Y2VzQGlldGYub3JnPjsgZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS0NCj4gY29udHJvbC5h bGxAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmNvbnRyb2wuYWxsQHRvb2xzLmlldGYub3JnPjsgc2lw LW92ZXJsb2FkQGlldGYub3JnPG1haWx0bzpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmc+DQo+IFN1Ympl Y3Q6IFJFOiBbc2lwLW92ZXJsb2FkXSBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1yYXRlLWNvbnRy b2wtMDQudHh0DQo+DQo+IEphbmV0LCBKYW1lcywNCj4NCj4gVGhhbmtzIHlvdSBmb3IgeW91ciB2 YWx1YWJsZSBjb21tZW50cyBhbmQgZGlzY3Vzc2lvbi4gIEkgdHJpZWQgdG8NCj4gY2FwdHVyZSBh bGwgcmVzb2x1dGlvbiBpbiB0aGUgZm9sbG93aW5nIHRleHQgKGJhc2VkIG9uIEphbWVzIHdvcmQN Cj4gZG9jdW1lbnQgd2l0aCB0cmFjayBjaGFuZ2VzIGFuZCBpbWJlZGRlZCBjb21tZW50cyBlbmFi bGVkKS4NCj4NCj4gKyBBYnN0cmFjdCBzZWN0aW9uOg0KPiAtIEFncmVlZCB3aXRoIHN1Z2dlc3Rl ZCBjaGFuZ2VzDQo+IC0gUGxlYXNlIG5vdGUgSSB3aWxsIGFsc28gbmVlZCB0byBtYWtlIGZ1cnRo ZXIgY2hhbmdlcyB0byByZW1vdmUgYWxsDQo+IHJlZmVyZW5jZXMgcGVyIENocmlzdGVyIEhvbG1i ZXJnIGNvbW1lbnQNCj4NCj4gKyBTZWN0aW9uIDE6DQo+IC0gQWdyZWVkIHdpdGggc3VnZ2VzdGVk IGNoYW5nZXMNCj4NCj4gKyBTZWN0aW9uIDMuMToNCj4gLSBBZ3JlZWQgd2l0aCBzdWdnZXN0ZWQg Y2hhbmdlcw0KPg0KPiArIFNlY3Rpb24gMy4yOiAtIFBsZWFzZSBub3RlIHRoZSBzZWN0aW9uIHRp dGxlIHdpbGwgYmVjb21lIOKAnFZpYQ0KPiBoZWFkZXIgZmllbGQgcGFyYW1ldGVycyBmb3Igb3Zl cmxvYWQgY29udHJvbCDigJwgcGVyIENocmlzdGVyIEhvbG1iZXJnIGNvbW1lbnQNCj4gLSBBZ3Jl ZWQgd2l0aCBzdWdnZXN0ZWQgY2hhbmdlcyBleGNsdWRpbmcgdGl0bGUgdGhhdCB3aWxsIGNoYW5n ZSBwZXINCj4gcHJldmlvdXMgYnVsbGV0DQo+DQo+ICsgU2VjdGlvbiAzLjM6DQo+IC0gQWdyZWVk IHdpdGggc3VnZ2VzdGVkIGNoYW5nZXMNCj4NCj4gKyBTZWN0aW9uIDMuNDoNCj4gLSBJRDogICJO b3RlIHRoYXQgdGhlIHRhcmdldCBTSVAgcmVxdWVzdCByYXRlIGlzIGEgbWF4IHJhdGUgdGhhdCBt YXkNCj4gbm90IGJlIGF0dGFpbmVkIGJ5IHRoZSBhcnJpdmFsIHJhdGUgYXQgdGhlIGNsaWVudCwg YW5kIHRoZSBzZXJ2ZXINCj4gY2Fubm90IGFzc3VtZSB0aGF0IGl0IHdpbGwuIg0KPiAgICBbSlld IE5vdCBjbGVhciB3aGF0IHZhbHVlIHRoaXMgcGFyYWdyYXBoIHRyaWVzIHRvIGFkZC4gIElzIGl0 DQo+IHNheWluZyB0aGF0IHRoZSBjbGllbnQncyBhcnJpdmFsIHJhdGUgbWF5IGJlIGxvd2VyIHRo YW4gdGhlIHRhcmdldA0KPiBTSVAgcmVxdWVzdCByYXRlPw0KPiAgICBbSkddIFllcyArIHN1cHBv cnRpbmcgZXhhbXBsZSAoc2VlIGJlbG93IGluIHRocmVhZCkNCj4gICBBZ3JlZWQgd2l0aCBKYW5l dCBhbmQgc3VwcG9ydGluZyBleGFtcGxlLiBQZXIgSmFtZXMgcmVxdWVzdCwgSQ0KPiB3aWxsIGFk ZCB0aGUgZm9sbG93aW5nIHRleHQgKGluc3BpcmVkIGZyb20gSmFuZXTigJlzIGlsbHVzdHJhdGl2 ZSBleGFtcGxlKToNCj4gICAg4oCcSW4gb3RoZXIgd29yZHMsIHdoZW4gbXVsdGlwbGUgY2xpZW50 cyBhcmUgYmVpbmcgY29udHJvbGxlZCBieSBhbg0KPiBvdmVybG9hZGVkIHNlcnZlciwgYXQgYW55 IGdpdmVuIHRpbWUgc29tZSBjbGllbnRzIG1heSByZWNlaXZlDQo+IHJlcXVlc3RzIGF0IGEgcmF0 ZSBiZWxvdyBpdHMgdGFyZ2V0IFNJUCByZXF1ZXN0IHJhdGUgd2hpbGUgb3RoZXJzDQo+IGFib3Zl IHRoYXQgdGFyZ2V0IHJhdGUuIEJ1dCB0aGUgcmVzdWx0aW5nIHJlcXVlc3QgcmF0ZSBwcmVzZW50 ZWQgdG8NCj4gdGhlIG92ZXJsb2FkZWQgc2VydmVyIHdpbGwgY29udmVyZ2UgdG93YXJkcyB0aGUg dGFyZ2V0IFNJUCByZXF1ZXN0IHJhdGUu4oCdDQo+IC0gQWdyZWVkIHdpdGggb3RoZXIgc3VnZ2Vz dGVkIGNoYW5nZXMNCj4NCj4gKyBTZWN0aW9uIDMuNS4xOg0KPiAtIElEOiDigJxBbmQgdGhlIGxh cmdlciB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIFRBVTEgYW5kIFRBVTIsIHRoZQ0KPiBjbG9zZXIg dG8gdGhlIGNvbnRyb2wgaXMgdG8gc3RyaWN0IHByaW9yaXR5LuKAnQ0KPiAgIFtKWV0gU3VnZ2Vz dCBjaGFuZ2luZyBpbnRvIOKAnEFuZCB0aGUgbGFyZ2VyIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4N Cj4gVEFVMSBhbmQgVEFVMiwgdGhlIGNsb3NlciB0aGUgY29udHJvbCBpcyB0byBzdHJpY3QgcHJp b3JpdHkgcXVldWluZy7igJ0NCj4gICBbSkddIFN1Z2dlc3QgY2hhbmdpbmcgaW50byDigJxBbmQg dGhlIGxhcmdlciB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuDQo+IFRBVTEgYW5kIFRBVTIsIHRoZSBj bG9zZXIgdGhlIGNvbnRyb2wgaXMgdG8gc3RyaWN0IHByaW9yaXR5IHRyZWF0bWVudC7igJ0NCj4g ICBbRU5dIEFncmVlZCB3aXRoIEphbmV04oCZcyBzdWdnZXN0aW9uDQo+IC0gQWdyZWVkIHdpdGgg b3RoZXIgc3VnZ2VzdGVkIGNoYW5nZXMNCj4NCj4gKyBTZWN0aW9uIDQ6DQo+IC0gQWdyZWVkIHdp dGggc3VnZ2VzdGVkIGNoYW5nZXMNCj4NCj4gKyBTZWN0aW9uIDU6DQo+IC0gUGxlYXNlIG5vdGUg dGhhdCBiYXNlZCBjb21tZW50cyBmcm9tIHBlciBDaHJpc3RlciBIb2xtYmVyZyBhbmQNCj4gSmFu ZXQgR3VubiwgdGhlIGZvbGxvd2luZyB3YXMgdGVudGF0aXZlbHkgYWdyZWVkDQo+ICAgIFJlcGxh Y2Ugb2MtdmFsdWUgPSAiTmFOIiAvIG9jLW51bSAgICBieSAgICBvYyA9ICJvYyIgW0VRVUFMIG9j LW51bV0NCj4gLSBBZ3JlZWQgd2l0aCBvdGhlciBzdWdnZXN0ZWQgY2hhbmdlDQo+DQo+ICsgU2Vj dGlvbiA3Og0KPiAtIFtKWV0gU2hvdWxkIOKAnHJhdGXigJ0gaW4gb2MtYWxnbyBiZSByZWdpc3Rl cmVkIHdpdGggSUFOQT8NCj4gICBUaGlzIGlzc3VlIG5lZWRzIHRvIGJlIGFkZHJlc3NlZCBieSBk cmFmdC1pZXRmLXNvYy1vdmVybG9hZC1jb250cm9sIGF1dGhvcnMNCj4NCj4gUGxlYXNlIG5vdGUg SSB3aWxsIHdhaXQgdW50aWwgZXhwaXJhdGlvbiBvZiBXR0xDIHByaW9yIHVwZGF0aW5nIG91cg0K PiBkcmFmdCBSRkMuIE9uY2UgYWdhaW4geW91ciBjb21tZW50cyBhbmQvb3Igc3VnZ2VzdGlvbnMg YXJlIG1vc3QgYXBwcmVjaWF0ZWQuDQo+DQo+IFRoYW5rcywNCj4NCj4gRXJpYyBOb2VsDQo+IEFU JlQgTGFicywgSW5jLg0KPiBSZXRoaW5rIFBvc3NpYmxlDQo+DQo+IE5ldHdvcmsgRGVzaWduIGFu ZCBQZXJmb3JtYW5jZSBBbmFseXNpcw0KPiAyMDAgU291dGggTGF1cmVsIEF2ZW51ZSwgRDUtM0Qx OQ0KPiBNaWRkbGV0b3duLCBOSiAwNzc0OA0KPiBQOiA3MzIuNDIwLjQxNzQNCj4gZWNub2VsQGF0 dC5jb208bWFpbHRvOmVjbm9lbEBhdHQuY29tPg0KPg0KPiBGcm9tOiBzaXAtb3ZlcmxvYWQtYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWls dG86c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmddDQo+IE9uIEJlaGFsZiBPZiBZdSwgSmFt ZXMNCj4gU2VudDogVHVlc2RheSwgSnVseSAwMiwgMjAxMyA5OjQyIEFNDQo+IFRvOiBKYW5ldCBQ IEd1bm4NCj4gQ2M6IHNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzaXAtb3Zl cmxvYWQtYm91bmNlc0BpZXRmLm9yZz47IGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLXJhdGUtDQo+ IGNvbnRyb2wuYWxsQHRvb2xzLmlldGYub3JnPG1haWx0bzpjb250cm9sLmFsbEB0b29scy5pZXRm Lm9yZz47IHNpcC1vdmVybG9hZEBpZXRmLm9yZzxtYWlsdG86c2lwLW92ZXJsb2FkQGlldGYub3Jn Pg0KPiBTdWJqZWN0OiBSZTogW3NpcC1vdmVybG9hZF0gZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQt cmF0ZS1jb250cm9sLTA0LnR4dA0KPg0KPiBKYW5ldCwNCj4NCj4gRm9yIG15IGNvbW1lbnQgb24g c2VjdGlvbiAzLjQgKHRoZSBmaXJzdCBvbmUgYmVsb3cpLCB0aGUgY3VycmVudA0KPiB0ZXh0IGRv ZXMgbm90IHByb3ZpZGUgYW55IHZhbHVlLiAgVGhlIGNsaWVudOKAmXMgYXJyaXZhbCByYXRlIGNv dWxkIGJlDQo+IHdlbGwgYmVsb3cgdGhlIHRhcmdldCBTSVAgcmVxdWVzdCByYXRlIHdoZW4gaXRz IGxvYWQgaXMgbGlnaHQgc28gdGhlDQo+IGZhY3QgdGhhdCB0aGUgY2xpZW50IG1heSBub3QgYWNo aWV2ZSB0aGUgdGFyZ2V0IFNJUCByZXF1ZXN0IHJhdGUNCj4gKHRoZSBtYXguIHJhdGUgaXQgaXMg YWxsb3dlZCB0byBzZW5kIHRvIHRoZSBzZXJ2ZXIpIGlzIHdlbGwNCj4gdW5kZXJzdG9vZC4gIEJ1 dCB3aXRoIHlvdXIgZXhwbGFuYXRpb24gb24gdGhlIOKAnGRlbHRh4oCdIHBhcnQsIHRoZSB0ZXh0 DQo+IHRoZW4gbWFrZXMgc2Vuc2UuICBQbGVhc2UgYWRkIHNvbWUgZGlzY3Vzc2lvbnMgb24gdGhl IOKAnGRlbHRh4oCdIGFzcGVjdA0KPiBzbyB0aGF0IGV2ZW4gaWYgdGhlIGF2ZXJhZ2UgYXJyaXZh bCByYXRlIGF0IHRoZSBjbGllbnQgaXMgaGlnaGVyDQo+IHRoYW4gdGhlIHRhcmdldCBTSVAgcmVx dWVzdCByYXRlIHRoZSBjbGllbnQgYXQgdGltZXMgbWF5IG5vdCBzZW5kDQo+IG1vcmUgdGhhbiB3 aGF0IHRoZSB0YXJnZXQgU0lQIHJlcXVlc3QgcmF0ZSBhbGxvd3MgZHVlIHRvIHRoZQ0KPiBmbHVj dHVhdGlvbiBvZiB0aGUgYXJyaXZpbmcgcmVxdWVzdHMgYXQgdGhlIGNsaWVudC4NCj4NCj4gRm9y IHRoZSBjb21tZW50IG9uIHNlY3Rpb24gMy41LjEsIEkgYWdyZWUgd2l0aCB5b3VyIHByb3Bvc2Vk IGNoYW5nZS4NCj4NCj4gRm9yIHRoZSByYXRlIGNvbnRyb2wsIHRoZSBzZXJ2ZXIgY291bGQgY2Fs Y3VsYXRlIHRoZSBhcnJpdmFsIHJhdGUNCj4gZnJvbSBlYWNoIGNvbW11bmljYXRpbmcgY2xpZW50 IHNvIHRoYXQgaXQgY291bGQgYWxsb2NhdGUgdGhlIG92ZXJhbGwNCj4gdGFyZ2V0IFNJUCByZXF1 ZXN0IHJhdGUgdG8gdGhlIGNsaWVudHMgYmFzZWQgb24gdGhlaXIgYXJyaXZhbCByYXRlcw0KPiBr bm93biB0byB0aGUgc2VydmVyLiAgQnV0IGFub3RoZXIgb3B0aW9uIGlzIGZvciB0aGUgY2xpZW50 IHRvDQo+IOKAnG9wdGlvbmFsbHnigJ0gaW5jbHVkZSBpdHMgY2FsY3VsYXRlZCBhcnJpdmFsIHJh dGUgaW4gaXRzIHJlcXVlc3QgdG8NCj4gdGhlIHNlcnZlciB3aGVuIHJhdGUgY29udHJvbCByZWxh dGVkIHBhcmFtZXRlcnMgYXJlIHByZXNlbnQuICBTaG91bGQNCj4gdGhpcyBvcHRpb24gYmUgZXZh bHVhdGVkL2luY2x1ZGVkIHRvIHJlbGlldmUgdGhlIHNlcnZlciBmcm9tIGRvaW5nDQo+IHRoZSBh cnJpdmFsIHJhdGUgY2FsY3VsYXRpb25zLiAgVGhpcyB3b3VsZCBiZSBiZW5lZmljaWFsIHRvIGEg c2VydmVyDQo+IHdoZW4gaXQgcmVjZWl2ZXMgdGhlIHJlcXVlc3RzIGZyb20gbWFueSBjbGllbnRz Lg0KPg0KPiBKYW1lcw0KPg0KPiBGcm9tOiBKYW5ldCBQIEd1bm4gW21haWx0bzpqZ3VubjZAY3Nj LmNvbV0NCj4gU2VudDogRnJpZGF5LCBKdW5lIDI4LCAyMDEzIDM6MzQgUE0NCj4gVG86IFl1LCBK YW1lcw0KPiBDYzogZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLmFsbEB0b29s cy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLmFs bEB0b29scy5pZXRmLm9yZz47IHNpcC0NCj4gb3ZlcmxvYWRAaWV0Zi5vcmc8bWFpbHRvOm92ZXJs b2FkQGlldGYub3JnPjsgc2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNpcC1v dmVybG9hZC1ib3VuY2VzQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW3NpcC1vdmVybG9hZF0g ZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLTA0LnR4dA0KPg0KPiBKYW1lcywN Cj4NCj4gSXQgaXMgYSBsaXR0bGUgaGFyZCB0byByZXNwb25kIGluIGVtYWlsIHdoZW4geW91ciBj b21tZW50cyBhcmUgaW4gYQ0KPiBzZXBhcmF0ZSBkb2N1bWVudCwgYnV0IGhlcmUgZ29lcy4NCj4N Cj4NCj4gc2VjdGlvbiAzLjQNCj4gSUQgc2F5czoNCj4gIk5vdGUgdGhhdCB0aGUgdGFyZ2V0IFNJ UCByZXF1ZXN0IHJhdGUgaXMgYSBtYXggcmF0ZSB0aGF0IG1heSBub3QgYmUNCj4gICAgYXR0YWlu ZWQgYnkgdGhlIGFycml2YWwgcmF0ZSBhdCB0aGUgY2xpZW50LCBhbmQgdGhlIHNlcnZlciBjYW5u b3QNCj4gICAgYXNzdW1lIHRoYXQgaXQgd2lsbC4iDQo+DQo+IFlvdXIgY29tbWVudCA6DQo+ICJO b3QgY2xlYXIgd2hhdCB2YWx1ZSB0aGlzIHBhcmFncmFwaCB0cmllcyB0byBhZGQuICBJcyBpdCBz YXlpbmcNCj4gdGhhdCB0aGUgY2xpZW50J3MgYXJyaXZhbCByYXRlIG1heSBiZSBsb3dlciB0aGFu IHRoZSB0YXJnZXQgU0lQDQo+IHJlcXVlc3QgcmF0ZT8gICINCj4NCj4gWWVzLg0KPg0KPiBTdXBw b3NlIHRoZSBzZXJ2ZXIgd2FudCB0byBsaW1pdCB0aGUgdG90YWwgcmF0ZSBvZiBhcnJpdmluZyBT SVANCj4gbWVzc2FnZXMgdG8gMTAwIC8gc2VjLCBhbmQgaGFzIDEwIGNsaWVudHMuICBFYWNoIGNs aWVudCBoYXMgYSBoaWdoDQo+IHZhcmlhbmNlIGluIGl0cyBtZXNzYWdlIHJhdGUsIGJ1dCB0b2dl dGhlciB0aGV5IGFyZSB3ZWxsIGFib3ZlIDEwMA0KPiBtZXNzYWdlcyBwZXIgc2VjDQo+DQo+IElm IGl0IHNldHMgdGhlIHJhdGUgYXQgMTAgbWVzc2FnZXMgcGVyIHNlY29uZCBmb3IgZWFjaCBvZiB0 aGUNCj4gY2xpZW50cywgaXQgd2lsbCBhbG1vc3QgY2VydGFpbmx5IGVuZCB1cCAgd2l0aCBhbiBv dmVyYWxsIGF2ZXJhZ2Ugb2YNCj4gbGVzcyB0aGFuIDEwMCBtZXNzYWdlcyBwZXIgc2VjLCBiZWNh dXNlIHNvbWUgY2xpZW50cyB3aWxsIGJlIGluIGENCj4gImx1bGwiIHdoaWxlIG90aGVycyBhcmUg YnVzeS4gIFRoaXMgaXMgZ29vZCBmcm9tIGEgdGhyb3R0bGluZw0KPiBwZXJzcGVjdGl2ZSwgYnV0 LCBhc3N1bWluZyBtZXNzYWdlcyBhcmUgY29ycmVsYXRlZCB3aXRoIHJldmVudWUsDQo+IGJhZC93 YXN0ZWZ1bCBmcm9tIGEgcmV2ZW51ZSwgb3Igb3ZlcmFsbCBwcm9kdWN0aXZpdHkgcGVyc3BlY3Rp dmUuDQo+IFNvIHRoZSBzZXJ2ZXIgbWlnaHQgd2FudCB0byBzZXQgdGhlIHJhdGUgcGVyIGNsaWVu dCB0byAxMCArIGRlbHRhLA0KPiB3aGVyZSBkZWx0YSBpcyBnb2luZyB0byBiZSB2ZXJ5IHNwZWNp ZmljIHRvIG9wZXJhdGluZyBlbnZpcm9ubWVudC4NCj4NCj4gLS0tDQo+IEluIHNlY3Rpb24gIDMu NS4xLCBib3R0b20gb2YgcGFnZSA4DQo+IElEIHNheXM6DQo+ICJBbmQgdGhlIGxhcmdlcg0KPiAg ICB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIFRBVTEgYW5kIFRBVTIsIHRoZSBjbG9zZXIgdG8gdGhl IGNvbnRyb2wgaXMNCj4gICAgdG8gc3RyaWN0IHByaW9yaXR5LiINCj4NCj4gWW91IHByb3Bvc2Ug Y2hhbmdpbmcgaXQgdG86DQo+ICJBbmQgdGhlIGxhcmdlcg0KPiAgICB0aGUgZGlmZmVyZW5jZSBi ZXR3ZWVuIFRBVTEgYW5kIFRBVTIsIHRoZSBjbG9zZXIgIHRoZSBjb250cm9sIGlzDQo+ICAgIHRv IHN0cmljdCBwcmlvcml0eSBxdWV1aW5nLiINCj4NCj4gSSBhZ3JlZSB3aXRoIHRha2luZyBvdXQg dGhlIHJlZHVuZGFudCAidG8iLiAgQnV0IEkgZGlzYWdyZWUgd2l0DQo+IGFkZGluZyAicXVldWlu ZyIuICBUaGVyZSBpcyBubyBxdWV1aW5nLCBwcmlvcml0eSBvciBvdGhlcndpc2UgaW52b2x2ZWQu DQo+DQo+IFlvdSBjb3VsZCBzYXk6DQo+ICJBbmQgdGhlIGxhcmdlcg0KPiAgICB0aGUgZGlmZmVy ZW5jZSBiZXR3ZWVuIFRBVTEgYW5kIFRBVTIsIHRoZSBjbG9zZXIgIHRoZSBjb250cm9sIGlzDQo+ ICAgIHRvIHN0cmljdCBwcmlvcml0eSB0cmVhdG1lbnQuIg0KPg0KPiB3aGVyZSAiIHN0cmljdCBw cmlvcml0eSB0cmVhdG1lbnQiIHdvdWxkIHJlZmVyIHRvIHRoZSBjYXNlIHdoZXJlDQo+IG5vbi1w cmlvcml0eSBtZXNzYWdlcyBhcmUgcmVzdHJpY3RlZCB0byBhIHRvdGFsIChwcmlvcml0eSArIG5v bi0NCj4gcHJpb3JpdHkpIHJhdGUgb2YgMTAgbWVzc2FnZXMgcGVyIHNlY29uZCwgYnV0IHByaW9y aXR5IG1lc3NhZ2VzIGNhbg0KPiBjb250aW51ZSB0byBiZSBzZW50IGFzIGxvbmcgYXMgdGhlIHRv dGFsIChwcmlvcml0eSArIG5vbi1wcmlvcml0eSkNCj4gcmF0ZSBpcyBsZXNzIHRoYW4gMTIgbWVz c2FnZXMgcGVyIHNlY29uZC4NCj4NCj4gQXQgbGVhc3QsIEkgdGhpbmsgdGhhdCBpcyB3aGF0IEVy aWMgYW5kICBQaGlsaXAgYXJlIHRyeWluZyB0byBzYXkuDQo+DQo+IEphbmV0DQo+DQo+DQo+DQo+ DQo+DQo+IFRoaXMgaXMgYSBQUklWQVRFIG1lc3NhZ2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRl bmRlZCByZWNpcGllbnQsDQo+IHBsZWFzZSBkZWxldGUgd2l0aG91dCBjb3B5aW5nIGFuZCBraW5k bHkgYWR2aXNlIHVzIGJ5IGUtbWFpbCBvZiB0aGUNCj4gbWlzdGFrZSBpbiBkZWxpdmVyeS4gTk9U RTogUmVnYXJkbGVzcyBvZiBjb250ZW50LCB0aGlzIGUtbWFpbCBzaGFsbA0KPiBub3Qgb3BlcmF0 ZSB0byBiaW5kIENTQyB0byBhbnkgb3JkZXIgb3Igb3RoZXIgY29udHJhY3QgdW5sZXNzDQo+IHB1 cnN1YW50IHRvIGV4cGxpY2l0IHdyaXR0ZW4gYWdyZWVtZW50IG9yIGdvdmVybm1lbnQgaW5pdGlh dGl2ZQ0KPiBleHByZXNzbHkgcGVybWl0dGluZyB0aGUgdXNlIG9mIGUtbWFpbCBmb3Igc3VjaCBw dXJwb3NlLg0KPg0KPg0KPg0KPiBGcm9tOiAgICAgICAgIll1LCBKYW1lcyIgPGphbWVzLnl1QG5l dXN0YXIuYml6PG1haWx0bzpqYW1lcy55dUBuZXVzdGFyLmJpej4+DQo+IFRvOiAgICAgICAgInNp cC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0Bp ZXRmLm9yZz4iIDxzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2lwLW92ZXJs b2FkLWJvdW5jZXNAaWV0Zi5vcmc+PiwgIg0KPiBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1yYXRl LWNvbnRyb2wuYWxsQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLXNvYy1vdmVybG9h ZC1yYXRlLWNvbnRyb2wuYWxsQHRvb2xzLmlldGYub3JnPiIgPGRyYWZ0LQ0KPiBpZXRmLXNvYy1v dmVybG9hZC1yYXRlLWNvbnRyb2wuYWxsQHRvb2xzLmlldGYub3JnPG1haWx0bzppZXRmLXNvYy1v dmVybG9hZC1yYXRlLWNvbnRyb2wuYWxsQHRvb2xzLmlldGYub3JnPj4sICJzaXAtb3ZlcmxvYWRA aWV0Zi5vcmc8bWFpbHRvOnNpcC1vdmVybG9hZEBpZXRmLm9yZz4iIDwNCj4gc2lwLW92ZXJsb2Fk QGlldGYub3JnPG1haWx0bzpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmc+Pg0KPiBEYXRlOiAgICAgICAg MDYvMjgvMjAxMyAwODoxMCBBTQ0KPiBTdWJqZWN0OiAgICAgICAgW3NpcC1vdmVybG9hZF0gZHJh ZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLTA0LnR4dA0KPiBTZW50IGJ5OiAgICAg ICAgc2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNpcC1vdmVybG9hZC1ib3Vu Y2VzQGlldGYub3JnPg0KPg0KPg0KPg0KPg0KPiBTYWx2YXRvcmUsDQo+DQo+IFBsZWFzZSBzZWUg dGhlIGF0dGFjaG1lbnQgZm9yIG15IGNvbW1lbnRzLg0KPg0KPiBJIHBhc3RlZCB0aGUgdGV4dCB0 byBhIHdvcmQgZG9jdW1lbnQgdG8gdHJhY2Uvc2hvdyB0aGUgcHJvcG9zZWQNCj4gY2hhbmdlcyBh bmQgY29tbWVudHMuDQo+DQo+IFJlZ2FyZHMsDQo+DQo+IEphbWVzDQo+ICBbYXR0YWNobWVudCAi Y29tbWVudHMgb24gZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS0NCj4gY29udHJvbC0wNC5k b2N4IiBkZWxldGVkIGJ5IEphbmV0IFAgR3Vubi9VU0EvQ1NDXQ0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzaXAtb3ZlcmxvYWQgbWFpbGluZyBs aXN0DQo+IHNpcC1vdmVybG9hZEBpZXRmLm9yZzxtYWlsdG86c2lwLW92ZXJsb2FkQGlldGYub3Jn Pg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcC1vdmVybG9hZA0K Pg0KPiBObyB2aXJ1cyBmb3VuZCBpbiB0aGlzIG1lc3NhZ2UuDQo+IENoZWNrZWQgYnkgQVZHIC0g d3d3LmF2Zy5jb20NCj4gVmVyc2lvbjogMjAxMy4wLjI5MDQgLyBWaXJ1cyBEYXRhYmFzZTogMzIw NC82NDUyIC0gUmVsZWFzZSBEYXRlOiAwNi8zMC8xMw0KPg0KPiBObyB2aXJ1cyBmb3VuZCBpbiB0 aGlzIG1lc3NhZ2UuDQo+IENoZWNrZWQgYnkgQVZHIC0gd3d3LmF2Zy5jb20NCj4gVmVyc2lvbjog MjAxMy4wLjI5MDQgLyBWaXJ1cyBEYXRhYmFzZTogMzIwNC82NDc4IC0gUmVsZWFzZSBEYXRlOiAw Ny8wOS8xMw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBzaXAtb3ZlcmxvYWQgbWFpbGluZyBsaXN0DQo+IHNpcC1vdmVybG9hZEBpZXRmLm9yZzxt YWlsdG86c2lwLW92ZXJsb2FkQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NpcC1vdmVybG9hZA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCk5vIHZpcnVzIGZvdW5kIGluIHRoaXMgbWVzc2FnZS4NCkNoZWNrZWQgYnkgQVZHIC0gd3d3 LmF2Zy5jb208aHR0cDovL3d3dy5hdmcuY29tPg0KVmVyc2lvbjogMjAxMy4wLjI5MDQgLyBWaXJ1 cyBEYXRhYmFzZTogMzIwNC82NDc4IC0gUmVsZWFzZSBEYXRlOiAwNy8wOS8xMw0K --_000_56FB15AFE08E1242B0736CBDCE6E856108092557stntexmb12cisne_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQp0dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SmFuZXQsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5JIGFncmVlIHdpdGggeW91IHRoYXQgdXNpbmcgdGhlIGV4aXN0aW5nIHBhcmFtZXRlcnMgd291 bGQgY2F1c2UgcHJvYmxlbXMgZm9yIHRoZSBsb3NzIGJhc2VkIHZlcnNpb24gYW5kIGFkZGluZyBu ZXcgcGFyYW1ldGVycyBhdCB0aGlzIHN0YWdlIHdvdWxkIGRlbGF5IHRoaXMNCiBJLUQuJm5ic3A7 IEnigJlsbCBkcm9wIHRoaXMgY29tbWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkphbWVzPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBK YW5ldCBQIEd1bm4gW21haWx0bzpqZ3VubjZAY3NjLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBX ZWRuZXNkYXksIEp1bHkgMTAsIDIwMTMgMTA6MTIgQU08YnI+DQo8Yj5Ubzo8L2I+IFl1LCBKYW1l czxicj4NCjxiPkNjOjwvYj4gZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLmFs bEB0b29scy5pZXRmLm9yZzsgTk9FTCwgRVJJQyBDIChFUklDIEMpOyBzaXAtb3ZlcmxvYWRAaWV0 Zi5vcmc7IHNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbc2lwLW92ZXJsb2FkXSBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1yYXRlLWNvbnRyb2wt MDQudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkkgdGhvdWdodCBJIHVuZGVyc3Rvb2QgdGhhdCB0aGUgcG9pbnQgb2Yg dGhpcyByYXRlIGJhc2VkIGFsZ29yaXRobSBJRCAmbmJzcDt3YXMgdG8gJnF1b3Q7cGlnZ3kgYmFj ayZxdW90OyBvbiB0aGUgY29tbXVuaWNhdGlvbnMgJm5ic3A7cHJvdG9jb2wgcGFyYW1ldGVycyBk ZWZpbmVkIGluIHRoZSBsb3NzIGJhc2VkIGFsZ29yaXRobSBJRA0KIChvYywgb2MtYWxnbywgb2Mt bnVtLCBvYy12YWxpZGl0eSwgb2Mtc2VxKSwgaW50cm9kdWNpbmcgbmV3IHBhcmFtZXRlciBWQUxV RVMsIGJ1dCBub3QgbmV3IHBhcmFtZXRlcnMuPC9zcGFuPg0KPGJyPg0KPGJyPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+SW4gb3JkZXIgdG8gY29udmV5IHRoZSAmcXVvdDtjdXJyZW50IGFy cml2YWwgcmF0ZSBvZiBtZXNzYWdlcyBpbnRlbmRlZCBmb3IgeW91JnF1b3Q7IGZyb20gdGhlIGNs aWVudCB0byB0aGUgc2VydmVyLCB5b3Ugd291bGQgbmVlZCB0byBhZGQgbmV3IHBhcmFtZXRlcnMs ICZuYnNwO29yIHVzZSBleGlzdGluZyBwYXJhbWV0ZXJzIGluIGEgd2F5IHRoYXQgd291bGQgY2F1 c2UNCiBwcm9ibGVtcyBmb3IgJm5ic3A7dGhlIGxvc3MgYmFzZWQgdmVyc2lvbi48L3NwYW4+IDxi cj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZ1cnRoZXJtb3JlLCB3aGVuIHRo ZSBjbGllbnQgaXMgcmVjZWl2aW5nLCBhbmQgdGhlcmVmb3JlIHNlbmRpbmcsIG1lc3NhZ2VkIGlu dGVuZGVkIGZvciB0aGlzIHNlcnZlciwgYXQgYSByYXRlIGxvd2VyIHRoYW4gdGhlIGN1cnJlbnQg c3BlY2lmaWVkIHJhdGUgbGltaXQsIHRoZSBzZXJ2ZXIgY2FuIGRlZHVjZSB0aGF0IGRpcmVjdGx5 LA0KIGFuZCBhZGp1c3QgdGhlIHNwZWNpZmljIHJhdGUgbGltaXQgaXQgc2VuZHMgdG8gKHRoaXMg b3Igb3RoZXIpIGNsaWVudHMgaWYgaXQgd2FudHMgdG8uPC9zcGFuPg0KPGJyPg0KPGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SSB0aGluayB0aGF0IHdvdWxkIGJlIG11Y2ggJnF1b3Q7 Y2xlYW5lciZxdW90OyAoYW5kIHByb2JhYmx5IG1vcmUgZWZmZWN0aXZlIGFzIHdlbGwpLCB0aGFu IGFkZGluZyBuZXcgcGFyYW1ldGVycywgb3IgbWFraW5nIG1ham9yIGNoYW5nZXMgdG8gdGhlIGNv bW11bmljYXRpb25zIHByb3RvY29sIGluIHRoZSBsb3NzIGJhc2VkIGFsZ29yaXRobSBJRC48L3Nw YW4+DQo8YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5KYW5ldDxicj4NCjxi cj4NCjwvc3Bhbj48YnI+DQo8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi PjxhIGhyZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZyI+c2lwLW92ZXJs b2FkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IHdyb3RlIG9uIDA3LzEwLzIwMTMgMDk6MDA6MzUgQU06 PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjxicj4NCjx0dD4mZ3Q7IEZyb206ICZxdW90O1l1 LCBKYW1lcyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmphbWVzLnl1QG5ldXN0YXIuYml6Ij5q YW1lcy55dUBuZXVzdGFyLmJpejwvYT4mZ3Q7PC90dD48L3NwYW4+DQo8YnI+DQo8dHQ+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsgVG86ICZxdW90O05PRUwsIEVSSUMgQyAoRVJJ QyBDKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVjbm9lbEByZXNlYXJjaC5hdHQuY29tIj5l Y25vZWxAcmVzZWFyY2guYXR0LmNvbTwvYT4mZ3Q7PC9zcGFuPjwvdHQ+DQo8YnI+DQo8dHQ+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsgQ2M6ICZxdW90OzxhIGhyZWY9Im1haWx0 bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZyI+c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0 Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2lwLW92ZXJsb2FkLWJvdW5jZXNA aWV0Zi5vcmciPnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDssPC9zcGFuPjwv dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPjxicj4NCjx0dD4mZ3Q7ICZxdW90OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1p ZXRmLXNvYy1vdmVybG9hZC1yYXRlLWNvbnRyb2wuYWxsQHRvb2xzLmlldGYub3JnIj5kcmFmdC1p ZXRmLXNvYy1vdmVybG9hZC1yYXRlLWNvbnRyb2wuYWxsQHRvb2xzLmlldGYub3JnPC9hPiZxdW90 OyAmbHQ7ZHJhZnQtPC90dD48YnI+DQo8dHQ+Jmd0OyA8YSBocmVmPSJtYWlsdG86aWV0Zi1zb2Mt b3ZlcmxvYWQtcmF0ZS1jb250cm9sLmFsbEB0b29scy5pZXRmLm9yZyI+aWV0Zi1zb2Mtb3Zlcmxv YWQtcmF0ZS1jb250cm9sLmFsbEB0b29scy5pZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDtzaXAtPC90 dD48YnI+DQo8dHQ+Jmd0OyA8YSBocmVmPSJtYWlsdG86b3ZlcmxvYWRAaWV0Zi5vcmciPm92ZXJs b2FkQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZEBp ZXRmLm9yZyI+c2lwLW92ZXJsb2FkQGlldGYub3JnPC9hPiZndDs8L3R0Pjwvc3Bhbj4NCjxicj4N Cjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyBEYXRlOiAwNy8xMC8yMDEz IDA5OjAxIEFNPC9zcGFuPjwvdHQ+IDxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdCI+Jmd0OyBTdWJqZWN0OiBSZTogW3NpcC1vdmVybG9hZF0gZHJhZnQtaWV0Zi1zb2Mtb3Zl cmxvYWQtcmF0ZS1jb250cm9sLTA0LnR4dDwvc3Bhbj48L3R0Pg0KPGJyPg0KPHR0PjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7IFNlbnQgYnk6IDxhIGhyZWY9Im1haWx0bzpzaXAt b3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZyI+DQpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9y ZzwvYT48L3NwYW4+PC90dD4gPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij4mZ3Q7IDwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jmd0OyBOb2VsLDwvdHQ+PC9z cGFuPiA8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsgJm5ic3A7 PC9zcGFuPjwvdHQ+IDxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0 OyBJIG1lbnRpb25lZCBpbiBteSBtZXNzYWdlIHRvIEphbmV0IG9uIDcvMjo8L3NwYW4+PC90dD4N Cjxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyAmbmJzcDs8L3Nw YW4+PC90dD4gPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7IEZv ciB0aGUgcmF0ZSBjb250cm9sLCB0aGUgc2VydmVyIGNvdWxkIGNhbGN1bGF0ZSB0aGUgYXJyaXZh bCByYXRlDQo8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PiZndDsgZnJvbSBlYWNoIGNv bW11bmljYXRpbmcgY2xpZW50IHNvIHRoYXQgaXQgY291bGQgYWxsb2NhdGUgdGhlIG92ZXJhbGw8 L3R0Pjxicj4NCjx0dD4mZ3Q7IHRhcmdldCBTSVAgcmVxdWVzdCByYXRlIHRvIHRoZSBjbGllbnRz IGJhc2VkIG9uIHRoZWlyIGFycml2YWwgcmF0ZXMgPC90dD48YnI+DQo8dHQ+Jmd0OyBrbm93biB0 byB0aGUgc2VydmVyLiAmbmJzcDtCdXQgYW5vdGhlciBvcHRpb24gaXMgZm9yIHRoZSBjbGllbnQg dG8gPC90dD48YnI+DQo8dHQ+Jmd0OyDigJxvcHRpb25hbGx54oCdIGluY2x1ZGUgaXRzIGNhbGN1 bGF0ZWQgYXJyaXZhbCByYXRlIGluIGl0cyByZXF1ZXN0IHRvIDwvdHQ+PGJyPg0KPHR0PiZndDsg dGhlIHNlcnZlciB3aGVuIHJhdGUgY29udHJvbCByZWxhdGVkIHBhcmFtZXRlcnMgYXJlIHByZXNl bnQuICZuYnNwO1Nob3VsZDwvdHQ+PGJyPg0KPHR0PiZndDsgdGhpcyBvcHRpb24gYmUgZXZhbHVh dGVkL2luY2x1ZGVkIHRvIHJlbGlldmUgdGhlIHNlcnZlciBmcm9tIGRvaW5nIDwvdHQ+PGJyPg0K PHR0PiZndDsgdGhlIGFycml2YWwgcmF0ZSBjYWxjdWxhdGlvbnMuICZuYnNwO1RoaXMgd291bGQg YmUgYmVuZWZpY2lhbCB0byBhIHNlcnZlcjwvdHQ+PGJyPg0KPHR0PiZndDsgd2hlbiBpdCByZWNl aXZlcyB0aGUgcmVxdWVzdHMgZnJvbSBtYW55IGNsaWVudHMuPC90dD48L3NwYW4+IDxicj4NCjx0 dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyAmbmJzcDs8L3NwYW4+PC90dD4g PGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7IEkgc3VnZ2VzdCB0 aGF0IHRoZSBJLUQgYWRkcyB0aGF0IG9wdGlvbiB0byBhbGxvdyB0aGUgY2xpZW50IHRvDQo8L3Nw YW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PiZndDsgaW5kaWNhdGUgaXRzIGN1cnJlbnQgYXJy aXZhbCByYXRlICh0b3dhcmRzIHRoZSByZWNlaXZpbmcgc2VydmVyKSBpbiA8L3R0Pjxicj4NCjx0 dD4mZ3Q7IHRoZSBTSVAgcmVxdWVzdC48L3R0Pjwvc3Bhbj4gPGJyPg0KPHR0PjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7ICZuYnNwOzwvc3Bhbj48L3R0PiA8YnI+DQo8dHQ+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsgSmFtZXM8L3NwYW4+PC90dD4gPGJyPg0K PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7ICZuYnNwOzwvc3Bhbj48L3R0 PiA8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsgRnJvbTogTk9F TCwgRVJJQyBDIChFUklDIEMpIFs8L3NwYW4+PC90dD48YSBocmVmPSJtYWlsdG86ZWNub2VsQHJl c2VhcmNoLmF0dC5jb20iPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+bWFpbHRv OmVjbm9lbEByZXNlYXJjaC5hdHQuY29tPC9zcGFuPjwvdHQ+PC9hPjx0dD48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+XQ0KPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD4mZ3Q7 IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMDksIDIwMTMgNDo0NCBQTTwvdHQ+PGJyPg0KPHR0PiZndDsg VG86IFl1LCBKYW1lczsgSmFuZXQgUCBHdW5uPC90dD48YnI+DQo8dHQ+Jmd0OyBDYzogPGEgaHJl Zj0ibWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnIj5zaXAtb3ZlcmxvYWQtYm91 bmNlc0BpZXRmLm9yZzwvYT47IGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLXJhdGUtPC90dD48YnI+ DQo8dHQ+Jmd0OyA8YSBocmVmPSJtYWlsdG86Y29udHJvbC5hbGxAdG9vbHMuaWV0Zi5vcmciPmNv bnRyb2wuYWxsQHRvb2xzLmlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpzaXAtb3Zlcmxv YWRAaWV0Zi5vcmciPnNpcC1vdmVybG9hZEBpZXRmLm9yZzwvYT48L3R0Pjxicj4NCjx0dD4mZ3Q7 IFN1YmplY3Q6IFJFOiBbc2lwLW92ZXJsb2FkXSBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1yYXRl LWNvbnRyb2wtMDQudHh0PC90dD48L3NwYW4+DQo8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPiZndDsgJm5ic3A7PC9zcGFuPjwvdHQ+IDxicj4NCjx0dD48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyBKYW5ldCwgSmFtZXMsPC9zcGFuPjwvdHQ+IDxicj4N Cjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyAmbmJzcDs8L3NwYW4+PC90 dD4gPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7IFRoYW5rcyB5 b3UgZm9yIHlvdXIgdmFsdWFibGUgY29tbWVudHMgYW5kIGRpc2N1c3Npb24uICZuYnNwO0kgdHJp ZWQgdG8NCjwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jmd0OyBjYXB0dXJlIGFsbCBy ZXNvbHV0aW9uIGluIHRoZSBmb2xsb3dpbmcgdGV4dCAoYmFzZWQgb24gSmFtZXMgd29yZCA8L3R0 Pjxicj4NCjx0dD4mZ3Q7IGRvY3VtZW50IHdpdGggdHJhY2sgY2hhbmdlcyBhbmQgaW1iZWRkZWQg Y29tbWVudHMgZW5hYmxlZCkuPC90dD48L3NwYW4+IDxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+Jmd0OyAmbmJzcDs8L3NwYW4+PC90dD4gPGJyPg0KPHR0PjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7ICYjNDM7IEFic3RyYWN0IHNlY3Rpb246IDwvc3Bh bj48L3R0Pjxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyAtIEFn cmVlZCB3aXRoIHN1Z2dlc3RlZCBjaGFuZ2VzPC9zcGFuPjwvdHQ+IDxicj4NCjx0dD48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyAtIFBsZWFzZSBub3RlIEkgd2lsbCBhbHNvIG5l ZWQgdG8gbWFrZSBmdXJ0aGVyIGNoYW5nZXMgdG8gcmVtb3ZlIGFsbDwvc3Bhbj48L3R0PjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij48YnI+DQo8dHQ+Jmd0OyByZWZlcmVuY2VzIHBlciBDaHJpc3RlciBIb2xtYmVyZyBjb21t ZW50PC90dD48L3NwYW4+IDxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ Jmd0OyAmbmJzcDs8L3NwYW4+PC90dD4gPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij4mZ3Q7ICYjNDM7IFNlY3Rpb24gMTo8L3NwYW4+PC90dD4gPGJyPg0KPHR0PjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7IC0gQWdyZWVkIHdpdGggc3VnZ2VzdGVkIGNo YW5nZXM8L3NwYW4+PC90dD4gPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij4mZ3Q7ICZuYnNwOzwvc3Bhbj48L3R0PiA8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPiZndDsgJiM0MzsgU2VjdGlvbiAzLjE6PC9zcGFuPjwvdHQ+IDxicj4NCjx0dD48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyAtIEFncmVlZCB3aXRoIHN1Z2dlc3Rl ZCBjaGFuZ2VzPC9zcGFuPjwvdHQ+IDxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdCI+Jmd0OyAmbmJzcDsgPC9zcGFuPjwvdHQ+PGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij4mZ3Q7ICYjNDM7IFNlY3Rpb24gMy4yOiAtIFBsZWFzZSBub3RlIHRoZSBz ZWN0aW9uIHRpdGxlIHdpbGwgYmVjb21lIOKAnFZpYQ0KPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxi cj4NCjx0dD4mZ3Q7IGhlYWRlciBmaWVsZCBwYXJhbWV0ZXJzIGZvciBvdmVybG9hZCBjb250cm9s IOKAnCBwZXIgQ2hyaXN0ZXIgSG9sbWJlcmcgY29tbWVudDwvdHQ+PC9zcGFuPg0KPGJyPg0KPHR0 PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7IC0gQWdyZWVkIHdpdGggc3VnZ2Vz dGVkIGNoYW5nZXMgZXhjbHVkaW5nIHRpdGxlIHRoYXQgd2lsbCBjaGFuZ2UgcGVyPC9zcGFuPjwv dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPjxicj4NCjx0dD4mZ3Q7IHByZXZpb3VzIGJ1bGxldDwvdHQ+PC9zcGFuPiA8 YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsgJm5ic3A7PC9zcGFu PjwvdHQ+IDxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyAmIzQz OyBTZWN0aW9uIDMuMzo8L3NwYW4+PC90dD4gPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij4mZ3Q7IC0gQWdyZWVkIHdpdGggc3VnZ2VzdGVkIGNoYW5nZXM8L3NwYW4+PC90 dD4gPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7ICZuYnNwOzwv c3Bhbj48L3R0PiA8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsg JiM0MzsgU2VjdGlvbiAzLjQ6PC9zcGFuPjwvdHQ+IDxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+Jmd0OyAtIElEOiAmbmJzcDsmcXVvdDtOb3RlIHRoYXQgdGhlIHRhcmdl dCBTSVAgcmVxdWVzdCByYXRlIGlzIGEgbWF4IHJhdGUgdGhhdCBtYXk8L3NwYW4+PC90dD48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+PGJyPg0KPHR0PiZndDsgbm90IGJlIGF0dGFpbmVkIGJ5IHRoZSBhcnJpdmFsIHJhdGUg YXQgdGhlIGNsaWVudCwgYW5kIHRoZSBzZXJ2ZXIgPC90dD48YnI+DQo8dHQ+Jmd0OyBjYW5ub3Qg YXNzdW1lIHRoYXQgaXQgd2lsbC4mcXVvdDsgPC90dD48L3NwYW4+PGJyPg0KPHR0PjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7ICZuYnNwOyAmbmJzcDtbSlldIE5vdCBjbGVhciB3 aGF0IHZhbHVlIHRoaXMgcGFyYWdyYXBoIHRyaWVzIHRvIGFkZC4gJm5ic3A7SXMgaXQNCjwvc3Bh bj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jmd0OyBzYXlpbmcgdGhhdCB0aGUgY2xpZW50J3Mg YXJyaXZhbCByYXRlIG1heSBiZSBsb3dlciB0aGFuIHRoZSB0YXJnZXQgPC90dD48YnI+DQo8dHQ+ Jmd0OyBTSVAgcmVxdWVzdCByYXRlPyA8L3R0Pjwvc3Bhbj48YnI+DQo8dHQ+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsgJm5ic3A7ICZuYnNwO1tKR10gWWVzICYjNDM7IHN1cHBv cnRpbmcgZXhhbXBsZSAoc2VlIGJlbG93IGluIHRocmVhZCk8L3NwYW4+PC90dD4NCjxicj4NCjx0 dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyAmbmJzcDsgQWdyZWVkIHdpdGgg SmFuZXQgYW5kIHN1cHBvcnRpbmcgZXhhbXBsZS4gUGVyIEphbWVzIHJlcXVlc3QsIEkNCjwvc3Bh bj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jmd0OyB3aWxsIGFkZCB0aGUgZm9sbG93aW5nIHRl eHQgKGluc3BpcmVkIGZyb20gSmFuZXTigJlzIGlsbHVzdHJhdGl2ZSBleGFtcGxlKTo8L3R0Pjwv c3Bhbj4NCjxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyAmbmJz cDsgJm5ic3A74oCcSW4gb3RoZXIgd29yZHMsIHdoZW4gbXVsdGlwbGUgY2xpZW50cyBhcmUgYmVp bmcgY29udHJvbGxlZCBieSBhbjwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jmd0OyBv dmVybG9hZGVkIHNlcnZlciwgYXQgYW55IGdpdmVuIHRpbWUgc29tZSBjbGllbnRzIG1heSByZWNl aXZlIDwvdHQ+PGJyPg0KPHR0PiZndDsgcmVxdWVzdHMgYXQgYSByYXRlIGJlbG93IGl0cyB0YXJn ZXQgU0lQIHJlcXVlc3QgcmF0ZSB3aGlsZSBvdGhlcnMgPC90dD48YnI+DQo8dHQ+Jmd0OyBhYm92 ZSB0aGF0IHRhcmdldCByYXRlLiBCdXQgdGhlIHJlc3VsdGluZyByZXF1ZXN0IHJhdGUgcHJlc2Vu dGVkIHRvIDwvdHQ+PGJyPg0KPHR0PiZndDsgdGhlIG92ZXJsb2FkZWQgc2VydmVyIHdpbGwgY29u dmVyZ2UgdG93YXJkcyB0aGUgdGFyZ2V0IFNJUCByZXF1ZXN0IHJhdGUu4oCdPC90dD48L3NwYW4+ DQo8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsgLSBBZ3JlZWQg d2l0aCBvdGhlciBzdWdnZXN0ZWQgY2hhbmdlcyA8L3NwYW4+DQo8L3R0Pjxicj4NCjx0dD48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvc3Bh bj48L3R0PiA8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsgJiM0 MzsgU2VjdGlvbiAzLjUuMTo8L3NwYW4+PC90dD4gPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij4mZ3Q7IC0gSUQ6IOKAnEFuZCB0aGUgbGFyZ2VyIHRoZSBkaWZmZXJlbmNl IGJldHdlZW4gVEFVMSBhbmQgVEFVMiwgdGhlDQo8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0K PHR0PiZndDsgY2xvc2VyIHRvIHRoZSBjb250cm9sIGlzIHRvIHN0cmljdCBwcmlvcml0eS7igJ08 L3R0Pjwvc3Bhbj4gPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7 ICZuYnNwOyBbSlldIFN1Z2dlc3QgY2hhbmdpbmcgaW50byDigJxBbmQgdGhlIGxhcmdlciB0aGUg ZGlmZmVyZW5jZSBiZXR3ZWVuDQo8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PiZndDsg VEFVMSBhbmQgVEFVMiwgdGhlIGNsb3NlciB0aGUgY29udHJvbCBpcyB0byBzdHJpY3QgcHJpb3Jp dHkgcXVldWluZy7igJ08L3R0Pjwvc3Bhbj4NCjxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+Jmd0OyAmbmJzcDsgW0pHXSBTdWdnZXN0IGNoYW5naW5nIGludG8g4oCcQW5k IHRoZSBsYXJnZXIgdGhlIGRpZmZlcmVuY2UgYmV0d2Vlbg0KPC9zcGFuPjwvdHQ+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi Pjxicj4NCjx0dD4mZ3Q7IFRBVTEgYW5kIFRBVTIsIHRoZSBjbG9zZXIgdGhlIGNvbnRyb2wgaXMg dG8gc3RyaWN0IHByaW9yaXR5IHRyZWF0bWVudC7igJ08L3R0Pjwvc3Bhbj4NCjxicj4NCjx0dD48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyAmbmJzcDsgW0VOXSBBZ3JlZWQgd2l0 aCBKYW5ldOKAmXMgc3VnZ2VzdGlvbjwvc3Bhbj48L3R0Pg0KPGJyPg0KPHR0PjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7IC0gQWdyZWVkIHdpdGggb3RoZXIgc3VnZ2VzdGVkIGNo YW5nZXM8L3NwYW4+PC90dD4NCjxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+Jmd0OyAmbmJzcDs8L3NwYW4+PC90dD4gPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij4mZ3Q7ICYjNDM7IFNlY3Rpb24gNDo8L3NwYW4+PC90dD4gPGJyPg0KPHR0Pjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7IC0gQWdyZWVkIHdpdGggc3VnZ2VzdGVk IGNoYW5nZXM8L3NwYW4+PC90dD4gPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij4mZ3Q7ICZuYnNwOzwvc3Bhbj48L3R0PiA8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPiZndDsgJiM0MzsgU2VjdGlvbiA1Ojwvc3Bhbj48L3R0PiA8YnI+DQo8dHQ+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsgLSBQbGVhc2Ugbm90ZSB0aGF0IGJh c2VkIGNvbW1lbnRzIGZyb20gcGVyIENocmlzdGVyIEhvbG1iZXJnIGFuZA0KPC9zcGFuPjwvdHQ+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPjxicj4NCjx0dD4mZ3Q7IEphbmV0IEd1bm4sIHRoZSBmb2xsb3dpbmcgd2FzIHRl bnRhdGl2ZWx5IGFncmVlZCA8L3R0Pjwvc3Bhbj48YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPiZndDsgJm5ic3A7ICZuYnNwO1JlcGxhY2Ugb2MtdmFsdWUgPSAmcXVvdDtO YU4mcXVvdDsgLyBvYy1udW0gJm5ic3A7ICZuYnNwO2J5ICZuYnNwOyAmbmJzcDtvYyA9ICZxdW90 O29jJnF1b3Q7IFtFUVVBTCBvYy1udW1dPC9zcGFuPjwvdHQ+DQo8YnI+DQo8dHQ+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsgLSBBZ3JlZWQgd2l0aCBvdGhlciBzdWdnZXN0ZWQg Y2hhbmdlPC9zcGFuPjwvdHQ+DQo8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPiZndDsgJm5ic3A7PC9zcGFuPjwvdHQ+IDxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+Jmd0OyAmIzQzOyBTZWN0aW9uIDc6PC9zcGFuPjwvdHQ+IDxicj4NCjx0dD48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyAtIFtKWV0gU2hvdWxkIOKAnHJhdGXi gJ0gaW4gb2MtYWxnbyBiZSByZWdpc3RlcmVkIHdpdGggSUFOQT88L3NwYW4+PC90dD4NCjxicj4N Cjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyAmbmJzcDsgVGhpcyBpc3N1 ZSBuZWVkcyB0byBiZSBhZGRyZXNzZWQgYnkgZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtY29udHJv bCBhdXRob3JzPC9zcGFuPjwvdHQ+DQo8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQiPiZndDsgJm5ic3A7PC9zcGFuPjwvdHQ+IDxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+Jmd0OyBQbGVhc2Ugbm90ZSBJIHdpbGwgd2FpdCB1bnRpbCBleHBpcmF0 aW9uIG9mIFdHTEMgcHJpb3IgdXBkYXRpbmcgb3VyDQo8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJy Pg0KPHR0PiZndDsgZHJhZnQgUkZDLiBPbmNlIGFnYWluIHlvdXIgY29tbWVudHMgYW5kL29yIHN1 Z2dlc3Rpb25zIGFyZSBtb3N0IGFwcHJlY2lhdGVkLjwvdHQ+PC9zcGFuPg0KPGJyPg0KPHR0Pjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7ICZuYnNwOzwvc3Bhbj48L3R0PiA8YnI+ DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsgVGhhbmtzLDwvc3Bhbj48 L3R0PiA8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsgJm5ic3A7 PC9zcGFuPjwvdHQ+IDxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0 OyBFcmljIE5vZWwgPC9zcGFuPjwvdHQ+PGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij4mZ3Q7IEFUJmFtcDtUIExhYnMsIEluYy4gPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxi cj4NCjx0dD4mZ3Q7IFJldGhpbmsgUG9zc2libGU8L3R0Pjwvc3Bhbj4gPGJyPg0KPHR0PjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7ICZuYnNwOzwvc3Bhbj48L3R0PiA8YnI+DQo8 dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsgTmV0d29yayBEZXNpZ24gYW5k IFBlcmZvcm1hbmNlIEFuYWx5c2lzPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD4mZ3Q7 IDIwMCBTb3V0aCBMYXVyZWwgQXZlbnVlLCBENS0zRDE5PC90dD48YnI+DQo8dHQ+Jmd0OyBNaWRk bGV0b3duLCBOSiAwNzc0ODwvdHQ+PGJyPg0KPHR0PiZndDsgUDogNzMyLjQyMC40MTc0PC90dD48 L3NwYW4+IDxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyA8YSBo cmVmPSJtYWlsdG86ZWNub2VsQGF0dC5jb20iPmVjbm9lbEBhdHQuY29tPC9hPjwvc3Bhbj48L3R0 Pg0KPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7ICZuYnNwOzwv c3Bhbj48L3R0PiA8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsg RnJvbTogPGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnIj4NCnNp cC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPC9hPiBbPC9zcGFuPjwvdHQ+PGEgaHJlZj0ibWFp bHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnIj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPm1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48 L3R0PjwvYT48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPl0NCjwvc3Bhbj48L3R0 PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jmd0OyBPbiBCZWhhbGYgT2YgWXUsIEphbWVzPC90dD48YnI+ DQo8dHQ+Jmd0OyBTZW50OiBUdWVzZGF5LCBKdWx5IDAyLCAyMDEzIDk6NDIgQU08L3R0Pjxicj4N Cjx0dD4mZ3Q7IFRvOiBKYW5ldCBQIEd1bm48L3R0Pjxicj4NCjx0dD4mZ3Q7IENjOiA8YSBocmVm PSJtYWlsdG86c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmciPnNpcC1vdmVybG9hZC1ib3Vu Y2VzQGlldGYub3JnPC9hPjsgZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS08L3R0Pjxicj4N Cjx0dD4mZ3Q7IDxhIGhyZWY9Im1haWx0bzpjb250cm9sLmFsbEB0b29scy5pZXRmLm9yZyI+Y29u dHJvbC5hbGxAdG9vbHMuaWV0Zi5vcmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVybG9h ZEBpZXRmLm9yZyI+c2lwLW92ZXJsb2FkQGlldGYub3JnPC9hPjwvdHQ+PGJyPg0KPHR0PiZndDsg U3ViamVjdDogUmU6IFtzaXAtb3ZlcmxvYWRdIGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLXJhdGUt Y29udHJvbC0wNC50eHQ8L3R0Pjwvc3Bhbj4NCjxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+Jmd0OyAmbmJzcDs8L3NwYW4+PC90dD4gPGJyPg0KPHR0PjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7IEphbmV0LDwvc3Bhbj48L3R0PiA8YnI+DQo8dHQ+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsgJm5ic3A7PC9zcGFuPjwvdHQ+IDxicj4N Cjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyBGb3IgbXkgY29tbWVudCBv biBzZWN0aW9uIDMuNCAodGhlIGZpcnN0IG9uZSBiZWxvdyksIHRoZSBjdXJyZW50DQo8L3NwYW4+ PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PiZndDsgdGV4dCBkb2VzIG5vdCBwcm92aWRlIGFueSB2 YWx1ZS4gJm5ic3A7VGhlIGNsaWVudOKAmXMgYXJyaXZhbCByYXRlIGNvdWxkIGJlPC90dD48YnI+ DQo8dHQ+Jmd0OyB3ZWxsIGJlbG93IHRoZSB0YXJnZXQgU0lQIHJlcXVlc3QgcmF0ZSB3aGVuIGl0 cyBsb2FkIGlzIGxpZ2h0IHNvIHRoZTwvdHQ+PGJyPg0KPHR0PiZndDsgZmFjdCB0aGF0IHRoZSBj bGllbnQgbWF5IG5vdCBhY2hpZXZlIHRoZSB0YXJnZXQgU0lQIHJlcXVlc3QgcmF0ZSA8L3R0Pjxi cj4NCjx0dD4mZ3Q7ICh0aGUgbWF4LiByYXRlIGl0IGlzIGFsbG93ZWQgdG8gc2VuZCB0byB0aGUg c2VydmVyKSBpcyB3ZWxsIDwvdHQ+PGJyPg0KPHR0PiZndDsgdW5kZXJzdG9vZC4gJm5ic3A7QnV0 IHdpdGggeW91ciBleHBsYW5hdGlvbiBvbiB0aGUg4oCcZGVsdGHigJ0gcGFydCwgdGhlIHRleHQ8 L3R0Pjxicj4NCjx0dD4mZ3Q7IHRoZW4gbWFrZXMgc2Vuc2UuICZuYnNwO1BsZWFzZSBhZGQgc29t ZSBkaXNjdXNzaW9ucyBvbiB0aGUg4oCcZGVsdGHigJ0gYXNwZWN0PC90dD48YnI+DQo8dHQ+Jmd0 OyBzbyB0aGF0IGV2ZW4gaWYgdGhlIGF2ZXJhZ2UgYXJyaXZhbCByYXRlIGF0IHRoZSBjbGllbnQg aXMgaGlnaGVyIDwvdHQ+PGJyPg0KPHR0PiZndDsgdGhhbiB0aGUgdGFyZ2V0IFNJUCByZXF1ZXN0 IHJhdGUgdGhlIGNsaWVudCBhdCB0aW1lcyBtYXkgbm90IHNlbmQgPC90dD48YnI+DQo8dHQ+Jmd0 OyBtb3JlIHRoYW4gd2hhdCB0aGUgdGFyZ2V0IFNJUCByZXF1ZXN0IHJhdGUgYWxsb3dzIGR1ZSB0 byB0aGUgPC90dD48YnI+DQo8dHQ+Jmd0OyBmbHVjdHVhdGlvbiBvZiB0aGUgYXJyaXZpbmcgcmVx dWVzdHMgYXQgdGhlIGNsaWVudC48L3R0Pjwvc3Bhbj4gPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0Ij4mZ3Q7ICZuYnNwOzwvc3Bhbj48L3R0PiA8YnI+DQo8dHQ+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsgRm9yIHRoZSBjb21tZW50IG9uIHNlY3Rpb24g My41LjEsIEkgYWdyZWUgd2l0aCB5b3VyIHByb3Bvc2VkIGNoYW5nZS48L3NwYW4+PC90dD4NCjxi cj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyAmbmJzcDs8L3NwYW4+ PC90dD4gPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7IEZvciB0 aGUgcmF0ZSBjb250cm9sLCB0aGUgc2VydmVyIGNvdWxkIGNhbGN1bGF0ZSB0aGUgYXJyaXZhbCBy YXRlDQo8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PiZndDsgZnJvbSBlYWNoIGNvbW11 bmljYXRpbmcgY2xpZW50IHNvIHRoYXQgaXQgY291bGQgYWxsb2NhdGUgdGhlIG92ZXJhbGw8L3R0 Pjxicj4NCjx0dD4mZ3Q7IHRhcmdldCBTSVAgcmVxdWVzdCByYXRlIHRvIHRoZSBjbGllbnRzIGJh c2VkIG9uIHRoZWlyIGFycml2YWwgcmF0ZXMgPC90dD48YnI+DQo8dHQ+Jmd0OyBrbm93biB0byB0 aGUgc2VydmVyLiAmbmJzcDtCdXQgYW5vdGhlciBvcHRpb24gaXMgZm9yIHRoZSBjbGllbnQgdG8g PC90dD48YnI+DQo8dHQ+Jmd0OyDigJxvcHRpb25hbGx54oCdIGluY2x1ZGUgaXRzIGNhbGN1bGF0 ZWQgYXJyaXZhbCByYXRlIGluIGl0cyByZXF1ZXN0IHRvIDwvdHQ+PGJyPg0KPHR0PiZndDsgdGhl IHNlcnZlciB3aGVuIHJhdGUgY29udHJvbCByZWxhdGVkIHBhcmFtZXRlcnMgYXJlIHByZXNlbnQu ICZuYnNwO1Nob3VsZDwvdHQ+PGJyPg0KPHR0PiZndDsgdGhpcyBvcHRpb24gYmUgZXZhbHVhdGVk L2luY2x1ZGVkIHRvIHJlbGlldmUgdGhlIHNlcnZlciBmcm9tIGRvaW5nIDwvdHQ+PGJyPg0KPHR0 PiZndDsgdGhlIGFycml2YWwgcmF0ZSBjYWxjdWxhdGlvbnMuICZuYnNwO1RoaXMgd291bGQgYmUg YmVuZWZpY2lhbCB0byBhIHNlcnZlcjwvdHQ+PGJyPg0KPHR0PiZndDsgd2hlbiBpdCByZWNlaXZl cyB0aGUgcmVxdWVzdHMgZnJvbSBtYW55IGNsaWVudHMuPC90dD48L3NwYW4+IDxicj4NCjx0dD48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyAmbmJzcDs8L3NwYW4+PC90dD4gPGJy Pg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7IEphbWVzPC9zcGFuPjwv dHQ+IDxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyAmbmJzcDs8 L3NwYW4+PC90dD4gPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7 IEZyb206IEphbmV0IFAgR3VubiBbPC9zcGFuPjwvdHQ+PGEgaHJlZj0ibWFpbHRvOmpndW5uNkBj c2MuY29tIj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPm1haWx0bzpqZ3VubjZA Y3NjLmNvbTwvc3Bhbj48L3R0PjwvYT48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi Pl0NCjwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jmd0OyBTZW50OiBGcmlkYXksIEp1 bmUgMjgsIDIwMTMgMzozNCBQTTwvdHQ+PGJyPg0KPHR0PiZndDsgVG86IFl1LCBKYW1lczwvdHQ+ PGJyPg0KPHR0PiZndDsgQ2M6IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLXNvYy1vdmVybG9h ZC1yYXRlLWNvbnRyb2wuYWxsQHRvb2xzLmlldGYub3JnIj4NCmRyYWZ0LWlldGYtc29jLW92ZXJs b2FkLXJhdGUtY29udHJvbC5hbGxAdG9vbHMuaWV0Zi5vcmc8L2E+OyBzaXAtPC90dD48YnI+DQo8 dHQ+Jmd0OyA8YSBocmVmPSJtYWlsdG86b3ZlcmxvYWRAaWV0Zi5vcmciPm92ZXJsb2FkQGlldGYu b3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnIj4N CnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPC9hPjwvdHQ+PGJyPg0KPHR0PiZndDsgU3Vi amVjdDogUmU6IFtzaXAtb3ZlcmxvYWRdIGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLXJhdGUtY29u dHJvbC0wNC50eHQ8L3R0Pjwvc3Bhbj4NCjxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+Jmd0OyAmbmJzcDs8L3NwYW4+PC90dD4gPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0Ij4mZ3Q7IEphbWVzLCA8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0K PHR0PiZndDsgPC90dD48YnI+DQo8dHQ+Jmd0OyBJdCBpcyBhIGxpdHRsZSBoYXJkIHRvIHJlc3Bv bmQgaW4gZW1haWwgd2hlbiB5b3VyIGNvbW1lbnRzIGFyZSBpbiBhIDwvdHQ+PGJyPg0KPHR0PiZn dDsgc2VwYXJhdGUgZG9jdW1lbnQsIGJ1dCBoZXJlIGdvZXMuIDwvdHQ+PGJyPg0KPHR0PiZndDsg PC90dD48YnI+DQo8dHQ+Jmd0OyA8L3R0Pjxicj4NCjx0dD4mZ3Q7IHNlY3Rpb24gMy40IDwvdHQ+ PGJyPg0KPHR0PiZndDsgSUQgc2F5czogPC90dD48YnI+DQo8dHQ+Jmd0OyAmcXVvdDtOb3RlIHRo YXQgdGhlIHRhcmdldCBTSVAgcmVxdWVzdCByYXRlIGlzIGEgbWF4IHJhdGUgdGhhdCBtYXkgbm90 IGJlIDwvdHQ+PGJyPg0KPHR0PiZndDsgJm5ic3A7ICZuYnNwO2F0dGFpbmVkIGJ5IHRoZSBhcnJp dmFsIHJhdGUgYXQgdGhlIGNsaWVudCwgYW5kIHRoZSBzZXJ2ZXIgY2Fubm90IDwvdHQ+PGJyPg0K PHR0PiZndDsgJm5ic3A7ICZuYnNwO2Fzc3VtZSB0aGF0IGl0IHdpbGwuJnF1b3Q7IDwvdHQ+PGJy Pg0KPHR0PiZndDsgPC90dD48YnI+DQo8dHQ+Jmd0OyBZb3VyIGNvbW1lbnQgOiA8L3R0Pjxicj4N Cjx0dD4mZ3Q7ICZxdW90O05vdCBjbGVhciB3aGF0IHZhbHVlIHRoaXMgcGFyYWdyYXBoIHRyaWVz IHRvIGFkZC4gJm5ic3A7SXMgaXQgc2F5aW5nIDwvdHQ+PGJyPg0KPHR0PiZndDsgdGhhdCB0aGUg Y2xpZW50J3MgYXJyaXZhbCByYXRlIG1heSBiZSBsb3dlciB0aGFuIHRoZSB0YXJnZXQgU0lQIDwv dHQ+PGJyPg0KPHR0PiZndDsgcmVxdWVzdCByYXRlPyAmbmJzcDsmcXVvdDsgPC90dD48YnI+DQo8 dHQ+Jmd0OyA8L3R0Pjxicj4NCjx0dD4mZ3Q7IFllcy4gPC90dD48YnI+DQo8dHQ+Jmd0OyA8L3R0 Pjxicj4NCjx0dD4mZ3Q7IFN1cHBvc2UgdGhlIHNlcnZlciB3YW50IHRvIGxpbWl0IHRoZSB0b3Rh bCByYXRlIG9mIGFycml2aW5nIFNJUCA8L3R0Pjxicj4NCjx0dD4mZ3Q7IG1lc3NhZ2VzIHRvIDEw MCAvIHNlYywgYW5kIGhhcyAxMCBjbGllbnRzLiAmbmJzcDtFYWNoIGNsaWVudCBoYXMgYSBoaWdo IDwvdHQ+PGJyPg0KPHR0PiZndDsgdmFyaWFuY2UgaW4gaXRzIG1lc3NhZ2UgcmF0ZSwgYnV0IHRv Z2V0aGVyIHRoZXkgYXJlIHdlbGwgYWJvdmUgMTAwIDwvdHQ+PGJyPg0KPHR0PiZndDsgbWVzc2Fn ZXMgcGVyIHNlYyA8L3R0Pjxicj4NCjx0dD4mZ3Q7IDwvdHQ+PGJyPg0KPHR0PiZndDsgSWYgaXQg c2V0cyB0aGUgcmF0ZSBhdCAxMCBtZXNzYWdlcyBwZXIgc2Vjb25kIGZvciBlYWNoIG9mIHRoZSA8 L3R0Pjxicj4NCjx0dD4mZ3Q7IGNsaWVudHMsIGl0IHdpbGwgYWxtb3N0IGNlcnRhaW5seSBlbmQg dXAgJm5ic3A7d2l0aCBhbiBvdmVyYWxsIGF2ZXJhZ2Ugb2Y8L3R0Pjxicj4NCjx0dD4mZ3Q7IGxl c3MgdGhhbiAxMDAgbWVzc2FnZXMgcGVyIHNlYywgYmVjYXVzZSBzb21lIGNsaWVudHMgd2lsbCBi ZSBpbiBhIDwvdHQ+PGJyPg0KPHR0PiZndDsgJnF1b3Q7bHVsbCZxdW90OyB3aGlsZSBvdGhlcnMg YXJlIGJ1c3kuICZuYnNwO1RoaXMgaXMgZ29vZCBmcm9tIGEgdGhyb3R0bGluZyA8L3R0Pjxicj4N Cjx0dD4mZ3Q7IHBlcnNwZWN0aXZlLCBidXQsIGFzc3VtaW5nIG1lc3NhZ2VzIGFyZSBjb3JyZWxh dGVkIHdpdGggcmV2ZW51ZSwgPC90dD48YnI+DQo8dHQ+Jmd0OyBiYWQvd2FzdGVmdWwgZnJvbSBh IHJldmVudWUsIG9yIG92ZXJhbGwgcHJvZHVjdGl2aXR5IHBlcnNwZWN0aXZlLiAmbmJzcDs8L3R0 Pjxicj4NCjx0dD4mZ3Q7IFNvIHRoZSBzZXJ2ZXIgbWlnaHQgd2FudCB0byBzZXQgdGhlIHJhdGUg cGVyIGNsaWVudCB0byAxMCAmIzQzOyBkZWx0YSwgPC90dD48YnI+DQo8dHQ+Jmd0OyB3aGVyZSBk ZWx0YSBpcyBnb2luZyB0byBiZSB2ZXJ5IHNwZWNpZmljIHRvIG9wZXJhdGluZyBlbnZpcm9ubWVu dC4gPC90dD48YnI+DQo8dHQ+Jmd0OyA8L3R0Pjxicj4NCjx0dD4mZ3Q7IC0tLSA8L3R0Pjxicj4N Cjx0dD4mZ3Q7IEluIHNlY3Rpb24gJm5ic3A7My41LjEsIGJvdHRvbSBvZiBwYWdlIDggPC90dD48 YnI+DQo8dHQ+Jmd0OyBJRCBzYXlzOiA8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZxdW90O0FuZCB0aGUg bGFyZ2VyIDwvdHQ+PGJyPg0KPHR0PiZndDsgJm5ic3A7ICZuYnNwO3RoZSBkaWZmZXJlbmNlIGJl dHdlZW4gVEFVMSBhbmQgVEFVMiwgdGhlIGNsb3NlciB0byB0aGUgY29udHJvbCBpcyA8L3R0Pg0K PGJyPg0KPHR0PiZndDsgJm5ic3A7ICZuYnNwO3RvIHN0cmljdCBwcmlvcml0eS4mcXVvdDsgPC90 dD48YnI+DQo8dHQ+Jmd0OyA8L3R0Pjxicj4NCjx0dD4mZ3Q7IFlvdSBwcm9wb3NlIGNoYW5naW5n IGl0IHRvOiA8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZxdW90O0FuZCB0aGUgbGFyZ2VyIDwvdHQ+PGJy Pg0KPHR0PiZndDsgJm5ic3A7ICZuYnNwO3RoZSBkaWZmZXJlbmNlIGJldHdlZW4gVEFVMSBhbmQg VEFVMiwgdGhlIGNsb3NlciAmbmJzcDt0aGUgY29udHJvbCBpcyA8L3R0Pjxicj4NCjx0dD4mZ3Q7 ICZuYnNwOyAmbmJzcDt0byBzdHJpY3QgcHJpb3JpdHkgcXVldWluZy4mcXVvdDsgPC90dD48YnI+ DQo8dHQ+Jmd0OyA8L3R0Pjxicj4NCjx0dD4mZ3Q7IEkgYWdyZWUgd2l0aCB0YWtpbmcgb3V0IHRo ZSByZWR1bmRhbnQgJnF1b3Q7dG8mcXVvdDsuICZuYnNwO0J1dCBJIGRpc2FncmVlIHdpdCA8L3R0 Pjxicj4NCjx0dD4mZ3Q7IGFkZGluZyAmcXVvdDtxdWV1aW5nJnF1b3Q7LiAmbmJzcDtUaGVyZSBp cyBubyBxdWV1aW5nLCBwcmlvcml0eSBvciBvdGhlcndpc2UgaW52b2x2ZWQuIDwvdHQ+DQo8YnI+ DQo8dHQ+Jmd0OyA8L3R0Pjxicj4NCjx0dD4mZ3Q7IFlvdSBjb3VsZCBzYXk6IDwvdHQ+PGJyPg0K PHR0PiZndDsgJnF1b3Q7QW5kIHRoZSBsYXJnZXIgPC90dD48YnI+DQo8dHQ+Jmd0OyAmbmJzcDsg Jm5ic3A7dGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBUQVUxIGFuZCBUQVUyLCB0aGUgY2xvc2VyICZu YnNwO3RoZSBjb250cm9sIGlzIDwvdHQ+PGJyPg0KPHR0PiZndDsgJm5ic3A7ICZuYnNwO3RvIHN0 cmljdCBwcmlvcml0eSB0cmVhdG1lbnQuJnF1b3Q7IDwvdHQ+PGJyPg0KPHR0PiZndDsgPC90dD48 YnI+DQo8dHQ+Jmd0OyB3aGVyZSAmcXVvdDsgc3RyaWN0IHByaW9yaXR5IHRyZWF0bWVudCZxdW90 OyB3b3VsZCByZWZlciB0byB0aGUgY2FzZSB3aGVyZSA8L3R0Pjxicj4NCjx0dD4mZ3Q7IG5vbi1w cmlvcml0eSBtZXNzYWdlcyBhcmUgcmVzdHJpY3RlZCB0byBhIHRvdGFsIChwcmlvcml0eSAmIzQz OyBub24tPC90dD48YnI+DQo8dHQ+Jmd0OyBwcmlvcml0eSkgcmF0ZSBvZiAxMCBtZXNzYWdlcyBw ZXIgc2Vjb25kLCBidXQgcHJpb3JpdHkgbWVzc2FnZXMgY2FuIDwvdHQ+PGJyPg0KPHR0PiZndDsg Y29udGludWUgdG8gYmUgc2VudCBhcyBsb25nIGFzIHRoZSB0b3RhbCAocHJpb3JpdHkgJiM0Mzsg bm9uLXByaW9yaXR5KSA8L3R0Pjxicj4NCjx0dD4mZ3Q7IHJhdGUgaXMgbGVzcyB0aGFuIDEyIG1l c3NhZ2VzIHBlciBzZWNvbmQuIDwvdHQ+PGJyPg0KPHR0PiZndDsgPC90dD48YnI+DQo8dHQ+Jmd0 OyBBdCBsZWFzdCwgSSB0aGluayB0aGF0IGlzIHdoYXQgRXJpYyBhbmQgJm5ic3A7UGhpbGlwIGFy ZSB0cnlpbmcgdG8gc2F5LiA8L3R0Pjxicj4NCjx0dD4mZ3Q7IDwvdHQ+PGJyPg0KPHR0PiZndDsg SmFuZXQgPC90dD48YnI+DQo8dHQ+Jmd0OyA8L3R0Pjxicj4NCjx0dD4mZ3Q7IDwvdHQ+PGJyPg0K PHR0PiZndDsgJm5ic3A7IDwvdHQ+PGJyPg0KPHR0PiZndDsgPC90dD48YnI+DQo8dHQ+Jmd0OyA8 L3R0Pjxicj4NCjx0dD4mZ3Q7IFRoaXMgaXMgYSBQUklWQVRFIG1lc3NhZ2UuIElmIHlvdSBhcmUg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIDwvdHQ+PGJyPg0KPHR0PiZndDsgcGxlYXNlIGRl bGV0ZSB3aXRob3V0IGNvcHlpbmcgYW5kIGtpbmRseSBhZHZpc2UgdXMgYnkgZS1tYWlsIG9mIHRo ZSA8L3R0Pjxicj4NCjx0dD4mZ3Q7IG1pc3Rha2UgaW4gZGVsaXZlcnkuIE5PVEU6IFJlZ2FyZGxl c3Mgb2YgY29udGVudCwgdGhpcyBlLW1haWwgc2hhbGwgPC90dD48YnI+DQo8dHQ+Jmd0OyBub3Qg b3BlcmF0ZSB0byBiaW5kIENTQyB0byBhbnkgb3JkZXIgb3Igb3RoZXIgY29udHJhY3QgdW5sZXNz IDwvdHQ+PGJyPg0KPHR0PiZndDsgcHVyc3VhbnQgdG8gZXhwbGljaXQgd3JpdHRlbiBhZ3JlZW1l bnQgb3IgZ292ZXJubWVudCBpbml0aWF0aXZlIDwvdHQ+PGJyPg0KPHR0PiZndDsgZXhwcmVzc2x5 IHBlcm1pdHRpbmcgdGhlIHVzZSBvZiBlLW1haWwgZm9yIHN1Y2ggcHVycG9zZS4gPC90dD48YnI+ DQo8dHQ+Jmd0OyA8L3R0Pjxicj4NCjx0dD4mZ3Q7IDwvdHQ+PGJyPg0KPHR0PiZndDsgPC90dD48 YnI+DQo8dHQ+Jmd0OyBGcm9tOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtZdSwg SmFtZXMmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpqYW1lcy55dUBuZXVzdGFyLmJpeiI+amFt ZXMueXVAbmV1c3Rhci5iaXo8L2E+Jmd0Ow0KPC90dD48YnI+DQo8dHQ+Jmd0OyBUbzogJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZC1i b3VuY2VzQGlldGYub3JnIj5zaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzwvYT4mcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZyI+c2lwLW92 ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PC90dD48YnI+DQo8dHQ+Jmd0 OyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLmFs bEB0b29scy5pZXRmLm9yZyI+ZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLmFs bEB0b29scy5pZXRmLm9yZzwvYT4mcXVvdDsgJmx0O2RyYWZ0LTwvdHQ+PGJyPg0KPHR0PiZndDsg PGEgaHJlZj0ibWFpbHRvOmlldGYtc29jLW92ZXJsb2FkLXJhdGUtY29udHJvbC5hbGxAdG9vbHMu aWV0Zi5vcmciPmlldGYtc29jLW92ZXJsb2FkLXJhdGUtY29udHJvbC5hbGxAdG9vbHMuaWV0Zi5v cmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZEBpZXRmLm9yZyI+ c2lwLW92ZXJsb2FkQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PC90dD48YnI+DQo8dHQ+Jmd0OyA8 YSBocmVmPSJtYWlsdG86c2lwLW92ZXJsb2FkQGlldGYub3JnIj5zaXAtb3ZlcmxvYWRAaWV0Zi5v cmc8L2E+Jmd0OyA8L3R0Pjxicj4NCjx0dD4mZ3Q7IERhdGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOzA2LzI4LzIwMTMgMDg6MTAgQU0gPC90dD48YnI+DQo8dHQ+Jmd0OyBTdWJqZWN0OiAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtbc2lwLW92ZXJsb2FkXSBkcmFmdC1pZXRmLXNvYy1v dmVybG9hZC1yYXRlLWNvbnRyb2wtMDQudHh0IDwvdHQ+DQo8YnI+DQo8dHQ+Jmd0OyBTZW50IGJ5 OiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJtYWlsdG86c2lwLW92ZXJsb2Fk LWJvdW5jZXNAaWV0Zi5vcmciPnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPC9hPg0KPC90 dD48L3NwYW4+PGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7IDwv c3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jmd0OyA8L3R0Pjxicj4NCjx0dD4mZ3Q7IDwv dHQ+PGJyPg0KPHR0PiZndDsgPC90dD48YnI+DQo8dHQ+Jmd0OyBTYWx2YXRvcmUsIDwvdHQ+PGJy Pg0KPHR0PiZndDsgJm5ic3A7IDwvdHQ+PGJyPg0KPHR0PiZndDsgUGxlYXNlIHNlZSB0aGUgYXR0 YWNobWVudCBmb3IgbXkgY29tbWVudHMuIDwvdHQ+PGJyPg0KPHR0PiZndDsgJm5ic3A7IDwvdHQ+ PGJyPg0KPHR0PiZndDsgSSBwYXN0ZWQgdGhlIHRleHQgdG8gYSB3b3JkIGRvY3VtZW50IHRvIHRy YWNlL3Nob3cgdGhlIHByb3Bvc2VkIDwvdHQ+PGJyPg0KPHR0PiZndDsgY2hhbmdlcyBhbmQgY29t bWVudHMuIDwvdHQ+PGJyPg0KPHR0PiZndDsgJm5ic3A7IDwvdHQ+PGJyPg0KPHR0PiZndDsgUmVn YXJkcywgPC90dD48YnI+DQo8dHQ+Jmd0OyAmbmJzcDsgPC90dD48YnI+DQo8dHQ+Jmd0OyBKYW1l cyA8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZuYnNwO1thdHRhY2htZW50ICZxdW90O2NvbW1lbnRzIG9u IGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLXJhdGUtPC90dD48YnI+DQo8dHQ+Jmd0OyBjb250cm9s LTA0LmRvY3gmcXVvdDsgZGVsZXRlZCBieSBKYW5ldCBQIEd1bm4vVVNBL0NTQ10gPC90dD48YnI+ DQo8dHQ+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XzwvdHQ+PGJyPg0KPHR0PiZndDsgc2lwLW92ZXJsb2FkIG1haWxpbmcgbGlzdDwvdHQ+PGJyPg0K PHR0PiZndDsgPGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZEBpZXRmLm9yZyI+c2lwLW92ZXJs b2FkQGlldGYub3JnPC9hPjwvdHQ+PGJyPg0KPHR0PiZndDsgPC90dD48L3NwYW4+PGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXAtb3ZlcmxvYWQiPjx0dD48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zaXAtb3ZlcmxvYWQ8L3NwYW4+PC90dD48L2E+DQo8YnI+DQo8dHQ+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsgPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4N Cjx0dD4mZ3Q7IE5vIHZpcnVzIGZvdW5kIGluIHRoaXMgbWVzc2FnZS48L3R0Pjxicj4NCjx0dD4m Z3Q7IENoZWNrZWQgYnkgQVZHIC0gPC90dD48L3NwYW4+PGEgaHJlZj0id3d3LmF2Zy5jb20iPjx0 dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+d3d3LmF2Zy5jb208L3NwYW4+PC90dD48 L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPjxicj4NCjx0dD4mZ3Q7IFZlcnNpb246IDIwMTMuMC4yOTA0IC8gVmlydXMg RGF0YWJhc2U6IDMyMDQvNjQ1MiAtIFJlbGVhc2UgRGF0ZTogMDYvMzAvMTM8L3R0Pjwvc3Bhbj4N Cjxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyA8L3NwYW4+PC90 dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+PGJyPg0KPHR0PiZndDsgTm8gdmlydXMgZm91bmQgaW4gdGhpcyBtZXNzYWdl LjwvdHQ+PGJyPg0KPHR0PiZndDsgQ2hlY2tlZCBieSBBVkcgLSA8L3R0Pjwvc3Bhbj48YSBocmVm PSJ3d3cuYXZnLmNvbSI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij53d3cuYXZn LmNvbTwvc3Bhbj48L3R0PjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PiZndDsgVmVyc2lvbjogMjAx My4wLjI5MDQgLyBWaXJ1cyBEYXRhYmFzZTogMzIwNC82NDc4IC0gUmVsZWFzZSBEYXRlOiAwNy8w OS8xMzwvdHQ+PGJyPg0KPHR0PiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188L3R0Pjxicj4NCjx0dD4mZ3Q7IHNpcC1vdmVybG9hZCBtYWlsaW5nIGxp c3Q8L3R0Pjxicj4NCjx0dD4mZ3Q7IDxhIGhyZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWRAaWV0Zi5v cmciPnNpcC1vdmVybG9hZEBpZXRmLm9yZzwvYT48L3R0Pjxicj4NCjx0dD4mZ3Q7IDwvdHQ+PC9z cGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwLW92 ZXJsb2FkIj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwLW92ZXJsb2FkPC9zcGFuPjwvdHQ+PC9hPjxvOnA+ PC9vOnA+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0i dGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjEiIHdpZHRoPSIxMDAlIiBub3NoYWRlPSIi IHN0eWxlPSJjb2xvcjojQTBBMEEwIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5ObyB2aXJ1cyBmb3VuZCBpbiB0aGlzIG1lc3NhZ2UuPGJyPg0KQ2hlY2tl ZCBieSBBVkcgLSA8YSBocmVmPSJodHRwOi8vd3d3LmF2Zy5jb20iPnd3dy5hdmcuY29tPC9hPjxi cj4NClZlcnNpb246IDIwMTMuMC4yOTA0IC8gVmlydXMgRGF0YWJhc2U6IDMyMDQvNjQ3OCAtIFJl bGVhc2UgRGF0ZTogMDcvMDkvMTM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_56FB15AFE08E1242B0736CBDCE6E856108092557stntexmb12cisne_-- From ecnoel@research.att.com Wed Jul 10 07:34:23 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 7D02621F9D80; Wed, 10 Jul 2013 07:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wItMo-A4-ukw; Wed, 10 Jul 2013 07:34:16 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id CCAE121F9E5C; Wed, 10 Jul 2013 07:34:15 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id F01A01205DF; Wed, 10 Jul 2013 10:34:12 -0400 (EDT) Received: from njfpsrvexg2.research.att.com (njfpsrvexg2.research.att.com [135.207.177.29]) by mail-green.research.att.com (Postfix) with ESMTP id B95B4E0211; Wed, 10 Jul 2013 10:32:37 -0400 (EDT) Received: from njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9]) by njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9%14]) with mapi; Wed, 10 Jul 2013 10:34:13 -0400 From: "NOEL, ERIC C (ERIC C)" To: "'Yu, James'" Date: Wed, 10 Jul 2013 10:34:12 -0400 Thread-Topic: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Thread-Index: Ac5zhcqru7dYQFxqQKSGvvGKSQFJEAA0j1MAALOuppABZadV0AAr0zMgAAH2JyA= Message-ID: <5EBD159DE88147488A3B1590E09001840353C0687576@njfpsrvexg2.research.att.com> References: <56FB15AFE08E1242B0736CBDCE6E85610808C32F@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610808EF90@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353BDA4CAD4@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E85610809239D@stntexmb12.cis.neustar.com> In-Reply-To: <56FB15AFE08E1242B0736CBDCE6E85610809239D@stntexmb12.cis.neustar.com> 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_5EBD159DE88147488A3B1590E09001840353C0687576njfpsrvexg2_" MIME-Version: 1.0 Cc: "sip-overload-bounces@ietf.org" , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" , "sip-overload@ietf.org" Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.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, 10 Jul 2013 14:34:23 -0000 --_000_5EBD159DE88147488A3B1590E09001840353C0687576njfpsrvexg2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable James, My apologies for having missed your comment. "For the rate control, the server could calculate the arrival rate from eac= h communicating client so that it could allocate the overall target SIP req= uest rate to the clients based on their arrival rates known to the server. = " [EN] Yes, instead of uniformly distributed target SIP request rate across c= lients, the overloaded server could distributed the request rate function o= f the requests it gets from the clients. In our propose we eluded to your suggestion through the following sentence = (section 3.4): "The server must allocate a portion of the target SIP request rate to each = of its client. The server may set the same rate for every client, or may se= t different rates for different clients." "But another option is for the client to "optionally" include its calculate= d arrival rate in its request to the server when rate control related param= eters are present. Should this option be evaluated/included to relieve the= server from doing the arrival rate calculations. This would be beneficial= to a server when it receives the requests from many clients." [EN] Your suggestion is currently not supported by draft-ietf-soc-overload-= control (there are no parameters that would allow clients to inform server = of their respective arrival rates) from which draft-ietf-soc-overload-rate-= control depends upon. You may want to propose this option to draft-ietf-soc= -overload-control authors. But in practice, servers estimate percent blocki= ng or rate dynamically based on their overload state so as to have clients = throttle at a level close to servers overload onset level. 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: Yu, James [mailto:james.yu@neustar.biz] Sent: Wednesday, July 10, 2013 9:01 AM To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all= @tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Noel, I mentioned in my message to Janet on 7/2: For the rate control, the server could calculate the arrival rate from each= communicating client so that it could allocate the overall target SIP requ= est rate to the clients based on their arrival rates known to the server. = But another option is for the client to "optionally" include its calculated= arrival rate in its request to the server when rate control related parame= ters are present. Should this option be evaluated/included to relieve the = server from doing the arrival rate calculations. This would be beneficial = to a server when it receives the requests from many clients. I suggest that the I-D adds that option to allow the client to indicate its= current arrival rate (towards the receiving server) in the SIP request. James From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] Sent: Tuesday, July 09, 2013 4:44 PM To: Yu, James; Janet P Gunn Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all= @tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Janet, James, Thanks you for your valuable comments and discussion. I tried to capture a= ll resolution in the following text (based on James word document with trac= k changes and imbedded comments enabled). + Abstract section: - Agreed with suggested changes - Please note I will also need to make further changes to remove all refere= nces per Christer Holmberg comment + Section 1: - Agreed with suggested changes + Section 3.1: - Agreed with suggested changes + Section 3.2: - Please note the section title will become "Via header fiel= d parameters for overload control " per Christer Holmberg comment - Agreed with suggested changes excluding title that will change per previo= us bullet + Section 3.3: - Agreed with suggested changes + Section 3.4: - ID: "Note that the target SIP request rate is a max rate that may not be= attained by the arrival rate at the client, and the server cannot assume t= hat it will." [JY] Not clear what value this paragraph tries to add. Is it saying tha= t the client's arrival rate may be lower than the target SIP request rate? [JG] Yes + supporting example (see below in thread) Agreed with Janet and supporting example. Per James request, I will add t= he following text (inspired from Janet's illustrative example): "In other words, when multiple clients are being controlled by an overlo= aded server, at any given time some clients may receive requests at a rate = below its target SIP request rate while others above that target rate. But = the resulting request rate presented to the overloaded server will converge= towards the target SIP request rate." - Agreed with other suggested changes + Section 3.5.1: - ID: "And the larger the difference between TAU1 and TAU2, the closer to t= he control is to strict priority." [JY] Suggest changing into "And the larger the difference between TAU1 an= d TAU2, the closer the control is to strict priority queuing." [JG] Suggest changing into "And the larger the difference between TAU1 an= d TAU2, the closer the control is to strict priority treatment." [EN] Agreed with Janet's suggestion - Agreed with other suggested changes + Section 4: - Agreed with suggested changes + Section 5: - Please note that based comments from per Christer Holmberg and Janet Gunn= , the following was tentatively agreed Replace oc-value =3D "NaN" / oc-num by oc =3D "oc" [EQUAL oc-num] - Agreed with other suggested change + Section 7: - [JY] Should "rate" in oc-algo be registered with IANA? This issue needs to be addressed by draft-ietf-soc-overload-control autho= rs Please note I will wait until expiration of WGLC prior updating our draft R= FC. Once again your comments and/or suggestions are most appreciated. 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 Yu, James Sent: Tuesday, July 02, 2013 9:42 AM To: Janet P Gunn Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Janet, For my comment on section 3.4 (the first one below), the current text does = not provide any value. The client's arrival rate could be well below the t= arget SIP request rate when its load is light so the fact that the client m= ay not achieve the target SIP request rate (the max. rate it is allowed to = send to the server) is well understood. But with your explanation on the "= delta" part, the text then makes sense. Please add some discussions on the= "delta" aspect so that even if the average arrival rate at the client is h= igher than the target SIP request rate the client at times may not send mor= e than what the target SIP request rate allows due to the fluctuation of th= e arriving requests at the client. For the comment on section 3.5.1, I agree with your proposed change. For the rate control, the server could calculate the arrival rate from each= communicating client so that it could allocate the overall target SIP requ= est rate to the clients based on their arrival rates known to the server. = But another option is for the client to "optionally" include its calculated= arrival rate in its request to the server when rate control related parame= ters are present. Should this option be evaluated/included to relieve the = server from doing the arrival rate calculations. This would be beneficial = to a server when it receives the requests from many clients. James From: Janet P Gunn [mailto:jgunn6@csc.com] Sent: Friday, June 28, 2013 3:34 PM To: Yu, James Cc: draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org; sip-overload-bounces@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, It is a little hard to respond in email when your comments are in a separat= e document, but here goes. section 3.4 ID says: "Note that the target SIP request rate is a max rate that may not be attained by the arrival rate at the client, and the server cannot assume that it will." Your comment : "Not clear what value this paragraph tries to add. Is it saying that the c= lient's arrival rate may be lower than the target SIP request rate? " Yes. Suppose the server want to limit the total rate of arriving SIP messages to= 100 / sec, and has 10 clients. Each client has a high variance in its mes= sage rate, but together they are well above 100 messages per sec If it sets the rate at 10 messages per second for each of the clients, it w= ill almost certainly end up with an overall average of less than 100 messa= ges per sec, because some clients will be in a "lull" while others are busy= . This is good from a throttling perspective, but, assuming messages are c= orrelated with revenue, bad/wasteful from a revenue, or overall productivit= y perspective. So the server might want to set the rate per client to 10 += delta, where delta is going to be very specific to operating environment. --- In section 3.5.1, bottom of page 8 ID says: "And the larger the difference between TAU1 and TAU2, the closer to the control is to strict priority." You propose changing it to: "And the larger the difference between TAU1 and TAU2, the closer the control is to strict priority queuing." I agree with taking out the redundant "to". But I disagree wit adding "que= uing". There is no queuing, priority or otherwise involved. You could say: "And the larger the difference between TAU1 and TAU2, the closer the control is to strict priority treatment." where " strict priority treatment" would refer to the case where non-priori= ty messages are restricted to a total (priority + non-priority) rate of 10 = messages per second, but priority messages can continue to be sent as long = as the total (priority + non-priority) rate is less than 12 messages per se= cond. At least, I think that is what Eric and Philip are trying to say. 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: "Yu, James" = > To: "sip-overload-bounces@ietf.org" >= , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" >, "sip-overload@ietf.org"= > Date: 06/28/2013 08:10 AM Subject: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Sent by: sip-overload-bounces@ietf.org ________________________________ Salvatore, Please see the attachment for my comments. I pasted the text to a word document to trace/show the proposed changes and= comments. Regards, James [attachment "comments on draft-ietf-soc-overload-rate-control-04.docx" del= eted by Janet P Gunn/USA/CSC] _____________________________________________= __ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6452 - Release Date: 06/30/13 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13 --_000_5EBD159DE88147488A3B1590E09001840353C0687576njfpsrvexg2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

James,

 

=

My apologies for having missed your comment.

 

=

“For the rate control, the server could c= alculate the arrival rate from each communicating client so that it could a= llocate the overall target SIP request rate to the clients based on their a= rrival rates known to the server. “

[EN] Yes, instead of uniformly distributed target SIP reque= st rate across clients, the overloaded server could distributed the request= rate function of the requests it gets from the clients.<= /p>

In our propose we eluded to your suggestion = through the following sentence (section 3.4):

“The server must allocate a portion of the target= SIP request rate to each of its client. The server may set the same rate f= or every client, or may set different rates for different clients.”

 

“But another option is for the client to= “optionally” include its calculated arrival rate in its reques= t to the server when rate control related parameters are present.  Sho= uld this option be evaluated/included to relieve the server from doing the = arrival rate calculations.  This would be beneficial to a server when = it receives the requests from many clients.”

[EN] Your suggestion is currently not supported by= draft-ietf-soc-overload-control (there are no parameters that would allow = clients to inform server of their respective arrival rates) from which draf= t-ietf-soc-overload-rate-control depends upon. You may want to propose this= option to draft-ietf-soc-overload-control authors. But in practice, server= s estimate percent blocking or rate dynamically based on their overload sta= te so as to have clients throttle at a level close to servers overload onse= t level.

 

Thanks,

 

Eric Noel

AT&T Labs, Inc.
Rethink Pos= sible

 

Network Design and Performance= Analysis
200 South Laurel Avenue, D5-3D19
Middletown, NJ 07748
P:= 732.420.4174

ecnoel@att.com

=

 

From: Yu, James [mailto:james.yu@neustar.biz]
Se= nt: Wednesday, July 10, 2013 9:01 AM
To: NOEL, ERIC C (ERIC C= )
Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate= -control.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [= sip-overload] draft-ietf-soc-overload-rate-control-04.txt=

 

Noel,

&nbs= p;

I mentioned in my message to= Janet on 7/2:

 =

For t= he rate control, the server could calculate the arrival rate from each comm= unicating client so that it could allocate the overall target SIP request r= ate to the clients based on their arrival rates known to the server.  = But another option is for the client to “optionally” include it= s calculated arrival rate in its request to the server when rate control re= lated parameters are present.  Should this option be evaluated/include= d to relieve the server from doing the arrival rate calculations.  Thi= s would be beneficial to a server when it receives the requests from many c= lients.

 <= /span>

I suggest that the I-D adds that opti= on to allow the client to indicate its current arrival rate (towards the re= ceiving server) in the SIP request.

 

James

 

<= div>

From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@= research.att.com]
Sent: Tuesday, July 09, 2013 4:44 PM
To:= Yu, James; Janet P Gunn
Cc: sip-overload-bounces@ietf.org; d= raft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.o= rg
Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-contr= ol-04.txt

 =

Janet, James,

 

= Thanks you for your valuable comments and discussion.  I tried = to capture all resolution in the following text (based on James word docume= nt with track changes and imbedded comments enabled).

=

 

+ Abstract section:

- Agreed with suggested changes

- Please note I will also need to make further changes to remove = all references per Christer Holmberg comment

 

+ Section 1:

- Agreed wit= h suggested changes

 

+ Section 3.1:

- Agreed with suggested changes

 

+ Section 3.2: - Please note the section title= will become “Via header field parameters for overload control “= ; per Christer Holmberg comment

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>- Agreed with suggested changes excluding title that will change per = previous bullet

 = ;

+ Section 3.3:

- Agreed with suggested changes

 

+ Section 3.4:

- ID:  "Note that the target SIP request rate is a max= rate that may not be attained by the arrival rate at the client, and the s= erver cannot assume that it will."

   [JY] Not clear what value this paragraph t= ries to add.  Is it saying that the client's arrival rate may be lower= than the target SIP request rate?

   [JG] Yes + supporting example (see below in thr= ead)

  Agreed wi= th Janet and supporting example. Per James request, I will add the followin= g text (inspired from Janet’s illustrative example):

   “In other words, when m= ultiple clients are being controlled by an overloaded server, at any given = time some clients may receive requests at a rate below its target SIP reque= st rate while others above that target rate. But the resulting request rate= presented to the overloaded server will converge towards the target SIP re= quest rate.”

- Agree= d with other suggested changes

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>     

+ Section 3.5.1:

- ID: “And the larger the difference between TAU1 and TAU2, the clo= ser to the control is to strict priority.”

  [JY] Suggest changing into “And the lar= ger the difference between TAU1 and TAU2, the closer the control is to stri= ct priority queuing.”

  [JG] Suggest changing into “And the larger the difference be= tween TAU1 and TAU2, the closer the control is to strict priority treatment= .”

  [EN] Agree= d with Janet’s suggestion

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>- Agreed with other suggested changes

 

+ Section 4:

- Agreed wit= h suggested changes

 

+ Section 5:=

- Please note that based comments fr= om per Christer Holmberg and Janet Gunn, the following was tentatively agre= ed

   Repl= ace oc-value =3D "NaN" / oc-num    by   =  oc =3D "oc" [EQUAL oc-num]

- Agreed with other suggested change

=

 

+ Section 7:

- [J= Y] Should “rate” in oc-algo be registered with IANA?=

  This issue needs to be addres= sed by draft-ietf-soc-overload-control authors

 

Please note I will wait until expiration of WGLC prior updating our draft= RFC. Once again your comments and/or suggestions are most appreciated.

 

<= p class=3DMsoNormal>Thanks,

 

Eric = Noel

AT&am= p;T Labs, Inc.
Rethink Possible

 

Network Design and Performance Analysis200 South Laurel Avenue, D5-3D19
Middletown, NJ 07748
P: 732.420.417= 4

ecnoel@att.com

 

From: sip-overload= -bounces@ietf.org [mai= lto:sip-overload-bounces@ietf.org] On Behalf Of Yu, James
= Sent: Tuesday, July 02, 2013 9:42 AM
To: Janet P Gunn
C= c: sip-overload-bounce= s@ietf.org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org= ; sip-overload@ietf.org
= Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt=

 

Janet,

 

For my co= mment on section 3.4 (the first one below), the current text does not provi= de any value.  The client’s arrival rate could be well below the= target SIP request rate when its load is light so the fact that the client= may not achieve the target SIP request rate (the max. rate it is allowed t= o send to the server) is well understood.  But with your explanation o= n the “delta” part, the text then makes sense.  Please add= some discussions on the “delta” aspect so that even if the ave= rage arrival rate at the client is higher than the target SIP request rate = the client at times may not send more than what the target SIP request rate= allows due to the fluctuation of the arriving requests at the client.=

 

For the comment on section 3.5.1, I agree with yo= ur proposed change.

 

For the rate control, t= he server could calculate the arrival rate from each communicating client s= o that it could allocate the overall target SIP request rate to the clients= based on their arrival rates known to the server.  But another option= is for the client to “optionally” include its calculated arriv= al rate in its request to the server when rate control related parameters a= re present.  Should this option be evaluated/included to relieve the s= erver from doing the arrival rate calculations.  This would be benefic= ial to a server when it receives the requests from many clients.=

 

James

=  

From: Janet P Gunn = [mailto:jgunn6@csc.com]
Sent:<= /b> Friday, June 28, 2013 3:34 PM
To: Yu, James
Cc: dra= ft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org; sip-overload-bounces@ietf.org
Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt

 

Jam= es,

It is a little hard to respond in email when your comments are in= a separate document, but here goes.


section 3.4
ID says:
&qu= ot;Note that the target SIP request rate is a max rate that may not be
&n= bsp;  attained by the arrival rate at the client, and the server canno= t
   assume that it will."

Your comment : "No= t clear what value this paragraph tries to add.  Is it saying that the= client's arrival rate may be lower than the target SIP request rate?  = ;"

Yes.

Suppose the server want to limit the total rate of= arriving SIP messages to 100 / sec, and has 10 clients.  Each client = has a high variance in its message rate, but together they are well above 1= 00 messages per sec

If it sets the rate at 10 messages per second for= each of the clients, it will almost certainly end up  with an overall= average of less than 100 messages per sec, because some clients will be in= a "lull" while others are busy.  This is good from a thrott= ling perspective, but, assuming messages are correlated with revenue, bad/w= asteful from a revenue, or overall productivity perspective.  So the s= erver might want to set the rate per client to 10 + delta, where delta is g= oing to be very specific to operating environment.

---
In section &= nbsp;3.5.1, bottom of page 8
ID says:
"And the larger
<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>  &nb= sp;the difference between TAU1 and TAU2, the closer to the control is
&nb= sp;  to strict priority."

You propose changing it to:
&qu= ot;And the larger
   the difference between TAU1 and TAU2, the = closer  the control is
   to strict priority queuing."= ;

I agree with taking out the redundant "to".  But I d= isagree wit adding "queuing".  There is no queuing, priority= or otherwise involved.

You could say:
"And the larger =
 = ;  the difference between TAU1 and TAU2, the closer  the control = is
   to strict priority treatment."

where " st= rict priority treatment" would refer to the case where non-priority me= ssages are restricted to a total (priority + non-priority) rate of 10 messa= ges per second, but priority messages can continue to be sent as long as th= e total (priority + non-priority) rate is less than 12 messages per second.=

At least, I think that is what Eric and  Philip are trying to s= ay.

Janet


 


This is a PRIVATE message. If yo= u 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 expr= essly permitting the use of e-mail for such purpose.


From:        "Yu, James" <james.yu@neustar.biz>
To: &= nbsp;      "sip-overload-bounces@ietf.org" <sip-overload-bounces@ietf.org>, "draft-i= etf-soc-overload-rate-control.all@tools.ietf.org" <draft-ietf-s= oc-overload-rate-control.all@tools.ietf.org>, "sip-overload@ietf.org" <sip-overload@ietf.org>
Dat= e:        06/28/2013 08:10 AM
Subject: &nbs= p;      [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt
Sent by:        sip-overload-bounces@ietf.org <= /o:p>

=
=




Salvatore,
 
Please see the attachment for my comments.
  =
I p= asted the text to a word document to trace/show the proposed changes and co= mments.
 
Regards,
 
James
 [attachment = "comments on draft-ietf-soc-overload-rate-control-04.docx" delete= d by Janet P Gunn/USA/CSC] ____= ___________________________________________
sip-overload mailing list
sip-overload@ietf.org
https://www.ietf.org/mailman/list= info/sip-overload

No virus found in this = message.
Checked by AVG - www.avg.com=
Version: 2013.0.2904 / Virus Database: 3204/6452 - Release Date: 06/30/= 13

No virus found in this message.
Checked by AVG - = www.avg.com
Version: 2013.0.2904 / Vi= rus Database: 3204/6478 - Release Date: 07/09/13

= --_000_5EBD159DE88147488A3B1590E09001840353C0687576njfpsrvexg2_-- From ecnoel@research.att.com Wed Jul 10 07:48:57 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 A03C321F9263; Wed, 10 Jul 2013 07:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVM5xPhiQqZf; Wed, 10 Jul 2013 07:48:50 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 4A27911E81AA; Wed, 10 Jul 2013 07:48:33 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id D9C1F1205DC; Wed, 10 Jul 2013 10:48:31 -0400 (EDT) Received: from njfpsrvexg2.research.att.com (njfpsrvexg2.research.att.com [135.207.177.29]) by mail-green.research.att.com (Postfix) with ESMTP id 9F8E0E0211; Wed, 10 Jul 2013 10:46:56 -0400 (EDT) Received: from njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9]) by njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9%14]) with mapi; Wed, 10 Jul 2013 10:48:32 -0400 From: "NOEL, ERIC C (ERIC C)" To: "'Yu, James'" Date: Wed, 10 Jul 2013 10:48:31 -0400 Thread-Topic: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Thread-Index: Ac5zhcqru7dYQFxqQKSGvvGKSQFJEAA0j1MAALOuppABZadV0AAr0zMgAAJGKhAAAUkxUA== Message-ID: <5EBD159DE88147488A3B1590E09001840353C0687578@njfpsrvexg2.research.att.com> References: <56FB15AFE08E1242B0736CBDCE6E85610808C32F@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610808EF90@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353BDA4CAD4@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E85610809239D@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610809253D@stntexmb12.cis.neustar.com> In-Reply-To: <56FB15AFE08E1242B0736CBDCE6E85610809253D@stntexmb12.cis.neustar.com> 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_5EBD159DE88147488A3B1590E09001840353C0687578njfpsrvexg2_" MIME-Version: 1.0 Cc: "sip-overload-bounces@ietf.org" , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" , "sip-overload@ietf.org" Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.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, 10 Jul 2013 14:48:57 -0000 --_000_5EBD159DE88147488A3B1590E09001840353C0687578njfpsrvexg2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable James, Thank you for your suggestion. Not being familiar with IANA procedure, would updating draft-ietf-soc-overl= oad-rate-control section 7 (IANA considerations) as follows work? This specification defines a new value for Via header parameter oc-algo as = detailed below in the "Header Field Parameter and Parameter Values" subregi= stry as per the registry created by [RFC3968]. The required information is: Header Field Parameter Name Predefined Val= ues Reference ---------------------------------------------------------------------------= ------------------------------- Via oc-algo = "rate" RFCXXXX RFC XXXX [NOTE TO RFC-EDITOR: Please replace with final RFC number of this = specification.] 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: Yu, James [mailto:james.yu@neustar.biz] Sent: Wednesday, July 10, 2013 10:17 AM To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all= @tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Noel, I forgot to respond to your reply about the IANA registration of "rate" in = oc-algo. I see that draft-ietf-soc-overload-control-13 mentions your I-D b= ut does not have "rate" in algo-list. There are two possible ways to address "rate" in algo-list. One is to have= draft-ietf-soc-overload-control-13 add "rate" to algo-list and refer to yo= ur I-D for details. The other is to register "rate" in algo-list with IANA= in your I-D, and this should be a simple task. The cleaner way that is mo= re inline with the IETF process would be the latter. It seems odd to have = something defined in a RFC without details about it, and it would be too mu= ch trouble to combine the two I-Ds. James From: Yu, James Sent: Wednesday, July 10, 2013 9:01 AM To: 'NOEL, ERIC C (ERIC C)' Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all= @tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Noel, I mentioned in my message to Janet on 7/2: For the rate control, the server could calculate the arrival rate from each= communicating client so that it could allocate the overall target SIP requ= est rate to the clients based on their arrival rates known to the server. = But another option is for the client to "optionally" include its calculated= arrival rate in its request to the server when rate control related parame= ters are present. Should this option be evaluated/included to relieve the = server from doing the arrival rate calculations. This would be beneficial = to a server when it receives the requests from many clients. I suggest that the I-D adds that option to allow the client to indicate its= current arrival rate (towards the receiving server) in the SIP request. James From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] Sent: Tuesday, July 09, 2013 4:44 PM To: Yu, James; Janet P Gunn Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Janet, James, Thanks you for your valuable comments and discussion. I tried to capture a= ll resolution in the following text (based on James word document with trac= k changes and imbedded comments enabled). + Abstract section: - Agreed with suggested changes - Please note I will also need to make further changes to remove all refere= nces per Christer Holmberg comment + Section 1: - Agreed with suggested changes + Section 3.1: - Agreed with suggested changes + Section 3.2: - Please note the section title will become "Via header fiel= d parameters for overload control " per Christer Holmberg comment - Agreed with suggested changes excluding title that will change per previo= us bullet + Section 3.3: - Agreed with suggested changes + Section 3.4: - ID: "Note that the target SIP request rate is a max rate that may not be= attained by the arrival rate at the client, and the server cannot assume t= hat it will." [JY] Not clear what value this paragraph tries to add. Is it saying tha= t the client's arrival rate may be lower than the target SIP request rate? [JG] Yes + supporting example (see below in thread) Agreed with Janet and supporting example. Per James request, I will add t= he following text (inspired from Janet's illustrative example): "In other words, when multiple clients are being controlled by an overlo= aded server, at any given time some clients may receive requests at a rate = below its target SIP request rate while others above that target rate. But = the resulting request rate presented to the overloaded server will converge= towards the target SIP request rate." - Agreed with other suggested changes + Section 3.5.1: - ID: "And the larger the difference between TAU1 and TAU2, the closer to t= he control is to strict priority." [JY] Suggest changing into "And the larger the difference between TAU1 an= d TAU2, the closer the control is to strict priority queuing." [JG] Suggest changing into "And the larger the difference between TAU1 an= d TAU2, the closer the control is to strict priority treatment." [EN] Agreed with Janet's suggestion - Agreed with other suggested changes + Section 4: - Agreed with suggested changes + Section 5: - Please note that based comments from per Christer Holmberg and Janet Gunn= , the following was tentatively agreed Replace oc-value =3D "NaN" / oc-num by oc =3D "oc" [EQUAL oc-num] - Agreed with other suggested change + Section 7: - [JY] Should "rate" in oc-algo be registered with IANA? This issue needs to be addressed by draft-ietf-soc-overload-control autho= rs Please note I will wait until expiration of WGLC prior updating our draft R= FC. Once again your comments and/or suggestions are most appreciated. 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 Yu, James Sent: Tuesday, July 02, 2013 9:42 AM To: Janet P Gunn Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Janet, For my comment on section 3.4 (the first one below), the current text does = not provide any value. The client's arrival rate could be well below the t= arget SIP request rate when its load is light so the fact that the client m= ay not achieve the target SIP request rate (the max. rate it is allowed to = send to the server) is well understood. But with your explanation on the "= delta" part, the text then makes sense. Please add some discussions on the= "delta" aspect so that even if the average arrival rate at the client is h= igher than the target SIP request rate the client at times may not send mor= e than what the target SIP request rate allows due to the fluctuation of th= e arriving requests at the client. For the comment on section 3.5.1, I agree with your proposed change. For the rate control, the server could calculate the arrival rate from each= communicating client so that it could allocate the overall target SIP requ= est rate to the clients based on their arrival rates known to the server. = But another option is for the client to "optionally" include its calculated= arrival rate in its request to the server when rate control related parame= ters are present. Should this option be evaluated/included to relieve the = server from doing the arrival rate calculations. This would be beneficial = to a server when it receives the requests from many clients. James From: Janet P Gunn [mailto:jgunn6@csc.com] Sent: Friday, June 28, 2013 3:34 PM To: Yu, James Cc: draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org; sip-overload-bounces@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, It is a little hard to respond in email when your comments are in a separat= e document, but here goes. section 3.4 ID says: "Note that the target SIP request rate is a max rate that may not be attained by the arrival rate at the client, and the server cannot assume that it will." Your comment : "Not clear what value this paragraph tries to add. Is it saying that the c= lient's arrival rate may be lower than the target SIP request rate? " Yes. Suppose the server want to limit the total rate of arriving SIP messages to= 100 / sec, and has 10 clients. Each client has a high variance in its mes= sage rate, but together they are well above 100 messages per sec If it sets the rate at 10 messages per second for each of the clients, it w= ill almost certainly end up with an overall average of less than 100 messa= ges per sec, because some clients will be in a "lull" while others are busy= . This is good from a throttling perspective, but, assuming messages are c= orrelated with revenue, bad/wasteful from a revenue, or overall productivit= y perspective. So the server might want to set the rate per client to 10 += delta, where delta is going to be very specific to operating environment. --- In section 3.5.1, bottom of page 8 ID says: "And the larger the difference between TAU1 and TAU2, the closer to the control is to strict priority." You propose changing it to: "And the larger the difference between TAU1 and TAU2, the closer the control is to strict priority queuing." I agree with taking out the redundant "to". But I disagree wit adding "que= uing". There is no queuing, priority or otherwise involved. You could say: "And the larger the difference between TAU1 and TAU2, the closer the control is to strict priority treatment." where " strict priority treatment" would refer to the case where non-priori= ty messages are restricted to a total (priority + non-priority) rate of 10 = messages per second, but priority messages can continue to be sent as long = as the total (priority + non-priority) rate is less than 12 messages per se= cond. At least, I think that is what Eric and Philip are trying to say. 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: "Yu, James" = > To: "sip-overload-bounces@ietf.org" >= , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" >, "sip-overload@ietf.org"= > Date: 06/28/2013 08:10 AM Subject: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Sent by: sip-overload-bounces@ietf.org ________________________________ Salvatore, Please see the attachment for my comments. I pasted the text to a word document to trace/show the proposed changes and= comments. Regards, James [attachment "comments on draft-ietf-soc-overload-rate-control-04.docx" del= eted by Janet P Gunn/USA/CSC] _____________________________________________= __ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6452 - Release Date: 06/30/13 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13 --_000_5EBD159DE88147488A3B1590E09001840353C0687578njfpsrvexg2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

James,

 

=

Thank you for your suggestion.

 

Not being familiar with IANA procedure, would updating draft= -ietf-soc-overload-rate-control section 7 (IANA considerations) as follows = work?

 

This specification defines a new value = for Via header parameter oc-algo as detailed below in the "Header Fiel= d Parameter and Parameter Values" subregistry as per the registry crea= ted by [RFC3968]. The required information is:

 

Header Field           = Parameter Name           =             &nb= sp;Predefined Values          =           Reference<= /o:p>

-------------------------------= ---------------------------------------------------------------------------=

Via    &nb= sp;            =             &nb= sp;oc-algo           &nbs= p;            &= nbsp;           &nbs= p;         “rate”&= nbsp;           &nbs= p;            &= nbsp;            &nb= sp;      RFCXXXX

 

RFC XXXX [NOTE TO RFC-EDITOR: Please replace with final RFC number of thi= s specification.]

&nb= sp;

Thanks,

 

Eric Noel

AT&T Labs, Inc.
Ret= hink Possible

=  

Network Design and Pe= rformance Analysis
200 South Laurel Avenue, D5-3D19
Middletown, NJ 07= 748
P: 732.420.4174

ecnoel@att.com

 

From: Yu, James [mailto:james.yu@neustar.biz] =
Sent: Wednesday, July 10, 2013 10:17 AM
To: NOEL, ERIC= C (ERIC C)
Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-ove= rload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject:= RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt

 

Noel,

 

I forgot to respon= d to your reply about the IANA registration of “rate” in oc-alg= o.  I see that draft-ietf-soc-overload-control-13 mentions your I-D bu= t does not have “rate” in algo-list.

 

There are two possible ways to address “rate” in algo-list.=   One is to have draft-ietf-soc-overload-control-13 add “rate= 221; to algo-list and refer to your I-D for details.  The other is to = register “rate” in algo-list with IANA in your I-D, and this sh= ould be a simple task.  The cleaner way that is more inline with the I= ETF process would be the latter.  It seems odd to have something defin= ed in a RFC without details about it, and it would be too much trouble to c= ombine the two I-Ds.

 

James=

 

<= p class=3DMsoNormal>From: Yu, James
Sent: Wednesday, July 10, 2013= 9:01 AM
To: 'NOEL, ERIC C (ERIC C)'
Cc: sip-overload-b= ounces@ietf.org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; s= ip-overload@ietf.org
Subject: RE: [sip-overload] draft-ietf-soc-o= verload-rate-control-04.txt

 

Noel,

 

I mentioned in my message to Janet on 7/2:

 

For the rate control, the server co= uld calculate the arrival rate from each communicating client so that it co= uld allocate the overall target SIP request rate to the clients based on th= eir arrival rates known to the server.  But another option is for the = client to “optionally” include its calculated arrival rate in i= ts request to the server when rate control related parameters are present. =  Should this option be evaluated/included to relieve the server from d= oing the arrival rate calculations.  This would be beneficial to a ser= ver when it receives the requests from many clients.

<= p class=3DMsoNormal> 

I suggest that the I-D adds that option to allow the client to indi= cate its current arrival rate (towards the receiving server) in the SIP req= uest.

 

James

 

F= rom: NOEL, ERIC C (ERIC C) [m= ailto:ecnoel@research.att.com]
Sent: Tuesday, July 09, 2013 = 4:44 PM
To: Yu, James; Janet P Gunn
Cc: sip-overload-bounces@ietf.org; draft-= ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-= overload] draft-ietf-soc-overload-rate-control-04.txt

=

 

= Janet, James,

 

Thanks you for your val= uable comments and discussion.  I tried to capture all resolution in t= he following text (based on James word document with track changes and imbe= dded comments enabled).

 

+ Abstract section: <= o:p>

- Agreed with suggested ch= anges

- Please note I will= also need to make further changes to remove all references per Christer Ho= lmberg comment

 =

+ Section 1:=

- Agreed with suggested changes<= /span>

 

+ Section 3.1:

- Agreed with suggested changes

 

+ S= ection 3.2: - Please note the section title will become “Via header f= ield parameters for overload control “ per Christer Holmberg comment<= o:p>

- Agreed with suggested ch= anges excluding title that will change per previous bullet

 

+ Section 3.3:

- Agreed with suggested changes

 

+ Section = 3.4:

- ID:  "Not= e that the target SIP request rate is a max rate that may not be attained b= y the arrival rate at the client, and the server cannot assume that it will= ."

   = ;[JY] Not clear what value this paragraph tries to add.  Is it saying = that the client's arrival rate may be lower than the target SIP request rat= e?

   [JG]= Yes + supporting example (see below in thread)

  Agreed with Janet and supporting example.= Per James request, I will add the following text (inspired from Janet̵= 7;s illustrative example):

   “In other words, when multiple clients are being contro= lled by an overloaded server, at any given time some clients may receive re= quests at a rate below its target SIP request rate while others above that = target rate. But the resulting request rate presented to the overloaded ser= ver will converge towards the target SIP request rate.”

- Agreed with other suggested changes <= o:p>

    &n= bsp;

+ Section 3.5.1:=

- ID: “And the larger th= e difference between TAU1 and TAU2, the closer to the control is to strict = priority.”

  [J= Y] Suggest changing into “And the larger the difference between TAU1 = and TAU2, the closer the control is to strict priority queuing.”=

  [JG] Suggest changing i= nto “And the larger the difference between TAU1 and TAU2, the closer = the control is to strict priority treatment.”

  [EN] Agreed with Janet’s suggestion<= o:p>

- Agreed with other sugges= ted changes

 

+ Section 4:

- Agreed with suggested changes

 

+ Section 5:

- Please note that based comments from per Christer Holmberg and Janet G= unn, the following was tentatively agreed

   Replace oc-value =3D "NaN" / o= c-num    by    oc =3D "oc" [EQUAL o= c-num]

- Agreed with other= suggested change

&nb= sp;

+ Section 7:

- [JY] Should “rate” in oc-a= lgo be registered with IANA?

  This issue needs to be addressed by draft-ietf-soc-overload-contr= ol authors

 

Please note I will wait until expi= ration of WGLC prior updating our draft RFC. Once again your comments and/o= r suggestions are most appreciated.

 

Thanks,

 

Eric Noel <= /p>

AT&T Labs, Inc.
= Rethink Possible

 

Net= work Design and Performance Analysis
200 South Laurel Avenue, D5-3D19Middletown, NJ 07748
P: 732.420.4174

ecnoel@att.com

 

 

Janet,<= o:p>

 

For my comment on section 3.4 (the first one = below), the current text does not provide any value.  The client’= ;s arrival rate could be well below the target SIP request rate when its lo= ad is light so the fact that the client may not achieve the target SIP requ= est rate (the max. rate it is allowed to send to the server) is well unders= tood.  But with your explanation on the “delta” part, the = text then makes sense.  Please add some discussions on the “delt= a” aspect so that even if the average arrival rate at the client is h= igher than the target SIP request rate the client at times may not send mor= e than what the target SIP request rate allows due to the fluctuation of th= e arriving requests at the client.

 

For the co= mment on section 3.5.1, I agree with your proposed change.

 

For the rate control, the server could calculate the arrival = rate from each communicating client so that it could allocate the overall t= arget SIP request rate to the clients based on their arrival rates known to= the server.  But another option is for the client to “optionall= y” include its calculated arrival rate in its request to the server w= hen rate control related parameters are present.  Should this option b= e evaluated/included to relieve the server from doing the arrival rate calc= ulations.  This would be beneficial to a server when it receives the r= equests from many clients.

 

James

 

 

James,

It is a little hard to respo= nd in email when your comments are in a separate document, but here goes.


section 3.4
ID says:
"Note that the target SIP request ra= te is a max rate that may not be
   attained by the arrival rat= e at the client, and the server cannot
   assume that it will.&= quot;

Your comment :
"Not clear what value this paragraph trie= s to add.  Is it saying that the client's arrival rate may be lower th= an the target SIP request rate?  "

Yes.

Suppose the s= erver want to limit the total rate of arriving SIP messages to 100 / sec, a= nd has 10 clients.  Each client has a high variance in its message rat= e, but together they are well above 100 messages per sec

If it sets t= he rate at 10 messages per second for each of the clients, it will almost c= ertainly end up  with an overall average of less than 100 messages per= sec, because some clients will be in a "lull" while others are b= usy.  This is good from a throttling perspective, but, assuming messag= es are correlated with revenue, bad/wasteful from a revenue, or overall pro= ductivity perspective.  So the server might want to set the rate per c= lient to 10 + delta, where delta is going to be very specific to operating = environment.

---
In section  3.5.1, bottom of page 8 ID says= :
"And the larger
   the difference between TAU1 and TAU= 2, the closer to the control is
   to strict priority."

You propose changing it to:
"And the larger
   the d= ifference between TAU1 and TAU2, the closer  the control is   &= nbsp;to strict priority queuing."

I agree with taking out the re= dundant "to".  But I disagree wit adding "queuing"= .  There is no queuing, priority or otherwise involved.
You coul= d say:
"And the larger
   the difference between TAU1 an= d TAU2, the closer  the control is
   to strict priority t= reatment."

where " strict priority treatment" would re= fer to the case where non-priority messages are restricted to a total (prio= rity + non-priority) rate of 10 messages per second, but priority messages = can continue to be sent as long as the total (priority + non-priority) rate= is less than 12 messages per second.

At least, I think that is what = Eric and  Philip are trying to say.

Janet


 

This is a PRIVATE message. If you are not the intended recipient, plea= se 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 bin= d CSC to any order or other contract unless pursuant to explicit written ag= reement or government initiative expressly permitting the use of e-mail for= such purpose.



From:        = &qu= ot;Yu, James" <james.yu@neu= star.biz>
To:        "sip-overload-bounces@ietf.org= " <sip-overload-bo= unces@ietf.org>, "draft-ietf-soc-overload-rate-control.all@tool= s.ietf.org" <draft-ietf-soc-overload-rate-control.all@tools.iet= f.org>, "sip-overload@= ietf.org" <sip-overloa= d@ietf.org>
Date:        <= span style=3D'font-size:7.5pt;font-family:"Arial","sans-serif"'>06/28/2013 = 08:10 AM
Subject:        [sip-overload] dra= ft-ietf-soc-overload-rate-control-04.txt
Sent by:   &nb= sp;    sip-overload= -bounces@ietf.org




Salvatore,
 
Please see the attachment = for my comments.
 
I pasted the text to a word document to tra= ce/show the proposed changes and comments.
 
Regards, <= br>&nbs= p;
James
 [attachment "comments on draft-ietf-soc-overloa= d-rate-control-04.docx" deleted by Janet P Gunn/USA/CSC] ____________________________________________= ___<= br>sip-overload mailing list
sip-overload@ietf.org
https://www.ietf.org/mailman/listinfo/sip-overload

<= hr size=3D1 width=3D"100%" noshade style=3D'color:#A0A0A0' align=3Dcenter><= /div>

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Databas= e: 3204/6452 - Release Date: 06/30/13

No virus found in t= his message.
Checked by AVG - www.avg.com=
Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07= /09/13

= --_000_5EBD159DE88147488A3B1590E09001840353C0687578njfpsrvexg2_-- From james.yu@neustar.biz Wed Jul 10 08:35: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 8F7E921F99F7; Wed, 10 Jul 2013 08:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.322 X-Spam-Level: X-Spam-Status: No, score=-6.322 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Ba7y1ZSCdva; Wed, 10 Jul 2013 08:35:42 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 780AC21F9A16; Wed, 10 Jul 2013 08:35:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1373470715; x=1688826968; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=Hz5zGiI9TWdUZL+/lDLFoIjYA0Mb7TGYCCeoKQTo0mI=; b=GgP5mWNZ2YrreCMmwDEyRVbLp0Mn133PHKdJLSzzJb4vM9c7S55itez1y2SOf/ /Ua851qn4t8FaPIgJQtbpdQA== Received: from ([10.31.58.69]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.26483835; Wed, 10 Jul 2013 11:38:34 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.240]) with mapi id 14.02.0342.003; Wed, 10 Jul 2013 11:35:31 -0400 From: "Yu, James" To: "NOEL, ERIC C (ERIC C)" Thread-Topic: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Thread-Index: Ac5zhcqru7dYQFxqQKSGvvGKSQFJEAA0j1MAALOuppABZadV0AAr0zMgAAJGKhAAAUkxUAABlYhg Date: Wed, 10 Jul 2013 15:35:30 +0000 Message-ID: <56FB15AFE08E1242B0736CBDCE6E856108092986@stntexmb12.cis.neustar.com> References: <56FB15AFE08E1242B0736CBDCE6E85610808C32F@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610808EF90@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353BDA4CAD4@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E85610809239D@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610809253D@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353C0687578@njfpsrvexg2.research.att.com> In-Reply-To: <5EBD159DE88147488A3B1590E09001840353C0687578@njfpsrvexg2.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.31.32.239] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: /py+BfEIlptXqK4nYzMmyA== Content-Type: multipart/alternative; boundary="_000_56FB15AFE08E1242B0736CBDCE6E856108092986stntexmb12cisne_" MIME-Version: 1.0 Cc: "sip-overload-bounces@ietf.org" , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" , "sip-overload@ietf.org" Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.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, 10 Jul 2013 15:35:50 -0000 --_000_56FB15AFE08E1242B0736CBDCE6E856108092986stntexmb12cisne_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Eric, Yes, this adds "rate" to "oc-algo" parameter but please check with IANA to = see if it is the correct way. You also need to copy some syntax lines from= the draft-ietf-soc-overload-control to show algo-list =3D "loss" / "rate" / *(other-algo) I've an email to Henning asking if algo-list in his I-D should be algo-list =3D "loss" / other-algo If yes, then this particular line in your I-D would be algo-list =3D "loss" / "rate" / other-algo James From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] Sent: Wednesday, July 10, 2013 10:49 AM To: Yu, James Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all= @tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, Thank you for your suggestion. Not being familiar with IANA procedure, would updating draft-ietf-soc-overl= oad-rate-control section 7 (IANA considerations) as follows work? This specification defines a new value for Via header parameter oc-algo as = detailed below in the "Header Field Parameter and Parameter Values" subregi= stry as per the registry created by [RFC3968]. The required information is: Header Field Parameter Name Predefined Val= ues Reference ---------------------------------------------------------------------------= ------------------------------- Via oc-algo = "rate" RFCXXXX RFC XXXX [NOTE TO RFC-EDITOR: Please replace with final RFC number of this = specification.] 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: Yu, James [mailto:james.yu@neustar.biz] Sent: Wednesday, July 10, 2013 10:17 AM To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Noel, I forgot to respond to your reply about the IANA registration of "rate" in = oc-algo. I see that draft-ietf-soc-overload-control-13 mentions your I-D b= ut does not have "rate" in algo-list. There are two possible ways to address "rate" in algo-list. One is to have= draft-ietf-soc-overload-control-13 add "rate" to algo-list and refer to yo= ur I-D for details. The other is to register "rate" in algo-list with IANA= in your I-D, and this should be a simple task. The cleaner way that is mo= re inline with the IETF process would be the latter. It seems odd to have = something defined in a RFC without details about it, and it would be too mu= ch trouble to combine the two I-Ds. James From: Yu, James Sent: Wednesday, July 10, 2013 9:01 AM To: 'NOEL, ERIC C (ERIC C)' Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Noel, I mentioned in my message to Janet on 7/2: For the rate control, the server could calculate the arrival rate from each= communicating client so that it could allocate the overall target SIP requ= est rate to the clients based on their arrival rates known to the server. = But another option is for the client to "optionally" include its calculated= arrival rate in its request to the server when rate control related parame= ters are present. Should this option be evaluated/included to relieve the = server from doing the arrival rate calculations. This would be beneficial = to a server when it receives the requests from many clients. I suggest that the I-D adds that option to allow the client to indicate its= current arrival rate (towards the receiving server) in the SIP request. James From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] Sent: Tuesday, July 09, 2013 4:44 PM To: Yu, James; Janet P Gunn Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Janet, James, Thanks you for your valuable comments and discussion. I tried to capture a= ll resolution in the following text (based on James word document with trac= k changes and imbedded comments enabled). + Abstract section: - Agreed with suggested changes - Please note I will also need to make further changes to remove all refere= nces per Christer Holmberg comment + Section 1: - Agreed with suggested changes + Section 3.1: - Agreed with suggested changes + Section 3.2: - Please note the section title will become "Via header fiel= d parameters for overload control " per Christer Holmberg comment - Agreed with suggested changes excluding title that will change per previo= us bullet + Section 3.3: - Agreed with suggested changes + Section 3.4: - ID: "Note that the target SIP request rate is a max rate that may not be= attained by the arrival rate at the client, and the server cannot assume t= hat it will." [JY] Not clear what value this paragraph tries to add. Is it saying tha= t the client's arrival rate may be lower than the target SIP request rate? [JG] Yes + supporting example (see below in thread) Agreed with Janet and supporting example. Per James request, I will add t= he following text (inspired from Janet's illustrative example): "In other words, when multiple clients are being controlled by an overlo= aded server, at any given time some clients may receive requests at a rate = below its target SIP request rate while others above that target rate. But = the resulting request rate presented to the overloaded server will converge= towards the target SIP request rate." - Agreed with other suggested changes + Section 3.5.1: - ID: "And the larger the difference between TAU1 and TAU2, the closer to t= he control is to strict priority." [JY] Suggest changing into "And the larger the difference between TAU1 an= d TAU2, the closer the control is to strict priority queuing." [JG] Suggest changing into "And the larger the difference between TAU1 an= d TAU2, the closer the control is to strict priority treatment." [EN] Agreed with Janet's suggestion - Agreed with other suggested changes + Section 4: - Agreed with suggested changes + Section 5: - Please note that based comments from per Christer Holmberg and Janet Gunn= , the following was tentatively agreed Replace oc-value =3D "NaN" / oc-num by oc =3D "oc" [EQUAL oc-num] - Agreed with other suggested change + Section 7: - [JY] Should "rate" in oc-algo be registered with IANA? This issue needs to be addressed by draft-ietf-soc-overload-control autho= rs Please note I will wait until expiration of WGLC prior updating our draft R= FC. Once again your comments and/or suggestions are most appreciated. 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 Yu, James Sent: Tuesday, July 02, 2013 9:42 AM To: Janet P Gunn Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Janet, For my comment on section 3.4 (the first one below), the current text does = not provide any value. The client's arrival rate could be well below the t= arget SIP request rate when its load is light so the fact that the client m= ay not achieve the target SIP request rate (the max. rate it is allowed to = send to the server) is well understood. But with your explanation on the "= delta" part, the text then makes sense. Please add some discussions on the= "delta" aspect so that even if the average arrival rate at the client is h= igher than the target SIP request rate the client at times may not send mor= e than what the target SIP request rate allows due to the fluctuation of th= e arriving requests at the client. For the comment on section 3.5.1, I agree with your proposed change. For the rate control, the server could calculate the arrival rate from each= communicating client so that it could allocate the overall target SIP requ= est rate to the clients based on their arrival rates known to the server. = But another option is for the client to "optionally" include its calculated= arrival rate in its request to the server when rate control related parame= ters are present. Should this option be evaluated/included to relieve the = server from doing the arrival rate calculations. This would be beneficial = to a server when it receives the requests from many clients. James From: Janet P Gunn [mailto:jgunn6@csc.com] Sent: Friday, June 28, 2013 3:34 PM To: Yu, James Cc: draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org; sip-overload-bounces@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, It is a little hard to respond in email when your comments are in a separat= e document, but here goes. section 3.4 ID says: "Note that the target SIP request rate is a max rate that may not be attained by the arrival rate at the client, and the server cannot assume that it will." Your comment : "Not clear what value this paragraph tries to add. Is it saying that the c= lient's arrival rate may be lower than the target SIP request rate? " Yes. Suppose the server want to limit the total rate of arriving SIP messages to= 100 / sec, and has 10 clients. Each client has a high variance in its mes= sage rate, but together they are well above 100 messages per sec If it sets the rate at 10 messages per second for each of the clients, it w= ill almost certainly end up with an overall average of less than 100 messa= ges per sec, because some clients will be in a "lull" while others are busy= . This is good from a throttling perspective, but, assuming messages are c= orrelated with revenue, bad/wasteful from a revenue, or overall productivit= y perspective. So the server might want to set the rate per client to 10 += delta, where delta is going to be very specific to operating environment. --- In section 3.5.1, bottom of page 8 ID says: "And the larger the difference between TAU1 and TAU2, the closer to the control is to strict priority." You propose changing it to: "And the larger the difference between TAU1 and TAU2, the closer the control is to strict priority queuing." I agree with taking out the redundant "to". But I disagree wit adding "que= uing". There is no queuing, priority or otherwise involved. You could say: "And the larger the difference between TAU1 and TAU2, the closer the control is to strict priority treatment." where " strict priority treatment" would refer to the case where non-priori= ty messages are restricted to a total (priority + non-priority) rate of 10 = messages per second, but priority messages can continue to be sent as long = as the total (priority + non-priority) rate is less than 12 messages per se= cond. At least, I think that is what Eric and Philip are trying to say. 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: "Yu, James" = > To: "sip-overload-bounces@ietf.org" >= , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" >, "sip-overload@ietf.org"= > Date: 06/28/2013 08:10 AM Subject: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Sent by: sip-overload-bounces@ietf.org ________________________________ Salvatore, Please see the attachment for my comments. I pasted the text to a word document to trace/show the proposed changes and= comments. Regards, James [attachment "comments on draft-ietf-soc-overload-rate-control-04.docx" del= eted by Janet P Gunn/USA/CSC] _____________________________________________= __ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6452 - Release Date: 06/30/13 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13 --_000_56FB15AFE08E1242B0736CBDCE6E856108092986stntexmb12cisne_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Eric,

 <= /p>

Yes, this adds “rat= e” to “oc-algo” parameter but please check with IANA to s= ee if it is the correct way.  You also need to copy some syntax lines = from the draft-ietf-soc-overload-control to show

 <= /p>

     algo-list   =3D “loss“ / “rate“ / *(other-algo)

 <= /p>

I’ve an email to He= nning asking if algo-list in his I-D should be

     = algo-list   =3D “loss“ / other-algo

 <= /p>

If yes, then this particu= lar line in your I-D would be

    &= nbsp;algo-list   =3D “loss“ / “rate“ / other-algo

 <= /p>

James

 <= /p>

From: NOEL, ER= IC C (ERIC C) [mailto:ecnoel@research.att.com]
Sent: Wednesday, July 10, 2013 10:49 AM
To: Yu, James
Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-cont= rol.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt

 

James,<= /p>

 <= /p>

Thank you for your sugges= tion.

 <= /p>

Not being familiar with I= ANA procedure, would updating draft-ietf-soc-overload-rate-control section = 7 (IANA considerations) as follows work?

 <= /p>

This specification define= s a new value for Via header parameter oc-algo as detailed below in the &qu= ot;Header Field Parameter and Parameter Values" subregistry as per the registry created by [RFC3968]. The required information is:

 <= /p>

Header Field   =         Parameter Name   =             &nb= sp;        Predefined Values  =             &nb= sp;     Reference

-------------------------= ---------------------------------------------------------------------------= ------

Via    &nb= sp;            =             &nb= sp;oc-algo           &nbs= p;            &= nbsp;           &nbs= p;         “rate”&= nbsp;           &nbs= p;            &= nbsp;            &nb= sp;      RFCXXXX

 <= /p>

RFC XXXX [NOTE TO RFC-EDI= TOR: Please replace with final RFC number of this specification.]

 <= /p>

Thanks,=

 <= /p>

Eric Noel

AT&T Labs, Inc.
Rethink Possible<= /p>

 

Network Design and Perform= ance Analysis
200 South Laurel Avenue, D5-3D19
Middletown, NJ 07748
P: 732.420.4174

ecnoel@att.com

 <= /p>

From: Yu, Jame= s [mailto:james.yu@neustar.biz]
Sent: Wednesday, July 10, 2013 10:17 AM
To: NOEL, ERIC C (ERIC C)
Cc: sip-overload-bo= unces@ietf.org; = draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt

 

Noel,

 <= /p>

I forgot to respond to yo= ur reply about the IANA registration of “rate” in oc-algo. = ; I see that draft-ietf-soc-overload-control-13 mentions your I-D but does not have “rate” in algo-list.

 <= /p>

There are two possible wa= ys to address “rate” in algo-list.  One is to have draft-i= etf-soc-overload-control-13 add “rate” to algo-list and refer t= o your I-D for details.  The other is to register “rate” in algo-lis= t with IANA in your I-D, and this should be a simple task.  The cleane= r way that is more inline with the IETF process would be the latter.  = It seems odd to have something defined in a RFC without details about it, and it would be too much trouble to combine the two I-Ds.

 <= /p>

James

 <= /p>

From: Yu, Jame= s
Sent: Wednesday, July 10, 2013 9:01 AM
To: 'NOEL, ERIC C (ERIC C)'
Cc: sip-overload-bo= unces@ietf.org; = draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt

 

Noel,

 <= /p>

I mentioned in my message= to Janet on 7/2:

 <= /p>

= For the rate control, the server could calculate the arrival rate from each= communicating client so that it could allocate the overall target SIP request rate to the clients based on their arrival rates known = to the server.  But another option is for the client to “optiona= lly” include its calculated arrival rate in its request to the server= when rate control related parameters are present.  Should this option be evaluated/included to relieve the server from = doing the arrival rate calculations.  This would be beneficial to a se= rver when it receives the requests from many clients.

 <= /p>

I suggest that the I-D ad= ds that option to allow the client to indicate its current arrival rate (to= wards the receiving server) in the SIP request.

 <= /p>

James

 <= /p>

From: NOEL, ER= IC C (ERIC C) [mailto:ecnoel@res= earch.att.com]
Sent: Tuesday, July 09, 2013 4:44 PM
To: Yu, James; Janet P Gunn
Cc: sip-overload-bo= unces@ietf.org; = draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt

 

Janet, James,<= /span>

 <= /p>

Thanks you for your valua= ble comments and discussion.  I tried to capture all resolution in the= following text (based on James word document with track changes and imbedded comments enabled).

 <= /p>

+ Abstract section:

- Agreed with suggested c= hanges

- Please note I will also= need to make further changes to remove all references per Christer Holmber= g comment

 <= /p>

+ Section 1:

- Agreed with suggested c= hanges

 <= /p>

+ Section 3.1:

- Agreed with suggested c= hanges

 

+ Section 3.2: - Plea= se note the section title will become “Via header field parameters fo= r overload control “ per Christer Holmberg comment<= /p>

- Agreed with suggested c= hanges excluding title that will change per previous bullet

 <= /p>

+ Section 3.3:

- Agreed with suggested c= hanges

 <= /p>

+ Section 3.4:

- ID:  "Note th= at the target SIP request rate is a max rate that may not be attained by th= e arrival rate at the client, and the server cannot assume that it will."

   [JY] No= t clear what value this paragraph tries to add.  Is it saying that the= client's arrival rate may be lower than the target SIP request rate?

   [JG] Ye= s + supporting example (see below in thread)

  Agreed with J= anet and supporting example. Per James request, I will add the following te= xt (inspired from Janet’s illustrative example):

   “In ot= her words, when multiple clients are being controlled by an overloaded serv= er, at any given time some clients may receive requests at a rate below its target SIP request rate while others above that target rate. But the r= esulting request rate presented to the overloaded server will converge towa= rds the target SIP request rate.”

- Agreed with other sugge= sted changes

    &= nbsp;

+ Section 3.5.1:=

- ID: “And the larg= er the difference between TAU1 and TAU2, the closer to the control is to st= rict priority.”

  [JY] Suggest chang= ing into “And the larger the difference between TAU1 and TAU2, the cl= oser the control is to strict priority queuing.”

  [JG] Suggest chang= ing into “And the larger the difference between TAU1 and TAU2, the cl= oser the control is to strict priority treatment.”<= /p>

  [EN] Agreed with J= anet’s suggestion

- Agreed with other sugge= sted changes

 <= /p>

+ Section 4:

- Agreed with suggested c= hanges

 <= /p>

+ Section 5:

- Please note that based = comments from per Christer Holmberg and Janet Gunn, the following was tenta= tively agreed

   Replace= oc-value =3D "NaN" / oc-num    by   &nb= sp;oc =3D "oc" [EQUAL oc-num]

- Agreed with other sugge= sted change

 <= /p>

+ Section 7:

- [JY] Should “rate= ” in oc-algo be registered with IANA?

  This issue needs t= o be addressed by draft-ietf-soc-overload-control authors=

 <= /p>

Please note I will wait u= ntil expiration of WGLC prior updating our draft RFC. Once again your comme= nts and/or suggestions are most appreciated.

 <= /p>

Thanks,=

 <= /p>

Eric Noel

AT&T Labs, Inc.
Rethink Possible<= /p>

 

Network Design and Perform= ance Analysis
200 South Laurel Avenue, D5-3D19
Middletown, NJ 07748
P: 732.420.4174

ecnoel@att.com

 <= /p>

From: sip-overload-bounces@ietf.= org [mailto:sip-overlo= ad-bounces@ietf.org] On Behalf Of Yu, James
Sent: Tuesday, July 02, 2013 9:42 AM
To: Janet P Gunn
Cc: sip-overload-bo= unces@ietf.org; = draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt

 

Janet,<= /p>

 <= /p>

For my comment on section= 3.4 (the first one below), the current text does not provide any value.&nb= sp; The client’s arrival rate could be well below the target SIP request rate when its load is light so the fact that the client may no= t achieve the target SIP request rate (the max. rate it is allowed to send = to the server) is well understood.  But with your explanation on the &= #8220;delta” part, the text then makes sense.  Please add some discussions on the “delta” aspect so that even= if the average arrival rate at the client is higher than the target SIP re= quest rate the client at times may not send more than what the target SIP r= equest rate allows due to the fluctuation of the arriving requests at the client.

 <= /p>

For the comment on sectio= n 3.5.1, I agree with your proposed change.

 <= /p>

For the rate control, the= server could calculate the arrival rate from each communicating client so = that it could allocate the overall target SIP request rate to the clients based on their arrival rates known to the server.  But= another option is for the client to “optionally” include its c= alculated arrival rate in its request to the server when rate control relat= ed parameters are present.  Should this option be evaluated/included to relieve the server from doing the arrival rate calcu= lations.  This would be beneficial to a server when it receives the re= quests from many clients.

 <= /p>

James

 <= /p>

From: Janet P = Gunn [mailto:jgunn6@csc.com]
Sent: Friday, June 28, 2013 3:34 PM
To: Yu, James
Cc: draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org; sip-overload-bounces@ietf.org
Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt

 

James,

It is a little hard to respond in email when your comments are i= n a separate document, but here goes.


section 3.4
ID says:
"Note that the target SIP request rate is a max rate that m= ay not be
   attained by the arrival rate at the client, and the= server cannot
   assume that it will."

Your comment :
"Not clear what value this paragraph tries to add.  Is= it saying that the client's arrival rate may be lower than the target SIP = request rate?  "

Yes.

Suppose the server want to limit the total rate of arriving SIP = messages to 100 / sec, and has 10 clients.  Each client has a high var= iance in its message rate, but together they are well above 100 messages per sec

If it sets the rate at 10 messages per second for each of the cl= ients, it will almost certainly end up  with an overall average of les= s than 100 messages per sec, because some clients will be in a "lull" while others are busy.  This is good from a thrott= ling perspective, but, assuming messages are correlated with revenue, bad/w= asteful from a revenue, or overall productivity perspective.  So the s= erver might want to set the rate per client to 10 + delta, where delta is going to be very specific to operating environment.<= /span>

---
In section  3.5.1, bottom of page 8
ID says:
"And the larger
   the difference between TAU1 and TAU2, the closer to= the control is
   to strict priority."

You propose changing it to:
"And the larger
   the difference between TAU1 and TAU2, the closer &n= bsp;the control is
   to strict priority queuing."

I agree with taking out the redundant "to".  But = I disagree wit adding "queuing".  There is no queuing, prior= ity or otherwise involved.

You could say:
"And the larger
   the difference between TAU1 and TAU2, the closer &n= bsp;the control is
   to strict priority treatment."

where " strict priority treatment" would refer to the = case where non-priority messages are restricted to a total (priority + = non-priority) rate of 10 messages per second, but priority messages can continue to be sent as long as the total (priority + non-priority)= rate is less than 12 messages per second.

At least, I think that is what Eric and  Philip are trying = to say.

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 agreement or government initiative exp= ressly permitting the use of e-mail for such purpose.



From:        &= quot;Yu, James" <james.yu@n= eustar.biz>
To:        &= quot;sip-overload-bounces@= ietf.org" <sip= -overload-bounces@ietf.org>, "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" &l= t;draft-ietf-soc-overload-rate-control.all@tools.ietf.org>, "sip-overload@ietf.org&q= uot; <sip-overload@ietf.org= >
Date:        0= 6/28/2013 08:10 AM
Subject:        [sip-overload] draft-ietf-soc-overload-rate-control-04.txt
Sent by:        sip-overload-bounces@iet= f.org




Salvatore,
 
Please see the attachment for my comments.
 
I pasted the text to a word document to trace/show the propose= d changes and comments.
 
Regards,
 
James
 [attachment "comments on draft-ietf-soc-overload-ra= te-control-04.docx" deleted by Janet P Gunn/USA/CSC] _______________________________= ________________
sip-overload mailing list
sip-overload@ietf.org=
<= span style=3D"font-size:10.0pt">https://www.ietf.org/mailman/listinfo/sip-o= verload

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 3204/6452 - Release Date: 06/30/13

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13

--_000_56FB15AFE08E1242B0736CBDCE6E856108092986stntexmb12cisne_-- From ecnoel@research.att.com Wed Jul 10 10:10: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 5DC1221F9E69; Wed, 10 Jul 2013 10:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OuSspr-dbcIz; Wed, 10 Jul 2013 10:10:12 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id C6FB121F9E15; Wed, 10 Jul 2013 10:10:11 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id C18161204A0; Wed, 10 Jul 2013 13:10:08 -0400 (EDT) Received: from njfpsrvexg2.research.att.com (njfpsrvexg2.research.att.com [135.207.177.29]) by mail-green.research.att.com (Postfix) with ESMTP id 65C6FE0211; Wed, 10 Jul 2013 13:08:33 -0400 (EDT) Received: from njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9]) by njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9%14]) with mapi; Wed, 10 Jul 2013 13:10:09 -0400 From: "NOEL, ERIC C (ERIC C)" To: "'Yu, James'" Date: Wed, 10 Jul 2013 13:10:09 -0400 Thread-Topic: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Thread-Index: Ac5zhcqru7dYQFxqQKSGvvGKSQFJEAA0j1MAALOuppABZadV0AAr0zMgAAJGKhAAAUkxUAABlYhgAAIP6nA= Message-ID: <5EBD159DE88147488A3B1590E09001840353C068757C@njfpsrvexg2.research.att.com> References: <56FB15AFE08E1242B0736CBDCE6E85610808C32F@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610808EF90@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353BDA4CAD4@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E85610809239D@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610809253D@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353C0687578@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E856108092986@stntexmb12.cis.neustar.com> In-Reply-To: <56FB15AFE08E1242B0736CBDCE6E856108092986@stntexmb12.cis.neustar.com> 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_5EBD159DE88147488A3B1590E09001840353C068757Cnjfpsrvexg2_" MIME-Version: 1.0 Cc: "sip-overload-bounces@ietf.org" , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" , "sip-overload@ietf.org" Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.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, 10 Jul 2013 17:10:27 -0000 --_000_5EBD159DE88147488A3B1590E09001840353C068757Cnjfpsrvexg2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable James, Based on your suggestion and comments from other reviewers, I intend to upd= ate section 5 (syntax) as follows: oc =3D "oc" [EQUAL oc-num] oc-num =3D 1*DIGIT algo-list =3D "loss" / "rate" / *(other-algo) other-algo =3D %x41-5A / %x61-7A / %x30-39 I understand there may be an additional change following Henning's reply. 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: Yu, James [mailto:james.yu@neustar.biz] Sent: Wednesday, July 10, 2013 11:36 AM To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all= @tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Eric, Yes, this adds "rate" to "oc-algo" parameter but please check with IANA to = see if it is the correct way. You also need to copy some syntax lines from= the draft-ietf-soc-overload-control to show algo-list =3D "loss" / "rate" / *(other-algo) I've an email to Henning asking if algo-list in his I-D should be algo-list =3D "loss" / other-algo If yes, then this particular line in your I-D would be algo-list =3D "loss" / "rate" / other-algo James From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] Sent: Wednesday, July 10, 2013 10:49 AM To: Yu, James Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all= @tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, Thank you for your suggestion. Not being familiar with IANA procedure, would updating draft-ietf-soc-overl= oad-rate-control section 7 (IANA considerations) as follows work? This specification defines a new value for Via header parameter oc-algo as = detailed below in the "Header Field Parameter and Parameter Values" subregi= stry as per the registry created by [RFC3968]. The required information is: Header Field Parameter Name Predefined Val= ues Reference ---------------------------------------------------------------------------= ------------------------------- Via oc-algo = "rate" RFCXXXX RFC XXXX [NOTE TO RFC-EDITOR: Please replace with final RFC number of this = specification.] 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: Yu, James [mailto:james.yu@neustar.biz] Sent: Wednesday, July 10, 2013 10:17 AM To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Noel, I forgot to respond to your reply about the IANA registration of "rate" in = oc-algo. I see that draft-ietf-soc-overload-control-13 mentions your I-D b= ut does not have "rate" in algo-list. There are two possible ways to address "rate" in algo-list. One is to have= draft-ietf-soc-overload-control-13 add "rate" to algo-list and refer to yo= ur I-D for details. The other is to register "rate" in algo-list with IANA= in your I-D, and this should be a simple task. The cleaner way that is mo= re inline with the IETF process would be the latter. It seems odd to have = something defined in a RFC without details about it, and it would be too mu= ch trouble to combine the two I-Ds. James From: Yu, James Sent: Wednesday, July 10, 2013 9:01 AM To: 'NOEL, ERIC C (ERIC C)' Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Noel, I mentioned in my message to Janet on 7/2: For the rate control, the server could calculate the arrival rate from each= communicating client so that it could allocate the overall target SIP requ= est rate to the clients based on their arrival rates known to the server. = But another option is for the client to "optionally" include its calculated= arrival rate in its request to the server when rate control related parame= ters are present. Should this option be evaluated/included to relieve the = server from doing the arrival rate calculations. This would be beneficial = to a server when it receives the requests from many clients. I suggest that the I-D adds that option to allow the client to indicate its= current arrival rate (towards the receiving server) in the SIP request. James From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] Sent: Tuesday, July 09, 2013 4:44 PM To: Yu, James; Janet P Gunn Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Janet, James, Thanks you for your valuable comments and discussion. I tried to capture a= ll resolution in the following text (based on James word document with trac= k changes and imbedded comments enabled). + Abstract section: - Agreed with suggested changes - Please note I will also need to make further changes to remove all refere= nces per Christer Holmberg comment + Section 1: - Agreed with suggested changes + Section 3.1: - Agreed with suggested changes + Section 3.2: - Please note the section title will become "Via header fiel= d parameters for overload control " per Christer Holmberg comment - Agreed with suggested changes excluding title that will change per previo= us bullet + Section 3.3: - Agreed with suggested changes + Section 3.4: - ID: "Note that the target SIP request rate is a max rate that may not be= attained by the arrival rate at the client, and the server cannot assume t= hat it will." [JY] Not clear what value this paragraph tries to add. Is it saying tha= t the client's arrival rate may be lower than the target SIP request rate? [JG] Yes + supporting example (see below in thread) Agreed with Janet and supporting example. Per James request, I will add t= he following text (inspired from Janet's illustrative example): "In other words, when multiple clients are being controlled by an overlo= aded server, at any given time some clients may receive requests at a rate = below its target SIP request rate while others above that target rate. But = the resulting request rate presented to the overloaded server will converge= towards the target SIP request rate." - Agreed with other suggested changes + Section 3.5.1: - ID: "And the larger the difference between TAU1 and TAU2, the closer to t= he control is to strict priority." [JY] Suggest changing into "And the larger the difference between TAU1 an= d TAU2, the closer the control is to strict priority queuing." [JG] Suggest changing into "And the larger the difference between TAU1 an= d TAU2, the closer the control is to strict priority treatment." [EN] Agreed with Janet's suggestion - Agreed with other suggested changes + Section 4: - Agreed with suggested changes + Section 5: - Please note that based comments from per Christer Holmberg and Janet Gunn= , the following was tentatively agreed Replace oc-value =3D "NaN" / oc-num by oc =3D "oc" [EQUAL oc-num] - Agreed with other suggested change + Section 7: - [JY] Should "rate" in oc-algo be registered with IANA? This issue needs to be addressed by draft-ietf-soc-overload-control autho= rs Please note I will wait until expiration of WGLC prior updating our draft R= FC. Once again your comments and/or suggestions are most appreciated. 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 Yu, James Sent: Tuesday, July 02, 2013 9:42 AM To: Janet P Gunn Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Janet, For my comment on section 3.4 (the first one below), the current text does = not provide any value. The client's arrival rate could be well below the t= arget SIP request rate when its load is light so the fact that the client m= ay not achieve the target SIP request rate (the max. rate it is allowed to = send to the server) is well understood. But with your explanation on the "= delta" part, the text then makes sense. Please add some discussions on the= "delta" aspect so that even if the average arrival rate at the client is h= igher than the target SIP request rate the client at times may not send mor= e than what the target SIP request rate allows due to the fluctuation of th= e arriving requests at the client. For the comment on section 3.5.1, I agree with your proposed change. For the rate control, the server could calculate the arrival rate from each= communicating client so that it could allocate the overall target SIP requ= est rate to the clients based on their arrival rates known to the server. = But another option is for the client to "optionally" include its calculated= arrival rate in its request to the server when rate control related parame= ters are present. Should this option be evaluated/included to relieve the = server from doing the arrival rate calculations. This would be beneficial = to a server when it receives the requests from many clients. James From: Janet P Gunn [mailto:jgunn6@csc.com] Sent: Friday, June 28, 2013 3:34 PM To: Yu, James Cc: draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org; sip-overload-bounces@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, It is a little hard to respond in email when your comments are in a separat= e document, but here goes. section 3.4 ID says: "Note that the target SIP request rate is a max rate that may not be attained by the arrival rate at the client, and the server cannot assume that it will." Your comment : "Not clear what value this paragraph tries to add. Is it saying that the c= lient's arrival rate may be lower than the target SIP request rate? " Yes. Suppose the server want to limit the total rate of arriving SIP messages to= 100 / sec, and has 10 clients. Each client has a high variance in its mes= sage rate, but together they are well above 100 messages per sec If it sets the rate at 10 messages per second for each of the clients, it w= ill almost certainly end up with an overall average of less than 100 messa= ges per sec, because some clients will be in a "lull" while others are busy= . This is good from a throttling perspective, but, assuming messages are c= orrelated with revenue, bad/wasteful from a revenue, or overall productivit= y perspective. So the server might want to set the rate per client to 10 += delta, where delta is going to be very specific to operating environment. --- In section 3.5.1, bottom of page 8 ID says: "And the larger the difference between TAU1 and TAU2, the closer to the control is to strict priority." You propose changing it to: "And the larger the difference between TAU1 and TAU2, the closer the control is to strict priority queuing." I agree with taking out the redundant "to". But I disagree wit adding "que= uing". There is no queuing, priority or otherwise involved. You could say: "And the larger the difference between TAU1 and TAU2, the closer the control is to strict priority treatment." where " strict priority treatment" would refer to the case where non-priori= ty messages are restricted to a total (priority + non-priority) rate of 10 = messages per second, but priority messages can continue to be sent as long = as the total (priority + non-priority) rate is less than 12 messages per se= cond. At least, I think that is what Eric and Philip are trying to say. 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: "Yu, James" = > To: "sip-overload-bounces@ietf.org" >= , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" >, "sip-overload@ietf.org"= > Date: 06/28/2013 08:10 AM Subject: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Sent by: sip-overload-bounces@ietf.org ________________________________ Salvatore, Please see the attachment for my comments. I pasted the text to a word document to trace/show the proposed changes and= comments. Regards, James [attachment "comments on draft-ietf-soc-overload-rate-control-04.docx" del= eted by Janet P Gunn/USA/CSC] _____________________________________________= __ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6452 - Release Date: 06/30/13 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13 --_000_5EBD159DE88147488A3B1590E09001840353C068757Cnjfpsrvexg2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

James,

 

=

Based on your suggestion and comments from othe= r reviewers, I intend to update section 5 (syntax) as follows:

 

oc =3D “oc” [EQUAL oc-num]

oc-num =3D 1*DIGIT

 

= algo-list =3D “loss” / “rate“ / *(other-algo= )

other-algo =3D %x41-5A /= %x61-7A / %x30-39

&n= bsp;

I understand there may be = an additional change following Henning’s reply.

=

 

Thanks,

&nbs= p;

Eric Noel <= o:p>

AT&T Labs, Inc.
Rethink Possible

=

 

Network Design and Performance Analysis
200 South Laurel A= venue, D5-3D19
Middletown, NJ 07748
P: 732.420.4174=

ecnoel@att.com

 

From: Yu, J= ames [mailto:james.yu@neustar.biz]
Sent: Wednesday, July 10, 201= 3 11:36 AM
To: NOEL, ERIC C (ERIC C)
Cc: sip-overload-b= ounces@ietf.org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; s= ip-overload@ietf.org
Subject: RE: [sip-overload] draft-ietf-soc-o= verload-rate-control-04.txt

 

Eric,

 

Yes, this adds “rate” to “oc-algo”= parameter but please check with IANA to see if it is the correct way. = ; You also need to copy some syntax lines from the draft-ietf-soc-overload-= control to show

&nbs= p;

     “loss= 220; / “rate“ / *(ot= her-algo)

 

I’ve an email to Henning aski= ng if algo-list in his I-D should be

     algo-list   =3D <= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>“loss“ / other-algo

 

If yes, then this particular line in your I-D would be

    &nbs= p;algo-list   =3D “loss“ / “rate“= /= other-algo

=  

James

 

From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.a= tt.com]
Sent: Wednesday, July 10, 2013 10:49 AM
To: Yu= , James
Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overloa= d-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject:= RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt<= /span>

 

James,

 

Thank you for your su= ggestion.

 

Not being familiar with IANA proce= dure, would updating draft-ietf-soc-overload-rate-control section 7 (IANA c= onsiderations) as follows work?

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

This specific= ation defines a new value for Via header parameter oc-algo as detailed belo= w in the "Header Field Parameter and Parameter Values" subregistr= y as per the registry created by [RFC3968]. The required information is:

 

=

Header Field      &nbs= p;    Parameter Name      &nbs= p;            &= nbsp;    Predefined Values     &nbs= p;            &= nbsp; Reference

----= ---------------------------------------------------------------------------= ---------------------------

Via            &nb= sp;            =      oc-algo       &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; “rate”        &= nbsp;           &nbs= p;             =            RFCXXXX

 

RFC XXXX [NOTE TO RFC-EDITOR: Please replace w= ith final RFC number of this specification.]

 

Thanks,

 =

Eric Noel

AT&T Labs, Inc.
Rethink Possible

 

= Network Design and Performance Analysis
200 South Laurel Avenue, D= 5-3D19
Middletown, NJ 07748
P: 732.420.4174

ecnoel@att.com=

 

From: Yu, James = [mailto:james.yu@neustar.biz] <= br>Sent: Wednesday, July 10, 2013 10:17 AM
To: NOEL, ERIC = C (ERIC C)
Cc: s= ip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all@= tools.ietf.org; sip-overload@i= etf.org
Subject: RE: [sip-overload] draft-ietf-soc-overload-r= ate-control-04.txt

 

Noel,

<= p class=3DMsoNormal> 

I forgot to respond to your reply about the IANA registration of &#= 8220;rate” in oc-algo.  I see that draft-ietf-soc-overload-contr= ol-13 mentions your I-D but does not have “rate” in algo-list.<= o:p>

 

There are two possible ways to address “= ;rate” in algo-list.  One is to have draft-ietf-soc-overload-con= trol-13 add “rate” to algo-list and refer to your I-D for detai= ls.  The other is to register “rate” in algo-list with IAN= A in your I-D, and this should be a simple task.  The cleaner way that= is more inline with the IETF process would be the latter.  It seems o= dd to have something defined in a RFC without details about it, and it woul= d be too much trouble to combine the two I-Ds.

 

James

 <= /span>

From: Yu, James
Sent:= Wednesday, July 10, 2013 9:01 AM
To: 'NOEL, ERIC C (ERIC C)'
= Cc: sip-overload-bo= unces@ietf.org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org= ; sip-overload@ietf.orgSubject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04= .txt

 

Noel,

 

I me= ntioned in my message to Janet on 7/2:

 

For the rate control, the server could calculate the arr= ival rate from each communicating client so that it could allocate the over= all target SIP request rate to the clients based on their arrival rates kno= wn to the server.  But another option is for the client to “opti= onally” include its calculated arrival rate in its request to the ser= ver when rate control related parameters are present.  Should this opt= ion be evaluated/included to relieve the server from doing the arrival rate= calculations.  This would be beneficial to a server when it receives = the requests from many clients.

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

I suggest tha= t the I-D adds that option to allow the client to indicate its current arri= val rate (towards the receiving server) in the SIP request.

 

James

 

From: NOEL, ERIC= C (ERIC C) [mailto:ecnoel@resea= rch.att.com]
Sent: Tuesday, July 09, 2013 4:44 PM
To:<= /b> Yu, James; Janet P Gunn
Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-= rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload] draft-ie= tf-soc-overload-rate-control-04.txt

 

Janet, Jame= s,

 

Thanks you for your valuable comments and = discussion.  I tried to capture all resolution in the following text (= based on James word document with track changes and imbedded comments enabl= ed).

 

+ Abstract section:

- Agreed with suggested changes

- Please note I will also need to make = further changes to remove all references per Christer Holmberg comment=

 

+ Section 1:

- Agreed with suggested changes

 

+ Section 3.1:

- Agreed w= ith suggested changes

&nbs= p;

+ Section 3.2: - Pleas= e note the section title will become “Via header field parameters for= overload control “ per Christer Holmberg comment

- Agreed with suggested changes excluding tit= le that will change per previous bullet

 

+ Se= ction 3.3:

- Agreed with s= uggested changes

&nbs= p;

+ Section 3.4:

- ID:  "Note that the target = SIP request rate is a max rate that may not be attained by the arrival rate= at the client, and the server cannot assume that it will."

   [JY] Not clear wh= at value this paragraph tries to add.  Is it saying that the client's = arrival rate may be lower than the target SIP request rate?

   [JG] Yes + supporting = example (see below in thread)

  Agreed with Janet and supporting example. Per James request= , I will add the following text (inspired from Janet’s illustrative e= xample):

   R= 20;In other words, when multiple clients are being controlled by an overloa= ded server, at any given time some clients may receive requests at a rate b= elow its target SIP request rate while others above that target rate. But t= he resulting request rate presented to the overloaded server will converge = towards the target SIP request rate.”

- Agreed with other suggested changes

     <= /span>

+ Section 3.5.1:

- ID: “And the larger the difference bet= ween TAU1 and TAU2, the closer to the control is to strict priority.”=

  [JY] Suggest chang= ing into “And the larger the difference between TAU1 and TAU2, the cl= oser the control is to strict priority queuing.”

  [JG] Suggest changing into “And t= he larger the difference between TAU1 and TAU2, the closer the control is t= o strict priority treatment.”

  [EN] Agreed with Janet’s suggestion

- Agreed with other suggested changes=

 

+ Section 4:

- Agreed with suggested changes

 

+ Section 5:

- Please not= e that based comments from per Christer Holmberg and Janet Gunn, the follow= ing was tentatively agreed

   Replace oc-value =3D "NaN" / oc-num &nbs= p;  by    oc =3D "oc" [EQUAL oc-num]

- Agreed with other suggested chan= ge

 

+ Section 7:

- [JY] Should “rate” in oc-algo be register= ed with IANA?

  This = issue needs to be addressed by draft-ietf-soc-overload-control authors=

 

Please note I will wait until expiration of WGLC = prior updating our draft RFC. Once again your comments and/or suggestions a= re most appreciated.

 

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

 

<= div>

From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] On Behalf= Of Yu, James
Sent: Tuesday, July 02, 2013 9:42 AM
To:<= /b> Janet P Gunn
Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-contro= l.all@tools.ietf.org; sip-over= load@ietf.org
Subject: Re: [sip-overload] draft-ietf-soc-over= load-rate-control-04.txt

 

Janet,

 

For my comment on section 3.4 (the first one below), the cur= rent text does not provide any value.  The client’s arrival rate= could be well below the target SIP request rate when its load is light so = the fact that the client may not achieve the target SIP request rate (the m= ax. rate it is allowed to send to the server) is well understood.  But= with your explanation on the “delta” part, the text then makes= sense.  Please add some discussions on the “delta” aspect= so that even if the average arrival rate at the client is higher than the = target SIP request rate the client at times may not send more than what the= target SIP request rate allows due to the fluctuation of the arriving requ= ests at the client.

 

For the comment on sect= ion 3.5.1, I agree with your proposed change.

 

For the rate control, the server could calculate the arrival rate from eac= h communicating client so that it could allocate the overall target SIP req= uest rate to the clients based on their arrival rates known to the server.&= nbsp; But another option is for the client to “optionally” incl= ude its calculated arrival rate in its request to the server when rate cont= rol related parameters are present.  Should this option be evaluated/i= ncluded to relieve the server from doing the arrival rate calculations.&nbs= p; This would be beneficial to a server when it receives the requests from = many clients.

 <= /o:p>

James

 

From: Janet P Gunn [mailto:jgunn6@cs= c.com]
Sent: Friday, June 28, 2013 3:34 PM
To: Yu,= James
Cc: draft-ietf-soc-overload-rate-control.all@tools.ietf.or= g; sip-overload@ietf.org; = sip-overload-bounces@ietf.= org
Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-= control-04.txt

 <= /o:p>

James,

It is a little hard to respond in email w= hen your comments are in a separate document, but here goes.

sect= ion 3.4
ID says:
"Note that the target SIP request rate is a max r= ate that may not be
   attained by the arrival rate at the clie= nt, and the server cannot
   assume that it will." =

Y= our comment :
"Not clear what value this paragraph tries to add. &nb= sp;Is it saying that the client's arrival rate may be lower than the target= SIP request rate?  "

Yes.

Suppose the server want to= limit the total rate of arriving SIP messages to 100 / sec, and has 10 cli= ents.  Each client has a high variance in its message rate, but togeth= er they are well above 100 messages per sec

If it sets the rate at 10= messages per second for each of the clients, it will almost certainly end = up  with an overall average of less than 100 messages per sec, because= some clients will be in a "lull" while others are busy.  Th= is is good from a throttling perspective, but, assuming messages are correl= ated with revenue, bad/wasteful from a revenue, or overall productivity per= spective.  So the server might want to set the rate per client to 10 += delta, where delta is going to be very specific to operating environment.<= /span>

---
In section  3.5.1, bottom of page 8
ID says:
= "And= the larger
   the difference between TAU1 and TAU2, the closer= to the control is
   to strict priority."

= You propo= se changing it to:
"And the larger
   the difference bet= ween TAU1 and TAU2, the closer  the control is
   to stri= ct priority queuing."

I agree with taking out the redundant &quo= t;to".  But I disagree wit adding "queuing".  Ther= e is no queuing, priority or otherwise involved.

You could say:
&qu= ot;And the larger
   the difference between TAU1 and TAU2, the = closer  the control is
   to strict priority treatment.&qu= ot;

where " strict priority treatment" would refer to the c= ase where non-priority messages are restricted to a total (priority + non-p= riority) rate of 10 messages per second, but priority messages can continue= to be sent as long as the total (priority + non-priority) rate is less tha= n 12 messages per second.

At least, I think that is what Eric and &nb= sp;Philip are trying to say.

Janet


 


This is= a PRIVATE message. If you are not the intended recipient, please delete wi= thout copying and kindly advise us by e-mail of the mistake in delivery. NO= TE: 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 g= overnment initiative expressly permitting the use of e-mail for such purpos= e.



From:        "Yu, James= " <james.yu@neustar.biz= >
To:        "sip-overload-bounces@ietf.org" <sip-overload-bounces@ietf.org= >, "draft-ietf-soc-overload-rate-control.all@tools.ietf.org= " <draft-ietf-soc-overload-rate-control.all@tools.ietf.org>,= "sip-overload@ietf.org&q= uot; <sip-overload@ietf.org= >
Date:        06/28/2013 08:10 AM
Subject:        [sip-overload] draft-ietf-soc-ov= erload-rate-control-04.txt
Sent by:       &nb= sp;= sip-overload-bounces@ietf.= org




Salvatore,
 
Please see the attachment for my comme= nts.
 
I pasted the text to a word document to trace/show the = proposed changes and comments.
 
Regards,
  James=
 [attachment "comments on draft-ietf-soc-overload-rate-contr= ol-04.docx" deleted by Janet P Gunn/USA/CSC] _______________________________________________
sip-o= verload mailing list
s= ip-overload@ietf.org
https://ww= w.ietf.org/mailman/listinfo/sip-overload

= No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 3204/6452= - Release Date: 06/30/13

No virus found in this message.=
Checked by AVG - www.avg.com
Vers= ion: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13<= /o:p>

=
=

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Databa= se: 3204/6478 - Release Date: 07/09/13

= --_000_5EBD159DE88147488A3B1590E09001840353C068757Cnjfpsrvexg2_-- From james.yu@neustar.biz Wed Jul 10 12:10:05 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 630FA21F9F96; Wed, 10 Jul 2013 12:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.266 X-Spam-Level: X-Spam-Status: No, score=-6.266 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4lIEnabNnSW; Wed, 10 Jul 2013 12:09:54 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id BC1C621F9BCB; Wed, 10 Jul 2013 12:09:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1373483895; x=1688830882; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=KOU6V9pI2DC8gGIbLwcpkkKTpKZ83IX/UU5CK4txMGQ=; b=sr76jfZp+NKywT8D/rU0UdlOsix0cTX/V3wJd9V5pY9Az2oiTY/tFMoQ3Q+tlj D1iF5udHktllnXcCJUI9TQfQ== Received: from ([10.31.58.69]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.27687425; Wed, 10 Jul 2013 15:18:14 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.240]) with mapi id 14.02.0342.003; Wed, 10 Jul 2013 15:09:42 -0400 From: "Yu, James" To: "NOEL, ERIC C (ERIC C)" Thread-Topic: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Thread-Index: Ac5zhcqru7dYQFxqQKSGvvGKSQFJEAA0j1MAALOuppABZadV0AAr0zMgAAJGKhAAAUkxUAABlYhgAAIP6nAABdJLAA== Date: Wed, 10 Jul 2013 19:09:42 +0000 Message-ID: <56FB15AFE08E1242B0736CBDCE6E856108092BD9@stntexmb12.cis.neustar.com> References: <56FB15AFE08E1242B0736CBDCE6E85610808C32F@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610808EF90@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353BDA4CAD4@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E85610809239D@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610809253D@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353C0687578@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E856108092986@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353C068757C@njfpsrvexg2.research.att.com> In-Reply-To: <5EBD159DE88147488A3B1590E09001840353C068757C@njfpsrvexg2.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.31.32.239] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: vnnjKtZCOSHCdp3UcLWJDw== Content-Type: multipart/alternative; boundary="_000_56FB15AFE08E1242B0736CBDCE6E856108092BD9stntexmb12cisne_" MIME-Version: 1.0 Cc: "sip-overload-bounces@ietf.org" , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" , "sip-overload@ietf.org" Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.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, 10 Jul 2013 19:10:05 -0000 --_000_56FB15AFE08E1242B0736CBDCE6E856108092BD9stntexmb12cisne_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Eric, You may want to copy the "oc-algo" line from other I-D. James From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] Sent: Wednesday, July 10, 2013 1:10 PM To: Yu, James Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all= @tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, Based on your suggestion and comments from other reviewers, I intend to upd= ate section 5 (syntax) as follows: oc =3D "oc" [EQUAL oc-num] oc-num =3D 1*DIGIT algo-list =3D "loss" / "rate" / *(other-algo) other-algo =3D %x41-5A / %x61-7A / %x30-39 I understand there may be an additional change following Henning's reply. 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: Yu, James [mailto:james.yu@neustar.biz] Sent: Wednesday, July 10, 2013 11:36 AM To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Eric, Yes, this adds "rate" to "oc-algo" parameter but please check with IANA to = see if it is the correct way. You also need to copy some syntax lines from= the draft-ietf-soc-overload-control to show algo-list =3D "loss" / "rate" / *(other-algo) I've an email to Henning asking if algo-list in his I-D should be algo-list =3D "loss" / other-algo If yes, then this particular line in your I-D would be algo-list =3D "loss" / "rate" / other-algo James From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] Sent: Wednesday, July 10, 2013 10:49 AM To: Yu, James Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, Thank you for your suggestion. Not being familiar with IANA procedure, would updating draft-ietf-soc-overl= oad-rate-control section 7 (IANA considerations) as follows work? This specification defines a new value for Via header parameter oc-algo as = detailed below in the "Header Field Parameter and Parameter Values" subregi= stry as per the registry created by [RFC3968]. The required information is: Header Field Parameter Name Predefined Val= ues Reference ---------------------------------------------------------------------------= ------------------------------- Via oc-algo = "rate" RFCXXXX RFC XXXX [NOTE TO RFC-EDITOR: Please replace with final RFC number of this = specification.] 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: Yu, James [mailto:james.yu@neustar.biz] Sent: Wednesday, July 10, 2013 10:17 AM To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Noel, I forgot to respond to your reply about the IANA registration of "rate" in = oc-algo. I see that draft-ietf-soc-overload-control-13 mentions your I-D b= ut does not have "rate" in algo-list. There are two possible ways to address "rate" in algo-list. One is to have= draft-ietf-soc-overload-control-13 add "rate" to algo-list and refer to yo= ur I-D for details. The other is to register "rate" in algo-list with IANA= in your I-D, and this should be a simple task. The cleaner way that is mo= re inline with the IETF process would be the latter. It seems odd to have = something defined in a RFC without details about it, and it would be too mu= ch trouble to combine the two I-Ds. James From: Yu, James Sent: Wednesday, July 10, 2013 9:01 AM To: 'NOEL, ERIC C (ERIC C)' Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Noel, I mentioned in my message to Janet on 7/2: For the rate control, the server could calculate the arrival rate from each= communicating client so that it could allocate the overall target SIP requ= est rate to the clients based on their arrival rates known to the server. = But another option is for the client to "optionally" include its calculated= arrival rate in its request to the server when rate control related parame= ters are present. Should this option be evaluated/included to relieve the = server from doing the arrival rate calculations. This would be beneficial = to a server when it receives the requests from many clients. I suggest that the I-D adds that option to allow the client to indicate its= current arrival rate (towards the receiving server) in the SIP request. James From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] Sent: Tuesday, July 09, 2013 4:44 PM To: Yu, James; Janet P Gunn Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Janet, James, Thanks you for your valuable comments and discussion. I tried to capture a= ll resolution in the following text (based on James word document with trac= k changes and imbedded comments enabled). + Abstract section: - Agreed with suggested changes - Please note I will also need to make further changes to remove all refere= nces per Christer Holmberg comment + Section 1: - Agreed with suggested changes + Section 3.1: - Agreed with suggested changes + Section 3.2: - Please note the section title will become "Via header fiel= d parameters for overload control " per Christer Holmberg comment - Agreed with suggested changes excluding title that will change per previo= us bullet + Section 3.3: - Agreed with suggested changes + Section 3.4: - ID: "Note that the target SIP request rate is a max rate that may not be= attained by the arrival rate at the client, and the server cannot assume t= hat it will." [JY] Not clear what value this paragraph tries to add. Is it saying tha= t the client's arrival rate may be lower than the target SIP request rate? [JG] Yes + supporting example (see below in thread) Agreed with Janet and supporting example. Per James request, I will add t= he following text (inspired from Janet's illustrative example): "In other words, when multiple clients are being controlled by an overlo= aded server, at any given time some clients may receive requests at a rate = below its target SIP request rate while others above that target rate. But = the resulting request rate presented to the overloaded server will converge= towards the target SIP request rate." - Agreed with other suggested changes + Section 3.5.1: - ID: "And the larger the difference between TAU1 and TAU2, the closer to t= he control is to strict priority." [JY] Suggest changing into "And the larger the difference between TAU1 an= d TAU2, the closer the control is to strict priority queuing." [JG] Suggest changing into "And the larger the difference between TAU1 an= d TAU2, the closer the control is to strict priority treatment." [EN] Agreed with Janet's suggestion - Agreed with other suggested changes + Section 4: - Agreed with suggested changes + Section 5: - Please note that based comments from per Christer Holmberg and Janet Gunn= , the following was tentatively agreed Replace oc-value =3D "NaN" / oc-num by oc =3D "oc" [EQUAL oc-num] - Agreed with other suggested change + Section 7: - [JY] Should "rate" in oc-algo be registered with IANA? This issue needs to be addressed by draft-ietf-soc-overload-control autho= rs Please note I will wait until expiration of WGLC prior updating our draft R= FC. Once again your comments and/or suggestions are most appreciated. 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 Yu, James Sent: Tuesday, July 02, 2013 9:42 AM To: Janet P Gunn Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Janet, For my comment on section 3.4 (the first one below), the current text does = not provide any value. The client's arrival rate could be well below the t= arget SIP request rate when its load is light so the fact that the client m= ay not achieve the target SIP request rate (the max. rate it is allowed to = send to the server) is well understood. But with your explanation on the "= delta" part, the text then makes sense. Please add some discussions on the= "delta" aspect so that even if the average arrival rate at the client is h= igher than the target SIP request rate the client at times may not send mor= e than what the target SIP request rate allows due to the fluctuation of th= e arriving requests at the client. For the comment on section 3.5.1, I agree with your proposed change. For the rate control, the server could calculate the arrival rate from each= communicating client so that it could allocate the overall target SIP requ= est rate to the clients based on their arrival rates known to the server. = But another option is for the client to "optionally" include its calculated= arrival rate in its request to the server when rate control related parame= ters are present. Should this option be evaluated/included to relieve the = server from doing the arrival rate calculations. This would be beneficial = to a server when it receives the requests from many clients. James From: Janet P Gunn [mailto:jgunn6@csc.com] Sent: Friday, June 28, 2013 3:34 PM To: Yu, James Cc: draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org; sip-overload-bounces@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, It is a little hard to respond in email when your comments are in a separat= e document, but here goes. section 3.4 ID says: "Note that the target SIP request rate is a max rate that may not be attained by the arrival rate at the client, and the server cannot assume that it will." Your comment : "Not clear what value this paragraph tries to add. Is it saying that the c= lient's arrival rate may be lower than the target SIP request rate? " Yes. Suppose the server want to limit the total rate of arriving SIP messages to= 100 / sec, and has 10 clients. Each client has a high variance in its mes= sage rate, but together they are well above 100 messages per sec If it sets the rate at 10 messages per second for each of the clients, it w= ill almost certainly end up with an overall average of less than 100 messa= ges per sec, because some clients will be in a "lull" while others are busy= . This is good from a throttling perspective, but, assuming messages are c= orrelated with revenue, bad/wasteful from a revenue, or overall productivit= y perspective. So the server might want to set the rate per client to 10 += delta, where delta is going to be very specific to operating environment. --- In section 3.5.1, bottom of page 8 ID says: "And the larger the difference between TAU1 and TAU2, the closer to the control is to strict priority." You propose changing it to: "And the larger the difference between TAU1 and TAU2, the closer the control is to strict priority queuing." I agree with taking out the redundant "to". But I disagree wit adding "que= uing". There is no queuing, priority or otherwise involved. You could say: "And the larger the difference between TAU1 and TAU2, the closer the control is to strict priority treatment." where " strict priority treatment" would refer to the case where non-priori= ty messages are restricted to a total (priority + non-priority) rate of 10 = messages per second, but priority messages can continue to be sent as long = as the total (priority + non-priority) rate is less than 12 messages per se= cond. At least, I think that is what Eric and Philip are trying to say. 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: "Yu, James" = > To: "sip-overload-bounces@ietf.org" >= , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" >, "sip-overload@ietf.org"= > Date: 06/28/2013 08:10 AM Subject: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Sent by: sip-overload-bounces@ietf.org ________________________________ Salvatore, Please see the attachment for my comments. I pasted the text to a word document to trace/show the proposed changes and= comments. Regards, James [attachment "comments on draft-ietf-soc-overload-rate-control-04.docx" del= eted by Janet P Gunn/USA/CSC] _____________________________________________= __ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6452 - Release Date: 06/30/13 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13 --_000_56FB15AFE08E1242B0736CBDCE6E856108092BD9stntexmb12cisne_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Eric,

You may want to copy the = “oc-algo” line from other I-D.

 <= /p>

James

 <= /p>

From: NOEL, ER= IC C (ERIC C) [mailto:ecnoel@research.att.com]
Sent: Wednesday, July 10, 2013 1:10 PM
To: Yu, James
Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-cont= rol.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt

 

James,<= /p>

 <= /p>

Based on your suggestion = and comments from other reviewers, I intend to update section 5 (syntax) as= follows:

 <= /p>

oc =3D “oc” [= EQUAL oc-num]

oc-num =3D 1*DIGIT

 <= /p>

algo-list =3D “loss= ” / “rate“ / *(other-algo)

other-algo =3D %x41-5A / = %x61-7A / %x30-39

 <= /p>

I understand there may be= an additional change following Henning’s reply.

 <= /p>

Thanks,=

 <= /p>

Eric Noel

AT&T Labs, Inc.
Rethink Possible<= /p>

 

Network Design and Perform= ance Analysis
200 South Laurel Avenue, D5-3D19
Middletown, NJ 07748
P: 732.420.4174

ecnoel@att.com

 <= /p>

From: Yu, Jame= s [mailto:james.yu@neustar.biz]
Sent: Wednesday, July 10, 2013 11:36 AM
To: NOEL, ERIC C (ERIC C)
Cc: sip-overload-bo= unces@ietf.org; = draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt

 

Eric,

 <= /p>

Yes, this adds “rat= e” to “oc-algo” parameter but please check with IANA to s= ee if it is the correct way.  You also need to copy some syntax lines = from the draft-ietf-soc-overload-control to show

 <= /p>

     algo-list   =3D “loss“ / “rate“ / *(other-algo)

 <= /p>

I’ve an email to He= nning asking if algo-list in his I-D should be

     = algo-list   =3D “loss“ / other-algo

 <= /p>

If yes, then this particu= lar line in your I-D would be

    &= nbsp;algo-list   =3D “loss“ / “rate“ / other-algo

 <= /p>

James

 <= /p>

From: NOEL, ER= IC C (ERIC C) [mailto:ecnoel@res= earch.att.com]
Sent: Wednesday, July 10, 2013 10:49 AM
To: Yu, James
Cc: sip-overload-bo= unces@ietf.org; = draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt

 

James,<= /p>

 <= /p>

Thank you for your sugges= tion.

 <= /p>

Not being familiar with I= ANA procedure, would updating draft-ietf-soc-overload-rate-control section = 7 (IANA considerations) as follows work?

 <= /p>

This specification define= s a new value for Via header parameter oc-algo as detailed below in the &qu= ot;Header Field Parameter and Parameter Values" subregistry as per the registry created by [RFC3968]. The required information is:

 <= /p>

Header Field   =         Parameter Name   =             &nb= sp;        Predefined Values  =             &nb= sp;     Reference

-------------------------= ---------------------------------------------------------------------------= ------

Via    &nb= sp;            =             &nb= sp;oc-algo           &nbs= p;            &= nbsp;           &nbs= p;         “rate”&= nbsp;           &nbs= p;            &= nbsp;            &nb= sp;      RFCXXXX

 <= /p>

RFC XXXX [NOTE TO RFC-EDI= TOR: Please replace with final RFC number of this specification.]

 <= /p>

Thanks,=

 <= /p>

Eric Noel

AT&T Labs, Inc.
Rethink Possible<= /p>

 

Network Design and Perform= ance Analysis
200 South Laurel Avenue, D5-3D19
Middletown, NJ 07748
P: 732.420.4174

ecnoel@att.com

 <= /p>

From: Yu, Jame= s [mailto:james.yu@neustar.biz]
Sent: Wednesday, July 10, 2013 10:17 AM
To: NOEL, ERIC C (ERIC C)
Cc: sip-overload-bo= unces@ietf.org; = draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt

 

Noel,

 <= /p>

I forgot to respond to yo= ur reply about the IANA registration of “rate” in oc-algo. = ; I see that draft-ietf-soc-overload-control-13 mentions your I-D but does not have “rate” in algo-list.

 <= /p>

There are two possible wa= ys to address “rate” in algo-list.  One is to have draft-i= etf-soc-overload-control-13 add “rate” to algo-list and refer t= o your I-D for details.  The other is to register “rate” in algo-lis= t with IANA in your I-D, and this should be a simple task.  The cleane= r way that is more inline with the IETF process would be the latter.  = It seems odd to have something defined in a RFC without details about it, and it would be too much trouble to combine the two I-Ds.

 <= /p>

James

 <= /p>

From: Yu, Jame= s
Sent: Wednesday, July 10, 2013 9:01 AM
To: 'NOEL, ERIC C (ERIC C)'
Cc: sip-overload-bo= unces@ietf.org; = draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt

 

Noel,

 <= /p>

I mentioned in my message= to Janet on 7/2:

 <= /p>

= For the rate control, the server could calculate the arrival rate from each= communicating client so that it could allocate the overall target SIP request rate to the clients based on their arrival rates known = to the server.  But another option is for the client to “optiona= lly” include its calculated arrival rate in its request to the server= when rate control related parameters are present.  Should this option be evaluated/included to relieve the server from = doing the arrival rate calculations.  This would be beneficial to a se= rver when it receives the requests from many clients.

 <= /p>

I suggest that the I-D ad= ds that option to allow the client to indicate its current arrival rate (to= wards the receiving server) in the SIP request.

 <= /p>

James

 <= /p>

From: NOEL, ER= IC C (ERIC C) [mailto:ecnoel@res= earch.att.com]
Sent: Tuesday, July 09, 2013 4:44 PM
To: Yu, James; Janet P Gunn
Cc: sip-overload-bo= unces@ietf.org; = draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt

 

Janet, James,<= /span>

 <= /p>

Thanks you for your valua= ble comments and discussion.  I tried to capture all resolution in the= following text (based on James word document with track changes and imbedded comments enabled).

 <= /p>

+ Abstract section:

- Agreed with suggested c= hanges

- Please note I will also= need to make further changes to remove all references per Christer Holmber= g comment

 <= /p>

+ Section 1:

- Agreed with suggested c= hanges

 <= /p>

+ Section 3.1:

- Agreed with suggested c= hanges

 

+ Section 3.2: - Plea= se note the section title will become “Via header field parameters fo= r overload control “ per Christer Holmberg comment<= /p>

- Agreed with suggested c= hanges excluding title that will change per previous bullet

 <= /p>

+ Section 3.3:

- Agreed with suggested c= hanges

 <= /p>

+ Section 3.4:

- ID:  "Note th= at the target SIP request rate is a max rate that may not be attained by th= e arrival rate at the client, and the server cannot assume that it will."

   [JY] No= t clear what value this paragraph tries to add.  Is it saying that the= client's arrival rate may be lower than the target SIP request rate?

   [JG] Ye= s + supporting example (see below in thread)

  Agreed with J= anet and supporting example. Per James request, I will add the following te= xt (inspired from Janet’s illustrative example):

   “In ot= her words, when multiple clients are being controlled by an overloaded serv= er, at any given time some clients may receive requests at a rate below its target SIP request rate while others above that target rate. But the r= esulting request rate presented to the overloaded server will converge towa= rds the target SIP request rate.”

- Agreed with other sugge= sted changes

    &= nbsp;

+ Section 3.5.1:=

- ID: “And the larg= er the difference between TAU1 and TAU2, the closer to the control is to st= rict priority.”

  [JY] Suggest chang= ing into “And the larger the difference between TAU1 and TAU2, the cl= oser the control is to strict priority queuing.”

  [JG] Suggest chang= ing into “And the larger the difference between TAU1 and TAU2, the cl= oser the control is to strict priority treatment.”<= /p>

  [EN] Agreed with J= anet’s suggestion

- Agreed with other sugge= sted changes

 <= /p>

+ Section 4:

- Agreed with suggested c= hanges

 <= /p>

+ Section 5:

- Please note that based = comments from per Christer Holmberg and Janet Gunn, the following was tenta= tively agreed

   Replace= oc-value =3D "NaN" / oc-num    by   &nb= sp;oc =3D "oc" [EQUAL oc-num]

- Agreed with other sugge= sted change

 <= /p>

+ Section 7:

- [JY] Should “rate= ” in oc-algo be registered with IANA?

  This issue needs t= o be addressed by draft-ietf-soc-overload-control authors=

 <= /p>

Please note I will wait u= ntil expiration of WGLC prior updating our draft RFC. Once again your comme= nts and/or suggestions are most appreciated.

 <= /p>

Thanks,=

 <= /p>

Eric Noel

AT&T Labs, Inc.
Rethink Possible<= /p>

 

Network Design and Perform= ance Analysis
200 South Laurel Avenue, D5-3D19
Middletown, NJ 07748
P: 732.420.4174

ecnoel@att.com

 <= /p>

From: sip-overload-bounces@ietf.= org [mailto:sip-overlo= ad-bounces@ietf.org] On Behalf Of Yu, James
Sent: Tuesday, July 02, 2013 9:42 AM
To: Janet P Gunn
Cc: sip-overload-bo= unces@ietf.org; = draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt

 

Janet,<= /p>

 <= /p>

For my comment on section= 3.4 (the first one below), the current text does not provide any value.&nb= sp; The client’s arrival rate could be well below the target SIP request rate when its load is light so the fact that the client may no= t achieve the target SIP request rate (the max. rate it is allowed to send = to the server) is well understood.  But with your explanation on the &= #8220;delta” part, the text then makes sense.  Please add some discussions on the “delta” aspect so that even= if the average arrival rate at the client is higher than the target SIP re= quest rate the client at times may not send more than what the target SIP r= equest rate allows due to the fluctuation of the arriving requests at the client.

 <= /p>

For the comment on sectio= n 3.5.1, I agree with your proposed change.

 <= /p>

For the rate control, the= server could calculate the arrival rate from each communicating client so = that it could allocate the overall target SIP request rate to the clients based on their arrival rates known to the server.  But= another option is for the client to “optionally” include its c= alculated arrival rate in its request to the server when rate control relat= ed parameters are present.  Should this option be evaluated/included to relieve the server from doing the arrival rate calcu= lations.  This would be beneficial to a server when it receives the re= quests from many clients.

 <= /p>

James

 <= /p>

From: Janet P = Gunn [mailto:jgunn6@csc.com]
Sent: Friday, June 28, 2013 3:34 PM
To: Yu, James
Cc: draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org; sip-overload-bounces@ietf.org
Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt

 

James,

It is a little hard to respond in email when your comments are i= n a separate document, but here goes.


section 3.4
ID says:
"Note that the target SIP request rate is a max rate that m= ay not be
   attained by the arrival rate at the client, and the= server cannot
   assume that it will."

Your comment :
"Not clear what value this paragraph tries to add.  Is= it saying that the client's arrival rate may be lower than the target SIP = request rate?  "

Yes.

Suppose the server want to limit the total rate of arriving SIP = messages to 100 / sec, and has 10 clients.  Each client has a high var= iance in its message rate, but together they are well above 100 messages per sec

If it sets the rate at 10 messages per second for each of the cl= ients, it will almost certainly end up  with an overall average of les= s than 100 messages per sec, because some clients will be in a "lull" while others are busy.  This is good from a thrott= ling perspective, but, assuming messages are correlated with revenue, bad/w= asteful from a revenue, or overall productivity perspective.  So the s= erver might want to set the rate per client to 10 + delta, where delta is going to be very specific to operating environment.<= /span>

---
In section  3.5.1, bottom of page 8
ID says:
"And the larger
   the difference between TAU1 and TAU2, the closer to= the control is
   to strict priority."

You propose changing it to:
"And the larger
   the difference between TAU1 and TAU2, the closer &n= bsp;the control is
   to strict priority queuing."

I agree with taking out the redundant "to".  But = I disagree wit adding "queuing".  There is no queuing, prior= ity or otherwise involved.

You could say:
"And the larger
   the difference between TAU1 and TAU2, the closer &n= bsp;the control is
   to strict priority treatment."

where " strict priority treatment" would refer to the = case where non-priority messages are restricted to a total (priority + = non-priority) rate of 10 messages per second, but priority messages can continue to be sent as long as the total (priority + non-priority)= rate is less than 12 messages per second.

At least, I think that is what Eric and  Philip are trying = to say.

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 agreement or government initiative exp= ressly permitting the use of e-mail for such purpose.



From:        &= quot;Yu, James" <james.yu@n= eustar.biz>
To:        &= quot;sip-overload-bounces@= ietf.org" <sip= -overload-bounces@ietf.org>, "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" &l= t;draft-ietf-soc-overload-rate-control.all@tools.ietf.org>, "sip-overload@ietf.org&q= uot; <sip-overload@ietf.org= >
Date:        0= 6/28/2013 08:10 AM
Subject:        [sip-overload] draft-ietf-soc-overload-rate-control-04.txt
Sent by:        sip-overload-bounces@iet= f.org




Salvatore,
 
Please see the attachment for my comments.
 
I pasted the text to a word document to trace/show the propose= d changes and comments.
 
Regards,
 
James
 [attachment "comments on draft-ietf-soc-overload-ra= te-control-04.docx" deleted by Janet P Gunn/USA/CSC] _______________________________= ________________
sip-overload mailing list
sip-overload@ietf.org=
<= span style=3D"font-size:10.0pt">https://www.ietf.org/mailman/listinfo/sip-o= verload

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 3204/6452 - Release Date: 06/30/13

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13

--_000_56FB15AFE08E1242B0736CBDCE6E856108092BD9stntexmb12cisne_-- From ecnoel@research.att.com Wed Jul 10 12:54: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 77A6721F9C6F; Wed, 10 Jul 2013 12:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8Ksx6mY-bui; Wed, 10 Jul 2013 12:54:12 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 2213021F9DE2; Wed, 10 Jul 2013 12:54:12 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 3D528120668; Wed, 10 Jul 2013 15:54:07 -0400 (EDT) Received: from njfpsrvexg2.research.att.com (njfpsrvexg2.research.att.com [135.207.177.29]) by mail-green.research.att.com (Postfix) with ESMTP id AF47DE0220; Wed, 10 Jul 2013 15:52:31 -0400 (EDT) Received: from njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9]) by njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9%14]) with mapi; Wed, 10 Jul 2013 15:54:08 -0400 From: "NOEL, ERIC C (ERIC C)" To: "'Yu, James'" Date: Wed, 10 Jul 2013 15:54:07 -0400 Thread-Topic: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Thread-Index: Ac5zhcqru7dYQFxqQKSGvvGKSQFJEAA0j1MAALOuppABZadV0AAr0zMgAAJGKhAAAUkxUAABlYhgAAIP6nAABdJLAAABh6NQ Message-ID: <5EBD159DE88147488A3B1590E09001840353C0687581@njfpsrvexg2.research.att.com> References: <56FB15AFE08E1242B0736CBDCE6E85610808C32F@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610808EF90@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353BDA4CAD4@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E85610809239D@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610809253D@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353C0687578@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E856108092986@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353C068757C@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E856108092BD9@stntexmb12.cis.neustar.com> In-Reply-To: <56FB15AFE08E1242B0736CBDCE6E856108092BD9@stntexmb12.cis.neustar.com> 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_5EBD159DE88147488A3B1590E09001840353C0687581njfpsrvexg2_" MIME-Version: 1.0 Cc: "sip-overload-bounces@ietf.org" , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" , "sip-overload@ietf.org" Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.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, 10 Jul 2013 19:54:21 -0000 --_000_5EBD159DE88147488A3B1590E09001840353C0687581njfpsrvexg2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable James, So section 5 (syntax) will include the following statements: oc =3D "oc" [EQUAL oc-num] oc-num =3D 1*DIGIT oc-algo =3D "oc-algo" EQUAL DQUOTE algo-list *(COMMA algo-list) DQUOTE algo-list =3D "loss" / "rate" / *(other-algo) other-algo =3D %x41-5A / %x61-7A / %x30-39 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: Yu, James [mailto:james.yu@neustar.biz] Sent: Wednesday, July 10, 2013 3:10 PM To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all= @tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Eric, You may want to copy the "oc-algo" line from other I-D. James From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] Sent: Wednesday, July 10, 2013 1:10 PM To: Yu, James Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all= @tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, Based on your suggestion and comments from other reviewers, I intend to upd= ate section 5 (syntax) as follows: oc =3D "oc" [EQUAL oc-num] oc-num =3D 1*DIGIT algo-list =3D "loss" / "rate" / *(other-algo) other-algo =3D %x41-5A / %x61-7A / %x30-39 I understand there may be an additional change following Henning's reply. 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: Yu, James [mailto:james.yu@neustar.biz] Sent: Wednesday, July 10, 2013 11:36 AM To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Eric, Yes, this adds "rate" to "oc-algo" parameter but please check with IANA to = see if it is the correct way. You also need to copy some syntax lines from= the draft-ietf-soc-overload-control to show algo-list =3D "loss" / "rate" / *(other-algo) I've an email to Henning asking if algo-list in his I-D should be algo-list =3D "loss" / other-algo If yes, then this particular line in your I-D would be algo-list =3D "loss" / "rate" / other-algo James From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] Sent: Wednesday, July 10, 2013 10:49 AM To: Yu, James Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, Thank you for your suggestion. Not being familiar with IANA procedure, would updating draft-ietf-soc-overl= oad-rate-control section 7 (IANA considerations) as follows work? This specification defines a new value for Via header parameter oc-algo as = detailed below in the "Header Field Parameter and Parameter Values" subregi= stry as per the registry created by [RFC3968]. The required information is: Header Field Parameter Name Predefined Val= ues Reference ---------------------------------------------------------------------------= ------------------------------- Via oc-algo = "rate" RFCXXXX RFC XXXX [NOTE TO RFC-EDITOR: Please replace with final RFC number of this = specification.] 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: Yu, James [mailto:james.yu@neustar.biz] Sent: Wednesday, July 10, 2013 10:17 AM To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Noel, I forgot to respond to your reply about the IANA registration of "rate" in = oc-algo. I see that draft-ietf-soc-overload-control-13 mentions your I-D b= ut does not have "rate" in algo-list. There are two possible ways to address "rate" in algo-list. One is to have= draft-ietf-soc-overload-control-13 add "rate" to algo-list and refer to yo= ur I-D for details. The other is to register "rate" in algo-list with IANA= in your I-D, and this should be a simple task. The cleaner way that is mo= re inline with the IETF process would be the latter. It seems odd to have = something defined in a RFC without details about it, and it would be too mu= ch trouble to combine the two I-Ds. James From: Yu, James Sent: Wednesday, July 10, 2013 9:01 AM To: 'NOEL, ERIC C (ERIC C)' Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Noel, I mentioned in my message to Janet on 7/2: For the rate control, the server could calculate the arrival rate from each= communicating client so that it could allocate the overall target SIP requ= est rate to the clients based on their arrival rates known to the server. = But another option is for the client to "optionally" include its calculated= arrival rate in its request to the server when rate control related parame= ters are present. Should this option be evaluated/included to relieve the = server from doing the arrival rate calculations. This would be beneficial = to a server when it receives the requests from many clients. I suggest that the I-D adds that option to allow the client to indicate its= current arrival rate (towards the receiving server) in the SIP request. James From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] Sent: Tuesday, July 09, 2013 4:44 PM To: Yu, James; Janet P Gunn Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Janet, James, Thanks you for your valuable comments and discussion. I tried to capture a= ll resolution in the following text (based on James word document with trac= k changes and imbedded comments enabled). + Abstract section: - Agreed with suggested changes - Please note I will also need to make further changes to remove all refere= nces per Christer Holmberg comment + Section 1: - Agreed with suggested changes + Section 3.1: - Agreed with suggested changes + Section 3.2: - Please note the section title will become "Via header fiel= d parameters for overload control " per Christer Holmberg comment - Agreed with suggested changes excluding title that will change per previo= us bullet + Section 3.3: - Agreed with suggested changes + Section 3.4: - ID: "Note that the target SIP request rate is a max rate that may not be= attained by the arrival rate at the client, and the server cannot assume t= hat it will." [JY] Not clear what value this paragraph tries to add. Is it saying tha= t the client's arrival rate may be lower than the target SIP request rate? [JG] Yes + supporting example (see below in thread) Agreed with Janet and supporting example. Per James request, I will add t= he following text (inspired from Janet's illustrative example): "In other words, when multiple clients are being controlled by an overlo= aded server, at any given time some clients may receive requests at a rate = below its target SIP request rate while others above that target rate. But = the resulting request rate presented to the overloaded server will converge= towards the target SIP request rate." - Agreed with other suggested changes + Section 3.5.1: - ID: "And the larger the difference between TAU1 and TAU2, the closer to t= he control is to strict priority." [JY] Suggest changing into "And the larger the difference between TAU1 an= d TAU2, the closer the control is to strict priority queuing." [JG] Suggest changing into "And the larger the difference between TAU1 an= d TAU2, the closer the control is to strict priority treatment." [EN] Agreed with Janet's suggestion - Agreed with other suggested changes + Section 4: - Agreed with suggested changes + Section 5: - Please note that based comments from per Christer Holmberg and Janet Gunn= , the following was tentatively agreed Replace oc-value =3D "NaN" / oc-num by oc =3D "oc" [EQUAL oc-num] - Agreed with other suggested change + Section 7: - [JY] Should "rate" in oc-algo be registered with IANA? This issue needs to be addressed by draft-ietf-soc-overload-control autho= rs Please note I will wait until expiration of WGLC prior updating our draft R= FC. Once again your comments and/or suggestions are most appreciated. 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 Yu, James Sent: Tuesday, July 02, 2013 9:42 AM To: Janet P Gunn Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Janet, For my comment on section 3.4 (the first one below), the current text does = not provide any value. The client's arrival rate could be well below the t= arget SIP request rate when its load is light so the fact that the client m= ay not achieve the target SIP request rate (the max. rate it is allowed to = send to the server) is well understood. But with your explanation on the "= delta" part, the text then makes sense. Please add some discussions on the= "delta" aspect so that even if the average arrival rate at the client is h= igher than the target SIP request rate the client at times may not send mor= e than what the target SIP request rate allows due to the fluctuation of th= e arriving requests at the client. For the comment on section 3.5.1, I agree with your proposed change. For the rate control, the server could calculate the arrival rate from each= communicating client so that it could allocate the overall target SIP requ= est rate to the clients based on their arrival rates known to the server. = But another option is for the client to "optionally" include its calculated= arrival rate in its request to the server when rate control related parame= ters are present. Should this option be evaluated/included to relieve the = server from doing the arrival rate calculations. This would be beneficial = to a server when it receives the requests from many clients. James From: Janet P Gunn [mailto:jgunn6@csc.com] Sent: Friday, June 28, 2013 3:34 PM To: Yu, James Cc: draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org; sip-overload-bounces@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, It is a little hard to respond in email when your comments are in a separat= e document, but here goes. section 3.4 ID says: "Note that the target SIP request rate is a max rate that may not be attained by the arrival rate at the client, and the server cannot assume that it will." Your comment : "Not clear what value this paragraph tries to add. Is it saying that the c= lient's arrival rate may be lower than the target SIP request rate? " Yes. Suppose the server want to limit the total rate of arriving SIP messages to= 100 / sec, and has 10 clients. Each client has a high variance in its mes= sage rate, but together they are well above 100 messages per sec If it sets the rate at 10 messages per second for each of the clients, it w= ill almost certainly end up with an overall average of less than 100 messa= ges per sec, because some clients will be in a "lull" while others are busy= . This is good from a throttling perspective, but, assuming messages are c= orrelated with revenue, bad/wasteful from a revenue, or overall productivit= y perspective. So the server might want to set the rate per client to 10 += delta, where delta is going to be very specific to operating environment. --- In section 3.5.1, bottom of page 8 ID says: "And the larger the difference between TAU1 and TAU2, the closer to the control is to strict priority." You propose changing it to: "And the larger the difference between TAU1 and TAU2, the closer the control is to strict priority queuing." I agree with taking out the redundant "to". But I disagree wit adding "que= uing". There is no queuing, priority or otherwise involved. You could say: "And the larger the difference between TAU1 and TAU2, the closer the control is to strict priority treatment." where " strict priority treatment" would refer to the case where non-priori= ty messages are restricted to a total (priority + non-priority) rate of 10 = messages per second, but priority messages can continue to be sent as long = as the total (priority + non-priority) rate is less than 12 messages per se= cond. At least, I think that is what Eric and Philip are trying to say. 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: "Yu, James" = > To: "sip-overload-bounces@ietf.org" >= , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" >, "sip-overload@ietf.org"= > Date: 06/28/2013 08:10 AM Subject: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Sent by: sip-overload-bounces@ietf.org ________________________________ Salvatore, Please see the attachment for my comments. I pasted the text to a word document to trace/show the proposed changes and= comments. Regards, James [attachment "comments on draft-ietf-soc-overload-rate-control-04.docx" del= eted by Janet P Gunn/USA/CSC] _____________________________________________= __ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6452 - Release Date: 06/30/13 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13 --_000_5EBD159DE88147488A3B1590E09001840353C0687581njfpsrvexg2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable = --_000_5EBD159DE88147488A3B1590E09001840353C0687581njfpsrvexg2_-- From keith.drage@alcatel-lucent.com Wed Jul 10 15:04:59 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 B4C3011E8124; Wed, 10 Jul 2013 15:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TddrfhZJG0Du; Wed, 10 Jul 2013 15:04:49 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 30AAB11E8135; Wed, 10 Jul 2013 15:04:45 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r6AM4dZF016299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 10 Jul 2013 17:04:41 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6AM4dt3025108 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Jul 2013 00:04:39 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Thu, 11 Jul 2013 00:04:38 +0200 From: "DRAGE, Keith (Keith)" To: "NOEL, ERIC C (ERIC C)" , "'Yu, James'" Thread-Topic: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Thread-Index: Ac5zhcqru7dYQFxqQKSGvvGKSQFJEAA0j1MAALOuppABZadV0AAr0zMgAAJGKhAAAUkxUAABlYhgAAIP6nAABdJLAAABh6NQAAMQj4A= Date: Wed, 10 Jul 2013 22:04:38 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B06820F@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <56FB15AFE08E1242B0736CBDCE6E85610808C32F@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610808EF90@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353BDA4CAD4@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E85610809239D@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610809253D@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353C0687578@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E856108092986@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353C068757C@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E856108092BD9@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353C0687581@njfpsrvexg2.research.att.com> In-Reply-To: <5EBD159DE88147488A3B1590E09001840353C0687581@njfpsrvexg2.research.att.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B06820FFR712WXCHMBA11zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "sip-overload-bounces@ietf.org" , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" , "sip-overload@ietf.org" Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.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, 10 Jul 2013 22:04:59 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B06820FFR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've lost track of what is happening here. What I expect is two things: 1) IANA registration impact. For the header field parameters registry, draft-ietf-soc-overload-control a= lready creates the new rows: Header Field Parameter Name Predefined Values Reference __________________________________________________________ Via oc Yes RFCXXXX Via oc-validity Yes RFCXXXX Via oc-seq Yes RFCXXXX Via oc-algo Yes RFCXXXX RFC XXXX [NOTE TO RFC-EDITOR: Please replace with final RFC number of this specification.] For the predefined values columns, RFC 3968 states: Some SIP header field parameters only accept a set of predefined parameter values. For example, a parameter indicating the transport protocol in use may only accept the predefined tokens TCP, UDP, and SCTP as valid values. Registering all parameter values for all SIP header field parameters of this type would require a large number of subregistries. Instead, we have chosen to register parameter values by reference. That is, the entry in the parameter registry for a given header field parameter contains references to the RFCs defining new values of the parameter. References to RFCs defining parameter values appear in double brackets in the registry. So, the header field parameter registry contains a column that indicates whether or not each parameter only accepts a set of predefined values. Implementers of parameters with a "yes" in that column need to find all the valid parameter values in the RFCs provided as references. With this understanding, I do not believe the rate-control draft needs to m= odify the "predefined values" column. What it does need to do is add its ul= timate RFC number to the reference column. There could be an argument that there needs to be a new table that lists th= e algorithm values, but a) if such a table is to be created, it needs to be creat= ed by draft-ietf-soc-overload-control rather than the rate-control draft/ b) I personally do not think it is necessary to add such = a new table, as I think the references are sufficient. One cannot handle th= e algorithm values unless one goes to the relevant RFC. 2) ABNF impact. ABNF defines the /=3D operator for adding new values to an existing defined= list. I do not think we should reproduce existing ABNF from draft-ietf-soc-overlo= ad-control and then amend it. The reason for this is that tools exist for automatically extracting the AB= NF from RFCs. An extracted algo-list /=3D "rate" will work perfectly well with the extract from draft-ietf-soc-overload-cont= rol (and from SIP). Reproducing productions will result in conflict. Regards Keith ________________________________ From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] = On Behalf Of NOEL, ERIC C (ERIC C) Sent: 10 July 2013 20:54 To: 'Yu, James' Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all= @tools.ietf.org; sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, So section 5 (syntax) will include the following statements: oc =3D "oc" [EQUAL oc-num] oc-num =3D 1*DIGIT oc-algo =3D "oc-algo" EQUAL DQUOTE algo-list *(COMMA algo-list) DQUOTE algo-list =3D "loss" / "rate" / *(other-algo) other-algo =3D %x41-5A / %x61-7A / %x30-39 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: Yu, James [mailto:james.yu@neustar.biz] Sent: Wednesday, July 10, 2013 3:10 PM To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all= @tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Eric, You may want to copy the "oc-algo" line from other I-D. James From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] Sent: Wednesday, July 10, 2013 1:10 PM To: Yu, James Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all= @tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, Based on your suggestion and comments from other reviewers, I intend to upd= ate section 5 (syntax) as follows: oc =3D "oc" [EQUAL oc-num] oc-num =3D 1*DIGIT algo-list =3D "loss" / "rate" / *(other-algo) other-algo =3D %x41-5A / %x61-7A / %x30-39 I understand there may be an additional change following Henning's reply. 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: Yu, James [mailto:james.yu@neustar.biz] Sent: Wednesday, July 10, 2013 11:36 AM To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Eric, Yes, this adds "rate" to "oc-algo" parameter but please check with IANA to = see if it is the correct way. You also need to copy some syntax lines from= the draft-ietf-soc-overload-control to show algo-list =3D "loss" / "rate" / *(other-algo) I've an email to Henning asking if algo-list in his I-D should be algo-list =3D "loss" / other-algo If yes, then this particular line in your I-D would be algo-list =3D "loss" / "rate" / other-algo James From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] Sent: Wednesday, July 10, 2013 10:49 AM To: Yu, James Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, Thank you for your suggestion. Not being familiar with IANA procedure, would updating draft-ietf-soc-overl= oad-rate-control section 7 (IANA considerations) as follows work? This specification defines a new value for Via header parameter oc-algo as = detailed below in the "Header Field Parameter and Parameter Values" subregi= stry as per the registry created by [RFC3968]. The required information is: Header Field Parameter Name Predefined Val= ues Reference ---------------------------------------------------------------------------= ------------------------------- Via oc-algo = "rate" RFCXXXX RFC XXXX [NOTE TO RFC-EDITOR: Please replace with final RFC number of this = specification.] 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: Yu, James [mailto:james.yu@neustar.biz] Sent: Wednesday, July 10, 2013 10:17 AM To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Noel, I forgot to respond to your reply about the IANA registration of "rate" in = oc-algo. I see that draft-ietf-soc-overload-control-13 mentions your I-D b= ut does not have "rate" in algo-list. There are two possible ways to address "rate" in algo-list. One is to have= draft-ietf-soc-overload-control-13 add "rate" to algo-list and refer to yo= ur I-D for details. The other is to register "rate" in algo-list with IANA= in your I-D, and this should be a simple task. The cleaner way that is mo= re inline with the IETF process would be the latter. It seems odd to have = something defined in a RFC without details about it, and it would be too mu= ch trouble to combine the two I-Ds. James From: Yu, James Sent: Wednesday, July 10, 2013 9:01 AM To: 'NOEL, ERIC C (ERIC C)' Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Noel, I mentioned in my message to Janet on 7/2: For the rate control, the server could calculate the arrival rate from each= communicating client so that it could allocate the overall target SIP requ= est rate to the clients based on their arrival rates known to the server. = But another option is for the client to "optionally" include its calculated= arrival rate in its request to the server when rate control related parame= ters are present. Should this option be evaluated/included to relieve the = server from doing the arrival rate calculations. This would be beneficial = to a server when it receives the requests from many clients. I suggest that the I-D adds that option to allow the client to indicate its= current arrival rate (towards the receiving server) in the SIP request. James From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] Sent: Tuesday, July 09, 2013 4:44 PM To: Yu, James; Janet P Gunn Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Janet, James, Thanks you for your valuable comments and discussion. I tried to capture a= ll resolution in the following text (based on James word document with trac= k changes and imbedded comments enabled). + Abstract section: - Agreed with suggested changes - Please note I will also need to make further changes to remove all refere= nces per Christer Holmberg comment + Section 1: - Agreed with suggested changes + Section 3.1: - Agreed with suggested changes + Section 3.2: - Please note the section title will become "Via header fiel= d parameters for overload control " per Christer Holmberg comment - Agreed with suggested changes excluding title that will change per previo= us bullet + Section 3.3: - Agreed with suggested changes + Section 3.4: - ID: "Note that the target SIP request rate is a max rate that may not be= attained by the arrival rate at the client, and the server cannot assume t= hat it will." [JY] Not clear what value this paragraph tries to add. Is it saying tha= t the client's arrival rate may be lower than the target SIP request rate? [JG] Yes + supporting example (see below in thread) Agreed with Janet and supporting example. Per James request, I will add t= he following text (inspired from Janet's illustrative example): "In other words, when multiple clients are being controlled by an overlo= aded server, at any given time some clients may receive requests at a rate = below its target SIP request rate while others above that target rate. But = the resulting request rate presented to the overloaded server will converge= towards the target SIP request rate." - Agreed with other suggested changes + Section 3.5.1: - ID: "And the larger the difference between TAU1 and TAU2, the closer to t= he control is to strict priority." [JY] Suggest changing into "And the larger the difference between TAU1 an= d TAU2, the closer the control is to strict priority queuing." [JG] Suggest changing into "And the larger the difference between TAU1 an= d TAU2, the closer the control is to strict priority treatment." [EN] Agreed with Janet's suggestion - Agreed with other suggested changes + Section 4: - Agreed with suggested changes + Section 5: - Please note that based comments from per Christer Holmberg and Janet Gunn= , the following was tentatively agreed Replace oc-value =3D "NaN" / oc-num by oc =3D "oc" [EQUAL oc-num] - Agreed with other suggested change + Section 7: - [JY] Should "rate" in oc-algo be registered with IANA? This issue needs to be addressed by draft-ietf-soc-overload-control autho= rs Please note I will wait until expiration of WGLC prior updating our draft R= FC. Once again your comments and/or suggestions are most appreciated. 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 Yu, James Sent: Tuesday, July 02, 2013 9:42 AM To: Janet P Gunn Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Janet, For my comment on section 3.4 (the first one below), the current text does = not provide any value. The client's arrival rate could be well below the t= arget SIP request rate when its load is light so the fact that the client m= ay not achieve the target SIP request rate (the max. rate it is allowed to = send to the server) is well understood. But with your explanation on the "= delta" part, the text then makes sense. Please add some discussions on the= "delta" aspect so that even if the average arrival rate at the client is h= igher than the target SIP request rate the client at times may not send mor= e than what the target SIP request rate allows due to the fluctuation of th= e arriving requests at the client. For the comment on section 3.5.1, I agree with your proposed change. For the rate control, the server could calculate the arrival rate from each= communicating client so that it could allocate the overall target SIP requ= est rate to the clients based on their arrival rates known to the server. = But another option is for the client to "optionally" include its calculated= arrival rate in its request to the server when rate control related parame= ters are present. Should this option be evaluated/included to relieve the = server from doing the arrival rate calculations. This would be beneficial = to a server when it receives the requests from many clients. James From: Janet P Gunn [mailto:jgunn6@csc.com] Sent: Friday, June 28, 2013 3:34 PM To: Yu, James Cc: draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org; sip-overload-bounces@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, It is a little hard to respond in email when your comments are in a separat= e document, but here goes. section 3.4 ID says: "Note that the target SIP request rate is a max rate that may not be attained by the arrival rate at the client, and the server cannot assume that it will." Your comment : "Not clear what value this paragraph tries to add. Is it saying that the c= lient's arrival rate may be lower than the target SIP request rate? " Yes. Suppose the server want to limit the total rate of arriving SIP messages to= 100 / sec, and has 10 clients. Each client has a high variance in its mes= sage rate, but together they are well above 100 messages per sec If it sets the rate at 10 messages per second for each of the clients, it w= ill almost certainly end up with an overall average of less than 100 messa= ges per sec, because some clients will be in a "lull" while others are busy= . This is good from a throttling perspective, but, assuming messages are c= orrelated with revenue, bad/wasteful from a revenue, or overall productivit= y perspective. So the server might want to set the rate per client to 10 += delta, where delta is going to be very specific to operating environment. --- In section 3.5.1, bottom of page 8 ID says: "And the larger the difference between TAU1 and TAU2, the closer to the control is to strict priority." You propose changing it to: "And the larger the difference between TAU1 and TAU2, the closer the control is to strict priority queuing." I agree with taking out the redundant "to". But I disagree wit adding "que= uing". There is no queuing, priority or otherwise involved. You could say: "And the larger the difference between TAU1 and TAU2, the closer the control is to strict priority treatment." where " strict priority treatment" would refer to the case where non-priori= ty messages are restricted to a total (priority + non-priority) rate of 10 = messages per second, but priority messages can continue to be sent as long = as the total (priority + non-priority) rate is less than 12 messages per se= cond. At least, I think that is what Eric and Philip are trying to say. 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: "Yu, James" = > To: "sip-overload-bounces@ietf.org" >= , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" >, "sip-overload@ietf.org"= > Date: 06/28/2013 08:10 AM Subject: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Sent by: sip-overload-bounces@ietf.org ________________________________ Salvatore, Please see the attachment for my comments. I pasted the text to a word document to trace/show the proposed changes and= comments. Regards, James [attachment "comments on draft-ietf-soc-overload-rate-control-04.docx" del= eted by Janet P Gunn/USA/CSC] _____________________________________________= __ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6452 - Release Date: 06/30/13 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13 --_000_949EF20990823C4C85C18D59AA11AD8B06820FFR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve lost track of what is happe= ning here. What I expect is two things:

 

1)      =    IANA registration impact.

 

For the header field parameters regist= ry, draft-ietf-soc-overload-control already creates the new rows:

 

       Header Field  Parameter Name&nbs=
p; Predefined Values  Reference
       _____________________________________=
_____________________
       Via     &nbs=
p;     oc       &nbs=
p;         Yes   &nb=
sp;         RFCXXXX
       Via     &nbs=
p;     oc-validity      &=
nbsp; Yes           =
  RFCXXXX
       Via     &nbs=
p;     oc-seq       =
      Yes       =
;      RFCXXXX
       Via     &nbs=
p;     oc-algo       =
;     Yes       &nbs=
p;     RFCXXXX
 
       RFC XXXX [NOTE TO RFC-EDITOR: Please =
replace with final RFC
       number of this specification.]

 

For the predefined values columns, RFC= 3968 states:

 

   Some SIP header field parameters only accept a set of predefi=
ned
   parameter values.  For example, a parameter indicating t=
he transport
   protocol in use may only accept the predefined tokens TCP, UDP, and
   SCTP as valid values.  Registering all parameter values =
for all SIP
   header field parameters of this type would require a large nu=
mber of
   subregistries.  Instead, we have chosen to register para=
meter values
   by reference.  That is, the entry in the parameter regis=
try for a
   given header field parameter contains references to the RFCs =
defining
   new values of the parameter.  References to RFCs definin=
g parameter
   values appear in double brackets in the registry.<=
/span>
 
   So, the header field parameter registry contains a column tha=
t
   indicates whether or not each parameter only accepts a set of=

   predefined values.  Implementers of parameters with a &q=
uot;yes" in that
   column need to find all the valid parameter values in the RFC=
s
   provided as references.

 

With this understanding, I do not beli= eve the rate-control draft needs to modify the “predefined valuesR= 21; column. What it does need to do is add its ultimate RFC number to the reference column.

 

There could be an argument that there = needs to be a new table that lists the algorithm values, but

 

a) &= nbsp;           &nbs= p;     if such a table is to be created, it needs to be created by draft-ietf-= soc-overload-control rather than the rate-control draft/

b) &= nbsp;           &nbs= p;     I personally do not think it is necessary to add such a new table, as I= think the references are sufficient. One cannot handle the algorithm values unless one goes to the relevant RFC.

 

2)      =    ABNF impact.

 

ABNF defines the /=3D operator for add= ing new values to an existing defined list.

 

I do not think we should reproduce exi= sting ABNF from draft-ietf-soc-overload-control and then amend it.

 

The reason for this is that tools exis= t for automatically extracting the ABNF from RFCs. An extracted

 

= algo-list /=3D “rate“

 

will work perfectly well with the extr= act from draft-ietf-soc-overload-control (and from SIP). Reproducing produc= tions will result in conflict.

 

Regards

 

Keith

 

From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] On Behalf Of NOEL, ERIC C (ERIC C)
Sent: 10 July 2013 20:54
To: 'Yu, James'
Cc: sip-overload-bounces@iet= f.org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overloa= d@ietf.org
Subject: Re: [sip-overload] = draft-ietf-soc-overload-rate-control-04.txt

 

= James,

=  

= So section 5 (syntax) will include the following statements:

=  

= oc =3D “oc” [EQUAL oc-num]

= oc-num =3D 1*DIGIT

= oc-algo =3D "oc-algo" EQUAL DQUOTE algo-list *(COMMA algo-= list) DQUOTE

= algo-list =3D “loss” / “rate“ / *(other-algo= )

= other-algo =3D %x41-5A / %x61-7A / %x30-39<= /p>

=  

= 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.4= 174

= = ecnoel@att.com

=  

From: Yu, James [mailto:james.yu@neustar.biz]
Sent: Wednesday, July 10, 2013 3:= 10 PM
To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@iet= f.org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overloa= d@ietf.org
Subject: RE: [sip-overload] = draft-ietf-soc-overload-rate-control-04.txt

 

Eric,

= You may want to copy the “oc-algo” line from other I-D.<= o:p>

=  

= James

=  

From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com]
Sent: Wednesday, July 10, 2013 1:= 10 PM
To: Yu, James
Cc: sip-overload-bounces@iet= f.org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overloa= d@ietf.org
Subject: RE: [sip-overload] = draft-ietf-soc-overload-rate-control-04.txt

 

= James,

=  

= Based on your suggestion and comments from other reviewers, I intend= to update section 5 (syntax) as follows:

=  

= oc =3D “oc” [EQUAL oc-num]

= oc-num =3D 1*DIGIT

=  

= algo-list =3D “loss” / “rate“ / *(other-algo= )

= other-algo =3D %x41-5A / %x61-7A / %x30-39<= /p>

=  

= I understand there may be an additional change following HenningR= 17;s reply.

=  

= 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.4= 174

= = ecnoel@att.com

=  

From: Yu, James [mailto:james.yu@neustar.biz] =
Sent: Wednesday, July 10, 2013 11= :36 AM
To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload] = draft-ietf-soc-overload-rate-control-04.txt

 

= Eric,

=  

= Yes, this adds “rate” to “oc-algo” parameter= but please check with IANA to see if it is the correct way.  You also need to copy some syntax lines from the draft-ietf-soc-overload-control to= show

=  

=      algo-list   =3D &#= 8220;= loss“ / “rate“ / *(other-algo)

=  

= I’ve an email to Henning asking if algo-list in his I-D should= be

=      algo-list   =3D “loss“ / other-algo

=  

= If yes, then this particular line in your I-D would be

=      algo-list &n= bsp; =3D “loss“ / “rate“ / other-algo

=  

= James

=  

From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@resea= rch.att.com]
Sent: Wednesday, July 10, 2013 10= :49 AM
To: Yu, James
Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload] = draft-ietf-soc-overload-rate-control-04.txt

 

= James,

=  

= Thank you for your suggestion.

=  

= Not being familiar with IANA procedure, would updating draft-ietf-so= c-overload-rate-control section 7 (IANA considerations) as follows work?

=  

= This specification defines a new value for Via header parameter oc-a= lgo as detailed below in the "Header Field Parameter and Parameter Values" subregistry as per the registry created by [RFC= 3968]. The required information is:

=  

= Header Field          &= nbsp;Parameter Name          &= nbsp;           &nbs= p; Predefined Values         &= nbsp;          Reference<= o:p>

= --------------------------------------------------------------------= --------------------------------------

= Via           &nbs= p;            &= nbsp;     oc-algo      &n= bsp;            = ;            &n= bsp;            = ;  “rate”       &n= bsp;            = ;                         RF= CXXXX

=  

= RFC XXXX [NOTE TO RFC-EDITOR: Please replace with final RFC number o= f this specification.]

=  

= 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.4= 174

= = ecnoel@att.com

=  

From: Yu, James [mailto:james.yu@neustar.biz] =
Sent: Wednesday, July 10, 2013 10= :17 AM
To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload] = draft-ietf-soc-overload-rate-control-04.txt

 

= Noel,

=  

= I forgot to respond to your reply about the IANA registration of = 220;rate” in oc-algo.  I see that draft-ietf-soc-overload-contro= l-13 mentions your I-D but does not have “rate” in algo-list.<= /o:p>

=  

= There are two possible ways to address “rate” in algo-li= st.  One is to have draft-ietf-soc-overload-control-13 add “rate” to algo-list and refer to your I-D for details.  T= he other is to register “rate” in algo-list with IANA in your I= -D, and this should be a simple task.  The cleaner way that is more in= line with the IETF process would be the latter.  It seems odd to have something defined in a RFC without details about it, and it would be too m= uch trouble to combine the two I-Ds.

=  

= James

=  

From: Yu, James
Sent: Wednesday, July 10, 2013 9:0= 1 AM
To: 'NOEL, ERIC C (ERIC C)'<= br> Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload] = draft-ietf-soc-overload-rate-control-04.txt

 

= Noel,

=  

= I mentioned in my message to Janet on 7/2:<= /p>

=  

For the rate control, the server could calculate the arrival r= ate from each communicating client so that it could allocate the overall target SIP request rate to th= e clients based on their arrival rates known to the server.  But anoth= er option is for the client to “optionally” include its calcula= ted arrival rate in its request to the server when rate control related parameters are present.  Should this option be e= valuated/included to relieve the server from doing the arrival rate calcula= tions.  This would be beneficial to a server when it receives the requ= ests from many clients.

=  

= I suggest that the I-D adds that option to allow the client to indic= ate its current arrival rate (towards the receiving server) in the SIP request.

=  

= James

=  

From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@resea= rch.att.com]
Sent: Tuesday, July 09, 2013 4:= 44 PM
To: Yu, James; Janet P Gunn<= br> Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload] = draft-ietf-soc-overload-rate-control-04.txt

 

= Janet, James,

=  

= Thanks you for your valuable comments and discussion.  I tried = to capture all resolution in the following text (based on James word document with track changes and imbedded comments enabled).<= o:p>

=  

= + Abstract section:

= - Agreed with suggested changes

= - Please note I will also need to make further changes to remove all= references per Christer Holmberg comment

=  

= + Section 1:

= - Agreed with suggested changes

=  

= + Section 3.1:

= - Agreed with suggested changes

=  

= + Section 3.2: - Please note the section title will become ̶= 0;Via header field parameters for overload control “ per Christer Holmberg comment

= - Agreed with suggested changes excluding title that will change per= previous bullet

=  

= + Section 3.3:

= - Agreed with suggested changes

=  

= + Section 3.4:

= - ID:  "Note that the target SIP request rate is a max rat= e that may not be attained by the arrival rate at the client, and the server cannot assume that it will."

=    [JY] Not clear what value this paragraph tries to = add.  Is it saying that the client's arrival rate may be lower than the target SIP request rate?

=    [JG] Yes + supporting example (see below in th= read)

=   Agreed with Janet and supporting example. Per James requ= est, I will add the following text (inspired from Janet’s illustrative example):

=    “In other words, when multiple clients are being = controlled by an overloaded server, at any given time some clients may receive requests at a rate below its target SIP request rate while oth= ers above that target rate. But the resulting request rate presented to the= overloaded server will converge towards the target SIP request rate.”= ;

= - Agreed with other suggested changes

=      

= + Section 3.5.1:

= - ID: “And the larger the difference between TAU1 and TAU2, th= e closer to the control is to strict priority.”

=   [JY] Suggest changing into “And the larger the differen= ce between TAU1 and TAU2, the closer the control is to strict priority queuing.”

=   [JG] Suggest changing into “And the larger the differen= ce between TAU1 and TAU2, the closer the control is to strict priority treatment.”

=   [EN] Agreed with Janet’s suggestion

= - Agreed with other suggested changes

=  

= + Section 4:

= - Agreed with suggested changes

=  

= + Section 5:

= - Please note that based comments from per Christer Holmberg and Jan= et Gunn, the following was tentatively agreed

=    Replace oc-value =3D "= NaN" / oc-num    by    oc = =3D "oc" [EQUAL oc-num]

= - Agreed with other suggested change

=  

= + Section 7:

= - [JY] Should “rate” in oc-algo be registered with IANA?=

=   This issue needs to be addressed by draft-ietf-soc-overload-c= ontrol authors

=  

= Please note I will wait until expiration of WGLC prior updating our = draft RFC. Once again your comments and/or suggestions are most appreciated.

=  

= 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.4= 174

= = ecnoel@att.com

=  

From: sip-overload-bounces@ietf.= org [mailto:sip-overlo= ad-bounces@ietf.org] On Behalf Of Yu, James
Sent: Tuesday, July 02, 2013 9:4= 2 AM
To: Janet P Gunn
Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: Re: [sip-overload] = draft-ietf-soc-overload-rate-control-04.txt

 

= Janet,

=  

= For my comment on section 3.4 (the first one below), the current tex= t does not provide any value.  The client’s arrival rate could be well below the target SIP request rate when its load= is light so the fact that the client may not achieve the target SIP reques= t rate (the max. rate it is allowed to send to the server) is well understo= od.  But with your explanation on the “delta” part, the text then makes sense.  Please add = some discussions on the “delta” aspect so that even if the aver= age arrival rate at the client is higher than the target SIP request rate t= he client at times may not send more than what the target SIP request rate allows due to the fluctuation of the arriving requests at the= client.

=  

= For the comment on section 3.5.1, I agree with your proposed change.=

=  

= For the rate control, the server could calculate the arrival rate fr= om each communicating client so that it could allocate the overall target SIP request rate to the clients based on their= arrival rates known to the server.  But another option is for the cli= ent to “optionally” include its calculated arrival rate in its = request to the server when rate control related parameters are present.  Should this option be evaluated/included to relieve the= server from doing the arrival rate calculations.  This would be benef= icial to a server when it receives the requests from many clients.

=  

= James

=  

From: Janet P Gunn [mailto:jgunn6@csc.com]
Sent: Friday, June 28, 2013 3:= 34 PM
To: Yu, James
Cc: draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org; sip-overload-bounces@ietf.org
Subject: Re: [sip-overload] = draft-ietf-soc-overload-rate-control-04.txt

 

James,

It is a little hard to respond in email when your commen= ts are in a separate document, but here goes.


section 3.4
ID says:
"Note that the target SIP request rate is a max rat= e that may not be
   attained by the arrival rate at the client,= and the server cannot
   assume that it will."

Your comment :
"Not clear what value this paragraph tries to add. =  Is it saying that the client's arrival rate may be lower than the tar= get SIP request rate?  "

Yes.

Suppose the server want to limit the total rate of arriv= ing SIP messages to 100 / sec, and has 10 clients.  Each client has a = high variance in its message rate, but together they are well above 100 messages per sec

If it sets the rate at 10 messages per second for each o= f the clients, it will almost certainly end up  with an overall averag= e of less than 100 messages per sec, because some clients will be in a "lull" while others are b= usy.  This is good from a throttling perspective, but, assuming messag= es are correlated with revenue, bad/wasteful from a revenue, or overall pro= ductivity perspective.  So the server might want to set the rate per client to 10 + delta, where delta is going to be v= ery specific to operating environment.

---
In section  3.5.1, bottom of page 8
ID says:
"And the larger
   the difference between TAU1 and TAU2, the c= loser to the control is
   to strict priority."

You propose changing it to:
"And the larger
   the difference between TAU1 and TAU2, the c= loser  the control is
   to strict priority queuing."

I agree with taking out the redundant "to". &n= bsp;But I disagree wit adding "queuing".  There is no queuin= g, priority or otherwise involved.

You could say:
"And the larger
   the difference between TAU1 and TAU2, the c= loser  the control is
   to strict priority treatment."

where " strict priority treatment" would refer= to the case where non-priority messages are restricted to a total (priorit= y + non-priority) rate of 10 messages per second, but priority messages can continue to be sent as long as the t= otal (priority + non-priority) rate is less than 12 messages per second= .

At least, I think that is what Eric and  Philip are= trying to say.

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 co= ntract unless pursuant to explicit written agreement or government initiati= ve expressly permitting the use of e-mail for such purpose.



From:   &= nbsp;    "Yu, James"= ; <james.yu@neustar.biz><= /span>
To:   &nb= sp;    "sip-overload-bounces@ietf.org" <sip-overload-bounces@= ietf.org>, "draft-ietf-soc-overload-rate-control.all@tools.ietf= .org" <draft-ietf-soc-overload-rate-control.all@tools.ietf.org<= /a>>, "sip-overload@ietf.org&q= uot; <sip-overload@ietf.org= >
Date:   &= nbsp;    06/28/2013 08:10 AM
Subject:  = ;      [sip-overload] draft-ietf-soc-overload-rate-control-04.txt
Sent by:  = ;      sip-overload-bounces@ietf.org




Salvatore,
 
Please see the attachment for my comments.
 
I pasted the text to a word document to trace/show the= proposed changes and comments.
 
Regards,
 
James
 [attachment "comments on draft-ietf-soc-ove= rload-rate-control-04.docx" deleted by Janet P Gunn/USA/CSC] ______________________________________________= _
sip-overload mailing list
sip= -overload@ietf.org
https://www.ietf.org/mailman/listinfo/sip-overload

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 3204/6452 - Release Date: 06/30/13

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13

--_000_949EF20990823C4C85C18D59AA11AD8B06820FFR712WXCHMBA11zeu_-- From keith.drage@alcatel-lucent.com Wed Jul 10 15:08: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 8503511E8135; Wed, 10 Jul 2013 15:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m69B39KrXEnL; Wed, 10 Jul 2013 15:08:10 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 26ED311E8124; Wed, 10 Jul 2013 15:08:09 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r6AM85jO029439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 10 Jul 2013 17:08:07 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6AM84S4026701 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Jul 2013 00:08:04 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Thu, 11 Jul 2013 00:08:04 +0200 From: "DRAGE, Keith (Keith)" To: "DRAGE, Keith (Keith)" , "NOEL, ERIC C (ERIC C)" , "'Yu, James'" Thread-Topic: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Thread-Index: Ac5zhcqru7dYQFxqQKSGvvGKSQFJEAA0j1MAALOuppABZadV0AAr0zMgAAJGKhAAAUkxUAABlYhgAAIP6nAABdJLAAABh6NQAAMQj4AAAahMkA== Date: Wed, 10 Jul 2013 22:08:04 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B068238@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <56FB15AFE08E1242B0736CBDCE6E85610808C32F@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610808EF90@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353BDA4CAD4@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E85610809239D@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610809253D@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353C0687578@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E856108092986@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353C068757C@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E856108092BD9@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353C0687581@njfpsrvexg2.research.att.com> <949EF20990823C4C85C18D59AA11AD8B06820F@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B06820F@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B068238FR712WXCHMBA11zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "sip-overload-bounces@ietf.org" , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" , "sip-overload@ietf.org" Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.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, 10 Jul 2013 22:08:21 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B068238FR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 2 additions. For /=3D read =3D/ For adding the new parameters to the Via header field, draft-ietf-soc-overl= oad control should also use =3D/ (it is not a problem of rate control to fi= x this issue. Keith ________________________________ From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] = On Behalf Of DRAGE, Keith (Keith) Sent: 10 July 2013 23:05 To: NOEL, ERIC C (ERIC C); 'Yu, James' Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all= @tools.ietf.org; sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt I've lost track of what is happening here. What I expect is two things: 1) IANA registration impact. For the header field parameters registry, draft-ietf-soc-overload-control a= lready creates the new rows: Header Field Parameter Name Predefined Values Reference __________________________________________________________ Via oc Yes RFCXXXX Via oc-validity Yes RFCXXXX Via oc-seq Yes RFCXXXX Via oc-algo Yes RFCXXXX RFC XXXX [NOTE TO RFC-EDITOR: Please replace with final RFC number of this specification.] For the predefined values columns, RFC 3968 states: Some SIP header field parameters only accept a set of predefined parameter values. For example, a parameter indicating the transport protocol in use may only accept the predefined tokens TCP, UDP, and SCTP as valid values. Registering all parameter values for all SIP header field parameters of this type would require a large number of subregistries. Instead, we have chosen to register parameter values by reference. That is, the entry in the parameter registry for a given header field parameter contains references to the RFCs defining new values of the parameter. References to RFCs defining parameter values appear in double brackets in the registry. So, the header field parameter registry contains a column that indicates whether or not each parameter only accepts a set of predefined values. Implementers of parameters with a "yes" in that column need to find all the valid parameter values in the RFCs provided as references. With this understanding, I do not believe the rate-control draft needs to m= odify the "predefined values" column. What it does need to do is add its ul= timate RFC number to the reference column. There could be an argument that there needs to be a new table that lists th= e algorithm values, but a) if such a table is to be created, it needs to be created b= y draft-ietf-soc-overload-control rather than the rate-control draft/ b) I personally do not think it is necessary to add such a ne= w table, as I think the references are sufficient. One cannot handle the al= gorithm values unless one goes to the relevant RFC. 2) ABNF impact. ABNF defines the /=3D operator for adding new values to an existing defined= list. I do not think we should reproduce existing ABNF from draft-ietf-soc-overlo= ad-control and then amend it. The reason for this is that tools exist for automatically extracting the AB= NF from RFCs. An extracted algo-list /=3D "rate" will work perfectly well with the extract from draft-ietf-soc-overload-cont= rol (and from SIP). Reproducing productions will result in conflict. Regards Keith ________________________________ From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] = On Behalf Of NOEL, ERIC C (ERIC C) Sent: 10 July 2013 20:54 To: 'Yu, James' Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all= @tools.ietf.org; sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, So section 5 (syntax) will include the following statements: oc =3D "oc" [EQUAL oc-num] oc-num =3D 1*DIGIT oc-algo =3D "oc-algo" EQUAL DQUOTE algo-list *(COMMA algo-list) DQUOTE algo-list =3D "loss" / "rate" / *(other-algo) other-algo =3D %x41-5A / %x61-7A / %x30-39 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: Yu, James [mailto:james.yu@neustar.biz] Sent: Wednesday, July 10, 2013 3:10 PM To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all= @tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Eric, You may want to copy the "oc-algo" line from other I-D. James From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] Sent: Wednesday, July 10, 2013 1:10 PM To: Yu, James Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all= @tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, Based on your suggestion and comments from other reviewers, I intend to upd= ate section 5 (syntax) as follows: oc =3D "oc" [EQUAL oc-num] oc-num =3D 1*DIGIT algo-list =3D "loss" / "rate" / *(other-algo) other-algo =3D %x41-5A / %x61-7A / %x30-39 I understand there may be an additional change following Henning's reply. 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: Yu, James [mailto:james.yu@neustar.biz] Sent: Wednesday, July 10, 2013 11:36 AM To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Eric, Yes, this adds "rate" to "oc-algo" parameter but please check with IANA to = see if it is the correct way. You also need to copy some syntax lines from= the draft-ietf-soc-overload-control to show algo-list =3D "loss" / "rate" / *(other-algo) I've an email to Henning asking if algo-list in his I-D should be algo-list =3D "loss" / other-algo If yes, then this particular line in your I-D would be algo-list =3D "loss" / "rate" / other-algo James From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] Sent: Wednesday, July 10, 2013 10:49 AM To: Yu, James Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, Thank you for your suggestion. Not being familiar with IANA procedure, would updating draft-ietf-soc-overl= oad-rate-control section 7 (IANA considerations) as follows work? This specification defines a new value for Via header parameter oc-algo as = detailed below in the "Header Field Parameter and Parameter Values" subregi= stry as per the registry created by [RFC3968]. The required information is: Header Field Parameter Name Predefined Val= ues Reference ---------------------------------------------------------------------------= ------------------------------- Via oc-algo = "rate" RFCXXXX RFC XXXX [NOTE TO RFC-EDITOR: Please replace with final RFC number of this = specification.] 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: Yu, James [mailto:james.yu@neustar.biz] Sent: Wednesday, July 10, 2013 10:17 AM To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Noel, I forgot to respond to your reply about the IANA registration of "rate" in = oc-algo. I see that draft-ietf-soc-overload-control-13 mentions your I-D b= ut does not have "rate" in algo-list. There are two possible ways to address "rate" in algo-list. One is to have= draft-ietf-soc-overload-control-13 add "rate" to algo-list and refer to yo= ur I-D for details. The other is to register "rate" in algo-list with IANA= in your I-D, and this should be a simple task. The cleaner way that is mo= re inline with the IETF process would be the latter. It seems odd to have = something defined in a RFC without details about it, and it would be too mu= ch trouble to combine the two I-Ds. James From: Yu, James Sent: Wednesday, July 10, 2013 9:01 AM To: 'NOEL, ERIC C (ERIC C)' Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Noel, I mentioned in my message to Janet on 7/2: For the rate control, the server could calculate the arrival rate from each= communicating client so that it could allocate the overall target SIP requ= est rate to the clients based on their arrival rates known to the server. = But another option is for the client to "optionally" include its calculated= arrival rate in its request to the server when rate control related parame= ters are present. Should this option be evaluated/included to relieve the = server from doing the arrival rate calculations. This would be beneficial = to a server when it receives the requests from many clients. I suggest that the I-D adds that option to allow the client to indicate its= current arrival rate (towards the receiving server) in the SIP request. James From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] Sent: Tuesday, July 09, 2013 4:44 PM To: Yu, James; Janet P Gunn Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Janet, James, Thanks you for your valuable comments and discussion. I tried to capture a= ll resolution in the following text (based on James word document with trac= k changes and imbedded comments enabled). + Abstract section: - Agreed with suggested changes - Please note I will also need to make further changes to remove all refere= nces per Christer Holmberg comment + Section 1: - Agreed with suggested changes + Section 3.1: - Agreed with suggested changes + Section 3.2: - Please note the section title will become "Via header fiel= d parameters for overload control " per Christer Holmberg comment - Agreed with suggested changes excluding title that will change per previo= us bullet + Section 3.3: - Agreed with suggested changes + Section 3.4: - ID: "Note that the target SIP request rate is a max rate that may not be= attained by the arrival rate at the client, and the server cannot assume t= hat it will." [JY] Not clear what value this paragraph tries to add. Is it saying tha= t the client's arrival rate may be lower than the target SIP request rate? [JG] Yes + supporting example (see below in thread) Agreed with Janet and supporting example. Per James request, I will add t= he following text (inspired from Janet's illustrative example): "In other words, when multiple clients are being controlled by an overlo= aded server, at any given time some clients may receive requests at a rate = below its target SIP request rate while others above that target rate. But = the resulting request rate presented to the overloaded server will converge= towards the target SIP request rate." - Agreed with other suggested changes + Section 3.5.1: - ID: "And the larger the difference between TAU1 and TAU2, the closer to t= he control is to strict priority." [JY] Suggest changing into "And the larger the difference between TAU1 an= d TAU2, the closer the control is to strict priority queuing." [JG] Suggest changing into "And the larger the difference between TAU1 an= d TAU2, the closer the control is to strict priority treatment." [EN] Agreed with Janet's suggestion - Agreed with other suggested changes + Section 4: - Agreed with suggested changes + Section 5: - Please note that based comments from per Christer Holmberg and Janet Gunn= , the following was tentatively agreed Replace oc-value =3D "NaN" / oc-num by oc =3D "oc" [EQUAL oc-num] - Agreed with other suggested change + Section 7: - [JY] Should "rate" in oc-algo be registered with IANA? This issue needs to be addressed by draft-ietf-soc-overload-control autho= rs Please note I will wait until expiration of WGLC prior updating our draft R= FC. Once again your comments and/or suggestions are most appreciated. 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 Yu, James Sent: Tuesday, July 02, 2013 9:42 AM To: Janet P Gunn Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Janet, For my comment on section 3.4 (the first one below), the current text does = not provide any value. The client's arrival rate could be well below the t= arget SIP request rate when its load is light so the fact that the client m= ay not achieve the target SIP request rate (the max. rate it is allowed to = send to the server) is well understood. But with your explanation on the "= delta" part, the text then makes sense. Please add some discussions on the= "delta" aspect so that even if the average arrival rate at the client is h= igher than the target SIP request rate the client at times may not send mor= e than what the target SIP request rate allows due to the fluctuation of th= e arriving requests at the client. For the comment on section 3.5.1, I agree with your proposed change. For the rate control, the server could calculate the arrival rate from each= communicating client so that it could allocate the overall target SIP requ= est rate to the clients based on their arrival rates known to the server. = But another option is for the client to "optionally" include its calculated= arrival rate in its request to the server when rate control related parame= ters are present. Should this option be evaluated/included to relieve the = server from doing the arrival rate calculations. This would be beneficial = to a server when it receives the requests from many clients. James From: Janet P Gunn [mailto:jgunn6@csc.com] Sent: Friday, June 28, 2013 3:34 PM To: Yu, James Cc: draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org; sip-overload-bounces@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, It is a little hard to respond in email when your comments are in a separat= e document, but here goes. section 3.4 ID says: "Note that the target SIP request rate is a max rate that may not be attained by the arrival rate at the client, and the server cannot assume that it will." Your comment : "Not clear what value this paragraph tries to add. Is it saying that the c= lient's arrival rate may be lower than the target SIP request rate? " Yes. Suppose the server want to limit the total rate of arriving SIP messages to= 100 / sec, and has 10 clients. Each client has a high variance in its mes= sage rate, but together they are well above 100 messages per sec If it sets the rate at 10 messages per second for each of the clients, it w= ill almost certainly end up with an overall average of less than 100 messa= ges per sec, because some clients will be in a "lull" while others are busy= . This is good from a throttling perspective, but, assuming messages are c= orrelated with revenue, bad/wasteful from a revenue, or overall productivit= y perspective. So the server might want to set the rate per client to 10 += delta, where delta is going to be very specific to operating environment. --- In section 3.5.1, bottom of page 8 ID says: "And the larger the difference between TAU1 and TAU2, the closer to the control is to strict priority." You propose changing it to: "And the larger the difference between TAU1 and TAU2, the closer the control is to strict priority queuing." I agree with taking out the redundant "to". But I disagree wit adding "que= uing". There is no queuing, priority or otherwise involved. You could say: "And the larger the difference between TAU1 and TAU2, the closer the control is to strict priority treatment." where " strict priority treatment" would refer to the case where non-priori= ty messages are restricted to a total (priority + non-priority) rate of 10 = messages per second, but priority messages can continue to be sent as long = as the total (priority + non-priority) rate is less than 12 messages per se= cond. At least, I think that is what Eric and Philip are trying to say. 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: "Yu, James" = > To: "sip-overload-bounces@ietf.org" >= , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" >, "sip-overload@ietf.org"= > Date: 06/28/2013 08:10 AM Subject: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Sent by: sip-overload-bounces@ietf.org ________________________________ Salvatore, Please see the attachment for my comments. I pasted the text to a word document to trace/show the proposed changes and= comments. Regards, James [attachment "comments on draft-ietf-soc-overload-rate-control-04.docx" del= eted by Janet P Gunn/USA/CSC] _____________________________________________= __ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6452 - Release Date: 06/30/13 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13 --_000_949EF20990823C4C85C18D59AA11AD8B068238FR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

2 additions.<= /p>

 

For /=3D read =3D/

 

For adding the new parameters to the V= ia header field, draft-ietf-soc-overload control should also use =3D/ (it i= s not a problem of rate control to fix this issue.

 

Keith

 

From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith)
Sent: 10 July 2013 23:05
To: NOEL, ERIC C (ERIC C); '= Yu, James'
Cc: sip-overload-bounces@iet= f.org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overloa= d@ietf.org
Subject: Re: [sip-overload] = draft-ietf-soc-overload-rate-control-04.txt

 

I’ve lost track of what is happe= ning here. What I expect is two things:

 

1)      =    IANA registration impact.

 

For the header field parameters regist= ry, draft-ietf-soc-overload-control already creates the new rows:

 

       Header Field  Parameter Name&nbs=
p; Predefined Values  Reference
       _____________________________________=
_____________________
       Via     &nbs=
p;     oc       &nbs=
p;         Yes   &nb=
sp;         RFCXXXX
       Via     &nbs=
p;     oc-validity      &=
nbsp; Yes           =
  RFCXXXX
       Via     &nbs=
p;     oc-seq       =
      Yes       =
;      RFCXXXX
       Via     &nbs=
p;     oc-algo       =
;     Yes       &nbs=
p;     RFCXXXX
 
       RFC XXXX [NOTE TO RFC-EDITOR: Please =
replace with final RFC
       number of this specification.]

 

For the predefined values columns, RFC= 3968 states:

 

   Some SIP header field parameters only accept a set of predefi=
ned
   parameter values.  For example, a parameter indicating t=
he transport
   protocol in use may only accept the predefined tokens TCP, UDP, and
   SCTP as valid values.  Registering all parameter values =
for all SIP
   header field parameters of this type would require a large nu=
mber of
   subregistries.  Instead, we have chosen to register para=
meter values
   by reference.  That is, the entry in the parameter regis=
try for a
   given header field parameter contains references to the RFCs =
defining
   new values of the parameter.  References to RFCs definin=
g parameter
   values appear in double brackets in the registry.<=
/span>
 
   So, the header field parameter registry contains a column tha=
t
   indicates whether or not each parameter only accepts a set of=

   predefined values.  Implementers of parameters with a &q=
uot;yes" in that
   column need to find all the valid parameter values in the RFC=
s
   provided as references.

 

With this understanding, I do not beli= eve the rate-control draft needs to modify the “predefined valuesR= 21; column. What it does need to do is add its ultimate RFC number to the reference column.

 

There could be an argument that there = needs to be a new table that lists the algorithm values, but

 

a) &= nbsp;           &nbs= p; if such a table is to be created, it needs to be created by draft-ietf-= soc-overload-control rather than the rate-control draft/

b) &= nbsp;           &nbs= p; I personally do not think it is necessary to add such a new table, as I= think the references are sufficient. One cannot handle the algorithm values unless one goes to the relevant RFC.

 

2)      =    ABNF impact.

 

ABNF defines the /=3D operator for add= ing new values to an existing defined list.

 

I do not think we should reproduce exi= sting ABNF from draft-ietf-soc-overload-control and then amend it.

 

The reason for this is that tools exis= t for automatically extracting the ABNF from RFCs. An extracted

 

= algo-list /=3D “rate“

 

will work perfectly well with the extr= act from draft-ietf-soc-overload-control (and from SIP). Reproducing produc= tions will result in conflict.

 

Regards

 

Keith

 

From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] On Behalf Of NOEL, ERIC C (ERIC C)
Sent: 10 July 2013 20:54
To: 'Yu, James'
Cc: sip-overload-bounces@iet= f.org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overloa= d@ietf.org
Subject: Re: [sip-overload] = draft-ietf-soc-overload-rate-control-04.txt

 

= James,

=  

= So section 5 (syntax) will include the following statements:

=  

= oc =3D “oc” [EQUAL oc-num]

= oc-num =3D 1*DIGIT

= oc-algo =3D "oc-algo" EQUAL DQUOTE algo-list *(COMMA algo-= list) DQUOTE

= algo-list =3D “loss” / “rate“ / *(other-algo= )

= other-algo =3D %x41-5A / %x61-7A / %x30-39<= /p>

=  

= 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.4= 174

= = ecnoel@att.com

=  

From: Yu, James [mailto:james.yu@neustar.biz]
Sent: Wednesday, July 10, 2013 3:= 10 PM
To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@iet= f.org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overloa= d@ietf.org
Subject: RE: [sip-overload] = draft-ietf-soc-overload-rate-control-04.txt

 

Eric,

= You may want to copy the “oc-algo” line from other I-D.<= o:p>

=  

= James

=  

From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com]
Sent: Wednesday, July 10, 2013 1:= 10 PM
To: Yu, James
Cc: sip-overload-bounces@iet= f.org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overloa= d@ietf.org
Subject: RE: [sip-overload] = draft-ietf-soc-overload-rate-control-04.txt

 

= James,

=  

= Based on your suggestion and comments from other reviewers, I intend= to update section 5 (syntax) as follows:

=  

= oc =3D “oc” [EQUAL oc-num]

= oc-num =3D 1*DIGIT

=  

= algo-list =3D “loss” / “rate“ / *(other-algo= )

= other-algo =3D %x41-5A / %x61-7A / %x30-39<= /p>

=  

= I understand there may be an additional change following HenningR= 17;s reply.

=  

= 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.4= 174

= = ecnoel@att.com

=  

From: Yu, James [mailto:james.yu@neustar.biz] =
Sent: Wednesday, July 10, 2013 11= :36 AM
To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload] = draft-ietf-soc-overload-rate-control-04.txt

 

= Eric,

=  

= Yes, this adds “rate” to “oc-algo” parameter= but please check with IANA to see if it is the correct way.  You also need to copy some syntax lines from the draft-ietf-soc-overload-control to= show

=  

=      algo-list   =3D &#= 8220;= loss“ / “rate“ / *(other-algo)

=  

= I’ve an email to Henning asking if algo-list in his I-D should= be

=      algo-list   =3D “loss“ / other-algo

=  

= If yes, then this particular line in your I-D would be

=      algo-list &n= bsp; =3D “loss“ / “rate“ / other-algo

=  

= James

=  

From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@resea= rch.att.com]
Sent: Wednesday, July 10, 2013 10= :49 AM
To: Yu, James
Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload] = draft-ietf-soc-overload-rate-control-04.txt

 

= James,

=  

= Thank you for your suggestion.

=  

= Not being familiar with IANA procedure, would updating draft-ietf-so= c-overload-rate-control section 7 (IANA considerations) as follows work?

=  

= This specification defines a new value for Via header parameter oc-a= lgo as detailed below in the "Header Field Parameter and Parameter Values" subregistry as per the registry created by [RFC= 3968]. The required information is:

=  

= Header Field          &= nbsp;Parameter Name          &= nbsp;           &nbs= p; Predefined Values         &= nbsp;          Reference<= o:p>

= --------------------------------------------------------------------= --------------------------------------

= Via           &nbs= p;            &= nbsp;     oc-algo      &n= bsp;            = ;            &n= bsp;            = ;  “rate”       &n= bsp;            = ;                         RF= CXXXX

=  

= RFC XXXX [NOTE TO RFC-EDITOR: Please replace with final RFC number o= f this specification.]

=  

= 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.4= 174

= = ecnoel@att.com

=  

From: Yu, James [mailto:james.yu@neustar.biz] =
Sent: Wednesday, July 10, 2013 10= :17 AM
To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload] = draft-ietf-soc-overload-rate-control-04.txt

 

= Noel,

=  

= I forgot to respond to your reply about the IANA registration of = 220;rate” in oc-algo.  I see that draft-ietf-soc-overload-contro= l-13 mentions your I-D but does not have “rate” in algo-list.<= /o:p>

=  

= There are two possible ways to address “rate” in algo-li= st.  One is to have draft-ietf-soc-overload-control-13 add “rate” to algo-list and refer to your I-D for details.  T= he other is to register “rate” in algo-list with IANA in your I= -D, and this should be a simple task.  The cleaner way that is more in= line with the IETF process would be the latter.  It seems odd to have something defined in a RFC without details about it, and it would be too m= uch trouble to combine the two I-Ds.

=  

= James

=  

From: Yu, James
Sent: Wednesday, July 10, 2013 9:0= 1 AM
To: 'NOEL, ERIC C (ERIC C)'<= br> Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload] = draft-ietf-soc-overload-rate-control-04.txt

 

= Noel,

=  

= I mentioned in my message to Janet on 7/2:<= /p>

=  

For the rate control, the server could calculate the arrival r= ate from each communicating client so that it could allocate the overall target SIP request rate to th= e clients based on their arrival rates known to the server.  But anoth= er option is for the client to “optionally” include its calcula= ted arrival rate in its request to the server when rate control related parameters are present.  Should this option be e= valuated/included to relieve the server from doing the arrival rate calcula= tions.  This would be beneficial to a server when it receives the requ= ests from many clients.

=  

= I suggest that the I-D adds that option to allow the client to indic= ate its current arrival rate (towards the receiving server) in the SIP request.

=  

= James

=  

From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@resea= rch.att.com]
Sent: Tuesday, July 09, 2013 4:= 44 PM
To: Yu, James; Janet P Gunn<= br> Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload] = draft-ietf-soc-overload-rate-control-04.txt

 

= Janet, James,

=  

= Thanks you for your valuable comments and discussion.  I tried = to capture all resolution in the following text (based on James word document with track changes and imbedded comments enabled).<= o:p>

=  

= + Abstract section:

= - Agreed with suggested changes

= - Please note I will also need to make further changes to remove all= references per Christer Holmberg comment

=  

= + Section 1:

= - Agreed with suggested changes

=  

= + Section 3.1:

= - Agreed with suggested changes

=  

= + Section 3.2: - Please note the section title will become ̶= 0;Via header field parameters for overload control “ per Christer Holmberg comment

= - Agreed with suggested changes excluding title that will change per= previous bullet

=  

= + Section 3.3:

= - Agreed with suggested changes

=  

= + Section 3.4:

= - ID:  "Note that the target SIP request rate is a max rat= e that may not be attained by the arrival rate at the client, and the server cannot assume that it will."

=    [JY] Not clear what value this paragraph tries to = add.  Is it saying that the client's arrival rate may be lower than the target SIP request rate?

=    [JG] Yes + supporting example (see below in th= read)

=   Agreed with Janet and supporting example. Per James requ= est, I will add the following text (inspired from Janet’s illustrative example):

=    “In other words, when multiple clients are being = controlled by an overloaded server, at any given time some clients may receive requests at a rate below its target SIP request rate while oth= ers above that target rate. But the resulting request rate presented to the= overloaded server will converge towards the target SIP request rate.”= ;

= - Agreed with other suggested changes

=      

= + Section 3.5.1:

= - ID: “And the larger the difference between TAU1 and TAU2, th= e closer to the control is to strict priority.”

=   [JY] Suggest changing into “And the larger the differen= ce between TAU1 and TAU2, the closer the control is to strict priority queuing.”

=   [JG] Suggest changing into “And the larger the differen= ce between TAU1 and TAU2, the closer the control is to strict priority treatment.”

=   [EN] Agreed with Janet’s suggestion

= - Agreed with other suggested changes

=  

= + Section 4:

= - Agreed with suggested changes

=  

= + Section 5:

= - Please note that based comments from per Christer Holmberg and Jan= et Gunn, the following was tentatively agreed

=    Replace oc-value =3D "= NaN" / oc-num    by    oc = =3D "oc" [EQUAL oc-num]

= - Agreed with other suggested change

=  

= + Section 7:

= - [JY] Should “rate” in oc-algo be registered with IANA?=

=   This issue needs to be addressed by draft-ietf-soc-overload-c= ontrol authors

=  

= Please note I will wait until expiration of WGLC prior updating our = draft RFC. Once again your comments and/or suggestions are most appreciated.

=  

= 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.4= 174

= = ecnoel@att.com

=  

From: sip-overload-bounces@ietf.= org [mailto:sip-overlo= ad-bounces@ietf.org] On Behalf Of Yu, James
Sent: Tuesday, July 02, 2013 9:4= 2 AM
To: Janet P Gunn
Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: Re: [sip-overload] = draft-ietf-soc-overload-rate-control-04.txt

 

= Janet,

=  

= For my comment on section 3.4 (the first one below), the current tex= t does not provide any value.  The client’s arrival rate could be well below the target SIP request rate when its load= is light so the fact that the client may not achieve the target SIP reques= t rate (the max. rate it is allowed to send to the server) is well understo= od.  But with your explanation on the “delta” part, the text then makes sense.  Please add = some discussions on the “delta” aspect so that even if the aver= age arrival rate at the client is higher than the target SIP request rate t= he client at times may not send more than what the target SIP request rate allows due to the fluctuation of the arriving requests at the= client.

=  

= For the comment on section 3.5.1, I agree with your proposed change.=

=  

= For the rate control, the server could calculate the arrival rate fr= om each communicating client so that it could allocate the overall target SIP request rate to the clients based on their= arrival rates known to the server.  But another option is for the cli= ent to “optionally” include its calculated arrival rate in its = request to the server when rate control related parameters are present.  Should this option be evaluated/included to relieve the= server from doing the arrival rate calculations.  This would be benef= icial to a server when it receives the requests from many clients.

=  

= James

=  

From: Janet P Gunn [mailto:jgunn6@csc.com]
Sent: Friday, June 28, 2013 3:= 34 PM
To: Yu, James
Cc: draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org; sip-overload-bounces@ietf.org
Subject: Re: [sip-overload] = draft-ietf-soc-overload-rate-control-04.txt

 

James,

It is a little hard to respond in email when your commen= ts are in a separate document, but here goes.


section 3.4
ID says:
"Note that the target SIP request rate is a max rat= e that may not be
   attained by the arrival rate at the client,= and the server cannot
   assume that it will."

Your comment :
"Not clear what value this paragraph tries to add. =  Is it saying that the client's arrival rate may be lower than the tar= get SIP request rate?  "

Yes.

Suppose the server want to limit the total rate of arriv= ing SIP messages to 100 / sec, and has 10 clients.  Each client has a = high variance in its message rate, but together they are well above 100 messages per sec

If it sets the rate at 10 messages per second for each o= f the clients, it will almost certainly end up  with an overall averag= e of less than 100 messages per sec, because some clients will be in a "lull" while others are b= usy.  This is good from a throttling perspective, but, assuming messag= es are correlated with revenue, bad/wasteful from a revenue, or overall pro= ductivity perspective.  So the server might want to set the rate per client to 10 + delta, where delta is going to be v= ery specific to operating environment.

---
In section  3.5.1, bottom of page 8
ID says:
"And the larger
   the difference between TAU1 and TAU2, the c= loser to the control is
   to strict priority."

You propose changing it to:
"And the larger
   the difference between TAU1 and TAU2, the c= loser  the control is
   to strict priority queuing."

I agree with taking out the redundant "to". &n= bsp;But I disagree wit adding "queuing".  There is no queuin= g, priority or otherwise involved.

You could say:
"And the larger
   the difference between TAU1 and TAU2, the c= loser  the control is
   to strict priority treatment."

where " strict priority treatment" would refer= to the case where non-priority messages are restricted to a total (priorit= y + non-priority) rate of 10 messages per second, but priority messages can continue to be sent as long as the t= otal (priority + non-priority) rate is less than 12 messages per second= .

At least, I think that is what Eric and  Philip are= trying to say.

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 co= ntract unless pursuant to explicit written agreement or government initiati= ve expressly permitting the use of e-mail for such purpose.



From:   &= nbsp;    "Yu, James"= ; <james.yu@neustar.biz><= /span>
To:   &nb= sp;    "sip-overload-bounces@ietf.org" <sip-overload-bounces@= ietf.org>, "draft-ietf-soc-overload-rate-control.all@tools.ietf= .org" <draft-ietf-soc-overload-rate-control.all@tools.ietf.org<= /a>>, "sip-overload@ietf.org&q= uot; <sip-overload@ietf.org= >
Date:   &= nbsp;    06/28/2013 08:10 AM
Subject:  = ;      [sip-overload] draft-ietf-soc-overload-rate-control-04.txt
Sent by:  = ;      sip-overload-bounces@ietf.org




Salvatore,
 
Please see the attachment for my comments.
 
I pasted the text to a word document to trace/show the= proposed changes and comments.
 
Regards,
 
James
 [attachment "comments on draft-ietf-soc-ove= rload-rate-control-04.docx" deleted by Janet P Gunn/USA/CSC] ______________________________________________= _
sip-overload mailing list
sip= -overload@ietf.org
https://www.ietf.org/mailman/listinfo/sip-overload

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 3204/6452 - Release Date: 06/30/13

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13

--_000_949EF20990823C4C85C18D59AA11AD8B068238FR712WXCHMBA11zeu_-- From keith.drage@alcatel-lucent.com Wed Jul 10 18:30: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 A172521F8A03 for ; Wed, 10 Jul 2013 18:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aNSPGhEk-Td for ; Wed, 10 Jul 2013 18:30:34 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id F0DA321F8925 for ; Wed, 10 Jul 2013 18:30:33 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r6B1UEXJ018415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 10 Jul 2013 20:30:16 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6B1UE1x010849 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Jul 2013 03:30:14 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Thu, 11 Jul 2013 03:30:14 +0200 From: "DRAGE, Keith (Keith)" To: "NOEL, ERIC C (ERIC C)" , "'Paul Kyzivat'" Thread-Topic: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - Christer's comments Thread-Index: Ac5zweEAF4KSgJ2oQr+eAJpjbv955QABR1ggAACFppAADhfAgAAJKZARAf9sBAAAbHgS4A== Date: Thu, 11 Jul 2013 01:30:13 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0683F9@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B1C3BD16D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C3BD239@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C3BD25A@ESESSMB209.ericsson.se> <51CDA863.6030802@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B062B74@FR712WXCHMBA11.zeu.alcatel-lucent.com> <51CDC9B4.306@alum.mit.edu> <5EBD159DE88147488A3B1590E09001840353BDA4CAC0@njfpsrvexg2.research.att.com> In-Reply-To: <5EBD159DE88147488A3B1590E09001840353BDA4CAC0@njfpsrvexg2.research.att.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "sip-overload@ietf.org" , "Gurbani, Vijay K \(Vijay\)" , "Hilt, Volker \(Volker\)" Subject: Re: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - Christer's comments 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, 11 Jul 2013 01:30:39 -0000 I think here you have a strange definition of authoritative, which is confu= sing the issue. By my definition at least, the authoritative source for all IANA material i= s the RFCs or other material cited to create the IANA registration. In my v= iew IANA is not authoritative because it is a secondary source. Apart from that I think our only difference is whether extending the ABNF c= reates an update of the original RFC or not. As I have indicated before, I = don't believe it does, but we do need the requirements that do the extensio= n in the rate-control draft, whether that makes it an update or not. We hav= en't as far as I know entered that discussion for this particular issue. Regards Keith > -----Original Message----- > From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] > Sent: 09 July 2013 00:41 > To: 'Paul Kyzivat'; DRAGE, Keith (Keith) > Cc: sip-overload@ietf.org; Hilt, Volker (Volker); Gurbani, Vijay K (Vijay= ) > Subject: RE: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - > Christer's comments >=20 > Keith, Paul, >=20 > I will also defer this comment to draft-ietf-soc-overload-control authors > and comply with the resolution. >=20 > Thanks, >=20 > Eric Noel > AT&T Labs, Inc. > Rethink Possible >=20 > Network Design and Performance Analysis > 200 South Laurel Avenue, D5-3D19 > Middletown, NJ 07748 > P: 732.420.4174 > ecnoel@att.com >=20 >=20 > -----Original Message----- > From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org= ] > On Behalf Of Paul Kyzivat > Sent: Friday, June 28, 2013 1:37 PM > To: DRAGE, Keith (Keith) > Cc: sip-overload@ietf.org > Subject: Re: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - > Christer's comments >=20 > Sorry to inflict this on the SOC wg, who probably just want to be told > what to do. But this is not settled ground. >=20 > On 6/28/13 12:46 PM, DRAGE, Keith (Keith) wrote: > > Nowhere in RFC 3968 does it say that. >=20 > By "that" I presume you mean "3261 is no longer authoritative for header > field parameters"? >=20 > > I agreed that what RFC 3968 does is ensure that new header field > parameters have to be registered, and therefore an IANA registration > section is required in this i-d to accomplish this. IANA registrations > should be correct, but they are never "authorative". >=20 > I agree with you. Before 3968 there was no registry. >=20 > And while 3261 makes provision for parameters defined in the future via > "generic-param", it doesn't say what the rules for defining new ones are. > If you just infer from the names, then for Via the hook is called "via- > extension". So I would be inclined to infer that it intended that an > extension to 3261 was required. >=20 > Then a convention grew up where such extensions did so by redefining the > 3261 ABNF (e.g., 'via-params =3D/ ...') in a normative extension to 3261. >=20 > So at that time, to obtain an exhaustive list of header parameters, you > could search 3261 and all declared extensions to it for syntax definition= s > of header field parameters. >=20 > RFC 3968 changed this by introducing a registry, and by saying that to ad= d > a new parameter you needed an RFC, but that it didn't need to be standard= s > track. I *think* that also means it doesn't need to be declared as an > *extension* to 3261. And so searching 3261 and extensions is no longer a > sufficient mechanism to find all defined header field params. >=20 > > However the defining i-d / RFC is still the normative specification of > that parameter. If ABNF is the easiest way of defining this, then so be i= t. >=20 > Agreed that ABNF is not required. But it must be clear. > And since this is intended to coordinate with the rest of sip that is > defined by ABNF, it is strongly recommended. If it isn't, then some of us= e > will probably complain if/when we notice. >=20 > > Adding a header field parameter has never required the defining i-d / > RFC to update RFC 3261, assuming the underlying RFC 3261 ABNF was > extendable in the first place. >=20 > The IANA registry is an authoritative list of all legitimate header field > parameters. >=20 > I agree that the registry is not authoritative for the definitions > themselves. The drafts containing those definitions, referenced by the > registry, provide the actual authoritative definitions of the parameters. >=20 > The IANA registry is the only IETF supported way to discover *all* define= d > header field parameters other than reading each and every RFC. >=20 > Thanks, > Paul >=20 > > Regards > > > > Keith > > > >> -----Original Message----- > >> From: sip-overload-bounces@ietf.org > >> [mailto:sip-overload-bounces@ietf.org] > >> On Behalf Of Paul Kyzivat > >> Sent: 28 June 2013 16:15 > >> To: sip-overload@ietf.org > >> Subject: Re: [sip-overload] WGLC: > >> draft-ietf-soc-overload-rate-control - Christer's comments > >> > >> Sorry, I haven't been following the progress of this draft for a long > >> time, but this just caught my eye... > >> > >> The ABNF of 3261 is no longer authoritative for header field parameter= s. > >> This was changed by RFC3968. Now these are registered in the "Header > >> Field Parameters and Parameter Values" sub-registry of the IANA > >> "Session Initiation Protocol (SIP) Parameters" registry. > >> > >> So you need an IANA considerations section that provides the info in > >> the form called out in Section 4.1 of RFC3968. > >> > >> There is some debate if need, or even if it is good to provide ABNF > >> extension syntax relative to 3261. IMO it is sufficient for you to > >> register the parameter in IANA and define the syntax of the parameter > >> *value* using ABNF. > >> > >> Done that way, IMO the draft doesn't technically extend 3261, but > >> that point has also been debated. > >> > >> If you want to reuse EQUAL and DIGIT from 3261 then you should > >> probably say so, though if you are formally extending 3261 via =3D/ > >> then of course you are implicitly inheriting everything defined in 326= 1. > >> > >> Thanks, > >> Paul > >> > >> > >> On 6/28/13 2:32 AM, Christer Holmberg wrote: > >>> The following is obviously not needed in draft-ietf-soc-overload- > >> control: > >>> > >>> "EQUAL" is defined in RFC 3261. "DIGIT" is defined in RFC 5234. > >>> > >>> *From:*sip-overload-bounces@ietf.org > >>> [mailto:sip-overload-bounces@ietf.org] *On Behalf Of *Christer > >>> Holmberg > >>> *Sent:* 28. kes=E4kuuta 2013 9:27 > >>> *To:* Janet P Gunn > >>> *Cc:* sip-overload-bounces@ietf.org; > >>> draft-ietf-soc-overload-rate-control.all@tools.ietf.org; > >>> sip-overload@ietf.org > >>> *Subject:* Re: [sip-overload] WGLC: > >>> draft-ietf-soc-overload-rate-control > >>> - Christer's comments > >>> > >>> Hi, > >>> > >>> So, with the third alternative, Section 5 would look something like: > >>> > >>> 5. Syntax > >>> > >>> This specification extends the existing definition of the Via > >>> header > >>> > >>> field parameters of [RFC3261] as follows: > >>> > >>> via-params =3D/ oc-nan > >>> > >>> oc-nan =3D "NaN" > >>> > >>> BTW, I think the syntax in *draft-ietf-soc-overload-control *should > >>> look > >>> like: > >>> > >>> ***via-params =3D/ oc / oc-validity / oc-seq / oc-algo* > >>> > >>> oc =3D "oc" [EQUAL oc-num] > >>> > >>> oc-num =3D 1*DIGIT > >>> > >>> oc-validity =3D "oc-validity" [EQUAL delta-ms] > >>> > >>> oc-seq =3D "oc-seq" EQUAL 1*12DIGIT "." 1*5DIGIT > >>> > >>> oc-algo =3D "oc-algo" EQUAL DQUOTE algo-list *(COMMA alg= o- > >> list) > >>> > >>> DQUOTE > >>> > >>> algo-list =3D "loss" / *(other-algo) > >>> > >>> other-algo =3D %x41-5A / %x61-7A / %x30-39 > >>> > >>> delta-ms =3D 1*DIGIT > >>> > >>> ** > >>> > >>> In both drafts, I would also suggest to rewrite the Syntax sections > >>> in the following way: > >>> > >>> 5. Grammar > >>> > >>> 5.1. General > >>> > >>> This section extends the ABNF definition of via-params from > >> [RFC3261] > >>> > >>> by adding a new Via header field parameter, "oc-nan". The ABNF > >> defined > >>> > >>> in this specification is conformant to RFC 5234 [RFC5234]. > "EQUAL" > >>> > >>> is defined in RFC 3261. "DIGIT" is defined in RFC 5234. > >>> > >>> 5.2. ABNF > >>> > >>> via-params =3D/ oc-nan > >>> > >>> oc-nan =3D "NaN" > >>> > >>> ** > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> ** > >>> > >>> ** > >>> > >>> ** > >>> > >>> *From:*Christer Holmberg > >>> *Sent:* 28. kes=E4kuuta 2013 8:40 > >>> *To:* Christer Holmberg; Janet P Gunn > >>> *Cc:* sip-overload-bounces@ietf.org > >>> ; > >>> draft-ietf-soc-overload-rate-control.all@tools.ietf.org > >>> ; > >>> sip-overload@ietf.org > >>> *Subject:* VS: [sip-overload] WGLC: > >>> draft-ietf-soc-overload-rate-control > >>> - Christer's comments > >>> > >>> Hi, > >>> > >>> A *third alternative* (probably the easiest one, at least from a > >>> syntax > >>> perspective) would be to simply define a new "oc-nan" Via header > >>> field parameter. > >>> > >>> *oc-nan =3D "nan"* > >>> > >>> .or something like that. > >>> > >>> It would *not* require any changes to draft-ietf-soc-overload-control= . > >>> > >>> (Then, in the *procedure sections* you need to describe how/whether > >>> the oc and oc-nan parameters can be used at the same time etc, but > >>> that is not a syntax question.) > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> *L=E4hett=E4j=E4:*sip-overload-bounces@ietf.org > >>> [mailto:sip-overload- > >> bounces@ietf.org] > >>> *Puolesta *Christer Holmberg > >>> *L=E4hetetty:* 27. kes=E4kuuta 2013 22:42 > >>> *Vastaanottaja:* Janet P Gunn > >>> *Kopio:* sip-overload-bounces@ietf.org > >>> ; > >>> draft-ietf-soc-overload-rate-control.all@tools.ietf.org > >>> ; > >>> sip-overload@ietf.org > >>> *Aihe:* Re: [sip-overload] WGLC: > >>> draft-ietf-soc-overload-rate-control - Christer's comments > >>> > >>> Hi, > >>> > >>> When taking a closer look, I actually think there is something > >>> technically wrong with the syntax in Section 5 of > >>> draft-ietf-soc-overload-rate-control. > >>> > >>> *draft-ietf-soc-overload-control * defines the oc parameter as: > >>> > >>> *oc =3D "oc" [EQUAL oc-num]* > >>> > >>> Now, it seems like *draft-ietf-soc-overload-rate-control* actually > >>> *re-defines *the *same parameter*. In addition, it's done in a > >>> backward compatible manner, e.g. because the parameter can now > >>> contain a non-numeric value (see the bullet list below what can go > wrong): > >>> > >>> *oc =3D "oc" EQUAL oc-value* > >>> > >>> The following can happen: > >>> > >>> 1.If an entity that supports draft-ietf-soc-overload-control > >>> receives > >>> *"oc=3DNaN"* it will *reject* it, as it expects a numeric value. > >>> > >>> 2.If an entity that supports draft-ietf-soc-overload-rate-control > >>> receives *"oc"* it will *reject* it, as it expects an oc-value. But, > >>> in draft-ietf-soc-overload-control the usage of oc-value is optional= . > >>> > >>> One way to fix this could be to define oc-value as a separate Via > >>> header field parameter (similar to oc-validity, oc-seq etc), instead > >>> of a value of the oc parameter. But, then you would have oc-num > >>> > >>> Another way is to change the syntax in > >>> draft-ietf-soc-overload-control , in order to allow what you want to > >>> do in draft-ietf-soc-overload-rate-control. > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> *L=E4hett=E4j=E4:*Janet P Gunn [mailto:jgunn6@csc.com] > >>> *L=E4hetetty:* 27. kes=E4kuuta 2013 22:04 > >>> *Vastaanottaja:* Christer Holmberg > >>> *Kopio:* draft-ietf-soc-overload-rate-control.all@tools.ietf.org > >>> ; > >>> sip-overload@ietf.org ; > >>> sip-overload-bounces@ietf.org > >>> *Aihe:* Re: VS: [sip-overload] WGLC: > >>> draft-ietf-soc-overload-rate-control - Christer's comments > >>> > >>> Christer > >>> > >>> draft-ietf-soc-overload-control says " 8. Syntax > >>> > >>> This specification extends the existing definition of the Via > header > >>> field parameters of [RFC3261] as follows: > >>> > >>> via-params =3D via-ttl / via-maddr > >>> / via-received / via-branch > >>> / oc / oc-validity > >>> / oc-seq / oc-algo / via-extension > >>> > >>> > >>> oc =3D "oc" [EQUAL oc-num] > >>> oc-num =3D 1*DIGIT > >>> oc-validity =3D "oc-validity" [EQUAL delta-ms] > >>> oc-seq =3D "oc-seq" EQUAL 1*12DIGIT "." 1*5DIGIT > >>> oc-algo =3D "oc-algo" EQUAL DQUOTE algo-list *(COMMA alg= o- > >> list) > >>> DQUOTE > >>> algo-list =3D "loss" / *(other-algo) > >>> other-algo =3D %x41-5A / %x61-7A / %x30-39 > >>> delta-ms =3D 1*DIGIT" > >>> and > >>> "11. IANA Considerations > >>> > >>> This specification defines four new Via header parameters as > >> detailed > >>> below in the "Header Field Parameter and Parameter Values" sub- > >>> registry as per the registry created by [RFC3968]. The required > >>> information is: > >>> > >>> Header Field Parameter Name Predefined Values Reference > >>> __________________________________________________________ > >>> Via oc Yes RFCXXXX > >>> Via oc-validity Yes RFCXXXX > >>> Via oc-seq Yes RFCXXXX > >>> Via oc-algo Yes RFCXXXX > >>> > >>> RFC XXXX [NOTE TO RFC-EDITOR: Please replace with final RFC > >>> number of this specification.]" > >>> > >>> The text of draft-ietf-soc-overload-control refers to both "loss" > >>> and "rate" as values for oc-algo. > >>> > >>> The text of draft-ietf-soc-overload-control section 5.3 refers to > >>> the use of oc for either rate or loss > >>> > >>> "As an example, a value of "oc=3D10" when the loss-based algorithm is > >>> used implies that 10% of the total number of SIP requests (dialo= g > >>> forming as well as in-dialogue) are subject to reduction at the > >>> client. Analogously, a value of "oc=3D10" when the rate-based > >>> algorithm [I-D.ietf-soc-overload-rate-control] is used > >>> indicates > >> that > >>> the client should send SIP requests at a rate of 10 SIP requests > or > >>> fewer per second." > >>> > >>> What are you suggesting would go in the "IANA Considerations" section > of > >>> draft-ietf-soc-overload-rate-control ? Does it just need a > >>> reference to the IANA Considerations in draft-ietf-soc-overload- > control? > >>> > >>> 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: Christer Holmberg >>> > > >>> To: Janet P Gunn/USA/CSC@CSC > >>> Cc: "draft-ietf-soc-overload-rate-control.all@tools.ietf.org > >>> " > >>> >>> >, > >>> "sip-overload@ietf.org " > >>> >, > >>> "sip-overload-bounces@ietf.org = " > >>> >>> > > >>> Date: 06/27/2013 12:54 PM > >>> Subject: VS: [sip-overload] WGLC: draft-ietf-soc-overload-rate-contro= l > - > >>> Christer's comments > >>> > >>> -------------------------------------------------------------------- > >>> ---- > >>> > >>> > >>> > >>> > >>> Hi, > >>> > >>>> The IANA considerations section of draft-ietf-soc-overload-control > >>> registers the new Via header field parameters. > >>>> > >>>> Is it needed here as well? > >>> > >>> The draft (Section 5) does extend the oc parameter, doesn't it? I > >>> would assume that needs to go to IANA. > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> _ > >>> _sip-overload-bounces@ietf.org > >>> wrote on 06/27/2013 06:05:41 AM= : > >>> > >>>> From: Christer Holmberg >> > > >>>> To: "sip-overload@ietf.org " > >>> > > >>>> Cc: "draft-ietf-soc-overload-rate-control.all@tools.ietf.org > >>> " > >>>> >>> > > >>>> Date: 06/27/2013 06:05 AM > >>>> Subject: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control > >>>> - Christer's comments Sent by:sip-overload-bounces@ietf.org > >>>> >> bounces@ietf.org> > >>>> > >>>> Hi, > >>>> > >>>> I have read draft-ietf-soc-overload-rate-control-04.txt as part of > >>>> the > >> WGLC. > >>>> > >>> ... > >>>> Q7: In Section 7 you say that there are no IANA considerations. > >>>> But, don't you need to request IANA to register the new Via header > >>>> field parameters? > >>>> > >>>> Regards, > >>>> > >>>> Christer > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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 > > >=20 > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload From charles.newyork@gmail.com Thu Jul 11 08:22:15 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 0661A21F9C32 for ; Thu, 11 Jul 2013 08:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJ1T-ZHJlFtT for ; Thu, 11 Jul 2013 08:22:13 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 2133F21F9A0A for ; Thu, 11 Jul 2013 08:22:12 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id va7so10229270obc.27 for ; Thu, 11 Jul 2013 08:22:10 -0700 (PDT) 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=T9VD01W7g3jnNVT9obl0lJqd9MyVh9KtLzl02SrI+JU=; b=KKdQ+b0XoIAhKrq80KY9frxcaIBJgSYkdGs60d1Mv/LSBH8kSMUl6fy4UQjlNi+e82 wgPSSWTBoWBdD+nGoUUdCHYCNVq6Maqg2kW6TffVEp8bHUIPH6jy+HyFZA0/HVmttwE+ gC9HoTw6iSW1l3uSwFX/aOg+DgxoIY+Xmafxc3isAV0eunV/u0MfELtkcTXqRRgeURlM /4v/TGJcrby7RM9Q3EmT4dyHzoaZX24licCfwJXhAiRHDkPvaUnNqnAip6PgHbQulAkK X3LHKVPsrnp4x1iJdUmtNRQRKsTnWn/id7kPLlO01Q/e4/1qfnHW/7+ITLtc4tSNZCKL 4/+w== X-Received: by 10.60.102.100 with SMTP id fn4mr32597875oeb.3.1373556130584; Thu, 11 Jul 2013 08:22:10 -0700 (PDT) MIME-Version: 1.0 Sender: charles.newyork@gmail.com Received: by 10.182.112.131 with HTTP; Thu, 11 Jul 2013 08:21:50 -0700 (PDT) In-Reply-To: References: From: Charles Shen Date: Thu, 11 Jul 2013 23:21:50 +0800 X-Google-Sender-Auth: 0GndBzNcgkvWr7Vg-uIBt5cr8yE Message-ID: To: Richard Barnes Content-Type: multipart/alternative; boundary=089e0111d8423e1ce704e13df5a3 Cc: sip-overload@ietf.org, draft-ietf-soc-load-control-event-package@tools.ietf.org Subject: Re: [sip-overload] AD review of draft-ietf-soc-load-control-event-package-08 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, 11 Jul 2013 15:22:15 -0000 --089e0111d8423e1ce704e13df5a3 Content-Type: text/plain; charset=UTF-8 Hi Richard, After putting up more thoughts on this as I finalize the revision, I feel that there are really two options: Option 1: Option 2: I also attach below the respective changes to the XML of these two options. Both will require extended definition of the RFC4745 identity element (unless we want to call it a different name), option 1 is cleaner in terms of usage. but requires extended definition of not only the RFC4745 "identity", also RFC4745 "many" and "except", Option 2 requires extended definition of RFC4745 "identity" but use separate names to extend "many" and "except". Since "many-tel" is independent of "many", everytime we want to include group of identities covering both sip and tel uris we have to specify both "many" and "many-tel". Is there one option that you prefer over the other? Thanks! Charles OPtion 1: redefinition of identity / many / except OPtion 2: redefinition of identity plus defining additional many-tel / except-tel On Wed, Jun 26, 2013 at 8:40 AM, Charles Shen wrote: > This makes a lot of sense, fully agree. Thanks! > > Charles > > > On Tue, Jun 25, 2013 at 10:52 PM, Richard Barnes wrote: > >> >> >> >> On Sun, Jun 23, 2013 at 12:50 AM, Charles Shen wrote: >> >>> Hi Richard, please see additional questions regarding "tel" URL grouping: >>> >>> On Fri, Jun 21, 2013 at 7:00 AM, Richard Barnes wrote: >>> >>>> Inline. Areas of agreement snipped. >>>> >>>> >>>> On Thu, Jun 20, 2013 at 1:40 AM, Charles Shen wrote: >>>> >>>>> To be clear on this, the ambiguity here is with regard to the >>>>> domain="..."> case. In the case, you just do Tel URI >>>>>> comparison. >>>>>> >>>>>> Thinking on this a little more, it looks like your use of the >>>>>> "domain" parameter actually breaks with RFC 4745. According to RFC 4745, >>>>>> there must be an exact match between the "domain" value provided by the >>>>>> using protocol and the value in the "domain" parameter. I can't think of a >>>>>> way that this document could define a way to extract a domain from a >>>>>> telephone number that would meet the semantic you seem to be intending. >>>>>> >>>>>> So it seems like you need to do one of the following: >>>>>> 1. Define a rule for how you compute a domain value from a tel: URI. >>>>>> 2. Define a new element for use under (since lacks an >>>>>> extension point) >>>>>> 3. Drop support for excluding phone numbers by domain (you just have >>>>>> to enumerate the exceptions individually) >>>>>> >>>>>> >>>>> [CS] If we opt for Option 1, can we do the following: >>>>> >>>>> a. assume E.164 numbers always start with + sign, so we can use the >>>>> digits after the + sign (after removing any visual separaters, as in the >>>>> Tel URL comparison rules) as the presumed domain value. >>>>> b. for local numbers (numbers that do not start with +), the >>>>> "phone-context" contains the domain value. >>>>> >>>> >>>> Are you sure that gives you the expressiveness you want? It doesn't >>>> allow you to exclude based on an arbitrary prefix. For example, >>> domain="+1212"> would not match the URI "tel:+12125551212", because >>>> the "domain" value for that URI would be "12125551212". >>>> >>>> It seems like (2) is the option that's most likely to give you what you >>>> want. Suggest defining something like a "" element, so that >>>> you could say something like . >>>> >>> >>> I am absolutely fine adding another element, but just want to make sure >>> I indeed understand your concern before doing that. >>> >>> According to the current texts (paragraph 2, pg.18), when the specified >>> domain value starts with a "+" sign, it denotes a number prefix, if its >>> "+1-212", the prefix is "1212" (after removing any visual separaters, >>> as in the Tel URL comparison rules, this needs to be added explicitly), >>> and this prefix is used to match numbers (again after removing any visual >>> separaters), therefore, it should match the number "1212551212" in the >>> tel URL tel:+12125551212. >>> >>> Did I miss something here? thanks! >>> >>> Charles >>> >> >> I think the concern here isn't with the definition, it's with the fact >> that you're "re-interpreting" an existing field. That's bad for >> interoperability, since if one of these policies is provided to an >> implementation that doesn't know about the reinterpretation, that >> implementation with interpret the field incorrectly. I agree that the risk >> of misinterpretation is pretty low here (since it's buried in a >> call-identity element), but it's best to be unambiguous. >> >> So I would just augment your existing schema to define a new element with >> the same semantic you have described above. >> >> --Richard >> >> >> >> >> >> >> >> > --089e0111d8423e1ce704e13df5a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Richard,=C2=A0

After putting up more thoughts on this= as I finalize the revision, I feel that there are really two options:

Option 1:

<from>
=C2=A0 =C2=A0 <many>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <e= xcept prefix=3D"+1-212-854"/>
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 <except domain=3D"m= anhattan.example.com"/>
=C2=A0 =C2=A0 </many>
</from>

Option 2:

<= div><from>
=C2=A0 =C2=A0 <many>
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 <except domain=3D"manhattan.example.com"/>
=C2=A0 =C2=A0 </many>
=C2=A0 =C2=A0 <many-tel>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <except-tel prefix=3D"+1-212-8= 54"/>
=C2=A0 =C2=A0 </many-tel>
</from= >

I also attach below the respective chan= ges to the XML of these two options. Both will require extended definition = of the RFC4745 identity element (unless we want to call it a different name= ), option 1 is cleaner in terms of usage. but requires extended definition = of not only the RFC4745 "identity", also RFC4745 "many"= and "except", Option 2 requires extended definition of RFC4745 &= quot;identity" but use separate names to extend "many" and &= quot;except". Since "many-tel" is independent of "many&= quot;, everytime we want to include group of identities covering both sip a= nd tel uris we have to specify both "many" and "many-tel&quo= t;. Is there one option that you prefer over the other?=C2=A0

Thanks!

Charles

=


OPtion 1: redefinition of ide= ntity / many / except

=C2=A0 =C2=A0<!-- SIP ID = TYPE -->
=C2=A0 =C2=A0<xs:complexType name=3D"sip-id-type">
=C2=A0 =C2=A0 =C2=A0<xs:sequence>
=C2=A0 =C2=A0 =C2= =A0<element name=3D"from" type=3D"lc:identityType" m= inOccurs=3D"0"/>
=C2=A0 =C2=A0 =C2=A0<element nam= e=3D"to" type=3D"lc:identityType" minOccurs=3D"0&q= uot;/>
=C2=A0 =C2=A0 =C2=A0<element name=3D"request-uri" type=3D= "lc:identityType" minOccurs=3D"0"/>
=C2=A0= =C2=A0 =C2=A0<element name=3D"p-asserted-identity" type=3D&qu= ot;lc:identityType"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0minOccurs=3D"0"/>
=C2=A0 =C2=A0 =C2=A0<any namespace=3D"##other" processCon= tents=3D"lax" minOccurs=3D"0"
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0maxOccurs=3D"unbounded"/>
=C2=A0 =C2=A0 =C2=A0</xs:sequence>
=C2=A0 =C2=A0 =C2=A0<= ;anyAtrribute namespace=3D"##other" processContents=3D"lax&q= uot;/>
=C2=A0 =C2=A0</xs:complexType>

=C2=A0 = =C2=A0 <!-- //conditions/identity -->
=C2=A0 =C2=A0 <xs:= complexType name=3D"identityType">
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 <xs:complexContent>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 <xs:restriction base=3D"xs:anyType">
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <xs:choice = =C2=A0minOccurs=3D"1" maxOccurs=3D"unbounded">
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = <xs:element name=3D"one" type=3D"cp:oneType"/>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 <xs:element name=3D"many" type=3D"lc:manyType"/&= gt;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = <xs:any namespace=3D"##other" processContents=3D"lax"= ;/>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &l= t;/xs:choice>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </x= s:restriction>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 </xs:complexCont= ent>
=C2=A0 =C2=A0 </xs:complexType>

=C2=A0 = =C2=A0 <!-- //identity/many -->
=C2=A0 =C2=A0 <xs:comple= xType name=3D"manyType">
=C2=A0 =C2=A0 =C2=A0 =C2=A0= <xs:complexContent>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 <xs:restriction base=3D"xs:anyType">
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <xs:choice = minOccurs=3D"0" maxOccurs=3D"unbounded">
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <x= s:element name=3D"except" type=3D"lc:exceptType"/>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 <xs:any namespace=3D"##other"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = minOccurs=3D"0" processContents=3D"lax"/>
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </xs:choice><= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <xs:at= tribute name=3D"domain"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 use=3D"optional" type=3D"xs:string&= quot;/>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <xs:attribu= te name=3D"prefix"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 use=3D"optional" type=3D"xs:string"= ;/>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </xs:restrict= ion>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 </xs:complexContent>
=C2=A0 =C2=A0 </xs:complexType>

=C2=A0 = =C2=A0 <!-- //many/except -->
=C2=A0 =C2=A0 <xs:complexT= ype name=3D"exceptType">
=C2=A0 =C2=A0 =C2=A0 =C2=A0= <xs:attribute name=3D"domain" type=3D"xs:string" us= e=3D"optional"/>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <xs:attribute name=3D"prefix"= type=3D"xs:string" use=3D"optional"/>
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 <xs:attribute name=3D"id" type=3D&quo= t;xs:anyURI" use=3D"optional"/>
=C2=A0 =C2=A0 </xs:complexType>


OPtion 2: redefinition of identity plus defining additional many-te= l / except-tel

=C2=A0 =C2=A0<!-- SIP ID TYPE --= >
=C2=A0 =C2=A0<xs:complexType name=3D"sip-id-type">
=C2=A0 =C2=A0 =C2=A0<xs:sequence>
=C2=A0 =C2=A0 =C2=A0= <element name=3D"from" type=3D"lc:identityType" minO= ccurs=3D"0"/>
=C2=A0 =C2=A0 =C2=A0<element name= =3D"to" type=3D"lc:identityType" minOccurs=3D"0&qu= ot;/>
=C2=A0 =C2=A0 =C2=A0<element name=3D"request-uri" type=3D= "lc:identityType" minOccurs=3D"0"/>
=C2=A0= =C2=A0 =C2=A0<element name=3D"p-asserted-identity" type=3D&qu= ot;lc:identityType"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0minOccurs=3D"0"/>
=C2=A0 =C2=A0 =C2=A0<any namespace=3D"##other" processCon= tents=3D"lax" minOccurs=3D"0"
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0maxOccurs=3D"unbounded"/>
=C2=A0 =C2=A0 =C2=A0</xs:sequence>
=C2=A0 =C2=A0 =C2=A0<= ;anyAtrribute namespace=3D"##other" processContents=3D"lax&q= uot;/>
=C2=A0 =C2=A0</xs:complexType>

=C2=A0 = =C2=A0 <!-- //conditions/identity -->
=C2=A0 =C2=A0 <xs:= complexType name=3D"identityType">
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 <xs:complexContent>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 <xs:restriction base=3D"xs:anyType">
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <xs:choice = =C2=A0minOccurs=3D"1" maxOccurs=3D"unbounded">
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = <xs:element name=3D"one" type=3D"cp:oneType"/>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 <xs:element name=3D"many" type=3D"cp:manyType"/&= gt;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = <xs:element name=3D"many-tel" type=3D"lc:many-telType&quo= t;/>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 <xs:any namespace=3D"##other" processContents=3D= "lax"/>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </xs:choice><= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </xs:restriction>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 </xs:complexContent>
=C2=A0 =C2=A0 </xs:complexType>
=C2=A0 =C2=A0 <!-- //id= entity/many-tel -->
=C2=A0 =C2=A0 <xs:complexType name=3D"many-telType">
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <xs:complexContent>
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <xs:restriction base=3D"xs:anyTy= pe">
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 <xs:choice minOccurs=3D"0" maxOccurs=3D"unbounded&quo= t;>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = <xs:element name=3D"exceptTel" type=3D"lc:except-telType&= quot;/>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 <xs:any namespace=3D"##other"
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 minOccur= s=3D"0" processContents=3D"lax"/>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </xs:choice= >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <= xs:attribute name=3D"domain"
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 use=3D"optional" type=3D"xs:= string"/>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </= xs:restriction>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 </xs:complexContent>
=C2= =A0 =C2=A0 </xs:complexType>
=C2=A0 =C2=A0 <!-- //many/e= xcept -->
=C2=A0 =C2=A0 <xs:complexType name=3D"except= -telType">
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <xs:attribute n= ame=3D"prefix" type=3D"xs:string" use=3D"optional&= quot;/>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <xs:attribute name=3D"id" typ= e=3D"xs:anyURI" use=3D"optional"/>
=C2=A0 = =C2=A0 </xs:complexType>





On Wed, Jun 26, 2013 at 8:40 AM, Charles Shen <charles@cs.columbia.e= du> wrote:
This makes a lot of sense, fully agree. Thanks!

Charles

On Tue, Jun 25, 2013 at 10:52 PM, Richard Barnes <rlb@ipv.sx> wrote= :



On Sun, Jun 23, 2013 at 12= :50 AM, Charles Shen <charles@cs.columbia.edu> wrote:<= br>
Hi Richard, please see additional questions regarding &quo= t;tel" URL grouping:

On Fri, Jun 21, 2013 at 7:00= AM, Richard Barnes <rlb@ipv.sx> wrote:
Inline. =C2=A0Areas of agreement snipped.=


On Thu, Jun 20, 2013 at 1:40 AM, Charles Shen <charles@cs.columbia.e= du> wrote:
To be clear on this, the ambiguity here is with regard to the <exc= ept domain=3D"..."> case. =C2=A0In the <one id=3D"...&= quot;> case, you just do Tel URI comparison.

Thinking on this a little more, it looks like your use = of the "domain" parameter actually breaks with RFC 4745. =C2=A0Ac= cording to RFC 4745, there must be an exact match between the "domain&= quot; value provided by the using protocol and the value in the "domai= n" parameter. =C2=A0I can't think of a way that this document coul= d define a way to extract a domain from a telephone number that would meet = the semantic you seem to be intending.

So it seems like you need to do one of the following:
1. Define a rule for how you compute a domain value from a tel: UR= I.
2. Define a new element for use under <many> (since <= except> lacks an extension point)
3. Drop support for excluding phone numbers by domain (you just have t= o enumerate the exceptions individually)


[CS] If we opt = for Option 1, can we do the following:

a. assume E.164 numbers always start with + sign, so we= can use the digits after the + sign (after removing any visual separaters,= as in the Tel URL comparison rules) as the presumed domain value.=C2=A0
b. for local numbers (numbers that do not start with +), the &quo= t;phone-context" contains the domain value.=C2=A0

Are you sure that gives you the e= xpressiveness you want? =C2=A0It doesn't allow you to exclude based on = an arbitrary prefix. =C2=A0For example, <except domain=3D"+1212&quo= t;> would not match the URI "tel:+12125551212", because the &= quot;domain" value for that URI would be "12125551212".

It seems like (2) is the option that's most likely = to give you what you want. =C2=A0Suggest defining something like a "&l= t;except-tel>" element, so that you could say something like <ex= cept-tel prefix=3D"+1212">.

=C2=A0I am absolut= ely fine adding another element, but just want to make sure I indeed unders= tand your concern before doing that.=C2=A0

Accordi= ng to the current texts (paragraph 2, pg.18), when the specified domain val= ue starts with a "+" sign,=C2=A0it = denotes a number prefix, if its "+1-212", the prefix is "121= 2"=C2=A0(after=C2=A0removi= ng any visual separaters, as in the Tel URL comparison rules, this needs to= be added explicitly), and this prefix is use= d to match numbers (again after removing any visual separaters), the= refore, it should match the number "1212551212" in the tel URL te= l:+= 12125551212.=C2=A0

Did I miss something here? thanks!

Charles

I think= the concern here isn't with the definition, it's with the fact tha= t you're "re-inte= rpreting" an existing field. =C2=A0That's bad for interoperability= , since if one of these policies is provided to an implementation that does= n't know about the reinterpretation, that implementation with interpret= the field incorrectly. =C2=A0I agree that the risk of misinterpretation is= pretty low here (since it's buried in a call-identity element), but it= 's best to be unambiguous.

So I would just augment your existing schema to define a= new element with the same semantic you have described above.

--Richard









--089e0111d8423e1ce704e13df5a3-- From ecnoel@research.att.com Thu Jul 11 11:32: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 A81FF21F9FF9; Thu, 11 Jul 2013 11:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BApa7MRVDWVm; Thu, 11 Jul 2013 11:32:46 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id C79B221F9CD9; Thu, 11 Jul 2013 11:32:45 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 3AB971206F5; Thu, 11 Jul 2013 14:32:44 -0400 (EDT) Received: from njfpsrvexg2.research.att.com (njfpsrvexg2.research.att.com [135.207.177.29]) by mail-blue.research.att.com (Postfix) with ESMTP id 2DBC4F035E; Thu, 11 Jul 2013 14:32:45 -0400 (EDT) Received: from njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9]) by njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9%14]) with mapi; Thu, 11 Jul 2013 14:32:44 -0400 From: "NOEL, ERIC C (ERIC C)" To: "'DRAGE, Keith (Keith)'" , "'Yu, James'" Date: Thu, 11 Jul 2013 14:32:42 -0400 Thread-Topic: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Thread-Index: Ac5zhcqru7dYQFxqQKSGvvGKSQFJEAA0j1MAALOuppABZadV0AAr0zMgAAJGKhAAAUkxUAABlYhgAAIP6nAABdJLAAABh6NQAAMQj4AAK6QVgA== Message-ID: <5EBD159DE88147488A3B1590E09001840353C068758D@njfpsrvexg2.research.att.com> References: <56FB15AFE08E1242B0736CBDCE6E85610808C32F@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610808EF90@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353BDA4CAD4@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E85610809239D@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610809253D@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353C0687578@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E856108092986@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353C068757C@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E856108092BD9@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353C0687581@njfpsrvexg2.research.att.com> <949EF20990823C4C85C18D59AA11AD8B06820F@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B06820F@FR712WXCHMBA11.zeu.alcatel-lucent.com> 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_5EBD159DE88147488A3B1590E09001840353C068758Dnjfpsrvexg2_" MIME-Version: 1.0 Cc: "sip-overload-bounces@ietf.org" , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" , "sip-overload@ietf.org" Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.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, 11 Jul 2013 18:32:58 -0000 --_000_5EBD159DE88147488A3B1590E09001840353C068758Dnjfpsrvexg2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Keith, Thank you for your comment. IANA impacts: - Based on Keith suggestion, for the IANA impacts we only need to have the = IANA consideration section in draft-ietf-soc-overload-control to include th= e future RFC number for draft-ietf-soc-overload-rate-control in the referen= ce column - While James is suggesting explicitly defining the new parameter value in = the IANA consideration section of draft-ietf-soc-overload-rate-control =3D> Because Keith proposal is aligned with RFC 3968 guidelines, I propose = adopting his proposal. ABNF impacts: - Based on Keith suggestion, draft-ietf-soc-overload-rate-control syntax se= ction should be reduced to algo-list /=3D "rate" - While James is suggesting that section to include oc =3D "oc" [EQUAL oc-num] oc-num =3D 1*DIGIT oc-algo =3D "oc-algo" EQUAL DQUOTE algo-list *(COMMA algo-list) DQUOTE algo-list =3D "loss" / "rate" / *(other-algo) other-algo =3D %x41-5A / %x61-7A / %x30-39 =3D> Per Keith suggestion, to prevent potential conflicts, I propose adopti= ng his proposal. James would you agree with the proposed resolution? 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: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] Sent: Wednesday, July 10, 2013 6:05 PM To: NOEL, ERIC C (ERIC C); 'Yu, James' Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all= @tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt I've lost track of what is happening here. What I expect is two things: 1) IANA registration impact. For the header field parameters registry, draft-ietf-soc-overload-control a= lready creates the new rows: Header Field Parameter Name Predefined Values Reference __________________________________________________________ Via oc Yes RFCXXXX Via oc-validity Yes RFCXXXX Via oc-seq Yes RFCXXXX Via oc-algo Yes RFCXXXX RFC XXXX [NOTE TO RFC-EDITOR: Please replace with final RFC number of this specification.] For the predefined values columns, RFC 3968 states: Some SIP header field parameters only accept a set of predefined parameter values. For example, a parameter indicating the transport protocol in use may only accept the predefined tokens TCP, UDP, and SCTP as valid values. Registering all parameter values for all SIP header field parameters of this type would require a large number of subregistries. Instead, we have chosen to register parameter values by reference. That is, the entry in the parameter registry for a given header field parameter contains references to the RFCs defining new values of the parameter. References to RFCs defining parameter values appear in double brackets in the registry. So, the header field parameter registry contains a column that indicates whether or not each parameter only accepts a set of predefined values. Implementers of parameters with a "yes" in that column need to find all the valid parameter values in the RFCs provided as references. With this understanding, I do not believe the rate-control draft needs to m= odify the "predefined values" column. What it does need to do is add its ul= timate RFC number to the reference column. There could be an argument that there needs to be a new table that lists th= e algorithm values, but a) if such a table is to be created, it needs to be created by = draft-ietf-soc-overload-control rather than the rate-control draft/ b) I personally do not think it is necessary to add such a new t= able, as I think the references are sufficient. One cannot handle the algor= ithm values unless one goes to the relevant RFC. 2) ABNF impact. ABNF defines the /=3D operator for adding new values to an existing defined= list. I do not think we should reproduce existing ABNF from draft-ietf-soc-overlo= ad-control and then amend it. The reason for this is that tools exist for automatically extracting the AB= NF from RFCs. An extracted algo-list /=3D "rate" will work perfectly well with the extract from draft-ietf-soc-overload-cont= rol (and from SIP). Reproducing productions will result in conflict. Regards Keith ________________________________ From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] = On Behalf Of NOEL, ERIC C (ERIC C) Sent: 10 July 2013 20:54 To: 'Yu, James' Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all= @tools.ietf.org; sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, So section 5 (syntax) will include the following statements: oc =3D "oc" [EQUAL oc-num] oc-num =3D 1*DIGIT oc-algo =3D "oc-algo" EQUAL DQUOTE algo-list *(COMMA algo-list) DQUOTE algo-list =3D "loss" / "rate" / *(other-algo) other-algo =3D %x41-5A / %x61-7A / %x30-39 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: Yu, James [mailto:james.yu@neustar.biz] Sent: Wednesday, July 10, 2013 3:10 PM To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all= @tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Eric, You may want to copy the "oc-algo" line from other I-D. James From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] Sent: Wednesday, July 10, 2013 1:10 PM To: Yu, James Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all= @tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, Based on your suggestion and comments from other reviewers, I intend to upd= ate section 5 (syntax) as follows: oc =3D "oc" [EQUAL oc-num] oc-num =3D 1*DIGIT algo-list =3D "loss" / "rate" / *(other-algo) other-algo =3D %x41-5A / %x61-7A / %x30-39 I understand there may be an additional change following Henning's reply. 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: Yu, James [mailto:james.yu@neustar.biz] Sent: Wednesday, July 10, 2013 11:36 AM To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Eric, Yes, this adds "rate" to "oc-algo" parameter but please check with IANA to = see if it is the correct way. You also need to copy some syntax lines from= the draft-ietf-soc-overload-control to show algo-list =3D "loss" / "rate" / *(other-algo) I've an email to Henning asking if algo-list in his I-D should be algo-list =3D "loss" / other-algo If yes, then this particular line in your I-D would be algo-list =3D "loss" / "rate" / other-algo James From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] Sent: Wednesday, July 10, 2013 10:49 AM To: Yu, James Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, Thank you for your suggestion. Not being familiar with IANA procedure, would updating draft-ietf-soc-overl= oad-rate-control section 7 (IANA considerations) as follows work? This specification defines a new value for Via header parameter oc-algo as = detailed below in the "Header Field Parameter and Parameter Values" subregi= stry as per the registry created by [RFC3968]. The required information is: Header Field Parameter Name Predefined Val= ues Reference ---------------------------------------------------------------------------= ------------------------------- Via oc-algo = "rate" RFCXXXX RFC XXXX [NOTE TO RFC-EDITOR: Please replace with final RFC number of this = specification.] 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: Yu, James [mailto:james.yu@neustar.biz] Sent: Wednesday, July 10, 2013 10:17 AM To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Noel, I forgot to respond to your reply about the IANA registration of "rate" in = oc-algo. I see that draft-ietf-soc-overload-control-13 mentions your I-D b= ut does not have "rate" in algo-list. There are two possible ways to address "rate" in algo-list. One is to have= draft-ietf-soc-overload-control-13 add "rate" to algo-list and refer to yo= ur I-D for details. The other is to register "rate" in algo-list with IANA= in your I-D, and this should be a simple task. The cleaner way that is mo= re inline with the IETF process would be the latter. It seems odd to have = something defined in a RFC without details about it, and it would be too mu= ch trouble to combine the two I-Ds. James From: Yu, James Sent: Wednesday, July 10, 2013 9:01 AM To: 'NOEL, ERIC C (ERIC C)' Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Noel, I mentioned in my message to Janet on 7/2: For the rate control, the server could calculate the arrival rate from each= communicating client so that it could allocate the overall target SIP requ= est rate to the clients based on their arrival rates known to the server. = But another option is for the client to "optionally" include its calculated= arrival rate in its request to the server when rate control related parame= ters are present. Should this option be evaluated/included to relieve the = server from doing the arrival rate calculations. This would be beneficial = to a server when it receives the requests from many clients. I suggest that the I-D adds that option to allow the client to indicate its= current arrival rate (towards the receiving server) in the SIP request. James From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] Sent: Tuesday, July 09, 2013 4:44 PM To: Yu, James; Janet P Gunn Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Janet, James, Thanks you for your valuable comments and discussion. I tried to capture a= ll resolution in the following text (based on James word document with trac= k changes and imbedded comments enabled). + Abstract section: - Agreed with suggested changes - Please note I will also need to make further changes to remove all refere= nces per Christer Holmberg comment + Section 1: - Agreed with suggested changes + Section 3.1: - Agreed with suggested changes + Section 3.2: - Please note the section title will become "Via header fiel= d parameters for overload control " per Christer Holmberg comment - Agreed with suggested changes excluding title that will change per previo= us bullet + Section 3.3: - Agreed with suggested changes + Section 3.4: - ID: "Note that the target SIP request rate is a max rate that may not be= attained by the arrival rate at the client, and the server cannot assume t= hat it will." [JY] Not clear what value this paragraph tries to add. Is it saying tha= t the client's arrival rate may be lower than the target SIP request rate? [JG] Yes + supporting example (see below in thread) Agreed with Janet and supporting example. Per James request, I will add t= he following text (inspired from Janet's illustrative example): "In other words, when multiple clients are being controlled by an overlo= aded server, at any given time some clients may receive requests at a rate = below its target SIP request rate while others above that target rate. But = the resulting request rate presented to the overloaded server will converge= towards the target SIP request rate." - Agreed with other suggested changes + Section 3.5.1: - ID: "And the larger the difference between TAU1 and TAU2, the closer to t= he control is to strict priority." [JY] Suggest changing into "And the larger the difference between TAU1 an= d TAU2, the closer the control is to strict priority queuing." [JG] Suggest changing into "And the larger the difference between TAU1 an= d TAU2, the closer the control is to strict priority treatment." [EN] Agreed with Janet's suggestion - Agreed with other suggested changes + Section 4: - Agreed with suggested changes + Section 5: - Please note that based comments from per Christer Holmberg and Janet Gunn= , the following was tentatively agreed Replace oc-value =3D "NaN" / oc-num by oc =3D "oc" [EQUAL oc-num] - Agreed with other suggested change + Section 7: - [JY] Should "rate" in oc-algo be registered with IANA? This issue needs to be addressed by draft-ietf-soc-overload-control autho= rs Please note I will wait until expiration of WGLC prior updating our draft R= FC. Once again your comments and/or suggestions are most appreciated. 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 Yu, James Sent: Tuesday, July 02, 2013 9:42 AM To: Janet P Gunn Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Janet, For my comment on section 3.4 (the first one below), the current text does = not provide any value. The client's arrival rate could be well below the t= arget SIP request rate when its load is light so the fact that the client m= ay not achieve the target SIP request rate (the max. rate it is allowed to = send to the server) is well understood. But with your explanation on the "= delta" part, the text then makes sense. Please add some discussions on the= "delta" aspect so that even if the average arrival rate at the client is h= igher than the target SIP request rate the client at times may not send mor= e than what the target SIP request rate allows due to the fluctuation of th= e arriving requests at the client. For the comment on section 3.5.1, I agree with your proposed change. For the rate control, the server could calculate the arrival rate from each= communicating client so that it could allocate the overall target SIP requ= est rate to the clients based on their arrival rates known to the server. = But another option is for the client to "optionally" include its calculated= arrival rate in its request to the server when rate control related parame= ters are present. Should this option be evaluated/included to relieve the = server from doing the arrival rate calculations. This would be beneficial = to a server when it receives the requests from many clients. James From: Janet P Gunn [mailto:jgunn6@csc.com] Sent: Friday, June 28, 2013 3:34 PM To: Yu, James Cc: draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org; sip-overload-bounces@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, It is a little hard to respond in email when your comments are in a separat= e document, but here goes. section 3.4 ID says: "Note that the target SIP request rate is a max rate that may not be attained by the arrival rate at the client, and the server cannot assume that it will." Your comment : "Not clear what value this paragraph tries to add. Is it saying that the c= lient's arrival rate may be lower than the target SIP request rate? " Yes. Suppose the server want to limit the total rate of arriving SIP messages to= 100 / sec, and has 10 clients. Each client has a high variance in its mes= sage rate, but together they are well above 100 messages per sec If it sets the rate at 10 messages per second for each of the clients, it w= ill almost certainly end up with an overall average of less than 100 messa= ges per sec, because some clients will be in a "lull" while others are busy= . This is good from a throttling perspective, but, assuming messages are c= orrelated with revenue, bad/wasteful from a revenue, or overall productivit= y perspective. So the server might want to set the rate per client to 10 += delta, where delta is going to be very specific to operating environment. --- In section 3.5.1, bottom of page 8 ID says: "And the larger the difference between TAU1 and TAU2, the closer to the control is to strict priority." You propose changing it to: "And the larger the difference between TAU1 and TAU2, the closer the control is to strict priority queuing." I agree with taking out the redundant "to". But I disagree wit adding "que= uing". There is no queuing, priority or otherwise involved. You could say: "And the larger the difference between TAU1 and TAU2, the closer the control is to strict priority treatment." where " strict priority treatment" would refer to the case where non-priori= ty messages are restricted to a total (priority + non-priority) rate of 10 = messages per second, but priority messages can continue to be sent as long = as the total (priority + non-priority) rate is less than 12 messages per se= cond. At least, I think that is what Eric and Philip are trying to say. 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: "Yu, James" = > To: "sip-overload-bounces@ietf.org" >= , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" >, "sip-overload@ietf.org"= > Date: 06/28/2013 08:10 AM Subject: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Sent by: sip-overload-bounces@ietf.org ________________________________ Salvatore, Please see the attachment for my comments. I pasted the text to a word document to trace/show the proposed changes and= comments. Regards, James [attachment "comments on draft-ietf-soc-overload-rate-control-04.docx" del= eted by Janet P Gunn/USA/CSC] _____________________________________________= __ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6452 - Release Date: 06/30/13 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13 --_000_5EBD159DE88147488A3B1590E09001840353C068758Dnjfpsrvexg2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Keith,

 

=

Thank you for your comment. <= /p>

 

IANA impacts:

= - Based on Keith suggestion, for the IANA impacts we only need to have the = IANA consideration section in draft-ietf-soc-overload-control to include th= e future RFC number for draft-ietf-soc-overload-rate-control in the referen= ce column

- While James is= suggesting explicitly defining the new parameter value in the IANA conside= ration section of draft-ietf-soc-overload-rate-control

=3D> Because Keith proposal is aligned with= RFC 3968 guidelines, I propose adopting his proposal.

 

ABNF impacts:

-= Based on Keith suggestion, draft-ietf-soc-overload-rate-control syntax sec= tion should be reduced to

= algo-list /=3D “rate“ <= /p>

- While James is suggesting that section to = include

oc =3D “oc&#= 8221; [EQUAL oc-num]

oc-n= um =3D 1*DIGIT

oc-algo =3D= "oc-algo" EQUAL DQUOTE algo-list *(COMMA algo-list) DQUOTE<= /o:p>

algo-list =3D “loss”= ; / “rate“ / *(other-algo)

other-algo =3D %x41-5A / %x61-7A / %x30-39

=3D> Per Keith suggestion, to prevent pote= ntial conflicts, I propose adopting his proposal.

 

James would you agree with the proposed resolution?<= /p>

 

Thanks,

 

Eric Noel

AT&T Labs, Inc.=
Rethink Possible

 

Network Design and Performance Analysis
200 South Lau= rel Avenue, D5-3D19
Middletown, NJ 07748
P: 732.420.4174

ecnoel@att.c= om

 

<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From: = DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com]
Sent: Wednesday, July 10, 2013 6:05 PM
To: NOEL, ERIC C (ERIC C); 'Y= u, James'
Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overl= oad-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt

 

I’ve lost track of what is happening here= . What I expect is two things:

 

1)         IANA registration impa= ct.

 

For the header field para= meters registry, draft-ietf-soc-overload-control already creates the new ro= ws:

 

       =
Header Field  Parameter Name  Predefined Values  Reference
     =
;  __________________________________________________________
      =
 Via           oc &n=
bsp;            =
;   Yes         &nbs=
p;   RFCXXXX
 =
;      Via      &nbs=
p;    oc-validity        =
Yes            =
 RFCXXXX
   &=
nbsp;   Via          =
; oc-seq          &n=
bsp;  Yes          &=
nbsp;  RFCXXXX
 &n=
bsp;     Via       &=
nbsp;   oc-algo        &n=
bsp;   Yes         &=
nbsp;   RFCXXXX
 
    =
;   RFC XXXX [NOTE TO RFC-EDITOR: Please replace with final RFC
     =
;  number of this specification.]

 

For the predefined values columns, RFC 3968 states:<= /span>

 

<= pre>   Some SIP header field parameters only a= ccept a set of predefined
&n=
bsp;  parameter values.  For example, a parameter indicating the =
transport
   proto=
col in use may only accept the predefined tokens TCP, UDP, and
   SCTP as valid values. =
 Registering all parameter values for all SIP
<=
span lang=3DEN-GB>   header field parameters of this type would r=
equire a large number of
&nb=
sp;  subregistries.  Instead, we have chosen to register paramete=
r values
   by ref=
erence.  That is, the entry in the parameter registry for a=

   given header field parame=
ter contains references to the RFCs defining
   new values of the parameter.  References=
 to RFCs defining parameter
=
   values appear in double brackets in the registry.
 
   So, the header field parameter registry contains=
 a column that
   =
indicates whether or not each parameter only accepts a set of
   predefined values.  Imp=
lementers of parameters with a "yes" in that
   column need to find all the valid p=
arameter values in the RFCs
=
   provided as references.
 
With this understanding, I do not believe the rate-control draft =
needs to modify the “predefined values” column. What it does ne=
ed to do is add its ultimate RFC number to the reference column.=

 
=

There could be an argument that there n=
eeds to be a new table that lists the algorithm values, but 
 
a)    =
;         if such a table is to be created, it needs to be creat=
ed by draft-ietf-soc-overload-control rather than the rate-control draft/
b)            =
I personally do not think it is nece=
ssary to add such a new table, as I think the references are sufficient. On=
e cannot handle the algorithm values unless one goes to the relevant RFC.
 
2)    &nbs=
p;    ABNF impact.
 
ABNF defines the /=3D operator for adding new values to an existing de=
fined list.
&=
nbsp;
I do not think we=
 should reproduce existing ABNF from draft-ietf-soc-overload-control and th=
en amend it. 
 
The reason for =
this is that tools exist for automatically extracting the ABNF from RFCs. A=
n extracted 
=
 
algo-list /=3D “ra=
te“ 
=
 
will work perfectly well with the extract from draft-ietf-soc-overload=
-control (and from SIP). Reproducing productions will result in conflict.
 
Regards
<=
p class=3DMsoNormal> 
Keith
 
From: sip-overload-bounces@ietf.org [ma=
ilto:sip-overload-bounces@ietf.org] On Behalf Of NOEL, ERIC C (ERIC =
C)
Sent: 10 July 2013 20:54
To: 'Yu, James'
Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all@=
tools.ietf.org; sip-overload@ietf.org
Subject: Re: [sip-overload]=
 draft-ietf-soc-overload-rate-control-04.txt
 
James,
 
So section 5 (synt=
ax) will include the following statements:
 
oc=
 =3D “oc” [EQUAL oc-num]
oc-num =3D 1*DIGIT
oc-algo =3D "oc-algo" EQUAL DQUOTE algo-list *(COMMA algo-lis=
t) DQUOTE
algo-list =3D &#=
8220;loss” / “rate“ / *(other-algo)
=

other-algo =3D %x41-5A / %x61-7A / %x30-39=

 
Thanks,
 
Eric =
Noel 
AT&am=
p;T Labs, Inc. 
Rethink Possible
 
Network Design and Performance Analysis200 South Laurel Avenue, D5-3D19
Middletown, NJ 07748
P: 732.420.417=
4
ecnoel@att.com
 
From: Yu, James [mailto:james.yu@neustar.biz] 
Sent: Wedn=
esday, July 10, 2013 3:10 PM
To: NOEL, ERIC C (ERIC C)
Cc:<=
/b> sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all=
@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload=
] draft-ietf-soc-overload-rate-control-04.txt
 
Eric,
You may want to copy the “oc-algo” line from other I-=
D.
 
James
 
From=
: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] 
Sent: Wednesday, July 10, 2013 1:10 PM
To: Yu, James
Cc: si=
p-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all@tools=
.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload] draf=
t-ietf-soc-overload-rate-control-04.txt
 
James,<=
o:p>
 
Based on your suggestion and comments from ot=
her reviewers, I intend to update section 5 (syntax) as follows:=

 
oc =3D “oc” [EQUAL oc-num]
oc-num =3D 1*DIGIT
 
=
algo-list =3D “loss” / “rate“ / *(other-algo=
)
other-algo =3D %x41-5A /=
 %x61-7A / %x30-39
&n=
bsp;
I understand there may be =
an additional change following Henning’s reply.
=

 
Thanks,
&nbs=
p;
Eric Noel <=
o:p>
AT&T Labs, Inc. 
Rethink Possible
=

 
Network Design and Performance Analysis
200 South Laurel A=
venue, D5-3D19
Middletown, NJ 07748
P: 732.420.4174=

ecnoel@att.com
 
 
Eric,=

 
Yes, this adds “rate” to “oc-algo” par=
ameter but please check with IANA to see if it is the correct way.  Yo=
u also need to copy some syntax lines from the draft-ietf-soc-overload-cont=
rol to show 
 
     =
al=
go-list   =3D “loss“=
 / “rate“ / *(other-=
algo)
 
I’ve an email to Henning asking i=
f algo-list in his I-D should be
=
     algo-list   =3D “loss“ / other-algo=

 
If yes, then this particular line in your I-D would be 
     algo-list   =3D “loss&#=
8220; / “rate“ / oth=
er-algo
 
James=

 
<=
p class=3DMsoNormal>From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] 
Sent: Wednesd=
ay, July 10, 2013 10:49 AM
To: Yu, James
Cc: sip-overload-bounces@ietf.org; <=
a href=3D"mailto:draft-ietf-soc-overload-rate-control.all@tools.ietf.org">d=
raft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: =
[sip-overload] draft-ietf-soc-overload-rate-control-04.txt
 
James,
&n=
bsp;
Thank you for your suggest=
ion. 
 
Not being familiar with IANA procedure,=
 would updating draft-ietf-soc-overload-rate-control section 7 (IANA consid=
erations) as follows work?
 
This specification=
 defines a new value for Via header parameter oc-algo as detailed below in =
the "Header Field Parameter and Parameter Values" subregistry as =
per the registry created by [RFC3968]. The required information is:
 
Header Field       &nb=
sp;   Parameter Name       &nb=
sp;            =
    Predefined Values      &nb=
sp;            =
 Reference
----------=
---------------------------------------------------------------------------=
---------------------
Via =
            &nb=
sp;            =
    oc-algo        &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;“rate”         &=
nbsp;           &nbs=
p;             =
          RFCXXXX
 
RFC XXXX [NOTE TO RFC-EDITOR: Please replace with fi=
nal RFC number of this specification.]
 
Than=
ks,
 
Eric Noel 
AT&T Labs, Inc. =

Rethink Possible
 
Network Design and Performance Analysis
200 South Laurel Avenue, D5-3D1=
9
Middletown, NJ 07748
P: 732.420.4174
ecnoel@att.com
&nbs=
p;
From: Yu, James [mailto:james.yu@neustar.biz] 
S=
ent: Wednesday, July 10, 2013 10:17 AM
To: NOEL, ERIC C (ERIC=
 C)
Cc: sip-over=
load-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all@tools.i=
etf.org; sip-overload@ietf.org=

Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-con=
trol-04.txt
&nbs=
p;
Noel,
 
I forgot to respond to your reply about the IANA registration of “ra=
te” in oc-algo.  I see that draft-ietf-soc-overload-control-13 m=
entions your I-D but does not have “rate” in algo-list.
 
There are two possible ways to address “rate&#=
8221; in algo-list.  One is to have draft-ietf-soc-overload-control-13=
 add “rate” to algo-list and refer to your I-D for details.&nbs=
p; The other is to register “rate” in algo-list with IANA in yo=
ur I-D, and this should be a simple task.  The cleaner way that is mor=
e inline with the IETF process would be the latter.  It seems odd to h=
ave something defined in a RFC without details about it, and it would be to=
o much trouble to combine the two I-Ds.
 
Jame=
s
 =

From: Yu, James 
Sent: Wedne=
sday, July 10, 2013 9:01 AM
To: 'NOEL, ERIC C (ERIC C)'
Cc:=
 sip-overload-bounces@=
ietf.org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; =
sip-overload@ietf.org
Su=
bject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt
 
<=
p class=3DMsoNormal>Noel,
=
 
I mentioned =
in my message to Janet on 7/2:
 
For the rate control, the server could calculate the arrival rat=
e from each communicating client so that it could allocate the overall targ=
et SIP request rate to the clients based on their arrival rates known to th=
e server.  But another option is for the client to “optionally&#=
8221; include its calculated arrival rate in its request to the server when=
 rate control related parameters are present.  Should this option be e=
valuated/included to relieve the server from doing the arrival rate calcula=
tions.  This would be beneficial to a server when it receives the requ=
ests from many clients.
 
I suggest that the I-=
D adds that option to allow the client to indicate its current arrival rate=
 (towards the receiving server) in the SIP request.
 
=
James
 
From: NOEL, ERIC C (ERIC C)=
 [mailto:ecnoel@research.att.com=
] 
Sent: Tuesday, July 09, 2013 4:44 PM
To: Yu, Jam=
es; Janet P Gunn
Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-contro=
l.all@tools.ietf.org; sip-over=
load@ietf.org
Subject: RE: [sip-overload] draft-ietf-soc-over=
load-rate-control-04.txt
 
Janet, James,
 
Thanks you for your valuable comments and discussion.=
  I tried to capture all resolution in the following text (based on Ja=
mes word document with track changes and imbedded comments enabled).
 
+ Abstract section: 
- Agreed with suggested changes
- Please note I will also need to make further ch=
anges to remove all references per Christer Holmberg comment
 
+ Section 1:
- Agreed with suggested changes
 
+ Section =
3.1:
- Agreed with suggest=
ed changes
  
+ Section 3.2: - Please note the =
section title will become “Via header field parameters for overload c=
ontrol “ per Christer Holmberg comment
- Agreed with suggested changes excluding title that wi=
ll change per previous bullet
 
+ Section 3.3:<=
o:p>
- Agreed with suggested ch=
anges
 
+ Section 3.4:
- ID:  "Note that the target SIP request=
 rate is a max rate that may not be attained by the arrival rate at the cli=
ent, and the server cannot assume that it will." 
   [JY] Not clear what value th=
is paragraph tries to add.  Is it saying that the client's arrival rat=
e may be lower than the target SIP request rate? 
   [JG] Yes + supporting example (se=
e below in thread)
 &=
nbsp;Agreed with Janet and supporting example. Per James request, I will ad=
d the following text (inspired from Janet’s illustrative example):
   “In other=
 words, when multiple clients are being controlled by an overloaded server,=
 at any given time some clients may receive requests at a rate below its ta=
rget SIP request rate while others above that target rate. But the resultin=
g request rate presented to the overloaded server will converge towards the=
 target SIP request rate.”
=
- Agreed with other suggested changes 
     
+ Section 3.5.1:
- ID: “And the larger the difference between TAU1 and=
 TAU2, the closer to the control is to strict priority.”
  [JY] Suggest changing into R=
20;And the larger the difference between TAU1 and TAU2, the closer the cont=
rol is to strict priority queuing.”
  [JG] Suggest changing into “And the larger the=
 difference between TAU1 and TAU2, the closer the control is to strict prio=
rity treatment.”
&nb=
sp; [EN] Agreed with Janet’s suggestion
- Agreed with other suggested changes=

 
+ Section 4:
=
- Agreed with suggested changes
<=
span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F=
497D'> 
+ Section 5:<=
o:p>
- Please note that based c=
omments from per Christer Holmberg and Janet Gunn, the following was tentat=
ively agreed 
  =
 Replace oc-value =3D "NaN" / oc-num    by&nb=
sp;   oc =3D "oc" [EQUAL oc-num]
<=
p class=3DMsoNormal>- Agreed with other suggested change<=
/span>
 
+ Section 7:
=
- [JY] Should “rate” in oc-algo be registered with IANA?=

  This issue needs t=
o be addressed by draft-ietf-soc-overload-control authors=

 
Please note I will wait until expiration of WGLC prior updatin=
g our draft RFC. Once again your comments and/or suggestions are most appre=
ciated.
 <=
/span>
Thanks,
 
<=
span style=3D'font-size:9.0pt;font-family:"Verdana","sans-serif";color:#F47=
B20'>Eric Noel 
<=
span style=3D'font-size:9.0pt;font-family:"Verdana","sans-serif";color:#666=
666'>AT&T Labs, Inc. 
Rethink Possi=
ble
 
Network Design and Performance A=
nalysis
200 South Laurel Avenue, D5-3D19
Middletown, NJ 07748
P: 7=
32.420.4174
ecnoel@att.com
 
 =
;
Janet,
 
For my comment on section 3.4 (the first one below), the current text does=
 not provide any value.  The client’s arrival rate could be well=
 below the target SIP request rate when its load is light so the fact that =
the client may not achieve the target SIP request rate (the max. rate it is=
 allowed to send to the server) is well understood.  But with your exp=
lanation on the “delta” part, the text then makes sense.  =
Please add some discussions on the “delta” aspect so that even =
if the average arrival rate at the client is higher than the target SIP req=
uest rate the client at times may not send more than what the target SIP re=
quest rate allows due to the fluctuation of the arriving requests at the cl=
ient.
 
For the comment on section 3.5.1, I agr=
ee with your proposed change.
 
For the rate co=
ntrol, the server could calculate the arrival rate from each communicating =
client so that it could allocate the overall target SIP request rate to the=
 clients based on their arrival rates known to the server.  But anothe=
r option is for the client to “optionally” include its calculat=
ed arrival rate in its request to the server when rate control related para=
meters are present.  Should this option be evaluated/included to relie=
ve the server from doing the arrival rate calculations.  This would be=
 beneficial to a server when it receives the requests from many clients.
 
=

James
 
From: Janet=
 P Gunn [mailto:jgunn6@csc.com] 
<=
b>Sent: Friday, June 28, 2013 3:34 PM
To: Yu, James
Cc:=
 draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org; sip-overload-bounces@ietf.org
=
Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt=

 
James, 

It is a little hard to respond in email when your comme=
nts are in a separate document, but here goes. 


section 3.4=
 
ID s=
ays: 
"Note that the target SIP request rate is a max rate that may n=
ot be 
   attained by the arrival rate at the client, and the se=
rver cannot 
   assume that it will." 

Your comment :<=
/span> 
"Not clear what value this paragraph tries to add.  Is it sayin=
g that the client's arrival rate may be lower than the target SIP request r=
ate?  " 

Yes. 

Suppose the server want to limit the tot=
al rate of arriving SIP messages to 100 / sec, and has 10 clients.  Ea=
ch client has a high variance in its message rate, but together they are we=
ll above 100 messages per sec 

If it sets the rate at 10 messages per =
second for each of the clients, it will almost certainly end up  with =
an overall average of less than 100 messages per sec, because some clients =
will be in a "lull" while others are busy.  This is good fro=
m a throttling perspective, but, assuming messages are correlated with reve=
nue, bad/wasteful from a revenue, or overall productivity perspective. &nbs=
p;So the server might want to set the rate per client to 10 + delta, where =
delta is going to be very specific to operating environment. 
--- 
In=
 section  3.5.1, bottom of page 8 
ID says: 
"And the larger 
=
   the difference between TAU1 and TAU2, the closer to the contro=
l is 
   to strict priority." 

You propose changing it=
 to: 
"And the larger 
   the difference between TAU1 and =
TAU2, the closer  the control is 
   to strict priority que=
uing." 

I agree with taking out the redundant "to". &nb=
sp;But I disagree wit adding "queuing".  There is no queuing=
, priority or otherwise involved. 

You could say: 
"And the larg=
er 
   the difference between TAU1 and TAU2, the closer  th=
e control is 
   to strict priority treatment." 
=

where=
 " strict priority treatment" would refer to the case where non-p=
riority messages are restricted to a total (priority + non-priority) rate o=
f 10 messages per second, but priority messages can continue to be sent as =
long as the total (priority + non-priority) rate is less than 12 messages p=
er second. 

At least, I think that is what Eric and  Philip are t=
rying to say. 

Janet 


  


This is a PRIVATE mess=
age. If you are not the intended recipient, please delete without copying a=
nd 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 initi=
ative expressly permitting the use of e-mail for such purpose. 
<=
br>

From:        "Yu, James" <james.yu@neustar.biz> To:        "sip-overload-bounces@ietf.org" <sip-overload-bounces@ietf.org>, "=
;draft-ietf-soc-overload-rate-control.all@tools.ietf.org" <draf=
t-ietf-soc-overload-rate-control.all@tools.ietf.org>, "sip-overload@ietf.org" <sip-overload@ietf.org> Date:        06/28/2013 08:10 AM 
Subj=
ect:        [sip-overload] draft-ietf-soc-overload-rate-co=
ntrol-04.txt 
Sent by:        sip-overload-bounces@ietf.org=
 


Salva=
tore, 
  
Please see the attachment for my comments. 
=
 <=
/span> 
I pasted the text to a word document to trace/show the proposed changes=
 and comments. 
  
Regards, 
  
James 
 [atta=
chment "comments on draft-ietf-soc-overload-rate-control-04.docx"=
 deleted by Janet P Gunn/USA/CSC] _______________________________________________
sip-overload mailin=
g list
sip-overload@ie=
tf.org
https://www.ietf.org/mai=
lman/listinfo/sip-overload
No virus found=
 in this message.
Checked by AVG - www.av=
g.com
Version: 2013.0.2904 / Virus Database: 3204/6452 - Release Dat=
e: 06/30/13
No virus found in this message.
Checked by=
 AVG - www.avg.com
Version: 2013.0.29=
04 / Virus Database: 3204/6478 - Release Date: 07/09/13
N=
o virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 3204/6478 =
- Release Date: 07/09/13
No virus found in this message.<=
br>Checked by AVG - www.avg.com
Versi=
on: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13
=

--_000_5EBD159DE88147488A3B1590E09001840353C068758Dnjfpsrvexg2_--

From rlb@ipv.sx  Fri Jul 12 06:35:56 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 A614521F9477 for ; Fri, 12 Jul 2013 06:35:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.788
X-Spam-Level: 
X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[AWL=0.188,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxiRBEfJ-FGC for ; Fri, 12 Jul 2013 06:35:48 -0700 (PDT)
Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4475B11E80F9 for ; Fri, 12 Jul 2013 06:35:48 -0700 (PDT)
Received: by mail-ob0-f173.google.com with SMTP id wc20so11168632obb.4 for ; Fri, 12 Jul 2013 06:35:47 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=qEDM6+N2qctjm1R9zeMpnfLMrPeD1c71BEGZIj6W4dk=; b=emfffKfLsAAboTc0Cb3vLNhwIYBS6PdFu3OjZ2DWZtxOySi2HHCkDrzC9sJ+XQtgL0 UcNLm1jVBJ/TdRBVOFc7fBok1/uWMsYFgrubPDSQC+A2Yn03PuS4wuSyi7Oqp4U8VsEd wlUPIt0AHxWc4lv1QCYJjRUxlNtk8r2LnF6VOmUiugECB8jtBb6bVqo26wKkqUeC3i2s B5Q3ZECfKREASMwaHUFbhHqN1xzLXkxrKbJvlwrPiz+wCJTOuOFYjhi5v9/j50iDsAba GMnftvt94jlZN2XX4Unua2qNsR6ykccPbswskWMG/frINnQs0HcKn/KDZXFKnMgMoG2r Nyqg==
MIME-Version: 1.0
X-Received: by 10.182.232.225 with SMTP id tr1mr35758106obc.69.1373636147682;  Fri, 12 Jul 2013 06:35:47 -0700 (PDT)
Received: by 10.60.26.135 with HTTP; Fri, 12 Jul 2013 06:35:47 -0700 (PDT)
X-Originating-IP: [76.21.182.222]
Date: Fri, 12 Jul 2013 09:35:47 -0400
Message-ID: 
From: Richard Barnes 
To: sip-overload@ietf.org
Content-Type: multipart/alternative; boundary=001a11c31242a22e8a04e1509682
X-Gm-Message-State: ALoCoQlUEvkjFPIk/b1+KAoXevpb7gK5ehGzsvFvOcOIJ24OMsangJzvZZ/V8O5erAD056CxaQDc
Subject: [sip-overload] AD review: draft-ietf-soc-overload-control-13
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, 12 Jul 2013 13:35:56 -0000

--001a11c31242a22e8a04e1509682
Content-Type: text/plain; charset=ISO-8859-1

I have reviewed this draft, and there are several issues that I would like
to address before sending it to IETF LC.

MAJOR:

1. The fourth paragraph of Section 4.4 does not allow clients to detect
when overflow has happened.  It seems like there are two options: (1)
Define the timestamp so it cannot overflow (e.g., as a sufficiently long
timestap), or (2) define what an "appropriate base value" is so that a
client can recognize when the "oc-seq" has been reset there.  It seems like
it would be simplest to imply say that "oc-seq" MUST be an N-bit counter
value or a timestamp.  (Or better, choose one.)

2. "oc=0" seems like a bad way to signal that there's no overload going on.
 "oc-validity=0" does that.  And if there's no overload condition, on
algorithm is being applied, so no "oc" parameter value needs to be
supplied.  So it seems like you should signal support with no overload with
"oc;oc-validity=0".

3. As written, it seems like Section 5.9 could be read to require a
behavior that would exacerbate overload conditions with liveness checks.
 (For example, "periodically" with period 500ms.)  Suggest that this
section recommend a back-off algorithm, possibly with some concrete timing
paramters.  E.g., start at whatever interval you like, exponential back-off
to some floor (say 10sec).

4. The Security Considerations do a good job of describing the threats that
this mechanism introduces, but less so the mitigations to these threats.
 In particular, there is no mitigation provided for the multi-hop attack,
and the mitigation for a malicious client is not clearly stated.  Suggest:
-- Recommending that clients enforce a maximum validity period (e.g.,
3600s) in order to limit the scope of spoofing attacks (off-path or
multi-hop)
-- "Servers SHOULD monitor client behavior to determine whether they are
complying with overload control policies.  If a client is not conforming,
then the server SHOULD treat it as a non-supporting client (Section
5.10.2)."


MINOR:

1. The last paragraph of Section 2 is tautological.  ("The normative
statements...this specification.")  If an entity doesn't support this
specification, then of course the normative requirements don't apply!  Do
you mean something different from that?

2. In Section 4.2, it would help if you could say briefly why multiple
algorithms are needed.  Are some algorithms better suited to different
overload conditions?  Or could the group just not make up its mind?  (Maybe
there's a reference for this?)

3. Mandating that "loss" be included in the list of supported algorithms
seems duplicative.  Clients are already required to support "loss" and put
supported algorithms in the list.  It also seems undesirable for servers to
rely on "loss" being present, since that could cause problems if for some
reason we decide to deprecate "loss" in the future (cf. [[ SDP codec change
]])

4. It's not clear why the "oc-seq" parameter needs a fractional portion.
 Wouldn't it be simple just to make it an integer?

5. In Section 5.8, "frequent changes of overload control algorithm MUST be
avoided" -- This is not an RFC 2119 MUST.

6. In Section 5.8, "the algorithm MUST remain in effect" -> "the server
SHOULD NOT change the algorithm for that client"  It seems like you
wouldn't want to prevent the server from changing if it really needed to.

7. In Section 5.10.2, the recommendation at the end seems a little light,
and unclear how to implement.  You might recommend a simple algorithm to
apply here, e.g., just drop everything from non-supporting clients.

8. In Section 6.1, the last two paragraphs are completely redundant with
the general behavior specified above.

9. The example in Section 6.2 is not specific to the "loss" algorithm.  It
should be moved up to the top level.

10. Should Section 9 be moved to an appendix?

11. In Section 10, it's not really even necessary to use TLS to prevent
spoofing.  In many cases just using a connection-oriented protocol like TLS
or WS would be sufficient.


Thanks,
--Richard

--001a11c31242a22e8a04e1509682
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


I have reviewed this draft, and there are several issues t=
hat I would like to address before sending it to IETF LC.

MAJOR:

1. The fourth paragraph of Section 4=
.4 does not allow clients to detect when overflow has happened. =A0It seems=
 like there are two options: (1) Define the timestamp so it cannot overflow=
 (e.g., as a sufficiently long timestap), or (2) define what an "appro=
priate base value" is so that a client can recognize when the "oc=
-seq" has been reset there. =A0It seems like it would be simplest to i=
mply say that "oc-seq" MUST be an N-bit counter value or a timest=
amp. =A0(Or better, choose one.)



2. "oc=3D0" seems like a bad way to signal th=
at there's no overload going on. =A0"oc-validity=3D0" does th=
at. =A0And if there's no overload condition, on algorithm is being appl=
ied, so no "oc" parameter value needs to be supplied. =A0So it se=
ems like you should signal support with no overload with "oc;oc-validi=
ty=3D0". =A0



3. As written, it seems like Section 5.9 could be read =
to require a behavior that would exacerbate overload conditions with livene=
ss checks. =A0(For example, "periodically" with period 500ms.) =
=A0Suggest that this section recommend a back-off algorithm, possibly with =
some concrete timing paramters. =A0E.g., start at whatever interval you lik=
e, exponential back-off to some floor (say 10sec).



4. The Security Considerations do a good job of describ=
ing the threats that this mechanism introduces, but less so the mitigations=
 to these threats. =A0In particular, there is no mitigation provided for th=
e multi-hop attack, and the mitigation for a malicious client is not clearl=
y stated. =A0Suggest:


-- Recommending that clients enforce a maximum validity period (e.g., =
3600s) in order to limit the scope of spoofing attacks (off-path or multi-h=
op)
-- "Servers SHOULD monitor client behavior to determine =
whether they are complying with overload control policies. =A0If a client i=
s not conforming, then the server SHOULD treat it as a non-supporting clien=
t (Section 5.10.2)."




MINOR:

1. The l=
ast paragraph of Section 2 is tautological. =A0("The normative stateme=
nts...this specification.") =A0If an entity doesn't support this s=
pecification, then of course the normative requirements don't apply! =
=A0Do you mean something different from that?



2. In Section 4.2, it would help if you could say brief=
ly why multiple algorithms are needed. =A0Are some algorithms better suited=
 to different overload conditions? =A0Or could the group just not make up i=
ts mind? =A0(Maybe there's a reference for this?)



3. Mandating that "loss" be included in the l=
ist of supported algorithms seems duplicative. =A0Clients are already requi=
red to support "loss" and put supported algorithms in the list. =
=A0It also seems undesirable for servers to rely on "loss" being =
present, since that could cause problems if for some reason we decide to de=
precate "loss" in the future (cf. [[ SDP codec change ]])



4. It's not clear why the "oc-seq" parame=
ter needs a fractional portion. =A0Wouldn't it be simple just to make i=
t an integer?

5. In Section 5.8, "frequent ch=
anges of overload control algorithm MUST be avoided" -- This is not an=
 RFC 2119 MUST.



6. In Section 5.8, "the algorithm MUST remain in e=
ffect" -> "the server SHOULD NOT change the algorithm for that=
 client" =A0It seems like you wouldn't want to prevent the server =
from changing if it really needed to.



7. In Section 5.10.2, the recommendation at the end see=
ms a little light, and unclear how to implement. =A0You might recommend a s=
imple algorithm to apply here, e.g., just drop everything from non-supporti=
ng clients.



8. In Section 6.1, the last two paragraphs are complete=
ly redundant with the general behavior specified above.

9. The example in Section 6.2 is not specific to the "loss"=
 algorithm. =A0It should be moved up to the top level.



10. Should Section 9 be moved to an appendix?

11. In Section 10, it's not really even necessary to us=
e TLS to prevent spoofing. =A0In many cases just using a connection-oriente=
d protocol like TLS or WS would be sufficient.




Thanks,
--Richard
<=
/div>

--001a11c31242a22e8a04e1509682--

From rlb@ipv.sx  Fri Jul 12 11:57:08 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 5D41921F9FF6 for ; Fri, 12 Jul 2013 11:57:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENHAqwoWgipw for ; Fri, 12 Jul 2013 11:57:02 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 390BC21F9F96 for ; Fri, 12 Jul 2013 11:57:02 -0700 (PDT)
Received: by mail-ob0-f172.google.com with SMTP id wo10so11765190obc.31 for ; Fri, 12 Jul 2013 11:57:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=ErA2OTL0yH13NkRNtS5bxb7z1UZKdzmv+/B6vvK92Xk=; b=oHOwzoizHhNGLqZP+zWTW9uF0tOTHloES4pgFCHVwdKtWFuUWZqY6PdT5fOrqQO+hC 4p5rWYVbnbv0oTy77j410NN2GPCMFoZKfvd1KeYEv2AE2OuuSnez7XWVrBygyHGe1QEq 35VFUNPhF3NUVUbKLPyCVHC3jbzpgIfO/J18a4yWITocZ/4mSaNA90OZ8JMfmpr9+DzP 7xku4PUctuozOSIZX7WLKTIrUOVbxXzjWoEKJD9dFvAXWTYOBGttOeOFVaxGMORm6e79 ikFvkCf05thDKykTk4oJucBvX91839xWPTrrvSoRW9qRAGuc7n1SCYWgNZQAsc9+9I8i mDHw==
MIME-Version: 1.0
X-Received: by 10.182.165.133 with SMTP id yy5mr37029740obb.89.1373655420679;  Fri, 12 Jul 2013 11:57:00 -0700 (PDT)
Received: by 10.60.26.135 with HTTP; Fri, 12 Jul 2013 11:57:00 -0700 (PDT)
X-Originating-IP: [128.89.253.61]
In-Reply-To: 
References:         
Date: Fri, 12 Jul 2013 14:57:00 -0400
Message-ID: 
From: Richard Barnes 
To: Charles Shen 
Content-Type: multipart/alternative; boundary=001a11c2e76a64c47904e15513c7
X-Gm-Message-State: ALoCoQktPivyClU2ghCdY+SKGWrcTdEG7FdpdHw+qvdl1d+OU4RP6t68O+FobcpG8yCdNp4bmrkw
Cc: sip-overload@ietf.org, draft-ietf-soc-load-control-event-package@tools.ietf.org
Subject: Re: [sip-overload] AD review of draft-ietf-soc-load-control-event-package-08
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, 12 Jul 2013 18:57:08 -0000

--001a11c2e76a64c47904e15513c7
Content-Type: text/plain; charset=ISO-8859-1

Keep in mind that you're *extending*, not redefining the RFC 4745 schema
here.

Option 1 doesn't work.  The schema for  in RFC 4745 doesn't allow
for attributes other than "domain".

Option 2 is overkill.  You don't need to define a new  element, you
can just define a new exception element inside of 

Option 3:


  
    
  


Then your extension schema is:



  
  
  








On Thu, Jul 11, 2013 at 11:21 AM, Charles Shen wrote:

> Hi Richard,
>
> After putting up more thoughts on this as I finalize the revision, I feel
> that there are really two options:
>
> Option 1:
>
> 
>     
>         
>         
>     
> 
>
> Option 2:
>
> 
>     
>         
>     
>     
>         
>     
> 
>
> I also attach below the respective changes to the XML of these two
> options. Both will require extended definition of the RFC4745 identity
> element (unless we want to call it a different name), option 1 is cleaner
> in terms of usage. but requires extended definition of not only the RFC4745
> "identity", also RFC4745 "many" and "except", Option 2 requires extended
> definition of RFC4745 "identity" but use separate names to extend "many"
> and "except". Since "many-tel" is independent of "many", everytime we want
> to include group of identities covering both sip and tel uris we have to
> specify both "many" and "many-tel". Is there one option that you prefer
> over the other?
>
> Thanks!
>
> Charles
>
>
>
> OPtion 1: redefinition of identity / many / except
>
>    
>    
>      
>      
>      
>      
>                  minOccurs="0"/>
>                  maxOccurs="unbounded"/>
>      
>      
>    
>
>     
>     
>         
>             
>                 
>                     
>                     
>                     
>                 
>             
>         
>     
>
>     
>     
>         
>             
>                 
>                     
>                                          minOccurs="0" processContents="lax"/>
>                 
>                                  use="optional" type="xs:string"/>
>                                  use="optional" type="xs:string"/>
>             
>         
>     
>
>     
>     
>         
>         
>         
>     
>
>
> OPtion 2: redefinition of identity plus defining additional many-tel /
> except-tel
>
>    
>    
>      
>      
>      
>      
>                  minOccurs="0"/>
>                  maxOccurs="unbounded"/>
>      
>      
>    
>
>     
>     
>         
>             
>                 
>                     
>                     
>                     
>                     
>                 
>             
>         
>     
>     
>     
>         
>             
>                 
>                     
>                                          minOccurs="0" processContents="lax"/>
>                 
>                                  use="optional" type="xs:string"/>
>             
>         
>     
>     
>     
>         
>         
>     
>
>
>
>
>
> On Wed, Jun 26, 2013 at 8:40 AM, Charles Shen wrote:
>
>> This makes a lot of sense, fully agree. Thanks!
>>
>> Charles
>>
>>
>> On Tue, Jun 25, 2013 at 10:52 PM, Richard Barnes  wrote:
>>
>>>
>>>
>>>
>>> On Sun, Jun 23, 2013 at 12:50 AM, Charles Shen wrote:
>>>
>>>> Hi Richard, please see additional questions regarding "tel" URL
>>>> grouping:
>>>>
>>>> On Fri, Jun 21, 2013 at 7:00 AM, Richard Barnes  wrote:
>>>>
>>>>> Inline.  Areas of agreement snipped.
>>>>>
>>>>>
>>>>> On Thu, Jun 20, 2013 at 1:40 AM, Charles Shen >>>> > wrote:
>>>>>
>>>>>> To be clear on this, the ambiguity here is with regard to the >>>>>> domain="..."> case.  In the  case, you just do Tel URI
>>>>>>> comparison.
>>>>>>>
>>>>>>> Thinking on this a little more, it looks like your use of the
>>>>>>> "domain" parameter actually breaks with RFC 4745.  According to RFC 4745,
>>>>>>> there must be an exact match between the "domain" value provided by the
>>>>>>> using protocol and the value in the "domain" parameter.  I can't think of a
>>>>>>> way that this document could define a way to extract a domain from a
>>>>>>> telephone number that would meet the semantic you seem to be intending.
>>>>>>>
>>>>>>> So it seems like you need to do one of the following:
>>>>>>> 1. Define a rule for how you compute a domain value from a tel: URI.
>>>>>>> 2. Define a new element for use under  (since  lacks
>>>>>>> an extension point)
>>>>>>> 3. Drop support for excluding phone numbers by domain (you just have
>>>>>>> to enumerate the exceptions individually)
>>>>>>>
>>>>>>>
>>>>>> [CS] If we opt for Option 1, can we do the following:
>>>>>>
>>>>>> a. assume E.164 numbers always start with + sign, so we can use the
>>>>>> digits after the + sign (after removing any visual separaters, as in the
>>>>>> Tel URL comparison rules) as the presumed domain value.
>>>>>> b. for local numbers (numbers that do not start with +), the
>>>>>> "phone-context" contains the domain value.
>>>>>>
>>>>>
>>>>> Are you sure that gives you the expressiveness you want?  It doesn't
>>>>> allow you to exclude based on an arbitrary prefix.  For example, >>>> domain="+1212"> would not match the URI "tel:+12125551212", because
>>>>> the "domain" value for that URI would be "12125551212".
>>>>>
>>>>> It seems like (2) is the option that's most likely to give you what
>>>>> you want.  Suggest defining something like a "" element, so
>>>>> that you could say something like .
>>>>>
>>>>
>>>>  I am absolutely fine adding another element, but just want to make
>>>> sure I indeed understand your concern before doing that.
>>>>
>>>> According to the current texts (paragraph 2, pg.18), when the specified
>>>> domain value starts with a "+" sign, it denotes a number prefix, if
>>>> its "+1-212", the prefix is "1212" (after removing any visual
>>>> separaters, as in the Tel URL comparison rules, this needs to be added
>>>> explicitly), and this prefix is used to match numbers (again after
>>>> removing any visual separaters), therefore, it should match the number
>>>> "1212551212" in the tel URL tel:+12125551212.
>>>>
>>>> Did I miss something here? thanks!
>>>>
>>>> Charles
>>>>
>>>
>>> I think the concern here isn't with the definition, it's with the fact
>>> that you're "re-interpreting" an existing field.  That's bad for
>>> interoperability, since if one of these policies is provided to an
>>> implementation that doesn't know about the reinterpretation, that
>>> implementation with interpret the field incorrectly.  I agree that the risk
>>> of misinterpretation is pretty low here (since it's buried in a
>>> call-identity element), but it's best to be unambiguous.
>>>
>>> So I would just augment your existing schema to define a new element
>>> with the same semantic you have described above.
>>>
>>> --Richard
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>

--001a11c2e76a64c47904e15513c7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Keep in mind that you're *extending*, not redefin=
ing the RFC 4745 schema here.

Option 1 doesn't work=
. =A0The schema for <except> in RFC 4745 doesn't allow for attrib=
utes other than "domain".


Option 2 is overkill. =A0You don't need to define a new =
<many> element, you can just define a new exception element inside of=
 <many>

Option 3:


<from>
=A0 <many>
=A0 =A0 <except-tel pr=
efix=3D"+1-212-854"/>
=A0 </many>
&l=
t;/from>

Then your extension schema is:



<xs:element name=3D"except-tel" type=3D"except=
TelType"/>
<xs:complexType name=3D"exceptTelType&=
quot;>
=A0 <xs:attribute name=3D"prefix"=
 type=3D"xs:string" use=3D"optional"/>


=A0 <xs:attribute name=3D"id" type=3D"xs:anyURI"=
; use=3D"optional"/>
=A0 <xs:anyAttribute>
</xs:complexType>








On Thu, Jul 11, 2013 at 11:21 AM, Charles Shen=
 <charles@cs.columbia.edu> wrote:


Hi Richard,=A0

After putt=
ing up more thoughts on this as I finalize the revision, I feel that there =
are really two options:



Option 1:

<from>


=A0 =A0 <many>
=A0 =A0 =A0 =A0 <except prefix=3D&qu=
ot;+1-212-854"/>
=A0 =A0 =A0 =A0 <except domain=3D&quo=
t;manhattan.exam=
ple.com"/>


=A0 =A0 </many>



</from>

Option 2:

<=
div><from>
=A0 =A0 <many>
=A0 =A0 =A0 =A0 &=
lt;except domain=3D"manhattan.example.com"/>




=A0 =A0 </many>
=A0 =A0 <many-tel>
=A0=
 =A0 =A0 =A0 <except-tel prefix=3D"+1-212-854"/>
=
=A0 =A0 </many-tel>
</from>

I also attach below the respective changes to the XML of these two op=
tions. Both will require extended definition of the RFC4745 identity elemen=
t (unless we want to call it a different name), option 1 is cleaner in term=
s of usage. but requires extended definition of not only the RFC4745 "=
identity", also RFC4745 "many" and "except", Optio=
n 2 requires extended definition of RFC4745 "identity" but use se=
parate names to extend "many" and "except". Since "=
;many-tel" is independent of "many", everytime we want to in=
clude group of identities covering both sip and tel uris we have to specify=
 both "many" and "many-tel". Is there one option that y=
ou prefer over the other?=A0





Thanks!

Charles

=



OPtion 1: redefinition of ide=
ntity / many / except

=A0 =A0<!-- SIP ID TYPE -=
->




=A0 =A0<xs:complexType name=3D"sip-id-type">
=A0 =A0 =A0<xs:sequence>
=A0 =A0 =A0<element name=3D&qu=
ot;from" type=3D"lc:identityType" minOccurs=3D"0"/=
>
=A0 =A0 =A0<element name=3D"to" type=3D"lc=
:identityType" minOccurs=3D"0"/>




=A0 =A0 =A0<element name=3D"request-uri" type=3D"lc:=
identityType" minOccurs=3D"0"/>
=A0 =A0 =A0<=
element name=3D"p-asserted-identity" type=3D"lc:identityType=
"


=A0 =A0 =A0 =A0 =A0 =A0minOccurs=3D"0"/>


=A0 =A0 =A0<any namespace=3D"##other" processContents=3D&=
quot;lax" minOccurs=3D"0"
=A0 =A0 =A0 =A0 =A0 =A0m=
axOccurs=3D"unbounded"/>
=A0 =A0 =A0</xs:sequence=
>
=A0 =A0 =A0<anyAtrribute namespace=3D"##other" =
processContents=3D"lax"/>




=A0 =A0</xs:complexType>

=A0 =A0 <!-=
- //conditions/identity -->
=A0 =A0 <xs:complexType name=3D=
"identityType">
=A0 =A0 =A0 =A0 <xs:complexConten=
t>
=A0 =A0 =A0 =A0 =A0 =A0 <xs:restriction base=3D"xs:=
anyType">




=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:choice =A0minOccurs=3D"1&q=
uot; maxOccurs=3D"unbounded">
=A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 <xs:element name=3D"one" type=3D"cp:o=
neType"/>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:=
element name=3D"many" type=3D"lc:manyType"/>




=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:any namespace=3D"#=
#other" processContents=3D"lax"/>
=A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 </xs:choice>
=A0 =A0 =A0 =A0 =A0 =A0 &l=
t;/xs:restriction>
=A0 =A0 =A0 =A0 </xs:complexContent><=
/div>



=A0 =A0 </xs:complexType>

=A0 =A0 <!=
-- //identity/many -->
=A0 =A0 <xs:complexType name=3D"=
;manyType">
=A0 =A0 =A0 =A0 <xs:complexContent>
=A0 =A0 =A0 =A0 =A0 =A0 <xs:restriction base=3D"xs:anyType&q=
uot;>




=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:choice minOccurs=3D"0"=
; maxOccurs=3D"unbounded">
=A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 <xs:element name=3D"except" type=3D"lc:ex=
ceptType"/>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <x=
s:any namespace=3D"##other"




=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 minOccurs=3D"0" proc=
essContents=3D"lax"/>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 </xs:choice>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:att=
ribute name=3D"domain"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
use=3D"optional" type=3D"xs:string"/>




=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:attribute name=3D"prefix&q=
uot;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 use=3D"optional" t=
ype=3D"xs:string"/>
=A0 =A0 =A0 =A0 =A0 =A0 </xs:=
restriction>
=A0 =A0 =A0 =A0 </xs:complexContent>




=A0 =A0 </xs:complexType>

=A0 =A0 <!=
-- //many/except -->
=A0 =A0 <xs:complexType name=3D"e=
xceptType">
=A0 =A0 =A0 =A0 <xs:attribute name=3D"=
;domain" type=3D"xs:string" use=3D"optional"/><=
/div>



=A0 =A0 =A0 =A0 <xs:attribute name=3D"prefix" type=3D&quo=
t;xs:string" use=3D"optional"/>
=A0 =A0 =A0 =A0=
 <xs:attribute name=3D"id" type=3D"xs:anyURI" use=3D=
"optional"/>




=A0 =A0 </xs:complexType>


OPtion 2: redefinition of identity plus defining additional many-tel / ex=
cept-tel

=A0 =A0<!-- SIP ID TYPE -->


=A0 =A0<xs:complexType name=3D"sip-id-type">


=A0 =A0 =A0<xs:sequence>
=A0 =A0 =A0<element name=
=3D"from" type=3D"lc:identityType" minOccurs=3D"0&=
quot;/>
=A0 =A0 =A0<element name=3D"to" type=3D&q=
uot;lc:identityType" minOccurs=3D"0"/>




=A0 =A0 =A0<element name=3D"request-uri" type=3D"lc:=
identityType" minOccurs=3D"0"/>
=A0 =A0 =A0<=
element name=3D"p-asserted-identity" type=3D"lc:identityType=
"


=A0 =A0 =A0 =A0 =A0 =A0minOccurs=3D"0"/>


=A0 =A0 =A0<any namespace=3D"##other" processContents=3D&=
quot;lax" minOccurs=3D"0"
=A0 =A0 =A0 =A0 =A0 =A0m=
axOccurs=3D"unbounded"/>
=A0 =A0 =A0</xs:sequence=
>
=A0 =A0 =A0<anyAtrribute namespace=3D"##other" =
processContents=3D"lax"/>




=A0 =A0</xs:complexType>

=A0 =A0 <!-=
- //conditions/identity -->
=A0 =A0 <xs:complexType name=3D=
"identityType">
=A0 =A0 =A0 =A0 <xs:complexConten=
t>
=A0 =A0 =A0 =A0 =A0 =A0 <xs:restriction base=3D"xs:=
anyType">




=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:choice =A0minOccurs=3D"1&q=
uot; maxOccurs=3D"unbounded">
=A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 <xs:element name=3D"one" type=3D"cp:o=
neType"/>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:=
element name=3D"many" type=3D"cp:manyType"/>




=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:element name=3D"ma=
ny-tel" type=3D"lc:many-telType"/>
=A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:any namespace=3D"##other" proc=
essContents=3D"lax"/>



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 </xs:choice>
=A0 =A0 =A0 =
=A0 =A0 =A0 </xs:restriction>
=A0 =A0 =A0 =A0 </xs:compl=
exContent>
=A0 =A0 </xs:complexType>
=A0 =A0 &=
lt;!-- //identity/many-tel -->



=A0 =A0 <xs:complexType name=3D"many-telType">
=
=A0 =A0 =A0 =A0 <xs:complexContent>
=A0 =A0 =A0 =A0 =A0 =A0=
 <xs:restriction base=3D"xs:anyType">
=A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 <xs:choice minOccurs=3D"0" maxOccurs=3D&q=
uot;unbounded">




=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:element name=3D"ex=
ceptTel" type=3D"lc:except-telType"/>
=A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:any namespace=3D"##other"<=
/div>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 minOccurs=3D"0"=
 processContents=3D"lax"/>




=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 </xs:choice>
=A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 <xs:attribute name=3D"domain"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 use=3D"optional" type=3D"x=
s:string"/>
=A0 =A0 =A0 =A0 =A0 =A0 </xs:restriction&g=
t;




=A0 =A0 =A0 =A0 </xs:complexContent>
=A0 =A0 </xs:c=
omplexType>
=A0 =A0 <!-- //many/except -->
=A0=
 =A0 <xs:complexType name=3D"except-telType">
=A0=
 =A0 =A0 =A0 <xs:attribute name=3D"prefix" type=3D"xs:str=
ing" use=3D"optional"/>




=A0 =A0 =A0 =A0 <xs:attribute name=3D"id" type=3D"xs=
:anyURI" use=3D"optional"/>
=A0 =A0 </xs:com=
plexType>









On Wed, Jun 26, 2013 at 8:40 AM, Charles Shen <charles@cs.columbia.e=
du> wrote:



This makes a lot of sense, fully agree. Thanks!

Charles




On Tue, Jun 25, 2013 at 10:52 PM, Richard Barnes <rlb@ipv.sx> wrote=
:





On Sun, Jun 23, 2013 at 12=
:50 AM, Charles Shen <charles@cs.columbia.edu> wrote:<=
br>





Hi Richard, please see additional questions regarding &quo=
t;tel" URL grouping:






On Fri, Jun 21, 2013 at 7:00=
 AM, Richard Barnes <rlb@ipv.sx> wrote:



Inline. =A0Areas of agreement snipped.









On Thu, Jun 20, 2013 at 1:40 AM, Charles Shen <charles@cs.columbia.e=
du> wrote:











To be clear on this, the ambiguity here is with regard to the <exc=
ept domain=3D"..."> case. =A0In the <one id=3D"...&quo=
t;> case, you just do Tel URI comparison.














Thinking on this a little more, it looks like your use =
of the "domain" parameter actually breaks with RFC 4745. =A0Accor=
ding to RFC 4745, there must be an exact match between the "domain&quo=
t; value provided by the using protocol and the value in the "domain&q=
uot; parameter. =A0I can't think of a way that this document could defi=
ne a way to extract a domain from a telephone number that would meet the se=
mantic you seem to be intending.














So it seems like you need to do one of the following:
1. Define a rule for how you compute a domain value from a tel: UR=
I.
2. Define a new element for use under <many> (since <=
except> lacks an extension point)













3. Drop support for excluding phone numbers by domain (you just have t=
o enumerate the exceptions individually)


[CS] If we opt =
for Option 1, can we do the following:












a. assume E.164 numbers always start with + sign, so we=
 can use the digits after the + sign (after removing any visual separaters,=
 as in the Tel URL comparison rules) as the presumed domain value.=A0











b. for local numbers (numbers that do not start with +), the &quo=
t;phone-context" contains the domain value.=A0
=


Are you sure that gives you the expr=
essiveness you want? =A0It doesn't allow you to exclude based on an arb=
itrary prefix. =A0For example, <except domain=3D"+1212"> wo=
uld not match the URI "tel:+12125551212", because the "doma=
in" value for that URI would be "12125551212".










It seems like (2) is the option that's most likely =
to give you what you want. =A0Suggest defining something like a "<e=
xcept-tel>" element, so that you could say something like <excep=
t-tel prefix=3D"+1212">.









=A0I am absolutely=
 fine adding another element, but just want to make sure I indeed understan=
d your concern before doing that.=A0

According to =
the current texts (paragraph 2, pg.18), when the specified domain value sta=
rts with a "+" sign,=A0it denotes a=
 number prefix, if its "+1-212", the prefix is "1212"=
=A0(after=A0removing any visual=
 separaters, as in the Tel URL comparison rules, this needs to be added exp=
licitly), and this prefix is used to match nu=
mbers (again after removing any visual separaters), therefore, it sh=
ould match the number "1212551212" in the tel URL tel:+12125551212.=A0









Did I miss something here? thanks!

Charles



I think=
 the concern here isn't with the definition, it's with the fact tha=
t you're "re-inte=
rpreting" an existing field. =A0That's bad for interoperability, s=
ince if one of these policies is provided to an implementation that doesn&#=
39;t know about the reinterpretation, that implementation with interpret th=
e field incorrectly. =A0I agree that the risk of misinterpretation is prett=
y low here (since it's buried in a call-identity element), but it's=
 best to be unambiguous.







So I would just augment your existing schema to define a=
 new element with the same semantic you have described above.







--Richard



























--001a11c2e76a64c47904e15513c7--

From charles.newyork@gmail.com  Sat Jul 13 10:25:00 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 854AF21F9EE6 for ; Sat, 13 Jul 2013 10:25:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcssF1OAMb3H for ; Sat, 13 Jul 2013 10:24:59 -0700 (PDT)
Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 200F921F9ED3 for ; Sat, 13 Jul 2013 10:24:58 -0700 (PDT)
Received: by mail-la0-f46.google.com with SMTP id eg20so8450942lab.5 for ; Sat, 13 Jul 2013 10:24:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=oPUbM2S1DZR7Wy7zZctH6KF9zggOMXmokHGxjGf+NPI=; b=QvTMRXnL/FCOggxLQh2hCfWRkod8MLANV+oqutfDvRr8mMT1lu3rqvyTMr0y3UDneU 8hNaNtF6FzhX43vCepjmH2DfM3CyVrDY7v3KR1Pe4SvV+yixDiYK3IB5v4viAl7gvxXg LjpxUCKWNrHcrxUUsLehVt6Y2QVaqCSaU+SzPHQix0aLiyzw9+QQoAd6j1BJG4HxL7ic 1N4jSL4yBEgK+KyyB3Hb/bBK01i5aCNSQ5MTO0qJLiyZbHvCGgF8kJXJG8M2pIObiQ7R oEMrK0hO0JhRDBeDeOT44uOi7u0FqN+kLROZ67WwP/n2XaC8N0ps4uSlh5dT/MP93g/J YkFg==
MIME-Version: 1.0
X-Received: by 10.152.43.52 with SMTP id t20mr21595429lal.62.1373736297932; Sat, 13 Jul 2013 10:24:57 -0700 (PDT)
Sender: charles.newyork@gmail.com
Received: by 10.114.187.12 with HTTP; Sat, 13 Jul 2013 10:24:57 -0700 (PDT)
In-Reply-To: 
References:          
Date: Sun, 14 Jul 2013 01:24:57 +0800
X-Google-Sender-Auth: ISlzJ64tH6b5HtqGQzNKFa7U_1E
Message-ID: 
From: Charles Shen 
To: Richard Barnes 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: sip-overload@ietf.org, draft-ietf-soc-load-control-event-package@tools.ietf.org
Subject: Re: [sip-overload] AD review of draft-ietf-soc-load-control-event-package-08
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: Sat, 13 Jul 2013 17:25:00 -0000

Hi Richard,

The reason I think we need to have  is that we also want to
allow the situation when we only filter a group of phone numbers with
the same prefix "eg., +1-212-854", similar to filtering a group of sip
ids with the same domain, e.g., "sip.example.com", if we only use
 we would have to list all available prefixes except that
one, which doesn't seem very plausible. it looks like  in
RFC4745 only accepts "domain" attribute, so we need a  with
the following schema.


        
            
                
                    
                    
                
                
            
        
    

Then we can say



in a way similar to


Is this something you would agree with?

Thanks!

Charles




On Sat, Jul 13, 2013 at 2:57 AM, Richard Barnes  wrote:
>
> Keep in mind that you're *extending*, not redefining the RFC 4745 schema =
here.
>
> Option 1 doesn't work. =C2=A0The schema for  in RFC 4745 doesn't =
allow for attributes other than "domain".
>
> Option 2 is overkill. =C2=A0You don't need to define a new  element=
, you can just define a new exception element inside of 
>
> Option 3:
>
> 
> =C2=A0 
> =C2=A0 =C2=A0 
> =C2=A0 
> 
>
> Then your extension schema is:
>
> 
> 
> =C2=A0 
> =C2=A0 
> =C2=A0 
> 
>
>
>
>
>
>
>
> On Thu, Jul 11, 2013 at 11:21 AM, Charles Shen  =
wrote:
>>
>> Hi Richard,
>>
>> After putting up more thoughts on this as I finalize the revision, I fee=
l that there are really two options:
>>
>> Option 1:
>>
>> 
>> =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 
>> 
>>
>> Option 2:
>>
>> 
>> =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 
>> 
>>
>> I also attach below the respective changes to the XML of these two optio=
ns. Both will require extended definition of the RFC4745 identity element (=
unless we want to call it a different name), option 1 is cleaner in terms o=
f usage. but requires extended definition of not only the RFC4745 "identity=
", also RFC4745 "many" and "except", Option 2 requires extended definition =
of RFC4745 "identity" but use separate names to extend "many" and "except".=
 Since "many-tel" is independent of "many", everytime we want to include gr=
oup of identities covering both sip and tel uris we have to specify both "m=
any" and "many-tel". Is there one option that you prefer over the other?
>>
>> Thanks!
>>
>> Charles
>>
>>
>>
>> OPtion 1: redefinition of identity / many / except
>>
>> =C2=A0 =C2=A0
>> =C2=A0 =C2=A0
>> =C2=A0 =C2=A0 =C2=A0
>> =C2=A0 =C2=A0 =C2=A0
>> =C2=A0 =C2=A0 =C2=A0
>> =C2=A0 =C2=A0 =C2=A0
>> =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0minOccurs=3D"0"/>
>> =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0maxOccurs=3D"unbounded"/>
>> =C2=A0 =C2=A0 =C2=A0
>> =C2=A0 =C2=A0 =C2=A0
>> =C2=A0 =C2=A0
>>
>> =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 
>>
>> =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mi=
nOccurs=3D"0" processContents=3D"lax"/>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 use=3D"optional"=
 type=3D"xs:string"/>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 use=3D"optional"=
 type=3D"xs:string"/>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 
>>
>> =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 
>>
>>
>> OPtion 2: redefinition of identity plus defining additional many-tel / e=
xcept-tel
>>
>> =C2=A0 =C2=A0
>> =C2=A0 =C2=A0
>> =C2=A0 =C2=A0 =C2=A0
>> =C2=A0 =C2=A0 =C2=A0
>> =C2=A0 =C2=A0 =C2=A0
>> =C2=A0 =C2=A0 =C2=A0
>> =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0minOccurs=3D"0"/>
>> =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0maxOccurs=3D"unbounded"/>
>> =C2=A0 =C2=A0 =C2=A0
>> =C2=A0 =C2=A0 =C2=A0
>> =C2=A0 =C2=A0
>>
>> =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mi=
nOccurs=3D"0" processContents=3D"lax"/>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 use=3D"optional"=
 type=3D"xs:string"/>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>> =C2=A0 =C2=A0 
>>
>>
>>
>>
>>
>> On Wed, Jun 26, 2013 at 8:40 AM, Charles Shen  =
wrote:
>>>
>>> This makes a lot of sense, fully agree. Thanks!
>>>
>>> Charles
>>>
>>>
>>> On Tue, Jun 25, 2013 at 10:52 PM, Richard Barnes  wrote:
>>>>
>>>>
>>>>
>>>>
>>>> On Sun, Jun 23, 2013 at 12:50 AM, Charles Shen  wrote:
>>>>>
>>>>> Hi Richard, please see additional questions regarding "tel" URL group=
ing:
>>>>>
>>>>> On Fri, Jun 21, 2013 at 7:00 AM, Richard Barnes  wrote:
>>>>>>
>>>>>> Inline. =C2=A0Areas of agreement snipped.
>>>>>>
>>>>>>
>>>>>> On Thu, Jun 20, 2013 at 1:40 AM, Charles Shen  wrote:
>>>>>>>>
>>>>>>>> To be clear on this, the ambiguity here is with regard to the  case. =C2=A0In the  case, you just do T=
el URI comparison.
>>>>>>>>
>>>>>>>> Thinking on this a little more, it looks like your use of the "dom=
ain" parameter actually breaks with RFC 4745. =C2=A0According to RFC 4745, =
there must be an exact match between the "domain" value provided by the usi=
ng protocol and the value in the "domain" parameter. =C2=A0I can't think of=
 a way that this document could define a way to extract a domain from a tel=
ephone number that would meet the semantic you seem to be intending.
>>>>>>>>
>>>>>>>> So it seems like you need to do one of the following:
>>>>>>>> 1. Define a rule for how you compute a domain value from a tel: UR=
I.
>>>>>>>> 2. Define a new element for use under  (since  lacks=
 an extension point)
>>>>>>>> 3. Drop support for excluding phone numbers by domain (you just ha=
ve to enumerate the exceptions individually)
>>>>>>>>
>>>>>>>
>>>>>>> [CS] If we opt for Option 1, can we do the following:
>>>>>>>
>>>>>>> a. assume E.164 numbers always start with + sign, so we can use the=
 digits after the + sign (after removing any visual separaters, as in the T=
el URL comparison rules) as the presumed domain value.
>>>>>>> b. for local numbers (numbers that do not start with +), the "phone=
-context" contains the domain value.
>>>>>>
>>>>>>
>>>>>> Are you sure that gives you the expressiveness you want? =C2=A0It do=
esn't allow you to exclude based on an arbitrary prefix. =C2=A0For example,=
  would not match the URI "tel:+12125551212", beca=
use the "domain" value for that URI would be "12125551212".
>>>>>>
>>>>>> It seems like (2) is the option that's most likely to give you what =
you want. =C2=A0Suggest defining something like a "" element, s=
o that you could say something like .
>>>>>
>>>>>
>>>>> =C2=A0I am absolutely fine adding another element, but just want to m=
ake sure I indeed understand your concern before doing that.
>>>>>
>>>>> According to the current texts (paragraph 2, pg.18), when the specifi=
ed domain value starts with a "+" sign,=C2=A0it denotes a number prefix, if=
 its "+1-212", the prefix is "1212"=C2=A0(after=C2=A0removing any visual se=
paraters, as in the Tel URL comparison rules, this needs to be added explic=
itly), and this prefix is used to match numbers (again after removing any v=
isual separaters), therefore, it should match the number "1212551212" in th=
e tel URL tel:+12125551212.
>>>>>
>>>>> Did I miss something here? thanks!
>>>>>
>>>>> Charles
>>>>
>>>>
>>>> I think the concern here isn't with the definition, it's with the fact=
 that you're "re-interpreting" an existing field. =C2=A0That's bad for inte=
roperability, since if one of these policies is provided to an implementati=
on that doesn't know about the reinterpretation, that implementation with i=
nterpret the field incorrectly. =C2=A0I agree that the risk of misinterpret=
ation is pretty low here (since it's buried in a call-identity element), bu=
t it's best to be unambiguous.
>>>>
>>>> So I would just augment your existing schema to define a new element w=
ith the same semantic you have described above.
>>>>
>>>> --Richard
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>

From rlb@ipv.sx  Sat Jul 13 13:04:26 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 EE13221F9DA8 for ; Sat, 13 Jul 2013 13:04:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqgfFlFFjNDS for ; Sat, 13 Jul 2013 13:04:07 -0700 (PDT)
Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by ietfa.amsl.com (Postfix) with ESMTP id F10F821F9C4D for ; Sat, 13 Jul 2013 13:04:06 -0700 (PDT)
Received: by mail-oa0-f46.google.com with SMTP id h1so14383077oag.33 for ; Sat, 13 Jul 2013 13:04:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=yZxB0+sjxNwzfXzr+btG6s/1tvqQx78EbdKIgwGZj94=; b=Opc2zL0XwSwravr0aHltT0/VFW/FcuN872g1dA0m1ALFa/hEyublQVWpuzs7T2K1yj edxSkS7OZinr3yYKDUeTaSYmD5GlS9Cs1lZlMNtKQl0of5s5i4sL3JAkX82lsu+6IG7Z yTznYDdcnIXaMo3/UXy/NQBhDpwFsQWsxPGBj5mwyeWheMx93h1VWBSUUrfVLYVonXDX SBy0uUoIrqevXs/QUOW6IdpmMy7aKz3mAHjAtbx7kREgkbcXiLR6hvH3cxHjBtb+jVTQ qVNhq7D4QOYJP13Zuzu3Z44YySQfqHWOg07uT+mOjCoMNZPTh37wiAKXdMfWYr10sE1M d+cw==
MIME-Version: 1.0
X-Received: by 10.182.142.104 with SMTP id rv8mr34754500obb.3.1373745846499; Sat, 13 Jul 2013 13:04:06 -0700 (PDT)
Received: by 10.60.26.135 with HTTP; Sat, 13 Jul 2013 13:04:06 -0700 (PDT)
X-Originating-IP: [108.48.145.202]
In-Reply-To: 
References:           
Date: Sat, 13 Jul 2013 16:04:06 -0400
Message-ID: 
From: Richard Barnes 
To: Charles Shen 
Content-Type: multipart/alternative; boundary=001a11c2eaae31489d04e16a21cc
X-Gm-Message-State: ALoCoQn769mUn2pQZLXybW5oxOwgK+5UMjwvbpM8i/71HxP9kXAtg1i2zI6tkMdPkrBEWK2c0rtv
Cc: sip-overload@ietf.org, draft-ietf-soc-load-control-event-package@tools.ietf.org
Subject: Re: [sip-overload] AD review of draft-ietf-soc-load-control-event-package-08
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: Sat, 13 Jul 2013 20:04:26 -0000

--001a11c2eaae31489d04e16a21cc
Content-Type: text/plain; charset=ISO-8859-1

I see.  That makes sense.  If the WG approves, I would be OK with Option 2.
--Richard


On Sat, Jul 13, 2013 at 1:24 PM, Charles Shen wrote:

> Hi Richard,
>
> The reason I think we need to have  is that we also want to
> allow the situation when we only filter a group of phone numbers with
> the same prefix "eg., +1-212-854", similar to filtering a group of sip
> ids with the same domain, e.g., "sip.example.com", if we only use
>  we would have to list all available prefixes except that
> one, which doesn't seem very plausible. it looks like  in
> RFC4745 only accepts "domain" attribute, so we need a  with
> the following schema.
>
> 
>         
>             
>                 
>                     
>                                          minOccurs="0" processContents="lax"/>
>                 
>                                  use="optional" type="xs:string"/>
>             
>         
>     
>
> Then we can say
>
> 
>
> in a way similar to
>  >
> > Option 2 is overkill.  You don't need to define a new  element,
> you can just define a new exception element inside of 
> >
> > Option 3:
> >
> > 
> >   
> >     
> >   
> > 
> >
> > Then your extension schema is:
> >
> > 
> > 
> >   
> >   
> >   
> > 
> >
> >
> >
> >
> >
> >
> >
> > On Thu, Jul 11, 2013 at 11:21 AM, Charles Shen 
> wrote:
> >>
> >> Hi Richard,
> >>
> >> After putting up more thoughts on this as I finalize the revision, I
> feel that there are really two options:
> >>
> >> Option 1:
> >>
> >> 
> >>     
> >>         
> >>         
> >>     
> >> 
> >>
> >> Option 2:
> >>
> >> 
> >>     
> >>         
> >>     
> >>     
> >>         
> >>     
> >> 
> >>
> >> I also attach below the respective changes to the XML of these two
> options. Both will require extended definition of the RFC4745 identity
> element (unless we want to call it a different name), option 1 is cleaner
> in terms of usage. but requires extended definition of not only the RFC4745
> "identity", also RFC4745 "many" and "except", Option 2 requires extended
> definition of RFC4745 "identity" but use separate names to extend "many"
> and "except". Since "many-tel" is independent of "many", everytime we want
> to include group of identities covering both sip and tel uris we have to
> specify both "many" and "many-tel". Is there one option that you prefer
> over the other?
> >>
> >> Thanks!
> >>
> >> Charles
> >>
> >>
> >>
> >> OPtion 1: redefinition of identity / many / except
> >>
> >>    
> >>    
> >>      
> >>      
> >>      
> >>      
> >>       >>            minOccurs="0"/>
> >>       >>            maxOccurs="unbounded"/>
> >>      
> >>      
> >>    
> >>
> >>     
> >>     
> >>         
> >>             
> >>                 
> >>                     
> >>                     
> >>                     
> >>                 
> >>             
> >>         
> >>     
> >>
> >>     
> >>     
> >>         
> >>             
> >>                 
> >>                     
> >>                      >>                     minOccurs="0" processContents="lax"/>
> >>                 
> >>                  >>                 use="optional" type="xs:string"/>
> >>                  >>                 use="optional" type="xs:string"/>
> >>             
> >>         
> >>     
> >>
> >>     
> >>     
> >>         
> >>         
> >>         
> >>     
> >>
> >>
> >> OPtion 2: redefinition of identity plus defining additional many-tel /
> except-tel
> >>
> >>    
> >>    
> >>      
> >>      
> >>      
> >>      
> >>       >>            minOccurs="0"/>
> >>       >>            maxOccurs="unbounded"/>
> >>      
> >>      
> >>    
> >>
> >>     
> >>     
> >>         
> >>             
> >>                 
> >>                     
> >>                     
> >>                     
> >>                     
> >>                 
> >>             
> >>         
> >>     
> >>     
> >>     
> >>         
> >>             
> >>                 
> >>                      type="lc:except-telType"/>
> >>                      >>                     minOccurs="0" processContents="lax"/>
> >>                 
> >>                  >>                 use="optional" type="xs:string"/>
> >>             
> >>         
> >>     
> >>     
> >>     
> >>         
> >>         
> >>     
> >>
> >>
> >>
> >>
> >>
> >> On Wed, Jun 26, 2013 at 8:40 AM, Charles Shen 
> wrote:
> >>>
> >>> This makes a lot of sense, fully agree. Thanks!
> >>>
> >>> Charles
> >>>
> >>>
> >>> On Tue, Jun 25, 2013 at 10:52 PM, Richard Barnes  wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Sun, Jun 23, 2013 at 12:50 AM, Charles Shen <
> charles@cs.columbia.edu> wrote:
> >>>>>
> >>>>> Hi Richard, please see additional questions regarding "tel" URL
> grouping:
> >>>>>
> >>>>> On Fri, Jun 21, 2013 at 7:00 AM, Richard Barnes  wrote:
> >>>>>>
> >>>>>> Inline.  Areas of agreement snipped.
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Jun 20, 2013 at 1:40 AM, Charles Shen <
> charles@cs.columbia.edu> wrote:
> >>>>>>>>
> >>>>>>>> To be clear on this, the ambiguity here is with regard to the
>  case.  In the  case, you just do Tel
> URI comparison.
> >>>>>>>>
> >>>>>>>> Thinking on this a little more, it looks like your use of the
> "domain" parameter actually breaks with RFC 4745.  According to RFC 4745,
> there must be an exact match between the "domain" value provided by the
> using protocol and the value in the "domain" parameter.  I can't think of a
> way that this document could define a way to extract a domain from a
> telephone number that would meet the semantic you seem to be intending.
> >>>>>>>>
> >>>>>>>> So it seems like you need to do one of the following:
> >>>>>>>> 1. Define a rule for how you compute a domain value from a tel:
> URI.
> >>>>>>>> 2. Define a new element for use under  (since 
> lacks an extension point)
> >>>>>>>> 3. Drop support for excluding phone numbers by domain (you just
> have to enumerate the exceptions individually)
> >>>>>>>>
> >>>>>>>
> >>>>>>> [CS] If we opt for Option 1, can we do the following:
> >>>>>>>
> >>>>>>> a. assume E.164 numbers always start with + sign, so we can use
> the digits after the + sign (after removing any visual separaters, as in
> the Tel URL comparison rules) as the presumed domain value.
> >>>>>>> b. for local numbers (numbers that do not start with +), the
> "phone-context" contains the domain value.
> >>>>>>
> >>>>>>
> >>>>>> Are you sure that gives you the expressiveness you want?  It
> doesn't allow you to exclude based on an arbitrary prefix.  For example,
>  would not match the URI "tel:+12125551212",
> because the "domain" value for that URI would be "12125551212".
> >>>>>>
> >>>>>> It seems like (2) is the option that's most likely to give you what
> you want.  Suggest defining something like a "" element, so
> that you could say something like .
> >>>>>
> >>>>>
> >>>>>  I am absolutely fine adding another element, but just want to make
> sure I indeed understand your concern before doing that.
> >>>>>
> >>>>> According to the current texts (paragraph 2, pg.18), when the
> specified domain value starts with a "+" sign, it denotes a number prefix,
> if its "+1-212", the prefix is "1212" (after removing any visual
> separaters, as in the Tel URL comparison rules, this needs to be added
> explicitly), and this prefix is used to match numbers (again after removing
> any visual separaters), therefore, it should match the number "1212551212"
> in the tel URL tel:+12125551212.
> >>>>>
> >>>>> Did I miss something here? thanks!
> >>>>>
> >>>>> Charles
> >>>>
> >>>>
> >>>> I think the concern here isn't with the definition, it's with the
> fact that you're "re-interpreting" an existing field.  That's bad for
> interoperability, since if one of these policies is provided to an
> implementation that doesn't know about the reinterpretation, that
> implementation with interpret the field incorrectly.  I agree that the risk
> of misinterpretation is pretty low here (since it's buried in a
> call-identity element), but it's best to be unambiguous.
> >>>>
> >>>> So I would just augment your existing schema to define a new element
> with the same semantic you have described above.
> >>>>
> >>>> --Richard
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >
>

--001a11c2eaae31489d04e16a21cc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


I see. =A0That makes sense. =A0If the WG approves, I would=
 be OK with Option 2.
--Richard
<=
br>
On Sat, Jul 13, 2013 at 1:24 PM, Charles =
Shen <charles@cs.columbia.edu> wrote:


Hi Richard,



The reason I think we need to have <many-tel> is that we also want to=


allow the situation when we only filter a group of phone numbers with

the same prefix "eg., +1-212-854", similar to filtering a group o=
f sip

ids with the same domain, e.g., "sip.example.com", if we only use

<exclude-tel> we would have to list all available prefixes except tha=
t

one, which doesn't seem very plausible. it looks like <many> in
RFC4745 only accepts "domain" attribute, so we need a <many-te=
l> with

the following schema.



<xs:complexType name=3D"manyTelType">


=A0 =A0 =A0 =A0 <xs:complexContent>

=A0 =A0 =A0 =A0 =A0 =A0 <xs:restriction base=3D"xs:anyType">=
;

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:choice minOccurs=3D"0" max=
Occurs=3D"unbounded">


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:element name=3D"e=
xceptTel" type=3D"lc:exceptTelType"/>


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:any namesp=
ace=3D"##other"

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 minOccurs=3D"0" processCo=
ntents=3D"lax"/>

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 </xs:choice>


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:attribute na=
me=3D"prefix"

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 use=3D"optional" type=3D"xs:=
string"/>

=A0 =A0 =A0 =A0 =A0 =A0 </xs:restriction>

=A0 =A0 =A0 =A0 </xs:complexContent>

=A0 =A0 </xs:complexType>




Then we can say



<many-tel prefix=3D"+1-212-854"/>



in a way similar to

<many domain=3D"sip.example.com>



Is this something you would agree with?



Thanks!



Charles










On Sat, Jul 13, 2013 at 2:57 AM, Richard Barnes <rlb@ipv.sx> wrote:
>

> Keep in mind that you're *extending*, not redefining the RFC 4745 =
schema here.

>

> Option 1 doesn't work. =A0The schema for <except> in RFC 474=
5 doesn't allow for attributes other than "domain".

>

> Option 2 is overkill. =A0You don't need to define a new <many&g=
t; element, you can just define a new exception element inside of <many&=
gt;

>

> Option 3:

>

> <from>

> =A0 <many>

> =A0 =A0 <except-tel prefix=3D"+1-212-854"/>

> =A0 </many>

> </from>

>

> Then your extension schema is:

>

> <xs:element name=3D"except-tel" type=3D"exceptTelTyp=
e"/>

> <xs:complexType name=3D"exceptTelType">

> =A0 <xs:attribute name=3D"prefix" type=3D"xs:string&=
quot; use=3D"optional"/>

> =A0 <xs:attribute name=3D"id" type=3D"xs:anyURI"=
; use=3D"optional"/>

> =A0 <xs:anyAttribute>

> </xs:complexType>

>

>

>

>

>

>

>

> On Thu, Jul 11, 2013 at 11:21 AM, Charles Shen <charles@cs.columbia.edu> wrote:

>>

>> Hi Richard,

>>

>> After putting up more thoughts on this as I finalize the revision,=
 I feel that there are really two options:

>>

>> Option 1:

>>

>> <from>

>> =A0 =A0 <many>

>> =A0 =A0 =A0 =A0 <except prefix=3D"+1-212-854"/>
>> =A0 =A0 =A0 =A0 <except domain=3D"manhattan.example.com"/>

>> =A0 =A0 </many>

>> </from>

>>

>> Option 2:

>>

>> <from>

>> =A0 =A0 <many>

>> =A0 =A0 =A0 =A0 <except domain=3D"manhattan.example.com"/>

>> =A0 =A0 </many>

>> =A0 =A0 <many-tel>

>> =A0 =A0 =A0 =A0 <except-tel prefix=3D"+1-212-854"/>=
;

>> =A0 =A0 </many-tel>

>> </from>

>>

>> I also attach below the respective changes to the XML of these two=
 options. Both will require extended definition of the RFC4745 identity ele=
ment (unless we want to call it a different name), option 1 is cleaner in t=
erms of usage. but requires extended definition of not only the RFC4745 &qu=
ot;identity", also RFC4745 "many" and "except", Op=
tion 2 requires extended definition of RFC4745 "identity" but use=
 separate names to extend "many" and "except". Since &q=
uot;many-tel" is independent of "many", everytime we want to=
 include group of identities covering both sip and tel uris we have to spec=
ify both "many" and "many-tel". Is there one option tha=
t you prefer over the other?


>>

>> Thanks!

>>

>> Charles

>>

>>

>>

>> OPtion 1: redefinition of identity / many / except

>>

>> =A0 =A0<!-- SIP ID TYPE -->

>> =A0 =A0<xs:complexType name=3D"sip-id-type">

>> =A0 =A0 =A0<xs:sequence>

>> =A0 =A0 =A0<element name=3D"from" type=3D"lc:ide=
ntityType" minOccurs=3D"0"/>

>> =A0 =A0 =A0<element name=3D"to" type=3D"lc:ident=
ityType" minOccurs=3D"0"/>

>> =A0 =A0 =A0<element name=3D"request-uri" type=3D"=
;lc:identityType" minOccurs=3D"0"/>

>> =A0 =A0 =A0<element name=3D"p-asserted-identity" type=
=3D"lc:identityType"

>> =A0 =A0 =A0 =A0 =A0 =A0minOccurs=3D"0"/>

>> =A0 =A0 =A0<any namespace=3D"##other" processContents=
=3D"lax" minOccurs=3D"0"

>> =A0 =A0 =A0 =A0 =A0 =A0maxOccurs=3D"unbounded"/>

>> =A0 =A0 =A0</xs:sequence>

>> =A0 =A0 =A0<anyAtrribute namespace=3D"##other" proces=
sContents=3D"lax"/>

>> =A0 =A0</xs:complexType>

>>

>> =A0 =A0 <!-- //conditions/identity -->

>> =A0 =A0 <xs:complexType name=3D"identityType">

>> =A0 =A0 =A0 =A0 <xs:complexContent>

>> =A0 =A0 =A0 =A0 =A0 =A0 <xs:restriction base=3D"xs:anyType=
">

>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:choice =A0minOccurs=3D"=
;1" maxOccurs=3D"unbounded">

>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:element name=3D&quo=
t;one" type=3D"cp:oneType"/>

>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:element name=3D&quo=
t;many" type=3D"lc:manyType"/>

>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:any namespace=3D&qu=
ot;##other" processContents=3D"lax"/>

>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 </xs:choice>

>> =A0 =A0 =A0 =A0 =A0 =A0 </xs:restriction>

>> =A0 =A0 =A0 =A0 </xs:complexContent>

>> =A0 =A0 </xs:complexType>

>>

>> =A0 =A0 <!-- //identity/many -->

>> =A0 =A0 <xs:complexType name=3D"manyType">

>> =A0 =A0 =A0 =A0 <xs:complexContent>

>> =A0 =A0 =A0 =A0 =A0 =A0 <xs:restriction base=3D"xs:anyType=
">

>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:choice minOccurs=3D"0&=
quot; maxOccurs=3D"unbounded">

>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:element name=3D&quo=
t;except" type=3D"lc:exceptType"/>

>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:any namespace=3D&qu=
ot;##other"

>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 minOccurs=3D"0" =
processContents=3D"lax"/>

>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 </xs:choice>

>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:attribute name=3D"doma=
in"

>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 use=3D"optional" type=3D=
"xs:string"/>

>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:attribute name=3D"pref=
ix"

>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 use=3D"optional" type=3D=
"xs:string"/>

>> =A0 =A0 =A0 =A0 =A0 =A0 </xs:restriction>

>> =A0 =A0 =A0 =A0 </xs:complexContent>

>> =A0 =A0 </xs:complexType>

>>

>> =A0 =A0 <!-- //many/except -->

>> =A0 =A0 <xs:complexType name=3D"exceptType">

>> =A0 =A0 =A0 =A0 <xs:attribute name=3D"domain" type=3D=
"xs:string" use=3D"optional"/>

>> =A0 =A0 =A0 =A0 <xs:attribute name=3D"prefix" type=3D=
"xs:string" use=3D"optional"/>

>> =A0 =A0 =A0 =A0 <xs:attribute name=3D"id" type=3D&quo=
t;xs:anyURI" use=3D"optional"/>

>> =A0 =A0 </xs:complexType>

>>

>>

>> OPtion 2: redefinition of identity plus defining additional many-t=
el / except-tel

>>

>> =A0 =A0<!-- SIP ID TYPE -->

>> =A0 =A0<xs:complexType name=3D"sip-id-type">

>> =A0 =A0 =A0<xs:sequence>

>> =A0 =A0 =A0<element name=3D"from" type=3D"lc:ide=
ntityType" minOccurs=3D"0"/>

>> =A0 =A0 =A0<element name=3D"to" type=3D"lc:ident=
ityType" minOccurs=3D"0"/>

>> =A0 =A0 =A0<element name=3D"request-uri" type=3D"=
;lc:identityType" minOccurs=3D"0"/>

>> =A0 =A0 =A0<element name=3D"p-asserted-identity" type=
=3D"lc:identityType"

>> =A0 =A0 =A0 =A0 =A0 =A0minOccurs=3D"0"/>

>> =A0 =A0 =A0<any namespace=3D"##other" processContents=
=3D"lax" minOccurs=3D"0"

>> =A0 =A0 =A0 =A0 =A0 =A0maxOccurs=3D"unbounded"/>

>> =A0 =A0 =A0</xs:sequence>

>> =A0 =A0 =A0<anyAtrribute namespace=3D"##other" proces=
sContents=3D"lax"/>

>> =A0 =A0</xs:complexType>

>>

>> =A0 =A0 <!-- //conditions/identity -->

>> =A0 =A0 <xs:complexType name=3D"identityType">

>> =A0 =A0 =A0 =A0 <xs:complexContent>

>> =A0 =A0 =A0 =A0 =A0 =A0 <xs:restriction base=3D"xs:anyType=
">

>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:choice =A0minOccurs=3D"=
;1" maxOccurs=3D"unbounded">

>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:element name=3D&quo=
t;one" type=3D"cp:oneType"/>

>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:element name=3D&quo=
t;many" type=3D"cp:manyType"/>

>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:element name=3D&quo=
t;many-tel" type=3D"lc:many-telType"/>

>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:any namespace=3D&qu=
ot;##other" processContents=3D"lax"/>

>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 </xs:choice>

>> =A0 =A0 =A0 =A0 =A0 =A0 </xs:restriction>

>> =A0 =A0 =A0 =A0 </xs:complexContent>

>> =A0 =A0 </xs:complexType>

>> =A0 =A0 <!-- //identity/many-tel -->

>> =A0 =A0 <xs:complexType name=3D"many-telType">

>> =A0 =A0 =A0 =A0 <xs:complexContent>

>> =A0 =A0 =A0 =A0 =A0 =A0 <xs:restriction base=3D"xs:anyType=
">

>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:choice minOccurs=3D"0&=
quot; maxOccurs=3D"unbounded">

>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:element name=3D&quo=
t;exceptTel" type=3D"lc:except-telType"/>

>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:any namespace=3D&qu=
ot;##other"

>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 minOccurs=3D"0" =
processContents=3D"lax"/>

>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 </xs:choice>

>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xs:attribute name=3D"doma=
in"

>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 use=3D"optional" type=3D=
"xs:string"/>

>> =A0 =A0 =A0 =A0 =A0 =A0 </xs:restriction>

>> =A0 =A0 =A0 =A0 </xs:complexContent>

>> =A0 =A0 </xs:complexType>

>> =A0 =A0 <!-- //many/except -->

>> =A0 =A0 <xs:complexType name=3D"except-telType">
>> =A0 =A0 =A0 =A0 <xs:attribute name=3D"prefix" type=3D=
"xs:string" use=3D"optional"/>

>> =A0 =A0 =A0 =A0 <xs:attribute name=3D"id" type=3D&quo=
t;xs:anyURI" use=3D"optional"/>

>> =A0 =A0 </xs:complexType>

>>

>>

>>

>>

>>

>> On Wed, Jun 26, 2013 at 8:40 AM, Charles Shen <charles@cs.columbia.edu> wrote:

>>>

>>> This makes a lot of sense, fully agree. Thanks!

>>>

>>> Charles

>>>

>>>

>>> On Tue, Jun 25, 2013 at 10:52 PM, Richard Barnes <rlb@ipv.s=
x> wrote:

>>>>

>>>>

>>>>

>>>>

>>>> On Sun, Jun 23, 2013 at 12:50 AM, Charles Shen <charles@cs.columbia.edu> wrote:<=
br>
>>>>>

>>>>> Hi Richard, please see additional questions regarding =
"tel" URL grouping:

>>>>>

>>>>> On Fri, Jun 21, 2013 at 7:00 AM, Richard Barnes <rl=
b@ipv.sx> wrote:

>>>>>>

>>>>>> Inline. =A0Areas of agreement snipped.

>>>>>>

>>>>>>

>>>>>> On Thu, Jun 20, 2013 at 1:40 AM, Charles Shen <=
charles@cs.columbia.edu> =
wrote:

>>>>>>>>

>>>>>>>> To be clear on this, the ambiguity here is=
 with regard to the <except domain=3D"..."> case. =A0In the=
 <one id=3D"..."> case, you just do Tel URI comparison.

>>>>>>>>

>>>>>>>> Thinking on this a little more, it looks l=
ike your use of the "domain" parameter actually breaks with RFC 4=
745. =A0According to RFC 4745, there must be an exact match between the &qu=
ot;domain" value provided by the using protocol and the value in the &=
quot;domain" parameter. =A0I can't think of a way that this docume=
nt could define a way to extract a domain from a telephone number that woul=
d meet the semantic you seem to be intending.


>>>>>>>>

>>>>>>>> So it seems like you need to do one of the=
 following:

>>>>>>>> 1. Define a rule for how you compute a dom=
ain value from a tel: URI.

>>>>>>>> 2. Define a new element for use under <=
many> (since <except> lacks an extension point)

>>>>>>>> 3. Drop support for excluding phone number=
s by domain (you just have to enumerate the exceptions individually)

>>>>>>>>

>>>>>>>

>>>>>>> [CS] If we opt for Option 1, can we do the fol=
lowing:

>>>>>>>

>>>>>>> a. assume E.164 numbers always start with + si=
gn, so we can use the digits after the + sign (after removing any visual se=
paraters, as in the Tel URL comparison rules) as the presumed domain value.=



>>>>>>> b. for local numbers (numbers that do not star=
t with +), the "phone-context" contains the domain value.

>>>>>>

>>>>>>

>>>>>> Are you sure that gives you the expressiveness you=
 want? =A0It doesn't allow you to exclude based on an arbitrary prefix.=
 =A0For example, <except domain=3D"+1212"> would not match =
the URI "tel:+12=
125551212", because the "domain" value for that URI woul=
d be "12125551212".


>>>>>>

>>>>>> It seems like (2) is the option that's most li=
kely to give you what you want. =A0Suggest defining something like a "=
<except-tel>" element, so that you could say something like <=
except-tel prefix=3D"+1212">.


>>>>>

>>>>>

>>>>> =A0I am absolutely fine adding another element, but ju=
st want to make sure I indeed understand your concern before doing that.
>>>>>

>>>>> According to the current texts (paragraph 2, pg.18), w=
hen the specified domain value starts with a "+" sign,=A0it denot=
es a number prefix, if its "+1-212", the prefix is "1212&quo=
t;=A0(after=A0removing any visual separaters, as in the Tel URL comparison =
rules, this needs to be added explicitly), and this prefix is used to match=
 numbers (again after removing any visual separaters), therefore, it should=
 match the number "1212551212" in the tel URL tel:+12125551212.

>>>>>

>>>>> Did I miss something here? thanks!

>>>>>

>>>>> Charles

>>>>

>>>>

>>>> I think the concern here isn't with the definition, it=
's with the fact that you're "re-interpreting" an existin=
g field. =A0That's bad for interoperability, since if one of these poli=
cies is provided to an implementation that doesn't know about the reint=
erpretation, that implementation with interpret the field incorrectly. =A0I=
 agree that the risk of misinterpretation is pretty low here (since it'=
s buried in a call-identity element), but it's best to be unambiguous.<=
br>

>>>>

>>>> So I would just augment your existing schema to define a n=
ew element with the same semantic you have described above.

>>>>

>>>> --Richard

>>>>

>>>>

>>>>

>>>>

>>>>

>>>>

>>>>

>>>

>>

>





--001a11c2eaae31489d04e16a21cc--

From charles.newyork@gmail.com  Sun Jul 14 08:28: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 DB5A221F9E6E for ; Sun, 14 Jul 2013 08:28:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+AcAREPyJZq for ; Sun, 14 Jul 2013 08:28:11 -0700 (PDT)
Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id F101521F9C93 for ; Sun, 14 Jul 2013 08:28:10 -0700 (PDT)
Received: by mail-oa0-f41.google.com with SMTP id n10so14994552oag.28 for ; Sun, 14 Jul 2013 08:28:09 -0700 (PDT)
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=z6LHnOxynAnp8R5Zue85k8kL+l6muBzrNm3JtbMjEQY=; b=gXNZG4ZUnP/FjgLyk/eYDeMz4YOOppRhmI1gzvUT8f26SZcuZ9x4R3l2v5WWrm+wmb 5k0Fl3oL0ue7S6mrGKTE4C4Y5kYCLQkCzVPuVCY9cBDlNqE74ICtx8N0SDrOjbe4ZJrC 8uj/5xCtkOGLl30Yds74fm8f+ixJoQY0yKhQwNcdmgPbI5/rGHxWUB348jd+x65bDSKd A9W5K0X1SMZa+FCRK4J9deEmHtLmKugOXGDbgYM+xxiWXqj4O/WF4ihTdGFpikuucFPU ns/Ra0Bt59EWiF9NaLbv/NemB4fwbrxpRBG6Bod9CWyj0fSu8s7VVy7hPXzfm6wksMI1 x0nA==
X-Received: by 10.182.110.226 with SMTP id id2mr40849500obb.95.1373815689465;  Sun, 14 Jul 2013 08:28:09 -0700 (PDT)
MIME-Version: 1.0
Sender: charles.newyork@gmail.com
Received: by 10.182.112.131 with HTTP; Sun, 14 Jul 2013 08:27:48 -0700 (PDT)
In-Reply-To: 
References:            
From: Charles Shen 
Date: Sun, 14 Jul 2013 23:27:48 +0800
X-Google-Sender-Auth: 7AzKk75adrQhBCqVV5Xjmx7_1vc
Message-ID: 
To: Richard Barnes 
Content-Type: multipart/alternative; boundary=089e0112ce202859cf04e17a64ab
Cc: sip-overload@ietf.org, draft-ietf-soc-load-control-event-package@tools.ietf.org
Subject: Re: [sip-overload] AD review of draft-ietf-soc-load-control-event-package-08
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: Sun, 14 Jul 2013 15:28:13 -0000

--089e0112ce202859cf04e17a64ab
Content-Type: text/plain; charset=UTF-8

Great and thank you!

On Sun, Jul 14, 2013 at 4:04 AM, Richard Barnes  wrote:

> I see.  That makes sense.  If the WG approves, I would be OK with Option 2.
> --Richard
>
>
> On Sat, Jul 13, 2013 at 1:24 PM, Charles Shen wrote:
>
>> Hi Richard,
>>
>> The reason I think we need to have  is that we also want to
>> allow the situation when we only filter a group of phone numbers with
>> the same prefix "eg., +1-212-854", similar to filtering a group of sip
>> ids with the same domain, e.g., "sip.example.com", if we only use
>>  we would have to list all available prefixes except that
>> one, which doesn't seem very plausible. it looks like  in
>> RFC4745 only accepts "domain" attribute, so we need a  with
>> the following schema.
>>
>> 
>>         
>>             
>>                 
>>                     
>>                     >                     minOccurs="0" processContents="lax"/>
>>                 
>>                 >                 use="optional" type="xs:string"/>
>>             
>>         
>>     
>>
>> Then we can say
>>
>> 
>>
>> in a way similar to
>> > >
>> > Option 2 is overkill.  You don't need to define a new  element,
>> you can just define a new exception element inside of 
>> >
>> > Option 3:
>> >
>> > 
>> >   
>> >     
>> >   
>> > 
>> >
>> > Then your extension schema is:
>> >
>> > 
>> > 
>> >   
>> >   
>> >   
>> > 
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Thu, Jul 11, 2013 at 11:21 AM, Charles Shen 
>> wrote:
>> >>
>> >> Hi Richard,
>> >>
>> >> After putting up more thoughts on this as I finalize the revision, I
>> feel that there are really two options:
>> >>
>> >> Option 1:
>> >>
>> >> 
>> >>     
>> >>         
>> >>         
>> >>     
>> >> 
>> >>
>> >> Option 2:
>> >>
>> >> 
>> >>     
>> >>         
>> >>     
>> >>     
>> >>         
>> >>     
>> >> 
>> >>
>> >> I also attach below the respective changes to the XML of these two
>> options. Both will require extended definition of the RFC4745 identity
>> element (unless we want to call it a different name), option 1 is cleaner
>> in terms of usage. but requires extended definition of not only the RFC4745
>> "identity", also RFC4745 "many" and "except", Option 2 requires extended
>> definition of RFC4745 "identity" but use separate names to extend "many"
>> and "except". Since "many-tel" is independent of "many", everytime we want
>> to include group of identities covering both sip and tel uris we have to
>> specify both "many" and "many-tel". Is there one option that you prefer
>> over the other?
>> >>
>> >> Thanks!
>> >>
>> >> Charles
>> >>
>> >>
>> >>
>> >> OPtion 1: redefinition of identity / many / except
>> >>
>> >>    
>> >>    
>> >>      
>> >>      
>> >>      
>> >>      
>> >>      > >>            minOccurs="0"/>
>> >>      > >>            maxOccurs="unbounded"/>
>> >>      
>> >>      
>> >>    
>> >>
>> >>     
>> >>     
>> >>         
>> >>             
>> >>                 
>> >>                     
>> >>                     
>> >>                     
>> >>                 
>> >>             
>> >>         
>> >>     
>> >>
>> >>     
>> >>     
>> >>         
>> >>             
>> >>                 
>> >>                     
>> >>                     > >>                     minOccurs="0" processContents="lax"/>
>> >>                 
>> >>                 > >>                 use="optional" type="xs:string"/>
>> >>                 > >>                 use="optional" type="xs:string"/>
>> >>             
>> >>         
>> >>     
>> >>
>> >>     
>> >>     
>> >>         
>> >>         
>> >>         
>> >>     
>> >>
>> >>
>> >> OPtion 2: redefinition of identity plus defining additional many-tel /
>> except-tel
>> >>
>> >>    
>> >>    
>> >>      
>> >>      
>> >>      
>> >>      
>> >>      > >>            minOccurs="0"/>
>> >>      > >>            maxOccurs="unbounded"/>
>> >>      
>> >>      
>> >>    
>> >>
>> >>     
>> >>     
>> >>         
>> >>             
>> >>                 
>> >>                     
>> >>                     
>> >>                     > type="lc:many-telType"/>
>> >>                     
>> >>                 
>> >>             
>> >>         
>> >>     
>> >>     
>> >>     
>> >>         
>> >>             
>> >>                 
>> >>                     > type="lc:except-telType"/>
>> >>                     > >>                     minOccurs="0" processContents="lax"/>
>> >>                 
>> >>                 > >>                 use="optional" type="xs:string"/>
>> >>             
>> >>         
>> >>     
>> >>     
>> >>     
>> >>         
>> >>         
>> >>     
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On Wed, Jun 26, 2013 at 8:40 AM, Charles Shen 
>> wrote:
>> >>>
>> >>> This makes a lot of sense, fully agree. Thanks!
>> >>>
>> >>> Charles
>> >>>
>> >>>
>> >>> On Tue, Jun 25, 2013 at 10:52 PM, Richard Barnes  wrote:
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Sun, Jun 23, 2013 at 12:50 AM, Charles Shen <
>> charles@cs.columbia.edu> wrote:
>> >>>>>
>> >>>>> Hi Richard, please see additional questions regarding "tel" URL
>> grouping:
>> >>>>>
>> >>>>> On Fri, Jun 21, 2013 at 7:00 AM, Richard Barnes  wrote:
>> >>>>>>
>> >>>>>> Inline.  Areas of agreement snipped.
>> >>>>>>
>> >>>>>>
>> >>>>>> On Thu, Jun 20, 2013 at 1:40 AM, Charles Shen <
>> charles@cs.columbia.edu> wrote:
>> >>>>>>>>
>> >>>>>>>> To be clear on this, the ambiguity here is with regard to the
>>  case.  In the  case, you just do Tel
>> URI comparison.
>> >>>>>>>>
>> >>>>>>>> Thinking on this a little more, it looks like your use of the
>> "domain" parameter actually breaks with RFC 4745.  According to RFC 4745,
>> there must be an exact match between the "domain" value provided by the
>> using protocol and the value in the "domain" parameter.  I can't think of a
>> way that this document could define a way to extract a domain from a
>> telephone number that would meet the semantic you seem to be intending.
>> >>>>>>>>
>> >>>>>>>> So it seems like you need to do one of the following:
>> >>>>>>>> 1. Define a rule for how you compute a domain value from a tel:
>> URI.
>> >>>>>>>> 2. Define a new element for use under  (since 
>> lacks an extension point)
>> >>>>>>>> 3. Drop support for excluding phone numbers by domain (you just
>> have to enumerate the exceptions individually)
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>> [CS] If we opt for Option 1, can we do the following:
>> >>>>>>>
>> >>>>>>> a. assume E.164 numbers always start with + sign, so we can use
>> the digits after the + sign (after removing any visual separaters, as in
>> the Tel URL comparison rules) as the presumed domain value.
>> >>>>>>> b. for local numbers (numbers that do not start with +), the
>> "phone-context" contains the domain value.
>> >>>>>>
>> >>>>>>
>> >>>>>> Are you sure that gives you the expressiveness you want?  It
>> doesn't allow you to exclude based on an arbitrary prefix.  For example,
>>  would not match the URI "tel:+12125551212",
>> because the "domain" value for that URI would be "12125551212".
>> >>>>>>
>> >>>>>> It seems like (2) is the option that's most likely to give you
>> what you want.  Suggest defining something like a "" element,
>> so that you could say something like .
>> >>>>>
>> >>>>>
>> >>>>>  I am absolutely fine adding another element, but just want to make
>> sure I indeed understand your concern before doing that.
>> >>>>>
>> >>>>> According to the current texts (paragraph 2, pg.18), when the
>> specified domain value starts with a "+" sign, it denotes a number prefix,
>> if its "+1-212", the prefix is "1212" (after removing any visual
>> separaters, as in the Tel URL comparison rules, this needs to be added
>> explicitly), and this prefix is used to match numbers (again after removing
>> any visual separaters), therefore, it should match the number "1212551212"
>> in the tel URL tel:+12125551212.
>> >>>>>
>> >>>>> Did I miss something here? thanks!
>> >>>>>
>> >>>>> Charles
>> >>>>
>> >>>>
>> >>>> I think the concern here isn't with the definition, it's with the
>> fact that you're "re-interpreting" an existing field.  That's bad for
>> interoperability, since if one of these policies is provided to an
>> implementation that doesn't know about the reinterpretation, that
>> implementation with interpret the field incorrectly.  I agree that the risk
>> of misinterpretation is pretty low here (since it's buried in a
>> call-identity element), but it's best to be unambiguous.
>> >>>>
>> >>>> So I would just augment your existing schema to define a new element
>> with the same semantic you have described above.
>> >>>>
>> >>>> --Richard
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>
>> >>
>> >
>>
>
>

--089e0112ce202859cf04e17a64ab
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Great and thank you!

On Sun, Jul 14, 2013=
 at 4:04 AM, Richard Barnes <rlb@ipv.sx> wrote:



I see. =C2=A0That makes sense. =C2=A0If the WG approves, I=
 would be OK with Option 2.<=
div>--Richard




On Sat, Jul 13, 2013 at 1:24 PM, Charles=
 Shen <charles@cs.columbia.edu> wrote:


Hi Richard,



The reason I think we need to have <many-tel> is that we also want to=


allow the situation when we only filter a group of phone numbers with

the same prefix "eg., +1-212-854", similar to filtering a group o=
f sip

ids with the same domain, e.g., "sip.example.com", if we only use

<exclude-tel> we would have to list all available prefixes except tha=
t

one, which doesn't seem very plausible. it looks like <many> in
RFC4745 only accepts "domain" attribute, so we need a <many-te=
l> with

the following schema.



<xs:complexType name=3D"manyTelType">


=C2=A0 =C2=A0 =C2=A0 =C2=A0 <xs:complexContent>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <xs:restriction base=3D"x=
s:anyType">

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <xs:choice minOc=
curs=3D"0" maxOccurs=3D"unbounded">


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 <xs:element name=3D"exceptTel" type=3D"lc:exceptTelType&=
quot;/>


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
<xs:any namespace=3D"##other"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 minOc=
curs=3D"0" processContents=3D"lax"/>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </xs:choice><=
br>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <xs:a=
ttribute name=3D"prefix"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 use=3D"optiona=
l" type=3D"xs:string"/>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </xs:restriction>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 </xs:complexContent>

=C2=A0 =C2=A0 </xs:complexType>




Then we can say



<many-tel prefix=3D"+1-212-854"/>



in a way similar to

<many domain=3D"sip.example.com>



Is this something you would agree with?



Thanks!



Charles










On Sat, Jul 13, 2013 at 2:57 AM, Richard Barnes <rlb@ipv.sx> wrote:
>

> Keep in mind that you're *extending*, not redefining the RFC 4745 =
schema here.

>

> Option 1 doesn't work. =C2=A0The schema for <except> in RFC =
4745 doesn't allow for attributes other than "domain".

>

> Option 2 is overkill. =C2=A0You don't need to define a new <man=
y> element, you can just define a new exception element inside of <ma=
ny>

>

> Option 3:

>

> <from>

> =C2=A0 <many>

> =C2=A0 =C2=A0 <except-tel prefix=3D"+1-212-854"/>

> =C2=A0 </many>

> </from>

>

> Then your extension schema is:

>

> <xs:element name=3D"except-tel" type=3D"exceptTelTyp=
e"/>

> <xs:complexType name=3D"exceptTelType">

> =C2=A0 <xs:attribute name=3D"prefix" type=3D"xs:stri=
ng" use=3D"optional"/>

> =C2=A0 <xs:attribute name=3D"id" type=3D"xs:anyURI&q=
uot; use=3D"optional"/>

> =C2=A0 <xs:anyAttribute>

> </xs:complexType>

>

>

>

>

>

>

>

> On Thu, Jul 11, 2013 at 11:21 AM, Charles Shen <charles@cs.columbia.edu> w=
rote:

>>

>> Hi Richard,

>>

>> After putting up more thoughts on this as I finalize the revision,=
 I feel that there are really two options:

>>

>> Option 1:

>>

>> <from>

>> =C2=A0 =C2=A0 <many>

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <except prefix=3D"+1-212-854&q=
uot;/>

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <except domain=3D"manhattan.example.com&qu=
ot;/>

>> =C2=A0 =C2=A0 </many>

>> </from>

>>

>> Option 2:

>>

>> <from>

>> =C2=A0 =C2=A0 <many>

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <except domain=3D"manhattan.example.com&qu=
ot;/>

>> =C2=A0 =C2=A0 </many>

>> =C2=A0 =C2=A0 <many-tel>

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <except-tel prefix=3D"+1-212-8=
54"/>

>> =C2=A0 =C2=A0 </many-tel>

>> </from>

>>

>> I also attach below the respective changes to the XML of these two=
 options. Both will require extended definition of the RFC4745 identity ele=
ment (unless we want to call it a different name), option 1 is cleaner in t=
erms of usage. but requires extended definition of not only the RFC4745 &qu=
ot;identity", also RFC4745 "many" and "except", Op=
tion 2 requires extended definition of RFC4745 "identity" but use=
 separate names to extend "many" and "except". Since &q=
uot;many-tel" is independent of "many", everytime we want to=
 include group of identities covering both sip and tel uris we have to spec=
ify both "many" and "many-tel". Is there one option tha=
t you prefer over the other?




>>

>> Thanks!

>>

>> Charles

>>

>>

>>

>> OPtion 1: redefinition of identity / many / except

>>

>> =C2=A0 =C2=A0<!-- SIP ID TYPE -->

>> =C2=A0 =C2=A0<xs:complexType name=3D"sip-id-type">=


>> =C2=A0 =C2=A0 =C2=A0<xs:sequence>

>> =C2=A0 =C2=A0 =C2=A0<element name=3D"from" type=3D&qu=
ot;lc:identityType" minOccurs=3D"0"/>

>> =C2=A0 =C2=A0 =C2=A0<element name=3D"to" type=3D"=
;lc:identityType" minOccurs=3D"0"/>

>> =C2=A0 =C2=A0 =C2=A0<element name=3D"request-uri" typ=
e=3D"lc:identityType" minOccurs=3D"0"/>

>> =C2=A0 =C2=A0 =C2=A0<element name=3D"p-asserted-identity&q=
uot; type=3D"lc:identityType"

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0minOccurs=3D"0"=
/>

>> =C2=A0 =C2=A0 =C2=A0<any namespace=3D"##other" proces=
sContents=3D"lax" minOccurs=3D"0"

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0maxOccurs=3D"unbound=
ed"/>

>> =C2=A0 =C2=A0 =C2=A0</xs:sequence>

>> =C2=A0 =C2=A0 =C2=A0<anyAtrribute namespace=3D"##other&quo=
t; processContents=3D"lax"/>

>> =C2=A0 =C2=A0</xs:complexType>

>>

>> =C2=A0 =C2=A0 <!-- //conditions/identity -->

>> =C2=A0 =C2=A0 <xs:complexType name=3D"identityType"&g=
t;

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <xs:complexContent>

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <xs:restriction base=
=3D"xs:anyType">

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <xs:cho=
ice =C2=A0minOccurs=3D"1" maxOccurs=3D"unbounded">
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 <xs:element name=3D"one" type=3D"cp:oneType"/>=
;

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 <xs:element name=3D"many" type=3D"lc:manyType"/&=
gt;

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 <xs:any namespace=3D"##other" processContents=3D"lax&=
quot;/>

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </xs:ch=
oice>

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </xs:restriction><=
br>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 </xs:complexContent>

>> =C2=A0 =C2=A0 </xs:complexType>

>>

>> =C2=A0 =C2=A0 <!-- //identity/many -->

>> =C2=A0 =C2=A0 <xs:complexType name=3D"manyType">
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <xs:complexContent>

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <xs:restriction base=
=3D"xs:anyType">

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <xs:cho=
ice minOccurs=3D"0" maxOccurs=3D"unbounded">

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 <xs:element name=3D"except" type=3D"lc:exceptType&quo=
t;/>

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 <xs:any namespace=3D"##other"

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 minOccurs=3D"0" processContents=3D"lax"/>

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </xs:ch=
oice>

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <xs:att=
ribute name=3D"domain"

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 use=3D&quo=
t;optional" type=3D"xs:string"/>

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <xs:att=
ribute name=3D"prefix"

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 use=3D&quo=
t;optional" type=3D"xs:string"/>

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </xs:restriction><=
br>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 </xs:complexContent>

>> =C2=A0 =C2=A0 </xs:complexType>

>>

>> =C2=A0 =C2=A0 <!-- //many/except -->

>> =C2=A0 =C2=A0 <xs:complexType name=3D"exceptType">=


>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <xs:attribute name=3D"domain&q=
uot; type=3D"xs:string" use=3D"optional"/>

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <xs:attribute name=3D"prefix&q=
uot; type=3D"xs:string" use=3D"optional"/>

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <xs:attribute name=3D"id"=
 type=3D"xs:anyURI" use=3D"optional"/>

>> =C2=A0 =C2=A0 </xs:complexType>

>>

>>

>> OPtion 2: redefinition of identity plus defining additional many-t=
el / except-tel

>>

>> =C2=A0 =C2=A0<!-- SIP ID TYPE -->

>> =C2=A0 =C2=A0<xs:complexType name=3D"sip-id-type">=


>> =C2=A0 =C2=A0 =C2=A0<xs:sequence>

>> =C2=A0 =C2=A0 =C2=A0<element name=3D"from" type=3D&qu=
ot;lc:identityType" minOccurs=3D"0"/>

>> =C2=A0 =C2=A0 =C2=A0<element name=3D"to" type=3D"=
;lc:identityType" minOccurs=3D"0"/>

>> =C2=A0 =C2=A0 =C2=A0<element name=3D"request-uri" typ=
e=3D"lc:identityType" minOccurs=3D"0"/>

>> =C2=A0 =C2=A0 =C2=A0<element name=3D"p-asserted-identity&q=
uot; type=3D"lc:identityType"

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0minOccurs=3D"0"=
/>

>> =C2=A0 =C2=A0 =C2=A0<any namespace=3D"##other" proces=
sContents=3D"lax" minOccurs=3D"0"

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0maxOccurs=3D"unbound=
ed"/>

>> =C2=A0 =C2=A0 =C2=A0</xs:sequence>

>> =C2=A0 =C2=A0 =C2=A0<anyAtrribute namespace=3D"##other&quo=
t; processContents=3D"lax"/>

>> =C2=A0 =C2=A0</xs:complexType>

>>

>> =C2=A0 =C2=A0 <!-- //conditions/identity -->

>> =C2=A0 =C2=A0 <xs:complexType name=3D"identityType"&g=
t;

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <xs:complexContent>

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <xs:restriction base=
=3D"xs:anyType">

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <xs:cho=
ice =C2=A0minOccurs=3D"1" maxOccurs=3D"unbounded">
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 <xs:element name=3D"one" type=3D"cp:oneType"/>=
;

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 <xs:element name=3D"many" type=3D"cp:manyType"/&=
gt;

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 <xs:element name=3D"many-tel" type=3D"lc:many-telType=
"/>

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 <xs:any namespace=3D"##other" processContents=3D"lax&=
quot;/>

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </xs:ch=
oice>

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </xs:restriction><=
br>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 </xs:complexContent>

>> =C2=A0 =C2=A0 </xs:complexType>

>> =C2=A0 =C2=A0 <!-- //identity/many-tel -->

>> =C2=A0 =C2=A0 <xs:complexType name=3D"many-telType"&g=
t;

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <xs:complexContent>

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <xs:restriction base=
=3D"xs:anyType">

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <xs:cho=
ice minOccurs=3D"0" maxOccurs=3D"unbounded">

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 <xs:element name=3D"exceptTel" type=3D"lc:except-telT=
ype"/>

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 <xs:any namespace=3D"##other"

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 minOccurs=3D"0" processContents=3D"lax"/>

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </xs:ch=
oice>

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <xs:att=
ribute name=3D"domain"

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 use=3D&quo=
t;optional" type=3D"xs:string"/>

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </xs:restriction><=
br>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 </xs:complexContent>

>> =C2=A0 =C2=A0 </xs:complexType>

>> =C2=A0 =C2=A0 <!-- //many/except -->

>> =C2=A0 =C2=A0 <xs:complexType name=3D"except-telType"=
>

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <xs:attribute name=3D"prefix&q=
uot; type=3D"xs:string" use=3D"optional"/>

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <xs:attribute name=3D"id"=
 type=3D"xs:anyURI" use=3D"optional"/>

>> =C2=A0 =C2=A0 </xs:complexType>

>>

>>

>>

>>

>>

>> On Wed, Jun 26, 2013 at 8:40 AM, Charles Shen <charles@cs.columbia.edu>=
; wrote:

>>>

>>> This makes a lot of sense, fully agree. Thanks!

>>>

>>> Charles

>>>

>>>

>>> On Tue, Jun 25, 2013 at 10:52 PM, Richard Barnes <rlb@ipv.s=
x> wrote:

>>>>

>>>>

>>>>

>>>>

>>>> On Sun, Jun 23, 2013 at 12:50 AM, Charles Shen <charles@cs.columbia.e=
du> wrote:

>>>>>

>>>>> Hi Richard, please see additional questions regarding =
"tel" URL grouping:

>>>>>

>>>>> On Fri, Jun 21, 2013 at 7:00 AM, Richard Barnes <rl=
b@ipv.sx> wrote:

>>>>>>

>>>>>> Inline. =C2=A0Areas of agreement snipped.

>>>>>>

>>>>>>

>>>>>> On Thu, Jun 20, 2013 at 1:40 AM, Charles Shen <=
charles@cs.col=
umbia.edu> wrote:

>>>>>>>>

>>>>>>>> To be clear on this, the ambiguity here is=
 with regard to the <except domain=3D"..."> case. =C2=A0In =
the <one id=3D"..."> case, you just do Tel URI comparison.<=
br>
>>>>>>>>

>>>>>>>> Thinking on this a little more, it looks l=
ike your use of the "domain" parameter actually breaks with RFC 4=
745. =C2=A0According to RFC 4745, there must be an exact match between the =
"domain" value provided by the using protocol and the value in th=
e "domain" parameter. =C2=A0I can't think of a way that this =
document could define a way to extract a domain from a telephone number tha=
t would meet the semantic you seem to be intending.




>>>>>>>>

>>>>>>>> So it seems like you need to do one of the=
 following:

>>>>>>>> 1. Define a rule for how you compute a dom=
ain value from a tel: URI.

>>>>>>>> 2. Define a new element for use under <=
many> (since <except> lacks an extension point)

>>>>>>>> 3. Drop support for excluding phone number=
s by domain (you just have to enumerate the exceptions individually)

>>>>>>>>

>>>>>>>

>>>>>>> [CS] If we opt for Option 1, can we do the fol=
lowing:

>>>>>>>

>>>>>>> a. assume E.164 numbers always start with + si=
gn, so we can use the digits after the + sign (after removing any visual se=
paraters, as in the Tel URL comparison rules) as the presumed domain value.=





>>>>>>> b. for local numbers (numbers that do not star=
t with +), the "phone-context" contains the domain value.

>>>>>>

>>>>>>

>>>>>> Are you sure that gives you the expressiveness you=
 want? =C2=A0It doesn't allow you to exclude based on an arbitrary pref=
ix. =C2=A0For example, <except domain=3D"+1212"> would not =
match the URI "tel:+12125551212", because the "domain"=
 value for that URI would be "12125551212".




>>>>>>

>>>>>> It seems like (2) is the option that's most li=
kely to give you what you want. =C2=A0Suggest defining something like a &qu=
ot;<except-tel>" element, so that you could say something like &=
lt;except-tel prefix=3D"+1212">.




>>>>>

>>>>>

>>>>> =C2=A0I am absolutely fine adding another element, but=
 just want to make sure I indeed understand your concern before doing that.=


>>>>>

>>>>> According to the current texts (paragraph 2, pg.18), w=
hen the specified domain value starts with a "+" sign,=C2=A0it de=
notes a number prefix, if its "+1-212", the prefix is "1212&=
quot;=C2=A0(after=C2=A0removing any visual separaters, as in the Tel URL co=
mparison rules, this needs to be added explicitly), and this prefix is used=
 to match numbers (again after removing any visual separaters), therefore, =
it should match the number "1212551212" in the tel URL tel:+12125551=
212.




>>>>>

>>>>> Did I miss something here? thanks!

>>>>>

>>>>> Charles

>>>>

>>>>

>>>> I think the concern here isn't with the definition, it=
's with the fact that you're "re-interpreting" an existin=
g field. =C2=A0That's bad for interoperability, since if one of these p=
olicies is provided to an implementation that doesn't know about the re=
interpretation, that implementation with interpret the field incorrectly. =
=C2=A0I agree that the risk of misinterpretation is pretty low here (since =
it's buried in a call-identity element), but it's best to be unambi=
guous.




>>>>

>>>> So I would just augment your existing schema to define a n=
ew element with the same semantic you have described above.

>>>>

>>>> --Richard

>>>>

>>>>

>>>>

>>>>

>>>>

>>>>

>>>>

>>>

>>

>

--089e0112ce202859cf04e17a64ab-- From charles.newyork@gmail.com Sun Jul 14 08:38:48 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 8990321F9E1D for ; Sun, 14 Jul 2013 08:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2J4OrCQS443u for ; Sun, 14 Jul 2013 08:38:47 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD0121F9E05 for ; Sun, 14 Jul 2013 08:38:46 -0700 (PDT) Received: by mail-ob0-f178.google.com with SMTP id fb19so13014485obc.23 for ; Sun, 14 Jul 2013 08:38:45 -0700 (PDT) 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=0APe5lEWFH4qqDH4afQ8rFr1gDXJXXuPL5Ojq3GGt2o=; b=Sl0odBkqheUKIgnlG+rRD9d/ySC/QHivDCXLmMJV/LwqummJmeofFnwLiN6shQx9g4 B8dkSZAjLUDEaI+D6d0jtl0bYcEORpMGoeD0xaulOm6DZeB5O49AgdxXDF2LlMwkPtf0 qvqOt4jDVnQi4pu9vfNqc67IZ9/9GVjtiPbjaIrCgnDdlHySE3bvcptDVVqTUj/fa8lv ijecyGiHgGcDZae6nEjJU2oe8PpJmV2FBthlzjekf+DtoVG3zhrae1ANKij7bByyuRO/ +Yk0XF7LaVN0Ey0J5oXZ6wbVuQesiXwX3bKcu+GGKFa5tmQI3fm5AaUgXh/E7Zhf4A3T 7gcg== X-Received: by 10.60.145.173 with SMTP id sv13mr40969223oeb.63.1373816325540; Sun, 14 Jul 2013 08:38:45 -0700 (PDT) MIME-Version: 1.0 Sender: charles.newyork@gmail.com Received: by 10.182.112.131 with HTTP; Sun, 14 Jul 2013 08:38:25 -0700 (PDT) In-Reply-To: References: From: Charles Shen Date: Sun, 14 Jul 2013 23:38:25 +0800 X-Google-Sender-Auth: 5yVjamrm3XR3SfsWqsX88QYESoo Message-ID: To: Richard Barnes Content-Type: multipart/alternative; boundary=047d7b5d532a1210a804e17a8aea Cc: sip-overload@ietf.org, draft-ietf-soc-load-control-event-package@tools.ietf.org Subject: Re: [sip-overload] AD review of draft-ietf-soc-load-control-event-package-08 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: Sun, 14 Jul 2013 15:38:48 -0000 --047d7b5d532a1210a804e17a8aea Content-Type: text/plain; charset=UTF-8 Hi Richard, for your comment on "trusted domain" >> [CS] How about phrasing it as being applicable "within trusted >> intra-domain and/or trusted inter-domain" scenarios? >> > > We really need to be clear here about what "trusted" means. ("Trusted" is > a word that makes Security ADs pounce :) ) What is each party "trusted" > not to do? If you look at RFC 3325, it lays out exactly what the parties > need to be agree on before they use P-Asserted-ID. I think an analogous > list of criteria is needed here. > > >From RFC 3324/3325, "A key requirement is that the behavior of all nodes within a given Trust Domain 'T' is known to comply to a certain set of specifications known as 'Spec(T)'." Therefore, if we define the "Trusted Domain" for load control, we must define what Spec(T) means for this document. RFC 3325 listed the following for its use with "P-Asserted-Identity" 1. The manner in which users are authenticated 2. The mechanisms used to secure the communication among nodes within the Trust Domain 3. The mechanisms used to secure the communication between UAs and nodes within the Trust Domain 4. The manner used to determine which hosts are part of the Trust Domain 5. The default privacy handling when no Privacy header field is present 6. That nodes in the Trust Domain are compliant to SIP [1] 7. That nodes in the Trust Domain are compliant to this document 8. Privacy handling for identity as described in Section 7. My revision in progress considers 2, 4, 6, 7 as applicable in our load control context - basically the UA and Privacy handling is not applicable in our case. Therefore, an example (non-nomative) Spec(T) for a trusted domain of load control can be as below 1. Protocol requirements The following specifications MUST be supported: 1) RFC 3261 2) RFC (this load control specification number) 2. Security requirements Connections between nodes within the Trust Domain in the Trust Domain MUST use TLS using a cipher suite of RSA_WITH_AES_128_CBC_SHA1. Mutual authentication between nodes in the trust domain MUST be performed and confidentiality MUST be negotiated. 3. Scope of Trust Domain The Trust Domain specified in this agreement consists of hosts which posses a valid certificate which is a) signed by examplerootca.org; b) whose subjectAltName ends with one of the following domain names: trusted.div1.carrier-a.net,trusted.div2.carrier-a.net, sip.carrier-b.com; and c) whose domain name corresponds to the hostname in the subjectAltName in the certificate. Is this OK with you or do you have any additional thoughts? thanks! Charles On Thu, Jun 20, 2013 at 1:40 PM, Charles Shen wrote: > Hi Richard, Thank you for the follow up, please see some comments below. > > On Sat, Jun 15, 2013 at 4:32 AM, Richard Barnes wrote: > >> >>>> >>> [CS] How about phrasing it as being applicable "within trusted >>> intra-domain and/or trusted inter-domain" scenarios? >>> >> >> We really need to be clear here about what "trusted" means. ("Trusted" >> is a word that makes Security ADs pounce :) ) What is each party "trusted" >> not to do? If you look at RFC 3325, it lays out exactly what the parties >> need to be agree on before they use P-Asserted-ID. I think an analogous >> list of criteria is needed here. >> > > [CS] It makes a lot of sense to adopt RFC3325/3324 notion of Trusted > domains, I will work on that. > > > >> I agree, let's do option (2). Suggested text: >> """ >> This document does not define the content of SUBSCRIBE bodies. Future >> specifications could define bodies for SUBSCRIBE messages, for example to >> request specific types of load control event notifications. >> """ >> > > [CS] Will do. > > >> >> To be clear on this, the ambiguity here is with regard to the > domain="..."> case. In the case, you just do Tel URI >> comparison. >> >> Thinking on this a little more, it looks like your use of the "domain" >> parameter actually breaks with RFC 4745. According to RFC 4745, there must >> be an exact match between the "domain" value provided by the using protocol >> and the value in the "domain" parameter. I can't think of a way that this >> document could define a way to extract a domain from a telephone number >> that would meet the semantic you seem to be intending. >> >> So it seems like you need to do one of the following: >> 1. Define a rule for how you compute a domain value from a tel: URI. >> 2. Define a new element for use under (since lacks an >> extension point) >> 3. Drop support for excluding phone numbers by domain (you just have to >> enumerate the exceptions individually) >> >> > [CS] If we opt for Option 1, can we do the following: > > a. assume E.164 numbers always start with + sign, so we can use the digits > after the + sign (after removing any visual separaters, as in the Tel URL > comparison rules) as the presumed domain value. > b. for local numbers (numbers that do not start with +), the > "phone-context" contains the domain value. > > > >> [CS] It seems to me that how to enforce the rate/window/percent becomes >>> more implementation specific, and these action items are what the rest of >>> the WG documents (http://datatracker.ietf.org/wg/soc/) are using as >>> well. The first paragraph of Section 7.4 also referenced RFC6357 on more >>> details about these actions. Therefore, I am not sure what more concrete >>> actions you are referring to, could you please elaborate a bit on this? >>> >> >> I can live with this answer. >> >> > [CS] OK > > >> To be clear, the concern here isn't about a policy that combines two >> actions in the same rule. The concern is when two rules match the same >> call, in which case both actions must be applied. >> >> For example suppose you have the following rule set: >> RULE 1: Reject all calls from example.com >> -- Conditions: >> -- Actions: 0 >> RULE 2: Redirect all calls from alice@example.com >> -- Conditions: >> -- Actions: 0 >> >> It doesn't seem like there's a sensible way to combine those rules. In >> principle, it seems like the simplest thing would be to say that a policy >> MUST NOT specify two rules that could apply to the same SIP message. Would >> people feel comfortable that you could efficiently check this exclusivity? >> It does scale as the square of the number of rules. >> >> > [CS] Very good point. We propose an easy "the first-match rule", i.e., > the call is handled based on the first rule that matches. What do you > think? > > >> >>> [CS] "simple drop" here means simply ignoring the request without doing >>> anything. i.e., in the reliable transport case, it does not have to close >>> the transport connection. It still saves some processing needed in sending >>> out the rejection in reliable transport. But I am open to eleminating it if >>> the group prefers so. >>> >> >> It would help if you could add that clarification to "simple drop". >> > > [CS] Will do. In addition, "Simple drop seems good for dealing with > telephony DOS attacks" > > Thanks! > > Charles > > > >> >> Thanks, >> --Richard >> >> _______________________________________________ >> sip-overload mailing list >> sip-overload@ietf.org >> https://www.ietf.org/mailman/listinfo/sip-overload >> >> > --047d7b5d532a1210a804e17a8aea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Richard, for your comment on "= ;trusted domain"=C2=A0



[CS] How about phrasing it as being= applicable "within trusted intra-domain and/or trusted inter-domain&q= uot; scenarios?=C2=A0

We really= need to be clear here about what "trusted" means. =C2=A0("T= rusted" is a word that makes Security ADs pounce :) ) =C2=A0What is ea= ch party "trusted" not to do? =C2=A0If you look at RFC 3325, it l= ays out exactly what the parties need to be agree on before they use P-Asse= rted-ID. =C2=A0 I think an analogous list of criteria is needed here.



From RFC 3324/3325, "A= key requirement is that the behavior of all nodes within a given Trust Dom= ain 'T' is known to comply to a certain set of specifications known= as 'Spec(T)'." Therefore, if we define the "Trusted Doma= in" for load control, we must define what Spec(T) means for this docum= ent. RFC 3325 listed the following for its use with "P-Asserted-Identi= ty"=C2=A0

1. The manner in which users are authenticated=C2=A0
2. The mechanisms used to secure the communication amo= ng nodes within the Trust Domain=C2=A0
3. The mechanisms used to secure the = communication between UAs and nodes within the Trust Domain=C2=A0
4. The manner used to determine which hosts are part of the Trust Domain=C2= =A0
5. The default privacy handl= ing when no Privacy header field is present=C2=A0
6. That nodes in the Trust Domain are= compliant to SIP [1]=C2=A0
7. That nodes in the Trust Domain are compliant to this document=C2=A0
8. Privacy handling for identity as = described in Section 7.=C2=A0

My revision in progress considers 2, 4, 6, 7 as applicable in our load cont= rol context - basically the UA and Privacy handling is not applicable in ou= r case.=C2=A0

Therefore, an example (non-= nomative) Spec(T) for a trusted domain of load control can be as below

1. Protocol requirements

The following specifications MUST be supported:=C2=A0
1) RFC 3261=C2=A0
2) RFC (this load control specification number)

2. Security requirements

Connections between nodes within the Trust Domain in the Trust Domain MUST = use TLS using a cipher suite of RSA_WITH_AES_128_CBC_SHA1. Mutual authentic= ation between nodes in the trust domain MUST be performed and confidentiali= ty MUST be negotiated.

3. Scope of Trust Domain

The Trust Domain specified in this agreement consists of hosts which posses= a valid certificate which is a) signed by=C2=A0examplerootca.o= rg; b) whose subjectAltName ends with one of the following domain names= : =C2=A0trusted.div1.carrier-a.net,trusted.div2.carrier-a.net,=C2=A0sip.carrier-b.com; and c) whose domain name corresponds to the hostname in the subjectAltNa= me in the certificate.

Is this OK with you or do you have any additional thoug= hts?=C2=A0

thanks!

Charle= s




On Thu, Jun 20, 2013 at 1:40 PM, Charles Shen <charles@cs.columbia.e= du> wrote:
Hi Richard, Thank you for the follow up, please see some comments below.
On Sat, Jun 15, 2013 at = 4:32 AM, Richard Barnes <rlb@ipv.sx> wrote:


[CS] How = about phrasing it as being applicable "within trusted intra-domain and= /or trusted inter-domain" scenarios?=C2=A0

We really need to = be clear here about what "trusted" means. =C2=A0("Trusted&qu= ot; is a word that makes Security ADs pounce :) ) =C2=A0What is each party = "trusted" not to do? =C2=A0If you look at RFC 3325, it lays out e= xactly what the parties need to be agree on before they use P-Asserted-ID. = =C2=A0 I think an analogous list of criteria is needed here.

[CS] It make= s a lot of sense to adopt RFC3325/3324 notion of Trusted domains, I will wo= rk on that.=C2=A0

=C2=A0
I agree, let's do option (2). =C2=A0Suggested text:
"""
This document does not define the content of S= UBSCRIBE bodies. =C2=A0Future specifications could define bodies for SUBSCR= IBE messages, for example to request specific types of load control event n= otifications.
"""

[CS] Will do.
=C2=A0

To be clear on this, the ambiguity here is = with regard to the <except domain=3D"..."> case. =C2=A0In t= he <one id=3D"..."> case, you just do Tel URI comparison.

Thinking on this a little more, it looks like your use = of the "domain" parameter actually breaks with RFC 4745. =C2=A0Ac= cording to RFC 4745, there must be an exact match between the "domain&= quot; value provided by the using protocol and the value in the "domai= n" parameter. =C2=A0I can't think of a way that this document coul= d define a way to extract a domain from a telephone number that would meet = the semantic you seem to be intending.

So it seems like you need to do one of the following:
1. Define a rule for how you compute a domain value from a tel: UR= I.
2. Define a new element for use under <many> (since <= except> lacks an extension point)
3. Drop support for excluding phone numbers by domain (you just have t= o enumerate the exceptions individually)


[CS] If we opt = for Option 1, can we do the following:

a. assume E.164 numbers always start with + sign, so we= can use the digits after the + sign (after removing any visual separaters,= as in the Tel URL comparison rules) as the presumed domain value.=C2=A0
b. for local numbers (numbers that do not start with +), the &quo= t;phone-context" contains the domain value.=C2=A0

=
=C2=A0
[CS] It seems to me that how to e= nforce the rate/window/percent becomes more implementation specific, and th= ese action items are what the rest of the WG documents (http://datatracker.ietf.org/= wg/soc/) are using as well. The first paragraph of Section 7.4 also ref= erenced RFC6357 on more details about these actions. Therefore, I am not su= re what more concrete actions you are referring to, could you please elabor= ate a bit on this?

= I can live with this answer.


[CS] OK
=C2=A0
To be clear, the concern here isn't about a policy that combines = two actions in the same rule. =C2=A0The concern is when two rules match the= same call, in which case both actions must be applied.

For example suppose you have the following rule set:
RULE 1: Reject all calls from example.com=C2=A0
-- Conditions: <from><= identity><many domain=3D"example.com"/></identity></from>
-- Actions: <accept alt-action=3D"reject"><rate>= 0</rate></accept>
RULE 2: Redirect all calls from alice@example.com
-- Conditions: <from><identity><one id=3D"sip:alice@example.com= "/></identity></from>
-- Actions: <accept alt-action=3D"redirect" alt-target=3D= "sip:eve@ex= ample.com"><rate>0</rate></accept>
=
It doesn't seem like there's a sensible way to combine t= hose rules. =C2=A0In principle, it seems like the simplest thing would be t= o say that a policy MUST NOT specify two rules that could apply to the same= SIP message. =C2=A0Would people feel comfortable that you could efficientl= y check this exclusivity? =C2=A0It does scale as the square of the number o= f rules.


[CS] Very good point. We propose an=C2=A0easy= "the first-match rule", i.e., the call is handled based on the f= irst rule that matches.=C2=A0What do you think?= =C2=A0
=C2=A0

[CS] &q= uot;simple drop" here means simply ignoring the request without doing = anything. =C2=A0i.e., in the reliable transport case, it does not have to c= lose the transport connection. It still saves some processing needed in sen= ding out the rejection in reliable transport. But I am open to eleminating = it if the group prefers so.=C2=A0

It would help if y= ou could add that clarification to "simple drop". =C2=A0

[CS] Will do. I= n addition, "Simple drop seems good for dealing wi= th telephony DOS attacks"

Thanks!<= /span>

Charles<= /span>

=C2=A0

Thanks,
--Richard=C2=A0

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



--047d7b5d532a1210a804e17a8aea-- From shida@ntt-at.com Mon Jul 15 19:49: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 19BF711E81C0 for ; Mon, 15 Jul 2013 19:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.661 X-Spam-Level: X-Spam-Status: No, score=-101.661 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jd3v5wp3KrjJ for ; Mon, 15 Jul 2013 19:49:32 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFE811E817B for ; Mon, 15 Jul 2013 19:49:31 -0700 (PDT) Received: from [50.152.169.249] (port=51564 helo=[192.168.1.8]) by gator465.hostgator.com with esmtpa (Exim 4.80) (envelope-from ) id 1UyvKS-00019F-F2; Mon, 15 Jul 2013 21:49:28 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_073F8013-52D2-48B8-B426-CEBC8BC4E4F0" From: Shida Schubert In-Reply-To: Date: Mon, 15 Jul 2013 19:49:27 -0700 Message-Id: <215A826D-A1A0-4EB2-9E07-7B19AF3783C1@ntt-at.com> References: To: Charles Shen X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.8]) [50.152.169.249]:51564 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 4 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: sip-overload@ietf.org, draft-ietf-soc-load-control-event-package@tools.ietf.org Subject: Re: [sip-overload] AD review of draft-ietf-soc-load-control-event-package-08 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, 16 Jul 2013 02:49:37 -0000 --Apple-Mail=_073F8013-52D2-48B8-B426-CEBC8BC4E4F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Charles; Hmm.. As far as I can recall RFC3325 references Spec(T) BUT it doesn't=20= reference it normatively.=20 Second paragraph of section 11. in RFC3325.=20 The remainder of this section presents an example Spec(T), which is not normative in any way. Actually security consideration in RFC3325 rather keeps the mechanism=20= to secure the channels open.=20 The use of transport or network layer hop-by-hop security mechanisms, such as TLS or IPSec with appropriate cipher suites, can satisfy this requirement. I think most of the implementations that will comply to use this will = not use=20 TLS and mandating TLS doesn't make sense. I think text in the line of = what=20 RFC3325 should be sufficient for security consideration in the = SOC-evnet-package=20 as well. Regards Shida =20 On Jul 14, 2013, at 8:38 AM, Charles Shen wrote: > Hi Richard, for your comment on "trusted domain"=20 >=20 >=20 >=20 > [CS] How about phrasing it as being applicable "within trusted = intra-domain and/or trusted inter-domain" scenarios?=20 >=20 > We really need to be clear here about what "trusted" means. = ("Trusted" is a word that makes Security ADs pounce :) ) What is each = party "trusted" not to do? If you look at RFC 3325, it lays out exactly = what the parties need to be agree on before they use P-Asserted-ID. I = think an analogous list of criteria is needed here. >=20 >=20 >=20 > =46rom RFC 3324/3325, "A key requirement is that the behavior of all = nodes within a given Trust Domain 'T' is known to comply to a certain = set of specifications known as 'Spec(T)'." Therefore, if we define the = "Trusted Domain" for load control, we must define what Spec(T) means for = this document. RFC 3325 listed the following for its use with = "P-Asserted-Identity"=20 >=20 > 1. The manner in which users are authenticated=20 > 2. The mechanisms used to secure the communication among nodes within = the Trust Domain=20 > 3. The mechanisms used to secure the communication between UAs and = nodes within the Trust Domain=20 > 4. The manner used to determine which hosts are part of the Trust = Domain=20 > 5. The default privacy handling when no Privacy header field is = present=20 > 6. That nodes in the Trust Domain are compliant to SIP [1]=20 > 7. That nodes in the Trust Domain are compliant to this document=20 > 8. Privacy handling for identity as described in Section 7.=20 >=20 > My revision in progress considers 2, 4, 6, 7 as applicable in our load = control context - basically the UA and Privacy handling is not = applicable in our case.=20 >=20 > Therefore, an example (non-nomative) Spec(T) for a trusted domain of = load control can be as below >=20 > 1. Protocol requirements >=20 > The following specifications MUST be supported:=20 > 1) RFC 3261=20 > 2) RFC (this load control specification number) >=20 > 2. Security requirements >=20 > Connections between nodes within the Trust Domain in the Trust Domain = MUST use TLS using a cipher suite of RSA_WITH_AES_128_CBC_SHA1. Mutual = authentication between nodes in the trust domain MUST be performed and = confidentiality MUST be negotiated. >=20 > 3. Scope of Trust Domain >=20 > The Trust Domain specified in this agreement consists of hosts which = posses a valid certificate which is a) signed by examplerootca.org; b) = whose subjectAltName ends with one of the following domain names: = trusted.div1.carrier-a.net,trusted.div2.carrier-a.net, = sip.carrier-b.com; and c) whose domain name corresponds to the hostname = in the subjectAltName in the certificate. >=20 > Is this OK with you or do you have any additional thoughts?=20 >=20 > thanks! >=20 > Charles >=20 >=20 >=20 >=20 > On Thu, Jun 20, 2013 at 1:40 PM, Charles Shen = wrote: > Hi Richard, Thank you for the follow up, please see some comments = below. >=20 > On Sat, Jun 15, 2013 at 4:32 AM, Richard Barnes wrote: >=20 >=20 > [CS] How about phrasing it as being applicable "within trusted = intra-domain and/or trusted inter-domain" scenarios?=20 >=20 > We really need to be clear here about what "trusted" means. = ("Trusted" is a word that makes Security ADs pounce :) ) What is each = party "trusted" not to do? If you look at RFC 3325, it lays out exactly = what the parties need to be agree on before they use P-Asserted-ID. I = think an analogous list of criteria is needed here. >=20 > [CS] It makes a lot of sense to adopt RFC3325/3324 notion of Trusted = domains, I will work on that.=20 >=20 > =20 > I agree, let's do option (2). Suggested text: > """ > This document does not define the content of SUBSCRIBE bodies. Future = specifications could define bodies for SUBSCRIBE messages, for example = to request specific types of load control event notifications. > """ >=20 > [CS] Will do. > =20 >=20 > To be clear on this, the ambiguity here is with regard to the case. In the case, you just do Tel URI = comparison. >=20 > Thinking on this a little more, it looks like your use of the "domain" = parameter actually breaks with RFC 4745. According to RFC 4745, there = must be an exact match between the "domain" value provided by the using = protocol and the value in the "domain" parameter. I can't think of a = way that this document could define a way to extract a domain from a = telephone number that would meet the semantic you seem to be intending. >=20 > So it seems like you need to do one of the following: > 1. Define a rule for how you compute a domain value from a tel: URI. > 2. Define a new element for use under (since lacks an = extension point) > 3. Drop support for excluding phone numbers by domain (you just have = to enumerate the exceptions individually) >=20 >=20 > [CS] If we opt for Option 1, can we do the following: >=20 > a. assume E.164 numbers always start with + sign, so we can use the = digits after the + sign (after removing any visual separaters, as in the = Tel URL comparison rules) as the presumed domain value.=20 > b. for local numbers (numbers that do not start with +), the = "phone-context" contains the domain value.=20 >=20 > =20 > [CS] It seems to me that how to enforce the rate/window/percent = becomes more implementation specific, and these action items are what = the rest of the WG documents (http://datatracker.ietf.org/wg/soc/) are = using as well. The first paragraph of Section 7.4 also referenced = RFC6357 on more details about these actions. Therefore, I am not sure = what more concrete actions you are referring to, could you please = elaborate a bit on this? >=20 > I can live with this answer. >=20 >=20 > [CS] OK > =20 > To be clear, the concern here isn't about a policy that combines two = actions in the same rule. The concern is when two rules match the same = call, in which case both actions must be applied. >=20 > For example suppose you have the following rule set: > RULE 1: Reject all calls from example.com=20 > -- Conditions: > -- Actions: 0 > RULE 2: Redirect all calls from alice@example.com > -- Conditions: > -- Actions: 0 >=20 > It doesn't seem like there's a sensible way to combine those rules. = In principle, it seems like the simplest thing would be to say that a = policy MUST NOT specify two rules that could apply to the same SIP = message. Would people feel comfortable that you could efficiently check = this exclusivity? It does scale as the square of the number of rules. >=20 >=20 > [CS] Very good point. We propose an easy "the first-match rule", i.e., = the call is handled based on the first rule that matches. What do you = think?=20 > =20 >=20 > [CS] "simple drop" here means simply ignoring the request without = doing anything. i.e., in the reliable transport case, it does not have = to close the transport connection. It still saves some processing needed = in sending out the rejection in reliable transport. But I am open to = eleminating it if the group prefers so.=20 >=20 > It would help if you could add that clarification to "simple drop". =20= >=20 > [CS] Will do. In addition, "Simple drop seems good for dealing with = telephony DOS attacks" >=20 > Thanks! >=20 > Charles >=20 > =20 >=20 > Thanks, > --Richard=20 >=20 > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload >=20 >=20 >=20 > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload --Apple-Mail=_073F8013-52D2-48B8-B426-CEBC8BC4E4F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The remainder of this section presents an = example Spec(T), which is
   not =
normative in any way.

 Actually security = consideration in RFC3325 rather keeps the mechanism 
to = secure the channels open. 
   The use of transport or
   network layer hop-by-hop security mechanisms, such as TLS or IPSec
   with appropriate cipher suites, can satisfy this =
requirement.

 I think most of the = implementations that will comply to use this will not = use 
TLS and mandating TLS doesn't make sense. I think = text in the line of what 
RFC3325 should be sufficient = for security consideration in the SOC-evnet-package 
as = well.

 Regards
  = Shida
 
On Jul 14, 2013, at 8:38 AM, = Charles Shen wrote:

Hi Richard, for your comment on = "trusted domain" 



[CS] How about phrasing it as = being applicable "within trusted intra-domain and/or trusted = inter-domain" = scenarios? 

We really = need to be clear here about what "trusted" means.  ("Trusted" is a = word that makes Security ADs pounce :) )  What is each party = "trusted" not to do?  If you look at RFC 3325, it lays out exactly = what the parties need to be agree on before they use P-Asserted-ID. =   I think an analogous list of criteria is needed here.



=46rom RFC 3324/3325, "A key = requirement is that the behavior of all nodes within a given Trust = Domain 'T' is known to comply to a certain set of specifications known = as 'Spec(T)'." Therefore, if we define the "Trusted Domain" for load = control, we must define what Spec(T) means for this document. RFC 3325 = listed the following for its use with "P-Asserted-Identity" 

1. The manner in which users are authenticated 
2. The mechanisms used to secure the = communication among nodes within the Trust Domain 
3. The mechanisms used to secure the = communication between UAs and nodes within the Trust = Domain 
4. The manner used to determine which hosts are part of the Trust = Domain 
5. The default privacy handling when = no Privacy header field is present 
6. That nodes in the Trust Domain are = compliant to SIP [1] 
7. That nodes in the Trust Domain are compliant to this = document 
8. Privacy handling for identity as = described in Section 7. 

My revision in progress considers 2, 4, 6, 7 as applicable in our load = control context - basically the UA and Privacy handling is not = applicable in our case. 

Therefore, an example (non-nomative) = Spec(T) for a trusted domain of load control can be as below

1. Protocol requirements

The following specifications MUST be supported: 
1) RFC 3261 
2) RFC (this load control specification number)

2. Security requirements

Connections between nodes within the Trust Domain in the Trust Domain = MUST use TLS using a cipher suite of RSA_WITH_AES_128_CBC_SHA1. Mutual = authentication between nodes in the trust domain MUST be performed and = confidentiality MUST be negotiated.

3. Scope of Trust Domain

The Trust Domain specified in this agreement consists of hosts which = posses a valid certificate which is a) signed by examplerootca.org; b) whose = subjectAltName ends with one of the following domain names:  trusted.div1.carrier-a.net,trusted.div2.carrier-a.net, sip.carrier-b.com; and c) whose = domain name corresponds to the hostname in the subjectAltName in the = certificate.

Is this OK with you or do you have any additional = thoughts? 

thanks!

= Charles




On Thu, Jun 20, 2013 at 1:40 PM, Charles Shen <charles@cs.columbia.edu> = wrote:
Hi Richard, Thank you for the follow up, please see some comments = below.

On Sat, Jun = 15, 2013 at 4:32 AM, Richard Barnes <rlb@ipv.sx> = wrote:
=

[CS] = How about phrasing it as being applicable "within trusted intra-domain = and/or trusted inter-domain" scenarios? 

We really need = to be clear here about what "trusted" means.  ("Trusted" is a word = that makes Security ADs pounce :) )  What is each party "trusted" = not to do?  If you look at RFC 3325, it lays out exactly what the = parties need to be agree on before they use P-Asserted-ID.   I = think an analogous list of criteria is needed here.

[CS] It = makes a lot of sense to adopt RFC3325/3324 notion of Trusted domains, I = will work on that. 

 
I agree, let's do option (2).  Suggested = text:
"""
This document does not define the content of SUBSCRIBE = bodies.  Future specifications could define bodies for SUBSCRIBE = messages, for example to request specific types of load control event = notifications.
=
"""

[CS] Will do.
 

To be clear on = this, the ambiguity here is with regard to the <except = domain=3D"..."> case.  In the <one id=3D"..."> case, you = just do Tel URI comparison.

Thinking on this a little more, it looks like your = use of the "domain" parameter actually breaks with RFC 4745. =  According to RFC 4745, there must be an exact match between the = "domain" value provided by the using protocol and the value in the = "domain" parameter.  I can't think of a way that this document = could define a way to extract a domain from a telephone number that = would meet the semantic you seem to be intending.

So it seems like you need to do one of the = following:
1. Define a rule for how you compute a domain value = from a tel: URI.
2. Define a new element for use under = <many> (since <except> lacks an extension point)
3. Drop support for excluding phone numbers by domain (you just = have to enumerate the exceptions = individually)


[CS] If we opt for Option 1, can we do = the following:

a. assume E.164 numbers always start with + sign, so = we can use the digits after the + sign (after removing any visual = separaters, as in the Tel URL comparison rules) as the presumed domain = value. 
b. for local numbers (numbers that do not start with +), the = "phone-context" contains the domain = value. 

 
[CS] It seems to me that how = to enforce the rate/window/percent becomes more implementation specific, = and these action items are what the rest of the WG documents (http://datatracker.ietf.org/wg/soc/) are using as = well. The first paragraph of Section 7.4 also referenced RFC6357 on more = details about these actions. Therefore, I am not sure what more concrete = actions you are referring to, could you please elaborate a bit on this? =

I can live with this = answer.

=

[CS] OK
 
To be clear, the concern here isn't about a = policy that combines two actions in the same rule.  The concern is = when two rules match the same call, in which case both actions must be = applied.

For example suppose you have the following rule = set:
RULE 1: Reject all calls from example.com 
-- Conditions: = <from><identity><many domain=3D"example.com"/></identity></from>
-- Actions: <accept = alt-action=3D"reject"><rate>0</rate></accept>
RULE 2: Redirect all calls from alice@example.com
-- Conditions: <from><identity><one id=3D"sip:alice@example.com"/></identity></fro= m>
-- Actions: <accept alt-action=3D"redirect" alt-target=3D"sip:eve@example.com"><rate>0</rate>&l= t;/accept>

It doesn't seem like there's a sensible way to combine those = rules.  In principle, it seems like the simplest thing would be to = say that a policy MUST NOT specify two rules that could apply to the = same SIP message.  Would people feel comfortable that you could = efficiently check this exclusivity?  It does scale as the square of = the number of rules.
=


<= /div>
[CS] Very good point. We propose an easy "the first-match rule", i.e., the call is handled = based on the first rule that matches. What do you think? 
 

[CS] = "simple drop" here means simply ignoring the request without doing = anything.  i.e., in the reliable transport case, it does not have = to close the transport connection. It still saves some processing needed = in sending out the rejection in reliable transport. But I am open to = eleminating it if the group prefers so. 

It would help = if you could add that clarification to "simple drop". =  

[CS] Will do. In addition, "Simple drop seems good for dealing with telephony DOS = attacks"

Thanks!

Charles

 

Thanks,
--Richard = ;

_______________________________________________
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

= --Apple-Mail=_073F8013-52D2-48B8-B426-CEBC8BC4E4F0-- From charles.newyork@gmail.com Fri Jul 19 12:11:47 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 BB0DF21E811F for ; Fri, 19 Jul 2013 12:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtGoJVU5eAVB for ; Fri, 19 Jul 2013 12:11:46 -0700 (PDT) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id F330021E80D2 for ; Fri, 19 Jul 2013 12:11:36 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id k7so6543723oag.23 for ; Fri, 19 Jul 2013 12:11:36 -0700 (PDT) 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=+c30a0f3hovZlejnk7vSjmJuTyG1XZiAForTdRqA9bY=; b=yH/p7aVOCUBKScayhUGxvsQccWj8TcUIPJeyuCmK5WUGZNeiD4wP+P7owAsehYeNq4 rvF0jGoiZVWQO62dfeAyxk1Ahw2LN8nB/LVVgHbylafWZfSWLAGawxRQNDyoYCrOqDOd fL60XH7ddGbtET6LB/JQZn4s1ZZLIJ84B2QHjvXpKIvsgsqUbx0IQW03Do7atlLq4gjp Jmx1S5E/e/nmT9pXMQaSaQkZo316CvHfzHelgl0WKBFIIGvnsLU9o8gDMpN/7KwmvkiT DagBbjTx8sOiC5F9FXQ/9QQertGjNwbYYoGT1Ewxz3Zr9wE4gghdJ6SrYb3PWZ/6vdBR MbgA== X-Received: by 10.60.141.226 with SMTP id rr2mr19219600oeb.12.1374261096438; Fri, 19 Jul 2013 12:11:36 -0700 (PDT) MIME-Version: 1.0 Sender: charles.newyork@gmail.com Received: by 10.182.112.131 with HTTP; Fri, 19 Jul 2013 12:11:16 -0700 (PDT) In-Reply-To: <215A826D-A1A0-4EB2-9E07-7B19AF3783C1@ntt-at.com> References: <215A826D-A1A0-4EB2-9E07-7B19AF3783C1@ntt-at.com> From: Charles Shen Date: Sat, 20 Jul 2013 03:11:16 +0800 X-Google-Sender-Auth: NqDqJHOwPfyDShrn3_URumPA-lA Message-ID: To: Shida Schubert Content-Type: multipart/alternative; boundary=047d7b41c7467b668904e1e21897 Cc: sip-overload@ietf.org, draft-ietf-soc-load-control-event-package@tools.ietf.org Subject: Re: [sip-overload] AD review of draft-ietf-soc-load-control-event-package-08 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, 19 Jul 2013 19:11:47 -0000 --047d7b41c7467b668904e1e21897 Content-Type: text/plain; charset=UTF-8 Hi Shida, I agree that we do not have to mandate TLS. How about adding the following texts about "Trust Domain" to the current document, without describing more specific details? "This specification MUST be applied inside a 'Trust Domain'. The concept of a Trust Domain is similar to that defined in [RFC3324]. A Trust Domain for the purpose of SIP load filtering is a set of entities such as SIP proxy servers that are trusted to exchange load filtering policies defined in this document. In the simplest case, a Trust Domain is a network of SIP entities belonging to a single owner/operator who deploys it and accurately knows the behaviour of those SIP entities. Such simple Trust Domains may be joined to form larger Trust Domains by bi-lateral agreements between the owners/operators of the SIP entities. A key requirement of the Trust Domain for the purpose of SIP load filtering is that the behavior of all SIP entities within a given Trust Domain 'T' is known to comply to the following set of specifications known as 'Spec(T)'. 1. The mechanisms used to secure the communication among SIP entities within the Trust Domain 2. The manner used to determine which SIP entities are part of the Trust Domain 3. That SIP entities in the Trust Domain are compliant to SIP [RFC3261] 4. That SIP entities in the Trust Domain are compliant to this document " Thanks Charles On Tue, Jul 16, 2013 at 10:49 AM, Shida Schubert wrote: > > Hi Charles; > > Hmm.. As far as I can recall RFC3325 references Spec(T) BUT it doesn't > reference it normatively. > > Second paragraph of section 11. in RFC3325. > > The remainder of this section presents an example Spec(T), which is > > > not normative in any way. > > > Actually security consideration in RFC3325 rather keeps the mechanism > to secure the channels open. > > > > The use of transport or > network layer hop-by-hop security mechanisms, such as TLS or IPSec > with appropriate cipher suites, can satisfy this requirement. > > > I think most of the implementations that will comply to use this will not > use > TLS and mandating TLS doesn't make sense. I think text in the line of what > RFC3325 should be sufficient for security consideration in the > SOC-evnet-package > as well. > > Regards > Shida > > On Jul 14, 2013, at 8:38 AM, Charles Shen wrote: > > Hi Richard, for your comment on "trusted domain" > > > >>> [CS] How about phrasing it as being applicable "within trusted >>> intra-domain and/or trusted inter-domain" scenarios? >>> >> >> We really need to be clear here about what "trusted" means. ("Trusted" >> is a word that makes Security ADs pounce :) ) What is each party "trusted" >> not to do? If you look at RFC 3325, it lays out exactly what the parties >> need to be agree on before they use P-Asserted-ID. I think an analogous >> list of criteria is needed here. >> >> > > From RFC 3324/3325, "A key requirement is that the behavior of all nodes > within a given Trust Domain 'T' is known to comply to a certain set of > specifications known as 'Spec(T)'." Therefore, if we define the "Trusted > Domain" for load control, we must define what Spec(T) means for this > document. RFC 3325 listed the following for its use with > "P-Asserted-Identity" > > 1. The manner in which users are authenticated > 2. The mechanisms used to secure the communication among nodes within the > Trust Domain > 3. The mechanisms used to secure the communication between UAs and nodes > within the Trust Domain > 4. The manner used to determine which hosts are part of the Trust Domain > 5. The default privacy handling when no Privacy header field is present > 6. That nodes in the Trust Domain are compliant to SIP [1] > 7. That nodes in the Trust Domain are compliant to this document > 8. Privacy handling for identity as described in Section 7. > > My revision in progress considers 2, 4, 6, 7 as applicable in our load > control context - basically the UA and Privacy handling is not applicable > in our case. > > Therefore, an example (non-nomative) Spec(T) for a trusted domain of load > control can be as below > > 1. Protocol requirements > > The following specifications MUST be supported: > 1) RFC 3261 > 2) RFC (this load control specification number) > > 2. Security requirements > > Connections between nodes within the Trust Domain in the Trust Domain MUST > use TLS using a cipher suite of RSA_WITH_AES_128_CBC_SHA1. Mutual > authentication between nodes in the trust domain MUST be performed and > confidentiality MUST be negotiated. > > 3. Scope of Trust Domain > > The Trust Domain specified in this agreement consists of hosts which > posses a valid certificate which is a) signed by examplerootca.org; b) > whose subjectAltName ends with one of the following domain names: > trusted.div1.carrier-a.net,trusted.div2.carrier-a.net, sip.carrier-b.com; > and c) whose domain name corresponds to the hostname in the subjectAltName > in the certificate. > > Is this OK with you or do you have any additional thoughts? > > thanks! > > Charles > > > > > On Thu, Jun 20, 2013 at 1:40 PM, Charles Shen wrote: > >> Hi Richard, Thank you for the follow up, please see some comments below. >> >> On Sat, Jun 15, 2013 at 4:32 AM, Richard Barnes wrote: >> >>> >>>>> >>>> [CS] How about phrasing it as being applicable "within trusted >>>> intra-domain and/or trusted inter-domain" scenarios? >>>> >>> >>> We really need to be clear here about what "trusted" means. ("Trusted" >>> is a word that makes Security ADs pounce :) ) What is each party "trusted" >>> not to do? If you look at RFC 3325, it lays out exactly what the parties >>> need to be agree on before they use P-Asserted-ID. I think an analogous >>> list of criteria is needed here. >>> >> >> [CS] It makes a lot of sense to adopt RFC3325/3324 notion of Trusted >> domains, I will work on that. >> >> >> >>> I agree, let's do option (2). Suggested text: >>> """ >>> This document does not define the content of SUBSCRIBE bodies. Future >>> specifications could define bodies for SUBSCRIBE messages, for example to >>> request specific types of load control event notifications. >>> """ >>> >> >> [CS] Will do. >> >> >>> >>> To be clear on this, the ambiguity here is with regard to the >> domain="..."> case. In the case, you just do Tel URI >>> comparison. >>> >>> Thinking on this a little more, it looks like your use of the "domain" >>> parameter actually breaks with RFC 4745. According to RFC 4745, there must >>> be an exact match between the "domain" value provided by the using protocol >>> and the value in the "domain" parameter. I can't think of a way that this >>> document could define a way to extract a domain from a telephone number >>> that would meet the semantic you seem to be intending. >>> >>> So it seems like you need to do one of the following: >>> 1. Define a rule for how you compute a domain value from a tel: URI. >>> 2. Define a new element for use under (since lacks an >>> extension point) >>> 3. Drop support for excluding phone numbers by domain (you just have to >>> enumerate the exceptions individually) >>> >>> >> [CS] If we opt for Option 1, can we do the following: >> >> a. assume E.164 numbers always start with + sign, so we can use the >> digits after the + sign (after removing any visual separaters, as in the >> Tel URL comparison rules) as the presumed domain value. >> b. for local numbers (numbers that do not start with +), the >> "phone-context" contains the domain value. >> >> >> >>> [CS] It seems to me that how to enforce the rate/window/percent >>>> becomes more implementation specific, and these action items are what the >>>> rest of the WG documents (http://datatracker.ietf.org/wg/soc/) are >>>> using as well. The first paragraph of Section 7.4 also referenced RFC6357 >>>> on more details about these actions. Therefore, I am not sure what more >>>> concrete actions you are referring to, could you please elaborate a bit on >>>> this? >>>> >>> >>> I can live with this answer. >>> >>> >> [CS] OK >> >> >>> To be clear, the concern here isn't about a policy that combines two >>> actions in the same rule. The concern is when two rules match the same >>> call, in which case both actions must be applied. >>> >>> For example suppose you have the following rule set: >>> RULE 1: Reject all calls from example.com >>> -- Conditions: >>> -- Actions: 0 >>> RULE 2: Redirect all calls from alice@example.com >>> -- Conditions: >>> -- Actions: 0 >>> >>> It doesn't seem like there's a sensible way to combine those rules. In >>> principle, it seems like the simplest thing would be to say that a policy >>> MUST NOT specify two rules that could apply to the same SIP message. Would >>> people feel comfortable that you could efficiently check this exclusivity? >>> It does scale as the square of the number of rules. >>> >>> >> [CS] Very good point. We propose an easy "the first-match rule", i.e., >> the call is handled based on the first rule that matches. What do you >> think? >> >> >>> >>>> [CS] "simple drop" here means simply ignoring the request without doing >>>> anything. i.e., in the reliable transport case, it does not have to close >>>> the transport connection. It still saves some processing needed in sending >>>> out the rejection in reliable transport. But I am open to eleminating it if >>>> the group prefers so. >>>> >>> >>> It would help if you could add that clarification to "simple drop". >>> >> >> [CS] Will do. In addition, "Simple drop seems good for dealing with >> telephony DOS attacks" >> >> Thanks! >> >> Charles >> >> >> >>> >>> Thanks, >>> --Richard >>> >>> _______________________________________________ >>> 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 > > > --047d7b41c7467b668904e1e21897 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Shida, I agree that we do not have to mandate TLS. How about adding= the following texts about "Trust Domain" to the current document= , without describing more specific details?=C2=A0

= "This specification MUST be applied inside a 'Trust Domain'. T= he concept of a Trust Domain is similar to that defined in [RFC3324]. A Tru= st Domain for the purpose of SIP load filtering is a set of entities such a= s SIP proxy servers that are trusted to exchange load filtering policies de= fined in this document. In the simplest case, a Trust Domain is a network o= f SIP entities belonging to a single owner/operator who deploys it and accu= rately knows the behaviour of those SIP entities. Such simple Trust Domains= may be joined to form larger Trust Domains by bi-lateral agreements betwee= n the owners/operators of the SIP entities.

A key requirement of the Trust Domain for the purpose o= f SIP load filtering is that the behavior of all SIP entities within a give= n Trust Domain 'T' is known to comply to the following set of speci= fications known as 'Spec(T)'.=C2=A0

1. The mechanisms used to secure the communication amon= g SIP entities within the Trust Domain=C2=A0
2. The manner used t= o determine which SIP entities are part of the Trust Domain=C2=A0
3. That SIP entities in the Trust Domain are compliant to SIP [RFC3261]=C2= =A0
4. That SIP entities in the Trust Domain are compliant to this documen= t "

Thanks

Charles
On Tue, Jul 16, 2013 at 10:49 AM, Shida = Schubert <shida@ntt-at.com> wrote:
Hi Charles;

=C2=A0Hmm.. As far as I ca= n recall RFC3325 references Spec(T) BUT=C2=A0it doesn't=C2=A0
reference it normatively.=C2=A0

=C2=A0Second = paragraph of section 11. in RFC3325.=C2=A0

=C2=A0<= span style=3D"font-family:monospace;font-size:10px;white-space:pre-wrap"> T= he remainder of this section presents an example Spec(T), which is 

   not normative in any way.

=C2=A0Actually securi= ty consideration in RFC3325 rather keeps the mechanism=C2=A0
to s= ecure the channels open.=C2=A0



   The use of transport or
   network layer hop-by-hop security mechanisms, such as TLS or IPSec
   with appropriate cipher suites, can satisfy this requirement.
=
=C2=A0I think most of the implementations that will co= mply to use this will not use=C2=A0
TLS and mandating TLS doesn&#= 39;t make sense. I think text in the line of what=C2=A0
RFC3325 should be sufficient for security consideration in the SOC-evn= et-package=C2=A0
as well.

=C2=A0Regards<= /div>
=C2=A0 Shida
=
=C2=A0
On Jul 14, 2013, at 8:38 AM, C= harles Shen wrote:

Hi Richard, for y= our comment on "trusted domain"=C2=A0



[CS] How about phrasing it as being applicable "within trusted int= ra-domain and/or trusted inter-domain" scenarios?=C2=A0

We really need to be clear here about what &q= uot;trusted" means. =C2=A0("Trusted" is a word that makes Se= curity ADs pounce :) ) =C2=A0What is each party "trusted" not to = do? =C2=A0If you look at RFC 3325, it lays out exactly what the parties nee= d to be agree on before they use P-Asserted-ID. =C2=A0 I think an analogous= list of criteria is needed here.



From RFC 3324/3325, "A key requirement is that the behav= ior of all nodes within a given Trust Domain 'T' is known to comply= to a certain set of specifications known as 'Spec(T)'." There= fore, if we define the "Trusted Domain" for load control, we must= define what Spec(T) means for this document. RFC 3325 listed the following= for its use with "P-Asserted-Identity"=C2=A0

1. The manner in which users are authenticated=C2=A0
2. The mechan= isms used to secure the communication among nodes within the Trust Domain= =C2=A0
3. The mechanisms used to secure the communication between UAs and node= s within the Trust Domain=C2=A0
4. The manner used to determine which hosts are part of the Trust Domain=C2= =A0
5. The default privacy handling when no Privacy header field i= s present=C2=A0
6. That nodes in the Trust Domain are compliant to SIP [1]=C2=A0
<= div style=3D"color:rgb(34,34,34);font-size:16px;font-family:arial,sans-seri= f"> 7. That nodes in the Trust Domain are compliant to this document=C2=A0
8. Privacy handling for identity as described in Section 7.=C2=A0

My revision in progress considers 2, 4, 6, 7 as applicable in our load cont= rol context - basically the UA and Privacy handling is not applicable in ou= r case.=C2=A0

Therefore, an example (non-nomative) Spec(T) for a trusted do= main of load control can be as below

1. Protocol requirements

The following specifications MUST be supported:=C2=A0
1) RFC 3261= =C2=A0
2) RFC (this load control specification number)

2. Security requirements

Connections between nodes within the Trust Domain in the Trust Domain MUST = use TLS using a cipher suite of RSA_WITH_AES_128_CBC_SHA1. Mutual authentic= ation between nodes in the trust domain MUST be performed and confidentiali= ty MUST be negotiated.

3. Scope of Trust Domain

The Trust Domain specified in this agreement consists of hosts which posses= a valid certificate which is a) signed by=C2=A0examplerootca.o= rg; b) whose subjectAltName ends with one of the following domain names= : =C2=A0trusted.div1.carrier-a.net,trusted.div2.carrier-a.net,=C2=A0sip.carrier-b.com; and c) whose domain name corresponds to the hostname in the subjectAltNa= me in the certificate.

Is this OK with you or do you have any additional thoug= hts?=C2=A0

thanks!

Charle= s




On Thu, Jun 20, 2013 at 1:40 PM, Charles Shen <charles@cs.columbia.e= du> wrote:
Hi Richard, Thank you for the follow up, please see some comments below.
On Sat, Jun 15, 2013 at 4:32 AM, Rich= ard Barnes <rlb@ipv.sx> wrote:


[CS] How = about phrasing it as being applicable "within trusted intra-domain and= /or trusted inter-domain" scenarios?=C2=A0

We really need to = be clear here about what "trusted" means. =C2=A0("Trusted&qu= ot; is a word that makes Security ADs pounce :) ) =C2=A0What is each party = "trusted" not to do? =C2=A0If you look at RFC 3325, it lays out e= xactly what the parties need to be agree on before they use P-Asserted-ID. = =C2=A0 I think an analogous list of criteria is needed here.

[CS] It make= s a lot of sense to adopt RFC3325/3324 notion of Trusted domains, I will wo= rk on that.=C2=A0

=C2=A0
I agree, let's do option (2). =C2=A0Suggested text:
"""
This document does not define the content of S= UBSCRIBE bodies. =C2=A0Future specifications could define bodies for SUBSCR= IBE messages, for example to request specific types of load control event n= otifications.
"""

[CS] Will do.
=C2=A0

To be clear on this, the ambiguity here is = with regard to the <except domain=3D"..."> case. =C2=A0In t= he <one id=3D"..."> case, you just do Tel URI comparison.

Thinking on this a little more, it looks like your use = of the "domain" parameter actually breaks with RFC 4745. =C2=A0Ac= cording to RFC 4745, there must be an exact match between the "domain&= quot; value provided by the using protocol and the value in the "domai= n" parameter. =C2=A0I can't think of a way that this document coul= d define a way to extract a domain from a telephone number that would meet = the semantic you seem to be intending.

So it seems like you need to do one of the following:
1. Define a rule for how you compute a domain value from a tel: UR= I.
2. Define a new element for use under <many> (since <= except> lacks an extension point)
3. Drop support for excluding phone numbers by domain (you just have t= o enumerate the exceptions individually)


[CS] If we opt = for Option 1, can we do the following:

a. assume E.164 numbers always start with + sign, so we= can use the digits after the + sign (after removing any visual separaters,= as in the Tel URL comparison rules) as the presumed domain value.=C2=A0
b. for local numbers (numbers that do not start with +), the &quo= t;phone-context" contains the domain value.=C2=A0

=
=C2=A0
[CS] It seems to me that how to e= nforce the rate/window/percent becomes more implementation specific, and th= ese action items are what the rest of the WG documents (http://datatracker.ietf.org/= wg/soc/) are using as well. The first paragraph of Section 7.4 also ref= erenced RFC6357 on more details about these actions. Therefore, I am not su= re what more concrete actions you are referring to, could you please elabor= ate a bit on this?

I can live wi= th this answer.


[CS] OK
=C2=A0
To be clear, the concern here isn't about a policy that combines = two actions in the same rule. =C2=A0The concern is when two rules match the= same call, in which case both actions must be applied.

For example suppose you have the following rule set:
RULE 1: Reject all calls from example.com=C2=A0
-- Conditions: <from><= ;identity><many domain=3D"example.com"/></identity></from>
-- Actions: <accept alt-action=3D"reject"><rate>= 0</rate></accept>
RULE 2: Redirect all calls from alice@example.com
-- Conditions: <from><identity><one id=3D"sip:alice@example.com= "/></identity></from>
-- Actions: <accept alt-action=3D"redirect" alt-target=3D= "sip:eve@ex= ample.com"><rate>0</rate></accept>
=
It doesn't seem like there's a sensible way to combine t= hose rules. =C2=A0In principle, it seems like the simplest thing would be t= o say that a policy MUST NOT specify two rules that could apply to the same= SIP message. =C2=A0Would people feel comfortable that you could efficientl= y check this exclusivity? =C2=A0It does scale as the square of the number o= f rules.


[CS] Very good point. We propose an=C2=A0easy= "the first-match rule", i.e., the call is handled based on the f= irst rule that matches.=C2=A0What do you think?= =C2=A0
=C2=A0

[CS] &q= uot;simple drop" here means simply ignoring the request without doing = anything. =C2=A0i.e., in the reliable transport case, it does not have to c= lose the transport connection. It still saves some processing needed in sen= ding out the rejection in reliable transport. But I am open to eleminating = it if the group prefers so.=C2=A0

It would help if y= ou could add that clarification to "simple drop". =C2=A0

[CS] Will do. I= n addition, "Simple drop seems good for dealing wi= th telephony DOS attacks"

Thanks!<= /span>

Charles<= /span>

=C2=A0

Thanks,
--Richard=C2=A0

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



_______________________________________________
sip-overload mailing lis= t
sip-overloa= d@ietf.org
https://www.ietf.org/mailman/listinfo/sip-overload<= /a>


--047d7b41c7467b668904e1e21897-- From christer.holmberg@ericsson.com Sat Jul 20 04:04: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 9762F21F99DA; Sat, 20 Jul 2013 04:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.499 X-Spam-Level: X-Spam-Status: No, score=-5.499 tagged_above=-999 required=5 tests=[AWL=0.749, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMCSUKVY5FVI; Sat, 20 Jul 2013 04:03:57 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8722821F8C40; Sat, 20 Jul 2013 04:03:55 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-11-51ea6e9a301e Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id D7.DB.19388.A9E6AE15; Sat, 20 Jul 2013 13:03:54 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.45]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0328.009; Sat, 20 Jul 2013 13:03:54 +0200 From: Christer Holmberg To: "NOEL, ERIC C (ERIC C)" Thread-Topic: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Thread-Index: Ac5zhcqru7dYQFxqQKSGvvGKSQFJEAAn/KwAALza+IABbsiJAAAiGiWAAAKrhAAAARl8gAABpBAAAANOPYAABCzcAAABjR6AAeiCBIA= Date: Sat, 20 Jul 2013 11:03:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3DA510@ESESSMB209.ericsson.se> References: <56FB15AFE08E1242B0736CBDCE6E85610808C32F@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610808EF90@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353BDA4CAD4@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E85610809239D@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610809253D@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353C0687578@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E856108092986@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353C068757C@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E856108092BD9@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353C0687581@njfpsrvexg2.research.att.com> In-Reply-To: <5EBD159DE88147488A3B1590E09001840353C0687581@njfpsrvexg2.research.att.com> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C3DA510ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM+Jvre6svFeBBhNf61hc2HGM1eLk/30s Fu0Xt7Ja7H+a4MDisWTJTyaP/0/ms3h8ufyZLYA5issmJTUnsyy1SN8ugStj/YwNTAUvjCo+ rl/D3MC4W7eLkZNDQsBE4sHahawQtpjEhXvr2boYuTiEBA4zSvy+sJoRwlnMKLGs7zNLFyMH B5uAhUT3P22QBhEBU4kZu4+wgNQwC7xnlLi1YgYjSEJYwF3i/aT3TBBFHhJ7Tj1iBekVESiT OPpbHyTMIqAq0fJvDhuIzSvgK7Fl7XZWiF3b2SRm35zJDpLgFIiQaDh2B2wmI9B130+tAZvJ LCAu8eHgdWaIqwUkluw5D2WLSrx8/A/qGyWJxiVPWCHq8yXOtZ1lgVgmKHFy5hOWCYyis5CM moWkbBaSMoi4jsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KkT03MTMnvdx8EyMw4g5u+W2w g3HTfbFDjNIcLErivJv1zgQKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYCz38fC9FVe0gK3x rVOBoXnqCf3GwLYPNy+tOMz+58xaa+t+hrUfnn5IujhrjrLhDv3IrM/ZNf6Jyx13/nGK5uAp EWwxPjrj7+m7PDNXaV/K1Xmrw/fXe7rjS9fsWctX5hwPnpARw3PQdKZA7I19bd1eH75Pl1l6 7IkY8zQn1piPEb/vbPgSaaHEUpyRaKjFXFScCADlYxW0hgIAAA== Cc: "sip-overload-bounces@ietf.org" , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" , "sip-overload@ietf.org" Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.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: Sat, 20 Jul 2013 11:04:03 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C3DA510ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Eric, In an e-mail you said that you will wait for "WGLC expiration" before you s= ubmit a new version of the draft. But, WGLC will not "expire" until we have a draft which addresses the raise= d issues :) So, if you think the issues have been solved, I would suggest that you subm= it a new version of the draft, where the solutions are implemented, so that= people can take a look. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C3DA510ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Eric,

 <= /p>

In an e-ma= il you said that you will wait for ”WGLC expiration” before you= submit a new version of the draft.

 = ;

But, WGLC = will not “expire” until we have a draft which addresses the rai= sed issues :)

 = ;

So, if you= think the issues have been solved, I would suggest that you submit a new v= ersion of the draft, where the solutions are implemented, so that people can take a look.

 = ;

Regards,

 = ;

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C3DA510ESESSMB209erics_-- From christer.holmberg@ericsson.com Sat Jul 20 04:10:57 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 B51BC11E80D7; Sat, 20 Jul 2013 04:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.713 X-Spam-Level: X-Spam-Status: No, score=-3.713 tagged_above=-999 required=5 tests=[AWL=-1.115, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9z14yklahDG; Sat, 20 Jul 2013 04:10:45 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id A7EA811E80EE; Sat, 20 Jul 2013 04:10:42 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-09-51ea70313989 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 98.18.11907.1307AE15; Sat, 20 Jul 2013 13:10:41 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.45]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0328.009; Sat, 20 Jul 2013 13:10:40 +0200 From: Christer Holmberg To: "NOEL, ERIC C (ERIC C)" , "'DRAGE, Keith (Keith)'" , "'Yu, James'" Thread-Topic: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Thread-Index: Ac5zhcqru7dYQFxqQKSGvvGKSQFJEAAn/KwAALza+IABbsiJAAAiGiWAAAKrhAAAARl8gAABpBAAAANOPYAABCzcAAABjR6AAASO6QAAKuPFAAG5ULpg Date: Sat, 20 Jul 2013 11:10:40 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3DA597@ESESSMB209.ericsson.se> References: <56FB15AFE08E1242B0736CBDCE6E85610808C32F@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610808EF90@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353BDA4CAD4@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E85610809239D@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610809253D@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353C0687578@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E856108092986@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353C068757C@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E856108092BD9@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353C0687581@njfpsrvexg2.research.att.com> <949EF20990823C4C85C18D59AA11AD8B06820F@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5EBD159DE88147488A3B1590E09001840353C068758D@njfpsrvexg2.research.att.com> In-Reply-To: <5EBD159DE88147488A3B1590E09001840353C068758D@njfpsrvexg2.research.att.com> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C3DA597ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGfG3Vtew4FWgwY/H0hYXdhxjtTj5fx+L xaJpIRZPG88yWrRf3Mpqsf9pggObR+uzvaweS5b8ZPLY0fCc2eP/k/ksHl8uf2YLYI3isklJ zcksSy3St0vgyrjwv6Bg4W72ir4fL9gbGBfcZeti5OCQEDCRuPDDpIuRE8gUk7hwbz1QmItD SOAoo8TCsx3MIAkhgcWMEt0H6kDq2QQsJLr/aYPUiAjMYpSY2r0XrIFZ4D2jxK0VMxhBGoQF 3CXeT3rPBGKLCHhI7Dn1iBWio4lRonftRGaQSSwCqhIXdzqB1PAK+ErsOvaJFWLzNXaJlk1/ WboY2Tk4BSIk9iaAlDACHff91BqwkcwC4hIfDl5nhjhaQGLJnvNQtqjEy8f/WCFsJYnGJU9Y QTYxC+RLPJnFCrFJUOLkzCcsExhFZyGZNAuhahaSKogSPYkbU6ewQdjaEssWvmaGsHUlZvw7 xIIsvoCRfRUjR3FqcVJuupHBJkZgTB7c8ttiB+PlvzaHGKU5WJTEebfonQkUEkhPLEnNTk0t SC2KLyrNSS0+xMjEwSnVwHiW+VdUSU4fV4LpJvOg+6w7D+iq3Y3PSEzVdbtwZlL8vRjfkqbt dqXp2pNVrOZfqdz5+8TWVSvvTBOqnZ27uPiMZbi40y+fyMuZv/MYtQyETzOtKZd+w5gdZfzz n75iiuLGh/oXuttjJ89z2OieWdLZ8PG9pseTjUsnOu7/3/UzeOGD01e3uSuxFGckGmoxFxUn AgC+2DS9lwIAAA== Cc: "sip-overload-bounces@ietf.org" , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" , "sip-overload@ietf.org" Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.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: Sat, 20 Jul 2013 11:10:57 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C3DA597ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I support Keith's suggestion. There is no need to copy/paste syntax from an= other specification - we should simply define the syntax additions/extensio= ns. Regards, Christer L=E4hett=E4j=E4: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces= @ietf.org] Puolesta NOEL, ERIC C (ERIC C) L=E4hetetty: 11. hein=E4kuuta 2013 21:33 Vastaanottaja: 'DRAGE, Keith (Keith)'; 'Yu, James' Kopio: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.= all@tools.ietf.org; sip-overload@ietf.org Aihe: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Keith, Thank you for your comment. IANA impacts: - Based on Keith suggestion, for the IANA impacts we only need to have the = IANA consideration section in draft-ietf-soc-overload-control to include th= e future RFC number for draft-ietf-soc-overload-rate-control in the referen= ce column - While James is suggesting explicitly defining the new parameter value in = the IANA consideration section of draft-ietf-soc-overload-rate-control =3D> Because Keith proposal is aligned with RFC 3968 guidelines, I propose = adopting his proposal. ABNF impacts: - Based on Keith suggestion, draft-ietf-soc-overload-rate-control syntax se= ction should be reduced to algo-list /=3D "rate" - While James is suggesting that section to include oc =3D "oc" [EQUAL oc-num] oc-num =3D 1*DIGIT oc-algo =3D "oc-algo" EQUAL DQUOTE algo-list *(COMMA algo-list) DQUOTE algo-list =3D "loss" / "rate" / *(other-algo) other-algo =3D %x41-5A / %x61-7A / %x30-39 =3D> Per Keith suggestion, to prevent potential conflicts, I propose adopti= ng his proposal. James would you agree with the proposed resolution? 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: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] Sent: Wednesday, July 10, 2013 6:05 PM To: NOEL, ERIC C (ERIC C); 'Yu, James' Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt I've lost track of what is happening here. What I expect is two things: 1) IANA registration impact. For the header field parameters registry, draft-ietf-soc-overload-control a= lready creates the new rows: Header Field Parameter Name Predefined Values Reference __________________________________________________________ Via oc Yes RFCXXXX Via oc-validity Yes RFCXXXX Via oc-seq Yes RFCXXXX Via oc-algo Yes RFCXXXX RFC XXXX [NOTE TO RFC-EDITOR: Please replace with final RFC number of this specification.] For the predefined values columns, RFC 3968 states: Some SIP header field parameters only accept a set of predefined parameter values. For example, a parameter indicating the transport protocol in use may only accept the predefined tokens TCP, UDP, and SCTP as valid values. Registering all parameter values for all SIP header field parameters of this type would require a large number of subregistries. Instead, we have chosen to register parameter values by reference. That is, the entry in the parameter registry for a given header field parameter contains references to the RFCs defining new values of the parameter. References to RFCs defining parameter values appear in double brackets in the registry. So, the header field parameter registry contains a column that indicates whether or not each parameter only accepts a set of predefined values. Implementers of parameters with a "yes" in that column need to find all the valid parameter values in the RFCs provided as references. With this understanding, I do not believe the rate-control draft needs to m= odify the "predefined values" column. What it does need to do is add its ul= timate RFC number to the reference column. There could be an argument that there needs to be a new table that lists th= e algorithm values, but a) if such a table is to be created, it needs to be created by = draft-ietf-soc-overload-control rather than the rate-control draft/ b) I personally do not think it is necessary to add such a new t= able, as I think the references are sufficient. One cannot handle the algor= ithm values unless one goes to the relevant RFC. 2) ABNF impact. ABNF defines the /=3D operator for adding new values to an existing defined= list. I do not think we should reproduce existing ABNF from draft-ietf-soc-overlo= ad-control and then amend it. The reason for this is that tools exist for automatically extracting the AB= NF from RFCs. An extracted algo-list /=3D "rate" will work perfectly well with the extract from draft-ietf-soc-overload-cont= rol (and from SIP). Reproducing productions will result in conflict. Regards Keith ________________________________ From: sip-overload-bounces@ietf.org [= mailto:sip-overload-bounces@ietf.org] On Behalf Of NOEL, ERIC C (ERIC C) Sent: 10 July 2013 20:54 To: 'Yu, James' Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, So section 5 (syntax) will include the following statements: oc =3D "oc" [EQUAL oc-num] oc-num =3D 1*DIGIT oc-algo =3D "oc-algo" EQUAL DQUOTE algo-list *(COMMA algo-list) DQUOTE algo-list =3D "loss" / "rate" / *(other-algo) other-algo =3D %x41-5A / %x61-7A / %x30-39 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: Yu, James [mailto:james.yu@neustar.biz] Sent: Wednesday, July 10, 2013 3:10 PM To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Eric, You may want to copy the "oc-algo" line from other I-D. James From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] Sent: Wednesday, July 10, 2013 1:10 PM To: Yu, James Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, Based on your suggestion and comments from other reviewers, I intend to upd= ate section 5 (syntax) as follows: oc =3D "oc" [EQUAL oc-num] oc-num =3D 1*DIGIT algo-list =3D "loss" / "rate" / *(other-algo) other-algo =3D %x41-5A / %x61-7A / %x30-39 I understand there may be an additional change following Henning's reply. 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: Yu, James [mailto:james.yu@neustar.biz] Sent: Wednesday, July 10, 2013 11:36 AM To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Eric, Yes, this adds "rate" to "oc-algo" parameter but please check with IANA to = see if it is the correct way. You also need to copy some syntax lines from= the draft-ietf-soc-overload-control to show algo-list =3D "loss" / "rate" / *(other-algo) I've an email to Henning asking if algo-list in his I-D should be algo-list =3D "loss" / other-algo If yes, then this particular line in your I-D would be algo-list =3D "loss" / "rate" / other-algo James From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] Sent: Wednesday, July 10, 2013 10:49 AM To: Yu, James Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, Thank you for your suggestion. Not being familiar with IANA procedure, would updating draft-ietf-soc-overl= oad-rate-control section 7 (IANA considerations) as follows work? This specification defines a new value for Via header parameter oc-algo as = detailed below in the "Header Field Parameter and Parameter Values" subregi= stry as per the registry created by [RFC3968]. The required information is: Header Field Parameter Name Predefined Val= ues Reference ---------------------------------------------------------------------------= ------------------------------- Via oc-algo = "rate" RFCXXXX RFC XXXX [NOTE TO RFC-EDITOR: Please replace with final RFC number of this = specification.] 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: Yu, James [mailto:james.yu@neustar.biz] Sent: Wednesday, July 10, 2013 10:17 AM To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Noel, I forgot to respond to your reply about the IANA registration of "rate" in = oc-algo. I see that draft-ietf-soc-overload-control-13 mentions your I-D b= ut does not have "rate" in algo-list. There are two possible ways to address "rate" in algo-list. One is to have= draft-ietf-soc-overload-control-13 add "rate" to algo-list and refer to yo= ur I-D for details. The other is to register "rate" in algo-list with IANA= in your I-D, and this should be a simple task. The cleaner way that is mo= re inline with the IETF process would be the latter. It seems odd to have = something defined in a RFC without details about it, and it would be too mu= ch trouble to combine the two I-Ds. James From: Yu, James Sent: Wednesday, July 10, 2013 9:01 AM To: 'NOEL, ERIC C (ERIC C)' Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Noel, I mentioned in my message to Janet on 7/2: For the rate control, the server could calculate the arrival rate from each= communicating client so that it could allocate the overall target SIP requ= est rate to the clients based on their arrival rates known to the server. = But another option is for the client to "optionally" include its calculated= arrival rate in its request to the server when rate control related parame= ters are present. Should this option be evaluated/included to relieve the = server from doing the arrival rate calculations. This would be beneficial = to a server when it receives the requests from many clients. I suggest that the I-D adds that option to allow the client to indicate its= current arrival rate (towards the receiving server) in the SIP request. James From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] Sent: Tuesday, July 09, 2013 4:44 PM To: Yu, James; Janet P Gunn Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Janet, James, Thanks you for your valuable comments and discussion. I tried to capture a= ll resolution in the following text (based on James word document with trac= k changes and imbedded comments enabled). + Abstract section: - Agreed with suggested changes - Please note I will also need to make further changes to remove all refere= nces per Christer Holmberg comment + Section 1: - Agreed with suggested changes + Section 3.1: - Agreed with suggested changes + Section 3.2: - Please note the section title will become "Via header fiel= d parameters for overload control " per Christer Holmberg comment - Agreed with suggested changes excluding title that will change per previo= us bullet + Section 3.3: - Agreed with suggested changes + Section 3.4: - ID: "Note that the target SIP request rate is a max rate that may not be= attained by the arrival rate at the client, and the server cannot assume t= hat it will." [JY] Not clear what value this paragraph tries to add. Is it saying tha= t the client's arrival rate may be lower than the target SIP request rate? [JG] Yes + supporting example (see below in thread) Agreed with Janet and supporting example. Per James request, I will add t= he following text (inspired from Janet's illustrative example): "In other words, when multiple clients are being controlled by an overlo= aded server, at any given time some clients may receive requests at a rate = below its target SIP request rate while others above that target rate. But = the resulting request rate presented to the overloaded server will converge= towards the target SIP request rate." - Agreed with other suggested changes + Section 3.5.1: - ID: "And the larger the difference between TAU1 and TAU2, the closer to t= he control is to strict priority." [JY] Suggest changing into "And the larger the difference between TAU1 an= d TAU2, the closer the control is to strict priority queuing." [JG] Suggest changing into "And the larger the difference between TAU1 an= d TAU2, the closer the control is to strict priority treatment." [EN] Agreed with Janet's suggestion - Agreed with other suggested changes + Section 4: - Agreed with suggested changes + Section 5: - Please note that based comments from per Christer Holmberg and Janet Gunn= , the following was tentatively agreed Replace oc-value =3D "NaN" / oc-num by oc =3D "oc" [EQUAL oc-num] - Agreed with other suggested change + Section 7: - [JY] Should "rate" in oc-algo be registered with IANA? This issue needs to be addressed by draft-ietf-soc-overload-control autho= rs Please note I will wait until expiration of WGLC prior updating our draft R= FC. Once again your comments and/or suggestions are most appreciated. 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 Yu, James Sent: Tuesday, July 02, 2013 9:42 AM To: Janet P Gunn Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Janet, For my comment on section 3.4 (the first one below), the current text does = not provide any value. The client's arrival rate could be well below the t= arget SIP request rate when its load is light so the fact that the client m= ay not achieve the target SIP request rate (the max. rate it is allowed to = send to the server) is well understood. But with your explanation on the "= delta" part, the text then makes sense. Please add some discussions on the= "delta" aspect so that even if the average arrival rate at the client is h= igher than the target SIP request rate the client at times may not send mor= e than what the target SIP request rate allows due to the fluctuation of th= e arriving requests at the client. For the comment on section 3.5.1, I agree with your proposed change. For the rate control, the server could calculate the arrival rate from each= communicating client so that it could allocate the overall target SIP requ= est rate to the clients based on their arrival rates known to the server. = But another option is for the client to "optionally" include its calculated= arrival rate in its request to the server when rate control related parame= ters are present. Should this option be evaluated/included to relieve the = server from doing the arrival rate calculations. This would be beneficial = to a server when it receives the requests from many clients. James From: Janet P Gunn [mailto:jgunn6@csc.com] Sent: Friday, June 28, 2013 3:34 PM To: Yu, James Cc: draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org; sip-overload-bounces@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, It is a little hard to respond in email when your comments are in a separat= e document, but here goes. section 3.4 ID says: "Note that the target SIP request rate is a max rate that may not be attained by the arrival rate at the client, and the server cannot assume that it will." Your comment : "Not clear what value this paragraph tries to add. Is it saying that the c= lient's arrival rate may be lower than the target SIP request rate? " Yes. Suppose the server want to limit the total rate of arriving SIP messages to= 100 / sec, and has 10 clients. Each client has a high variance in its mes= sage rate, but together they are well above 100 messages per sec If it sets the rate at 10 messages per second for each of the clients, it w= ill almost certainly end up with an overall average of less than 100 messa= ges per sec, because some clients will be in a "lull" while others are busy= . This is good from a throttling perspective, but, assuming messages are c= orrelated with revenue, bad/wasteful from a revenue, or overall productivit= y perspective. So the server might want to set the rate per client to 10 += delta, where delta is going to be very specific to operating environment. --- In section 3.5.1, bottom of page 8 ID says: "And the larger the difference between TAU1 and TAU2, the closer to the control is to strict priority." You propose changing it to: "And the larger the difference between TAU1 and TAU2, the closer the control is to strict priority queuing." I agree with taking out the redundant "to". But I disagree wit adding "que= uing". There is no queuing, priority or otherwise involved. You could say: "And the larger the difference between TAU1 and TAU2, the closer the control is to strict priority treatment." where " strict priority treatment" would refer to the case where non-priori= ty messages are restricted to a total (priority + non-priority) rate of 10 = messages per second, but priority messages can continue to be sent as long = as the total (priority + non-priority) rate is less than 12 messages per se= cond. At least, I think that is what Eric and Philip are trying to say. 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: "Yu, James" = > To: "sip-overload-bounces@ietf.org" >= , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" >, "sip-overload@ietf.org"= > Date: 06/28/2013 08:10 AM Subject: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Sent by: sip-overload-bounces@ietf.org ________________________________ Salvatore, Please see the attachment for my comments. I pasted the text to a word document to trace/show the proposed changes and= comments. Regards, James [attachment "comments on draft-ietf-soc-overload-rate-control-04.docx" del= eted by Janet P Gunn/USA/CSC] _____________________________________________= __ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6452 - Release Date: 06/30/13 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13 --_000_7594FB04B1934943A5C02806D1A2204B1C3DA597ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

I support = Keith’s suggestion. There is no need to copy/paste syntax from anothe= r specification – we should simply define the syntax additions/extens= ions.

 = ;

Regards,

 = ;

Christer

 = ;

L=E4hett=E4j=E4: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] Puolesta NOEL, ERIC C (ERIC C)
L=E4hetetty: 11. hein=E4kuuta 2013 21:33
Vastaanottaja: 'DRAGE, Keith (Keith)'; 'Yu, James'
Kopio: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-c= ontrol.all@tools.ietf.org; sip-overload@ietf.org
Aihe: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt=

 

Keith,

 = ;

Thank you = for your comment.

 = ;

IANA impac= ts:

- Based on= Keith suggestion, for the IANA impacts we only need to have the IANA consi= deration section in draft-ietf-soc-overload-control to include the future RFC number for draft-ietf-soc-overload-rate-control in the refe= rence column

- While Ja= mes is suggesting explicitly defining the new parameter value in the IANA c= onsideration section of draft-ietf-soc-overload-rate-control

=3D> Be= cause Keith proposal is aligned with RFC 3968 guidelines, I propose adoptin= g his proposal.

 = ;

ABNF impac= ts:

- Based on= Keith suggestion, draft-ietf-soc-overload-rate-control syntax section shou= ld be reduced to

algo-list = /=3D “rate“

- While Ja= mes is suggesting that section to include

oc =3D = 220;oc” [EQUAL oc-num]

oc-num =3D= 1*DIGIT

oc-algo = =3D "oc-algo" EQUAL DQUOTE algo-list *(COMMA algo-list) DQUOTE

algo-list = =3D “loss” / “rate“ / *(other-algo)

other-algo= =3D %x41-5A / %x61-7A / %x30-39

=3D> Pe= r Keith suggestion, to prevent potential conflicts, I propose adopting his = proposal.

 = ;

James woul= d you agree with the proposed resolution?

 = ;

Thanks,

 = ;

 = ;

From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com]
Sent: Wednesday, July 10, 2013 6:05 PM
To: NOEL, ERIC C (ERIC C); 'Yu, James'
Cc: sip-overload-bo= unces@ietf.org; = draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt

 

I’ve lost= track of what is happening here. What I expect is two things:

 

1)  &= nbsp;      IANA registration impact.

 

For the header = field parameters registry, draft-ietf-soc-overload-control already creates = the new rows:

 

       Header Field=
  Parameter Name  Predefined Values  Reference
       ____________=
______________________________________________
       Via &nb=
sp;         oc   &nb=
sp;            =
 Yes            =
; RFCXXXX
       Via &nb=
sp;         oc-validity  =
      Yes       =
;      RFCXXXX
       Via &nb=
sp;         oc-seq   =
;          Yes  &nbs=
p;          RFCXXXX=

       Via &nb=
sp;         oc-algo  &nbs=
p;         Yes   &nb=
sp;         RFCXXXX
 
       RFC XXXX [NO=
TE TO RFC-EDITOR: Please replace with final RFC
       number of th=
is specification.]

 

For the predefi= ned values columns, RFC 3968 states:

 

   Some SIP header field parameters onl=
y accept a set of predefined
   parameter values.  For example,=
 a parameter indicating the transport
   protocol in use may only accept the =
predefined tokens TCP, UDP, and
   SCTP as valid values.  Register=
ing all parameter values for all SIP
   header field parameters of this type=
 would require a large number of
   subregistries.  Instead, we hav=
e chosen to register parameter values
   by reference.  That is, the ent=
ry in the parameter registry for a
   given header field parameter contain=
s references to the RFCs defining
   new values of the parameter.  R=
eferences to RFCs defining parameter
   values appear in double brackets in =
the registry.
 
   So, the header field parameter regis=
try contains a column that
   indicates whether or not each parame=
ter only accepts a set of
   predefined values.  Implementer=
s of parameters with a "yes" in that
   column need to find all the valid pa=
rameter values in the RFCs
   provided as references.

 

With this under= standing, I do not believe the rate-control draft needs to modify the ̶= 0;predefined values” column. What it does need to do is add its ultimate RFC number to the reference column.

 

There could be = an argument that there needs to be a new table that lists the algorithm val= ues, but

 

a)&nb= sp;            if such= a table is to be created, it needs to be created by draft-ietf-soc-overloa= d-control rather than the rate-control draft/

b)&nb= sp;           I perso= nally do not think it is necessary to add such a new table, as I think the = references are sufficient. One cannot handle the algorithm values unless one goes to the relevant RFC.

 

2)  &= nbsp;      ABNF impact.

 

ABNF defines th= e /=3D operator for adding new values to an existing defined list.

 

I do not think = we should reproduce existing ABNF from draft-ietf-soc-overload-control and = then amend it.

 

The reason for = this is that tools exist for automatically extracting the ABNF from RFCs. A= n extracted

 

algo-list = /=3D “rate“

 

will work perfe= ctly well with the extract from draft-ietf-soc-overload-control (and from S= IP). Reproducing productions will result in conflict.

 

Regards

 

Keith

 

From: sip-overload-bounces@ietf.= org [mailto:sip-overlo= ad-bounces@ietf.org] On Behalf Of NOEL, ERIC C (ERIC C)
Sent: 10 July 2013 20:54
To: 'Yu, James'
Cc: sip-overload-bo= unces@ietf.org; = draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt

 

James,

 = ;

So section= 5 (syntax) will include the following statements:

 = ;

oc =3D = 220;oc” [EQUAL oc-num]

oc-num =3D= 1*DIGIT

oc-algo = =3D "oc-algo" EQUAL DQUOTE algo-list *(COMMA algo-list) DQUOTE

algo-list = =3D “loss” / “rate“ / *(other-algo)

other-algo= =3D %x41-5A / %x61-7A / %x30-39

 = ;

Thanks,

 = ;

Eric Noel

AT&T= Labs, Inc.
Rethink Possible

&nb= sp;

Network Des= ign and Performance Analysis
200 South Laurel Avenue, D5-3D19
Middletown, NJ 07748
P: 732.420.4174

ecnoel@att.com

 = ;

From: Yu, James [ma= ilto:james.yu@neustar.biz]
Sent: Wednesday, July 10, 2013 3:10 PM
To: NOEL, ERIC C (ERIC C)
Cc: sip-overload-bo= unces@ietf.org; = draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt

 

Eric,

You may wa= nt to copy the “oc-algo” line from other I-D.=

 = ;

James=

 = ;

From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com]
Sent: Wednesday, July 10, 2013 1:10 PM
To: Yu, James
Cc: sip-overload-bo= unces@ietf.org; = draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt

 

James,

 = ;

Based on y= our suggestion and comments from other reviewers, I intend to update sectio= n 5 (syntax) as follows:

 = ;

oc =3D = 220;oc” [EQUAL oc-num]

oc-num =3D= 1*DIGIT

 = ;

algo-list = =3D “loss” / “rate“ / *(other-algo)

other-algo= =3D %x41-5A / %x61-7A / %x30-39

 = ;

I understa= nd there may be an additional change following Henning’s reply.<= /o:p>

 = ;

Thanks,

 = ;

Eric Noel

AT&T= Labs, Inc.
Rethink Possible

&nb= sp;

Network Des= ign and Performance Analysis
200 South Laurel Avenue, D5-3D19
Middletown, NJ 07748
P: 732.420.4174

ecnoel@att.com

 = ;

From: Yu, James [ma= ilto:james.yu@neustar.biz]
Sent: Wednesday, July 10, 2013 11:36 AM
To: NOEL, ERIC C (ERIC C)
Cc: sip-overload-bo= unces@ietf.org; = draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt

 

Eric,=

 = ;

Yes, this = adds “rate” to “oc-algo” parameter but please check= with IANA to see if it is the correct way.  You also need to copy som= e syntax lines from the draft-ietf-soc-overload-control to show

 = ;

 &nbs= p;   algo-list   =3D “loss“ / “rate“<= /span> / *(other-algo)

 = ;

I’ve= an email to Henning asking if algo-list in his I-D should be

 &nbs= p;   algo-list   =3D “loss“ / other-algo

 = ;

If yes, th= en this particular line in your I-D would be

 &nbs= p;   algo-list   =3D “loss“ / “rate“<= /span> / other-algo

 = ;

James=

 = ;

From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com]
Sent: Wednesday, July 10, 2013 10:49 AM
To: Yu, James
Cc: sip-overload-bo= unces@ietf.org; = draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt

 

James,

 = ;

Thank you = for your suggestion.

 = ;

Not being = familiar with IANA procedure, would updating draft-ietf-soc-overload-rate-c= ontrol section 7 (IANA considerations) as follows work?

 = ;

This speci= fication defines a new value for Via header parameter oc-algo as detailed b= elow in the "Header Field Parameter and Parameter Values" subregistry as per the registry created by [RFC3968]. The required informa= tion is:

 = ;

Header Fie= ld           Parameter Na= me             =            Predefine= d Values            =         Reference=

----------= ---------------------------------------------------------------------------= ---------------------

Via  =             &nb= sp;            =    oc-algo         &= nbsp;           &nbs= p;            &= nbsp;           R= 20;rate”          &= nbsp;           &nbs= p;             =          RFCXXXX

 = ;

RFC XXXX [= NOTE TO RFC-EDITOR: Please replace with final RFC number of this specificat= ion.]

 = ;

Thanks,

 = ;

Eric Noel

AT&T= Labs, Inc.
Rethink Possible

&nb= sp;

Network Des= ign and Performance Analysis
200 South Laurel Avenue, D5-3D19
Middletown, NJ 07748
P: 732.420.4174

ecnoel@att.com

 = ;

From: Yu, James [ma= ilto:james.yu@neustar.biz]
Sent: Wednesday, July 10, 2013 10:17 AM
To: NOEL, ERIC C (ERIC C)
Cc: sip-overload-bo= unces@ietf.org; = draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt

 

Noel,=

 = ;

I forgot t= o respond to your reply about the IANA registration of “rate” i= n oc-algo.  I see that draft-ietf-soc-overload-control-13 mentions you= r I-D but does not have “rate” in algo-list.

 = ;

There are = two possible ways to address “rate” in algo-list.  One is = to have draft-ietf-soc-overload-control-13 add “rate” to algo-l= ist and refer to your I-D for details.  The other is to register “rate”= in algo-list with IANA in your I-D, and this should be a simple task. = ; The cleaner way that is more inline with the IETF process would be the la= tter.  It seems odd to have something defined in a RFC without details about it, and it would be too much trouble to combine the = two I-Ds.

 = ;

James=

 = ;

From: Yu, James
Sent: Wednesday, July 10, 2013 9:01 AM
To: 'NOEL, ERIC C (ERIC C)'
Cc: sip-overload-bo= unces@ietf.org; = draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt

 

Noel,=

 = ;

I mentione= d in my message to Janet on 7/2:

 = ;

For the rate control, the server could calculate the arriv= al rate from each communicating client so that it could allocate the overall target SIP request rate to the clients based on their arrival = rates known to the server.  But another option is for the client to &#= 8220;optionally” include its calculated arrival rate in its request t= o the server when rate control related parameters are present.  Should this option be evaluated/included to relieve the= server from doing the arrival rate calculations.  This would be benef= icial to a server when it receives the requests from many clients.

 = ;

I suggest = that the I-D adds that option to allow the client to indicate its current a= rrival rate (towards the receiving server) in the SIP request.

 = ;

James=

 = ;

From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com]
Sent: Tuesday, July 09, 2013 4:44 PM
To: Yu, James; Janet P Gunn
Cc: sip-overload-bo= unces@ietf.org; = draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt

 

Janet, Jam= es,

 = ;

Thanks you= for your valuable comments and discussion.  I tried to capture all re= solution in the following text (based on James word document with track changes and imbedded comments enabled).

 = ;

+ Abst= ract section:

- Agreed w= ith suggested changes

- Please n= ote I will also need to make further changes to remove all references per C= hrister Holmberg comment

 = ;

+ Sect= ion 1:

- Agreed w= ith suggested changes

 = ;

+ Sect= ion 3.1:

- Agreed w= ith suggested changes

 

+ Sect= ion 3.2: - Please note the section title will become “Via header fiel= d parameters for overload control “ per Christer Holmberg comment

- Agreed w= ith suggested changes excluding title that will change per previous bullet<= o:p>

 = ;

+ Sect= ion 3.3:

- Agreed w= ith suggested changes

 = ;

+ Sect= ion 3.4:

- ID: &nbs= p;"Note that the target SIP request rate is a max rate that may not be= attained by the arrival rate at the client, and the server cannot assume that it will."

 &nbs= p; [JY] Not clear what value this paragraph tries to add.  Is it = saying that the client's arrival rate may be lower than the target SIP requ= est rate?

 &nbs= p; [JG] Yes + supporting example (see below in thread)<= /span>

 &nbs= p;Agreed with Janet and supporting example. Per James request, I will add t= he following text (inspired from Janet’s illustrative example):<= /o:p>

 &nbs= p; “In other words, when multiple clients are being controlled by an = overloaded server, at any given time some clients may receive requests at a rate below its target SIP request rate while others above that target ra= te. But the resulting request rate presented to the overloaded server will = converge towards the target SIP request rate.”

- Agreed w= ith other suggested changes

 &nbs= p;   

+ Sect= ion 3.5.1:

- ID: R= 20;And the larger the difference between TAU1 and TAU2, the closer to the c= ontrol is to strict priority.”

  [JY= ] Suggest changing into “And the larger the difference between TAU1 a= nd TAU2, the closer the control is to strict priority queuing.”<= /o:p>

  [JG= ] Suggest changing into “And the larger the difference between TAU1 a= nd TAU2, the closer the control is to strict priority treatment.”

  [EN= ] Agreed with Janet’s suggestion

- Agreed w= ith other suggested changes

 = ;

+ Sect= ion 4:

- Agreed w= ith suggested changes

 = ;

+ Sect= ion 5:

- Please n= ote that based comments from per Christer Holmberg and Janet Gunn, the foll= owing was tentatively agreed

 &nbs= p; Replace oc-value =3D "NaN" / oc-num    by&= nbsp;   oc =3D "oc" [EQUAL oc-num]

- Agreed w= ith other suggested change

 = ;

+ Sect= ion 7:

- [JY] Sho= uld “rate” in oc-algo be registered with IANA?

  Thi= s issue needs to be addressed by draft-ietf-soc-overload-control authors

 = ;

Please not= e I will wait until expiration of WGLC prior updating our draft RFC. Once a= gain your comments and/or suggestions are most appreciated.

 = ;

Thanks,

 = ;

Eric Noel

AT&T= Labs, Inc.
Rethink Possible

&nb= sp;

Network Des= ign 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-overlo= ad-bounces@ietf.org] On Behalf Of Yu, James
Sent: Tuesday, July 02, 2013 9:42 AM
To: Janet P Gunn
Cc: sip-overload-bo= unces@ietf.org; = draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt

 

Janet,

 = ;

For my com= ment on section 3.4 (the first one below), the current text does not provid= e any value.  The client’s arrival rate could be well below the target SIP request rate when its load is light so the fact that the cl= ient may not achieve the target SIP request rate (the max. rate it is allow= ed to send to the server) is well understood.  But with your explanati= on on the “delta” part, the text then makes sense.  Please add some discussions on the “delta” = aspect so that even if the average arrival rate at the client is higher tha= n the target SIP request rate the client at times may not send more than wh= at the target SIP request rate allows due to the fluctuation of the arriving requests at the client.

 = ;

For the co= mment on section 3.5.1, I agree with your proposed change.

 = ;

For the ra= te control, the server could calculate the arrival rate from each communica= ting client so that it could allocate the overall target SIP request rate to the clients based on their arrival rates known to the serv= er.  But another option is for the client to “optionally” = include its calculated arrival rate in its request to the server when rate = control related parameters are present.  Should this option be evaluated/included to relieve the server from doing the arrival = rate calculations.  This would be beneficial to a server when it recei= ves the requests from many clients.

 = ;

James=

 = ;

From: Janet P Gunn [mailt= o:jgunn6@csc.com]
Sent: Friday, June 28, 2013 3:34 PM
To: Yu, James
Cc: draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org; sip-overload-bounces@ietf.org
Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt

 

James,

It is a little hard to respond in email wh= en your comments are in a separate document, but here goes.


section 3.4
ID says:
"Note that the target SIP request rat= e is a max rate that may not be
   attained by the arrival rate = at the client, and the server cannot
   assume that it will."

Your comment :
"Not clear what value this paragraph = tries to add.  Is it saying that the client's arrival rate may be lowe= r than the target SIP request rate?  "

Yes.

Suppose the server want to limit the total= rate of arriving SIP messages to 100 / sec, and has 10 clients.  Each= client has a high variance in its message rate, but together they are well above 100 messages per sec

If it sets the rate at 10 messages per sec= ond for each of the clients, it will almost certainly end up  with an = overall average of less than 100 messages per sec, because some clients will be in a "lull" while others are busy.  This is= good from a throttling perspective, but, assuming messages are correlated = with revenue, bad/wasteful from a revenue, or overall productivity perspect= ive.  So the server might want to set the rate per client to 10 + delta, where delta is going to be very specific to = operating environment.

---
In section  3.5.1, bottom of page 8
ID says:
"And the larger
   the difference between TAU1 a= nd TAU2, the closer to the control is
   to strict priority."

You propose changing it to:
"And the larger
   the difference between TAU1 a= nd TAU2, the closer  the control is
   to strict priority queuing.&q= uot;

I agree with taking out the redundant &quo= t;to".  But I disagree wit adding "queuing".  Ther= e is no queuing, priority or otherwise involved.

You could say:
"And the larger
   the difference between TAU1 a= nd TAU2, the closer  the control is
   to strict priority treatment.= "

where " strict priority treatment&quo= t; would refer to the case where non-priority messages are restricted to a = total (priority + non-priority) rate of 10 messages per second, but priority messages can continue to be sent as long as the total (priority &= #43; non-priority) rate is less than 12 messages per second.

At least, I think that is what Eric and &n= bsp;Philip are trying to say.

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 agreement or government initiative exp= ressly permitting the use of e-mail for such purpose.



From:       &n= bsp;"Yu, James" <james.yu@neustar.biz>
To:       &nbs= p;"sip-overload-bounces@ietf.org" <sip-overload-bounces@= ietf.org>, "draft-ietf-soc-overload-rate-control.all@tools.ietf= .org" <draft-ietf-soc-overload-rate-control.all@tools.ietf.org<= /a>>, "sip-overload@ietf.org&q= uot; <sip-overload@ietf.org= >
Date:       &n= bsp;06/28/2013 08:10 AM
Subject:      =  [sip-overload] draft-ietf-soc-overlo= ad-rate-control-04.txt
Sent by:      =  sip-overload-bounces@ietf.org

=


Salvatore,
 
Please see the attachment for my comment= s.
 
I pasted the text to a word document to = trace/show the proposed changes and comments.
 
Regards,
 
James
 [attachment "comments on draf= t-ietf-soc-overload-rate-control-04.docx" deleted by Janet P Gunn/USA/= CSC] ________________= _______________________________
sip-overload mailing list
sip-overload@ietf.org=
https://www.ietf.org/m= ailman/listinfo/sip-overload

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 3204/6452 - Release Date: 06/30/13

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13

--_000_7594FB04B1934943A5C02806D1A2204B1C3DA597ESESSMB209erics_-- From ecnoel@research.att.com Mon Jul 22 06:30:35 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 21AC221E8093; Mon, 22 Jul 2013 06:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.391 X-Spam-Level: X-Spam-Status: No, score=-5.391 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rosT4ArKjGCq; Mon, 22 Jul 2013 06:30:28 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0E421E80AC; Mon, 22 Jul 2013 06:30:28 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id B7E38120373; Mon, 22 Jul 2013 09:30:25 -0400 (EDT) Received: from njfpsrvexg2.research.att.com (njfpsrvexg2.research.att.com [135.207.177.29]) by mail-green.research.att.com (Postfix) with ESMTP id 08CA0E0085; Mon, 22 Jul 2013 09:30:09 -0400 (EDT) Received: from njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9]) by njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9%14]) with mapi; Mon, 22 Jul 2013 09:30:27 -0400 From: "NOEL, ERIC C (ERIC C)" To: 'Christer Holmberg' Date: Mon, 22 Jul 2013 09:30:26 -0400 Thread-Topic: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Thread-Index: Ac5zhcqru7dYQFxqQKSGvvGKSQFJEAAn/KwAALza+IABbsiJAAAiGiWAAAKrhAAAARl8gAABpBAAAANOPYAABCzcAAABjR6AAeiCBIAAabmfkA== Message-ID: <5EBD159DE88147488A3B1590E09001840353C06875E3@njfpsrvexg2.research.att.com> References: <56FB15AFE08E1242B0736CBDCE6E85610808C32F@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610808EF90@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353BDA4CAD4@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E85610809239D@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610809253D@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353C0687578@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E856108092986@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353C068757C@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E856108092BD9@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353C0687581@njfpsrvexg2.research.att.com> <7594FB04B1934943A5C02806D1A2204B1C3DA510@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3DA510@ESESSMB209.ericsson.se> 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_5EBD159DE88147488A3B1590E09001840353C06875E3njfpsrvexg2_" MIME-Version: 1.0 Cc: "sip-overload-bounces@ietf.org" , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" , "sip-overload@ietf.org" Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.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, 22 Jul 2013 13:30:35 -0000 --_000_5EBD159DE88147488A3B1590E09001840353C06875E3njfpsrvexg2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Christer, I believe I addressed all the issues and will send an updated version short= ly to finalize the WGLC. Thanks, Eric Noel AT&T Labs, Inc. Rethink Possible Optimization, Reliability and Customer Analytics 200 South Laurel Avenue, D5-3D19 Middletown, NJ 07748 P: 732.420.4174 ecnoel@att.com From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Saturday, July 20, 2013 7:04 AM To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all= @tools.ietf.org; sip-overload@ietf.org Subject: VS: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Hi Eric, In an e-mail you said that you will wait for "WGLC expiration" before you s= ubmit a new version of the draft. But, WGLC will not "expire" until we have a draft which addresses the raise= d issues :) So, if you think the issues have been solved, I would suggest that you subm= it a new version of the draft, where the solutions are implemented, so that= people can take a look. Regards, Christer --_000_5EBD159DE88147488A3B1590E09001840353C06875E3njfpsrvexg2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Christer,=

 <= /p>

I believe I addressed all the issues and wil= l send an updated version shortly to finalize the WGLC.

 

Thanks,

&n= bsp;

Eric Noel=

AT&T Labs, Inc.
Rethink Possible

 

Optimization, Reliability and Customer Analytics=

200 South Laurel Avenue, D5-3D19
Middleto= wn, NJ 07748
P: 732.420.4174

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>ecnoel@att.com

 

From: Christer Holmberg [mailto:chris= ter.holmberg@ericsson.com]
Sent: Saturday, July 20, 2013 7:04 AM=
To: NOEL, ERIC C (ERIC C)
Cc: sip-overload-bounces@iet= f.org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overloa= d@ietf.org
Subject: VS: [sip-overload] draft-ietf-soc-overload-ra= te-control-04.txt

 

Hi Eric,=

 

In an e-mail you said that you will wait for = ”WGLC expiration” before you submit a new version of the draft.=

 <= /p>

But, WGLC will not “expire” unti= l we have a draft which addresses the raised issues :)

 

So, if you think the issues have been solved, I would suggest tha= t you submit a new version of the draft, where the solutions are implemente= d, so that people can take a look.

 

Regards,

 

Christer

= --_000_5EBD159DE88147488A3B1590E09001840353C06875E3njfpsrvexg2_-- From ecnoel@research.att.com Mon Jul 22 06:38:59 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 4926B11E80F0; Mon, 22 Jul 2013 06:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.488 X-Spam-Level: X-Spam-Status: No, score=-6.488 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sv42mE3GRuHF; Mon, 22 Jul 2013 06:38:46 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id E826F11E80AE; Mon, 22 Jul 2013 06:38:45 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 8C65812034F; Mon, 22 Jul 2013 09:38:43 -0400 (EDT) Received: from njfpsrvexg2.research.att.com (njfpsrvexg2.research.att.com [135.207.177.29]) by mail-green.research.att.com (Postfix) with ESMTP id C9289E0085; Mon, 22 Jul 2013 09:38:26 -0400 (EDT) Received: from njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9]) by njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9%14]) with mapi; Mon, 22 Jul 2013 09:38:45 -0400 From: "NOEL, ERIC C (ERIC C)" To: 'Christer Holmberg' , "'DRAGE, Keith (Keith)'" , "'Yu, James'" Date: Mon, 22 Jul 2013 09:38:44 -0400 Thread-Topic: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Thread-Index: Ac5zhcqru7dYQFxqQKSGvvGKSQFJEAAn/KwAALza+IABbsiJAAAiGiWAAAKrhAAAARl8gAABpBAAAANOPYAABCzcAAABjR6AAASO6QAAKuPFAAG5ULpgAGmY52A= Message-ID: <5EBD159DE88147488A3B1590E09001840353C06875E4@njfpsrvexg2.research.att.com> References: <56FB15AFE08E1242B0736CBDCE6E85610808C32F@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610808EF90@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353BDA4CAD4@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E85610809239D@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610809253D@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353C0687578@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E856108092986@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353C068757C@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E856108092BD9@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353C0687581@njfpsrvexg2.research.att.com> <949EF20990823C4C85C18D59AA11AD8B06820F@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5EBD159DE88147488A3B1590E09001840353C068758D@njfpsrvexg2.research.att.com> <7594FB04B1934943A5C02806D1A2204B1C3DA597@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3DA597@ESESSMB209.ericsson.se> 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_5EBD159DE88147488A3B1590E09001840353C06875E4njfpsrvexg2_" MIME-Version: 1.0 Cc: "sip-overload-bounces@ietf.org" , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" , "sip-overload@ietf.org" Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.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, 22 Jul 2013 13:38:59 -0000 --_000_5EBD159DE88147488A3B1590E09001840353C06875E4njfpsrvexg2_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Christer, Thanks for the follow-up. We had off line email exchanges between Keith Drage and James Yu on this is= sue (I just realize I forgot to post the resolution). The following was agreed: Update Section 7, "IANA Considerations": Header Field Parameter Name Predefined Values = Reference _________________________________________________________________ Via oc-algo = Yes RFCABCD RFCOPRQ RFCABCD RFCOPRQ [NOTE TO RFC-EDITOR: Please replace with final RFC number o= f draft-ietf-soc-overload-rate-control & draft-ietf-soc-overload-control] Update Section 5, "Syntax": This specification extends the existing definition of the Via header field = parameters of [RFC3261] as follows: algo-list /=3D "rate" And no additional changes related to the above will be required in draft-ie= tf-soc-overload-control. Thanks, Eric Noel AT&T Labs, Inc. Rethink Possible Optimization, Reliability and Customer Analytics 200 South Laurel Avenue, D5-3D19 Middletown, NJ 07748 P: 732.420.4174 ecnoel@att.com From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Saturday, July 20, 2013 7:11 AM To: NOEL, ERIC C (ERIC C); 'DRAGE, Keith (Keith)'; 'Yu, James' Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all= @tools.ietf.org; sip-overload@ietf.org Subject: VS: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Hi, I support Keith's suggestion. There is no need to copy/paste syntax from an= other specification - we should simply define the syntax additions/extensio= ns. Regards, Christer L=E4hett=E4j=E4: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces= @ietf.org] Puolesta NOEL, ERIC C (ERIC C) L=E4hetetty: 11. hein=E4kuuta 2013 21:33 Vastaanottaja: 'DRAGE, Keith (Keith)'; 'Yu, James' Kopio: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.= all@tools.ietf.org; sip-overload@ietf.org Aihe: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Keith, Thank you for your comment. IANA impacts: - Based on Keith suggestion, for the IANA impacts we only need to have the = IANA consideration section in draft-ietf-soc-overload-control to include th= e future RFC number for draft-ietf-soc-overload-rate-control in the referen= ce column - While James is suggesting explicitly defining the new parameter value in = the IANA consideration section of draft-ietf-soc-overload-rate-control =3D> Because Keith proposal is aligned with RFC 3968 guidelines, I propose = adopting his proposal. ABNF impacts: - Based on Keith suggestion, draft-ietf-soc-overload-rate-control syntax se= ction should be reduced to algo-list /=3D "rate" - While James is suggesting that section to include oc =3D "oc" [EQUAL oc-num] oc-num =3D 1*DIGIT oc-algo =3D "oc-algo" EQUAL DQUOTE algo-list *(COMMA algo-list) DQUOTE algo-list =3D "loss" / "rate" / *(other-algo) other-algo =3D %x41-5A / %x61-7A / %x30-39 =3D> Per Keith suggestion, to prevent potential conflicts, I propose adopti= ng his proposal. James would you agree with the proposed resolution? 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: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] Sent: Wednesday, July 10, 2013 6:05 PM To: NOEL, ERIC C (ERIC C); 'Yu, James' Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt I've lost track of what is happening here. What I expect is two things: 1) IANA registration impact. For the header field parameters registry, draft-ietf-soc-overload-control a= lready creates the new rows: Header Field Parameter Name Predefined Values Reference __________________________________________________________ Via oc Yes RFCXXXX Via oc-validity Yes RFCXXXX Via oc-seq Yes RFCXXXX Via oc-algo Yes RFCXXXX RFC XXXX [NOTE TO RFC-EDITOR: Please replace with final RFC number of this specification.] For the predefined values columns, RFC 3968 states: Some SIP header field parameters only accept a set of predefined parameter values. For example, a parameter indicating the transport protocol in use may only accept the predefined tokens TCP, UDP, and SCTP as valid values. Registering all parameter values for all SIP header field parameters of this type would require a large number of subregistries. Instead, we have chosen to register parameter values by reference. That is, the entry in the parameter registry for a given header field parameter contains references to the RFCs defining new values of the parameter. References to RFCs defining parameter values appear in double brackets in the registry. So, the header field parameter registry contains a column that indicates whether or not each parameter only accepts a set of predefined values. Implementers of parameters with a "yes" in that column need to find all the valid parameter values in the RFCs provided as references. With this understanding, I do not believe the rate-control draft needs to m= odify the "predefined values" column. What it does need to do is add its ul= timate RFC number to the reference column. There could be an argument that there needs to be a new table that lists th= e algorithm values, but a) if such a table is to be created, it needs to be create= d by draft-ietf-soc-overload-control rather than the rate-control draft/ b) I personally do not think it is necessary to add such a= new table, as I think the references are sufficient. One cannot handle the= algorithm values unless one goes to the relevant RFC. 2) ABNF impact. ABNF defines the /=3D operator for adding new values to an existing defined= list. I do not think we should reproduce existing ABNF from draft-ietf-soc-overlo= ad-control and then amend it. The reason for this is that tools exist for automatically extracting the AB= NF from RFCs. An extracted algo-list /=3D "rate" will work perfectly well with the extract from draft-ietf-soc-overload-cont= rol (and from SIP). Reproducing productions will result in conflict. Regards Keith ________________________________ From: sip-overload-bounces@ietf.org [= mailto:sip-overload-bounces@ietf.org] On Behalf Of NOEL, ERIC C (ERIC C) Sent: 10 July 2013 20:54 To: 'Yu, James' Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, So section 5 (syntax) will include the following statements: oc =3D "oc" [EQUAL oc-num] oc-num =3D 1*DIGIT oc-algo =3D "oc-algo" EQUAL DQUOTE algo-list *(COMMA algo-list) DQUOTE algo-list =3D "loss" / "rate" / *(other-algo) other-algo =3D %x41-5A / %x61-7A / %x30-39 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: Yu, James [mailto:james.yu@neustar.biz] Sent: Wednesday, July 10, 2013 3:10 PM To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Eric, You may want to copy the "oc-algo" line from other I-D. James From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] Sent: Wednesday, July 10, 2013 1:10 PM To: Yu, James Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, Based on your suggestion and comments from other reviewers, I intend to upd= ate section 5 (syntax) as follows: oc =3D "oc" [EQUAL oc-num] oc-num =3D 1*DIGIT algo-list =3D "loss" / "rate" / *(other-algo) other-algo =3D %x41-5A / %x61-7A / %x30-39 I understand there may be an additional change following Henning's reply. 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: Yu, James [mailto:james.yu@neustar.biz] Sent: Wednesday, July 10, 2013 11:36 AM To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Eric, Yes, this adds "rate" to "oc-algo" parameter but please check with IANA to = see if it is the correct way. You also need to copy some syntax lines from= the draft-ietf-soc-overload-control to show algo-list =3D "loss" / "rate" / *(other-algo) I've an email to Henning asking if algo-list in his I-D should be algo-list =3D "loss" / other-algo If yes, then this particular line in your I-D would be algo-list =3D "loss" / "rate" / other-algo James From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] Sent: Wednesday, July 10, 2013 10:49 AM To: Yu, James Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, Thank you for your suggestion. Not being familiar with IANA procedure, would updating draft-ietf-soc-overl= oad-rate-control section 7 (IANA considerations) as follows work? This specification defines a new value for Via header parameter oc-algo as = detailed below in the "Header Field Parameter and Parameter Values" subregi= stry as per the registry created by [RFC3968]. The required information is: Header Field Parameter Name Predefined Val= ues Reference ---------------------------------------------------------------------------= ------------------------------- Via oc-algo = "rate" RFCXXXX RFC XXXX [NOTE TO RFC-EDITOR: Please replace with final RFC number of this = specification.] 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: Yu, James [mailto:james.yu@neustar.biz] Sent: Wednesday, July 10, 2013 10:17 AM To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Noel, I forgot to respond to your reply about the IANA registration of "rate" in = oc-algo. I see that draft-ietf-soc-overload-control-13 mentions your I-D b= ut does not have "rate" in algo-list. There are two possible ways to address "rate" in algo-list. One is to have= draft-ietf-soc-overload-control-13 add "rate" to algo-list and refer to yo= ur I-D for details. The other is to register "rate" in algo-list with IANA= in your I-D, and this should be a simple task. The cleaner way that is mo= re inline with the IETF process would be the latter. It seems odd to have = something defined in a RFC without details about it, and it would be too mu= ch trouble to combine the two I-Ds. James From: Yu, James Sent: Wednesday, July 10, 2013 9:01 AM To: 'NOEL, ERIC C (ERIC C)' Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Noel, I mentioned in my message to Janet on 7/2: For the rate control, the server could calculate the arrival rate from each= communicating client so that it could allocate the overall target SIP requ= est rate to the clients based on their arrival rates known to the server. = But another option is for the client to "optionally" include its calculated= arrival rate in its request to the server when rate control related parame= ters are present. Should this option be evaluated/included to relieve the = server from doing the arrival rate calculations. This would be beneficial = to a server when it receives the requests from many clients. I suggest that the I-D adds that option to allow the client to indicate its= current arrival rate (towards the receiving server) in the SIP request. James From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] Sent: Tuesday, July 09, 2013 4:44 PM To: Yu, James; Janet P Gunn Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Janet, James, Thanks you for your valuable comments and discussion. I tried to capture a= ll resolution in the following text (based on James word document with trac= k changes and imbedded comments enabled). + Abstract section: - Agreed with suggested changes - Please note I will also need to make further changes to remove all refere= nces per Christer Holmberg comment + Section 1: - Agreed with suggested changes + Section 3.1: - Agreed with suggested changes + Section 3.2: - Please note the section title will become "Via header fiel= d parameters for overload control " per Christer Holmberg comment - Agreed with suggested changes excluding title that will change per previo= us bullet + Section 3.3: - Agreed with suggested changes + Section 3.4: - ID: "Note that the target SIP request rate is a max rate that may not be= attained by the arrival rate at the client, and the server cannot assume t= hat it will." [JY] Not clear what value this paragraph tries to add. Is it saying tha= t the client's arrival rate may be lower than the target SIP request rate? [JG] Yes + supporting example (see below in thread) Agreed with Janet and supporting example. Per James request, I will add t= he following text (inspired from Janet's illustrative example): "In other words, when multiple clients are being controlled by an overlo= aded server, at any given time some clients may receive requests at a rate = below its target SIP request rate while others above that target rate. But = the resulting request rate presented to the overloaded server will converge= towards the target SIP request rate." - Agreed with other suggested changes + Section 3.5.1: - ID: "And the larger the difference between TAU1 and TAU2, the closer to t= he control is to strict priority." [JY] Suggest changing into "And the larger the difference between TAU1 an= d TAU2, the closer the control is to strict priority queuing." [JG] Suggest changing into "And the larger the difference between TAU1 an= d TAU2, the closer the control is to strict priority treatment." [EN] Agreed with Janet's suggestion - Agreed with other suggested changes + Section 4: - Agreed with suggested changes + Section 5: - Please note that based comments from per Christer Holmberg and Janet Gunn= , the following was tentatively agreed Replace oc-value =3D "NaN" / oc-num by oc =3D "oc" [EQUAL oc-num] - Agreed with other suggested change + Section 7: - [JY] Should "rate" in oc-algo be registered with IANA? This issue needs to be addressed by draft-ietf-soc-overload-control autho= rs Please note I will wait until expiration of WGLC prior updating our draft R= FC. Once again your comments and/or suggestions are most appreciated. 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 Yu, James Sent: Tuesday, July 02, 2013 9:42 AM To: Janet P Gunn Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Janet, For my comment on section 3.4 (the first one below), the current text does = not provide any value. The client's arrival rate could be well below the t= arget SIP request rate when its load is light so the fact that the client m= ay not achieve the target SIP request rate (the max. rate it is allowed to = send to the server) is well understood. But with your explanation on the "= delta" part, the text then makes sense. Please add some discussions on the= "delta" aspect so that even if the average arrival rate at the client is h= igher than the target SIP request rate the client at times may not send mor= e than what the target SIP request rate allows due to the fluctuation of th= e arriving requests at the client. For the comment on section 3.5.1, I agree with your proposed change. For the rate control, the server could calculate the arrival rate from each= communicating client so that it could allocate the overall target SIP requ= est rate to the clients based on their arrival rates known to the server. = But another option is for the client to "optionally" include its calculated= arrival rate in its request to the server when rate control related parame= ters are present. Should this option be evaluated/included to relieve the = server from doing the arrival rate calculations. This would be beneficial = to a server when it receives the requests from many clients. James From: Janet P Gunn [mailto:jgunn6@csc.com] Sent: Friday, June 28, 2013 3:34 PM To: Yu, James Cc: draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org; sip-overload-bounces@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, It is a little hard to respond in email when your comments are in a separat= e document, but here goes. section 3.4 ID says: "Note that the target SIP request rate is a max rate that may not be attained by the arrival rate at the client, and the server cannot assume that it will." Your comment : "Not clear what value this paragraph tries to add. Is it saying that the c= lient's arrival rate may be lower than the target SIP request rate? " Yes. Suppose the server want to limit the total rate of arriving SIP messages to= 100 / sec, and has 10 clients. Each client has a high variance in its mes= sage rate, but together they are well above 100 messages per sec If it sets the rate at 10 messages per second for each of the clients, it w= ill almost certainly end up with an overall average of less than 100 messa= ges per sec, because some clients will be in a "lull" while others are busy= . This is good from a throttling perspective, but, assuming messages are c= orrelated with revenue, bad/wasteful from a revenue, or overall productivit= y perspective. So the server might want to set the rate per client to 10 += delta, where delta is going to be very specific to operating environment. --- In section 3.5.1, bottom of page 8 ID says: "And the larger the difference between TAU1 and TAU2, the closer to the control is to strict priority." You propose changing it to: "And the larger the difference between TAU1 and TAU2, the closer the control is to strict priority queuing." I agree with taking out the redundant "to". But I disagree wit adding "que= uing". There is no queuing, priority or otherwise involved. You could say: "And the larger the difference between TAU1 and TAU2, the closer the control is to strict priority treatment." where " strict priority treatment" would refer to the case where non-priori= ty messages are restricted to a total (priority + non-priority) rate of 10 = messages per second, but priority messages can continue to be sent as long = as the total (priority + non-priority) rate is less than 12 messages per se= cond. At least, I think that is what Eric and Philip are trying to say. 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: "Yu, James" = > To: "sip-overload-bounces@ietf.org" >= , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" >, "sip-overload@ietf.org"= > Date: 06/28/2013 08:10 AM Subject: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Sent by: sip-overload-bounces@ietf.org ________________________________ Salvatore, Please see the attachment for my comments. I pasted the text to a word document to trace/show the proposed changes and= comments. Regards, James [attachment "comments on draft-ietf-soc-overload-rate-control-04.docx" del= eted by Janet P Gunn/USA/CSC] _____________________________________________= __ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6452 - Release Date: 06/30/13 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13 --_000_5EBD159DE88147488A3B1590E09001840353C06875E4njfpsrvexg2_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Christer,=

 <= /p>

Thanks for the follow-up.<= /p>

 

We had off line email exchanges between Keith Drage and James Y= u on this issue (I just realize I forgot to post the resolution).

 

The following was agreed:

 

Update Section 7, “IANA Considerations”:

       Header &n= bsp;           Field=   Parameter Name        Predefined =  Values           Re= ference

   =     ________________________________________________________= _________

  &nbs= p;    Via        &nb= sp;           oc-algo&nbs= p;             =             &nb= sp;            =     Yes        =              &n= bsp;            = ;         RFCABCD RFCOPRQ=

RFCABCD RFCOPRQ [NOTE TO RFC-E= DITOR: Please replace with final RFC number of draft-ietf-soc-overload-rate= -control & draft-ietf-soc-overload-control]

 

Update Section 5, “Syntax”:

This specification extends the existing definition of the = Via header field parameters of [RFC3261] as follows:

<= p class=3DMsoNormal>algo-list /=3D “rate“

 

And no additional changes related to the above will be requ= ired in draft-ietf-soc-overload-control.

 

Tha= nks,

 

Eric Noel

AT&T Labs, Inc.=
Rethink Possible

 

Optim= ization, Reliability and Customer Analytics

200 South Laurel Avenue, D5-3D19
Middletown, NJ 07748=
P: 732.420.4174

ecnoel@att.com

 

=

From: Christer Holmberg [mailto:christer.holmbe= rg@ericsson.com]
Sent: Saturday, July 20, 2013 7:11 AM
To:= NOEL, ERIC C (ERIC C); 'DRAGE, Keith (Keith)'; 'Yu, James'
Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all@= tools.ietf.org; sip-overload@ietf.org
Subject: VS: [sip-overload]= draft-ietf-soc-overload-rate-control-04.txt

 

Hi,

 

I support Keith’s suggestion. There is no need= to copy/paste syntax from another specification – we should simply d= efine the syntax additions/extensions.

 

Regards,

 =

Christer

 

L= =E4hett=E4j=E4: sip-overload-bounces@ietf.org [mailto:sip-over= load-bounces@ietf.org] Puolesta NOEL, ERIC C (ERIC C)
L=E4hete= tty: 11. hein=E4kuuta 2013 21:33
Vastaanottaja: 'DRAGE, Keith= (Keith)'; 'Yu, James'
Kopio: sip-overload-bounces@ietf.org; draf= t-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org<= br>Aihe: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt

 

Keith,

=  

Thank you for your comment.

 

IANA impacts:

- Based on Keith sugges= tion, for the IANA impacts we only need to have the IANA consideration sect= ion in draft-ietf-soc-overload-control to include the future RFC number for= draft-ietf-soc-overload-rate-control in the reference column

- While James is= suggesting explicitly defining the new parameter value in the IANA conside= ration section of draft-ietf-soc-overload-rate-control

=3D> Because Keith p= roposal is aligned with RFC 3968 guidelines, I propose adopting his proposa= l.

 

ABNF impacts:

- Based on Keith suggestion, draft-ietf-soc-overload-rate-c= ontrol syntax section should be reduced to

algo-list /=3D “rate“ <= /span>

- W= hile James is suggesting that section to include

oc =3D “oc” [EQUA= L oc-num]

= oc-num =3D 1*DIGIT

oc-algo =3D "oc-algo" EQUAL DQUOTE algo-li= st *(COMMA algo-list) DQUOTE

algo-list =3D “loss” / “rate= 220; / *(other-algo)

other-algo =3D %x41-5A / %x61-7A / %x30-39

=3D> Per Kei= th suggestion, to prevent potential conflicts, I propose adopting his propo= sal.

 

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>James would you agree with the proposed resolution?

 

Thanks,<= span lang=3DFI>

 

Er= ic Noel

AT&T Labs, Inc.
Rethink Possible

 =

Network Design and Performance Analysis
2= 00 South Laurel Avenue, D5-3D19
Middletown, NJ 07748
P: 732.420.4174<= /span>

ecnoel@att.com

 

From:<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> DRAGE, K= eith (Keith) [mailto:keit= h.drage@alcatel-lucent.com]
Sent: Wednesday, July 10, 2013 6= :05 PM
To: NOEL, ERIC C (ERIC C); 'Yu, James'
Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject:= RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt

 

I= 217;ve lost track of what is happening here. What I expect is two things:

 

1)         IANA re= gistration impact.

 

=

For the header field parameters registr= y, draft-ietf-soc-overload-control already creates the new rows:

 = ;

    &nb=
sp;  Header Field  Parameter Name  Predefined Values  R=
eference
       ___=
_______________________________________________________<=
/pre>
       Via    &nbs=
p;      oc      &nbs=
p;          Yes  &nb=
sp;          RFCXXXX
       Via   =
        oc-validity   &nb=
sp;    Yes        &n=
bsp;    RFCXXXX
   =
    Via         &nbs=
p; oc-seq          &=
nbsp;  Yes          =
   RFCXXXX
    &nb=
sp;  Via           o=
c-algo            Ye=
s             R=
FCXXXX
 
 &nb=
sp;     RFC XXXX [NOTE TO RFC-EDITOR: Please replace wi=
th final RFC
      =
 number of this specification.]
 
For the predefined values columns, RFC 3968 st=
ates:
 
  =
; Some SIP header field parameters only accept a set of predefined
   parameter values.  For example, a param=
eter indicating the transport
   protoc=
ol in use may only accept the predefined tokens TCP, UDP, and
   SCTP as valid values.  Registering all param=
eter values for all SIP
   header field=
 parameters of this type would require a large number of
   subregistries.  Instead, we have chosen to regi=
ster parameter values
   by reference.&=
nbsp; That is, the entry in the parameter registry for a
   given header field parameter contains references to =
the RFCs defining
   new values of the =
parameter.  References to RFCs defining parameter
   values appear in double brackets in the registry.=
<=
/o:p>
 
   So, the h=
eader field parameter registry contains a column that
   indicates whether or not each parameter only accepts a se=
t of
   predefined values.  Implem=
enters of parameters with a "yes" in that
   provided as references.
 
With this=
 understanding, I do not believe the rate-control draft needs to modify the=
 “predefined values” column. What it does need to do is add its=
 ultimate RFC number to the reference column.
 
There cou=
ld be an argument that there needs to be a new table that lists the algorit=
hm values, but 
 
a)   &nb=
sp;            =
  if such a table is to =
be created, it needs to be created by draft-ietf-soc-overload-control rathe=
r than the rate-control draft/
=

b)   =
            &nb=
sp;  I personally do not=
 think it is necessary to add such a new table, as I think the references a=
re sufficient. One cannot handle the algorithm values unless one goes to th=
e relevant RFC.
 
2)      &nbs=
p;  ABNF impact.
 =

ABNF defines the /=3D operator for =
adding new values to an existing defined list.<=
/o:p>
 
I do not =
think we should reproduce existing ABNF from draft-ietf-soc-overload-contro=
l and then amend it. 
 =

The reason for this is that tools e=
xist for automatically extracting the ABNF from RFCs. An extracted <=
span lang=3DFI>
&n=
bsp;
algo-list /=3D “rate“ 
 
will work perfectly w=
ell with the extract from draft-ietf-soc-overload-control (and from SIP). R=
eproducing productions will result in conflict.=

 
Regards
 
Keith
 =

Fro=
m: sip-overload-bounces=
@ietf.org [mailto:sip-=
overload-bounces@ietf.org] On Behalf Of NOEL, ERIC C (ERIC C)Sent: 10 July 2013 20:54
To: 'Yu, James'
Cc: sip-overload-bounces@ietf.or=
g; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject:<=
/b> Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt
 
James,
 
So section 5 (syntax) will include the following state=
ments:
 
oc =3D “oc” [EQUAL oc-num]<=
/o:p>
oc-num =3D 1*DIGIT
oc-algo =3D &qu=
ot;oc-algo" EQUAL DQUOTE algo-list *(COMMA algo-list) DQUOTE
algo-list =
=3D “loss” / “rate“ / *(other-algo)
other-algo =3D %x4=
1-5A / %x61-7A / %x30-39
 
Thanks,<=
/p>
 
Eric Noel 
AT&T Labs=
, Inc. 
Rethink Possible
 
Netw=
ork Design and Performance Analysis
200 South Laurel Avenue, D5-3D19
=
Middletown, NJ 07748
P: 732.420.4174
ecnoel@att.c=
om
 
From: Yu, James [mailto:james.yu@neustar.biz] 
Sent: Wednesday, July 1=
0, 2013 3:10 PM
To: NOEL, ERIC C (ERIC C)
Cc: sip-overload-bounces@ietf.org=
; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: R=
E: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt
 
Eric,
You may want to copy the “oc-algo” line fro=
m other I-D.
 
James
 
From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] 
Sent:=
 Wednesday, July 10, 2013 1:10 PM
To: Yu, James
Cc: sip-overload-bounces@ietf.org=
; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject:<=
/b> RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt

 =

James,

&nbs= p;

= Based on your suggestion and comments from other reviewers, I intend to upd= ate section 5 (syntax) as follows:=

 

oc =3D “oc” [EQUAL oc-num]<= /span>

oc-= num =3D 1*DIGIT

 

algo-list =3D “loss” / “rate“ / *(= other-algo)

other-algo =3D %x41-5A / %x61-7A / %x30-39<= o:p>

 

I understand there may= be an additional change following Henning’s reply.

 

Thanks,<= span lang=3DFI>

 

Er= ic Noel

AT&T Labs, Inc.
Rethink Possible

 =

Network Design and Performance Analysis
2= 00 South Laurel Avenue, D5-3D19
Middletown, NJ 07748
P: 732.420.4174<= /span>

ecnoel@att.com

 

From:<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Yu, Jame= s [mailto:james.yu@neustar.biz]=
Sent: Wednesday, July 10, 2013 11:36 AM
To: NOEL, ERI= C C (ERIC C)
Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.al= l@tools.ietf.org; sip-overload= @ietf.org
Subject: RE: [sip-overload] draft-ietf-soc-overload= -rate-control-04.txt

 

Eric,

 

<= p class=3DMsoNormal>Yes, this adds “rate” to “oc-a= lgo” parameter but please check with IANA to see if it is the correct= way.  You also need to copy some syntax lines from the draft-ietf-soc= -overload-control to show

 

=

     algo-list &n= bsp; =3D “loss“ / = “rate“ / *(other-algo)

 

I’= ve an email to Henning asking if algo-list in his I-D should be

   &= nbsp; algo-list   =3D “loss“ / other-algo

 <= /span>

If yes, then this particular line in = your I-D would be

     algo-list   = =3D “loss“ / “rate“ / other-algo

 

James

 

= From:= NOEL, ERIC C (ERIC C) [mailt= o:ecnoel@research.att.com]
Sent: Wednesday, July 10, 2013 10= :49 AM
To: Yu, James
Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overlo= ad-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload] draft= -ietf-soc-overload-rate-control-04.txt

 <= /span>

James,

 

Thank you for your suggestion= .

=  

Not being familiar with IANA procedure, would updating draft-ietf-soc-o= verload-rate-control section 7 (IANA considerations) as follows work?

 

This= specification defines a new value for Via header parameter oc-algo as deta= iled below in the "Header Field Parameter and Parameter Values" s= ubregistry as per the registry created by [RFC3968]. The required informati= on is:

 

Header Field          =  Parameter Name          =             &nb= sp; Predefined Values         =            Reference=

--= ---------------------------------------------------------------------------= -----------------------------

<= p class=3DMsoNormal>Via        &n= bsp;            = ;         oc-algo   =             &nb= sp;            =             &nb= sp;     “rate”    =             &nb= sp;            =              &n= bsp;  RFCXXXX

 

RFC XXXX [NOTE TO RFC-EDITOR: Please replace with = final RFC number of this specification.]<= /span>

 

Thanks,

 

Eric Noel

AT&T Labs, Inc.
Rethink Possibl= e

<= span style=3D'font-size:9.0pt;font-family:"Verdana","sans-serif";color:#00B= 0E0'> 

Network Design and Performance Analysis
200 South Laurel Ave= nue, D5-3D19
Middletown, NJ 07748
P: 732.420.4174

ecnoel@att.com

<= /div>

 

From: Yu, James [mailto:james.yu@neustar.biz]
Sent: W= ednesday, July 10, 2013 10:17 AM
To: NOEL, ERIC C (ERIC C)
= Cc: sip-overload-bounc= es@ietf.org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.tx= t

 

Noel,

 

I forgot to respond to your reply about the IANA registration of &#= 8220;rate” in oc-algo.  I see that draft-ietf-soc-overload-contr= ol-13 mentions your I-D but does not have “rate” in algo-list.<= /span>

&nb= sp;

There are two possible ways to address “rate” in algo-list.&nb= sp; One is to have draft-ietf-soc-overload-control-13 add “rate”= ; to algo-list and refer to your I-D for details.  The other is to reg= ister “rate” in algo-list with IANA in your I-D, and this shoul= d be a simple task.  The cleaner way that is more inline with the IETF= process would be the latter.  It seems odd to have something defined = in a RFC without details about it, and it would be too much trouble to comb= ine the two I-Ds.

 

James

 

<= div>

From: Yu, James
Sent: Wednesday,= July 10, 2013 9:01 AM
To: 'NOEL, ERIC C (ERIC C)'
Cc: = sip-overload-bounces@ietf.= org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject= : RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt=

&nbs= p;

Noel,

&nbs= p;

= I mentioned in my message to Janet on 7/2:

 <= /o:p>

For th= e rate control, the server could calculate the arrival rate from each commu= nicating client so that it could allocate the overall target SIP request ra= te to the clients based on their arrival rates known to the server.  B= ut another option is for the client to “optionally” include its= calculated arrival rate in its request to the server when rate control rel= ated parameters are present.  Should this option be evaluated/included= to relieve the server from doing the arrival rate calculations.  This= would be beneficial to a server when it receives the requests from many cl= ients.

 

I suggest that the I-D adds that option to allow the client to indi= cate its current arrival rate (towards the receiving server) in the SIP req= uest.

 

= James

 

=

From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com]
Sent: Tuesda= y, July 09, 2013 4:44 PM
To: Yu, James; Janet P Gunn
Cc: sip-overload-bounces@iet= f.org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subje= ct: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt

&n= bsp;

Jane= t, James,

=  

Thanks you for your valuable comments and discussion.  I tr= ied to capture all resolution in the following text (based on James word do= cument with track changes and imbedded comments enabled).

 

+ Abstract sect= ion:

- Agreed with suggested changes=

- Please note I will also need to make furt= her changes to remove all references per Christer Holmberg comment

 

+ Secti= on 1:

- Agreed with suggested changes=

 

+ Section 3.1:

- Agreed with suggested cha= nges

 

= + Section 3.2: - Please note the section title will become “Vi= a header field parameters for overload control “ per Christer Holmber= g comment

= - Agreed with suggested changes excluding title that will change per= previous bullet

 

+ Section 3.3:=

- Agreed with suggested changes

 <= span lang=3DFI>

+ Section = 3.4:

- ID:  "Note that the target SIP request rate is a max rate tha= t may not be attained by the arrival rate at the client, and the server can= not assume that it will."

   [JY] Not clear what value th= is paragraph tries to add.  Is it saying that the client's arrival rat= e may be lower than the target SIP request rate?

   [JG] Yes += supporting example (see below in thread)=

  Agreed with Janet and su= pporting example. Per James request, I will add the following text (inspire= d from Janet’s illustrative example):

   “In other words= , when multiple clients are being controlled by an overloaded server, at an= y given time some clients may receive requests at a rate below its target S= IP request rate while others above that target rate. But the resulting requ= est rate presented to the overloaded server will converge towards the targe= t SIP request rate.”

- Agreed with other suggested changes

  &nb= sp;  

+ Section 3.5.1:

<= p class=3DMsoNormal>- ID: “And the larger the difference betwe= en TAU1 and TAU2, the closer to the control is to strict priority.”

&nbs= p; [JY] Suggest changing into “And the larger the difference between = TAU1 and TAU2, the closer the control is to strict priority queuing.”=

&n= bsp; [JG] Suggest changing into “And the larger the difference betwee= n TAU1 and TAU2, the closer the control is to strict priority treatment.= 221;

  [EN] Agreed with Janet’s suggestion

- Agreed with other suggest= ed changes

 

+ Section 4:

- Agreed with suggested changes

 

+ Section 5:=

- Please = note that based comments from per Christer Holmberg and Janet Gunn, the fol= lowing was tentatively agreed

=

   Replace oc-value =3D "Na= N" / oc-num    by    oc =3D "oc&quo= t; [EQUAL oc-num]

- Agreed with other suggested change<= o:p>

 

+ Section 7:

- [JY] Shoul= d “rate” in oc-algo be registered with IANA?

  This issue n= eeds to be addressed by draft-ietf-soc-overload-control authors

 <= span lang=3DFI>

Please not= e I will wait until expiration of WGLC prior updating our draft RFC. Once a= gain your comments and/or suggestions are most appreciated.

 

Thanks,=

 

E= ric Noel

AT&T Labs, Inc.
Rethink Possible

 =

Network Design and Performance Analysis
2= 00 South Laurel Avenue, D5-3D19
Middletown, NJ 07748
P: 732.420.4174<= /span>

ecnoel@att.com

 

From:<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> sip-overload-bounces@ietf.org= [mailto:sip-overload-boun= ces@ietf.org] On Behalf Of Yu, James
Sent: Tuesday, Ju= ly 02, 2013 9:42 AM
To: Janet P Gunn
Cc: sip-overload-bounces@ietf.org; draft= -ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: Re: [sip= -overload] draft-ietf-soc-overload-rate-control-04.txt

 

Janet,

 

For my comm= ent on section 3.4 (the first one below), the current text does not provide= any value.  The client’s arrival rate could be well below the t= arget SIP request rate when its load is light so the fact that the client m= ay not achieve the target SIP request rate (the max. rate it is allowed to = send to the server) is well understood.  But with your explanation on = the “delta” part, the text then makes sense.  Please add s= ome discussions on the “delta” aspect so that even if the avera= ge arrival rate at the client is higher than the target SIP request rate th= e client at times may not send more than what the target SIP request rate a= llows due to the fluctuation of the arriving requests at the client.=

 

For = the comment on section 3.5.1, I agree with your proposed change.

 =

For the r= ate control, the server could calculate the arrival rate from each communic= ating client so that it could allocate the overall target SIP request rate = to the clients based on their arrival rates known to the server.  But = another option is for the client to “optionally” include its ca= lculated arrival rate in its request to the server when rate control relate= d parameters are present.  Should this option be evaluated/included to= relieve the server from doing the arrival rate calculations.  This wo= uld be beneficial to a server when it receives the requests from many clien= ts.

 

James

 

From: Janet P Gunn [mailto:jg= unn6@csc.com]
Sent: Friday, June 28, 2013 3:34 PM
To:<= /b> Yu, James
Cc: draft-ietf-soc-overload-rate-control.all@tools.= ietf.org; sip-overload@ietf.or= g; sip-overload-bounce= s@ietf.org
Subject: Re: [sip-overload] draft-ietf-soc-overloa= d-rate-control-04.txt

 

J= ames,

It is a little hard to respond in email when your comments are = in a separate document, but here goes.


section 3.4
ID says:
&= quot;Note that the target SIP request rate is a max rate that may not be
=    attained by the arrival rate at the client, and the server can= not
   assume that it will."

Your comment : <= br>"= Not clear what value this paragraph tries to add.  Is it saying that t= he client's arrival rate may be lower than the target SIP request rate? &nb= sp;"

Yes.

Suppose the server want to limit the total rate = of arriving SIP messages to 100 / sec, and has 10 clients.  Each clien= t has a high variance in its message rate, but together they are well above= 100 messages per sec

If it sets the rate at 10 messages per second f= or each of the clients, it will almost certainly end up  with an overa= ll average of less than 100 messages per sec, because some clients will be = in a "lull" while others are busy.  This is good from a thro= ttling perspective, but, assuming messages are correlated with revenue, bad= /wasteful from a revenue, or overall productivity perspective.  So the= server might want to set the rate per client to 10 + delta, where delta is= going to be very specific to operating environment.

---
<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>In section=  3.5.1, bottom of page 8
ID says:
"And the larger   &= nbsp;the difference between TAU1 and TAU2, the closer to the control is
&= nbsp;  to strict priority."

You propose changing it to:
&= quot;And the larger
   the difference between TAU1 and TAU2, th= e closer  the control is
   to strict priority queuing.&qu= ot;

I agree with taking out the redundant "to".  But I= disagree wit adding "queuing".  There is no queuing, priori= ty or otherwise involved.

You could say:
"And the larger
&nb= sp;  the difference between TAU1 and TAU2, the closer  the contro= l is
   to strict priority treatment."

where " = strict priority treatment" would refer to the case where non-priority = messages are restricted to a total (priority + non-priority) rate of 10 mes= sages per second, but priority messages can continue to be sent as long as = the total (priority + non-priority) rate is less than 12 messages per secon= d.

At least, I think that is what Eric and  Philip are trying to= say.

Janet


 


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


<= br>From:        "Yu, James" <james.yu@neustar.biz>
To:=        "sip-overload-bounces@ietf.org" <sip-overload-bounces@ietf.org>, "draft-i= etf-soc-overload-rate-control.all@tools.ietf.org" <draft-ietf-s= oc-overload-rate-control.all@tools.ietf.org>, "sip-overload@ietf.org" <sip-overload@ietf.org>
Dat= e:        06/28/2013 08:10 AM
Subject: &nbs= p;      [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt
Sent by:        sip-overload-bounces@ietf.org




Salvatore,
 
Please see the attachment for my comme= nts.
 
I pasted the text to a word document to trace/show the = proposed changes and comments.
 
Regards,
  James=
 [attachment "comments on draft-ietf-soc-overload-rate-contr= ol-04.docx" deleted by Janet P Gunn/USA/CSC] _______________________________________________
sip-o= verload mailing list
s= ip-overload@ietf.org
https://ww= w.ietf.org/mailman/listinfo/sip-overload

No virus found in this message.
Checked by AVG - = www.avg.com
Version: 2013.0.2904 / Vi= rus Database: 3204/6452 - Release Date: 06/30/13=

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Dat= abase: 3204/6478 - Release Date: 07/09/13=

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 3= 204/6478 - Release Date: 07/09/13

= No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 3204/6478= - Release Date: 07/09/13

= = --_000_5EBD159DE88147488A3B1590E09001840353C06875E4njfpsrvexg2_-- From christer.holmberg@ericsson.com Mon Jul 22 06:57:23 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 45B3311E80F5; Mon, 22 Jul 2013 06:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.637 X-Spam-Level: X-Spam-Status: No, score=-5.637 tagged_above=-999 required=5 tests=[AWL=0.611, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fA1s2Q6pF2oM; Mon, 22 Jul 2013 06:57:10 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6775811E8101; Mon, 22 Jul 2013 06:57:08 -0700 (PDT) X-AuditID: c1b4fb2d-b7f0b6d0000002d5-0f-51ed3a3214f4 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id C2.41.00725.23A3DE15; Mon, 22 Jul 2013 15:57:06 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0328.009; Mon, 22 Jul 2013 15:57:06 +0200 From: Christer Holmberg To: "NOEL, ERIC C (ERIC C)" , "'DRAGE, Keith (Keith)'" , "'Yu, James'" Thread-Topic: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Thread-Index: Ac5zhcqru7dYQFxqQKSGvvGKSQFJEAAn/KwAALza+IABbsiJAAAiGiWAAAKrhAAAARl8gAABpBAAAANOPYAABCzcAAABjR6AAASO6QAAKuPFAAG5ULpgAGmY52AAANWQoA== Date: Mon, 22 Jul 2013 13:57:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3F6D87@ESESSMB209.ericsson.se> References: <56FB15AFE08E1242B0736CBDCE6E85610808C32F@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610808EF90@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353BDA4CAD4@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E85610809239D@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610809253D@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353C0687578@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E856108092986@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353C068757C@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E856108092BD9@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353C0687581@njfpsrvexg2.research.att.com> <949EF20990823C4C85C18D59AA11AD8B06820F@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5EBD159DE88147488A3B1590E09001840353C068758D@njfpsrvexg2.research.att.com> <7594FB04B1934943A5C02806D1A2204B1C3DA597@ESESSMB209.ericsson.se> <5EBD159DE88147488A3B1590E09001840353C06875E4@njfpsrvexg2.research.att.com> In-Reply-To: <5EBD159DE88147488A3B1590E09001840353C06875E4@njfpsrvexg2.research.att.com> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C3F6D87ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZGfG3VtfI6m2gwfNJZhYXdhxjtTj5fx+L xaJpIRZPG88yWrRf3Mpqsf9pggObR+uzvaweS5b8ZPLY0fCc2eP/k/ksHl8uf2YLYI3isklJ zcksSy3St0vgyni1+AxrwYZdHBU7TvSxNzBOuMTexcjJISFgIjHjxTlWCFtM4sK99WxdjFwc QgKHGSX6//9mhnCWMEo8/fYDqIqDg03AQqL7nzZIXERgFqPE1O69YB3MAu8ZJW6tmMEIMkpY wF3i/aT3TCC2iICHxJ5Tj1ghOiYxSizfNRlsH4uAqsSPozvBGngFfCV+/G6DWveCQ2Jz/y42 kASnQITE2btvwWxGoAO/n1oDNpVZQFziw8HrzBCHC0gs2XMeyhaVePn4H9RDShKNS56wQtTn S3x8fY0NYpmgxMmZT1gmMIrOQjJqFpKyWUjKIOJ6EjemTmGDsLUlli18DVWvKzHj3yEWZPEF jOyrGNlzEzNz0ssNNzECI/Tglt+6OxhPnRM5xCjNwaIkzrtJ70ygkEB6YklqdmpqQWpRfFFp TmrxIUYmDk6pBkYju1A+3fkrCreo/O9l+D67JPq9e+uXrJ8P+cIt39wuXBMU9XOJ0UdZoSXn zSr6y/43tM/ac3zPJ6XrfDK1suv8nXxNM1onnMrWebLRLot71YX5u7piP068MXG92RfPK05z 7dOvM7dMjqt6l8FmozD3e9nS7a9zgzMq7NW+6t7kmp6ZsPncYS8lluKMREMt5qLiRABjNFPU ngIAAA== Cc: "sip-overload-bounces@ietf.org" , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" , "sip-overload@ietf.org" Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.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, 22 Jul 2013 13:57:23 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C3F6D87ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, The resolution looks fine to me. Regards, Christer L=E4hett=E4j=E4: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] L=E4hetetty: 22. hein=E4kuuta 2013 16:39 Vastaanottaja: Christer Holmberg; 'DRAGE, Keith (Keith)'; 'Yu, James' Kopio: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.= all@tools.ietf.org; sip-overload@ietf.org Aihe: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Christer, Thanks for the follow-up. We had off line email exchanges between Keith Drage and James Yu on this is= sue (I just realize I forgot to post the resolution). The following was agreed: Update Section 7, "IANA Considerations": Header Field Parameter Name Predefined Values = Reference _________________________________________________________________ Via oc-algo = Yes RFCABCD RFCOPRQ RFCABCD RFCOPRQ [NOTE TO RFC-EDITOR: Please replace with final RFC number o= f draft-ietf-soc-overload-rate-control & draft-ietf-soc-overload-control] Update Section 5, "Syntax": This specification extends the existing definition of the Via header field = parameters of [RFC3261] as follows: algo-list /=3D "rate" And no additional changes related to the above will be required in draft-ie= tf-soc-overload-control. Thanks, Eric Noel AT&T Labs, Inc. Rethink Possible Optimization, Reliability and Customer Analytics 200 South Laurel Avenue, D5-3D19 Middletown, NJ 07748 P: 732.420.4174 ecnoel@att.com From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Saturday, July 20, 2013 7:11 AM To: NOEL, ERIC C (ERIC C); 'DRAGE, Keith (Keith)'; 'Yu, James' Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: VS: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Hi, I support Keith's suggestion. There is no need to copy/paste syntax from an= other specification - we should simply define the syntax additions/extensio= ns. Regards, Christer L=E4hett=E4j=E4: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] Puolesta NOEL, ERIC C (ERI= C C) L=E4hetetty: 11. hein=E4kuuta 2013 21:33 Vastaanottaja: 'DRAGE, Keith (Keith)'; 'Yu, James' Kopio: sip-overload-bounces@ietf.org;= draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Aihe: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Keith, Thank you for your comment. IANA impacts: - Based on Keith suggestion, for the IANA impacts we only need to have the = IANA consideration section in draft-ietf-soc-overload-control to include th= e future RFC number for draft-ietf-soc-overload-rate-control in the referen= ce column - While James is suggesting explicitly defining the new parameter value in = the IANA consideration section of draft-ietf-soc-overload-rate-control =3D> Because Keith proposal is aligned with RFC 3968 guidelines, I propose = adopting his proposal. ABNF impacts: - Based on Keith suggestion, draft-ietf-soc-overload-rate-control syntax se= ction should be reduced to algo-list /=3D "rate" - While James is suggesting that section to include oc =3D "oc" [EQUAL oc-num] oc-num =3D 1*DIGIT oc-algo =3D "oc-algo" EQUAL DQUOTE algo-list *(COMMA algo-list) DQUOTE algo-list =3D "loss" / "rate" / *(other-algo) other-algo =3D %x41-5A / %x61-7A / %x30-39 =3D> Per Keith suggestion, to prevent potential conflicts, I propose adopti= ng his proposal. James would you agree with the proposed resolution? 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: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] Sent: Wednesday, July 10, 2013 6:05 PM To: NOEL, ERIC C (ERIC C); 'Yu, James' Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt I've lost track of what is happening here. What I expect is two things: 1) IANA registration impact. For the header field parameters registry, draft-ietf-soc-overload-control a= lready creates the new rows: Header Field Parameter Name Predefined Values Reference __________________________________________________________ Via oc Yes RFCXXXX Via oc-validity Yes RFCXXXX Via oc-seq Yes RFCXXXX Via oc-algo Yes RFCXXXX RFC XXXX [NOTE TO RFC-EDITOR: Please replace with final RFC number of this specification.] For the predefined values columns, RFC 3968 states: Some SIP header field parameters only accept a set of predefined parameter values. For example, a parameter indicating the transport protocol in use may only accept the predefined tokens TCP, UDP, and SCTP as valid values. Registering all parameter values for all SIP header field parameters of this type would require a large number of subregistries. Instead, we have chosen to register parameter values by reference. That is, the entry in the parameter registry for a given header field parameter contains references to the RFCs defining new values of the parameter. References to RFCs defining parameter values appear in double brackets in the registry. So, the header field parameter registry contains a column that indicates whether or not each parameter only accepts a set of predefined values. Implementers of parameters with a "yes" in that column need to find all the valid parameter values in the RFCs provided as references. With this understanding, I do not believe the rate-control draft needs to m= odify the "predefined values" column. What it does need to do is add its ul= timate RFC number to the reference column. There could be an argument that there needs to be a new table that lists th= e algorithm values, but a) if such a table is to be created, it needs to be create= d by draft-ietf-soc-overload-control rather than the rate-control draft/ b) I personally do not think it is necessary to add such a= new table, as I think the references are sufficient. One cannot handle the= algorithm values unless one goes to the relevant RFC. 2) ABNF impact. ABNF defines the /=3D operator for adding new values to an existing defined= list. I do not think we should reproduce existing ABNF from draft-ietf-soc-overlo= ad-control and then amend it. The reason for this is that tools exist for automatically extracting the AB= NF from RFCs. An extracted algo-list /=3D "rate" will work perfectly well with the extract from draft-ietf-soc-overload-cont= rol (and from SIP). Reproducing productions will result in conflict. Regards Keith ________________________________ From: sip-overload-bounces@ietf.org [= mailto:sip-overload-bounces@ietf.org] On Behalf Of NOEL, ERIC C (ERIC C) Sent: 10 July 2013 20:54 To: 'Yu, James' Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, So section 5 (syntax) will include the following statements: oc =3D "oc" [EQUAL oc-num] oc-num =3D 1*DIGIT oc-algo =3D "oc-algo" EQUAL DQUOTE algo-list *(COMMA algo-list) DQUOTE algo-list =3D "loss" / "rate" / *(other-algo) other-algo =3D %x41-5A / %x61-7A / %x30-39 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: Yu, James [mailto:james.yu@neustar.biz] Sent: Wednesday, July 10, 2013 3:10 PM To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Eric, You may want to copy the "oc-algo" line from other I-D. James From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] Sent: Wednesday, July 10, 2013 1:10 PM To: Yu, James Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, Based on your suggestion and comments from other reviewers, I intend to upd= ate section 5 (syntax) as follows: oc =3D "oc" [EQUAL oc-num] oc-num =3D 1*DIGIT algo-list =3D "loss" / "rate" / *(other-algo) other-algo =3D %x41-5A / %x61-7A / %x30-39 I understand there may be an additional change following Henning's reply. 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: Yu, James [mailto:james.yu@neustar.biz] Sent: Wednesday, July 10, 2013 11:36 AM To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Eric, Yes, this adds "rate" to "oc-algo" parameter but please check with IANA to = see if it is the correct way. You also need to copy some syntax lines from= the draft-ietf-soc-overload-control to show algo-list =3D "loss" / "rate" / *(other-algo) I've an email to Henning asking if algo-list in his I-D should be algo-list =3D "loss" / other-algo If yes, then this particular line in your I-D would be algo-list =3D "loss" / "rate" / other-algo James From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] Sent: Wednesday, July 10, 2013 10:49 AM To: Yu, James Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, Thank you for your suggestion. Not being familiar with IANA procedure, would updating draft-ietf-soc-overl= oad-rate-control section 7 (IANA considerations) as follows work? This specification defines a new value for Via header parameter oc-algo as = detailed below in the "Header Field Parameter and Parameter Values" subregi= stry as per the registry created by [RFC3968]. The required information is: Header Field Parameter Name Predefined Val= ues Reference ---------------------------------------------------------------------------= ------------------------------- Via oc-algo = "rate" RFCXXXX RFC XXXX [NOTE TO RFC-EDITOR: Please replace with final RFC number of this = specification.] 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: Yu, James [mailto:james.yu@neustar.biz] Sent: Wednesday, July 10, 2013 10:17 AM To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Noel, I forgot to respond to your reply about the IANA registration of "rate" in = oc-algo. I see that draft-ietf-soc-overload-control-13 mentions your I-D b= ut does not have "rate" in algo-list. There are two possible ways to address "rate" in algo-list. One is to have= draft-ietf-soc-overload-control-13 add "rate" to algo-list and refer to yo= ur I-D for details. The other is to register "rate" in algo-list with IANA= in your I-D, and this should be a simple task. The cleaner way that is mo= re inline with the IETF process would be the latter. It seems odd to have = something defined in a RFC without details about it, and it would be too mu= ch trouble to combine the two I-Ds. James From: Yu, James Sent: Wednesday, July 10, 2013 9:01 AM To: 'NOEL, ERIC C (ERIC C)' Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Noel, I mentioned in my message to Janet on 7/2: For the rate control, the server could calculate the arrival rate from each= communicating client so that it could allocate the overall target SIP requ= est rate to the clients based on their arrival rates known to the server. = But another option is for the client to "optionally" include its calculated= arrival rate in its request to the server when rate control related parame= ters are present. Should this option be evaluated/included to relieve the = server from doing the arrival rate calculations. This would be beneficial = to a server when it receives the requests from many clients. I suggest that the I-D adds that option to allow the client to indicate its= current arrival rate (towards the receiving server) in the SIP request. James From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] Sent: Tuesday, July 09, 2013 4:44 PM To: Yu, James; Janet P Gunn Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Janet, James, Thanks you for your valuable comments and discussion. I tried to capture a= ll resolution in the following text (based on James word document with trac= k changes and imbedded comments enabled). + Abstract section: - Agreed with suggested changes - Please note I will also need to make further changes to remove all refere= nces per Christer Holmberg comment + Section 1: - Agreed with suggested changes + Section 3.1: - Agreed with suggested changes + Section 3.2: - Please note the section title will become "Via header fiel= d parameters for overload control " per Christer Holmberg comment - Agreed with suggested changes excluding title that will change per previo= us bullet + Section 3.3: - Agreed with suggested changes + Section 3.4: - ID: "Note that the target SIP request rate is a max rate that may not be= attained by the arrival rate at the client, and the server cannot assume t= hat it will." [JY] Not clear what value this paragraph tries to add. Is it saying tha= t the client's arrival rate may be lower than the target SIP request rate? [JG] Yes + supporting example (see below in thread) Agreed with Janet and supporting example. Per James request, I will add t= he following text (inspired from Janet's illustrative example): "In other words, when multiple clients are being controlled by an overlo= aded server, at any given time some clients may receive requests at a rate = below its target SIP request rate while others above that target rate. But = the resulting request rate presented to the overloaded server will converge= towards the target SIP request rate." - Agreed with other suggested changes + Section 3.5.1: - ID: "And the larger the difference between TAU1 and TAU2, the closer to t= he control is to strict priority." [JY] Suggest changing into "And the larger the difference between TAU1 an= d TAU2, the closer the control is to strict priority queuing." [JG] Suggest changing into "And the larger the difference between TAU1 an= d TAU2, the closer the control is to strict priority treatment." [EN] Agreed with Janet's suggestion - Agreed with other suggested changes + Section 4: - Agreed with suggested changes + Section 5: - Please note that based comments from per Christer Holmberg and Janet Gunn= , the following was tentatively agreed Replace oc-value =3D "NaN" / oc-num by oc =3D "oc" [EQUAL oc-num] - Agreed with other suggested change + Section 7: - [JY] Should "rate" in oc-algo be registered with IANA? This issue needs to be addressed by draft-ietf-soc-overload-control autho= rs Please note I will wait until expiration of WGLC prior updating our draft R= FC. Once again your comments and/or suggestions are most appreciated. 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 Yu, James Sent: Tuesday, July 02, 2013 9:42 AM To: Janet P Gunn Cc: sip-overload-bounces@ietf.org; dr= aft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Janet, For my comment on section 3.4 (the first one below), the current text does = not provide any value. The client's arrival rate could be well below the t= arget SIP request rate when its load is light so the fact that the client m= ay not achieve the target SIP request rate (the max. rate it is allowed to = send to the server) is well understood. But with your explanation on the "= delta" part, the text then makes sense. Please add some discussions on the= "delta" aspect so that even if the average arrival rate at the client is h= igher than the target SIP request rate the client at times may not send mor= e than what the target SIP request rate allows due to the fluctuation of th= e arriving requests at the client. For the comment on section 3.5.1, I agree with your proposed change. For the rate control, the server could calculate the arrival rate from each= communicating client so that it could allocate the overall target SIP requ= est rate to the clients based on their arrival rates known to the server. = But another option is for the client to "optionally" include its calculated= arrival rate in its request to the server when rate control related parame= ters are present. Should this option be evaluated/included to relieve the = server from doing the arrival rate calculations. This would be beneficial = to a server when it receives the requests from many clients. James From: Janet P Gunn [mailto:jgunn6@csc.com] Sent: Friday, June 28, 2013 3:34 PM To: Yu, James Cc: draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org; sip-overload-bounces@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, It is a little hard to respond in email when your comments are in a separat= e document, but here goes. section 3.4 ID says: "Note that the target SIP request rate is a max rate that may not be attained by the arrival rate at the client, and the server cannot assume that it will." Your comment : "Not clear what value this paragraph tries to add. Is it saying that the c= lient's arrival rate may be lower than the target SIP request rate? " Yes. Suppose the server want to limit the total rate of arriving SIP messages to= 100 / sec, and has 10 clients. Each client has a high variance in its mes= sage rate, but together they are well above 100 messages per sec If it sets the rate at 10 messages per second for each of the clients, it w= ill almost certainly end up with an overall average of less than 100 messa= ges per sec, because some clients will be in a "lull" while others are busy= . This is good from a throttling perspective, but, assuming messages are c= orrelated with revenue, bad/wasteful from a revenue, or overall productivit= y perspective. So the server might want to set the rate per client to 10 += delta, where delta is going to be very specific to operating environment. --- In section 3.5.1, bottom of page 8 ID says: "And the larger the difference between TAU1 and TAU2, the closer to the control is to strict priority." You propose changing it to: "And the larger the difference between TAU1 and TAU2, the closer the control is to strict priority queuing." I agree with taking out the redundant "to". But I disagree wit adding "que= uing". There is no queuing, priority or otherwise involved. You could say: "And the larger the difference between TAU1 and TAU2, the closer the control is to strict priority treatment." where " strict priority treatment" would refer to the case where non-priori= ty messages are restricted to a total (priority + non-priority) rate of 10 = messages per second, but priority messages can continue to be sent as long = as the total (priority + non-priority) rate is less than 12 messages per se= cond. At least, I think that is what Eric and Philip are trying to say. 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: "Yu, James" = > To: "sip-overload-bounces@ietf.org" >= , "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" >, "sip-overload@ietf.org"= > Date: 06/28/2013 08:10 AM Subject: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Sent by: sip-overload-bounces@ietf.org ________________________________ Salvatore, Please see the attachment for my comments. I pasted the text to a word document to trace/show the proposed changes and= comments. Regards, James [attachment "comments on draft-ietf-soc-overload-rate-control-04.docx" del= eted by Janet P Gunn/USA/CSC] _____________________________________________= __ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6452 - Release Date: 06/30/13 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13 --_000_7594FB04B1934943A5C02806D1A2204B1C3F6D87ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

The resolu= tion looks fine to me.

 = ;

Regards,

 = ;

Christer

 = ;

L=E4hett=E4j=E4: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com]
L=E4hetetty: 22. hein=E4kuuta 2013 16:39
Vastaanottaja: Christer Holmberg; 'DRAGE, Keith (Keith)'; 'Yu, James= '
Kopio: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-c= ontrol.all@tools.ietf.org; sip-overload@ietf.org
Aihe: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt=

 

Christer,<= o:p>

 = ;

Thanks for= the follow-up.

 = ;

We had off= line email exchanges between Keith Drage and James Yu on this issue (I jus= t realize I forgot to post the resolution).

 = ;

The follow= ing was agreed:

 = ;

Update Sec= tion 7, “IANA Considerations”:

 &nbs= p;     Header        = ;     Field  Parameter Name    = ;    Predefined  Values     &n= bsp;     Reference

 &nbs= p;     ________________________________________________= _________________

 &nbs= p;     Via       &nb= sp;            oc-al= go             =             &nb= sp;            =      Yes       =              &n= bsp;            = ;          RFCABCD RFCOPR= Q

RFCABCD RF= COPRQ [NOTE TO RFC-EDITOR: Please replace with final RFC number of draft-ie= tf-soc-overload-rate-control & draft-ietf-soc-overload-control]

 = ;

Update Sec= tion 5, “Syntax”:

This speci= fication extends the existing definition of the Via header field parameters= of [RFC3261] as follows:

algo-list = /=3D “rate“

 = ;

And no add= itional changes related to the above will be required in draft-ietf-soc-ove= rload-control.

 = ;

Thanks,

 = ;

Eric Noel

AT&T= Labs, Inc.
Rethink Possible

 =

Optimizatio= n, Reliability and Customer Analytics

200 South L= aurel Avenue, D5-3D19
Middletown, NJ 07748
P: 732.420.4174

ecnoel@att.com

 = ;

From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Saturday, July 20, 2013 7:11 AM
To: NOEL, ERIC C (ERIC C); 'DRAGE, Keith (Keith)'; 'Yu, James'
Cc: sip-overload-bo= unces@ietf.org; = draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: VS: [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt

 

Hi,

 <= /p>

I support = Keith’s suggestion. There is no need to copy/paste syntax from anothe= r specification – we should simply define the syntax additions/extens= ions.

 

Regards,

 

Christer

 

L=E4hett=E4j=E4: sip-overload-bounces@ietf.= org [mailto:sip-overlo= ad-bounces@ietf.org] Puolesta NOEL, ERIC C (ERIC C)
L=E4hetetty: 11. hein=E4kuuta 2013 21:33
Vastaanottaja: 'DRAGE, Keith (Keith)'; 'Yu, James'
Kopio: sip-overload= -bounces@ietf.org; = draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Aihe: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt=

 

Keith,

 

Thank you = for your comment.

 

IANA impac= ts:

- Based on= Keith suggestion, for the IANA impacts we only need to have the IANA consi= deration section in draft-ietf-soc-overload-control to include the future RFC number for draft-ietf-soc-overload-rate-control in the refe= rence column

- While Ja= mes is suggesting explicitly defining the new parameter value in the IANA c= onsideration section of draft-ietf-soc-overload-rate-control

=3D> Be= cause Keith proposal is aligned with RFC 3968 guidelines, I propose adoptin= g his proposal.

 

ABNF impac= ts:

- Based on= Keith suggestion, draft-ietf-soc-overload-rate-control syntax section shou= ld be reduced to

algo-list = /=3D “rate“

- While Ja= mes is suggesting that section to include

oc =3D = 220;oc” [EQUAL oc-num]

oc-num =3D= 1*DIGIT

oc-algo = =3D "oc-algo" EQUAL DQUOTE algo-list *(COMMA algo-list) DQUOTE

algo-list = =3D “loss” / “rate“ / *(other-algo)

other-algo= =3D %x41-5A / %x61-7A / %x30-39

=3D> Pe= r Keith suggestion, to prevent potential conflicts, I propose adopting his = proposal.

 

James woul= d you agree with the proposed resolution?

 

Thanks,

 

Eric Noel

AT&T= Labs, Inc.
Rethink Possible<= /i>

 

Network Des= ign and Performance Analysis
200 South Laurel Avenue, D5-3D19
Middletown, NJ 07748
P: 732.420.4174

ecnoel@att.com

 

From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com]
Sent: Wednesday, July 10, 2013 6:05 PM
To: NOEL, ERIC C (ERIC C); 'Yu, James'
Cc: sip-overload-bo= unces@ietf.org; = draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt

 

I’ve lost= track of what is happening here. What I expect is two things:<= /o:p>

 

1)  &= nbsp;      IANA registration impact.

 

For the header = field parameters registry, draft-ietf-soc-overload-control already creates = the new rows:

 

       Header Field  Param=
eter Name  Predefined Values  Reference
       ________________________=
__________________________________
       Via   &nb=
sp;       oc     &nb=
sp;           Yes &n=
bsp;           RFCXXXX
       Via   &nb=
sp;       oc-validity    =
    Yes         =
;    RFCXXXX
       Via   &nb=
sp;       oc-seq     =
;        Yes    &nbs=
p;        RFCXXXX

       Via   &nb=
sp;       oc-algo    &nbs=
p;       Yes     &nb=
sp;       RFCXXXX


 


       RFC XXXX [NOTE TO RFC-ED=
ITOR: Please replace with final RFC


       number of this specifica=
tion.]


 


For the predefi=
ned values columns, RFC 3968 states:


 


   Some SIP header field parameters only accept a s=
et of predefined


   parameter values.  For example, a parameter=
 indicating the transport


   protocol in use may only accept the predefined t=
okens TCP, UDP, and


   SCTP as valid values.  Registering all para=
meter values for all SIP


   header field parameters of this type would requi=
re a large number of


   subregistries.  Instead, we have chosen to =
register parameter values


   by reference.  That is, the entry in the pa=
rameter registry for a


   given header field parameter contains references=
 to the RFCs defining


   new values of the parameter.  References to=
 RFCs defining parameter


   values appear in double brackets in the registry=
. 


   So, the header field parameter registry contains=
 a column that


   indicates whether or not each parameter only acc=
epts a set of


   predefined values.  Implementers of paramet=
ers with a "yes" in that


   column need to find all the valid parameter valu=
es in the RFCs


   provided as references.


 


With this under=
standing, I do not believe the rate-control draft needs to modify the ̶=
0;predefined values” column. What it does need to do is add its
 ultimate RFC number to the reference column.


 


There could be =
an argument that there needs to be a new table that lists the algorithm val=
ues, but



 



a)      &nbs=
p;          
if such a tabl=
e is to be created, it needs to be created by draft-ietf-soc-overload-contr=
ol rather than the rate-control draft/



b)      &nbs=
p;          
I personally d=
o not think it is necessary to add such a new table, as I think the referen=
ces are sufficient. One cannot handle the algorithm values
 unless one goes to the relevant RFC.


 


2)  &=
nbsp;      ABNF impact.


 


ABNF defines th=
e /=3D operator for adding new values to an existing defined list.


 


I do not think =
we should reproduce existing ABNF from draft-ietf-soc-overload-control and =
then amend it.



 


The reason for =
this is that tools exist for automatically extracting the ABNF from RFCs. A=
n extracted



 


algo-list =
/=3D “rate“



 


will work perfe=
ctly well with the extract from draft-ietf-soc-overload-control (and from S=
IP). Reproducing productions will result in conflict.


 


Regards<=
o:p>


 


Keith


 












From:
sip-overload-bounces@ietf.=
org [mailto:sip-overlo=
ad-bounces@ietf.org]
On Behalf Of NOEL, ERIC C (ERIC C)

Sent: 10 July 2013 20:54

To: 'Yu, James'

Cc: sip-overload-bo=
unces@ietf.org;
=
draft-ietf-soc-overload-rate-control.all@tools.ietf.org;
sip-overload@ietf.org

Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.=
txt




 


James,


 


So section=
 5 (syntax) will include the following statements:


 


oc =3D =
220;oc” [EQUAL oc-num]


oc-num =3D=
 1*DIGIT


oc-algo =
=3D "oc-algo" EQUAL DQUOTE algo-list *(COMMA algo-list) DQUOTE


algo-list =
=3D “loss” / “rate“ / *(other-algo)


other-algo=
 =3D %x41-5A / %x61-7A / %x30-39


 


Thanks,


 




Eric Noel



AT&T=
 Labs, Inc.


Rethink Possible<=
/i>


 


Network Des=
ign and Performance Analysis

200 South Laurel Avenue, D5-3D19

Middletown, NJ 07748

P: 732.420.4174


ecnoel@att.com




 






From: Yu, James [ma=
ilto:james.yu@neustar.biz]


Sent: Wednesday, July 10, 2013 3:10 PM

To: NOEL, ERIC C (ERIC C)

Cc: sip-overload-bo=
unces@ietf.org;
=
draft-ietf-soc-overload-rate-control.all@tools.ietf.org;
sip-overload@ietf.org

Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.=
txt






 


Eric,


You may wa=
nt to copy the “oc-algo” line from other I-D.=



 


James


 






From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com]


Sent: Wednesday, July 10, 2013 1:10 PM

To: Yu, James

Cc: sip-overload-bo=
unces@ietf.org;
=
draft-ietf-soc-overload-rate-control.all@tools.ietf.org;
sip-overload@ietf.org

Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.=
txt






 


James,


 


Based on y=
our suggestion and comments from other reviewers, I intend to update sectio=
n 5 (syntax) as follows:


 


oc =3D =
220;oc” [EQUAL oc-num]


oc-num =3D=
 1*DIGIT


 


algo-list =
=3D “loss” / “rate“ / *(other-algo)


other-algo=
 =3D %x41-5A / %x61-7A / %x30-39


 


I understa=
nd there may be an additional change following Henning’s reply.


 


Thanks,


 




Eric Noel



AT&T=
 Labs, Inc.


Rethink Possible<=
/i>


 


Network Des=
ign and Performance Analysis

200 South Laurel Avenue, D5-3D19

Middletown, NJ 07748

P: 732.420.4174


ecnoel@att.com




 






From: Yu, James [ma=
ilto:james.yu@neustar.biz]


Sent: Wednesday, July 10, 2013 11:36 AM

To: NOEL, ERIC C (ERIC C)

Cc: sip-overload-bo=
unces@ietf.org;
=
draft-ietf-soc-overload-rate-control.all@tools.ietf.org;
sip-overload@ietf.org

Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.=
txt






 


Eric,


 


Yes, this =
adds “rate” to “oc-algo” parameter but please check=
 with IANA to see if it is the correct way.  You also need to copy som=
e syntax lines
 from the draft-ietf-soc-overload-control to show 


 


 &nbs=
p;  
algo-list   =3D
“loss“
 / “rate“<=
/span>
 / *(other-algo)


 


I’ve=
 an email to Henning asking if algo-list in his I-D should be


 &nbs=
p;   algo-list   =3D
“loss“
 / other-algo


 


If yes, th=
en this particular line in your I-D would be



 &nbs=
p;   algo-list   =3D
“loss“
 / “rate“<=
/span>
 / other-algo


 


James


 






From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com]


Sent: Wednesday, July 10, 2013 10:49 AM

To: Yu, James

Cc: sip-overload-bo=
unces@ietf.org;
=
draft-ietf-soc-overload-rate-control.all@tools.ietf.org;
sip-overload@ietf.org

Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.=
txt






 


James,


 


Thank you =
for your suggestion.



 


Not being =
familiar with IANA procedure, would updating draft-ietf-soc-overload-rate-c=
ontrol section 7 (IANA considerations) as follows work?

 


This speci=
fication defines a new value for Via header parameter oc-algo as detailed b=
elow in the "Header Field Parameter and Parameter Values"
 subregistry as per the registry created by [RFC3968]. The required informa=
tion is:


 


Header Fie=
ld           Parameter Na=
me             =
           Predefine=
d Values            =
        Reference=



----------=
---------------------------------------------------------------------------=
---------------------


Via  =
            &nb=
sp;            =
   oc-algo         &=
nbsp;           &nbs=
p;            &=
nbsp;           R=
20;rate”          &=
nbsp;           &nbs=
p;             =
         RFCXXXX


 


RFC XXXX [=
NOTE TO RFC-EDITOR: Please replace with final RFC number of this specificat=
ion.]


 


Thanks,


 




Eric Noel



AT&T=
 Labs, Inc.


Rethink Possible<=
/i>


 


Network Des=
ign and Performance Analysis

200 South Laurel Avenue, D5-3D19

Middletown, NJ 07748

P: 732.420.4174


ecnoel@att.com




 






From: Yu, James [ma=
ilto:james.yu@neustar.biz]


Sent: Wednesday, July 10, 2013 10:17 AM

To: NOEL, ERIC C (ERIC C)

Cc: sip-overload-bo=
unces@ietf.org;
=
draft-ietf-soc-overload-rate-control.all@tools.ietf.org;
sip-overload@ietf.org

Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.=
txt






 


Noel,


 


I forgot t=
o respond to your reply about the IANA registration of “rate” i=
n oc-algo.  I see that draft-ietf-soc-overload-control-13 mentions you=
r
 I-D but does not have “rate” in algo-list.

 


There are =
two possible ways to address “rate” in algo-list.  One is =
to have draft-ietf-soc-overload-control-13 add “rate” to algo-l=
ist and refer
 to your I-D for details.  The other is to register “rate”=
 in algo-list with IANA in your I-D, and this should be a simple task. =
; The cleaner way that is more inline with the IETF process would be the la=
tter.  It seems odd to have something defined in a RFC
 without details about it, and it would be too much trouble to combine the =
two I-Ds.


 


James


 






From: Yu, James


Sent: Wednesday, July 10, 2013 9:01 AM

To: 'NOEL, ERIC C (ERIC C)'

Cc: sip-overload-bo=
unces@ietf.org;
=
draft-ietf-soc-overload-rate-control.all@tools.ietf.org;
sip-overload@ietf.org

Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.=
txt






 


Noel,


 


I mentione=
d in my message to Janet on 7/2:


 


For the rate control, the server could calculate the arriv=
al rate from each communicating client so that it could allocate
 the overall target SIP request rate to the clients based on their arrival =
rates known to the server.  But another option is for the client to &#=
8220;optionally” include its calculated arrival rate in its request t=
o the server when rate control related parameters
 are present.  Should this option be evaluated/included to relieve the=
 server from doing the arrival rate calculations.  This would be benef=
icial to a server when it receives the requests from many clients.


 


I suggest =
that the I-D adds that option to allow the client to indicate its current a=
rrival rate (towards the receiving server) in the SIP request.<=
/o:p>


 


James


 






From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com]


Sent: Tuesday, July 09, 2013 4:44 PM

To: Yu, James; Janet P Gunn

Cc: sip-overload-bo=
unces@ietf.org;
=
draft-ietf-soc-overload-rate-control.all@tools.ietf.org;
sip-overload@ietf.org

Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.=
txt






 


Janet, Jam=
es,


 


Thanks you=
 for your valuable comments and discussion.  I tried to capture all re=
solution in the following text (based on James word document with
 track changes and imbedded comments enabled).


 


+ Abst=
ract section:



- Agreed w=
ith suggested changes


- Please n=
ote I will also need to make further changes to remove all references per C=
hrister Holmberg comment


 


+ Sect=
ion 1:


- Agreed w=
ith suggested changes


 


+ Sect=
ion 3.1:


- Agreed w=
ith suggested changes


 



+ Sect=
ion 3.2: - Please note the section title will become “Via header fiel=
d parameters for overload control “ per Christer Holmberg comment


- Agreed w=
ith suggested changes excluding title that will change per previous bullet<=
/span>


 


+ Sect=
ion 3.3:


- Agreed w=
ith suggested changes


 


+ Sect=
ion 3.4:


- ID: &nbs=
p;"Note that the target SIP request rate is a max rate that may not be=
 attained by the arrival rate at the client, and the server cannot assume
 that it will." 


 &nbs=
p; [JY] Not clear what value this paragraph tries to add.  Is it =
saying that the client's arrival rate may be lower than the target SIP requ=
est
 rate? 


 &nbs=
p; [JG] Yes + supporting example (see below in thread)=



 &nbs=
p;Agreed with Janet and supporting example. Per James request, I will add t=
he following text (inspired from Janet’s illustrative example):


 &nbs=
p; “In other words, when multiple clients are being controlled by an =
overloaded server, at any given time some clients may receive requests at
 a rate below its target SIP request rate while others above that target ra=
te. But the resulting request rate presented to the overloaded server will =
converge towards the target SIP request rate.”


- Agreed w=
ith other suggested changes



 &nbs=
p;   


+ Sect=
ion 3.5.1:


- ID: R=
20;And the larger the difference between TAU1 and TAU2, the closer to the c=
ontrol is to strict priority.”


  [JY=
] Suggest changing into “And the larger the difference between TAU1 a=
nd TAU2, the closer the control is to strict priority queuing.”


  [JG=
] Suggest changing into “And the larger the difference between TAU1 a=
nd TAU2, the closer the control is to strict priority treatment.”


  [EN=
] Agreed with Janet’s suggestion


- Agreed w=
ith other suggested changes


 


+ Sect=
ion 4:


- Agreed w=
ith suggested changes


 


+ Sect=
ion 5:


- Please n=
ote that based comments from per Christer Holmberg and Janet Gunn, the foll=
owing was tentatively agreed



 &nbs=
p; Replace oc-value =3D "NaN" / oc-num    by&=
nbsp;   oc =3D "oc" [EQUAL oc-num]

- Agreed w=
ith other suggested change


 


+ Sect=
ion 7:


- [JY] Sho=
uld “rate” in oc-algo be registered with IANA?


  Thi=
s issue needs to be addressed by draft-ietf-soc-overload-control authors


 


Please not=
e I will wait until expiration of WGLC prior updating our draft RFC. Once a=
gain your comments and/or suggestions are most appreciated.


 


Thanks,


 




Eric Noel



AT&T=
 Labs, Inc.


Rethink Possible<=
/i>


 


Network Des=
ign 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-overlo=
ad-bounces@ietf.org]
On Behalf Of Yu, James

Sent: Tuesday, July 02, 2013 9:42 AM

To: Janet P Gunn

Cc: sip-overload-bo=
unces@ietf.org;
=
draft-ietf-soc-overload-rate-control.all@tools.ietf.org;
sip-overload@ietf.org

Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.=
txt






 


Janet,


 


For my com=
ment on section 3.4 (the first one below), the current text does not provid=
e any value.  The client’s arrival rate could be well below
 the target SIP request rate when its load is light so the fact that the cl=
ient may not achieve the target SIP request rate (the max. rate it is allow=
ed to send to the server) is well understood.  But with your explanati=
on on the “delta” part, the text then
 makes sense.  Please add some discussions on the “delta” =
aspect so that even if the average arrival rate at the client is higher tha=
n the target SIP request rate the client at times may not send more than wh=
at the target SIP request rate allows due to the
 fluctuation of the arriving requests at the client.


 


For the co=
mment on section 3.5.1, I agree with your proposed change.


 


For the ra=
te control, the server could calculate the arrival rate from each communica=
ting client so that it could allocate the overall target SIP
 request rate to the clients based on their arrival rates known to the serv=
er.  But another option is for the client to “optionally” =
include its calculated arrival rate in its request to the server when rate =
control related parameters are present.  Should this
 option be evaluated/included to relieve the server from doing the arrival =
rate calculations.  This would be beneficial to a server when it recei=
ves the requests from many clients.


 


James


 




From: Janet P Gunn [mailt=
o:jgunn6@csc.com]


Sent: Friday, June 28, 2013 3:34 PM

To: Yu, James

Cc: 
draft-ietf-soc-overload-rate-control.all@tools.ietf.org; 
sip-overload@ietf.org; sip-overload-bounces@ietf.org

Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.=
txt




 


James,




It is a little hard to respond in email wh=
en your comments are in a separate document, but here goes.






section 3.4


ID says:


"Note that the target SIP request rat=
e is a max rate that may not be


   attained by the arrival rate =
at the client, and the server cannot


   assume that it will."




Your comment :


"Not clear what value this paragraph =
tries to add.  Is it saying that the client's arrival rate may be lowe=
r than the target SIP request rate?  "




Yes.




Suppose the server want to limit the total=
 rate of arriving SIP messages to 100 / sec, and has 10 clients.  Each=
 client has a high variance in its message rate, but together
 they are well above 100 messages per sec 



If it sets the rate at 10 messages per sec=
ond for each of the clients, it will almost certainly end up  with an =
overall average of less than 100 messages per sec, because some
 clients will be in a "lull" while others are busy.  This is=
 good from a throttling perspective, but, assuming messages are correlated =
with revenue, bad/wasteful from a revenue, or overall productivity perspect=
ive.  So the server might want to set the rate
 per client to 10 + delta, where delta is going to be very specific to =
operating environment.




---


In section  3.5.1, bottom of page 8


ID says:


"And the larger


   the difference between TAU1 a=
nd TAU2, the closer to the control is


   to strict priority."




You propose changing it to:


"And the larger


   the difference between TAU1 a=
nd TAU2, the closer  the control is


   to strict priority queuing.&q=
uot;




I agree with taking out the redundant &quo=
t;to".  But I disagree wit adding "queuing".  Ther=
e is no queuing, priority or otherwise involved.




You could say:


"And the larger


   the difference between TAU1 a=
nd TAU2, the closer  the control is


   to strict priority treatment.=
"




where " strict priority treatment&quo=
t; would refer to the case where non-priority messages are restricted to a =
total (priority + non-priority) rate of 10 messages per second, but
 priority messages can continue to be sent as long as the total (priority &=
#43; non-priority) rate is less than 12 messages per second.




At least, I think that is what Eric and &n=
bsp;Philip are trying to say.




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 agreement or government initiative exp=
ressly permitting the use of e-mail for such purpose.








From:       &n=
bsp;"Yu, James" <james.yu@neustar.biz>


To:       &nbs=
p;"sip-overload-bounces@ietf.org"
 <sip-overload-bounces@=
ietf.org>, "draft-ietf-soc-overload-rate-control.all@tools.ietf=
.org" <draft-ietf-soc-overload-rate-control.all@tools.ietf.org<=
/a>>,
 "sip-overload@ietf.org&q=
uot; <sip-overload@ietf.org=
>


Date:       &n=
bsp;06/28/2013 08:10 AM


Subject:      =
  [sip-overload] draft-ietf-soc-overlo=
ad-rate-control-04.txt


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









=






Salvatore,


 


Please see the attachment for my comment=
s.


 


I pasted the text to a word document to =
trace/show the proposed changes and comments.


 


Regards,


 


James


 [attachment "comments on draf=
t-ietf-soc-overload-rate-control-04.docx" deleted by Janet P Gunn/USA/=
CSC]
________________=
_______________________________

sip-overload mailing list

sip-overload@ietf.org=


https://www.ietf.org/m=
ailman/listinfo/sip-overload








No virus found in this message.

Checked by AVG - www.avg.com

Version: 2013.0.2904 / Virus Database: 3204/6452 - Release Date: 06/30/13








No virus found in this message.

Checked by AVG - www.avg.com

Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13








No virus found in this message.

Checked by AVG - www.avg.com

Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13








No virus found in this message.

Checked by AVG - www.avg.com

Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13
--_000_7594FB04B1934943A5C02806D1A2204B1C3F6D87ESESSMB209erics_-- From shida@ntt-at.com Mon Jul 22 09:11:31 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 DDFBB21E808D for ; Mon, 22 Jul 2013 09:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.862 X-Spam-Level: X-Spam-Status: No, score=-101.862 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8I7d16sUEBT for ; Mon, 22 Jul 2013 09:11:27 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 62F6C11E80E7 for ; Mon, 22 Jul 2013 09:11:27 -0700 (PDT) Received: from [50.152.169.249] (port=50654 helo=[192.168.1.8]) by gator465.hostgator.com with esmtpa (Exim 4.80) (envelope-from ) id 1V1Iho-0007oM-UH; Mon, 22 Jul 2013 11:11:25 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_9B77D08F-1892-49FB-9E7A-F78186475EC0" From: Shida Schubert In-Reply-To: Date: Mon, 22 Jul 2013 09:11:23 -0700 Message-Id: <42387DF3-A8BF-4668-853B-2E1CB5088838@ntt-at.com> References: <215A826D-A1A0-4EB2-9E07-7B19AF3783C1@ntt-at.com> To: Charles Shen X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.8]) [50.152.169.249]:50654 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 2 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: sip-overload@ietf.org, draft-ietf-soc-load-control-event-package@tools.ietf.org Subject: Re: [sip-overload] AD review of draft-ietf-soc-load-control-event-package-08 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, 22 Jul 2013 16:11:32 -0000 --Apple-Mail=_9B77D08F-1892-49FB-9E7A-F78186475EC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Charles; Below looks good.=20 Thanks Shida On Jul 19, 2013, at 12:11 PM, Charles Shen wrote: > Hi Shida, I agree that we do not have to mandate TLS. How about adding = the following texts about "Trust Domain" to the current document, = without describing more specific details?=20 >=20 > "This specification MUST be applied inside a 'Trust Domain'. The = concept of a Trust Domain is similar to that defined in [RFC3324]. A = Trust Domain for the purpose of SIP load filtering is a set of entities = such as SIP proxy servers that are trusted to exchange load filtering = policies defined in this document. In the simplest case, a Trust Domain = is a network of SIP entities belonging to a single owner/operator who = deploys it and accurately knows the behaviour of those SIP entities. = Such simple Trust Domains may be joined to form larger Trust Domains by = bi-lateral agreements between the owners/operators of the SIP entities. >=20 > A key requirement of the Trust Domain for the purpose of SIP load = filtering is that the behavior of all SIP entities within a given Trust = Domain 'T' is known to comply to the following set of specifications = known as 'Spec(T)'.=20 >=20 > 1. The mechanisms used to secure the communication among SIP entities = within the Trust Domain=20 > 2. The manner used to determine which SIP entities are part of the = Trust Domain=20 > 3. That SIP entities in the Trust Domain are compliant to SIP = [RFC3261]=20 > 4. That SIP entities in the Trust Domain are compliant to this = document " >=20 > Thanks >=20 > Charles >=20 > On Tue, Jul 16, 2013 at 10:49 AM, Shida Schubert = wrote: >=20 > Hi Charles; >=20 > Hmm.. As far as I can recall RFC3325 references Spec(T) BUT it = doesn't=20 > reference it normatively.=20 >=20 > Second paragraph of section 11. in RFC3325.=20 >=20 > The remainder of this section presents an example Spec(T), which is >=20 > not normative in any way. >=20 > Actually security consideration in RFC3325 rather keeps the mechanism=20= > to secure the channels open.=20 >=20 >=20 >=20 > The use of transport or > network layer hop-by-hop security mechanisms, such as TLS or IPSec > with appropriate cipher suites, can satisfy this requirement. >=20 > I think most of the implementations that will comply to use this will = not use=20 > TLS and mandating TLS doesn't make sense. I think text in the line of = what=20 > RFC3325 should be sufficient for security consideration in the = SOC-evnet-package=20 > as well. >=20 > Regards > Shida > =20 > On Jul 14, 2013, at 8:38 AM, Charles Shen wrote: >=20 >> Hi Richard, for your comment on "trusted domain"=20 >>=20 >>=20 >>=20 >> [CS] How about phrasing it as being applicable "within trusted = intra-domain and/or trusted inter-domain" scenarios?=20 >>=20 >> We really need to be clear here about what "trusted" means. = ("Trusted" is a word that makes Security ADs pounce :) ) What is each = party "trusted" not to do? If you look at RFC 3325, it lays out exactly = what the parties need to be agree on before they use P-Asserted-ID. I = think an analogous list of criteria is needed here. >>=20 >>=20 >>=20 >> =46rom RFC 3324/3325, "A key requirement is that the behavior of all = nodes within a given Trust Domain 'T' is known to comply to a certain = set of specifications known as 'Spec(T)'." Therefore, if we define the = "Trusted Domain" for load control, we must define what Spec(T) means for = this document. RFC 3325 listed the following for its use with = "P-Asserted-Identity"=20 >>=20 >> 1. The manner in which users are authenticated=20 >> 2. The mechanisms used to secure the communication among nodes within = the Trust Domain=20 >> 3. The mechanisms used to secure the communication between UAs and = nodes within the Trust Domain=20 >> 4. The manner used to determine which hosts are part of the Trust = Domain=20 >> 5. The default privacy handling when no Privacy header field is = present=20 >> 6. That nodes in the Trust Domain are compliant to SIP [1]=20 >> 7. That nodes in the Trust Domain are compliant to this document=20 >> 8. Privacy handling for identity as described in Section 7.=20 >>=20 >> My revision in progress considers 2, 4, 6, 7 as applicable in our = load control context - basically the UA and Privacy handling is not = applicable in our case.=20 >>=20 >> Therefore, an example (non-nomative) Spec(T) for a trusted domain of = load control can be as below >>=20 >> 1. Protocol requirements >>=20 >> The following specifications MUST be supported:=20 >> 1) RFC 3261=20 >> 2) RFC (this load control specification number) >>=20 >> 2. Security requirements >>=20 >> Connections between nodes within the Trust Domain in the Trust Domain = MUST use TLS using a cipher suite of RSA_WITH_AES_128_CBC_SHA1. Mutual = authentication between nodes in the trust domain MUST be performed and = confidentiality MUST be negotiated. >>=20 >> 3. Scope of Trust Domain >>=20 >> The Trust Domain specified in this agreement consists of hosts which = posses a valid certificate which is a) signed by examplerootca.org; b) = whose subjectAltName ends with one of the following domain names: = trusted.div1.carrier-a.net,trusted.div2.carrier-a.net, = sip.carrier-b.com; and c) whose domain name corresponds to the hostname = in the subjectAltName in the certificate. >>=20 >> Is this OK with you or do you have any additional thoughts?=20 >>=20 >> thanks! >>=20 >> Charles >>=20 >>=20 >>=20 >>=20 >> On Thu, Jun 20, 2013 at 1:40 PM, Charles Shen = wrote: >> Hi Richard, Thank you for the follow up, please see some comments = below. >>=20 >> On Sat, Jun 15, 2013 at 4:32 AM, Richard Barnes wrote: >>=20 >>=20 >> [CS] How about phrasing it as being applicable "within trusted = intra-domain and/or trusted inter-domain" scenarios?=20 >>=20 >> We really need to be clear here about what "trusted" means. = ("Trusted" is a word that makes Security ADs pounce :) ) What is each = party "trusted" not to do? If you look at RFC 3325, it lays out exactly = what the parties need to be agree on before they use P-Asserted-ID. I = think an analogous list of criteria is needed here. >>=20 >> [CS] It makes a lot of sense to adopt RFC3325/3324 notion of Trusted = domains, I will work on that.=20 >>=20 >> =20 >> I agree, let's do option (2). Suggested text: >> """ >> This document does not define the content of SUBSCRIBE bodies. = Future specifications could define bodies for SUBSCRIBE messages, for = example to request specific types of load control event notifications. >> """ >>=20 >> [CS] Will do. >> =20 >>=20 >> To be clear on this, the ambiguity here is with regard to the case. In the case, you just do Tel URI = comparison. >>=20 >> Thinking on this a little more, it looks like your use of the = "domain" parameter actually breaks with RFC 4745. According to RFC = 4745, there must be an exact match between the "domain" value provided = by the using protocol and the value in the "domain" parameter. I can't = think of a way that this document could define a way to extract a domain = from a telephone number that would meet the semantic you seem to be = intending. >>=20 >> So it seems like you need to do one of the following: >> 1. Define a rule for how you compute a domain value from a tel: URI. >> 2. Define a new element for use under (since lacks an = extension point) >> 3. Drop support for excluding phone numbers by domain (you just have = to enumerate the exceptions individually) >>=20 >>=20 >> [CS] If we opt for Option 1, can we do the following: >>=20 >> a. assume E.164 numbers always start with + sign, so we can use the = digits after the + sign (after removing any visual separaters, as in the = Tel URL comparison rules) as the presumed domain value.=20 >> b. for local numbers (numbers that do not start with +), the = "phone-context" contains the domain value.=20 >>=20 >> =20 >> [CS] It seems to me that how to enforce the rate/window/percent = becomes more implementation specific, and these action items are what = the rest of the WG documents (http://datatracker.ietf.org/wg/soc/) are = using as well. The first paragraph of Section 7.4 also referenced = RFC6357 on more details about these actions. Therefore, I am not sure = what more concrete actions you are referring to, could you please = elaborate a bit on this? >>=20 >> I can live with this answer. >>=20 >>=20 >> [CS] OK >> =20 >> To be clear, the concern here isn't about a policy that combines two = actions in the same rule. The concern is when two rules match the same = call, in which case both actions must be applied. >>=20 >> For example suppose you have the following rule set: >> RULE 1: Reject all calls from example.com=20 >> -- Conditions: >> -- Actions: 0 >> RULE 2: Redirect all calls from alice@example.com >> -- Conditions: >> -- Actions: 0 >>=20 >> It doesn't seem like there's a sensible way to combine those rules. = In principle, it seems like the simplest thing would be to say that a = policy MUST NOT specify two rules that could apply to the same SIP = message. Would people feel comfortable that you could efficiently check = this exclusivity? It does scale as the square of the number of rules. >>=20 >>=20 >> [CS] Very good point. We propose an easy "the first-match rule", = i.e., the call is handled based on the first rule that matches. What do = you think?=20 >> =20 >>=20 >> [CS] "simple drop" here means simply ignoring the request without = doing anything. i.e., in the reliable transport case, it does not have = to close the transport connection. It still saves some processing needed = in sending out the rejection in reliable transport. But I am open to = eleminating it if the group prefers so.=20 >>=20 >> It would help if you could add that clarification to "simple drop". =20= >>=20 >> [CS] Will do. In addition, "Simple drop seems good for dealing with = telephony DOS attacks" >>=20 >> Thanks! >>=20 >> Charles >>=20 >> =20 >>=20 >> Thanks, >> --Richard=20 >>=20 >> _______________________________________________ >> sip-overload mailing list >> sip-overload@ietf.org >> https://www.ietf.org/mailman/listinfo/sip-overload >>=20 >>=20 >>=20 >> _______________________________________________ >> sip-overload mailing list >> sip-overload@ietf.org >> https://www.ietf.org/mailman/listinfo/sip-overload >=20 >=20 --Apple-Mail=_9B77D08F-1892-49FB-9E7A-F78186475EC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi Shida, I agree that we do not have to mandate TLS. = How about adding the following texts about "Trust Domain" to the current = document, without describing more specific = details? 

"This specification MUST be = applied inside a 'Trust Domain'. The concept of a Trust Domain is = similar to that defined in [RFC3324]. A Trust Domain for the purpose of = SIP load filtering is a set of entities such as SIP proxy servers that = are trusted to exchange load filtering policies defined in this = document. In the simplest case, a Trust Domain is a network of SIP = entities belonging to a single owner/operator who deploys it and = accurately knows the behaviour of those SIP entities. Such simple Trust = Domains may be joined to form larger Trust Domains by bi-lateral = agreements between the owners/operators of the SIP entities.

A key requirement of the Trust Domain for the = purpose of SIP load filtering is that the behavior of all SIP entities = within a given Trust Domain 'T' is known to comply to the following set = of specifications known as 'Spec(T)'. 

1. The mechanisms used to secure the communication = among SIP entities within the Trust Domain 
2. The manner = used to determine which SIP entities are part of the Trust = Domain 
3. That SIP entities in the Trust Domain are = compliant to SIP [RFC3261] 
4. That SIP entities in the Trust Domain are compliant to this = document = "

Thanks

Charles
On Tue, Jul 16, 2013 at 10:49 AM, Shida = Schubert <shida@ntt-at.com> wrote:

Hi = Charles;

 Hmm.. As far as I can recall = RFC3325 references Spec(T) BUT it doesn't 
reference it = normatively. 

 Second paragraph of = section 11. in RFC3325. 

  The = remainder of this section presents an example Spec(T), which = is
   not normative in any way.

 Actually = security consideration in RFC3325 rather keeps the = mechanism 
to secure the channels = open. 

   The use of transport or
   network layer hop-by-hop security mechanisms, such as TLS or IPSec
   with appropriate cipher suites, can satisfy this =
requirement.

 I think most of the = implementations that will comply to use this will not = use 
TLS and mandating TLS doesn't make sense. I think = text in the line of what 
RFC3325 should be sufficient for security consideration in the = SOC-evnet-package 
as = well.

 Regards
  = Shida
 
On Jul 14, 2013, at 8:38 = AM, Charles Shen wrote:

= Hi Richard, for your comment on "trusted domain" 
=
=
=

[CS] How about phrasing it as being applicable "within trusted = intra-domain and/or trusted inter-domain" = scenarios? 

We really = need to be clear here about what "trusted" means.  ("Trusted" is a = word that makes Security ADs pounce :) )  What is each party = "trusted" not to do?  If you look at RFC 3325, it lays out exactly = what the parties need to be agree on before they use P-Asserted-ID. =   I think an analogous list of criteria is needed here.

=
=
= =46rom RFC 3324/3325, "A key requirement is that the behavior of all = nodes within a given Trust Domain 'T' is known to comply to a certain = set of specifications known as 'Spec(T)'." Therefore, if we define the = "Trusted Domain" for load control, we must define what Spec(T) means for = this document. RFC 3325 listed the following for its use with = "P-Asserted-Identity" 
=
= 1. The manner in which users are authenticated 
= 2. The mechanisms used to secure the communication among nodes within = the Trust Domain 
= 3. The mechanisms used to secure the communication between UAs and nodes = within the Trust Domain 
= 4. The manner used to determine which hosts are part of the Trust = Domain 
= 5. The default privacy handling when no Privacy header field is = present 
= 6. That nodes in the Trust Domain are compliant to SIP = [1] 
= 7. That nodes in the Trust Domain are compliant to this = document 
= 8. Privacy handling for identity as described in Section 7. 
=
= My revision in progress considers 2, 4, 6, 7 as applicable in our load = control context - basically the UA and Privacy handling is not = applicable in our case. 
=
= Therefore, an example (non-nomative) Spec(T) for a trusted domain of = load control can be as below
=
= 1. Protocol requirements
=
= The following specifications MUST be supported: 
= 1) RFC 3261 
= 2) RFC (this load control specification number)
=
= 2. Security requirements
=
= Connections between nodes within the Trust Domain in the Trust Domain = MUST use TLS using a cipher suite of RSA_WITH_AES_128_CBC_SHA1. Mutual = authentication between nodes in the trust domain MUST be performed and = confidentiality MUST be negotiated.
=
= 3. Scope of Trust Domain
=
= The Trust Domain specified in this agreement consists of hosts which = posses a valid certificate which is a) signed by examplerootca.org; b) whose subjectAltName ends = with one of the following domain names:  trusted.div1.carrier-a.net,trusted.div2.carrier-a.net, sip.carrier-b.com; and c) whose domain name = corresponds to the hostname in the subjectAltName in the = certificate.

Is this OK with you or do you have any additional = thoughts? 

thanks!

= Charles




On Thu, Jun 20, 2013 at 1:40 PM, Charles Shen <charles@cs.columbia.edu> = wrote:
Hi Richard, Thank you for the follow up, please see some comments = below.

On Sat, Jun 15, 2013 at = 4:32 AM, Richard Barnes <rlb@ipv.sx> = wrote:
=

[CS] = How about phrasing it as being applicable "within trusted intra-domain = and/or trusted inter-domain" scenarios? 

We really need = to be clear here about what "trusted" means.  ("Trusted" is a word = that makes Security ADs pounce :) )  What is each party "trusted" = not to do?  If you look at RFC 3325, it lays out exactly what the = parties need to be agree on before they use P-Asserted-ID.   I = think an analogous list of criteria is needed here.

[CS] It = makes a lot of sense to adopt RFC3325/3324 notion of Trusted domains, I = will work on = that. 

 
I agree, let's do option (2).  Suggested = text:
"""
This document does not define the content of SUBSCRIBE = bodies.  Future specifications could define bodies for SUBSCRIBE = messages, for example to request specific types of load control event = notifications.
=
"""

[CS] Will do.
 

To be clear on = this, the ambiguity here is with regard to the <except = domain=3D"..."> case.  In the <one id=3D"..."> case, you = just do Tel URI comparison.

Thinking on this a little more, it looks like your = use of the "domain" parameter actually breaks with RFC 4745. =  According to RFC 4745, there must be an exact match between the = "domain" value provided by the using protocol and the value in the = "domain" parameter.  I can't think of a way that this document = could define a way to extract a domain from a telephone number that = would meet the semantic you seem to be intending.

So it seems like you need to do one of the = following:
1. Define a rule for how you compute a domain value = from a tel: URI.
2. Define a new element for use under = <many> (since <except> lacks an extension point)
3. Drop support for excluding phone numbers by domain (you just = have to enumerate the exceptions = individually)


[CS] If we opt for Option 1, can we do = the following:

a. assume E.164 numbers always start with + sign, so = we can use the digits after the + sign (after removing any visual = separaters, as in the Tel URL comparison rules) as the presumed domain = value. 
b. for local numbers (numbers that do not start with +), the = "phone-context" contains the domain = value. 

 
[CS] It seems to me that how = to enforce the rate/window/percent becomes more implementation specific, = and these action items are what the rest of the WG documents (http://datatracker.ietf.org/wg/soc/) are using as = well. The first paragraph of Section 7.4 also referenced RFC6357 on more = details about these actions. Therefore, I am not sure what more concrete = actions you are referring to, could you please elaborate a bit on this? =

I can live = with this = answer.

=

[CS] OK
 
To be clear, the concern here isn't about a = policy that combines two actions in the same rule.  The concern is = when two rules match the same call, in which case both actions must be = applied.

For example suppose you have the following rule = set:
RULE 1: Reject all calls from example.com 
-- Conditions: = <from><identity><many domain=3D"example.com"/></identity></from>
-- Actions: <accept = alt-action=3D"reject"><rate>0</rate></accept>
RULE 2: Redirect all calls from alice@example.com
-- Conditions: <from><identity><one id=3D"sip:alice@example.com"/></identity></fro= m>
-- Actions: <accept alt-action=3D"redirect" alt-target=3D"sip:eve@example.com"><rate>0</rate>&l= t;/accept>

It doesn't seem like there's a sensible way to combine those = rules.  In principle, it seems like the simplest thing would be to = say that a policy MUST NOT specify two rules that could apply to the = same SIP message.  Would people feel comfortable that you could = efficiently check this exclusivity?  It does scale as the square of = the number of rules.
=


<= /div>
[CS] Very good point. We propose an easy "the first-match rule", i.e., the call is handled = based on the first rule that matches. What do you think? 
 

[CS] = "simple drop" here means simply ignoring the request without doing = anything.  i.e., in the reliable transport case, it does not have = to close the transport connection. It still saves some processing needed = in sending out the rejection in reliable transport. But I am open to = eleminating it if the group prefers so. 

It would help = if you could add that clarification to "simple drop". =  

[CS] Will do. In addition, "Simple drop seems good for dealing with telephony DOS = attacks"

Thanks!

Charles

 

Thanks,
--Richard = ;

_______________________________________________
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



= --Apple-Mail=_9B77D08F-1892-49FB-9E7A-F78186475EC0-- From james.yu@neustar.biz Mon Jul 22 12:18:56 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 3477F11E80F5; Mon, 22 Jul 2013 12:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6CoXJb76lLZ; Mon, 22 Jul 2013 12:18:44 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id DF5DA11E80AD; Mon, 22 Jul 2013 12:18:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1374520668; x=1689878326; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=bnRHNx6Up/ucrkjjeyq4JO6Ik+pXyXfqsbGssVC92u0=; b=qFaXGKH8l9e9zWOCr7LB5xAVFn6PxWA32PXgn1PdxvVz6jdcvcpzxH2iePVn1B yC1ki1dimixXiqFSSdz2ZHlg== Received: from ([10.31.58.70]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.22744409; Mon, 22 Jul 2013 15:17:47 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Mon, 22 Jul 2013 15:18:12 -0400 From: "Yu, James" To: "hgs@cs.columbia.edu" , "vkg@bell-labs.com" , "volkerh@bell-labs.com" Thread-Topic: [sip-overload] draft-ietf-soc-overload-control-13 Thread-Index: AQHOhxA1oeh2GmM75kOFVkO2B67yLw== Date: Mon, 22 Jul 2013 19:18:12 +0000 Message-ID: <56FB15AFE08E1242B0736CBDCE6E856108096C00@stntexmb12.cis.neustar.com> References: <56FB15AFE08E1242B0736CBDCE6E85610808C32F@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610808EF90@stntexmb12.cis.neustar.com> In-Reply-To: <56FB15AFE08E1242B0736CBDCE6E85610808EF90@stntexmb12.cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.130.24] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: e4oYRJoSAYfDi/gc24OWOA== Content-Type: multipart/alternative; boundary="_000_56FB15AFE08E1242B0736CBDCE6E856108096C00stntexmb12cisne_" MIME-Version: 1.0 Cc: "sip-overload-bounces@ietf.org" , "sip-overload@ietf.org" Subject: [sip-overload] draft-ietf-soc-overload-control-13 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, 22 Jul 2013 19:18:56 -0000 --_000_56FB15AFE08E1242B0736CBDCE6E856108096C00stntexmb12cisne_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Henning, Vijay, Volker, When I reviewed draft-ietf-soc-overload-rate-control-04.txt, I glanced thro= ugh the syntax in this I-D to understand the oc related parameters. When looking at "algo-list", I wonder if there are two "other-algo" such as= "abc" and "xyz", 'abc" and "xyz" won't be comma-separated based on the oc-= algo syntax. It seems that algo-list would be algo-list =3D "loss" / other-algo This would ensure that one and only one algorithm is present in algo-list. = If there is no algorithm other than "loss", *(COMMA algo-list) would take = care of that. Since algo-list contains a single algorithm, may be it is better to use "al= go" only. Or if algo-list contains a list of comma separated algorithms, t= hen alog-list and oc-algo can be modified so that oc-algo has a single "alg= o-list". The latter may be better because the current syntax would allow t= he same algorithm to appear more than once. James --_000_56FB15AFE08E1242B0736CBDCE6E856108096C00stntexmb12cisne_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Henning, Vijay, Volker,

 

When I reviewed draft-ietf-soc-overload-rate-control= -04.txt, I glanced through the syntax in this I-D to understand the oc rela= ted parameters.

 

When looking at “algo-list”, I wonder if= there are two “other-algo” such as “abc” and ̶= 0;xyz”, ‘abc” and “xyz” won’t be comma-= separated based on the oc-algo syntax.  It seems that algo-list would = be

 

=  algo-list =3D “loss̶= 0; / other-algo

=  

This would ensure that one and only one algorithm is= present in algo-list.  If there is no algorithm other than “los= s”, *(COMMA algo-list) would take care of that.

 

Since algo-list contains a single algorithm, may be = it is better to use “algo” only.  Or if algo-list contains= a list of comma separated algorithms, then alog-list and oc-algo can be mo= dified so that oc-algo has a single “algo-list”.  The latter may be better because the current syntax would allow the same algor= ithm to appear more than once.

 

James

--_000_56FB15AFE08E1242B0736CBDCE6E856108096C00stntexmb12cisne_-- From vkg@bell-labs.com Mon Jul 22 12:39:16 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 F188C11E811D for ; Mon, 22 Jul 2013 12:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuzd7k-QruSi for ; Mon, 22 Jul 2013 12:39:10 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4A14F11E80F5 for ; Mon, 22 Jul 2013 12:39:10 -0700 (PDT) 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 r6MJd29W028206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 22 Jul 2013 14:39:02 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r6MJd09v026834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Jul 2013 14:39:00 -0500 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 r6MJctr6012607; Mon, 22 Jul 2013 14:38:56 -0500 (CDT) Message-ID: <51ED8B54.7040705@bell-labs.com> Date: Mon, 22 Jul 2013 14:43:16 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Yu, James" References: <56FB15AFE08E1242B0736CBDCE6E85610808C32F@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610808EF90@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E856108096C00@stntexmb12.cis.neustar.com> In-Reply-To: <56FB15AFE08E1242B0736CBDCE6E856108096C00@stntexmb12.cis.neustar.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: "volkerh@bell-labs.com" , "sip-overload@ietf.org" , "hgs@cs.columbia.edu" Subject: Re: [sip-overload] draft-ietf-soc-overload-control-13 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, 22 Jul 2013 19:39:16 -0000 James: This is a quick ack of your email. It is on my list of things to do. I will circle back on it sometimes next week. Cheers, On 07/22/2013 02:18 PM, Yu, James wrote: > Hi, Henning, Vijay, Volker, > > When I reviewed draft-ietf-soc-overload-rate-control-04.txt, I glanced > through the syntax in this I-D to understand the oc related parameters. > > When looking at “algo-list”, I wonder if there are two “other-algo” such > as “abc” and “xyz”, ‘abc” and “xyz” won’t be comma-separated based on > the oc-algo syntax. It seems that algo-list would be > > algo-list = “loss“/ other-algo > > This would ensure that one and only one algorithm is present in > algo-list. If there is no algorithm other than “loss”, *(COMMA > algo-list) would take care of that. > > Since algo-list contains a single algorithm, may be it is better to use > “algo” only. Or if algo-list contains a list of comma separated > algorithms, then alog-list and oc-algo can be modified so that oc-algo > has a single “algo-list”. The latter may be better because the current > syntax would allow the same algorithm to appear more than once. - 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/ | Calendar: http://goo.gl/x3Ogq From jgunn6@csc.com Mon Jul 22 12:53:57 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 C88C611E811F; Mon, 22 Jul 2013 12:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTbHo1LvawxC; Mon, 22 Jul 2013 12:53:53 -0700 (PDT) Received: from mail86.messagelabs.com (mail86.messagelabs.com [216.82.242.179]) by ietfa.amsl.com (Postfix) with ESMTP id A608A11E8112; Mon, 22 Jul 2013 12:53:52 -0700 (PDT) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-5.tower-86.messagelabs.com!1374522830!32873839!1 X-Originating-IP: [20.137.2.88] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30167 invoked from network); 22 Jul 2013 19:53:50 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-5.tower-86.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Jul 2013 19:53:50 -0000 Received: from amer-gw09.amer.csc.com (cscmail.csc.com [20.6.39.245]) by amer-mta102.csc.com (8.13.8/8.13.8) with ESMTP id r6MJq27c022848; Mon, 22 Jul 2013 15:52:02 -0400 In-Reply-To: <56FB15AFE08E1242B0736CBDCE6E856108096C00@stntexmb12.cis.neustar.com> References: <56FB15AFE08E1242B0736CBDCE6E85610808C32F@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610808EF90@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E856108096C00@stntexmb12.cis.neustar.com> To: "Yu, James" MIME-Version: 1.0 X-KeepSent: 1E1E4629:9430E707-85257BB0:006CEB61; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Mon, 22 Jul 2013 15:53:45 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 07/22/2013 03:47:28 PM, Serialize complete at 07/22/2013 03:47:28 PM Content-Type: multipart/alternative; boundary="=_alternative 006D56E685257BB0_=" Cc: sip-overload-bounces@ietf.org, "volkerh@bell-labs.com" , "vkg@bell-labs.com" , "sip-overload@ietf.org" , "hgs@cs.columbia.edu" Subject: Re: [sip-overload] draft-ietf-soc-overload-control-13 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, 22 Jul 2013 19:53:58 -0000 This is a multipart message in MIME format. --=_alternative 006D56E685257BB0_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 VGhlcmUgaXMgYXQgbGVhc3Qgb25lICJvdGhlci1hbGdvIiwgInJhdGUiLg0KDQpXaGVuIGFsZ28t bGlzdCBpcyBpbmNsdWRlZCBpbiB0aGUgVmlhIGhlYWRlcnMgb2YgYSBtZXNzYWdlIHNlbnQgYnkg dGhlIA0KY2xpZW50IHRvIHRoZSBzZXJ2ZXIsIGl0IG1heSBoYXZlIG11bHRpcGxlIGFsZ29yaXRo bXMgaW5jbHVkZWQgaW4gdGhlIA0KYWxnby1saXN0IC0gYWxsIHRoZSBhbGdvcml0aG1zIHN1cHBv cnRlZCBieSB0aGUgY2xpZW50Lg0KDQpXaGVuIGFsZ28tbGlzdCBpcyBpbmNsdWRlZCBpbiB0aGUg VmlhIGhlYWRlcnMgc2VudCBmcm9tIHRoZSBzZXJ2ZXIgdG8gdGhlIA0KY2xpZW50LCBpdCBzaG91 bGQgaGF2ZSAiIG9uZSBhbmQgb25seSBvbmUgYWxnb3JpdGhtIiBpbiB0aGUgbGlzdC4NCg0KSmFu ZXQNCg0KDQoNCg0KDQpGcm9tOiAgICJZdSwgSmFtZXMiIDxqYW1lcy55dUBuZXVzdGFyLmJpej4N ClRvOiAgICAgImhnc0Bjcy5jb2x1bWJpYS5lZHUiIDxoZ3NAY3MuY29sdW1iaWEuZWR1PiwgInZr Z0BiZWxsLWxhYnMuY29tIiANCjx2a2dAYmVsbC1sYWJzLmNvbT4sICJ2b2xrZXJoQGJlbGwtbGFi cy5jb20iIDx2b2xrZXJoQGJlbGwtbGFicy5jb20+DQpDYzogICAgICJzaXAtb3ZlcmxvYWQtYm91 bmNlc0BpZXRmLm9yZyIgPHNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPiwgDQoic2lwLW92 ZXJsb2FkQGlldGYub3JnIiA8c2lwLW92ZXJsb2FkQGlldGYub3JnPg0KRGF0ZTogICAwNy8yMi8y MDEzIDAzOjE5IFBNDQpTdWJqZWN0OiAgICAgICAgW3NpcC1vdmVybG9hZF0gIGRyYWZ0LWlldGYt c29jLW92ZXJsb2FkLWNvbnRyb2wtMTMNClNlbnQgYnk6ICAgICAgICBzaXAtb3ZlcmxvYWQtYm91 bmNlc0BpZXRmLm9yZw0KDQoNCg0KSGksIEhlbm5pbmcsIFZpamF5LCBWb2xrZXIsDQogDQpXaGVu IEkgcmV2aWV3ZWQgZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLTA0LnR4dCwg SSBnbGFuY2VkIA0KdGhyb3VnaCB0aGUgc3ludGF4IGluIHRoaXMgSS1EIHRvIHVuZGVyc3RhbmQg dGhlIG9jIHJlbGF0ZWQgcGFyYW1ldGVycy4NCiANCldoZW4gbG9va2luZyBhdCDigJxhbGdvLWxp c3TigJ0sIEkgd29uZGVyIGlmIHRoZXJlIGFyZSB0d28g4oCcb3RoZXItYWxnb+KAnSBzdWNoIA0K YXMg4oCcYWJj4oCdIGFuZCDigJx4eXrigJ0sIOKAmGFiY+KAnSBhbmQg4oCceHl64oCdIHdvbuKA mXQgYmUgY29tbWEtc2VwYXJhdGVkIGJhc2VkIG9uIHRoZSANCm9jLWFsZ28gc3ludGF4LiAgSXQg c2VlbXMgdGhhdCBhbGdvLWxpc3Qgd291bGQgYmUgDQogDQogYWxnby1saXN0ID0g4oCcbG9zc+KA nCAvIG90aGVyLWFsZ28NCiANClRoaXMgd291bGQgZW5zdXJlIHRoYXQgb25lIGFuZCBvbmx5IG9u ZSBhbGdvcml0aG0gaXMgcHJlc2VudCBpbiBhbGdvLWxpc3QuIA0KIElmIHRoZXJlIGlzIG5vIGFs Z29yaXRobSBvdGhlciB0aGFuIOKAnGxvc3PigJ0sICooQ09NTUEgYWxnby1saXN0KSB3b3VsZCB0 YWtlIA0KY2FyZSBvZiB0aGF0Lg0KIA0KU2luY2UgYWxnby1saXN0IGNvbnRhaW5zIGEgc2luZ2xl IGFsZ29yaXRobSwgbWF5IGJlIGl0IGlzIGJldHRlciB0byB1c2UgDQrigJxhbGdv4oCdIG9ubHku ICBPciBpZiBhbGdvLWxpc3QgY29udGFpbnMgYSBsaXN0IG9mIGNvbW1hIHNlcGFyYXRlZCANCmFs Z29yaXRobXMsIHRoZW4gYWxvZy1saXN0IGFuZCBvYy1hbGdvIGNhbiBiZSBtb2RpZmllZCBzbyB0 aGF0IG9jLWFsZ28gaGFzIA0KYSBzaW5nbGUg4oCcYWxnby1saXN04oCdLiAgVGhlIGxhdHRlciBt YXkgYmUgYmV0dGVyIGJlY2F1c2UgdGhlIGN1cnJlbnQgc3ludGF4IA0Kd291bGQgYWxsb3cgdGhl IHNhbWUgYWxnb3JpdGhtIHRvIGFwcGVhciBtb3JlIHRoYW4gb25jZS4NCiANCkphbWVzX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpcC1vdmVybG9hZCBt YWlsaW5nIGxpc3QNCnNpcC1vdmVybG9hZEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zaXAtb3ZlcmxvYWQNCg0KDQo= --=_alternative 006D56E685257BB0_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZXJlIGlzIGF0IGxlYXN0IG9uZSAmcXVv dDtvdGhlci1hbGdvJnF1b3Q7LA0KJnF1b3Q7cmF0ZSZxdW90Oy48L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPldoZW4gYWxnby1saXN0IGlzIGluY2x1ZGVk IGluIHRoZSBWaWENCmhlYWRlcnMgb2YgYSBtZXNzYWdlIHNlbnQgYnkgdGhlIGNsaWVudCB0byB0 aGUgc2VydmVyLCBpdCBtYXkgaGF2ZSBtdWx0aXBsZQ0KYWxnb3JpdGhtcyBpbmNsdWRlZCBpbiB0 aGUgYWxnby1saXN0IC0gYWxsIHRoZSBhbGdvcml0aG1zIHN1cHBvcnRlZCBieQ0KdGhlIGNsaWVu dC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPldoZW4g YWxnby1saXN0IGlzIGluY2x1ZGVkIGluIHRoZSBWaWENCmhlYWRlcnMgc2VudCBmcm9tIHRoZSBz ZXJ2ZXIgdG8gdGhlIGNsaWVudCwgaXQgc2hvdWxkIGhhdmUgJnF1b3Q7PC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0Kb25lIGFuZCBvbmx5IG9uZSBhbGdvcml0aG08 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90Ow0KaW4gdGhlIGxpc3Qu PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5KYW5ldDxi cj4NCjxicj4NCjwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTEgY29s b3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5Gcm9tOiAmbmJzcDsgJm5ic3A7ICZuYnNwOw0K Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtZdSwgSmFt ZXMmcXVvdDsNCiZsdDtqYW1lcy55dUBuZXVzdGFyLmJpeiZndDs8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+VG86ICZuYnNwOyAmbmJzcDsg Jm5ic3A7DQombmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90 O2hnc0Bjcy5jb2x1bWJpYS5lZHUmcXVvdDsNCiZsdDtoZ3NAY3MuY29sdW1iaWEuZWR1Jmd0Oywg JnF1b3Q7dmtnQGJlbGwtbGFicy5jb20mcXVvdDsgJmx0O3ZrZ0BiZWxsLWxhYnMuY29tJmd0OywN CiZxdW90O3ZvbGtlcmhAYmVsbC1sYWJzLmNvbSZxdW90OyAmbHQ7dm9sa2VyaEBiZWxsLWxhYnMu Y29tJmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5z LXNlcmlmIj5DYzogJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOzwvZm9udD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmcm cXVvdDsNCiZsdDtzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZyZndDssICZxdW90O3NpcC1v dmVybG9hZEBpZXRmLm9yZyZxdW90Ow0KJmx0O3NpcC1vdmVybG9hZEBpZXRmLm9yZyZndDs8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+RGF0 ZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+MDcvMjIvMjAxMyAwMzoxOSBQTTwvZm9udD4NCjxicj48Zm9udCBzaXplPTEg Y29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5TdWJqZWN0OiAmbmJzcDsgJm5ic3A7DQom bmJzcDsgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5bc2lwLW92 ZXJsb2FkXQ0KJm5ic3A7ZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtY29udHJvbC0xMzwvZm9udD4N Cjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5TZW50IGJ5 OiAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj5zaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxicj4NCjxo ciBub3NoYWRlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPkhpLCBIZW5uaW5nLCBWaWpheSwgVm9sa2VyLDwvZm9udD4NCjxicj48Zm9udCBzaXpl PTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0z IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+V2hlbiBJIHJldmlld2VkIGRyYWZ0LWlldGYtc29jLW92 ZXJsb2FkLXJhdGUtY29udHJvbC0wNC50eHQsDQpJIGdsYW5jZWQgdGhyb3VnaCB0aGUgc3ludGF4 IGluIHRoaXMgSS1EIHRvIHVuZGVyc3RhbmQgdGhlIG9jIHJlbGF0ZWQgcGFyYW1ldGVycy48L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250 Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPldoZW4gbG9va2luZyBh dCDigJxhbGdvLWxpc3TigJ0sDQpJIHdvbmRlciBpZiB0aGVyZSBhcmUgdHdvIOKAnG90aGVyLWFs Z2/igJ0gc3VjaCBhcyDigJxhYmPigJ0gYW5kIOKAnHh5euKAnSwg4oCYYWJj4oCdDQphbmQg4oCc eHl64oCdIHdvbuKAmXQgYmUgY29tbWEtc2VwYXJhdGVkIGJhc2VkIG9uIHRoZSBvYy1hbGdvIHN5 bnRheC4gJm5ic3A7SXQNCnNlZW1zIHRoYXQgYWxnby1saXN0IHdvdWxkIGJlIDwvZm9udD4NCjxi cj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDthbGdvLWxpc3QgPSA8L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+4oCcPC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJDb3VyaWVyIE5ldyI+bG9zczwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj7igJw8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCi8g b3RoZXItYWxnbzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPiZu YnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5UaGlz IHdvdWxkIGVuc3VyZSB0aGF0IG9uZSBhbmQNCm9ubHkgb25lIGFsZ29yaXRobSBpcyBwcmVzZW50 IGluIGFsZ28tbGlzdC4gJm5ic3A7SWYgdGhlcmUgaXMgbm8gYWxnb3JpdGhtDQpvdGhlciB0aGFu IOKAnGxvc3PigJ0sICooQ09NTUEgYWxnby1saXN0KSB3b3VsZCB0YWtlIGNhcmUgb2YgdGhhdC48 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9m b250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPlNpbmNlIGFsZ28t bGlzdCBjb250YWlucyBhIHNpbmdsZQ0KYWxnb3JpdGhtLCBtYXkgYmUgaXQgaXMgYmV0dGVyIHRv IHVzZSDigJxhbGdv4oCdIG9ubHkuICZuYnNwO09yIGlmIGFsZ28tbGlzdA0KY29udGFpbnMgYSBs aXN0IG9mIGNvbW1hIHNlcGFyYXRlZCBhbGdvcml0aG1zLCB0aGVuIGFsb2ctbGlzdCBhbmQgb2Mt YWxnbw0KY2FuIGJlIG1vZGlmaWVkIHNvIHRoYXQgb2MtYWxnbyBoYXMgYSBzaW5nbGUg4oCcYWxn by1saXN04oCdLiAmbmJzcDtUaGUgbGF0dGVyDQptYXkgYmUgYmV0dGVyIGJlY2F1c2UgdGhlIGN1 cnJlbnQgc3ludGF4IHdvdWxkIGFsbG93IHRoZSBzYW1lIGFsZ29yaXRobQ0KdG8gYXBwZWFyIG1v cmUgdGhhbiBvbmNlLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+SmFtZXM8L2ZvbnQ+PHR0Pjxmb250IHNpemU9Mj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNpcC1vdmVybG9hZCBtYWlsaW5nIGxpc3Q8YnI+ DQpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmc8YnI+DQo8L2ZvbnQ+PC90dD48YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcC1vdmVybG9hZCI+PHR0Pjxmb250IHNp emU9Mj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcC1vdmVybG9hZDwv Zm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0K --=_alternative 006D56E685257BB0_=-- From james.yu@neustar.biz Mon Jul 22 13:12:15 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 442DD11E813B; Mon, 22 Jul 2013 13:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEyRZNzlDMyf; Mon, 22 Jul 2013 13:12:11 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 07FFC21F99F6; Mon, 22 Jul 2013 13:12:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1374524466; x=1689881303; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=4uIADAAK6E591YExg7Q/aI9xLI9s8ecXH969R0oN9gQ=; b=EkN+Od1PRfaoOgrrmmxCD0+PZ1t2XgMk9OMi5EJxKSLLpDrkHlRAExFYuo69Tq MYGY5X+T+GM5ypIaUr60/YJA== Received: from ([10.31.58.71]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.28476111; Mon, 22 Jul 2013 16:21:05 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Mon, 22 Jul 2013 16:11:54 -0400 From: "Yu, James" To: Janet P Gunn Thread-Topic: [sip-overload] draft-ietf-soc-overload-control-13 Thread-Index: AQHOhxUzabInufn/zEaEfjKV4MiTG5lxIB0g Date: Mon, 22 Jul 2013 20:11:54 +0000 Message-ID: <56FB15AFE08E1242B0736CBDCE6E856108096C3D@stntexmb12.cis.neustar.com> References: <56FB15AFE08E1242B0736CBDCE6E85610808C32F@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610808EF90@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E856108096C00@stntexmb12.cis.neustar.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.130.24] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: f4dPv10mDjE2HkOOn3LUPg== Content-Type: multipart/alternative; boundary="_000_56FB15AFE08E1242B0736CBDCE6E856108096C3Dstntexmb12cisne_" MIME-Version: 1.0 Cc: "sip-overload-bounces@ietf.org" , "volkerh@bell-labs.com" , "vkg@bell-labs.com" , "sip-overload@ietf.org" , "hgs@cs.columbia.edu" Subject: Re: [sip-overload] draft-ietf-soc-overload-control-13 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, 22 Jul 2013 20:12:15 -0000 --_000_56FB15AFE08E1242B0736CBDCE6E856108096C3Dstntexmb12cisne_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SmFuZXQsDQoNCk15IGNvbW1lbnQgaXMgbm90IG9uIGhhdmluZyBtdWx0aXBsZSBhbGdvcml0aG1z IGluIHRoZSB2aWEgaGVhZGVyIGJ1dCBvbiB0aGUgc3ludGF4IGluIHRoZSBjdXJyZW50IEktRCB0 aGF0IGNvdWxkIGFsbG93IG11bHRpcGxlIGFsZ29yaXRobXMgdGhhdCBhcmUgbm90IHNlcGFyYXRl ZCBieSDigJws4oCdLiAgUGxlYXNlIGNoZWNrIHRoZSBzeW50YXggYnkgaGF2aW5nIOKAnHJhdGXi gJ0gYW5kIOKAnGZvb+KAnS4NCg0KSmFtZXMNCg0KRnJvbTogSmFuZXQgUCBHdW5uIFttYWlsdG86 amd1bm42QGNzYy5jb21dDQpTZW50OiBNb25kYXksIEp1bHkgMjIsIDIwMTMgMzo1NCBQTQ0KVG86 IFl1LCBKYW1lcw0KQ2M6IGhnc0Bjcy5jb2x1bWJpYS5lZHU7IHZrZ0BiZWxsLWxhYnMuY29tOyB2 b2xrZXJoQGJlbGwtbGFicy5jb207IHNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnOyBzaXAt b3ZlcmxvYWRAaWV0Zi5vcmc7IHNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW3NpcC1vdmVybG9hZF0gZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtY29udHJvbC0xMw0K DQpUaGVyZSBpcyBhdCBsZWFzdCBvbmUgIm90aGVyLWFsZ28iLCAicmF0ZSIuDQoNCldoZW4gYWxn by1saXN0IGlzIGluY2x1ZGVkIGluIHRoZSBWaWEgaGVhZGVycyBvZiBhIG1lc3NhZ2Ugc2VudCBi eSB0aGUgY2xpZW50IHRvIHRoZSBzZXJ2ZXIsIGl0IG1heSBoYXZlIG11bHRpcGxlIGFsZ29yaXRo bXMgaW5jbHVkZWQgaW4gdGhlIGFsZ28tbGlzdCAtIGFsbCB0aGUgYWxnb3JpdGhtcyBzdXBwb3J0 ZWQgYnkgdGhlIGNsaWVudC4NCg0KV2hlbiBhbGdvLWxpc3QgaXMgaW5jbHVkZWQgaW4gdGhlIFZp YSBoZWFkZXJzIHNlbnQgZnJvbSB0aGUgc2VydmVyIHRvIHRoZSBjbGllbnQsIGl0IHNob3VsZCBo YXZlICIgb25lIGFuZCBvbmx5IG9uZSBhbGdvcml0aG0iIGluIHRoZSBsaXN0Lg0KDQpKYW5ldA0K DQoNCg0KDQoNCkZyb206ICAgICAgICAiWXUsIEphbWVzIiA8amFtZXMueXVAbmV1c3Rhci5iaXo8 bWFpbHRvOmphbWVzLnl1QG5ldXN0YXIuYml6Pj4NClRvOiAgICAgICAgImhnc0Bjcy5jb2x1bWJp YS5lZHU8bWFpbHRvOmhnc0Bjcy5jb2x1bWJpYS5lZHU+IiA8aGdzQGNzLmNvbHVtYmlhLmVkdTxt YWlsdG86aGdzQGNzLmNvbHVtYmlhLmVkdT4+LCAidmtnQGJlbGwtbGFicy5jb208bWFpbHRvOnZr Z0BiZWxsLWxhYnMuY29tPiIgPHZrZ0BiZWxsLWxhYnMuY29tPG1haWx0bzp2a2dAYmVsbC1sYWJz LmNvbT4+LCAidm9sa2VyaEBiZWxsLWxhYnMuY29tPG1haWx0bzp2b2xrZXJoQGJlbGwtbGFicy5j b20+IiA8dm9sa2VyaEBiZWxsLWxhYnMuY29tPG1haWx0bzp2b2xrZXJoQGJlbGwtbGFicy5jb20+ Pg0KQ2M6ICAgICAgICAic2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNpcC1v dmVybG9hZC1ib3VuY2VzQGlldGYub3JnPiIgPHNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZz4+LCAic2lwLW92ZXJsb2FkQGll dGYub3JnPG1haWx0bzpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmc+IiA8c2lwLW92ZXJsb2FkQGlldGYu b3JnPG1haWx0bzpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmc+Pg0KRGF0ZTogICAgICAgIDA3LzIyLzIw MTMgMDM6MTkgUE0NClN1YmplY3Q6ICAgICAgICBbc2lwLW92ZXJsb2FkXSAgZHJhZnQtaWV0Zi1z b2Mtb3ZlcmxvYWQtY29udHJvbC0xMw0KU2VudCBieTogICAgICAgIHNpcC1vdmVybG9hZC1ib3Vu Y2VzQGlldGYub3JnPG1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZz4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0KDQpIaSwgSGVubmluZywgVmlqYXksIFZv bGtlciwNCg0KV2hlbiBJIHJldmlld2VkIGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLXJhdGUtY29u dHJvbC0wNC50eHQsIEkgZ2xhbmNlZCB0aHJvdWdoIHRoZSBzeW50YXggaW4gdGhpcyBJLUQgdG8g dW5kZXJzdGFuZCB0aGUgb2MgcmVsYXRlZCBwYXJhbWV0ZXJzLg0KDQpXaGVuIGxvb2tpbmcgYXQg 4oCcYWxnby1saXN04oCdLCBJIHdvbmRlciBpZiB0aGVyZSBhcmUgdHdvIOKAnG90aGVyLWFsZ2/i gJ0gc3VjaCBhcyDigJxhYmPigJ0gYW5kIOKAnHh5euKAnSwg4oCYYWJj4oCdIGFuZCDigJx4eXri gJ0gd29u4oCZdCBiZSBjb21tYS1zZXBhcmF0ZWQgYmFzZWQgb24gdGhlIG9jLWFsZ28gc3ludGF4 LiAgSXQgc2VlbXMgdGhhdCBhbGdvLWxpc3Qgd291bGQgYmUNCg0KIGFsZ28tbGlzdCA9IOKAnGxv c3PigJwgLyBvdGhlci1hbGdvDQoNClRoaXMgd291bGQgZW5zdXJlIHRoYXQgb25lIGFuZCBvbmx5 IG9uZSBhbGdvcml0aG0gaXMgcHJlc2VudCBpbiBhbGdvLWxpc3QuICBJZiB0aGVyZSBpcyBubyBh bGdvcml0aG0gb3RoZXIgdGhhbiDigJxsb3Nz4oCdLCAqKENPTU1BIGFsZ28tbGlzdCkgd291bGQg dGFrZSBjYXJlIG9mIHRoYXQuDQoNClNpbmNlIGFsZ28tbGlzdCBjb250YWlucyBhIHNpbmdsZSBh bGdvcml0aG0sIG1heSBiZSBpdCBpcyBiZXR0ZXIgdG8gdXNlIOKAnGFsZ2/igJ0gb25seS4gIE9y IGlmIGFsZ28tbGlzdCBjb250YWlucyBhIGxpc3Qgb2YgY29tbWEgc2VwYXJhdGVkIGFsZ29yaXRo bXMsIHRoZW4gYWxvZy1saXN0IGFuZCBvYy1hbGdvIGNhbiBiZSBtb2RpZmllZCBzbyB0aGF0IG9j LWFsZ28gaGFzIGEgc2luZ2xlIOKAnGFsZ28tbGlzdOKAnS4gIFRoZSBsYXR0ZXIgbWF5IGJlIGJl dHRlciBiZWNhdXNlIHRoZSBjdXJyZW50IHN5bnRheCB3b3VsZCBhbGxvdyB0aGUgc2FtZSBhbGdv cml0aG0gdG8gYXBwZWFyIG1vcmUgdGhhbiBvbmNlLg0KDQpKYW1lc19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzaXAtb3ZlcmxvYWQgbWFpbGluZyBsaXN0 DQpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmc8bWFpbHRvOnNpcC1vdmVybG9hZEBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwLW92ZXJsb2FkDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KTm8gdmlydXMgZm91bmQgaW4gdGhpcyBtZXNzYWdl Lg0KQ2hlY2tlZCBieSBBVkcgLSB3d3cuYXZnLmNvbTxodHRwOi8vd3d3LmF2Zy5jb20+DQpWZXJz aW9uOiAyMDEzLjAuMjkwNCAvIFZpcnVzIERhdGFiYXNlOiAzMjA0LzY1MTAgLSBSZWxlYXNlIERh dGU6IDA3LzIyLzEzDQo= --_000_56FB15AFE08E1242B0736CBDCE6E856108096C3Dstntexmb12cisne_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQp0dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SmFuZXQsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5NeSBjb21tZW50IGlzIG5vdCBvbiBoYXZpbmcgbXVsdGlwbGUgYWxnb3JpdGhtcyBpbiB0aGUg dmlhIGhlYWRlciBidXQgb24gdGhlIHN5bnRheCBpbiB0aGUgY3VycmVudCBJLUQgdGhhdCBjb3Vs ZCBhbGxvdyBtdWx0aXBsZSBhbGdvcml0aG1zIHRoYXQgYXJlIG5vdCBzZXBhcmF0ZWQNCiBieSDi gJws4oCdLiZuYnNwOyBQbGVhc2UgY2hlY2sgdGhlIHN5bnRheCBieSBoYXZpbmcg4oCccmF0ZeKA nSBhbmQg4oCcZm9v4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SmFtZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEphbmV0IFAgR3Vu biBbbWFpbHRvOmpndW5uNkBjc2MuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgSnVs eSAyMiwgMjAxMyAzOjU0IFBNPGJyPg0KPGI+VG86PC9iPiBZdSwgSmFtZXM8YnI+DQo8Yj5DYzo8 L2I+IGhnc0Bjcy5jb2x1bWJpYS5lZHU7IHZrZ0BiZWxsLWxhYnMuY29tOyB2b2xrZXJoQGJlbGwt bGFicy5jb207IHNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnOyBzaXAtb3ZlcmxvYWRAaWV0 Zi5vcmc7IHNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbc2lwLW92ZXJsb2FkXSBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1jb250cm9sLTEzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPlRoZXJlIGlzIGF0IGxlYXN0IG9uZSAmcXVvdDtvdGhlci1hbGdvJnF1b3Q7LCAmcXVv dDtyYXRlJnF1b3Q7Ljwvc3Bhbj4NCjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPldoZW4gYWxnby1saXN0IGlzIGluY2x1ZGVkIGluIHRoZSBWaWEgaGVhZGVycyBvZiBhIG1l c3NhZ2Ugc2VudCBieSB0aGUgY2xpZW50IHRvIHRoZSBzZXJ2ZXIsIGl0IG1heSBoYXZlIG11bHRp cGxlIGFsZ29yaXRobXMgaW5jbHVkZWQgaW4gdGhlIGFsZ28tbGlzdCAtIGFsbCB0aGUgYWxnb3Jp dGhtcyBzdXBwb3J0ZWQgYnkgdGhlIGNsaWVudC48L3NwYW4+DQo8YnI+DQo8YnI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5XaGVuIGFsZ28tbGlzdCBpcyBpbmNsdWRlZCBpbiB0aGUgVmlh IGhlYWRlcnMgc2VudCBmcm9tIHRoZSBzZXJ2ZXIgdG8gdGhlIGNsaWVudCwgaXQgc2hvdWxkIGhh dmUgJnF1b3Q7PC9zcGFuPiBvbmUgYW5kIG9ubHkgb25lIGFsZ29yaXRobTxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiZxdW90Ow0KIGluIHRoZSBsaXN0Ljwvc3Bhbj4gPGJyPg0KPGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SmFuZXQ8YnI+DQo8YnI+DQo8L3NwYW4+PGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1RjVGNUYiPkZy b206ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiZxdW90O1l1LCBKYW1lcyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmphbWVzLnl1 QG5ldXN0YXIuYml6Ij5qYW1lcy55dUBuZXVzdGFyLmJpejwvYT4mZ3Q7PC9zcGFuPg0KPGJyPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1RjVGNUYiPlRvOiAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mcXVvdDs8YSBo cmVmPSJtYWlsdG86aGdzQGNzLmNvbHVtYmlhLmVkdSI+aGdzQGNzLmNvbHVtYmlhLmVkdTwvYT4m cXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpoZ3NAY3MuY29sdW1iaWEuZWR1Ij5oZ3NAY3MuY29s dW1iaWEuZWR1PC9hPiZndDssDQogJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnZrZ0BiZWxsLWxhYnMu Y29tIj52a2dAYmVsbC1sYWJzLmNvbTwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp2a2dA YmVsbC1sYWJzLmNvbSI+dmtnQGJlbGwtbGFicy5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0i bWFpbHRvOnZvbGtlcmhAYmVsbC1sYWJzLmNvbSI+dm9sa2VyaEBiZWxsLWxhYnMuY29tPC9hPiZx dW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZvbGtlcmhAYmVsbC1sYWJzLmNvbSI+dm9sa2VyaEBi ZWxsLWxhYnMuY29tPC9hPiZndDs8L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzVGNUY1RiI+Q2M6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZxdW90OzxhIGhyZWY9Im1haWx0bzpzaXAtb3Zlcmxv YWQtYm91bmNlc0BpZXRmLm9yZyI+c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+JnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmciPnNp cC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDssDQogJnF1b3Q7PGEgaHJlZj0ibWFp bHRvOnNpcC1vdmVybG9hZEBpZXRmLm9yZyI+c2lwLW92ZXJsb2FkQGlldGYub3JnPC9hPiZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZEBpZXRmLm9yZyI+c2lwLW92ZXJsb2Fk QGlldGYub3JnPC9hPiZndDs8L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjcu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzVGNUY1RiI+RGF0ZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+MDcvMjIvMjAxMyAwMzoxOSBQTTwvc3Bhbj4NCjxicj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNUY1RjVGIj5TdWJqZWN0OiAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5bc2lw LW92ZXJsb2FkXSAmbmJzcDtkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1jb250cm9sLTEzPC9zcGFu Pg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1RjVGNUYiPlNlbnQgYnk6 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPjxhIGhyZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZyI+c2lwLW92 ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+PC9zcGFuPg0KPG86cD48L286cD48L3A+DQo8ZGl2 IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRl ciI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIG5vc2hhZGU9IiIgc3R5bGU9ImNvbG9yOiNB MEEwQTAiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxicj4NCjxicj4NCkhpLCBIZW5uaW5nLCBW aWpheSwgVm9sa2VyLCA8YnI+DQombmJzcDsgPGJyPg0KV2hlbiBJIHJldmlld2VkIGRyYWZ0LWll dGYtc29jLW92ZXJsb2FkLXJhdGUtY29udHJvbC0wNC50eHQsIEkgZ2xhbmNlZCB0aHJvdWdoIHRo ZSBzeW50YXggaW4gdGhpcyBJLUQgdG8gdW5kZXJzdGFuZCB0aGUgb2MgcmVsYXRlZCBwYXJhbWV0 ZXJzLg0KPGJyPg0KJm5ic3A7IDxicj4NCldoZW4gbG9va2luZyBhdCDigJxhbGdvLWxpc3TigJ0s IEkgd29uZGVyIGlmIHRoZXJlIGFyZSB0d28g4oCcb3RoZXItYWxnb+KAnSBzdWNoIGFzIOKAnGFi Y+KAnSBhbmQg4oCceHl64oCdLCDigJhhYmPigJ0gYW5kIOKAnHh5euKAnSB3b27igJl0IGJlIGNv bW1hLXNlcGFyYXRlZCBiYXNlZCBvbiB0aGUgb2MtYWxnbyBzeW50YXguICZuYnNwO0l0IHNlZW1z IHRoYXQgYWxnby1saXN0IHdvdWxkIGJlDQo8YnI+DQombmJzcDsgPGJyPg0KPHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDthbGdvLWxpc3QgPSA8 L3NwYW4+4oCcPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij5sb3NzPC9zcGFuPuKAnDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+IC8gb3RoZXItYWxnbzwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPiA8YnI+DQpUaGlzIHdv dWxkIGVuc3VyZSB0aGF0IG9uZSBhbmQgb25seSBvbmUgYWxnb3JpdGhtIGlzIHByZXNlbnQgaW4g YWxnby1saXN0LiAmbmJzcDtJZiB0aGVyZSBpcyBubyBhbGdvcml0aG0gb3RoZXIgdGhhbiDigJxs b3Nz4oCdLCAqKENPTU1BIGFsZ28tbGlzdCkgd291bGQgdGFrZSBjYXJlIG9mIHRoYXQuDQo8YnI+ DQombmJzcDsgPGJyPg0KU2luY2UgYWxnby1saXN0IGNvbnRhaW5zIGEgc2luZ2xlIGFsZ29yaXRo bSwgbWF5IGJlIGl0IGlzIGJldHRlciB0byB1c2Ug4oCcYWxnb+KAnSBvbmx5LiAmbmJzcDtPciBp ZiBhbGdvLWxpc3QgY29udGFpbnMgYSBsaXN0IG9mIGNvbW1hIHNlcGFyYXRlZCBhbGdvcml0aG1z LCB0aGVuIGFsb2ctbGlzdCBhbmQgb2MtYWxnbyBjYW4gYmUgbW9kaWZpZWQgc28gdGhhdCBvYy1h bGdvIGhhcyBhIHNpbmdsZSDigJxhbGdvLWxpc3TigJ0uICZuYnNwO1RoZSBsYXR0ZXIgbWF5IGJl IGJldHRlcg0KIGJlY2F1c2UgdGhlIGN1cnJlbnQgc3ludGF4IHdvdWxkIGFsbG93IHRoZSBzYW1l IGFsZ29yaXRobSB0byBhcHBlYXIgbW9yZSB0aGFuIG9uY2UuDQo8YnI+DQombmJzcDsgPGJyPg0K SmFtZXM8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4N Cjx0dD5zaXAtb3ZlcmxvYWQgbWFpbGluZyBsaXN0PC90dD48YnI+DQo8dHQ+PGEgaHJlZj0ibWFp bHRvOnNpcC1vdmVybG9hZEBpZXRmLm9yZyI+c2lwLW92ZXJsb2FkQGlldGYub3JnPC9hPjwvdHQ+ PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2lwLW92ZXJsb2FkIj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwLW92ZXJsb2FkPC9zcGFuPjwvdHQ+ PC9hPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVy IiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjEiIHdpZHRoPSIxMDAlIiBu b3NoYWRlPSIiIHN0eWxlPSJjb2xvcjojQTBBMEEwIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5ObyB2aXJ1cyBmb3VuZCBpbiB0aGlzIG1lc3NhZ2UuPGJy Pg0KQ2hlY2tlZCBieSBBVkcgLSA8YSBocmVmPSJodHRwOi8vd3d3LmF2Zy5jb20iPnd3dy5hdmcu Y29tPC9hPjxicj4NClZlcnNpb246IDIwMTMuMC4yOTA0IC8gVmlydXMgRGF0YWJhc2U6IDMyMDQv NjUxMCAtIFJlbGVhc2UgRGF0ZTogMDcvMjIvMTM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_56FB15AFE08E1242B0736CBDCE6E856108096C3Dstntexmb12cisne_-- From christer.holmberg@ericsson.com Mon Jul 22 20:54: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 7C9AF11E81D5; Mon, 22 Jul 2013 20:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 282wA7MmVgA8; Mon, 22 Jul 2013 20:54:49 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id D5A6111E8183; Mon, 22 Jul 2013 20:54:46 -0700 (PDT) X-AuditID: c1b4fb2d-b7f0b6d0000002d5-fa-51edfe84dd3a Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id F2.4E.00725.48EFDE15; Tue, 23 Jul 2013 05:54:45 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0328.009; Tue, 23 Jul 2013 05:54:44 +0200 From: Christer Holmberg To: "Yu, James" , Janet P Gunn Thread-Topic: [sip-overload] draft-ietf-soc-overload-control-13 Thread-Index: AQHOhxU3F7sJun9uH0SBY0IRumtD5plw/7kAgACg/lA= Date: Tue, 23 Jul 2013 03:54:44 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3FC99D@ESESSMB209.ericsson.se> References: <56FB15AFE08E1242B0736CBDCE6E85610808C32F@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610808EF90@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E856108096C00@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E856108096C3D@stntexmb12.cis.neustar.com> In-Reply-To: <56FB15AFE08E1242B0736CBDCE6E856108096C3D@stntexmb12.cis.neustar.com> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C3FC99DESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGfG3Vrf139tAg4eHGS2u9K1kslg0LcTi 3MMvrBbtF7eyWux/mmDRsEbOYtPyW+wO7B59l108vt46yORx8XqUx5IlP5k8djQ8Zw5gjeKy SUnNySxLLdK3S+DKWHF4K0vBvquMFTuWTGBtYHxznrGLkZNDQsBEonHlXShbTOLCvfVsXYxc HEIChxklpn9+DOUsYZS4NH0ZSxcjBwebgIVE9z9tEFNEwFVi3jYLkBJmgUYmifan19lABgkL 2EnMfzoZbKiIgL3Eu+bXLBC2lcTxfxvYQHpZBFQl7nx0AQnzCvhK7GuaArVqK7PE3eu/wFZx CgRJLFsENpIR6Lbvp9YwgdjMAuISHw5eZ4a4WUBiyZ7zULaoxMvH/1ghbCWJHxsugY1hFsiX eLRQFWKVoMTJmU9YJjCKzkIyaRZC1SwkVRBhTYn1u/QhqhUlpnQ/ZIewNSRa58xlRxZfwMi+ ipE9NzEzJ73ccBMjMCoPbvmtu4Px1DmRQ4zSHCxK4ryb9M4ECgmkJ5akZqemFqQWxReV5qQW H2Jk4uCUamA0Xen0Q2Tt3tw5J930w2YI3NxdK5K45kDo0j0nL20W17xX8kn4xKRJ0dKMnAo1 7666H33EnrLo8Nb5rQJ2C1iKd2x46cPT3sPe8qWb9ybH8eiP/31/HPjPx7k5Zf29XdITf89b Kdv5+fzLyYc/HLlecSWRx3KT+8JMOR85W7VMpaq8yCL9QP7TSizFGYmGWsxFxYkAvIIhdZgC AAA= Cc: "sip-overload-bounces@ietf.org" , "volkerh@bell-labs.com" , "vkg@bell-labs.com" , "sip-overload@ietf.org" , "hgs@cs.columbia.edu" Subject: Re: [sip-overload] draft-ietf-soc-overload-control-13 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, 23 Jul 2013 03:54:53 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C3FC99DESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgZG9u4oCZdCB0aGluayB0aGUgY3VycmVudCBBQk5GIGFsbG93cyBhIGxpc3Qgd2l0 aG91dCBjb21tYSBzZXBhcmF0aW9uLiBLZWVwIGluIG1pbmQgdGhhdCDigJxhbGdvLWxpc3TigJ0g ZG9lcyBub3QgcmVwcmVzZW50IHRoZSBsaXN0LCBvbmx5IGEgc2luZ2xlIHZhbHVlIGluIHRoZSBs aXN0Lg0KDQpCdXQsIEkgdW5kZXJzdGFuZCB5b3VyIGNvbmZ1c2lvbiwgYW5kIGluIGZhY3QgSSB0 aGluayDigJ1hbGdvLWxpc3TigJ0gaXMgYSBsaXR0bGUgbWlzbGVhZGluZy4gSSB0aGluayBpdCB3 b3VsZCBiZSBiZXR0ZXIgdG8gY2FsbCBpdCDigJxhbGdvLXZhbHVl4oCdLCBvciBzb21ldGhpbmcg c2ltaWxhci4NCg0Kb2MtYWxnbyAgICAgPSAib2MtYWxnbyIgRVFVQUwgRFFVT1RFIGFsZ28tdmFs dWUgKihDT01NQSBhbGdvLXZhbHVlKURRVU9URQ0KYWxnby12YWx1ZSAgID0gImxvc3MiIC8gKihv dGhlci1hbGdvKQ0Kb3RoZXItYWxnbyAgPSAleDQxLTVBIC8gJXg2MS03QSAvICV4MzAtMzkNCg0K UmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCkzDpGhldHTDpGrDpDogc2lwLW92ZXJsb2FkLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZ10gUHVv bGVzdGEgWXUsIEphbWVzDQpMw6RoZXRldHR5OiAyMi4gaGVpbsOka3V1dGEgMjAxMyAyMzoxMg0K VmFzdGFhbm90dGFqYTogSmFuZXQgUCBHdW5uDQpLb3Bpbzogc2lwLW92ZXJsb2FkLWJvdW5jZXNA aWV0Zi5vcmc7IHZvbGtlcmhAYmVsbC1sYWJzLmNvbTsgdmtnQGJlbGwtbGFicy5jb207IHNpcC1v dmVybG9hZEBpZXRmLm9yZzsgaGdzQGNzLmNvbHVtYmlhLmVkdQ0KQWloZTogUmU6IFtzaXAtb3Zl cmxvYWRdIGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLWNvbnRyb2wtMTMNCg0KSmFuZXQsDQoNCk15 IGNvbW1lbnQgaXMgbm90IG9uIGhhdmluZyBtdWx0aXBsZSBhbGdvcml0aG1zIGluIHRoZSB2aWEg aGVhZGVyIGJ1dCBvbiB0aGUgc3ludGF4IGluIHRoZSBjdXJyZW50IEktRCB0aGF0IGNvdWxkIGFs bG93IG11bHRpcGxlIGFsZ29yaXRobXMgdGhhdCBhcmUgbm90IHNlcGFyYXRlZCBieSDigJws4oCd LiAgUGxlYXNlIGNoZWNrIHRoZSBzeW50YXggYnkgaGF2aW5nIOKAnHJhdGXigJ0gYW5kIOKAnGZv b+KAnS4NCg0KSmFtZXMNCg0KRnJvbTogSmFuZXQgUCBHdW5uIFttYWlsdG86amd1bm42QGNzYy5j b21dDQpTZW50OiBNb25kYXksIEp1bHkgMjIsIDIwMTMgMzo1NCBQTQ0KVG86IFl1LCBKYW1lcw0K Q2M6IGhnc0Bjcy5jb2x1bWJpYS5lZHU8bWFpbHRvOmhnc0Bjcy5jb2x1bWJpYS5lZHU+OyB2a2dA YmVsbC1sYWJzLmNvbTxtYWlsdG86dmtnQGJlbGwtbGFicy5jb20+OyB2b2xrZXJoQGJlbGwtbGFi cy5jb208bWFpbHRvOnZvbGtlcmhAYmVsbC1sYWJzLmNvbT47IHNpcC1vdmVybG9hZC1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZz47IHNpcC1vdmVy bG9hZEBpZXRmLm9yZzxtYWlsdG86c2lwLW92ZXJsb2FkQGlldGYub3JnPjsgc2lwLW92ZXJsb2Fk LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPg0K U3ViamVjdDogUmU6IFtzaXAtb3ZlcmxvYWRdIGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLWNvbnRy b2wtMTMNCg0KVGhlcmUgaXMgYXQgbGVhc3Qgb25lICJvdGhlci1hbGdvIiwgInJhdGUiLg0KDQpX aGVuIGFsZ28tbGlzdCBpcyBpbmNsdWRlZCBpbiB0aGUgVmlhIGhlYWRlcnMgb2YgYSBtZXNzYWdl IHNlbnQgYnkgdGhlIGNsaWVudCB0byB0aGUgc2VydmVyLCBpdCBtYXkgaGF2ZSBtdWx0aXBsZSBh bGdvcml0aG1zIGluY2x1ZGVkIGluIHRoZSBhbGdvLWxpc3QgLSBhbGwgdGhlIGFsZ29yaXRobXMg c3VwcG9ydGVkIGJ5IHRoZSBjbGllbnQuDQoNCldoZW4gYWxnby1saXN0IGlzIGluY2x1ZGVkIGlu IHRoZSBWaWEgaGVhZGVycyBzZW50IGZyb20gdGhlIHNlcnZlciB0byB0aGUgY2xpZW50LCBpdCBz aG91bGQgaGF2ZSAiIG9uZSBhbmQgb25seSBvbmUgYWxnb3JpdGhtIiBpbiB0aGUgbGlzdC4NCg0K SmFuZXQNCg0KDQoNCg0KDQpGcm9tOiAgICAgICAgIll1LCBKYW1lcyIgPGphbWVzLnl1QG5ldXN0 YXIuYml6PG1haWx0bzpqYW1lcy55dUBuZXVzdGFyLmJpej4+DQpUbzogICAgICAgICJoZ3NAY3Mu Y29sdW1iaWEuZWR1PG1haWx0bzpoZ3NAY3MuY29sdW1iaWEuZWR1PiIgPGhnc0Bjcy5jb2x1bWJp YS5lZHU8bWFpbHRvOmhnc0Bjcy5jb2x1bWJpYS5lZHU+PiwgInZrZ0BiZWxsLWxhYnMuY29tPG1h aWx0bzp2a2dAYmVsbC1sYWJzLmNvbT4iIDx2a2dAYmVsbC1sYWJzLmNvbTxtYWlsdG86dmtnQGJl bGwtbGFicy5jb20+PiwgInZvbGtlcmhAYmVsbC1sYWJzLmNvbTxtYWlsdG86dm9sa2VyaEBiZWxs LWxhYnMuY29tPiIgPHZvbGtlcmhAYmVsbC1sYWJzLmNvbTxtYWlsdG86dm9sa2VyaEBiZWxsLWxh YnMuY29tPj4NCkNjOiAgICAgICAgInNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPG1haWx0 bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZz4iIDxzaXAtb3ZlcmxvYWQtYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc+PiwgInNpcC1vdmVy bG9hZEBpZXRmLm9yZzxtYWlsdG86c2lwLW92ZXJsb2FkQGlldGYub3JnPiIgPHNpcC1vdmVybG9h ZEBpZXRmLm9yZzxtYWlsdG86c2lwLW92ZXJsb2FkQGlldGYub3JnPj4NCkRhdGU6ICAgICAgICAw Ny8yMi8yMDEzIDAzOjE5IFBNDQpTdWJqZWN0OiAgICAgICAgW3NpcC1vdmVybG9hZF0gIGRyYWZ0 LWlldGYtc29jLW92ZXJsb2FkLWNvbnRyb2wtMTMNClNlbnQgYnk6ICAgICAgICBzaXAtb3Zlcmxv YWQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCg0KSGksIEhlbm5pbmcsIFZp amF5LCBWb2xrZXIsDQoNCldoZW4gSSByZXZpZXdlZCBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1y YXRlLWNvbnRyb2wtMDQudHh0LCBJIGdsYW5jZWQgdGhyb3VnaCB0aGUgc3ludGF4IGluIHRoaXMg SS1EIHRvIHVuZGVyc3RhbmQgdGhlIG9jIHJlbGF0ZWQgcGFyYW1ldGVycy4NCg0KV2hlbiBsb29r aW5nIGF0IOKAnGFsZ28tbGlzdOKAnSwgSSB3b25kZXIgaWYgdGhlcmUgYXJlIHR3byDigJxvdGhl ci1hbGdv4oCdIHN1Y2ggYXMg4oCcYWJj4oCdIGFuZCDigJx4eXrigJ0sIOKAmGFiY+KAnSBhbmQg 4oCceHl64oCdIHdvbuKAmXQgYmUgY29tbWEtc2VwYXJhdGVkIGJhc2VkIG9uIHRoZSBvYy1hbGdv IHN5bnRheC4gIEl0IHNlZW1zIHRoYXQgYWxnby1saXN0IHdvdWxkIGJlDQoNCiBhbGdvLWxpc3Qg PSDigJxsb3Nz4oCcIC8gb3RoZXItYWxnbw0KDQpUaGlzIHdvdWxkIGVuc3VyZSB0aGF0IG9uZSBh bmQgb25seSBvbmUgYWxnb3JpdGhtIGlzIHByZXNlbnQgaW4gYWxnby1saXN0LiAgSWYgdGhlcmUg aXMgbm8gYWxnb3JpdGhtIG90aGVyIHRoYW4g4oCcbG9zc+KAnSwgKihDT01NQSBhbGdvLWxpc3Qp IHdvdWxkIHRha2UgY2FyZSBvZiB0aGF0Lg0KDQpTaW5jZSBhbGdvLWxpc3QgY29udGFpbnMgYSBz aW5nbGUgYWxnb3JpdGhtLCBtYXkgYmUgaXQgaXMgYmV0dGVyIHRvIHVzZSDigJxhbGdv4oCdIG9u bHkuICBPciBpZiBhbGdvLWxpc3QgY29udGFpbnMgYSBsaXN0IG9mIGNvbW1hIHNlcGFyYXRlZCBh bGdvcml0aG1zLCB0aGVuIGFsb2ctbGlzdCBhbmQgb2MtYWxnbyBjYW4gYmUgbW9kaWZpZWQgc28g dGhhdCBvYy1hbGdvIGhhcyBhIHNpbmdsZSDigJxhbGdvLWxpc3TigJ0uICBUaGUgbGF0dGVyIG1h eSBiZSBiZXR0ZXIgYmVjYXVzZSB0aGUgY3VycmVudCBzeW50YXggd291bGQgYWxsb3cgdGhlIHNh bWUgYWxnb3JpdGhtIHRvIGFwcGVhciBtb3JlIHRoYW4gb25jZS4NCg0KSmFtZXNfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2lwLW92ZXJsb2FkIG1haWxp bmcgbGlzdA0Kc2lwLW92ZXJsb2FkQGlldGYub3JnPG1haWx0bzpzaXAtb3ZlcmxvYWRAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcC1vdmVybG9hZA0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5vIHZpcnVzIGZvdW5kIGluIHRoaXMg bWVzc2FnZS4NCkNoZWNrZWQgYnkgQVZHIC0gd3d3LmF2Zy5jb208aHR0cDovL3d3dy5hdmcuY29t Pg0KVmVyc2lvbjogMjAxMy4wLjI5MDQgLyBWaXJ1cyBEYXRhYmFzZTogMzIwNC82NTEwIC0gUmVs ZWFzZSBEYXRlOiAwNy8yMi8xMw0K --_000_7594FB04B1934943A5C02806D1A2204B1C3FC99DESESSMB209erics_ 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 MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwtZXNpbXVvdG9pbHR1 IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQp0dA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUs IGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiU2VsaXRldGVrc3RpIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5TaGtwb3N0aXR5eWxpMTgNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCnNwYW4uU2hrcG9zdGl0eXlsaTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQpzcGFuLlNlbGl0ZXRla3N0aUNoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlNlbGl0 ZXRla3N0aSBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 U2VsaXRldGVrc3RpOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LkhUTUwtZXNpbXVvdG9pbHR1Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTC1lc2ltdW90b2ls dHUgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOkhUTUwt ZXNpbXVvdG9pbHR1Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBw dCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZJIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGksPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SSBkb27igJl0IHRoaW5rIHRoZSBjdXJyZW50IEFCTkYgYWxsb3dzIGEg bGlzdCB3aXRob3V0IGNvbW1hIHNlcGFyYXRpb24uIEtlZXAgaW4gbWluZCB0aGF0IOKAnGFsZ28t bGlzdOKAnSBkb2VzIG5vdCByZXByZXNlbnQgdGhlIGxpc3QsIG9ubHkgYSBzaW5nbGUNCiB2YWx1 ZSBpbiB0aGUgbGlzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QnV0LCBJ IHVuZGVyc3RhbmQgeW91ciBjb25mdXNpb24sIGFuZCBpbiBmYWN0IEkgdGhpbmsg4oCdYWxnby1s aXN04oCdIGlzIGEgbGl0dGxlIG1pc2xlYWRpbmcuIEkgdGhpbmsgaXQgd291bGQgYmUgYmV0dGVy IHRvIGNhbGwgaXQNCjxiPuKAnGFsZ28tdmFsdWXigJ08L2I+LCBvciBzb21ldGhpbmcgc2ltaWxh ci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+b2MtYWxnbyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA9ICZxdW90O29jLWFsZ28mcXVv dDsgRVFVQUwgRFFVT1RFIGFsZ28tdmFsdWUgKihDT01NQSBhbGdvLXZhbHVlKURRVU9URTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+YWxnby12YWx1ZSZuYnNwOyZuYnNwOyA9ICZxdW90O2xvc3MmcXVvdDsgLyAqKG90aGVy LWFsZ28pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij5vdGhlci1hbGdvJm5ic3A7ID0gJXg0MS01QSAvICV4NjEtN0EgLyAl eDMwLTM5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Mw6RoZXR0w6Rqw6Q6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+IHNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c2lwLW92ZXJs b2FkLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5QdW9sZXN0YSA8L2I+WXUsIEphbWVzPGJyPg0KPGI+ TMOkaGV0ZXR0eTo8L2I+IDIyLiBoZWluw6RrdXV0YSAyMDEzIDIzOjEyPGJyPg0KPGI+VmFzdGFh bm90dGFqYTo8L2I+IEphbmV0IFAgR3Vubjxicj4NCjxiPktvcGlvOjwvYj4gc2lwLW92ZXJsb2Fk LWJvdW5jZXNAaWV0Zi5vcmc7IHZvbGtlcmhAYmVsbC1sYWJzLmNvbTsgdmtnQGJlbGwtbGFicy5j b207IHNpcC1vdmVybG9hZEBpZXRmLm9yZzsgaGdzQGNzLmNvbHVtYmlhLmVkdTxicj4NCjxiPkFp aGU6PC9iPiBSZTogW3NpcC1vdmVybG9hZF0gZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtY29udHJv bC0xMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SmFuZXQs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk15IGNvbW1lbnQgaXMgbm90IG9u IGhhdmluZyBtdWx0aXBsZSBhbGdvcml0aG1zIGluIHRoZSB2aWEgaGVhZGVyIGJ1dCBvbiB0aGUg c3ludGF4IGluIHRoZSBjdXJyZW50IEktRCB0aGF0IGNvdWxkIGFsbG93IG11bHRpcGxlIGFsZ29y aXRobXMgdGhhdA0KIGFyZSBub3Qgc2VwYXJhdGVkIGJ5IOKAnCzigJ0uJm5ic3A7IFBsZWFzZSBj aGVjayB0aGUgc3ludGF4IGJ5IGhhdmluZyDigJxyYXRl4oCdIGFuZCDigJxmb2/igJ0uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkphbWVzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBKYW5ldCBQIEd1bm4gWzxhIGhyZWY9Im1h aWx0bzpqZ3VubjZAY3NjLmNvbSI+bWFpbHRvOmpndW5uNkBjc2MuY29tPC9hPl0NCjxicj4NCjxi PlNlbnQ6PC9iPiBNb25kYXksIEp1bHkgMjIsIDIwMTMgMzo1NCBQTTxicj4NCjxiPlRvOjwvYj4g WXUsIEphbWVzPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86aGdzQGNzLmNvbHVtYmlh LmVkdSI+aGdzQGNzLmNvbHVtYmlhLmVkdTwvYT47IDxhIGhyZWY9Im1haWx0bzp2a2dAYmVsbC1s YWJzLmNvbSI+DQp2a2dAYmVsbC1sYWJzLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzp2b2xrZXJo QGJlbGwtbGFicy5jb20iPnZvbGtlcmhAYmVsbC1sYWJzLmNvbTwvYT47DQo8YSBocmVmPSJtYWls dG86c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmciPnNpcC1vdmVybG9hZC1ib3VuY2VzQGll dGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmciPnNpcC1v dmVybG9hZEBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNl c0BpZXRmLm9yZyI+DQpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtzaXAtb3ZlcmxvYWRdIGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLWNv bnRyb2wtMTM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ VGhlcmUgaXMgYXQgbGVhc3Qgb25lICZxdW90O290aGVyLWFsZ28mcXVvdDssICZxdW90O3JhdGUm cXVvdDsuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4NCjxicj4NCjxicj4NCjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+V2hlbiBhbGdvLWxpc3QgaXMgaW5j bHVkZWQgaW4gdGhlIFZpYSBoZWFkZXJzIG9mIGEgbWVzc2FnZSBzZW50IGJ5IHRoZSBjbGllbnQg dG8gdGhlIHNlcnZlciwgaXQgbWF5IGhhdmUgbXVsdGlwbGUgYWxnb3JpdGhtcyBpbmNsdWRlZCBp biB0aGUgYWxnby1saXN0IC0gYWxsIHRoZSBhbGdvcml0aG1zIHN1cHBvcnRlZA0KIGJ5IHRoZSBj bGllbnQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4gPGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5XaGVuIGFsZ28tbGlzdCBpcyBpbmNs dWRlZCBpbiB0aGUgVmlhIGhlYWRlcnMgc2VudCBmcm9tIHRoZSBzZXJ2ZXIgdG8gdGhlIGNsaWVu dCwgaXQgc2hvdWxkIGhhdmUgJnF1b3Q7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4gb25lIGFu ZCBvbmx5IG9uZSBhbGdvcml0aG08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiZxdW90Ow0KIGluIHRoZSBsaXN0Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ IDxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+SmFuZXQ8YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4N Cjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3 LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiM1RjVGNUYiPkZyb206ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mcXVvdDtZdSwgSmFtZXMmcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzpqYW1lcy55dUBuZXVzdGFyLmJpeiI+amFtZXMueXVAbmV1 c3Rhci5iaXo8L2E+Jmd0Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+DQo8YnI+DQo8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNUY1RjVGIj5Ubzog Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiZxdW90OzxhIGhyZWY9Im1haWx0bzpoZ3NAY3MuY29sdW1iaWEuZWR1 Ij5oZ3NAY3MuY29sdW1iaWEuZWR1PC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhnc0Bj cy5jb2x1bWJpYS5lZHUiPmhnc0Bjcy5jb2x1bWJpYS5lZHU8L2E+Jmd0OywNCiAmcXVvdDs8YSBo cmVmPSJtYWlsdG86dmtnQGJlbGwtbGFicy5jb20iPnZrZ0BiZWxsLWxhYnMuY29tPC9hPiZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZrZ0BiZWxsLWxhYnMuY29tIj52a2dAYmVsbC1sYWJzLmNv bTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86dm9sa2VyaEBiZWxsLWxhYnMuY29tIj52 b2xrZXJoQGJlbGwtbGFicy5jb208L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86dm9sa2Vy aEBiZWxsLWxhYnMuY29tIj52b2xrZXJoQGJlbGwtbGFicy5jb208L2E+Jmd0Ozwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojNUY1RjVGIj5DYzogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZxdW90OzxhIGhy ZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZyI+c2lwLW92ZXJsb2FkLWJv dW5jZXNAaWV0Zi5vcmc8L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1haWx0bzpzaXAtb3Zlcmxv YWQtYm91bmNlc0BpZXRmLm9yZyI+c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0 OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZEBpZXRmLm9yZyI+c2lwLW92ZXJs b2FkQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZEBp ZXRmLm9yZyI+c2lwLW92ZXJsb2FkQGlldGYub3JnPC9hPiZndDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzVGNUY1RiI+RGF0ZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjA3LzIyLzIwMTMgMDM6MTkg UE08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzVGNUY1RiI+U3ViamVjdDogJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPltzaXAtb3ZlcmxvYWRdICZuYnNwO2RyYWZ0LWlldGYtc29jLW92ZXJsb2FkLWNvbnRy b2wtMTM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzVGNUY1RiI+U2VudCBieTogJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxhIGhyZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZyI+ c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249 ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBsYW5nPSJFTi1VUyI+DQo8 aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIG5vc2hhZGU9IiIgc3R5bGU9ImNvbG9yOiNBMEEwQTAi IGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0K PGJyPg0KSGksIEhlbm5pbmcsIFZpamF5LCBWb2xrZXIsIDxicj4NCiZuYnNwOyA8YnI+DQpXaGVu IEkgcmV2aWV3ZWQgZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLTA0LnR4dCwg SSBnbGFuY2VkIHRocm91Z2ggdGhlIHN5bnRheCBpbiB0aGlzIEktRCB0byB1bmRlcnN0YW5kIHRo ZSBvYyByZWxhdGVkIHBhcmFtZXRlcnMuDQo8YnI+DQombmJzcDsgPGJyPg0KV2hlbiBsb29raW5n IGF0IOKAnGFsZ28tbGlzdOKAnSwgSSB3b25kZXIgaWYgdGhlcmUgYXJlIHR3byDigJxvdGhlci1h bGdv4oCdIHN1Y2ggYXMg4oCcYWJj4oCdIGFuZCDigJx4eXrigJ0sIOKAmGFiY+KAnSBhbmQg4oCc eHl64oCdIHdvbuKAmXQgYmUgY29tbWEtc2VwYXJhdGVkIGJhc2VkIG9uIHRoZSBvYy1hbGdvIHN5 bnRheC4gJm5ic3A7SXQgc2VlbXMgdGhhdCBhbGdvLWxpc3Qgd291bGQgYmUNCjxicj4NCiZuYnNw OyA8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7YWxnby1saXN0ID0gPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj7igJw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+bG9zczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+4oCc PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiAvIG90aGVyLWFsZ288L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPg0KPGJy Pg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+DQo8YnI+DQpU aGlzIHdvdWxkIGVuc3VyZSB0aGF0IG9uZSBhbmQgb25seSBvbmUgYWxnb3JpdGhtIGlzIHByZXNl bnQgaW4gYWxnby1saXN0LiAmbmJzcDtJZiB0aGVyZSBpcyBubyBhbGdvcml0aG0gb3RoZXIgdGhh biDigJxsb3Nz4oCdLCAqKENPTU1BIGFsZ28tbGlzdCkgd291bGQgdGFrZSBjYXJlIG9mIHRoYXQu DQo8YnI+DQombmJzcDsgPGJyPg0KU2luY2UgYWxnby1saXN0IGNvbnRhaW5zIGEgc2luZ2xlIGFs Z29yaXRobSwgbWF5IGJlIGl0IGlzIGJldHRlciB0byB1c2Ug4oCcYWxnb+KAnSBvbmx5LiAmbmJz cDtPciBpZiBhbGdvLWxpc3QgY29udGFpbnMgYSBsaXN0IG9mIGNvbW1hIHNlcGFyYXRlZCBhbGdv cml0aG1zLCB0aGVuIGFsb2ctbGlzdCBhbmQgb2MtYWxnbyBjYW4gYmUgbW9kaWZpZWQgc28gdGhh dCBvYy1hbGdvIGhhcyBhIHNpbmdsZSDigJxhbGdvLWxpc3TigJ0uICZuYnNwO1RoZSBsYXR0ZXIg bWF5IGJlIGJldHRlcg0KIGJlY2F1c2UgdGhlIGN1cnJlbnQgc3ludGF4IHdvdWxkIGFsbG93IHRo ZSBzYW1lIGFsZ29yaXRobSB0byBhcHBlYXIgbW9yZSB0aGFuIG9uY2UuDQo8YnI+DQombmJzcDsg PGJyPg0KSmFtZXM8L3NwYW4+PHR0PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 L3NwYW4+PC90dD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD5zaXAtb3ZlcmxvYWQg bWFpbGluZyBsaXN0PC90dD48YnI+DQo8dHQ+PGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZEBp ZXRmLm9yZyI+c2lwLW92ZXJsb2FkQGlldGYub3JnPC9hPjwvdHQ+PGJyPg0KPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NpcC1vdmVybG9hZCI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcC1vdmVybG9hZDwvc3Bhbj48L3R0 PjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu PSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PHNwYW4gbGFuZz0iRU4tVVMiPg0K PGhyIHNpemU9IjEiIHdpZHRoPSIxMDAlIiBub3NoYWRlPSIiIHN0eWxlPSJjb2xvcjojQTBBMEEw IiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiPk5vIHZpcnVzIGZvdW5kIGluIHRoaXMgbWVzc2FnZS48YnI+DQpD aGVja2VkIGJ5IEFWRyAtIDxhIGhyZWY9Imh0dHA6Ly93d3cuYXZnLmNvbSI+d3d3LmF2Zy5jb208 L2E+PGJyPg0KVmVyc2lvbjogMjAxMy4wLjI5MDQgLyBWaXJ1cyBEYXRhYmFzZTogMzIwNC82NTEw IC0gUmVsZWFzZSBEYXRlOiAwNy8yMi8xMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B1C3FC99DESESSMB209erics_-- From internet-drafts@ietf.org Tue Jul 30 05:57:54 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 A88E221E80DB; Tue, 30 Jul 2013 05:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUEf70Y-0vNr; Tue, 30 Jul 2013 05:57:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1408121E8091; Tue, 30 Jul 2013 05:57:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130730125753.27885.54925.idtracker@ietfa.amsl.com> Date: Tue, 30 Jul 2013 05:57:53 -0700 Cc: sip-overload@ietf.org Subject: [sip-overload] I-D Action: draft-ietf-soc-load-control-event-package-09.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, 30 Jul 2013 12:57:54 -0000 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 Event P= ackage Author(s) : Charles Shen Henning Schulzrinne Arata Koike Filename : draft-ietf-soc-load-control-event-package-09.txt Pages : 42 Date : 2013-07-30 Abstract: We define a load control event package for the Session Initiation Protocol (SIP). It allows SIP entities to distribute load filtering policies to other SIP entities in the network. The load filtering policies 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-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-soc-load-control-event-packag= e-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From james.yu@neustar.biz Wed Jul 31 06:47:57 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 4CB8011E80E4; Wed, 31 Jul 2013 06:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.322 X-Spam-Level: X-Spam-Status: No, score=-6.322 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-akEjQqWbpV; Wed, 31 Jul 2013 06:47:45 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 42DAD21E8111; Wed, 31 Jul 2013 06:47:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1375279001; x=1690629428; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=NnlQveoB/gvNM0QThD82/gxvBYpDNlLmj5AiHxxGQNA=; b=XfCXnj+CVkFvYJrwm4amkihqtMX9XlJsr3Fmuu59Qnfa6dJruPWYkZ8kWC48LO TFdAg2mwWExqekeXwNe93Dbw== Received: from ([10.31.58.71]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.29024072; Wed, 31 Jul 2013 09:56:40 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.95]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Wed, 31 Jul 2013 09:47:23 -0400 From: "Yu, James" To: Christer Holmberg Thread-Topic: [sip-overload] draft-ietf-soc-overload-control-13 Thread-Index: AQHOh1hieKRy9s++6U21x6LAxw4G95l+2MqA Date: Wed, 31 Jul 2013 13:47:22 +0000 Message-ID: <56FB15AFE08E1242B0736CBDCE6E8561080A4D90@STNTEXMB10.cis.neustar.com> References: <56FB15AFE08E1242B0736CBDCE6E85610808C32F@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610808EF90@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E856108096C00@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E856108096C3D@stntexmb12.cis.neustar.com> <7594FB04B1934943A5C02806D1A2204B1C3FC99D@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3FC99D@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.31.33.140] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 6R8PCUCo9qS0RL7kuFSc7A== Content-Type: multipart/alternative; boundary="_000_56FB15AFE08E1242B0736CBDCE6E8561080A4D90STNTEXMB10cisne_" MIME-Version: 1.0 Cc: "sip-overload-bounces@ietf.org" , "volkerh@bell-labs.com" , "vkg@bell-labs.com" , "sip-overload@ietf.org" , "hgs@cs.columbia.edu" Subject: Re: [sip-overload] draft-ietf-soc-overload-control-13 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, 31 Jul 2013 13:47:57 -0000 --_000_56FB15AFE08E1242B0736CBDCE6E8561080A4D90STNTEXMB10cisne_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q2hyaXN0ZXIsDQoNClNvcnJ5IGZvciBhIGxhdGUgcmVwbHkuICBJIHdhcyBqdXN0IGJhY2sgZnJv bSB2YWNhdGlvbi4NCg0KSSBhbSB3b25kZXJpbmcgaWYgaXQgc2hvdWxkIGJlDQoNCiAgICAgICBh bGdvLXZhbHVlID0g4oCcbG9zc+KAnSAvIG90aGVyLWFsZ28NCg0Kd2hlcmUgYWxnby12YWx1ZSB3 b3VsZCBvbmx5IGNvbnRhaW4gYSBzaW5nbGUgYWxnb3JpdGhtIHZhbHVlIHN1Y2ggYXMg4oCcbG9z c+KAnSBvciBzb21ldGhpbmcgZWxzZS4NCg0KV2hlbiBhIG5ldyBhbGdvcml0aG0gc3VjaCBhcyDi gJxyYXRl4oCdIGlzIGFkZGVkLCBpdCBiZWNvbWVzDQoNCiAgICAgICBhbGdvLXZhbHVlID0g4oCc bG9zc+KAnSAvIOKAnHJhdGXigJ0gLyBvdGhlci1hbGdvDQoNCkphbWVzDQoNCkZyb206IENocmlz dGVyIEhvbG1iZXJnIFttYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tXQ0KU2Vu dDogTW9uZGF5LCBKdWx5IDIyLCAyMDEzIDExOjU1IFBNDQpUbzogWXUsIEphbWVzOyBKYW5ldCBQ IEd1bm4NCkNjOiBzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzsgdm9sa2VyaEBiZWxsLWxh YnMuY29tOyB2a2dAYmVsbC1sYWJzLmNvbTsgc2lwLW92ZXJsb2FkQGlldGYub3JnOyBoZ3NAY3Mu Y29sdW1iaWEuZWR1DQpTdWJqZWN0OiBWUzogW3NpcC1vdmVybG9hZF0gZHJhZnQtaWV0Zi1zb2Mt b3ZlcmxvYWQtY29udHJvbC0xMw0KDQpIaSwNCg0KSSBkb27igJl0IHRoaW5rIHRoZSBjdXJyZW50 IEFCTkYgYWxsb3dzIGEgbGlzdCB3aXRob3V0IGNvbW1hIHNlcGFyYXRpb24uIEtlZXAgaW4gbWlu ZCB0aGF0IOKAnGFsZ28tbGlzdOKAnSBkb2VzIG5vdCByZXByZXNlbnQgdGhlIGxpc3QsIG9ubHkg YSBzaW5nbGUgdmFsdWUgaW4gdGhlIGxpc3QuDQoNCkJ1dCwgSSB1bmRlcnN0YW5kIHlvdXIgY29u ZnVzaW9uLCBhbmQgaW4gZmFjdCBJIHRoaW5rIOKAnWFsZ28tbGlzdOKAnSBpcyBhIGxpdHRsZSBt aXNsZWFkaW5nLiBJIHRoaW5rIGl0IHdvdWxkIGJlIGJldHRlciB0byBjYWxsIGl0IOKAnGFsZ28t dmFsdWXigJ0sIG9yIHNvbWV0aGluZyBzaW1pbGFyLg0KDQpvYy1hbGdvICAgICA9ICJvYy1hbGdv IiBFUVVBTCBEUVVPVEUgYWxnby12YWx1ZSAqKENPTU1BIGFsZ28tdmFsdWUpRFFVT1RFDQphbGdv LXZhbHVlICAgPSAibG9zcyIgLyAqKG90aGVyLWFsZ28pDQpvdGhlci1hbGdvICA9ICV4NDEtNUEg LyAleDYxLTdBIC8gJXgzMC0zOQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KTMOkaGV0 dMOkasOkOiBzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2lwLW92ZXJsb2Fk LWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmdd IFB1b2xlc3RhIFl1LCBKYW1lcw0KTMOkaGV0ZXR0eTogMjIuIGhlaW7DpGt1dXRhIDIwMTMgMjM6 MTINClZhc3RhYW5vdHRhamE6IEphbmV0IFAgR3Vubg0KS29waW86IHNpcC1vdmVybG9hZC1ib3Vu Y2VzQGlldGYub3JnPG1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZz47IHZvbGtl cmhAYmVsbC1sYWJzLmNvbTxtYWlsdG86dm9sa2VyaEBiZWxsLWxhYnMuY29tPjsgdmtnQGJlbGwt bGFicy5jb208bWFpbHRvOnZrZ0BiZWxsLWxhYnMuY29tPjsgc2lwLW92ZXJsb2FkQGlldGYub3Jn PG1haWx0bzpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmc+OyBoZ3NAY3MuY29sdW1iaWEuZWR1PG1haWx0 bzpoZ3NAY3MuY29sdW1iaWEuZWR1Pg0KQWloZTogUmU6IFtzaXAtb3ZlcmxvYWRdIGRyYWZ0LWll dGYtc29jLW92ZXJsb2FkLWNvbnRyb2wtMTMNCg0KSmFuZXQsDQoNCk15IGNvbW1lbnQgaXMgbm90 IG9uIGhhdmluZyBtdWx0aXBsZSBhbGdvcml0aG1zIGluIHRoZSB2aWEgaGVhZGVyIGJ1dCBvbiB0 aGUgc3ludGF4IGluIHRoZSBjdXJyZW50IEktRCB0aGF0IGNvdWxkIGFsbG93IG11bHRpcGxlIGFs Z29yaXRobXMgdGhhdCBhcmUgbm90IHNlcGFyYXRlZCBieSDigJws4oCdLiAgUGxlYXNlIGNoZWNr IHRoZSBzeW50YXggYnkgaGF2aW5nIOKAnHJhdGXigJ0gYW5kIOKAnGZvb+KAnS4NCg0KSmFtZXMN Cg0KRnJvbTogSmFuZXQgUCBHdW5uIFttYWlsdG86amd1bm42QGNzYy5jb21dDQpTZW50OiBNb25k YXksIEp1bHkgMjIsIDIwMTMgMzo1NCBQTQ0KVG86IFl1LCBKYW1lcw0KQ2M6IGhnc0Bjcy5jb2x1 bWJpYS5lZHU8bWFpbHRvOmhnc0Bjcy5jb2x1bWJpYS5lZHU+OyB2a2dAYmVsbC1sYWJzLmNvbTxt YWlsdG86dmtnQGJlbGwtbGFicy5jb20+OyB2b2xrZXJoQGJlbGwtbGFicy5jb208bWFpbHRvOnZv bGtlcmhAYmVsbC1sYWJzLmNvbT47IHNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPG1haWx0 bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZz47IHNpcC1vdmVybG9hZEBpZXRmLm9yZzxt YWlsdG86c2lwLW92ZXJsb2FkQGlldGYub3JnPjsgc2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5v cmc8bWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtz aXAtb3ZlcmxvYWRdIGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLWNvbnRyb2wtMTMNCg0KVGhlcmUg aXMgYXQgbGVhc3Qgb25lICJvdGhlci1hbGdvIiwgInJhdGUiLg0KDQpXaGVuIGFsZ28tbGlzdCBp cyBpbmNsdWRlZCBpbiB0aGUgVmlhIGhlYWRlcnMgb2YgYSBtZXNzYWdlIHNlbnQgYnkgdGhlIGNs aWVudCB0byB0aGUgc2VydmVyLCBpdCBtYXkgaGF2ZSBtdWx0aXBsZSBhbGdvcml0aG1zIGluY2x1 ZGVkIGluIHRoZSBhbGdvLWxpc3QgLSBhbGwgdGhlIGFsZ29yaXRobXMgc3VwcG9ydGVkIGJ5IHRo ZSBjbGllbnQuDQoNCldoZW4gYWxnby1saXN0IGlzIGluY2x1ZGVkIGluIHRoZSBWaWEgaGVhZGVy cyBzZW50IGZyb20gdGhlIHNlcnZlciB0byB0aGUgY2xpZW50LCBpdCBzaG91bGQgaGF2ZSAiIG9u ZSBhbmQgb25seSBvbmUgYWxnb3JpdGhtIiBpbiB0aGUgbGlzdC4NCg0KSmFuZXQNCg0KDQoNCg0K DQpGcm9tOiAgICAgICAgIll1LCBKYW1lcyIgPGphbWVzLnl1QG5ldXN0YXIuYml6PG1haWx0bzpq YW1lcy55dUBuZXVzdGFyLmJpej4+DQpUbzogICAgICAgICJoZ3NAY3MuY29sdW1iaWEuZWR1PG1h aWx0bzpoZ3NAY3MuY29sdW1iaWEuZWR1PiIgPGhnc0Bjcy5jb2x1bWJpYS5lZHU8bWFpbHRvOmhn c0Bjcy5jb2x1bWJpYS5lZHU+PiwgInZrZ0BiZWxsLWxhYnMuY29tPG1haWx0bzp2a2dAYmVsbC1s YWJzLmNvbT4iIDx2a2dAYmVsbC1sYWJzLmNvbTxtYWlsdG86dmtnQGJlbGwtbGFicy5jb20+Piwg InZvbGtlcmhAYmVsbC1sYWJzLmNvbTxtYWlsdG86dm9sa2VyaEBiZWxsLWxhYnMuY29tPiIgPHZv bGtlcmhAYmVsbC1sYWJzLmNvbTxtYWlsdG86dm9sa2VyaEBiZWxsLWxhYnMuY29tPj4NCkNjOiAg ICAgICAgInNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzaXAtb3ZlcmxvYWQt Ym91bmNlc0BpZXRmLm9yZz4iIDxzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86 c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc+PiwgInNpcC1vdmVybG9hZEBpZXRmLm9yZzxt YWlsdG86c2lwLW92ZXJsb2FkQGlldGYub3JnPiIgPHNpcC1vdmVybG9hZEBpZXRmLm9yZzxtYWls dG86c2lwLW92ZXJsb2FkQGlldGYub3JnPj4NCkRhdGU6ICAgICAgICAwNy8yMi8yMDEzIDAzOjE5 IFBNDQpTdWJqZWN0OiAgICAgICAgW3NpcC1vdmVybG9hZF0gIGRyYWZ0LWlldGYtc29jLW92ZXJs b2FkLWNvbnRyb2wtMTMNClNlbnQgYnk6ICAgICAgICBzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRm Lm9yZzxtYWlsdG86c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KDQoNCg0KSGksIEhlbm5pbmcsIFZpamF5LCBWb2xrZXIsDQoN CldoZW4gSSByZXZpZXdlZCBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1yYXRlLWNvbnRyb2wtMDQu dHh0LCBJIGdsYW5jZWQgdGhyb3VnaCB0aGUgc3ludGF4IGluIHRoaXMgSS1EIHRvIHVuZGVyc3Rh bmQgdGhlIG9jIHJlbGF0ZWQgcGFyYW1ldGVycy4NCg0KV2hlbiBsb29raW5nIGF0IOKAnGFsZ28t bGlzdOKAnSwgSSB3b25kZXIgaWYgdGhlcmUgYXJlIHR3byDigJxvdGhlci1hbGdv4oCdIHN1Y2gg YXMg4oCcYWJj4oCdIGFuZCDigJx4eXrigJ0sIOKAmGFiY+KAnSBhbmQg4oCceHl64oCdIHdvbuKA mXQgYmUgY29tbWEtc2VwYXJhdGVkIGJhc2VkIG9uIHRoZSBvYy1hbGdvIHN5bnRheC4gIEl0IHNl ZW1zIHRoYXQgYWxnby1saXN0IHdvdWxkIGJlDQoNCiBhbGdvLWxpc3QgPSDigJxsb3Nz4oCcIC8g b3RoZXItYWxnbw0KDQpUaGlzIHdvdWxkIGVuc3VyZSB0aGF0IG9uZSBhbmQgb25seSBvbmUgYWxn b3JpdGhtIGlzIHByZXNlbnQgaW4gYWxnby1saXN0LiAgSWYgdGhlcmUgaXMgbm8gYWxnb3JpdGht IG90aGVyIHRoYW4g4oCcbG9zc+KAnSwgKihDT01NQSBhbGdvLWxpc3QpIHdvdWxkIHRha2UgY2Fy ZSBvZiB0aGF0Lg0KDQpTaW5jZSBhbGdvLWxpc3QgY29udGFpbnMgYSBzaW5nbGUgYWxnb3JpdGht LCBtYXkgYmUgaXQgaXMgYmV0dGVyIHRvIHVzZSDigJxhbGdv4oCdIG9ubHkuICBPciBpZiBhbGdv LWxpc3QgY29udGFpbnMgYSBsaXN0IG9mIGNvbW1hIHNlcGFyYXRlZCBhbGdvcml0aG1zLCB0aGVu IGFsb2ctbGlzdCBhbmQgb2MtYWxnbyBjYW4gYmUgbW9kaWZpZWQgc28gdGhhdCBvYy1hbGdvIGhh cyBhIHNpbmdsZSDigJxhbGdvLWxpc3TigJ0uICBUaGUgbGF0dGVyIG1heSBiZSBiZXR0ZXIgYmVj YXVzZSB0aGUgY3VycmVudCBzeW50YXggd291bGQgYWxsb3cgdGhlIHNhbWUgYWxnb3JpdGhtIHRv IGFwcGVhciBtb3JlIHRoYW4gb25jZS4NCg0KSmFtZXNfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0Kc2lwLW92ZXJsb2FkIG1haWxpbmcgbGlzdA0Kc2lwLW92 ZXJsb2FkQGlldGYub3JnPG1haWx0bzpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcC1vdmVybG9hZA0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCk5vIHZpcnVzIGZvdW5kIGluIHRoaXMgbWVzc2FnZS4NCkNoZWNr ZWQgYnkgQVZHIC0gd3d3LmF2Zy5jb208aHR0cDovL3d3dy5hdmcuY29tPg0KVmVyc2lvbjogMjAx My4wLjI5MDQgLyBWaXJ1cyBEYXRhYmFzZTogMzIwNC82NTEwIC0gUmVsZWFzZSBEYXRlOiAwNy8y Mi8xMw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5vIHZpcnVzIGZvdW5kIGlu IHRoaXMgbWVzc2FnZS4NCkNoZWNrZWQgYnkgQVZHIC0gd3d3LmF2Zy5jb208aHR0cDovL3d3dy5h dmcuY29tPg0KVmVyc2lvbjogMjAxMy4wLjI5MDQgLyBWaXJ1cyBEYXRhYmFzZTogMzIwOS82NTM2 IC0gUmVsZWFzZSBEYXRlOiAwNy8zMC8xMw0K --_000_56FB15AFE08E1242B0736CBDCE6E8561080A4D90STNTEXMB10cisne_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQp0dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29B Y2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bh bi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0 ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5CYWxsb29uVGV4 dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0KcC5TZWxpdGV0ZWtzdGksIGxpLlNlbGl0ZXRla3N0aSwgZGl2LlNlbGl0ZXRla3N0aQ0K CXttc28tc3R5bGUtbmFtZTpTZWxpdGV0ZWtzdGk7DQoJbXNvLXN0eWxlLWxpbms6IlNlbGl0ZXRl a3N0aSBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0K c3Bhbi5TZWxpdGV0ZWtzdGlDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJTZWxpdGV0ZWtzdGkgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOlNlbGl0ZXRla3N0 aTsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KcC5IVE1MLWVzaW11b3Rv aWx0dSwgbGkuSFRNTC1lc2ltdW90b2lsdHUsIGRpdi5IVE1MLWVzaW11b3RvaWx0dQ0KCXttc28t c3R5bGUtbmFtZTpIVE1MLWVzaW11b3RvaWx0dTsNCgltc28tc3R5bGUtbGluazoiSFRNTC1lc2lt dW90b2lsdHUgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCnNwYW4uSFRNTC1lc2ltdW90b2lsdHVDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MLWVz aW11b3RvaWx0dSBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6SFRNTC1lc2ltdW90b2lsdHU7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFu LkVtYWlsU3R5bGUyOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DaHJpc3Rlciw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlNvcnJ5IGZvciBhIGxhdGUgcmVwbHkuJm5ic3A7IEkgd2FzIGp1c3QgYmFjayBmcm9t IHZhY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhbSB3b25kZXJpbmcgaWYgaXQgc2hvdWxkIGJlDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhbGdvLXZhbHVlID0g 4oCcbG9zc+KAnSAvIG90aGVyLWFsZ288bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPndoZXJlIGFsZ28tdmFsdWUgd291bGQg b25seSBjb250YWluIGEgc2luZ2xlIGFsZ29yaXRobSB2YWx1ZSBzdWNoIGFzIOKAnGxvc3PigJ0g b3Igc29tZXRoaW5nIGVsc2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaGVuIGEgbmV3IGFsZ29yaXRobSBzdWNoIGFz IOKAnHJhdGXigJ0gaXMgYWRkZWQsIGl0IGJlY29tZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhbGdvLXZhbHVlID0g4oCcbG9zc+KAnSAvIOKAnHJhdGXi gJ0gLyBvdGhlci1hbGdvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5KYW1lczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IENocmlz dGVyIEhvbG1iZXJnIFttYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tXQ0KPGJy Pg0KPGI+U2VudDo8L2I+IE1vbmRheSwgSnVseSAyMiwgMjAxMyAxMTo1NSBQTTxicj4NCjxiPlRv OjwvYj4gWXUsIEphbWVzOyBKYW5ldCBQIEd1bm48YnI+DQo8Yj5DYzo8L2I+IHNpcC1vdmVybG9h ZC1ib3VuY2VzQGlldGYub3JnOyB2b2xrZXJoQGJlbGwtbGFicy5jb207IHZrZ0BiZWxsLWxhYnMu Y29tOyBzaXAtb3ZlcmxvYWRAaWV0Zi5vcmc7IGhnc0Bjcy5jb2x1bWJpYS5lZHU8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gVlM6IFtzaXAtb3ZlcmxvYWRdIGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLWNv bnRyb2wtMTM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJGSSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZJ IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZG9u4oCZdCB0aGluayB0aGUgY3VycmVudCBBQk5GIGFsbG93 cyBhIGxpc3Qgd2l0aG91dCBjb21tYSBzZXBhcmF0aW9uLiBLZWVwIGluIG1pbmQgdGhhdCDigJxh bGdvLWxpc3TigJ0gZG9lcyBub3QgcmVwcmVzZW50IHRoZSBsaXN0LCBvbmx5IGEgc2luZ2xlIHZh bHVlIGluIHRoZQ0KIGxpc3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CdXQsIEkgdW5kZXJzdGFuZCB5b3VyIGNvbmZ1 c2lvbiwgYW5kIGluIGZhY3QgSSB0aGluayDigJ1hbGdvLWxpc3TigJ0gaXMgYSBsaXR0bGUgbWlz bGVhZGluZy4gSSB0aGluayBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gY2FsbCBpdA0KPGI+4oCcYWxn by12YWx1ZeKAnTwvYj4sIG9yIHNvbWV0aGluZyBzaW1pbGFyLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+b2MtYWxnbyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA9ICZxdW90O29j LWFsZ28mcXVvdDsgRVFVQUwgRFFVT1RFIGFsZ28tdmFsdWUgKihDT01NQSBhbGdvLXZhbHVlKURR VU9URTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij5hbGdvLXZhbHVlJm5ic3A7Jm5ic3A7ID0gJnF1b3Q7bG9zcyZxdW90OyAvICoob3RoZXItYWxn byk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ b3RoZXItYWxnbyZuYnNwOyA9ICV4NDEtNUEgLyAleDYxLTdBIC8gJXgzMC0zOTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxh bmc9IkZJIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+TMOkaGV0dMOkasOkOjwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRkkiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjxhIGhyZWY9Im1haWx0bzpzaXAt b3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZyI+c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+IFs8YSBocmVmPSJtYWlsdG86c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0 bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5QdW9sZXN0YSA8L2I+WXUs IEphbWVzPGJyPg0KPGI+TMOkaGV0ZXR0eTo8L2I+IDIyLiBoZWluw6RrdXV0YSAyMDEzIDIzOjEy PGJyPg0KPGI+VmFzdGFhbm90dGFqYTo8L2I+IEphbmV0IFAgR3Vubjxicj4NCjxiPktvcGlvOjwv Yj4gPGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnIj5zaXAtb3Zl cmxvYWQtYm91bmNlc0BpZXRmLm9yZzwvYT47DQo8YSBocmVmPSJtYWlsdG86dm9sa2VyaEBiZWxs LWxhYnMuY29tIj52b2xrZXJoQGJlbGwtbGFicy5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86dmtn QGJlbGwtbGFicy5jb20iPg0KdmtnQGJlbGwtbGFicy5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86 c2lwLW92ZXJsb2FkQGlldGYub3JnIj5zaXAtb3ZlcmxvYWRAaWV0Zi5vcmc8L2E+Ow0KPGEgaHJl Zj0ibWFpbHRvOmhnc0Bjcy5jb2x1bWJpYS5lZHUiPmhnc0Bjcy5jb2x1bWJpYS5lZHU8L2E+PGJy Pg0KPGI+QWloZTo8L2I+IFJlOiBbc2lwLW92ZXJsb2FkXSBkcmFmdC1pZXRmLXNvYy1vdmVybG9h ZC1jb250cm9sLTEzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZJIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+SmFuZXQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NeSBjb21tZW50IGlzIG5vdCBvbiBoYXZpbmcg bXVsdGlwbGUgYWxnb3JpdGhtcyBpbiB0aGUgdmlhIGhlYWRlciBidXQgb24gdGhlIHN5bnRheCBp biB0aGUgY3VycmVudCBJLUQgdGhhdCBjb3VsZCBhbGxvdyBtdWx0aXBsZSBhbGdvcml0aG1zIHRo YXQgYXJlIG5vdCBzZXBhcmF0ZWQNCiBieSDigJws4oCdLiZuYnNwOyBQbGVhc2UgY2hlY2sgdGhl IHN5bnRheCBieSBoYXZpbmcg4oCccmF0ZeKAnSBhbmQg4oCcZm9v4oCdLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SmFt ZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IEphbmV0IFAgR3VubiBbPGEgaHJlZj0ibWFpbHRvOmpndW5uNkBjc2Mu Y29tIj5tYWlsdG86amd1bm42QGNzYy5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRh eSwgSnVseSAyMiwgMjAxMyAzOjU0IFBNPGJyPg0KPGI+VG86PC9iPiBZdSwgSmFtZXM8YnI+DQo8 Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpoZ3NAY3MuY29sdW1iaWEuZWR1Ij5oZ3NAY3MuY29s dW1iaWEuZWR1PC9hPjsgPGEgaHJlZj0ibWFpbHRvOnZrZ0BiZWxsLWxhYnMuY29tIj4NCnZrZ0Bi ZWxsLWxhYnMuY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnZvbGtlcmhAYmVsbC1sYWJzLmNvbSI+ dm9sa2VyaEBiZWxsLWxhYnMuY29tPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWQt Ym91bmNlc0BpZXRmLm9yZyI+c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Ow0KPGEg aHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZEBpZXRmLm9yZyI+c2lwLW92ZXJsb2FkQGlldGYub3Jn PC9hPjsgPGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnIj4NCnNp cC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W3NpcC1vdmVybG9hZF0gZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtY29udHJvbC0xMzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5UaGVyZSBpcyBhdCBsZWFzdCBvbmUgJnF1b3Q7b3RoZXItYWxnbyZxdW90OywgJnF1b3Q7cmF0 ZSZxdW90Oy48L3NwYW4+DQo8YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5X aGVuIGFsZ28tbGlzdCBpcyBpbmNsdWRlZCBpbiB0aGUgVmlhIGhlYWRlcnMgb2YgYSBtZXNzYWdl IHNlbnQgYnkgdGhlIGNsaWVudCB0byB0aGUgc2VydmVyLCBpdCBtYXkgaGF2ZSBtdWx0aXBsZSBh bGdvcml0aG1zIGluY2x1ZGVkIGluIHRoZSBhbGdvLWxpc3QgLSBhbGwgdGhlIGFsZ29yaXRobXMg c3VwcG9ydGVkIGJ5IHRoZSBjbGllbnQuPC9zcGFuPg0KPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+V2hlbiBhbGdvLWxpc3QgaXMgaW5jbHVkZWQgaW4gdGhlIFZpYSBoZWFk ZXJzIHNlbnQgZnJvbSB0aGUgc2VydmVyIHRvIHRoZSBjbGllbnQsIGl0IHNob3VsZCBoYXZlICZx dW90Ozwvc3Bhbj4gb25lIGFuZCBvbmx5IG9uZSBhbGdvcml0aG08c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4mcXVvdDsNCiBpbiB0aGUgbGlzdC48L3NwYW4+IDxicj4NCjxicj4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkphbmV0PGJyPg0KPGJyPg0KPC9zcGFuPjxicj4NCjxicj4NCjxi cj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNUY1RjVGIj5Gcm9tOiAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3 LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4mcXVvdDtZdSwgSmFtZXMmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpqYW1lcy55dUBuZXVz dGFyLmJpeiI+amFtZXMueXVAbmV1c3Rhci5iaXo8L2E+Jmd0Ozwvc3Bhbj4NCjxicj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNUY1RjVGIj5UbzogJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+JnF1b3Q7PGEgaHJlZj0i bWFpbHRvOmhnc0Bjcy5jb2x1bWJpYS5lZHUiPmhnc0Bjcy5jb2x1bWJpYS5lZHU8L2E+JnF1b3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86aGdzQGNzLmNvbHVtYmlhLmVkdSI+aGdzQGNzLmNvbHVtYmlh LmVkdTwvYT4mZ3Q7LA0KICZxdW90OzxhIGhyZWY9Im1haWx0bzp2a2dAYmVsbC1sYWJzLmNvbSI+ dmtnQGJlbGwtbGFicy5jb208L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86dmtnQGJlbGwt bGFicy5jb20iPnZrZ0BiZWxsLWxhYnMuY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0 bzp2b2xrZXJoQGJlbGwtbGFicy5jb20iPnZvbGtlcmhAYmVsbC1sYWJzLmNvbTwvYT4mcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzp2b2xrZXJoQGJlbGwtbGFicy5jb20iPnZvbGtlcmhAYmVsbC1s YWJzLmNvbTwvYT4mZ3Q7PC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiM1RjVGNUYiPkNjOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mcXVvdDs8YSBocmVmPSJtYWlsdG86c2lwLW92ZXJsb2FkLWJv dW5jZXNAaWV0Zi5vcmciPnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPC9hPiZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnIj5zaXAtb3Zl cmxvYWQtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7LA0KICZxdW90OzxhIGhyZWY9Im1haWx0bzpz aXAtb3ZlcmxvYWRAaWV0Zi5vcmciPnNpcC1vdmVybG9hZEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0 OzxhIGhyZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmciPnNpcC1vdmVybG9hZEBpZXRm Lm9yZzwvYT4mZ3Q7PC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiM1RjVGNUYiPkRhdGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPjA3LzIyLzIwMTMgMDM6MTkgUE08L3NwYW4+DQo8YnI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzVGNUY1RiI+U3ViamVjdDogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+W3NpcC1vdmVy bG9hZF0gJm5ic3A7ZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtY29udHJvbC0xMzwvc3Bhbj4NCjxi cj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNUY1RjVGIj5TZW50IGJ5OiAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 YSBocmVmPSJtYWlsdG86c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmciPnNpcC1vdmVybG9h ZC1ib3VuY2VzQGlldGYub3JnPC9hPjwvc3Bhbj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBjbGFz cz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0K PGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBub3NoYWRlPSIiIHN0eWxlPSJjb2xvcjojQTBBMEEw IiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQo8YnI+DQpIaSwgSGVubmluZywgVmlqYXks IFZvbGtlciwgPGJyPg0KJm5ic3A7IDxicj4NCldoZW4gSSByZXZpZXdlZCBkcmFmdC1pZXRmLXNv Yy1vdmVybG9hZC1yYXRlLWNvbnRyb2wtMDQudHh0LCBJIGdsYW5jZWQgdGhyb3VnaCB0aGUgc3lu dGF4IGluIHRoaXMgSS1EIHRvIHVuZGVyc3RhbmQgdGhlIG9jIHJlbGF0ZWQgcGFyYW1ldGVycy4N Cjxicj4NCiZuYnNwOyA8YnI+DQpXaGVuIGxvb2tpbmcgYXQg4oCcYWxnby1saXN04oCdLCBJIHdv bmRlciBpZiB0aGVyZSBhcmUgdHdvIOKAnG90aGVyLWFsZ2/igJ0gc3VjaCBhcyDigJxhYmPigJ0g YW5kIOKAnHh5euKAnSwg4oCYYWJj4oCdIGFuZCDigJx4eXrigJ0gd29u4oCZdCBiZSBjb21tYS1z ZXBhcmF0ZWQgYmFzZWQgb24gdGhlIG9jLWFsZ28gc3ludGF4LiAmbmJzcDtJdCBzZWVtcyB0aGF0 IGFsZ28tbGlzdCB3b3VsZCBiZQ0KPGJyPg0KJm5ic3A7IDxicj4NCjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7YWxnby1saXN0ID0gPC9zcGFu PuKAnDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+bG9z czwvc3Bhbj7igJw8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiAvIG90aGVyLWFsZ288L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj4gPGJyPg0KVGhpcyB3b3VsZCBl bnN1cmUgdGhhdCBvbmUgYW5kIG9ubHkgb25lIGFsZ29yaXRobSBpcyBwcmVzZW50IGluIGFsZ28t bGlzdC4gJm5ic3A7SWYgdGhlcmUgaXMgbm8gYWxnb3JpdGhtIG90aGVyIHRoYW4g4oCcbG9zc+KA nSwgKihDT01NQSBhbGdvLWxpc3QpIHdvdWxkIHRha2UgY2FyZSBvZiB0aGF0Lg0KPGJyPg0KJm5i c3A7IDxicj4NClNpbmNlIGFsZ28tbGlzdCBjb250YWlucyBhIHNpbmdsZSBhbGdvcml0aG0sIG1h eSBiZSBpdCBpcyBiZXR0ZXIgdG8gdXNlIOKAnGFsZ2/igJ0gb25seS4gJm5ic3A7T3IgaWYgYWxn by1saXN0IGNvbnRhaW5zIGEgbGlzdCBvZiBjb21tYSBzZXBhcmF0ZWQgYWxnb3JpdGhtcywgdGhl biBhbG9nLWxpc3QgYW5kIG9jLWFsZ28gY2FuIGJlIG1vZGlmaWVkIHNvIHRoYXQgb2MtYWxnbyBo YXMgYSBzaW5nbGUg4oCcYWxnby1saXN04oCdLiAmbmJzcDtUaGUgbGF0dGVyIG1heSBiZSBiZXR0 ZXINCiBiZWNhdXNlIHRoZSBjdXJyZW50IHN5bnRheCB3b3VsZCBhbGxvdyB0aGUgc2FtZSBhbGdv cml0aG0gdG8gYXBwZWFyIG1vcmUgdGhhbiBvbmNlLg0KPGJyPg0KJm5ic3A7IDxicj4NCkphbWVz PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+ c2lwLW92ZXJsb2FkIG1haWxpbmcgbGlzdDwvdHQ+PGJyPg0KPHR0PjxhIGhyZWY9Im1haWx0bzpz aXAtb3ZlcmxvYWRAaWV0Zi5vcmciPnNpcC1vdmVybG9hZEBpZXRmLm9yZzwvYT48L3R0Pjxicj4N Cjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Np cC1vdmVybG9hZCI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcC1vdmVybG9hZDwvc3Bhbj48L3R0PjwvYT48 bzpwPjwvbzpwPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5 bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIxIiB3aWR0aD0iMTAwJSIgbm9zaGFk ZT0iIiBzdHlsZT0iY29sb3I6I0EwQTBBMCIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Tm8gdmlydXMgZm91bmQgaW4gdGhpcyBtZXNzYWdlLjxicj4NCkNo ZWNrZWQgYnkgQVZHIC0gPGEgaHJlZj0iaHR0cDovL3d3dy5hdmcuY29tIj53d3cuYXZnLmNvbTwv YT48YnI+DQpWZXJzaW9uOiAyMDEzLjAuMjkwNCAvIFZpcnVzIERhdGFiYXNlOiAzMjA0LzY1MTAg LSBSZWxlYXNlIERhdGU6IDA3LzIyLzEzPG86cD48L286cD48L3A+DQo8ZGl2IGNsYXNzPSJNc29O b3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PHNwYW4gbGFu Zz0iRkkiPg0KPGhyIHNpemU9IjEiIHdpZHRoPSIxMDAlIiBub3NoYWRlPSIiIHN0eWxlPSJjb2xv cjojQTBBMEEwIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRkkiPk5vIHZpcnVzIGZvdW5kIGluIHRoaXMgbWVzc2FnZS48 YnI+DQpDaGVja2VkIGJ5IEFWRyAtIDxhIGhyZWY9Imh0dHA6Ly93d3cuYXZnLmNvbSI+d3d3LmF2 Zy5jb208L2E+PGJyPg0KVmVyc2lvbjogMjAxMy4wLjI5MDQgLyBWaXJ1cyBEYXRhYmFzZTogMzIw OS82NTM2IC0gUmVsZWFzZSBEYXRlOiAwNy8zMC8xMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_56FB15AFE08E1242B0736CBDCE6E8561080A4D90STNTEXMB10cisne_-- From christer.holmberg@ericsson.com Wed Jul 31 07:47: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 7253721F9DF1; Wed, 31 Jul 2013 07:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.931 X-Spam-Level: X-Spam-Status: No, score=-5.931 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHowO7fyXuu9; Wed, 31 Jul 2013 07:47:26 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 07EB421F9CD9; Wed, 31 Jul 2013 07:47:24 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-eb-51f9237b22f9 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id FC.05.19388.B7329F15; Wed, 31 Jul 2013 16:47:24 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Wed, 31 Jul 2013 16:47:23 +0200 From: Christer Holmberg To: "Yu, James" Thread-Topic: [sip-overload] draft-ietf-soc-overload-control-13 Thread-Index: AQHOhxU3F7sJun9uH0SBY0IRumtD5plw/7kAgACg/lCADRiOAIAAMJyg Date: Wed, 31 Jul 2013 14:47:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C41581A@ESESSMB209.ericsson.se> References: <56FB15AFE08E1242B0736CBDCE6E85610808C32F@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610808EF90@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E856108096C00@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E856108096C3D@stntexmb12.cis.neustar.com> <7594FB04B1934943A5C02806D1A2204B1C3FC99D@ESESSMB209.ericsson.se> <56FB15AFE08E1242B0736CBDCE6E8561080A4D90@STNTEXMB10.cis.neustar.com> In-Reply-To: <56FB15AFE08E1242B0736CBDCE6E8561080A4D90@STNTEXMB10.cis.neustar.com> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C41581AESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGfG3VrdG+WegwbJ3bBZX+lYyWSyaFmLR fnErq8X+pwkWDWvkLDYtv8XuwObRd9nF4+utg0weS5b8ZPLY0fCcOYAlissmJTUnsyy1SN8u gSvjzu2JLAVdu5gqNsy7xNLA+GEjUxcjJ4eEgInE6/UvGSFsMYkL99azdTFycQgJHGaU6J50 mB0kISSwhFFi3YHsLkYODjYBC4nuf9ogYREBNYmz+7cygtQzCzQySbQ/vc4GkhAWsJOY/3Qy I0SRvcS75tcsELabxKve52BxFgFViR8L5oDZvAK+Em0bLzBCLD7IInFs6muwQZwCQRLfn6xl BrEZga77fmoN2NXMAuISHw5eZ4a4WkBiyZ7zULaoxMvH/1ghbCWJxiVPWCHq8yW6V21hg1gm KHFy5hOWCYyis5CMmoWkbBaSsllAPzMLaEqs36UPUaIoMaX7ITuErSHROmcuO7L4Akb2VYzs uYmZOenl5psYgbF4cMtvgx2Mm+6LHWKU5mBREufdrHcmUEggPbEkNTs1tSC1KL6oNCe1+BAj EwenVANjaZ1J5LO3pm6O6mkH5C81CQZ+Ea9c8P7l1s+BR7MK7G/dvnToptmM2Kmsc6Vyayx8 tfxeXP92TjXo1QL7MK+awmxDXs+M229fKL7wy3u7/mq71W6/nmvCq9tWmSi4LjhnxGnDpdu6 6rTvdXdnsZvRTyPjFz6yeVRU0DL7xNqbe6r4024+WKmsxFKckWioxVxUnAgAG+tlzpMCAAA= Cc: "sip-overload-bounces@ietf.org" , "volkerh@bell-labs.com" , "vkg@bell-labs.com" , "sip-overload@ietf.org" , "hgs@cs.columbia.edu" Subject: Re: [sip-overload] draft-ietf-soc-overload-control-13 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, 31 Jul 2013 14:47:32 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C41581AESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5Tb3JyeSBmb3IgYSBsYXRlIHJlcGx5LiAgSSB3YXMganVzdCBiYWNrIGZyb20gdmFj YXRpb24uDQo+DQo+SSBhbSB3b25kZXJpbmcgaWYgaXQgc2hvdWxkIGJlDQo+DQo+ICAgICAgIGFs Z28tdmFsdWUgPSDigJxsb3Nz4oCdIC8gb3RoZXItYWxnbw0KPg0KPiB3aGVyZSBhbGdvLXZhbHVl IHdvdWxkIG9ubHkgY29udGFpbiBhIHNpbmdsZSBhbGdvcml0aG0gdmFsdWUgc3VjaCBhcyDigJxs b3Nz4oCdIG9yIHNvbWV0aGluZyBlbHNlLg0KDQpLZWVwIGluIG1pbmQgdGhhdCB0aGUgZGVmaW5p dGlvbiBvZiBvdGhlci1hbGdvIGlzIG9ubHkgYSBzaW5nbGUgY2hhcmFjdGVyLg0KDQpCdXQsIHdl IGNhbiBjaGFuZ2Ugb3RoZXItYWxnbyB0bzoNCg0Kb3RoZXItYWxnbyAgPSAxKigleDQxLTVBIC8g JXg2MS03QSAvICV4MzAtMzkpDQoNCuKApndoaWNoIHByb2JhYmx5IGNsYXJpZmllcyBldmVuIGZ1 cnRoZXIuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KRnJvbTogQ2hyaXN0ZXIgSG9sbWJl cmcgW21haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb21dDQpTZW50OiBNb25kYXks IEp1bHkgMjIsIDIwMTMgMTE6NTUgUE0NClRvOiBZdSwgSmFtZXM7IEphbmV0IFAgR3Vubg0KQ2M6 IHNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNl c0BpZXRmLm9yZz47IHZvbGtlcmhAYmVsbC1sYWJzLmNvbTxtYWlsdG86dm9sa2VyaEBiZWxsLWxh YnMuY29tPjsgdmtnQGJlbGwtbGFicy5jb208bWFpbHRvOnZrZ0BiZWxsLWxhYnMuY29tPjsgc2lw LW92ZXJsb2FkQGlldGYub3JnPG1haWx0bzpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmc+OyBoZ3NAY3Mu Y29sdW1iaWEuZWR1PG1haWx0bzpoZ3NAY3MuY29sdW1iaWEuZWR1Pg0KU3ViamVjdDogVlM6IFtz aXAtb3ZlcmxvYWRdIGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLWNvbnRyb2wtMTMNCg0KSGksDQoN CkkgZG9u4oCZdCB0aGluayB0aGUgY3VycmVudCBBQk5GIGFsbG93cyBhIGxpc3Qgd2l0aG91dCBj b21tYSBzZXBhcmF0aW9uLiBLZWVwIGluIG1pbmQgdGhhdCDigJxhbGdvLWxpc3TigJ0gZG9lcyBu b3QgcmVwcmVzZW50IHRoZSBsaXN0LCBvbmx5IGEgc2luZ2xlIHZhbHVlIGluIHRoZSBsaXN0Lg0K DQpCdXQsIEkgdW5kZXJzdGFuZCB5b3VyIGNvbmZ1c2lvbiwgYW5kIGluIGZhY3QgSSB0aGluayDi gJ1hbGdvLWxpc3TigJ0gaXMgYSBsaXR0bGUgbWlzbGVhZGluZy4gSSB0aGluayBpdCB3b3VsZCBi ZSBiZXR0ZXIgdG8gY2FsbCBpdCDigJxhbGdvLXZhbHVl4oCdLCBvciBzb21ldGhpbmcgc2ltaWxh ci4NCg0Kb2MtYWxnbyAgICAgPSAib2MtYWxnbyIgRVFVQUwgRFFVT1RFIGFsZ28tdmFsdWUgKihD T01NQSBhbGdvLXZhbHVlKURRVU9URQ0KYWxnby12YWx1ZSAgID0gImxvc3MiIC8gKihvdGhlci1h bGdvKQ0Kb3RoZXItYWxnbyAgPSAleDQxLTVBIC8gJXg2MS03QSAvICV4MzAtMzkNCg0KUmVnYXJk cywNCg0KQ2hyaXN0ZXINCg0KDQoNCkzDpGhldHTDpGrDpDogc2lwLW92ZXJsb2FkLWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOnNp cC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnXSBQdW9sZXN0YSBZdSwgSmFtZXMNCkzDpGhldGV0 dHk6IDIyLiBoZWluw6RrdXV0YSAyMDEzIDIzOjEyDQpWYXN0YWFub3R0YWphOiBKYW5ldCBQIEd1 bm4NCktvcGlvOiBzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2lwLW92ZXJs b2FkLWJvdW5jZXNAaWV0Zi5vcmc+OyB2b2xrZXJoQGJlbGwtbGFicy5jb208bWFpbHRvOnZvbGtl cmhAYmVsbC1sYWJzLmNvbT47IHZrZ0BiZWxsLWxhYnMuY29tPG1haWx0bzp2a2dAYmVsbC1sYWJz LmNvbT47IHNpcC1vdmVybG9hZEBpZXRmLm9yZzxtYWlsdG86c2lwLW92ZXJsb2FkQGlldGYub3Jn PjsgaGdzQGNzLmNvbHVtYmlhLmVkdTxtYWlsdG86aGdzQGNzLmNvbHVtYmlhLmVkdT4NCkFpaGU6 IFJlOiBbc2lwLW92ZXJsb2FkXSBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1jb250cm9sLTEzDQoN CkphbmV0LA0KDQpNeSBjb21tZW50IGlzIG5vdCBvbiBoYXZpbmcgbXVsdGlwbGUgYWxnb3JpdGht cyBpbiB0aGUgdmlhIGhlYWRlciBidXQgb24gdGhlIHN5bnRheCBpbiB0aGUgY3VycmVudCBJLUQg dGhhdCBjb3VsZCBhbGxvdyBtdWx0aXBsZSBhbGdvcml0aG1zIHRoYXQgYXJlIG5vdCBzZXBhcmF0 ZWQgYnkg4oCcLOKAnS4gIFBsZWFzZSBjaGVjayB0aGUgc3ludGF4IGJ5IGhhdmluZyDigJxyYXRl 4oCdIGFuZCDigJxmb2/igJ0uDQoNCkphbWVzDQoNCkZyb206IEphbmV0IFAgR3VubiBbbWFpbHRv OmpndW5uNkBjc2MuY29tXQ0KU2VudDogTW9uZGF5LCBKdWx5IDIyLCAyMDEzIDM6NTQgUE0NClRv OiBZdSwgSmFtZXMNCkNjOiBoZ3NAY3MuY29sdW1iaWEuZWR1PG1haWx0bzpoZ3NAY3MuY29sdW1i aWEuZWR1PjsgdmtnQGJlbGwtbGFicy5jb208bWFpbHRvOnZrZ0BiZWxsLWxhYnMuY29tPjsgdm9s a2VyaEBiZWxsLWxhYnMuY29tPG1haWx0bzp2b2xrZXJoQGJlbGwtbGFicy5jb20+OyBzaXAtb3Zl cmxvYWQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5v cmc+OyBzaXAtb3ZlcmxvYWRAaWV0Zi5vcmc8bWFpbHRvOnNpcC1vdmVybG9hZEBpZXRmLm9yZz47 IHNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNl c0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc2lwLW92ZXJsb2FkXSBkcmFmdC1pZXRmLXNvYy1v dmVybG9hZC1jb250cm9sLTEzDQoNClRoZXJlIGlzIGF0IGxlYXN0IG9uZSAib3RoZXItYWxnbyIs ICJyYXRlIi4NCg0KV2hlbiBhbGdvLWxpc3QgaXMgaW5jbHVkZWQgaW4gdGhlIFZpYSBoZWFkZXJz IG9mIGEgbWVzc2FnZSBzZW50IGJ5IHRoZSBjbGllbnQgdG8gdGhlIHNlcnZlciwgaXQgbWF5IGhh dmUgbXVsdGlwbGUgYWxnb3JpdGhtcyBpbmNsdWRlZCBpbiB0aGUgYWxnby1saXN0IC0gYWxsIHRo ZSBhbGdvcml0aG1zIHN1cHBvcnRlZCBieSB0aGUgY2xpZW50Lg0KDQpXaGVuIGFsZ28tbGlzdCBp cyBpbmNsdWRlZCBpbiB0aGUgVmlhIGhlYWRlcnMgc2VudCBmcm9tIHRoZSBzZXJ2ZXIgdG8gdGhl IGNsaWVudCwgaXQgc2hvdWxkIGhhdmUgIiBvbmUgYW5kIG9ubHkgb25lIGFsZ29yaXRobSIgaW4g dGhlIGxpc3QuDQoNCkphbmV0DQoNCg0KDQoNCg0KRnJvbTogICAgICAgICJZdSwgSmFtZXMiIDxq YW1lcy55dUBuZXVzdGFyLmJpejxtYWlsdG86amFtZXMueXVAbmV1c3Rhci5iaXo+Pg0KVG86ICAg ICAgICAiaGdzQGNzLmNvbHVtYmlhLmVkdTxtYWlsdG86aGdzQGNzLmNvbHVtYmlhLmVkdT4iIDxo Z3NAY3MuY29sdW1iaWEuZWR1PG1haWx0bzpoZ3NAY3MuY29sdW1iaWEuZWR1Pj4sICJ2a2dAYmVs bC1sYWJzLmNvbTxtYWlsdG86dmtnQGJlbGwtbGFicy5jb20+IiA8dmtnQGJlbGwtbGFicy5jb208 bWFpbHRvOnZrZ0BiZWxsLWxhYnMuY29tPj4sICJ2b2xrZXJoQGJlbGwtbGFicy5jb208bWFpbHRv OnZvbGtlcmhAYmVsbC1sYWJzLmNvbT4iIDx2b2xrZXJoQGJlbGwtbGFicy5jb208bWFpbHRvOnZv bGtlcmhAYmVsbC1sYWJzLmNvbT4+DQpDYzogICAgICAgICJzaXAtb3ZlcmxvYWQtYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc+IiA8c2lwLW92ZXJs b2FkLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3Jn Pj4sICJzaXAtb3ZlcmxvYWRAaWV0Zi5vcmc8bWFpbHRvOnNpcC1vdmVybG9hZEBpZXRmLm9yZz4i IDxzaXAtb3ZlcmxvYWRAaWV0Zi5vcmc8bWFpbHRvOnNpcC1vdmVybG9hZEBpZXRmLm9yZz4+DQpE YXRlOiAgICAgICAgMDcvMjIvMjAxMyAwMzoxOSBQTQ0KU3ViamVjdDogICAgICAgIFtzaXAtb3Zl cmxvYWRdICBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1jb250cm9sLTEzDQpTZW50IGJ5OiAgICAg ICAgc2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNpcC1vdmVybG9hZC1ib3Vu Y2VzQGlldGYub3JnPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KDQoNCkhp LCBIZW5uaW5nLCBWaWpheSwgVm9sa2VyLA0KDQpXaGVuIEkgcmV2aWV3ZWQgZHJhZnQtaWV0Zi1z b2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLTA0LnR4dCwgSSBnbGFuY2VkIHRocm91Z2ggdGhlIHN5 bnRheCBpbiB0aGlzIEktRCB0byB1bmRlcnN0YW5kIHRoZSBvYyByZWxhdGVkIHBhcmFtZXRlcnMu DQoNCldoZW4gbG9va2luZyBhdCDigJxhbGdvLWxpc3TigJ0sIEkgd29uZGVyIGlmIHRoZXJlIGFy ZSB0d28g4oCcb3RoZXItYWxnb+KAnSBzdWNoIGFzIOKAnGFiY+KAnSBhbmQg4oCceHl64oCdLCDi gJhhYmPigJ0gYW5kIOKAnHh5euKAnSB3b27igJl0IGJlIGNvbW1hLXNlcGFyYXRlZCBiYXNlZCBv biB0aGUgb2MtYWxnbyBzeW50YXguICBJdCBzZWVtcyB0aGF0IGFsZ28tbGlzdCB3b3VsZCBiZQ0K DQogYWxnby1saXN0ID0g4oCcbG9zc+KAnCAvIG90aGVyLWFsZ28NCg0KVGhpcyB3b3VsZCBlbnN1 cmUgdGhhdCBvbmUgYW5kIG9ubHkgb25lIGFsZ29yaXRobSBpcyBwcmVzZW50IGluIGFsZ28tbGlz dC4gIElmIHRoZXJlIGlzIG5vIGFsZ29yaXRobSBvdGhlciB0aGFuIOKAnGxvc3PigJ0sICooQ09N TUEgYWxnby1saXN0KSB3b3VsZCB0YWtlIGNhcmUgb2YgdGhhdC4NCg0KU2luY2UgYWxnby1saXN0 IGNvbnRhaW5zIGEgc2luZ2xlIGFsZ29yaXRobSwgbWF5IGJlIGl0IGlzIGJldHRlciB0byB1c2Ug 4oCcYWxnb+KAnSBvbmx5LiAgT3IgaWYgYWxnby1saXN0IGNvbnRhaW5zIGEgbGlzdCBvZiBjb21t YSBzZXBhcmF0ZWQgYWxnb3JpdGhtcywgdGhlbiBhbG9nLWxpc3QgYW5kIG9jLWFsZ28gY2FuIGJl IG1vZGlmaWVkIHNvIHRoYXQgb2MtYWxnbyBoYXMgYSBzaW5nbGUg4oCcYWxnby1saXN04oCdLiAg VGhlIGxhdHRlciBtYXkgYmUgYmV0dGVyIGJlY2F1c2UgdGhlIGN1cnJlbnQgc3ludGF4IHdvdWxk IGFsbG93IHRoZSBzYW1lIGFsZ29yaXRobSB0byBhcHBlYXIgbW9yZSB0aGFuIG9uY2UuDQoNCkph bWVzX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpcC1v dmVybG9hZCBtYWlsaW5nIGxpc3QNCnNpcC1vdmVybG9hZEBpZXRmLm9yZzxtYWlsdG86c2lwLW92 ZXJsb2FkQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z aXAtb3ZlcmxvYWQNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpObyB2aXJ1cyBm b3VuZCBpbiB0aGlzIG1lc3NhZ2UuDQpDaGVja2VkIGJ5IEFWRyAtIHd3dy5hdmcuY29tPGh0dHA6 Ly93d3cuYXZnLmNvbT4NClZlcnNpb246IDIwMTMuMC4yOTA0IC8gVmlydXMgRGF0YWJhc2U6IDMy MDQvNjUxMCAtIFJlbGVhc2UgRGF0ZTogMDcvMjIvMTMNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpObyB2aXJ1cyBmb3VuZCBpbiB0aGlzIG1lc3NhZ2UuDQpDaGVja2VkIGJ5IEFW RyAtIHd3dy5hdmcuY29tPGh0dHA6Ly93d3cuYXZnLmNvbT4NClZlcnNpb246IDIwMTMuMC4yOTA0 IC8gVmlydXMgRGF0YWJhc2U6IDMyMDkvNjUzNiAtIFJlbGVhc2UgRGF0ZTogMDcvMzAvMTMNCg== --_000_7594FB04B1934943A5C02806D1A2204B1C41581AESESSMB209erics_ 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 MyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5v c2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TC1lc2ltdW90b2lsdHUgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCnR0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJTZWxpdGV0ZWtzdGkg Q2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4u SFRNTC1lc2ltdW90b2lsdHVDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MLWVzaW11b3RvaWx0 dSBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6SFRNTC1l c2ltdW90b2lsdHU7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLlNlbGl0ZXRl a3N0aUNoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlNlbGl0ZXRla3N0aSBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6U2VsaXRldGVrc3RpOw0KCWZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLkhUTUxQcmVmb3JtYXR0ZWQsIGxpLkhUTUxQ cmVmb3JtYXR0ZWQsIGRpdi5IVE1MUHJlZm9ybWF0dGVkDQoJe21zby1zdHlsZS1uYW1lOiJIVE1M IFByZWZvcm1hdHRlZCI7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkhUTUxQ cmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9y bWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpwLkJhbGxvb25UZXh0LCBsaS5CYWxs b29uVGV4dCwgZGl2LkJhbGxvb25UZXh0DQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQi Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQpzcGFuLlNoa3Bvc3RpdHl5bGkyNg0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0Kc3Bhbi5TaGtwb3N0aXR5eWxpMjcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNw YW4uU2hrcG9zdGl0eXlsaTI4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLlNoa3Bv c3RpdHl5bGkyOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBw dCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZJIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGksPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Tb3JyeSBmb3IgYSBsYXRlIHJl cGx5LiZuYnNwOyBJIHdhcyBqdXN0IGJhY2sgZnJvbQ0KIHZhY2F0aW9uLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYW0gd29uZGVyaW5n IGlmIGl0IHNob3VsZCBiZQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mZ3Q7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mZ3Q7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFs Z28tdmFsdWUgPSDigJxsb3Nz4oCdIC8gb3RoZXItYWxnbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmd0Ow0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+d2hlcmUgYWxnby12YWx1ZSB3b3Vs ZCBvbmx5IGNvbnRhaW4gYSBzaW5nbGUgYWxnb3JpdGhtIHZhbHVlIHN1Y2ggYXMg4oCcbG9zc+KA nSBvciBzb21ldGhpbmcgZWxzZS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+S2VlcCBpbiBtaW5kIHRoYXQgdGhlIGRlZmluaXRpb24gb2Ygb3RoZXItYWxnbyBpcyBv bmx5IGEgc2luZ2xlIGNoYXJhY3Rlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+QnV0LCB3ZSBjYW4gY2hhbmdlIG90aGVyLWFsZ28gdG86PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPm90aGVyLWFsZ28mbmJzcDsgPSAxKigleDQxLTVBIC8gJXg2MS03QSAv ICV4MzAtMzkpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKApndoaWNoIHBy b2JhYmx5IGNsYXJpZmllcyBldmVuIGZ1cnRoZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNo cmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBDaHJpc3RlciBIb2xtYmVyZyBbPGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVy aWNzc29uLmNvbSI+bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT5dDQo8 YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBKdWx5IDIyLCAyMDEzIDExOjU1IFBNPGJyPg0KPGI+ VG86PC9iPiBZdSwgSmFtZXM7IEphbmV0IFAgR3Vubjxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0i bWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnIj5zaXAtb3ZlcmxvYWQtYm91bmNl c0BpZXRmLm9yZzwvYT47DQo8YSBocmVmPSJtYWlsdG86dm9sa2VyaEBiZWxsLWxhYnMuY29tIj52 b2xrZXJoQGJlbGwtbGFicy5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86dmtnQGJlbGwtbGFicy5j b20iPg0KdmtnQGJlbGwtbGFicy5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86c2lwLW92ZXJsb2Fk QGlldGYub3JnIj5zaXAtb3ZlcmxvYWRAaWV0Zi5vcmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmhn c0Bjcy5jb2x1bWJpYS5lZHUiPmhnc0Bjcy5jb2x1bWJpYS5lZHU8L2E+PGJyPg0KPGI+U3ViamVj dDo8L2I+IFZTOiBbc2lwLW92ZXJsb2FkXSBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1jb250cm9s LTEzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBkb27igJl0IHRoaW5rIHRoZSBjdXJy ZW50IEFCTkYgYWxsb3dzIGEgbGlzdCB3aXRob3V0IGNvbW1hIHNlcGFyYXRpb24uIEtlZXAgaW4g bWluZCB0aGF0IOKAnGFsZ28tbGlzdOKAnSBkb2VzIG5vdCByZXByZXNlbnQgdGhlIGxpc3QsIG9u bHkgYSBzaW5nbGUNCiB2YWx1ZSBpbiB0aGUgbGlzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+QnV0LCBJIHVuZGVyc3RhbmQgeW91ciBjb25mdXNpb24sIGFuZCBpbiBmYWN0 IEkgdGhpbmsg4oCdYWxnby1saXN04oCdIGlzIGEgbGl0dGxlIG1pc2xlYWRpbmcuIEkgdGhpbmsg aXQgd291bGQgYmUgYmV0dGVyIHRvIGNhbGwgaXQNCjxiPuKAnGFsZ28tdmFsdWXigJ08L2I+LCBv ciBzb21ldGhpbmcgc2ltaWxhci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+b2MtYWxnbyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA9 ICZxdW90O29jLWFsZ28mcXVvdDsgRVFVQUwgRFFVT1RFIGFsZ28tdmFsdWUgKihDT01NQSBhbGdv LXZhbHVlKURRVU9URTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+YWxnby12YWx1ZSZuYnNwOyZuYnNwOyA9ICZxdW90O2xv c3MmcXVvdDsgLyAqKG90aGVyLWFsZ28pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5vdGhlci1hbGdvJm5ic3A7ID0gJXg0 MS01QSAvICV4NjEtN0EgLyAleDMwLTM5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNocmlzdGVy PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Mw6RoZXR0w6Rqw6Q6PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8YSBocmVmPSJtYWlsdG86c2lwLW92ZXJsb2Fk LWJvdW5jZXNAaWV0Zi5vcmciPnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPC9hPiBbPGEg aHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2lwLW92 ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+UHVvbGVzdGEgPC9iPll1LCBKYW1lczxi cj4NCjxiPkzDpGhldGV0dHk6PC9iPiAyMi4gaGVpbsOka3V1dGEgMjAxMyAyMzoxMjxicj4NCjxi PlZhc3RhYW5vdHRhamE6PC9iPiBKYW5ldCBQIEd1bm48YnI+DQo8Yj5Lb3Bpbzo8L2I+IDxhIGhy ZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZyI+c2lwLW92ZXJsb2FkLWJv dW5jZXNAaWV0Zi5vcmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOnZvbGtlcmhAYmVsbC1sYWJzLmNv bSI+dm9sa2VyaEBiZWxsLWxhYnMuY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnZrZ0BiZWxsLWxh YnMuY29tIj4NCnZrZ0BiZWxsLWxhYnMuY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVy bG9hZEBpZXRmLm9yZyI+c2lwLW92ZXJsb2FkQGlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0 bzpoZ3NAY3MuY29sdW1iaWEuZWR1Ij5oZ3NAY3MuY29sdW1iaWEuZWR1PC9hPjxicj4NCjxiPkFp aGU6PC9iPiBSZTogW3NpcC1vdmVybG9hZF0gZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtY29udHJv bC0xMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SmFuZXQs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk15IGNvbW1lbnQgaXMgbm90IG9u IGhhdmluZyBtdWx0aXBsZSBhbGdvcml0aG1zIGluIHRoZSB2aWEgaGVhZGVyIGJ1dCBvbiB0aGUg c3ludGF4IGluIHRoZSBjdXJyZW50IEktRCB0aGF0IGNvdWxkIGFsbG93IG11bHRpcGxlIGFsZ29y aXRobXMgdGhhdA0KIGFyZSBub3Qgc2VwYXJhdGVkIGJ5IOKAnCzigJ0uJm5ic3A7IFBsZWFzZSBj aGVjayB0aGUgc3ludGF4IGJ5IGhhdmluZyDigJxyYXRl4oCdIGFuZCDigJxmb2/igJ0uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkphbWVzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBKYW5ldCBQIEd1bm4gWzxhIGhyZWY9Im1h aWx0bzpqZ3VubjZAY3NjLmNvbSI+bWFpbHRvOmpndW5uNkBjc2MuY29tPC9hPl0NCjxicj4NCjxi PlNlbnQ6PC9iPiBNb25kYXksIEp1bHkgMjIsIDIwMTMgMzo1NCBQTTxicj4NCjxiPlRvOjwvYj4g WXUsIEphbWVzPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86aGdzQGNzLmNvbHVtYmlh LmVkdSI+aGdzQGNzLmNvbHVtYmlhLmVkdTwvYT47IDxhIGhyZWY9Im1haWx0bzp2a2dAYmVsbC1s YWJzLmNvbSI+DQp2a2dAYmVsbC1sYWJzLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzp2b2xrZXJo QGJlbGwtbGFicy5jb20iPnZvbGtlcmhAYmVsbC1sYWJzLmNvbTwvYT47DQo8YSBocmVmPSJtYWls dG86c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmciPnNpcC1vdmVybG9hZC1ib3VuY2VzQGll dGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmciPnNpcC1v dmVybG9hZEBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNl c0BpZXRmLm9yZyI+DQpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtzaXAtb3ZlcmxvYWRdIGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLWNv bnRyb2wtMTM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ VGhlcmUgaXMgYXQgbGVhc3Qgb25lICZxdW90O290aGVyLWFsZ28mcXVvdDssICZxdW90O3JhdGUm cXVvdDsuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4NCjxicj4NCjxicj4NCjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+V2hlbiBhbGdvLWxpc3QgaXMgaW5j bHVkZWQgaW4gdGhlIFZpYSBoZWFkZXJzIG9mIGEgbWVzc2FnZSBzZW50IGJ5IHRoZSBjbGllbnQg dG8gdGhlIHNlcnZlciwgaXQgbWF5IGhhdmUgbXVsdGlwbGUgYWxnb3JpdGhtcyBpbmNsdWRlZCBp biB0aGUgYWxnby1saXN0IC0gYWxsIHRoZSBhbGdvcml0aG1zIHN1cHBvcnRlZA0KIGJ5IHRoZSBj bGllbnQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4gPGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5XaGVuIGFsZ28tbGlzdCBpcyBpbmNs dWRlZCBpbiB0aGUgVmlhIGhlYWRlcnMgc2VudCBmcm9tIHRoZSBzZXJ2ZXIgdG8gdGhlIGNsaWVu dCwgaXQgc2hvdWxkIGhhdmUgJnF1b3Q7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4gb25lIGFu ZCBvbmx5IG9uZSBhbGdvcml0aG08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiZxdW90Ow0KIGluIHRoZSBsaXN0Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ IDxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+SmFuZXQ8YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4N Cjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3 LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiM1RjVGNUYiPkZyb206ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mcXVvdDtZdSwgSmFtZXMmcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzpqYW1lcy55dUBuZXVzdGFyLmJpeiI+amFtZXMueXVAbmV1 c3Rhci5iaXo8L2E+Jmd0Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+DQo8YnI+DQo8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNUY1RjVGIj5Ubzog Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiZxdW90OzxhIGhyZWY9Im1haWx0bzpoZ3NAY3MuY29sdW1iaWEuZWR1 Ij5oZ3NAY3MuY29sdW1iaWEuZWR1PC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhnc0Bj cy5jb2x1bWJpYS5lZHUiPmhnc0Bjcy5jb2x1bWJpYS5lZHU8L2E+Jmd0OywNCiAmcXVvdDs8YSBo cmVmPSJtYWlsdG86dmtnQGJlbGwtbGFicy5jb20iPnZrZ0BiZWxsLWxhYnMuY29tPC9hPiZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZrZ0BiZWxsLWxhYnMuY29tIj52a2dAYmVsbC1sYWJzLmNv bTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86dm9sa2VyaEBiZWxsLWxhYnMuY29tIj52 b2xrZXJoQGJlbGwtbGFicy5jb208L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86dm9sa2Vy aEBiZWxsLWxhYnMuY29tIj52b2xrZXJoQGJlbGwtbGFicy5jb208L2E+Jmd0Ozwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojNUY1RjVGIj5DYzogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZxdW90OzxhIGhy ZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZyI+c2lwLW92ZXJsb2FkLWJv dW5jZXNAaWV0Zi5vcmc8L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1haWx0bzpzaXAtb3Zlcmxv YWQtYm91bmNlc0BpZXRmLm9yZyI+c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0 OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZEBpZXRmLm9yZyI+c2lwLW92ZXJs b2FkQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZEBp ZXRmLm9yZyI+c2lwLW92ZXJsb2FkQGlldGYub3JnPC9hPiZndDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzVGNUY1RiI+RGF0ZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjA3LzIyLzIwMTMgMDM6MTkg UE08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzVGNUY1RiI+U3ViamVjdDogJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPltzaXAtb3ZlcmxvYWRdICZuYnNwO2RyYWZ0LWlldGYtc29jLW92ZXJsb2FkLWNvbnRy b2wtMTM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzVGNUY1RiI+U2VudCBieTogJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxhIGhyZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZyI+ c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249 ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBsYW5nPSJFTi1VUyI+DQo8 aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIG5vc2hhZGU9IiIgc3R5bGU9ImNvbG9yOiNBMEEwQTAi IGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0K PGJyPg0KSGksIEhlbm5pbmcsIFZpamF5LCBWb2xrZXIsIDxicj4NCiZuYnNwOyA8YnI+DQpXaGVu IEkgcmV2aWV3ZWQgZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLTA0LnR4dCwg SSBnbGFuY2VkIHRocm91Z2ggdGhlIHN5bnRheCBpbiB0aGlzIEktRCB0byB1bmRlcnN0YW5kIHRo ZSBvYyByZWxhdGVkIHBhcmFtZXRlcnMuDQo8YnI+DQombmJzcDsgPGJyPg0KV2hlbiBsb29raW5n IGF0IOKAnGFsZ28tbGlzdOKAnSwgSSB3b25kZXIgaWYgdGhlcmUgYXJlIHR3byDigJxvdGhlci1h bGdv4oCdIHN1Y2ggYXMg4oCcYWJj4oCdIGFuZCDigJx4eXrigJ0sIOKAmGFiY+KAnSBhbmQg4oCc eHl64oCdIHdvbuKAmXQgYmUgY29tbWEtc2VwYXJhdGVkIGJhc2VkIG9uIHRoZSBvYy1hbGdvIHN5 bnRheC4gJm5ic3A7SXQgc2VlbXMgdGhhdCBhbGdvLWxpc3Qgd291bGQgYmUNCjxicj4NCiZuYnNw OyA8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7YWxnby1saXN0ID0gPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj7igJw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+bG9zczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+4oCc PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiAvIG90aGVyLWFsZ288L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPg0KPGJy Pg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+DQo8YnI+DQpU aGlzIHdvdWxkIGVuc3VyZSB0aGF0IG9uZSBhbmQgb25seSBvbmUgYWxnb3JpdGhtIGlzIHByZXNl bnQgaW4gYWxnby1saXN0LiAmbmJzcDtJZiB0aGVyZSBpcyBubyBhbGdvcml0aG0gb3RoZXIgdGhh biDigJxsb3Nz4oCdLCAqKENPTU1BIGFsZ28tbGlzdCkgd291bGQgdGFrZSBjYXJlIG9mIHRoYXQu DQo8YnI+DQombmJzcDsgPGJyPg0KU2luY2UgYWxnby1saXN0IGNvbnRhaW5zIGEgc2luZ2xlIGFs Z29yaXRobSwgbWF5IGJlIGl0IGlzIGJldHRlciB0byB1c2Ug4oCcYWxnb+KAnSBvbmx5LiAmbmJz cDtPciBpZiBhbGdvLWxpc3QgY29udGFpbnMgYSBsaXN0IG9mIGNvbW1hIHNlcGFyYXRlZCBhbGdv cml0aG1zLCB0aGVuIGFsb2ctbGlzdCBhbmQgb2MtYWxnbyBjYW4gYmUgbW9kaWZpZWQgc28gdGhh dCBvYy1hbGdvIGhhcyBhIHNpbmdsZSDigJxhbGdvLWxpc3TigJ0uICZuYnNwO1RoZSBsYXR0ZXIg bWF5IGJlIGJldHRlcg0KIGJlY2F1c2UgdGhlIGN1cnJlbnQgc3ludGF4IHdvdWxkIGFsbG93IHRo ZSBzYW1lIGFsZ29yaXRobSB0byBhcHBlYXIgbW9yZSB0aGFuIG9uY2UuDQo8YnI+DQombmJzcDsg PGJyPg0KSmFtZXM8L3NwYW4+PHR0PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 L3NwYW4+PC90dD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD5zaXAtb3ZlcmxvYWQg bWFpbGluZyBsaXN0PC90dD48YnI+DQo8dHQ+PGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZEBp ZXRmLm9yZyI+c2lwLW92ZXJsb2FkQGlldGYub3JnPC9hPjwvdHQ+PGJyPg0KPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NpcC1vdmVybG9hZCI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcC1vdmVybG9hZDwvc3Bhbj48L3R0 PjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu PSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PHNwYW4gbGFuZz0iRU4tVVMiPg0K PGhyIHNpemU9IjEiIHdpZHRoPSIxMDAlIiBub3NoYWRlPSIiIHN0eWxlPSJjb2xvcjojQTBBMEEw IiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiPk5vIHZpcnVzIGZvdW5kIGluIHRoaXMgbWVzc2FnZS48YnI+DQpD aGVja2VkIGJ5IEFWRyAtIDxhIGhyZWY9Imh0dHA6Ly93d3cuYXZnLmNvbSI+d3d3LmF2Zy5jb208 L2E+PGJyPg0KVmVyc2lvbjogMjAxMy4wLjI5MDQgLyBWaXJ1cyBEYXRhYmFzZTogMzIwNC82NTEw IC0gUmVsZWFzZSBEYXRlOiAwNy8yMi8xMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgY2xh c3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4N CjxociBzaXplPSIxIiB3aWR0aD0iMTAwJSIgbm9zaGFkZT0iIiBzdHlsZT0iY29sb3I6I0EwQTBB MCIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Tm8gdmly dXMgZm91bmQgaW4gdGhpcyBtZXNzYWdlLjxicj4NCkNoZWNrZWQgYnkgQVZHIC0gPGEgaHJlZj0i aHR0cDovL3d3dy5hdmcuY29tIj53d3cuYXZnLmNvbTwvYT48YnI+DQpWZXJzaW9uOiAyMDEzLjAu MjkwNCAvIFZpcnVzIERhdGFiYXNlOiAzMjA5LzY1MzYgLSBSZWxlYXNlIERhdGU6IDA3LzMwLzEz PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B1C41581AESESSMB209erics_-- From james.yu@neustar.biz Wed Jul 31 11:05:56 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 95ADE11E819F; Wed, 31 Jul 2013 11:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBvEW9w0ZsHG; Wed, 31 Jul 2013 11:05:52 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 58BFF11E8186; Wed, 31 Jul 2013 11:05:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1375293849; x=1690650383; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=A/ubhWAKANqZo27F2emU9QfpM/VgAAWisrIbiGJBtVw=; b=m6H3eZpJIIxSfMiu/jwjDZqCKuBeo10mr4sQJ6wXl1OVHgKJEQhQReNP0x6953 mipiwrTtbT12Og+SgmUxZD9A== Received: from ([10.31.58.70]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.21809743; Wed, 31 Jul 2013 14:04:07 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.95]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Wed, 31 Jul 2013 14:05:26 -0400 From: "Yu, James" To: Christer Holmberg Thread-Topic: [sip-overload] draft-ietf-soc-overload-control-13 Thread-Index: AQHOh1hieKRy9s++6U21x6LAxw4G95l+2MqAgABVToD///QlMA== Date: Wed, 31 Jul 2013 18:05:26 +0000 Message-ID: <56FB15AFE08E1242B0736CBDCE6E8561080A51DC@STNTEXMB10.cis.neustar.com> References: <56FB15AFE08E1242B0736CBDCE6E85610808C32F@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610808EF90@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E856108096C00@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E856108096C3D@stntexmb12.cis.neustar.com> <7594FB04B1934943A5C02806D1A2204B1C3FC99D@ESESSMB209.ericsson.se> <56FB15AFE08E1242B0736CBDCE6E8561080A4D90@STNTEXMB10.cis.neustar.com> <7594FB04B1934943A5C02806D1A2204B1C41581A@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C41581A@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.31.33.140] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: sM9GhtFENKVUki6eshSViA== Content-Type: multipart/alternative; boundary="_000_56FB15AFE08E1242B0736CBDCE6E8561080A51DCSTNTEXMB10cisne_" MIME-Version: 1.0 Cc: "sip-overload-bounces@ietf.org" , "volkerh@bell-labs.com" , "vkg@bell-labs.com" , "sip-overload@ietf.org" , "hgs@cs.columbia.edu" Subject: Re: [sip-overload] draft-ietf-soc-overload-control-13 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, 31 Jul 2013 18:05:56 -0000 --_000_56FB15AFE08E1242B0736CBDCE6E8561080A51DCSTNTEXMB10cisne_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIHRoZSBjaGFuZ2UuDQoNCkphbWVzDQoNCkZyb206IENocmlzdGVyIEhvbG1i ZXJnIFttYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tXQ0KU2VudDogV2VkbmVz ZGF5LCBKdWx5IDMxLCAyMDEzIDEwOjQ3IEFNDQpUbzogWXUsIEphbWVzDQpDYzogc2lwLW92ZXJs b2FkLWJvdW5jZXNAaWV0Zi5vcmc7IHZvbGtlcmhAYmVsbC1sYWJzLmNvbTsgdmtnQGJlbGwtbGFi cy5jb207IHNpcC1vdmVybG9hZEBpZXRmLm9yZzsgaGdzQGNzLmNvbHVtYmlhLmVkdQ0KU3ViamVj dDogVlM6IFtzaXAtb3ZlcmxvYWRdIGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLWNvbnRyb2wtMTMN Cg0KSGksDQoNCj5Tb3JyeSBmb3IgYSBsYXRlIHJlcGx5LiAgSSB3YXMganVzdCBiYWNrIGZyb20g dmFjYXRpb24uDQo+DQo+SSBhbSB3b25kZXJpbmcgaWYgaXQgc2hvdWxkIGJlDQo+DQo+ICAgICAg IGFsZ28tdmFsdWUgPSDigJxsb3Nz4oCdIC8gb3RoZXItYWxnbw0KPg0KPiB3aGVyZSBhbGdvLXZh bHVlIHdvdWxkIG9ubHkgY29udGFpbiBhIHNpbmdsZSBhbGdvcml0aG0gdmFsdWUgc3VjaCBhcyDi gJxsb3Nz4oCdIG9yIHNvbWV0aGluZyBlbHNlLg0KDQpLZWVwIGluIG1pbmQgdGhhdCB0aGUgZGVm aW5pdGlvbiBvZiBvdGhlci1hbGdvIGlzIG9ubHkgYSBzaW5nbGUgY2hhcmFjdGVyLg0KDQpCdXQs IHdlIGNhbiBjaGFuZ2Ugb3RoZXItYWxnbyB0bzoNCg0Kb3RoZXItYWxnbyAgPSAxKigleDQxLTVB IC8gJXg2MS03QSAvICV4MzAtMzkpDQoNCuKApndoaWNoIHByb2JhYmx5IGNsYXJpZmllcyBldmVu IGZ1cnRoZXIuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KRnJvbTogQ2hyaXN0ZXIgSG9s bWJlcmcgW21haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb21dDQpTZW50OiBNb25k YXksIEp1bHkgMjIsIDIwMTMgMTE6NTUgUE0NClRvOiBZdSwgSmFtZXM7IEphbmV0IFAgR3Vubg0K Q2M6IHNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzaXAtb3ZlcmxvYWQtYm91 bmNlc0BpZXRmLm9yZz47IHZvbGtlcmhAYmVsbC1sYWJzLmNvbTxtYWlsdG86dm9sa2VyaEBiZWxs LWxhYnMuY29tPjsgdmtnQGJlbGwtbGFicy5jb208bWFpbHRvOnZrZ0BiZWxsLWxhYnMuY29tPjsg c2lwLW92ZXJsb2FkQGlldGYub3JnPG1haWx0bzpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmc+OyBoZ3NA Y3MuY29sdW1iaWEuZWR1PG1haWx0bzpoZ3NAY3MuY29sdW1iaWEuZWR1Pg0KU3ViamVjdDogVlM6 IFtzaXAtb3ZlcmxvYWRdIGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLWNvbnRyb2wtMTMNCg0KSGks DQoNCkkgZG9u4oCZdCB0aGluayB0aGUgY3VycmVudCBBQk5GIGFsbG93cyBhIGxpc3Qgd2l0aG91 dCBjb21tYSBzZXBhcmF0aW9uLiBLZWVwIGluIG1pbmQgdGhhdCDigJxhbGdvLWxpc3TigJ0gZG9l cyBub3QgcmVwcmVzZW50IHRoZSBsaXN0LCBvbmx5IGEgc2luZ2xlIHZhbHVlIGluIHRoZSBsaXN0 Lg0KDQpCdXQsIEkgdW5kZXJzdGFuZCB5b3VyIGNvbmZ1c2lvbiwgYW5kIGluIGZhY3QgSSB0aGlu ayDigJ1hbGdvLWxpc3TigJ0gaXMgYSBsaXR0bGUgbWlzbGVhZGluZy4gSSB0aGluayBpdCB3b3Vs ZCBiZSBiZXR0ZXIgdG8gY2FsbCBpdCDigJxhbGdvLXZhbHVl4oCdLCBvciBzb21ldGhpbmcgc2lt aWxhci4NCg0Kb2MtYWxnbyAgICAgPSAib2MtYWxnbyIgRVFVQUwgRFFVT1RFIGFsZ28tdmFsdWUg KihDT01NQSBhbGdvLXZhbHVlKURRVU9URQ0KYWxnby12YWx1ZSAgID0gImxvc3MiIC8gKihvdGhl ci1hbGdvKQ0Kb3RoZXItYWxnbyAgPSAleDQxLTVBIC8gJXg2MS03QSAvICV4MzAtMzkNCg0KUmVn YXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCkzDpGhldHTDpGrDpDogc2lwLW92ZXJsb2FkLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRv OnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnXSBQdW9sZXN0YSBZdSwgSmFtZXMNCkzDpGhl dGV0dHk6IDIyLiBoZWluw6RrdXV0YSAyMDEzIDIzOjEyDQpWYXN0YWFub3R0YWphOiBKYW5ldCBQ IEd1bm4NCktvcGlvOiBzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2lwLW92 ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc+OyB2b2xrZXJoQGJlbGwtbGFicy5jb208bWFpbHRvOnZv bGtlcmhAYmVsbC1sYWJzLmNvbT47IHZrZ0BiZWxsLWxhYnMuY29tPG1haWx0bzp2a2dAYmVsbC1s YWJzLmNvbT47IHNpcC1vdmVybG9hZEBpZXRmLm9yZzxtYWlsdG86c2lwLW92ZXJsb2FkQGlldGYu b3JnPjsgaGdzQGNzLmNvbHVtYmlhLmVkdTxtYWlsdG86aGdzQGNzLmNvbHVtYmlhLmVkdT4NCkFp aGU6IFJlOiBbc2lwLW92ZXJsb2FkXSBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1jb250cm9sLTEz DQoNCkphbmV0LA0KDQpNeSBjb21tZW50IGlzIG5vdCBvbiBoYXZpbmcgbXVsdGlwbGUgYWxnb3Jp dGhtcyBpbiB0aGUgdmlhIGhlYWRlciBidXQgb24gdGhlIHN5bnRheCBpbiB0aGUgY3VycmVudCBJ LUQgdGhhdCBjb3VsZCBhbGxvdyBtdWx0aXBsZSBhbGdvcml0aG1zIHRoYXQgYXJlIG5vdCBzZXBh cmF0ZWQgYnkg4oCcLOKAnS4gIFBsZWFzZSBjaGVjayB0aGUgc3ludGF4IGJ5IGhhdmluZyDigJxy YXRl4oCdIGFuZCDigJxmb2/igJ0uDQoNCkphbWVzDQoNCkZyb206IEphbmV0IFAgR3VubiBbbWFp bHRvOmpndW5uNkBjc2MuY29tXQ0KU2VudDogTW9uZGF5LCBKdWx5IDIyLCAyMDEzIDM6NTQgUE0N ClRvOiBZdSwgSmFtZXMNCkNjOiBoZ3NAY3MuY29sdW1iaWEuZWR1PG1haWx0bzpoZ3NAY3MuY29s dW1iaWEuZWR1PjsgdmtnQGJlbGwtbGFicy5jb208bWFpbHRvOnZrZ0BiZWxsLWxhYnMuY29tPjsg dm9sa2VyaEBiZWxsLWxhYnMuY29tPG1haWx0bzp2b2xrZXJoQGJlbGwtbGFicy5jb20+OyBzaXAt b3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0 Zi5vcmc+OyBzaXAtb3ZlcmxvYWRAaWV0Zi5vcmc8bWFpbHRvOnNpcC1vdmVybG9hZEBpZXRmLm9y Zz47IHNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzaXAtb3ZlcmxvYWQtYm91 bmNlc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc2lwLW92ZXJsb2FkXSBkcmFmdC1pZXRmLXNv Yy1vdmVybG9hZC1jb250cm9sLTEzDQoNClRoZXJlIGlzIGF0IGxlYXN0IG9uZSAib3RoZXItYWxn byIsICJyYXRlIi4NCg0KV2hlbiBhbGdvLWxpc3QgaXMgaW5jbHVkZWQgaW4gdGhlIFZpYSBoZWFk ZXJzIG9mIGEgbWVzc2FnZSBzZW50IGJ5IHRoZSBjbGllbnQgdG8gdGhlIHNlcnZlciwgaXQgbWF5 IGhhdmUgbXVsdGlwbGUgYWxnb3JpdGhtcyBpbmNsdWRlZCBpbiB0aGUgYWxnby1saXN0IC0gYWxs IHRoZSBhbGdvcml0aG1zIHN1cHBvcnRlZCBieSB0aGUgY2xpZW50Lg0KDQpXaGVuIGFsZ28tbGlz dCBpcyBpbmNsdWRlZCBpbiB0aGUgVmlhIGhlYWRlcnMgc2VudCBmcm9tIHRoZSBzZXJ2ZXIgdG8g dGhlIGNsaWVudCwgaXQgc2hvdWxkIGhhdmUgIiBvbmUgYW5kIG9ubHkgb25lIGFsZ29yaXRobSIg aW4gdGhlIGxpc3QuDQoNCkphbmV0DQoNCg0KDQoNCg0KRnJvbTogICAgICAgICJZdSwgSmFtZXMi IDxqYW1lcy55dUBuZXVzdGFyLmJpejxtYWlsdG86amFtZXMueXVAbmV1c3Rhci5iaXo+Pg0KVG86 ICAgICAgICAiaGdzQGNzLmNvbHVtYmlhLmVkdTxtYWlsdG86aGdzQGNzLmNvbHVtYmlhLmVkdT4i IDxoZ3NAY3MuY29sdW1iaWEuZWR1PG1haWx0bzpoZ3NAY3MuY29sdW1iaWEuZWR1Pj4sICJ2a2dA YmVsbC1sYWJzLmNvbTxtYWlsdG86dmtnQGJlbGwtbGFicy5jb20+IiA8dmtnQGJlbGwtbGFicy5j b208bWFpbHRvOnZrZ0BiZWxsLWxhYnMuY29tPj4sICJ2b2xrZXJoQGJlbGwtbGFicy5jb208bWFp bHRvOnZvbGtlcmhAYmVsbC1sYWJzLmNvbT4iIDx2b2xrZXJoQGJlbGwtbGFicy5jb208bWFpbHRv OnZvbGtlcmhAYmVsbC1sYWJzLmNvbT4+DQpDYzogICAgICAgICJzaXAtb3ZlcmxvYWQtYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc+IiA8c2lwLW92 ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYu b3JnPj4sICJzaXAtb3ZlcmxvYWRAaWV0Zi5vcmc8bWFpbHRvOnNpcC1vdmVybG9hZEBpZXRmLm9y Zz4iIDxzaXAtb3ZlcmxvYWRAaWV0Zi5vcmc8bWFpbHRvOnNpcC1vdmVybG9hZEBpZXRmLm9yZz4+ DQpEYXRlOiAgICAgICAgMDcvMjIvMjAxMyAwMzoxOSBQTQ0KU3ViamVjdDogICAgICAgIFtzaXAt b3ZlcmxvYWRdICBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1jb250cm9sLTEzDQpTZW50IGJ5OiAg ICAgICAgc2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNpcC1vdmVybG9hZC1i b3VuY2VzQGlldGYub3JnPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KDQoN CkhpLCBIZW5uaW5nLCBWaWpheSwgVm9sa2VyLA0KDQpXaGVuIEkgcmV2aWV3ZWQgZHJhZnQtaWV0 Zi1zb2Mtb3ZlcmxvYWQtcmF0ZS1jb250cm9sLTA0LnR4dCwgSSBnbGFuY2VkIHRocm91Z2ggdGhl IHN5bnRheCBpbiB0aGlzIEktRCB0byB1bmRlcnN0YW5kIHRoZSBvYyByZWxhdGVkIHBhcmFtZXRl cnMuDQoNCldoZW4gbG9va2luZyBhdCDigJxhbGdvLWxpc3TigJ0sIEkgd29uZGVyIGlmIHRoZXJl IGFyZSB0d28g4oCcb3RoZXItYWxnb+KAnSBzdWNoIGFzIOKAnGFiY+KAnSBhbmQg4oCceHl64oCd LCDigJhhYmPigJ0gYW5kIOKAnHh5euKAnSB3b27igJl0IGJlIGNvbW1hLXNlcGFyYXRlZCBiYXNl ZCBvbiB0aGUgb2MtYWxnbyBzeW50YXguICBJdCBzZWVtcyB0aGF0IGFsZ28tbGlzdCB3b3VsZCBi ZQ0KDQogYWxnby1saXN0ID0g4oCcbG9zc+KAnCAvIG90aGVyLWFsZ28NCg0KVGhpcyB3b3VsZCBl bnN1cmUgdGhhdCBvbmUgYW5kIG9ubHkgb25lIGFsZ29yaXRobSBpcyBwcmVzZW50IGluIGFsZ28t bGlzdC4gIElmIHRoZXJlIGlzIG5vIGFsZ29yaXRobSBvdGhlciB0aGFuIOKAnGxvc3PigJ0sICoo Q09NTUEgYWxnby1saXN0KSB3b3VsZCB0YWtlIGNhcmUgb2YgdGhhdC4NCg0KU2luY2UgYWxnby1s aXN0IGNvbnRhaW5zIGEgc2luZ2xlIGFsZ29yaXRobSwgbWF5IGJlIGl0IGlzIGJldHRlciB0byB1 c2Ug4oCcYWxnb+KAnSBvbmx5LiAgT3IgaWYgYWxnby1saXN0IGNvbnRhaW5zIGEgbGlzdCBvZiBj b21tYSBzZXBhcmF0ZWQgYWxnb3JpdGhtcywgdGhlbiBhbG9nLWxpc3QgYW5kIG9jLWFsZ28gY2Fu IGJlIG1vZGlmaWVkIHNvIHRoYXQgb2MtYWxnbyBoYXMgYSBzaW5nbGUg4oCcYWxnby1saXN04oCd LiAgVGhlIGxhdHRlciBtYXkgYmUgYmV0dGVyIGJlY2F1c2UgdGhlIGN1cnJlbnQgc3ludGF4IHdv dWxkIGFsbG93IHRoZSBzYW1lIGFsZ29yaXRobSB0byBhcHBlYXIgbW9yZSB0aGFuIG9uY2UuDQoN CkphbWVzX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNp cC1vdmVybG9hZCBtYWlsaW5nIGxpc3QNCnNpcC1vdmVybG9hZEBpZXRmLm9yZzxtYWlsdG86c2lw LW92ZXJsb2FkQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zaXAtb3ZlcmxvYWQNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpObyB2aXJ1 cyBmb3VuZCBpbiB0aGlzIG1lc3NhZ2UuDQpDaGVja2VkIGJ5IEFWRyAtIHd3dy5hdmcuY29tPGh0 dHA6Ly93d3cuYXZnLmNvbT4NClZlcnNpb246IDIwMTMuMC4yOTA0IC8gVmlydXMgRGF0YWJhc2U6 IDMyMDQvNjUxMCAtIFJlbGVhc2UgRGF0ZTogMDcvMjIvMTMNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpObyB2aXJ1cyBmb3VuZCBpbiB0aGlzIG1lc3NhZ2UuDQpDaGVja2VkIGJ5 IEFWRyAtIHd3dy5hdmcuY29tPGh0dHA6Ly93d3cuYXZnLmNvbT4NClZlcnNpb246IDIwMTMuMC4y OTA0IC8gVmlydXMgRGF0YWJhc2U6IDMyMDkvNjUzNiAtIFJlbGVhc2UgRGF0ZTogMDcvMzAvMTMN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpObyB2aXJ1cyBmb3VuZCBpbiB0aGlz IG1lc3NhZ2UuDQpDaGVja2VkIGJ5IEFWRyAtIHd3dy5hdmcuY29tPGh0dHA6Ly93d3cuYXZnLmNv bT4NClZlcnNpb246IDIwMTMuMC4yOTA0IC8gVmlydXMgRGF0YWJhc2U6IDMyMDkvNjUzNiAtIFJl bGVhc2UgRGF0ZTogMDcvMzAvMTMNCg== --_000_56FB15AFE08E1242B0736CBDCE6E8561080A51DCSTNTEXMB10cisne_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQp0dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRh dGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsInNlcmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1l OiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9 DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENo YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBU ZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KcC5IVE1MLWVzaW11 b3RvaWx0dSwgbGkuSFRNTC1lc2ltdW90b2lsdHUsIGRpdi5IVE1MLWVzaW11b3RvaWx0dQ0KCXtt c28tc3R5bGUtbmFtZTpIVE1MLWVzaW11b3RvaWx0dTsNCgltc28tc3R5bGUtbGluazoiSFRNTC1l c2ltdW90b2lsdHUgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2Vy aWYiO30NCnNwYW4uSFRNTC1lc2ltdW90b2lsdHVDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1M LWVzaW11b3RvaWx0dSBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6SFRNTC1lc2ltdW90b2lsdHU7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpw LlNlbGl0ZXRla3N0aSwgbGkuU2VsaXRldGVrc3RpLCBkaXYuU2VsaXRldGVrc3RpDQoJe21zby1z dHlsZS1uYW1lOlNlbGl0ZXRla3N0aTsNCgltc28tc3R5bGUtbGluazoiU2VsaXRldGVrc3RpIENo YXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLlNl bGl0ZXRla3N0aUNoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlNlbGl0ZXRla3N0aSBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6U2VsaXRldGVrc3RpOw0KCWZv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjcNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQpzcGFuLkVtYWlsU3R5bGUyOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFp bFN0eWxlMzANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB3aXRoIHRoZSBj aGFuZ2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5KYW1lczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IENocmlzdGVyIEhvbG1i ZXJnIFttYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tXQ0KPGJyPg0KPGI+U2Vu dDo8L2I+IFdlZG5lc2RheSwgSnVseSAzMSwgMjAxMyAxMDo0NyBBTTxicj4NCjxiPlRvOjwvYj4g WXUsIEphbWVzPGJyPg0KPGI+Q2M6PC9iPiBzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzsg dm9sa2VyaEBiZWxsLWxhYnMuY29tOyB2a2dAYmVsbC1sYWJzLmNvbTsgc2lwLW92ZXJsb2FkQGll dGYub3JnOyBoZ3NAY3MuY29sdW1iaWEuZWR1PGJyPg0KPGI+U3ViamVjdDo8L2I+IFZTOiBbc2lw LW92ZXJsb2FkXSBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1jb250cm9sLTEzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRkkiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDtTb3JyeSBm b3IgYSBsYXRlIHJlcGx5LiZuYnNwOyBJIHdhcyBqdXN0IGJhY2sgZnJvbSB2YWNhdGlvbi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mZ3Q7SSBhbSB3b25kZXJpbmcgaWYgaXQgc2hvdWxkIGJlDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFsZ28tdmFsdWUg PSDigJxsb3Nz4oCdIC8gb3RoZXItYWxnbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m Z3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDsgd2hlcmUgYWxnby12 YWx1ZSB3b3VsZCBvbmx5IGNvbnRhaW4gYSBzaW5nbGUgYWxnb3JpdGhtIHZhbHVlIHN1Y2ggYXMg 4oCcbG9zc+KAnSBvciBzb21ldGhpbmcgZWxzZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPktlZXAgaW4gbWluZCB0aGF0 IHRoZSBkZWZpbml0aW9uIG9mIG90aGVyLWFsZ28gaXMgb25seSBhIHNpbmdsZSBjaGFyYWN0ZXIu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5CdXQsIHdlIGNhbiBjaGFuZ2Ugb3RoZXItYWxnbyB0bzo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPm90 aGVyLWFsZ28mbmJzcDsgPSAxKigleDQxLTVBIC8gJXg2MS03QSAvICV4MzAtMzkpPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij7igKZ3aGljaCBwcm9iYWJseSBjbGFyaWZpZXMgZXZlbiBmdXJ0aGVyLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVn YXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IENocmlzdGVyIEhvbG1iZXJnIFs8YSBocmVmPSJtYWls dG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIj5tYWlsdG86Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEp1bHkgMjIs IDIwMTMgMTE6NTUgUE08YnI+DQo8Yj5Ubzo8L2I+IFl1LCBKYW1lczsgSmFuZXQgUCBHdW5uPGJy Pg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5v cmciPnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0bzp2 b2xrZXJoQGJlbGwtbGFicy5jb20iPnZvbGtlcmhAYmVsbC1sYWJzLmNvbTwvYT47IDxhIGhyZWY9 Im1haWx0bzp2a2dAYmVsbC1sYWJzLmNvbSI+DQp2a2dAYmVsbC1sYWJzLmNvbTwvYT47IDxhIGhy ZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmciPnNpcC1vdmVybG9hZEBpZXRmLm9yZzwv YT47DQo8YSBocmVmPSJtYWlsdG86aGdzQGNzLmNvbHVtYmlhLmVkdSI+aGdzQGNzLmNvbHVtYmlh LmVkdTwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gVlM6IFtzaXAtb3ZlcmxvYWRdIGRyYWZ0LWll dGYtc29jLW92ZXJsb2FkLWNvbnRyb2wtMTM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGSSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkZJIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZG9u4oCZdCB0aGluayB0aGUg Y3VycmVudCBBQk5GIGFsbG93cyBhIGxpc3Qgd2l0aG91dCBjb21tYSBzZXBhcmF0aW9uLiBLZWVw IGluIG1pbmQgdGhhdCDigJxhbGdvLWxpc3TigJ0gZG9lcyBub3QgcmVwcmVzZW50IHRoZSBsaXN0 LCBvbmx5IGEgc2luZ2xlIHZhbHVlIGluIHRoZQ0KIGxpc3QuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CdXQsIEkgdW5k ZXJzdGFuZCB5b3VyIGNvbmZ1c2lvbiwgYW5kIGluIGZhY3QgSSB0aGluayDigJ1hbGdvLWxpc3Ti gJ0gaXMgYSBsaXR0bGUgbWlzbGVhZGluZy4gSSB0aGluayBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8g Y2FsbCBpdA0KPGI+4oCcYWxnby12YWx1ZeKAnTwvYj4sIG9yIHNvbWV0aGluZyBzaW1pbGFyLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+b2MtYWxnbyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA9ICZxdW90O29jLWFsZ28mcXVvdDsgRVFVQUwgRFFVT1RFIGFsZ28tdmFsdWUgKihD T01NQSBhbGdvLXZhbHVlKURRVU9URTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij5hbGdvLXZhbHVlJm5ic3A7Jm5ic3A7ID0gJnF1b3Q7bG9zcyZx dW90OyAvICoob3RoZXItYWxnbyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+b3RoZXItYWxnbyZuYnNwOyA9ICV4NDEtNUEgLyAleDYxLTdBIC8g JXgzMC0zOTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNocmlzdGVyPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIGxhbmc9IkZJIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+TMOkaGV0dMOk asOkOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRkkiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjxh IGhyZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZyI+c2lwLW92ZXJsb2Fk LWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFs8YSBocmVmPSJtYWlsdG86c2lwLW92ZXJsb2FkLWJvdW5j ZXNAaWV0Zi5vcmciPm1haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8 Yj5QdW9sZXN0YSA8L2I+WXUsIEphbWVzPGJyPg0KPGI+TMOkaGV0ZXR0eTo8L2I+IDIyLiBoZWlu w6RrdXV0YSAyMDEzIDIzOjEyPGJyPg0KPGI+VmFzdGFhbm90dGFqYTo8L2I+IEphbmV0IFAgR3Vu bjxicj4NCjxiPktvcGlvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2Vz QGlldGYub3JnIj5zaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzwvYT47DQo8YSBocmVmPSJt YWlsdG86dm9sa2VyaEBiZWxsLWxhYnMuY29tIj52b2xrZXJoQGJlbGwtbGFicy5jb208L2E+OyA8 YSBocmVmPSJtYWlsdG86dmtnQGJlbGwtbGFicy5jb20iPg0KdmtnQGJlbGwtbGFicy5jb208L2E+ OyA8YSBocmVmPSJtYWlsdG86c2lwLW92ZXJsb2FkQGlldGYub3JnIj5zaXAtb3ZlcmxvYWRAaWV0 Zi5vcmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmhnc0Bjcy5jb2x1bWJpYS5lZHUiPmhnc0Bjcy5j b2x1bWJpYS5lZHU8L2E+PGJyPg0KPGI+QWloZTo8L2I+IFJlOiBbc2lwLW92ZXJsb2FkXSBkcmFm dC1pZXRmLXNvYy1vdmVybG9hZC1jb250cm9sLTEzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZJIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SmFuZXQsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NeSBjb21tZW50 IGlzIG5vdCBvbiBoYXZpbmcgbXVsdGlwbGUgYWxnb3JpdGhtcyBpbiB0aGUgdmlhIGhlYWRlciBi dXQgb24gdGhlIHN5bnRheCBpbiB0aGUgY3VycmVudCBJLUQgdGhhdCBjb3VsZCBhbGxvdyBtdWx0 aXBsZSBhbGdvcml0aG1zIHRoYXQgYXJlIG5vdCBzZXBhcmF0ZWQNCiBieSDigJws4oCdLiZuYnNw OyBQbGVhc2UgY2hlY2sgdGhlIHN5bnRheCBieSBoYXZpbmcg4oCccmF0ZeKAnSBhbmQg4oCcZm9v 4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SmFtZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEphbmV0IFAgR3VubiBbPGEgaHJlZj0i bWFpbHRvOmpndW5uNkBjc2MuY29tIj5tYWlsdG86amd1bm42QGNzYy5jb208L2E+XQ0KPGJyPg0K PGI+U2VudDo8L2I+IE1vbmRheSwgSnVseSAyMiwgMjAxMyAzOjU0IFBNPGJyPg0KPGI+VG86PC9i PiBZdSwgSmFtZXM8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpoZ3NAY3MuY29sdW1i aWEuZWR1Ij5oZ3NAY3MuY29sdW1iaWEuZWR1PC9hPjsgPGEgaHJlZj0ibWFpbHRvOnZrZ0BiZWxs LWxhYnMuY29tIj4NCnZrZ0BiZWxsLWxhYnMuY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnZvbGtl cmhAYmVsbC1sYWJzLmNvbSI+dm9sa2VyaEBiZWxsLWxhYnMuY29tPC9hPjsNCjxhIGhyZWY9Im1h aWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZyI+c2lwLW92ZXJsb2FkLWJvdW5jZXNA aWV0Zi5vcmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZEBpZXRmLm9yZyI+c2lw LW92ZXJsb2FkQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZC1ib3Vu Y2VzQGlldGYub3JnIj4NCnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPC9hPjxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW3NpcC1vdmVybG9hZF0gZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQt Y29udHJvbC0xMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGVyZSBpcyBhdCBsZWFzdCBvbmUgJnF1b3Q7b3RoZXItYWxn byZxdW90OywgJnF1b3Q7cmF0ZSZxdW90Oy48L3NwYW4+DQo8YnI+DQo8YnI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5XaGVuIGFsZ28tbGlzdCBpcyBpbmNsdWRlZCBpbiB0aGUgVmlhIGhl YWRlcnMgb2YgYSBtZXNzYWdlIHNlbnQgYnkgdGhlIGNsaWVudCB0byB0aGUgc2VydmVyLCBpdCBt YXkgaGF2ZSBtdWx0aXBsZSBhbGdvcml0aG1zIGluY2x1ZGVkIGluIHRoZSBhbGdvLWxpc3QgLSBh bGwgdGhlIGFsZ29yaXRobXMgc3VwcG9ydGVkIGJ5IHRoZSBjbGllbnQuPC9zcGFuPg0KPGJyPg0K PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+V2hlbiBhbGdvLWxpc3QgaXMgaW5jbHVk ZWQgaW4gdGhlIFZpYSBoZWFkZXJzIHNlbnQgZnJvbSB0aGUgc2VydmVyIHRvIHRoZSBjbGllbnQs IGl0IHNob3VsZCBoYXZlICZxdW90Ozwvc3Bhbj4gb25lIGFuZCBvbmx5IG9uZSBhbGdvcml0aG08 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mcXVvdDsNCiBpbiB0aGUgbGlzdC48L3NwYW4+IDxi cj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkphbmV0PGJyPg0KPGJyPg0KPC9z cGFuPjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojNUY1RjVGIj5Gcm9tOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mcXVvdDtZdSwgSmFtZXMmcXVvdDsgJmx0OzxhIGhyZWY9Im1h aWx0bzpqYW1lcy55dUBuZXVzdGFyLmJpeiI+amFtZXMueXVAbmV1c3Rhci5iaXo8L2E+Jmd0Ozwv c3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNUY1RjVGIj5Ubzog Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmhnc0Bjcy5jb2x1bWJpYS5lZHUiPmhnc0Bjcy5jb2x1 bWJpYS5lZHU8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86aGdzQGNzLmNvbHVtYmlhLmVk dSI+aGdzQGNzLmNvbHVtYmlhLmVkdTwvYT4mZ3Q7LA0KICZxdW90OzxhIGhyZWY9Im1haWx0bzp2 a2dAYmVsbC1sYWJzLmNvbSI+dmtnQGJlbGwtbGFicy5jb208L2E+JnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86dmtnQGJlbGwtbGFicy5jb20iPnZrZ0BiZWxsLWxhYnMuY29tPC9hPiZndDssICZx dW90OzxhIGhyZWY9Im1haWx0bzp2b2xrZXJoQGJlbGwtbGFicy5jb20iPnZvbGtlcmhAYmVsbC1s YWJzLmNvbTwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp2b2xrZXJoQGJlbGwtbGFicy5j b20iPnZvbGtlcmhAYmVsbC1sYWJzLmNvbTwvYT4mZ3Q7PC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1RjVGNUYiPkNjOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mcXVvdDs8YSBocmVmPSJtYWls dG86c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmciPnNpcC1vdmVybG9hZC1ib3VuY2VzQGll dGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2Vz QGlldGYub3JnIj5zaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7LA0KICZxdW90 OzxhIGhyZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmciPnNpcC1vdmVybG9hZEBpZXRm Lm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmci PnNpcC1vdmVybG9hZEBpZXRmLm9yZzwvYT4mZ3Q7PC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiM1RjVGNUYiPkRhdGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjA3LzIyLzIwMTMgMDM6MTkgUE08 L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzVGNUY1RiI+U3Vi amVjdDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+W3NpcC1vdmVybG9hZF0gJm5ic3A7ZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtY29u dHJvbC0xMzwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNUY1 RjVGIj5TZW50IGJ5OiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJtYWlsdG86c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0 Zi5vcmciPnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnPC9hPjwvc3Bhbj4NCjxvOnA+PC9v OnA+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4 dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBub3NoYWRlPSIiIHN0 eWxlPSJjb2xvcjojQTBBMEEwIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQo8YnI+DQpI aSwgSGVubmluZywgVmlqYXksIFZvbGtlciwgPGJyPg0KJm5ic3A7IDxicj4NCldoZW4gSSByZXZp ZXdlZCBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1yYXRlLWNvbnRyb2wtMDQudHh0LCBJIGdsYW5j ZWQgdGhyb3VnaCB0aGUgc3ludGF4IGluIHRoaXMgSS1EIHRvIHVuZGVyc3RhbmQgdGhlIG9jIHJl bGF0ZWQgcGFyYW1ldGVycy4NCjxicj4NCiZuYnNwOyA8YnI+DQpXaGVuIGxvb2tpbmcgYXQg4oCc YWxnby1saXN04oCdLCBJIHdvbmRlciBpZiB0aGVyZSBhcmUgdHdvIOKAnG90aGVyLWFsZ2/igJ0g c3VjaCBhcyDigJxhYmPigJ0gYW5kIOKAnHh5euKAnSwg4oCYYWJj4oCdIGFuZCDigJx4eXrigJ0g d29u4oCZdCBiZSBjb21tYS1zZXBhcmF0ZWQgYmFzZWQgb24gdGhlIG9jLWFsZ28gc3ludGF4LiAm bmJzcDtJdCBzZWVtcyB0aGF0IGFsZ28tbGlzdCB3b3VsZCBiZQ0KPGJyPg0KJm5ic3A7IDxicj4N CjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 YWxnby1saXN0ID0gPC9zcGFuPuKAnDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+bG9zczwvc3Bhbj7igJw8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiAvIG90aGVyLWFsZ288L3NwYW4+DQo8YnI+DQo8c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj4g PGJyPg0KVGhpcyB3b3VsZCBlbnN1cmUgdGhhdCBvbmUgYW5kIG9ubHkgb25lIGFsZ29yaXRobSBp cyBwcmVzZW50IGluIGFsZ28tbGlzdC4gJm5ic3A7SWYgdGhlcmUgaXMgbm8gYWxnb3JpdGhtIG90 aGVyIHRoYW4g4oCcbG9zc+KAnSwgKihDT01NQSBhbGdvLWxpc3QpIHdvdWxkIHRha2UgY2FyZSBv ZiB0aGF0Lg0KPGJyPg0KJm5ic3A7IDxicj4NClNpbmNlIGFsZ28tbGlzdCBjb250YWlucyBhIHNp bmdsZSBhbGdvcml0aG0sIG1heSBiZSBpdCBpcyBiZXR0ZXIgdG8gdXNlIOKAnGFsZ2/igJ0gb25s eS4gJm5ic3A7T3IgaWYgYWxnby1saXN0IGNvbnRhaW5zIGEgbGlzdCBvZiBjb21tYSBzZXBhcmF0 ZWQgYWxnb3JpdGhtcywgdGhlbiBhbG9nLWxpc3QgYW5kIG9jLWFsZ28gY2FuIGJlIG1vZGlmaWVk IHNvIHRoYXQgb2MtYWxnbyBoYXMgYSBzaW5nbGUg4oCcYWxnby1saXN04oCdLiAmbmJzcDtUaGUg bGF0dGVyIG1heSBiZSBiZXR0ZXINCiBiZWNhdXNlIHRoZSBjdXJyZW50IHN5bnRheCB3b3VsZCBh bGxvdyB0aGUgc2FtZSBhbGdvcml0aG0gdG8gYXBwZWFyIG1vcmUgdGhhbiBvbmNlLg0KPGJyPg0K Jm5ic3A7IDxicj4NCkphbWVzPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48L3R0Pjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij48YnI+DQo8dHQ+c2lwLW92ZXJsb2FkIG1haWxpbmcgbGlzdDwvdHQ+PGJyPg0KPHR0 PjxhIGhyZWY9Im1haWx0bzpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmciPnNpcC1vdmVybG9hZEBpZXRm Lm9yZzwvYT48L3R0Pjxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NpcC1vdmVybG9hZCI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcC1vdmVybG9h ZDwvc3Bhbj48L3R0PjwvYT48bzpwPjwvbzpwPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIg YWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIxIiB3 aWR0aD0iMTAwJSIgbm9zaGFkZT0iIiBzdHlsZT0iY29sb3I6I0EwQTBBMCIgYWxpZ249ImNlbnRl ciI+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Tm8gdmlydXMgZm91bmQgaW4gdGhp cyBtZXNzYWdlLjxicj4NCkNoZWNrZWQgYnkgQVZHIC0gPGEgaHJlZj0iaHR0cDovL3d3dy5hdmcu Y29tIj53d3cuYXZnLmNvbTwvYT48YnI+DQpWZXJzaW9uOiAyMDEzLjAuMjkwNCAvIFZpcnVzIERh dGFiYXNlOiAzMjA0LzY1MTAgLSBSZWxlYXNlIERhdGU6IDA3LzIyLzEzPG86cD48L286cD48L3A+ DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWdu OmNlbnRlciI+PHNwYW4gbGFuZz0iRkkiPg0KPGhyIHNpemU9IjEiIHdpZHRoPSIxMDAlIiBub3No YWRlPSIiIHN0eWxlPSJjb2xvcjojQTBBMEEwIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRkkiPk5vIHZpcnVzIGZvdW5k IGluIHRoaXMgbWVzc2FnZS48YnI+DQpDaGVja2VkIGJ5IEFWRyAtIDxhIGhyZWY9Imh0dHA6Ly93 d3cuYXZnLmNvbSI+d3d3LmF2Zy5jb208L2E+PGJyPg0KVmVyc2lvbjogMjAxMy4wLjI5MDQgLyBW aXJ1cyBEYXRhYmFzZTogMzIwOS82NTM2IC0gUmVsZWFzZSBEYXRlOiAwNy8zMC8xMzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5 bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBsYW5nPSJGSSI+DQo8aHIgc2l6ZT0iMSIgd2lk dGg9IjEwMCUiIG5vc2hhZGU9IiIgc3R5bGU9ImNvbG9yOiNBMEEwQTAiIGFsaWduPSJjZW50ZXIi Pg0KPC9zcGFuPjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGSSI+ Tm8gdmlydXMgZm91bmQgaW4gdGhpcyBtZXNzYWdlLjxicj4NCkNoZWNrZWQgYnkgQVZHIC0gPGEg aHJlZj0iaHR0cDovL3d3dy5hdmcuY29tIj53d3cuYXZnLmNvbTwvYT48YnI+DQpWZXJzaW9uOiAy MDEzLjAuMjkwNCAvIFZpcnVzIERhdGFiYXNlOiAzMjA5LzY1MzYgLSBSZWxlYXNlIERhdGU6IDA3 LzMwLzEzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_56FB15AFE08E1242B0736CBDCE6E8561080A51DCSTNTEXMB10cisne_--
<= p class=3DMsoNormal>From: Janet P Gunn [mai= lto:jgunn6@csc.com]
Sent: Friday, June 28, 2013 3:34 PM
<= b>To: Yu, James
Cc: draft-ietf-soc-overload-rate-control.all@= tools.ietf.org; sip-overload@i= etf.org; sip-overload-= bounces@ietf.org
Subject: Re: [sip-overload] draft-ietf-soc-o= verload-rate-control-04.txt

James,

 

=

So section 5 (syntax) will includ= e the following statements:

 

oc =3D “oc&= #8221; [EQUAL oc-num]

oc-n= um =3D 1*DIGIT

oc-algo =3D= "oc-algo" EQUAL DQUOTE algo-list *(COMMA algo-list) DQUOTE<= /o:p>

algo-list =3D “loss”= ; / “rate“ / *(other-algo)

other-algo =3D %x41-5A / %x61-7A / %x30-39

 

Thanks,

&n= bsp;

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<= /span>

 

From:= Yu,= James [mailto:james.yu@neustar.biz]
Sent: Wednesday, July 10, 2= 013 3:10 PM
To: NOEL, ERIC C (ERIC C)
Cc: sip-overload-= bounces@ietf.org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; = sip-overload@ietf.org
Subject: RE: [sip-overload] draft-ietf-soc-= overload-rate-control-04.txt

 

Eric,

You may= want to copy the “oc-algo” line from other I-D.

 

James

 

From: NOEL, ERIC= C (ERIC C) [mailto:ecnoel@research.att.com]
Sent: Wednesday, Ju= ly 10, 2013 1:10 PM
To: Yu, James
Cc: sip-overload-boun= ces@ietf.org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-= overload@ietf.org
Subject: RE: [sip-overload] draft-ietf-soc-over= load-rate-control-04.txt

 

James,

 

Based on your suggestion and comments from other reviewers, = I intend to update section 5 (syntax) as follows:

 

oc =3D “oc” [EQUAL oc-num]

oc-num =3D 1*DIGIT

 

algo= -list =3D “loss” / “rate“ / *(other-algo)

other-algo =3D %x41-5A / %x61-7A / = %x30-39

 <= /span>

I understand there may be an addition= al change following Henning’s reply.

 

Th= anks,

 

Eric Noel <= /span>

AT&T Labs, Inc.
Rethink Possible

 

Network Design and Performance Analysis
200 South Laurel Avenue, D5-3= D19
Middletown, NJ 07748
P: 732.420.4174

ecnoel@att.com

&nb= sp;

From: Yu, James [mailto:james.yu@neustar.biz]
= Sent: Wednesday, July 10, 2013 11:36 AM
To: NOEL, ERIC C (ERI= C C)
Cc: sip-ove= rload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all@tools.= ietf.org; sip-overload@ietf.or= g
Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-co= ntrol-04.txt

&nb= sp;

Eric,

 

Yes, this adds “rate” to “oc-algo” parameter but = please check with IANA to see if it is the correct way.  You also need= to copy some syntax lines from the draft-ietf-soc-overload-control to show=

 =

     algo-list&nbs= p;  =3D “loss“ / “rate“ / *(other-algo)<= /o:p>

 

I’ve an email to Henning asking if algo-list= in his I-D should be

&nbs= p;    algo-list   =3D “loss“ / other-algo

 

If yes, then this particular line in your I-D would be =

     algo-lis= t   =3D “loss“ = / “rate“ / other-algo

 

James

 

From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com]
Sent: Wednesday, July 10= , 2013 10:49 AM
To: Yu, James
Cc: sip-overload-bounces@ietf.org; draft-ietf-s= oc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: [sip-overlo= ad] draft-ietf-soc-overload-rate-control-04.txt

=

 

James,

 <= /span>

Thank you for your suggestion. <= /o:p>

 

Not being familiar with IANA procedure, would upda= ting draft-ietf-soc-overload-rate-control section 7 (IANA considerations) a= s follows work?

 = ;

This specification defines a = new value for Via header parameter oc-algo as detailed below in the "H= eader Field Parameter and Parameter Values" subregistry as per the reg= istry created by [RFC3968]. The required information is:<= /p>

 

Header Field         &n= bsp; Parameter Name         &n= bsp;            = ;  Predefined Values        &n= bsp;           Refer= ence

---------------------= ---------------------------------------------------------------------------= ----------

Via   = ;            &n= bsp;            = ;  oc-algo          =             &nb= sp;            =            “ra= te”           =             &nb= sp;             = ;        RFCXXXX<= /p>

 

RFC XXXX [NOTE TO RFC-EDITOR: Please replace with final RFC num= ber of this specification.]

 

Thanks,

 

Eric Noel

AT&T Labs, Inc.
Rethink Possible

 

Network Desi= gn and Performance Analysis
200 South Laurel Avenue, D5-3D19
Middleto= wn, NJ 07748
P: 732.420.4174

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>ecnoel@att.com

 

From: Yu, James [mailto:james.yu@neustar.biz]
Sent: Wedne= sday, July 10, 2013 10:17 AM
To: NOEL, ERIC C (ERIC C)
Cc:<= /b> sip-overload-bounces@i= etf.org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; <= a href=3D"mailto:sip-overload@ietf.org">sip-overload@ietf.org
Sub= ject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt

 

Noel,

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

I forgot to r= espond to your reply about the IANA registration of “rate” in o= c-algo.  I see that draft-ietf-soc-overload-control-13 mentions your I= -D but does not have “rate” in algo-list.

=

 

There are two possible ways to address “rate” in algo-= list.  One is to have draft-ietf-soc-overload-control-13 add “ra= te” to algo-list and refer to your I-D for details.  The other i= s to register “rate” in algo-list with IANA in your I-D, and th= is should be a simple task.  The cleaner way that is more inline with = the IETF process would be the latter.  It seems odd to have something = defined in a RFC without details about it, and it would be too much trouble= to combine the two I-Ds.

=  

James

 

From: Yu, James
Sent: Wednesday, July 10, = 2013 9:01 AM
To: 'NOEL, ERIC C (ERIC C)'
Cc: sip-overload-bounces@ietf.org; <= a href=3D"mailto:draft-ietf-soc-overload-rate-control.all@tools.ietf.org">d= raft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Subject: RE: = [sip-overload] draft-ietf-soc-overload-rate-control-04.txt

 

Noel,

&nb= sp;

I mentioned in my message t= o Janet on 7/2:

 = ;

For = the rate control, the server could calculate the arrival rate from each com= municating client so that it could allocate the overall target SIP request = rate to the clients based on their arrival rates known to the server.  = ;But another option is for the client to “optionally” include i= ts calculated arrival rate in its request to the server when rate control r= elated parameters are present.  Should this option be evaluated/includ= ed to relieve the server from doing the arrival rate calculations.  Th= is would be beneficial to a server when it receives the requests from many = clients.

 =

I suggest that the I-D adds that opt= ion to allow the client to indicate its current arrival rate (towards the r= eceiving server) in the SIP request.

 

James

 

=

 =

Janet, James,

 

= Thanks you for your valuable comments and discussion.  I tried = to capture all resolution in the following text (based on James word docume= nt with track changes and imbedded comments enabled).

=

 

+ Abstract section:

- Agreed with suggested changes

- Please note I will also need to make further changes to remove = all references per Christer Holmberg comment

 

+ Section 1:

- Agreed wit= h suggested changes

 

+ Section 3.1:

- Agreed with suggested changes

 

+ Section 3.2: - Please note the section title= will become “Via header field parameters for overload control “= ; per Christer Holmberg comment

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>- Agreed with suggested changes excluding title that will change per = previous bullet

 = ;

+ Section 3.3:

- Agreed with suggested changes

 

+ Section 3.4:

- ID:  "Note that the target SIP request rate is a max= rate that may not be attained by the arrival rate at the client, and the s= erver cannot assume that it will."

   [JY] Not clear what value this paragraph t= ries to add.  Is it saying that the client's arrival rate may be lower= than the target SIP request rate?

   [JG] Yes + supporting example (see below in thr= ead)

  Agreed wi= th Janet and supporting example. Per James request, I will add the followin= g text (inspired from Janet’s illustrative example):

   “In other words, when m= ultiple clients are being controlled by an overloaded server, at any given = time some clients may receive requests at a rate below its target SIP reque= st rate while others above that target rate. But the resulting request rate= presented to the overloaded server will converge towards the target SIP re= quest rate.”

- Agree= d with other suggested changes

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>     

+ Section 3.5.1:

- ID: “And the larger the difference between TAU1 and TAU2, the clo= ser to the control is to strict priority.”

  [JY] Suggest changing into “And the lar= ger the difference between TAU1 and TAU2, the closer the control is to stri= ct priority queuing.”

  [JG] Suggest changing into “And the larger the difference be= tween TAU1 and TAU2, the closer the control is to strict priority treatment= .”

  [EN] Agree= d with Janet’s suggestion

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>- Agreed with other suggested changes

 

+ Section 4:

- Agreed wit= h suggested changes

 

+ Section 5:=

- Please note that based comments fr= om per Christer Holmberg and Janet Gunn, the following was tentatively agre= ed

   Repl= ace oc-value =3D "NaN" / oc-num    by   =  oc =3D "oc" [EQUAL oc-num]

- Agreed with other suggested change

=

 

+ Section 7:

- [J= Y] Should “rate” in oc-algo be registered with IANA?=

  This issue needs to be addres= sed by draft-ietf-soc-overload-control authors

 

Please note I will wait until expiration of WGLC prior updating our draft= RFC. Once again your comments and/or suggestions are most appreciated.

 

<= p class=3DMsoNormal>Thanks,

 

 

From: sip-overload= -bounces@ietf.org [mai= lto:sip-overload-bounces@ietf.org] On Behalf Of Yu, James
= Sent: Tuesday, July 02, 2013 9:42 AM
To: Janet P Gunn
C= c: sip-overload-bounce= s@ietf.org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org= ; sip-overload@ietf.org
= Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt=

 

Janet,

 

For my co= mment on section 3.4 (the first one below), the current text does not provi= de any value.  The client’s arrival rate could be well below the= target SIP request rate when its load is light so the fact that the client= may not achieve the target SIP request rate (the max. rate it is allowed t= o send to the server) is well understood.  But with your explanation o= n the “delta” part, the text then makes sense.  Please add= some discussions on the “delta” aspect so that even if the ave= rage arrival rate at the client is higher than the target SIP request rate = the client at times may not send more than what the target SIP request rate= allows due to the fluctuation of the arriving requests at the client.=

 

For the comment on section 3.5.1, I agree with yo= ur proposed change.

 

For the rate control, t= he server could calculate the arrival rate from each communicating client s= o that it could allocate the overall target SIP request rate to the clients= based on their arrival rates known to the server.  But another option= is for the client to “optionally” include its calculated arriv= al rate in its request to the server when rate control related parameters a= re present.  Should this option be evaluated/included to relieve the s= erver from doing the arrival rate calculations.  This would be benefic= ial to a server when it receives the requests from many clients.=

 

James

=  

From: Janet P Gunn = [mailto:jgunn6@csc.com]
Sent:<= /b> Friday, June 28, 2013 3:34 PM
To: Yu, James
Cc: dra= ft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org; sip-overload-bounces@ietf.org
Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt

 

Jam= es,

It is a little hard to respond in email when your comments are in= a separate document, but here goes.


section 3.4
ID says:
&qu= ot;Note that the target SIP request rate is a max rate that may not be
&n= bsp;  attained by the arrival rate at the client, and the server canno= t
   assume that it will."

Your comment : "No= t clear what value this paragraph tries to add.  Is it saying that the= client's arrival rate may be lower than the target SIP request rate?  = ;"

Yes.

Suppose the server want to limit the total rate of= arriving SIP messages to 100 / sec, and has 10 clients.  Each client = has a high variance in its message rate, but together they are well above 1= 00 messages per sec

If it sets the rate at 10 messages per second for= each of the clients, it will almost certainly end up  with an overall= average of less than 100 messages per sec, because some clients will be in= a "lull" while others are busy.  This is good from a thrott= ling perspective, but, assuming messages are correlated with revenue, bad/w= asteful from a revenue, or overall productivity perspective.  So the s= erver might want to set the rate per client to 10 + delta, where delta is g= oing to be very specific to operating environment.

---
In section &= nbsp;3.5.1, bottom of page 8
ID says:
"And the larger
<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>  &nb= sp;the difference between TAU1 and TAU2, the closer to the control is
&nb= sp;  to strict priority."

You propose changing it to:
&qu= ot;And the larger
   the difference between TAU1 and TAU2, the = closer  the control is
   to strict priority queuing."= ;

I agree with taking out the redundant "to".  But I d= isagree wit adding "queuing".  There is no queuing, priority= or otherwise involved.

You could say:
"And the larger =
 = ;  the difference between TAU1 and TAU2, the closer  the control = is
   to strict priority treatment."

where " st= rict priority treatment" would refer to the case where non-priority me= ssages are restricted to a total (priority + non-priority) rate of 10 messa= ges per second, but priority messages can continue to be sent as long as th= e total (priority + non-priority) rate is less than 12 messages per second.=

At least, I think that is what Eric and  Philip are trying to s= ay.

Janet


 


This is a PRIVATE message. If yo= u 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 expr= essly permitting the use of e-mail for such purpose.


From:        "Yu, James" <james.yu@neustar.biz>
To: &= nbsp;      "sip-overload-bounces@ietf.org" <sip-overload-bounces@ietf.org>, "draft-i= etf-soc-overload-rate-control.all@tools.ietf.org" <draft-ietf-s= oc-overload-rate-control.all@tools.ietf.org>, "sip-overload@ietf.org" <sip-overload@ietf.org>
Dat= e:        06/28/2013 08:10 AM
Subject: &nbs= p;      [sip-overload] draft-ietf-soc-overload-rate-control-04.= txt
Sent by:        sip-overload-bounces@ietf.org <= /o:p>

=
=




Salvatore,
 
Please see the attachment for my comments.
  =
I p= asted the text to a word document to trace/show the proposed changes and co= mments.
 
Regards,
 
James
 [attachment = "comments on draft-ietf-soc-overload-rate-control-04.docx" delete= d by Janet P Gunn/USA/CSC] ____= ___________________________________________
sip-overload mailing list
sip-overload@ietf.org
https://www.ietf.org/mailman/list= info/sip-overload

No virus found in this = message.
Checked by AVG - www.avg.com=
Version: 2013.0.2904 / Virus Database: 3204/6452 - Release Date: 06/30/= 13

No virus found in this message.
Checked by AVG - = www.avg.com
Version: 2013.0.2904 / Vi= rus Database: 3204/6478 - Release Date: 07/09/13

No vi= rus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 3204/6478 - Re= lease Date: 07/09/13

No virus found in this message.
C= hecked by AVG - www.avg.com
Version: = 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13=