From saul@ag-projects.com Wed Jan 2 00:35:02 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B6A21F8C46 for ; Wed, 2 Jan 2013 00:35:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vf8L-fxr+G5i for ; Wed, 2 Jan 2013 00:35:02 -0800 (PST) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 809F121F8C3C for ; Wed, 2 Jan 2013 00:35:01 -0800 (PST) Received: by mail.sipthor.net (Postfix, from userid 5001) id 7BE61B01BE; Wed, 2 Jan 2013 09:34:59 +0100 (CET) Received: from [192.168.1.41] (176.Red-83-43-226.dynamicIP.rima-tde.net [83.43.226.176]) by mail.sipthor.net (Postfix) with ESMTPSA id 61BDCB0067; Wed, 2 Jan 2013 09:34:57 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: Date: Wed, 2 Jan 2013 09:34:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4A541458-A884-4BB9-8C0C-EDD8C7CCB2D0@ag-projects.com> References: <20121217161521.30393.14625.idtracker@ietfa.amsl.com> To: Victor Pascual Avila X-Mailer: Apple Mail (2.1085) Cc: DISPATCH Subject: Re: [dispatch] FW: New Version Notification for draft-pd-dispatch-msrp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 08:35:02 -0000 Hi, Thanks for putting this together, I do support this work. A few comments from an initial (and shallow) read: - Section 5.3.1: why mandate authentication? Is there a specific reason = for this or could it be left out as an implementation detail? - Section 6: maybe it should be mentioned that in the absence of a WS = pint mechanism the defined MSRP way (that is, an empty SEND) should be = used? Given the limitations of WS with regards to receiving incoming = connections, I think this document should mention how ACM = (http://tools.ietf.org/html/rfc6135) should be used in WS scenarios. Keep up the good work! Regards, On Dec 17, 2012, at 11:29 PM, Victor Pascual Avila wrote: > Dear DISPATCH, >=20 > comments on the draft below[1] would be appreciated. The proposed = mechanism has been implemented and there's open-source code available = for both client[2] and server[3] side implementations. >=20 > [1] http://tools.ietf.org/html/draft-pd-dispatch-msrp-websocket-00 > [2] http://code.google.com/p/crocodile-msrp/wiki/Overview > [3] http://www.kamailio.org/wiki/features/new-in-devel#websocket >=20 > Thanks, > Peter, Gavin and Victor >=20 > On 12/17/12 5:15 PM, "internet-drafts@ietf.org" = > wrote: >=20 > > > >A new version of I-D, draft-pd-dispatch-msrp-websocket-00.txt > >has been successfully submitted by Peter Dunkley and posted to the > >IETF repository. > > > >Filename: draft-pd-dispatch-msrp-websocket > >Revision: 00 > >Title: The WebSocket Protocol as a Transport for the Message = Session > >Relay Protocol (MSRP) > >Creation date: 2012-12-17 > >WG ID: Individual Submission > >Number of pages: 19 > >URL: > = >http://www.ietf.org/internet-drafts/draft-pd-dispatch-msrp-websocket-00.t= x > >t > >Status: > >http://datatracker.ietf.org/doc/draft-pd-dispatch-msrp-websocket > >Htmlized: > >http://tools.ietf.org/html/draft-pd-dispatch-msrp-websocket-00 > > > > > >Abstract: > > The WebSocket protocol enables two-way real-time communication > > between clients and servers. This document specifies a new = WebSocket > > sub-protocol as a reliable transport mechanism between MSRP = (Message > > Session Relay Protocol) clients and relays to enable usage of MSRP = in > > new scenarios. This document normatively updates RFC 4975 and RFC > > 4976. > > > > > > > > > > > >The IETF Secretariat > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --=20 Sa=FAl Ibarra Corretg=E9 AG Projects From ibc@aliax.net Fri Jan 4 07:10:41 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD36121F88B4 for ; Fri, 4 Jan 2013 07:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0imo9+OvOkJ for ; Fri, 4 Jan 2013 07:10:41 -0800 (PST) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id 33F9C21F8891 for ; Fri, 4 Jan 2013 07:10:41 -0800 (PST) Received: by mail-qa0-f46.google.com with SMTP id r4so13343470qaq.19 for ; Fri, 04 Jan 2013 07:10:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=MvnAyYZHO6qGPTWW0bi8AgofjUyn0geP3cjyFG6szdk=; b=E54tah/dsWmmF/DyobnMm+zP22MKwzdklH6jJSZ8rQmCrWlCMPNEC1ROsq+qVso/v9 0cPWyOOzGoCQUW7t7yn/UkbpbKpg79B3zIhLTFDGep9H9Jlh/csxTHLKgWWVOZshCAU3 PPDh4KrsRvmIbDzscdi6tNJ9WH88HNBp5+ICTBOlfMsXdI0QKmEGs0PD00pG/43l63ei gG5MVY4Qf3tHmHbUIp/rBoREH2ucrbV4S/7cK3wvArO1uBXvM5208H2VGw1TCtxSp9X+ D5QnaWhR346rGJxEj0BXIOx0/6+Wh5uTbMzp9EIRz9gwt8Dhkz203e/Ku4GrHAloHqRv vnyQ== Received: by 10.229.102.146 with SMTP id g18mr7732867qco.143.1357312233862; Fri, 04 Jan 2013 07:10:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.94.193 with HTTP; Fri, 4 Jan 2013 07:10:13 -0800 (PST) In-Reply-To: <4A541458-A884-4BB9-8C0C-EDD8C7CCB2D0@ag-projects.com> References: <20121217161521.30393.14625.idtracker@ietfa.amsl.com> <4A541458-A884-4BB9-8C0C-EDD8C7CCB2D0@ag-projects.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 4 Jan 2013 16:10:13 +0100 Message-ID: To: dispatch@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQm1SAfzh3k+wC44yDQMIRd1PBNJgvnPAsaWyeWN1TFL6aqZ0LNY9gzgg0UTqLlQFLpIOaC6 Subject: Re: [dispatch] FW: New Version Notification for draft-pd-dispatch-msrp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 15:10:41 -0000 Hi all, I support this work and, in fact, plan to implement it. The only point I don't like (until a deeper review) is 5.2.2, it seems a hack IMHO. Regards. --=20 I=C3=B1aki Baz Castillo From jmillan@aliax.net Fri Jan 4 10:45:27 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B98421F84F0 for ; Fri, 4 Jan 2013 10:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoCwCe05SfkE for ; Fri, 4 Jan 2013 10:45:26 -0800 (PST) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 7061621F8460 for ; Fri, 4 Jan 2013 10:45:26 -0800 (PST) Received: by mail-qc0-f179.google.com with SMTP id b14so8994608qcs.10 for ; Fri, 04 Jan 2013 10:45:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=X5E050Elg0deF8tZBroKrs6aSkWbf3oaM/6co0oNCPc=; b=BQz6XeMISGSLEMyHgXDS85HQBGAPtsccYQaBQXwXmpMPURxPZQW9LQb6etUo5btd9R Af69p/H2KHIA6l4SAM1qSTDp6m/+8ItiyUuu0o8R1GrgXkthhwpAQxDgMvovfhqnykgg /9lH6uCkgQPrh1NbLAimyFZ/yGb5uPbVgDy9trdZMmMlu4844q+l5BYyBS1suV01vQKp huetJKkc9pbmRfClseANfkYOaRfWFMtpTD+wTwhAlspF615zRrvD41WOL50y9etcLkh6 zvE1lxQYr3GCKtRQHoeO1AzowKkbhycxOderX9wpcsRnU89gKpEP4I8pvx//1NzMhvCR uQuA== MIME-Version: 1.0 Received: by 10.229.106.131 with SMTP id x3mr7555505qco.50.1357325125752; Fri, 04 Jan 2013 10:45:25 -0800 (PST) Received: by 10.49.61.104 with HTTP; Fri, 4 Jan 2013 10:45:25 -0800 (PST) In-Reply-To: References: <20121217161521.30393.14625.idtracker@ietfa.amsl.com> <4A541458-A884-4BB9-8C0C-EDD8C7CCB2D0@ag-projects.com> Date: Fri, 4 Jan 2013 19:45:25 +0100 Message-ID: From: =?UTF-8?B?Sm9zw6kgTHVpcyBNaWxsw6Fu?= To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=0023544719ecf7169504d27ae107 X-Gm-Message-State: ALoCoQmhDHlrCFypTiV27L3PgBZhmLwDgTA9WzP6XjKmInUAA0oJe0hQyw/5/eXCTK081AOZA8MN Cc: dispatch@ietf.org Subject: Re: [dispatch] FW: New Version Notification for draft-pd-dispatch-msrp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 18:45:27 -0000 --0023544719ecf7169504d27ae107 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear all, I also support this work and plan to implement it. Thank you for this work. 2013/1/4 I=C3=B1aki Baz Castillo > Hi all, > > I support this work and, in fact, plan to implement it. > > The only point I don't like (until a deeper review) is 5.2.2, it seems > a hack IMHO. > > Regards. > > > -- > I=C3=B1aki Baz Castillo > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --=20 Jos=C3=A9 Luis Mill=C3=A1n --0023544719ecf7169504d27ae107 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,

I also support this wor= k and plan to implement it.

Thank you = for this work.


2013/1/4 I=C3=B1aki Baz Castillo <ibc@aliax.net>
Hi all,

I support this work and, in fact, plan to implement it.

The only point I don't like (until a deeper review) is 5.2.2, it seems<= br> a hack IMHO.

Regards.


--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>
_____________________________= __________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch



--
= Jos=C3=A9 Luis Mill=C3=A1n
--0023544719ecf7169504d27ae107-- From gonzalo.camarillo@ericsson.com Mon Jan 7 03:10:24 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C33921F86C4 for ; Mon, 7 Jan 2013 03:10:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sL+ii6q8b301 for ; Mon, 7 Jan 2013 03:10:23 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id B9E0B21F866E for ; Mon, 7 Jan 2013 03:10:22 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-5e-50eaad1dcfa6 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 18.2F.10459.D1DAAE05; Mon, 7 Jan 2013 12:10:21 +0100 (CET) Received: from [131.160.36.111] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Mon, 7 Jan 2013 12:10:21 +0100 Message-ID: <50EAAD1C.9010201@ericsson.com> Date: Mon, 7 Jan 2013 13:10:20 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "dispatch@ietf.org" References: <50ABBAD6.9050103@gmail.com> <50B49D64.7030600@ericsson.com> In-Reply-To: <50B49D64.7030600@ericsson.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFJMWRmVeSWpSXmKPExsUyM+Jvja7s2lcBBjMmKVgsnbSA1YHRY8mS n0wBjFFcNimpOZllqUX6dglcGY2TLrIU/AmuuHD0O2sD4wfnLkZODgkBE4ktW48zQdhiEhfu rWfrYuTiEBI4ySgx/dEvdpCEkMBqRonej6ldjBwcvALaEvNaZEDCLAIqEv3fH7OA2GwCFhJb bt0Hs0UFQiSuf3/ECGLzCghKnJz5BCwuAtR6dFUXM8h8YYFmRok7h96wQcz3kHh8uA3sCE4B HYlNk26xQxwkKbFoWidYM7OAnsSUqy2MELa8xPa3c5gherUllj9rYZnAKDgLyb5ZSFpmIWlZ wMi8ipE9NzEzJ73ccBMjMPwObvmtu4Px1DmRQ4zSHCxK4rxhrhcChATSE0tSs1NTC1KL4otK c1KLDzEycXBKNTCy27m/VpmixDitKnPenw18W69VL3wgfrvHd4n3P6t7WeyN3WXRzZ/trj5T 5Yyd0qCws3x6JrvHwR/2c+YVFP4pEWzpeZQg52G/q1t9zeUPFSHRawo+LxK9VSCxWOPf1dlG xa0XV+c8VFnId6SU/53U7EUz+pT2Cl4pKqmVSCi08JJJlbG/WqfEUpyRaKjFXFScCAAzZmPr DQIAAA== Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 11:10:24 -0000 Folks, I would like to get more comments on these two drafts before moving things forward. Now that the Christmas break is over, please have a look at them and send your comments to this list. Thanks, Gonzalo On 27/11/2012 1:00 PM, Gonzalo Camarillo wrote: > All, > > as you can see in the email below, Andrew believes that the current > versions of these drafts address all concerns that were previously > discussed on this list. Those concerns mostly related to > interoperability (what happens with UAs that do not have an IMEI) and > privacy (whether a UA can choose not to send its IMEI in order to > preserve its user's privacy). > > With respect to the URN definition (in the montemurro draft), it needs > to also be discussed on the urn-nid@ietf.org list, per RFC 3406. > > The SIP usage (specified in the allen draft), needs to be reviewed on > this list. So, please, have a look at the current versions of these > drafts and send your comments to the list. > > I have already talked with the editors of these drafts so that they are > responsive. Getting people to reload the state related to these drafts > into the heads is a lot of work for everyone. So, I would like to > discuss these drafts one last time and make a *final* decision (whatever > it is) shortly. > > Cheers, > > Gonzalo > > > On 20/11/2012 7:16 PM, Tom Taylor wrote: >> Andrew's original note appeared to me at least as a brief message: >> "WARNING: contains banned part", with attachments. As a public service, >> I have extracted and reproduced the text of his message. Hope this isn't >> a duplicate from others' point of view. >> >> Tom Taylor >> >> Andrew's message: >> ========================== >> New versions of draft-montemurro-gsma-imei-urn and >> draft-allen-dispatch-imei-urn-as-instanceid were submitted at the >> beginning of October. >> >> http://www.ietf.org/internet-drafts/draft-allen-dispatch-imei-urn-as-instanceid-06.txt >> >> >> http://www.ietf.org/internet-drafts/draft-montemurro-gsma-imei-urn-11.txt >> >> There are not many major changes since the previous versions which were >> submitted in March and July which themselves were submitted after the >> conference call held between 3GPP and IETF interested parties in early >> January on the topic. Basically editorial updates and some strengthening >> of the normative language. >> >> The main change in draft-montemurro-gsma-imei-urn since the previous >> version is to address the ABNF comment from Dale and it was decided we >> do not need parameters to have multiple values so Dale's proposed >> resolution has been adopted. The January version of >> draft-montemurro-gsma-imei-urn (09 version) added the following to the >> Security Considerations section to address the privacy concerns: >> >> Further, because IMEIs can be loosely correlated to a user, they >> need to be treated as any other personally identifiable >> information. In particular, the IMEI SHOULD NOT be included in >> messages intended to convey any level of anonymity. >> >> In the latest (11 version) this has been strengthened from a SHOULD NOT >> to a MUST NOT. >> >> The draft-allen-dispatch-imei-urn-as-instanceid 05 version that was >> submitted in March incorporated a number of significant changes including: >> >> 1. Additional text was added to the abstract stating: >> >> [The purpose of the draft] is to fulfil the requirements in RFC 5626 [1] >> that state "If a URN scheme other than UUID is used, the UA MUST only >> use URNs for which an RFC (from the IETF stream) defines how the >> specific URN needs to be constructed and used in the "+sip.instance" >> Contact header field parameter for outbound behavior." >> >> 2. A new section was added describing the three 3GPP use cases >> >> 3. A new section was added for 3GPP Registrar Procedures with the >> following text: >> >> In 3GPP IMS when the Registrar receives in the Contact header field a >> "sip.instance" media feature tag containing the GSMA IMEI URN according >> to the syntax defined in draft-montemurro-gsma-imei-urn-09[3] the >> registrar follows the procedures defined in RFC 5626 [1] and RFC 5627 >> [2] if those extensions are supported and indicated as supported by the >> UA. If the Registrar allocates a public GRUU according to the >> procedures defined in RFC 5627 [2] the the instance-id MUST be >> obfuscated when creating the "gr" parameter in order not to reveal the >> IMEI to other UAs when the public GRUU is included in non register >> requests. 3GPP TS 24.229 [6] subcluase 5.4.7A.2 defines the mechanism >> for obfuscating the IMEI when creating the "gr" parameter. >> >> 4. The security section was beefed up as follows: >> >> Because IMEIs like other formats of instance IDs can be loosely >> correlated to a user, they need to be treated as any other personally >> identifiable information. In particular, the "sip.instance" media >> feature tag containing the GSMA IMEI URN MUST NOT be included in >> requests or responses intended to convey any level of anonymity. RFC >> 5626 [1] states "One case where a UA could prefer to omit the >> "sip.instance" media feature tag is when it is making an anonymous >> request or some other privacy concern requires that the UA not reveal >> its identity". The same concerns apply when using the GSMA IMEI URN as >> an instance ID. Publication of the GSMA IMEI URN to networks that the >> UA is not attached to or the UA does not have a service relationship >> with is a security breach and the "sip.instance" media feature tag MUST >> NOT be forwarded by the service provider's network elements when >> forwarding requests or responses towards the destination UA. >> >> In order to protect from tampering the REGISTER requests containing the >> GSMA IMEI URN MUST be sent using a security mechanism such as TLS [12] >> (or another security mechanism that provides equivalent levels of >> protection). >> >> There do not seem to be any comments made against the >> draft-allen-dispatch-imei-urn-as-instanceid-05 version that was >> submitted in March. Not sure if this was because everyone was Ok with it >> or because it was overlooked. >> >> At the conference call held between 3GPP and IETF interested >> participants in January at which privacy concerns about the use of the >> IMEI as an instance ID by 3GPP were raised. It was proposed during the >> conference call that the authors submit a new revision of the draft >> clarifying the use of the mechanism and explaining how the 3GPP >> architecture addresses the privacy issues that were discussed. >> >> There was a further discussion at a following 3GPP meeting on these >> privacy concerns. During the 3GPP discussion it was pointed out that RFC >> 5626 already previously considered and addressed privacy concerns with >> instance ID in section 4.1 which only states the "UA could prefer to >> omit the "sip.instance" media feature tag": >> >> 4.1. Instance ID Creation >> >> To convey its instance-id in both requests and responses, the UA >> includes a "sip.instance" media feature tag as a UA characteristic >> [RFC3840]. This media feature tag is encoded in the Contact header >> field as the "+sip.instance" Contact header field parameter. One >> case where a UA could prefer to omit the "sip.instance" media feature >> tag is when it is making an anonymous request or some other privacy >> concern requires that the UA not reveal its identity. >> >> draft-montemurro-gsma-imei-urn and >> draft-allen-dispatch-imei-urn-as-instanceid and the 3GPP specified usage >> of the IMEI already go considerably further than RFC 5626 does in this >> regard. Regardless of whether a UUID URN or the IMEI URN is used as an >> instance ID the privacy issues are the same since an instance ID based >> on a UUID is static once generated and therefore like the IMEI >> potentially reveals the identity of the caller if it can be correlated >> with the identity of that caller from a previous call. >> >> The view in 3GPP was that the IMEI should not be of any greater concern >> when used as an instance ID than using a UUID. Asking 3GPP to go >> considerably further in addressing privacy concerns with use of IMEI as >> an instance ID than RFC 5626 already does was considered by many in 3GPP >> to be unwarranted. Describing fully all the potential uses with 3GPP IMS >> of instance ID and documenting all the security mechanisms in all >> scenarios is a really non-trivial task considering that many >> organizations outside 3GPP specify access networks for IMS and >> applications using IMS (OMA, GSMA, Cablelabs, 3GPP2, TISPAN, WIMAX >> Forum...) and outside the capability of the authors of the draft alone. >> In basic summary most if not all accesses to IMS provide for at least >> basic levels of transport security such as use of IPsec or TLS tunnels >> and/or access layer security (although there is no guarantee these will >> be always enabled by the every carrier). This goes beyond what is >> required by RFC 5626 which only recommends use of TLS even though the >> general internet is probably more open to attack than a managed carrier >> network. >> >> Those that think privacy issues are insufficiently addressed need to >> explain why the IMEI is of significantly greater concern in terms of >> revealing privacy than the UUID when used as an instance ID. >> >> In our view the security concerns raised have now been sufficiently >> addressed in the drafts and to a much higher bar than that of UUID in >> RFC 5626. >> >> The 3GPP use cases have now been described in >> draft-allen-dispatch-imei-urn-as-instanceid. It is my view that >> describing these uses as an instance ID also in >> draft-montemurro-gsma-imei-urn is both redundant and inappropriate since >> this draft does not define use of the IMEI as an instance ID. >> >> Attached are diffs between the 04 and 06 versions of >> draft-allen-dispatch-imei-urn-as-instanceid and between the 09 and 11 >> versions of draft-montemurro-gsma-imei-urn. >> >> So I would like to ask for review of these two latest drafts and to >> provide any comments. 3GPP urgently needs to progress these drafts which >> are needed to complete 3GPP Release 8. >> >> Andrew >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > From peter.dunkley@crocodile-rcs.com Mon Jan 7 09:13:04 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E361721F8A09 for ; Mon, 7 Jan 2013 09:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.964 X-Spam-Level: X-Spam-Status: No, score=-1.964 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuWtrOQ6j0mr for ; Mon, 7 Jan 2013 09:13:04 -0800 (PST) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 5749021F893D for ; Mon, 7 Jan 2013 09:13:02 -0800 (PST) Received: (qmail 10509 invoked by uid 0); 7 Jan 2013 17:12:41 -0000 Received: from unknown (HELO just121.justhost.com) (173.254.28.121) by oproxy9.bluehost.com with SMTP; 7 Jan 2013 17:12:41 -0000 Received: from [90.152.0.102] (port=60591 helo=[192.168.0.189]) by just121.justhost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1TsGFd-0003f5-0h; Mon, 07 Jan 2013 10:12:41 -0700 Message-ID: <1357578758.29808.3.camel@pd-notebook-linux.croc.internal> From: Peter Dunkley To: =?ISO-8859-1?Q?I=F1aki?= Baz Castillo Date: Mon, 07 Jan 2013 17:12:38 +0000 In-Reply-To: References: <20121217161521.30393.14625.idtracker@ietfa.amsl.com> <4A541458-A884-4BB9-8C0C-EDD8C7CCB2D0@ag-projects.com> Organization: Crocodile RCS Ltd Content-Type: multipart/alternative; boundary="=-Sp2kZsvsJ+qa0iS9SNEY" X-Mailer: Evolution 3.4.4 (3.4.4-2.fc17) Mime-Version: 1.0 X-Identified-User: {596:just121.justhost.com:crocodi1:crocodile-rcs.com} {sentby:smtp auth 90.152.0.102 authed with peter.dunkley@crocodile-rcs.com} Cc: dispatch@ietf.org Subject: Re: [dispatch] FW: New Version Notification for draft-pd-dispatch-msrp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 17:13:05 -0000 --=-Sp2kZsvsJ+qa0iS9SNEY Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Hi Inaki, I agree that section 5.2.2 is a hack. The problem is trying to make sure that there aren't interworking problems with existing clients (which may not have robust SDP parsing) without needing to do SDP mangling in the SIP server. Any suggestions on how to improve this section would be more than welcome! Peter On Fri, 2013-01-04 at 16:10 +0100, Iñaki Baz Castillo wrote: > Hi all, > > I support this work and, in fact, plan to implement it. > > The only point I don't like (until a deeper review) is 5.2.2, it seems > a hack IMHO. > > Regards. > > -- Peter Dunkley Technical Director Crocodile RCS Ltd --=-Sp2kZsvsJ+qa0iS9SNEY Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Hi Inaki,

I agree that section 5.2.2 is a hack.  The problem is trying to make sure that there aren't interworking problems with existing clients (which may not have robust SDP parsing) without needing to do SDP mangling in the SIP server.

Any suggestions on how to improve this section would be more than welcome!

Peter

On Fri, 2013-01-04 at 16:10 +0100, Iñaki Baz Castillo wrote: 
Hi all,

I support this work and, in fact, plan to implement it.

The only point I don't like (until a deeper review) is 5.2.2, it seems
a hack IMHO.

Regards.




-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd
--=-Sp2kZsvsJ+qa0iS9SNEY-- From peter.dunkley@crocodile-rcs.com Mon Jan 7 09:28:49 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7864F21F88ED for ; Mon, 7 Jan 2013 09:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.964 X-Spam-Level: X-Spam-Status: No, score=-1.964 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BG43mlTsI2jM for ; Mon, 7 Jan 2013 09:28:48 -0800 (PST) Received: from oproxy5-pub.bluehost.com (oproxy5-pub.bluehost.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id D207521F88DD for ; Mon, 7 Jan 2013 09:28:46 -0800 (PST) Received: (qmail 14888 invoked by uid 0); 7 Jan 2013 17:28:24 -0000 Received: from unknown (HELO just121.justhost.com) (173.254.28.121) by cpoproxy2.bluehost.com with SMTP; 7 Jan 2013 17:28:24 -0000 Received: from [90.152.0.102] (port=60632 helo=[192.168.0.189]) by just121.justhost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1TsGUq-0004eb-9K; Mon, 07 Jan 2013 10:28:24 -0700 Message-ID: <1357579689.29808.16.camel@pd-notebook-linux.croc.internal> From: Peter Dunkley To: =?ISO-8859-1?Q?Sa=FAl?= Ibarra =?ISO-8859-1?Q?Corretg=E9?= Date: Mon, 07 Jan 2013 17:28:09 +0000 In-Reply-To: <4A541458-A884-4BB9-8C0C-EDD8C7CCB2D0@ag-projects.com> References: <20121217161521.30393.14625.idtracker@ietfa.amsl.com> <4A541458-A884-4BB9-8C0C-EDD8C7CCB2D0@ag-projects.com> Organization: Crocodile RCS Ltd Content-Type: multipart/alternative; boundary="=-rryJRgVZ4hXBCmxpBRIl" X-Mailer: Evolution 3.4.4 (3.4.4-2.fc17) Mime-Version: 1.0 X-Identified-User: {596:just121.justhost.com:crocodi1:crocodile-rcs.com} {sentby:smtp auth 90.152.0.102 authed with peter.dunkley@crocodile-rcs.com} Cc: DISPATCH Subject: Re: [dispatch] FW: New Version Notification for draft-pd-dispatch-msrp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 17:28:49 -0000 --=-rryJRgVZ4hXBCmxpBRIl Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Hi Saul, I have put comments in-line below. Thanks, Peter On Wed, 2013-01-02 at 09:34 +0100, Saúl Ibarra Corretgé wrote: > A few comments from an initial (and shallow) read: > > - Section 5.3.1: why mandate authentication? Is there a specific reason for this or could it be left out as an implementation detail? Section 5.3.1 mandates authentication because RFC 4976 does. I did not want to loosen the authentication/security of MSRP relays here but did want to make sure that an appropriate WebSocket compatible mechanism (authenticating the handshake) was in place. At the end of the day, any WebSocket client stack that wants to be able to use a sequence of relays (for example, intra-net and extra-net) will need to support the MSRP relay authentication as per RFC 4976 because the later relays in the sequence will be accessed using TLS from the earlier relays and may issue challenges. > - Section 6: maybe it should be mentioned that in the absence of a WS pint mechanism the defined MSRP way (that is, an empty SEND) should be used? > I will add this to the next issue of the draft. > Given the limitations of WS with regards to receiving incoming connections, I think this document should mention how ACM (http://tools.ietf.org/html/rfc6135) should be used in WS scenarios. > I am not sure this will help: - a WS client cannot receive an incoming connection at all, so when you have two WS clients you must have an MSRP relay acting as an WS server (which the WS clients always initiate the connection to) - a non-WS client will expect to use TCP or TLS not WS, so to allow it to interwork with WS clients you must have an MSRP relay acting as an WS server (which the WS clients always initiate the connection to) to convert between the transports -- Peter Dunkley Technical Director Crocodile RCS Ltd --=-rryJRgVZ4hXBCmxpBRIl Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Hi Saul,

I have put comments in-line below.

Thanks,

Peter

On Wed, 2013-01-02 at 09:34 +0100, Saúl Ibarra Corretgé wrote: 
A few comments from an initial (and shallow) read:

- Section 5.3.1: why mandate authentication? Is there a specific reason for this or could it be left out as an implementation detail?
Section 5.3.1 mandates authentication because RFC 4976 does.  I did not want to loosen the authentication/security of MSRP relays here but did want to make sure that an appropriate WebSocket compatible mechanism (authenticating the handshake) was in place.

At the end of the day, any WebSocket client stack that wants to be able to use a sequence of relays (for example, intra-net and extra-net) will need to support the MSRP relay authentication as per RFC 4976 because the later relays in the sequence will be accessed using TLS from the earlier relays and may issue challenges.

- Section 6: maybe it should be mentioned that in the absence of a WS pint mechanism the defined MSRP way (that is, an empty SEND) should be used?
I will add this to the next issue of the draft.

Given the limitations of WS with regards to receiving incoming connections, I think this document should mention how ACM (http://tools.ietf.org/html/rfc6135) should be used in WS scenarios.
I am not sure this will help:
- a WS client cannot receive an incoming connection at all, so when you have two WS clients you must have an MSRP relay acting as an WS server (which the WS clients always initiate the connection to)
- a non-WS client will expect to use TCP or TLS not WS, so to allow it to interwork with WS clients you must have an MSRP relay acting as an WS server (which the WS clients always initiate the connection to) to convert between the transports

-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd
--=-rryJRgVZ4hXBCmxpBRIl-- From saul@ag-projects.com Mon Jan 7 13:17:20 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0AA21F84F5 for ; Mon, 7 Jan 2013 13:17:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVjXbYjp2nPY for ; Mon, 7 Jan 2013 13:17:19 -0800 (PST) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 79E5021F84E0 for ; Mon, 7 Jan 2013 13:17:18 -0800 (PST) Received: by mail.sipthor.net (Postfix, from userid 5001) id 9A5B8B35E2; Mon, 7 Jan 2013 22:17:12 +0100 (CET) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id CFA83B007E; Mon, 7 Jan 2013 22:16:57 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <1357579689.29808.16.camel@pd-notebook-linux.croc.internal> Date: Mon, 7 Jan 2013 22:16:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <052443FF-6719-4450-B676-10CAEC4D7035@ag-projects.com> References: <20121217161521.30393.14625.idtracker@ietfa.amsl.com> <4A541458-A884-4BB9-8C0C-EDD8C7CCB2D0@ag-projects.com> <1357579689.29808.16.camel@pd-notebook-linux.croc.internal> To: Peter Dunkley X-Mailer: Apple Mail (2.1085) Cc: DISPATCH Subject: Re: [dispatch] FW: New Version Notification for draft-pd-dispatch-msrp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 21:17:20 -0000 Hi Peter, On Jan 7, 2013, at 6:28 PM, Peter Dunkley wrote: > Hi Saul, >=20 > I have put comments in-line below. >=20 > Thanks, >=20 > Peter >=20 > On Wed, 2013-01-02 at 09:34 +0100, Sa=FAl Ibarra Corretg=E9 wrote: >> A few comments from an initial (and shallow) read: >>=20 >> - Section 5.3.1: why mandate authentication? Is there a specific = reason for this or could it be left out as an implementation detail? >>=20 > Section 5.3.1 mandates authentication because RFC 4976 does. I did = not want to loosen the authentication/security of MSRP relays here but = did want to make sure that an appropriate WebSocket compatible mechanism = (authenticating the handshake) was in place. >=20 > At the end of the day, any WebSocket client stack that wants to be = able to use a sequence of relays (for example, intra-net and extra-net) = will need to support the MSRP relay authentication as per RFC 4976 = because the later relays in the sequence will be accessed using TLS from = the earlier relays and may issue challenges. Right, I forgot that open relays are explicitly forbidden y 4976. >=20 >> - Section 6: maybe it should be mentioned that in the absence of a WS = pint mechanism the defined MSRP way (that is, an empty SEND) should be = used? >>=20 >>=20 > I will add this to the next issue of the draft. >=20 >> Given the limitations of WS with regards to receiving incoming = connections, I think this document should mention how ACM = (http://tools.ietf.org/html/rfc6135 >> ) should be used in WS scenarios. >>=20 >>=20 > I am not sure this will help: > - a WS client cannot receive an incoming connection at all, so when = you have two WS clients you must have an MSRP relay acting as an WS = server (which the WS clients always initiate the connection to) > - a non-WS client will expect to use TCP or TLS not WS, so to allow it = to interwork with WS clients you must have an MSRP relay acting as an WS = server (which the WS clients always initiate the connection to) to = convert between the transports >=20 Actually, we can use it to our advantage. Using an outbound relay didn't = make any sense until ACM came out. With ACM, if a user is using a relay = it can set a=3Dsetup:actpass, because it's very likely that the relay is = able to handle the incoming connection without any problem. That said, = and given that a=3Dsetup:passive is not allowed in an offer, I guess = there is nothing to be said about ACM in the end, it just works :-) = Sorry for the noise there. Cheers, -- Sa=FAl Ibarra Corretg=E9 AG Projects From vumip1@gmail.com Mon Jan 7 16:34:06 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADFD31F0CB3 for ; Mon, 7 Jan 2013 16:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2f9DeRERFAw for ; Mon, 7 Jan 2013 16:34:06 -0800 (PST) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDE81F0C5F for ; Mon, 7 Jan 2013 16:34:04 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id fs13so17186095lab.23 for ; Mon, 07 Jan 2013 16:34:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=jBF1PK93aTkV/6NaT3wh249humVuxQfAach/MaI/m8Y=; b=MG3gTum4QqbcOh+tTlCsAjddDrcL3IpaOLRL0FJq6JfzhYhXw8Ikzki3/6Uk+a99xq FgoOWOfwXgv/NesZlRh0T1TojdWx4/MRQMS51xR9gTOXp8oYGIT9FKdJEhvVyo3J3/rN Cp7SdUgS18XxRgeFvUozdiCzfglWHZTlKoaBxbhoU5Jlshvo4JhUyWMhEWf/wSIlAaWh 8Ka85ZHFUrAkJSTJro+JUXT5i8aiKDhI98TeVZv1ig438Bj2STjsQvW6dS9pVKtEI5aO xLW0DN24gpS6SndVUGL6yicsPGOILDlPeD2LDt8CQ/bCavo78U27pz11qD4F4XwKPjjQ SvUw== MIME-Version: 1.0 Received: by 10.112.17.129 with SMTP id o1mr25569793lbd.54.1357605243424; Mon, 07 Jan 2013 16:34:03 -0800 (PST) Received: by 10.114.29.198 with HTTP; Mon, 7 Jan 2013 16:34:03 -0800 (PST) Date: Mon, 7 Jan 2013 19:34:03 -0500 Message-ID: From: "B.Khasnabish@ieee.org" To: dispatch@ietf.org Content-Type: multipart/alternative; boundary=bcaec554d944478fc404d2bc1a37 Subject: [dispatch] Fwd: End-point based Multimedia QoE Management draft (draft-khasnabish-dispatch-qoe-management-00.txt) published X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 00:34:06 -0000 --bcaec554d944478fc404d2bc1a37 Content-Type: text/plain; charset=ISO-8859-1 FYI and kind review/comments/suggestions. Thanks. Happy New Year to Everyone. Best. Bhumip I-D Action: draft-khasnabish-dispatch-qoe-management-00.txt ------------------------------ - *To*: i-d-announce at ietf.org - *Subject*: I-D Action: draft-khasnabish-dispatch-qoe-management-00.txt - *From*: internet-drafts at ietf.org - *Date*: Mon, 31 Dec 2012 19:18:28 -0800 - *Delivered-to*: i-d-announce at ietfa.amsl.com - *List-archive*: - *List-help*: > - *List-id*: Internet Draft Announcements only - *List-post*: > - *List-subscribe*: , > - *List-unsubscribe*: , > - *Reply-to*: internet-drafts at ietf.org ------------------------------ A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : End-point based Multimedia QoE Management Author(s) : Bhumip Khasnabish Gerard Fernando Filename : draft-khasnabish-dispatch-qoe-management-00.txt Pages : 17 Date : 2012-12-31 Abstract: This draft describes a method for improving the quality of experience (QoE) for real-time video and other multimedia services using features and functions of the end-point only, that is, without requiring any upgrade to the network transport infrastructure. Any upgrade to the network transport infrastructure not only incurs significant costs, these are also time consuming and technology- dependent. Therefore, these QoE improvement mechanisms are significantly more attractive to both network operators and service providers. The IETF datatracker status page for this draft is:https://datatracker.ietf.org/doc/draft-khasnabish-dispatch-qoe-management There's also a htmlized version available at:http://tools.ietf.org/html/draft-khasnabish-dispatch-qoe-management-00 Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.org/internet-drafts/ --bcaec554d944478fc404d2bc1a37 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
FYI and = kind review/comments/suggestions. Thanks.=A0
= =A0
Happy Ne= w Year to Everyone.
= =A0
Best.
= =A0
Bhumip

=A0

I-D Action: draft-khasnabish-dispatch-qoe-management-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.


	Title           : End-point based Multimedia QoE Management
	Author(s)       : Bhumip Khasnabish
                          Gerard Fernando
	Filename        : draft-khasnabish-dispatch-qoe-management-00.txt
	Pages           : 17
	Date            : 2012-12-31

Abstract:
   This draft describes a method for improving the quality of experience
   (QoE) for real-time video and other multimedia services using
   features and functions of the end-point only, that is, without
   requiring any upgrade to the network transport infrastructure.  Any
   upgrade to the network transport infrastructure not only incurs
   significant costs, these are also time consuming and technology-
   dependent.  Therefore, these QoE improvement mechanisms are
   significantly more attractive to both network operators and service
   providers.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-khasnabi=
sh-dispatch-qoe-management

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-khasnabish-dispat=
ch-qoe-management-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.=
ietf.org/internet-drafts/
--bcaec554d944478fc404d2bc1a37-- From gavin.llewellyn@crocodile-rcs.com Tue Jan 8 06:02:42 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A859421F89CB for ; Tue, 8 Jan 2013 06:02:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.964 X-Spam-Level: X-Spam-Status: No, score=-1.964 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssQ9I0VbmaDH for ; Tue, 8 Jan 2013 06:02:42 -0800 (PST) Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id 1251A21F84A1 for ; Tue, 8 Jan 2013 06:02:40 -0800 (PST) Received: (qmail 19280 invoked by uid 0); 8 Jan 2013 14:02:15 -0000 Received: from unknown (HELO just121.justhost.com) (173.254.28.121) by oproxy13.unifiedlayer.com with SMTP; 8 Jan 2013 14:02:15 -0000 Received: from [90.152.0.102] (port=53196 helo=[192.168.0.144]) by just121.justhost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1TsZkt-0006zV-9p; Tue, 08 Jan 2013 07:02:15 -0700 Message-ID: <50EC26E4.4080109@crocodile-rcs.com> Date: Tue, 08 Jan 2013 14:02:12 +0000 From: Gavin Llewellyn Organization: Crocodile RCS Ltd User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= References: <20121217161521.30393.14625.idtracker@ietfa.amsl.com> <4A541458-A884-4BB9-8C0C-EDD8C7CCB2D0@ag-projects.com> <1357578758.29808.3.camel@pd-notebook-linux.croc.internal> In-Reply-To: <1357578758.29808.3.camel@pd-notebook-linux.croc.internal> Content-Type: multipart/alternative; boundary="------------090500060905020206030204" X-Identified-User: {596:just121.justhost.com:crocodi1:crocodile-rcs.com} {sentby:smtp auth 90.152.0.102 authed with gavin.llewellyn@crocodile-rcs.com} Cc: dispatch@ietf.org Subject: Re: [dispatch] FW: New Version Notification for draft-pd-dispatch-msrp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 14:02:42 -0000 This is a multi-part message in MIME format. --------------090500060905020206030204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Inaki, IMHO, the SDP is correct - the SDP negotiation is trying to set up the leg beyond the WebSocket MSRP relay, and this is expected to be a TCP or TLS connection. The WebSocket leg of the relay chain is already established when the SDP is constructed, and isn't relevant to the far end (though it can be spotted from the URIs in the path attribute if necessary). I think we'd have more work to do if we wanted to negotiate some other MSRP transport beyond the relay, but since the WebSocket transport is only used (and only useful) at the edges of the link I don't think the SDP needs to change. Regards, Gavin Gavin Llewellyn Principal Design Engineer Crocodile RCS Ltd On 07/01/2013 17:12, Peter Dunkley wrote: > Hi Inaki, > > I agree that section 5.2.2 is a hack. The problem is trying to make > sure that there aren't interworking problems with existing clients > (which may not have robust SDP parsing) without needing to do SDP > mangling in the SIP server. > > Any suggestions on how to improve this section would be more than welcome! > > Peter > > On Fri, 2013-01-04 at 16:10 +0100, Iñaki Baz Castillo wrote: >> Hi all, >> >> I support this work and, in fact, plan to implement it. >> >> The only point I don't like (until a deeper review) is 5.2.2, it seems >> a hack IMHO. >> >> Regards. >> >> > > -- > Peter Dunkley > Technical Director > Crocodile RCS Ltd > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --------------090500060905020206030204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Inaki,

IMHO, the SDP is correct - the SDP negotiation is trying to set up the leg beyond the WebSocket MSRP relay, and this is expected to be a TCP or TLS connection.  The WebSocket leg of the relay chain is already established when the SDP is constructed, and isn't relevant to the far end (though it can be spotted from the URIs in the path attribute if necessary).

I think we'd have more work to do if we wanted to negotiate some other MSRP transport beyond the relay, but since the WebSocket transport is only used (and only useful) at the edges of the link I don't think the SDP needs to change.

Regards,
Gavin
Gavin Llewellyn
Principal Design Engineer
Crocodile RCS Ltd
On 07/01/2013 17:12, Peter Dunkley wrote:
Hi Inaki,

I agree that section 5.2.2 is a hack.  The problem is trying to make sure that there aren't interworking problems with existing clients (which may not have robust SDP parsing) without needing to do SDP mangling in the SIP server.

Any suggestions on how to improve this section would be more than welcome!

Peter

On Fri, 2013-01-04 at 16:10 +0100, Iñaki Baz Castillo wrote: 
Hi all,

I support this work and, in fact, plan to implement it.

The only point I don't like (until a deeper review) is 5.2.2, it seems
a hack IMHO.

Regards.




-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd



_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--------------090500060905020206030204-- From ibc@aliax.net Tue Jan 8 06:28:25 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEED721F8900 for ; Tue, 8 Jan 2013 06:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iho6MkDxoN0K for ; Tue, 8 Jan 2013 06:28:25 -0800 (PST) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) by ietfa.amsl.com (Postfix) with ESMTP id 195AB21F842E for ; Tue, 8 Jan 2013 06:28:25 -0800 (PST) Received: by mail-qc0-f181.google.com with SMTP id x40so598547qcp.40 for ; Tue, 08 Jan 2013 06:28:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=NKS6Tx/wQa811M49hHuys+LASURmuqA+GOB1KLfjBsw=; b=JrLdrw2prxvWaK1TfHnQrTd8CnPZwpyX/pCke8/wGkmrf0u3TR9gz2HglzB9x39HBu tDKH9WNVLD9fVRvyj6w+HxJuOlDSE1N9zwpV7Cxt6UgvQO2hWsMdE/Si2rkf0D46ABTM SJ86qjH4hevRKysW9vC2jdRWVOT/iqPpU7IM7jyZFAO7AP8vKcZXxFEW/7Fvul50AoOj BCAwqsnBl8aFFoTx4JwqXV3fybI6NG2fyvQhvPVycPmzjvuITl0sJvCDvrJQZQW+fMQj UdgBIlSXLvJreYSIvG/QY0L4sMhkUnGY8GtbwVC9HDxXfbzQPNSJOVI6XPaphIleEJDH zfoA== Received: by 10.49.29.135 with SMTP id k7mr55425047qeh.39.1357655304424; Tue, 08 Jan 2013 06:28:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.94.193 with HTTP; Tue, 8 Jan 2013 06:28:04 -0800 (PST) In-Reply-To: <1357578758.29808.3.camel@pd-notebook-linux.croc.internal> References: <20121217161521.30393.14625.idtracker@ietfa.amsl.com> <4A541458-A884-4BB9-8C0C-EDD8C7CCB2D0@ag-projects.com> <1357578758.29808.3.camel@pd-notebook-linux.croc.internal> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 8 Jan 2013 15:28:04 +0100 Message-ID: To: Peter Dunkley Content-Type: multipart/alternative; boundary=047d7bea3f1425cdcf04d2c7c2a5 X-Gm-Message-State: ALoCoQnY/gp7XjgorY0LInLGwcGCcEWXrTX6bKjSYMVrDfNcQijGE91Y4gsqYLGI8lJJyoSOvIl0 Cc: dispatch@ietf.org Subject: Re: [dispatch] FW: New Version Notification for draft-pd-dispatch-msrp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 14:28:26 -0000 --047d7bea3f1425cdcf04d2c7c2a5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2013/1/7 Peter Dunkley > Hi Inaki, > > I agree that section 5.2.2 is a hack. The problem is trying to make sure > that there aren't interworking problems with existing clients (which may > not have robust SDP parsing) without needing to do SDP mangling in the SI= P > server. > > Any suggestions on how to improve this section would be more than welcome= ! > Hi Peter, I understand your concerns, but IMHO a new specification should not mention that. Obviously when a new specification appears old clients should be updated if they want to interoperate with the new spec or with devices using the new spec. Anyhow RFC 4975 already defines the ;trasport parameter as: transport =3D "tcp" / 1*ALPHANUM So existing clients MUST NOT assume just "tcp", even less in URI's they must not directly contact to (which is the case since a non WS MSRP client won't never directly contact a WS MSRP client, but a TCP MSRP relay. IMHO the nex spec cannot allow violating its own grammar. WS clients should use "ws" transport in the MSRP URI. Have you seen MSRP clients failing when the SDP includes a MSRP URI with "ws" transport? --=20 I=C3=B1aki Baz Castillo --047d7bea3f1425cdcf04d2c7c2a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2013/1/7 Peter Dunkley <peter.dunkley@crocodile-rcs.com&= gt;
Hi Inaki,

I agree that section 5.2.2 is a hack.=C2=A0 The problem is trying to make s= ure that there aren't interworking problems with existing clients (whic= h may not have robust SDP parsing) without needing to do SDP mangling in th= e SIP server.

Any suggestions on how to improve this section would be more than welcome!<= /div>

Hi Peter, I understand your concerns, but IMHO = a new specification should not mention that. Obviously when a new specifica= tion appears old clients should be updated if they want to interoperate wit= h the new spec or with devices using the new spec.

Anyhow RFC 4975 already defines the ;trasport parameter= as:

  transport =3D "tcp" / 1*ALPH=
ANUM

So existing clients MUST NOT assume just "tcp"=
;, even less in URI's they must not directly contact to (which is the c=
ase since a non WS MSRP client won't never directly contact a WS MSRP c=
lient, but a TCP MSRP relay.

IMHO the nex spec cannot allow violating its own gramma=
r. WS clients should use "ws" transport in the MSRP URI. Have you=
 seen MSRP clients failing when the SDP includes a MSRP URI with "ws&q=
uot; transport?


--
I=C3=B1aki Baz Castillo
<<= a href=3D"mailto:ibc@aliax.net">ibc@aliax.net> --047d7bea3f1425cdcf04d2c7c2a5-- From gavin.llewellyn@crocodile-rcs.com Tue Jan 8 07:23:39 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04FEB21F8A8B for ; Tue, 8 Jan 2013 07:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.131 X-Spam-Level: X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+UDXt0rzCeL for ; Tue, 8 Jan 2013 07:23:38 -0800 (PST) Received: from oproxy11-pub.bluehost.com (oproxy11-pub.bluehost.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id D731821F8A74 for ; Tue, 8 Jan 2013 07:23:36 -0800 (PST) Received: (qmail 19850 invoked by uid 0); 8 Jan 2013 15:23:08 -0000 Received: from unknown (HELO just121.justhost.com) (173.254.28.121) by oproxy11.bluehost.com with SMTP; 8 Jan 2013 15:23:08 -0000 Received: from [90.152.0.102] (port=53530 helo=[192.168.0.144]) by just121.justhost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1Tsb19-0006m5-QP; Tue, 08 Jan 2013 08:23:08 -0700 Message-ID: <50EC39D9.2020706@crocodile-rcs.com> Date: Tue, 08 Jan 2013 15:23:05 +0000 From: Gavin Llewellyn Organization: Crocodile RCS Ltd User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= References: <20121217161521.30393.14625.idtracker@ietfa.amsl.com> <4A541458-A884-4BB9-8C0C-EDD8C7CCB2D0@ag-projects.com> <1357578758.29808.3.camel@pd-notebook-linux.croc.internal> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030806060701030806010908" X-Identified-User: {596:just121.justhost.com:crocodi1:crocodile-rcs.com} {sentby:smtp auth 90.152.0.102 authed with gavin.llewellyn@crocodile-rcs.com} Cc: dispatch@ietf.org Subject: Re: [dispatch] FW: New Version Notification for draft-pd-dispatch-msrp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 15:23:39 -0000 This is a multi-part message in MIME format. --------------030806060701030806010908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Inaki, OK, I understand what you mean now. It is not our intention to hide the "ws" parameter in the URIs; the section was instead referring to the protocol component of the m-line. I suggest that 5.2.2 be clarified as follows: This document does not define a new SDP transport protocol for MSRP over WebSockets. As all MSRP over WebSocket messages MUST be routed via an MSRP WebSocket Server, it is acceptable for an MSRP WebSocket Client to specify the "TCP/MSRP" or "TCP/TLS/MSRP" protocols in the SDP m-line - that being the protocol used by non-WebSocket clients and between MSRP relays (RFC 4975 Section 8.1). The "ws" transport parameter will appear in the endpoint URI in the SDP "path" attribute (RFC 4975 Section 8.2); compliant MSRP implementations should already allow unrecognised transports, provided that they do not have to establish a direct connection to the resource described by the URI. Does this make more sense? Regards, Gavin Gavin Llewellyn Principal Design Engineer Crocodile RCS Ltd On 08/01/2013 14:28, Iñaki Baz Castillo wrote: > 2013/1/7 Peter Dunkley > > > Hi Inaki, > > I agree that section 5.2.2 is a hack. The problem is trying to > make sure that there aren't interworking problems with existing > clients (which may not have robust SDP parsing) without needing to > do SDP mangling in the SIP server. > > Any suggestions on how to improve this section would be more than > welcome! > > > Hi Peter, I understand your concerns, but IMHO a new specification > should not mention that. Obviously when a new specification appears > old clients should be updated if they want to interoperate with the > new spec or with devices using the new spec. > > Anyhow RFC 4975 already defines the ;trasport parameter as: > > transport = "tcp" / 1*ALPHANUM > So existing clients MUST NOT assume just "tcp", even less in URI's they must not directly contact to (which is the case since a non WS MSRP client won't never directly contact a WS MSRP client, but a TCP MSRP relay. > IMHO the nex spec cannot allow violating its own grammar. WS clients should use "ws" transport in the MSRP URI. Have you seen MSRP clients failing when the SDP includes a MSRP URI with "ws" transport? > -- > Iñaki Baz Castillo > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --------------030806060701030806010908 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Inaki,

OK, I understand what you mean now.  It is not our intention to hide the "ws" parameter in the URIs; the section was instead referring to the protocol component of the m-line.  I suggest that 5.2.2 be clarified as follows:
This document does not define a new SDP transport protocol for MSRP over WebSockets.  As all MSRP over WebSocket messages MUST be routed via an MSRP WebSocket Server, it is acceptable for an MSRP WebSocket Client to specify the "TCP/MSRP" or "TCP/TLS/MSRP" protocols in the SDP m-line - that being the protocol used by non-WebSocket clients and between MSRP relays (RFC 4975 Section 8.1).

The "ws" transport parameter will appear in the endpoint URI in the SDP "path" attribute (RFC 4975 Section 8.2); compliant MSRP implementations should already allow unrecognised transports, provided that they do not have to establish a direct connection to the resource described by the URI.
Does this make more sense?

Regards,
Gavin

Gavin Llewellyn
Principal Design Engineer
Crocodile RCS Ltd
On 08/01/2013 14:28, Iñaki Baz Castillo wrote:
2013/1/7 Peter Dunkley <peter.dunkley@crocodile-rcs.com>
Hi Inaki,

I agree that section 5.2.2 is a hack.  The problem is trying to make sure that there aren't interworking problems with existing clients (which may not have robust SDP parsing) without needing to do SDP mangling in the SIP server.

Any suggestions on how to improve this section would be more than welcome!

Hi Peter, I understand your concerns, but IMHO a new specification should not mention that. Obviously when a new specification appears old clients should be updated if they want to interoperate with the new spec or with devices using the new spec.

Anyhow RFC 4975 already defines the ;trasport parameter as:

  transport = "tcp" / 1*ALPHANUM

        
So existing clients MUST NOT assume just "tcp", even less in URI's they must not directly contact to (which is the case since a non WS MSRP client won't never directly contact a WS MSRP client, but a TCP MSRP relay.

        

        
IMHO the nex spec cannot allow violating its own grammar. WS clients should use "ws" transport in the MSRP URI. Have you seen MSRP clients failing when the SDP includes a MSRP URI with "ws" transport?

        

        

      

      -- 

      Iñaki Baz Castillo

      <ibc@aliax.net>
      

      

      

      
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


    

    

  


--------------030806060701030806010908--

From ibc@aliax.net  Tue Jan  8 07:52:26 2013
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56DC821F8841 for ; Tue,  8 Jan 2013 07:52:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.577
X-Spam-Level: 
X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id coBtABzrchSn for ; Tue,  8 Jan 2013 07:52:22 -0800 (PST)
Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) by ietfa.amsl.com (Postfix) with ESMTP id 23CCC21F8833 for ; Tue,  8 Jan 2013 07:52:22 -0800 (PST)
Received: by mail-qc0-f174.google.com with SMTP id o22so729142qcr.5 for ; Tue, 08 Jan 2013 07:52:21 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=INYGExV8l4hSw6YImy1wCndCvGjURB1bQ3GNG1SSsvo=; b=QmGyoWDVuItLrGFobJ1lDxvRqUjIpX+XYBh3mveviakui0X/+mlxY17JxDM5i6fT5E EuSaGvG/8ncPZEdONUPl/Envc0eKzS7Lq1LlkVChYs20FFakYU1A1tNqhtKIOV50xedS HB3OUzbF6Di94LJYWGHqfQR3Zk3MN2heUTdHbhZlEZAmxbTppNa8Rbvxi7Wv+Gh5ZM8u Pk0vqHniQRhZxppz//bEOUwZby+4qZPSQ22w7cdVO+S6lSZtTv2HEesqVFnbuV23TeF9 ZNNY4ewMYA0P7ipE0FbsLs6evw0mCPbGSwlegz4qoVOn46GmAVIASkIpH5jB6JeBnSRQ FCMA==
Received: by 10.224.35.137 with SMTP id p9mr46905700qad.85.1357660341303; Tue, 08 Jan 2013 07:52:21 -0800 (PST)
MIME-Version: 1.0
Received: by 10.49.94.193 with HTTP; Tue, 8 Jan 2013 07:52:01 -0800 (PST)
In-Reply-To: <50EC39D9.2020706@crocodile-rcs.com>
References: <20121217161521.30393.14625.idtracker@ietfa.amsl.com>   <4A541458-A884-4BB9-8C0C-EDD8C7CCB2D0@ag-projects.com>  <1357578758.29808.3.camel@pd-notebook-linux.croc.internal>  <50EC39D9.2020706@crocodile-rcs.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Tue, 8 Jan 2013 16:52:01 +0100
Message-ID: 
To: Gavin Llewellyn 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQl1+OG7QlCj3GL0KMiibPrk4QwnwEShmEd/6uEn1sNE6JV60LpsJMeqMcblzNjo3tlN7pvC
Cc: dispatch@ietf.org
Subject: Re: [dispatch] FW: New Version Notification for draft-pd-dispatch-msrp-websocket-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Jan 2013 15:52:26 -0000

2013/1/8 Gavin Llewellyn :
> OK, I understand what you mean now.  It is not our intention to hide the
> "ws" parameter in the URIs; the section was instead referring to the
> protocol component of the m-line.

Hi Gavin, could you please alter the example in section 11 of RFC 4976
(MSRP Relay) assuming that Alice (initiator) is a WS MSRP client (so
she needs to provide a MSRP line) and Bob a TCP MSRP client (which
needs to provice a TCP MSRP line)?

It could clarify this a bit more.

Thanks a lot.

--=20
I=C3=B1aki Baz Castillo


From gavin.llewellyn@crocodile-rcs.com  Tue Jan  8 08:32:18 2013
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B8621F867B for ; Tue,  8 Jan 2013 08:32:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.048
X-Spam-Level: 
X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIrKUVsoG9lr for ; Tue,  8 Jan 2013 08:32:17 -0800 (PST)
Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id DA6DB21F859B for ; Tue,  8 Jan 2013 08:32:16 -0800 (PST)
Received: (qmail 13420 invoked by uid 0); 8 Jan 2013 16:31:53 -0000
Received: from unknown (HELO just121.justhost.com) (173.254.28.121) by cpoproxy3.bluehost.com with SMTP; 8 Jan 2013 16:31:53 -0000
Received: from [90.152.0.102] (port=53630 helo=[192.168.0.144]) by just121.justhost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1Tsc5g-0000kL-Qf; Tue, 08 Jan 2013 09:31:52 -0700
Message-ID: <50EC49F6.3060905@crocodile-rcs.com>
Date: Tue, 08 Jan 2013 16:31:50 +0000
From: Gavin Llewellyn 
Organization: Crocodile RCS Ltd
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= 
References: <20121217161521.30393.14625.idtracker@ietfa.amsl.com>   <4A541458-A884-4BB9-8C0C-EDD8C7CCB2D0@ag-projects.com>  <1357578758.29808.3.camel@pd-notebook-linux.croc.internal>  <50EC39D9.2020706@crocodile-rcs.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Identified-User: {596:just121.justhost.com:crocodi1:crocodile-rcs.com} {sentby:smtp auth 90.152.0.102 authed with gavin.llewellyn@crocodile-rcs.com}
Cc: dispatch@ietf.org
Subject: Re: [dispatch] FW: New Version Notification for draft-pd-dispatch-msrp-websocket-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Jan 2013 16:32:18 -0000

We will include some sample SDP in section 8 of the next draft.

Regards,
Gavin

Gavin Llewellyn
Principal Design Engineer
Crocodile RCS Ltd

On 08/01/2013 15:52, Iñaki Baz Castillo wrote:
> 2013/1/8 Gavin Llewellyn :
>> OK, I understand what you mean now.  It is not our intention to hide the
>> "ws" parameter in the URIs; the section was instead referring to the
>> protocol component of the m-line.
> Hi Gavin, could you please alter the example in section 11 of RFC 4976
> (MSRP Relay) assuming that Alice (initiator) is a WS MSRP client (so
> she needs to provide a MSRP line) and Bob a TCP MSRP client (which
> needs to provice a TCP MSRP line)?
>
> It could clarify this a bit more.
>
> Thanks a lot.
>


From peter.dunkley@crocodile-rcs.com  Tue Jan  8 10:18:41 2013
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2FE1F0CFA for ; Tue,  8 Jan 2013 10:18:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.114
X-Spam-Level: 
X-Spam-Status: No, score=-2.114 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3v5YUayQQFe for ; Tue,  8 Jan 2013 10:18:40 -0800 (PST)
Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id A910C1F0CB3 for ; Tue,  8 Jan 2013 10:18:40 -0800 (PST)
Received: (qmail 21314 invoked by uid 0); 8 Jan 2013 18:18:15 -0000
Received: from unknown (HELO just121.justhost.com) (173.254.28.121) by oproxy7.bluehost.com with SMTP; 8 Jan 2013 18:18:15 -0000
Received: from [90.152.0.102] (port=34471 helo=[192.168.0.189]) by just121.justhost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1Tsdkd-0007lB-2Z for dispatch@ietf.org; Tue, 08 Jan 2013 11:18:15 -0700
Message-ID: <1357669085.6214.25.camel@pd-notebook-linux.croc.internal>
From: Peter Dunkley 
To: dispatch@ietf.org
Date: Tue, 08 Jan 2013 18:18:05 +0000
Organization: Crocodile RCS Ltd
Content-Type: multipart/alternative; boundary="=-g2v/64fQkxpAGCSXT5Y3"
X-Mailer: Evolution 3.4.4 (3.4.4-2.fc17) 
Mime-Version: 1.0
X-Identified-User: {596:just121.justhost.com:crocodi1:crocodile-rcs.com} {sentby:smtp auth 90.152.0.102 authed with peter.dunkley@crocodile-rcs.com}
Subject: [dispatch] [Fwd: New Version Notification for draft-pd-dispatch-msrp-websocket-01.txt]
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Jan 2013 18:18:41 -0000

--=-g2v/64fQkxpAGCSXT5Y3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

Dear DISPATCH,

Here is an updated version of draft-pd-dispatch-msrp-websocket.  The
changes from the previous version are:
* Section 5.2.2, clarifying the SDP handling (thanks to Inaki Baz
Castillo for his comments)
* Section 6, allowing the use of MSRP keep alives when WebSocket pings
are not available (thanks to Saul Ibarra Corretge for his comments)
* New section 8.2, containing example SDP (thanks to Inaki Baz Castillo
for his comment)

Regards,

Peter

-------- Forwarded Message --------
From: internet-drafts@ietf.org
To: peter.dunkley@crocodile-rcs.com
Cc: vpascual@acmepacket.com, gavin.llewellyn@crocodile-rcs.com
Subject: New Version Notification for
draft-pd-dispatch-msrp-websocket-01.txt
Date: Tue, 08 Jan 2013 10:12:53 -0800


A new version of I-D, draft-pd-dispatch-msrp-websocket-01.txt
has been successfully submitted by Peter Dunkley and posted to the
IETF repository.

Filename:	 draft-pd-dispatch-msrp-websocket
Revision:	 01
Title:		 The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP)
Creation date:	 2013-01-08
WG ID:		 Individual Submission
Number of pages: 21
URL:             http://www.ietf.org/internet-drafts/draft-pd-dispatch-msrp-websocket-01.txt
Status:          http://datatracker.ietf.org/doc/draft-pd-dispatch-msrp-websocket
Htmlized:        http://tools.ietf.org/html/draft-pd-dispatch-msrp-websocket-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-pd-dispatch-msrp-websocket-01

Abstract:
   The WebSocket protocol enables two-way real-time communication
   between clients and servers.  This document specifies a new WebSocket
   sub-protocol as a reliable transport mechanism between MSRP (Message
   Session Relay Protocol) clients and relays to enable usage of MSRP in
   new scenarios.  This document normatively updates RFC 4975 and RFC
   4976.

                                                                                  


The IETF Secretariat



-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd

--=-g2v/64fQkxpAGCSXT5Y3
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit




  
  


Dear DISPATCH,



Here is an updated version of draft-pd-dispatch-msrp-websocket.  The changes from the previous version are:

* Section 5.2.2, clarifying the SDP handling (thanks to Inaki Baz Castillo for his comments)

* Section 6, allowing the use of MSRP keep alives when WebSocket pings are not available (thanks to Saul Ibarra Corretge for his comments)

* New section 8.2, containing example SDP (thanks to Inaki Baz Castillo for his comment)



Regards,



Peter



-------- Forwarded Message --------

From: internet-drafts@ietf.org

To: peter.dunkley@crocodile-rcs.com

Cc: vpascual@acmepacket.com, gavin.llewellyn@crocodile-rcs.com

Subject: New Version Notification for draft-pd-dispatch-msrp-websocket-01.txt

Date: Tue, 08 Jan 2013 10:12:53 -0800




A new version of I-D, draft-pd-dispatch-msrp-websocket-01.txt
has been successfully submitted by Peter Dunkley and posted to the
IETF repository.

Filename:	 draft-pd-dispatch-msrp-websocket
Revision:	 01
Title:		 The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP)
Creation date:	 2013-01-08
WG ID:		 Individual Submission
Number of pages: 21
URL:             http://www.ietf.org/internet-drafts/draft-pd-dispatch-msrp-websocket-01.txt
Status:          http://datatracker.ietf.org/doc/draft-pd-dispatch-msrp-websocket
Htmlized:        http://tools.ietf.org/html/draft-pd-dispatch-msrp-websocket-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-pd-dispatch-msrp-websocket-01

Abstract:
   The WebSocket protocol enables two-way real-time communication
   between clients and servers.  This document specifies a new WebSocket
   sub-protocol as a reliable transport mechanism between MSRP (Message
   Session Relay Protocol) clients and relays to enable usage of MSRP in
   new scenarios.  This document normatively updates RFC 4975 and RFC
   4976.

                                                                                  


The IETF Secretariat











-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd










--=-g2v/64fQkxpAGCSXT5Y3--


From ibc@aliax.net  Tue Jan  8 10:32:58 2013
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7892421F8518 for ; Tue,  8 Jan 2013 10:32:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8JQcpyXmrSB for ; Tue,  8 Jan 2013 10:32:56 -0800 (PST)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6D721F8507 for ; Tue,  8 Jan 2013 10:32:56 -0800 (PST)
Received: by mail-qc0-f172.google.com with SMTP id b25so969000qca.17 for ; Tue, 08 Jan 2013 10:32:46 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=H8mIZtO7o9zD3YdJRdjPaMj4M1eXHD4onersyk1kF6c=; b=RiHp4wwPxIskUy9lIog1wvJGjv7JKfTbw5HiwTBwOwlo5dLD6izXlcFawAVFHSUfKt EXPR4rgQCoQZ+7QXyDiezebwL0BHgGmGSkOInBZ3uSj0YLA8RjSpySE485GJvOo2ahkh 1vWu//SDjZc3Ce4Ozp3PmpFSE5sE10CzlZUpFNU1kfQ2a9CbQLAwjjf/lKXB7L3B/7Yw fJfeFlKJDmD6fo7IdgCBbItTwWErYdW3GT/1NYCcgjPq7VAfSifOtpPG1QSKYOSbAI3v FB52h7Mf1/6Gdr35EthBrQ9bGXweIYijbyfRUBya1ecjQ1+TIdoPG61giuZ0O02GU9ol rVrw==
Received: by 10.49.73.232 with SMTP id o8mr56120391qev.0.1357669966541; Tue, 08 Jan 2013 10:32:46 -0800 (PST)
MIME-Version: 1.0
Received: by 10.49.94.193 with HTTP; Tue, 8 Jan 2013 10:32:26 -0800 (PST)
In-Reply-To: <50EC49F6.3060905@crocodile-rcs.com>
References: <20121217161521.30393.14625.idtracker@ietfa.amsl.com>   <4A541458-A884-4BB9-8C0C-EDD8C7CCB2D0@ag-projects.com>  <1357578758.29808.3.camel@pd-notebook-linux.croc.internal>  <50EC39D9.2020706@crocodile-rcs.com>  <50EC49F6.3060905@crocodile-rcs.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Tue, 8 Jan 2013 19:32:26 +0100
Message-ID: 
To: Gavin Llewellyn 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQmW3xsBefSEol/oEzP89m/j16q+Cgyuo49MS05zFDY/SMcVva02yEBCvvHKiVTIn25HhyX1
Cc: dispatch@ietf.org
Subject: Re: [dispatch] FW: New Version Notification for draft-pd-dispatch-msrp-websocket-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Jan 2013 18:32:58 -0000

2013/1/8 Gavin Llewellyn :
> We will include some sample SDP in section 8 of the next draft.

Great. Thanks a lot.



--=20
I=C3=B1aki Baz Castillo


From ibc@aliax.net  Wed Jan  9 01:29:26 2013
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFE221F8561 for ; Wed,  9 Jan 2013 01:29:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.617
X-Spam-Level: 
X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kScCwel3PT3b for ; Wed,  9 Jan 2013 01:29:25 -0800 (PST)
Received: from mail-vb0-f52.google.com (mail-vb0-f52.google.com [209.85.212.52]) by ietfa.amsl.com (Postfix) with ESMTP id 9825A21F8438 for ; Wed,  9 Jan 2013 01:29:25 -0800 (PST)
Received: by mail-vb0-f52.google.com with SMTP id ez10so1309391vbb.39 for ; Wed, 09 Jan 2013 01:29:24 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=q0b4X7O/BUrke6QpAjedyAB5UwXNsoXrVLalkyduoIY=; b=KgE2MqCapBDhrkXb+xNnyHTfiZF+46A/PzoQ0beLaYtcKdeMj1SALipmoA2Pp+H5lQ /htE/HJssi9mwsX08+Q+foCSQefAAJqTIzNrQw61nhXdB/meSXcN3qVqqyc8r1nUDHA0 OZu1qWrjrqFs0jR6Qg2/VwN6sJHT4XzTmd6uIksTEJHSq4SqIDd8RF8nILkbf3yMiXRp PDzSrwmkyjwSFl9Guqx0SfzBKLP73bdr5wKbNHBo3h/pDSglZVUCL0lY7LUD5jv7i00C /ZQRGbN37RP0MDEwh0m+NnKEDMQJMMBt0ih+XBomCNMkwqau1oDH8lBtjfjqWnTiJtTw 9X+w==
Received: by 10.52.89.242 with SMTP id br18mr76837980vdb.22.1357723764669; Wed, 09 Jan 2013 01:29:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.59.11.97 with HTTP; Wed, 9 Jan 2013 01:29:00 -0800 (PST)
In-Reply-To: <50EC39D9.2020706@crocodile-rcs.com>
References: <20121217161521.30393.14625.idtracker@ietfa.amsl.com>   <4A541458-A884-4BB9-8C0C-EDD8C7CCB2D0@ag-projects.com>  <1357578758.29808.3.camel@pd-notebook-linux.croc.internal>  <50EC39D9.2020706@crocodile-rcs.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Wed, 9 Jan 2013 10:29:00 +0100
Message-ID: 
To: Gavin Llewellyn 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQnNFglvkc1ZZc5homc8kU8XuzgFbYOJ1kNZSx5O9V/2f5fRtG7Q+4JH7goduEKFfj4xuVCB
Cc: dispatch@ietf.org
Subject: Re: [dispatch] FW: New Version Notification for draft-pd-dispatch-msrp-websocket-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Jan 2013 09:29:26 -0000

Hi Gavin, Peter,

I've read revision 01 of the draft. Just some comments related to the
subject below:



2013/1/8 Gavin Llewellyn :
> Inaki,
>
> OK, I understand what you mean now.  It is not our intention to hide the
> "ws" parameter in the URIs; the section was instead referring to the
> protocol component of the m-line.  I suggest that 5.2.2 be clarified as
> follows:
>
> This document does not define a new SDP transport protocol for MSRP over
> WebSockets.  As all MSRP over WebSocket messages MUST be routed via an MS=
RP
> WebSocket Server, it is acceptable for an MSRP WebSocket Client to specif=
y
> the "TCP/MSRP" or "TCP/TLS/MSRP" protocols in the SDP m-line - that being
> the protocol used by non-WebSocket clients and between MSRP relays (RFC 4=
975
> Section 8.1).


RFC 4975 states in section 8.1:

   An offered or accepted media-line for MSRP over TCP MUST include a
   protocol field value of "TCP/MSRP", or "TCP/TLS/MSRP" for TLS.

Well, this is not flexible enough so I understand your concerns and
you probably have detected that some existing MSRP devices fail to
negotiate a MSRP session in case the SDP media-line does not contain
"TCP/MSRP" or "TCP/TLS/MSRP".

In fact the media-line is basically cosmetic for MSRP:

      MSRP devices do not use the c-line address field, or the m-line
      port and format list fields to determine where to connect.
      Rather, they use the attributes defined in this specification.
      The connection information is copied to the c-line and m-line for
      purposes of backwards compatibility with conventional SDP usages.
      While MSRP could theoretically carry any media-type, "message" is
      appropriate.

So I'm OK with the current approach (don't define "WS/MSRP" nor
"WSS/MSRP" nor "TLC/WS/MSRP" nor "TCP/TLS/WS/MSRP" nor
"TCP/WSS/MSRP"...).



> The "ws" transport parameter will appear in the endpoint URI in the SDP
> "path" attribute (RFC 4975 Section 8.2); compliant MSRP implementations
> should already allow unrecognised transports, provided that they do not h=
ave
> to establish a direct connection to the resource described by the URI.
>
> Does this make more sense?

I'm ok with current section 5.2.2 "SDP Transport Protocol" in
draft-pd-dispatch-msrp-websocket-01.


Thanks a lot.


--=20
I=C3=B1aki Baz Castillo


From saul@ag-projects.com  Wed Jan  9 01:51:00 2013
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29AA321F8581 for ; Wed,  9 Jan 2013 01:50:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.688
X-Spam-Level: 
X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiAgSl9nE3hl for ; Wed,  9 Jan 2013 01:50:58 -0800 (PST)
Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 429D121F858A for ; Wed,  9 Jan 2013 01:50:57 -0800 (PST)
Received: by mail.sipthor.net (Postfix, from userid 5001) id BF1E8B35E2; Wed,  9 Jan 2013 10:50:56 +0100 (CET)
Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id BA451B007E; Wed,  9 Jan 2013 10:50:55 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= 
In-Reply-To: 
Date: Wed, 9 Jan 2013 10:50:55 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <97D1D658-1A3A-42A1-BBB3-155D59056293@ag-projects.com>
References: <20121217161521.30393.14625.idtracker@ietfa.amsl.com>   <4A541458-A884-4BB9-8C0C-EDD8C7CCB2D0@ag-projects.com>  <1357578758.29808.3.camel@pd-notebook-linux.croc.internal>  <50EC39D9.2020706@crocodile-rcs.com> 
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= 
X-Mailer: Apple Mail (2.1085)
Cc: dispatch@ietf.org
Subject: Re: [dispatch] FW: New Version Notification for draft-pd-dispatch-msrp-websocket-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Jan 2013 09:51:01 -0000

On Jan 9, 2013, at 10:29 AM, I=F1aki Baz Castillo wrote:

> Hi Gavin, Peter,
>=20
> I've read revision 01 of the draft. Just some comments related to the
> subject below:
>=20
>=20
>=20
> 2013/1/8 Gavin Llewellyn :
>> Inaki,
>>=20
>> OK, I understand what you mean now.  It is not our intention to hide =
the
>> "ws" parameter in the URIs; the section was instead referring to the
>> protocol component of the m-line.  I suggest that 5.2.2 be clarified =
as
>> follows:
>>=20
>> This document does not define a new SDP transport protocol for MSRP =
over
>> WebSockets.  As all MSRP over WebSocket messages MUST be routed via =
an MSRP
>> WebSocket Server, it is acceptable for an MSRP WebSocket Client to =
specify
>> the "TCP/MSRP" or "TCP/TLS/MSRP" protocols in the SDP m-line - that =
being
>> the protocol used by non-WebSocket clients and between MSRP relays =
(RFC 4975
>> Section 8.1).
>=20
>=20
> RFC 4975 states in section 8.1:
>=20
>   An offered or accepted media-line for MSRP over TCP MUST include a
>   protocol field value of "TCP/MSRP", or "TCP/TLS/MSRP" for TLS.
>=20
> Well, this is not flexible enough so I understand your concerns and
> you probably have detected that some existing MSRP devices fail to
> negotiate a MSRP session in case the SDP media-line does not contain
> "TCP/MSRP" or "TCP/TLS/MSRP".
>=20
> In fact the media-line is basically cosmetic for MSRP:
>=20
>      MSRP devices do not use the c-line address field, or the m-line
>      port and format list fields to determine where to connect.
>      Rather, they use the attributes defined in this specification.
>      The connection information is copied to the c-line and m-line for
>      purposes of backwards compatibility with conventional SDP usages.
>      While MSRP could theoretically carry any media-type, "message" is
>      appropriate.
>=20
> So I'm OK with the current approach (don't define "WS/MSRP" nor
> "WSS/MSRP" nor "TLC/WS/MSRP" nor "TCP/TLS/WS/MSRP" nor
> "TCP/WSS/MSRP"...).
>=20

+1.


--
Sa=FAl Ibarra Corretg=E9
AG Projects




From Peter.Dawes@vodafone.com  Fri Jan 11 02:07:21 2013
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 726EA21F8610 for ; Fri, 11 Jan 2013 02:07:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.371
X-Spam-Level: 
X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k03wMnTIxewB for ; Fri, 11 Jan 2013 02:07:09 -0800 (PST)
Received: from mailout09.vodafone.com (mailout09.vodafone.com [195.232.224.78]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC3121F8456 for ; Fri, 11 Jan 2013 02:07:08 -0800 (PST)
Received: from mailint09 (localhost [127.0.0.1]) by mailout09 (Postfix) with ESMTP id EEA6AE13AA for ; Fri, 11 Jan 2013 11:07:05 +0100 (CET)
Received: from VOEXC02W.internal.vodafone.com (voexc02w.dc-ratingen.de [145.230.101.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint09 (Postfix) with ESMTPS id D92E7E1024; Fri, 11 Jan 2013 11:07:05 +0100 (CET)
Received: from VOEXM31W.internal.vodafone.com ([169.254.7.92]) by VOEXC02W.internal.vodafone.com ([145.230.101.22]) with mapi id 14.02.0318.004; Fri, 11 Jan 2013 11:07:05 +0100
From: "Dawes, Peter, Vodafone Group" 
To: "akaithal@cisco.com" , "sandks@cisco.com" , Parthasarathi R , "Dale R. Worley (worley@ariadne.com)" , "pkyzivat@alum.mit.edu" 
Thread-Topic: RE: [dispatch] draft-dawes-dispatch-logme-reqs-00.txt
Thread-Index: Ac3v4h0Aj/rGciu0Q/6DwRNNslIM7Q==
Date: Fri, 11 Jan 2013 10:07:05 +0000
Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D996CB784C3@VOEXM31W.internal.vodafone.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [145.230.12.26]
Content-Type: multipart/alternative; boundary="_000_4A4F136CBD0E0D44AE1EDE36C4CD9D996CB784C3VOEXM31Winterna_"
MIME-Version: 1.0
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] draft-dawes-dispatch-logme-reqs-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jan 2013 10:07:21 -0000

--_000_4A4F136CBD0E0D44AE1EDE36C4CD9D996CB784C3VOEXM31Winterna_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Thanks to everyone who reviewed and commented on version -00 of the log me =
requirements draft, I have uploaded revision -01 (http://www.ietf.org/id/dr=
aft-dawes-dispatch-logme-reqs-01.txt) which clarifies requirements on maint=
aining state and the meanings of identifiers. Further comments on the revis=
ed requirements, applicable scenarios, or any other aspect are welcome.

Peter

--_000_4A4F136CBD0E0D44AE1EDE36C4CD9D996CB784C3VOEXM31Winterna_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Thanks to everyone who reviewed and commented on ver=
sion -00 of the log me requirements draft, I have uploaded revision -01 (ht=
tp://www.ietf.org/id/draft-dawes-dispatch-logme-reqs-01.txt) which clarifie=
s requirements on maintaining state
 and the meanings of identifiers. Further comments on the revised requireme=
nts, applicable scenarios, or any other aspect are welcome.



 


Peter






--_000_4A4F136CBD0E0D44AE1EDE36C4CD9D996CB784C3VOEXM31Winterna_--

From caryfitz@employees.org  Wed Jan 16 10:36:26 2013
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C2521F8AD8 for ; Wed, 16 Jan 2013 10:36:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2mY+NDuNNvr for ; Wed, 16 Jan 2013 10:36:26 -0800 (PST)
Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA7321F8941 for ; Wed, 16 Jan 2013 10:36:26 -0800 (PST)
Received: from [192.168.1.6] (c-24-7-29-157.hsd1.ca.comcast.net [24.7.29.157]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: caryfitz) by banjo.employees.org (Postfix) with ESMTPSA id 192A85EE8 for ; Wed, 16 Jan 2013 10:36:25 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1283)
From: Cary FitzGerald 
In-Reply-To: <20130115221242.24696.18448.idtracker@ietfa.amsl.com>
Date: Wed, 16 Jan 2013 10:36:24 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <2C2D00AB-C0DD-4714-B570-0F63778B52ED@employees.org>
References: <20130115221242.24696.18448.idtracker@ietfa.amsl.com>
To: dispatch@ietf.org
X-Mailer: Apple Mail (2.1283)
Subject: Re: [dispatch] I-D Action: draft-hanes-dispatch-fax-capability-07.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Jan 2013 18:36:26 -0000

I don't understand use case for this draft.  Unless I'm missing =
something, it helps to solve a very small corner case.

For the IP-UA to UA case, it seems very unlikely to be useful.  Of =
course someone _could_ construct a UA that sends T.38, but why bother =
when SMTP or mumble is so much less trouble.  So I don't see an actual =
problem here.

For the PSTN-UA to UA case, as the draft points out, there is no way to =
predict whether fax is going to be part of the call.  It's certainly =
true that increasing the probability of successfully handling a media =
stream, but I don't know how to figure out a priori how to set the =
balance between capabilities, convenience and whatever else the user's =
preferences are trying to tell us.

If the call is routed to BOB (Big Old Business), then I'd kind of expect =
that by administrative policy, the BOB administrators would set a =
routing policy if some of the incoming PSTN numbers were fax banks to =
route to fax capable UAs.  You _could_ solve the problem with =
preferences, but that seems like a lot of unnecessary nuance.  Routing =
policy is a hammer, for sure, but it's simple and works for this case.

If the call is routed to Bob Regular Guy, and assuming Alice can predict =
the preferences for that particular call (outside of any other =
preferences), then the draft solves an actual problem.

I think that the draft would be improved if the authors could add some =
words about how Alice would calculate a preference.

Cary.

On Jan 15, 2013, at 2:12 PM, internet-drafts@ietf.org wrote:

>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>=20
>=20
> 	Title           : Indicating Fax over IP Capability in the =
Session Initiation Protocol (SIP)
> 	Author(s)       : David Hanes
>                          Gonzalo Salgueiro
>                          Kevin P. Fleming
> 	Filename        : draft-hanes-dispatch-fax-capability-07.txt
> 	Pages           : 9
> 	Date            : 2013-01-15
>=20
> Abstract:
>   This document defines and registers with IANA the new 'fax' media
>   feature tag for use with SIP.  Currently, fax calls are
>   indistinguishable from voice at call initiation.  Consequently, fax
>   calls can be routed to SIP user agents that are not fax capable.  A
>   'fax' media feature tag implemented in conjunction with caller
>   preferences allows for more accurate fax call routing.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-hanes-dispatch-fax-capability
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-hanes-dispatch-fax-capability-07
>=20
> A diff from the previous version is available at:
> =
http://www.ietf.org/rfcdiff?url2=3Ddraft-hanes-dispatch-fax-capability-07
>=20
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


From gonzalo.camarillo@ericsson.com  Fri Jan 18 03:37:55 2013
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278C221F8450 for ; Fri, 18 Jan 2013 03:37:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level: 
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdClWD7j8225 for ; Fri, 18 Jan 2013 03:37:54 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 616F721F846E for ; Fri, 18 Jan 2013 03:37:53 -0800 (PST)
X-AuditID: c1b4fb2d-b7f316d0000028db-28-50f9340362c1
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 9D.4E.10459.30439F05; Fri, 18 Jan 2013 12:37:39 +0100 (CET)
Received: from [131.160.36.97] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Fri, 18 Jan 2013 12:37:39 +0100
Message-ID: <50F93402.5090204@ericsson.com>
Date: Fri, 18 Jan 2013 13:37:38 +0200
From: Gonzalo Camarillo 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: "dispatch@ietf.org" 
References: <50ABBAD6.9050103@gmail.com> <50B49D64.7030600@ericsson.com> <50EAAD1C.9010201@ericsson.com>
In-Reply-To: <50EAAD1C.9010201@ericsson.com>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDJMWRmVeSWpSXmKPExsUyM+Jvja6Ayc8Ag/PHpS2WTlrA6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujC0LzrAVLIqs6P6yn7mBcY9HFyMnh4SAicSn5kZmCFtM4sK9 9WxdjFwcQgInGSXmfe1ggnBWM0q0z5nCBFLFK6At0X/xClgHi4CqxLzGm6wgNpuAhcSWW/dZ QGxRgSiJ91ebmCHqBSVOznwCFhcB6j26qosZZKiwQDOjxJ1Db9hAEkICGRIXuiayg9icAjoS 7x7eYIM4SVJi0bROsGZmAT2JKVdbGCFseYntb+cwQ/RqSyx/1sIygVFwFpJ9s5C0zELSsoCR eRUje25iZk56ueEmRmAIHtzyW3cH46lzIocYpTlYlMR5w1wvBAgJpCeWpGanphakFsUXleak Fh9iZOLglGpgNOvRXH32SladeuymtTN+h305JHv+6a1dyxzmvDz0/tiFjQt7Duzv7Hu5PUlH MtfpBgfbwqTe60HXJ3T0PkkX2+b0TXDjkY+7n99/YblK9PmKb01cUp9X8Ow/x7/02OHjEhFF oTuemS1VdFGtMf4aGBz9jaXFd+ZcCYF1LEedg3mWvQtTfXZ5UaYSS3FGoqEWc1FxIgD4rVGS DwIAAA==
Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Jan 2013 11:37:55 -0000

Folks,

at this point, the authors are going to revise the draft to address
Dale's comments and send it to the URN list for feedback.

If you have comments on this draft, please send them to this (DISPATCH)
list shortly.

Thanks,

Gonzalo

On 07/01/2013 1:10 PM, Gonzalo Camarillo wrote:
> Folks,
> 
> I would like to get more comments on these two drafts before moving
> things forward. Now that the Christmas break is over, please have a look
> at them and send your comments to this list.
> 
> Thanks,
> 
> Gonzalo
> 
> On 27/11/2012 1:00 PM, Gonzalo Camarillo wrote:
>> All,
>>
>> as you can see in the email below, Andrew believes that the current
>> versions of these drafts address all concerns that were previously
>> discussed on this list. Those concerns mostly related to
>> interoperability (what happens with UAs that do not have an IMEI) and
>> privacy (whether a UA can choose not to send its IMEI in order to
>> preserve its user's privacy).
>>
>> With respect to the URN definition (in the montemurro draft), it needs
>> to also be discussed on the urn-nid@ietf.org list, per RFC 3406.
>>
>> The SIP usage (specified in the allen draft), needs to be reviewed on
>> this list. So, please, have a look at the current versions of these
>> drafts and send your comments to the list.
>>
>> I have already talked with the editors of these drafts so that they are
>> responsive. Getting people to reload the state related to these drafts
>> into the heads is a lot of work for everyone. So, I would like to
>> discuss these drafts one last time and make a *final* decision (whatever
>> it is) shortly.
>>
>> Cheers,
>>
>> Gonzalo
>>
>>
>> On 20/11/2012 7:16 PM, Tom Taylor wrote:
>>> Andrew's original note appeared to me at least as a brief message:
>>> "WARNING: contains banned part", with attachments. As a public service,
>>> I have extracted and reproduced the text of his message. Hope this isn't
>>> a duplicate from others' point of view.
>>>
>>> Tom Taylor
>>>
>>> Andrew's message:
>>> ==========================
>>> New versions of draft-montemurro-gsma-imei-urn and
>>> draft-allen-dispatch-imei-urn-as-instanceid were submitted at the
>>> beginning of October.
>>>
>>> http://www.ietf.org/internet-drafts/draft-allen-dispatch-imei-urn-as-instanceid-06.txt
>>>
>>>
>>> http://www.ietf.org/internet-drafts/draft-montemurro-gsma-imei-urn-11.txt
>>>
>>> There are not many major changes since the previous versions which were
>>> submitted in March and July which themselves were submitted after the
>>> conference call held between 3GPP and IETF interested parties in early
>>> January on the topic. Basically editorial updates and some strengthening
>>> of the normative language.
>>>
>>> The main change in draft-montemurro-gsma-imei-urn since the previous
>>> version is to address the ABNF comment from Dale and it was decided we
>>> do not need parameters to have multiple values so Dale's proposed
>>> resolution has been adopted. The January version of
>>> draft-montemurro-gsma-imei-urn (09 version) added the following to the
>>> Security Considerations section to address the privacy concerns:
>>>
>>>    Further, because IMEIs can be loosely correlated to a user, they
>>>    need to be treated as any other personally identifiable
>>>    information. In particular, the IMEI SHOULD NOT be included in
>>>    messages intended to convey any level of anonymity.
>>>
>>> In the latest (11 version) this has been strengthened from a SHOULD NOT
>>> to a MUST NOT.
>>>
>>> The draft-allen-dispatch-imei-urn-as-instanceid 05 version that was
>>> submitted in March incorporated a number of significant changes including:
>>>
>>> 1.    Additional text was added to the abstract stating:
>>>
>>> [The purpose of the draft] is to fulfil the requirements in RFC 5626 [1]
>>> that state "If a URN scheme other than UUID is used, the UA MUST only
>>> use URNs for which an RFC (from the IETF stream) defines how the
>>> specific URN needs to be constructed and used in the "+sip.instance"
>>> Contact header field parameter for outbound behavior."
>>>
>>> 2.    A new section was added describing the three 3GPP use cases
>>>
>>> 3.    A new section was added for 3GPP Registrar Procedures with the
>>> following text:
>>>
>>> In 3GPP IMS when the Registrar receives in the Contact header field a
>>> "sip.instance" media feature tag containing the GSMA IMEI URN according
>>> to the syntax defined in draft-montemurro-gsma-imei-urn-09[3] the
>>> registrar follows the procedures defined in RFC 5626 [1] and RFC 5627
>>> [2] if those extensions are supported and indicated as supported by the
>>> UA.  If the Registrar allocates a public GRUU according to the
>>> procedures defined in RFC 5627 [2] the the instance-id MUST be
>>> obfuscated when creating the "gr" parameter in order not to reveal the
>>> IMEI to other UAs when the public GRUU is included in non register
>>> requests. 3GPP TS 24.229 [6] subcluase 5.4.7A.2 defines the mechanism
>>> for obfuscating the IMEI when creating the "gr" parameter.
>>>
>>> 4.    The security section was beefed up as follows:
>>>
>>> Because IMEIs like other formats of instance IDs can be loosely
>>> correlated to a user, they need to be treated as any other personally
>>> identifiable information.  In particular, the "sip.instance" media
>>> feature tag containing the GSMA IMEI URN MUST NOT be included in
>>> requests or responses intended to convey any level of anonymity.  RFC
>>> 5626 [1] states "One case where a UA could prefer to omit the
>>> "sip.instance" media feature tag is when it is making an anonymous
>>> request or some other privacy concern requires that the UA not reveal
>>> its identity".  The same concerns apply when using the GSMA IMEI URN as
>>> an instance ID.  Publication of the GSMA IMEI URN to networks that the
>>> UA is not attached to or the UA does not have a service relationship
>>> with is a security breach and the "sip.instance" media feature tag MUST
>>> NOT be forwarded by the service provider's network elements when
>>> forwarding requests or responses towards the destination UA.
>>>
>>> In order to protect from tampering the REGISTER requests containing the
>>> GSMA IMEI URN MUST be sent using a security mechanism such as TLS [12]
>>> (or another security mechanism that provides equivalent levels of
>>> protection).
>>>
>>> There do not seem to be any comments made against the
>>> draft-allen-dispatch-imei-urn-as-instanceid-05 version that was
>>> submitted in March. Not sure if this was because everyone was Ok with it
>>> or because it was overlooked.
>>>
>>> At the conference call held between 3GPP and IETF interested
>>> participants in January at which privacy concerns about the use of the
>>> IMEI as an instance ID by 3GPP were raised. It was proposed during the
>>> conference call that the authors submit a new revision of the draft
>>> clarifying the use of the mechanism and explaining how the 3GPP
>>> architecture addresses the privacy issues that were discussed.
>>>
>>> There was a further discussion at a following 3GPP meeting on these
>>> privacy concerns. During the 3GPP discussion it was pointed out that RFC
>>> 5626 already previously considered and addressed privacy concerns  with
>>> instance ID in section 4.1 which only states the "UA could prefer to
>>> omit the "sip.instance" media feature tag":
>>>
>>> 4.1.  Instance ID Creation
>>>
>>>    To convey its instance-id in both requests and responses, the UA
>>>    includes a "sip.instance" media feature tag as a UA characteristic
>>>    [RFC3840].  This media feature tag is encoded in the Contact header
>>>    field as the "+sip.instance" Contact header field parameter.  One
>>>    case where a UA could prefer to omit the "sip.instance" media feature
>>>    tag is when it is making an anonymous request or some other privacy
>>>    concern requires that the UA not reveal its identity.
>>>
>>> draft-montemurro-gsma-imei-urn and
>>> draft-allen-dispatch-imei-urn-as-instanceid and the 3GPP specified usage
>>> of the IMEI already go considerably further than RFC 5626 does in this
>>> regard. Regardless of whether a UUID URN or the IMEI URN is used as an
>>> instance ID the privacy issues are the same since an instance ID based
>>> on a UUID is static once generated and therefore like the IMEI
>>> potentially reveals the identity of the caller if it can be correlated
>>> with the identity of that caller from a previous call.
>>>
>>> The view in 3GPP was that the IMEI should not be of any greater concern
>>> when used as an instance ID than using a UUID. Asking 3GPP to go
>>> considerably further in addressing privacy concerns with use of IMEI as
>>> an instance ID than RFC 5626 already does was considered by many in 3GPP
>>> to be unwarranted. Describing fully all the potential uses with 3GPP IMS
>>> of instance ID and documenting all the security mechanisms in all
>>> scenarios is a really non-trivial task considering that many
>>> organizations outside 3GPP specify access networks for IMS and
>>> applications using IMS (OMA, GSMA, Cablelabs, 3GPP2, TISPAN, WIMAX
>>> Forum...) and outside the capability of the authors of the draft alone.
>>> In basic summary most if not all accesses to IMS provide for at least
>>> basic levels of transport security such as use of IPsec or TLS tunnels
>>> and/or access layer security (although there is no guarantee these will
>>> be always enabled by the every carrier). This goes beyond what is
>>> required by RFC 5626 which only recommends use of TLS even though the
>>> general internet is probably more open to attack than a managed carrier
>>> network.
>>>
>>> Those that think privacy issues are insufficiently addressed need to
>>> explain why the IMEI is of significantly greater concern in terms of
>>> revealing privacy than the UUID when used as an instance ID.
>>>
>>> In our view the security concerns raised have now been sufficiently
>>> addressed in the drafts and to a much higher bar than that of UUID in
>>> RFC 5626.
>>>
>>> The 3GPP use cases have now been described in
>>> draft-allen-dispatch-imei-urn-as-instanceid. It is my view that
>>> describing these uses as an instance ID also in
>>> draft-montemurro-gsma-imei-urn is both redundant and inappropriate since
>>> this draft does not define use of the IMEI as an instance ID.
>>>
>>> Attached are diffs between the 04 and 06 versions of
>>> draft-allen-dispatch-imei-urn-as-instanceid and between the 09 and 11
>>> versions of draft-montemurro-gsma-imei-urn.
>>>
>>> So I would like to ask for review of these two latest drafts and to
>>> provide any comments. 3GPP urgently needs to progress these drafts which
>>> are needed to complete 3GPP Release 8.
>>>
>>> Andrew
>>> _______________________________________________
>>> dispatch mailing list
>>> dispatch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>
>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
>>
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> 
> 


From fluffy@cisco.com  Sat Jan 19 08:49:07 2013
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 045EB21F8629 for ; Sat, 19 Jan 2013 08:49:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.038
X-Spam-Level: 
X-Spam-Status: No, score=-110.038 tagged_above=-999 required=5 tests=[AWL=0.561, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yozKKMw+OeVA for ; Sat, 19 Jan 2013 08:49:05 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id D6C0921F8599 for ; Sat, 19 Jan 2013 08:49:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=664; q=dns/txt; s=iport; t=1358614146; x=1359823746; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Y4RyKYOa6zWPSnhNVleXKIwcw7s0kTjCdJwnMihmRO8=; b=bBzXvLw7GmDrQEC3P9iIduhwcxNkJPH1ysLh8T/0GW+ze3/hNig2G970 z9O2kmt89AD0ALGDSEfawNOOYvrDUQiLqX1twjB+sTBtLlUHdRwn7VeIu 08pdA83IMhpL4fiPSyBwMJsTNrz7pjf9Fn2sg9evuDwxIWngTSonREPnB 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnkFANnN+lCtJXHB/2dsb2JhbABEhX64QRZzgh4BAQEDATo/BQsCAQgiFAULIRElAgQBDQUIh38DCQazBQ2IYowJbYNiYQOUNo0NhRKCdYIk
X-IronPort-AV: E=Sophos;i="4.84,498,1355097600"; d="scan'208";a="161915752"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 19 Jan 2013 16:49:05 +0000
Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r0JGn5D4004490 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 19 Jan 2013 16:49:05 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.197]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Sat, 19 Jan 2013 10:49:04 -0600
From: "Cullen Jennings (fluffy)" 
To: Tom Taylor , Gonzalo Camarillo 
Thread-Topic: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted
Thread-Index: AQHN9mTjqHu4K409JkqXLlcWXXqFgg==
Date: Sat, 19 Jan 2013 16:49:04 +0000
Message-ID: 
References: <50ABBAD6.9050103@gmail.com>
In-Reply-To: <50ABBAD6.9050103@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.20.249.164]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 19 Jan 2013 16:49:07 -0000

On Nov 20, 2012, at 10:16 AM, Tom Taylor  wrote:

> Those that think privacy issues are insufficiently addressed need to expl=
ain why the IMEI is of significantly greater concern in terms of revealing =
privacy than the UUID when used as an instance ID.

That has been explained in detail multiple times. For one thing, the user c=
an't change the IMEI. For a second thing, it can be directly mapped to a sp=
ecific user in many cases.=20

>=20
> In our view the security concerns raised have now been sufficiently addre=
ssed in the drafts and to a much higher bar than that of UUID in RFC 5626.

I strongly disagree.


From fluffy@cisco.com  Sat Jan 19 08:50:12 2013
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE6B21F85AC for ; Sat, 19 Jan 2013 08:50:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.078
X-Spam-Level: 
X-Spam-Status: No, score=-110.078 tagged_above=-999 required=5 tests=[AWL=0.521, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWoezB-4gQez for ; Sat, 19 Jan 2013 08:50:11 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id CFA5921F8599 for ; Sat, 19 Jan 2013 08:50:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9317; q=dns/txt; s=iport; t=1358614210; x=1359823810; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=REaa7l2IOsH3TD1c22ZjVWBISlw/RwbXEsuKYtZSsoA=; b=QaPPfOIgaqOc06VcxqXKwZ3ghbdmsDEXW2mAlzgjyjjzueZCwO+ImKky txq9zmilT9jQL8P9kLxM7qj87RvJZ2jKHt7wXTw5ju+sZOq8FzBmsv0Qz /Y58RXdIJwSjvg3uW/MtPL+CzsYdeu7KmF7fOv6jUOFrbtlN5ul4vcCbd Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAHDO+lCtJXG9/2dsb2JhbAA7BAW+PxZzgh4BAQEDAQEBATctAQYEBwULAgEIEhAUBQshBgsXDgIEDgMCCAGHfgMJBgyydw2IYowJbRIXgzlhA5JZgV2NDYUSgnU/gWU
X-IronPort-AV: E=Sophos;i="4.84,498,1355097600"; d="scan'208";a="164910540"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 19 Jan 2013 16:50:10 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0JGo9QU032635 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 19 Jan 2013 16:50:09 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.197]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Sat, 19 Jan 2013 10:50:09 -0600
From: "Cullen Jennings (fluffy)" 
To: Tom Taylor 
Thread-Topic: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted
Thread-Index: AQHN9mUKaB+6YdE5jkOld6WDzG8Jaw==
Date: Sat, 19 Jan 2013 16:50:08 +0000
Message-ID: 
References: <50ABBAD6.9050103@gmail.com>
In-Reply-To: <50ABBAD6.9050103@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.20.249.164]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8525E36074E84B47AFE4A33B4C3C3A0E@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 19 Jan 2013 16:50:12 -0000

I would like to point out that several of my comments, including the one ab=
out IPR, had never been addressed.=20

On Nov 20, 2012, at 10:16 AM, Tom Taylor  wrote:

> Andrew's original note appeared to me at least as a brief message: "WARNI=
NG: contains banned part", with attachments. As a public service, I have ex=
tracted and reproduced the text of his message. Hope this isn't a duplicate=
 from others' point of view.
>=20
> Tom Taylor
>=20
> Andrew's message:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
> New versions of draft-montemurro-gsma-imei-urn and draft-allen-dispatch-i=
mei-urn-as-instanceid were submitted at the beginning of October.
>=20
> http://www.ietf.org/internet-drafts/draft-allen-dispatch-imei-urn-as-inst=
anceid-06.txt
>=20
> http://www.ietf.org/internet-drafts/draft-montemurro-gsma-imei-urn-11.txt
>=20
> There are not many major changes since the previous versions which were s=
ubmitted in March and July which themselves were submitted after the confer=
ence call held between 3GPP and IETF interested parties in early January on=
 the topic. Basically editorial updates and some strengthening of the norma=
tive language.
>=20
> The main change in draft-montemurro-gsma-imei-urn since the previous vers=
ion is to address the ABNF comment from Dale and it was decided we do not n=
eed parameters to have multiple values so Dale's proposed resolution has be=
en adopted. The January version of draft-montemurro-gsma-imei-urn (09 versi=
on) added the following to the Security Considerations section to address t=
he privacy concerns:
>=20
>   Further, because IMEIs can be loosely correlated to a user, they
>   need to be treated as any other personally identifiable
>   information. In particular, the IMEI SHOULD NOT be included in
>   messages intended to convey any level of anonymity.
>=20
> In the latest (11 version) this has been strengthened from a SHOULD NOT t=
o a MUST NOT.
>=20
> The draft-allen-dispatch-imei-urn-as-instanceid 05 version that was submi=
tted in March incorporated a number of significant changes including:
>=20
> 1.    Additional text was added to the abstract stating:
>=20
> [The purpose of the draft] is to fulfil the requirements in RFC 5626 [1] =
that state "If a URN scheme other than UUID is used, the UA MUST only use U=
RNs for which an RFC (from the IETF stream) defines how the specific URN ne=
eds to be constructed and used in the "+sip.instance" Contact header field =
parameter for outbound behavior."
>=20
> 2.    A new section was added describing the three 3GPP use cases
>=20
> 3.    A new section was added for 3GPP Registrar Procedures with the foll=
owing text:
>=20
> In 3GPP IMS when the Registrar receives in the Contact header field a "si=
p.instance" media feature tag containing the GSMA IMEI URN according to the=
 syntax defined in draft-montemurro-gsma-imei-urn-09[3] the registrar follo=
ws the procedures defined in RFC 5626 [1] and RFC 5627 [2] if those extensi=
ons are supported and indicated as supported by the UA.  If the Registrar a=
llocates a public GRUU according to the procedures defined in RFC 5627 [2] =
the the instance-id MUST be obfuscated when creating the "gr" parameter in =
order not to reveal the IMEI to other UAs when the public GRUU is included =
in non register requests. 3GPP TS 24.229 [6] subcluase 5.4.7A.2 defines the=
 mechanism for obfuscating the IMEI when creating the "gr" parameter.
>=20
> 4.    The security section was beefed up as follows:
>=20
> Because IMEIs like other formats of instance IDs can be loosely correlate=
d to a user, they need to be treated as any other personally identifiable i=
nformation.  In particular, the "sip.instance" media feature tag containing=
 the GSMA IMEI URN MUST NOT be included in requests or responses intended t=
o convey any level of anonymity.  RFC 5626 [1] states "One case where a UA =
could prefer to omit the "sip.instance" media feature tag is when it is mak=
ing an anonymous request or some other privacy concern requires that the UA=
 not reveal its identity".  The same concerns apply when using the GSMA IME=
I URN as an instance ID.  Publication of the GSMA IMEI URN to networks that=
 the UA is not attached to or the UA does not have a service relationship w=
ith is a security breach and the "sip.instance" media feature tag MUST NOT =
be forwarded by the service provider's network elements when forwarding req=
uests or responses towards the destination UA.
>=20
> In order to protect from tampering the REGISTER requests containing the G=
SMA IMEI URN MUST be sent using a security mechanism such as TLS [12] (or a=
nother security mechanism that provides equivalent levels of protection).
>=20
> There do not seem to be any comments made against the draft-allen-dispatc=
h-imei-urn-as-instanceid-05 version that was submitted in March. Not sure i=
f this was because everyone was Ok with it or because it was overlooked.
>=20
> At the conference call held between 3GPP and IETF interested participants=
 in January at which privacy concerns about the use of the IMEI as an insta=
nce ID by 3GPP were raised. It was proposed during the conference call that=
 the authors submit a new revision of the draft clarifying the use of the m=
echanism and explaining how the 3GPP architecture addresses the privacy iss=
ues that were discussed.
>=20
> There was a further discussion at a following 3GPP meeting on these priva=
cy concerns. During the 3GPP discussion it was pointed out that RFC 5626 al=
ready previously considered and addressed privacy concerns  with instance I=
D in section 4.1 which only states the "UA could prefer to omit the "sip.in=
stance" media feature tag":
>=20
> 4.1.  Instance ID Creation
>=20
>   To convey its instance-id in both requests and responses, the UA
>   includes a "sip.instance" media feature tag as a UA characteristic
>   [RFC3840].  This media feature tag is encoded in the Contact header
>   field as the "+sip.instance" Contact header field parameter.  One
>   case where a UA could prefer to omit the "sip.instance" media feature
>   tag is when it is making an anonymous request or some other privacy
>   concern requires that the UA not reveal its identity.
>=20
> draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-insta=
nceid and the 3GPP specified usage of the IMEI already go considerably furt=
her than RFC 5626 does in this regard. Regardless of whether a UUID URN or =
the IMEI URN is used as an instance ID the privacy issues are the same sinc=
e an instance ID based on a UUID is static once generated and therefore lik=
e the IMEI potentially reveals the identity of the caller if it can be corr=
elated with the identity of that caller from a previous call.
>=20
> The view in 3GPP was that the IMEI should not be of any greater concern w=
hen used as an instance ID than using a UUID. Asking 3GPP to go considerabl=
y further in addressing privacy concerns with use of IMEI as an instance ID=
 than RFC 5626 already does was considered by many in 3GPP to be unwarrante=
d. Describing fully all the potential uses with 3GPP IMS of instance ID and=
 documenting all the security mechanisms in all scenarios is a really non-t=
rivial task considering that many organizations outside 3GPP specify access=
 networks for IMS and applications using IMS (OMA, GSMA, Cablelabs, 3GPP2, =
TISPAN, WIMAX Forum...) and outside the capability of the authors of the dr=
aft alone. In basic summary most if not all accesses to IMS provide for at =
least basic levels of transport security such as use of IPsec or TLS tunnel=
s and/or access layer security (although there is no guarantee these will b=
e always enabled by the every carrier). This goes beyond what is required b=
y RFC 5626 which only recommends use of TLS even though the general interne=
t is probably more open to attack than a managed carrier network.
>=20
> Those that think privacy issues are insufficiently addressed need to expl=
ain why the IMEI is of significantly greater concern in terms of revealing =
privacy than the UUID when used as an instance ID.
>=20
> In our view the security concerns raised have now been sufficiently addre=
ssed in the drafts and to a much higher bar than that of UUID in RFC 5626.
>=20
> The 3GPP use cases have now been described in draft-allen-dispatch-imei-u=
rn-as-instanceid. It is my view that describing these uses as an instance I=
D also in draft-montemurro-gsma-imei-urn is both redundant and inappropriat=
e since this draft does not define use of the IMEI as an instance ID.
>=20
> Attached are diffs between the 04 and 06 versions of draft-allen-dispatch=
-imei-urn-as-instanceid and between the 09 and 11 versions of draft-montemu=
rro-gsma-imei-urn.
>=20
> So I would like to ask for review of these two latest drafts and to provi=
de any comments. 3GPP urgently needs to progress these drafts which are nee=
ded to complete 3GPP Release 8.
>=20
> Andrew
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch


From prvs=1731faac38=aallen@rim.com  Sat Jan 19 09:31:54 2013
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C1C21F857D for ; Sat, 19 Jan 2013 09:31:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.332
X-Spam-Level: 
X-Spam-Status: No, score=-5.332 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7vkHb8hDrLW for ; Sat, 19 Jan 2013 09:31:53 -0800 (PST)
Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 410D321F8702 for ; Sat, 19 Jan 2013 09:31:52 -0800 (PST)
X-AuditID: 0a412830-b7f646d0000038d1-93-50fad87c5201
Received: from XCT101ADS.rim.net (xct101ads.rim.net [10.67.111.42]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 7A.36.14545.D78DAF05; Sat, 19 Jan 2013 11:31:41 -0600 (CST)
Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT101ADS.rim.net ([fe80::2c7e:1215:d554:35b5%20]) with mapi id 14.02.0318.001; Sat, 19 Jan 2013 11:31:40 -0600
From: Andrew Allen 
To: "Cullen Jennings (fluffy)" , Tom Taylor , Gonzalo Camarillo 
Thread-Topic: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted
Thread-Index: AQHNx0LDMMCAzJYzhkOmkNSi4UyFuJhRn9YA//+gKOA=
Date: Sat, 19 Jan 2013 17:31:40 +0000
Message-ID: 
References: <50ABBAD6.9050103@gmail.com> 
In-Reply-To: 
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.67.110.253]
Content-Type: text/plain; charset="us-ascii"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCKsWRmVeSWpSXmKPExsXC5ZyvpVt741eAwewWEYulkxawWnRMZrPY tHwlk8WF9b9YHFg8pvzeyOrx6+tVNo+ds+6yeyxZ8pMpgCWqgdEmKbGkLDgzPU/fziYxLy+/ JLEkVSEltTjZVsknNT0xRyGgKLMsMblSwSWzODknMTM3tUhJITPFVslESaEgJzE5NTc1r8RW KbGgIDUvRcmOSwED2ACVZeYppOYl56dk5qXbKnkG++taWJha6hoq2ekmdPJkrL3yl7XguEzF nhc/mBsYr4p1MXJySAiYSOw7+oodwhaTuHBvPRuILSTQxiSxvpO1i5ELyN7MKLH6SxcrSIJN QFli+e8ZjCC2iMBERolVZ41BbGYBbYn/19cxgjQICzQzSmw4vIEVoqiFUeLeHw8I20ri9ZRn QEUcHCwCqhIzPteBhHkFPCTWXrnECLE4W2L/1jMsIDangK/E+quHwY5jFJCV2H32OhPELnGJ W0/mM0EcLSCxZM95ZghbVOLl43+sELaixN+931kh6nUkFuz+xAZz57KFr5kh9gpKnJz5hGUC o9gsJGNnIWmZhaRlFpKWBYwsqxgFczOKDcwMk/OS9Yoyc/XyUks2MYKSiaOGwQ7G9+8tDjEK cDAq8fAmnPkVIMSaWFZcmXuIUYKDWUmEd3IDUIg3JbGyKrUoP76oNCe1+BCjKzBQJjJLcSfn AxNdXkm8sYEBbo6SOK9k7+UAIYF0YFLKTk0tSC2CmcPEwQmyh0tKpBiYWlKLEktLMuJBCTC+ GJgCpRoYA9bNvXm7yKo9zcd4JU+d/gPtwiPsz/eZPfXp++/6KWa7aYj2hk1PDKNfyU2ZeTmj zXXC6nU7zP0un7my+Yvb0YjDl6P2+Ec6h7fvmVPczNL4s/eX1dwLXCHPwl49EglM9eWdbrYg SMN3Wtw29RxJb/nLXpuyug51nLo+fwZXkkpupO/le3nSSizFGYmGWsxFxYkAss0IymcDAAA=
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 19 Jan 2013 17:31:54 -0000

Cullen

To clarify these comments I think are your comments not Tom Taylor's (Tom si=
mply forwarded my original post as it was rejected due to attached diff file=
s).

Where does it state in RFC 5626 or anywhere else that an instance ID can be=
 changed by the user?

In fact RFC 5626 states the opposite:

	3.1.  Summary of Mechanism
  		 Each UA has a unique instance-id that stays the same for this UA even i=
f the UA reboots or is power cycled.  

And

	4.1.  Instance ID Creation

   		Each UA MUST have an Instance Identifier Uniform Resource Name (URN) [R=
FC2141] that uniquely identifies the device.  Usage of a URN
 	  provides a persistent and unique name for the UA instance.  It also prov=
ides an easy way to guarantee uniqueness within the AOR.  This
  	  URN MUST be persistent across power cycles of the device.  

So the instance ID is persistent (RFC 5626 wording) and does not change and=
 is not changeable by the user. Whether the instance ID is a UUID or IMEI th=
is does not change.

If an Instance ID containing a UUID is provided in a SIP request or response=
 to another party then it can be stored as the instance ID of a device belon=
ging to that user if their identity is known. Then if the same instance ID i=
s provided again in a SIP request when the originating user requests anonymi=
ty then that user can potentially be identified by correlation with the stor=
ed instance ID.  

If I call you and your device rings and in the response I receive the instan=
ce ID I can potentially learn the Instance ID of the specific device even if=
 it is a UUID.

This is the same regardless of whether the instance ID is a UUID or IMEI. In=
 3GPP usage the instance ID is never supplied to the far end party except fo=
r the case of emergency calls where the far end is a PSAP.

RFC 5626 does not seem overly concerned about this privacy issue as it has a=
 very weak statement - prefer to omit is a far lower strength than MUST NOT=
 or SHOULD NOT.

The only thing it states about it is:

	4.1.  Instance ID Creation

		One case where a UA could prefer to omit the "sip.instance" media feature=
  tag is when it is making an anonymous request or some other privacy concer=
n 
	requires that the UA not reveal its identity.

3GPP procedures and draft-allen-dispatch-imei-urn-as-instanceid protect reve=
lation of the Instance ID far more than is required by RFC 5626.

Andrew

-----Original Messsage-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf=
 Of Cullen Jennings (fluffy)
Sent: Saturday, January 19, 2013 11:49 AM
To: Tom Taylor; Gonzalo Camarillo
Cc: dispatch@ietf.org
Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and,=
 draft-allen-dispatch-imei-urn-as-instanceid submitted


On Nov 20, 2012, at 10:16 AM, Tom Taylor  wrote:

> Those that think privacy issues are insufficiently addressed need to expla=
in why the IMEI is of significantly greater concern in terms of revealing pr=
ivacy than the UUID when used as an instance ID.

That has been explained in detail multiple times. For one thing, the user ca=
n't change the IMEI. For a second thing, it can be directly mapped to a spec=
ific user in many cases. 

> 
> In our view the security concerns raised have now been sufficiently addres=
sed in the drafts and to a much higher bar than that of UUID in RFC 5626.

I strongly disagree.

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

From prvs=8731041280=aallen@rim.com  Sat Jan 19 09:36:12 2013
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA69921F85AC for ; Sat, 19 Jan 2013 09:36:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.317
X-Spam-Level: 
X-Spam-Status: No, score=-5.317 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8Tp4vlSgRS3 for ; Sat, 19 Jan 2013 09:36:10 -0800 (PST)
Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 98D9921F857A for ; Sat, 19 Jan 2013 09:36:10 -0800 (PST)
X-AuditID: 0a41282f-b7f8c6d000004b29-36-50fad98896ad
Received: from XCT105ADS.rim.net (xct105ads.rim.net [10.67.111.46]) by mhs060cnc.rim.net (SBG) with SMTP id 14.08.19241.889DAF05; Sat, 19 Jan 2013 11:36:08 -0600 (CST)
Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT105ADS.rim.net ([fe80::2d01:2041:eea3:819b%22]) with mapi id 14.02.0318.001; Sat, 19 Jan 2013 11:36:08 -0600
From: Andrew Allen 
To: "Cullen Jennings (fluffy)" , "dispatch@ietf.org" 
Thread-Topic: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted
Thread-Index: AQHNx0LDMMCAzJYzhkOmkNSi4UyFuJhRoCMA//+nLXA=
Date: Sat, 19 Jan 2013 17:36:07 +0000
Message-ID: 
References: <50ABBAD6.9050103@gmail.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.67.110.253]
Content-Type: text/plain; charset="us-ascii"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKKsWRmVeSWpSXmKPExsXC5Zyvp9tx81eAQdMNY4ulkxawWnRMZnNg 8pjyeyOrx5IlP5kCmKIaGG2SEkvKgjPT8/TtbBLz8vJLEktSFVJSi5NtlXxS0xNzFAKKMssS kysVXDKLk3MSM3NTi5QUMlNslUyUFApyEpNTc1PzSmyVEgsKUvNSlOy4FDCADVBZZp5Cal5y fkpmXrqtkmewv66FhamlrqGSnW5CJ0/G3Gn7GAtm+1d8uHeVrYHxhEMXIyeHhICJxNzv89kg bDGJC/fWA9lcHEICKxklLr/ZxgzhbGaU2LNnKzNIFZuAssTy3zMYuxg5OEQEYiTOTy4AqREW aGaU2HB4AytIjYhAC6PEvT8eELaVxP+na5hAbBYBVYlDLWdZQGxeAQ+JbXP3gtlCAtkSX3+c B+vlFPCV+PFsOdguRqCLvp+C6GUWEJe49WQ+E8SlAhJL9pxnhrBFJV4+/scKYStK/N37nRWi Xkdiwe5PbBC2tsSyha+ZIfYKSpyc+YRlAqPoLCRjZyFpmYWkZRaSlgWMLKsYBXMzig3MDJLz kvWKMnP18lJLNjGC0oGjhv4OxrfvLQ4xCnAwKvHwSh79FSDEmlhWXJl7iFGCg1lJhHdyA1CI NyWxsiq1KD++qDQntfgQoyswVCYyS3En5wNTVV5JvLGBAW6OkjivZO/lACGBdGD6yU5NLUgt gpnDxMEJsodLSqQYmERSixJLSzLiQakuvhiY7KQaGJfJ1yj9D+67/ySrc2e9ntWiwodzp/+Z oh26RmTKDaeV0z5/cS26Vcdy8sHtvaeSFweerV/9teYDm47ha9fzExSK53C7rHmtOycl44n9 fdsfl6ddVso99dg1kCH6Zdu13T0ptksS1mlt4HzeH1zR9LZqianGlmCWlQmBXDMWzDkk9lN/ 0on3G7cpsRRnJBpqMRcVJwIAicVO1UgDAAA=
Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 19 Jan 2013 17:36:12 -0000

Cullen

An IPR declaration on these drafts was made over 3 years ago so I think the=
 IPR situation and terms are well known.

I think Dale Worley  in some much earlier thread also explained why in his v=
iew this should not be an issue preventing progress of the draft. I concur w=
ith Dale on that.

Andrew

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf=
 Of Cullen Jennings (fluffy)
Sent: Saturday, January 19, 2013 11:50 AM
To: Tom Taylor
Cc: dispatch@ietf.org
Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and,=
 draft-allen-dispatch-imei-urn-as-instanceid submitted


I would like to point out that several of my comments, including the one abo=
ut IPR, had never been addressed. 

On Nov 20, 2012, at 10:16 AM, Tom Taylor  wrote:

> Andrew's original note appeared to me at least as a brief message: "WARNIN=
G: contains banned part", with attachments. As a public service, I have extr=
acted and reproduced the text of his message. Hope this isn't a duplicate fr=
om others' point of view.
> 
> Tom Taylor
> 
> Andrew's message:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
> New versions of draft-montemurro-gsma-imei-urn and draft-allen-dispatch-im=
ei-urn-as-instanceid were submitted at the beginning of October.
> 
> http://www.ietf.org/internet-drafts/draft-allen-dispatch-imei-urn-as-insta=
nceid-06.txt
> 
> http://www.ietf.org/internet-drafts/draft-montemurro-gsma-imei-urn-11.txt
> 
> There are not many major changes since the previous versions which were su=
bmitted in March and July which themselves were submitted after the conferen=
ce call held between 3GPP and IETF interested parties in early January on th=
e topic. Basically editorial updates and some strengthening of the normative=
 language.
> 
> The main change in draft-montemurro-gsma-imei-urn since the previous versi=
on is to address the ABNF comment from Dale and it was decided we do not nee=
d parameters to have multiple values so Dale's proposed resolution has been=
 adopted. The January version of draft-montemurro-gsma-imei-urn (09 version)=
 added the following to the Security Considerations section to address the p=
rivacy concerns:
> 
>   Further, because IMEIs can be loosely correlated to a user, they
>   need to be treated as any other personally identifiable
>   information. In particular, the IMEI SHOULD NOT be included in
>   messages intended to convey any level of anonymity.
> 
> In the latest (11 version) this has been strengthened from a SHOULD NOT to=
 a MUST NOT.
> 
> The draft-allen-dispatch-imei-urn-as-instanceid 05 version that was submit=
ted in March incorporated a number of significant changes including:
> 
> 1.    Additional text was added to the abstract stating:
> 
> [The purpose of the draft] is to fulfil the requirements in RFC 5626 [1] t=
hat state "If a URN scheme other than UUID is used, the UA MUST only use URN=
s for which an RFC (from the IETF stream) defines how the specific URN needs=
 to be constructed and used in the "+sip.instance" Contact header field para=
meter for outbound behavior."
> 
> 2.    A new section was added describing the three 3GPP use cases
> 
> 3.    A new section was added for 3GPP Registrar Procedures with the follo=
wing text:
> 
> In 3GPP IMS when the Registrar receives in the Contact header field a "sip=
.instance" media feature tag containing the GSMA IMEI URN according to the s=
yntax defined in draft-montemurro-gsma-imei-urn-09[3] the registrar follows=
 the procedures defined in RFC 5626 [1] and RFC 5627 [2] if those extensions=
 are supported and indicated as supported by the UA.  If the Registrar alloc=
ates a public GRUU according to the procedures defined in RFC 5627 [2] the t=
he instance-id MUST be obfuscated when creating the "gr" parameter in order=
 not to reveal the IMEI to other UAs when the public GRUU is included in non=
 register requests. 3GPP TS 24.229 [6] subcluase 5.4.7A.2 defines the mechan=
ism for obfuscating the IMEI when creating the "gr" parameter.
> 
> 4.    The security section was beefed up as follows:
> 
> Because IMEIs like other formats of instance IDs can be loosely correlated=
 to a user, they need to be treated as any other personally identifiable inf=
ormation.  In particular, the "sip.instance" media feature tag containing th=
e GSMA IMEI URN MUST NOT be included in requests or responses intended to co=
nvey any level of anonymity.  RFC 5626 [1] states "One case where a UA could=
 prefer to omit the "sip.instance" media feature tag is when it is making an=
 anonymous request or some other privacy concern requires that the UA not re=
veal its identity".  The same concerns apply when using the GSMA IMEI URN as=
 an instance ID.  Publication of the GSMA IMEI URN to networks that the UA i=
s not attached to or the UA does not have a service relationship with is a s=
ecurity breach and the "sip.instance" media feature tag MUST NOT be forwarde=
d by the service provider's network elements when forwarding requests or res=
ponses towards the destination UA.
> 
> In order to protect from tampering the REGISTER requests containing the GS=
MA IMEI URN MUST be sent using a security mechanism such as TLS [12] (or ano=
ther security mechanism that provides equivalent levels of protection).
> 
> There do not seem to be any comments made against the draft-allen-dispatch=
-imei-urn-as-instanceid-05 version that was submitted in March. Not sure if=
 this was because everyone was Ok with it or because it was overlooked.
> 
> At the conference call held between 3GPP and IETF interested participants=
 in January at which privacy concerns about the use of the IMEI as an instan=
ce ID by 3GPP were raised. It was proposed during the conference call that t=
he authors submit a new revision of the draft clarifying the use of the mech=
anism and explaining how the 3GPP architecture addresses the privacy issues=
 that were discussed.
> 
> There was a further discussion at a following 3GPP meeting on these privac=
y concerns. During the 3GPP discussion it was pointed out that RFC 5626 alre=
ady previously considered and addressed privacy concerns  with instance ID i=
n section 4.1 which only states the "UA could prefer to omit the "sip.instan=
ce" media feature tag":
> 
> 4.1.  Instance ID Creation
> 
>   To convey its instance-id in both requests and responses, the UA
>   includes a "sip.instance" media feature tag as a UA characteristic
>   [RFC3840].  This media feature tag is encoded in the Contact header
>   field as the "+sip.instance" Contact header field parameter.  One
>   case where a UA could prefer to omit the "sip.instance" media feature
>   tag is when it is making an anonymous request or some other privacy
>   concern requires that the UA not reveal its identity.
> 
> draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instan=
ceid and the 3GPP specified usage of the IMEI already go considerably furthe=
r than RFC 5626 does in this regard. Regardless of whether a UUID URN or the=
 IMEI URN is used as an instance ID the privacy issues are the same since an=
 instance ID based on a UUID is static once generated and therefore like the=
 IMEI potentially reveals the identity of the caller if it can be correlated=
 with the identity of that caller from a previous call.

> 
> The view in 3GPP was that the IMEI should not be of any greater concern wh=
en used as an instance ID than using a UUID. Asking 3GPP to go considerably=
 further in addressing privacy concerns with use of IMEI as an instance ID t=
han RFC 5626 already does was considered by many in 3GPP to be unwarranted.=
 Describing fully all the potential uses with 3GPP IMS of instance ID and do=
cumenting all the security mechanisms in all scenarios is a really non-trivi=
al task considering that many organizations outside 3GPP specify access netw=
orks for IMS and applications using IMS (OMA, GSMA, Cablelabs, 3GPP2, TISPAN=
, WIMAX Forum...) and outside the capability of the authors of the draft alo=
ne. In basic summary most if not all accesses to IMS provide for at least ba=
sic levels of transport security such as use of IPsec or TLS tunnels and/or=
 access layer security (although there is no guarantee these will be always=
 enabled by the every carrier). This goes beyond what is required by RFC 562=
6 whic
 h only recommends use of TLS even though the general internet is probably m=
ore open to attack than a managed carrier network.
> 
> Those that think privacy issues are insufficiently addressed need to expla=
in why the IMEI is of significantly greater concern in terms of revealing pr=
ivacy than the UUID when used as an instance ID.
> 
> In our view the security concerns raised have now been sufficiently addres=
sed in the drafts and to a much higher bar than that of UUID in RFC 5626.
> 
> The 3GPP use cases have now been described in draft-allen-dispatch-imei-ur=
n-as-instanceid. It is my view that describing these uses as an instance ID=
 also in draft-montemurro-gsma-imei-urn is both redundant and inappropriate=
 since this draft does not define use of the IMEI as an instance ID.
> 
> Attached are diffs between the 04 and 06 versions of draft-allen-dispatch-=
imei-urn-as-instanceid and between the 09 and 11 versions of draft-montemurr=
o-gsma-imei-urn.
> 
> So I would like to ask for review of these two latest drafts and to provid=
e any comments. 3GPP urgently needs to progress these drafts which are neede=
d to complete 3GPP Release 8.
> 
> Andrew
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

From tom.taylor.stds@gmail.com  Sat Jan 19 19:32:59 2013
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13B221F879B for ; Sat, 19 Jan 2013 19:32:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.384
X-Spam-Level: 
X-Spam-Status: No, score=-3.384 tagged_above=-999 required=5 tests=[AWL=0.215,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVq+hN3q5B1c for ; Sat, 19 Jan 2013 19:32:59 -0800 (PST)
Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by ietfa.amsl.com (Postfix) with ESMTP id 2920421F8742 for ; Sat, 19 Jan 2013 19:32:59 -0800 (PST)
Received: by mail-ie0-f180.google.com with SMTP id c10so8333266ieb.11 for ; Sat, 19 Jan 2013 19:32:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-antivirus:x-antivirus-status; bh=ZkW/eFiC6zYmm51n3UFLq44NtwdFIJVnFUy2jZL6NmU=; b=y0f8iIK6V46am/PVLUE26hGa/RPc+i6JKQLbSgavDQ+NbTV+IoOGovxHaQMwvepGoq MCq1Aup5uGcsiBCGuckxMjJoyvBhefpHe0Ha7jShMUctDkgJqXmY9MU8EqV08B8U/TVF hlSMw5ZjpSRWMKyHvtti4fRoAiOd6Mz5uP2tj0X7RWKVGPn1ewJ6eJkYy/W79CXsBTcl rsKxJKNVtPdB1nBMFZ00brKxlO9DPFxHR2IwTZpwXmS0YLrC5kyzeu0Wk90YDBJsOLYu 1OrN04AnGu8WGOt1YaH9Zaut6Fea+SXPdTBhoBzweidUpQmZuLrKrd9CkVJ3nkyRQs00 DNZA==
X-Received: by 10.42.42.69 with SMTP id s5mr9738459ice.2.1358652778762; Sat, 19 Jan 2013 19:32:58 -0800 (PST)
Received: from [127.0.0.1] (dsl-173-206-87-33.tor.primus.ca. [173.206.87.33]) by mx.google.com with ESMTPS id e9sm5491365igp.11.2013.01.19.19.32.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Jan 2013 19:32:57 -0800 (PST)
Message-ID: <50FB6569.8020008@gmail.com>
Date: Sat, 19 Jan 2013 22:32:57 -0500
From: Tom Taylor 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: "Cullen Jennings (fluffy)" 
References: <50ABBAD6.9050103@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Antivirus: avast! (VPS 130119-1, 19/01/2013), Outbound message
X-Antivirus-Status: Clean
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Jan 2013 03:32:59 -0000

Those weren't my remarks. All I did on Nov. 20 was forward Andrew's note 
in readable form.

On 19/01/2013 11:49 AM, Cullen Jennings (fluffy) wrote:
>
> On Nov 20, 2012, at 10:16 AM, Tom Taylor 
> wrote:
>
>> Those that think privacy issues are insufficiently addressed need
>> to explain why the IMEI is of significantly greater concern in
>> terms of revealing privacy than the UUID when used as an instance
>> ID.
>
> That has been explained in detail multiple times. For one thing, the
> user can't change the IMEI. For a second thing, it can be directly
> mapped to a specific user in many cases.
>
>>
>> In our view the security concerns raised have now been sufficiently
>> addressed in the drafts and to a much higher bar than that of UUID
>> in RFC 5626.
>
> I strongly disagree.
>
>

From caryfitz@employees.org  Sun Jan 20 17:18:49 2013
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4AC21F88E4 for ; Sun, 20 Jan 2013 17:18:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.214
X-Spam-Level: *
X-Spam-Status: No, score=1.214 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SARE_OBFU_MILLIONS=1.213]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AB+J3qUroYIA for ; Sun, 20 Jan 2013 17:18:47 -0800 (PST)
Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6E821F891A for ; Sun, 20 Jan 2013 17:18:44 -0800 (PST)
Received: from [192.168.1.6] (c-24-7-29-157.hsd1.ca.comcast.net [24.7.29.157]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: caryfitz) by banjo.employees.org (Postfix) with ESMTPSA id 23CAF5EC3; Sun, 20 Jan 2013 17:18:43 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_2CE6FAAD-31AE-43D7-A152-7AF2B68DA87E"
From: Cary FitzGerald 
In-Reply-To: 
Date: Sun, 20 Jan 2013 17:18:42 -0800
Message-Id: 
References: <20130115221242.24696.18448.idtracker@ietfa.amsl.com> <2C2D00AB-C0DD-4714-B570-0F63778B52ED@employees.org> <5C7C04EC-0B62-4E4E-88D0-5C59ADA26AA0@cisco.com> <6192484F-7FCB-4BA7-A7A0-256D66218B88@cisco.com> <64DCFB07-223F-4470-AC25-8353C32AC7A6@employees.org>  <67276E5D-6F73-45CB-A103-8407A6E78DEC@employees.org> 
To: Kevin Fleming 
X-Mailer: Apple Mail (2.1283)
Cc: dispatch@ietf.org
Subject: Re: [dispatch] I-D Action: draft-hanes-dispatch-fax-capability-07.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Jan 2013 01:18:49 -0000

--Apple-Mail=_2CE6FAAD-31AE-43D7-A152-7AF2B68DA87E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Copying dispatch.

You keep trying to tell me that fax is a widely used feature - trust me, =
I know that very well (and have the scars to prove it!).

What I don't understand is how a preference helps.  If there were some =
way _a priori_ to determine that a call was likely to be a fax call, =
then OK.  But the example you present says precisely that you don't have =
any of that information - the INVITE for a call that has some fax =
content is indistinguishable from one that doesn't (as it should, calls =
can go between fax and voice content multiple times).  My only real =
request is to add some kind of logic to the draft on how one divines =
that a call is more likely to contain fax content than any other call.

I don't think that this draft hurts anything, but I don't see how it =
helps.

Cary.

On Jan 20, 2013, at 4:48 AM, Kevin Fleming wrote:

> You are absolutely correct; there are plenty of far more useful =
alternatives to T.38 FAX. In spite of that, it's used heavily, and will =
likely be so for the foreseeable future. A simple example of where this =
feature tag would be useful would be a small business replacing a TDM =
PBX with an IP PBX, and using SIP for connection to the PSTN and other =
businesses. It is quite likely that such a small business would own one =
or more FAX machines, and when those are connected to the new PBX, their =
analog ports would be 'marked' as FAX ports. Any calls that they =
initiate would be marked as "FAX" calls on their way out of the PBX, due =
to the vast majority of them actually being FAX calls. Doing so would =
actually indicate to any network elements in the path of that call that =
it is intended to be a FAX call as early as that information is =
available (long before CNG or other inband negotiation would begin, =
which is much too late for many use cases).
>=20
> That describes how it could be applied; as to how it could be useful, =
take the example of auto-discrimination of inbound calls to extensions =
on a PBX. Many PBXes do this today, so that users of the PBX can publish =
a single phone number for both voice and FAX calls. The implementation =
of this is rather ugly, though, the PBX has to spy on the media path to =
listen for CNG after the call is answered so it can redirect the call to =
a FAX endpoint. This works acceptably well when the user is not at their =
desk and the call lands at their voicemail, but it's inelegant when they =
are at their desk and their phone rings. They get interrupted, answer =
the call, say "Hello?" a few times, and then hear a short blip of CNG =
before the is dropped from their handset. It is even less elegant when a =
PBX user has 'call-forward-no-answer' to someone else in their team; now =
the FAX call rings for 6-7 rings before being answered, only to again be =
pulled away. As another complication, auto-discrimination effectively =
disables the use of V.34 FAX, because in that mode the *receiving* FAX =
endpoint is responsible for initiating the protocol negotiation (by =
emitting ANSam), which can't be done if the call wasn't answered by a =
FAX endpoint. The result of this is that even if both FAX endpoints are =
V.34 capable, the FAX transaction will use older/slower/less reliable =
modem protocols because the calling endpoint's state machine will have =
passed the 'point of no return' for V.34 negotiation by the time the =
call is redirected.
>=20
> On the conceptual level, I think we're all in agreement that FAX is a =
terrible mechanism for document transmission and that there are far more =
effective (and less expensive) mechanisms available. Unfortunately, =
there are tens of milllions (if not hundreds of millions) of FAX =
machines deployed and they are used every day for billions of document =
transmissions. As the voice networks of the world move to IP and SIP, =
there is a need to provide FAX call success rates comparable to what the =
TDM networks provided.
>=20
>=20
>=20
>=20
> On Sat, Jan 19, 2013 at 10:16 PM, Cary FitzGerald =
 wrote:
>=20
> On Jan 19, 2013, at 4:32 AM, Kevin Fleming wrote:
>=20
>> Actually, the primary use case for this feature tag is *not* expected =
to be PSTN-originated calls, but instead FAX-capable SIP endpoints
>=20
> I am skeptical that this is an important use case.  Why would SIP =
endpoint generate a T.38 call when there are so many *much* better =
alternatives?
>=20
>> (or non-SIP endpoints attached to a SIP gateway that has been =
administratively configured to be aware of their FAX capabilities).
>=20
> That's what I meant by a PSTN call - the gateway is acting as a proxy =
for the PSTN-connected fax machine.
>=20
>> In these cases, the endpoint or its immediate gateway will have =
explicit knowledge that the call being placed by the endpoint is for the =
purpose of a FAX transmission. If the T.38 recommendation had been =
designed differently, and INVITE carrying only a T.38 SDP was an =
acceptable option, then this feature tag would be unnecessary. =
Unfortunately (and for legitimate reasons) that is not the case, and the =
SIP Forum's FOIP task group came to the conclusion that providing a =
mechanism for the endpoint to explicitly indicate its intent to initiate =
a FAX transaction would be useful.
>>=20
> However, I still am baffled about what logic one would use to =
determine that a call was more likely to carry fax than anything else.  =
That's all I'm asking - given that a fax call is in general =
indistinguishable from any other call how would someone make the =
determination that any specific call should get special treatment?
>=20
> I don't think that this draft is harmful, so if itproceeds I don't =
mind.  Not to be rude, I just don't think that it is useful.  I'm not =
suggesting that fax is not important, I just don't understand how the =
draft helps.  The fact that you can't express T.38 in sdp is a canard - =
you wouldn't know whether that was important or not doesn't matter when =
an INVITE arrives, because you'd only know about CNG well after the =
media path was established - hundreds of milliseconds later.  I don't =
know what logic you'd use to figure out a m=3D line or this prefs =
decision.
>=20
> Cary.
>>=20
>> On Fri, Jan 18, 2013 at 11:03 PM, Cary FitzGerald =
 wrote:
>> Hmmm.  I _thought_ i was subscribed to dispatch, but apparently =
there's a problem there.  I'll try to figure this out tomorrow.
>>=20
>> On Jan 18, 2013, at 7:29 PM, David Hanes wrote:
>>=20
>> > Hi Cary,
>> >
>> > I just wanted to follow-up once since we had not heard back from =
you and we are facing a deadline. This draft is on the agenda of the =
1/24 IESG telechat and we want to make sure that we have addressed your =
concerns.
>> >
>> > Thanks,
>> > David
>> >
>> >
>> > On Jan 16, 2013, at 11:56 PM, David Hanes wrote:
>> >
>> >> Hi Cary,
>> >>
>> >> Thanks for the comments. I am taking this off-list as I needed =
some clarification on a few things; some of which may have been =
addressed already through the various discussions on DISPATCH that have =
already taken place prior to Last Call.  Some inline comments...
>> >>
>> >> Regards,
>> >> David
>> >>
>> >>
>> >>
>> >>
>> >> On Jan 16, 2013, at 1:36 PM, Cary FitzGerald wrote:
>> >>
>> >>> I don't understand use case for this draft.  Unless I'm missing =
something, it helps to solve a very small corner case.
>> >>>
>> >>> For the IP-UA to UA case, it seems very unlikely to be useful.  =
Of course someone _could_ construct a UA that sends T.38, but why bother =
when SMTP or mumble is so much less trouble.  So I don't see an actual =
problem here.
>> >>
>> >> Admittedly, fax is that evil which will never die but actually =
this draft addresses a very real problem that has been under discussion =
by the FoIP Task Group of the SIP Forum for a couple of years. They =
concluded that the ability to select SIP endpoints for session =
termination based on the need for fax support by the calling endpoint =
would be very useful. This draft is doing nothing more than registering =
a new media feature tag (like audio, video, data, text, etc.) that was =
omitted earlier.
>> >>
>> No argument that fax is the undead, stabbed in the heart many times, =
still stumbling forward.
>>=20
>> >>>
>> >>> For the PSTN-UA to UA case, as the draft points out, there is no =
way to predict whether fax is going to be part of the call.  It's =
certainly true that increasing the probability of successfully handling =
a media stream, but I don't know how to figure out a priori how to set =
the balance between capabilities, convenience and whatever else the =
user's preferences are trying to tell us.
>> >>>
>> >>> If the call is routed to BOB (Big Old Business), then I'd kind of =
expect that by administrative policy, the BOB administrators would set a =
routing policy if some of the incoming PSTN numbers were fax banks to =
route to fax capable UAs.  You _could_ solve the problem with =
preferences, but that seems like a lot of unnecessary nuance.  Routing =
policy is a hammer, for sure, but it's simple and works for this case.
>> >>
>> >> Yes, routing policy can work in this case but in other cases it =
cannot. This draft provides a broader solution and encompasses use cases =
where multiple UAs are registered for a single number but only a certain =
one can handle fax media.
>>=20
>> Of course, it is possible that BOB has UAs that are not always =
accessible, and that having a preference is that is dynamically updated =
is useful, but operationally, I don't see this actually happening.
>> >>
>> >>>
>> >>> If the call is routed to Bob Regular Guy, and assuming Alice can =
predict the preferences for that particular call (outside of any other =
preferences), then the draft solves an actual problem.
>> >>>
>> >>> I think that the draft would be improved if the authors could add =
some words about how Alice would calculate a preference.
>> >>
>> >> The main use case here would involve Alice initiating fax calls =
from a fax server or from a DID fronted by a proxy. In either of these =
cases, the fax media feature tag is appended to the INVITE. Can you =
clarify what you mean by "calculate a preference" as Alice is the =
initiator and ascertaining that the call is fax would not be =
complicated?
>> >>
>> >>
>> Sorry if I was being obscure.
>>=20
>> An INVITE carries whatever information it carries.  What information =
would you use to assert that for _this call_ the INVITE should be routed =
this way versus that way?  If you buy my argument that this is a call =
that is originated in the PSTN, then you have an originating number and =
terminating number.  If this is what you know, what logic do you see =
filling in here:
>>=20
>> if (originating_number =3D=3D condition) then
>>         if (terminating_number =3D=3D condition)
>>                 foo;
>>         else
>>                 bar;
>> else
>>         if (terminating_number =3D=3D condition)
>>                 blatz;
>>         else
>>                 buzz;
>>=20
>> I'm not disputing that there is value in increasing the probability =
of successfully terminating a fax call, I just don't know how to do it.  =
What I'm asking for is a clue how.
>>=20
>> You can argue that my issues should not be in a protocol =
specification, but in this case, if I were a product manager, I wouldn't =
know how to assign a non-zero priority to this feature.  My point is =
what I said before.  If you could provide some logic of how you would =
decide how to route any particular call, it would help me understand how =
this draft helps the cause.
>>=20
>> Cary.
>> >>>
>> >>> Cary.
>> >>>
>> >>> On Jan 15, 2013, at 2:12 PM, internet-drafts@ietf.org wrote:
>> >>>
>> >>>>
>> >>>> A New Internet-Draft is available from the on-line =
Internet-Drafts directories.
>> >>>>
>> >>>>
>> >>>>    Title           : Indicating Fax over IP Capability in the =
Session Initiation Protocol (SIP)
>> >>>>    Author(s)       : David Hanes
>> >>>>                       Gonzalo Salgueiro
>> >>>>                       Kevin P. Fleming
>> >>>>    Filename        : draft-hanes-dispatch-fax-capability-07.txt
>> >>>>    Pages           : 9
>> >>>>    Date            : 2013-01-15
>> >>>>
>> >>>> Abstract:
>> >>>> This document defines and registers with IANA the new 'fax' =
media
>> >>>> feature tag for use with SIP.  Currently, fax calls are
>> >>>> indistinguishable from voice at call initiation.  Consequently, =
fax
>> >>>> calls can be routed to SIP user agents that are not fax capable. =
 A
>> >>>> 'fax' media feature tag implemented in conjunction with caller
>> >>>> preferences allows for more accurate fax call routing.
>> >>>>
>> >>>>
>> >>>> The IETF datatracker status page for this draft is:
>> >>>> =
https://datatracker.ietf.org/doc/draft-hanes-dispatch-fax-capability
>> >>>>
>> >>>> There's also a htmlized version available at:
>> >>>> =
http://tools.ietf.org/html/draft-hanes-dispatch-fax-capability-07
>> >>>>
>> >>>> A diff from the previous version is available at:
>> >>>> =
http://www.ietf.org/rfcdiff?url2=3Ddraft-hanes-dispatch-fax-capability-07
>> >>>>
>> >>>>
>> >>>> Internet-Drafts are also available by anonymous FTP at:
>> >>>> ftp://ftp.ietf.org/internet-drafts/
>> >>>>
>> >>>> _______________________________________________
>> >>>> I-D-Announce mailing list
>> >>>> I-D-Announce@ietf.org
>> >>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> >>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> >>>
>> >>> _______________________________________________
>> >>> dispatch mailing list
>> >>> dispatch@ietf.org
>> >>> https://www.ietf.org/mailman/listinfo/dispatch
>> >>
>>=20
>>=20
>=20
>=20


--Apple-Mail=_2CE6FAAD-31AE-43D7-A152-7AF2B68DA87E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


You are absolutely correct; there are plenty of far more =
useful alternatives to T.38 FAX. In spite of that, it's used heavily, =
and will likely be so for the foreseeable future. A simple example of =
where this feature tag would be useful would be a small business =
replacing a TDM PBX with an IP PBX, and using SIP for connection to the =
PSTN and other businesses. It is quite likely that such a small business =
would own one or more FAX machines, and when those are connected to the =
new PBX, their analog ports would be 'marked' as FAX ports. Any calls =
that they initiate would be marked as "FAX" calls on their way out of =
the PBX, due to the vast majority of them actually being FAX calls. =
Doing so would actually indicate to any network elements in the path of =
that call that it is intended to be a FAX call as early as that =
information is available (long before CNG or other inband negotiation =
would begin, which is much too late for many use cases).


That describes how it could be applied; as to =
how it could be useful, take the example of auto-discrimination of =
inbound calls to extensions on a PBX. Many PBXes do this today, so that =
users of the PBX can publish a single phone number for both voice and =
FAX calls. The implementation of this is rather ugly, though, the PBX =
has to spy on the media path to listen for CNG after the call is =
answered so it can redirect the call to a FAX endpoint. This works =
acceptably well when the user is not at their desk and the call lands at =
their voicemail, but it's inelegant when they are at their desk and =
their phone rings. They get interrupted, answer the call, say "Hello?" a =
few times, and then hear a short blip of CNG before the is dropped from =
their handset. It is even less elegant when a PBX user has =
'call-forward-no-answer' to someone else in their team; now the FAX call =
rings for 6-7 rings before being answered, only to again be pulled away. =
As another complication, auto-discrimination effectively disables the =
use of V.34 FAX, because in that mode the *receiving* FAX endpoint is =
responsible for initiating the protocol negotiation (by emitting ANSam), =
which can't be done if the call wasn't answered by a FAX endpoint. The =
result of this is that even if both FAX endpoints are V.34 capable, the =
FAX transaction will use older/slower/less reliable modem protocols =
because the calling endpoint's state machine will have passed the 'point =
of no return' for V.34 negotiation by the time the call is =
redirected.



On the conceptual level, I =
think we're all in agreement that FAX is a terrible mechanism for =
document transmission and that there are far more effective (and less =
expensive) mechanisms available. Unfortunately, there are tens of =
milllions (if not hundreds of millions) of FAX machines deployed and =
they are used every day for billions of document transmissions. As the =
voice networks of the world move to IP and SIP, there is a need to =
provide FAX call success rates comparable to what the TDM networks =
provided.






On Sat, Jan 19, =
2013 at 10:16 PM, Cary FitzGerald <caryfitz@employees.org> wrote:



On Jan =
19, 2013, at 4:32 AM, Kevin Fleming wrote:


Actually, the primary use =
case for this feature tag is *not* expected to be PSTN-originated calls, =
but instead FAX-capable SIP =
endpoints

I am skeptical that =
this is an important use case.  Why would SIP endpoint generate a =
T.38 call when there are so many *much* better alternatives?



(or =
non-SIP endpoints attached to a SIP gateway that has been =
administratively configured to be aware of their FAX capabilities). =




That's what I meant by a PSTN call - the gateway is =
acting as a proxy for the PSTN-connected fax machine.

In these =
cases, the endpoint or its immediate gateway will have explicit =
knowledge that the call being placed by the endpoint is for the purpose =
of a FAX transmission. If the T.38 recommendation had been designed =
differently, and INVITE carrying only a T.38 SDP was an acceptable =
option, then this feature tag would be unnecessary. Unfortunately (and =
for legitimate reasons) that is not the case, and the SIP Forum's FOIP =
task group came to the conclusion that providing a mechanism for the =
endpoint to explicitly indicate its intent to initiate a FAX transaction =
would be useful.




However, I still =
am baffled about what logic one would use to determine that a call was =
more likely to carry fax than anything else.  That's all I'm asking =
- given that a fax call is in general indistinguishable from any other =
call how would someone make the determination that any specific call =
should get special treatment?



I don't think that this draft is harmful, so if =
itproceeds I don't mind.  Not to be rude, I just don't think that =
it is useful.  I'm not suggesting that fax is not important, I just =
don't understand how the draft helps.  The fact that you can't =
express T.38 in sdp is a canard - you wouldn't know whether that was =
important or not doesn't matter when an INVITE arrives, because you'd =
only know about CNG well after the media path was established - hundreds =
of milliseconds later.  I don't know what logic you'd use to figure =
out a m=3D line or this prefs decision.



Cary.

On Fri, Jan 18, =
2013 at 11:03 PM, Cary FitzGerald <caryfitz@employees.org> wrote:



Hmmm.  I _thought_ i was subscribed to =
dispatch, but apparently there's a problem there.  I'll try to =
figure this out tomorrow.






On Jan 18, 2013, at 7:29 PM, David Hanes wrote:



> Hi Cary,

>

> I just wanted to follow-up once since we had not heard back from =
you and we are facing a deadline. This draft is on the agenda of the =
1/24 IESG telechat and we want to make sure that we have addressed your =
concerns.



>

> Thanks,

> David

>

>

> On Jan 16, 2013, at 11:56 PM, David Hanes wrote:

>

>> Hi Cary,

>>

>> Thanks for the comments. I am taking this off-list as I needed =
some clarification on a few things; some of which may have been =
addressed already through the various discussions on DISPATCH that have =
already taken place prior to Last Call.  Some inline =
comments...



>>

>> Regards,

>> David

>>

>>

>>

>>

>> On Jan 16, 2013, at 1:36 PM, Cary FitzGerald wrote:

>>

>>> I don't understand use case for this draft.  Unless =
I'm missing something, it helps to solve a very small corner case.

>>>

>>> For the IP-UA to UA case, it seems very unlikely to be =
useful.  Of course someone _could_ construct a UA that sends T.38, =
but why bother when SMTP or mumble is so much less trouble.  So I =
don't see an actual problem here.



>>

>> Admittedly, fax is that evil which will never die but actually =
this draft addresses a very real problem that has been under discussion =
by the FoIP Task Group of the SIP Forum for a couple of years. They =
concluded that the ability to select SIP endpoints for session =
termination based on the need for fax support by the calling endpoint =
would be very useful. This draft is doing nothing more than registering =
a new media feature tag (like audio, video, data, text, etc.) that was =
omitted earlier.



>>


No argument that fax is the undead, stabbed in the heart many =
times, still stumbling forward.




>>>

>>> For the PSTN-UA to UA case, as the draft points out, there =
is no way to predict whether fax is going to be part of the call. =
 It's certainly true that increasing the probability of =
successfully handling a media stream, but I don't know how to figure out =
a priori how to set the balance between capabilities, convenience and =
whatever else the user's preferences are trying to tell us.



>>>

>>> If the call is routed to BOB (Big Old Business), then I'd =
kind of expect that by administrative policy, the BOB administrators =
would set a routing policy if some of the incoming PSTN numbers were fax =
banks to route to fax capable UAs.  You _could_ solve the problem =
with preferences, but that seems like a lot of unnecessary nuance. =
 Routing policy is a hammer, for sure, but it's simple and works =
for this case.



>>

>> Yes, routing policy can work in this case but in other cases it =
cannot. This draft provides a broader solution and encompasses use cases =
where multiple UAs are registered for a single number but only a certain =
one can handle fax media.






Of course, it is possible that BOB has UAs that are not always =
accessible, and that having a preference is that is dynamically updated =
is useful, but operationally, I don't see this actually happening.


>>

>>>

>>> If the call is routed to Bob Regular Guy, and assuming =
Alice can predict the preferences for that particular call (outside of =
any other preferences), then the draft solves an actual problem.

>>>

>>> I think that the draft would be improved if the authors =
could add some words about how Alice would calculate a preference.

>>

>> The main use case here would involve Alice initiating fax calls =
from a fax server or from a DID fronted by a proxy. In either of these =
cases, the fax media feature tag is appended to the INVITE. Can you =
clarify what you mean by "calculate a preference" as Alice is the =
initiator and ascertaining that the call is fax would not be =
complicated?



>>

>>


Sorry if I was being obscure.



An INVITE carries whatever information it carries.  What =
information would you use to assert that for _this call_ the INVITE =
should be routed this way versus that way?  If you buy my argument =
that this is a call that is originated in the PSTN, then you have an =
originating number and terminating number.  If this is what you =
know, what logic do you see filling in here:





if (originating_number =3D=3D condition) then

        if (terminating_number =3D=3D condition)

                foo;

        else

                bar;

else

        if (terminating_number =3D=3D condition)

                blatz;

        else

                buzz;



I'm not disputing that there is value in increasing the probability of =
successfully terminating a fax call, I just don't know how to do it. =
 What I'm asking for is a clue how.



You can argue that my issues should not be in a protocol specification, =
but in this case, if I were a product manager, I wouldn't know how to =
assign a non-zero priority to this feature.  My point is what I =
said before.  If you could provide some logic of how you would =
decide how to route any particular call, it would help me understand how =
this draft helps the cause.





Cary.


>>>

>>> Cary.

>>>

>>> On Jan 15, 2013, at 2:12 PM, internet-drafts@ietf.org wrote:

>>>

>>>>

>>>> A New Internet-Draft is available from the on-line =
Internet-Drafts directories.

>>>>

>>>>

>>>>    Title           : =
Indicating Fax over IP Capability in the Session Initiation Protocol =
(SIP)

>>>>    Author(s)       : David =
Hanes

>>>>                 =
      Gonzalo Salgueiro

>>>>                 =
      Kevin P. Fleming

>>>>    Filename        : =
draft-hanes-dispatch-fax-capability-07.txt

>>>>    Pages           : =
9

>>>>    Date           =
 : 2013-01-15

>>>>

>>>> Abstract:

>>>> This document defines and registers with IANA the new =
'fax' media

>>>> feature tag for use with SIP.  Currently, fax =
calls are

>>>> indistinguishable from voice at call initiation. =
 Consequently, fax

>>>> calls can be routed to SIP user agents that are not fax =
capable.  A

>>>> 'fax' media feature tag implemented in conjunction with =
caller

>>>> preferences allows for more accurate fax call =
routing.

>>>>

>>>>

>>>> The IETF datatracker status page for this draft is:

>>>> https://datatracker.ietf.org/doc/draft-hanes-dispatch-fa=
x-capability

>>>>

>>>> There's also a htmlized version available at:

>>>> http://tools.ietf.org/html/draft-hanes-dispatch-fax-capa=
bility-07

>>>>

>>>> A diff from the previous version is available at:

>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-hanes-dispatch-=
fax-capability-07

>>>>

>>>>

>>>> Internet-Drafts are also available by anonymous FTP =
at:

>>>> ftp://ftp.ietf.org/internet-drafts/

>>>>

>>>> _______________________________________________

>>>> I-D-Announce mailing list

>>>> I-D-Announce@ietf.org

>>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>>> Internet-Draft directories: http://www.ietf.org/shadow.html

>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

>>>

>>> _______________________________________________

>>> dispatch mailing list

>>> dispatch@ietf.org

>>> https://www.ietf.org/mailman/listinfo/dispatch

>>












=

--Apple-Mail=_2CE6FAAD-31AE-43D7-A152-7AF2B68DA87E--

From dhanes@cisco.com  Mon Jan 21 08:52:04 2013
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3475421F8585 for ; Mon, 21 Jan 2013 08:52:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.385
X-Spam-Level: 
X-Spam-Status: No, score=-9.385 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_OBFU_MILLIONS=1.213]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tx40cN8AiRJK for ; Mon, 21 Jan 2013 08:52:02 -0800 (PST)
Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4C921F856D for ; Mon, 21 Jan 2013 08:52:01 -0800 (PST)
X-TACSUNS: Virus Scanned
Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0LGpugP007273; Mon, 21 Jan 2013 11:51:56 -0500 (EST)
Received: from rtp-dhanes-8918.cisco.com (rtp-dhanes-8918.cisco.com [10.117.39.201]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0LGptMk014479;  Mon, 21 Jan 2013 11:51:55 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: multipart/alternative; boundary=Apple-Mail-3-375309885
From: David Hanes 
In-Reply-To: 
Date: Mon, 21 Jan 2013 11:51:55 -0500
Message-Id: 
References: <20130115221242.24696.18448.idtracker@ietfa.amsl.com> <2C2D00AB-C0DD-4714-B570-0F63778B52ED@employees.org> <5C7C04EC-0B62-4E4E-88D0-5C59ADA26AA0@cisco.com> <6192484F-7FCB-4BA7-A7A0-256D66218B88@cisco.com> <64DCFB07-223F-4470-AC25-8353C32AC7A6@employees.org>  <67276E5D-6F73-45CB-A103-8407A6E78DEC@employees.org>  
To: Cary FitzGerald 
X-Mailer: Apple Mail (2.1085)
Cc: dispatch@ietf.org
Subject: Re: [dispatch] I-D Action: draft-hanes-dispatch-fax-capability-07.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Jan 2013 16:52:04 -0000

--Apple-Mail-3-375309885
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Jan 20, 2013, at 8:18 PM, Cary FitzGerald wrote:

> Copying dispatch.
>=20
> You keep trying to tell me that fax is a widely used feature - trust =
me, I know that very well (and have the scars to prove it!).
>=20
> What I don't understand is how a preference helps.  If there were some =
way _a priori_ to determine that a call was likely to be a fax call, =
then OK. =20


Yes, the cases we are interested in covering are from fax devices that =
originate the call knowing a priori that it is to be a fax call (e.g. =
fax servers). We've mentioned a few ways to make this determination. The =
simplest example again is an IP fax server. It knows the call it is =
sending out is ultimately going to be fax so the determination is easy. =
The fax server then simply tags its initial INVITE with the fax media =
feature tag expressing its preference for a fax capable termination. =
This all happens prior to any tone detection or re-INVITE.


> But the example you present says precisely that you don't have any of =
that information - the INVITE for a call that has some fax content is =
indistinguishable from one that doesn't (as it should, calls can go =
between fax and voice content multiple times). =20


Actually, Kevin says that we DO have that information in his first =
paragraph -=20

"It is quite likely that such a small business would own one or more FAX =
machines, and when those are connected to the new PBX, their analog =
ports would be 'marked' as FAX ports. Any calls that they initiate would =
be marked as "FAX" calls on their way out of the PBX, due to the vast =
majority of them actually being FAX calls."

The PBX knows that a fax machine is on a specific port. So, it can =
easily apply the fax media feature to that initial INVITE without having =
to wait for the re-INVITE, CNG, or some other mechanism later in the =
call.

You say that "the INVITE for a call that has some fax content is =
indistinguishable from one that doesn't". I admit I may be missing your =
point but based on my understanding, the examples and text in this draft =
indicate otherwise. Let's see if we can agree on the following example. =
Here is a sample INVITE header for a voice call -=20

INVITE sip:bob@biloxi.example.com SIP/2.0
  Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=3Dz9hG4bK74b43
  Max-Forwards: 70
  From: Alice ;tag=3D9fxced76sl
  To: Bob 
  Call-ID: 3848276298220188511@atlanta.example.com



And here is the same example for a fax call. The SDP in both would be =
the same as they both start as a voice call, which I think we already =
agree on.

INVITE sip:bob@biloxi.example.com SIP/2.0
  Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=3Dz9hG4bK74b43
  Max-Forwards: 70
  From: Alice ;tag=3D9fxced76sl
  To: Bob 
  Accept-Contact: *;+sip.fax=3D"t38"
  Call-ID: 3848276298220188511@atlanta.example.com



The sample headers for the fax call have the fax media feature tag =
(+sip.fax=3D"t38") in the Accept-Contact header while the voice does =
not. So, from this example, can we agree that the INVITE for a call that =
has some fax content is distinguishable from one that doesn't?=20


> My only real request is to add some kind of logic to the draft on how =
one divines that a call is more likely to contain fax content than any =
other call.
>=20
> I don't think that this draft hurts anything, but I don't see how it =
helps.
>=20
> Cary.
>=20
> On Jan 20, 2013, at 4:48 AM, Kevin Fleming wrote:
>=20
>> You are absolutely correct; there are plenty of far more useful =
alternatives to T.38 FAX. In spite of that, it's used heavily, and will =
likely be so for the foreseeable future. A simple example of where this =
feature tag would be useful would be a small business replacing a TDM =
PBX with an IP PBX, and using SIP for connection to the PSTN and other =
businesses. It is quite likely that such a small business would own one =
or more FAX machines, and when those are connected to the new PBX, their =
analog ports would be 'marked' as FAX ports. Any calls that they =
initiate would be marked as "FAX" calls on their way out of the PBX, due =
to the vast majority of them actually being FAX calls. Doing so would =
actually indicate to any network elements in the path of that call that =
it is intended to be a FAX call as early as that information is =
available (long before CNG or other inband negotiation would begin, =
which is much too late for many use cases).
>>=20
>> That describes how it could be applied; as to how it could be useful, =
take the example of auto-discrimination of inbound calls to extensions =
on a PBX. Many PBXes do this today, so that users of the PBX can publish =
a single phone number for both voice and FAX calls. The implementation =
of this is rather ugly, though, the PBX has to spy on the media path to =
listen for CNG after the call is answered so it can redirect the call to =
a FAX endpoint. This works acceptably well when the user is not at their =
desk and the call lands at their voicemail, but it's inelegant when they =
are at their desk and their phone rings. They get interrupted, answer =
the call, say "Hello?" a few times, and then hear a short blip of CNG =
before the is dropped from their handset. It is even less elegant when a =
PBX user has 'call-forward-no-answer' to someone else in their team; now =
the FAX call rings for 6-7 rings before being answered, only to again be =
pulled away. As another complication, auto-discrimination effectively =
disables the use of V.34 FAX, because in that mode the *receiving* FAX =
endpoint is responsible for initiating the protocol negotiation (by =
emitting ANSam), which can't be done if the call wasn't answered by a =
FAX endpoint. The result of this is that even if both FAX endpoints are =
V.34 capable, the FAX transaction will use older/slower/less reliable =
modem protocols because the calling endpoint's state machine will have =
passed the 'point of no return' for V.34 negotiation by the time the =
call is redirected.
>>=20
>> On the conceptual level, I think we're all in agreement that FAX is a =
terrible mechanism for document transmission and that there are far more =
effective (and less expensive) mechanisms available. Unfortunately, =
there are tens of milllions (if not hundreds of millions) of FAX =
machines deployed and they are used every day for billions of document =
transmissions. As the voice networks of the world move to IP and SIP, =
there is a need to provide FAX call success rates comparable to what the =
TDM networks provided.
>>=20
>>=20
>>=20
>>=20
>> On Sat, Jan 19, 2013 at 10:16 PM, Cary FitzGerald =
 wrote:
>>=20
>> On Jan 19, 2013, at 4:32 AM, Kevin Fleming wrote:
>>=20
>>> Actually, the primary use case for this feature tag is *not* =
expected to be PSTN-originated calls, but instead FAX-capable SIP =
endpoints
>>=20
>> I am skeptical that this is an important use case.  Why would SIP =
endpoint generate a T.38 call when there are so many *much* better =
alternatives?
>>=20
>>> (or non-SIP endpoints attached to a SIP gateway that has been =
administratively configured to be aware of their FAX capabilities).
>>=20
>> That's what I meant by a PSTN call - the gateway is acting as a proxy =
for the PSTN-connected fax machine.
>>=20
>>> In these cases, the endpoint or its immediate gateway will have =
explicit knowledge that the call being placed by the endpoint is for the =
purpose of a FAX transmission. If the T.38 recommendation had been =
designed differently, and INVITE carrying only a T.38 SDP was an =
acceptable option, then this feature tag would be unnecessary. =
Unfortunately (and for legitimate reasons) that is not the case, and the =
SIP Forum's FOIP task group came to the conclusion that providing a =
mechanism for the endpoint to explicitly indicate its intent to initiate =
a FAX transaction would be useful.
>>>=20
>> However, I still am baffled about what logic one would use to =
determine that a call was more likely to carry fax than anything else.  =
That's all I'm asking - given that a fax call is in general =
indistinguishable from any other call how would someone make the =
determination that any specific call should get special treatment?
>>=20
>> I don't think that this draft is harmful, so if itproceeds I don't =
mind.  Not to be rude, I just don't think that it is useful.  I'm not =
suggesting that fax is not important, I just don't understand how the =
draft helps.  The fact that you can't express T.38 in sdp is a canard - =
you wouldn't know whether that was important or not doesn't matter when =
an INVITE arrives, because you'd only know about CNG well after the =
media path was established - hundreds of milliseconds later.  I don't =
know what logic you'd use to figure out a m=3D line or this prefs =
decision.
>>=20
>> Cary.
>>>=20
>>> On Fri, Jan 18, 2013 at 11:03 PM, Cary FitzGerald =
 wrote:
>>> Hmmm.  I _thought_ i was subscribed to dispatch, but apparently =
there's a problem there.  I'll try to figure this out tomorrow.
>>>=20
>>> On Jan 18, 2013, at 7:29 PM, David Hanes wrote:
>>>=20
>>> > Hi Cary,
>>> >
>>> > I just wanted to follow-up once since we had not heard back from =
you and we are facing a deadline. This draft is on the agenda of the =
1/24 IESG telechat and we want to make sure that we have addressed your =
concerns.
>>> >
>>> > Thanks,
>>> > David
>>> >
>>> >
>>> > On Jan 16, 2013, at 11:56 PM, David Hanes wrote:
>>> >
>>> >> Hi Cary,
>>> >>
>>> >> Thanks for the comments. I am taking this off-list as I needed =
some clarification on a few things; some of which may have been =
addressed already through the various discussions on DISPATCH that have =
already taken place prior to Last Call.  Some inline comments...
>>> >>
>>> >> Regards,
>>> >> David
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> On Jan 16, 2013, at 1:36 PM, Cary FitzGerald wrote:
>>> >>
>>> >>> I don't understand use case for this draft.  Unless I'm missing =
something, it helps to solve a very small corner case.
>>> >>>
>>> >>> For the IP-UA to UA case, it seems very unlikely to be useful.  =
Of course someone _could_ construct a UA that sends T.38, but why bother =
when SMTP or mumble is so much less trouble.  So I don't see an actual =
problem here.
>>> >>
>>> >> Admittedly, fax is that evil which will never die but actually =
this draft addresses a very real problem that has been under discussion =
by the FoIP Task Group of the SIP Forum for a couple of years. They =
concluded that the ability to select SIP endpoints for session =
termination based on the need for fax support by the calling endpoint =
would be very useful. This draft is doing nothing more than registering =
a new media feature tag (like audio, video, data, text, etc.) that was =
omitted earlier.
>>> >>
>>> No argument that fax is the undead, stabbed in the heart many times, =
still stumbling forward.
>>>=20
>>> >>>
>>> >>> For the PSTN-UA to UA case, as the draft points out, there is no =
way to predict whether fax is going to be part of the call.  It's =
certainly true that increasing the probability of successfully handling =
a media stream, but I don't know how to figure out a priori how to set =
the balance between capabilities, convenience and whatever else the =
user's preferences are trying to tell us.
>>> >>>
>>> >>> If the call is routed to BOB (Big Old Business), then I'd kind =
of expect that by administrative policy, the BOB administrators would =
set a routing policy if some of the incoming PSTN numbers were fax banks =
to route to fax capable UAs.  You _could_ solve the problem with =
preferences, but that seems like a lot of unnecessary nuance.  Routing =
policy is a hammer, for sure, but it's simple and works for this case.
>>> >>
>>> >> Yes, routing policy can work in this case but in other cases it =
cannot. This draft provides a broader solution and encompasses use cases =
where multiple UAs are registered for a single number but only a certain =
one can handle fax media.
>>>=20
>>> Of course, it is possible that BOB has UAs that are not always =
accessible, and that having a preference is that is dynamically updated =
is useful, but operationally, I don't see this actually happening.
>>> >>
>>> >>>
>>> >>> If the call is routed to Bob Regular Guy, and assuming Alice can =
predict the preferences for that particular call (outside of any other =
preferences), then the draft solves an actual problem.
>>> >>>
>>> >>> I think that the draft would be improved if the authors could =
add some words about how Alice would calculate a preference.
>>> >>
>>> >> The main use case here would involve Alice initiating fax calls =
from a fax server or from a DID fronted by a proxy. In either of these =
cases, the fax media feature tag is appended to the INVITE. Can you =
clarify what you mean by "calculate a preference" as Alice is the =
initiator and ascertaining that the call is fax would not be =
complicated?
>>> >>
>>> >>
>>> Sorry if I was being obscure.
>>>=20
>>> An INVITE carries whatever information it carries.  What information =
would you use to assert that for _this call_ the INVITE should be routed =
this way versus that way?  If you buy my argument that this is a call =
that is originated in the PSTN, then you have an originating number and =
terminating number.  If this is what you know, what logic do you see =
filling in here:
>>>=20
>>> if (originating_number =3D=3D condition) then
>>>         if (terminating_number =3D=3D condition)
>>>                 foo;
>>>         else
>>>                 bar;
>>> else
>>>         if (terminating_number =3D=3D condition)
>>>                 blatz;
>>>         else
>>>                 buzz;
>>>=20
>>> I'm not disputing that there is value in increasing the probability =
of successfully terminating a fax call, I just don't know how to do it.  =
What I'm asking for is a clue how.
>>>=20
>>> You can argue that my issues should not be in a protocol =
specification, but in this case, if I were a product manager, I wouldn't =
know how to assign a non-zero priority to this feature.  My point is =
what I said before.  If you could provide some logic of how you would =
decide how to route any particular call, it would help me understand how =
this draft helps the cause.
>>>=20
>>> Cary.
>>> >>>
>>> >>> Cary.
>>> >>>
>>> >>> On Jan 15, 2013, at 2:12 PM, internet-drafts@ietf.org wrote:
>>> >>>
>>> >>>>
>>> >>>> A New Internet-Draft is available from the on-line =
Internet-Drafts directories.
>>> >>>>
>>> >>>>
>>> >>>>    Title           : Indicating Fax over IP Capability in the =
Session Initiation Protocol (SIP)
>>> >>>>    Author(s)       : David Hanes
>>> >>>>                       Gonzalo Salgueiro
>>> >>>>                       Kevin P. Fleming
>>> >>>>    Filename        : draft-hanes-dispatch-fax-capability-07.txt
>>> >>>>    Pages           : 9
>>> >>>>    Date            : 2013-01-15
>>> >>>>
>>> >>>> Abstract:
>>> >>>> This document defines and registers with IANA the new 'fax' =
media
>>> >>>> feature tag for use with SIP.  Currently, fax calls are
>>> >>>> indistinguishable from voice at call initiation.  Consequently, =
fax
>>> >>>> calls can be routed to SIP user agents that are not fax =
capable.  A
>>> >>>> 'fax' media feature tag implemented in conjunction with caller
>>> >>>> preferences allows for more accurate fax call routing.
>>> >>>>
>>> >>>>
>>> >>>> The IETF datatracker status page for this draft is:
>>> >>>> =
https://datatracker.ietf.org/doc/draft-hanes-dispatch-fax-capability
>>> >>>>
>>> >>>> There's also a htmlized version available at:
>>> >>>> =
http://tools.ietf.org/html/draft-hanes-dispatch-fax-capability-07
>>> >>>>
>>> >>>> A diff from the previous version is available at:
>>> >>>> =
http://www.ietf.org/rfcdiff?url2=3Ddraft-hanes-dispatch-fax-capability-07
>>> >>>>
>>> >>>>
>>> >>>> Internet-Drafts are also available by anonymous FTP at:
>>> >>>> ftp://ftp.ietf.org/internet-drafts/
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> I-D-Announce mailing list
>>> >>>> I-D-Announce@ietf.org
>>> >>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>> >>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>> >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>> >>>
>>> >>> _______________________________________________
>>> >>> dispatch mailing list
>>> >>> dispatch@ietf.org
>>> >>> https://www.ietf.org/mailman/listinfo/dispatch
>>> >>
>>>=20
>>>=20
>>=20
>>=20
>=20


--Apple-Mail-3-375309885
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii




But the example you =
present says precisely that you don't have any of that information - the =
INVITE for a call that has some fax content is indistinguishable from =
one that doesn't (as it should, calls can go between fax and voice =
content multiple times). =
 


Actually=
, Kevin says that we DO have that information in his first paragraph =
- 

"It is quite likely that such a small business would own =
one or more FAX machines, and when those are connected to the new PBX, =
their analog ports would be 'marked' as FAX ports. Any calls that they =
initiate would be marked as "FAX" calls on their way out of the PBX, due =
to the vast majority of them actually being FAX calls."

The PBX =
knows that a fax machine is on a specific port. So, it can easily apply =
the fax media feature to that initial INVITE without having to wait for =
the re-INVITE, CNG, or some other mechanism later in the =
call.

You say that "the INVITE for a call that has some fax =
content is indistinguishable from one that doesn't". I admit I may be =
missing your point but based on my understanding, the examples and text =
in this draft indicate otherwise. Let's see if we can agree on the =
following example. Here is a sample INVITE header for a voice call =
- 

INVITE sip:bob@biloxi.example.com SI=
P/2.0
  Via: SIP/2.0/TCP =
client.atlanta.example.com:5060;branch=3Dz9hG4bK74b43
  Max-F=
orwards: 70
  From: Alice <sip:alice@atlanta.example.com&g=
t;;tag=3D9fxced76sl
  To: Bob <sip:bob@biloxi.example.com>
=
  Call-ID: 384827629822018851=
1@atlanta.example.com

<snip>

And here is the =
same example for a fax call. The SDP in both would be the same as they =
both start as a voice call, which I think we already agree =
on.

INVITE sip:bob@biloxi.example.com SI=
P/2.0
  Via: SIP/2.0/TCP =
client.atlanta.example.com:5060;branch=3Dz9hG4bK74b43
  Max-F=
orwards: 70
  From: Alice <sip:alice@atlanta.example.com&g=
t;;tag=3D9fxced76sl
  To: Bob <sip:bob@biloxi.example.com>
=
  Accept-Contact: =
*;+sip.fax=3D"t38"
  Call-ID: 384827629822018851=
1@atlanta.example.com

<snip>

The sample headers =
for the fax call have the fax media feature tag (+sip.fax=3D"t38") in =
the Accept-Contact header while the voice does not. So, from this =
example, can we agree that the INVITE for a call that has some fax =
content is distinguishable from one that =
doesn't? 


My only real request is to =
add some kind of logic to the draft on how one divines that a call is =
more likely to contain fax content than any other =
call.

I don't think that this draft hurts =
anything, but I don't see how it =
helps.

Cary.

On Jan 20, =
2013, at 4:48 AM, Kevin Fleming wrote:

You are absolutely correct; there are plenty of far more =
useful alternatives to T.38 FAX. In spite of that, it's used heavily, =
and will likely be so for the foreseeable future. A simple example of =
where this feature tag would be useful would be a small business =
replacing a TDM PBX with an IP PBX, and using SIP for connection to the =
PSTN and other businesses. It is quite likely that such a small business =
would own one or more FAX machines, and when those are connected to the =
new PBX, their analog ports would be 'marked' as FAX ports. Any calls =
that they initiate would be marked as "FAX" calls on their way out of =
the PBX, due to the vast majority of them actually being FAX calls. =
Doing so would actually indicate to any network elements in the path of =
that call that it is intended to be a FAX call as early as that =
information is available (long before CNG or other inband negotiation =
would begin, which is much too late for many use cases).


That describes how it could be applied; as to =
how it could be useful, take the example of auto-discrimination of =
inbound calls to extensions on a PBX. Many PBXes do this today, so that =
users of the PBX can publish a single phone number for both voice and =
FAX calls. The implementation of this is rather ugly, though, the PBX =
has to spy on the media path to listen for CNG after the call is =
answered so it can redirect the call to a FAX endpoint. This works =
acceptably well when the user is not at their desk and the call lands at =
their voicemail, but it's inelegant when they are at their desk and =
their phone rings. They get interrupted, answer the call, say "Hello?" a =
few times, and then hear a short blip of CNG before the is dropped from =
their handset. It is even less elegant when a PBX user has =
'call-forward-no-answer' to someone else in their team; now the FAX call =
rings for 6-7 rings before being answered, only to again be pulled away. =
As another complication, auto-discrimination effectively disables the =
use of V.34 FAX, because in that mode the *receiving* FAX endpoint is =
responsible for initiating the protocol negotiation (by emitting ANSam), =
which can't be done if the call wasn't answered by a FAX endpoint. The =
result of this is that even if both FAX endpoints are V.34 capable, the =
FAX transaction will use older/slower/less reliable modem protocols =
because the calling endpoint's state machine will have passed the 'point =
of no return' for V.34 negotiation by the time the call is =
redirected.



On the conceptual level, I =
think we're all in agreement that FAX is a terrible mechanism for =
document transmission and that there are far more effective (and less =
expensive) mechanisms available. Unfortunately, there are tens of =
milllions (if not hundreds of millions) of FAX machines deployed and =
they are used every day for billions of document transmissions. As the =
voice networks of the world move to IP and SIP, there is a need to =
provide FAX call success rates comparable to what the TDM networks =
provided.






On Sat, Jan 19, =
2013 at 10:16 PM, Cary FitzGerald <caryfitz@employees.org> wrote:



On Jan =
19, 2013, at 4:32 AM, Kevin Fleming wrote:


Actually, the primary use =
case for this feature tag is *not* expected to be PSTN-originated calls, =
but instead FAX-capable SIP =
endpoints

I am skeptical that =
this is an important use case.  Why would SIP endpoint generate a =
T.38 call when there are so many *much* better alternatives?



(or =
non-SIP endpoints attached to a SIP gateway that has been =
administratively configured to be aware of their FAX capabilities). =




That's what I meant by a PSTN call - the gateway is =
acting as a proxy for the PSTN-connected fax machine.

In these =
cases, the endpoint or its immediate gateway will have explicit =
knowledge that the call being placed by the endpoint is for the purpose =
of a FAX transmission. If the T.38 recommendation had been designed =
differently, and INVITE carrying only a T.38 SDP was an acceptable =
option, then this feature tag would be unnecessary. Unfortunately (and =
for legitimate reasons) that is not the case, and the SIP Forum's FOIP =
task group came to the conclusion that providing a mechanism for the =
endpoint to explicitly indicate its intent to initiate a FAX transaction =
would be useful.




However, I still =
am baffled about what logic one would use to determine that a call was =
more likely to carry fax than anything else.  That's all I'm asking =
- given that a fax call is in general indistinguishable from any other =
call how would someone make the determination that any specific call =
should get special treatment?



I don't think that this draft is harmful, so if =
itproceeds I don't mind.  Not to be rude, I just don't think that =
it is useful.  I'm not suggesting that fax is not important, I just =
don't understand how the draft helps.  The fact that you can't =
express T.38 in sdp is a canard - you wouldn't know whether that was =
important or not doesn't matter when an INVITE arrives, because you'd =
only know about CNG well after the media path was established - hundreds =
of milliseconds later.  I don't know what logic you'd use to figure =
out a m=3D line or this prefs decision.



Cary.

On Fri, Jan 18, =
2013 at 11:03 PM, Cary FitzGerald <caryfitz@employees.org> wrote:



Hmmm.  I _thought_ i was subscribed to =
dispatch, but apparently there's a problem there.  I'll try to =
figure this out tomorrow.






On Jan 18, 2013, at 7:29 PM, David Hanes wrote:



> Hi Cary,

>

> I just wanted to follow-up once since we had not heard back from =
you and we are facing a deadline. This draft is on the agenda of the =
1/24 IESG telechat and we want to make sure that we have addressed your =
concerns.



>

> Thanks,

> David

>

>

> On Jan 16, 2013, at 11:56 PM, David Hanes wrote:

>

>> Hi Cary,

>>

>> Thanks for the comments. I am taking this off-list as I needed =
some clarification on a few things; some of which may have been =
addressed already through the various discussions on DISPATCH that have =
already taken place prior to Last Call.  Some inline =
comments...



>>

>> Regards,

>> David

>>

>>

>>

>>

>> On Jan 16, 2013, at 1:36 PM, Cary FitzGerald wrote:

>>

>>> I don't understand use case for this draft.  Unless =
I'm missing something, it helps to solve a very small corner case.

>>>

>>> For the IP-UA to UA case, it seems very unlikely to be =
useful.  Of course someone _could_ construct a UA that sends T.38, =
but why bother when SMTP or mumble is so much less trouble.  So I =
don't see an actual problem here.



>>

>> Admittedly, fax is that evil which will never die but actually =
this draft addresses a very real problem that has been under discussion =
by the FoIP Task Group of the SIP Forum for a couple of years. They =
concluded that the ability to select SIP endpoints for session =
termination based on the need for fax support by the calling endpoint =
would be very useful. This draft is doing nothing more than registering =
a new media feature tag (like audio, video, data, text, etc.) that was =
omitted earlier.



>>


No argument that fax is the undead, stabbed in the heart many =
times, still stumbling forward.




>>>

>>> For the PSTN-UA to UA case, as the draft points out, there =
is no way to predict whether fax is going to be part of the call. =
 It's certainly true that increasing the probability of =
successfully handling a media stream, but I don't know how to figure out =
a priori how to set the balance between capabilities, convenience and =
whatever else the user's preferences are trying to tell us.



>>>

>>> If the call is routed to BOB (Big Old Business), then I'd =
kind of expect that by administrative policy, the BOB administrators =
would set a routing policy if some of the incoming PSTN numbers were fax =
banks to route to fax capable UAs.  You _could_ solve the problem =
with preferences, but that seems like a lot of unnecessary nuance. =
 Routing policy is a hammer, for sure, but it's simple and works =
for this case.



>>

>> Yes, routing policy can work in this case but in other cases it =
cannot. This draft provides a broader solution and encompasses use cases =
where multiple UAs are registered for a single number but only a certain =
one can handle fax media.






Of course, it is possible that BOB has UAs that are not always =
accessible, and that having a preference is that is dynamically updated =
is useful, but operationally, I don't see this actually happening.


>>

>>>

>>> If the call is routed to Bob Regular Guy, and assuming =
Alice can predict the preferences for that particular call (outside of =
any other preferences), then the draft solves an actual problem.

>>>

>>> I think that the draft would be improved if the authors =
could add some words about how Alice would calculate a preference.

>>

>> The main use case here would involve Alice initiating fax calls =
from a fax server or from a DID fronted by a proxy. In either of these =
cases, the fax media feature tag is appended to the INVITE. Can you =
clarify what you mean by "calculate a preference" as Alice is the =
initiator and ascertaining that the call is fax would not be =
complicated?



>>

>>


Sorry if I was being obscure.



An INVITE carries whatever information it carries.  What =
information would you use to assert that for _this call_ the INVITE =
should be routed this way versus that way?  If you buy my argument =
that this is a call that is originated in the PSTN, then you have an =
originating number and terminating number.  If this is what you =
know, what logic do you see filling in here:





if (originating_number =3D=3D condition) then

        if (terminating_number =3D=3D condition)

                foo;

        else

                bar;

else

        if (terminating_number =3D=3D condition)

                blatz;

        else

                buzz;



I'm not disputing that there is value in increasing the probability of =
successfully terminating a fax call, I just don't know how to do it. =
 What I'm asking for is a clue how.



You can argue that my issues should not be in a protocol specification, =
but in this case, if I were a product manager, I wouldn't know how to =
assign a non-zero priority to this feature.  My point is what I =
said before.  If you could provide some logic of how you would =
decide how to route any particular call, it would help me understand how =
this draft helps the cause.





Cary.


>>>

>>> Cary.

>>>

>>> On Jan 15, 2013, at 2:12 PM, internet-drafts@ietf.org wrote:

>>>

>>>>

>>>> A New Internet-Draft is available from the on-line =
Internet-Drafts directories.

>>>>

>>>>

>>>>    Title           : =
Indicating Fax over IP Capability in the Session Initiation Protocol =
(SIP)

>>>>    Author(s)       : David =
Hanes

>>>>                 =
      Gonzalo Salgueiro

>>>>                 =
      Kevin P. Fleming

>>>>    Filename        : =
draft-hanes-dispatch-fax-capability-07.txt

>>>>    Pages           : =
9

>>>>    Date           =
 : 2013-01-15

>>>>

>>>> Abstract:

>>>> This document defines and registers with IANA the new =
'fax' media

>>>> feature tag for use with SIP.  Currently, fax =
calls are

>>>> indistinguishable from voice at call initiation. =
 Consequently, fax

>>>> calls can be routed to SIP user agents that are not fax =
capable.  A

>>>> 'fax' media feature tag implemented in conjunction with =
caller

>>>> preferences allows for more accurate fax call =
routing.

>>>>

>>>>

>>>> The IETF datatracker status page for this draft is:

>>>> https://datatracker.ietf.org/doc/draft-hanes-dispatch-fa=
x-capability

>>>>

>>>> There's also a htmlized version available at:

>>>> http://tools.ietf.org/html/draft-hanes-dispatch-fax-capa=
bility-07

>>>>

>>>> A diff from the previous version is available at:

>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-hanes-dispatch-=
fax-capability-07

>>>>

>>>>

>>>> Internet-Drafts are also available by anonymous FTP =
at:

>>>> ftp://ftp.ietf.org/internet-drafts/

>>>>

>>>> _______________________________________________

>>>> I-D-Announce mailing list

>>>> I-D-Announce@ietf.org

>>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>>> Internet-Draft directories: http://www.ietf.org/shadow.html

>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

>>>

>>> _______________________________________________

>>> dispatch mailing list

>>> dispatch@ietf.org

>>> https://www.ietf.org/mailman/listinfo/dispatch

>>













=

--Apple-Mail-3-375309885--

From caryfitz@employees.org  Mon Jan 21 13:49:29 2013
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59BB021F84ED for ; Mon, 21 Jan 2013 13:49:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.086
X-Spam-Level: 
X-Spam-Status: No, score=-0.086 tagged_above=-999 required=5 tests=[AWL=1.300,  BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_OBFU_MILLIONS=1.213]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LknQ0EPADg+5 for ; Mon, 21 Jan 2013 13:49:27 -0800 (PST)
Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id AE85321F84EA for ; Mon, 21 Jan 2013 13:49:26 -0800 (PST)
Received: from [192.168.1.6] (c-24-7-29-157.hsd1.ca.comcast.net [24.7.29.157]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: caryfitz) by banjo.employees.org (Postfix) with ESMTPSA id 8CBA25ED3; Mon, 21 Jan 2013 13:49:25 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_B8D1DDD5-D97F-4774-9373-E20643390AFF"
From: Cary FitzGerald 
In-Reply-To: 
Date: Mon, 21 Jan 2013 13:49:24 -0800
Message-Id: 
References: <20130115221242.24696.18448.idtracker@ietfa.amsl.com> <2C2D00AB-C0DD-4714-B570-0F63778B52ED@employees.org> <5C7C04EC-0B62-4E4E-88D0-5C59ADA26AA0@cisco.com> <6192484F-7FCB-4BA7-A7A0-256D66218B88@cisco.com> <64DCFB07-223F-4470-AC25-8353C32AC7A6@employees.org>  <67276E5D-6F73-45CB-A103-8407A6E78DEC@employees.org>   
To: David Hanes 
X-Mailer: Apple Mail (2.1283)
Cc: dispatch@ietf.org
Subject: Re: [dispatch] I-D Action: draft-hanes-dispatch-fax-capability-07.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Jan 2013 21:49:29 -0000

--Apple-Mail=_B8D1DDD5-D97F-4774-9373-E20643390AFF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I'm going to restrict my attention to the gazallions of fax machines =
connected to the PSTN, since I think we're agreed that's the only real =
use case.

Also, I'm not disputing that the draft describes a way to denote =
probable fax calls from other calls - your example below is perfectly =
fine.

I'm a SMB and I have business cards printed up for my employees.  They =
either have one number on them for all of an employee's calls or a =
separate number for fax calls.

If they have one number, then I still don't see how to distinguish =
between a probable fax call and a probable voice call.  Should a call =
get routed to an employee on a UA that is not capable of dealing with =
fax, they'll probably transfer the call to voice mail since most =
messaging systems will take the fax call and render it as an email =
attachment in their unified mailbox.

If they have a separate number, then the server can make a rational =
routing decision.  There are several ways to do that, and this draft is =
one of them.

If you implement the draft, then there is code to write on the server =
and on the UA to implement the preference.  Then configure the UA to say =
that it would like to accept fax calls.  Good, works great.

Otherwise, configure the server to route calls to the fax number(s) to a =
(set of) UA(s).  Done.

I view preferences as a way to express fairly dynamic policy, rather =
than static routing.

If the draft proceeds, I don't mind, it just seems like a lot of bother =
to solve either an unsolvable problem or a non-problem.

I'm sorry if I've sounded like a curmudgeon on this thread.  I've had my =
say and that's pretty much it.

Cary.

On Jan 21, 2013, at 8:51 AM, David Hanes wrote:

>=20
> On Jan 20, 2013, at 8:18 PM, Cary FitzGerald wrote:
>=20
>> Copying dispatch.
>>=20
>> You keep trying to tell me that fax is a widely used feature - trust =
me, I know that very well (and have the scars to prove it!).
>>=20
>> What I don't understand is how a preference helps.  If there were =
some way _a priori_ to determine that a call was likely to be a fax =
call, then OK. =20
>=20
>=20
> Yes, the cases we are interested in covering are from fax devices that =
originate the call knowing a priori that it is to be a fax call (e.g. =
fax servers). We've mentioned a few ways to make this determination. The =
simplest example again is an IP fax server. It knows the call it is =
sending out is ultimately going to be fax so the determination is easy. =
The fax server then simply tags its initial INVITE with the fax media =
feature tag expressing its preference for a fax capable termination. =
This all happens prior to any tone detection or re-INVITE.
>=20
>=20
>> But the example you present says precisely that you don't have any of =
that information - the INVITE for a call that has some fax content is =
indistinguishable from one that doesn't (as it should, calls can go =
between fax and voice content multiple times). =20
>=20
>=20
> Actually, Kevin says that we DO have that information in his first =
paragraph -=20
>=20
> "It is quite likely that such a small business would own one or more =
FAX machines, and when those are connected to the new PBX, their analog =
ports would be 'marked' as FAX ports. Any calls that they initiate would =
be marked as "FAX" calls on their way out of the PBX, due to the vast =
majority of them actually being FAX calls."
>=20
> The PBX knows that a fax machine is on a specific port. So, it can =
easily apply the fax media feature to that initial INVITE without having =
to wait for the re-INVITE, CNG, or some other mechanism later in the =
call.
>=20
> You say that "the INVITE for a call that has some fax content is =
indistinguishable from one that doesn't". I admit I may be missing your =
point but based on my understanding, the examples and text in this draft =
indicate otherwise. Let's see if we can agree on the following example. =
Here is a sample INVITE header for a voice call -=20
>=20
> INVITE sip:bob@biloxi.example.com SIP/2.0
>   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=3Dz9hG4bK74b43=

>   Max-Forwards: 70
>   From: Alice ;tag=3D9fxced76sl
>   To: Bob 
>   Call-ID: 3848276298220188511@atlanta.example.com
>=20
> 
>=20
> And here is the same example for a fax call. The SDP in both would be =
the same as they both start as a voice call, which I think we already =
agree on.
>=20
> INVITE sip:bob@biloxi.example.com SIP/2.0
>   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=3Dz9hG4bK74b43=

>   Max-Forwards: 70
>   From: Alice ;tag=3D9fxced76sl
>   To: Bob 
>   Accept-Contact: *;+sip.fax=3D"t38"
>   Call-ID: 3848276298220188511@atlanta.example.com
>=20
> 
>=20
> The sample headers for the fax call have the fax media feature tag =
(+sip.fax=3D"t38") in the Accept-Contact header while the voice does =
not. So, from this example, can we agree that the INVITE for a call that =
has some fax content is distinguishable from one that doesn't?=20
>=20
>=20
>> My only real request is to add some kind of logic to the draft on how =
one divines that a call is more likely to contain fax content than any =
other call.
>>=20
>> I don't think that this draft hurts anything, but I don't see how it =
helps.
>>=20
>> Cary.
>>=20
>> On Jan 20, 2013, at 4:48 AM, Kevin Fleming wrote:
>>=20
>>> You are absolutely correct; there are plenty of far more useful =
alternatives to T.38 FAX. In spite of that, it's used heavily, and will =
likely be so for the foreseeable future. A simple example of where this =
feature tag would be useful would be a small business replacing a TDM =
PBX with an IP PBX, and using SIP for connection to the PSTN and other =
businesses. It is quite likely that such a small business would own one =
or more FAX machines, and when those are connected to the new PBX, their =
analog ports would be 'marked' as FAX ports. Any calls that they =
initiate would be marked as "FAX" calls on their way out of the PBX, due =
to the vast majority of them actually being FAX calls. Doing so would =
actually indicate to any network elements in the path of that call that =
it is intended to be a FAX call as early as that information is =
available (long before CNG or other inband negotiation would begin, =
which is much too late for many use cases).
>>>=20
>>> That describes how it could be applied; as to how it could be =
useful, take the example of auto-discrimination of inbound calls to =
extensions on a PBX. Many PBXes do this today, so that users of the PBX =
can publish a single phone number for both voice and FAX calls. The =
implementation of this is rather ugly, though, the PBX has to spy on the =
media path to listen for CNG after the call is answered so it can =
redirect the call to a FAX endpoint. This works acceptably well when the =
user is not at their desk and the call lands at their voicemail, but =
it's inelegant when they are at their desk and their phone rings. They =
get interrupted, answer the call, say "Hello?" a few times, and then =
hear a short blip of CNG before the is dropped from their handset. It is =
even less elegant when a PBX user has 'call-forward-no-answer' to =
someone else in their team; now the FAX call rings for 6-7 rings before =
being answered, only to again be pulled away. As another complication, =
auto-discrimination effectively disables the use of V.34 FAX, because in =
that mode the *receiving* FAX endpoint is responsible for initiating the =
protocol negotiation (by emitting ANSam), which can't be done if the =
call wasn't answered by a FAX endpoint. The result of this is that even =
if both FAX endpoints are V.34 capable, the FAX transaction will use =
older/slower/less reliable modem protocols because the calling =
endpoint's state machine will have passed the 'point of no return' for =
V.34 negotiation by the time the call is redirected.
>>>=20
>>> On the conceptual level, I think we're all in agreement that FAX is =
a terrible mechanism for document transmission and that there are far =
more effective (and less expensive) mechanisms available. Unfortunately, =
there are tens of milllions (if not hundreds of millions) of FAX =
machines deployed and they are used every day for billions of document =
transmissions. As the voice networks of the world move to IP and SIP, =
there is a need to provide FAX call success rates comparable to what the =
TDM networks provided.
>>>=20
>>>=20
>>>=20
>>>=20
>>> On Sat, Jan 19, 2013 at 10:16 PM, Cary FitzGerald =
 wrote:
>>>=20
>>> On Jan 19, 2013, at 4:32 AM, Kevin Fleming wrote:
>>>=20
>>>> Actually, the primary use case for this feature tag is *not* =
expected to be PSTN-originated calls, but instead FAX-capable SIP =
endpoints
>>>=20
>>> I am skeptical that this is an important use case.  Why would SIP =
endpoint generate a T.38 call when there are so many *much* better =
alternatives?
>>>=20
>>>> (or non-SIP endpoints attached to a SIP gateway that has been =
administratively configured to be aware of their FAX capabilities).
>>>=20
>>> That's what I meant by a PSTN call - the gateway is acting as a =
proxy for the PSTN-connected fax machine.
>>>=20
>>>> In these cases, the endpoint or its immediate gateway will have =
explicit knowledge that the call being placed by the endpoint is for the =
purpose of a FAX transmission. If the T.38 recommendation had been =
designed differently, and INVITE carrying only a T.38 SDP was an =
acceptable option, then this feature tag would be unnecessary. =
Unfortunately (and for legitimate reasons) that is not the case, and the =
SIP Forum's FOIP task group came to the conclusion that providing a =
mechanism for the endpoint to explicitly indicate its intent to initiate =
a FAX transaction would be useful.
>>>>=20
>>> However, I still am baffled about what logic one would use to =
determine that a call was more likely to carry fax than anything else.  =
That's all I'm asking - given that a fax call is in general =
indistinguishable from any other call how would someone make the =
determination that any specific call should get special treatment?
>>>=20
>>> I don't think that this draft is harmful, so if itproceeds I don't =
mind.  Not to be rude, I just don't think that it is useful.  I'm not =
suggesting that fax is not important, I just don't understand how the =
draft helps.  The fact that you can't express T.38 in sdp is a canard - =
you wouldn't know whether that was important or not doesn't matter when =
an INVITE arrives, because you'd only know about CNG well after the =
media path was established - hundreds of milliseconds later.  I don't =
know what logic you'd use to figure out a m=3D line or this prefs =
decision.
>>>=20
>>> Cary.
>>>>=20
>>>> On Fri, Jan 18, 2013 at 11:03 PM, Cary FitzGerald =
 wrote:
>>>> Hmmm.  I _thought_ i was subscribed to dispatch, but apparently =
there's a problem there.  I'll try to figure this out tomorrow.
>>>>=20
>>>> On Jan 18, 2013, at 7:29 PM, David Hanes wrote:
>>>>=20
>>>> > Hi Cary,
>>>> >
>>>> > I just wanted to follow-up once since we had not heard back from =
you and we are facing a deadline. This draft is on the agenda of the =
1/24 IESG telechat and we want to make sure that we have addressed your =
concerns.
>>>> >
>>>> > Thanks,
>>>> > David
>>>> >
>>>> >
>>>> > On Jan 16, 2013, at 11:56 PM, David Hanes wrote:
>>>> >
>>>> >> Hi Cary,
>>>> >>
>>>> >> Thanks for the comments. I am taking this off-list as I needed =
some clarification on a few things; some of which may have been =
addressed already through the various discussions on DISPATCH that have =
already taken place prior to Last Call.  Some inline comments...
>>>> >>
>>>> >> Regards,
>>>> >> David
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Jan 16, 2013, at 1:36 PM, Cary FitzGerald wrote:
>>>> >>
>>>> >>> I don't understand use case for this draft.  Unless I'm missing =
something, it helps to solve a very small corner case.
>>>> >>>
>>>> >>> For the IP-UA to UA case, it seems very unlikely to be useful.  =
Of course someone _could_ construct a UA that sends T.38, but why bother =
when SMTP or mumble is so much less trouble.  So I don't see an actual =
problem here.
>>>> >>
>>>> >> Admittedly, fax is that evil which will never die but actually =
this draft addresses a very real problem that has been under discussion =
by the FoIP Task Group of the SIP Forum for a couple of years. They =
concluded that the ability to select SIP endpoints for session =
termination based on the need for fax support by the calling endpoint =
would be very useful. This draft is doing nothing more than registering =
a new media feature tag (like audio, video, data, text, etc.) that was =
omitted earlier.
>>>> >>
>>>> No argument that fax is the undead, stabbed in the heart many =
times, still stumbling forward.
>>>>=20
>>>> >>>
>>>> >>> For the PSTN-UA to UA case, as the draft points out, there is =
no way to predict whether fax is going to be part of the call.  It's =
certainly true that increasing the probability of successfully handling =
a media stream, but I don't know how to figure out a priori how to set =
the balance between capabilities, convenience and whatever else the =
user's preferences are trying to tell us.
>>>> >>>
>>>> >>> If the call is routed to BOB (Big Old Business), then I'd kind =
of expect that by administrative policy, the BOB administrators would =
set a routing policy if some of the incoming PSTN numbers were fax banks =
to route to fax capable UAs.  You _could_ solve the problem with =
preferences, but that seems like a lot of unnecessary nuance.  Routing =
policy is a hammer, for sure, but it's simple and works for this case.
>>>> >>
>>>> >> Yes, routing policy can work in this case but in other cases it =
cannot. This draft provides a broader solution and encompasses use cases =
where multiple UAs are registered for a single number but only a certain =
one can handle fax media.
>>>>=20
>>>> Of course, it is possible that BOB has UAs that are not always =
accessible, and that having a preference is that is dynamically updated =
is useful, but operationally, I don't see this actually happening.
>>>> >>
>>>> >>>
>>>> >>> If the call is routed to Bob Regular Guy, and assuming Alice =
can predict the preferences for that particular call (outside of any =
other preferences), then the draft solves an actual problem.
>>>> >>>
>>>> >>> I think that the draft would be improved if the authors could =
add some words about how Alice would calculate a preference.
>>>> >>
>>>> >> The main use case here would involve Alice initiating fax calls =
from a fax server or from a DID fronted by a proxy. In either of these =
cases, the fax media feature tag is appended to the INVITE. Can you =
clarify what you mean by "calculate a preference" as Alice is the =
initiator and ascertaining that the call is fax would not be =
complicated?
>>>> >>
>>>> >>
>>>> Sorry if I was being obscure.
>>>>=20
>>>> An INVITE carries whatever information it carries.  What =
information would you use to assert that for _this call_ the INVITE =
should be routed this way versus that way?  If you buy my argument that =
this is a call that is originated in the PSTN, then you have an =
originating number and terminating number.  If this is what you know, =
what logic do you see filling in here:
>>>>=20
>>>> if (originating_number =3D=3D condition) then
>>>>         if (terminating_number =3D=3D condition)
>>>>                 foo;
>>>>         else
>>>>                 bar;
>>>> else
>>>>         if (terminating_number =3D=3D condition)
>>>>                 blatz;
>>>>         else
>>>>                 buzz;
>>>>=20
>>>> I'm not disputing that there is value in increasing the probability =
of successfully terminating a fax call, I just don't know how to do it.  =
What I'm asking for is a clue how.
>>>>=20
>>>> You can argue that my issues should not be in a protocol =
specification, but in this case, if I were a product manager, I wouldn't =
know how to assign a non-zero priority to this feature.  My point is =
what I said before.  If you could provide some logic of how you would =
decide how to route any particular call, it would help me understand how =
this draft helps the cause.
>>>>=20
>>>> Cary.
>>>> >>>
>>>> >>> Cary.
>>>> >>>
>>>> >>> On Jan 15, 2013, at 2:12 PM, internet-drafts@ietf.org wrote:
>>>> >>>
>>>> >>>>
>>>> >>>> A New Internet-Draft is available from the on-line =
Internet-Drafts directories.
>>>> >>>>
>>>> >>>>
>>>> >>>>    Title           : Indicating Fax over IP Capability in the =
Session Initiation Protocol (SIP)
>>>> >>>>    Author(s)       : David Hanes
>>>> >>>>                       Gonzalo Salgueiro
>>>> >>>>                       Kevin P. Fleming
>>>> >>>>    Filename        : =
draft-hanes-dispatch-fax-capability-07.txt
>>>> >>>>    Pages           : 9
>>>> >>>>    Date            : 2013-01-15
>>>> >>>>
>>>> >>>> Abstract:
>>>> >>>> This document defines and registers with IANA the new 'fax' =
media
>>>> >>>> feature tag for use with SIP.  Currently, fax calls are
>>>> >>>> indistinguishable from voice at call initiation.  =
Consequently, fax
>>>> >>>> calls can be routed to SIP user agents that are not fax =
capable.  A
>>>> >>>> 'fax' media feature tag implemented in conjunction with caller
>>>> >>>> preferences allows for more accurate fax call routing.
>>>> >>>>
>>>> >>>>
>>>> >>>> The IETF datatracker status page for this draft is:
>>>> >>>> =
https://datatracker.ietf.org/doc/draft-hanes-dispatch-fax-capability
>>>> >>>>
>>>> >>>> There's also a htmlized version available at:
>>>> >>>> =
http://tools.ietf.org/html/draft-hanes-dispatch-fax-capability-07
>>>> >>>>
>>>> >>>> A diff from the previous version is available at:
>>>> >>>> =
http://www.ietf.org/rfcdiff?url2=3Ddraft-hanes-dispatch-fax-capability-07
>>>> >>>>
>>>> >>>>
>>>> >>>> Internet-Drafts are also available by anonymous FTP at:
>>>> >>>> ftp://ftp.ietf.org/internet-drafts/
>>>> >>>>
>>>> >>>> _______________________________________________
>>>> >>>> I-D-Announce mailing list
>>>> >>>> I-D-Announce@ietf.org
>>>> >>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>>> >>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>>> >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>> >>>
>>>> >>> _______________________________________________
>>>> >>> dispatch mailing list
>>>> >>> dispatch@ietf.org
>>>> >>> https://www.ietf.org/mailman/listinfo/dispatch
>>>> >>
>>>>=20
>>>>=20
>>>=20
>>>=20
>>=20
>=20


--Apple-Mail=_B8D1DDD5-D97F-4774-9373-E20643390AFF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

I'm =
going to restrict my attention to the gazallions of fax machines =
connected to the PSTN, since I think we're agreed that's the only real =
use case.

Also, I'm not disputing that the draft =
describes a way to denote probable fax calls from other calls - your =
example below is perfectly fine.

I'm a SMB and I =
have business cards printed up for my employees.  They either have =
one number on them for all of an employee's calls or a separate number =
for fax calls.

If they have one number, then I still =
don't see how to distinguish between a probable fax call and a probable =
voice call.  Should a call get routed to an employee on a UA that =
is not capable of dealing with fax, they'll probably transfer the call =
to voice mail since most messaging systems will take the fax call and =
render it as an email attachment in their unified =
mailbox.

If they have a separate number, then =
the server can make a rational routing decision.  There are several =
ways to do that, and this draft is one of =
them.

If you implement the draft, then there is =
code to write on the server and on the UA to implement the preference. =
 Then configure the UA to say that it would like to accept fax =
calls.  Good, works great.

Otherwise, =
configure the server to route calls to the fax number(s) to a (set of) =
UA(s).  Done.

I view preferences as a way =
to express fairly dynamic policy, rather than static =
routing.

If the draft proceeds, I don't mind, =
it just seems like a lot of bother to solve either an unsolvable problem =
or a non-problem.

I'm sorry if I've sounded =
like a curmudgeon on this thread.  I've had my say and that's =
pretty much =
it.

Cary.

On Jan =
21, 2013, at 8:51 AM, David Hanes wrote:


On Jan 20, 2013, =
at 8:18 PM, Cary FitzGerald wrote:



But the example you =
present says precisely that you don't have any of that information - the =
INVITE for a call that has some fax content is indistinguishable from =
one that doesn't (as it should, calls can go between fax and voice =
content multiple times). =
 


Actually=
, Kevin says that we DO have that information in his first paragraph =
- 

"It is quite likely that such a small business would own =
one or more FAX machines, and when those are connected to the new PBX, =
their analog ports would be 'marked' as FAX ports. Any calls that they =
initiate would be marked as "FAX" calls on their way out of the PBX, due =
to the vast majority of them actually being FAX calls."

The PBX =
knows that a fax machine is on a specific port. So, it can easily apply =
the fax media feature to that initial INVITE without having to wait for =
the re-INVITE, CNG, or some other mechanism later in the =
call.

You say that "the INVITE for a call that has some fax =
content is indistinguishable from one that doesn't". I admit I may be =
missing your point but based on my understanding, the examples and text =
in this draft indicate otherwise. Let's see if we can agree on the =
following example. Here is a sample INVITE header for a voice call =
- 

INVITE sip:bob@biloxi.example.com SI=
P/2.0
  Via: SIP/2.0/TCP =
client.atlanta.example.com:5060;branch=3Dz9hG4bK74b43
  Max-F=
orwards: 70
  From: Alice <sip:alice@atlanta.example.com&g=
t;;tag=3D9fxced76sl
  To: Bob <sip:bob@biloxi.example.com>
=
  Call-ID: 384827629822018851=
1@atlanta.example.com

<snip>

And here is the =
same example for a fax call. The SDP in both would be the same as they =
both start as a voice call, which I think we already agree =
on.

INVITE sip:bob@biloxi.example.com SI=
P/2.0
  Via: SIP/2.0/TCP =
client.atlanta.example.com:5060;branch=3Dz9hG4bK74b43
  Max-F=
orwards: 70
  From: Alice <sip:alice@atlanta.example.com&g=
t;;tag=3D9fxced76sl
  To: Bob <sip:bob@biloxi.example.com>
=
  Accept-Contact: =
*;+sip.fax=3D"t38"
  Call-ID: 384827629822018851=
1@atlanta.example.com

<snip>

The sample headers =
for the fax call have the fax media feature tag (+sip.fax=3D"t38") in =
the Accept-Contact header while the voice does not. So, from this =
example, can we agree that the INVITE for a call that has some fax =
content is distinguishable from one that =
doesn't? 


My only real request is to =
add some kind of logic to the draft on how one divines that a call is =
more likely to contain fax content than any other =
call.

I don't think that this draft hurts =
anything, but I don't see how it =
helps.

Cary.

On Jan 20, =
2013, at 4:48 AM, Kevin Fleming wrote:

You are absolutely correct; there are plenty of far more =
useful alternatives to T.38 FAX. In spite of that, it's used heavily, =
and will likely be so for the foreseeable future. A simple example of =
where this feature tag would be useful would be a small business =
replacing a TDM PBX with an IP PBX, and using SIP for connection to the =
PSTN and other businesses. It is quite likely that such a small business =
would own one or more FAX machines, and when those are connected to the =
new PBX, their analog ports would be 'marked' as FAX ports. Any calls =
that they initiate would be marked as "FAX" calls on their way out of =
the PBX, due to the vast majority of them actually being FAX calls. =
Doing so would actually indicate to any network elements in the path of =
that call that it is intended to be a FAX call as early as that =
information is available (long before CNG or other inband negotiation =
would begin, which is much too late for many use cases).


That describes how it could be applied; as to =
how it could be useful, take the example of auto-discrimination of =
inbound calls to extensions on a PBX. Many PBXes do this today, so that =
users of the PBX can publish a single phone number for both voice and =
FAX calls. The implementation of this is rather ugly, though, the PBX =
has to spy on the media path to listen for CNG after the call is =
answered so it can redirect the call to a FAX endpoint. This works =
acceptably well when the user is not at their desk and the call lands at =
their voicemail, but it's inelegant when they are at their desk and =
their phone rings. They get interrupted, answer the call, say "Hello?" a =
few times, and then hear a short blip of CNG before the is dropped from =
their handset. It is even less elegant when a PBX user has =
'call-forward-no-answer' to someone else in their team; now the FAX call =
rings for 6-7 rings before being answered, only to again be pulled away. =
As another complication, auto-discrimination effectively disables the =
use of V.34 FAX, because in that mode the *receiving* FAX endpoint is =
responsible for initiating the protocol negotiation (by emitting ANSam), =
which can't be done if the call wasn't answered by a FAX endpoint. The =
result of this is that even if both FAX endpoints are V.34 capable, the =
FAX transaction will use older/slower/less reliable modem protocols =
because the calling endpoint's state machine will have passed the 'point =
of no return' for V.34 negotiation by the time the call is =
redirected.



On the conceptual level, I =
think we're all in agreement that FAX is a terrible mechanism for =
document transmission and that there are far more effective (and less =
expensive) mechanisms available. Unfortunately, there are tens of =
milllions (if not hundreds of millions) of FAX machines deployed and =
they are used every day for billions of document transmissions. As the =
voice networks of the world move to IP and SIP, there is a need to =
provide FAX call success rates comparable to what the TDM networks =
provided.






On Sat, Jan 19, =
2013 at 10:16 PM, Cary FitzGerald <caryfitz@employees.org> wrote:



On Jan =
19, 2013, at 4:32 AM, Kevin Fleming wrote:


Actually, the primary use =
case for this feature tag is *not* expected to be PSTN-originated calls, =
but instead FAX-capable SIP =
endpoints

I am skeptical that =
this is an important use case.  Why would SIP endpoint generate a =
T.38 call when there are so many *much* better alternatives?



(or =
non-SIP endpoints attached to a SIP gateway that has been =
administratively configured to be aware of their FAX capabilities). =




That's what I meant by a PSTN call - the gateway is =
acting as a proxy for the PSTN-connected fax machine.

In these =
cases, the endpoint or its immediate gateway will have explicit =
knowledge that the call being placed by the endpoint is for the purpose =
of a FAX transmission. If the T.38 recommendation had been designed =
differently, and INVITE carrying only a T.38 SDP was an acceptable =
option, then this feature tag would be unnecessary. Unfortunately (and =
for legitimate reasons) that is not the case, and the SIP Forum's FOIP =
task group came to the conclusion that providing a mechanism for the =
endpoint to explicitly indicate its intent to initiate a FAX transaction =
would be useful.




However, I still =
am baffled about what logic one would use to determine that a call was =
more likely to carry fax than anything else.  That's all I'm asking =
- given that a fax call is in general indistinguishable from any other =
call how would someone make the determination that any specific call =
should get special treatment?



I don't think that this draft is harmful, so if =
itproceeds I don't mind.  Not to be rude, I just don't think that =
it is useful.  I'm not suggesting that fax is not important, I just =
don't understand how the draft helps.  The fact that you can't =
express T.38 in sdp is a canard - you wouldn't know whether that was =
important or not doesn't matter when an INVITE arrives, because you'd =
only know about CNG well after the media path was established - hundreds =
of milliseconds later.  I don't know what logic you'd use to figure =
out a m=3D line or this prefs decision.



Cary.

On Fri, Jan 18, =
2013 at 11:03 PM, Cary FitzGerald <caryfitz@employees.org> wrote:



Hmmm.  I _thought_ i was subscribed to =
dispatch, but apparently there's a problem there.  I'll try to =
figure this out tomorrow.






On Jan 18, 2013, at 7:29 PM, David Hanes wrote:



> Hi Cary,

>

> I just wanted to follow-up once since we had not heard back from =
you and we are facing a deadline. This draft is on the agenda of the =
1/24 IESG telechat and we want to make sure that we have addressed your =
concerns.



>

> Thanks,

> David

>

>

> On Jan 16, 2013, at 11:56 PM, David Hanes wrote:

>

>> Hi Cary,

>>

>> Thanks for the comments. I am taking this off-list as I needed =
some clarification on a few things; some of which may have been =
addressed already through the various discussions on DISPATCH that have =
already taken place prior to Last Call.  Some inline =
comments...



>>

>> Regards,

>> David

>>

>>

>>

>>

>> On Jan 16, 2013, at 1:36 PM, Cary FitzGerald wrote:

>>

>>> I don't understand use case for this draft.  Unless =
I'm missing something, it helps to solve a very small corner case.

>>>

>>> For the IP-UA to UA case, it seems very unlikely to be =
useful.  Of course someone _could_ construct a UA that sends T.38, =
but why bother when SMTP or mumble is so much less trouble.  So I =
don't see an actual problem here.



>>

>> Admittedly, fax is that evil which will never die but actually =
this draft addresses a very real problem that has been under discussion =
by the FoIP Task Group of the SIP Forum for a couple of years. They =
concluded that the ability to select SIP endpoints for session =
termination based on the need for fax support by the calling endpoint =
would be very useful. This draft is doing nothing more than registering =
a new media feature tag (like audio, video, data, text, etc.) that was =
omitted earlier.



>>


No argument that fax is the undead, stabbed in the heart many =
times, still stumbling forward.




>>>

>>> For the PSTN-UA to UA case, as the draft points out, there =
is no way to predict whether fax is going to be part of the call. =
 It's certainly true that increasing the probability of =
successfully handling a media stream, but I don't know how to figure out =
a priori how to set the balance between capabilities, convenience and =
whatever else the user's preferences are trying to tell us.



>>>

>>> If the call is routed to BOB (Big Old Business), then I'd =
kind of expect that by administrative policy, the BOB administrators =
would set a routing policy if some of the incoming PSTN numbers were fax =
banks to route to fax capable UAs.  You _could_ solve the problem =
with preferences, but that seems like a lot of unnecessary nuance. =
 Routing policy is a hammer, for sure, but it's simple and works =
for this case.



>>

>> Yes, routing policy can work in this case but in other cases it =
cannot. This draft provides a broader solution and encompasses use cases =
where multiple UAs are registered for a single number but only a certain =
one can handle fax media.






Of course, it is possible that BOB has UAs that are not always =
accessible, and that having a preference is that is dynamically updated =
is useful, but operationally, I don't see this actually happening.


>>

>>>

>>> If the call is routed to Bob Regular Guy, and assuming =
Alice can predict the preferences for that particular call (outside of =
any other preferences), then the draft solves an actual problem.

>>>

>>> I think that the draft would be improved if the authors =
could add some words about how Alice would calculate a preference.

>>

>> The main use case here would involve Alice initiating fax calls =
from a fax server or from a DID fronted by a proxy. In either of these =
cases, the fax media feature tag is appended to the INVITE. Can you =
clarify what you mean by "calculate a preference" as Alice is the =
initiator and ascertaining that the call is fax would not be =
complicated?



>>

>>


Sorry if I was being obscure.



An INVITE carries whatever information it carries.  What =
information would you use to assert that for _this call_ the INVITE =
should be routed this way versus that way?  If you buy my argument =
that this is a call that is originated in the PSTN, then you have an =
originating number and terminating number.  If this is what you =
know, what logic do you see filling in here:





if (originating_number =3D=3D condition) then

        if (terminating_number =3D=3D condition)

                foo;

        else

                bar;

else

        if (terminating_number =3D=3D condition)

                blatz;

        else

                buzz;



I'm not disputing that there is value in increasing the probability of =
successfully terminating a fax call, I just don't know how to do it. =
 What I'm asking for is a clue how.



You can argue that my issues should not be in a protocol specification, =
but in this case, if I were a product manager, I wouldn't know how to =
assign a non-zero priority to this feature.  My point is what I =
said before.  If you could provide some logic of how you would =
decide how to route any particular call, it would help me understand how =
this draft helps the cause.





Cary.


>>>

>>> Cary.

>>>

>>> On Jan 15, 2013, at 2:12 PM, internet-drafts@ietf.org wrote:

>>>

>>>>

>>>> A New Internet-Draft is available from the on-line =
Internet-Drafts directories.

>>>>

>>>>

>>>>    Title           : =
Indicating Fax over IP Capability in the Session Initiation Protocol =
(SIP)

>>>>    Author(s)       : David =
Hanes

>>>>                 =
      Gonzalo Salgueiro

>>>>                 =
      Kevin P. Fleming

>>>>    Filename        : =
draft-hanes-dispatch-fax-capability-07.txt

>>>>    Pages           : =
9

>>>>    Date           =
 : 2013-01-15

>>>>

>>>> Abstract:

>>>> This document defines and registers with IANA the new =
'fax' media

>>>> feature tag for use with SIP.  Currently, fax =
calls are

>>>> indistinguishable from voice at call initiation. =
 Consequently, fax

>>>> calls can be routed to SIP user agents that are not fax =
capable.  A

>>>> 'fax' media feature tag implemented in conjunction with =
caller

>>>> preferences allows for more accurate fax call =
routing.

>>>>

>>>>

>>>> The IETF datatracker status page for this draft is:

>>>> https://datatracker.ietf.org/doc/draft-hanes-dispatch-fa=
x-capability

>>>>

>>>> There's also a htmlized version available at:

>>>> http://tools.ietf.org/html/draft-hanes-dispatch-fax-capa=
bility-07

>>>>

>>>> A diff from the previous version is available at:

>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-hanes-dispatch-=
fax-capability-07

>>>>

>>>>

>>>> Internet-Drafts are also available by anonymous FTP =
at:

>>>> ftp://ftp.ietf.org/internet-drafts/

>>>>

>>>> _______________________________________________

>>>> I-D-Announce mailing list

>>>> I-D-Announce@ietf.org

>>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>>> Internet-Draft directories: http://www.ietf.org/shadow.html

>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

>>>

>>> _______________________________________________

>>> dispatch mailing list

>>> dispatch@ietf.org

>>> https://www.ietf.org/mailman/listinfo/dispatch

>>










=




=

--Apple-Mail=_B8D1DDD5-D97F-4774-9373-E20643390AFF--

From worley@shell01.TheWorld.com  Mon Jan 21 16:30:03 2013
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C6121F8472 for ; Mon, 21 Jan 2013 16:30:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.98
X-Spam-Level: 
X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnnNkR+El-ba for ; Mon, 21 Jan 2013 16:30:02 -0800 (PST)
Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id A5B7021F845A for ; Mon, 21 Jan 2013 16:30:02 -0800 (PST)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r0M0TMXi030831; Mon, 21 Jan 2013 19:29:24 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r0M0TLKi199262; Mon, 21 Jan 2013 19:29:22 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r0M0TLTu188731; Mon, 21 Jan 2013 19:29:21 -0500 (EST)
Date: Mon, 21 Jan 2013 19:29:21 -0500 (EST)
Message-Id: <201301220029.r0M0TLTu188731@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: "Cullen Jennings (fluffy)" 
In-reply-to:  (fluffy@cisco.com)
References: <50ABBAD6.9050103@gmail.com> 
Cc: dispatch@ietf.org
Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Jan 2013 00:30:03 -0000

> From: "Cullen Jennings (fluffy)" 
> 
> I would like to point out that several of my comments, including the
> one about IPR, had never been addressed. 

It would be very helpful to me if you could give us a listing of which
specific comments and concerns have not been addressed to your
satisfaction.  You could do this by referencing the archived e-mail
messages, but I would be better informed if you copied and edited them
to remove parts that you think have been properly addressed, updated
the wording to fix any ambiguities that have been discovered, and
clarified the arguments in whatever ways have been revealed in the
following discussions.  As things stand now, I'd have to review all of
your messages for the past several months, and cross-correlate them
with all of the discussions, before I could start to think about your
objections...

Dale

From Ales.Sliber@telekom.si  Thu Jan 24 23:01:55 2013
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED88821F85C0 for ; Thu, 24 Jan 2013 23:01:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.449
X-Spam-Level: 
X-Spam-Status: No, score=-0.449 tagged_above=-999 required=5 tests=[AWL=-0.566, BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1kAjNIJPOa7 for ; Thu, 24 Jan 2013 23:01:55 -0800 (PST)
Received: from smtp2.telekom.si (smtp2.telekom.si [193.77.55.38]) by ietfa.amsl.com (Postfix) with ESMTP id 477DD21F848B for ; Thu, 24 Jan 2013 23:01:54 -0800 (PST)
Received: from srexch14.ts.telekom.si (cas.ts.telekom.si) by srmps02.ts.telekom.si (Clearswift SMTPRS 5.5.0) with ESMTP id  for ; Fri, 25 Jan 2013 08:01:53 +0100
Received: from SREXDB14.ts.telekom.si ([169.254.4.68]) by srexch14.ts.telekom.si ([192.168.27.26]) with mapi id 14.02.0247.003; Fri, 25 Jan 2013 08:01:52 +0100
From: =?iso-8859-2?Q?=A9liber_Ale=B9?= 
To: "dispatch@ietf.org" 
Thread-Topic: RFC 3398 - problems with ISUP cause mapping
Thread-Index: Ac36L/Ouvi96ppcBSLCYfqPfGqmxGAAl8IiQAACHohA=
Date: Fri, 25 Jan 2013 07:01:52 +0000
Message-ID: <26300ECDDED68545A78AAC3D98640BF3A157E82F@srexdb14.ts.telekom.si>
Accept-Language: sl-SI, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.13.3.86]
Content-Type: multipart/alternative; boundary="_000_26300ECDDED68545A78AAC3D98640BF3A157E82Fsrexdb14tstelek_"
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 25 Jan 2013 06:14:14 -0800
Subject: Re: [dispatch] RFC 3398 - problems with ISUP cause mapping
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jan 2013 07:01:56 -0000

--_000_26300ECDDED68545A78AAC3D98640BF3A157E82Fsrexdb14tstelek_
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

Hi,

I'm mobile core network engineer working a lot with ISUP to SIP mapping and=
 vice versa.
I come up to an unsolved problem with mapping the traffic from ISUP to SIP =
and back to ISUP.

>From RFC 3398:

ISUP-SIP
   18 no user responding                   408 Request Timeout
   19 no answer from the user              480 Temporarily unavailable
   20 subscriber absent                    480 Temporarily unavailable

SIP-ISUP:
   408 Request timeout                  102 Recovery on timer expiry
   480 Temporarily unavailable           18 No user responding

So if I send from ISUP REL-19 and this trafic wents maps to SIP and then ba=
ck to ISUP, I receive on the other side ISUP REL-18.
There is the same story with ISUP REL18 mappng to SIP and back to ISUP - I =
will receive ISUP REL.102?!

Can you help me with this isue. Is there any new RFC how to map this kind o=
f traffic?

Thank you,
BR Ales Sliber

Ale=B9 =A9liber
Core network engineer
Tel: +386-1-472-8482
W-mobile: www.mobitel.si
W-fix: www.telekom.si
Telekom Slovenije


--_000_26300ECDDED68545A78AAC3D98640BF3A157E82Fsrexdb14tstelek_
Content-Type: text/html; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable











Hi,


 


I'm mobile core network engineer working a lot with ISUP t=
o SIP mapping and vice versa.


I come up to an unsolved problem with mapping the traffic =
from ISUP to SIP and back to ISUP.


 


From RFC 3398:


 


ISUP-SIP


   
18 no user responding         =
          408 Request Timeout<=
/span>


   19 no answer=
 from the user          &=
nbsp;   480 Temporarily unavailable<=
/p>

   20 subscriber absent    &=
nbsp;           &nbs=
p;   480 Temporarily unavailable


   


SIP-ISUP:


   408 Request =
timeout           &n=
bsp;      102 Recovery on timer expiry=



   480 Temporar=
ily unavailable          =
 18 No user responding


 


So if I send from ISUP REL-19 and this trafic wents maps t=
o SIP and then back to ISUP, I receive on the other side ISUP REL-18.<=
/o:p>


There is the same story with ISUP REL18 mappng to SIP and =
back to ISUP – I will receive ISUP REL.102?!


 


Can you help me with this isue. Is there any new RFC how t=
o map this kind of traffic?


 


Thank you,


BR Ales Sliber


 


=
Ale=B9 =A9liber


Co=
re network engineer


T=
el:
+386-1-472-8482


W=
-mobile:
www.mobit=
el.si



W=
-fix:
www.telek=
om.si


Telekom
Slovenije=



 






--_000_26300ECDDED68545A78AAC3D98640BF3A157E82Fsrexdb14tstelek_--

From christer.holmberg@ericsson.com  Fri Jan 25 06:17:44 2013
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851B721F87FA for ; Fri, 25 Jan 2013 06:17:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.098
X-Spam-Level: 
X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgDRiS+r+Aeq for ; Fri, 25 Jan 2013 06:17:43 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8550D21F867A for ; Fri, 25 Jan 2013 06:17:42 -0800 (PST)
X-AuditID: c1b4fb2d-b7f316d0000028db-ba-51029405d694
Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 0D.A0.10459.50492015; Fri, 25 Jan 2013 15:17:41 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.195]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0318.004; Fri, 25 Jan 2013 15:17:40 +0100
From: Christer Holmberg 
To: =?iso-8859-2?Q?=A9liber_Ale=B9?= , "dispatch@ietf.org" 
Thread-Topic: RFC 3398 - problems with ISUP cause mapping
Thread-Index: Ac36L/Ouvi96ppcBSLCYfqPfGqmxGAAl8IiQAACHohAADzCpEA==
Date: Fri, 25 Jan 2013 14:17:40 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B0CA15E@ESESSMB209.ericsson.se>
References: <26300ECDDED68545A78AAC3D98640BF3A157E82F@srexdb14.ts.telekom.si>
In-Reply-To: <26300ECDDED68545A78AAC3D98640BF3A157E82F@srexdb14.ts.telekom.si>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.16]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B0CA15EESESSMB209ericsso_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+JvrS7rFKZAgyVr5S2mnb7EZLF00gJW ByaPJUt+Mnls3tHIHsAUxWWTkpqTWZZapG+XwJVxadditoKrSRUv999ia2B8ENHFyMEhIWAi 8aOxpouRE8gUk7hwbz0biC0kcIhRYtoaxS5GLiB7CaPEo8/L2EDq2QQsJLr/aYPUiAhkSCw+ 85wFxBYGCnfsWcIKEbeU6JxxiAnCdpLYs+4VO4jNIqAqMffeNUYQm1fAW+L5tUksELt8JSZP ew5WzyngJ7HwWyPYHEage76fWgMWZxYQl7j1ZD4TxJ0CEkv2nGeGsEUlXj7+xwphK0rsPNvO DFGfL9H25zw7xC5BiZMzn7BMYBSZhWTULCRls5CUQcT1JJ6dmgVla0ssW/iaGcLWlbj0cB0r svgCRvZVjOy5iZk56eWGmxiBcXNwy2/dHYynzokcYpTmYFES5w1zvRAgJJCeWJKanZpakFoU X1Sak1p8iJGJg1OqgbEgpr7c63PBL13/a30bGi/kL74Qe/WQY83B4009E+csV/D/bVew7mhR /5nQuk1v+uQWvvsRZBK683+YlMdWaQ1vF/X+Oj09rXklPHdCnj97Guqy23f9dVMjCY0z567r zXN+0Tfpz9Ur4hObPI9ZrLhz+O95/sA5Vho3Ci31PhrGptg1/1tj/UKJpTgj0VCLuag4EQBa ZXGfaQIAAA==
Subject: Re: [dispatch] RFC 3398 - problems with ISUP cause mapping
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jan 2013 14:17:44 -0000

--_000_7594FB04B1934943A5C02806D1A2204B0CA15EESESSMB209ericsso_
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

Hi,

There is no new RFC, but SDOs like ITU-T and 3GPP have specified mapping wh=
ich in some cases differs from the RFC.

Regards,

Christer

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal=
f Of =A9liber Ale=B9
Sent: 25. tammikuuta 2013 9:02
To: dispatch@ietf.org
Subject: Re: [dispatch] RFC 3398 - problems with ISUP cause mapping

Hi,

I'm mobile core network engineer working a lot with ISUP to SIP mapping and=
 vice versa.
I come up to an unsolved problem with mapping the traffic from ISUP to SIP =
and back to ISUP.

>From RFC 3398:

ISUP-SIP
   18 no user responding                   408 Request Timeout
   19 no answer from the user              480 Temporarily unavailable
   20 subscriber absent                    480 Temporarily unavailable

SIP-ISUP:
   408 Request timeout                  102 Recovery on timer expiry
   480 Temporarily unavailable           18 No user responding

So if I send from ISUP REL-19 and this trafic wents maps to SIP and then ba=
ck to ISUP, I receive on the other side ISUP REL-18.
There is the same story with ISUP REL18 mappng to SIP and back to ISUP - I =
will receive ISUP REL.102?!

Can you help me with this isue. Is there any new RFC how to map this kind o=
f traffic?

Thank you,
BR Ales Sliber

Ale=B9 =A9liber
Core network engineer
Tel: +386-1-472-8482
W-mobile: www.mobitel.si
W-fix: www.telekom.si
Telekom Slovenije


--_000_7594FB04B1934943A5C02806D1A2204B0CA15EESESSMB209ericsso_
Content-Type: text/html; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable











Hi,<=
/p>

 


There is no new RFC, b=
ut SDOs like ITU-T and 3GPP have specified mapping which in some cases diff=
ers from the RFC.


 


Regards,


 


Christer


 






From: dispatch=
-bounces@ietf.org [mailto:dispatch-bounces@ietf.org]
On Behalf Of =A9liber Ale=B9

Sent: 25. tammikuuta 2013 9:02

To: dispatch@ietf.org

Subject: Re: [dispatch] RFC 3398 - problems with ISUP cause mapping<=
o:p>






 


Hi,


 


I'm mobile core network engineer working a lot=
 with ISUP to SIP mapping and vice versa.


I come up to an unsolved problem with mapping =
the traffic from ISUP to SIP and back to ISUP.


 


From RFC 3398:


 


ISUP-SIP


  
18 no user responding    =
            &nb=
sp;  408 Request Timeout


   
19 no answer from the user   &=
nbsp;          480 Temporarily=
 unavailable


   20 subscriber absent  &=
nbsp;           &nbs=
p;     480 Temporarily unavailable

   



SIP-ISUP:


   
408 Request timeout    &n=
bsp;            =
; 102 Recovery on timer expiry


   
480 Temporarily unavailable   =
        18 No user responding


 


So if I send from ISUP REL-19 and this trafic =
wents maps to SIP and then back to ISUP, I receive on the other side ISUP R=
EL-18.


There is the same story with ISUP REL18 mappng=
 to SIP and back to ISUP – I will receive ISUP REL.102?!


 


Can you help me with this isue. Is there any n=
ew RFC how to map this kind of traffic?


 


Thank you,


BR Ales Sliber


 


Ale=B9 =A9liber


Core network engineer


Tel:
+386-1-472-8482


W-mobile:
www.mobitel.si



W-fix:
www.telekom.si


Telekom
Slovenije


 






--_000_7594FB04B1934943A5C02806D1A2204B0CA15EESESSMB209ericsso_--

From jim.calme@alcatel-lucent.com  Fri Jan 25 06:23:39 2013
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F06421F8953 for ; Fri, 25 Jan 2013 06:23:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.948
X-Spam-Level: 
X-Spam-Status: No, score=-9.948 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frOvHUszvaEV for ; Fri, 25 Jan 2013 06:23:38 -0800 (PST)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2FE21F81FE for ; Fri, 25 Jan 2013 06:23:37 -0800 (PST)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r0PEN2fH031468 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 25 Jan 2013 15:23:32 +0100
Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 25 Jan 2013 15:23:23 +0100
Received: from US70TWXCHMBA10.zam.alcatel-lucent.com ([169.254.4.41]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Fri, 25 Jan 2013 09:23:21 -0500
From: "Calme, James A (Jim)" 
To: Christer Holmberg , =?iso-8859-2?Q?=A9liber_Ale=B9?= , "dispatch@ietf.org" 
Thread-Topic: RFC 3398 - problems with ISUP cause mapping
Thread-Index: Ac36L/Ouvi96ppcBSLCYfqPfGqmxGAAl8IiQAACHohAADzCpEAAAKSbQ
Date: Fri, 25 Jan 2013 14:23:21 +0000
Message-ID: <7B8DC1AC12241143921AC7733AF3C17B1DF55878@US70TWXCHMBA10.zam.alcatel-lucent.com>
References: <26300ECDDED68545A78AAC3D98640BF3A157E82F@srexdb14.ts.telekom.si> <7594FB04B1934943A5C02806D1A2204B0CA15E@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0CA15E@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.5.27.18]
Content-Type: multipart/alternative; boundary="_000_7B8DC1AC12241143921AC7733AF3C17B1DF55878US70TWXCHMBA10z_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13
Subject: Re: [dispatch] RFC 3398 - problems with ISUP cause mapping
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jan 2013 14:23:39 -0000

--_000_7B8DC1AC12241143921AC7733AF3C17B1DF55878US70TWXCHMBA10z_
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

Please reference 3GPP TS 29.163, much work as been done on this document ov=
er the last couple years to address mapping concerns.

Jim

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal=
f Of Christer Holmberg
Sent: Friday, January 25, 2013 8:18 AM
To: =A9liber Ale=B9; dispatch@ietf.org
Subject: Re: [dispatch] RFC 3398 - problems with ISUP cause mapping

Hi,

There is no new RFC, but SDOs like ITU-T and 3GPP have specified mapping wh=
ich in some cases differs from the RFC.

Regards,

Christer

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal=
f Of =A9liber Ale=B9
Sent: 25. tammikuuta 2013 9:02
To: dispatch@ietf.org
Subject: Re: [dispatch] RFC 3398 - problems with ISUP cause mapping

Hi,

I'm mobile core network engineer working a lot with ISUP to SIP mapping and=
 vice versa.
I come up to an unsolved problem with mapping the traffic from ISUP to SIP =
and back to ISUP.

>From RFC 3398:

ISUP-SIP
   18 no user responding                   408 Request Timeout
   19 no answer from the user              480 Temporarily unavailable
   20 subscriber absent                    480 Temporarily unavailable

SIP-ISUP:
   408 Request timeout                  102 Recovery on timer expiry
   480 Temporarily unavailable           18 No user responding

So if I send from ISUP REL-19 and this trafic wents maps to SIP and then ba=
ck to ISUP, I receive on the other side ISUP REL-18.
There is the same story with ISUP REL18 mappng to SIP and back to ISUP - I =
will receive ISUP REL.102?!

Can you help me with this isue. Is there any new RFC how to map this kind o=
f traffic?

Thank you,
BR Ales Sliber

Ale=B9 =A9liber
Core network engineer
Tel: +386-1-472-8482
W-mobile: www.mobitel.si
W-fix: www.telekom.si
Telekom Slovenije


--_000_7B8DC1AC12241143921AC7733AF3C17B1DF55878US70TWXCHMBA10z_
Content-Type: text/html; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable











Please reference 3GPP TS 29.163, much work as been done on t=
his document over the last couple years to address mapping concerns.


 


Jim


 






From: dispatch-bounces@ie=
tf.org [mailto:dispatch-bounces@ietf.org]
On Behalf Of Christer Holmberg

Sent: Friday, January 25, 2013 8:18 AM

To: =A9liber Ale=B9; dispatch@ietf.org

Subject: Re: [dispatch] RFC 3398 - problems with ISUP cause mapping<=
o:p>






 


Hi,


 


There is no new RFC, but SDOs like ITU-T and 3GPP have specified mappi=
ng which in some cases differs from the RFC.


 


Regards,


 


Christer


 






From: dispatch-bounces@ie=
tf.org [mailto:dispatch-bounces@ietf.org]
On Behalf Of =A9liber Ale=B9

Sent: 25. tammikuuta 2013 9:02

To: dispatch@ietf.org

Subject: Re: [dispatch] RFC 3398 - problems with ISUP cause mapping<=
/span>






 


Hi,


 


I'm mobile core network engineer =
working a lot with ISUP to SIP mapping and vice versa.

I come up to an unsolved problem =
with mapping the traffic from ISUP to SIP and back to ISUP.


 


From RFC 3398:<=
/p>

 


ISUP-SIP

  
18 no user responding    =
            &nb=
sp;  408 Request Timeout


  
19 no answer from the user  &nbs=
p;           480 Temporar=
ily unavailable


   20 subscriber absent=
            &nb=
sp;       480 Temporarily unavailable<=
o:p>


  



SIP-ISUP:

  
408 Request timeout    =
;            &n=
bsp; 102 Recovery on timer expiry


  
480 Temporarily unavailable  &nb=
sp;        18 No user responding<=
/b>


 


So if I send from ISUP REL-19 and=
 this trafic wents maps to SIP and then back to ISUP, I receive on the othe=
r side ISUP REL-18.


There is the same story with ISUP=
 REL18 mappng to SIP and back to ISUP – I will receive ISUP REL.102?!=



 


Can you help me with this isue. I=
s there any new RFC how to map this kind of traffic?


 


Thank you,


BR Ales Sliber<=
/p>

 <=
/b>


Ale=B9 =A9liber


Core network engineer


Tel:
+386-1-472-8482<=
/o:p>


W-mobile:
www.mobitel.si



W-fix:
www.telekom.si


Telekom
Slovenije


 






--_000_7B8DC1AC12241143921AC7733AF3C17B1DF55878US70TWXCHMBA10z_--

From adam@nostrum.com  Fri Jan 25 06:46:17 2013
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 052D621F85DB for ; Fri, 25 Jan 2013 06:46:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.903
X-Spam-Level: 
X-Spam-Status: No, score=-100.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpomqWm2Wcxp for ; Fri, 25 Jan 2013 06:46:16 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id EE6A421F84CA for ; Fri, 25 Jan 2013 06:46:15 -0800 (PST)
Received: from [192.168.0.159] (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r0PEkDes047985 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 25 Jan 2013 08:46:14 -0600 (CST) (envelope-from adam@nostrum.com)
References: <26300ECDDED68545A78AAC3D98640BF3A157E82F@srexdb14.ts.telekom.si>
Mime-Version: 1.0 (1.0)
In-Reply-To: <26300ECDDED68545A78AAC3D98640BF3A157E82F@srexdb14.ts.telekom.si>
Content-Type: multipart/alternative; boundary=Apple-Mail-6F8C4307-7D63-466E-A8CE-0806AD44927F
Content-Transfer-Encoding: 7bit
Message-Id: 
X-Mailer: iPad Mail (10A403)
From: Adam Roach 
Date: Fri, 25 Jan 2013 08:46:13 -0600
To: =?utf-8?Q?=C5=A0liber_Ale=C5=A1?= 
Received-SPF: pass (shaman.nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism)
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] RFC 3398 - problems with ISUP cause mapping
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jan 2013 14:46:17 -0000

--Apple-Mail-6F8C4307-7D63-466E-A8CE-0806AD44927F
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Jan 25, 2013, at 1:01, =C5=A0liber Ale=C5=A1  wro=
te:

> Hi,
> =20
> I'm mobile core network engineer working a lot with ISUP to SIP mapping an=
d vice versa.
> I come up to an unsolved problem with mapping the traffic from ISUP to SIP=
 and back to ISUP.
> =20
> =46rom RFC 3398:
> =20
> ISUP-SIP
>    18 no user responding                   408 Request Timeout
>    19 no answer from the user              480 Temporarily unavailable
>    20 subscriber absent                    480 Temporarily unavailable
>  =20
> SIP-ISUP:
>    408 Request timeout                  102 Recovery on timer expiry
>    480 Temporarily unavailable           18 No user responding
> =20
> So if I send from ISUP REL-19 and this trafic wents maps to SIP and then b=
ack to ISUP, I receive on the other side ISUP REL-18.
> There is the same story with ISUP REL18 mappng to SIP and back to ISUP =E2=
=80=93 I will receive ISUP REL.102?!
> =20

No, because the cause code in the tunneled ISUP is supposed to take priority=
 over the SIP response code. So if you send REL-19, then the SIP will contai=
n an ISUP body part, and that ISUP body will contain REL-19. Then, when it g=
ets mapped back from SIP to ISUP, the gateway will use the REL-19 from the I=
SUP body rather than the SIP error code mapping.=20

The mapping from SIP response code to ISUP release code is used ONLY if ther=
e is no ISUP body present in the SIP message (basically, only for calls that=
 originate at a SIP terminal that has no knowledge of ISUP).=20

/a=

--Apple-Mail-6F8C4307-7D63-466E-A8CE-0806AD44927F
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable




On Jan 25, 2013, at 1:01, =C5=A0=
liber Ale=C5=A1 <Ales.Sliber@te=
lekom.si> wrote:











Hi,


 


I'm mobile core network engineer working a lot with ISUP to S=
IP mapping and vice versa.


I come up to an unsolved problem with mapping the traffic fr=
om ISUP to SIP and back to ISUP.


 


=46rom RFC 3398:


 


ISUP-SIP


   
18 no user responding         &=
nbsp;         408 Request Timeout


   19 no answer f=
rom the user          &nbs=
p;   480 Temporarily unavailable


   20 subscriber absent    &nb=
sp;            &=
nbsp;  480 Temporarily unavailable


   


SIP-ISUP:


   408 Request ti=
meout            =
;      102 Recovery on timer expiry


   480 Temporaril=
y unavailable           18=
 No user responding


 


So if I send from ISUP REL-19 and this trafic wents maps to S=
IP and then back to ISUP, I receive on the other side ISUP REL-18.


There is the same story with ISUP REL18 mappng to SIP and ba=
ck to ISUP =E2=80=93 I will receive ISUP REL.102?!


 
No, because the cause code in the tunneled ISUP is supposed to t=
ake priority over the SIP response code. So if you send REL-19, then the SIP=
 will contain an ISUP body part, and that ISUP body will contain REL-19. The=
n, when it gets mapped back from SIP to ISUP, the gateway will use the REL-1=
9 from the ISUP body rather than the SIP error code mapping. 

The mapping from SIP response code to ISUP release code is u=
sed ONLY if there is no ISUP body present in the SIP message (basically, onl=
y for calls that originate at a SIP terminal that has no knowledge of ISUP).=
 

/a
=

--Apple-Mail-6F8C4307-7D63-466E-A8CE-0806AD44927F--

From Markus.Isomaki@nokia.com  Sun Jan 27 13:15:54 2013
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340B121F87D4 for ; Sun, 27 Jan 2013 13:15:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohIqBGQbCHh3 for ; Sun, 27 Jan 2013 13:15:53 -0800 (PST)
Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 44DCA21F87D5 for ; Sun, 27 Jan 2013 13:15:53 -0800 (PST)
Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r0RLFlbe002038; Sun, 27 Jan 2013 23:15:48 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Sun, 27 Jan 2013 23:15:47 +0200
Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.171]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.02.0318.003; Sun, 27 Jan 2013 21:15:47 +0000
From: 
To: , , 
Thread-Topic: Review of draft-ivov-xmpp-cusax-02
Thread-Index: Ac38zMgQ/8KQM2zASWydYeH/yGSFJw==
Date: Sun, 27 Jan 2013 21:15:46 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.163.169.149]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 27 Jan 2013 21:15:47.0443 (UTC) FILETIME=[79BE5C30:01CDFCD3]
X-Nokia-AV: Clean
Cc: dispatch@ietf.org
Subject: [dispatch] Review of draft-ivov-xmpp-cusax-02
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 27 Jan 2013 21:15:54 -0000

Hi,

I did a review of draft-ivov-xmpp-cusax-02.

* Overview

The draft describes good practices for providing a full set of telephony, v=
ideo call, IM and presence type of services with complementary use of SIP a=
nd XMPP. SIP is used for telephony and video calls, while XMPP in practice =
for the rest. The draft does not propose any new SIP or XMPP protocol exten=
sions to achieve this, but explains how client developers and service provi=
ders can use the protocols' existing capabilties in a smart way to offer go=
od user experience.=20

* General comments

I personally believe there is a lot of merit in the approach presented in t=
he draft. Although it might not become a massively popular deployment case,=
 there are a number of interested client developers and service providers, =
and the document gives them useful guidance. For some currently not yet int=
erested it might give new ideas. So I'm in favor of publishing this as BCP,=
 but I think at least one more revision is needed.=20

Some clarification could still be added about the deployment cases consider=
ed:=20
- A single combined SIP + XMPP service provider vs. an opportunistic SIP =
=B4+ XMPP client making use of two indepdendent services. I belive the form=
er is the primary case but the latter is not totally scoped out either?
- Intra vs. inter-domain use: Some features seem to be more realistic in si=
ngle domain communication as compared to inter-domain?

One or two ascii art figures might be useful to explain the setups.=20

The document is quite short. However, it would be good to consider if the a=
ctual recommendations could be summarized at the end of each Section, or ma=
ke them stand out better in some other way. Especially when there is a reco=
mmendation to implement and use a particular SIP or XMPP extension.=20

A potentially interesting case these days that is not covered in the draft =
is the interconnection between two WebRTC service providers. SIP is usually=
 expected to be the poison of choice for telephony or video calls, but if m=
essaging and presence type of services are included, perhaps CUSAX approach=
 might make sense. On the other hand including this type of scenario might =
confuse the draft a bit too much.

* Detailed comments

-- Abstract:

- "This document describes current practices..."

I understanding this wording comes from Best Current Practices. For me, how=
ever, something like "recommended practices" would make more sense, since I=
 believe for most part the proposed practices are not yet in use.=20

-- Introduction:

- The targeted deployment scenarious could be explained here in a bit more =
detail.=20

- Short description of document organization at the end of Introduction wou=
ld be useful, even if this is a very simple document.

-- Client bootstrap

The draft says: "While it should be possible for CUSAX users to manually co=
nfigure
   their separate SIP and XMPP accounts, dual-stack SIP/XMPP clients
   ought to provide means of online provisioning.  While the specifics
   of such mechanisms are outside the scope of this specification, they
   should make it possible for a service provider to remotely configure
   the clients based on minimal user input (e.g., only a user ID and
   password)."

It is clearly said the mechanisms are out of scope. But in terms of interop=
erability and deployment scenarios this is an important question. Naturally=
 any proprietary mechanisms can be used, but that limits the deployment to =
cases where there is some kind of special relationship between the SIP + XM=
PP client and at least some part of the server infra. For independent clien=
ts, it would be useful to at least point out and probably recommend some me=
chanisms. In SIP there is the relatively recent UA configuration work, and =
I believe XMPP has something directly targeted for account/client provision=
ing. Those should be brought up.=20

-- Operation

- "An alternate mechanism would be for CUSAX clients to add to their SIP
   invite requests a Contact header containing the XMPP URI
   corresponding to their JID as per [RFC5122]."

The mechanism is mentioned but it is not clear how seriously it should be t=
aken by client developers. Shouldn't it be more clearly recommended for the=
 clients to support?

-- Federation

- Some text seems to be missing here.

Regards,
	Markus


From Ales.Sliber@telekom.si  Mon Jan 28 01:23:18 2013
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEACF21F8573 for ; Mon, 28 Jan 2013 01:23:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.543
X-Spam-Level: 
X-Spam-Status: No, score=-1.543 tagged_above=-999 required=5 tests=[AWL=0.754,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HESsbhAi80jf for ; Mon, 28 Jan 2013 01:23:16 -0800 (PST)
Received: from smtp2.telekom.si (smtp2.telekom.si [193.77.55.38]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDBC21F8549 for ; Mon, 28 Jan 2013 01:23:11 -0800 (PST)
Received: from srexch16.ts.telekom.si (cas.ts.telekom.si) by srmps02.ts.telekom.si (Clearswift SMTPRS 5.5.0) with ESMTP id ;  Mon, 28 Jan 2013 10:23:06 +0100
Received: from SREXDB14.ts.telekom.si ([169.254.4.68]) by srexch16.ts.telekom.si ([192.168.27.209]) with mapi id 14.02.0247.003; Mon, 28 Jan 2013 10:23:06 +0100
From: =?windows-1257?Q?=D0liber_Ale=F0?= 
To: "Calme, James A (Jim)" , Christer Holmberg , "dispatch@ietf.org" 
Thread-Topic: RFC 3398 - problems with ISUP cause mapping
Thread-Index: Ac36L/Ouvi96ppcBSLCYfqPfGqmxGAAl8IiQAACHohAADzCpEAAAKSbQAIxAG4A=
Date: Mon, 28 Jan 2013 09:23:06 +0000
Message-ID: <26300ECDDED68545A78AAC3D98640BF3A157F8B6@srexdb14.ts.telekom.si>
References: <26300ECDDED68545A78AAC3D98640BF3A157E82F@srexdb14.ts.telekom.si> <7594FB04B1934943A5C02806D1A2204B0CA15E@ESESSMB209.ericsson.se> <7B8DC1AC12241143921AC7733AF3C17B1DF55878@US70TWXCHMBA10.zam.alcatel-lucent.com>
In-Reply-To: <7B8DC1AC12241143921AC7733AF3C17B1DF55878@US70TWXCHMBA10.zam.alcatel-lucent.com>
Accept-Language: sl-SI, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.13.3.86]
Content-Type: multipart/alternative; boundary="_000_26300ECDDED68545A78AAC3D98640BF3A157F8B6srexdb14tstelek_"
MIME-Version: 1.0
Subject: Re: [dispatch] RFC 3398 - problems with ISUP cause mapping
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Jan 2013 09:23:18 -0000

--_000_26300ECDDED68545A78AAC3D98640BF3A157F8B6srexdb14tstelek_
Content-Type: text/plain; charset="windows-1257"
Content-Transfer-Encoding: quoted-printable

Hi,

Thank you for reply, but as I can see, from 3GPP TS 29.163 document =96 the=
re is quite the same story (maby even worst =96 because ISUP 18 is mapd als=
o in SIP 480 and not in-to SIP-408 as in RFC):


Table 9: Receipt of the Release message (REL)

=95SIP Message


=95 REL


Status code


Cause parameter


404 Not Found


Cause value No. 1 (unallocated (unassigned) number)


500 Server Internal error


Cause value No 2 (no route to network)


500 Server Internal error


Cause value No 3 (no route to destination)


500 Server Internal error


Cause value No. 4 (Send special information tone)


404 Not Found


Cause value No. 5 (Misdialled trunk prefix)


486 Busy Here


Cause value No. 17 (user busy)


480 Temporarily unavailable


Cause value No 18 (no user responding)


480 Temporarily unavailable


Cause value No 19 (no answer from the user)


480 Temporarily unavailable


Cause value No. 20 (subscriber absent)


603 Decline


Cause value No 21 (call rejected), Location =3D 000 / user (U)


480Temporarily unavailable


Cause value No 21 (call rejected) , Location <> 000 / user (U)


410 Gone


Cause value No 22 (number changed)


433 Anonymity Disallowed.(NOTE 1)


Cause value No. 24 (call rejected due to ACR supplementary service)


480 Temporarily unavailable


Cause value No 25 (Exchange routing error)


502 Bad Gateway


Cause value No 27 (destination out of order)


484 Address Incomplete


Cause value No. 28 invalid number format (address incomplete)


500 Server Internal error


Cause value No 29 (facility rejected)


480 Temporarily unavailable


Cause value No 31 (normal unspecified) (class default) (NOTE 2)


486 Busy here if Diagnostics indicator includes the (CCBS indicator =3D CCB=
S possible)

else 480 Temporarily unavailable


Cause value in the Class 010 (resource unavailable, Cause value No 34)


500 Server Internal error


Cause value in the Class 010
(resource unavailable, Cause value No=92s. 38, 41, 42, 43, 44, & 47) (47 is=
 class default)


500 Server Internal error


Cause value No 50 (requested facility no subscribed)


500 Server Internal error


Cause value No 57 (bearer capability not authorised)


500 Server Internal error


Cause value No 58 (bearer capability not presently)


500 Server Internal error


Cause value No 63 (service option not available, unspecified)
(class default)


500 Server Internal error


Cause value in the Class 100 (service or option not implemented, Cause valu=
e No=92s. 65, 70 & 79) 79 is class default


500 Server Internal error


Cause value No 88 (incompatible destination)


404 Not Found


Cause value No 91 (invalid transit network selection)


500 Server Internal error


Cause value No 95 (invalid message)
(class default)


500 Server Internal error


Cause value No 97 (Message type non-existent or not implemented)


500 Server Internal error


Cause value No 99 (information element/parameter non-existent or not implem=
ented))


480 Temporarily unavailable


Cause value No. 102 (recovery on timer expiry)


500 Server Internal error


Cause value No 110 (Message with unrecognised Parameter, discarded)


500 Server Internal error


Cause value No. 111 (protocol error, unspecified)
(class default)


480 Temporarily unavailable


Cause value No. 127 (interworking unspecified)
(class default)


NOTE 1:    Anonymity Disallowed, RFC 5079 [77] refers

NOTE 2:    Class 1 and class 2 have the same default value.





Table 18: 4xx/5xx/6xx Received on SIP side of O-MGCF

=95REL (cause code)


=954xx/5xx/6xx SIP Message


127 (interworking unspecified)


400 Bad Request


127 (interworking unspecified)


401 Unauthorized


127 (interworking unspecified)


402 Payment Required


127 (interworking unspecified)


403 Forbidden


1 (Unallocated number)


404 Not Found


127 (interworking unspecified)


405 Method Not Allowed


127 (interworking unspecified)


406 Not Acceptable


127 (interworking unspecified)


407 Proxy authentication required


127 (interworking unspecified)


408 Request Timeout


22 (Number changed)


410 Gone


127 (interworking unspecified)


413 Request Entity too long


127 (interworking unspecified)


414 Request-URI too long


127 (interworking unspecified)


415 Unsupported Media type


127 (interworking unspecified)


416 Unsupported URI scheme


127 (interworking unspecified)


420 Bad Extension


127 (interworking unspecified)


421 Extension required


127 (interworking unspecified)


423 Interval Too Brief


24 (call rejected due to ACR supplementary service)


433 Anonymity Disallowed.(NOTE 1)


20 Subscriber absent


480 Temporarily Unavailable


127 (interworking unspecified)


481 Call/Transaction does not exist


127 (interworking unspecified)


482 Loop detected


127 (interworking unspecified)


483 Too many hops


28 (Invalid Number format)


484 Address Incomplete


127 (interworking unspecified)


485 Ambiguous


17 (User busy)


486 Busy Here


127 (Interworking unspecified) or not interworked. (NOTE 2)


487 Request terminated


127 (interworking unspecified)


488 Not acceptable here


127 (interworking unspecified)


493 Undecipherable


127 (interworking unspecified)


500 Server Internal error


127 (interworking unspecified)


501 Not implemented


127 (interworking unspecified)


502 Bad Gateway


127 (interworking unspecified)


503 Service Unavailable


127 (interworking unspecified)


504 Server timeout


127 (interworking unspecified)


505 Version not supported


127 (interworking unspecified)


513 Message too large


127 (interworking unspecified)


580 Precondition failure


17 (User busy)


600 Busy Everywhere


21 (Call rejected)


603 Decline


1 (unallocated number)


604 Does not exist anywhere


127 (interworking unspecified)


606 Not acceptable


NOTE 1:    Anonymity Disallowed, RFC 5079 [77] refers.

NOTE 2:    No interworking if the O-MGCF previously issued a CANCEL request=
 for the INVITE.

NOTE 3:    The 4xx/5xx/6xx SIP responses that are not covered in this table=
 are not interworked.



BR Ale=F0

From: Calme, James A (Jim) [mailto:jim.calme@alcatel-lucent.com]
Sent: 25. januar 2013 15:23
To: Christer Holmberg; =D0liber Ale=F0; dispatch@ietf.org
Subject: RE: RFC 3398 - problems with ISUP cause mapping

Please reference 3GPP TS 29.163, much work as been done on this document ov=
er the last couple years to address mapping concerns.

Jim

From: dispatch-bounces@ietf.org [mailto:d=
ispatch-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Friday, January 25, 2013 8:18 AM
To: =D0liber Ale=F0; dispatch@ietf.org
Subject: Re: [dispatch] RFC 3398 - problems with ISUP cause mapping

Hi,

There is no new RFC, but SDOs like ITU-T and 3GPP have specified mapping wh=
ich in some cases differs from the RFC.

Regards,

Christer

From: dispatch-bounces@ietf.org [mailto:d=
ispatch-bounces@ietf.org] On Behalf Of =D0liber Ale=F0
Sent: 25. tammikuuta 2013 9:02
To: dispatch@ietf.org
Subject: Re: [dispatch] RFC 3398 - problems with ISUP cause mapping

Hi,

I'm mobile core network engineer working a lot with ISUP to SIP mapping and=
 vice versa.
I come up to an unsolved problem with mapping the traffic from ISUP to SIP =
and back to ISUP.

>From RFC 3398:

ISUP-SIP
   18 no user responding                   408 Request Timeout
   19 no answer from the user              480 Temporarily unavailable
   20 subscriber absent                    480 Temporarily unavailable

SIP-ISUP:
   408 Request timeout                  102 Recovery on timer expiry
   480 Temporarily unavailable           18 No user responding

So if I send from ISUP REL-19 and this trafic wents maps to SIP and then ba=
ck to ISUP, I receive on the other side ISUP REL-18.
There is the same story with ISUP REL18 mappng to SIP and back to ISUP =96 =
I will receive ISUP REL.102?!

Can you help me with this isue. Is there any new RFC how to map this kind o=
f traffic?

Thank you,
BR Ales Sliber

Ale=F0 =D0liber
Core network engineer
Tel: +386-1-472-8482
W-mobile: www.mobitel.si
W-fix: www.telekom.si
Telekom Slovenije


--_000_26300ECDDED68545A78AAC3D98640BF3A157F8B6srexdb14tstelek_
Content-Type: text/html; charset="windows-1257"
Content-Transfer-Encoding: quoted-printable











Hi,


 


Thank you for reply, but as I can see, from 3GPP TS 29.163=
 document =96 there is quite the same story (maby even worst =96 because IS=
UP 18 is mapd also in SIP 480 and not in-to SIP-408 as in RFC):<=
/span>


 








Table =
9: Receipt of the Release message (REL)










=ACSIP Message





=AC REL








Status code




Cause parameter










404 N=
ot Found




Cause=
 value No. 1 (unallocated (unassigned) number)








500 S=
erver Internal error




Cause=
 value No 2 (no route to network)








500 S=
erver Internal error




Cause=
 value No 3 (no route to destination)








500 S=
erver Internal error




Cause value No. 4 (Send special information tone)








404 N=
ot Found




Cause value No. 5 (Misdialled trunk prefix)








486 B=
usy Here




Cause=
 value No. 17 (user busy)








480 Temporarily unavailable<=
o:p>




Cause value No 18 (no user r=
esponding)








480 Temporarily unavailable<=
o:p>




Cause value No 19 (no answer=
 from the user)








480 Temporarily unavailable<=
o:p>




Cause value No. 20 (sub=
scriber absent)








603 D=
ecline




Cause=
 value No 21 (call rejected), Location =3D 000 / user (U)=









480Te=
mporarily unavailable




Cause=
 value No 21 (call rejected) , Location <> 000 / user (U)








410 G=
one




Cause=
 value No 22 (number changed)








433 A=
nonymity Disallowed.(NOTE 1)




Cause=
 value No. 24 (call rejected due to ACR supplementary service)








480 T=
emporarily unavailable




Cause=
 value No 25 (Exchange routing error)








502 B=
ad Gateway




Cause=
 value No 27 (destination out of order)








484 A=
ddress Incomplete




Cause=
 value No. 28 invalid number format (address incomplete)








500 S=
erver Internal error




Cause=
 value No 29 (facility rejected)








480 T=
emporarily unavailable




Cause=
 value No 31 (normal unspecified) (class default) (NOTE 2)








486 B=
usy here if Diagnostics indicator includes the (CCBS indicator =3D CCBS pos=
sible)


else =
480 Temporarily unavailable




Cause=
 value in the Class 010 (resource unavailable, Cause value No 34)








500 S=
erver Internal error




Cause=
 value in the Class 010

(resource unavailable, Cause value No=92s. 38, 41, 42, 43, 44, & 47) (4=
7 is class default)








500 S=
erver Internal error




Cause=
 value No 50 (requested facility no subscribed)








500 S=
erver Internal error




Cause=
 value No 57 (bearer capability not authorised)








500 S=
erver Internal error




Cause=
 value No 58 (bearer capability not presently)








500 S=
erver Internal error




Cause=
 value No 63 (service option not available, unspecified)

(class default)








500 S=
erver Internal error




Cause=
 value in the Class 100 (service or option not implemented, Cause value No=
=92s. 65, 70 & 79) 79 is class default








500 S=
erver Internal error




Cause va=
lue No 88 (incompatible destination)








404 N=
ot Found




Cause=
 value No 91 (invalid transit network selection)








500 S=
erver Internal error




Cause=
 value No 95 (invalid message)

(class default)








500 S=
erver Internal error




Cause=
 value No 97 (Messag=
e type non-existent or not implemented)








500 S=
erver Internal error




Cause=
 value No 99 (information element/parameter non-existent or not implemented=
))








480 T=
emporarily unavailable




Cause=
 value No. 102 (recovery on timer expiry)








500 S=
erver Internal error




Cause=
 value No 110 (Message with unrecognised Parameter, discarded)








500 S=
erver Internal error




Cause=
 value No. 111 (protocol error, unspecified)

(class default)








480 T=
emporarily unavailable




Cause=
 value No. 127 (interworking unspecified)

(class default)








NOTE 1:    Anonymity D=
isallowed, RFC 5079 [77] refers


NOTE 2:    Class 1 and=
 class 2 have the same default value.










 <=
/span>


 




Table =
18: 4xx/5xx/6xx Received on SIP side of O-MGCF










=ACREL (cause code)




=AC4xx/5xx/6xx SIP Message=











127 (=
interworking unspecified)




400 B=
ad Request








127 (=
interworking unspecified)




401 U=
nauthorized








127 (=
interworking unspecified)




402 P=
ayment Required








127 (=
interworking unspecified)




403 F=
orbidden








1 (Un=
allocated number)




404 N=
ot Found








127 (=
interworking unspecified)




405 M=
ethod Not Allowed








127 (=
interworking unspecified)




406 N=
ot Acceptable








127 (=
interworking unspecified)




407 P=
roxy authentication required








127 (interworking unspecifie=
d)




408 Request Timeout








22 (N=
umber changed)




410 G=
one








127 (=
interworking unspecified)




413 R=
equest Entity too long








127 (=
interworking unspecified)




414 R=
equest-URI too long








127 (=
interworking unspecified)




415 U=
nsupported Media type








127 (=
interworking unspecified)




416 U=
nsupported URI scheme








127 (=
interworking unspecified)




420 B=
ad Extension








127 (=
interworking unspecified)




421 E=
xtension required








127 (=
interworking unspecified)




423 I=
nterval Too Brief








24 (c=
all rejected due to ACR supplementary service)




433 A=
nonymity Disallowed.(NOTE 1)








20 Subscriber absent




480 Temporarily Unavailable<=
o:p>








127 (=
interworking unspecified)




481 C=
all/Transaction does not exist








127 (=
interworking unspecified)




482 L=
oop detected








127 (=
interworking unspecified)




483 T=
oo many hops








28 (I=
nvalid Number format)




484 A=
ddress Incomplete








127 (=
interworking unspecified)




485 A=
mbiguous








17 (U=
ser busy)




486 B=
usy Here








127 (=
Interworking unspecified) or not interworked. (NOTE 2)




487 R=
equest terminated








127 (=
interworking unspecified)




488 N=
ot acceptable here








127 (=
interworking unspecified)




493 U=
ndecipherable








127 (=
interworking unspecified)




500 S=
erver Internal error








127 (=
interworking unspecified)




501 N=
ot implemented








127 (=
interworking unspecified)




502 B=
ad Gateway








127 (=
interworking unspecified)




503 S=
ervice Unavailable








127 (=
interworking unspecified)




504 S=
erver timeout








127 (=
interworking unspecified)




505 V=
ersion not supported








127 (=
interworking unspecified)




513 M=
essage too large








127 (=
interworking unspecified)




580 P=
recondition failure








17 (U=
ser busy)




600 B=
usy Everywhere








21 (C=
all rejected)




603 D=
ecline








1 (un=
allocated number)




604 D=
oes not exist anywhere








127 (=
interworking unspecified)




606 N=
ot acceptable








NOTE 1:    Anonymity D=
isallowed, RFC 5079 [77] refers.


NOTE 2:    No interwor=
king if the O-MGCF previously issued a CANCEL request for the INVITE.<=
/o:p>


NOTE 3:    The 4xx/5xx=
/6xx SIP responses that are not covered in this table are not interworked.<=
o:p>


















 


BR Ale=F0


 






From: Calme, James A (Jim) [mailto:jim.calme@alcatel-lucent=
.com]


Sent: 25. januar 2013 15:23

To: Christer Holmberg; =D0liber Ale=F0; dispatch@ietf.org

Subject: RE: RFC 3398 - problems with ISUP cause mapping<=
/span>






 


Please reference 3GPP =
TS 29.163, much work as been done on this document over the last couple yea=
rs to address mapping concerns.


 


Jim<=
/p>

 






From:
dispatch-bounces@ietf.org =
[mailto:dispatch-bounces@ietf.=
org]
On Behalf Of Christer Holmberg

Sent: Friday, January 25, 2013 8:18 AM

To: =D0liber Ale=F0; dispatch@i=
etf.org

Subject: Re: [dispatch] RFC 3398 - problems with ISUP cause mapping<=
o:p>






 


Hi,


 <=
/p>

There is no new RFC, but SDOs like ITU-T and 3GPP hav=
e specified mapping which in some cases differs from the RFC.


 <=
/p>

Regards,


 <=
/p>

Christer


 <=
/p>





From:
dispatch-bounces@ietf.org =
[mailto:dispatch-bounces@ietf.=
org]
On Behalf Of =D0liber Ale=F0

Sent: 25. tammikuuta 2013 9:02

To: dispatch@ietf.org

Subject: Re: [dispatch] RFC 3398 - problems with ISUP cause mapping<=
/span>






&n=
bsp;


Hi,


 


I'm mobile core network engin=
eer working a lot with ISUP to SIP mapping and vice versa.


I come up to an unsolved prob=
lem with mapping the traffic from ISUP to SIP and back to ISUP.


 


From RFC 3398:


 


ISUP-SIP


  
18 no user responding    =
            &nb=
sp;  408 Request Timeout


  
19 no answer from the user  &nbs=
p;           480 Temporar=
ily unavailable

   20 subscriber ab=
sent            =
;        480 Temporarily unavailable


  



SIP-ISUP:


  
408 Request timeout    =
;            &n=
bsp; 102 Recovery on timer expiry


  
480 Temporarily unavailable  &nb=
sp;        18 No user responding<=
/b>


 


So if I send from ISUP REL-19=
 and this trafic wents maps to SIP and then back to ISUP, I receive on the =
other side ISUP REL-18.


There is the same story with =
ISUP REL18 mappng to SIP and back to ISUP =96 I will receive ISUP REL.102?!=



 


Can you help me with this isu=
e. Is there any new RFC how to map this kind of traffic?


 


Thank you,


BR Ales Sliber


 


<=
span style=3D"font-size:9.0pt;font-family:"Arial","sans-seri=
f";color:red">Ale=F0 =D0liber


Core network engineer


Tel:
+386-1-472-8482


W-mobile:
www.mobit=
el.si



W-fix:
www.telek=
om.si


<=
span style=3D"font-size:9.0pt;font-family:"Arial","sans-seri=
f";color:#0070C0">Telekom
Slovenije=



 






--_000_26300ECDDED68545A78AAC3D98640BF3A157F8B6srexdb14tstelek_--

From jim.calme@alcatel-lucent.com  Mon Jan 28 06:09:56 2013
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B24A21F86E7 for ; Mon, 28 Jan 2013 06:09:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.948
X-Spam-Level: 
X-Spam-Status: No, score=-9.948 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgFh1vJvwPtR for ; Mon, 28 Jan 2013 06:09:54 -0800 (PST)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 38C7521F86E4 for ; Mon, 28 Jan 2013 06:09:53 -0800 (PST)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r0SE9m8q029551 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 28 Jan 2013 15:09:48 +0100
Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 28 Jan 2013 15:09:48 +0100
Received: from US70TWXCHMBA10.zam.alcatel-lucent.com ([169.254.4.41]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Mon, 28 Jan 2013 09:09:43 -0500
From: "Calme, James A (Jim)" 
To: =?windows-1257?Q?=D0liber_Ale=F0?= , "Christer Holmberg" , "dispatch@ietf.org" 
Thread-Topic: RFC 3398 - problems with ISUP cause mapping
Thread-Index: Ac36L/Ouvi96ppcBSLCYfqPfGqmxGAAl8IiQAACHohAADzCpEAAAKSbQAIxAG4AACh/T0A==
Date: Mon, 28 Jan 2013 14:09:43 +0000
Message-ID: <7B8DC1AC12241143921AC7733AF3C17B1DF55C31@US70TWXCHMBA10.zam.alcatel-lucent.com>
References: <26300ECDDED68545A78AAC3D98640BF3A157E82F@srexdb14.ts.telekom.si> <7594FB04B1934943A5C02806D1A2204B0CA15E@ESESSMB209.ericsson.se> <7B8DC1AC12241143921AC7733AF3C17B1DF55878@US70TWXCHMBA10.zam.alcatel-lucent.com> <26300ECDDED68545A78AAC3D98640BF3A157F8B6@srexdb14.ts.telekom.si>
In-Reply-To: <26300ECDDED68545A78AAC3D98640BF3A157F8B6@srexdb14.ts.telekom.si>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.5.27.16]
Content-Type: multipart/alternative; boundary="_000_7B8DC1AC12241143921AC7733AF3C17B1DF55C31US70TWXCHMBA10z_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80
Subject: Re: [dispatch] RFC 3398 - problems with ISUP cause mapping
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Jan 2013 14:09:56 -0000

--_000_7B8DC1AC12241143921AC7733AF3C17B1DF55C31US70TWXCHMBA10z_
Content-Type: text/plain; charset="windows-1257"
Content-Transfer-Encoding: quoted-printable

True, it is not 100% symmetric.
If it is required to maintain the original ISUP cause, then I would suggest=
 using the Reason header field.
Jim

From: =D0liber Ale=F0 [mailto:Ales.Sliber@telekom.si]
Sent: Monday, January 28, 2013 3:23 AM
To: Calme, James A (Jim); Christer Holmberg; dispatch@ietf.org
Subject: RE: RFC 3398 - problems with ISUP cause mapping

Hi,

Thank you for reply, but as I can see, from 3GPP TS 29.163 document =96 the=
re is quite the same story (maby even worst =96 because ISUP 18 is mapd als=
o in SIP 480 and not in-to SIP-408 as in RFC):


Table 9: Receipt of the Release message (REL)

=95SIP Message


=95 REL


Status code


Cause parameter


404 Not Found


Cause value No. 1 (unallocated (unassigned) number)


500 Server Internal error


Cause value No 2 (no route to network)


500 Server Internal error


Cause value No 3 (no route to destination)


500 Server Internal error


Cause value No. 4 (Send special information tone)


404 Not Found


Cause value No. 5 (Misdialled trunk prefix)


486 Busy Here


Cause value No. 17 (user busy)


480 Temporarily unavailable


Cause value No 18 (no user responding)


480 Temporarily unavailable


Cause value No 19 (no answer from the user)


480 Temporarily unavailable


Cause value No. 20 (subscriber absent)


603 Decline


Cause value No 21 (call rejected), Location =3D 000 / user (U)


480Temporarily unavailable


Cause value No 21 (call rejected) , Location <> 000 / user (U)


410 Gone


Cause value No 22 (number changed)


433 Anonymity Disallowed.(NOTE 1)


Cause value No. 24 (call rejected due to ACR supplementary service)


480 Temporarily unavailable


Cause value No 25 (Exchange routing error)


502 Bad Gateway


Cause value No 27 (destination out of order)


484 Address Incomplete


Cause value No. 28 invalid number format (address incomplete)


500 Server Internal error


Cause value No 29 (facility rejected)


480 Temporarily unavailable


Cause value No 31 (normal unspecified) (class default) (NOTE 2)


486 Busy here if Diagnostics indicator includes the (CCBS indicator =3D CCB=
S possible)

else 480 Temporarily unavailable


Cause value in the Class 010 (resource unavailable, Cause value No 34)


500 Server Internal error


Cause value in the Class 010
(resource unavailable, Cause value No=92s. 38, 41, 42, 43, 44, & 47) (47 is=
 class default)


500 Server Internal error


Cause value No 50 (requested facility no subscribed)


500 Server Internal error


Cause value No 57 (bearer capability not authorised)


500 Server Internal error


Cause value No 58 (bearer capability not presently)


500 Server Internal error


Cause value No 63 (service option not available, unspecified)
(class default)


500 Server Internal error


Cause value in the Class 100 (service or option not implemented, Cause valu=
e No=92s. 65, 70 & 79) 79 is class default


500 Server Internal error


Cause value No 88 (incompatible destination)


404 Not Found


Cause value No 91 (invalid transit network selection)


500 Server Internal error


Cause value No 95 (invalid message)
(class default)


500 Server Internal error


Cause value No 97 (Message type non-existent or not implemented)


500 Server Internal error


Cause value No 99 (information element/parameter non-existent or not implem=
ented))


480 Temporarily unavailable


Cause value No. 102 (recovery on timer expiry)


500 Server Internal error


Cause value No 110 (Message with unrecognised Parameter, discarded)


500 Server Internal error


Cause value No. 111 (protocol error, unspecified)
(class default)


480 Temporarily unavailable


Cause value No. 127 (interworking unspecified)
(class default)


NOTE 1:    Anonymity Disallowed, RFC 5079 [77] refers

NOTE 2:    Class 1 and class 2 have the same default value.





Table 18: 4xx/5xx/6xx Received on SIP side of O-MGCF

=95REL (cause code)


=954xx/5xx/6xx SIP Message


127 (interworking unspecified)


400 Bad Request


127 (interworking unspecified)


401 Unauthorized


127 (interworking unspecified)


402 Payment Required


127 (interworking unspecified)


403 Forbidden


1 (Unallocated number)


404 Not Found


127 (interworking unspecified)


405 Method Not Allowed


127 (interworking unspecified)


406 Not Acceptable


127 (interworking unspecified)


407 Proxy authentication required


127 (interworking unspecified)


408 Request Timeout


22 (Number changed)


410 Gone


127 (interworking unspecified)


413 Request Entity too long


127 (interworking unspecified)


414 Request-URI too long


127 (interworking unspecified)


415 Unsupported Media type


127 (interworking unspecified)


416 Unsupported URI scheme


127 (interworking unspecified)


420 Bad Extension


127 (interworking unspecified)


421 Extension required


127 (interworking unspecified)


423 Interval Too Brief


24 (call rejected due to ACR supplementary service)


433 Anonymity Disallowed.(NOTE 1)


20 Subscriber absent


480 Temporarily Unavailable


127 (interworking unspecified)


481 Call/Transaction does not exist


127 (interworking unspecified)


482 Loop detected


127 (interworking unspecified)


483 Too many hops


28 (Invalid Number format)


484 Address Incomplete


127 (interworking unspecified)


485 Ambiguous


17 (User busy)


486 Busy Here


127 (Interworking unspecified) or not interworked. (NOTE 2)


487 Request terminated


127 (interworking unspecified)


488 Not acceptable here


127 (interworking unspecified)


493 Undecipherable


127 (interworking unspecified)


500 Server Internal error


127 (interworking unspecified)


501 Not implemented


127 (interworking unspecified)


502 Bad Gateway


127 (interworking unspecified)


503 Service Unavailable


127 (interworking unspecified)


504 Server timeout


127 (interworking unspecified)


505 Version not supported


127 (interworking unspecified)


513 Message too large


127 (interworking unspecified)


580 Precondition failure


17 (User busy)


600 Busy Everywhere


21 (Call rejected)


603 Decline


1 (unallocated number)


604 Does not exist anywhere


127 (interworking unspecified)


606 Not acceptable


NOTE 1:    Anonymity Disallowed, RFC 5079 [77] refers.

NOTE 2:    No interworking if the O-MGCF previously issued a CANCEL request=
 for the INVITE.

NOTE 3:    The 4xx/5xx/6xx SIP responses that are not covered in this table=
 are not interworked.



BR Ale=F0

From: Calme, James A (Jim) [mailto:jim.calme@alcatel-lucent.com]
Sent: 25. januar 2013 15:23
To: Christer Holmberg; =D0liber Ale=F0; dispatch@ietf.org
Subject: RE: RFC 3398 - problems with ISUP cause mapping

Please reference 3GPP TS 29.163, much work as been done on this document ov=
er the last couple years to address mapping concerns.

Jim

From: dispatch-bounces@ietf.org [mailto:d=
ispatch-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Friday, January 25, 2013 8:18 AM
To: =D0liber Ale=F0; dispatch@ietf.org
Subject: Re: [dispatch] RFC 3398 - problems with ISUP cause mapping

Hi,

There is no new RFC, but SDOs like ITU-T and 3GPP have specified mapping wh=
ich in some cases differs from the RFC.

Regards,

Christer

From: dispatch-bounces@ietf.org [mailto:d=
ispatch-bounces@ietf.org] On Behalf Of =D0liber Ale=F0
Sent: 25. tammikuuta 2013 9:02
To: dispatch@ietf.org
Subject: Re: [dispatch] RFC 3398 - problems with ISUP cause mapping

Hi,

I'm mobile core network engineer working a lot with ISUP to SIP mapping and=
 vice versa.
I come up to an unsolved problem with mapping the traffic from ISUP to SIP =
and back to ISUP.

>From RFC 3398:

ISUP-SIP
   18 no user responding                   408 Request Timeout
   19 no answer from the user              480 Temporarily unavailable
   20 subscriber absent                    480 Temporarily unavailable

SIP-ISUP:
   408 Request timeout                  102 Recovery on timer expiry
   480 Temporarily unavailable           18 No user responding

So if I send from ISUP REL-19 and this trafic wents maps to SIP and then ba=
ck to ISUP, I receive on the other side ISUP REL-18.
There is the same story with ISUP REL18 mappng to SIP and back to ISUP =96 =
I will receive ISUP REL.102?!

Can you help me with this isue. Is there any new RFC how to map this kind o=
f traffic?

Thank you,
BR Ales Sliber

Ale=F0 =D0liber
Core network engineer
Tel: +386-1-472-8482
W-mobile: www.mobitel.si
W-fix: www.telekom.si
Telekom Slovenije


--_000_7B8DC1AC12241143921AC7733AF3C17B1DF55C31US70TWXCHMBA10z_
Content-Type: text/html; charset="windows-1257"
Content-Transfer-Encoding: quoted-printable











True, it is not 100% symmetric.



If it is required to maintain the original ISUP cause, then =
I would suggest using the Reason header field.


Jim


 






From: =D0liber Ale=F0 [ma=
ilto:Ales.Sliber@telekom.si]


Sent: Monday, January 28, 2013 3:23 AM

To: Calme, James A (Jim); Christer Holmberg; dispatch@ietf.org

Subject: RE: RFC 3398 - problems with ISUP cause mapping<=
/span>






 


Hi,=



 


Thank you for reply, but as I can=
 see, from 3GPP TS 29.163 document =96 there is quite the same story (maby =
even worst =96 because ISUP 18 is mapd also in SIP
 480 and not in-to SIP-408 as in RFC):<=
/span>


 








Table =
9: Receipt of the Release message (REL)










=ACSIP Message





=AC REL








Status code




Cause parameter










404 N=
ot Found




Cause=
 value No. 1 (unallocated (unassigned) number)








500 S=
erver Internal error




Cause=
 value No 2 (no route to network)








500 S=
erver Internal error




Cause=
 value No 3 (no route to destination)








500 S=
erver Internal error




Cause value No. 4 (Send special information tone)








404 N=
ot Found




Cause value No. 5 (Misdialled trunk prefix)








486 B=
usy Here




Cause=
 value No. 17 (user busy)








480 Temporarily unavailable<=
/span>




Cause value No 18 (no user r=
esponding)








480 Temporarily unavailable<=
/span>




Cause value No 19 (no answer=
 from the user)








480 Temporarily unavailable<=
/span>




Cause value No. 20 (sub=
scriber absent)








603 D=
ecline




Cause=
 value No 21 (call rejected), Location =3D 000 / user (U)=









480Te=
mporarily unavailable




Cause=
 value No 21 (call rejected) , Location <> 000 / user (U)=









410 G=
one




Cause=
 value No 22 (number changed)








433 A=
nonymity Disallowed.(NOTE 1)




Cause=
 value No. 24 (call rejected due to ACR supplementary service)<=
/o:p>








480 T=
emporarily unavailable




Cause=
 value No 25 (Exchange routing error)








502 B=
ad Gateway




Cause=
 value No 27 (destination out of order)








484 A=
ddress Incomplete




Cause=
 value No. 28 invalid number format (address incomplete)








500 S=
erver Internal error




Cause=
 value No 29 (facility rejected)








480 T=
emporarily unavailable




Cause=
 value No 31 (normal unspecified) (class default) (NOTE 2)








486 B=
usy here if Diagnostics indicator includes the (CCBS indicator =3D CCBS pos=
sible)


else =
480 Temporarily unavailable




Cause=
 value in the Class 010 (resource unavailable, Cause value No 34)








500 S=
erver Internal error




Cause=
 value in the Class 010

(resource unavailable, Cause value No=92s. 38, 41, 42, 43, 44, & 47) (4=
7 is class default)








500 S=
erver Internal error




Cause=
 value No 50 (requested facility no subscribed)








500 S=
erver Internal error




Cause=
 value No 57 (bearer capability not authorised)








500 S=
erver Internal error




Cause=
 value No 58 (bearer capability not presently)








500 S=
erver Internal error




Cause=
 value No 63 (service option not available, unspecified)

(class default)








500 S=
erver Internal error




Cause=
 value in the Class 100 (service or option not implemented, Cause value No=
=92s. 65, 70 & 79) 79 is class default








500 S=
erver Internal error




Cause va=
lue No 88 (incompatible destination)








404 N=
ot Found




Cause=
 value No 91 (invalid transit network selection)








500 S=
erver Internal error




Cause=
 value No 95 (invalid message)

(class default)








500 S=
erver Internal error




Cause=
 value No 97 (Messag=
e type non-existent or not implemented)<=
o:p>








500 S=
erver Internal error




Cause=
 value No 99 (information element/parameter non-existent or not implemented=
))








480 T=
emporarily unavailable




Cause=
 value No. 102 (recovery on timer expiry)








500 S=
erver Internal error




Cause=
 value No 110 (Message with unrecognised Parameter, discarded)<=
/o:p>








500 S=
erver Internal error




Cause=
 value No. 111 (protocol error, unspecified)

(class default)








480 T=
emporarily unavailable




Cause=
 value No. 127 (interworking unspecified)

(class default)








NOTE 1:    Anonymity D=
isallowed, RFC 5079 [77] refers


NOTE 2:    Class 1 and=
 class 2 have the same default value.










 <=
/o:p>


 




Table =
18: 4xx/5xx/6xx Received on SIP side of O-MGCF










=ACREL (cause code)




=AC4xx/5xx/6xx SIP Message=











127 (=
interworking unspecified)




400 B=
ad Request








127 (=
interworking unspecified)




401 U=
nauthorized








127 (=
interworking unspecified)




402 P=
ayment Required








127 (=
interworking unspecified)




403 F=
orbidden








1 (Un=
allocated number)




404 N=
ot Found








127 (=
interworking unspecified)




405 M=
ethod Not Allowed








127 (=
interworking unspecified)




406 N=
ot Acceptable








127 (=
interworking unspecified)




407 P=
roxy authentication required








127 (interworking unspecifie=
d)




408 Request Timeout








22 (N=
umber changed)




410 G=
one








127 (=
interworking unspecified)




413 R=
equest Entity too long








127 (=
interworking unspecified)




414 R=
equest-URI too long








127 (=
interworking unspecified)




415 U=
nsupported Media type








127 (=
interworking unspecified)




416 U=
nsupported URI scheme








127 (=
interworking unspecified)




420 B=
ad Extension








127 (=
interworking unspecified)




421 E=
xtension required








127 (=
interworking unspecified)




423 I=
nterval Too Brief








24 (c=
all rejected due to ACR supplementary service)




433 A=
nonymity Disallowed.(NOTE 1)








20 Subscriber absent<=
/b>




480 Temporarily Unavailable<=
/span>








127 (=
interworking unspecified)




481 C=
all/Transaction does not exist








127 (=
interworking unspecified)




482 L=
oop detected








127 (=
interworking unspecified)




483 T=
oo many hops








28 (I=
nvalid Number format)




484 A=
ddress Incomplete








127 (=
interworking unspecified)




485 A=
mbiguous








17 (U=
ser busy)




486 B=
usy Here








127 (=
Interworking unspecified) or not interworked. (NOTE 2)




487 R=
equest terminated








127 (=
interworking unspecified)




488 N=
ot acceptable here








127 (=
interworking unspecified)




493 U=
ndecipherable








127 (=
interworking unspecified)




500 S=
erver Internal error








127 (=
interworking unspecified)




501 N=
ot implemented








127 (=
interworking unspecified)




502 B=
ad Gateway








127 (=
interworking unspecified)




503 S=
ervice Unavailable








127 (=
interworking unspecified)




504 S=
erver timeout








127 (=
interworking unspecified)




505 V=
ersion not supported








127 (=
interworking unspecified)




513 M=
essage too large








127 (=
interworking unspecified)




580 P=
recondition failure








17 (U=
ser busy)




600 B=
usy Everywhere








21 (C=
all rejected)




603 D=
ecline








1 (un=
allocated number)




604 D=
oes not exist anywhere








127 (=
interworking unspecified)




606 N=
ot acceptable








NOTE 1:    Anonymity D=
isallowed, RFC 5079 [77] refers.


NOTE 2:    No interwor=
king if the O-MGCF previously issued a CANCEL request for the INVITE.


NOTE 3:    The 4xx/5xx=
/6xx SIP responses that are not covered in this table are not interworked.<=
/span>
















 


BR Ale=F0


 






From: Calme, James A (Jim=
) [mailto:jim.calme@alcatel-lucent.com]


Sent: 25. januar 2013 15:23

To: Christer Holmberg; =D0liber Ale=F0; dispatch@ietf.org

Subject: RE: RFC 3398 - problems with ISUP cause mapping






 <=
o:p>


Please reference 3GPP TS 29.163, much work as been done on t=
his document over the last couple years to address mapping concerns.=



 


Jim


 






From:
dispatch-bounces@ietf.org =
[mailto:dispatch-bounces@ietf.=
org]
On Behalf Of Christer Holmberg

Sent: Friday, January 25, 2013 8:18 AM

To: =D0liber Ale=F0; dispatch@i=
etf.org

Subject: Re: [dispatch] RFC 3398 - problems with ISUP cause mapping<=
/span>






 =



Hi,


 


There is no new RFC, but SDOs like ITU-T and 3GPP have specified mapp=
ing which in some cases differs from the RFC.=



 


Regards,


 


Christer


 






From:
dispatch-bounces@ietf.org =
[mailto:dispatch-bounces@ietf.=
org]
On Behalf Of =D0liber Ale=F0

Sent: 25. tammikuuta 2013 9:02

To: dispatch@ietf.org

Subject: Re: [dispatch] RFC 3398 - problems with ISUP cause mapping<=
/span>






 =



Hi,=



 


I'm mobile core network engineer =
working a lot with ISUP to SIP mapping and vice versa.


I come up to an unsolved problem =
with mapping the traffic from ISUP to SIP and back to ISUP.


 


From RFC 3398:


 


ISUP-SIP


  
18 no user responding    =
            &nb=
sp;  408 Request Timeout


  
19 no answer from the user  &nbs=
p;           480 Temporar=
ily unavailable


   20 subscriber absent=
            &nb=
sp;       480 Temporarily unavailable<=
span lang=3D"SL">


  



SIP-ISUP:


  
408 Request timeout    =
;            &n=
bsp; 102 Recovery on timer expiry<=
/o:p>


  
480 Temporarily unavailable  &nb=
sp;        18 No user responding<=
/b>


 


So if I send from ISUP REL-19 and=
 this trafic wents maps to SIP and then back to ISUP, I receive on the othe=
r side ISUP REL-18.


There is the same story with ISUP=
 REL18 mappng to SIP and back to ISUP =96 I will receive ISUP REL.102?!


 


Can you help me with this isue. I=
s there any new RFC how to map this kind of traffic?


 


Thank you,


BR Ales Sliber


 <=
/b>


Ale=F0 =D0liber<=
o:p>


Core network engineer<=
o:p>


Tel:
+386-1-472-8482


W-mobile:
www.mobitel.si



W-fix:
www.telekom.si


Telekom
Slovenije


 






--_000_7B8DC1AC12241143921AC7733AF3C17B1DF55C31US70TWXCHMBA10z_--

From adam@nostrum.com  Mon Jan 28 06:33:50 2013
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8607D21F8694 for ; Mon, 28 Jan 2013 06:33:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.053
X-Spam-Level: 
X-Spam-Status: No, score=-101.053 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXElNcC4Koxu for ; Mon, 28 Jan 2013 06:33:49 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id ACA1821F8467 for ; Mon, 28 Jan 2013 06:33:46 -0800 (PST)
Received: from [192.168.0.159] (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r0SEXchf023429 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Jan 2013 08:33:39 -0600 (CST) (envelope-from adam@nostrum.com)
References: <26300ECDDED68545A78AAC3D98640BF3A157E82F@srexdb14.ts.telekom.si> <7594FB04B1934943A5C02806D1A2204B0CA15E@ESESSMB209.ericsson.se> <7B8DC1AC12241143921AC7733AF3C17B1DF55878@US70TWXCHMBA10.zam.alcatel-lucent.com> <26300ECDDED68545A78AAC3D98640BF3A157F8B6@srexdb14.ts.telekom.si> <7B8DC1AC12241143921AC7733AF3C17B1DF55C31@US70TWXCHMBA10.zam.alcatel-lucent.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <7B8DC1AC12241143921AC7733AF3C17B1DF55C31@US70TWXCHMBA10.zam.alcatel-lucent.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-521E8814-1E67-476F-998C-B8C121CB3149
Content-Transfer-Encoding: 7bit
Message-Id: <13B6E229-4EBB-4086-8889-0CE9DD1E72B0@nostrum.com>
X-Mailer: iPad Mail (10A403)
From: Adam Roach 
Date: Mon, 28 Jan 2013 08:33:39 -0600
To: "Calme, James A (Jim)" 
Received-SPF: pass (shaman.nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism)
Cc: "dispatch@ietf.org" , =?utf-8?Q?=C5=A0liber_Ale=C5=A1?= 
Subject: Re: [dispatch] RFC 3398 - problems with ISUP cause mapping
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Jan 2013 14:33:50 -0000

--Apple-Mail-521E8814-1E67-476F-998C-B8C121CB3149
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Guys, you're doing it wrong. Completely wrong.=20

Go back and read my response from Friday.=20

/a

On Jan 28, 2013, at 8:09, "Calme, James A (Jim)"  wrote:

> True, it is not 100% symmetric.
> If it is required to maintain the original ISUP cause, then I would sugges=
t using the Reason header field.
> Jim
> =20
> From: =C5=A0liber Ale=C5=A1 [mailto:Ales.Sliber@telekom.si]=20
> Sent: Monday, January 28, 2013 3:23 AM
> To: Calme, James A (Jim); Christer Holmberg; dispatch@ietf.org
> Subject: RE: RFC 3398 - problems with ISUP cause mapping
> =20
> Hi,
> =20
> Thank you for reply, but as I can see, from 3GPP TS 29.163 document =E2=80=
=93 there is quite the same story (maby even worst =E2=80=93 because ISUP 18=
 is mapd also in SIP 480 and not in-to SIP-408 as in RFC):
> =20
> Table 9: Receipt of the Release message (REL)
>=20
> =C2=ACSIP Message=20
> =C2=AC REL
> Status code
> Cause parameter
> 404 Not Found
> Cause value No. 1 (unallocated (unassigned) number)
> 500 Server Internal error
> Cause value No 2 (no route to network)
> 500 Server Internal error
> Cause value No 3 (no route to destination)
> 500 Server Internal error
> Cause value No. 4 (Send special information tone)
> 404 Not Found
> Cause value No. 5 (Misdialled trunk prefix)
> 486 Busy Here
> Cause value No. 17 (user busy)
> 480 Temporarily unavailable
> Cause value No 18 (no user responding)
> 480 Temporarily unavailable
> Cause value No 19 (no answer from the user)
> 480 Temporarily unavailable
> Cause value No. 20 (subscriber absent)
> 603 Decline
> Cause value No 21 (call rejected), Location =3D 000 / user (U)
> 480Temporarily unavailable
> Cause value No 21 (call rejected) , Location <> 000 / user (U)
> 410 Gone
> Cause value No 22 (number changed)
> 433 Anonymity Disallowed.(NOTE 1)
> Cause value No. 24 (call rejected due to ACR supplementary service)
> 480 Temporarily unavailable
> Cause value No 25 (Exchange routing error)
> 502 Bad Gateway
> Cause value No 27 (destination out of order)
> 484 Address Incomplete
> Cause value No. 28 invalid number format (address incomplete)
> 500 Server Internal error
> Cause value No 29 (facility rejected)
> 480 Temporarily unavailable
> Cause value No 31 (normal unspecified) (class default) (NOTE 2)
> 486 Busy here if Diagnostics indicator includes the (CCBS indicator =3D CC=
BS possible)
> else 480 Temporarily unavailable
> Cause value in the Class 010 (resource unavailable, Cause value No 34)
> 500 Server Internal error
> Cause value in the Class 010
> (resource unavailable, Cause value No=E2=80=99s. 38, 41, 42, 43, 44, & 47)=
 (47 is class default)
> 500 Server Internal error
> Cause value No 50 (requested facility no subscribed)
> 500 Server Internal error
> Cause value No 57 (bearer capability not authorised)
> 500 Server Internal error
> Cause value No 58 (bearer capability not presently)
> 500 Server Internal error
> Cause value No 63 (service option not available, unspecified)
> (class default)
> 500 Server Internal error
> Cause value in the Class 100 (service or option not implemented, Cause val=
ue No=E2=80=99s. 65, 70 & 79) 79 is class default
> 500 Server Internal error
> Cause value No 88 (incompatible destination)
> 404 Not Found
> Cause value No 91 (invalid transit network selection)
> 500 Server Internal error
> Cause value No 95 (invalid message)
> (class default)
> 500 Server Internal error
> Cause value No 97 (Message type non-existent or not implemented)
> 500 Server Internal error
> Cause value No 99 (information element/parameter non-existent or not imple=
mented))
> 480 Temporarily unavailable
> Cause value No. 102 (recovery on timer expiry)
> 500 Server Internal error
> Cause value No 110 (Message with unrecognised Parameter, discarded)
> 500 Server Internal error
> Cause value No. 111 (protocol error, unspecified)
> (class default)
> 480 Temporarily unavailable
> Cause value No. 127 (interworking unspecified)
> (class default)
> NOTE 1:    Anonymity Disallowed, RFC 5079 [77] refers
> NOTE 2:    Class 1 and class 2 have the same default value.
> =20
> =20
> Table 18: 4xx/5xx/6xx Received on SIP side of O-MGCF
>=20
> =C2=ACREL (cause code)
> =C2=AC4xx/5xx/6xx SIP Message
> 127 (interworking unspecified)
> 400 Bad Request
> 127 (interworking unspecified)
> 401 Unauthorized
> 127 (interworking unspecified)
> 402 Payment Required
> 127 (interworking unspecified)
> 403 Forbidden
> 1 (Unallocated number)
> 404 Not Found
> 127 (interworking unspecified)
> 405 Method Not Allowed
> 127 (interworking unspecified)
> 406 Not Acceptable
> 127 (interworking unspecified)
> 407 Proxy authentication required
> 127 (interworking unspecified)
> 408 Request Timeout
> 22 (Number changed)
> 410 Gone
> 127 (interworking unspecified)
> 413 Request Entity too long
> 127 (interworking unspecified)
> 414 Request-URI too long
> 127 (interworking unspecified)
> 415 Unsupported Media type
> 127 (interworking unspecified)
> 416 Unsupported URI scheme
> 127 (interworking unspecified)
> 420 Bad Extension
> 127 (interworking unspecified)
> 421 Extension required
> 127 (interworking unspecified)
> 423 Interval Too Brief
> 24 (call rejected due to ACR supplementary service)
> 433 Anonymity Disallowed.(NOTE 1)
> 20 Subscriber absent
> 480 Temporarily Unavailable
> 127 (interworking unspecified)
> 481 Call/Transaction does not exist
> 127 (interworking unspecified)
> 482 Loop detected
> 127 (interworking unspecified)
> 483 Too many hops
> 28 (Invalid Number format)
> 484 Address Incomplete
> 127 (interworking unspecified)
> 485 Ambiguous
> 17 (User busy)
> 486 Busy Here
> 127 (Interworking unspecified) or not interworked. (NOTE 2)
> 487 Request terminated
> 127 (interworking unspecified)
> 488 Not acceptable here
> 127 (interworking unspecified)
> 493 Undecipherable
> 127 (interworking unspecified)
> 500 Server Internal error
> 127 (interworking unspecified)
> 501 Not implemented
> 127 (interworking unspecified)
> 502 Bad Gateway
> 127 (interworking unspecified)
> 503 Service Unavailable
> 127 (interworking unspecified)
> 504 Server timeout
> 127 (interworking unspecified)
> 505 Version not supported
> 127 (interworking unspecified)
> 513 Message too large
> 127 (interworking unspecified)
> 580 Precondition failure
> 17 (User busy)
> 600 Busy Everywhere
> 21 (Call rejected)
> 603 Decline
> 1 (unallocated number)
> 604 Does not exist anywhere
> 127 (interworking unspecified)
> 606 Not acceptable
> NOTE 1:    Anonymity Disallowed, RFC 5079 [77] refers.
> NOTE 2:    No interworking if the O-MGCF previously issued a CANCEL reques=
t for the INVITE.
> NOTE 3:    The 4xx/5xx/6xx SIP responses that are not covered in this tabl=
e are not interworked.
> =20
> BR Ale=C5=A1
> =20
> From: Calme, James A (Jim) [mailto:jim.calme@alcatel-lucent.com]=20
> Sent: 25. januar 2013 15:23
> To: Christer Holmberg; =C5=A0liber Ale=C5=A1; dispatch@ietf.org
> Subject: RE: RFC 3398 - problems with ISUP cause mapping
> =20
> Please reference 3GPP TS 29.163, much work as been done on this document o=
ver the last couple years to address mapping concerns.
> =20
> Jim
> =20
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Beha=
lf Of Christer Holmberg
> Sent: Friday, January 25, 2013 8:18 AM
> To: =C5=A0liber Ale=C5=A1; dispatch@ietf.org
> Subject: Re: [dispatch] RFC 3398 - problems with ISUP cause mapping
> =20
> Hi,
> =20
> There is no new RFC, but SDOs like ITU-T and 3GPP have specified mapping w=
hich in some cases differs from the RFC.
> =20
> Regards,
> =20
> Christer
> =20
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Beha=
lf Of =C5=A0liber Ale=C5=A1
> Sent: 25. tammikuuta 2013 9:02
> To: dispatch@ietf.org
> Subject: Re: [dispatch] RFC 3398 - problems with ISUP cause mapping
> =20
> Hi,
> =20
> I'm mobile core network engineer working a lot with ISUP to SIP mapping an=
d vice versa.
> I come up to an unsolved problem with mapping the traffic from ISUP to SIP=
 and back to ISUP.
> =20
> =46rom RFC 3398:
> =20
> ISUP-SIP
>    18 no user responding                   408 Request Timeout
>    19 no answer from the user              480 Temporarily unavailable
>    20 subscriber absent                    480 Temporarily unavailable
>  =20
> SIP-ISUP:
>    408 Request timeout                  102 Recovery on timer expiry
>    480 Temporarily unavailable           18 No user responding
> =20
> So if I send from ISUP REL-19 and this trafic wents maps to SIP and then b=
ack to ISUP, I receive on the other side ISUP REL-18.
> There is the same story with ISUP REL18 mappng to SIP and back to ISUP =E2=
=80=93 I will receive ISUP REL.102?!
> =20
> Can you help me with this isue. Is there any new RFC how to map this kind o=
f traffic?
> =20
> Thank you,
> BR Ales Sliber
> =20
> Ale=C5=A1 =C5=A0liber
> Core network engineer
> Tel: +386-1-472-8482
> W-mobile: www.mobitel.si
> W-fix: www.telekom.si
> Telekom Slovenije
> =20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

--Apple-Mail-521E8814-1E67-476F-998C-B8C121CB3149
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Guys, you're doing it wrong. Completel=
y wrong. 

Go back and read my response from Fri=
day. 

/a

On Jan 28, 2013, at 8:09, "Cal=
me, James A (Jim)" <jim.c=
alme@alcatel-lucent.com> wrote:











True, it is not 100% symmetric.



If it is required to maintain the original ISUP cause, then I=
 would suggest using the Reason header field.


Jim


 






From: =C5=A0liber Ale=C5=A1=
 [mailto:Ales.Sliber@telekom.si]


Sent: Monday, January 28, 2013 3:23 AM

To: Calme, James A (Jim); Christer Holmberg; dispatch@ietf.org

Subject: RE: RFC 3398 - problems with ISUP cause mapping






 


Hi,<=
/o:p>


 


Thank you for reply, but as I can s=
ee, from 3GPP TS 29.163 document =E2=80=93 there is quite the same story (ma=
by even worst =E2=80=93 because ISUP 18 is mapd also in SIP
 480 and not in-to SIP-408 as in RFC):


 








Table 9=
: Receipt of the Release message (REL)










=C2=ACSIP Message





=C2=AC REL








Status code




Cause parameter










404 No=
t Found




Cause v=
alue No. 1 (unallocated (unassigned) number)








500 Se=
rver Internal error




Cause v=
alue No 2 (no route to network)








500 Se=
rver Internal error




Cause v=
alue No 3 (no route to destination)








500 Se=
rver Internal error




Cause value No. 4 (Send special information tone)<=
o:p>








404 No=
t Found




Cause value No. 5 (Misdialled trunk prefix)








486 Bu=
sy Here




Cause v=
alue No. 17 (user busy)








480 Temporarily unavailable




Cause value No 18 (no user res=
ponding)








480 Temporarily unavailable




Cause value No 19 (no answer f=
rom the user)








480 Temporarily unavailable




Cause value No. 20 (subsc=
riber absent)








603 De=
cline




Cause v=
alue No 21 (call rejected), Location =3D 000 / user (U)








480Tem=
porarily unavailable




Cause v=
alue No 21 (call rejected) , Location <> 000 / user (U)








410 Go=
ne




Cause v=
alue No 22 (number changed)








433 An=
onymity Disallowed.(NOTE 1)




Cause v=
alue No. 24 (call rejected due to ACR supplementary service)








480 Te=
mporarily unavailable




Cause v=
alue No 25 (Exchange routing error)








502 Ba=
d Gateway




Cause v=
alue No 27 (destination out of order)








484 Ad=
dress Incomplete




Cause v=
alue No. 28 invalid number format (address incomplete)








500 Se=
rver Internal error




Cause v=
alue No 29 (facility rejected)








480 Te=
mporarily unavailable




Cause v=
alue No 31 (normal unspecified) (class default) (NOTE 2)








486 Bu=
sy here if Diagnostics indicator includes the (CCBS indicator =3D CCBS possi=
ble)


else 4=
80 Temporarily unavailable




Cause v=
alue in the Class 010 (resource unavailable, Cause value No 34)<=
/o:p>








500 Se=
rver Internal error




Cause v=
alue in the Class 010

(resource unavailable, Cause value No=E2=80=99s. 38, 41, 42, 43, 44, & 4=
7) (47 is class default)








500 Se=
rver Internal error




Cause v=
alue No 50 (requested facility no subscribed)








500 Se=
rver Internal error




Cause v=
alue No 57 (bearer capability not authorised)








500 Se=
rver Internal error




Cause v=
alue No 58 (bearer capability not presently)








500 Se=
rver Internal error




Cause v=
alue No 63 (service option not available, unspecified)

(class default)








500 Se=
rver Internal error




Cause v=
alue in the Class 100 (service or option not implemented, Cause value No=E2=80=
=99s. 65, 70 & 79) 79 is class default








500 Se=
rver Internal error




Cause val=
ue No 88 (incompatible destination)








404 No=
t Found




Cause v=
alue No 91 (invalid transit network selection)








500 Se=
rver Internal error




Cause v=
alue No 95 (invalid message)

(class default)








500 Se=
rver Internal error




Cause v=
alue No 97 (Message t=
ype non-existent or not implemented)=









500 Se=
rver Internal error




Cause v=
alue No 99 (information element/parameter non-existent or not implemented))<=
/span>








480 Te=
mporarily unavailable




Cause v=
alue No. 102 (recovery on timer expiry)








500 Se=
rver Internal error




Cause v=
alue No 110 (Message with unrecognised Parameter, discarded)








500 Se=
rver Internal error




Cause v=
alue No. 111 (protocol error, unspecified)

(class default)








480 Te=
mporarily unavailable




Cause v=
alue No. 127 (interworking unspecified)

(class default)








NOTE 1:    Anonymity Di=
sallowed, RFC 5079 [77] refers


NOTE 2:    Class 1 and c=
lass 2 have the same default value.










 


 




Table 1=
8: 4xx/5xx/6xx Received on SIP side of O-MGCF










=C2=ACREL (cause code)




=C2=AC4xx/5xx/6xx SIP Message<=
/span>










127 (i=
nterworking unspecified)




400 Ba=
d Request








127 (i=
nterworking unspecified)




401 Un=
authorized








127 (i=
nterworking unspecified)




402 Pa=
yment Required








127 (i=
nterworking unspecified)




403 Fo=
rbidden








1 (Una=
llocated number)




404 No=
t Found








127 (i=
nterworking unspecified)




405 Me=
thod Not Allowed








127 (i=
nterworking unspecified)




406 No=
t Acceptable








127 (i=
nterworking unspecified)




407 Pr=
oxy authentication required








127 (interworking unspecified)=





408 Request Timeout=









22 (Nu=
mber changed)




410 Go=
ne








127 (i=
nterworking unspecified)




413 Re=
quest Entity too long








127 (i=
nterworking unspecified)




414 Re=
quest-URI too long








127 (i=
nterworking unspecified)




415 Un=
supported Media type








127 (i=
nterworking unspecified)




416 Un=
supported URI scheme








127 (i=
nterworking unspecified)




420 Ba=
d Extension








127 (i=
nterworking unspecified)




421 Ex=
tension required








127 (i=
nterworking unspecified)




423 In=
terval Too Brief








24 (ca=
ll rejected due to ACR supplementary service)




433 An=
onymity Disallowed.(NOTE 1)








20 Subscriber absent




480 Temporarily Unavailable








127 (i=
nterworking unspecified)




481 Ca=
ll/Transaction does not exist








127 (i=
nterworking unspecified)




482 Lo=
op detected








127 (i=
nterworking unspecified)




483 To=
o many hops








28 (In=
valid Number format)




484 Ad=
dress Incomplete








127 (i=
nterworking unspecified)




485 Am=
biguous








17 (Us=
er busy)




486 Bu=
sy Here








127 (I=
nterworking unspecified) or not interworked. (NOTE 2)




487 Re=
quest terminated








127 (i=
nterworking unspecified)




488 No=
t acceptable here








127 (i=
nterworking unspecified)




493 Un=
decipherable








127 (i=
nterworking unspecified)




500 Se=
rver Internal error








127 (i=
nterworking unspecified)




501 No=
t implemented








127 (i=
nterworking unspecified)




502 Ba=
d Gateway








127 (i=
nterworking unspecified)




503 Se=
rvice Unavailable








127 (i=
nterworking unspecified)




504 Se=
rver timeout








127 (i=
nterworking unspecified)




505 Ve=
rsion not supported








127 (i=
nterworking unspecified)




513 Me=
ssage too large








127 (i=
nterworking unspecified)




580 Pr=
econdition failure








17 (Us=
er busy)




600 Bu=
sy Everywhere








21 (Ca=
ll rejected)




603 De=
cline








1 (una=
llocated number)




604 Do=
es not exist anywhere








127 (i=
nterworking unspecified)




606 No=
t acceptable








NOTE 1:    Anonymity Di=
sallowed, RFC 5079 [77] refers.


NOTE 2:    No interwork=
ing if the O-MGCF previously issued a CANCEL request for the INVITE.<=
o:p>


NOTE 3:    The 4xx/5xx/=
6xx SIP responses that are not covered in this table are not interworked.
















 


BR Ale=C5=A1


 






From: Calme, James A (Jim)=
 [mailto:jim.calme@alcatel-l=
ucent.com]


Sent: 25. januar 2013 15:23

To: Christer Holmberg; =C5=A0liber Ale=C5=A1; dispatch@ietf.org

Subject: RE: RFC 3398 - problems with ISUP cause mapping






 


Please reference 3GPP TS 29.163, much work as been done on th=
is document over the last couple years to address mapping concerns.


 


Jim


 






From:
dispatch-bounces@ietf.org [=
mailto:dispatch-bounces@ietf.or=
g]
On Behalf Of Christer Holmberg

Sent: Friday, January 25, 2013 8:18 AM

To: =C5=A0liber Ale=C5=A1; dispa=
tch@ietf.org

Subject: Re: [dispatch] RFC 3398 - problems with ISUP cause mapping






 <=
o:p>


Hi,


 


There is no new RFC, but SDOs like ITU-T and 3GPP have specified mappin=
g which in some cases differs from the RFC.


 


Regards,


 


Christer


 






From:
dispatch-bounces@ietf.org [=
mailto:dispatch-bounces@ietf.or=
g]
On Behalf Of =C5=A0liber Ale=C5=A1

Sent: 25. tammikuuta 2013 9:02

To: dispatch@ietf.org

Subject: Re: [dispatch] RFC 3398 - problems with ISUP cause mapping






 <=
o:p>


Hi,<=
/o:p>


 


I'm mobile core network engineer w=
orking a lot with ISUP to SIP mapping and vice versa.


I come up to an unsolved problem w=
ith mapping the traffic from ISUP to SIP and back to ISUP.


 


=46rom RFC 3398:


 


ISUP-SIP


  
18 no user responding    &=
nbsp;            =
;  408 Request Timeout


  
19 no answer from the user   =
;           480 Temporaril=
y unavailable


   20 subscriber absent&=
nbsp;            =
;       480 Temporarily unavailable


  



SIP-ISUP:


  
408 Request timeout    =
            &nbs=
p; 102 Recovery on timer expiry


  
480 Temporarily unavailable  &nbs=
p;        18 No user responding


 


So if I send from ISUP REL-19 and t=
his trafic wents maps to SIP and then back to ISUP, I receive on the other s=
ide ISUP REL-18.


There is the same story with ISUP R=
EL18 mappng to SIP and back to ISUP =E2=80=93 I will receive ISUP REL.102?!<=
/span>


 


Can you help me with this isue. Is=
 there any new RFC how to map this kind of traffic?=



 


Thank you,


BR Ales Sliber


 


Ale=C5=A1 =C5=A0liber


Core network engineer=



Tel:
+386-1-472-8482


W-mobile:
www.mobitel.si



W-fix:
www.telekom.si


Telekom
Slovenije


 






____________________=
___________________________
dispatch mailing list
=
dispatch@ietf.org
<=
span>https://www.=
ietf.org/mailman/listinfo/dispatch
<=
/html>=

--Apple-Mail-521E8814-1E67-476F-998C-B8C121CB3149--

From christer.holmberg@ericsson.com  Mon Jan 28 06:44:15 2013
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 876D321F855A for ; Mon, 28 Jan 2013 06:44:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.21
X-Spam-Level: 
X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[AWL=0.038,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hedBF8SRKuk8 for ; Mon, 28 Jan 2013 06:44:13 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id E860121F84BC for ; Mon, 28 Jan 2013 06:44:11 -0800 (PST)
X-AuditID: c1b4fb25-b7f366d000004d10-3d-51068eba5691
Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id DC.00.19728.ABE86015; Mon, 28 Jan 2013 15:44:10 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.195]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0318.004; Mon, 28 Jan 2013 15:44:10 +0100
From: Christer Holmberg 
To: Adam Roach , "Calme, James A (Jim)" 
Thread-Topic: [dispatch] RFC 3398 - problems with ISUP cause mapping
Thread-Index: Ac36L/Ouvi96ppcBSLCYfqPfGqmxGAAl8IiQAACHohAADzCpEAAAKSbQAIxAG4AACh/T0P//9rKA///s6sA=
Date: Mon, 28 Jan 2013 14:44:09 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B0CB9CA@ESESSMB209.ericsson.se>
References: <26300ECDDED68545A78AAC3D98640BF3A157E82F@srexdb14.ts.telekom.si> <7594FB04B1934943A5C02806D1A2204B0CA15E@ESESSMB209.ericsson.se> <7B8DC1AC12241143921AC7733AF3C17B1DF55878@US70TWXCHMBA10.zam.alcatel-lucent.com> <26300ECDDED68545A78AAC3D98640BF3A157F8B6@srexdb14.ts.telekom.si> <7B8DC1AC12241143921AC7733AF3C17B1DF55C31@US70TWXCHMBA10.zam.alcatel-lucent.com> <13B6E229-4EBB-4086-8889-0CE9DD1E72B0@nostrum.com>
In-Reply-To: <13B6E229-4EBB-4086-8889-0CE9DD1E72B0@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.17]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B0CB9CAESESSMB209ericsso_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyM+Jvre6uPrZAgxP71Sz2/F3EbjHt9CUm i6WTFrBaXJi0hN2BxaP12V5WjyVLfjJ5zNr5hMVj845G9gCWKC6blNSczLLUIn27BK6MrW/v MBYs+MdWsWyTRQPjlOdsXYycHBICJhKzDs2EssUkLtxbD2YLCRxilLh9zKCLkQvIXsIosefr duYuRg4ONgELie5/2iCmiECUxLJ2RpByZoEMiUNLr4DZwgLOEs/2fWIBsUUEXCS+Pt4AZSdJ LJp8AGw8i4CqxL73P9hBbF4Bb4mm1Y3sEKvWMUtsuPwMrIhTwF5iQstcsCJGoNu+n1rDBLFM XOLWk/lMEDcLSCzZc54ZwhaVePn4HyvIbRICihLL++UgyvMlWmcvYoXYJShxcuYTlgmMorOQ TJqFpGwWkrJZQJOYBTQl1u/ShyhRlJjS/ZAdwtaQaJ0zlx1ZfAEj+ypG9tzEzJz0cqNNjMC4 O7jlt+oOxjvnRA4xSnOwKInzhrteCBASSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAOFM/MOnr jF9rHDe2HPku/VT06r9VvwQjWd5u0pF75J3B+vLGH4uD2zj35Mw42bP7+/botzpWzl951nrP aJl5LZVbObvfXveQgrnR58Wq/e/e/i7ytlgRt2K5kisDx0fdo6t2F1xzjZiVZKm1ffdvt8lt JvGFlW6BKR+Lk5bleeurPY8LiT48QYmlOCPRUIu5qDgRAGk3bSWJAgAA
Cc: "dispatch@ietf.org" , =?utf-8?B?xaBsaWJlciBBbGXFoQ==?= 
Subject: Re: [dispatch] RFC 3398 - problems with ISUP cause mapping
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Jan 2013 14:44:15 -0000

--_000_7594FB04B1934943A5C02806D1A2204B0CB9CAESESSMB209ericsso_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGksDQoNCj5HdXlzLCB5b3UncmUgZG9pbmcgaXQgd3JvbmcuIENvbXBsZXRlbHkgd3JvbmcuDQo+
DQo+R28gYmFjayBhbmQgcmVhZCBteSByZXNwb25zZSBmcm9tIEZyaWRheS4NCg0KTWF5YmUgSeKA
mXZlIG1pc3NlZCBzb21ldGhpbmcsIGJ1dCBJIGRvbuKAmXQgdGhpbmsgSVNVUCB0dW5uZWxpbmcg
aXMgdXNlZCBpbiB0aGUgY2FzZSBiZWluZyBkaXNjdXNzZWQuDQoNClJlZ2FyZHMsDQoNCkNocmlz
dGVyDQoNCg0KDQpPbiBKYW4gMjgsIDIwMTMsIGF0IDg6MDksICJDYWxtZSwgSmFtZXMgQSAoSmlt
KSIgPGppbS5jYWxtZUBhbGNhdGVsLWx1Y2VudC5jb208bWFpbHRvOmppbS5jYWxtZUBhbGNhdGVs
LWx1Y2VudC5jb20+PiB3cm90ZToNClRydWUsIGl0IGlzIG5vdCAxMDAlIHN5bW1ldHJpYy4NCklm
IGl0IGlzIHJlcXVpcmVkIHRvIG1haW50YWluIHRoZSBvcmlnaW5hbCBJU1VQIGNhdXNlLCB0aGVu
IEkgd291bGQgc3VnZ2VzdCB1c2luZyB0aGUgUmVhc29uIGhlYWRlciBmaWVsZC4NCkppbQ0KDQpG
cm9tOiDFoGxpYmVyIEFsZcWhIFttYWlsdG86QWxlcy5TbGliZXJAdGVsZWtvbS5zaV0NClNlbnQ6
IE1vbmRheSwgSmFudWFyeSAyOCwgMjAxMyAzOjIzIEFNDQpUbzogQ2FsbWUsIEphbWVzIEEgKEpp
bSk7IENocmlzdGVyIEhvbG1iZXJnOyBkaXNwYXRjaEBpZXRmLm9yZzxtYWlsdG86ZGlzcGF0Y2hA
aWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogUkZDIDMzOTggLSBwcm9ibGVtcyB3aXRoIElTVVAgY2F1
c2UgbWFwcGluZw0KDQpIaSwNCg0KVGhhbmsgeW91IGZvciByZXBseSwgYnV0IGFzIEkgY2FuIHNl
ZSwgZnJvbSAzR1BQIFRTIDI5LjE2MyBkb2N1bWVudCDigJMgdGhlcmUgaXMgcXVpdGUgdGhlIHNh
bWUgc3RvcnkgKG1hYnkgZXZlbiB3b3JzdCDigJMgYmVjYXVzZSBJU1VQIDE4IGlzIG1hcGQgYWxz
byBpbiBTSVAgNDgwIGFuZCBub3QgaW4tdG8gU0lQLTQwOCBhcyBpbiBSRkMpOg0KDQoNClRhYmxl
IDk6IFJlY2VpcHQgb2YgdGhlIFJlbGVhc2UgbWVzc2FnZSAoUkVMKQ0KDQrigKJTSVAgTWVzc2Fn
ZQ0KDQoNCuKAoiBSRUwNCg0KDQpTdGF0dXMgY29kZQ0KDQoNCkNhdXNlIHBhcmFtZXRlcg0KDQoN
CjQwNCBOb3QgRm91bmQNCg0KDQpDYXVzZSB2YWx1ZSBOby4gMSAodW5hbGxvY2F0ZWQgKHVuYXNz
aWduZWQpIG51bWJlcikNCg0KDQo1MDAgU2VydmVyIEludGVybmFsIGVycm9yDQoNCg0KQ2F1c2Ug
dmFsdWUgTm8gMiAobm8gcm91dGUgdG8gbmV0d29yaykNCg0KDQo1MDAgU2VydmVyIEludGVybmFs
IGVycm9yDQoNCg0KQ2F1c2UgdmFsdWUgTm8gMyAobm8gcm91dGUgdG8gZGVzdGluYXRpb24pDQoN
Cg0KNTAwIFNlcnZlciBJbnRlcm5hbCBlcnJvcg0KDQoNCkNhdXNlIHZhbHVlIE5vLiA0IChTZW5k
IHNwZWNpYWwgaW5mb3JtYXRpb24gdG9uZSkNCg0KDQo0MDQgTm90IEZvdW5kDQoNCg0KQ2F1c2Ug
dmFsdWUgTm8uIDUgKE1pc2RpYWxsZWQgdHJ1bmsgcHJlZml4KQ0KDQoNCjQ4NiBCdXN5IEhlcmUN
Cg0KDQpDYXVzZSB2YWx1ZSBOby4gMTcgKHVzZXIgYnVzeSkNCg0KDQo0ODAgVGVtcG9yYXJpbHkg
dW5hdmFpbGFibGUNCg0KDQpDYXVzZSB2YWx1ZSBObyAxOCAobm8gdXNlciByZXNwb25kaW5nKQ0K
DQoNCjQ4MCBUZW1wb3JhcmlseSB1bmF2YWlsYWJsZQ0KDQoNCkNhdXNlIHZhbHVlIE5vIDE5IChu
byBhbnN3ZXIgZnJvbSB0aGUgdXNlcikNCg0KDQo0ODAgVGVtcG9yYXJpbHkgdW5hdmFpbGFibGUN
Cg0KDQpDYXVzZSB2YWx1ZSBOby4gMjAgKHN1YnNjcmliZXIgYWJzZW50KQ0KDQoNCjYwMyBEZWNs
aW5lDQoNCg0KQ2F1c2UgdmFsdWUgTm8gMjEgKGNhbGwgcmVqZWN0ZWQpLCBMb2NhdGlvbiA9IDAw
MCAvIHVzZXIgKFUpDQoNCg0KNDgwVGVtcG9yYXJpbHkgdW5hdmFpbGFibGUNCg0KDQpDYXVzZSB2
YWx1ZSBObyAyMSAoY2FsbCByZWplY3RlZCkgLCBMb2NhdGlvbiA8PiAwMDAgLyB1c2VyIChVKQ0K
DQoNCjQxMCBHb25lDQoNCg0KQ2F1c2UgdmFsdWUgTm8gMjIgKG51bWJlciBjaGFuZ2VkKQ0KDQoN
CjQzMyBBbm9ueW1pdHkgRGlzYWxsb3dlZC4oTk9URSAxKQ0KDQoNCkNhdXNlIHZhbHVlIE5vLiAy
NCAoY2FsbCByZWplY3RlZCBkdWUgdG8gQUNSIHN1cHBsZW1lbnRhcnkgc2VydmljZSkNCg0KDQo0
ODAgVGVtcG9yYXJpbHkgdW5hdmFpbGFibGUNCg0KDQpDYXVzZSB2YWx1ZSBObyAyNSAoRXhjaGFu
Z2Ugcm91dGluZyBlcnJvcikNCg0KDQo1MDIgQmFkIEdhdGV3YXkNCg0KDQpDYXVzZSB2YWx1ZSBO
byAyNyAoZGVzdGluYXRpb24gb3V0IG9mIG9yZGVyKQ0KDQoNCjQ4NCBBZGRyZXNzIEluY29tcGxl
dGUNCg0KDQpDYXVzZSB2YWx1ZSBOby4gMjggaW52YWxpZCBudW1iZXIgZm9ybWF0IChhZGRyZXNz
IGluY29tcGxldGUpDQoNCg0KNTAwIFNlcnZlciBJbnRlcm5hbCBlcnJvcg0KDQoNCkNhdXNlIHZh
bHVlIE5vIDI5IChmYWNpbGl0eSByZWplY3RlZCkNCg0KDQo0ODAgVGVtcG9yYXJpbHkgdW5hdmFp
bGFibGUNCg0KDQpDYXVzZSB2YWx1ZSBObyAzMSAobm9ybWFsIHVuc3BlY2lmaWVkKSAoY2xhc3Mg
ZGVmYXVsdCkgKE5PVEUgMikNCg0KDQo0ODYgQnVzeSBoZXJlIGlmIERpYWdub3N0aWNzIGluZGlj
YXRvciBpbmNsdWRlcyB0aGUgKENDQlMgaW5kaWNhdG9yID0gQ0NCUyBwb3NzaWJsZSkNCg0KZWxz
ZSA0ODAgVGVtcG9yYXJpbHkgdW5hdmFpbGFibGUNCg0KDQpDYXVzZSB2YWx1ZSBpbiB0aGUgQ2xh
c3MgMDEwIChyZXNvdXJjZSB1bmF2YWlsYWJsZSwgQ2F1c2UgdmFsdWUgTm8gMzQpDQoNCg0KNTAw
IFNlcnZlciBJbnRlcm5hbCBlcnJvcg0KDQoNCkNhdXNlIHZhbHVlIGluIHRoZSBDbGFzcyAwMTAN
CihyZXNvdXJjZSB1bmF2YWlsYWJsZSwgQ2F1c2UgdmFsdWUgTm/igJlzLiAzOCwgNDEsIDQyLCA0
MywgNDQsICYgNDcpICg0NyBpcyBjbGFzcyBkZWZhdWx0KQ0KDQoNCjUwMCBTZXJ2ZXIgSW50ZXJu
YWwgZXJyb3INCg0KDQpDYXVzZSB2YWx1ZSBObyA1MCAocmVxdWVzdGVkIGZhY2lsaXR5IG5vIHN1
YnNjcmliZWQpDQoNCg0KNTAwIFNlcnZlciBJbnRlcm5hbCBlcnJvcg0KDQoNCkNhdXNlIHZhbHVl
IE5vIDU3IChiZWFyZXIgY2FwYWJpbGl0eSBub3QgYXV0aG9yaXNlZCkNCg0KDQo1MDAgU2VydmVy
IEludGVybmFsIGVycm9yDQoNCg0KQ2F1c2UgdmFsdWUgTm8gNTggKGJlYXJlciBjYXBhYmlsaXR5
IG5vdCBwcmVzZW50bHkpDQoNCg0KNTAwIFNlcnZlciBJbnRlcm5hbCBlcnJvcg0KDQoNCkNhdXNl
IHZhbHVlIE5vIDYzIChzZXJ2aWNlIG9wdGlvbiBub3QgYXZhaWxhYmxlLCB1bnNwZWNpZmllZCkN
CihjbGFzcyBkZWZhdWx0KQ0KDQoNCjUwMCBTZXJ2ZXIgSW50ZXJuYWwgZXJyb3INCg0KDQpDYXVz
ZSB2YWx1ZSBpbiB0aGUgQ2xhc3MgMTAwIChzZXJ2aWNlIG9yIG9wdGlvbiBub3QgaW1wbGVtZW50
ZWQsIENhdXNlIHZhbHVlIE5v4oCZcy4gNjUsIDcwICYgNzkpIDc5IGlzIGNsYXNzIGRlZmF1bHQN
Cg0KDQo1MDAgU2VydmVyIEludGVybmFsIGVycm9yDQoNCg0KQ2F1c2UgdmFsdWUgTm8gODggKGlu
Y29tcGF0aWJsZSBkZXN0aW5hdGlvbikNCg0KDQo0MDQgTm90IEZvdW5kDQoNCg0KQ2F1c2UgdmFs
dWUgTm8gOTEgKGludmFsaWQgdHJhbnNpdCBuZXR3b3JrIHNlbGVjdGlvbikNCg0KDQo1MDAgU2Vy
dmVyIEludGVybmFsIGVycm9yDQoNCg0KQ2F1c2UgdmFsdWUgTm8gOTUgKGludmFsaWQgbWVzc2Fn
ZSkNCihjbGFzcyBkZWZhdWx0KQ0KDQoNCjUwMCBTZXJ2ZXIgSW50ZXJuYWwgZXJyb3INCg0KDQpD
YXVzZSB2YWx1ZSBObyA5NyAoTWVzc2FnZSB0eXBlIG5vbi1leGlzdGVudCBvciBub3QgaW1wbGVt
ZW50ZWQpDQoNCg0KNTAwIFNlcnZlciBJbnRlcm5hbCBlcnJvcg0KDQoNCkNhdXNlIHZhbHVlIE5v
IDk5IChpbmZvcm1hdGlvbiBlbGVtZW50L3BhcmFtZXRlciBub24tZXhpc3RlbnQgb3Igbm90IGlt
cGxlbWVudGVkKSkNCg0KDQo0ODAgVGVtcG9yYXJpbHkgdW5hdmFpbGFibGUNCg0KDQpDYXVzZSB2
YWx1ZSBOby4gMTAyIChyZWNvdmVyeSBvbiB0aW1lciBleHBpcnkpDQoNCg0KNTAwIFNlcnZlciBJ
bnRlcm5hbCBlcnJvcg0KDQoNCkNhdXNlIHZhbHVlIE5vIDExMCAoTWVzc2FnZSB3aXRoIHVucmVj
b2duaXNlZCBQYXJhbWV0ZXIsIGRpc2NhcmRlZCkNCg0KDQo1MDAgU2VydmVyIEludGVybmFsIGVy
cm9yDQoNCg0KQ2F1c2UgdmFsdWUgTm8uIDExMSAocHJvdG9jb2wgZXJyb3IsIHVuc3BlY2lmaWVk
KQ0KKGNsYXNzIGRlZmF1bHQpDQoNCg0KNDgwIFRlbXBvcmFyaWx5IHVuYXZhaWxhYmxlDQoNCg0K
Q2F1c2UgdmFsdWUgTm8uIDEyNyAoaW50ZXJ3b3JraW5nIHVuc3BlY2lmaWVkKQ0KKGNsYXNzIGRl
ZmF1bHQpDQoNCg0KTk9URSAxOiAgICBBbm9ueW1pdHkgRGlzYWxsb3dlZCwgUkZDIDUwNzkgWzc3
XSByZWZlcnMNCg0KTk9URSAyOiAgICBDbGFzcyAxIGFuZCBjbGFzcyAyIGhhdmUgdGhlIHNhbWUg
ZGVmYXVsdCB2YWx1ZS4NCg0KDQoNCg0KDQpUYWJsZSAxODogNHh4LzV4eC82eHggUmVjZWl2ZWQg
b24gU0lQIHNpZGUgb2YgTy1NR0NGDQoNCuKAolJFTCAoY2F1c2UgY29kZSkNCg0KDQrigKI0eHgv
NXh4LzZ4eCBTSVAgTWVzc2FnZQ0KDQoNCjEyNyAoaW50ZXJ3b3JraW5nIHVuc3BlY2lmaWVkKQ0K
DQoNCjQwMCBCYWQgUmVxdWVzdA0KDQoNCjEyNyAoaW50ZXJ3b3JraW5nIHVuc3BlY2lmaWVkKQ0K
DQoNCjQwMSBVbmF1dGhvcml6ZWQNCg0KDQoxMjcgKGludGVyd29ya2luZyB1bnNwZWNpZmllZCkN
Cg0KDQo0MDIgUGF5bWVudCBSZXF1aXJlZA0KDQoNCjEyNyAoaW50ZXJ3b3JraW5nIHVuc3BlY2lm
aWVkKQ0KDQoNCjQwMyBGb3JiaWRkZW4NCg0KDQoxIChVbmFsbG9jYXRlZCBudW1iZXIpDQoNCg0K
NDA0IE5vdCBGb3VuZA0KDQoNCjEyNyAoaW50ZXJ3b3JraW5nIHVuc3BlY2lmaWVkKQ0KDQoNCjQw
NSBNZXRob2QgTm90IEFsbG93ZWQNCg0KDQoxMjcgKGludGVyd29ya2luZyB1bnNwZWNpZmllZCkN
Cg0KDQo0MDYgTm90IEFjY2VwdGFibGUNCg0KDQoxMjcgKGludGVyd29ya2luZyB1bnNwZWNpZmll
ZCkNCg0KDQo0MDcgUHJveHkgYXV0aGVudGljYXRpb24gcmVxdWlyZWQNCg0KDQoxMjcgKGludGVy
d29ya2luZyB1bnNwZWNpZmllZCkNCg0KDQo0MDggUmVxdWVzdCBUaW1lb3V0DQoNCg0KMjIgKE51
bWJlciBjaGFuZ2VkKQ0KDQoNCjQxMCBHb25lDQoNCg0KMTI3IChpbnRlcndvcmtpbmcgdW5zcGVj
aWZpZWQpDQoNCg0KNDEzIFJlcXVlc3QgRW50aXR5IHRvbyBsb25nDQoNCg0KMTI3IChpbnRlcndv
cmtpbmcgdW5zcGVjaWZpZWQpDQoNCg0KNDE0IFJlcXVlc3QtVVJJIHRvbyBsb25nDQoNCg0KMTI3
IChpbnRlcndvcmtpbmcgdW5zcGVjaWZpZWQpDQoNCg0KNDE1IFVuc3VwcG9ydGVkIE1lZGlhIHR5
cGUNCg0KDQoxMjcgKGludGVyd29ya2luZyB1bnNwZWNpZmllZCkNCg0KDQo0MTYgVW5zdXBwb3J0
ZWQgVVJJIHNjaGVtZQ0KDQoNCjEyNyAoaW50ZXJ3b3JraW5nIHVuc3BlY2lmaWVkKQ0KDQoNCjQy
MCBCYWQgRXh0ZW5zaW9uDQoNCg0KMTI3IChpbnRlcndvcmtpbmcgdW5zcGVjaWZpZWQpDQoNCg0K
NDIxIEV4dGVuc2lvbiByZXF1aXJlZA0KDQoNCjEyNyAoaW50ZXJ3b3JraW5nIHVuc3BlY2lmaWVk
KQ0KDQoNCjQyMyBJbnRlcnZhbCBUb28gQnJpZWYNCg0KDQoyNCAoY2FsbCByZWplY3RlZCBkdWUg
dG8gQUNSIHN1cHBsZW1lbnRhcnkgc2VydmljZSkNCg0KDQo0MzMgQW5vbnltaXR5IERpc2FsbG93
ZWQuKE5PVEUgMSkNCg0KDQoyMCBTdWJzY3JpYmVyIGFic2VudA0KDQoNCjQ4MCBUZW1wb3Jhcmls
eSBVbmF2YWlsYWJsZQ0KDQoNCjEyNyAoaW50ZXJ3b3JraW5nIHVuc3BlY2lmaWVkKQ0KDQoNCjQ4
MSBDYWxsL1RyYW5zYWN0aW9uIGRvZXMgbm90IGV4aXN0DQoNCg0KMTI3IChpbnRlcndvcmtpbmcg
dW5zcGVjaWZpZWQpDQoNCg0KNDgyIExvb3AgZGV0ZWN0ZWQNCg0KDQoxMjcgKGludGVyd29ya2lu
ZyB1bnNwZWNpZmllZCkNCg0KDQo0ODMgVG9vIG1hbnkgaG9wcw0KDQoNCjI4IChJbnZhbGlkIE51
bWJlciBmb3JtYXQpDQoNCg0KNDg0IEFkZHJlc3MgSW5jb21wbGV0ZQ0KDQoNCjEyNyAoaW50ZXJ3
b3JraW5nIHVuc3BlY2lmaWVkKQ0KDQoNCjQ4NSBBbWJpZ3VvdXMNCg0KDQoxNyAoVXNlciBidXN5
KQ0KDQoNCjQ4NiBCdXN5IEhlcmUNCg0KDQoxMjcgKEludGVyd29ya2luZyB1bnNwZWNpZmllZCkg
b3Igbm90IGludGVyd29ya2VkLiAoTk9URSAyKQ0KDQoNCjQ4NyBSZXF1ZXN0IHRlcm1pbmF0ZWQN
Cg0KDQoxMjcgKGludGVyd29ya2luZyB1bnNwZWNpZmllZCkNCg0KDQo0ODggTm90IGFjY2VwdGFi
bGUgaGVyZQ0KDQoNCjEyNyAoaW50ZXJ3b3JraW5nIHVuc3BlY2lmaWVkKQ0KDQoNCjQ5MyBVbmRl
Y2lwaGVyYWJsZQ0KDQoNCjEyNyAoaW50ZXJ3b3JraW5nIHVuc3BlY2lmaWVkKQ0KDQoNCjUwMCBT
ZXJ2ZXIgSW50ZXJuYWwgZXJyb3INCg0KDQoxMjcgKGludGVyd29ya2luZyB1bnNwZWNpZmllZCkN
Cg0KDQo1MDEgTm90IGltcGxlbWVudGVkDQoNCg0KMTI3IChpbnRlcndvcmtpbmcgdW5zcGVjaWZp
ZWQpDQoNCg0KNTAyIEJhZCBHYXRld2F5DQoNCg0KMTI3IChpbnRlcndvcmtpbmcgdW5zcGVjaWZp
ZWQpDQoNCg0KNTAzIFNlcnZpY2UgVW5hdmFpbGFibGUNCg0KDQoxMjcgKGludGVyd29ya2luZyB1
bnNwZWNpZmllZCkNCg0KDQo1MDQgU2VydmVyIHRpbWVvdXQNCg0KDQoxMjcgKGludGVyd29ya2lu
ZyB1bnNwZWNpZmllZCkNCg0KDQo1MDUgVmVyc2lvbiBub3Qgc3VwcG9ydGVkDQoNCg0KMTI3IChp
bnRlcndvcmtpbmcgdW5zcGVjaWZpZWQpDQoNCg0KNTEzIE1lc3NhZ2UgdG9vIGxhcmdlDQoNCg0K
MTI3IChpbnRlcndvcmtpbmcgdW5zcGVjaWZpZWQpDQoNCg0KNTgwIFByZWNvbmRpdGlvbiBmYWls
dXJlDQoNCg0KMTcgKFVzZXIgYnVzeSkNCg0KDQo2MDAgQnVzeSBFdmVyeXdoZXJlDQoNCg0KMjEg
KENhbGwgcmVqZWN0ZWQpDQoNCg0KNjAzIERlY2xpbmUNCg0KDQoxICh1bmFsbG9jYXRlZCBudW1i
ZXIpDQoNCg0KNjA0IERvZXMgbm90IGV4aXN0IGFueXdoZXJlDQoNCg0KMTI3IChpbnRlcndvcmtp
bmcgdW5zcGVjaWZpZWQpDQoNCg0KNjA2IE5vdCBhY2NlcHRhYmxlDQoNCg0KTk9URSAxOiAgICBB
bm9ueW1pdHkgRGlzYWxsb3dlZCwgUkZDIDUwNzkgWzc3XSByZWZlcnMuDQoNCk5PVEUgMjogICAg
Tm8gaW50ZXJ3b3JraW5nIGlmIHRoZSBPLU1HQ0YgcHJldmlvdXNseSBpc3N1ZWQgYSBDQU5DRUwg
cmVxdWVzdCBmb3IgdGhlIElOVklURS4NCg0KTk9URSAzOiAgICBUaGUgNHh4LzV4eC82eHggU0lQ
IHJlc3BvbnNlcyB0aGF0IGFyZSBub3QgY292ZXJlZCBpbiB0aGlzIHRhYmxlIGFyZSBub3QgaW50
ZXJ3b3JrZWQuDQoNCg0KDQpCUiBBbGXFoQ0KDQpGcm9tOiBDYWxtZSwgSmFtZXMgQSAoSmltKSBb
bWFpbHRvOmppbS5jYWxtZUBhbGNhdGVsLWx1Y2VudC5jb21dDQpTZW50OiAyNS4gamFudWFyIDIw
MTMgMTU6MjMNClRvOiBDaHJpc3RlciBIb2xtYmVyZzsgxaBsaWJlciBBbGXFoTsgZGlzcGF0Y2hA
aWV0Zi5vcmc8bWFpbHRvOmRpc3BhdGNoQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFJGQyAzMzk4
IC0gcHJvYmxlbXMgd2l0aCBJU1VQIGNhdXNlIG1hcHBpbmcNCg0KUGxlYXNlIHJlZmVyZW5jZSAz
R1BQIFRTIDI5LjE2MywgbXVjaCB3b3JrIGFzIGJlZW4gZG9uZSBvbiB0aGlzIGRvY3VtZW50IG92
ZXIgdGhlIGxhc3QgY291cGxlIHllYXJzIHRvIGFkZHJlc3MgbWFwcGluZyBjb25jZXJucy4NCg0K
SmltDQoNCkZyb206IGRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmRpc3BhdGNoLWJv
dW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86ZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo
YWxmIE9mIENocmlzdGVyIEhvbG1iZXJnDQpTZW50OiBGcmlkYXksIEphbnVhcnkgMjUsIDIwMTMg
ODoxOCBBTQ0KVG86IMWgbGliZXIgQWxlxaE7IGRpc3BhdGNoQGlldGYub3JnPG1haWx0bzpkaXNw
YXRjaEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbZGlzcGF0Y2hdIFJGQyAzMzk4IC0gcHJvYmxl
bXMgd2l0aCBJU1VQIGNhdXNlIG1hcHBpbmcNCg0KSGksDQoNClRoZXJlIGlzIG5vIG5ldyBSRkMs
IGJ1dCBTRE9zIGxpa2UgSVRVLVQgYW5kIDNHUFAgaGF2ZSBzcGVjaWZpZWQgbWFwcGluZyB3aGlj
aCBpbiBzb21lIGNhc2VzIGRpZmZlcnMgZnJvbSB0aGUgUkZDLg0KDQpSZWdhcmRzLA0KDQpDaHJp
c3Rlcg0KDQpGcm9tOiBkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpkaXNwYXRjaC1i
b3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl
aGFsZiBPZiDFoGxpYmVyIEFsZcWhDQpTZW50OiAyNS4gdGFtbWlrdXV0YSAyMDEzIDk6MDINClRv
OiBkaXNwYXRjaEBpZXRmLm9yZzxtYWlsdG86ZGlzcGF0Y2hAaWV0Zi5vcmc+DQpTdWJqZWN0OiBS
ZTogW2Rpc3BhdGNoXSBSRkMgMzM5OCAtIHByb2JsZW1zIHdpdGggSVNVUCBjYXVzZSBtYXBwaW5n
DQoNCkhpLA0KDQpJJ20gbW9iaWxlIGNvcmUgbmV0d29yayBlbmdpbmVlciB3b3JraW5nIGEgbG90
IHdpdGggSVNVUCB0byBTSVAgbWFwcGluZyBhbmQgdmljZSB2ZXJzYS4NCkkgY29tZSB1cCB0byBh
biB1bnNvbHZlZCBwcm9ibGVtIHdpdGggbWFwcGluZyB0aGUgdHJhZmZpYyBmcm9tIElTVVAgdG8g
U0lQIGFuZCBiYWNrIHRvIElTVVAuDQoNCkZyb20gUkZDIDMzOTg6DQoNCklTVVAtU0lQDQogICAx
OCBubyB1c2VyIHJlc3BvbmRpbmcgICAgICAgICAgICAgICAgICAgNDA4IFJlcXVlc3QgVGltZW91
dA0KICAgMTkgbm8gYW5zd2VyIGZyb20gdGhlIHVzZXIgICAgICAgICAgICAgIDQ4MCBUZW1wb3Jh
cmlseSB1bmF2YWlsYWJsZQ0KICAgMjAgc3Vic2NyaWJlciBhYnNlbnQgICAgICAgICAgICAgICAg
ICAgIDQ4MCBUZW1wb3JhcmlseSB1bmF2YWlsYWJsZQ0KDQpTSVAtSVNVUDoNCiAgIDQwOCBSZXF1
ZXN0IHRpbWVvdXQgICAgICAgICAgICAgICAgICAxMDIgUmVjb3Zlcnkgb24gdGltZXIgZXhwaXJ5
DQogICA0ODAgVGVtcG9yYXJpbHkgdW5hdmFpbGFibGUgICAgICAgICAgIDE4IE5vIHVzZXIgcmVz
cG9uZGluZw0KDQpTbyBpZiBJIHNlbmQgZnJvbSBJU1VQIFJFTC0xOSBhbmQgdGhpcyB0cmFmaWMg
d2VudHMgbWFwcyB0byBTSVAgYW5kIHRoZW4gYmFjayB0byBJU1VQLCBJIHJlY2VpdmUgb24gdGhl
IG90aGVyIHNpZGUgSVNVUCBSRUwtMTguDQpUaGVyZSBpcyB0aGUgc2FtZSBzdG9yeSB3aXRoIElT
VVAgUkVMMTggbWFwcG5nIHRvIFNJUCBhbmQgYmFjayB0byBJU1VQIOKAkyBJIHdpbGwgcmVjZWl2
ZSBJU1VQIFJFTC4xMDI/IQ0KDQpDYW4geW91IGhlbHAgbWUgd2l0aCB0aGlzIGlzdWUuIElzIHRo
ZXJlIGFueSBuZXcgUkZDIGhvdyB0byBtYXAgdGhpcyBraW5kIG9mIHRyYWZmaWM/DQoNClRoYW5r
IHlvdSwNCkJSIEFsZXMgU2xpYmVyDQoNCkFsZcWhIMWgbGliZXINCkNvcmUgbmV0d29yayBlbmdp
bmVlcg0KVGVsOiArMzg2LTEtNDcyLTg0ODINClctbW9iaWxlOiB3d3cubW9iaXRlbC5zaTxodHRw
Oi8vd3d3Lm1vYml0ZWwuc2kvPg0KVy1maXg6IHd3dy50ZWxla29tLnNpPGh0dHA6Ly93d3cudGVs
ZWtvbS5zaS8+DQpUZWxla29tIFNsb3ZlbmlqZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KZGlzcGF0Y2ggbWFpbGluZyBsaXN0DQpkaXNwYXRjaEBp
ZXRmLm9yZzxtYWlsdG86ZGlzcGF0Y2hAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoDQo=

--_000_7594FB04B1934943A5C02806D1A2204B0CB9CAESESSMB209ericsso_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUcmVidWNoZXQgTVMiOw0KCXBhbm9zZS0xOjIgMTEg
NiAzIDIgMiAyIDIgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg
bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv
bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz
YW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv
cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2
aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5
OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0Fj
ZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207
DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWls
eToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0
eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ
bXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNh
bnMtc2VyaWYiO30NCnNwYW4uVEFMQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiVEFMIENoYXIiOw0K
CW1zby1zdHlsZS1saW5rOlRBTDsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjt9
DQpwLlRBTCwgbGkuVEFMLCBkaXYuVEFMDQoJe21zby1zdHlsZS1uYW1lOlRBTDsNCgltc28tc3R5
bGUtbGluazoiVEFMIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0
Ow0KCXBhZ2UtYnJlYWstYWZ0ZXI6YXZvaWQ7DQoJZm9udC1zaXplOjkuMHB0Ow0KCWZvbnQtZmFt
aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO30NCnNwYW4uVEFDQ2hhcg0KCXttc28tc3R5bGUtbmFt
ZToiVEFDIENoYXIiOw0KCW1zby1zdHlsZS1saW5rOlRBQzsNCglmb250LWZhbWlseToiQXJpYWwi
LCJzYW5zLXNlcmlmIjt9DQpwLlRBQywgbGkuVEFDLCBkaXYuVEFDDQoJe21zby1zdHlsZS1uYW1l
OlRBQzsNCgltc28tc3R5bGUtbGluazoiVEFDIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2lu
LWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYWxpZ246Y2VudGVyOw0KCXBhZ2UtYnJlYWstYWZ0ZXI6
YXZvaWQ7DQoJZm9udC1zaXplOjkuMHB0Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy
aWYiO30NCnNwYW4uVEhDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJUSCBDaGFyIjsNCgltc28tc3R5
bGUtbGluazpUSDsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCglmb250LXdl
aWdodDpib2xkO30NCnAuVEgsIGxpLlRILCBkaXYuVEgNCgl7bXNvLXN0eWxlLW5hbWU6VEg7DQoJ
bXNvLXN0eWxlLWxpbms6IlRIIENoYXIiOw0KCW1hcmdpbi10b3A6My4wcHQ7DQoJbWFyZ2luLXJp
Z2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjkuMHB0Ow0KCW1hcmdpbi1sZWZ0OjBjbTsNCgl0ZXh0
LWFsaWduOmNlbnRlcjsNCglwYWdlLWJyZWFrLWFmdGVyOmF2b2lkOw0KCWZvbnQtc2l6ZToxMC4w
cHQ7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJZm9udC13ZWlnaHQ6Ym9s
ZDt9DQpwLlRBTiwgbGkuVEFOLCBkaXYuVEFODQoJe21zby1zdHlsZS1uYW1lOlRBTjsNCgltYXJn
aW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1h
cmdpbi1sZWZ0OjQyLjU1cHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtaW5kZW50
Oi00Mi41NXB0Ow0KCXBhZ2UtYnJlYWstYWZ0ZXI6YXZvaWQ7DQoJZm9udC1zaXplOjkuMHB0Ow0K
CWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO30NCnAuVEFILCBsaS5UQUgsIGRpdi5U
QUgNCgl7bXNvLXN0eWxlLW5hbWU6VEFIOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTou
MDAwMXB0Ow0KCXRleHQtYWxpZ246Y2VudGVyOw0KCXBhZ2UtYnJlYWstYWZ0ZXI6YXZvaWQ7DQoJ
Zm9udC1zaXplOjkuMHB0Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWZv
bnQtd2VpZ2h0OmJvbGQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjcNCgl7bXNvLXN0eWxlLXR5cGU6cGVy
c29uYWw7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93
dGV4dDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJdGV4dC1k
ZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQpzcGFuLkVtYWlsU3R5bGUyOA0KCXttc28tc3R5bGUtdHlw
ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3
aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0
ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCnNwYW4uRW1haWxTdHlsZTI5DQoJe21zby1zdHls
ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNv
bG9yOndpbmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFs
Ow0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzANCgl7bXNv
LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm
IjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTMxDQoJe21zby1zdHlsZS10eXBl
OnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJUcmVidWNoZXQgTVMiLCJzYW5zLXNlcmlmIjsNCglj
b2xvcjojMDA3MEMwO30NCnNwYW4uRW1haWxTdHlsZTMyDQoJe21zby1zdHlsZS10eXBlOnBlcnNv
bmFsOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3Rl
eHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVj
b3JhdGlvbjpub25lIG5vbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzMNCgl7bXNvLXN0eWxlLXR5cGU6
cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IlRyZWJ1Y2hldCBNUyIsInNhbnMtc2VyaWYiOw0KCWNv
bG9yOiMwMDcwQzA7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u
YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj
MUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K
CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3
OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRT
ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z
byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg
Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs
YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8
L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF
Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv
bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkhp
LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv
cjojMUY0OTdEIj4mZ3Q7PC9zcGFuPkd1eXMsIHlvdSdyZSBkb2luZyBpdCB3cm9uZy4gQ29tcGxl
dGVseSB3cm9uZy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+R28gYmFjayBhbmQgcmVhZCBteSBy
ZXNwb25zZSBmcm9tIEZyaWRheS4mbmJzcDs8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv
bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5NYXliZSBJ4oCZdmUgbWlzc2VkIHNv
bWV0aGluZywgYnV0IEkgZG9u4oCZdCB0aGluayBJU1VQIHR1bm5lbGluZyBpcyB1c2VkIGluIHRo
ZSBjYXNlIGJlaW5nIGRpc2N1c3NlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5
N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5DaHJpc3Rl
cjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5
N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
YXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gSmFuIDI4LCAyMDEzLCBhdCA4OjA5LCAmcXVv
dDtDYWxtZSwgSmFtZXMgQSAoSmltKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmppbS5jYWxt
ZUBhbGNhdGVsLWx1Y2VudC5jb20iPmppbS5jYWxtZUBhbGNhdGVsLWx1Y2VudC5jb208L2E+Jmd0
OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp
bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDcwQzAiPlRydWUsIGl0IGlzIG5vdCAxMDAl
IHN5bW1ldHJpYy4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3MEMwIj5JZiBpdCBpcyByZXF1aXJlZCB0byBtYWlu
dGFpbiB0aGUgb3JpZ2luYWwgSVNVUCBjYXVzZSwgdGhlbiBJIHdvdWxkIHN1Z2dlc3QgdXNpbmcg
dGhlIFJlYXNvbiBoZWFkZXIgZmllbGQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDcwQzAiPkppbTwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls
eTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MDA3MEMwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i
Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg
MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2
LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IMWgbGliZXIgQWxlxaEgWzxhIGhyZWY9Im1haWx0bzpB
bGVzLlNsaWJlckB0ZWxla29tLnNpIj5tYWlsdG86QWxlcy5TbGliZXJAdGVsZWtvbS5zaTwvYT5d
DQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBKYW51YXJ5IDI4LCAyMDEzIDM6MjMgQU08YnI+
DQo8Yj5Ubzo8L2I+IENhbG1lLCBKYW1lcyBBIChKaW0pOyBDaHJpc3RlciBIb2xtYmVyZzsgPGEg
aHJlZj0ibWFpbHRvOmRpc3BhdGNoQGlldGYub3JnIj4NCmRpc3BhdGNoQGlldGYub3JnPC9hPjxi
cj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogUkZDIDMzOTggLSBwcm9ibGVtcyB3aXRoIElTVVAgY2F1
c2UgbWFwcGluZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxz
cGFuIGxhbmc9IlNMIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90OyI+SGksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iU0wiIHN0eWxl
PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4m
bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJTTCIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx
dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoYW5rIHlvdSBmb3IgcmVw
bHksIGJ1dCBhcyBJIGNhbiBzZWUsIGZyb20gM0dQUCBUUyAyOS4xNjMgZG9jdW1lbnQg4oCTIHRo
ZXJlIGlzIHF1aXRlIHRoZSBzYW1lIHN0b3J5IChtYWJ5IGV2ZW4gd29yc3Qg4oCTIGJlY2F1c2Ug
SVNVUCAxOCBpcyBtYXBkIGFsc28gaW4gU0lQDQogNDgwIGFuZCBub3QgaW4tdG8gU0lQLTQwOCBh
cyBpbiBSRkMpOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IlNMIiBzdHlsZT0iZm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIw
IiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSI2MzgiIHN0eWxlPSJ3aWR0
aDo0NzguOHB0O21hcmdpbi1sZWZ0OjM2LjBwdDtib3JkZXItY29sbGFwc2U6Y29sbGFwc2UiPg0K
PHRib2R5Pg0KPHRyPg0KPHRkIHdpZHRoPSIzMTIiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6
MjMzLjdwdDtib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSA1LjRwdCAw
Y20gNS40cHQiPg0KPHAgY2xhc3M9IlRIIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48
c3BhbiBsYW5nPSJFTi1HQiI+VGFibGUgOTogUmVjZWlwdCBvZiB0aGUgUmVsZWFzZSBtZXNzYWdl
IChSRUwpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBhbGlnbj0iY2VudGVyIj4NCjx0YWJs
ZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxw
YWRkaW5nPSIwIiB3aWR0aD0iODclIiBzdHlsZT0id2lkdGg6ODcuMTglO21hcmdpbi1sZWZ0OjQy
LjE1cHQ7Ym9yZGVyLWNvbGxhcHNlOmNvbGxhcHNlIj4NCjx0aGVhZD4NCjx0ciBzdHlsZT0icGFn
ZS1icmVhay1pbnNpZGU6YXZvaWQ7aGVpZ2h0OjE0LjE1cHQiPg0KPHRkIHdpZHRoPSIyMyUiIHZh
bGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MjMuMSU7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4w
cHQ7cGFkZGluZzowY20gNS4zNXB0IDBjbSA1LjM1cHQ7aGVpZ2h0OjE0LjE1cHQiPg0KPHAgY2xh
c3M9IlRBSCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPsKs
PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj5TSVAgTWVzc2FnZQ0KPC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNzYlIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjc2
LjklO2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1sZWZ0Om5vbmU7cGFkZGlu
ZzowY20gNS4zNXB0IDBjbSA1LjM1cHQ7aGVpZ2h0OjE0LjE1cHQiPg0KPHAgY2xhc3M9IlRBSCI+
PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPsKsPC9zcGFuPjxz
cGFuIGxhbmc9IkVOLUdCIj4gUkVMPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+
DQo8dHIgc3R5bGU9InBhZ2UtYnJlYWstaW5zaWRlOmF2b2lkO2hlaWdodDoxMy42NXB0Ij4NCjx0
ZCB3aWR0aD0iMjMlIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjIzLjElO2JvcmRlcjpzb2xp
ZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjM1cHQgMGNt
IDUuMzVwdDtoZWlnaHQ6MTMuNjVwdCI+DQo8cCBjbGFzcz0iVEFIIj48c3BhbiBsYW5nPSJFTi1H
QiI+U3RhdHVzIGNvZGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI3
NiUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6NzYuOSU7Ym9yZGVyLXRvcDpub25lO2JvcmRl
ci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1y
aWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0
O2hlaWdodDoxMy42NXB0Ij4NCjxwIGNsYXNzPSJUQUgiPjxzcGFuIGxhbmc9IkVOLUdCIj5DYXVz
ZSBwYXJhbWV0ZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGhlYWQ+
DQo8dGJvZHk+DQo8dHIgc3R5bGU9InBhZ2UtYnJlYWstaW5zaWRlOmF2b2lkO2hlaWdodDoxNS4w
cHQiPg0KPHRkIHdpZHRoPSIyMyUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MjMuMSU7Ym9y
ZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGNtIDUu
MzVwdCAwY20gNS4zNXB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBh
Z2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPjQwNCBOb3QgRm91bmQ8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI3NiUiIHZhbGlnbj0idG9wIiBz
dHlsZT0id2lkdGg6NzYuOSU7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVy
LWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0
ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDoxNS4wcHQiPg0K
PHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0i
RU4tR0IiPkNhdXNlIHZhbHVlIE5vLiZuYnNwOzEgKHVuYWxsb2NhdGVkICh1bmFzc2lnbmVkKSBu
dW1iZXIpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9InBh
Z2UtYnJlYWstaW5zaWRlOmF2b2lkO2hlaWdodDoxNS4wcHQiPg0KPHRkIHdpZHRoPSIyMyUiIHZh
bGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MjMuMSU7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4w
cHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDox
NS4wcHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNw
YW4gbGFuZz0iRU4tR0IiPjUwMCBTZXJ2ZXIgSW50ZXJuYWwgZXJyb3I8L3NwYW4+PG86cD48L286
cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI3NiUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6
NzYuOSU7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xp
ZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3Bh
ZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9IlRB
QyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPkNhdXNl
IHZhbHVlIE5vIDIgKG5vIHJvdXRlIHRvIG5ldHdvcmspPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9InBhZ2UtYnJlYWstaW5zaWRlOmF2b2lkO2hlaWdodDox
NS4wcHQiPg0KPHRkIHdpZHRoPSIyMyUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MjMuMSU7
Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGNt
IDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9
InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPjUwMCBTZXJ2ZXIgSW50
ZXJuYWwgZXJyb3I8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI3NiUi
IHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6NzYuOSU7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1s
ZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdo
dDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hl
aWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0
byI+PHNwYW4gbGFuZz0iRU4tR0IiPkNhdXNlIHZhbHVlIE5vIDMgKG5vIHJvdXRlIHRvIGRlc3Rp
bmF0aW9uKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJw
YWdlLWJyZWFrLWluc2lkZTphdm9pZDtoZWlnaHQ6MTYuNTVwdCI+DQo8dGQgd2lkdGg9IjIzJSIg
dmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoyMy4xJTtib3JkZXI6c29saWQgd2luZG93dGV4dCAx
LjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowY20gNS4zNXB0IDBjbSA1LjM1cHQ7aGVpZ2h0
OjE2LjU1cHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+
PHNwYW4gbGFuZz0iRU4tR0IiPjUwMCBTZXJ2ZXIgSW50ZXJuYWwgZXJyb3I8L3NwYW4+PG86cD48
L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI3NiUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lk
dGg6NzYuOSU7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpz
b2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0
O3BhZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDoxNi41NXB0Ij4NCjxwIGNsYXNz
PSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Q2F1c2UgdmFsdWUgTm8uIDQgKFNlbmQgc3BlY2lhbCBp
bmZvcm1hdGlvbiB0b25lKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRy
IHN0eWxlPSJwYWdlLWJyZWFrLWluc2lkZTphdm9pZDtoZWlnaHQ6MTUuNzVwdCI+DQo8dGQgd2lk
dGg9IjIzJSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoyMy4xJTtib3JkZXI6c29saWQgd2lu
ZG93dGV4dCAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowY20gNS4zNXB0IDBjbSA1LjM1
cHQ7aGVpZ2h0OjE1Ljc1cHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0
ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPjQwNCBOb3QgRm91bmQ8L3NwYW4+PG86cD48L286
cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI3NiUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6
NzYuOSU7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xp
ZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3Bh
ZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDoxNS43NXB0Ij4NCjxwIGNsYXNzPSJU
QUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdCI+Q2F1c2UgdmFsdWUgTm8uIDUgKE1pc2RpYWxsZWQgdHJ1bmsg
cHJlZml4KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJw
YWdlLWJyZWFrLWluc2lkZTphdm9pZDtoZWlnaHQ6MTUuMHB0Ij4NCjx0ZCB3aWR0aD0iMjMlIiB2
YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjIzLjElO2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEu
MHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjM1cHQgMGNtIDUuMzVwdDtoZWlnaHQ6
MTUuMHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxz
cGFuIGxhbmc9IkVOLUdCIj40ODYgQnVzeSBIZXJlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90
ZD4NCjx0ZCB3aWR0aD0iNzYlIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjc2LjklO2JvcmRl
ci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4
dCAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSA1
LjM1cHQgMGNtIDUuMzVwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJw
YWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5DYXVzZSB2YWx1ZSBOby4m
bmJzcDsxNyAodXNlciBidXN5KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0K
PHRyIHN0eWxlPSJwYWdlLWJyZWFrLWluc2lkZTphdm9pZDtoZWlnaHQ6MTUuMHB0Ij4NCjx0ZCB3
aWR0aD0iMjMlIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjIzLjElO2JvcmRlcjpzb2xpZCB3
aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjM1cHQgMGNtIDUu
MzVwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFm
dGVyOmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iYmFja2dyb3VuZDp5ZWxsb3c7
bXNvLWhpZ2hsaWdodDp5ZWxsb3ciPjQ4MCBUZW1wb3JhcmlseSB1bmF2YWlsYWJsZTwvc3Bhbj48
L2I+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI3NiUiIHZhbGlnbj0idG9wIiBz
dHlsZT0id2lkdGg6NzYuOSU7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVy
LWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0
ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDoxNS4wcHQiPg0K
PHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PGI+PHNwYW4gbGFu
Zz0iRU4tR0IiIHN0eWxlPSJiYWNrZ3JvdW5kOnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxvdyI+
Q2F1c2UgdmFsdWUgTm8gMTggKG5vIHVzZXIgcmVzcG9uZGluZyk8L3NwYW4+PC9iPjxvOnA+PC9v
OnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9InBhZ2UtYnJlYWstaW5zaWRlOmF2b2lk
O2hlaWdodDoxNS4wcHQiPg0KPHRkIHdpZHRoPSIyMyUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lk
dGg6MjMuMSU7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3Bh
ZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9IlRB
QyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0
eWxlPSJiYWNrZ3JvdW5kOnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxvdyI+NDgwIFRlbXBvcmFy
aWx5IHVuYXZhaWxhYmxlPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lk
dGg9Ijc2JSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDo3Ni45JTtib3JkZXItdG9wOm5vbmU7
Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9y
ZGVyLXJpZ2h0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20gNS4zNXB0IDBjbSA1
LjM1cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1h
ZnRlcjphdXRvIj48Yj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93
O21zby1oaWdobGlnaHQ6eWVsbG93Ij5DYXVzZSB2YWx1ZSBObyAxOSAobm8gYW5zd2VyIGZyb20g
dGhlIHVzZXIpPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0
eWxlPSJwYWdlLWJyZWFrLWluc2lkZTphdm9pZDtoZWlnaHQ6MTUuMHB0Ij4NCjx0ZCB3aWR0aD0i
MjMlIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjIzLjElO2JvcmRlcjpzb2xpZCB3aW5kb3d0
ZXh0IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjM1cHQgMGNtIDUuMzVwdDto
ZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1
dG8iPjxiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iYmFja2dyb3VuZDp5ZWxsb3c7bXNvLWhp
Z2hsaWdodDp5ZWxsb3ciPjQ4MCBUZW1wb3JhcmlseSB1bmF2YWlsYWJsZTwvc3Bhbj48L2I+PG86
cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI3NiUiIHZhbGlnbj0idG9wIiBzdHlsZT0i
d2lkdGg6NzYuOSU7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRv
bTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEu
MHB0O3BhZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xh
c3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4t
R0IiIHN0eWxlPSJiYWNrZ3JvdW5kOnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxvdyI+Q2F1c2Ug
dmFsdWUgTm8uJm5ic3A7MjAgKHN1YnNjcmliZXIgYWJzZW50KTwvc3Bhbj48L2I+PG86cD48L286
cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0icGFnZS1icmVhay1pbnNpZGU6YXZvaWQ7
aGVpZ2h0OjE1LjBwdCI+DQo8dGQgd2lkdGg9IjIzJSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0
aDoyMy4xJTtib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFk
ZGluZzowY20gNS4zNXB0IDBjbSA1LjM1cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iVEFD
IiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+NjAzIERl
Y2xpbmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI3NiUiIHZhbGln
bj0idG9wIiBzdHlsZT0id2lkdGg6NzYuOSU7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5v
bmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpzb2xp
ZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDox
NS4wcHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNw
YW4gbGFuZz0iRU4tR0IiPkNhdXNlIHZhbHVlIE5vIDIxIChjYWxsIHJlamVjdGVkKSwgTG9jYXRp
b24gPSAwMDAgLyB1c2VyIChVKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0K
PHRyIHN0eWxlPSJwYWdlLWJyZWFrLWluc2lkZTphdm9pZDtoZWlnaHQ6MTUuMHB0Ij4NCjx0ZCB3
aWR0aD0iMjMlIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjIzLjElO2JvcmRlcjpzb2xpZCB3
aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjM1cHQgMGNtIDUu
MzVwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFm
dGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj40ODBUZW1wb3JhcmlseSB1bmF2YWlsYWJsZTwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9Ijc2JSIgdmFsaWduPSJ0b3Ai
IHN0eWxlPSJ3aWR0aDo3Ni45JTtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3Jk
ZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkIHdpbmRv
d3RleHQgMS4wcHQ7cGFkZGluZzowY20gNS4zNXB0IDBjbSA1LjM1cHQ7aGVpZ2h0OjE1LjBwdCI+
DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5n
PSJFTi1HQiI+Q2F1c2UgdmFsdWUgTm8gMjEgKGNhbGwgcmVqZWN0ZWQpICwgTG9jYXRpb24gJmx0
OyZndDsgMDAwIC8gdXNlciAoVSk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4N
Cjx0ciBzdHlsZT0icGFnZS1icmVhay1pbnNpZGU6YXZvaWQ7aGVpZ2h0OjE1LjBwdCI+DQo8dGQg
d2lkdGg9IjIzJSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoyMy4xJTtib3JkZXI6c29saWQg
d2luZG93dGV4dCAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowY20gNS4zNXB0IDBjbSA1
LjM1cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1h
ZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+NDEwIEdvbmU8L3NwYW4+PG86cD48L286cD48
L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI3NiUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6NzYu
OSU7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3
aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRp
bmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9IlRBQyIg
c3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPkNhdXNlIHZh
bHVlIE5vIDIyIChudW1iZXIgY2hhbmdlZCk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0K
PC90cj4NCjx0ciBzdHlsZT0icGFnZS1icmVhay1pbnNpZGU6YXZvaWQ7aGVpZ2h0OjE1LjBwdCI+
DQo8dGQgd2lkdGg9IjIzJSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoyMy4xJTtib3JkZXI6
c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowY20gNS4zNXB0
IDBjbSA1LjM1cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1i
cmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+NDMzIEFub255bWl0eSBEaXNhbGxv
d2VkLihOT1RFIDEpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNzYl
IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjc2LjklO2JvcmRlci10b3A6bm9uZTtib3JkZXIt
bGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItcmln
aHQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSA1LjM1cHQgMGNtIDUuMzVwdDto
ZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1
dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5DYXVzZSB2YWx1ZSBOby4gMjQgKGNhbGwgcmVqZWN0ZWQg
ZHVlIHRvIEFDUiBzdXBwbGVtZW50YXJ5IHNlcnZpY2UpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9InBhZ2UtYnJlYWstaW5zaWRlOmF2b2lkO2hlaWdodDox
NS4wcHQiPg0KPHRkIHdpZHRoPSIyMyUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MjMuMSU7
Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGNt
IDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9
InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPjQ4MCBUZW1wb3Jhcmls
eSB1bmF2YWlsYWJsZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9Ijc2
JSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDo3Ni45JTtib3JkZXItdG9wOm5vbmU7Ym9yZGVy
LWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXJp
Z2h0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20gNS4zNXB0IDBjbSA1LjM1cHQ7
aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjph
dXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Q2F1c2UgdmFsdWUgTm8gMjUgKEV4Y2hhbmdlIHJvdXRp
bmcgZXJyb3IpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9
InBhZ2UtYnJlYWstaW5zaWRlOmF2b2lkO2hlaWdodDoxNS4wcHQiPg0KPHRkIHdpZHRoPSIyMyUi
IHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MjMuMSU7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQg
MS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdo
dDoxNS4wcHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+
PHNwYW4gbGFuZz0iRU4tR0IiPjUwMiBCYWQgR2F0ZXdheTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjwvdGQ+DQo8dGQgd2lkdGg9Ijc2JSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDo3Ni45JTti
b3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRv
d3RleHQgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzow
Y20gNS4zNXB0IDBjbSA1LjM1cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHls
ZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Q2F1c2UgdmFsdWUg
Tm8gMjcgKGRlc3RpbmF0aW9uIG91dCBvZiBvcmRlcik8L3NwYW4+PG86cD48L286cD48L3A+DQo8
L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0icGFnZS1icmVhay1pbnNpZGU6YXZvaWQ7aGVpZ2h0OjE0
LjJwdCI+DQo8dGQgd2lkdGg9IjIzJSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoyMy4xJTti
b3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowY20g
NS4zNXB0IDBjbSA1LjM1cHQ7aGVpZ2h0OjE0LjJwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0i
cGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+NDg0IEFkZHJlc3MgSW5j
b21wbGV0ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9Ijc2JSIgdmFs
aWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDo3Ni45JTtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6
bm9uZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNv
bGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20gNS4zNXB0IDBjbSA1LjM1cHQ7aGVpZ2h0
OjE0LjJwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48
c3BhbiBsYW5nPSJFTi1HQiI+Q2F1c2UgdmFsdWUgTm8uJm5ic3A7MjggaW52YWxpZCBudW1iZXIg
Zm9ybWF0IChhZGRyZXNzIGluY29tcGxldGUpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4N
CjwvdHI+DQo8dHIgc3R5bGU9InBhZ2UtYnJlYWstaW5zaWRlOmF2b2lkO2hlaWdodDoxNC4ycHQi
Pg0KPHRkIHdpZHRoPSIyMyUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MjMuMSU7Ym9yZGVy
OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGNtIDUuMzVw
dCAwY20gNS4zNXB0O2hlaWdodDoxNC4ycHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2Ut
YnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPjUwMCBTZXJ2ZXIgSW50ZXJuYWwg
ZXJyb3I8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI3NiUiIHZhbGln
bj0idG9wIiBzdHlsZT0id2lkdGg6NzYuOSU7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5v
bmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpzb2xp
ZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDox
NC4ycHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNw
YW4gbGFuZz0iRU4tR0IiPkNhdXNlIHZhbHVlIE5vIDI5IChmYWNpbGl0eSByZWplY3RlZCk8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0icGFnZS1icmVhay1p
bnNpZGU6YXZvaWQ7aGVpZ2h0OjE1LjBwdCI+DQo8dGQgd2lkdGg9IjIzJSIgdmFsaWduPSJ0b3Ai
IHN0eWxlPSJ3aWR0aDoyMy4xJTtib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXIt
dG9wOm5vbmU7cGFkZGluZzowY20gNS4zNXB0IDBjbSA1LjM1cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8
cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJF
Ti1HQiI+NDgwIFRlbXBvcmFyaWx5IHVuYXZhaWxhYmxlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PC90ZD4NCjx0ZCB3aWR0aD0iNzYlIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjc2LjklO2Jv
cmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93
dGV4dCAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBj
bSA1LjM1cHQgMGNtIDUuMzVwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxl
PSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5DYXVzZSB2YWx1ZSBO
byAzMSAobm9ybWFsIHVuc3BlY2lmaWVkKSAoY2xhc3MgZGVmYXVsdCkgKE5PVEUgMik8L3NwYW4+
PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0icGFnZS1icmVhay1pbnNp
ZGU6YXZvaWQ7aGVpZ2h0OjM3LjRwdCI+DQo8dGQgd2lkdGg9IjIzJSIgdmFsaWduPSJ0b3AiIHN0
eWxlPSJ3aWR0aDoyMy4xJTtib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItdG9w
Om5vbmU7cGFkZGluZzowY20gNS4zNXB0IDBjbSA1LjM1cHQ7aGVpZ2h0OjM3LjRwdCI+DQo8cCBj
bGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1H
QiI+NDg2IEJ1c3kgaGVyZSBpZiBEaWFnbm9zdGljcyBpbmRpY2F0b3IgaW5jbHVkZXMgdGhlIChD
Q0JTIGluZGljYXRvciA9IENDQlMgcG9zc2libGUpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4t
R0IiPmVsc2UgNDgwIFRlbXBvcmFyaWx5IHVuYXZhaWxhYmxlPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPC90ZD4NCjx0ZCB3aWR0aD0iNzYlIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjc2Ljkl
O2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgd2lu
ZG93dGV4dCAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5n
OjBjbSA1LjM1cHQgMGNtIDUuMzVwdDtoZWlnaHQ6MzcuNHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0
eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5DYXVzZSB2YWx1
ZSBpbiB0aGUgQ2xhc3MgMDEwIChyZXNvdXJjZSB1bmF2YWlsYWJsZSwgQ2F1c2UgdmFsdWUgTm8g
MzQpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9InBhZ2Ut
YnJlYWstaW5zaWRlOmF2b2lkO2hlaWdodDoyNi4wcHQiPg0KPHRkIHdpZHRoPSIyMyUiIHZhbGln
bj0idG9wIiBzdHlsZT0id2lkdGg6MjMuMSU7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7
Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDoyNi4w
cHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4g
bGFuZz0iRU4tR0IiPjUwMCBTZXJ2ZXIgSW50ZXJuYWwgZXJyb3I8L3NwYW4+PG86cD48L286cD48
L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI3NiUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6NzYu
OSU7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3
aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRp
bmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDoyNi4wcHQiPg0KPHAgY2xhc3M9IlRBQyIg
c3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPkNhdXNlIHZh
bHVlIGluIHRoZSBDbGFzcyAwMTA8YnI+DQoocmVzb3VyY2UgdW5hdmFpbGFibGUsIENhdXNlIHZh
bHVlIE5v4oCZcy4gMzgsIDQxLCA0MiwgNDMsIDQ0LCAmYW1wOyA0NykgKDQ3IGlzIGNsYXNzIGRl
ZmF1bHQpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9InBh
Z2UtYnJlYWstaW5zaWRlOmF2b2lkO2hlaWdodDoxNS4wcHQiPg0KPHRkIHdpZHRoPSIyMyUiIHZh
bGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MjMuMSU7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4w
cHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDox
NS4wcHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNw
YW4gbGFuZz0iRU4tR0IiPjUwMCBTZXJ2ZXIgSW50ZXJuYWwgZXJyb3I8L3NwYW4+PG86cD48L286
cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI3NiUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6
NzYuOSU7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xp
ZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3Bh
ZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9IlRB
QyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPkNhdXNl
IHZhbHVlIE5vIDUwIChyZXF1ZXN0ZWQgZmFjaWxpdHkgbm8gc3Vic2NyaWJlZCk8L3NwYW4+PG86
cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0icGFnZS1icmVhay1pbnNpZGU6
YXZvaWQ7aGVpZ2h0OjE1LjBwdCI+DQo8dGQgd2lkdGg9IjIzJSIgdmFsaWduPSJ0b3AiIHN0eWxl
PSJ3aWR0aDoyMy4xJTtib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItdG9wOm5v
bmU7cGFkZGluZzowY20gNS4zNXB0IDBjbSA1LjM1cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFz
cz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+
NTAwIFNlcnZlciBJbnRlcm5hbCBlcnJvcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8
dGQgd2lkdGg9Ijc2JSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDo3Ni45JTtib3JkZXItdG9w
Om5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4w
cHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20gNS4zNXB0
IDBjbSA1LjM1cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1i
cmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Q2F1c2UgdmFsdWUgTm8gNTcgKGJl
YXJlciBjYXBhYmlsaXR5IG5vdCBhdXRob3Jpc2VkKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv
dGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJwYWdlLWJyZWFrLWluc2lkZTphdm9pZDtoZWlnaHQ6MTUu
MHB0Ij4NCjx0ZCB3aWR0aD0iMjMlIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjIzLjElO2Jv
cmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1
LjM1cHQgMGNtIDUuMzVwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJw
YWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj41MDAgU2VydmVyIEludGVy
bmFsIGVycm9yPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNzYlIiB2
YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjc2LjklO2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVm
dDpub25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItcmlnaHQ6
c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSA1LjM1cHQgMGNtIDUuMzVwdDtoZWln
aHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8i
PjxzcGFuIGxhbmc9IkVOLUdCIj5DYXVzZSB2YWx1ZSBObyA1OCAoYmVhcmVyIGNhcGFiaWxpdHkg
bm90IHByZXNlbnRseSk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBz
dHlsZT0icGFnZS1icmVhay1pbnNpZGU6YXZvaWQ7aGVpZ2h0OjE1LjBwdCI+DQo8dGQgd2lkdGg9
IjIzJSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoyMy4xJTtib3JkZXI6c29saWQgd2luZG93
dGV4dCAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowY20gNS4zNXB0IDBjbSA1LjM1cHQ7
aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjph
dXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+NTAwIFNlcnZlciBJbnRlcm5hbCBlcnJvcjwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9Ijc2JSIgdmFsaWduPSJ0b3AiIHN0eWxl
PSJ3aWR0aDo3Ni45JTtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90
dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkIHdpbmRvd3RleHQg
MS4wcHQ7cGFkZGluZzowY20gNS4zNXB0IDBjbSA1LjM1cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBj
bGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1H
QiI+Q2F1c2UgdmFsdWUgTm8gNjMgKHNlcnZpY2Ugb3B0aW9uIG5vdCBhdmFpbGFibGUsIHVuc3Bl
Y2lmaWVkKTxicj4NCihjbGFzcyBkZWZhdWx0KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+
DQo8L3RyPg0KPHRyIHN0eWxlPSJwYWdlLWJyZWFrLWluc2lkZTphdm9pZDtoZWlnaHQ6MjUuMjVw
dCI+DQo8dGQgd2lkdGg9IjIzJSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoyMy4xJTtib3Jk
ZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowY20gNS4z
NXB0IDBjbSA1LjM1cHQ7aGVpZ2h0OjI1LjI1cHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBh
Z2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPjUwMCBTZXJ2ZXIgSW50ZXJu
YWwgZXJyb3I8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI3NiUiIHZh
bGlnbj0idG9wIiBzdHlsZT0id2lkdGg6NzYuOSU7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0
Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpz
b2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdo
dDoyNS4yNXB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8i
PjxzcGFuIGxhbmc9IkVOLUdCIj5DYXVzZSB2YWx1ZSBpbiB0aGUgQ2xhc3MgMTAwIChzZXJ2aWNl
IG9yIG9wdGlvbiBub3QgaW1wbGVtZW50ZWQsIENhdXNlIHZhbHVlIE5v4oCZcy4gNjUsIDcwICZh
bXA7IDc5KSA3OSBpcyBjbGFzcyBkZWZhdWx0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4N
CjwvdHI+DQo8dHIgc3R5bGU9InBhZ2UtYnJlYWstaW5zaWRlOmF2b2lkO2hlaWdodDoxNS4wcHQi
Pg0KPHRkIHdpZHRoPSIyMyUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MjMuMSU7Ym9yZGVy
OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGNtIDUuMzVw
dCAwY20gNS4zNXB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2Ut
YnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPjUwMCBTZXJ2ZXIgSW50ZXJuYWwg
ZXJyb3I8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI3NiUiIHZhbGln
bj0idG9wIiBzdHlsZT0id2lkdGg6NzYuOSU7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5v
bmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpzb2xp
ZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDox
NS4wcHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNw
YW4gbGFuZz0iRlIiPkNhdXNlIHZhbHVlIE5vIDg4IChpbmNvbXBhdGlibGUgZGVzdGluYXRpb24p
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9InBhZ2UtYnJl
YWstaW5zaWRlOmF2b2lkO2hlaWdodDoxNS4wcHQiPg0KPHRkIHdpZHRoPSIyMyUiIHZhbGlnbj0i
dG9wIiBzdHlsZT0id2lkdGg6MjMuMSU7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9y
ZGVyLXRvcDpub25lO3BhZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDoxNS4wcHQi
Pg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFu
Zz0iRU4tR0IiPjQwNCBOb3QgRm91bmQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRk
IHdpZHRoPSI3NiUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6NzYuOSU7Ym9yZGVyLXRvcDpu
b25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0
O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUuMzVwdCAw
Y20gNS4zNXB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJl
YWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPkNhdXNlIHZhbHVlIE5vIDkxIChpbnZh
bGlkIHRyYW5zaXQgbmV0d29yayBzZWxlY3Rpb24pPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90
ZD4NCjwvdHI+DQo8dHIgc3R5bGU9InBhZ2UtYnJlYWstaW5zaWRlOmF2b2lkO2hlaWdodDoxNS4w
cHQiPg0KPHRkIHdpZHRoPSIyMyUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MjMuMSU7Ym9y
ZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGNtIDUu
MzVwdCAwY20gNS4zNXB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBh
Z2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPjUwMCBTZXJ2ZXIgSW50ZXJu
YWwgZXJyb3I8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI3NiUiIHZh
bGlnbj0idG9wIiBzdHlsZT0id2lkdGg6NzYuOSU7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0
Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpz
b2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdo
dDoxNS4wcHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+
PHNwYW4gbGFuZz0iRU4tR0IiPkNhdXNlIHZhbHVlIE5vIDk1IChpbnZhbGlkIG1lc3NhZ2UpPGJy
Pg0KKGNsYXNzIGRlZmF1bHQpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8
dHIgc3R5bGU9InBhZ2UtYnJlYWstaW5zaWRlOmF2b2lkO2hlaWdodDoxNi41NXB0Ij4NCjx0ZCB3
aWR0aD0iMjMlIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjIzLjElO2JvcmRlcjpzb2xpZCB3
aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjM1cHQgMGNtIDUu
MzVwdDtoZWlnaHQ6MTYuNTVwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1h
ZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+NTAwIFNlcnZlciBJbnRlcm5hbCBlcnJvcjwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9Ijc2JSIgdmFsaWduPSJ0b3Ai
IHN0eWxlPSJ3aWR0aDo3Ni45JTtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3Jk
ZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkIHdpbmRv
d3RleHQgMS4wcHQ7cGFkZGluZzowY20gNS4zNXB0IDBjbSA1LjM1cHQ7aGVpZ2h0OjE2LjU1cHQi
Pg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFu
Zz0iRU4tR0IiPkNhdXNlIHZhbHVlIE5vIDk3ICg8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0Ij5NZXNzYWdlIHR5cGUgbm9uLWV4aXN0ZW50IG9yIG5vdCBp
bXBsZW1lbnRlZDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+KTwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJwYWdlLWJyZWFrLWluc2lkZTphdm9pZDtoZWln
aHQ6MTUuMHB0Ij4NCjx0ZCB3aWR0aD0iMjMlIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjIz
LjElO2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5n
OjBjbSA1LjM1cHQgMGNtIDUuMzVwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0
eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj41MDAgU2VydmVy
IEludGVybmFsIGVycm9yPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0i
NzYlIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjc2LjklO2JvcmRlci10b3A6bm9uZTtib3Jk
ZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXIt
cmlnaHQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSA1LjM1cHQgMGNtIDUuMzVw
dDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVy
OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5DYXVzZSB2YWx1ZSBObyA5OSAoaW5mb3JtYXRpb24g
ZWxlbWVudC9wYXJhbWV0ZXIgbm9uLWV4aXN0ZW50IG9yIG5vdCBpbXBsZW1lbnRlZCkpPC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9InBhZ2UtYnJlYWstaW5z
aWRlOmF2b2lkO2hlaWdodDoxNS4wcHQiPg0KPHRkIHdpZHRoPSIyMyUiIHZhbGlnbj0idG9wIiBz
dHlsZT0id2lkdGg6MjMuMSU7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRv
cDpub25lO3BhZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDoxNS4wcHQiPg0KPHAg
Y2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4t
R0IiPjQ4MCBUZW1wb3JhcmlseSB1bmF2YWlsYWJsZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv
dGQ+DQo8dGQgd2lkdGg9Ijc2JSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDo3Ni45JTtib3Jk
ZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3Rl
eHQgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20g
NS4zNXB0IDBjbSA1LjM1cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0i
cGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Q2F1c2UgdmFsdWUgTm8u
Jm5ic3A7MTAyIChyZWNvdmVyeSBvbiB0aW1lciBleHBpcnkpPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9InBhZ2UtYnJlYWstaW5zaWRlOmF2b2lkO2hlaWdo
dDoxNS4wcHQiPg0KPHRkIHdpZHRoPSIyMyUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MjMu
MSU7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6
MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5
bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPjUwMCBTZXJ2ZXIg
SW50ZXJuYWwgZXJyb3I8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI3
NiUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6NzYuOSU7Ym9yZGVyLXRvcDpub25lO2JvcmRl
ci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1y
aWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0
O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6
YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPkNhdXNlIHZhbHVlIE5vIDExMCAoTWVzc2FnZSB3aXRo
IHVucmVjb2duaXNlZCBQYXJhbWV0ZXIsIGRpc2NhcmRlZCk8L3NwYW4+PG86cD48L286cD48L3A+
DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0icGFnZS1icmVhay1pbnNpZGU6YXZvaWQ7aGVpZ2h0
OjE1LjBwdCI+DQo8dGQgd2lkdGg9IjIzJSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoyMy4x
JTtib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzow
Y20gNS4zNXB0IDBjbSA1LjM1cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHls
ZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+NTAwIFNlcnZlciBJ
bnRlcm5hbCBlcnJvcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9Ijc2
JSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDo3Ni45JTtib3JkZXItdG9wOm5vbmU7Ym9yZGVy
LWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXJp
Z2h0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20gNS4zNXB0IDBjbSA1LjM1cHQ7
aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjph
dXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Q2F1c2UgdmFsdWUgTm8uJm5ic3A7MTExIChwcm90b2Nv
bCBlcnJvciwgdW5zcGVjaWZpZWQpPGJyPg0KKGNsYXNzIGRlZmF1bHQpPC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9InBhZ2UtYnJlYWstaW5zaWRlOmF2b2lk
O2hlaWdodDoxOS4ycHQiPg0KPHRkIHdpZHRoPSIyMyUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lk
dGg6MjMuMSU7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3Bh
ZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDoxOS4ycHQiPg0KPHAgY2xhc3M9IlRB
QyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPjQ4MCBU
ZW1wb3JhcmlseSB1bmF2YWlsYWJsZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQg
d2lkdGg9Ijc2JSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDo3Ni45JTtib3JkZXItdG9wOm5v
bmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7
Ym9yZGVyLXJpZ2h0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20gNS4zNXB0IDBj
bSA1LjM1cHQ7aGVpZ2h0OjE5LjJwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVh
ay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Q2F1c2UgdmFsdWUgTm8uIDEyNyAoaW50
ZXJ3b3JraW5nIHVuc3BlY2lmaWVkKTxicj4NCihjbGFzcyBkZWZhdWx0KTwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJwYWdlLWJyZWFrLWluc2lkZTphdm9p
ZDtoZWlnaHQ6MTkuMnB0Ij4NCjx0ZCB3aWR0aD0iMTAwJSIgY29sc3Bhbj0iMiIgdmFsaWduPSJ0
b3AiIHN0eWxlPSJ3aWR0aDoxMDAuMCU7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9y
ZGVyLXRvcDpub25lO3BhZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDoxOS4ycHQi
Pg0KPHAgY2xhc3M9IlRBTiI+PHNwYW4gbGFuZz0iRU4tR0IiPk5PVEUgMTombmJzcDsmbmJzcDsm
bmJzcDsgQW5vbnltaXR5IERpc2FsbG93ZWQsIFJGQyA1MDc5IFs3N10gcmVmZXJzPC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9IlRBTiI+PHNwYW4gbGFuZz0iRU4tR0IiPk5PVEUgMjom
bmJzcDsmbmJzcDsmbmJzcDsgQ2xhc3MgMSBhbmQgY2xhc3MgMiBoYXZlIHRoZSBzYW1lIGRlZmF1
bHQgdmFsdWUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0K
PC90YWJsZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRk
IHdpZHRoPSIzMjciIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MjQ1LjFwdDtib3JkZXI6c29s
aWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItbGVmdDpub25lO3BhZGRpbmc6MGNtIDUuNHB0IDBj
bSA1LjRwdCI+DQo8cCBjbGFzcz0iVEgiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxz
cGFuIGxhbmc9IkVOLUdCIj5UYWJsZSAxODogNHh4LzV4eC82eHggUmVjZWl2ZWQgb24gU0lQIHNp
ZGUgb2YgTy1NR0NGPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBhbGlnbj0iY2VudGVyIj4N
Cjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAi
IGNlbGxwYWRkaW5nPSIwIiBzdHlsZT0iYm9yZGVyLWNvbGxhcHNlOmNvbGxhcHNlIj4NCjx0aGVh
ZD4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE4LjRwdCI+DQo8dGQgd2lkdGg9IjE5OSIgdmFsaWduPSJ0
b3AiIHN0eWxlPSJ3aWR0aDoxNDkuMTVwdDtib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtw
YWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRwdCI+DQo8cCBjbGFzcz0iVEFI
IiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9
ImZvbnQtZmFtaWx5OlN5bWJvbCI+wqw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPlJFTCAoY2F1
c2UgY29kZSk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSIyNTUiIHZh
bGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTkxLjM1cHQ7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQg
MS4wcHQ7Ym9yZGVyLWxlZnQ6bm9uZTtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0
OjE4LjRwdCI+DQo8cCBjbGFzcz0iVEFIIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48
c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+wqw8L3NwYW4+PHNw
YW4gbGFuZz0iRlIiPjR4eC81eHgvNnh4IFNJUCBNZXNzYWdlPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPC90ZD4NCjwvdHI+DQo8L3RoZWFkPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTgu
NHB0Ij4NCjx0ZCB3aWR0aD0iMTk5IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjE0OS4xNXB0
O2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBj
bSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0i
cGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+MTI3IChpbnRlcndvcmtp
bmcgdW5zcGVjaWZpZWQpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0i
MjU1IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjE5MS4zNXB0O2JvcmRlci10b3A6bm9uZTti
b3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtib3Jk
ZXItcmlnaHQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40
cHQ7aGVpZ2h0OjE4LjRwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRl
cjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+NDAwIEJhZCBSZXF1ZXN0PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9ImhlaWdodDoxOC40cHQiPg0KPHRkIHdp
ZHRoPSIxOTkiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTQ5LjE1cHQ7Ym9yZGVyOnNvbGlk
IHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1
LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFm
dGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4xMjcgKGludGVyd29ya2luZyB1bnNwZWNpZmll
ZCk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSIyNTUiIHZhbGlnbj0i
dG9wIiBzdHlsZT0id2lkdGg6MTkxLjM1cHQ7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5v
bmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpzb2xp
ZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTgu
NHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFu
IGxhbmc9IkVOLUdCIj40MDEgVW5hdXRob3JpemVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90
ZD4NCjwvdHI+DQo8dHIgc3R5bGU9ImhlaWdodDoxOC40cHQiPg0KPHRkIHdpZHRoPSIxOTkiIHZh
bGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTQ5LjE1cHQ7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQg
MS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdDtoZWlnaHQ6
MTguNHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxz
cGFuIGxhbmc9IkVOLUdCIj4xMjcgKGludGVyd29ya2luZyB1bnNwZWNpZmllZCk8L3NwYW4+PG86
cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSIyNTUiIHZhbGlnbj0idG9wIiBzdHlsZT0i
d2lkdGg6MTkxLjM1cHQ7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJv
dHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0
IDEuMHB0O3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNs
YXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdC
Ij40MDIgUGF5bWVudCBSZXF1aXJlZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3Ry
Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTguNHB0Ij4NCjx0ZCB3aWR0aD0iMTk5IiB2YWxpZ249InRv
cCIgc3R5bGU9IndpZHRoOjE0OS4xNXB0O2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2Jv
cmRlci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRwdCI+
DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5n
PSJFTi1HQiI+MTI3IChpbnRlcndvcmtpbmcgdW5zcGVjaWZpZWQpPC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iMjU1IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjE5
MS4zNXB0O2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29s
aWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtw
YWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRwdCI+DQo8cCBjbGFzcz0iVEFD
IiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+NDAzIEZv
cmJpZGRlbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJo
ZWlnaHQ6MTguNHB0Ij4NCjx0ZCB3aWR0aD0iMTk5IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRo
OjE0OS4xNXB0O2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci10b3A6bm9uZTtw
YWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRwdCI+DQo8cCBjbGFzcz0iVEFD
IiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+MSAoVW5h
bGxvY2F0ZWQgbnVtYmVyKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9
IjI1NSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxOTEuMzVwdDtib3JkZXItdG9wOm5vbmU7
Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9y
ZGVyLXJpZ2h0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20gNS40cHQgMGNtIDUu
NHB0O2hlaWdodDoxOC40cHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0
ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPjQwNCBOb3QgRm91bmQ8L3NwYW4+PG86cD48L286
cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE4LjRwdCI+DQo8dGQgd2lk
dGg9IjE5OSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxNDkuMTVwdDtib3JkZXI6c29saWQg
d2luZG93dGV4dCAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowY20gNS40cHQgMGNtIDUu
NHB0O2hlaWdodDoxOC40cHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0
ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPjEyNyAoaW50ZXJ3b3JraW5nIHVuc3BlY2lmaWVk
KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjI1NSIgdmFsaWduPSJ0
b3AiIHN0eWxlPSJ3aWR0aDoxOTEuMzVwdDtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9u
ZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlk
IHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0O2hlaWdodDoxOC40
cHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4g
bGFuZz0iRU4tR0IiPjQwNSBNZXRob2QgTm90IEFsbG93ZWQ8L3NwYW4+PG86cD48L286cD48L3A+
DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE4LjRwdCI+DQo8dGQgd2lkdGg9IjE5
OSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxNDkuMTVwdDtib3JkZXI6c29saWQgd2luZG93
dGV4dCAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0O2hl
aWdodDoxOC40cHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0
byI+PHNwYW4gbGFuZz0iRU4tR0IiPjEyNyAoaW50ZXJ3b3JraW5nIHVuc3BlY2lmaWVkKTwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjI1NSIgdmFsaWduPSJ0b3AiIHN0
eWxlPSJ3aWR0aDoxOTEuMzVwdDtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3Jk
ZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkIHdpbmRv
d3RleHQgMS4wcHQ7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0O2hlaWdodDoxOC40cHQiPg0K
PHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0i
RU4tR0IiPjQwNiBOb3QgQWNjZXB0YWJsZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8
L3RyPg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTguNHB0Ij4NCjx0ZCB3aWR0aD0iMTk5IiB2YWxpZ249
InRvcCIgc3R5bGU9IndpZHRoOjE0OS4xNXB0O2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0
O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRw
dCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBs
YW5nPSJFTi1HQiI+MTI3IChpbnRlcndvcmtpbmcgdW5zcGVjaWZpZWQpPC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iMjU1IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRo
OjE5MS4zNXB0O2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206
c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgd2luZG93dGV4dCAxLjBw
dDtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRwdCI+DQo8cCBjbGFzcz0i
VEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+NDA3
IFByb3h5IGF1dGhlbnRpY2F0aW9uIHJlcXVpcmVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90
ZD4NCjwvdHI+DQo8dHIgc3R5bGU9ImhlaWdodDoxOC40cHQiPg0KPHRkIHdpZHRoPSIxOTkiIHZh
bGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTQ5LjE1cHQ7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQg
MS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdDtoZWlnaHQ6
MTguNHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxi
PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iYmFja2dyb3VuZDp5ZWxsb3c7bXNvLWhpZ2hsaWdo
dDp5ZWxsb3ciPjEyNyAoaW50ZXJ3b3JraW5nIHVuc3BlY2lmaWVkKTwvc3Bhbj48L2I+PG86cD48
L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSIyNTUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lk
dGg6MTkxLjM1cHQ7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRv
bTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEu
MHB0O3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNsYXNz
PSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVOLUdC
IiBzdHlsZT0iYmFja2dyb3VuZDp5ZWxsb3c7bXNvLWhpZ2hsaWdodDp5ZWxsb3ciPjQwOCBSZXF1
ZXN0IFRpbWVvdXQ8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIg
c3R5bGU9ImhlaWdodDoxOC40cHQiPg0KPHRkIHdpZHRoPSIxOTkiIHZhbGlnbj0idG9wIiBzdHls
ZT0id2lkdGg6MTQ5LjE1cHQ7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRv
cDpub25lO3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNs
YXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdC
Ij4yMiAoTnVtYmVyIGNoYW5nZWQpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3
aWR0aD0iMjU1IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjE5MS4zNXB0O2JvcmRlci10b3A6
bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBw
dDtib3JkZXItcmlnaHQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSA1LjRwdCAw
Y20gNS40cHQ7aGVpZ2h0OjE4LjRwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVh
ay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+NDEwIEdvbmU8L3NwYW4+PG86cD48L286
cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE4LjRwdCI+DQo8dGQgd2lk
dGg9IjE5OSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxNDkuMTVwdDtib3JkZXI6c29saWQg
d2luZG93dGV4dCAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowY20gNS40cHQgMGNtIDUu
NHB0O2hlaWdodDoxOC40cHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0
ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPjEyNyAoaW50ZXJ3b3JraW5nIHVuc3BlY2lmaWVk
KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjI1NSIgdmFsaWduPSJ0
b3AiIHN0eWxlPSJ3aWR0aDoxOTEuMzVwdDtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9u
ZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlk
IHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0O2hlaWdodDoxOC40
cHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4g
bGFuZz0iRU4tR0IiPjQxMyBSZXF1ZXN0IEVudGl0eSB0b28gbG9uZzwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTguNHB0Ij4NCjx0ZCB3aWR0
aD0iMTk5IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjE0OS4xNXB0O2JvcmRlcjpzb2xpZCB3
aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40
cHQ7aGVpZ2h0OjE4LjRwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRl
cjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+MTI3IChpbnRlcndvcmtpbmcgdW5zcGVjaWZpZWQp
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iMjU1IiB2YWxpZ249InRv
cCIgc3R5bGU9IndpZHRoOjE5MS4zNXB0O2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25l
O2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQg
d2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRw
dCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBs
YW5nPSJFTi1HQiI+NDE0IFJlcXVlc3QtVVJJIHRvbyBsb25nPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9ImhlaWdodDoxOC40cHQiPg0KPHRkIHdpZHRoPSIx
OTkiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTQ5LjE1cHQ7Ym9yZGVyOnNvbGlkIHdpbmRv
d3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdDto
ZWlnaHQ6MTguNHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1
dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4xMjcgKGludGVyd29ya2luZyB1bnNwZWNpZmllZCk8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSIyNTUiIHZhbGlnbj0idG9wIiBz
dHlsZT0id2lkdGg6MTkxLjM1cHQ7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9y
ZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3aW5k
b3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4N
CjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9
IkVOLUdCIj40MTUgVW5zdXBwb3J0ZWQgTWVkaWEgdHlwZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTguNHB0Ij4NCjx0ZCB3aWR0aD0iMTk5
IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjE0OS4xNXB0O2JvcmRlcjpzb2xpZCB3aW5kb3d0
ZXh0IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVp
Z2h0OjE4LjRwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRv
Ij48c3BhbiBsYW5nPSJFTi1HQiI+MTI3IChpbnRlcndvcmtpbmcgdW5zcGVjaWZpZWQpPC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iMjU1IiB2YWxpZ249InRvcCIgc3R5
bGU9IndpZHRoOjE5MS4zNXB0O2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRl
ci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgd2luZG93
dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRwdCI+DQo8
cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJF
Ti1HQiI+NDE2IFVuc3VwcG9ydGVkIFVSSSBzY2hlbWU8L3NwYW4+PG86cD48L286cD48L3A+DQo8
L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE4LjRwdCI+DQo8dGQgd2lkdGg9IjE5OSIg
dmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxNDkuMTVwdDtib3JkZXI6c29saWQgd2luZG93dGV4
dCAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0O2hlaWdo
dDoxOC40cHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+
PHNwYW4gbGFuZz0iRU4tR0IiPjEyNyAoaW50ZXJ3b3JraW5nIHVuc3BlY2lmaWVkKTwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjI1NSIgdmFsaWduPSJ0b3AiIHN0eWxl
PSJ3aWR0aDoxOTEuMzVwdDtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXIt
Ym90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkIHdpbmRvd3Rl
eHQgMS4wcHQ7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0O2hlaWdodDoxOC40cHQiPg0KPHAg
Y2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4t
R0IiPjQyMCBCYWQgRXh0ZW5zaW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+
DQo8dHIgc3R5bGU9ImhlaWdodDoxOC40cHQiPg0KPHRkIHdpZHRoPSIxOTkiIHZhbGlnbj0idG9w
IiBzdHlsZT0id2lkdGg6MTQ5LjE1cHQ7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9y
ZGVyLXRvcDpub25lO3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4N
CjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9
IkVOLUdCIj4xMjcgKGludGVyd29ya2luZyB1bnNwZWNpZmllZCk8L3NwYW4+PG86cD48L286cD48
L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSIyNTUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTkx
LjM1cHQ7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xp
ZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3Bh
ZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNsYXNzPSJUQUMi
IHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj40MjEgRXh0
ZW5zaW9uIHJlcXVpcmVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIg
c3R5bGU9ImhlaWdodDoxOC40cHQiPg0KPHRkIHdpZHRoPSIxOTkiIHZhbGlnbj0idG9wIiBzdHls
ZT0id2lkdGg6MTQ5LjE1cHQ7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRv
cDpub25lO3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNs
YXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdC
Ij4xMjcgKGludGVyd29ya2luZyB1bnNwZWNpZmllZCk8L3NwYW4+PG86cD48L286cD48L3A+DQo8
L3RkPg0KPHRkIHdpZHRoPSIyNTUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTkxLjM1cHQ7
Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5k
b3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6
MGNtIDUuNHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxl
PSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj40MjMgSW50ZXJ2YWwg
VG9vIEJyaWVmPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9
ImhlaWdodDoxOC40cHQiPg0KPHRkIHdpZHRoPSIxOTkiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lk
dGg6MTQ5LjE1cHQ7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25l
O3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNsYXNzPSJU
QUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4yNCAo
Y2FsbCByZWplY3RlZCBkdWUgdG8gQUNSIHN1cHBsZW1lbnRhcnkgc2VydmljZSk8L3NwYW4+PG86
cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSIyNTUiIHZhbGlnbj0idG9wIiBzdHlsZT0i
d2lkdGg6MTkxLjM1cHQ7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJv
dHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0
IDEuMHB0O3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNs
YXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdC
Ij40MzMgQW5vbnltaXR5IERpc2FsbG93ZWQuKE5PVEUgMSk8L3NwYW4+PG86cD48L286cD48L3A+
DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE4LjRwdCI+DQo8dGQgd2lkdGg9IjE5
OSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxNDkuMTVwdDtib3JkZXI6c29saWQgd2luZG93
dGV4dCAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0O2hl
aWdodDoxOC40cHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0
byI+PGI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJiYWNrZ3JvdW5kOnllbGxvdzttc28taGln
aGxpZ2h0OnllbGxvdyI+MjAgU3Vic2NyaWJlciBhYnNlbnQ8L3NwYW4+PC9iPjxvOnA+PC9vOnA+
PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iMjU1IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjE5
MS4zNXB0O2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29s
aWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtw
YWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRwdCI+DQo8cCBjbGFzcz0iVEFD
IiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48Yj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5
bGU9ImJhY2tncm91bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93Ij40ODAgVGVtcG9yYXJp
bHkgVW5hdmFpbGFibGU8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8
dHIgc3R5bGU9ImhlaWdodDoxOC40cHQiPg0KPHRkIHdpZHRoPSIxOTkiIHZhbGlnbj0idG9wIiBz
dHlsZT0id2lkdGg6MTQ5LjE1cHQ7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVy
LXRvcDpub25lO3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxw
IGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVO
LUdCIj4xMjcgKGludGVyd29ya2luZyB1bnNwZWNpZmllZCk8L3NwYW4+PG86cD48L286cD48L3A+
DQo8L3RkPg0KPHRkIHdpZHRoPSIyNTUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTkxLjM1
cHQ7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3
aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRp
bmc6MGNtIDUuNHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0
eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj40ODEgQ2FsbC9U
cmFuc2FjdGlvbiBkb2VzIG5vdCBleGlzdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8
L3RyPg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTguNHB0Ij4NCjx0ZCB3aWR0aD0iMTk5IiB2YWxpZ249
InRvcCIgc3R5bGU9IndpZHRoOjE0OS4xNXB0O2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0
O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRw
dCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBs
YW5nPSJFTi1HQiI+MTI3IChpbnRlcndvcmtpbmcgdW5zcGVjaWZpZWQpPC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iMjU1IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRo
OjE5MS4zNXB0O2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206
c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgd2luZG93dGV4dCAxLjBw
dDtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRwdCI+DQo8cCBjbGFzcz0i
VEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+NDgy
IExvb3AgZGV0ZWN0ZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBz
dHlsZT0iaGVpZ2h0OjE4LjRwdCI+DQo8dGQgd2lkdGg9IjE5OSIgdmFsaWduPSJ0b3AiIHN0eWxl
PSJ3aWR0aDoxNDkuMTVwdDtib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItdG9w
Om5vbmU7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0O2hlaWdodDoxOC40cHQiPg0KPHAgY2xh
c3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0Ii
PjEyNyAoaW50ZXJ3b3JraW5nIHVuc3BlY2lmaWVkKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv
dGQ+DQo8dGQgd2lkdGg9IjI1NSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxOTEuMzVwdDti
b3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRv
d3RleHQgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzow
Y20gNS40cHQgMGNtIDUuNHB0O2hlaWdodDoxOC40cHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9
InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPjQ4MyBUb28gbWFueSBo
b3BzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9ImhlaWdo
dDoxOC40cHQiPg0KPHRkIHdpZHRoPSIxOTkiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTQ5
LjE1cHQ7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRp
bmc6MGNtIDUuNHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0
eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4yOCAoSW52YWxp
ZCBOdW1iZXIgZm9ybWF0KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9
IjI1NSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxOTEuMzVwdDtib3JkZXItdG9wOm5vbmU7
Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9y
ZGVyLXJpZ2h0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20gNS40cHQgMGNtIDUu
NHB0O2hlaWdodDoxOC40cHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0
ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPjQ4NCBBZGRyZXNzIEluY29tcGxldGU8L3NwYW4+
PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE4LjRwdCI+
DQo8dGQgd2lkdGg9IjE5OSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxNDkuMTVwdDtib3Jk
ZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowY20gNS40
cHQgMGNtIDUuNHB0O2hlaWdodDoxOC40cHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2Ut
YnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPjEyNyAoaW50ZXJ3b3JraW5nIHVu
c3BlY2lmaWVkKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjI1NSIg
dmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxOTEuMzVwdDtib3JkZXItdG9wOm5vbmU7Ym9yZGVy
LWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXJp
Z2h0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0O2hl
aWdodDoxOC40cHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0
byI+PHNwYW4gbGFuZz0iRU4tR0IiPjQ4NSBBbWJpZ3VvdXM8L3NwYW4+PG86cD48L286cD48L3A+
DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE4LjRwdCI+DQo8dGQgd2lkdGg9IjE5
OSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxNDkuMTVwdDtib3JkZXI6c29saWQgd2luZG93
dGV4dCAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0O2hl
aWdodDoxOC40cHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0
byI+PHNwYW4gbGFuZz0iRU4tR0IiPjE3IChVc2VyIGJ1c3kpPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPC90ZD4NCjx0ZCB3aWR0aD0iMjU1IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjE5MS4z
NXB0O2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQg
d2luZG93dGV4dCAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRk
aW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRwdCI+DQo8cCBjbGFzcz0iVEFDIiBz
dHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+NDg2IEJ1c3kg
SGVyZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJoZWln
aHQ6MTguNHB0Ij4NCjx0ZCB3aWR0aD0iMTk5IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjE0
OS4xNXB0O2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRk
aW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRwdCI+DQo8cCBjbGFzcz0iVEFDIiBz
dHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+MTI3IChJbnRl
cndvcmtpbmcgdW5zcGVjaWZpZWQpIG9yIG5vdCBpbnRlcndvcmtlZC4gKE5PVEUgMik8L3NwYW4+
PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSIyNTUiIHZhbGlnbj0idG9wIiBzdHls
ZT0id2lkdGg6MTkxLjM1cHQ7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVy
LWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0
ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxw
IGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVO
LUdCIj40ODcgUmVxdWVzdCB0ZXJtaW5hdGVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4N
CjwvdHI+DQo8dHIgc3R5bGU9ImhlaWdodDoxOC40cHQiPg0KPHRkIHdpZHRoPSIxOTkiIHZhbGln
bj0idG9wIiBzdHlsZT0id2lkdGg6MTQ5LjE1cHQ7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4w
cHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTgu
NHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFu
IGxhbmc9IkVOLUdCIj4xMjcgKGludGVyd29ya2luZyB1bnNwZWNpZmllZCk8L3NwYW4+PG86cD48
L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSIyNTUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lk
dGg6MTkxLjM1cHQ7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRv
bTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEu
MHB0O3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNsYXNz
PSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj40
ODggTm90IGFjY2VwdGFibGUgaGVyZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3Ry
Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTguNHB0Ij4NCjx0ZCB3aWR0aD0iMTk5IiB2YWxpZ249InRv
cCIgc3R5bGU9IndpZHRoOjE0OS4xNXB0O2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2Jv
cmRlci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRwdCI+
DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5n
PSJFTi1HQiI+MTI3IChpbnRlcndvcmtpbmcgdW5zcGVjaWZpZWQpPC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iMjU1IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjE5
MS4zNXB0O2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29s
aWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtw
YWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRwdCI+DQo8cCBjbGFzcz0iVEFD
IiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+NDkzIFVu
ZGVjaXBoZXJhYmxlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5
bGU9ImhlaWdodDoxOC40cHQiPg0KPHRkIHdpZHRoPSIxOTkiIHZhbGlnbj0idG9wIiBzdHlsZT0i
d2lkdGg6MTQ5LjE1cHQ7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpu
b25lO3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNsYXNz
PSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4x
MjcgKGludGVyd29ya2luZyB1bnNwZWNpZmllZCk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3Rk
Pg0KPHRkIHdpZHRoPSIyNTUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTkxLjM1cHQ7Ym9y
ZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0
ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNt
IDUuNHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJw
YWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj41MDAgU2VydmVyIEludGVy
bmFsIGVycm9yPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9
ImhlaWdodDoxOC40cHQiPg0KPHRkIHdpZHRoPSIxOTkiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lk
dGg6MTQ5LjE1cHQ7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25l
O3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNsYXNzPSJU
QUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4xMjcg
KGludGVyd29ya2luZyB1bnNwZWNpZmllZCk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0K
PHRkIHdpZHRoPSIyNTUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTkxLjM1cHQ7Ym9yZGVy
LXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0
IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUu
NHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdl
LWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj41MDEgTm90IGltcGxlbWVudGVk
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9ImhlaWdodDox
OC40cHQiPg0KPHRkIHdpZHRoPSIxOTkiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTQ5LjE1
cHQ7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6
MGNtIDUuNHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxl
PSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4xMjcgKGludGVyd29y
a2luZyB1bnNwZWNpZmllZCk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRo
PSIyNTUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTkxLjM1cHQ7Ym9yZGVyLXRvcDpub25l
O2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2Jv
cmRlci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1
LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFm
dGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj41MDIgQmFkIEdhdGV3YXk8L3NwYW4+PG86cD48
L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE4LjRwdCI+DQo8dGQg
d2lkdGg9IjE5OSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxNDkuMTVwdDtib3JkZXI6c29s
aWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowY20gNS40cHQgMGNt
IDUuNHB0O2hlaWdodDoxOC40cHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWst
YWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPjEyNyAoaW50ZXJ3b3JraW5nIHVuc3BlY2lm
aWVkKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjI1NSIgdmFsaWdu
PSJ0b3AiIHN0eWxlPSJ3aWR0aDoxOTEuMzVwdDtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6
bm9uZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNv
bGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0O2hlaWdodDox
OC40cHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNw
YW4gbGFuZz0iRU4tR0IiPjUwMyBTZXJ2aWNlIFVuYXZhaWxhYmxlPC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9ImhlaWdodDoxOC40cHQiPg0KPHRkIHdpZHRo
PSIxOTkiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTQ5LjE1cHQ7Ym9yZGVyOnNvbGlkIHdp
bmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRw
dDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVy
OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4xMjcgKGludGVyd29ya2luZyB1bnNwZWNpZmllZCk8
L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSIyNTUiIHZhbGlnbj0idG9w
IiBzdHlsZT0id2lkdGg6MTkxLjM1cHQ7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7
Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3
aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTguNHB0
Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxh
bmc9IkVOLUdCIj41MDQgU2VydmVyIHRpbWVvdXQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3Rk
Pg0KPC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE4LjRwdCI+DQo8dGQgd2lkdGg9IjE5OSIgdmFs
aWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxNDkuMTVwdDtib3JkZXI6c29saWQgd2luZG93dGV4dCAx
LjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0O2hlaWdodDox
OC40cHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNw
YW4gbGFuZz0iRU4tR0IiPjEyNyAoaW50ZXJ3b3JraW5nIHVuc3BlY2lmaWVkKTwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjI1NSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3
aWR0aDoxOTEuMzVwdDtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90
dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkIHdpbmRvd3RleHQg
MS4wcHQ7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0O2hlaWdodDoxOC40cHQiPg0KPHAgY2xh
c3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0Ii
PjUwNSBWZXJzaW9uIG5vdCBzdXBwb3J0ZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0K
PC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE4LjRwdCI+DQo8dGQgd2lkdGg9IjE5OSIgdmFsaWdu
PSJ0b3AiIHN0eWxlPSJ3aWR0aDoxNDkuMTVwdDtib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBw
dDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0O2hlaWdodDoxOC40
cHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4g
bGFuZz0iRU4tR0IiPjEyNyAoaW50ZXJ3b3JraW5nIHVuc3BlY2lmaWVkKTwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjI1NSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0
aDoxOTEuMzVwdDtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9t
OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkIHdpbmRvd3RleHQgMS4w
cHQ7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0O2hlaWdodDoxOC40cHQiPg0KPHAgY2xhc3M9
IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPjUx
MyBNZXNzYWdlIHRvbyBsYXJnZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0K
PHRyIHN0eWxlPSJoZWlnaHQ6MTguNHB0Ij4NCjx0ZCB3aWR0aD0iMTk5IiB2YWxpZ249InRvcCIg
c3R5bGU9IndpZHRoOjE0OS4xNXB0O2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRl
ci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRwdCI+DQo8
cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJF
Ti1HQiI+MTI3IChpbnRlcndvcmtpbmcgdW5zcGVjaWZpZWQpPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPC90ZD4NCjx0ZCB3aWR0aD0iMjU1IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjE5MS4z
NXB0O2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQg
d2luZG93dGV4dCAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRk
aW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRwdCI+DQo8cCBjbGFzcz0iVEFDIiBz
dHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+NTgwIFByZWNv
bmRpdGlvbiBmYWlsdXJlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIg
c3R5bGU9ImhlaWdodDoxOC40cHQiPg0KPHRkIHdpZHRoPSIxOTkiIHZhbGlnbj0idG9wIiBzdHls
ZT0id2lkdGg6MTQ5LjE1cHQ7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRv
cDpub25lO3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNs
YXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdC
Ij4xNyAoVXNlciBidXN5KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9
IjI1NSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxOTEuMzVwdDtib3JkZXItdG9wOm5vbmU7
Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9y
ZGVyLXJpZ2h0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20gNS40cHQgMGNtIDUu
NHB0O2hlaWdodDoxOC40cHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0
ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPjYwMCBCdXN5IEV2ZXJ5d2hlcmU8L3NwYW4+PG86
cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE4LjRwdCI+DQo8
dGQgd2lkdGg9IjE5OSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxNDkuMTVwdDtib3JkZXI6
c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowY20gNS40cHQg
MGNtIDUuNHB0O2hlaWdodDoxOC40cHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJl
YWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPjIxIChDYWxsIHJlamVjdGVkKTwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjI1NSIgdmFsaWduPSJ0b3AiIHN0
eWxlPSJ3aWR0aDoxOTEuMzVwdDtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3Jk
ZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkIHdpbmRv
d3RleHQgMS4wcHQ7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0O2hlaWdodDoxOC40cHQiPg0K
PHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0i
RU4tR0IiPjYwMyBEZWNsaW5lPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8
dHIgc3R5bGU9ImhlaWdodDoxOC40cHQiPg0KPHRkIHdpZHRoPSIxOTkiIHZhbGlnbj0idG9wIiBz
dHlsZT0id2lkdGg6MTQ5LjE1cHQ7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVy
LXRvcDpub25lO3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxw
IGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVO
LUdCIj4xICh1bmFsbG9jYXRlZCBudW1iZXIpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4N
Cjx0ZCB3aWR0aD0iMjU1IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjE5MS4zNXB0O2JvcmRl
ci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4
dCAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSA1
LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFn
ZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+NjA0IERvZXMgbm90IGV4aXN0
IGFueXdoZXJlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9
ImhlaWdodDoxOC40cHQiPg0KPHRkIHdpZHRoPSIxOTkiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lk
dGg6MTQ5LjE1cHQ7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25l
O3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNsYXNzPSJU
QUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4xMjcg
KGludGVyd29ya2luZyB1bnNwZWNpZmllZCk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0K
PHRkIHdpZHRoPSIyNTUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTkxLjM1cHQ7Ym9yZGVy
LXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0
IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUu
NHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdl
LWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj42MDYgTm90IGFjY2VwdGFibGU8
L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0icGFnZS1icmVh
ay1pbnNpZGU6YXZvaWQ7aGVpZ2h0OjE4LjRwdCI+DQo8dGQgd2lkdGg9IjQ1NCIgY29sc3Bhbj0i
MiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDozNDAuNXB0O2JvcmRlcjpzb2xpZCB3aW5kb3d0
ZXh0IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVp
Z2h0OjE4LjRwdCI+DQo8cCBjbGFzcz0iVEFOIj48c3BhbiBsYW5nPSJFTi1HQiI+Tk9URSAxOiZu
YnNwOyZuYnNwOyZuYnNwOyBBbm9ueW1pdHkgRGlzYWxsb3dlZCwgUkZDIDUwNzkgWzc3XSByZWZl
cnMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9IlRBTiI+PHNwYW4gbGFuZz0iRU4t
R0IiPk5PVEUgMjombmJzcDsmbmJzcDsmbmJzcDsgTm8gaW50ZXJ3b3JraW5nIGlmIHRoZSBPLU1H
Q0YgcHJldmlvdXNseSBpc3N1ZWQgYSBDQU5DRUwgcmVxdWVzdCBmb3IgdGhlIElOVklURS48L3Nw
YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iVEFOIj48c3BhbiBsYW5nPSJFTi1HQiI+Tk9U
RSAzOiZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgNHh4LzV4eC82eHggU0lQIHJlc3BvbnNlcyB0aGF0
IGFyZSBub3QgY292ZXJlZCBpbiB0aGlzIHRhYmxlIGFyZSBub3QgaW50ZXJ3b3JrZWQuPC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvZGl2
Pg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IlNMIiBzdHlsZT0iZm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s
ZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iU0wiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5CUiBBbGXFoTwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxz
cGFuIGxhbmc9IlNMIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk
aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk
aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn
aW4tbGVmdDozNi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh
bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo
b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBDYWxtZSwgSmFtZXMgQSAoSmltKSBb
PGEgaHJlZj0ibWFpbHRvOmppbS5jYWxtZUBhbGNhdGVsLWx1Y2VudC5jb20iPm1haWx0bzpqaW0u
Y2FsbWVAYWxjYXRlbC1sdWNlbnQuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiAyNS4gamFu
dWFyIDIwMTMgMTU6MjM8YnI+DQo8Yj5Ubzo8L2I+IENocmlzdGVyIEhvbG1iZXJnOyDFoGxpYmVy
IEFsZcWhOyA8YSBocmVmPSJtYWlsdG86ZGlzcGF0Y2hAaWV0Zi5vcmciPmRpc3BhdGNoQGlldGYu
b3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogUkZDIDMzOTggLSBwcm9ibGVtcyB3aXRo
IElTVVAgY2F1c2UgbWFwcGluZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBs
YW5nPSJTTCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx
dW90O1RyZWJ1Y2hldCBNUyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDcw
QzAiPlBsZWFzZSByZWZlcmVuY2UgM0dQUCBUUyAyOS4xNjMsIG11Y2ggd29yayBhcyBiZWVuIGRv
bmUgb24gdGhpcyBkb2N1bWVudCBvdmVyIHRoZSBsYXN0IGNvdXBsZSB5ZWFycyB0byBhZGRyZXNz
IG1hcHBpbmcgY29uY2VybnMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5
OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMw
MDcwQzAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv
dDtUcmVidWNoZXQgTVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3MEMw
Ij5KaW08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVj
aGV0IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwNzBDMCI+Jm5ic3A7
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv
cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPjxiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPg0KPGEgaHJlZj0ibWFpbHRvOmRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmciPmRp
c3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFs8YSBocmVmPSJtYWlsdG86ZGlzcGF0Y2gtYm91
bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+
T24gQmVoYWxmIE9mIDwvYj5DaHJpc3RlciBIb2xtYmVyZzxicj4NCjxiPlNlbnQ6PC9iPiBGcmlk
YXksIEphbnVhcnkgMjUsIDIwMTMgODoxOCBBTTxicj4NCjxiPlRvOjwvYj4gxaBsaWJlciBBbGXF
oTsgPGEgaHJlZj0ibWFpbHRvOmRpc3BhdGNoQGlldGYub3JnIj5kaXNwYXRjaEBpZXRmLm9yZzwv
YT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtkaXNwYXRjaF0gUkZDIDMzOTggLSBwcm9ibGVt
cyB3aXRoIElTVVAgY2F1c2UgbWFwcGluZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t
bGVmdDo3Mi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5IaSw8L3NwYW4+PG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0
Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+PHNwYW4g
c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoZXJlIGlzIG5vIG5ldyBSRkMsIGJ1dCBTRE9zIGxpa2Ug
SVRVLVQgYW5kIDNHUFAgaGF2ZSBzcGVjaWZpZWQgbWFwcGluZyB3aGljaCBpbiBzb21lIGNhc2Vz
IGRpZmZlcnMgZnJvbSB0aGUgUkZDLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjoj
MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+
UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp
bi1sZWZ0OjcyLjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkNocmlzdGVyPC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0
OjcyLjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk
ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjxh
IGhyZWY9Im1haWx0bzpkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnIj5kaXNwYXRjaC1ib3VuY2Vz
QGlldGYub3JnPC9hPiBbPGEgaHJlZj0ibWFpbHRvOmRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmci
Pm1haWx0bzpkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8
L2I+xaBsaWJlciBBbGXFoTxicj4NCjxiPlNlbnQ6PC9iPiAyNS4gdGFtbWlrdXV0YSAyMDEzIDk6
MDI8YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpkaXNwYXRjaEBpZXRmLm9yZyI+ZGlz
cGF0Y2hAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbZGlzcGF0Y2hdIFJG
QyAzMzk4IC0gcHJvYmxlbXMgd2l0aCBJU1VQIGNhdXNlIG1hcHBpbmc8L3NwYW4+PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp
bi1sZWZ0OjcyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48c3BhbiBsYW5nPSJTTCIgc3R5bGU9ImZvbnQt
ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkhpLDwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm
dDo3Mi4wcHQiPjxzcGFuIGxhbmc9IlNMIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+PHNwYW4g
bGFuZz0iU0wiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7Ij5JJ20gbW9iaWxlIGNvcmUgbmV0d29yayBlbmdpbmVlciB3b3JraW5nIGEg
bG90IHdpdGggSVNVUCB0byBTSVAgbWFwcGluZyBhbmQgdmljZSB2ZXJzYS48L3NwYW4+PG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0
Ij48c3BhbiBsYW5nPSJTTCIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDsiPkkgY29tZSB1cCB0byBhbiB1bnNvbHZlZCBwcm9ibGVtIHdp
dGggbWFwcGluZyB0aGUgdHJhZmZpYyBmcm9tIElTVVAgdG8gU0lQIGFuZCBiYWNrIHRvIElTVVAu
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp
bi1sZWZ0OjcyLjBwdCI+PHNwYW4gbGFuZz0iU0wiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48
c3BhbiBsYW5nPSJTTCIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDsiPkZyb20gUkZDIDMzOTg6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+PHNwYW4gbGFu
Zz0iU0wiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48Yj48c3BhbiBsYW5nPSJTTCIgc3R5bGU9
ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPklT
VVAtU0lQPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPjxiPjxzcGFuIGxhbmc9IlNMIiBzdHlsZT0iZm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7Jm5i
c3A7DQo8c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+MTggbm8gdXNlciByZXNwb25kaW5nJm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDQwOCBSZXF1
ZXN0IFRpbWVvdXQ8L3NwYW4+PC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPjxzcGFuIGxhbmc9IlNMIiBzdHls
ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+
Jm5ic3A7Jm5ic3A7DQo8Yj48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+MTkgbm8gYW5zd2Vy
IGZyb20gdGhlIHVzZXImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNDgwIFRlbXBvcmFyaWx5IHVuYXZh
aWxhYmxlPC9zcGFuPjwvYj48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48c3BhbiBsYW5nPSJTTCIgc3R5bGU9ImZv
bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNw
OyZuYnNwOyAyMCBzdWJzY3JpYmVyIGFic2VudCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA0ODAgVGVtcG9yYXJpbHkgdW5hdmFpbGFibGU8
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu
LWxlZnQ6NzIuMHB0Ij48c3BhbiBsYW5nPSJTTCIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy
aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Ojcy
LjBwdCI+PGI+PHNwYW4gbGFuZz0iU0wiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TSVAtSVNVUDo8L3NwYW4+PC9iPjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+
PHNwYW4gbGFuZz0iU0wiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsNCjxiPjxzcGFuIHN0eWxlPSJjb2xvcjoj
MDA3MEMwIj40MDggUmVxdWVzdCB0aW1lb3V0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IDEwMiBSZWNvdmVyeSBvbiB0aW1lciBleHBpcnk8L3NwYW4+PC9iPjwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t
bGVmdDo3Mi4wcHQiPjxzcGFuIGxhbmc9IlNMIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7DQo8Yj48c3BhbiBz
dHlsZT0iY29sb3I6IzAwQjA1MCI+NDgwIFRlbXBvcmFyaWx5IHVuYXZhaWxhYmxlJm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDE4IE5v
IHVzZXIgcmVzcG9uZGluZzwvc3Bhbj48L2I+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+PHNwYW4gbGFuZz0iU0wi
IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48c3BhbiBsYW5nPSJTTCIgc3R5bGU9ImZvbnQtZmFt
aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNvIGlmIEkgc2Vu
ZCBmcm9tIElTVVAgUkVMLTE5IGFuZCB0aGlzIHRyYWZpYyB3ZW50cyBtYXBzIHRvIFNJUCBhbmQg
dGhlbiBiYWNrIHRvIElTVVAsIEkgcmVjZWl2ZSBvbiB0aGUgb3RoZXIgc2lkZSBJU1VQIFJFTC0x
OC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy
Z2luLWxlZnQ6NzIuMHB0Ij48c3BhbiBsYW5nPSJTTCIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90
O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoZXJlIGlzIHRoZSBzYW1lIHN0
b3J5IHdpdGggSVNVUCBSRUwxOCBtYXBwbmcgdG8gU0lQIGFuZCBiYWNrIHRvIElTVVAg4oCTIEkg
d2lsbCByZWNlaXZlIElTVVAgUkVMLjEwMj8hPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+PHNwYW4gbGFuZz0iU0wi
IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48c3BhbiBsYW5nPSJTTCIgc3R5bGU9ImZvbnQtZmFt
aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkNhbiB5b3UgaGVs
cCBtZSB3aXRoIHRoaXMgaXN1ZS4gSXMgdGhlcmUgYW55IG5ldyBSRkMgaG93IHRvIG1hcCB0aGlz
IGtpbmQgb2YgdHJhZmZpYz88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48c3BhbiBsYW5nPSJTTCIgc3R5bGU9ImZv
bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNw
Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn
aW4tbGVmdDo3Mi4wcHQiPjxzcGFuIGxhbmc9IlNMIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhhbmsgeW91LDwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4w
cHQiPjxzcGFuIGxhbmc9IlNMIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QlIgQWxlcyBTbGliZXI8L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48Yj48
c3BhbiBsYW5nPSJTTCIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvYj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4w
cHQ7YmFja2dyb3VuZDojRjNGM0YzIj48Yj48c3BhbiBsYW5nPSJTTCIgc3R5bGU9ImZvbnQtc2l6
ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOnJlZCI+QWxlxaEgxaBsaWJlcjwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O2JhY2tncm91bmQ6
I0YzRjNGMyI+PHNwYW4gbGFuZz0iU0wiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpncmF5Ij5D
b3JlIG5ldHdvcmsgZW5naW5lZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O2JhY2tncm91bmQ6I0YzRjNGMyI+PHNw
YW4gbGFuZz0iU0wiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGVsOg0KPC9zcGFu
PjxzcGFuIGxhbmc9IlNMIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzNjZGRiI+JiM0Mzsz
ODYtMS00NzItODQ4Mjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7YmFja2dyb3VuZDojRjNGM0YzIj48c3BhbiBsYW5n
PSJTTCIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5XLW1vYmlsZToNCjwvc3Bhbj48
c3BhbiBsYW5nPSJTTCIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzY2RkYiPjxhIGhyZWY9
Imh0dHA6Ly93d3cubW9iaXRlbC5zaS8iPnd3dy5tb2JpdGVsLnNpPC9hPjwvc3Bhbj48c3BhbiBs
YW5nPSJTTCIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7YmFja2dyb3VuZDoj
RjNGM0YzIj48c3BhbiBsYW5nPSJTTCIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5X
LWZpeDoNCjwvc3Bhbj48c3BhbiBsYW5nPSJTTCIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMz
MzY2RkYiPjxhIGhyZWY9Imh0dHA6Ly93d3cudGVsZWtvbS5zaS8iPnd3dy50ZWxla29tLnNpPC9h
Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn
aW4tbGVmdDo3Mi4wcHQ7YmFja2dyb3VuZDojRjNGM0YzIj48Yj48c3BhbiBsYW5nPSJTTCIgc3R5
bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDcwQzAiPlRlbGVrb208L3NwYW4+PC9iPjxzcGFuIGxh
bmc9IlNMIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwNzBDMCI+DQo8L3NwYW4+PGI+PHNw
YW4gbGFuZz0iU0wiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMEYwIj5TbG92ZW5pamU8
L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h
cmdpbi1sZWZ0OjcyLjBwdCI+PHNwYW4gbGFuZz0iU0wiIHN0eWxlPSJmb250LWZhbWlseTomcXVv
dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn
aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rp
bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+X19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpkaXNwYXRjaCBtYWlsaW5nIGxpc3Q8
YnI+DQo8YSBocmVmPSJtYWlsdG86ZGlzcGF0Y2hAaWV0Zi5vcmciPmRpc3BhdGNoQGlldGYub3Jn
PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
ZGlzcGF0Y2giPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2g8
L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N
CjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_7594FB04B1934943A5C02806D1A2204B0CB9CAESESSMB209ericsso_--

From Ales.Sliber@telekom.si  Mon Jan 28 07:10:40 2013
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C84F21F87DF for ; Mon, 28 Jan 2013 07:10:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.668
X-Spam-Level: 
X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[AWL=0.629,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWXe7XZfuj5c for ; Mon, 28 Jan 2013 07:10:33 -0800 (PST)
Received: from smtp1.telekom.si (smtp1.telekom.si [193.77.55.37]) by ietfa.amsl.com (Postfix) with ESMTP id C84AF21F87AA for ; Mon, 28 Jan 2013 07:10:30 -0800 (PST)
Received: from srexch16.ts.telekom.si (cas.ts.telekom.si) by srmps01.ts.telekom.si (Clearswift SMTPRS 5.5.0) with ESMTP id ;  Mon, 28 Jan 2013 16:10:29 +0100
Received: from SREXDB14.ts.telekom.si ([169.254.4.68]) by srexch16.ts.telekom.si ([192.168.27.209]) with mapi id 14.02.0247.003; Mon, 28 Jan 2013 16:10:28 +0100
From: =?utf-8?B?xaBsaWJlciBBbGXFoQ==?= 
To: Christer Holmberg , Adam Roach , "Calme, James A (Jim)" 
Thread-Topic: [dispatch] RFC 3398 - problems with ISUP cause mapping
Thread-Index: Ac36L/Ouvi96ppcBSLCYfqPfGqmxGAAl8IiQAACHohAADzCpEAAAKSbQAIxAG4AACh/T0P//9rKA///s6sD//9J28A==
Date: Mon, 28 Jan 2013 15:10:26 +0000
Message-ID: <26300ECDDED68545A78AAC3D98640BF3A157FC84@srexdb14.ts.telekom.si>
References: <26300ECDDED68545A78AAC3D98640BF3A157E82F@srexdb14.ts.telekom.si> <7594FB04B1934943A5C02806D1A2204B0CA15E@ESESSMB209.ericsson.se> <7B8DC1AC12241143921AC7733AF3C17B1DF55878@US70TWXCHMBA10.zam.alcatel-lucent.com> <26300ECDDED68545A78AAC3D98640BF3A157F8B6@srexdb14.ts.telekom.si> <7B8DC1AC12241143921AC7733AF3C17B1DF55C31@US70TWXCHMBA10.zam.alcatel-lucent.com> <13B6E229-4EBB-4086-8889-0CE9DD1E72B0@nostrum.com> <7594FB04B1934943A5C02806D1A2204B0CB9CA@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0CB9CA@ESESSMB209.ericsson.se>
Accept-Language: sl-SI, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.13.3.86]
Content-Type: multipart/alternative; boundary="_000_26300ECDDED68545A78AAC3D98640BF3A157FC84srexdb14tstelek_"
MIME-Version: 1.0
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] RFC 3398 - problems with ISUP cause mapping
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Jan 2013 15:10:40 -0000

--_000_26300ECDDED68545A78AAC3D98640BF3A157FC84srexdb14tstelek_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgdG8gZXZlcnlvbmUuDQpZZXMgY29ycmVjdCwgSSdtIHRhbGtpbmcgYWJvdXQgZG91YmxlIG1h
cHBpbmcgSVNVUCAtLT4gU0lQIC0tPiBJU1VQIGFuZCBub3QgYWJvdXQgU0lQLUkuDQoNCk9LLCBJ
IHdpbGwgY2hlY2sgdGhpcyDCu1JlYXNvbiBoZWFkZXIgZmllbGTCqy4NCg0KVGhueHMgdG8gYWxs
LA0KQlIgQWxlxaENCg0KRnJvbTogQ2hyaXN0ZXIgSG9sbWJlcmcgW21haWx0bzpjaHJpc3Rlci5o
b2xtYmVyZ0Blcmljc3Nvbi5jb21dDQpTZW50OiAyOC4gamFudWFyIDIwMTMgMTU6NDQNClRvOiBB
ZGFtIFJvYWNoOyBDYWxtZSwgSmFtZXMgQSAoSmltKQ0KQ2M6IMWgbGliZXIgQWxlxaE7IGRpc3Bh
dGNoQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW2Rpc3BhdGNoXSBSRkMgMzM5OCAtIHByb2JsZW1z
IHdpdGggSVNVUCBjYXVzZSBtYXBwaW5nDQoNCkhpLA0KDQo+R3V5cywgeW91J3JlIGRvaW5nIGl0
IHdyb25nLiBDb21wbGV0ZWx5IHdyb25nLg0KPg0KPkdvIGJhY2sgYW5kIHJlYWQgbXkgcmVzcG9u
c2UgZnJvbSBGcmlkYXkuDQoNCk1heWJlIEnigJl2ZSBtaXNzZWQgc29tZXRoaW5nLCBidXQgSSBk
b27igJl0IHRoaW5rIElTVVAgdHVubmVsaW5nIGlzIHVzZWQgaW4gdGhlIGNhc2UgYmVpbmcgZGlz
Y3Vzc2VkLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KT24gSmFuIDI4LCAyMDEzLCBh
dCA4OjA5LCAiQ2FsbWUsIEphbWVzIEEgKEppbSkiIDxqaW0uY2FsbWVAYWxjYXRlbC1sdWNlbnQu
Y29tPG1haWx0bzpqaW0uY2FsbWVAYWxjYXRlbC1sdWNlbnQuY29tPj4gd3JvdGU6DQpUcnVlLCBp
dCBpcyBub3QgMTAwJSBzeW1tZXRyaWMuDQpJZiBpdCBpcyByZXF1aXJlZCB0byBtYWludGFpbiB0
aGUgb3JpZ2luYWwgSVNVUCBjYXVzZSwgdGhlbiBJIHdvdWxkIHN1Z2dlc3QgdXNpbmcgdGhlIFJl
YXNvbiBoZWFkZXIgZmllbGQuDQpKaW0NCg0KRnJvbTogxaBsaWJlciBBbGXFoSBbbWFpbHRvOkFs
ZXMuU2xpYmVyQHRlbGVrb20uc2ldDQpTZW50OiBNb25kYXksIEphbnVhcnkgMjgsIDIwMTMgMzoy
MyBBTQ0KVG86IENhbG1lLCBKYW1lcyBBIChKaW0pOyBDaHJpc3RlciBIb2xtYmVyZzsgZGlzcGF0
Y2hAaWV0Zi5vcmc8bWFpbHRvOmRpc3BhdGNoQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFJGQyAz
Mzk4IC0gcHJvYmxlbXMgd2l0aCBJU1VQIGNhdXNlIG1hcHBpbmcNCg0KSGksDQoNClRoYW5rIHlv
dSBmb3IgcmVwbHksIGJ1dCBhcyBJIGNhbiBzZWUsIGZyb20gM0dQUCBUUyAyOS4xNjMgZG9jdW1l
bnQg4oCTIHRoZXJlIGlzIHF1aXRlIHRoZSBzYW1lIHN0b3J5IChtYWJ5IGV2ZW4gd29yc3Qg4oCT
IGJlY2F1c2UgSVNVUCAxOCBpcyBtYXBkIGFsc28gaW4gU0lQIDQ4MCBhbmQgbm90IGluLXRvIFNJ
UC00MDggYXMgaW4gUkZDKToNCg0KDQpUYWJsZSA5OiBSZWNlaXB0IG9mIHRoZSBSZWxlYXNlIG1l
c3NhZ2UgKFJFTCkNCg0K4oCiU0lQIE1lc3NhZ2UNCg0KDQrigKIgUkVMDQoNCg0KU3RhdHVzIGNv
ZGUNCg0KDQpDYXVzZSBwYXJhbWV0ZXINCg0KDQo0MDQgTm90IEZvdW5kDQoNCg0KQ2F1c2UgdmFs
dWUgTm8uIDEgKHVuYWxsb2NhdGVkICh1bmFzc2lnbmVkKSBudW1iZXIpDQoNCg0KNTAwIFNlcnZl
ciBJbnRlcm5hbCBlcnJvcg0KDQoNCkNhdXNlIHZhbHVlIE5vIDIgKG5vIHJvdXRlIHRvIG5ldHdv
cmspDQoNCg0KNTAwIFNlcnZlciBJbnRlcm5hbCBlcnJvcg0KDQoNCkNhdXNlIHZhbHVlIE5vIDMg
KG5vIHJvdXRlIHRvIGRlc3RpbmF0aW9uKQ0KDQoNCjUwMCBTZXJ2ZXIgSW50ZXJuYWwgZXJyb3IN
Cg0KDQpDYXVzZSB2YWx1ZSBOby4gNCAoU2VuZCBzcGVjaWFsIGluZm9ybWF0aW9uIHRvbmUpDQoN
Cg0KNDA0IE5vdCBGb3VuZA0KDQoNCkNhdXNlIHZhbHVlIE5vLiA1IChNaXNkaWFsbGVkIHRydW5r
IHByZWZpeCkNCg0KDQo0ODYgQnVzeSBIZXJlDQoNCg0KQ2F1c2UgdmFsdWUgTm8uIDE3ICh1c2Vy
IGJ1c3kpDQoNCg0KNDgwIFRlbXBvcmFyaWx5IHVuYXZhaWxhYmxlDQoNCg0KQ2F1c2UgdmFsdWUg
Tm8gMTggKG5vIHVzZXIgcmVzcG9uZGluZykNCg0KDQo0ODAgVGVtcG9yYXJpbHkgdW5hdmFpbGFi
bGUNCg0KDQpDYXVzZSB2YWx1ZSBObyAxOSAobm8gYW5zd2VyIGZyb20gdGhlIHVzZXIpDQoNCg0K
NDgwIFRlbXBvcmFyaWx5IHVuYXZhaWxhYmxlDQoNCg0KQ2F1c2UgdmFsdWUgTm8uIDIwIChzdWJz
Y3JpYmVyIGFic2VudCkNCg0KDQo2MDMgRGVjbGluZQ0KDQoNCkNhdXNlIHZhbHVlIE5vIDIxIChj
YWxsIHJlamVjdGVkKSwgTG9jYXRpb24gPSAwMDAgLyB1c2VyIChVKQ0KDQoNCjQ4MFRlbXBvcmFy
aWx5IHVuYXZhaWxhYmxlDQoNCg0KQ2F1c2UgdmFsdWUgTm8gMjEgKGNhbGwgcmVqZWN0ZWQpICwg
TG9jYXRpb24gPD4gMDAwIC8gdXNlciAoVSkNCg0KDQo0MTAgR29uZQ0KDQoNCkNhdXNlIHZhbHVl
IE5vIDIyIChudW1iZXIgY2hhbmdlZCkNCg0KDQo0MzMgQW5vbnltaXR5IERpc2FsbG93ZWQuKE5P
VEUgMSkNCg0KDQpDYXVzZSB2YWx1ZSBOby4gMjQgKGNhbGwgcmVqZWN0ZWQgZHVlIHRvIEFDUiBz
dXBwbGVtZW50YXJ5IHNlcnZpY2UpDQoNCg0KNDgwIFRlbXBvcmFyaWx5IHVuYXZhaWxhYmxlDQoN
Cg0KQ2F1c2UgdmFsdWUgTm8gMjUgKEV4Y2hhbmdlIHJvdXRpbmcgZXJyb3IpDQoNCg0KNTAyIEJh
ZCBHYXRld2F5DQoNCg0KQ2F1c2UgdmFsdWUgTm8gMjcgKGRlc3RpbmF0aW9uIG91dCBvZiBvcmRl
cikNCg0KDQo0ODQgQWRkcmVzcyBJbmNvbXBsZXRlDQoNCg0KQ2F1c2UgdmFsdWUgTm8uIDI4IGlu
dmFsaWQgbnVtYmVyIGZvcm1hdCAoYWRkcmVzcyBpbmNvbXBsZXRlKQ0KDQoNCjUwMCBTZXJ2ZXIg
SW50ZXJuYWwgZXJyb3INCg0KDQpDYXVzZSB2YWx1ZSBObyAyOSAoZmFjaWxpdHkgcmVqZWN0ZWQp
DQoNCg0KNDgwIFRlbXBvcmFyaWx5IHVuYXZhaWxhYmxlDQoNCg0KQ2F1c2UgdmFsdWUgTm8gMzEg
KG5vcm1hbCB1bnNwZWNpZmllZCkgKGNsYXNzIGRlZmF1bHQpIChOT1RFIDIpDQoNCg0KNDg2IEJ1
c3kgaGVyZSBpZiBEaWFnbm9zdGljcyBpbmRpY2F0b3IgaW5jbHVkZXMgdGhlIChDQ0JTIGluZGlj
YXRvciA9IENDQlMgcG9zc2libGUpDQoNCmVsc2UgNDgwIFRlbXBvcmFyaWx5IHVuYXZhaWxhYmxl
DQoNCg0KQ2F1c2UgdmFsdWUgaW4gdGhlIENsYXNzIDAxMCAocmVzb3VyY2UgdW5hdmFpbGFibGUs
IENhdXNlIHZhbHVlIE5vIDM0KQ0KDQoNCjUwMCBTZXJ2ZXIgSW50ZXJuYWwgZXJyb3INCg0KDQpD
YXVzZSB2YWx1ZSBpbiB0aGUgQ2xhc3MgMDEwDQoocmVzb3VyY2UgdW5hdmFpbGFibGUsIENhdXNl
IHZhbHVlIE5v4oCZcy4gMzgsIDQxLCA0MiwgNDMsIDQ0LCAmIDQ3KSAoNDcgaXMgY2xhc3MgZGVm
YXVsdCkNCg0KDQo1MDAgU2VydmVyIEludGVybmFsIGVycm9yDQoNCg0KQ2F1c2UgdmFsdWUgTm8g
NTAgKHJlcXVlc3RlZCBmYWNpbGl0eSBubyBzdWJzY3JpYmVkKQ0KDQoNCjUwMCBTZXJ2ZXIgSW50
ZXJuYWwgZXJyb3INCg0KDQpDYXVzZSB2YWx1ZSBObyA1NyAoYmVhcmVyIGNhcGFiaWxpdHkgbm90
IGF1dGhvcmlzZWQpDQoNCg0KNTAwIFNlcnZlciBJbnRlcm5hbCBlcnJvcg0KDQoNCkNhdXNlIHZh
bHVlIE5vIDU4IChiZWFyZXIgY2FwYWJpbGl0eSBub3QgcHJlc2VudGx5KQ0KDQoNCjUwMCBTZXJ2
ZXIgSW50ZXJuYWwgZXJyb3INCg0KDQpDYXVzZSB2YWx1ZSBObyA2MyAoc2VydmljZSBvcHRpb24g
bm90IGF2YWlsYWJsZSwgdW5zcGVjaWZpZWQpDQooY2xhc3MgZGVmYXVsdCkNCg0KDQo1MDAgU2Vy
dmVyIEludGVybmFsIGVycm9yDQoNCg0KQ2F1c2UgdmFsdWUgaW4gdGhlIENsYXNzIDEwMCAoc2Vy
dmljZSBvciBvcHRpb24gbm90IGltcGxlbWVudGVkLCBDYXVzZSB2YWx1ZSBOb+KAmXMuIDY1LCA3
MCAmIDc5KSA3OSBpcyBjbGFzcyBkZWZhdWx0DQoNCg0KNTAwIFNlcnZlciBJbnRlcm5hbCBlcnJv
cg0KDQoNCkNhdXNlIHZhbHVlIE5vIDg4IChpbmNvbXBhdGlibGUgZGVzdGluYXRpb24pDQoNCg0K
NDA0IE5vdCBGb3VuZA0KDQoNCkNhdXNlIHZhbHVlIE5vIDkxIChpbnZhbGlkIHRyYW5zaXQgbmV0
d29yayBzZWxlY3Rpb24pDQoNCg0KNTAwIFNlcnZlciBJbnRlcm5hbCBlcnJvcg0KDQoNCkNhdXNl
IHZhbHVlIE5vIDk1IChpbnZhbGlkIG1lc3NhZ2UpDQooY2xhc3MgZGVmYXVsdCkNCg0KDQo1MDAg
U2VydmVyIEludGVybmFsIGVycm9yDQoNCg0KQ2F1c2UgdmFsdWUgTm8gOTcgKE1lc3NhZ2UgdHlw
ZSBub24tZXhpc3RlbnQgb3Igbm90IGltcGxlbWVudGVkKQ0KDQoNCjUwMCBTZXJ2ZXIgSW50ZXJu
YWwgZXJyb3INCg0KDQpDYXVzZSB2YWx1ZSBObyA5OSAoaW5mb3JtYXRpb24gZWxlbWVudC9wYXJh
bWV0ZXIgbm9uLWV4aXN0ZW50IG9yIG5vdCBpbXBsZW1lbnRlZCkpDQoNCg0KNDgwIFRlbXBvcmFy
aWx5IHVuYXZhaWxhYmxlDQoNCg0KQ2F1c2UgdmFsdWUgTm8uIDEwMiAocmVjb3Zlcnkgb24gdGlt
ZXIgZXhwaXJ5KQ0KDQoNCjUwMCBTZXJ2ZXIgSW50ZXJuYWwgZXJyb3INCg0KDQpDYXVzZSB2YWx1
ZSBObyAxMTAgKE1lc3NhZ2Ugd2l0aCB1bnJlY29nbmlzZWQgUGFyYW1ldGVyLCBkaXNjYXJkZWQp
DQoNCg0KNTAwIFNlcnZlciBJbnRlcm5hbCBlcnJvcg0KDQoNCkNhdXNlIHZhbHVlIE5vLiAxMTEg
KHByb3RvY29sIGVycm9yLCB1bnNwZWNpZmllZCkNCihjbGFzcyBkZWZhdWx0KQ0KDQoNCjQ4MCBU
ZW1wb3JhcmlseSB1bmF2YWlsYWJsZQ0KDQoNCkNhdXNlIHZhbHVlIE5vLiAxMjcgKGludGVyd29y
a2luZyB1bnNwZWNpZmllZCkNCihjbGFzcyBkZWZhdWx0KQ0KDQoNCk5PVEUgMTogICAgQW5vbnlt
aXR5IERpc2FsbG93ZWQsIFJGQyA1MDc5IFs3N10gcmVmZXJzDQoNCk5PVEUgMjogICAgQ2xhc3Mg
MSBhbmQgY2xhc3MgMiBoYXZlIHRoZSBzYW1lIGRlZmF1bHQgdmFsdWUuDQoNCg0KDQoNCg0KVGFi
bGUgMTg6IDR4eC81eHgvNnh4IFJlY2VpdmVkIG9uIFNJUCBzaWRlIG9mIE8tTUdDRg0KDQrigKJS
RUwgKGNhdXNlIGNvZGUpDQoNCg0K4oCiNHh4LzV4eC82eHggU0lQIE1lc3NhZ2UNCg0KDQoxMjcg
KGludGVyd29ya2luZyB1bnNwZWNpZmllZCkNCg0KDQo0MDAgQmFkIFJlcXVlc3QNCg0KDQoxMjcg
KGludGVyd29ya2luZyB1bnNwZWNpZmllZCkNCg0KDQo0MDEgVW5hdXRob3JpemVkDQoNCg0KMTI3
IChpbnRlcndvcmtpbmcgdW5zcGVjaWZpZWQpDQoNCg0KNDAyIFBheW1lbnQgUmVxdWlyZWQNCg0K
DQoxMjcgKGludGVyd29ya2luZyB1bnNwZWNpZmllZCkNCg0KDQo0MDMgRm9yYmlkZGVuDQoNCg0K
MSAoVW5hbGxvY2F0ZWQgbnVtYmVyKQ0KDQoNCjQwNCBOb3QgRm91bmQNCg0KDQoxMjcgKGludGVy
d29ya2luZyB1bnNwZWNpZmllZCkNCg0KDQo0MDUgTWV0aG9kIE5vdCBBbGxvd2VkDQoNCg0KMTI3
IChpbnRlcndvcmtpbmcgdW5zcGVjaWZpZWQpDQoNCg0KNDA2IE5vdCBBY2NlcHRhYmxlDQoNCg0K
MTI3IChpbnRlcndvcmtpbmcgdW5zcGVjaWZpZWQpDQoNCg0KNDA3IFByb3h5IGF1dGhlbnRpY2F0
aW9uIHJlcXVpcmVkDQoNCg0KMTI3IChpbnRlcndvcmtpbmcgdW5zcGVjaWZpZWQpDQoNCg0KNDA4
IFJlcXVlc3QgVGltZW91dA0KDQoNCjIyIChOdW1iZXIgY2hhbmdlZCkNCg0KDQo0MTAgR29uZQ0K
DQoNCjEyNyAoaW50ZXJ3b3JraW5nIHVuc3BlY2lmaWVkKQ0KDQoNCjQxMyBSZXF1ZXN0IEVudGl0
eSB0b28gbG9uZw0KDQoNCjEyNyAoaW50ZXJ3b3JraW5nIHVuc3BlY2lmaWVkKQ0KDQoNCjQxNCBS
ZXF1ZXN0LVVSSSB0b28gbG9uZw0KDQoNCjEyNyAoaW50ZXJ3b3JraW5nIHVuc3BlY2lmaWVkKQ0K
DQoNCjQxNSBVbnN1cHBvcnRlZCBNZWRpYSB0eXBlDQoNCg0KMTI3IChpbnRlcndvcmtpbmcgdW5z
cGVjaWZpZWQpDQoNCg0KNDE2IFVuc3VwcG9ydGVkIFVSSSBzY2hlbWUNCg0KDQoxMjcgKGludGVy
d29ya2luZyB1bnNwZWNpZmllZCkNCg0KDQo0MjAgQmFkIEV4dGVuc2lvbg0KDQoNCjEyNyAoaW50
ZXJ3b3JraW5nIHVuc3BlY2lmaWVkKQ0KDQoNCjQyMSBFeHRlbnNpb24gcmVxdWlyZWQNCg0KDQox
MjcgKGludGVyd29ya2luZyB1bnNwZWNpZmllZCkNCg0KDQo0MjMgSW50ZXJ2YWwgVG9vIEJyaWVm
DQoNCg0KMjQgKGNhbGwgcmVqZWN0ZWQgZHVlIHRvIEFDUiBzdXBwbGVtZW50YXJ5IHNlcnZpY2Up
DQoNCg0KNDMzIEFub255bWl0eSBEaXNhbGxvd2VkLihOT1RFIDEpDQoNCg0KMjAgU3Vic2NyaWJl
ciBhYnNlbnQNCg0KDQo0ODAgVGVtcG9yYXJpbHkgVW5hdmFpbGFibGUNCg0KDQoxMjcgKGludGVy
d29ya2luZyB1bnNwZWNpZmllZCkNCg0KDQo0ODEgQ2FsbC9UcmFuc2FjdGlvbiBkb2VzIG5vdCBl
eGlzdA0KDQoNCjEyNyAoaW50ZXJ3b3JraW5nIHVuc3BlY2lmaWVkKQ0KDQoNCjQ4MiBMb29wIGRl
dGVjdGVkDQoNCg0KMTI3IChpbnRlcndvcmtpbmcgdW5zcGVjaWZpZWQpDQoNCg0KNDgzIFRvbyBt
YW55IGhvcHMNCg0KDQoyOCAoSW52YWxpZCBOdW1iZXIgZm9ybWF0KQ0KDQoNCjQ4NCBBZGRyZXNz
IEluY29tcGxldGUNCg0KDQoxMjcgKGludGVyd29ya2luZyB1bnNwZWNpZmllZCkNCg0KDQo0ODUg
QW1iaWd1b3VzDQoNCg0KMTcgKFVzZXIgYnVzeSkNCg0KDQo0ODYgQnVzeSBIZXJlDQoNCg0KMTI3
IChJbnRlcndvcmtpbmcgdW5zcGVjaWZpZWQpIG9yIG5vdCBpbnRlcndvcmtlZC4gKE5PVEUgMikN
Cg0KDQo0ODcgUmVxdWVzdCB0ZXJtaW5hdGVkDQoNCg0KMTI3IChpbnRlcndvcmtpbmcgdW5zcGVj
aWZpZWQpDQoNCg0KNDg4IE5vdCBhY2NlcHRhYmxlIGhlcmUNCg0KDQoxMjcgKGludGVyd29ya2lu
ZyB1bnNwZWNpZmllZCkNCg0KDQo0OTMgVW5kZWNpcGhlcmFibGUNCg0KDQoxMjcgKGludGVyd29y
a2luZyB1bnNwZWNpZmllZCkNCg0KDQo1MDAgU2VydmVyIEludGVybmFsIGVycm9yDQoNCg0KMTI3
IChpbnRlcndvcmtpbmcgdW5zcGVjaWZpZWQpDQoNCg0KNTAxIE5vdCBpbXBsZW1lbnRlZA0KDQoN
CjEyNyAoaW50ZXJ3b3JraW5nIHVuc3BlY2lmaWVkKQ0KDQoNCjUwMiBCYWQgR2F0ZXdheQ0KDQoN
CjEyNyAoaW50ZXJ3b3JraW5nIHVuc3BlY2lmaWVkKQ0KDQoNCjUwMyBTZXJ2aWNlIFVuYXZhaWxh
YmxlDQoNCg0KMTI3IChpbnRlcndvcmtpbmcgdW5zcGVjaWZpZWQpDQoNCg0KNTA0IFNlcnZlciB0
aW1lb3V0DQoNCg0KMTI3IChpbnRlcndvcmtpbmcgdW5zcGVjaWZpZWQpDQoNCg0KNTA1IFZlcnNp
b24gbm90IHN1cHBvcnRlZA0KDQoNCjEyNyAoaW50ZXJ3b3JraW5nIHVuc3BlY2lmaWVkKQ0KDQoN
CjUxMyBNZXNzYWdlIHRvbyBsYXJnZQ0KDQoNCjEyNyAoaW50ZXJ3b3JraW5nIHVuc3BlY2lmaWVk
KQ0KDQoNCjU4MCBQcmVjb25kaXRpb24gZmFpbHVyZQ0KDQoNCjE3IChVc2VyIGJ1c3kpDQoNCg0K
NjAwIEJ1c3kgRXZlcnl3aGVyZQ0KDQoNCjIxIChDYWxsIHJlamVjdGVkKQ0KDQoNCjYwMyBEZWNs
aW5lDQoNCg0KMSAodW5hbGxvY2F0ZWQgbnVtYmVyKQ0KDQoNCjYwNCBEb2VzIG5vdCBleGlzdCBh
bnl3aGVyZQ0KDQoNCjEyNyAoaW50ZXJ3b3JraW5nIHVuc3BlY2lmaWVkKQ0KDQoNCjYwNiBOb3Qg
YWNjZXB0YWJsZQ0KDQoNCk5PVEUgMTogICAgQW5vbnltaXR5IERpc2FsbG93ZWQsIFJGQyA1MDc5
IFs3N10gcmVmZXJzLg0KDQpOT1RFIDI6ICAgIE5vIGludGVyd29ya2luZyBpZiB0aGUgTy1NR0NG
IHByZXZpb3VzbHkgaXNzdWVkIGEgQ0FOQ0VMIHJlcXVlc3QgZm9yIHRoZSBJTlZJVEUuDQoNCk5P
VEUgMzogICAgVGhlIDR4eC81eHgvNnh4IFNJUCByZXNwb25zZXMgdGhhdCBhcmUgbm90IGNvdmVy
ZWQgaW4gdGhpcyB0YWJsZSBhcmUgbm90IGludGVyd29ya2VkLg0KDQoNCg0KQlIgQWxlxaENCg0K
RnJvbTogQ2FsbWUsIEphbWVzIEEgKEppbSkgW21haWx0bzpqaW0uY2FsbWVAYWxjYXRlbC1sdWNl
bnQuY29tXQ0KU2VudDogMjUuIGphbnVhciAyMDEzIDE1OjIzDQpUbzogQ2hyaXN0ZXIgSG9sbWJl
cmc7IMWgbGliZXIgQWxlxaE7IGRpc3BhdGNoQGlldGYub3JnPG1haWx0bzpkaXNwYXRjaEBpZXRm
Lm9yZz4NClN1YmplY3Q6IFJFOiBSRkMgMzM5OCAtIHByb2JsZW1zIHdpdGggSVNVUCBjYXVzZSBt
YXBwaW5nDQoNClBsZWFzZSByZWZlcmVuY2UgM0dQUCBUUyAyOS4xNjMsIG11Y2ggd29yayBhcyBi
ZWVuIGRvbmUgb24gdGhpcyBkb2N1bWVudCBvdmVyIHRoZSBsYXN0IGNvdXBsZSB5ZWFycyB0byBh
ZGRyZXNzIG1hcHBpbmcgY29uY2VybnMuDQoNCkppbQ0KDQpGcm9tOiBkaXNwYXRjaC1ib3VuY2Vz
QGlldGYub3JnPG1haWx0bzpkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmRpc3Bh
dGNoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDaHJpc3RlciBIb2xtYmVyZw0KU2Vu
dDogRnJpZGF5LCBKYW51YXJ5IDI1LCAyMDEzIDg6MTggQU0NClRvOiDFoGxpYmVyIEFsZcWhOyBk
aXNwYXRjaEBpZXRmLm9yZzxtYWlsdG86ZGlzcGF0Y2hAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTog
W2Rpc3BhdGNoXSBSRkMgMzM5OCAtIHByb2JsZW1zIHdpdGggSVNVUCBjYXVzZSBtYXBwaW5nDQoN
CkhpLA0KDQpUaGVyZSBpcyBubyBuZXcgUkZDLCBidXQgU0RPcyBsaWtlIElUVS1UIGFuZCAzR1BQ
IGhhdmUgc3BlY2lmaWVkIG1hcHBpbmcgd2hpY2ggaW4gc29tZSBjYXNlcyBkaWZmZXJzIGZyb20g
dGhlIFJGQy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogZGlzcGF0Y2gtYm91bmNl
c0BpZXRmLm9yZzxtYWlsdG86ZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpkaXNw
YXRjaC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgxaBsaWJlciBBbGXFoQ0KU2VudDog
MjUuIHRhbW1pa3V1dGEgMjAxMyA5OjAyDQpUbzogZGlzcGF0Y2hAaWV0Zi5vcmc8bWFpbHRvOmRp
c3BhdGNoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtkaXNwYXRjaF0gUkZDIDMzOTggLSBwcm9i
bGVtcyB3aXRoIElTVVAgY2F1c2UgbWFwcGluZw0KDQpIaSwNCg0KSSdtIG1vYmlsZSBjb3JlIG5l
dHdvcmsgZW5naW5lZXIgd29ya2luZyBhIGxvdCB3aXRoIElTVVAgdG8gU0lQIG1hcHBpbmcgYW5k
IHZpY2UgdmVyc2EuDQpJIGNvbWUgdXAgdG8gYW4gdW5zb2x2ZWQgcHJvYmxlbSB3aXRoIG1hcHBp
bmcgdGhlIHRyYWZmaWMgZnJvbSBJU1VQIHRvIFNJUCBhbmQgYmFjayB0byBJU1VQLg0KDQpGcm9t
IFJGQyAzMzk4Og0KDQpJU1VQLVNJUA0KICAgMTggbm8gdXNlciByZXNwb25kaW5nICAgICAgICAg
ICAgICAgICAgIDQwOCBSZXF1ZXN0IFRpbWVvdXQNCiAgIDE5IG5vIGFuc3dlciBmcm9tIHRoZSB1
c2VyICAgICAgICAgICAgICA0ODAgVGVtcG9yYXJpbHkgdW5hdmFpbGFibGUNCiAgIDIwIHN1YnNj
cmliZXIgYWJzZW50ICAgICAgICAgICAgICAgICAgICA0ODAgVGVtcG9yYXJpbHkgdW5hdmFpbGFi
bGUNCg0KU0lQLUlTVVA6DQogICA0MDggUmVxdWVzdCB0aW1lb3V0ICAgICAgICAgICAgICAgICAg
MTAyIFJlY292ZXJ5IG9uIHRpbWVyIGV4cGlyeQ0KICAgNDgwIFRlbXBvcmFyaWx5IHVuYXZhaWxh
YmxlICAgICAgICAgICAxOCBObyB1c2VyIHJlc3BvbmRpbmcNCg0KU28gaWYgSSBzZW5kIGZyb20g
SVNVUCBSRUwtMTkgYW5kIHRoaXMgdHJhZmljIHdlbnRzIG1hcHMgdG8gU0lQIGFuZCB0aGVuIGJh
Y2sgdG8gSVNVUCwgSSByZWNlaXZlIG9uIHRoZSBvdGhlciBzaWRlIElTVVAgUkVMLTE4Lg0KVGhl
cmUgaXMgdGhlIHNhbWUgc3Rvcnkgd2l0aCBJU1VQIFJFTDE4IG1hcHBuZyB0byBTSVAgYW5kIGJh
Y2sgdG8gSVNVUCDigJMgSSB3aWxsIHJlY2VpdmUgSVNVUCBSRUwuMTAyPyENCg0KQ2FuIHlvdSBo
ZWxwIG1lIHdpdGggdGhpcyBpc3VlLiBJcyB0aGVyZSBhbnkgbmV3IFJGQyBob3cgdG8gbWFwIHRo
aXMga2luZCBvZiB0cmFmZmljPw0KDQpUaGFuayB5b3UsDQpCUiBBbGVzIFNsaWJlcg0KDQpBbGXF
oSDFoGxpYmVyDQpDb3JlIG5ldHdvcmsgZW5naW5lZXINClRlbDogKzM4Ni0xLTQ3Mi04NDgyDQpX
LW1vYmlsZTogd3d3Lm1vYml0ZWwuc2k8aHR0cDovL3d3dy5tb2JpdGVsLnNpLz4NClctZml4OiB3
d3cudGVsZWtvbS5zaTxodHRwOi8vd3d3LnRlbGVrb20uc2kvPg0KVGVsZWtvbSBTbG92ZW5pamUN
Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRpc3Bh
dGNoIG1haWxpbmcgbGlzdA0KZGlzcGF0Y2hAaWV0Zi5vcmc8bWFpbHRvOmRpc3BhdGNoQGlldGYu
b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaA0K

--_000_26300ECDDED68545A78AAC3D98640BF3A157FC84srexdb14tstelek_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9
DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg
MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl
LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiVHJl
YnVjaGV0IE1TIjsNCglwYW5vc2UtMToyIDExIDYgMyAyIDIgMiAyIDIgNDt9DQovKiBTdHlsZSBE
ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K
CXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0
Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z
b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0
LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs
b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj
b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv
QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv
b24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm
b250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNw
YW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7
DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQi
Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLlRBTENoYXINCgl7
bXNvLXN0eWxlLW5hbWU6IlRBTCBDaGFyIjsNCgltc28tc3R5bGUtbGluazpUQUw7DQoJZm9udC1m
YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7fQ0KcC5UQUwsIGxpLlRBTCwgZGl2LlRBTA0KCXtt
c28tc3R5bGUtbmFtZTpUQUw7DQoJbXNvLXN0eWxlLWxpbms6IlRBTCBDaGFyIjsNCgltYXJnaW46
MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglwYWdlLWJyZWFrLWFmdGVyOmF2b2lkOw0K
CWZvbnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjt9DQpz
cGFuLlRBQ0NoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlRBQyBDaGFyIjsNCgltc28tc3R5bGUtbGlu
azpUQUM7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7fQ0KcC5UQUMsIGxpLlRB
QywgZGl2LlRBQw0KCXttc28tc3R5bGUtbmFtZTpUQUM7DQoJbXNvLXN0eWxlLWxpbms6IlRBQyBD
aGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWdu
OmNlbnRlcjsNCglwYWdlLWJyZWFrLWFmdGVyOmF2b2lkOw0KCWZvbnQtc2l6ZTo5LjBwdDsNCglm
b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLlRIQ2hhcg0KCXttc28tc3R5
bGUtbmFtZToiVEggQ2hhciI7DQoJbXNvLXN0eWxlLWxpbms6VEg7DQoJZm9udC1mYW1pbHk6IkFy
aWFsIiwic2Fucy1zZXJpZiI7DQoJZm9udC13ZWlnaHQ6Ym9sZDt9DQpwLlRILCBsaS5USCwgZGl2
LlRIDQoJe21zby1zdHlsZS1uYW1lOlRIOw0KCW1zby1zdHlsZS1saW5rOiJUSCBDaGFyIjsNCglt
YXJnaW4tdG9wOjMuMHB0Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTo5LjBw
dDsNCgltYXJnaW4tbGVmdDowY207DQoJdGV4dC1hbGlnbjpjZW50ZXI7DQoJcGFnZS1icmVhay1h
ZnRlcjphdm9pZDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNh
bnMtc2VyaWYiOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KcC5UQU4sIGxpLlRBTiwgZGl2LlRBTg0K
CXttc28tc3R5bGUtbmFtZTpUQU47DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBj
bTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDo0Mi41NXB0Ow0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCgl0ZXh0LWluZGVudDotNDIuNTVwdDsNCglwYWdlLWJyZWFrLWFmdGVy
OmF2b2lkOw0KCWZvbnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNl
cmlmIjt9DQpwLlRBSCwgbGkuVEFILCBkaXYuVEFIDQoJe21zby1zdHlsZS1uYW1lOlRBSDsNCglt
YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmNlbnRlcjsN
CglwYWdlLWJyZWFrLWFmdGVyOmF2b2lkOw0KCWZvbnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWls
eToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCglmb250LXdlaWdodDpib2xkO30NCnNwYW4uRW1haWxT
dHlsZTI3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIs
InNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0K
CWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0Kc3Bhbi5F
bWFpbFN0eWxlMjgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkFy
aWFsIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDsNCglmb250LXdlaWdodDpub3Jt
YWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQpz
cGFuLkVtYWlsU3R5bGUyOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls
eToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0
Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25l
O30NCnNwYW4uRW1haWxTdHlsZTMwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt
ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVt
YWlsU3R5bGUzMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiVHJl
YnVjaGV0IE1TIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzAwNzBDMDt9DQpzcGFuLkVtYWlsU3R5
bGUzMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQXJpYWwiLCJz
YW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglm
b250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCnNwYW4uRW1h
aWxTdHlsZTMzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJUcmVi
dWNoZXQgTVMiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMDA3MEMwO30NCnNwYW4uRW1haWxTdHls
ZTM0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi
c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzNQ0KCXttc28t
c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNl
cmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0
eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCi5Nc29DaHBEZWZhdWx0
DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh
Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQg
NzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0
aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh
dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh
LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86
aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb
ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJTTCIgbGluaz0iYmx1ZSIgdmxpbms9InB1
cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPkhpIHRvIGV2ZXJ5b25lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5ZZXMgY29ycmVjdCwgSSdtIHRhbGtpbmcgYWJvdXQgZG91
YmxlIG1hcHBpbmcgSVNVUA0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGlu
Z3MiPsOgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gU0lQDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFt
aWx5OldpbmdkaW5ncyI+w6A8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy
aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBJU1VQIGFuZCBub3QgYWJvdXQgU0lQ
LUkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7Ij5PSywgSSB3aWxsIGNoZWNrIHRoaXMgwrs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMDA3MEMwIj5SZWFzb24gaGVhZGVyIGZpZWxkPC9zcGFuPjxzcGFuIHN0
eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
Ij7Cqy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDsiPlRobnhzIHRvIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90OyI+QlIgQWxlxaE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp
dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw
dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IENocmlzdGVyIEhvbG1iZXJn
IFttYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tXQ0KPGJyPg0KPGI+U2VudDo8
L2I+IDI4LiBqYW51YXIgMjAxMyAxNTo0NDxicj4NCjxiPlRvOjwvYj4gQWRhbSBSb2FjaDsgQ2Fs
bWUsIEphbWVzIEEgKEppbSk8YnI+DQo8Yj5DYzo8L2I+IMWgbGliZXIgQWxlxaE7IGRpc3BhdGNo
QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbZGlzcGF0Y2hdIFJGQyAzMzk4IC0g
cHJvYmxlbXMgd2l0aCBJU1VQIGNhdXNlIG1hcHBpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMx
RjQ5N0QiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdE
Ij4mZ3Q7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj5HdXlzLCB5b3UncmUgZG9pbmcgaXQgd3Jv
bmcuIENvbXBsZXRlbHkgd3JvbmcuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj
b2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+PHNwYW4gbGFu
Zz0iRU4tVVMiPkdvIGJhY2sgYW5kIHJlYWQgbXkgcmVzcG9uc2UgZnJvbSBGcmlkYXkuJm5ic3A7
PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMx
RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+TWF5YmUgSeKAmXZlIG1p
c3NlZCBzb21ldGhpbmcsIGJ1dCBJIGRvbuKAmXQgdGhpbmsgSVNVUCB0dW5uZWxpbmcgaXMgdXNl
ZCBpbiB0aGUgY2FzZSBiZWluZyBkaXNjdXNzZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdE
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkNocmlz
dGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxh
bmc9IkVOLVVTIj48YnI+DQpPbiBKYW4gMjgsIDIwMTMsIGF0IDg6MDksICZxdW90O0NhbG1lLCBK
YW1lcyBBIChKaW0pJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86amltLmNhbG1lQGFsY2F0ZWwt
bHVjZW50LmNvbSI+amltLmNhbG1lQGFsY2F0ZWwtbHVjZW50LmNvbTwvYT4mZ3Q7IHdyb3RlOjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10
b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQg
TVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3MEMwIj5UcnVlLCBpdCBp
cyBub3QgMTAwJSBzeW1tZXRyaWMuDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzAwNzBDMCI+SWYgaXQgaXMgcmVxdWlyZWQgdG8gbWFpbnRhaW4gdGhl
IG9yaWdpbmFsIElTVVAgY2F1c2UsIHRoZW4gSSB3b3VsZCBzdWdnZXN0IHVzaW5nIHRoZSBSZWFz
b24gaGVhZGVyIGZpZWxkLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMDA3MEMwIj5KaW08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzAwNzBDMCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy
LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t
YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t
YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gxaBsaWJlciBBbGXFoSBbPGEgaHJlZj0i
bWFpbHRvOkFsZXMuU2xpYmVyQHRlbGVrb20uc2kiPm1haWx0bzpBbGVzLlNsaWJlckB0ZWxla29t
LnNpPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEphbnVhcnkgMjgsIDIwMTMgMzoy
MyBBTTxicj4NCjxiPlRvOjwvYj4gQ2FsbWUsIEphbWVzIEEgKEppbSk7IENocmlzdGVyIEhvbG1i
ZXJnOyA8YSBocmVmPSJtYWlsdG86ZGlzcGF0Y2hAaWV0Zi5vcmciPg0KZGlzcGF0Y2hAaWV0Zi5v
cmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBSRkMgMzM5OCAtIHByb2JsZW1zIHdpdGgg
SVNVUCBjYXVzZSBtYXBwaW5nPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h
cmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi
PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7Ij5IaSw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij5UaGFuayB5b3UgZm9yIHJlcGx5LCBidXQgYXMgSSBjYW4gc2VlLCBmcm9tIDNHUFAg
VFMgMjkuMTYzIGRvY3VtZW50IOKAkyB0aGVyZSBpcyBxdWl0ZSB0aGUgc2FtZSBzdG9yeSAobWFi
eSBldmVuIHdvcnN0IOKAkyBiZWNhdXNlIElTVVAgMTggaXMgbWFwZCBhbHNvIGluIFNJUCA0ODAg
YW5kDQogbm90IGluLXRvIFNJUC00MDggYXMgaW4gUkZDKTo8L3NwYW4+PHNwYW4gbGFuZz0iRU4t
VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
YXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t
VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUi
IGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iNjM4IiBz
dHlsZT0id2lkdGg6NDc4LjhwdDttYXJnaW4tbGVmdDozNi4wcHQ7Ym9yZGVyLWNvbGxhcHNlOmNv
bGxhcHNlIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCB3aWR0aD0iMzEyIiB2YWxpZ249InRvcCIgc3R5
bGU9IndpZHRoOjIzMy43cHQ7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzow
Y20gNS40cHQgMGNtIDUuNHB0Ij4NCjxwIGNsYXNzPSJUSCIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0
ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPlRhYmxlIDk6IFJlY2VpcHQgb2YgdGhlIFJlbGVh
c2UgbWVzc2FnZSAoUkVMKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgYWxpZ249ImNlbnRl
ciI+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5n
PSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9Ijg3JSIgc3R5bGU9IndpZHRoOjg3LjE4JTttYXJn
aW4tbGVmdDo0Mi4xNXB0O2JvcmRlci1jb2xsYXBzZTpjb2xsYXBzZSI+DQo8dGhlYWQ+DQo8dHIg
c3R5bGU9InBhZ2UtYnJlYWstaW5zaWRlOmF2b2lkO2hlaWdodDoxNC4xNXB0Ij4NCjx0ZCB3aWR0
aD0iMjMlIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjIzLjElO2JvcmRlcjpzb2xpZCB3aW5k
b3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDoxNC4xNXB0
Ij4NCjxwIGNsYXNzPSJUQUgiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6
U3ltYm9sIj7CrDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+U0lQIE1lc3NhZ2UNCjwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9Ijc2JSIgdmFsaWduPSJ0b3AiIHN0eWxl
PSJ3aWR0aDo3Ni45JTtib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItbGVmdDpu
b25lO3BhZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDoxNC4xNXB0Ij4NCjxwIGNs
YXNzPSJUQUgiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj7C
rDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+IFJFTDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv
dGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJwYWdlLWJyZWFrLWluc2lkZTphdm9pZDtoZWlnaHQ6MTMu
NjVwdCI+DQo8dGQgd2lkdGg9IjIzJSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoyMy4xJTti
b3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowY20g
NS4zNXB0IDBjbSA1LjM1cHQ7aGVpZ2h0OjEzLjY1cHQiPg0KPHAgY2xhc3M9IlRBSCI+PHNwYW4g
bGFuZz0iRU4tR0IiPlN0YXR1cyBjb2RlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0
ZCB3aWR0aD0iNzYlIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjc2LjklO2JvcmRlci10b3A6
bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBw
dDtib3JkZXItcmlnaHQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSA1LjM1cHQg
MGNtIDUuMzVwdDtoZWlnaHQ6MTMuNjVwdCI+DQo8cCBjbGFzcz0iVEFIIj48c3BhbiBsYW5nPSJF
Ti1HQiI+Q2F1c2UgcGFyYW1ldGVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+
DQo8L3RoZWFkPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJwYWdlLWJyZWFrLWluc2lkZTphdm9pZDto
ZWlnaHQ6MTUuMHB0Ij4NCjx0ZCB3aWR0aD0iMjMlIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRo
OjIzLjElO2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRk
aW5nOjBjbSA1LjM1cHQgMGNtIDUuMzVwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJUQUMi
IHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj40MDQgTm90
IEZvdW5kPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNzYlIiB2YWxp
Z249InRvcCIgc3R5bGU9IndpZHRoOjc2LjklO2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpu
b25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItcmlnaHQ6c29s
aWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSA1LjM1cHQgMGNtIDUuMzVwdDtoZWlnaHQ6
MTUuMHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxz
cGFuIGxhbmc9IkVOLUdCIj5DYXVzZSB2YWx1ZSBOby4mbmJzcDsxICh1bmFsbG9jYXRlZCAodW5h
c3NpZ25lZCkgbnVtYmVyKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRy
IHN0eWxlPSJwYWdlLWJyZWFrLWluc2lkZTphdm9pZDtoZWlnaHQ6MTUuMHB0Ij4NCjx0ZCB3aWR0
aD0iMjMlIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjIzLjElO2JvcmRlcjpzb2xpZCB3aW5k
b3d0ZXh0IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjM1cHQgMGNtIDUuMzVw
dDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVy
OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj41MDAgU2VydmVyIEludGVybmFsIGVycm9yPC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNzYlIiB2YWxpZ249InRvcCIgc3R5
bGU9IndpZHRoOjc2LjklO2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1i
b3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgd2luZG93dGV4
dCAxLjBwdDtwYWRkaW5nOjBjbSA1LjM1cHQgMGNtIDUuMzVwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxw
IGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVO
LUdCIj5DYXVzZSB2YWx1ZSBObyAyIChubyByb3V0ZSB0byBuZXR3b3JrKTwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJwYWdlLWJyZWFrLWluc2lkZTphdm9p
ZDtoZWlnaHQ6MTUuMHB0Ij4NCjx0ZCB3aWR0aD0iMjMlIiB2YWxpZ249InRvcCIgc3R5bGU9Indp
ZHRoOjIzLjElO2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci10b3A6bm9uZTtw
YWRkaW5nOjBjbSA1LjM1cHQgMGNtIDUuMzVwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJU
QUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj41MDAg
U2VydmVyIEludGVybmFsIGVycm9yPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3
aWR0aD0iNzYlIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjc2LjklO2JvcmRlci10b3A6bm9u
ZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDti
b3JkZXItcmlnaHQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSA1LjM1cHQgMGNt
IDUuMzVwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFr
LWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5DYXVzZSB2YWx1ZSBObyAzIChubyByb3V0
ZSB0byBkZXN0aW5hdGlvbik8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0
ciBzdHlsZT0icGFnZS1icmVhay1pbnNpZGU6YXZvaWQ7aGVpZ2h0OjE2LjU1cHQiPg0KPHRkIHdp
ZHRoPSIyMyUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MjMuMSU7Ym9yZGVyOnNvbGlkIHdp
bmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4z
NXB0O2hlaWdodDoxNi41NXB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFm
dGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj41MDAgU2VydmVyIEludGVybmFsIGVycm9yPC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNzYlIiB2YWxpZ249InRvcCIg
c3R5bGU9IndpZHRoOjc2LjklO2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRl
ci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgd2luZG93
dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSA1LjM1cHQgMGNtIDUuMzVwdDtoZWlnaHQ6MTYuNTVwdCI+
DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5n
PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkNhdXNlIHZhbHVlIE5vLiA0IChTZW5k
IHNwZWNpYWwgaW5mb3JtYXRpb24gdG9uZSk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0K
PC90cj4NCjx0ciBzdHlsZT0icGFnZS1icmVhay1pbnNpZGU6YXZvaWQ7aGVpZ2h0OjE1Ljc1cHQi
Pg0KPHRkIHdpZHRoPSIyMyUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MjMuMSU7Ym9yZGVy
OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGNtIDUuMzVw
dCAwY20gNS4zNXB0O2hlaWdodDoxNS43NXB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdl
LWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj40MDQgTm90IEZvdW5kPC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNzYlIiB2YWxpZ249InRvcCIgc3R5
bGU9IndpZHRoOjc2LjklO2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1i
b3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgd2luZG93dGV4
dCAxLjBwdDtwYWRkaW5nOjBjbSA1LjM1cHQgMGNtIDUuMzVwdDtoZWlnaHQ6MTUuNzVwdCI+DQo8
cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJF
Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkNhdXNlIHZhbHVlIE5vLiA1IChNaXNkaWFs
bGVkIHRydW5rIHByZWZpeCk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0
ciBzdHlsZT0icGFnZS1icmVhay1pbnNpZGU6YXZvaWQ7aGVpZ2h0OjE1LjBwdCI+DQo8dGQgd2lk
dGg9IjIzJSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoyMy4xJTtib3JkZXI6c29saWQgd2lu
ZG93dGV4dCAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowY20gNS4zNXB0IDBjbSA1LjM1
cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRl
cjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+NDg2IEJ1c3kgSGVyZTwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9Ijc2JSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDo3
Ni45JTtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlk
IHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFk
ZGluZzowY20gNS4zNXB0IDBjbSA1LjM1cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iVEFD
IiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Q2F1c2Ug
dmFsdWUgTm8uJm5ic3A7MTcgKHVzZXIgYnVzeSk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3Rk
Pg0KPC90cj4NCjx0ciBzdHlsZT0icGFnZS1icmVhay1pbnNpZGU6YXZvaWQ7aGVpZ2h0OjE1LjBw
dCI+DQo8dGQgd2lkdGg9IjIzJSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoyMy4xJTtib3Jk
ZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowY20gNS4z
NXB0IDBjbSA1LjM1cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFn
ZS1icmVhay1hZnRlcjphdXRvIj48Yj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImJhY2tncm91
bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93Ij40ODAgVGVtcG9yYXJpbHkgdW5hdmFpbGFi
bGU8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNzYlIiB2YWxp
Z249InRvcCIgc3R5bGU9IndpZHRoOjc2LjklO2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpu
b25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItcmlnaHQ6c29s
aWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSA1LjM1cHQgMGNtIDUuMzVwdDtoZWlnaHQ6
MTUuMHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxi
PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iYmFja2dyb3VuZDp5ZWxsb3c7bXNvLWhpZ2hsaWdo
dDp5ZWxsb3ciPkNhdXNlIHZhbHVlIE5vIDE4IChubyB1c2VyIHJlc3BvbmRpbmcpPC9zcGFuPjwv
Yj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJwYWdlLWJyZWFrLWlu
c2lkZTphdm9pZDtoZWlnaHQ6MTUuMHB0Ij4NCjx0ZCB3aWR0aD0iMjMlIiB2YWxpZ249InRvcCIg
c3R5bGU9IndpZHRoOjIzLjElO2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci10
b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjM1cHQgMGNtIDUuMzVwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxw
IGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxiPjxzcGFuIGxhbmc9
IkVOLUdCIiBzdHlsZT0iYmFja2dyb3VuZDp5ZWxsb3c7bXNvLWhpZ2hsaWdodDp5ZWxsb3ciPjQ4
MCBUZW1wb3JhcmlseSB1bmF2YWlsYWJsZTwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L3Rk
Pg0KPHRkIHdpZHRoPSI3NiUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6NzYuOSU7Ym9yZGVy
LXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0
IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUu
MzVwdCAwY20gNS4zNXB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBh
Z2UtYnJlYWstYWZ0ZXI6YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJiYWNrZ3Jv
dW5kOnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxvdyI+Q2F1c2UgdmFsdWUgTm8gMTkgKG5vIGFu
c3dlciBmcm9tIHRoZSB1c2VyKTwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90
cj4NCjx0ciBzdHlsZT0icGFnZS1icmVhay1pbnNpZGU6YXZvaWQ7aGVpZ2h0OjE1LjBwdCI+DQo8
dGQgd2lkdGg9IjIzJSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoyMy4xJTtib3JkZXI6c29s
aWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowY20gNS4zNXB0IDBj
bSA1LjM1cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVh
ay1hZnRlcjphdXRvIj48Yj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImJhY2tncm91bmQ6eWVs
bG93O21zby1oaWdobGlnaHQ6eWVsbG93Ij40ODAgVGVtcG9yYXJpbHkgdW5hdmFpbGFibGU8L3Nw
YW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNzYlIiB2YWxpZ249InRv
cCIgc3R5bGU9IndpZHRoOjc2LjklO2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2Jv
cmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgd2lu
ZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSA1LjM1cHQgMGNtIDUuMzVwdDtoZWlnaHQ6MTUuMHB0
Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxiPjxzcGFu
IGxhbmc9IkVOLUdCIiBzdHlsZT0iYmFja2dyb3VuZDp5ZWxsb3c7bXNvLWhpZ2hsaWdodDp5ZWxs
b3ciPkNhdXNlIHZhbHVlIE5vLiZuYnNwOzIwIChzdWJzY3JpYmVyIGFic2VudCk8L3NwYW4+PC9i
PjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9InBhZ2UtYnJlYWstaW5z
aWRlOmF2b2lkO2hlaWdodDoxNS4wcHQiPg0KPHRkIHdpZHRoPSIyMyUiIHZhbGlnbj0idG9wIiBz
dHlsZT0id2lkdGg6MjMuMSU7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRv
cDpub25lO3BhZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDoxNS4wcHQiPg0KPHAg
Y2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4t
R0IiPjYwMyBEZWNsaW5lPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0i
NzYlIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjc2LjklO2JvcmRlci10b3A6bm9uZTtib3Jk
ZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXIt
cmlnaHQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSA1LjM1cHQgMGNtIDUuMzVw
dDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVy
OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5DYXVzZSB2YWx1ZSBObyAyMSAoY2FsbCByZWplY3Rl
ZCksIExvY2F0aW9uID0gMDAwIC8gdXNlciAoVSk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3Rk
Pg0KPC90cj4NCjx0ciBzdHlsZT0icGFnZS1icmVhay1pbnNpZGU6YXZvaWQ7aGVpZ2h0OjE1LjBw
dCI+DQo8dGQgd2lkdGg9IjIzJSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoyMy4xJTtib3Jk
ZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowY20gNS4z
NXB0IDBjbSA1LjM1cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFn
ZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+NDgwVGVtcG9yYXJpbHkgdW5h
dmFpbGFibGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI3NiUiIHZh
bGlnbj0idG9wIiBzdHlsZT0id2lkdGg6NzYuOSU7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0
Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpz
b2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdo
dDoxNS4wcHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+
PHNwYW4gbGFuZz0iRU4tR0IiPkNhdXNlIHZhbHVlIE5vIDIxIChjYWxsIHJlamVjdGVkKSAsIExv
Y2F0aW9uICZsdDsmZ3Q7IDAwMCAvIHVzZXIgKFUpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90
ZD4NCjwvdHI+DQo8dHIgc3R5bGU9InBhZ2UtYnJlYWstaW5zaWRlOmF2b2lkO2hlaWdodDoxNS4w
cHQiPg0KPHRkIHdpZHRoPSIyMyUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MjMuMSU7Ym9y
ZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGNtIDUu
MzVwdCAwY20gNS4zNXB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBh
Z2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPjQxMCBHb25lPC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNzYlIiB2YWxpZ249InRvcCIgc3R5bGU9
IndpZHRoOjc2LjklO2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0
b206c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgd2luZG93dGV4dCAx
LjBwdDtwYWRkaW5nOjBjbSA1LjM1cHQgMGNtIDUuMzVwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNs
YXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdC
Ij5DYXVzZSB2YWx1ZSBObyAyMiAobnVtYmVyIGNoYW5nZWQpPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9InBhZ2UtYnJlYWstaW5zaWRlOmF2b2lkO2hlaWdo
dDoxNS4wcHQiPg0KPHRkIHdpZHRoPSIyMyUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MjMu
MSU7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6
MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5
bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPjQzMyBBbm9ueW1p
dHkgRGlzYWxsb3dlZC4oTk9URSAxKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQg
d2lkdGg9Ijc2JSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDo3Ni45JTtib3JkZXItdG9wOm5v
bmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7
Ym9yZGVyLXJpZ2h0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20gNS4zNXB0IDBj
bSA1LjM1cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVh
ay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Q2F1c2UgdmFsdWUgTm8uIDI0IChjYWxs
IHJlamVjdGVkIGR1ZSB0byBBQ1Igc3VwcGxlbWVudGFyeSBzZXJ2aWNlKTwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJwYWdlLWJyZWFrLWluc2lkZTphdm9p
ZDtoZWlnaHQ6MTUuMHB0Ij4NCjx0ZCB3aWR0aD0iMjMlIiB2YWxpZ249InRvcCIgc3R5bGU9Indp
ZHRoOjIzLjElO2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci10b3A6bm9uZTtw
YWRkaW5nOjBjbSA1LjM1cHQgMGNtIDUuMzVwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJU
QUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj40ODAg
VGVtcG9yYXJpbHkgdW5hdmFpbGFibGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRk
IHdpZHRoPSI3NiUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6NzYuOSU7Ym9yZGVyLXRvcDpu
b25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0
O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUuMzVwdCAw
Y20gNS4zNXB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJl
YWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPkNhdXNlIHZhbHVlIE5vIDI1IChFeGNo
YW5nZSByb3V0aW5nIGVycm9yKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0K
PHRyIHN0eWxlPSJwYWdlLWJyZWFrLWluc2lkZTphdm9pZDtoZWlnaHQ6MTUuMHB0Ij4NCjx0ZCB3
aWR0aD0iMjMlIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjIzLjElO2JvcmRlcjpzb2xpZCB3
aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjM1cHQgMGNtIDUu
MzVwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFm
dGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj41MDIgQmFkIEdhdGV3YXk8L3NwYW4+PG86cD48
L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI3NiUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lk
dGg6NzYuOSU7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpz
b2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0
O3BhZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9
IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPkNh
dXNlIHZhbHVlIE5vIDI3IChkZXN0aW5hdGlvbiBvdXQgb2Ygb3JkZXIpPC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9InBhZ2UtYnJlYWstaW5zaWRlOmF2b2lk
O2hlaWdodDoxNC4ycHQiPg0KPHRkIHdpZHRoPSIyMyUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lk
dGg6MjMuMSU7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3Bh
ZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDoxNC4ycHQiPg0KPHAgY2xhc3M9IlRB
QyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPjQ4NCBB
ZGRyZXNzIEluY29tcGxldGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRo
PSI3NiUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6NzYuOSU7Ym9yZGVyLXRvcDpub25lO2Jv
cmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRl
ci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4z
NXB0O2hlaWdodDoxNC4ycHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0
ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPkNhdXNlIHZhbHVlIE5vLiZuYnNwOzI4IGludmFs
aWQgbnVtYmVyIGZvcm1hdCAoYWRkcmVzcyBpbmNvbXBsZXRlKTwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJwYWdlLWJyZWFrLWluc2lkZTphdm9pZDtoZWln
aHQ6MTQuMnB0Ij4NCjx0ZCB3aWR0aD0iMjMlIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjIz
LjElO2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5n
OjBjbSA1LjM1cHQgMGNtIDUuMzVwdDtoZWlnaHQ6MTQuMnB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0
eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj41MDAgU2VydmVy
IEludGVybmFsIGVycm9yPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0i
NzYlIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjc2LjklO2JvcmRlci10b3A6bm9uZTtib3Jk
ZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXIt
cmlnaHQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSA1LjM1cHQgMGNtIDUuMzVw
dDtoZWlnaHQ6MTQuMnB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVy
OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5DYXVzZSB2YWx1ZSBObyAyOSAoZmFjaWxpdHkgcmVq
ZWN0ZWQpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9InBh
Z2UtYnJlYWstaW5zaWRlOmF2b2lkO2hlaWdodDoxNS4wcHQiPg0KPHRkIHdpZHRoPSIyMyUiIHZh
bGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MjMuMSU7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4w
cHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDox
NS4wcHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNw
YW4gbGFuZz0iRU4tR0IiPjQ4MCBUZW1wb3JhcmlseSB1bmF2YWlsYWJsZTwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9Ijc2JSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0
aDo3Ni45JTtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNv
bGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7
cGFkZGluZzowY20gNS4zNXB0IDBjbSA1LjM1cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0i
VEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Q2F1
c2UgdmFsdWUgTm8gMzEgKG5vcm1hbCB1bnNwZWNpZmllZCkgKGNsYXNzIGRlZmF1bHQpIChOT1RF
IDIpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9InBhZ2Ut
YnJlYWstaW5zaWRlOmF2b2lkO2hlaWdodDozNy40cHQiPg0KPHRkIHdpZHRoPSIyMyUiIHZhbGln
bj0idG9wIiBzdHlsZT0id2lkdGg6MjMuMSU7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7
Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDozNy40
cHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4g
bGFuZz0iRU4tR0IiPjQ4NiBCdXN5IGhlcmUgaWYgRGlhZ25vc3RpY3MgaW5kaWNhdG9yIGluY2x1
ZGVzIHRoZSAoQ0NCUyBpbmRpY2F0b3IgPSBDQ0JTIHBvc3NpYmxlKTwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFu
IGxhbmc9IkVOLUdCIj5lbHNlIDQ4MCBUZW1wb3JhcmlseSB1bmF2YWlsYWJsZTwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9Ijc2JSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3
aWR0aDo3Ni45JTtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9t
OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkIHdpbmRvd3RleHQgMS4w
cHQ7cGFkZGluZzowY20gNS4zNXB0IDBjbSA1LjM1cHQ7aGVpZ2h0OjM3LjRwdCI+DQo8cCBjbGFz
cz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+
Q2F1c2UgdmFsdWUgaW4gdGhlIENsYXNzIDAxMCAocmVzb3VyY2UgdW5hdmFpbGFibGUsIENhdXNl
IHZhbHVlIE5vIDM0KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0
eWxlPSJwYWdlLWJyZWFrLWluc2lkZTphdm9pZDtoZWlnaHQ6MjYuMHB0Ij4NCjx0ZCB3aWR0aD0i
MjMlIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjIzLjElO2JvcmRlcjpzb2xpZCB3aW5kb3d0
ZXh0IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjM1cHQgMGNtIDUuMzVwdDto
ZWlnaHQ6MjYuMHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1
dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj41MDAgU2VydmVyIEludGVybmFsIGVycm9yPC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNzYlIiB2YWxpZ249InRvcCIgc3R5bGU9
IndpZHRoOjc2LjklO2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0
b206c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgd2luZG93dGV4dCAx
LjBwdDtwYWRkaW5nOjBjbSA1LjM1cHQgMGNtIDUuMzVwdDtoZWlnaHQ6MjYuMHB0Ij4NCjxwIGNs
YXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdC
Ij5DYXVzZSB2YWx1ZSBpbiB0aGUgQ2xhc3MgMDEwPGJyPg0KKHJlc291cmNlIHVuYXZhaWxhYmxl
LCBDYXVzZSB2YWx1ZSBOb+KAmXMuIDM4LCA0MSwgNDIsIDQzLCA0NCwgJmFtcDsgNDcpICg0NyBp
cyBjbGFzcyBkZWZhdWx0KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRy
IHN0eWxlPSJwYWdlLWJyZWFrLWluc2lkZTphdm9pZDtoZWlnaHQ6MTUuMHB0Ij4NCjx0ZCB3aWR0
aD0iMjMlIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjIzLjElO2JvcmRlcjpzb2xpZCB3aW5k
b3d0ZXh0IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjM1cHQgMGNtIDUuMzVw
dDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVy
OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj41MDAgU2VydmVyIEludGVybmFsIGVycm9yPC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNzYlIiB2YWxpZ249InRvcCIgc3R5
bGU9IndpZHRoOjc2LjklO2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1i
b3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgd2luZG93dGV4
dCAxLjBwdDtwYWRkaW5nOjBjbSA1LjM1cHQgMGNtIDUuMzVwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxw
IGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVO
LUdCIj5DYXVzZSB2YWx1ZSBObyA1MCAocmVxdWVzdGVkIGZhY2lsaXR5IG5vIHN1YnNjcmliZWQp
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9InBhZ2UtYnJl
YWstaW5zaWRlOmF2b2lkO2hlaWdodDoxNS4wcHQiPg0KPHRkIHdpZHRoPSIyMyUiIHZhbGlnbj0i
dG9wIiBzdHlsZT0id2lkdGg6MjMuMSU7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9y
ZGVyLXRvcDpub25lO3BhZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDoxNS4wcHQi
Pg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFu
Zz0iRU4tR0IiPjUwMCBTZXJ2ZXIgSW50ZXJuYWwgZXJyb3I8L3NwYW4+PG86cD48L286cD48L3A+
DQo8L3RkPg0KPHRkIHdpZHRoPSI3NiUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6NzYuOSU7
Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5k
b3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6
MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5
bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPkNhdXNlIHZhbHVl
IE5vIDU3IChiZWFyZXIgY2FwYWJpbGl0eSBub3QgYXV0aG9yaXNlZCk8L3NwYW4+PG86cD48L286
cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0icGFnZS1icmVhay1pbnNpZGU6YXZvaWQ7
aGVpZ2h0OjE1LjBwdCI+DQo8dGQgd2lkdGg9IjIzJSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0
aDoyMy4xJTtib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFk
ZGluZzowY20gNS4zNXB0IDBjbSA1LjM1cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iVEFD
IiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+NTAwIFNl
cnZlciBJbnRlcm5hbCBlcnJvcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lk
dGg9Ijc2JSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDo3Ni45JTtib3JkZXItdG9wOm5vbmU7
Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9y
ZGVyLXJpZ2h0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20gNS4zNXB0IDBjbSA1
LjM1cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1h
ZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Q2F1c2UgdmFsdWUgTm8gNTggKGJlYXJlciBj
YXBhYmlsaXR5IG5vdCBwcmVzZW50bHkpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwv
dHI+DQo8dHIgc3R5bGU9InBhZ2UtYnJlYWstaW5zaWRlOmF2b2lkO2hlaWdodDoxNS4wcHQiPg0K
PHRkIHdpZHRoPSIyMyUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MjMuMSU7Ym9yZGVyOnNv
bGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGNtIDUuMzVwdCAw
Y20gNS4zNXB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJl
YWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPjUwMCBTZXJ2ZXIgSW50ZXJuYWwgZXJy
b3I8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI3NiUiIHZhbGlnbj0i
dG9wIiBzdHlsZT0id2lkdGg6NzYuOSU7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7
Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3
aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDoxNS4w
cHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4g
bGFuZz0iRU4tR0IiPkNhdXNlIHZhbHVlIE5vIDYzIChzZXJ2aWNlIG9wdGlvbiBub3QgYXZhaWxh
YmxlLCB1bnNwZWNpZmllZCk8YnI+DQooY2xhc3MgZGVmYXVsdCk8L3NwYW4+PG86cD48L286cD48
L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0icGFnZS1icmVhay1pbnNpZGU6YXZvaWQ7aGVp
Z2h0OjI1LjI1cHQiPg0KPHRkIHdpZHRoPSIyMyUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6
MjMuMSU7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRp
bmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDoyNS4yNXB0Ij4NCjxwIGNsYXNzPSJUQUMi
IHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj41MDAgU2Vy
dmVyIEludGVybmFsIGVycm9yPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0
aD0iNzYlIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjc2LjklO2JvcmRlci10b3A6bm9uZTti
b3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtib3Jk
ZXItcmlnaHQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSA1LjM1cHQgMGNtIDUu
MzVwdDtoZWlnaHQ6MjUuMjVwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1h
ZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Q2F1c2UgdmFsdWUgaW4gdGhlIENsYXNzIDEw
MCAoc2VydmljZSBvciBvcHRpb24gbm90IGltcGxlbWVudGVkLCBDYXVzZSB2YWx1ZSBOb+KAmXMu
IDY1LCA3MCAmYW1wOyA3OSkgNzkgaXMgY2xhc3MgZGVmYXVsdDwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJwYWdlLWJyZWFrLWluc2lkZTphdm9pZDtoZWln
aHQ6MTUuMHB0Ij4NCjx0ZCB3aWR0aD0iMjMlIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjIz
LjElO2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5n
OjBjbSA1LjM1cHQgMGNtIDUuMzVwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0
eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj41MDAgU2VydmVy
IEludGVybmFsIGVycm9yPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0i
NzYlIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjc2LjklO2JvcmRlci10b3A6bm9uZTtib3Jk
ZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXIt
cmlnaHQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSA1LjM1cHQgMGNtIDUuMzVw
dDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVy
OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj5DYXVzZSB2YWx1ZSBObyA4OCAoaW5jb21wYXRpYmxlIGRl
c3RpbmF0aW9uKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxl
PSJwYWdlLWJyZWFrLWluc2lkZTphdm9pZDtoZWlnaHQ6MTUuMHB0Ij4NCjx0ZCB3aWR0aD0iMjMl
IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjIzLjElO2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0
IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjM1cHQgMGNtIDUuMzVwdDtoZWln
aHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8i
PjxzcGFuIGxhbmc9IkVOLUdCIj40MDQgTm90IEZvdW5kPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PC90ZD4NCjx0ZCB3aWR0aD0iNzYlIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjc2LjklO2Jv
cmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93
dGV4dCAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBj
bSA1LjM1cHQgMGNtIDUuMzVwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxl
PSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5DYXVzZSB2YWx1ZSBO
byA5MSAoaW52YWxpZCB0cmFuc2l0IG5ldHdvcmsgc2VsZWN0aW9uKTwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJwYWdlLWJyZWFrLWluc2lkZTphdm9pZDto
ZWlnaHQ6MTUuMHB0Ij4NCjx0ZCB3aWR0aD0iMjMlIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRo
OjIzLjElO2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRk
aW5nOjBjbSA1LjM1cHQgMGNtIDUuMzVwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJUQUMi
IHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj41MDAgU2Vy
dmVyIEludGVybmFsIGVycm9yPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0
aD0iNzYlIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjc2LjklO2JvcmRlci10b3A6bm9uZTti
b3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtib3Jk
ZXItcmlnaHQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSA1LjM1cHQgMGNtIDUu
MzVwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFm
dGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5DYXVzZSB2YWx1ZSBObyA5NSAoaW52YWxpZCBt
ZXNzYWdlKTxicj4NCihjbGFzcyBkZWZhdWx0KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+
DQo8L3RyPg0KPHRyIHN0eWxlPSJwYWdlLWJyZWFrLWluc2lkZTphdm9pZDtoZWlnaHQ6MTYuNTVw
dCI+DQo8dGQgd2lkdGg9IjIzJSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoyMy4xJTtib3Jk
ZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowY20gNS4z
NXB0IDBjbSA1LjM1cHQ7aGVpZ2h0OjE2LjU1cHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBh
Z2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPjUwMCBTZXJ2ZXIgSW50ZXJu
YWwgZXJyb3I8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI3NiUiIHZh
bGlnbj0idG9wIiBzdHlsZT0id2lkdGg6NzYuOSU7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0
Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpz
b2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdo
dDoxNi41NXB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8i
PjxzcGFuIGxhbmc9IkVOLUdCIj5DYXVzZSB2YWx1ZSBObyA5NyAoPC9zcGFuPjxzcGFuIGxhbmc9
IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+TWVzc2FnZSB0eXBlIG5vbi1leGlzdGVu
dCBvciBub3QgaW1wbGVtZW50ZWQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPik8L3NwYW4+PG86
cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0icGFnZS1icmVhay1pbnNpZGU6
YXZvaWQ7aGVpZ2h0OjE1LjBwdCI+DQo8dGQgd2lkdGg9IjIzJSIgdmFsaWduPSJ0b3AiIHN0eWxl
PSJ3aWR0aDoyMy4xJTtib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItdG9wOm5v
bmU7cGFkZGluZzowY20gNS4zNXB0IDBjbSA1LjM1cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFz
cz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+
NTAwIFNlcnZlciBJbnRlcm5hbCBlcnJvcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8
dGQgd2lkdGg9Ijc2JSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDo3Ni45JTtib3JkZXItdG9w
Om5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4w
cHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20gNS4zNXB0
IDBjbSA1LjM1cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1i
cmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Q2F1c2UgdmFsdWUgTm8gOTkgKGlu
Zm9ybWF0aW9uIGVsZW1lbnQvcGFyYW1ldGVyIG5vbi1leGlzdGVudCBvciBub3QgaW1wbGVtZW50
ZWQpKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJwYWdl
LWJyZWFrLWluc2lkZTphdm9pZDtoZWlnaHQ6MTUuMHB0Ij4NCjx0ZCB3aWR0aD0iMjMlIiB2YWxp
Z249InRvcCIgc3R5bGU9IndpZHRoOjIzLjElO2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0
O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjM1cHQgMGNtIDUuMzVwdDtoZWlnaHQ6MTUu
MHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFu
IGxhbmc9IkVOLUdCIj40ODAgVGVtcG9yYXJpbHkgdW5hdmFpbGFibGU8L3NwYW4+PG86cD48L286
cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI3NiUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6
NzYuOSU7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xp
ZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3Bh
ZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9IlRB
QyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPkNhdXNl
IHZhbHVlIE5vLiZuYnNwOzEwMiAocmVjb3Zlcnkgb24gdGltZXIgZXhwaXJ5KTwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJwYWdlLWJyZWFrLWluc2lkZTph
dm9pZDtoZWlnaHQ6MTUuMHB0Ij4NCjx0ZCB3aWR0aD0iMjMlIiB2YWxpZ249InRvcCIgc3R5bGU9
IndpZHRoOjIzLjElO2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci10b3A6bm9u
ZTtwYWRkaW5nOjBjbSA1LjM1cHQgMGNtIDUuMzVwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNz
PSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj41
MDAgU2VydmVyIEludGVybmFsIGVycm9yPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0
ZCB3aWR0aD0iNzYlIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjc2LjklO2JvcmRlci10b3A6
bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBw
dDtib3JkZXItcmlnaHQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSA1LjM1cHQg
MGNtIDUuMzVwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJy
ZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5DYXVzZSB2YWx1ZSBObyAxMTAgKE1l
c3NhZ2Ugd2l0aCB1bnJlY29nbmlzZWQgUGFyYW1ldGVyLCBkaXNjYXJkZWQpPC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9InBhZ2UtYnJlYWstaW5zaWRlOmF2
b2lkO2hlaWdodDoxNS4wcHQiPg0KPHRkIHdpZHRoPSIyMyUiIHZhbGlnbj0idG9wIiBzdHlsZT0i
d2lkdGg6MjMuMSU7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25l
O3BhZGRpbmc6MGNtIDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9
IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPjUw
MCBTZXJ2ZXIgSW50ZXJuYWwgZXJyb3I8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRk
IHdpZHRoPSI3NiUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6NzYuOSU7Ym9yZGVyLXRvcDpu
b25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0
O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUuMzVwdCAw
Y20gNS4zNXB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJl
YWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPkNhdXNlIHZhbHVlIE5vLiZuYnNwOzEx
MSAocHJvdG9jb2wgZXJyb3IsIHVuc3BlY2lmaWVkKTxicj4NCihjbGFzcyBkZWZhdWx0KTwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJwYWdlLWJyZWFrLWlu
c2lkZTphdm9pZDtoZWlnaHQ6MTkuMnB0Ij4NCjx0ZCB3aWR0aD0iMjMlIiB2YWxpZ249InRvcCIg
c3R5bGU9IndpZHRoOjIzLjElO2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci10
b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjM1cHQgMGNtIDUuMzVwdDtoZWlnaHQ6MTkuMnB0Ij4NCjxw
IGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVO
LUdCIj40ODAgVGVtcG9yYXJpbHkgdW5hdmFpbGFibGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8
L3RkPg0KPHRkIHdpZHRoPSI3NiUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6NzYuOSU7Ym9y
ZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0
ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNt
IDUuMzVwdCAwY20gNS4zNXB0O2hlaWdodDoxOS4ycHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9
InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPkNhdXNlIHZhbHVlIE5v
LiAxMjcgKGludGVyd29ya2luZyB1bnNwZWNpZmllZCk8YnI+DQooY2xhc3MgZGVmYXVsdCk8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0icGFnZS1icmVhay1p
bnNpZGU6YXZvaWQ7aGVpZ2h0OjE5LjJwdCI+DQo8dGQgd2lkdGg9IjEwMCUiIGNvbHNwYW49IjIi
IHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTAwLjAlO2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0
IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjM1cHQgMGNtIDUuMzVwdDtoZWln
aHQ6MTkuMnB0Ij4NCjxwIGNsYXNzPSJUQU4iPjxzcGFuIGxhbmc9IkVOLUdCIj5OT1RFIDE6Jm5i
c3A7Jm5ic3A7Jm5ic3A7IEFub255bWl0eSBEaXNhbGxvd2VkLCBSRkMgNTA3OSBbNzddIHJlZmVy
czwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJUQU4iPjxzcGFuIGxhbmc9IkVOLUdC
Ij5OT1RFIDI6Jm5ic3A7Jm5ic3A7Jm5ic3A7IENsYXNzIDEgYW5kIGNsYXNzIDIgaGF2ZSB0aGUg
c2FtZSBkZWZhdWx0IHZhbHVlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0K
PC90Ym9keT4NCjwvdGFibGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PC90ZD4NCjx0ZCB3aWR0aD0iMzI3IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjI0NS4xcHQ7
Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLWxlZnQ6bm9uZTtwYWRkaW5nOjBj
bSA1LjRwdCAwY20gNS40cHQiPg0KPHAgY2xhc3M9IlRIIiBzdHlsZT0icGFnZS1icmVhay1hZnRl
cjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+VGFibGUgMTg6IDR4eC81eHgvNnh4IFJlY2VpdmVk
IG9uIFNJUCBzaWRlIG9mIE8tTUdDRjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgYWxpZ249
ImNlbnRlciI+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxz
cGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgc3R5bGU9ImJvcmRlci1jb2xsYXBzZTpjb2xsYXBz
ZSI+DQo8dGhlYWQ+DQo8dHIgc3R5bGU9ImhlaWdodDoxOC40cHQiPg0KPHRkIHdpZHRoPSIxOTki
IHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTQ5LjE1cHQ7Ym9yZGVyOnNvbGlkIHdpbmRvd3Rl
eHQgMS4wcHQ7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0O2hlaWdodDoxOC40cHQiPg0KPHAg
Y2xhc3M9IlRBSCIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4t
R0IiIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPsKsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdC
Ij5SRUwgKGNhdXNlIGNvZGUpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0
aD0iMjU1IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjE5MS4zNXB0O2JvcmRlcjpzb2xpZCB3
aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1sZWZ0Om5vbmU7cGFkZGluZzowY20gNS40cHQgMGNtIDUu
NHB0O2hlaWdodDoxOC40cHQiPg0KPHAgY2xhc3M9IlRBSCIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0
ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPsKs
PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj40eHgvNXh4LzZ4eCBTSVAgTWVzc2FnZTwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90aGVhZD4NCjx0Ym9keT4NCjx0ciBzdHlsZT0i
aGVpZ2h0OjE4LjRwdCI+DQo8dGQgd2lkdGg9IjE5OSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0
aDoxNDkuMTVwdDtib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItdG9wOm5vbmU7
cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0O2hlaWdodDoxOC40cHQiPg0KPHAgY2xhc3M9IlRB
QyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPjEyNyAo
aW50ZXJ3b3JraW5nIHVuc3BlY2lmaWVkKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8
dGQgd2lkdGg9IjI1NSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxOTEuMzVwdDtib3JkZXIt
dG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQg
MS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20gNS40
cHQgMGNtIDUuNHB0O2hlaWdodDoxOC40cHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2Ut
YnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPjQwMCBCYWQgUmVxdWVzdDwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTguNHB0
Ij4NCjx0ZCB3aWR0aD0iMTk5IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjE0OS4xNXB0O2Jv
cmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1
LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFn
ZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+MTI3IChpbnRlcndvcmtpbmcg
dW5zcGVjaWZpZWQpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iMjU1
IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjE5MS4zNXB0O2JvcmRlci10b3A6bm9uZTtib3Jk
ZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXIt
cmlnaHQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7
aGVpZ2h0OjE4LjRwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjph
dXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+NDAxIFVuYXV0aG9yaXplZDwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTguNHB0Ij4NCjx0ZCB3aWR0
aD0iMTk5IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjE0OS4xNXB0O2JvcmRlcjpzb2xpZCB3
aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40
cHQ7aGVpZ2h0OjE4LjRwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRl
cjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+MTI3IChpbnRlcndvcmtpbmcgdW5zcGVjaWZpZWQp
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iMjU1IiB2YWxpZ249InRv
cCIgc3R5bGU9IndpZHRoOjE5MS4zNXB0O2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25l
O2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQg
d2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRw
dCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBs
YW5nPSJFTi1HQiI+NDAyIFBheW1lbnQgUmVxdWlyZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8
L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE4LjRwdCI+DQo8dGQgd2lkdGg9IjE5OSIg
dmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxNDkuMTVwdDtib3JkZXI6c29saWQgd2luZG93dGV4
dCAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0O2hlaWdo
dDoxOC40cHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+
PHNwYW4gbGFuZz0iRU4tR0IiPjEyNyAoaW50ZXJ3b3JraW5nIHVuc3BlY2lmaWVkKTwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjI1NSIgdmFsaWduPSJ0b3AiIHN0eWxl
PSJ3aWR0aDoxOTEuMzVwdDtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXIt
Ym90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkIHdpbmRvd3Rl
eHQgMS4wcHQ7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0O2hlaWdodDoxOC40cHQiPg0KPHAg
Y2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4t
R0IiPjQwMyBGb3JiaWRkZW48L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0
ciBzdHlsZT0iaGVpZ2h0OjE4LjRwdCI+DQo8dGQgd2lkdGg9IjE5OSIgdmFsaWduPSJ0b3AiIHN0
eWxlPSJ3aWR0aDoxNDkuMTVwdDtib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXIt
dG9wOm5vbmU7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0O2hlaWdodDoxOC40cHQiPg0KPHAg
Y2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4t
R0IiPjEgKFVuYWxsb2NhdGVkIG51bWJlcik8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0K
PHRkIHdpZHRoPSIyNTUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTkxLjM1cHQ7Ym9yZGVy
LXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0
IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUu
NHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdl
LWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj40MDQgTm90IEZvdW5kPC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9ImhlaWdodDoxOC40cHQi
Pg0KPHRkIHdpZHRoPSIxOTkiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTQ5LjE1cHQ7Ym9y
ZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGNtIDUu
NHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdl
LWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4xMjcgKGludGVyd29ya2luZyB1
bnNwZWNpZmllZCk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSIyNTUi
IHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTkxLjM1cHQ7Ym9yZGVyLXRvcDpub25lO2JvcmRl
ci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1y
aWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdDto
ZWlnaHQ6MTguNHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1
dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj40MDUgTWV0aG9kIE5vdCBBbGxvd2VkPC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9ImhlaWdodDoxOC40cHQiPg0KPHRk
IHdpZHRoPSIxOTkiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTQ5LjE1cHQ7Ym9yZGVyOnNv
bGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGNtIDUuNHB0IDBj
bSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFr
LWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4xMjcgKGludGVyd29ya2luZyB1bnNwZWNp
ZmllZCk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSIyNTUiIHZhbGln
bj0idG9wIiBzdHlsZT0id2lkdGg6MTkxLjM1cHQ7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0
Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpz
b2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdDtoZWlnaHQ6
MTguNHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxz
cGFuIGxhbmc9IkVOLUdCIj40MDYgTm90IEFjY2VwdGFibGU8L3NwYW4+PG86cD48L286cD48L3A+
DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE4LjRwdCI+DQo8dGQgd2lkdGg9IjE5
OSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxNDkuMTVwdDtib3JkZXI6c29saWQgd2luZG93
dGV4dCAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0O2hl
aWdodDoxOC40cHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0
byI+PHNwYW4gbGFuZz0iRU4tR0IiPjEyNyAoaW50ZXJ3b3JraW5nIHVuc3BlY2lmaWVkKTwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjI1NSIgdmFsaWduPSJ0b3AiIHN0
eWxlPSJ3aWR0aDoxOTEuMzVwdDtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3Jk
ZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkIHdpbmRv
d3RleHQgMS4wcHQ7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0O2hlaWdodDoxOC40cHQiPg0K
PHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0i
RU4tR0IiPjQwNyBQcm94eSBhdXRoZW50aWNhdGlvbiByZXF1aXJlZDwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTguNHB0Ij4NCjx0ZCB3aWR0
aD0iMTk5IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjE0OS4xNXB0O2JvcmRlcjpzb2xpZCB3
aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40
cHQ7aGVpZ2h0OjE4LjRwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRl
cjphdXRvIj48Yj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93O21z
by1oaWdobGlnaHQ6eWVsbG93Ij4xMjcgKGludGVyd29ya2luZyB1bnNwZWNpZmllZCk8L3NwYW4+
PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iMjU1IiB2YWxpZ249InRvcCIg
c3R5bGU9IndpZHRoOjE5MS4zNXB0O2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2Jv
cmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgd2lu
ZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRwdCI+
DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48Yj48c3BhbiBs
YW5nPSJFTi1HQiIgc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93
Ij40MDggUmVxdWVzdCBUaW1lb3V0PC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8
L3RyPg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTguNHB0Ij4NCjx0ZCB3aWR0aD0iMTk5IiB2YWxpZ249
InRvcCIgc3R5bGU9IndpZHRoOjE0OS4xNXB0O2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0
O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRw
dCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBs
YW5nPSJFTi1HQiI+MjIgKE51bWJlciBjaGFuZ2VkKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv
dGQ+DQo8dGQgd2lkdGg9IjI1NSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxOTEuMzVwdDti
b3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRv
d3RleHQgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzow
Y20gNS40cHQgMGNtIDUuNHB0O2hlaWdodDoxOC40cHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9
InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPjQxMCBHb25lPC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9ImhlaWdodDoxOC40cHQi
Pg0KPHRkIHdpZHRoPSIxOTkiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTQ5LjE1cHQ7Ym9y
ZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGNtIDUu
NHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdl
LWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4xMjcgKGludGVyd29ya2luZyB1
bnNwZWNpZmllZCk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSIyNTUi
IHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTkxLjM1cHQ7Ym9yZGVyLXRvcDpub25lO2JvcmRl
ci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1y
aWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdDto
ZWlnaHQ6MTguNHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1
dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj40MTMgUmVxdWVzdCBFbnRpdHkgdG9vIGxvbmc8L3NwYW4+
PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE4LjRwdCI+
DQo8dGQgd2lkdGg9IjE5OSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxNDkuMTVwdDtib3Jk
ZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowY20gNS40
cHQgMGNtIDUuNHB0O2hlaWdodDoxOC40cHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2Ut
YnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPjEyNyAoaW50ZXJ3b3JraW5nIHVu
c3BlY2lmaWVkKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjI1NSIg
dmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxOTEuMzVwdDtib3JkZXItdG9wOm5vbmU7Ym9yZGVy
LWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXJp
Z2h0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0O2hl
aWdodDoxOC40cHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0
byI+PHNwYW4gbGFuZz0iRU4tR0IiPjQxNCBSZXF1ZXN0LVVSSSB0b28gbG9uZzwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTguNHB0Ij4NCjx0
ZCB3aWR0aD0iMTk5IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjE0OS4xNXB0O2JvcmRlcjpz
b2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjRwdCAw
Y20gNS40cHQ7aGVpZ2h0OjE4LjRwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVh
ay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+MTI3IChpbnRlcndvcmtpbmcgdW5zcGVj
aWZpZWQpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iMjU1IiB2YWxp
Z249InRvcCIgc3R5bGU9IndpZHRoOjE5MS4zNXB0O2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVm
dDpub25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItcmlnaHQ6
c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0
OjE4LjRwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48
c3BhbiBsYW5nPSJFTi1HQiI+NDE1IFVuc3VwcG9ydGVkIE1lZGlhIHR5cGU8L3NwYW4+PG86cD48
L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE4LjRwdCI+DQo8dGQg
d2lkdGg9IjE5OSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxNDkuMTVwdDtib3JkZXI6c29s
aWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowY20gNS40cHQgMGNt
IDUuNHB0O2hlaWdodDoxOC40cHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWst
YWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPjEyNyAoaW50ZXJ3b3JraW5nIHVuc3BlY2lm
aWVkKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjI1NSIgdmFsaWdu
PSJ0b3AiIHN0eWxlPSJ3aWR0aDoxOTEuMzVwdDtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6
bm9uZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNv
bGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0O2hlaWdodDox
OC40cHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNw
YW4gbGFuZz0iRU4tR0IiPjQxNiBVbnN1cHBvcnRlZCBVUkkgc2NoZW1lPC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9ImhlaWdodDoxOC40cHQiPg0KPHRkIHdp
ZHRoPSIxOTkiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTQ5LjE1cHQ7Ym9yZGVyOnNvbGlk
IHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1
LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFm
dGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4xMjcgKGludGVyd29ya2luZyB1bnNwZWNpZmll
ZCk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSIyNTUiIHZhbGlnbj0i
dG9wIiBzdHlsZT0id2lkdGg6MTkxLjM1cHQ7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5v
bmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpzb2xp
ZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTgu
NHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFu
IGxhbmc9IkVOLUdCIj40MjAgQmFkIEV4dGVuc2lvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv
dGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTguNHB0Ij4NCjx0ZCB3aWR0aD0iMTk5IiB2
YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjE0OS4xNXB0O2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0
IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0
OjE4LjRwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48
c3BhbiBsYW5nPSJFTi1HQiI+MTI3IChpbnRlcndvcmtpbmcgdW5zcGVjaWZpZWQpPC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iMjU1IiB2YWxpZ249InRvcCIgc3R5bGU9
IndpZHRoOjE5MS4zNXB0O2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1i
b3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgd2luZG93dGV4
dCAxLjBwdDtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRwdCI+DQo8cCBj
bGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1H
QiI+NDIxIEV4dGVuc2lvbiByZXF1aXJlZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8
L3RyPg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTguNHB0Ij4NCjx0ZCB3aWR0aD0iMTk5IiB2YWxpZ249
InRvcCIgc3R5bGU9IndpZHRoOjE0OS4xNXB0O2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0
O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRw
dCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBs
YW5nPSJFTi1HQiI+MTI3IChpbnRlcndvcmtpbmcgdW5zcGVjaWZpZWQpPC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iMjU1IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRo
OjE5MS4zNXB0O2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206
c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgd2luZG93dGV4dCAxLjBw
dDtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRwdCI+DQo8cCBjbGFzcz0i
VEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+NDIz
IEludGVydmFsIFRvbyBCcmllZjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0K
PHRyIHN0eWxlPSJoZWlnaHQ6MTguNHB0Ij4NCjx0ZCB3aWR0aD0iMTk5IiB2YWxpZ249InRvcCIg
c3R5bGU9IndpZHRoOjE0OS4xNXB0O2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRl
ci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRwdCI+DQo8
cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJF
Ti1HQiI+MjQgKGNhbGwgcmVqZWN0ZWQgZHVlIHRvIEFDUiBzdXBwbGVtZW50YXJ5IHNlcnZpY2Up
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iMjU1IiB2YWxpZ249InRv
cCIgc3R5bGU9IndpZHRoOjE5MS4zNXB0O2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25l
O2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQg
d2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRw
dCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBs
YW5nPSJFTi1HQiI+NDMzIEFub255bWl0eSBEaXNhbGxvd2VkLihOT1RFIDEpPC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9ImhlaWdodDoxOC40cHQiPg0KPHRk
IHdpZHRoPSIxOTkiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTQ5LjE1cHQ7Ym9yZGVyOnNv
bGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGNtIDUuNHB0IDBj
bSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFr
LWFmdGVyOmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iYmFja2dyb3VuZDp5ZWxs
b3c7bXNvLWhpZ2hsaWdodDp5ZWxsb3ciPjIwIFN1YnNjcmliZXIgYWJzZW50PC9zcGFuPjwvYj48
bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjI1NSIgdmFsaWduPSJ0b3AiIHN0eWxl
PSJ3aWR0aDoxOTEuMzVwdDtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXIt
Ym90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkIHdpbmRvd3Rl
eHQgMS4wcHQ7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0O2hlaWdodDoxOC40cHQiPg0KPHAg
Y2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PGI+PHNwYW4gbGFuZz0i
RU4tR0IiIHN0eWxlPSJiYWNrZ3JvdW5kOnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxvdyI+NDgw
IFRlbXBvcmFyaWx5IFVuYXZhaWxhYmxlPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+
DQo8L3RyPg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTguNHB0Ij4NCjx0ZCB3aWR0aD0iMTk5IiB2YWxp
Z249InRvcCIgc3R5bGU9IndpZHRoOjE0OS4xNXB0O2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEu
MHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4
LjRwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3Bh
biBsYW5nPSJFTi1HQiI+MTI3IChpbnRlcndvcmtpbmcgdW5zcGVjaWZpZWQpPC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iMjU1IiB2YWxpZ249InRvcCIgc3R5bGU9Indp
ZHRoOjE5MS4zNXB0O2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0
b206c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgd2luZG93dGV4dCAx
LjBwdDtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRwdCI+DQo8cCBjbGFz
cz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+
NDgxIENhbGwvVHJhbnNhY3Rpb24gZG9lcyBub3QgZXhpc3Q8L3NwYW4+PG86cD48L286cD48L3A+
DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE4LjRwdCI+DQo8dGQgd2lkdGg9IjE5
OSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxNDkuMTVwdDtib3JkZXI6c29saWQgd2luZG93
dGV4dCAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0O2hl
aWdodDoxOC40cHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0
byI+PHNwYW4gbGFuZz0iRU4tR0IiPjEyNyAoaW50ZXJ3b3JraW5nIHVuc3BlY2lmaWVkKTwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjI1NSIgdmFsaWduPSJ0b3AiIHN0
eWxlPSJ3aWR0aDoxOTEuMzVwdDtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3Jk
ZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkIHdpbmRv
d3RleHQgMS4wcHQ7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0O2hlaWdodDoxOC40cHQiPg0K
PHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0i
RU4tR0IiPjQ4MiBMb29wIGRldGVjdGVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwv
dHI+DQo8dHIgc3R5bGU9ImhlaWdodDoxOC40cHQiPg0KPHRkIHdpZHRoPSIxOTkiIHZhbGlnbj0i
dG9wIiBzdHlsZT0id2lkdGg6MTQ5LjE1cHQ7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7
Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTguNHB0
Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxh
bmc9IkVOLUdCIj4xMjcgKGludGVyd29ya2luZyB1bnNwZWNpZmllZCk8L3NwYW4+PG86cD48L286
cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSIyNTUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6
MTkxLjM1cHQ7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpz
b2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0
O3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNsYXNzPSJU
QUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj40ODMg
VG9vIG1hbnkgaG9wczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0
eWxlPSJoZWlnaHQ6MTguNHB0Ij4NCjx0ZCB3aWR0aD0iMTk5IiB2YWxpZ249InRvcCIgc3R5bGU9
IndpZHRoOjE0OS4xNXB0O2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci10b3A6
bm9uZTtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRwdCI+DQo8cCBjbGFz
cz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+
MjggKEludmFsaWQgTnVtYmVyIGZvcm1hdCk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0K
PHRkIHdpZHRoPSIyNTUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTkxLjM1cHQ7Ym9yZGVy
LXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0
IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUu
NHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdl
LWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj40ODQgQWRkcmVzcyBJbmNvbXBs
ZXRlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9ImhlaWdo
dDoxOC40cHQiPg0KPHRkIHdpZHRoPSIxOTkiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTQ5
LjE1cHQ7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRp
bmc6MGNtIDUuNHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0
eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4xMjcgKGludGVy
d29ya2luZyB1bnNwZWNpZmllZCk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdp
ZHRoPSIyNTUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTkxLjM1cHQ7Ym9yZGVyLXRvcDpu
b25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0
O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUuNHB0IDBj
bSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFr
LWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj40ODUgQW1iaWd1b3VzPC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9ImhlaWdodDoxOC40cHQiPg0KPHRk
IHdpZHRoPSIxOTkiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTQ5LjE1cHQ7Ym9yZGVyOnNv
bGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGNtIDUuNHB0IDBj
bSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFr
LWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4xNyAoVXNlciBidXN5KTwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjI1NSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3
aWR0aDoxOTEuMzVwdDtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90
dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkIHdpbmRvd3RleHQg
MS4wcHQ7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0O2hlaWdodDoxOC40cHQiPg0KPHAgY2xh
c3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0Ii
PjQ4NiBCdXN5IEhlcmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBz
dHlsZT0iaGVpZ2h0OjE4LjRwdCI+DQo8dGQgd2lkdGg9IjE5OSIgdmFsaWduPSJ0b3AiIHN0eWxl
PSJ3aWR0aDoxNDkuMTVwdDtib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItdG9w
Om5vbmU7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0O2hlaWdodDoxOC40cHQiPg0KPHAgY2xh
c3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0Ii
PjEyNyAoSW50ZXJ3b3JraW5nIHVuc3BlY2lmaWVkKSBvciBub3QgaW50ZXJ3b3JrZWQuIChOT1RF
IDIpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iMjU1IiB2YWxpZ249
InRvcCIgc3R5bGU9IndpZHRoOjE5MS4zNXB0O2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpu
b25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItcmlnaHQ6c29s
aWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4
LjRwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3Bh
biBsYW5nPSJFTi1HQiI+NDg3IFJlcXVlc3QgdGVybWluYXRlZDwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTguNHB0Ij4NCjx0ZCB3aWR0aD0i
MTk5IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjE0OS4xNXB0O2JvcmRlcjpzb2xpZCB3aW5k
b3d0ZXh0IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7
aGVpZ2h0OjE4LjRwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjph
dXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+MTI3IChpbnRlcndvcmtpbmcgdW5zcGVjaWZpZWQpPC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iMjU1IiB2YWxpZ249InRvcCIg
c3R5bGU9IndpZHRoOjE5MS4zNXB0O2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2Jv
cmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgd2lu
ZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRwdCI+
DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5n
PSJFTi1HQiI+NDg4IE5vdCBhY2NlcHRhYmxlIGhlcmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8
L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE4LjRwdCI+DQo8dGQgd2lkdGg9IjE5OSIg
dmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxNDkuMTVwdDtib3JkZXI6c29saWQgd2luZG93dGV4
dCAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0O2hlaWdo
dDoxOC40cHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+
PHNwYW4gbGFuZz0iRU4tR0IiPjEyNyAoaW50ZXJ3b3JraW5nIHVuc3BlY2lmaWVkKTwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjI1NSIgdmFsaWduPSJ0b3AiIHN0eWxl
PSJ3aWR0aDoxOTEuMzVwdDtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXIt
Ym90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkIHdpbmRvd3Rl
eHQgMS4wcHQ7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0O2hlaWdodDoxOC40cHQiPg0KPHAg
Y2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4t
R0IiPjQ5MyBVbmRlY2lwaGVyYWJsZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3Ry
Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTguNHB0Ij4NCjx0ZCB3aWR0aD0iMTk5IiB2YWxpZ249InRv
cCIgc3R5bGU9IndpZHRoOjE0OS4xNXB0O2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2Jv
cmRlci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRwdCI+
DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5n
PSJFTi1HQiI+MTI3IChpbnRlcndvcmtpbmcgdW5zcGVjaWZpZWQpPC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iMjU1IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjE5
MS4zNXB0O2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29s
aWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtw
YWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRwdCI+DQo8cCBjbGFzcz0iVEFD
IiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+NTAwIFNl
cnZlciBJbnRlcm5hbCBlcnJvcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0K
PHRyIHN0eWxlPSJoZWlnaHQ6MTguNHB0Ij4NCjx0ZCB3aWR0aD0iMTk5IiB2YWxpZ249InRvcCIg
c3R5bGU9IndpZHRoOjE0OS4xNXB0O2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRl
ci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRwdCI+DQo8
cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJF
Ti1HQiI+MTI3IChpbnRlcndvcmtpbmcgdW5zcGVjaWZpZWQpPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPC90ZD4NCjx0ZCB3aWR0aD0iMjU1IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjE5MS4z
NXB0O2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQg
d2luZG93dGV4dCAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRk
aW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRwdCI+DQo8cCBjbGFzcz0iVEFDIiBz
dHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+NTAxIE5vdCBp
bXBsZW1lbnRlZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxl
PSJoZWlnaHQ6MTguNHB0Ij4NCjx0ZCB3aWR0aD0iMTk5IiB2YWxpZ249InRvcCIgc3R5bGU9Indp
ZHRoOjE0OS4xNXB0O2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci10b3A6bm9u
ZTtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRwdCI+DQo8cCBjbGFzcz0i
VEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+MTI3
IChpbnRlcndvcmtpbmcgdW5zcGVjaWZpZWQpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4N
Cjx0ZCB3aWR0aD0iMjU1IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjE5MS4zNXB0O2JvcmRl
ci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4
dCAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSA1
LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFn
ZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+NTAyIEJhZCBHYXRld2F5PC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9ImhlaWdodDoxOC40
cHQiPg0KPHRkIHdpZHRoPSIxOTkiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTQ5LjE1cHQ7
Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGNt
IDUuNHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJw
YWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4xMjcgKGludGVyd29ya2lu
ZyB1bnNwZWNpZmllZCk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSIy
NTUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTkxLjM1cHQ7Ym9yZGVyLXRvcDpub25lO2Jv
cmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRl
ci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRw
dDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVy
OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj41MDMgU2VydmljZSBVbmF2YWlsYWJsZTwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTguNHB0Ij4N
Cjx0ZCB3aWR0aD0iMTk5IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjE0OS4xNXB0O2JvcmRl
cjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjRw
dCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1i
cmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+MTI3IChpbnRlcndvcmtpbmcgdW5z
cGVjaWZpZWQpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iMjU1IiB2
YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjE5MS4zNXB0O2JvcmRlci10b3A6bm9uZTtib3JkZXIt
bGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItcmln
aHQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVp
Z2h0OjE4LjRwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRv
Ij48c3BhbiBsYW5nPSJFTi1HQiI+NTA0IFNlcnZlciB0aW1lb3V0PC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9ImhlaWdodDoxOC40cHQiPg0KPHRkIHdpZHRo
PSIxOTkiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTQ5LjE1cHQ7Ym9yZGVyOnNvbGlkIHdp
bmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRw
dDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVy
OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4xMjcgKGludGVyd29ya2luZyB1bnNwZWNpZmllZCk8
L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSIyNTUiIHZhbGlnbj0idG9w
IiBzdHlsZT0id2lkdGg6MTkxLjM1cHQ7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7
Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3
aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTguNHB0
Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxh
bmc9IkVOLUdCIj41MDUgVmVyc2lvbiBub3Qgc3VwcG9ydGVkPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9ImhlaWdodDoxOC40cHQiPg0KPHRkIHdpZHRoPSIx
OTkiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTQ5LjE1cHQ7Ym9yZGVyOnNvbGlkIHdpbmRv
d3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdDto
ZWlnaHQ6MTguNHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1
dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4xMjcgKGludGVyd29ya2luZyB1bnNwZWNpZmllZCk8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSIyNTUiIHZhbGlnbj0idG9wIiBz
dHlsZT0id2lkdGg6MTkxLjM1cHQ7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9y
ZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3aW5k
b3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4N
CjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9
IkVOLUdCIj41MTMgTWVzc2FnZSB0b28gbGFyZ2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3Rk
Pg0KPC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE4LjRwdCI+DQo8dGQgd2lkdGg9IjE5OSIgdmFs
aWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxNDkuMTVwdDtib3JkZXI6c29saWQgd2luZG93dGV4dCAx
LjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0O2hlaWdodDox
OC40cHQiPg0KPHAgY2xhc3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNw
YW4gbGFuZz0iRU4tR0IiPjEyNyAoaW50ZXJ3b3JraW5nIHVuc3BlY2lmaWVkKTwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjI1NSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3
aWR0aDoxOTEuMzVwdDtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90
dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkIHdpbmRvd3RleHQg
MS4wcHQ7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0O2hlaWdodDoxOC40cHQiPg0KPHAgY2xh
c3M9IlRBQyIgc3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0Ii
PjU4MCBQcmVjb25kaXRpb24gZmFpbHVyZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8
L3RyPg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTguNHB0Ij4NCjx0ZCB3aWR0aD0iMTk5IiB2YWxpZ249
InRvcCIgc3R5bGU9IndpZHRoOjE0OS4xNXB0O2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0
O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRw
dCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBs
YW5nPSJFTi1HQiI+MTcgKFVzZXIgYnVzeSk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0K
PHRkIHdpZHRoPSIyNTUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTkxLjM1cHQ7Ym9yZGVy
LXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0
IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUu
NHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdl
LWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj42MDAgQnVzeSBFdmVyeXdoZXJl
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9ImhlaWdodDox
OC40cHQiPg0KPHRkIHdpZHRoPSIxOTkiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTQ5LjE1
cHQ7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6
MGNtIDUuNHB0IDBjbSA1LjRwdDtoZWlnaHQ6MTguNHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxl
PSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4yMSAoQ2FsbCByZWpl
Y3RlZCk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSIyNTUiIHZhbGln
bj0idG9wIiBzdHlsZT0id2lkdGg6MTkxLjM1cHQ7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0
Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpz
b2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdDtoZWlnaHQ6
MTguNHB0Ij4NCjxwIGNsYXNzPSJUQUMiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVyOmF1dG8iPjxz
cGFuIGxhbmc9IkVOLUdCIj42MDMgRGVjbGluZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+
DQo8L3RyPg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTguNHB0Ij4NCjx0ZCB3aWR0aD0iMTk5IiB2YWxp
Z249InRvcCIgc3R5bGU9IndpZHRoOjE0OS4xNXB0O2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEu
MHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4
LjRwdCI+DQo8cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3Bh
biBsYW5nPSJFTi1HQiI+MSAodW5hbGxvY2F0ZWQgbnVtYmVyKTwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjI1NSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxOTEu
MzVwdDtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlk
IHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFk
ZGluZzowY20gNS40cHQgMGNtIDUuNHB0O2hlaWdodDoxOC40cHQiPg0KPHAgY2xhc3M9IlRBQyIg
c3R5bGU9InBhZ2UtYnJlYWstYWZ0ZXI6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPjYwNCBEb2Vz
IG5vdCBleGlzdCBhbnl3aGVyZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0K
PHRyIHN0eWxlPSJoZWlnaHQ6MTguNHB0Ij4NCjx0ZCB3aWR0aD0iMTk5IiB2YWxpZ249InRvcCIg
c3R5bGU9IndpZHRoOjE0OS4xNXB0O2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRl
ci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRwdCI+DQo8
cCBjbGFzcz0iVEFDIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJF
Ti1HQiI+MTI3IChpbnRlcndvcmtpbmcgdW5zcGVjaWZpZWQpPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPC90ZD4NCjx0ZCB3aWR0aD0iMjU1IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjE5MS4z
NXB0O2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQg
d2luZG93dGV4dCAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRk
aW5nOjBjbSA1LjRwdCAwY20gNS40cHQ7aGVpZ2h0OjE4LjRwdCI+DQo8cCBjbGFzcz0iVEFDIiBz
dHlsZT0icGFnZS1icmVhay1hZnRlcjphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+NjA2IE5vdCBh
Y2NlcHRhYmxlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9
InBhZ2UtYnJlYWstaW5zaWRlOmF2b2lkO2hlaWdodDoxOC40cHQiPg0KPHRkIHdpZHRoPSI0NTQi
IGNvbHNwYW49IjIiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MzQwLjVwdDtib3JkZXI6c29s
aWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowY20gNS40cHQgMGNt
IDUuNHB0O2hlaWdodDoxOC40cHQiPg0KPHAgY2xhc3M9IlRBTiI+PHNwYW4gbGFuZz0iRU4tR0Ii
Pk5PVEUgMTombmJzcDsmbmJzcDsmbmJzcDsgQW5vbnltaXR5IERpc2FsbG93ZWQsIFJGQyA1MDc5
IFs3N10gcmVmZXJzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJUQU4iPjxzcGFu
IGxhbmc9IkVOLUdCIj5OT1RFIDI6Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5vIGludGVyd29ya2luZyBp
ZiB0aGUgTy1NR0NGIHByZXZpb3VzbHkgaXNzdWVkIGEgQ0FOQ0VMIHJlcXVlc3QgZm9yIHRoZSBJ
TlZJVEUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9IlRBTiI+PHNwYW4gbGFuZz0i
RU4tR0IiPk5PVEUgMzombmJzcDsmbmJzcDsmbmJzcDsgVGhlIDR4eC81eHgvNnh4IFNJUCByZXNw
b25zZXMgdGhhdCBhcmUgbm90IGNvdmVyZWQgaW4gdGhpcyB0YWJsZSBhcmUgbm90IGludGVyd29y
a2VkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFi
bGU+DQo8L2Rpdj4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9z
cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QlIgQWxlxaE8
L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8
L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8
ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk
ZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy
Z2luLWxlZnQ6MzYuMHB0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDsiPiBDYWxtZSwgSmFtZXMgQSAoSmltKSBbPGEgaHJlZj0ibWFpbHRvOmppbS5jYWxtZUBhbGNh
dGVsLWx1Y2VudC5jb20iPm1haWx0bzpqaW0uY2FsbWVAYWxjYXRlbC1sdWNlbnQuY29tPC9hPl0N
Cjxicj4NCjxiPlNlbnQ6PC9iPiAyNS4gamFudWFyIDIwMTMgMTU6MjM8YnI+DQo8Yj5Ubzo8L2I+
IENocmlzdGVyIEhvbG1iZXJnOyDFoGxpYmVyIEFsZcWhOyA8YSBocmVmPSJtYWlsdG86ZGlzcGF0
Y2hAaWV0Zi5vcmciPmRpc3BhdGNoQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBS
RTogUkZDIDMzOTggLSBwcm9ibGVtcyB3aXRoIElTVVAgY2F1c2UgbWFwcGluZzwvc3Bhbj48c3Bh
biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxzcGFu
IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv
bnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMwMDcwQzAiPlBsZWFzZSByZWZlcmVuY2UgM0dQUCBUUyAyOS4xNjMsIG11Y2ggd29y
ayBhcyBiZWVuIGRvbmUgb24gdGhpcyBkb2N1bWVudCBvdmVyIHRoZSBsYXN0IGNvdXBsZSB5ZWFy
cyB0byBhZGRyZXNzIG1hcHBpbmcgY29uY2VybnMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu
LWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90
O1RyZWJ1Y2hldCBNUyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDcwQzAi
PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3MEMwIj5KaW08L3NwYW4+PHNwYW4gbGFuZz0i
RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p
bHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzAwNzBDMCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj
QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjxhIGhyZWY9Im1haWx0bzpkaXNwYXRjaC1ib3VuY2VzQGll
dGYub3JnIj5kaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnPC9hPiBbPGEgaHJlZj0ibWFpbHRvOmRp
c3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaXNwYXRjaC1ib3VuY2VzQGlldGYub3Jn
PC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Q2hyaXN0ZXIgSG9sbWJlcmc8YnI+DQo8Yj5TZW50
OjwvYj4gRnJpZGF5LCBKYW51YXJ5IDI1LCAyMDEzIDg6MTggQU08YnI+DQo8Yj5Ubzo8L2I+IMWg
bGliZXIgQWxlxaE7IDxhIGhyZWY9Im1haWx0bzpkaXNwYXRjaEBpZXRmLm9yZyI+ZGlzcGF0Y2hA
aWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbZGlzcGF0Y2hdIFJGQyAzMzk4
IC0gcHJvYmxlbXMgd2l0aCBJU1VQIGNhdXNlIG1hcHBpbmc8L3NwYW4+PHNwYW4gbGFuZz0iRU4t
VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i
c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h
cmdpbi1sZWZ0OjcyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdE
Ij5IaSw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVO
LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bWFyZ2luLWxlZnQ6NzIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5
N0QiPlRoZXJlIGlzIG5vIG5ldyBSRkMsIGJ1dCBTRE9zIGxpa2UgSVRVLVQgYW5kIDNHUFAgaGF2
ZSBzcGVjaWZpZWQgbWFwcGluZyB3aGljaCBpbiBzb21lIGNhc2VzIGRpZmZlcnMgZnJvbSB0aGUg
UkZDLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t
VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
YXJnaW4tbGVmdDo3Mi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3
RCI+UmVnYXJkcyw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxh
bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y
OiMxRjQ5N0QiPkNocmlzdGVyPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48
c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu
MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm
dDo3Mi4wcHQiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv
bTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8
YSBocmVmPSJtYWlsdG86ZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZyI+ZGlzcGF0Y2gtYm91bmNl
c0BpZXRmLm9yZzwvYT4gWzxhIGhyZWY9Im1haWx0bzpkaXNwYXRjaC1ib3VuY2VzQGlldGYub3Jn
Ij5tYWlsdG86ZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2Yg
PC9iPsWgbGliZXIgQWxlxaE8YnI+DQo8Yj5TZW50OjwvYj4gMjUuIHRhbW1pa3V1dGEgMjAxMyA5
OjAyPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86ZGlzcGF0Y2hAaWV0Zi5vcmciPmRp
c3BhdGNoQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2Rpc3BhdGNoXSBS
RkMgMzM5OCAtIHByb2JsZW1zIHdpdGggSVNVUCBjYXVzZSBtYXBwaW5nPC9zcGFuPjxzcGFuIGxh
bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+PHNwYW4gbGFuZz0iRU4t
VVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5IaSw8L3NwYW4+PHNwYW4gbGFuZz0i
RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtYXJnaW4tbGVmdDo3Mi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i
RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtYXJnaW4tbGVmdDo3Mi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JJ20gbW9iaWxlIGNvcmUgbmV0d29yayBl
bmdpbmVlciB3b3JraW5nIGEgbG90IHdpdGggSVNVUCB0byBTSVAgbWFwcGluZyBhbmQgdmljZSB2
ZXJzYS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5J
IGNvbWUgdXAgdG8gYW4gdW5zb2x2ZWQgcHJvYmxlbSB3aXRoIG1hcHBpbmcgdGhlIHRyYWZmaWMg
ZnJvbSBJU1VQIHRvIFNJUCBhbmQgYmFjayB0byBJU1VQLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V
UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h
cmdpbi1sZWZ0OjcyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V
UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h
cmdpbi1sZWZ0OjcyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb20gUkZDIDMzOTg6PC9zcGFuPjxzcGFuIGxh
bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxh
bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1
b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SVNVUC1TSVA8L3NwYW4+PC9i
PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7Jm5i
c3A7DQo8c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+MTggbm8gdXNlciByZXNwb25kaW5nJm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDQwOCBSZXF1
ZXN0IFRpbWVvdXQ8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Ojcy
LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOw0KPGI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIw
NTAiPjE5IG5vIGFuc3dlciBmcm9tIHRoZSB1c2VyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDQ4MCBU
ZW1wb3JhcmlseSB1bmF2YWlsYWJsZTwvc3Bhbj48L2I+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT
Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy
Z2luLWxlZnQ6NzIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7IDIwIHN1YnNjcmliZXIgYWJz
ZW50Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IDQ4MCBUZW1wb3JhcmlseSB1bmF2YWlsYWJsZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp
bi1sZWZ0OjcyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9
IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U0lQLUlTVVA6PC9zcGFuPjwvYj48
c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOw0K
PGI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPjQwOCBSZXF1ZXN0IHRpbWVvdXQmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMTAyIFJlY292ZXJ5IG9uIHRp
bWVyIGV4cGlyeTwvc3Bhbj48L2I+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIu
MHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7DQo8Yj48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1
MCI+NDgwIFRlbXBvcmFyaWx5IHVuYXZhaWxhYmxlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDE4IE5vIHVzZXIgcmVzcG9uZGluZzwv
c3Bhbj48L2I+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48c3BhbiBz
dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48c3BhbiBz
dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
OyI+U28gaWYgSSBzZW5kIGZyb20gSVNVUCBSRUwtMTkgYW5kIHRoaXMgdHJhZmljIHdlbnRzIG1h
cHMgdG8gU0lQIGFuZCB0aGVuIGJhY2sgdG8gSVNVUCwgSSByZWNlaXZlIG9uIHRoZSBvdGhlciBz
aWRlIElTVVAgUkVMLTE4Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPlRoZXJlIGlzIHRoZSBzYW1lIHN0b3J5IHdpdGggSVNVUCBSRUwxOCBtYXBwbmcg
dG8gU0lQIGFuZCBiYWNrIHRvIElTVVAg4oCTIEkgd2lsbCByZWNlaXZlIElTVVAgUkVMLjEwMj8h
PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7
PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q2FuIHlv
dSBoZWxwIG1lIHdpdGggdGhpcyBpc3VlLiBJcyB0aGVyZSBhbnkgbmV3IFJGQyBob3cgdG8gbWFw
IHRoaXMga2luZCBvZiB0cmFmZmljPzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Ojcy
LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Ojcy
LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDsiPlRoYW5rIHlvdSw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm
dDo3Mi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7Ij5CUiBBbGVzIFNsaWJlcjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V
UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h
cmdpbi1sZWZ0OjcyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9z
cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDtiYWNrZ3JvdW5kOiNGM0Yz
RjMiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZWQiPkFsZcWhIMWgbGliZXI8
L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O2JhY2tncm91bmQ6I0Yz
RjNGMyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmdyYXkiPkNvcmUgbmV0d29yayBl
bmdpbmVlcjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDtiYWNrZ3JvdW5k
OiNGM0YzRjMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGVsOg0KPC9z
cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzM2NkZGIj4mIzQzOzM4Ni0xLTQ3
Mi04NDgyPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O2JhY2tncm91bmQ6
I0YzRjNGMyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5XLW1vYmlsZToN
Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy
aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzNjZGRiI+PGEgaHJlZj0i
aHR0cDovL3d3dy5tb2JpdGVsLnNpLyI+d3d3Lm1vYml0ZWwuc2k8L2E+PC9zcGFuPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90OyI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4w
cHQ7YmFja2dyb3VuZDojRjNGM0YzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh
Y2siPlctZml4Og0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzM2NkZG
Ij48YSBocmVmPSJodHRwOi8vd3d3LnRlbGVrb20uc2kvIj53d3cudGVsZWtvbS5zaTwvYT48L3Nw
YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7YmFja2dyb3VuZDojRjNGM0YzIj48
Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwNzBDMCI+VGVsZWtvbTwvc3Bhbj48
L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDcwQzAiPg0KPC9zcGFuPjxiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMEYwIj5TbG92ZW5pamU8L3NwYW4+PC9i
PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFu
PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxv
Y2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0
b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t
YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fPGJyPg0KZGlzcGF0Y2ggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl
Zj0ibWFpbHRvOmRpc3BhdGNoQGlldGYub3JnIj5kaXNwYXRjaEBpZXRmLm9yZzwvYT48YnI+DQo8
YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoIj5o
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoPC9hPjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8
L2h0bWw+DQo=

--_000_26300ECDDED68545A78AAC3D98640BF3A157FC84srexdb14tstelek_--

From R.Jesske@telekom.de  Mon Jan 28 10:08:34 2013
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2135021F8901 for ; Mon, 28 Jan 2013 10:08:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.948
X-Spam-Level: 
X-Spam-Status: No, score=-0.948 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MANGLED_LOAN=2.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45ZB5X9rB1Bq for ; Mon, 28 Jan 2013 10:08:32 -0800 (PST)
Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD7521F88A9 for ; Mon, 28 Jan 2013 10:08:28 -0800 (PST)
Received: from he111629.emea1.cds.t-internal.com ([10.134.93.21]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 28 Jan 2013 19:08:26 +0100
Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE111629.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 28 Jan 2013 19:08:26 +0100
From: 
To: , , , 
Date: Mon, 28 Jan 2013 19:08:21 +0100
Thread-Topic: RFC 3398 - problems with ISUP cause mapping
Thread-Index: Ac36L/Ouvi96ppcBSLCYfqPfGqmxGAAl8IiQAACHohAADzCpEAAAKSbQAIxAG4AACh/T0AAIRxcg
Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D16E115C117@HE111648.emea1.cds.t-internal.com>
References: <26300ECDDED68545A78AAC3D98640BF3A157E82F@srexdb14.ts.telekom.si> <7594FB04B1934943A5C02806D1A2204B0CA15E@ESESSMB209.ericsson.se> <7B8DC1AC12241143921AC7733AF3C17B1DF55878@US70TWXCHMBA10.zam.alcatel-lucent.com> <26300ECDDED68545A78AAC3D98640BF3A157F8B6@srexdb14.ts.telekom.si> <7B8DC1AC12241143921AC7733AF3C17B1DF55C31@US70TWXCHMBA10.zam.alcatel-lucent.com>
In-Reply-To: <7B8DC1AC12241143921AC7733AF3C17B1DF55C31@US70TWXCHMBA10.zam.alcatel-lucent.com>
Accept-Language: de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE
Content-Type: multipart/alternative; boundary="_000_580BEA5E3B99744AB1F5BFF5E9A3C67D16E115C117HE111648emea1_"
MIME-Version: 1.0
Subject: Re: [dispatch] RFC 3398 - problems with ISUP cause mapping
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Jan 2013 18:08:34 -0000

--_000_580BEA5E3B99744AB1F5BFF5E9A3C67D16E115C117HE111648emea1_
Content-Type: text/plain; charset="windows-1257"
Content-Transfer-Encoding: quoted-printable

Hi Ales,
that was the discussion we had over the last years in different fora like 3=
GPP, I3 Forum, ETSI TISPAN and also IETF. which result in RFC6432. The reco=
mmendation is if you want to have 100% symmetry then use http://www.rfc-edi=
tor.org/rfc/rfc6432.txt where you put in the Q.850 cause into the SIP respo=
nse as already Jim pointed out.

Thank you and Best Regards

Roland

________________________________
Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im Auftra=
g von Calme, James A (Jim)
Gesendet: Montag, 28. Januar 2013 15:10
An: =D0liber Ale=F0; Christer Holmberg; dispatch@ietf.org
Betreff: Re: [dispatch] RFC 3398 - problems with ISUP cause mapping

True, it is not 100% symmetric.
If it is required to maintain the original ISUP cause, then I would suggest=
 using the Reason header field.
Jim

From: =D0liber Ale=F0 [mailto:Ales.Sliber@telekom.si]
Sent: Monday, January 28, 2013 3:23 AM
To: Calme, James A (Jim); Christer Holmberg; dispatch@ietf.org
Subject: RE: RFC 3398 - problems with ISUP cause mapping

Hi,

Thank you for reply, but as I can see, from 3GPP TS 29.163 document =96 the=
re is quite the same story (maby even worst =96 because ISUP 18 is mapd als=
o in SIP 480 and not in-to SIP-408 as in RFC):


Table 9: Receipt of the Release message (REL)

=95SIP Message


=95 REL


Status code


Cause parameter


404 Not Found


Cause value No. 1 (unallocated (unassigned) number)


500 Server Internal error


Cause value No 2 (no route to network)


500 Server Internal error


Cause value No 3 (no route to destination)


500 Server Internal error


Cause value No. 4 (Send special information tone)


404 Not Found


Cause value No. 5 (Misdialled trunk prefix)


486 Busy Here


Cause value No. 17 (user busy)


480 Temporarily unavailable


Cause value No 18 (no user responding)


480 Temporarily unavailable


Cause value No 19 (no answer from the user)


480 Temporarily unavailable


Cause value No. 20 (subscriber absent)


603 Decline


Cause value No 21 (call rejected), Location =3D 000 / user (U)


480Temporarily unavailable


Cause value No 21 (call rejected) , Location <> 000 / user (U)


410 Gone


Cause value No 22 (number changed)


433 Anonymity Disallowed.(NOTE 1)


Cause value No. 24 (call rejected due to ACR supplementary service)


480 Temporarily unavailable


Cause value No 25 (Exchange routing error)


502 Bad Gateway


Cause value No 27 (destination out of order)


484 Address Incomplete


Cause value No. 28 invalid number format (address incomplete)


500 Server Internal error


Cause value No 29 (facility rejected)


480 Temporarily unavailable


Cause value No 31 (normal unspecified) (class default) (NOTE 2)


486 Busy here if Diagnostics indicator includes the (CCBS indicator =3D CCB=
S possible)

else 480 Temporarily unavailable


Cause value in the Class 010 (resource unavailable, Cause value No 34)


500 Server Internal error


Cause value in the Class 010
(resource unavailable, Cause value No=92s. 38, 41, 42, 43, 44, & 47) (47 is=
 class default)


500 Server Internal error


Cause value No 50 (requested facility no subscribed)


500 Server Internal error


Cause value No 57 (bearer capability not authorised)


500 Server Internal error


Cause value No 58 (bearer capability not presently)


500 Server Internal error


Cause value No 63 (service option not available, unspecified)
(class default)


500 Server Internal error


Cause value in the Class 100 (service or option not implemented, Cause valu=
e No=92s. 65, 70 & 79) 79 is class default


500 Server Internal error


Cause value No 88 (incompatible destination)


404 Not Found


Cause value No 91 (invalid transit network selection)


500 Server Internal error


Cause value No 95 (invalid message)
(class default)


500 Server Internal error


Cause value No 97 (Message type non-existent or not implemented)


500 Server Internal error


Cause value No 99 (information element/parameter non-existent or not implem=
ented))


480 Temporarily unavailable


Cause value No. 102 (recovery on timer expiry)


500 Server Internal error


Cause value No 110 (Message with unrecognised Parameter, discarded)


500 Server Internal error


Cause value No. 111 (protocol error, unspecified)
(class default)


480 Temporarily unavailable


Cause value No. 127 (interworking unspecified)
(class default)


NOTE 1:    Anonymity Disallowed, RFC 5079 [77] refers

NOTE 2:    Class 1 and class 2 have the same default value.





Table 18: 4xx/5xx/6xx Received on SIP side of O-MGCF

=95REL (cause code)


=954xx/5xx/6xx SIP Message


127 (interworking unspecified)


400 Bad Request


127 (interworking unspecified)


401 Unauthorized


127 (interworking unspecified)


402 Payment Required


127 (interworking unspecified)


403 Forbidden


1 (Unallocated number)


404 Not Found


127 (interworking unspecified)


405 Method Not Allowed


127 (interworking unspecified)


406 Not Acceptable


127 (interworking unspecified)


407 Proxy authentication required


127 (interworking unspecified)


408 Request Timeout


22 (Number changed)


410 Gone


127 (interworking unspecified)


413 Request Entity too long


127 (interworking unspecified)


414 Request-URI too long


127 (interworking unspecified)


415 Unsupported Media type


127 (interworking unspecified)


416 Unsupported URI scheme


127 (interworking unspecified)


420 Bad Extension


127 (interworking unspecified)


421 Extension required


127 (interworking unspecified)


423 Interval Too Brief


24 (call rejected due to ACR supplementary service)


433 Anonymity Disallowed.(NOTE 1)


20 Subscriber absent


480 Temporarily Unavailable


127 (interworking unspecified)


481 Call/Transaction does not exist


127 (interworking unspecified)


482 Loop detected


127 (interworking unspecified)


483 Too many hops


28 (Invalid Number format)


484 Address Incomplete


127 (interworking unspecified)


485 Ambiguous


17 (User busy)


486 Busy Here


127 (Interworking unspecified) or not interworked. (NOTE 2)


487 Request terminated


127 (interworking unspecified)


488 Not acceptable here


127 (interworking unspecified)


493 Undecipherable


127 (interworking unspecified)


500 Server Internal error


127 (interworking unspecified)


501 Not implemented


127 (interworking unspecified)


502 Bad Gateway


127 (interworking unspecified)


503 Service Unavailable


127 (interworking unspecified)


504 Server timeout


127 (interworking unspecified)


505 Version not supported


127 (interworking unspecified)


513 Message too large


127 (interworking unspecified)


580 Precondition failure


17 (User busy)


600 Busy Everywhere


21 (Call rejected)


603 Decline


1 (unallocated number)


604 Does not exist anywhere


127 (interworking unspecified)


606 Not acceptable


NOTE 1:    Anonymity Disallowed, RFC 5079 [77] refers.

NOTE 2:    No interworking if the O-MGCF previously issued a CANCEL request=
 for the INVITE.

NOTE 3:    The 4xx/5xx/6xx SIP responses that are not covered in this table=
 are not interworked.



BR Ale=F0

From: Calme, James A (Jim) [mailto:jim.calme@alcatel-lucent.com]
Sent: 25. januar 2013 15:23
To: Christer Holmberg; =D0liber Ale=F0; dispatch@ietf.org
Subject: RE: RFC 3398 - problems with ISUP cause mapping

Please reference 3GPP TS 29.163, much work as been done on this document ov=
er the last couple years to address mapping concerns.

Jim

From: dispatch-bounces@ietf.org [mailto:d=
ispatch-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Friday, January 25, 2013 8:18 AM
To: =D0liber Ale=F0; dispatch@ietf.org
Subject: Re: [dispatch] RFC 3398 - problems with ISUP cause mapping

Hi,

There is no new RFC, but SDOs like ITU-T and 3GPP have specified mapping wh=
ich in some cases differs from the RFC.

Regards,

Christer

From: dispatch-bounces@ietf.org [mailto:d=
ispatch-bounces@ietf.org] On Behalf Of =D0liber Ale=F0
Sent: 25. tammikuuta 2013 9:02
To: dispatch@ietf.org
Subject: Re: [dispatch] RFC 3398 - problems with ISUP cause mapping

Hi,

I'm mobile core network engineer working a lot with ISUP to SIP mapping and=
 vice versa.
I come up to an unsolved problem with mapping the traffic from ISUP to SIP =
and back to ISUP.

>From RFC 3398:

ISUP-SIP
   18 no user responding                   408 Request Timeout
   19 no answer from the user              480 Temporarily unavailable
   20 subscriber absent                    480 Temporarily unavailable

SIP-ISUP:
   408 Request timeout                  102 Recovery on timer expiry
   480 Temporarily unavailable           18 No user responding

So if I send from ISUP REL-19 and this trafic wents maps to SIP and then ba=
ck to ISUP, I receive on the other side ISUP REL-18.
There is the same story with ISUP REL18 mappng to SIP and back to ISUP =96 =
I will receive ISUP REL.102?!

Can you help me with this isue. Is there any new RFC how to map this kind o=
f traffic?

Thank you,
BR Ales Sliber

Ale=F0 =D0liber
Core network engineer
Tel: +386-1-472-8482
W-mobile: www.mobitel.si
W-fix: www.telekom.si
Telekom Slovenije


--_000_580BEA5E3B99744AB1F5BFF5E9A3C67D16E115C117HE111648emea1_
Content-Type: text/html; charset="windows-1257"
Content-Transfer-Encoding: quoted-printable









Hi=20
Ales,


that=20
was the discussion we had over the last years in different fora like 3=
GPP,=20
I3 Forum, ETSI TISPAN and also IETF. which result in RFC6432. The recommend=
ation=20
is if you want to have 100% symmetry then use http://www.rfc-editor.or=
g/rfc/rfc6432.txt where=20
you put in the Q.850 cause into the SIP response as already Jim pointed=20
out.


 


Thank=20
you and Best Regards


 


Roland



  

  

  Von: dispatch-bounces@ietf.org=20
  [mailto:dispatch-bounces@ietf.org] Im Auftrag von Calme, James A=20
  (Jim)
Gesendet: Montag, 28. Januar 2013 15:10
An: =D0=
liber=20
  Ale=F0; Christer Holmberg; dispatch@ietf.org
Betreff: Re: [disp=
atch]=20
  RFC 3398 - problems with ISUP cause mapping


  

  

  
True, =
it is=20
  not 100% symmetric. 

  
If it =
is=20
  required to maintain the original ISUP cause, then I would suggest using =
the=20
  Reason header field.

  
Jim

  
&=
nbsp;

  

  
  
From: =D0liber A=
le=F0=20
  [mailto:Ales.Sliber@telekom.si] 
Sent: Monday, January 28, 2013=
 3:23=20
  AM
To: Calme, James A (Jim); Christer Holmberg;=20
  dispatch@ietf.org
Subject: RE: RFC 3398 - problems with ISUP ca=
use=20
  mapping

  
 

  
Hi,

  
 

  
Thank you for reply=
, but as=20
  I can see, from 3GPP TS 29.163 document =96 there is quite the same story=
 (maby=20
  even worst =96 because ISUP 18 is mapd also in SIP 480 and not in-to SIP-=
408 as=20
  in RFC):

  
 

  
        
T=
able 9:=20
        Receipt of the Release message (REL)

        

        
          

              
=ACSIP Message=20
              

            
              
=AC=20
          REL

              
Status code

            
              
Cause=20
            parameter

              
404=20
              Not Found

            
              
Cause=20
              value No. 1 (unallocated (unassigned)=20
              number)

              
500=20
              Server Internal error

            
              
Cause=20
              value No 2 (no route to network)

          
              
500=20
              Server Internal error

            
              
Cause=20
              value No 3 (no route to destination)

              
500=20
              Server Internal error

            
              
Cause value No. 4 (Sen=
d special=20
              information tone)

              
404=20
              Not Found

            
              
Cause value No. 5 (Mis=
dialled=20
              trunk prefix)

              
486=20
              Busy Here

            
              
Cause=20
              value No. 17 (user busy)

              
480=20
              Temporarily unavailable

            
              
Cause=20
              value No 18 (no user responding)

              
480=20
              Temporarily unavailable

            
              
Cause=20
              value No 19 (no answer from the=20
          user)

              
480=20
              Temporarily unavailable

            
              
Cause=20
              value No. 20 (subscriber=20
          absent)

              
603=20
              Decline

            
              
Cause=20
              value No 21 (call rejected), Location =3D 000 / user=20
              (U)

              
480Temporarily unavailable
=

            
              
Cause=20
              value No 21 (call rejected) , Location <> 000 / user=20
              (U)

              
410=20
              Gone

            
              
Cause=20
              value No 22 (number changed)

              
433=20
              Anonymity Disallowed.(NOTE 1)

            
              
Cause=20
              value No. 24 (call rejected due to ACR supplementary=20
              service)

              
480=20
              Temporarily unavailable

            
              
Cause=20
              value No 25 (Exchange routing error)

              
502=20
              Bad Gateway

            
              
Cause=20
              value No 27 (destination out of order)
<=
/TD>
              
484=20
              Address Incomplete

            
              
Cause=20
              value No. 28 invalid number format (address=20
              incomplete)

              
500=20
              Server Internal error

            
              
Cause=20
              value No 29 (facility rejected)

          
              
480=20
              Temporarily unavailable

            
              
Cause=20
              value No 31 (normal unspecified) (class default) (NOTE=20
              2)

              
486=20
              Busy here if Diagnostics indicator includes the (CCBS indicat=
or =3D=20
              CCBS possible)

              
else=20
              480 Temporarily unavailable

            
              
Cause=20
              value in the Class 010 (resource unavailable, Cause value No=
=20
              34)

              
500=20
              Server Internal error

            
              
Cause=20
              value in the Class 010
(resource unavailable, Cause value =
No=92s.=20
              38, 41, 42, 43, 44, & 47) (47 is class=20
              default)

              
500=20
              Server Internal error

            
              
Cause=20
              value No 50 (requested facility no=20
              subscribed)

              
500=20
              Server Internal error

            
              
Cause=20
              value No 57 (bearer capability not=20
              authorised)

              
500=20
              Server Internal error

            
              
Cause=20
              value No 58 (bearer capability not=20
            presently)

              
500=20
              Server Internal error

            
              
Cause=20
              value No 63 (service option not available, unspecified)
(c=
lass=20
              default)

              
500=20
              Server Internal error

            
              
Cause=20
              value in the Class 100 (service or option not implemented, Ca=
use=20
              value No=92s. 65, 70 & 79) 79 is class=20
              default

              
500=20
              Server Internal error

            
              
Cause=20
              value No 88 (incompatible destination)
<=
/TD>
              
404=20
              Not Found

            
              
Cause=20
              value No 91 (invalid transit network=20
              selection)

              
500=20
              Server Internal error

            
              
Cause=20
              value No 95 (invalid message)
(class=20
              default)

              
500=20
              Server Internal error

            
              
Cause=20
              value No 97 (Message type non-existent or not=20
              implemented)
<=
/TD>
              
500=20
              Server Internal error

            
              
Cause=20
              value No 99 (information element/parameter non-existent or no=
t=20
              implemented))

              
480=20
              Temporarily unavailable

            
              
Cause=20
              value No. 102 (recovery on timer=20
            expiry)

              
500=20
              Server Internal error

            
              
Cause=20
              value No 110 (Message with unrecognised Parameter,=20
              discarded)

              
500=20
              Server Internal error

            
              
Cause=20
              value No. 111 (protocol error, unspecified)
(class=20
              default)

              
480=20
              Temporarily unavailable

            
              
Cause=20
              value No. 127 (interworking unspecified)
(class=20
              default)

              
NOTE 1:    A=
nonymity=20
              Disallowed, RFC 5079 [77] refers

              
NOTE 2:    C=
lass 1=20
              and class 2 have the same default=20
          value.

    
    

      

          

            

          

            

          
          

            

          

            

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

        
 

        
 

      
        
T=
able 18:=20
        4xx/5xx/6xx Received on SIP side of O-MGCF

        

        
              
=ACREL (cause code)

            
              
=AC4xx/5xx/6xx SIP=20
Message

              
127=20
              (interworking unspecified)

            
              
400=20
              Bad Request

              
127=20
              (interworking unspecified)

            
              
401=20
              Unauthorized

              
127=20
              (interworking unspecified)

            
              
402=20
              Payment Required

              
127=20
              (interworking unspecified)

            
              
403=20
              Forbidden

              
1=20
              (Unallocated number)

            
              
404=20
              Not Found

              
127=20
              (interworking unspecified)

            
              
405=20
              Method Not Allowed

              
127=20
              (interworking unspecified)

            
              
406=20
              Not Acceptable

              
127=20
              (interworking unspecified)

            
              
407=20
              Proxy authentication required

              
127=20
              (interworking unspecified)

            
              
408=20
              Request Timeout

              
22=20
              (Number changed)

            
              
410=20
              Gone

              
127=20
              (interworking unspecified)

            
              
413=20
              Request Entity too long

              
127=20
              (interworking unspecified)

            
              
414=20
              Request-URI too long

              
127=20
              (interworking unspecified)

            
              
415=20
              Unsupported Media type

              
127=20
              (interworking unspecified)

            
              
416=20
              Unsupported URI scheme

              
127=20
              (interworking unspecified)

            
              
420=20
              Bad Extension

              
127=20
              (interworking unspecified)

            
              
421=20
              Extension required

              
127=20
              (interworking unspecified)

            
              
423=20
              Interval Too Brief

              
24=20
              (call rejected due to ACR supplementary=20
              service)

            
              
433=20
              Anonymity Disallowed.(NOTE 1)

              
20=20
              Subscriber absent

            
              
480=20
              Temporarily Unavailable

              
127=20
              (interworking unspecified)

            
              
481=20
              Call/Transaction does not exist

          
              
127=20
              (interworking unspecified)

            
              
482=20
              Loop detected

              
127=20
              (interworking unspecified)

            
              
483=20
              Too many hops

              
28=20
              (Invalid Number format)

            
              
484=20
              Address Incomplete

              
127=20
              (interworking unspecified)

            
              
485=20
              Ambiguous

              
17=20
              (User busy)

            
              
486=20
              Busy Here

              
127=20
              (Interworking unspecified) or not interworked. (NOTE=20
              2)

            
              
487=20
              Request terminated

              
127=20
              (interworking unspecified)

            
              
488=20
              Not acceptable here

              
127=20
              (interworking unspecified)

            
              
493=20
              Undecipherable

              
127=20
              (interworking unspecified)

            
              
500=20
              Server Internal error

              
127=20
              (interworking unspecified)

            
              
501=20
              Not implemented

              
127=20
              (interworking unspecified)

            
              
502=20
              Bad Gateway

              
127=20
              (interworking unspecified)

            
              
503=20
              Service Unavailable

              
127=20
              (interworking unspecified)

            
              
504=20
              Server timeout

              
127=20
              (interworking unspecified)

            
              
505=20
              Version not supported

              
127=20
              (interworking unspecified)

            
              
513=20
              Message too large

              
127=20
              (interworking unspecified)

            
              
580=20
              Precondition failure

              
17=20
              (User busy)

            
              
600=20
              Busy Everywhere

              
21=20
              (Call rejected)

            
              
603=20
              Decline

              
1=20
              (unallocated number)

            
              
604=20
              Does not exist anywhere

              
127=20
              (interworking unspecified)

            
              
606=20
              Not acceptable

              
NOTE 1:    A=
nonymity=20
              Disallowed, RFC 5079 [77] refers.

              
NOTE 2:    N=
o=20
              interworking if the O-MGCF previously issued a CANCEL request=
 for=20
              the INVITE.

              
NOTE 3:    T=
he=20
              4xx/5xx/6xx SIP responses that are not covered in this table =
are=20
              not=20
    interworked.

          
          

            

          
          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            

          

            
=

  
 

  
BR Ale=F0

  
 

  

  
  
From: Calme, Jam=
es A=20
  (Jim) [mailto:jim.calme@alcatel-lucent.com] 
Sent: 25. januar 2=
013=20
  15:23
To: Christer Holmberg; =D0liber Ale=F0;=20
  dispatch@ietf.org
Subject: RE: RFC 3398 - problems with ISUP ca=
use=20
  mapping

  
 

  
Please=
=20
  reference 3GPP TS 29.163, much work as been done on this document over th=
e=20
  last couple years to address mapping concerns.

  
 =


  
Jim

  
 =


  

  
  
From: dispatch-bounces@ietf.org [=
mailto:dispatch-bounces@ietf.or=
g]=20
  On Behalf Of Christer Holmberg
Sent: Friday, January 25,=
 2013=20
  8:18 AM
To: =D0liber Ale=F0; dispatch@ietf.org
Subject: Re:=20
  [dispatch] RFC 3398 - problems with ISUP cause mapping

  
 

  
Hi,

  
 <=
/P>
  
There=20
  is no new RFC, but SDOs like ITU-T and 3GPP have specified mapping which =
in=20
  some cases differs from the RFC.=


  
 <=
/P>
  
Regards,

  
 <=
/P>
  
Christer

  
 <=
/P>
  

  
  
From: dispatch-bounces@ietf.org [=
mailto:dispatch-bounces@ietf.or=
g]=20
  On Behalf Of =D0liber Ale=F0
Sent: 25. tammikuuta 2013=20
  9:02
To: dispatch@ietf.org
Subject: Re:=20
  [dispatch] RFC 3398 - problems with ISUP cause mapping

  
 

  
Hi,

  
 

  
I'm mobile core net=
work=20
  engineer working a lot with ISUP to SIP mapping and vice versa.

  
I come up to an uns=
olved=20
  problem with mapping the traffic from ISUP to SIP and back to=20
  ISUP.

  
 

  
From RFC 3398:

  
 

  
ISUP-SIP=


  
   18 no user=20
  responding          &nb=
sp;       =20
  408 Request Timeout
  
   19 no answer from the=20
  user           &nb=
sp; =20
  480 Temporarily unavailable

  
   20 sub=
scriber=20
  absent           &=
nbsp;       =20
  480 Temporarily unavailable

  
   

  
SIP-ISUP:

  
   408 Request=20
  timeout           =
      =20
  102 Recovery on timer expiry

  
   480 Temporarily=20
  unavailable           1=
8 No=20
  user responding

  
 

  
So if I send from I=
SUP=20
  REL-19 and this trafic wents maps to SIP and then back to ISUP, I receive=
 on=20
  the other side ISUP REL-18.

  
There is the same s=
tory with=20
  ISUP REL18 mappng to SIP and back to ISUP =96 I will receive ISUP=20
  REL.102?!

  
 

  
Can you help me wit=
h this=20
  isue. Is there any new RFC how to map this kind of traffic?

  
 

  
Thank you,

  
BR Ales Sliber

  
 

  
<=
SPAN=20
  style=3D"FONT-FAMILY: 'Arial','sans-serif'; COLOR: red; FONT-SIZE: 9pt"=20
  lang=3DSL>Ale=F0 =D0liber
  
Core network engineer<=
/P>
  
Tel: +386-1-472-8482

  
W-mobile: www.mobitel.si=20
  

  
W-fix: www.telekom.si

  
<=
SPAN=20
  style=3D"FONT-FAMILY: 'Arial','sans-serif'; COLOR: #0070c0; FONT-SIZE: 9p=
t"=20
  lang=3DSL>Telekom Slovenije

  
 


--_000_580BEA5E3B99744AB1F5BFF5E9A3C67D16E115C117HE111648emea1_--

From jon.peterson@neustar.biz  Thu Jan 31 18:03:20 2013
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A8E21F8901 for ; Thu, 31 Jan 2013 18:03:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.311
X-Spam-Level: 
X-Spam-Status: No, score=-106.311 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jc5Tl6EJksJu for ; Thu, 31 Jan 2013 18:03:19 -0800 (PST)
Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id DFD8521F88FB for ; Thu, 31 Jan 2013 18:03:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1359684064; x=1675042515; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=W/eEZyQz/pOw47EYTiAHs CzQ6NResAwL8TvXeBbkHY4=; b=m4RKHWWO46mPcO1IoW8JR8Qk3GUyOufNceQ+r wmp1Fi8vS/CK0lxpUw8/9W5SX3jnnaURPhcESuWyIsvi+W+AA==
Received: from ([10.31.13.228]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.15988301;  Thu, 31 Jan 2013 21:01:03 -0500
Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Thu, 31 Jan 2013 21:03:14 -0500
From: "Peterson, Jon" 
To: "dispatch@ietf.org" 
Date: Thu, 31 Jan 2013 21:03:12 -0500
Thread-Topic: TeRQ use cases
Thread-Index: AQHOACBKj0PzRTitgUGLpQeV4DlUgg==
Message-ID: <55A5A9A87506CB4BA580BF9D531957DA921A03FA@STNTEXCH01.cis.neustar.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
x-ems-proccessed: 
x-ems-stamp: up8S7UIrqGusUk7Im1sq8Q==
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [dispatch] TeRQ use cases
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Feb 2013 02:03:20 -0000

I took an action item back in Atlanta to return to the DISPATCH list with a=
 few use cases for TeRQ. Eventually these would probably end up being incor=
porated into the framework spec, provided there's agreement that these seem=
 like good use cases to work on. Some I've fleshed out here more than other=
s for this initial write-up, but hopefully they're all sufficient to commun=
icate the gist. Many of these are familiar use cases, hopefully. Comments w=
elcome.


1) Number translation (mixed public and private directories)

An Internet gateway receives a call from the PSTN destined for a telephone =
number. The gateway resides in a walled garden that has numerous peering po=
ints with other administrative domains, including through a number of clear=
inghouses, typical of a SPEERMINT architecture. The gateway queries two ser=
vices to determine where it should deliver the call. The gateway first make=
s a number translation request of a public directory, which returns a servi=
ce provider identifier (SPID) of the network to which the call should be de=
livered (LUF). The gateway then makes a query to a private directory, inter=
nal to its walled garden, to translate that SPID into the the address of th=
e proper point-of-interconnection to exit the walled garden (LRF).

In this case, the SPID might take the form of a numerical identifier, a dom=
ain name or other identifier; behind the scenes, the internal private direc=
tory may contain links between several different forms of identifiers.

The internal private directory may respond with a different POI depending o=
n which gateway is asking - a USA West Coast gateway might get a different =
answer than an East Coast gateway. The directory therefore authenticates in=
coming queries to identify the originating gateway and serve a customized a=
nswer.

Although the internal private directory is inherently trusted by the gatewa=
y, the public directory (which returns the SPID) is not directly trusted by=
 the gateway. The data in the public directory, however, is provisioned by =
authorities, including the number owners. As they provision records at the =
public gateway, they sign those records, and when the gateway receives a re=
sponse it validates the signatures on the records and trusts those records,=
 or not, based on its association with the signer.

Translations should be available for nationally specific numbers, including=
 freephone numbers.

A very similar use case could also be constructed for SMS (including short =
codes).

2) Customer name, with query aggregation at an intermediary

An Internet gateway receives a call from the PSTN. The gateway wants to put=
 the calling number (IAM CIN) into the username portion of the From header =
field value of a SIP request, and also to populate the display-name of that=
 header field. The gateway therefore launches a query to a CNAM service, wh=
ich may or may not be the same as any services used for number translation.=
 The CNAM service only accepts requests from authorized parties with whom i=
t has a billing relationship. Since the Internet gateway launching the quer=
y is only one of many gateways in its administrative domain, not every gate=
way will have a trust relationship n with the CNAM service. Instead, the ga=
teways send their requests to a local intermediary which aggregates request=
s and maintains a trust relationship with the CNAM service.

Under high volumes, the intermediary maintains a transport connection to th=
e CNAM service, rather than opening a new socket and re-negotiating securit=
y for each individual request. The intermediary may also bundle multiple nu=
mbers into a single request, and expect to get back a response with multipl=
e records associated with those numbers. In both cases, a transaction numbe=
r is used to match requests to responses.

Finally, the intermediary authenticates sources of traffic and authorizes o=
nly gateways to receive responses, as CNAM data is sensitive and the CNAM s=
ervice may charge for transactions.

3) Pre-port validation

A mall kiosk that sells cellular telephones has a customer that wants to pu=
rchase a new phone and port their old number onto the phone. Porting needs =
to be validated on the spot and typically completed in a very short time fr=
ame (say within fifteen minutes). The new service provider for the number n=
eeds to make a query to an intercarrier communications process (ICP) servic=
e to validate the customer with the old service provider. In order to valid=
ate the port, the new service provider needs to submit the telephone number=
, the customer's name and customer's zip code. The ICP needs to respond eit=
her confirming that the customer information is correct for the number in q=
uestion or not.

The responses to ICP queries are potentially privacy-sensitive. It is not f=
easible for every mall kiosk to have a direct relationship with this databa=
se, therefore requests go through an intermediary which has a trust relatio=
nship with the ICP service.

4) Caller-ID Spoofing prevention

An SMS service bureau receives an SMS message from a particular telephone n=
umber. It wants to be able to consult an authoritative service to ascertain=
 whether or not that number is allocated and SMS capable. The bureau sends =
a request to the service to determine if the number in question exists and =
has an SMS capability. Only if a record is returned proving that the number=
 is SMS capable does the bureau forward the SMS to its destination.

A similar use case could be constructed for voice calls.

5) Prefix-based route caching

A soft client on a tablet attempts to call out to a telephone number. The c=
lient has a pre-existing association with a service that performs number tr=
anslation on its behalf; the client knows the address of an intermediary be=
longing to the service, and has security credentials to pass requests throu=
gh that intermediary. When the intermediary forwards the request to the ser=
vice, the service returns a response indicating that the entire thousand-bl=
ock to which that number belongs is routed to an enterprise with an Interne=
t PBX. The intermediary receives this response along with a time-to-live an=
d caches the response locally. When subsequent requests come in from client=
s, the intermediary can match the requests against this prefix, and return =
the appropriate response without needing to consult the service.

6) Multiple authorities

An end user and a service provider both want to provision data against the =
same telephone number; for example, a service provider might want to provis=
ion an endpoint address on an Internet gateway for the number, whereas an e=
nd user might want to provision the preferred voicemail service for the num=
ber. A service can permit multiple authorities to provision data for the sa=
me telephone number. Clients who query for this data might have a trust rel=
ationship with either party or both. When a client launches a query, it sho=
uld receive in response any records that authorities authorize the client t=
o receive, allowing the client to decide what it should trust and use.

7) Inventory search

A Internet service provider provisions many telephone numbers within a give=
n number range. The provider later wants to verify which numbers are associ=
ated with the address of a particular SMSC, perhaps an SMSC that has experi=
enced a failure. The service provider thus wants to formulate a search quer=
y across the entire number range, requesting only those numbers that have t=
hat association. The service where the numbers are provisioned must be able=
 to authenticate the service provider as this sort of search operation woul=
d not be authorized for end users.

Jon Peterson
Neustar, Inc.=